モデルコンテキストプロトコル（MCP）の内部：アーキテクチャ、動機、および内部での利用

はじめに

LLMを活用したアプリケーションは、モデルが多様なソースから最新のドメイン固有データにアクセスする必要性を高めています。MCPは、アプリケーションがデータや機能をあらゆるLLM活用アプリケーションに動的に公開する方法を標準化する統一プロトコルを提供することで、この課題に対応します。

MCPの概要

MCPは、その核となる部分でJSON-RPCベースのクライアント・サーバーアーキテクチャを採用しており、ホストアプリケーションは複数のサーバーに接続できます。

• MCPホスト Claude Desktop、IDE、AIツールなどのLLMを活用したアプリケーションであり、MCPを介してデータにアクセスしたいと考えています。
• MCPクライアント さまざまなプログラミング言語でクライアント側のMCPプロトコルを実装します。これらは、MCPホストがMCPサーバーと接続するための橋渡し役となります。
• MCPサーバー MCPプロトコルを介して特定のデータと機能を公開します。主に3種類の機能を提供できます。
  • リソース MCPサーバーがアプリケーションで読み取り可能にするデータです。ファイルの内容、API応答などが含まれます。リソースはアプリケーションによって制御され、アプリケーションがユーザーフローにどのように含めるかを決定します。
  • ツール MCPサーバーによって公開される機能とデータです。例えば、Kubernetes MCPサーバーは、すべてのポッドを取得したり、ポッドを削除したりするためのツールを公開できます。ツールはモデルによって制御されます。LLMは、与えられたコンテキストに基づいてそれらを呼び出すかどうかを決定します。
  • プロンプト MCPサーバーによって公開される、テンプレート化可能なユーザーインタラクションまたはワークフローです。これらはユーザーによって制御されます。LLMアプリケーションは、ユーザーが適切なプロンプトを選択できるように、それらをどのように公開するかを決定します。

トランスポート

トランスポートは、MCPクライアントとサーバーが互いにどのように通信するかを定義します。

STDIO

この設定では、MCPホスト内のMCPクライアントが、同じマシン上でMCPサーバーを起動する役割を担います。MCPクライアントとMCPサーバー間の通信は、STDINとSTDOUTを介して行われます。この場合、1つのMCPサーバーは1つのMCPクライアントとのみ通信します。

一般的な構成は次のようになります。

例：Dockerと個人アクセストークン（PAT）を使用して、GitHubのMCPサーバーをローカルで実行できます。

GitHub - github/github-mcp-server: GitHub公式のMCPサーバー  

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

認証

通常、認証は2つの方法で行われます。

1. ユーザーは環境変数を使用して、トークンをMCPサーバープロセスに渡すことができます。これは広く使われている方法です。
2. MCPサーバーはOAuth2デバイスフローを実装できます。しかし、公式のMCP仕様では何も規定されていません。

制限事項

• LLM搭載アプリケーションを実行しているユーザーのデバイスは、DockerまたはNode/Pythonをインストールする必要があります。これは開発者にとっては問題ではありませんが、MCPサーバーを利用できる人の数を大幅に減らしてしまいます。
• MCPサーバーがユーザーのデバイス上に存在し、実行されていることを考えると、アップグレードは煩雑になり、迅速なイテレーションが影響を受けます。
• ブラウザで実行されるWebアプリはこれを使用できません。
• OAuth2デバイスフローがない場合、ユーザーはMCPサーバーごとにトークンを設定する必要があります。トークンはデバイスに安全に保存されていないことが多く、ローテーションも煩雑です。

これらの制限を考慮すると、STDIOトランスポートは、企業のサービスやデータソース、またはGitHubやSlackのようなSaaSサブスクリプションの上にカスタムMCPサーバーを作成するには不向きです。しかし、IDEにおける開発者ツールのようなユースケースには役立つでしょう。

ストリーマブルHTTP

