MCPゲートウェイはいつ必要？Cloudflare・Docker・Lassoの費用と選び方

MCPゲートウェイの導入を考えるタイミングは、複数のエージェントクライアントに共通のアクセスルールが必要になったときです。6人の開発者が4種類のクライアントから8台のMCPサーバーを使うと、クライアントとサーバーの接続設定は192件に達することがあります。導入で得たいのは、アクセス制御とツール呼び出しの調査を集約できる場所です。同時に、その運用費用に責任を持つ担当者も決める必要があります。

MCPゲートウェイで何を管理できるのか

MCPゲートウェイは、エージェントとMCPサーバーの間で、認証、ツールの許可リスト、ログ、レート制限を管理する窓口です。 Model Context Protocol（MCP）は、AIアプリケーションがツールを見つけ、実行を依頼するための共通インターフェースです。ゲートウェイを使うと、それぞれの接続をまとめて管理できます。ただし、利用できる制御機能は実装によって異なります。KongによるMCPゲートウェイの解説では、プロキシとしての役割とポリシーを適用する役割が説明されています。

たとえば、業務アシスタントが顧客情報を検索し、その後でサポートチケットを更新する場面を考えてみます。これらの操作を提供するのはMCPサーバーです。ゲートウェイが管理すべきなのは、誰が呼び出しているか、その利用者にどの操作を許可するか、実行時に何が起きたかです。

Claude、ChatGPT、Codex、Cursorを使う開発者にとっての利点は、組織が認めたクライアント間でツールへのアクセスを統一できることです。ただし、各クライアントのプラン、対応する認証方式、接続方法は個別に確認する必要があります。

それぞれの制御機能には、次の役割があります。

• 認証： リクエストを送った人物やワークロードを特定します。そのうえで認可によって、その主体に何を許すかを決めます。APIキーを全員で共有すると、個人ごとの責任を追えなくなることがあります。
• ツールの許可リスト： 必要な操作だけを意図的に公開し、実行を許可します。サポートアシスタントに顧客検索を許しても、削除ツールは許可しない、といった設定です。ツール一覧の取得時だけでなく、呼び出し時にもルールを適用します。
• ログ： 操作を調査できるように、実行主体、サーバー、ツール、ポリシーによる判定、実行結果を記録します。どの引数を記録してよいか、機密性の高い値をどう扱うかも決めます。
• レート制限： 保護したい主体、ツール、上流サービスに応じて呼び出し数を制限します。同じ処理を繰り返すエージェントがバックエンドを圧迫する前に、設定した制限で止められるようにします。

これらは導入時に確認すべき要件です。ゲートウェイという名称だけで、すべての機能が保証されるわけではありません。ローカルのツールを集約する仕組みが役立っても、組織のID管理やレート制限は別途実装する必要がある場合があります。

MCPゲートウェイとMCPサーバーはどう違うのか

MCPサーバーは機能を提供し、MCPゲートウェイはサーバーへのアクセスを管理します。 サーバーが提供するのは、たとえばデータベースへのクエリやチケットの作成です。ゲートウェイは許可済みの機能をクライアントに提示し、呼び出しを適切なサーバーへ送り、設定された制御を適用します。

MCPのアーキテクチャでは、クライアントはtools/listでツールを取得し、tools/callで呼び出します。ゲートウェイは、エージェントに対してはサーバーとして、上流サーバーに対してはクライアントとして振る舞えます。ただし、呼び出した主体がどのレコードを閲覧・変更できるかは、引き続き元のアプリケーションが判断します。

たとえば、チケット更新ツールを許可したからといって、すべての顧客アカウントにアクセスできることにはなりません。レコード単位の権限やテナント間の分離は、アプリケーションとそのサーバー連携側で担保する必要があります。

AIゲートウェイ・LLMゲートウェイとの違い

