--- title: "文書MCPの振り分け" language: "ja" documentation_version: "3.x" channel: "development" release_context: null source_revision: "10297d1e28653321d6996609fc53718d3b7c8278" working_tree_clean: true source_path: "docs/ja/guides/mcp-gateway.md" source_sha256: "70c13b9fa61b5773f7b1580096186b407677bb16651fca1a8a58366ffe460a07" source_at_revision: true source_url: "https://github.com/matsumotory/ngx_mruby/blob/10297d1e28653321d6996609fc53718d3b7c8278/docs/ja/guides/mcp-gateway.md" html_url: "https://ngx.mruby.org/ja/guides/mcp-gateway/" markdown_url: "https://ngx.mruby.org/markdown/ja/guides/mcp-gateway.md" last_updated: "2026-10-30" --- # 文書MCPの振り分け **用途の設計案です。MCP連携の実行検証はまだありません。** 対象は`next`のngx_mruby 3.xです。HTTP振り分けとストリーム中継は検証されていますが、MCP専用の実例と相互運用テストは未実装です。以下のMCP要件は**2026-07-28**版を対象とします。構築するサービスが満たす要件であり、ngx_mrubyが自動で提供する機能ではありません。 ## 誰のための構成か 文書検索、本文取得、重い原本処理を提供するサービスを想定します。利用者のMCP接続先を一つに保ちながら、運営者は処理先を分けたい。ゲートウェイに許可表とサービス固有の規則を置き、設定済みの処理先を選ぶ構成です。 複数条件や業務の規則を組み合わせる場合にRubyが役立ちます。ヘッダーと処理先の固定対応には、nginxの`map`も使えます。 想定経路は**AIクライアント → 一つの`/mcp` → nginxとRubyの規則 →検索・本文取得・原本処理のバックエンド → 元の応答**です。原本処理と検索のワーカーを分ければ資源の競合を分離できますが、それだけで遅延や容量を保証するものではありません。実環境の負荷で測定してください。 LLM向けのMessages／Responsesと、MCP向けのJSON-RPCは別の経路です。一つのゲートウェイに両方のlocationを置いても、相互変換はしません。stdioとHTTPの変換器、MCPサーバー、ツール発見の集約機能、OAuth実装ではありません。 ## 公開前に満たす責任 [Streamable HTTP仕様](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)と[版の規則](https://modelcontextprotocol.io/specification/versioning)を契約とします。受け付ける版を明示し、古いクライアントとの互換性は別途設計します。2026-07-28版では、プロトコルのセッションとGETストリームが廃止されました。SSE切断はキャンセルを意味します。 `Mcp-Method`、`Mcp-Name`、`MCP-Protocol-Version`は、規定の復号後にJSON-RPC本文と一致する必要があります。宛先のMCPサービスはツール実行前に一致を検査します。ヘッダーだけでは権限を判断できません。discoveryと完全なツール一覧に責任を持つサービスを置き、未知のツールや非対応版を任意のバックエンドに流さず拒否します。JSON／SSE応答と必要なエラーヘッダーも保ちます。 Originを検証し、[MCPの認可契約](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)を満たします。RubyのHashでBearer文字列を照合するだけではOAuthになりません。リソースサーバー側で発行者、対象audience、許可scopeを検証し、別サービス用のトークンを転用しません。本文や秘密の識別子をログに残さず、`tools/call`の一律自動再試行も有効にしません。更新系ツールの再実行は副作用が重複します。 ## 現在再利用できるもの - [HTTP振り分け](/ja/guides/routing/): リクエストから設定済みのupstreamを選ぶ。 - [エージェントプロキシの実例](/ja/guides/agent-proxy/): nginxの接続制限、認証情報の差し替え、バイトを保つ中継。mock LLM APIで検証しています。 - [リクエストのフェーズ](/ja/concepts/request-phases/): nginx内でRubyが動く位置。 これらのテストは個々の仕組みを検証したもので、MCP互換性の証明ではありません。接続制限は同時実行の制御であり、月間利用量やトークン課金ではありません。長時間の購読と短いツール呼び出しを、意図せず同じ枠で数えないようにします。共有利用量集計、イベント単位の処理、最初の応答の期限はv3の予定です。実装状況はエージェントプロキシの状態表で確認できます。 ## 実例の検証項目 後続の実例では、localhostのmock MCPバックエンドを二つと入口を一つ用意し、外部アカウントや実際の認証情報を不要にします。以下の項目を検証します。 1. discoveryと完全なツール一覧、既知／未知のツール、対応／非対応の版、ヘッダーと本文の不一致。 2. 検索と原本処理の振り分け、リクエスト本文と応答バイトの保存。Rubyの規則を編集すると送信先が変わること。 3. Originの拒否、認可エラーと応答ヘッダー、JSON／SSE、切断時のキャンセル、更新系呼び出しを一度だけ送ること。 4. 古い版をサポートする場合は独立したケース。新版のセッションやキャンセルの規則をそのまま古い版へ適用しないこと。 実例が動くまでは、このページは責任分界の設計に使い、振り分けの実習にはHTTPの実例を使います。LLMテストを根拠にMCP準拠を宣言しないでください。