ストリーマブルHTTPにより、MCPサーバーはHTTPプロトコルを使用して接続および通信する複数のMCPクライアントを処理できます。これにより、STDIOトランスポートの多くの制限が解消されます。主に：

1. MCPサーバーをユーザーのデバイス上でホストする必要がなくなります。どこにでもホストできます。
2. MCPサーバーに追加された新機能は、すべてのユーザーに即座に利用可能になります。
3. ブラウザ上で動作するウェブアプリでこれを利用できます。

認可

このトランスポートにおける認可は活発に開発が進められています。最新の仕様（2025年3月26日リリース）では、次のように述べられています。

1. MCP認証の実装はOAuth 2.1に従う必要があります。
2. MCP認証の実装は動的クライアント登録に従うべきです。

一般的な認証フローは次のようになります。

上記のフローでは、トークンを発行するMCPサーバーが、リソースサーバーと認可サーバーの両方として機能します。これは、SlackやGitHubなどのプロバイダーがすでにOAuth2認可サーバーを実装している場合、それらのMCPサーバーにとっては非現実的です。IDPが提供する認可サーバーの背後にある企業内のホスト型サービスも、同様の問題を抱えています（例：Oktaが提供する認可サーバーの背後にあるArgoCDのインストール）。

仕様では、これをサードパーティの認可サーバーに委任することが許可されていますが、MCPサーバーは独自のトークンを発行し、サードパーティのトークンとの関係を管理する必要があります。これでは、MCPサーバーが安全なトークン管理とOAuth2ルートを実装する必要があるため、サードパーティの認可サーバーを利用する利点がすべて失われます。

制限事項

• 認証機能を備えたMCPサーバーは、トークンを安全に保存し、そのライフサイクルを管理するために、データベースのようなインフラストラクチャを必要とします。事実上、すべてのMCPサーバーが独自の認可サーバーとなり、これは冗長であり、企業内で維持することは不可能です。 コミュニティは、これを改善するために認可仕様の修正に活発に取り組んでいます。
• Atlassian、Sentry、Slack、Githubなどのプロバイダーは、動的クライアント登録（DCR）をサポートしておらず、OAuth2パブリッククライアントさえサポートしていません。これらのプロバイダーの上にMCPサーバーを構築することは、コミュニティにとってより困難になり、プロバイダーにとってもより多くの作業が必要になります。 Atlassianは最近、独自のMCPサーバーを公開しましたが、そのDCR実装は許可しているのは localhost および、Claudeなどごく一部のリダイレクトURIのみです。

TrueFoundryのアプローチ

TrueFoundryでは、同僚がAtlassian、Sentry、Slack、GitHubなどのアカウントをLLMに追加のコンテキストとして積極的に接続できるようにしたいと考えています。また、すべての従業員が、認可されたLLMを介してのみリソースにアクセスしたり、リソースに対してアクションを実行したりできるようにしたいと考えています。MCP + OAuth2は、これを公開する完璧な方法であると思われます。

• 私たちは、データと機能をLLMにより効率的に公開するために、高品質なMCPサーバーの作成に注力したいと考えています。これを安全に行い、プロバイダー内で定義されたRBAC境界を遵守したいと考えています。
• 異なるMCPサーバーのために追加の認可サーバーを維持したくありません。プロバイダーのOAuth2機能を再利用したいと考えています。
• プロバイダーは通常、OAuth2の機密クライアントのみをサポートしています。DCRやパブリッククライアントは選択肢にすらありません。
• MCP認証の仕様はまだ活発に変更されており、作業が進められています。これに取り組む前に、仕様が安定するのを待つことはできません。

上記を踏まえ、以下のアーキテクチャを考案しました。

ここにはいくつかのコンポーネントがあります。

MCPサーバー

Slack、Sentry、Atlassian、Githubなどのプロバイダー向けに、ストリーマブルHTTPトランスポートに従ったHTTP MCPサーバーを作成しました。