AIゲートウェイやLLM（大規模言語モデル）ゲートウェイが制御するのは、モデルへのリクエストです。 MCPゲートウェイはツールへのリクエストを制御します。この違いによって、それぞれが解決できる課題が決まります。

Cloudflare AI Gatewayのドキュメントには、モデルへのリクエストのログ、キャッシュ、レート制限、リトライ、フォールバックが記載されています。これらは推論コストやプロバイダーの信頼性を管理する機能です。一方、MCPゲートウェイのツールポリシーでは、顧客システムで承認済みの操作をエージェントに実行させてよいかを判断できます。

両方の経路を扱う製品もありますが、それぞれを個別に評価する必要があります。モデルの予算設定があってもツールの権限が適切とは限らず、ツールの許可リストがあってもすべてのモデルリクエストに上限が設けられるわけではありません。予算を投じて解決したい課題がモデルのルーティング、推論費用、プロバイダーの障害であれば、コーディングエージェント向けAIゲートウェイの比較を参照してください。

通常のAPIゲートウェイでも、HTTPリクエストの認証や流量制御はできます。MCPに対応した管理では、リクエストの中身であるツールの検出、ツール名、呼び出し引数まで扱います。複数の操作が同じ/mcp URLを使うこともあるため、そのURLへのアクセスを許可するだけでは、意図したツールポリシーよりも広い操作を認めてしまう可能性があります。

2026年9月24日、何が変わったのか

Cloudflareは、2026年9月24日にMCP Server PortalsをすべてのCloudflare顧客向けに一般提供しました。 公式発表では、承認済みサーバーをまとめる単一のエンドポイントと、ツール、プロンプト、リソースの利用を記録するAccessログが紹介されています。

発表には、自律型エージェント向けのサービストークン認証、より詳細なHTTPログとデータ損失防止に使うGateway経由のルーティング、利用履歴をエクスポートするLogpushへの対応も含まれます。データ損失防止（DLP）は、機密情報に関するルールに照らしてコンテンツを検査する仕組みです。

この変更で得られる実務上の利点は、ゲートウェイのプロセスを自分たちで運用せずに、リモートMCPへのアクセスを一元管理できることです。ただし、提供開始後も判断すべきことはふたつ残ります。利用中のサーバーとクライアントが対応しているか、必要な監査機能がプランに含まれているかです。

MCPゲートウェイという設計パターンは、以前から存在していました。今回変わったのはマネージドサービスの選択肢の提供範囲であり、すべてのMCP接続にゲートウェイが必須になったわけではありません。

小規模チームがMCPゲートウェイを導入すべきタイミング

クライアント、従業員、サーバーの担当者が変わっても、アクセス方針を維持する必要があるなら、ゲートウェイの出番です。 少数のサーバーだけでは済まなくなったことも目安になりますが、より強い導入のきっかけはポリシーが分散していることです。

同じ開発者が複数のクライアントを使い、どれでも同じ制限付きツールを利用する必要があるなら、導入を検討します。運用担当者がアクセスを取り消したり、操作の経緯を追ったり、機密情報や書き込みを扱うツールに共通のポリシーを適用したりする必要がある場合も同様です。重要な書き込み操作を含む小さな環境のほうが、公開ドキュメント用ツールを大量に使う環境よりも、早く対応が必要になることがあります。

例として、6人の開発者が4種類のエージェントクライアントと8台のMCPサーバーを使う環境を考えます。全員が、すべてのクライアントにすべてのサーバーを設定する想定です。

• 直接接続の場合：6 × 4 × 8 = 192件のクライアント・サーバー間の接続設定。
• 共通ゲートウェイを使う場合：6 × 4 = 24件のクライアント・ゲートウェイ間の接続設定と、8件の上流エンドポイント定義。
• エンドポイント参照の合計：32件。

これは接続設定数を説明するための計算例です。実際の導入事例や性能測定の結果ではありません。すでに設定を一元配布している場合もあれば、役割によってゲートウェイやプロファイルを分ける必要がある場合もあります。また、各ユーザーが上流サービスに与えるOAuthの許可は、エンドポイントの定義とは別に必要です。

