本エントリはModel Context Protocol (MCP) Advent Calendar 2025の12/11の投稿です。
はじめに
AIエージェントに対する期待の高まりとあわせて、エージェントからAPI（Tools）にアクセスする必要性が急激に高まりました。その必要性から、Function CallingやTool Useといったプロバイダ毎の独自仕様が現れ始め、AIエージェント開発におけるLLM利用の互換性が急速に失われ始めました。そんな中、Anthropicが標準仕様としてModel Context Protocolを提案し、瞬く間に業界標準として受け入れられ本日に至っています。
MCP自体は、エージェントからAPIへのアクセスをクライアント/サーバーという通信経路に再定義することにより抽象化しています。これにより、エージェントが採用するLLMやプロバイダーに関わらず、API提供側としては同じ方式でAPIをエージェントに公開する事が可能となり、Toolの定義も各エージェントの中ではなくサーバー側に吸収されます。一方、REST APIではない新たなプロトコルに対するエンドポイントを提供する必要性が生まれました。
このMCPサーバーの構築にあたり、Kong Gatewayでは新たにAI MCP Proxyと呼ばれるプラグインを3.12より提供しています。本エントリでは、このAI MCP Proxyプラグインのメリットや利用方法についてご紹介します。
Model Context Protocol
REST APIは原則データアクセスに対する標準的なアプローチです。アクセス対象となるリソースをパターン化したURIで定義し、HTTPメソッドを利用してそのアクションを定義します。ステートレスなアクセスを前提としており、(Hateoasの様な例外はありますが) 基本的にAPIの利用者はその定義や利用方法について知っている必要があります。
一方MCPでは、エージェントにはMCPサーバーに繋げる際利用するAPIの仕様を把握しておらず、この為サーバー側ではどのようなAPIを提供しており、どの様に利用するかの情報を問い合わせる必要があります。これはAIエージェントの本質的な特性によるもので、コンテキストによって何のAPIをどう利用するかの判断をLLMが行う為です。個別のAPIをエージェント内に埋め込むのではなく、エージェントから切り離す事によってエージェントとAPIの関係を疎結合化する効果もあります。
MCPサーバーとのやり取りは：
- initialize - MCPサーバーに接続する
- tools/list - MCPサーバーから利用可能なAPIとその利用方法を取得する
- tools/call - APIを実行する
という流れで行われます。MCPは、通信におけるこれら決まり事を定義したプロトコル仕様となっています。
MCPサーバー
MCPサーバーの役割は、接続先のAPIになり代わりこれらMCPにおける仕様に適合した通信を担う事です。initializeにおける認可、tools/listリクエストに対してAPIの仕様を提供、そしてAPIコールに対する中継等が主な役割です。これら処理はAPI自体が提供する機能とは直接的に関係の無い、MCP通信する上で必要な非機能要件の集合体になるサーバーとなります。
MCPサーバーの構築には、一般的には言語毎に提供されいてるSDKを利用され、中でもPythonであればFastMCP v2等を利用してさらに実装コードを簡略化するアプローチも見受けられます。これはMCPサーバーが非機能要件の集合体という特性から考えると自然なアプローチであり、実際にかなり少ない工数でMCPサーバーを立てる事も可能となります。
MCPサーバーを建てるということ
一方、AIエージェントに利用させたいAPIに対して1つ1つMCPサーバーを開発していくアプローチにはいくつかの課題があります。
- 容易に開発出来るといっても、開発が発生し、当然運用も発生する。それぞれのMCP毎のリポジトリ、パイプライン、実行環境の確保やテスト等を含めると無視出来ない量の工数がかかる事になる。特に数が多くなる傾向のMCPサーバーにおいては相応の開発/運用負荷となる。
- MCPの仕様変更が発生した際の改修対象が飛躍的に増えている。例えば2025年5月にようやく公開された認可仕様の様に、汎用的かつ実践的な利用に対しては明らかに未熟なものもあり、これらの変更が入る度にMCPサーバーにも手を入れる必要性が出てくる。
現在はAIエージェントにツール提供するニーズの高まりから、MCPサーバーの早期構築に焦点が置かれていますが、MCPサーバーの構築が進むにつれてこれら課題が浮き彫りになってきます。「MCPサーバを建てない」という選択肢について、Kongなりの一つの解釈としてAI MCP Proxyプラグインを提供しています。
Kong AI MCP Proxyとは
Kong AI MCP Proxyプラグイン (以下「MCP Proxy」)は、Kong Gateway 3.12で新たに追加されたエンタープライズプラグインです。クライアントからのMCP通信に対するKongゲートウェイ側の拡張機能であり、他のプラグイン同様の方法で利用する事ができます。AIという名前が付いているのでAI Gatewayというグループには属しますが、他のAI Gatewayプラグインと異なりLLMとの接続に利用するものではありません。
MCP Proxyは文字通りAPIのプロキシとしての役割を担いますが、接続するAPIは既存のMCPサーバー (Passthrough) だけでなく、一般的なREST API(Conversion) とも接続する事が出来ます。
Passthrough - 既存のMCPに対するリバースプロキシ。REST APIに対するKong Gatewayの様に、MCPサーバーに対するプロキシです。横断的なメトリクス/ログ集約、その他既存のプラグインを利用してMCPサーバーの処理を部分的に吸収出来ます。
Conversion - REST APIをMCPでアクセスする上でのプロトコル変換を実施。API毎に個々のMCPサーバーを構築するのではなく、プラグインの追加によりAPIをMCP化する事が出来ます。
これら双方のユースケースをサポートする事により、組織中のMCPに対した横断的なプロキシ群（MCP Gateway）として機能するよう設計されています。利用するAIエージェントからは、アクセス出来るMCPサーバーはゲートウェイに集約/抽象化されます。組織観点では、様々なAIエージェントからのAPIを通信を横断的に管理でき、より迅速に多くのMCPサーバーをAIエージェントに対して提供出来る様になります。
MCP Proxyにおけるモード
MCP Proxyは前述の通りプラグインとしての提供であり、一つのリバースプロキシとしてではなくプラグインを複数組み合わせて利用します。個々のMCP Proxyには用途に応じてモードを指定します。MCP Proxyのモードには、大きく分けてListener（MCPエンドポイントの提供）とConversion（MCP/RESTプロトコル変換）の種類があります。
passthrough-listener - 既存のMCPサーバーに対するパススルーのプロキシ。MCP Proxy自体でプロトコル変換等の処理は行いませんが、統一したログ/メトリクスの取得や複数MCPサーバーに対する横断的なポリシー適用の対象として機能します。
conversion-listener - MCP Autogenerationとも呼ばれる、REST APIへのプロトコル変換を行うプロキシ。MCPサーバーとしてJSON RPCリクエストを受け付け、REST API形式に返還したのちAPIコールを行います。
listener - MCPサーバーとしてのエンドポイント。JSON RPCリクエストを受け付けるMCPのエンドポイントを提供します。複数のconversion-onlyモードのMCP Proxyと紐付ける事により、REST API側の構成を抽象化した単一のMCPサーバーを構築できます。
conversion-only - MCP/RESTのプロトコル変換を実施。接続先のREST APIとは1対1の関係にあり、それぞれのAPIに対してMCPプロトコルとの変換ルールを指定する。listenerモードのMCP Proxyと紐付ける事が前提です。
おわりに
今回は、Kong AI MCP ProxyプラグインによるMCPサーバーを建てないというアプローチについてご紹介しました。このプラグインで全てのMCPサーバーニーズに対応出来る訳ではありませんが、将来的な仕様変更に対してプラグインの更新で対応出来るというメリットは大きいのではないかと考えています。管理対象がyamlの一部のプラグイン定義だけになりますし、数が増えてきた際の運用負荷も大きく軽減できます。
次回からは、実際にMCP Proxyを使ったサンプルをご紹介しながら、その仕組みを紐解いていきたいと思います。