これらのMCPサーバーは、LLMとプロバイダーのHTTP APIの間でプロキシとして機能します。これは1対1の変換ではないことに注意してください。これらのプロバイダーのHTTP APIには、LLMを簡単に脱線させ、コンテキストウィンドウを埋め尽くす可能性のある不要なコンテンツが多数含まれています。例えば、Kubernetes MCPサーバー上のポッド一覧ツールでは、ポッドの仕様が複数のポッドで繰り返されるため、多くの重複コンテンツが含まれます。大きなフィールド、例えば managedFieldsは、ほとんどのユーザーのリクエストには必要ありません。他のSaaSプロバイダーには、ネストされた親エンティティや、アバターURLなどの機能的ではないフィールドが存在します。ここに開発時間のほとんどを費やしたいと考えています。最終的には、LLMがシステムのデータモデルを発見し、リソースの特定のフィールドを動的にクエリできるようなシステムをMCP内に構築する必要があります。

これらのMCPサーバーはHTTP認証ヘッダーを期待し、それをプロバイダーのHTTP APIに直接渡します。

TrueFoundryへのMCPサーバーの登録

MCPサーバーをデプロイした後、各プロバイダー向けにOAuth2アプリまたは機密クライアントを作成します。Slackの場合、このようになります。

上記で、オーソライザーのリダイレクトURIが設定されていることにもお気づきでしょう。通常、次のような形式です。 https://base-url/mcp-integrations/oauth2/callback。

次に、MCPサーバーをURLとともに統合します。

必要であれば、スコープを使用してこの統合全体を読み取り専用にしたり、特定のリソースタイプに権限を付与したりできます。MCPサーバーが任意のリソースを「書き込む」ツールを持ち、ユーザーが「書き込み」アクセス権を持っている場合でも、LLMは同じ特権を得ることはできません。

TrueFoundry GatewayでのMCPサーバーの選択と認証

統合が完了すると、Gateway PlaygroundでMCPサーバーを選択できます。

ユーザーが認証されていない場合、統合内のOAuth2クライアント情報を使用して、OAuth2認証コードフローをユーザーに案内します。プロセスの最後に、TrueFoundryはアクセスおよびリフレッシュトークン（サポートされ、有効になっている場合）を安全に保存します。

TrueFoundryから認証情報を削除したり、プロバイダーから直接取り消したりすることも可能です。

ぜひご利用ください！

一度認証されると、MCPサーバーからのコンテキストを当社のPlaygroundで直接使用できます。

なお、OAuth2認証情報はフロントエンドには渡されません。フロントエンドはAPIを呼び出します：

curl -X POST "https://base-url/api/llm/agent/responses" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-main/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "what are the issues in my app"
      }
    ],
    "tools": [
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:sentry",
        "tools": ["list_projects", "list_issues"]
      },
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:slack"
      }
    ]
  }'

‍

LLM Gatewayは「エージェント的」ループを実装し、初期メッセージとMCPサーバーのツール記述をLLMに送信します。ユーザーはLLMに公開されるツールをフィルタリングすることも可能です。LLMの応答に基づいて、LLM GatewayはMCPサーバーと通信し、呼び出し元の認証情報を渡すことができます。短期間有効な認証情報は自動的に更新されます。更新はSSEを使用してフロントエンドに送信されます。

結論

このMCP + OAuth2フローにより、当社の同僚はSlack、GitHub、Sentryなどのプロバイダーからのデータを、LLM中心のワークフローに安全に組み込むことができました。

いくつかのユースケースをご紹介します。

• LLMはMCPを介してSentryにアクセスし、エラーの詳細を取得し、GitHubからの関連するコード変更と関連付けることで、デバッグを高速化できます。
• LLMはMCPを通じてJiraチケットを作成、更新、照会し、開発者のワークフローを効率化します。
• LLMはMCPを介してSlackの会話にアクセスし、長い議論スレッドを分析・要約することで、チームがチャットログ全体を読むことなく、意思決定やアクションアイテムを迅速に理解するのに役立ちます。