利点は、承認済みサーバーのアドレスやツールポリシーを変更する作業を、一元化できることです。一方で、その変更を誤れば影響も集中します。ポリシーをバージョン管理し、変更できる担当者を決めてください。

導入を見送ってよいのは、 担当者が既存のID管理と共通設定を使って、少数の低リスクなツールをすでに管理できている場合です。ゲートウェイを追加すると、運用するサービス、依存関係、障害の発生経路が増えます。解決したい運用課題を具体的に示せることが前提です。

エージェントがMCPツールを使っていなければ、影響はありません。 管理したいのがモデルへのリクエストだけなら、まずLLM側のゲートウェイを検討します。アプリケーション側ですでに必要なツールポリシーと監査経路を確保できているなら、その管理範囲を改善できる場合に限って追加します。

開発・運用・調達で確認すべきこと

開発担当者：まず通信方式を確認する

自分たちが運用するサーバーに接続できるゲートウェイを選びます。stdioは、ローカルプロセスの入出力ストリームを使ってクライアントと通信する方式です。Streamable HTTPは、リモートのエンドポイントへMCPの通信を送る方式です。プロトコルのアーキテクチャで両方が説明されています。

マネージドのリモートゲートウェイが、手元のノートPCでstdioプロセスを自動起動できるわけではありません。そのプロセスをホストされたHTTPサービスに変えるには、デプロイと認証情報の管理が必要になります。クライアントの設定を置き換える前に、通信方式の互換性を確認してください。

運用担当者：実際の呼び出し経路を管理する

共通ポリシーが効くのは、対象の呼び出しがそこを通る場合だけです。ゲートウェイ経由の接続とあわせて、直接接続に使う認証情報やエンドポイントも棚卸しします。承認済みクライアントがツールに到達する経路、インシデントの記録先、ゲートウェイ障害時の復旧責任者を定めてください。

サポートのワークフローで必要なのは、誰がどの操作でチケットを変更したかを示す記録です。接続成功のログだけでは、それを確認できません。ログ機能ならどれも同じ証拠を残すと考えず、選んだ製品が実際に出力する記録を確認します。

調達担当者：必要な管理範囲に予算を付ける

ゲートウェイ、上流サーバー、その両方を担当する人まで含めて予算を組みます。Freeプランがユーザー数の条件を満たしても、ログの保存期間が要件を満たすとは限りません。オープンソースがデプロイの要件に合っても、ID管理との追加連携が必要になる場合があります。

未承認サーバーの検出、実行時の詳細な検査、企業向けのインシデント対応まで必要なら、企業向けエージェントのMCPセキュリティプラットフォーム比較で、より広い範囲の選択肢を扱っています。

MCPゲートウェイの3つの選択肢：2026年10月4日確認

Cloudflareはリモートアクセスのマネージド管理、Dockerはコンテナによるサーバー運用、Lassoはプラグインによるオーケストレーションに適しています。 選択を左右するのは、通信方式、アクセス制御、ログ、そして誰がサービスを運用するかです。

以下の価格とライセンスは、2026年10月4日に各提供元の公開ページとリポジトリで確認しました。後半の費用例は、明記した前提に基づく試算です。

出典：Cloudflareのプラン、Dockerのライセンス、Lassoのライセンス。

Cloudflare MCP Server Portals

Cloudflare MCP Server Portalsは、承認済みのリモートMCPサーバーをマネージドで管理する選択肢です。 Cloudflare Oneが自社のID管理と運用要件に合うことが前提になります。複数のサーバーを単一のHTTPエンドポイントにまとめ、認証にはCloudflare Accessを使います。管理者は、ポータルで公開するツールとプロンプトを選べます。

