MCPゲートウェイおすすめ8選【2026年版】認証・ツール単位の権限・トークン削減で比較ランキング
MCPゲートウェイ8製品（Obot、Cloudflare MCP Server Portals、agentgateway、IBM ContextForge、NodeFlare、Composio、Docker、Kong）を、認証・ツール単位の認可・上流の認証情報・集約とstdio・トークン削減・監査ログ・分離・料金の公開基準で採点。2026年10月時点で公式情報を確認。
最終更新：2026年10月19日 ／ 各社の機能・料金は2026年10月19日に公式ドキュメント・料金ページ・公式GitHubのREADMEで確認
開示： NodeFlareは筆者の運営するサービスです。全サービスを下に公開した同じ基準で採点し、公式に記載のない項目は自社も含めて控えめに評価しました。その結果、NodeFlareはこのランキングで1位ではありません。
結論（30秒で読める要約と順位表）
MCPゲートウェイとは、MCPクライアント（Claude、Cursor、自作エージェントなど）とMCPサーバーの間に立つプロキシで、「誰が接続できるか」「どのツールを呼べるか」「上流サービスの認証情報をどう扱うか」「何を記録するか」をまとめて管理するものです。8つのゲートウェイを8つの評価基準（重み付き、後述）で採点した結果は次のとおりです（2026年10月時点）。
| 順位 | ゲートウェイ | 得点（100点満点） | 向いている人 |
|---|---|---|---|
| 1 | Obot MCP Gateway | 87 | ユーザー単位・ツール単位のポリシー、上流OAuth、監査ログをまとめて欲しいチーム（MITでセルフホスト、またはObot Cloud） |
| 2 | Cloudflare MCP Server Portals | 85 | 多数のリモートMCPサーバーを、SSOで守られた1つのURLにまとめたい人 |
| 3 | agentgateway | 81 | OSS（Apache-2.0）のRust製プロキシで、CELポリシーとOpenTelemetryを使いたい基盤チーム |
| 4 | IBM ContextForge | 81 | MCP・REST・gRPCを仮想サーバーにまとめ、RBACやOPA/Cedarで制御したい企業 |
| 5 | NodeFlare | 79 | GitHubのサーバーをホスティングしつつ、APIキー・OAuth検出・ツール単位のスコープ・トークン削減も一度に済ませたい人 |
| 6 | Composio | 71 | 数百のSaaSへのOAuth接続を任せたいエージェント開発者（月10万ツール呼び出しまで無料） |
| 7 | Docker MCP Gateway | 69 | コンテナ化したMCPサーバーを手元で安全に動かしたい個人開発者 |
| 8 | Kong AI Gateway（MCPプラグイン） | 64 | すでにKongを使っており、OAuth 2.1のリソースサーバーとツール単位のACLを足したい企業 |
選ぶときは、次の3点でほぼ決まります。
- 1つのURLに複数サーバーをまとめたいか。 Obot、Cloudflare、agentgateway、ContextForgeは集約が前提の設計です。NodeFlareとKongは1サーバーにつき1つのURLです。
- サーバーをどこで動かすか。 CloudflareはリモートのHTTPサーバーを中継するだけです。Obot、agentgateway、ContextForge、Dockerはstdioサーバーも動かせます。NodeFlareはサーバー自体をホスティングします。
- ゲートウェイを自分で運用したいか。 agentgateway、ContextForge、Dockerはセルフホストのみ、Cloudflare、Composio、NodeFlareはマネージド、ObotとKongは両方を選べます。
この記事はゲートウェイの比較です。サーバーをどこで動かすかを決めたい場合は、姉妹記事のMCPサーバーホスティングおすすめ8選（2026年版）を参照してください。
目次
- 評価基準と重み
- 比較表（8サービスを同じ項目で）
- 採点の内訳
- 各ゲートウェイの解説
- 用途別のおすすめ
- NodeFlareならこう解決できる
- よくある質問
- まとめと参考資料
評価基準と重み
採点の前に基準を決めました。各基準を1〜5点で採点し、重みを掛けて100点満点に換算しています。
| 評価基準 | 重み | 5点の条件 |
|---|---|---|
| クライアント認証 | 20 | MCPクライアント向けのOAuth（Protected Resource Metadata）に加え、APIキーか自社IdPでのSSOに対応 |
| ツール単位の認可 | 20 | ユーザー・グループ・トークンごとに個別ツールの許可・拒否ができ、毎回の呼び出しで検査される |
| 上流の認証情報の扱い | 10 | 上流サービスのシークレットやOAuthトークンをゲートウェイが管理し、エージェントに渡さない |
| 集約と対応サーバー | 15 | 複数サーバーを1つのURLにまとめられ、リモートHTTPとstdioの両方に対応 |
| トークン削減 | 10 | モデルが読むツール一覧を減らす機能（絞り込み、ツール検索、コードモード）がある |
| 監査と可観測性 | 10 | 呼び出しごとに利用者とツール名を記録し、外部へ出力できる。OpenTelemetry対応なら理想 |
| 分離とネットワーク制御 | 5 | サーバーのコードを隔離して動かし、外向き通信を制限できることが文書化されている |
| 導入の手間と料金 | 10 | すぐ始められ、料金が公開され、使える無料枠か無料ライセンスがある |
採点ルール：
- 公式情報だけを根拠にする。 2026年10月19日に各社の公式ドキュメント、料金ページ、公式GitHubのREADMEを読みました。
- 記載がなければ2点。 公開されていない項目は2点とし、本文にその旨を書いています。
- 中継専用のゲートウェイは分離を2点、ネットワーク制御があれば3点。 サーバーのコードを動かさないので隔離の対象がありません。Cloudflareは、任意でDLP検査つきのGateway経由にできるため3点です。
- 同点の場合は監査と可観測性の点で順位を決める。 制御の次に大事なのは「何が起きたか」の記録だからです。
比較表（8サービスを同じ項目で）
以下はすべて2026年10月19日時点で公式ページを確認した内容です。「記載なし」は公開ページで見つけられなかった項目です。
| ゲートウェイ | 提供形態 | クライアント認証 | ツール単位の制御 | 上流の認証情報 | 集約・stdio | トークン削減 | ログ | 料金 |
|---|---|---|---|---|---|---|---|---|
| Obot | セルフホスト（MIT）またはObot Cloud | APIキー・Bearerトークン、OAuth。GoogleとGitHubのIdP（OktaとEntraはEnterprise版） | ユーザーまたはIdPグループ単位でツールごと | 上流サーバー向けのOAuthトークン交換と更新を代行 | 複合サーバー。リモートとnpx/uvxのstdioサーバーに対応 |
ツールの選択、リクエスト・レスポンスのフィルター | リクエストとレスポンスを関連づけた監査ログ | セルフホストは無料。Cloudの料金は非公開（14日間の試用あり） |
| Cloudflare MCP Server Portals | マネージド | Cloudflare Access経由で自社IdP、マネージドOAuth、サービストークン | ポータル単位でツールをオフ、サーバーごとにAccessポリシー | ユーザーごとに上流へOAuth、クライアントシークレットは暗号化保存 | 1ポータル最大80サーバー。リモートHTTPのみ | minimize_tools（公式は「最大5倍」の削減と記載）、search_and_execute、Code Mode |
Accessのリクエストログ。LogpushはEnterpriseのみ | Cloudflare Zero Trustが必要（Freeプランは50ユーザーまで$0）。ポータル単体の料金は記載なし |
| agentgateway | セルフホスト（Apache-2.0） | JWT。Protected Resource Metadataを返すリソースサーバーとして動作 | ツール・プロンプト・リソースへのCELルール | サーバー側でシークレットを注入、トークン交換 | 複数サーバーを集約。stdio、リモートHTTP、OpenAPIに対応 | クライアントごとのツール仮想化 | OpenTelemetryのトレース、メトリクス、構造化ログ | 無料（OSS）。Solo.ioのEnterprise版は料金非公開 |
| IBM ContextForge | セルフホスト（Apache-2.0） | Basic、JWT、SSO（Keycloak、Google、GitHub、Entra ID）、DCR対応のOAuth | 4つの組み込みロールのRBAC、OPA・Cedarプラグイン | ユーザー単位のOAuth、暗号化保存、On-Behalf-Ofトークン交換 | 仮想サーバー。リモート、stdio（translate経由）、REST、gRPC | タグによる絞り込み、TOON圧縮、出力系プラグイン | ネイティブのOpenTelemetry | 無料（OSS） |
| NodeFlare | マネージド（サーバーもホスティング） | mcp_*のBearer APIキー、OAuth検出（RFC 8414 / 9728）、IP許可リスト |
tools:call:<name>などのスコープを毎リクエストで検査 |
シークレットはVM起動時に注入。認証情報の素通しも可 | ホスティングした1サーバーにつき1つのURL。GitHubのstdio・HTTPサーバーに対応 | スコープによる絞り込み、スキーマ短縮、ツール検索、コードモード | リクエストごとのログ（引数は名前のみで値は記録しない）。保存7日または30日 | Free：1サーバー・月30 GB時間。Pro：月額2,980円 |
| Composio | マネージド | x-api-keyヘッダー。利用者はuser_idで識別 |
サーバーごとのallowed_tools、セッションごとのツールキット制限 |
Connect Linksで1,000以上のアプリへの認証を代行 | 1サーバーに複数のComposioツールキット。外部サーバーとstdioは記載なし | セッションは少数のメタツールだけを公開 | Logs API | Hobby $0（月10万ツール呼び出し）、Pro 月$29 |
| Docker MCP Gateway | セルフホスト・ローカル（MIT） | ローカル用トークン（MCP_GATEWAY_AUTH_TOKEN）。OAuthは記載なし |
--toolsの許可リスト、プロファイルごとのツール |
Docker Desktopのシークレット、GitHubなどへのOAuth | コンテナ化した多数のstdioサーバーを1つに集約。リモートは記載なし | Dynamic MCP（mcp-find、mcp-add、コードモード） |
--log-calls、呼び出しのトレース |
無料（OSS）。Dockerのプランは$0から |
| Kong AI Gateway | セルフホストまたはKonnect | AI MCP OAuth2プラグイン（OAuth 2.1のリソースサーバー）、OIDC、Key Auth | コンシューマー・グループ単位のツールACL（3.13以降） | passthrough_credentialsを設定しない限り上流に渡さない。トークン交換は3.14以降 |
パススルー1経路につきリモート1サーバー。RESTのMCP変換。stdioなし | 記載なし | 許可・拒否した呼び出しの監査ログ、MCPメトリクス | MCPプラグインはAI Gateway Enterpriseが必要。Plusは月$25から。30日間の試用 |
採点の内訳
| ゲートウェイ | 認証(20) | ツール単位(20) | 上流(10) | 集約(15) | トークン(10) | 監査(10) | 分離(5) | 導入・料金(10) | 合計 |
|---|---|---|---|---|---|---|---|---|---|
| Obot | 4 | 5 | 5 | 5 | 3 | 5 | 4 | 3 | 87 |
| Cloudflare Portals | 5 | 4 | 4 | 4 | 5 | 4 | 3 | 4 | 85 |
| agentgateway | 4 | 5 | 3 | 5 | 3 | 5 | 2 | 3 | 81 |
| IBM ContextForge | 4 | 5 | 4 | 5 | 3 | 4 | 2 | 3 | 81 |
| NodeFlare | 4 | 5 | 2 | 2 | 5 | 4 | 5 | 5 | 79 |
| Composio | 3 | 3 | 5 | 3 | 5 | 3 | 2* | 5 | 71 |
| Docker MCP Gateway | 2 | 3 | 4 | 4 | 4 | 3 | 5 | 5 | 69 |
| Kong AI Gateway | 5 | 4 | 3 | 2 | 1 | 4 | 2 | 2 | 64 |
* 公開ページに記載がないため、ルールどおり2点。agentgatewayとContextForgeは同点ですが、OpenTelemetryのトレースに加えてMCP専用のメトリクスとツール名のログ項目があるため、agentgatewayを上にしています。
得点 =（各点数 × 重み）の合計 ÷ 5。例：Obotは（4×20 + 5×20 + 5×10 + 5×15 + 3×10 + 5×10 + 4×5 + 3×10）÷ 5 = 87点です。
各ゲートウェイの解説
1. Obot MCP Gateway：チームで使うなら最もバランスがよい
Obotはゲートウェイを「ユーザーが到達を許されたすべてのMCPサーバーへの、統制された単一の入口」と説明しています。MITライセンスで、KubernetesかDockerでセルフホストするか、Obot Cloudを使えます。
強み： どのユーザー・グループ・エージェントが、どのサーバーのどのツールを呼べるかをポリシーで決められます。上流MCPサーバーへのOAuthトークンの交換と更新をObotが代行するので、エージェントは生の認証情報を持ちません。複数サーバーから選んだツールだけを出す「複合サーバー」、外部のMCPエンドポイントへの接続、npx・uvxのstdioサーバーの実行にも対応します。リクエストとレスポンスを関連づけた監査ログ、本体と分けた実行環境、ドメイン単位の外向き通信ルールもあります。
弱み： Okta・Entra・SAML/OIDCのIdP連携はEnterprise版です。Obot Cloudの料金は公開されていません（14日間の試用あり）。ツール検索やコードモードの専用機能は記載がありません。
向いている人： 社員全体にMCPを展開し、人ごとのツール権限と監査証跡が必要な組織。
2. Cloudflare MCP Server Portals：リモートサーバーをまとめるマネージド型の本命
ポータルは複数のMCPサーバーを1つのHTTPエンドポイントにまとめるもので、1ポータルあたり最大80サーバーまで登録できます。利用者はCloudflare Access経由で自社のIdPにログインし、MCPクライアントはマネージドOAuthで接続します。ブラウザ以外のクライアントにはWWW-Authenticateヘッダーつきの401が返ります。
強み： IdPとの統合が強く、機械同士の接続にはサービストークンも使えます。オフにしたツールはポータルのツール一覧に出ません。公式ドキュメントではminimize_toolsで「最大5倍」のトークン削減とされ、search_and_executeやCode Modeを使えば、サーバーを足してもコンテキストの消費量が一定に保たれます。任意でGateway経由にすると、HTTPログとDLP検査が加わります。
弱み： 対応するのはリモートのHTTPサーバーだけなので、stdioサーバーは先にどこかでホスティングする必要があります。LogpushでのログのエクスポートはEnterpriseのみで、デバイス認証にも対応していません。ポータル単体の料金は公開されていません（Cloudflare Zero Trustの一部で、Freeプランは50ユーザーまで）。
向いている人： すでにCloudflare Zero Trustを使っていて、多数のリモートサーバーをSSOつきの1つのURLにまとめたい会社。
3. agentgateway：基盤チーム向けのOSSプロキシ
agentgatewayはApache-2.0のRust製プロキシで、2025年にLinux Foundationへ寄贈されました。stdioのサブプロセス、リモートHTTPサーバー、OpenAPIのバックエンドを含む複数のMCPサーバーを、1つのエンドポイントに集約できます。
強み： JWT認証を内蔵し、MCP認可仕様のリソースサーバーとしてProtected Resource Metadataを返せます（KeycloakとAuth0のアダプターあり）。ツール・プロンプト・リソースへの呼び出しをCELのルールで評価できます。OpenTelemetryのトレース、mcp_requests_totalメトリクス、ツール名を含むログもそろっています。クライアントごとにツールを仮想化して見せ分けることもできます。
弱み： セルフホストのみです（Solo.ioのEnterprise版は料金非公開）。stdioサーバーは単なるサブプロセスとして動き、隔離の仕組みは記載がありません。権限のないツールがtools/listから隠れるかは確認できませんでした。
向いている人： インフラを自分たちで運用でき、特定ベンダーに依存しないポリシー・アズ・コードで制御したい基盤チーム。
4. IBM ContextForge：MCPとREST・gRPCをまとめたいなら
ContextForgeはMCP、A2A、REST、gRPCを1つのエンドポイントにまとめるゲートウェイ兼レジストリです。Apache-2.0で、機能制限のある有料版はないと明記しています。
強み： 4つの組み込みロールによるRBACとチーム単位のカタログ、OPA（Rego）・Cedar・レート制限のプラグインがあります。上流にはユーザー単位のOAuth、暗号化した認証情報の保存、On-Behalf-Ofのトークン交換で接続できます。連携した複数サーバーのツールを仮想サーバーにまとめられ、stdioサーバーもmcpgateway.translateでStreamable HTTPとして公開できます。OpenTelemetryにネイティブ対応し、Output Length GuardやTOON圧縮など出力を小さくするプラグインもあります。
弱み： セルフホストのみです。READMEは信頼できないサーバーにはサンドボックス・コンテナ・microVMを使うよう勧めていますが、それは自分で用意する必要があります。セマンティックなツール検索はロードマップ段階です。
向いている人： 既存の社内APIをMCPツールとして、1つの統制されたカタログで公開したい企業。
5. NodeFlare：ホスティングとゲートウェイ機能を一度に済ませたいなら
NodeFlareはMCPのホスティングサービスで、そのプロキシがゲートウェイの役割も担います。GitHubのリポジトリを選ぶとビルドと動作確認が行われ、発行される/mcpのURLへのリクエストはすべて認証、スコープ検査、トークン削減のフィルターを通ります。
強み： mcp_*のBearer APIキー（ハッシュ化して保存）、RFC 8414 / RFC 9728に沿ったOAuth検出、誤ったキーが続いたIPを10分間ブロックする仕組み、空なら全拒否になる送信元IPの許可リストがあります。スコープはメソッドと対象まで毎リクエストで検査されます（tools:call:get_weather、resources:read:<uri>など）。トークン削減は4つのスイッチ（tool_list_filter_by_scope、tool_schema_slim、tool_search_mode、tool_code_mode）で切り替えられます。サーバーごとに専用のFirecracker microVMで動き、外向き通信の許可リスト（observeかenforce、最大100件）も使えます。料金は公開されていて、無料プランもあります。
弱み： 前に立てるのは自分でホスティングしたサーバーだけで、1サーバーにつき1つのURLです。他社でホスティングされたリモートサーバーを集約する用途には使えません。上流SaaSへのマネージドOAuthはなく、シークレットは環境変数として渡します。ログは引数の名前だけを残して値は残さないため、プライバシーには有利ですが、事後の再現調査には不向きです。自社IdPとのSSOは記載がありません。料金は日本円です。
向いている人： 自作やOSSのMCPサーバーをデプロイしつつ、別のゲートウェイを運用せずに認証・ツール単位の権限・トークン削減を済ませたい開発者。
6. Composio：SaaSへの認証を大規模に任せたいなら
Composioは1,000以上のアプリを対象に、ツールの検索、アカウント接続、実行を提供します。MCPクライアントはx-api-keyヘッダーで接続し、エンドユーザーはConnect Linksで自分のアカウントをつなぎます。
強み： 巨大なカタログへの認証を任せられます。セッションは少数のメタツールだけを公開し、アプリのスキーマはエージェントが必要としたときに読み込まれます。サーバーごとのallowed_tools、ツール・入力・レスポンス・所要時間を確認できるLogs APIもあります。料金も明確で、Hobbyは$0で月10万ツール呼び出し、Proは月$29（$29分の利用料込み、超過は1呼び出し$0.0003）です。
弱み： 対象はComposio自身のツールキットです。自作や外部のMCPサーバーを前に立てること、stdioサーバーの実行は記載がありません。RBACやサンドボックスの詳細も記載がなく、SSO・SCIMはEnterpriseの機能です。
向いている人： Gmail、Slack、GitHubなどとの連携を、ユーザーごとのOAuthごと任せたいエージェント開発者。
7. Docker MCP Gateway：手元のコンテナで安全に動かすなら
OSS（MIT）のdocker mcp CLIプラグインで、Docker DesktopのMCP Toolkitの中核です。AIモデルは1つのゲートウェイを通して各MCPサーバーにアクセスし、サーバーはそれぞれ別のコンテナで動きます。
強み： ローカルで使う選択肢の中では隔離が最も強力です。初期設定で1 CPU・2 GBの上限、ホストのファイルシステムへのアクセスなし、--block-secretsと--block-network、署名とSBOMつきのカタログイメージがそろっています。Docker Desktopのシークレット管理やGitHub・NotionなどへのOAuthにも対応します。Dynamic MCPではmcp-find、mcp-add、コードモードが使えます（Docker Desktop 4.50以降）。無料です。
弱み： クライアント認証はDNSリバインディング対策のローカル用トークンだけで、OAuthやSSOは記載がありません。ツールの制御は許可リストで、ユーザー単位のポリシーではありません。リモートサーバーの中継も記載がありません。pkg.go.devにはこのプロジェクトの脆弱性情報GO-2026-5604が載っているので、常に最新版を使ってください。
向いている人： ノートPCで多数のMCPサーバーを、ホストへのアクセス権を渡さずに動かしたい個人開発者。
8. Kong AI Gateway：Kongをすでに使っている企業なら
KongのAI MCP ProxyとAI MCP OAuth2のプラグイン（Kong Gateway 3.12以降）を使うと、ゲートウェイがMCP向けのOAuth 2.1リソースサーバーになります。3.13からはコンシューマーやコンシューマーグループ単位でツールのACLを設定でき、拒否された呼び出しにはHTTP 403が返ります。
強み： Key Auth、OIDC、レート制限など、成熟したAPIゲートウェイの機能をそのまま使えます。許可・拒否したツール呼び出しの監査ログ、RESTのMCP変換もあり、セルフホストでもKonnectでも動きます。
弱み： MCPプラグインはAI Gateway Enterpriseでしか使えず、恒久的な無料枠はありません（30日間の試用のみ）。パススルーの1経路で中継できるのはリモートサーバー1つで、stdioやトークン削減の機能は記載がありません。
向いている人： すでにAPIをKong経由で管理していて、MCPも同じポリシーで統制したい組織。
ほかに、MicrosoftのOSSのMCP Gateway（Kubernetes上でEntra ID認証とアプリロールによる認可）も検討しましたが、現時点では用途が限られます。Glamaのゲートウェイは料金とゲートウェイのページを読み切れなかったため、ホスティングの比較記事で扱っています。
用途別のおすすめ
| こうしたいなら | おすすめ | 理由 |
|---|---|---|
| 多数のリモートサーバーを一番手軽にまとめたい | Cloudflare MCP Server Portals | 1ポータル最大80サーバー、Access経由のSSO |
| 社員ごとのツール権限と監査ログが必要 | Obot | ユーザー・グループとツールを結ぶポリシーと、関連づけた監査ログ |
| OSSでポリシー・アズ・コードを書きたい | agentgatewayまたはContextForge | CELのルール、またはRBACとOPA/Cedarのプラグイン |
| ホスティングとゲートウェイ機能を一度に | NodeFlare | GitHubのリポジトリから、スコープつきの/mcp URLまで一気に |
| ツール一覧のトークンを減らしたい | Cloudflare PortalsまたはNodeFlare | ツール検索とコードモードを内蔵（コード実行でトークンを減らす記事も参照） |
| 多数のSaaSへのOAuthを任せたい | Composio | 1,000以上のアプリ、月10万ツール呼び出しの無料枠 |
| ノートPCで安全にサーバーを動かしたい | Docker MCP Gateway | サーバーごとのコンテナ、ネットワークとシークレットの遮断 |
| 既存の企業向けAPI統制にMCPを載せたい | Kong | OAuth 2.1のリソースサーバーとツール単位のACL |
どれを選ぶ場合も、本番に出す前に「何を記録するか」を決めておきましょう。必要なログ項目とアラートはMCPの監査ログの記事にまとめています。
NodeFlareならこう解決できる
ゲートウェイを探す人がよく困っているのは、認証なしで公開されたサーバー、呼ばせたくないツールまで呼べてしまうエージェント、コンテキストを食うツール一覧、信頼できないサーバーのコード、そして別のプロキシを運用する手間です。サーバーがGitHubにあるなら、NodeFlareはこれらをホスティングの段階で解決できます（公式ドキュメントに記載のある機能のみ）。
| 困っていること | NodeFlareの機能 |
|---|---|
| MCPサーバーに認証がない | mcp_*のBearer APIキー（ハッシュ化して保存）、RFC 8414 / RFC 9728に沿ったOAuth検出。誤ったキーが続いたIPは10分間ブロック |
| 呼ばせたくないツールまで呼べてしまう | tools:call:get_weatherやprompts:get:<name>のように、メソッドと対象までスコープを毎リクエストで検査 |
| 社内からだけ接続させたい | CIDRで指定するrestrictedの送信元IP許可リストを認証の前に適用。空なら全拒否 |
| ツール一覧がコンテキストを食う | tool_list_filter_by_scope、tool_schema_slim（500文字を超える説明を切り詰め）、tool_search_mode、tool_code_mode（サンドボックスで実行、1回の実行で呼べるツールは初期値で50回まで） |
| stdioサーバーをゲートウェイの後ろに置けない | 内蔵のstdioアダプターがStreamable HTTPと旧HTTP+SSEで公開 |
| サーバーのコードを信頼しきれない | サーバーごとに専用のFirecracker microVM。外向き通信はobserveかenforceで制御（最大100件） |
| エージェントが何を呼んだか分からない | mcp_method、tool_name、arg_keys（値は記録しない）、scope_deniedなどの結果、所要時間をリクエストごとに記録 |
| 想定外の請求が怖い | 任意で月の支出上限を設定でき、上限に達するとHTTP 402を返して停止 |
最小の始め方：GitHubでサインインし、リポジトリのURLを貼るだけでランタイムとビルド設定は自動で入力されます。環境変数を入れてデプロイしたら、エージェントに必要なスコープだけを持つAPIキーを作り、/mcpのURLをClaude・Cursor・自作エージェントに貼り付けます。stdioサーバーを別の環境で動かす方法はstdioのMCPサーバーをリモートで動かす手順で解説しています。
1サーバーまで無料で試せます → nodeflare.tech
よくある質問
MCPゲートウェイとは？
MCPゲートウェイとは、MCPクライアントとMCPサーバーの間に立ち、認証、ツール単位の認可、上流の認証情報、ログをまとめて扱うプロキシです。複数のサーバーを1つのエンドポイントにまとめる製品も多くあります。サーバーごとに作り込まず、エージェントのツール利用を1か所で統制できます。
2026年のおすすめMCPゲートウェイは？
公開した基準では、ユーザー単位のツールポリシー、上流OAuthの代行、監査ログがそろったObotが最高点（87点）です。リモートサーバー向けのマネージド型ならCloudflare MCP Server Portals（85点）が有力です。セルフホストのOSSではagentgatewayとIBM ContextForge（各81点）が上位です。
MCPゲートウェイとMCPホスティングの違いは？
MCPホスティングはサーバーのプロセスを動かしてURLを発行するもので、MCPゲートウェイはすでにどこかで動いているサーバーへのアクセスを制御するものです。両方を兼ねる製品もあり、NodeFlareはゲートウェイ機能つきのホスティング、ObotとDockerはサーバーの実行と中継の両方ができます。
無料で使えるOSSのMCPゲートウェイは？
あります。agentgatewayとIBM ContextForgeはApache-2.0、ObotとDocker MCP GatewayはMITライセンスです。かかるのは動かすインフラの費用だけです。
ツール単位で権限を分けられるMCPゲートウェイは？
Obot、agentgateway（CELルール）、IBM ContextForge（RBACとOPA/Cedar）、NodeFlare（tools:call:<name>のスコープ）、Kong（3.13以降のツールACL）がツール単位のルールを強制できます。Cloudflare PortalsとComposioはツールのオフや許可リスト、Dockerは--toolsの許可リストに対応しています。
MCPゲートウェイでトークン使用量は減らせる？
モデルに見せるツールを変える機能があれば減らせます。Cloudflareのminimize_tools（公式は最大5倍と記載）、Composioのメタツール、DockerのDynamic MCP、NodeFlareのツール検索とコードモードは、ツール一覧全体を少数の検索用ツールに置き換えます。呼べないツールを一覧から外すだけでも効果があります。
stdioのMCPサーバーをゲートウェイの後ろに置ける？
stdioプロセスを動かせるゲートウェイなら置けます。Obot、agentgateway、ContextForge（mcpgateway.translate経由）、Docker、NodeFlareが対応しています。Cloudflare PortalsとKongはリモートのHTTPサーバーだけが対象なので、先にstdioサーバーをどこかでホスティングする必要があります。
MCPゲートウェイにOAuthは必要？
Claudeのカスタムコネクタのように、MCPの認可フローを前提とするクライアントから接続させるならOAuthが必要です。自作エージェントやCursorだけなら、Bearer APIキーで足りることが多いです。Cloudflare、agentgateway、Kong、NodeFlareはOAuthのメタデータを公開するか、OAuthのリソースサーバーとして動作します。
Cloudflare MCP Server Portalsは別料金？
ポータル単体の料金は公開されておらず、Cloudflare Zero Trustの機能の一部です。Zero TrustのFreeプランは50ユーザーまで$0、Pay-as-you-goは1ユーザー月$7です。ポータルのログをLogpushで出力するにはEnterpriseプランが必要です。
MCPゲートウェイでは何をログに残すべき？
最低限、利用者、MCPメソッド、ツール名、結果（許可・拒否・レート制限）、所要時間、セッションIDを残します。引数の値まで残すかは意図して決めましょう。全文を残すと事後調査には役立ちますが、シークレットや個人情報まで記録してしまうおそれがあります。
まとめ
どのMCPゲートウェイが最適かは、統制したいサーバーの数と、ゲートウェイを自分で運用したいかで決まります。総合力ではObot、リモートサーバーを手軽にまとめるならCloudflare MCP Server Portals、基盤チームがOSSで組むならagentgatewayとIBM ContextForgeが有力です。NodeFlareは外部サーバーを集約できないためゲートウェイとしては5位ですが、サーバーのホスティングも必要で、APIキー・ツール単位のスコープ・トークン削減を最初から前に置きたい場合は最も手軽な選択肢です。Composio、Docker、Kongはそれぞれ、SaaSへの認証、手元での隔離、既存のKong環境という特定の用途で強みがあります。ゲートウェイ以外の対策はMCPセキュリティのチェックリストを参照してください。
参考資料
- Obot MCP Gateway、Obotドキュメント：MCP Gateway
- Cloudflare：MCP Server Portals、Cloudflare Zero Trustの料金
- agentgateway（GitHub）、MCPの認証、MCPの認可
- IBM ContextForge（GitHub）、ContextForgeのプラグイン
- NodeFlareドキュメント、料金
- Composio Tool Routerの概要、Composioの料金
- Docker MCP GatewayのCLIリファレンス、Dynamic MCP
- Kong AI MCP Proxyプラグイン、AI MCP OAuth2プラグイン、Kongの料金
- MCP仕様
