モデル・コンテキスト・プロトコル（MCP）の分解

MCPのクライアント・サーバー・アーキテクチャ

MCPは、AIモデルが外部データソースを取得し、相互作用する方法を構造化したクライアント・サーバー・モデルに基づいて構築されている。

• MCPクライアントは、AIエージェント、アプリケーション、または構造化データを要求するあらゆるシステムである。
• MCPサーバーは仲介役として、様々なAPI、データベース、または企業システムからデータを取得し、一貫性のあるフォーマットで返します。

AIモデルが直接APIリクエストを行う代わりに、MCPサーバーが認証、データ検索、レスポンスの正規化といった複雑な処理を行う。つまり、AIエージェントは複数のAPI認証情報、異なるリクエスト形式、一貫性のないレスポンス構造を管理する必要がなくなる。

例えば、AIモデルがGoogle Drive、Slack、データベースなどの複数のサービスから情報を引き出す必要がある場合、各APIに個別に問い合わせることはない。MCPサーバーはリクエストを処理し、必要なソースからデータを収集し、整理されたレスポンスを返す。

MCPリクエスト・レスポンスのライフサイクル

典型的なMCPインタラクションは、冗長なAPIコールを排除し、データ検索を標準化する、構造化されたリクエスト-レスポンス・サイクルに従う。

1.AIエージェントはMCPサーバーに構造化されたリクエストを送信する。個々のAPIリクエストを作成する代わりに、エージェントは必要なデータを統一されたフォーマットで定義する。

{

  "request_id"："xyz-987"、

  "クエリ"：[

    {"source": "github", "action": "get_recent_commits", "repo": "company/project"},

    {"source": "slack", "action": "fetch_unread_messages", "channel": "engineering"}

  ]

}

2.MCPサーバーは、認証の有効性を確認し、アクセス許可をチェックし、照会する外部シス テムを決定することによって、リクエストを処理する。

3.クエリーは並列に実行される。つまり、複数のサービスからのデータが順次ではなく同時に取得されるため、全体的な待ち時間が短縮される。

4.異なるソースからの回答は、AIモデルが容易に処理できる構造化されたフォーマットに標準化される。

{

  "github": {

    "recent_commits"：[

      {"author": "Alice", "message": "Refactored AI pipeline", "timestamp": "2024-03-12T10:15:00Z"}

    ]

  },

  "slack": {

    "unread_messages"：[

      {"user": "Bob", "text": "Hey, can you review the PR?", "timestamp": "2024-03-12T09:45:00Z"}

    ]

  }

}

手作業による解析が必要な生のAPIレスポンスとは異なり、MCPは、取得されたすべてのデータが予測可能な構造化されたフォーマットに従っていることを保証し、AIモデルが理解し、利用しやすくする。

クエリーの実行とレスポンスの集約

MCPは、構造化された実行プロセスを導入することで、AIモデルが外部システムとどのように相互作用するかを最適化するように設計されている。

1. リクエスト・バリデーションは、データを取得する前に、AIモデルが必要な権限を持っていることを保証する。
2. クエリ・ルーティングは、どの外部サービスにアクセスする必要があるかを決定する。
3. 並列実行は、複数のソースから同時にデータを取得し、逐次的なAPIリクエストによって引き起こされる遅延を軽減します。
4. レスポンスの集約は、構造化データを単一のレスポンスに統合し、AIモデルが複数の生のAPI出力を手作業で処理する必要性を排除する。

冗長なリクエストを減らし、レスポンスを正規化し、認証を一元的に処理することで、MCPは不必要なAPIのオーバーヘッドを排除し、AI主導の自動化をよりスケーラブルにする。

認証の課題

MCPの最大の約束の一つは、AIエージェントをAPI固有の統合に依存しないようにすることである。しかし、認証（AuthN）は依然として大きな課題である。

今日、API認証は断片的なプロセスであり、OAuthを使用するサービスもあれば、APIキーに依存するサービスもあり、セッションベースの認証を必要とするサービスもある。この一貫性のなさが、新しいAPIのオンボーディングに時間がかかる原因となっており、MCPには現在、この複雑さを処理する認証フレームワークが組み込まれていない。

つまり、MCPを使用するAIエージェントは、APIクレデンシャルを管理するために、Composioのような追加のソリューションに依存しなければならない。認証はMCPのロードマップ上にあるが、それが完全に実装されるまでは、開発者は複数のシステム間で認証を処理するための回避策が必要になる。

不明確なアイデンティティ管理

もう1つの未解決の問題は、ID管理である。AIエージェントがMCPを通じてリクエストを行ったとき、外部のシステムは誰を見るのだろうか？

例えば、AIアシスタントがMCP経由でSlack 問い合わせをした場合、Slack そのリクエストの発信元を認識できるだろうか：

• エンドユーザーですか？
• AIエージェントそのもの？(そうなると、Slack AIベースのやりとりを別に扱う必要がある)。
• 共有のシステムアカウントか？

この問題は、誰がどのデータを取得できるかをアクセス・コントロール・ ポリシーによって決定する企業環境ではさらに複雑になります。明確なIDマッピングがなければ、MCPの統合はアクセス制限、セキュリティリスク、または異なるプラットフォーム間での不整合に直面する可能性があります。

MCPではOAuthのサポートが予定されており、アイデンティティの取り扱いが明確になるかもしれないが、これが完全に実装されるまでは、AIモデルはサードパーティ・サービスへの許可制アクセスで苦労するかもしれない。 

ベンダーのロックインとエコシステムの断片化

MCPは現在、Anthropic主導のイニシアチブであり、長期的な標準化については疑問が残る。AIのエコシステムが進化するにつれて、OpenAI DeepSeekのような他の主要なプレーヤーが、AIとシステムの相互作用のための独自のプロトコルを開発する可能性が高い。

競合する複数の規格が登場すれば、業界は細分化され、開発者は互換性のない異なるアプローチを選択せざるを得なくなる可能性がある。MCPが支配的なアプローチであり続けるのか、それとも単に競合するいくつかの選択肢のひとつになるのかは、まだわからない。