現行のプラン表には、Freeは$0で50ユーザーまで、Pay-as-you-goは$7/ユーザー/月、Contractはユーザーごとの年間料金を個別見積もりと記載されています。標準のログ保存期間は、Freeで最大24時間、Pay-as-you-goで最大30日です。保存期間は、利用するサービスによって異なります。

制約になるのは、互換性と監査機能の利用条件です。Cloudflareのポータルのドキュメントでは、リモートHTTPのMCPサーバーに対応し、ポータルあたり最大80サーバーを扱えるとされています。stdioのみのサーバーは、まず認証付きのHTTPエンドポイントとしてホストする必要があります。上流サーバーによっては、プロキシ経由のクライアントを受け付けない場合もあります。

ポータル内のログと、外部へのログエクスポートも分けて考える必要があります。CloudflareのLogpush連携はEnterprise限定です。監査担当者に外部アーカイブを約束する前に、この利用条件を確認してください。

対応するリモートツールを使い、ゲートウェイの計算資源を自分たちで管理せずに共通のアクセス制御を設けたい場合に適しています。ユーザー数、ホスティング、監査それぞれの費用は、Cloudflare MCP Portalsは無料で使えるのかで確認できます。

Docker MCP Gateway

Docker MCP Gatewayは、MCPサーバー自体の運用も課題になっている場合に適したオープンソースの選択肢です。 分離されたコンテナでサーバーを起動し、そのライフサイクル、認証情報、ルーティングを管理します。利用できるサーバーはプロファイルにまとめます。プロファイルは、クライアントに提供するサーバーの組み合わせを保存したものです。

単体のゲートウェイのコードはMITライセンスです。Dockerのドキュメントには、Docker Engineを使う手動インストールと、Docker Desktopを使う方法の両方が記載されています。ホスト、更新、認証情報、デプロイ設計は、引き続き自分たちで管理します。

Docker Desktopの商用利用には、別の条件があります。Dockerのライセンスのページによると、中小企業がDesktopを商用で無料利用するには、従業員が250人未満、かつ年間売上が$10 million未満である必要があります。より規模の大きい組織と政府機関には、有料サブスクリプションが必要です。Docker Proは、月払いで$11/ユーザー/月、年払いプランで$9/ユーザー/月です。これはDesktopのサブスクリプション料金であり、ゲートウェイのコードに対する料金ではありません。

提供形態にも別の区分があります。Dockerの現行ゲートウェイのドキュメントでは、Docker AI Governanceの一部として提供されるMCP Gatewayは招待制とされ、営業窓口を通じて提供されます。公開されているMITライセンスのリポジトリは、単体のコードとして使う選択肢です。商用のガバナンス製品を、リポジトリのライセンス料金で利用できるものとして予算化しないでください。

コンテナの分離とサーバー運用が重要で、その実行環境を担当する人がいるならDockerが適しています。各ノートPCで動くゲートウェイはローカルツールを集約できますが、組織共通のポリシーやリモートクライアントからのアクセスには、目的に応じたデプロイ設計が必要です。

Lasso MCP Gateway

Lasso MCP Gatewayは、プラグインでMCPのリクエストとレスポンスを処理する中継層です。 サーバー設定を読み込み、設定済みサーバーを管理し、その機能を統一されたインターフェースで公開します。リポジトリには、CursorとClaude Desktop向けの例が含まれています。

ゲートウェイのコードはMITライセンスです。basicプラグインはトークンとシークレットをマスキングします。任意のpresidioプラグインは個人情報をマスキングし、xetrackはSQLiteにイベントを保存するトレーシングを追加します。このプラグインには別途インストール要件があります。

特に確認すべきなのは、プラグインがどのサービスを使って動くかです。lassoプラグインにはLasso APIキーが必要で、検査のためにコンテンツをLassoのAPIへ送ります。ゲートウェイがMITライセンスでも、このホスト型APIの料金や利用条件まで決まるわけではありません。READMEには料金が記載されていません。予算を組む際も、コンテンツの送信先を判断する際も、別の外部サービスへの依存として扱ってください。

リクエストとレスポンスの処理を拡張する必要があり、周辺の運用も自分たちで担えるならLassoが適しています。READMEの記載だけでは、共通のID管理、ユーザー別のツール権限、レート制限をすぐに使えるサービスが揃っているとは判断できません。それらが導入目的なら、必要な制御として明示的に求めてください。

MCPゲートウェイの運用にかかる費用

ソフトウェアのライセンスは、予算の一項目にすぎません。 ゲートウェイのソフトウェアやサブスクリプションの料金、計算資源とログ、運用担当者の作業時間、ワークフローで使うモデルと上流アプリケーションを分けて見積もります。

マネージドサービスでは、IDごとのシート料金や従量料金に加え、必要なエクスポート機能やセキュリティの追加機能を含めます。セルフホストでは、ゲートウェイとサーバーの計算資源、ログ保存、更新、認証情報の管理、復旧作業を含めます。無料のゲートウェイの先で、有料のSaaSアカウントと有料モデルを使う場合もあります。

小規模チームの予算例を見てみます。間接費を含む社内の人件費単価を**$100/時間と仮定します。また、セルフホストで追加する計算資源とログの費用を$20/月**とします。いずれも予算計算のために置いた数値であり、ベンダーの見積もりや実測したホスティング要件ではありません。

この前提では、セルフホストは直接接続の設定をサポートする場合と比べて**$180/月を節約できます。ただし、ゲートウェイのコードのライセンス料金が$0でも、費用は$220/月です。導入作業に延べ8時間かかるなら、$800を加えます。初年度の試算は12 × $220 + $800 = $3,440となり、想定した直接接続のサポート費用$4,800**と比較できます。

節約できるかどうかは、ゲートウェイが想定どおりにサポートの負担を減らすかに全面的に依存します。現在の作業時間を測り、自社の数値に置き換えてください。単純な共通設定で直接接続を維持できているなら、費用はもっと低い可能性があります。

ベンダーの料金を自社の環境に当てはめる

Cloudflareを利用するユーザーが6人なら、50ユーザーまでのFreeプランでCloudflareのプラン料金は$0にできる場合があります。表の「互換性のあるマネージドゲートウェイ」の想定では、それでも社内でポリシーを管理する人件費が$50/月かかります。上流サーバーのホスティング、モデル利用料、サブスクリプション、追加機能は、この金額に含まれません。

Pay-as-you-goのシートを60席購入する場合、公開料金の$7を使うと、60 × $7 = $420/月、年間では**$5,040/年**です。これは購入する60席すべての予算です。Freeの50ユーザー上限は別プランの条件であり、この計算で50席分を差し引くものではありません。Cloudflareのシート管理のドキュメントでは、利用できるシート数は購入ユーザー数に応じ、アクセスするアプリケーションの数にかかわらず、同じIDは単一のシートを占有すると説明されています。

選んだDesktopの利用方法で必要になり、Docker Proの月払いサブスクリプションを6人分、新たに契約する場合は、Dockerの公式料金で6 × $11 = $66/月となります。利用条件を満たす契約がすでにあれば、追加のサブスクリプション費用は$0の場合もあります。Docker Engineを使う構成では、別途インフラの予算を組みます。

Lassoでは、MITライセンスのゲートウェイのコードを起点に、ホストとログの予算を加えます。APIに依存するプラグインを有効にするなら、ホスト型サービスの利用条件を別途確認してください。料金が分からない依存サービスを、$0として予算に入れることはできません。

直接接続・セルフホスト・マネージドをどう選ぶか

既存の制御でワークフローの要件を満たせる間は、直接接続を維持します。 ツールが少数で管理されており、責任者が明確で、アクセスの取り消しと監査の手順が機能しているなら適切な選択です。クライアント、役割、機密性の高い操作が増えてポリシーに違いが生じたら、判断を見直します。

実行環境の責任者を決められるなら、オープンソースのセルフホストを選びます。 コンテナ化したMCPサーバーなら、Dockerから検討するのが分かりやすいでしょう。プラグインによる処理の介入が必要なら、Lassoがより参考になる選択肢です。ID管理との連携、ホスティング、ログは個別に予算化し、必要な制御が働くことを確認します。

対応するリモートツールに共通ポリシーが必要で、ゲートウェイ運用を自分たちで担いたくないなら、マネージドを選びます。 小規模なCloudflare One環境では、Cloudflareが最初に評価する実用的な選択肢になります。広く展開する前に、通信方式、上流サービスでの認可、ツールポリシー、必要な監査プランを確認してください。

要件が変われば、選択も変わります。マネージドではサーバーに接続できない、または必要な制御を提供できないなら、セルフホストの担当者を決めるか、管理された直接接続を維持します。製品の機能数が多くても、必要な管理範囲との不一致は解消できません。

MCPゲートウェイを過大評価しやすいポイント

URLをまとめるだけで、信頼できる権限管理が完成するわけではありません。 最も大きな誤解は、ゲートウェイにつなげば、認可、監査、セキュリティがまとめて整うと考えることです。

ポータルにログインした後も、上流サービスでOAuthによる認可が必要な場合があります。ゲートウェイのポリシーと、上流アプリケーションのレコード権限の両方が重要です。MCPのセキュリティガイダンスでは、別のリソース向けに発行されたトークンを受け入れ、そのまま転送することについて明確に警告しています。

同様に、ツールの許可は、その利用を制御するための一部にすぎません。サーバー連携側で防げなければ、許可された操作に危険な引数が渡ったり、別のテナントに影響したりする可能性があります。レスポンスのマスキングは、アプリケーションの権限管理や、影響の大きい操作に対する人の承認を代替しません。

Cloudflareには、具体的なポリシーの例があります。ポータルのドキュメントによると、ポータルを通じてサーバーへのアクセスを認可する場合、独立したMFA、利用目的の説明、一時認証は適用されません。 一方で、グループやデバイスのセキュリティ状態といったセレクターは引き続き適用されます。MFAは追加の認証要素を使う仕組みです。ポータルを承認ワークフローとして扱う前に、このポリシーの制限を確認してください。

さらに、ゲートウェイを経由せずに送られたツールの通信は、ゲートウェイでは記録できません。承認済みの経路を定め、上流の権限を維持し、サーバーの保守も管理対象に含めます。製品は有用な制御の窓口を追加しますが、その管理がどこまで行き届くかは、担当者の運用によって決まります。

まず着手すること：ワークフローを試験導入する

ワークフローをひとつに絞って試し、導入目的の制御が働くことを確かめます。 そのワークフローから、リスクの低いツールと影響の大きいツールを選び、運用担当者が普段使うエージェントクライアントで検証してください。

1. 1

   現在の接続を整理する

   クライアント、サーバーのエンドポイント、通信方式、認証情報の管理者、公開ツール、ログの保存先を記録します。繰り返し発生するポリシー変更のうち、一元化したいものを特定してください。ロールバックできるよう、現在のクライアント設定を保存します。

2. 2

   運用する接続方式を選ぶ

   既存の制御で十分なら、直接接続を使います。セルフホストの試験導入は、実行環境の責任者がいる場合に選んでください。Cloudflareで試すなら、Zero Trust > Access controls > MCP Portalsに進み、対応するHTTPサーバーを追加し、サーバーとポータルのAccessポリシーを設定して、許可するツールとプロンプトを選びます。

3. 3

   ツールの検出と呼び出しを確認する

   選んだクライアントを、それぞれが対応する方法で接続します。低リスクの操作が表示され、実行できることを確認してください。禁止した操作は、明示的に要求しても拒否されることを検証します。ゲートウェイのツール一覧だけでなく、上流のデータ権限も確認します。

4. 4

   アクセスを取り消し、記録を追う

   試験用IDの権限を取り消し、次に操作を試みたときに失敗することを確認します。製品が出力する記録から、許可されたリクエストと拒否されたリクエストを探してください。ログの保存先と保存期間が要件を満たすことも確認します。

5. 5

   費用を見積もり、担当者を決める

   サブスクリプション料金、上流サーバーのホスティング、ログ、担当者の作業時間を記録します。ポリシーと復旧経路が機能してから、対象を広げてください。管理されない迂回経路を作らずに、以前の管理された設定へ戻す方法を文書化します。

よくある質問

MCPゲートウェイとは何ですか？

MCPゲートウェイは、AIクライアントとMCPサーバーの間に置く制御の窓口です。認証、ツールの許可リスト、ログ、レート制限、ルーティングを集約できます。ただし、ツールを集約する製品ならすべて対応していると考えず、各機能を具体的な実装で確認してください。

MCPゲートウェイとMCPサーバーの違いは何ですか？

MCPサーバーは、ツール、リソース、プロンプトを公開します。ゲートウェイはサーバーへのアクセスを管理し、許可済みの機能を共通のインターフェースで提示できます。元の処理を実行し、その処理を認可する役割は、引き続き上流サーバーとアプリケーションが担います。

MCPゲートウェイは導入する必要がありますか？

複数のクライアントや役割に共通のツールポリシー、アクセス取り消しの手順、監査経路が必要なら、導入を検討します。担当者がすでにそれらの要件を満たしているなら、直接接続も適切な選択です。特定のサーバー数に達したらゲートウェイを必須とする、というプロトコル上のルールはありません。

プロキシとMCPゲートウェイはどう違いますか？

基本的なプロキシは、通信を転送します。MCPに対応したゲートウェイは、ツールの検出と呼び出しを理解し、機能を集約し、ツールごとのポリシーを適用できます。MCPの複数の操作が同じHTTPエンドポイントを使うことがあるため、URL単位の権限だけでは、必要な操作制限を表現できない場合があります。

MCPはAPIゲートウェイのようなものですか？

MCPそのものはプロトコルです。MCPゲートウェイはAPIゲートウェイと似た役割を持ちますが、管理するのはMCPの機能と呼び出しです。同じ構成の中で、HTTP認証、ネットワーク制御、流量制御のためにAPIゲートウェイを使うこともできます。

MCPとHTTPは同じものですか？

異なります。MCPはメッセージと機能を定義し、HTTPはそのメッセージをリモートサーバーへ運ぶ方法です。MCPはローカルプロセス向けのstdioにも対応しています。この通信方式の違いにより、マネージドのHTTPゲートウェイから、ローカル専用のすべてのサーバーを直接利用できるわけではありません。

RESTではなくMCPを使う理由は何ですか？

MCPは、対応するAIクライアントに、ツールを見つけて呼び出すための共通の方法を提供します。サーバーで既存のREST APIをラップできるので、内部ではRESTを使い続けられます。実際のクライアントが必要とするインターフェースを選んでください。MCPを追加しても、すべてのアプリケーションAPIを書き直す必要はありません。

MCPはJSONを使っていますか？

はい。MCPは、リクエスト、レスポンス、通知にJSON-RPC 2.0のメッセージを使います。プロトコルは、ツールの検出や呼び出しを含め、メッセージの意味を定義しています。汎用的なJSONエンドポイントを設けるだけの仕組みではありません。

MCPとRAGはどう違いますか？

MCPは、ツールやデータを連携させるためのプロトコルです。RAG（検索拡張生成）は、モデルの回答に役立つ情報を検索する手法です。検索ツールをMCPで公開することもできるため、両者は組み合わせて使えます。ゲートウェイを追加するだけで、検索の品質が向上するわけではありません。

インフラ構成の実務的な判断や、確認日を明記した料金検証を読みたい方は、ニュースレターに登録してください。