MCPを企業で安全に使うには。KongでAIエージェントの通信経路をガバナンスする方法
2026年5月14日に開催された「Kong AI Connectivity Day in Fukuoka」に、Kong株式会社 スタッフ ソリューションエンジニアの白石庸祐が登壇。「エージェント時代を支えるMCPの仕組みと実装ノウハウ」と題し、テクニカルセッションを行いました。
本記事では、MCPサーバーを企業で利用するときに生じる運用、権限管理、可観測性の課題と、Kongによる実装の要点をレポートします。
目次
AI GatewayはAI利用を企業の管理対象に移すための接点
AIエージェントの権限を最小化する「Token Exchange」
AI活用にはLLM接続だけでなく通信経路全体の統制が必要
白石はまず、AI Connectivityの全体像として、AIエージェントからMCPサーバーを通してデータソースへアクセスする流れを示しました。ここでいうAI Connectivityとは、AIエージェント、LLM、MCPサーバー、API、イベント、データソースをつなぐ通信経路全体を指します。
その上で「通信経路には統制を効かせる必要があります」と説明しました。その理由は次の4点です。
- ガバナンス：ポリシーに基づいた通信の制御と管理
- セキュリティ：不正アクセスや脅威からの保護
- 情報漏えい防止：機密データの外部流出を遮断
- 可観測性：AI・MCPサーバー・API間の通信の可視化と追跡
統制を効かせるにはAIエージェントやMCPサーバーに個別の工夫を入れる方法もありますが、白石は「最もシンプルで実装しやすい方法は、KongのMCP Gatewayを入れることです」と述べました。
Kongでは、AI Gateway、MCP Gateway、API Gateway、Event Gatewayなどを通じて、AIエージェント、LLM、MCPサーバー、API、イベントの各データパスを横断的に扱います。白石は、Kong Konnectをコントロールプレーン、顧客環境に配置するゲートウェイをデータプレーンとするハイブリッド構成も紹介しました。
AI GatewayはAI利用を企業の管理対象に移すための接点
白石は、AI利用の最適化として、AI Gatewayの考え方を説明しました。ユーザーやAIエージェントと、ChatGPT、Claude、Gemini、Copilot、BedrockなどのLLMの間にゲートウェイを挟み、通信を集約します。この構成により、AIへのAPI通信を一元管理できます。
AI Gatewayで実現できることは、次の5項目です。
- トークン流量制限
- APIキーの一元管理
- キャッシュ
- 可観測性の確保
- 情報漏えい対策
Kongを通してLLMを利用することで、企業として全体の利用状況を把握し、必要なポリシーを適用できます。
AI活用が組織全体へ広がるほど、誰が、どのAIサービスに、どのようなリクエストを送っているかを把握する重要性も示されました。AI Gatewayは、AI利用を個人の操作から企業の管理対象へ移すための接点になります。
企業ではガバナンスしやすいリモートMCPサーバーを推奨
続いて白石は、MCPの基本を説明しました。MCPはModel Context Protocolの略で、AIモデルが外部データや機能を使うための共通規格です。AIエージェントが利用できるツールを探し、必要な処理を呼び出すための標準インターフェースと言えます。
白石は「AIエージェントにどんな選択肢があるのかを知りたい」ときに、MCPサーバーへ「tools/list」を送り、MCPサーバーがツールの一覧を返す流れを紹介しました。
AIエージェントは、その一覧から必要なツールを選び、「tools/call」というコマンドで実行します。APIであれば、その結果としてAPIコールが実行されます。
一方で、MCPサーバーを企業で使うと、課題が浮き彫りになります。顧客からよく聞く課題として挙げられたのは、次のような点です。
- MCPサーバーの運用負荷
- セキュリティと権限管理
- MCPサーバーやツール定義の管理
- ツール定義の増加によるトークン消費
- 不要な質問によるトークンの無駄遣い
これらの課題を解決する方法として白石が推奨したのは、Streamable HTTPを用いた「リモートMCPサーバー」です。MCPサーバーのセキュリティやガバナンスを考える上で、白石はローカルMCPサーバーとリモートMCPサーバーの違いを取り上げました。
ローカルMCPサーバー
- 個人PC上で動作し、Claude Codeなどの開発環境と組み合わせると素早く使える
- ログ取得やガバナンス適用が難しく、社内リソースへのアクセス管理には不向き
リモートMCPサーバー（Streamable HTTP）
- AIエージェントとMCPサーバーの経路上にKongを配置することで、すべての通信がKongを経由する
- ログやメトリクスをCloudWatch、Splunk、DatadogなどのObservability基盤へ送信できる
- ポリシーを適用できる
白石は、ガバナンスを効かせたい場合には、KongでMCPサーバーへの通信を管理する構成が望ましいと述べました。
MCPサーバー運用の簡素化はAPIのMCP化がカギ
MCPサーバー活用では、運用負荷も課題になります。MCPサーバー自体を作ることは難しくなくても、仕様変更やバージョン変更のたびに作り直す運用は負担になります。
白石は、この課題に対して2つのパターンを紹介しました。
1つ目は、Kong側で社内APIや社外APIをMCP互換のエンドポイントとして公開し、専用のMCPサーバーを立てずにAIエージェントから利用できるようにする方法です。
2つ目は、NotionやBoxなど、外部SaaSが提供するMCPサーバーをそのまま活用する方法です。
この整理から見えるのは、MCPサーバーを増やすこと自体が目的ではない点です。企業に必要なのは、既存APIや外部サービスをAIエージェントが安全に使える状態へ変換し、その利用状況を管理できる仕組みだと整理されました。
いずれのパターンでも、Kongを経由させることで同じ粒度でセキュリティ、可観測性、ポリシーを適用できます。白石は「MCPサーバーの運用負荷が大きく、次の段階へ進められないお客様に向けて、Kongで管理する構成が1つの選択肢になる」と説明しました。
AIエージェントの権限を最小化する「Token Exchange」
権限管理については、Token Exchangeの考え方が紹介されました。ユーザーのアクセストークンをそのままAIエージェントやMCPサーバーへ渡すと、エージェントがユーザーと同じ権限を持ち続ける可能性があります。
白石は、ユーザーがアクセスするときにユーザー用のアクセストークンをエージェント用のアクセストークンへ切り替え、さらにMCPサーバー用のアクセストークンへ切り替える流れを説明しました。これにより、各段階で必要な権限だけを持たせることができます。
「いわゆる“最小権限”を維持し続けることが、非常に重要なポイントです」と述べ、KongはこのToken Exchangeに対応していると説明しました。
MCPレジストリはAIエージェントの組織的利用を促進
白石は次に、KongでMCPサーバーやツールを管理・資産化する「MCPレジストリ」を紹介しました。MCPサーバーやツール定義が増えると、その存在を把握し、開発者やAIエージェントごとに利用可否を管理する必要があります。
MCPレジストリにMCPサーバーやツールを登録しておくことで、開発者は利用可能なMCPサーバーやツールを把握し、開発を進められます。また、MCPレジストリの内容をAIエージェントに参照させることで、AIエージェントが必要なMCPサーバーやツールを使えるようになります。白石は「Streamable HTTPにもSTDIOにも対応している」と説明しました。
MCPサーバーやツールを企業の再利用可能な資産として管理することで、AIエージェント活用を属人的な試行から組織的な利用へ移行しやすくなります。
MCPレジストリが担う役割は、次の3点に整理できます。
- 利用可能なMCPサーバーやツールを一覧化する
- 開発者やAIエージェントが使える範囲を管理する
- MCPサーバーやツールを再利用可能な社内資産として管理する
デモ：AI Connectivityの実装例
セッション後半では、ECサイトを模したデモ環境を使い、KongによるAI Connectivityの実装例が示されました。フロントエンドからAPI Gatewayを通じて、カタログ、カート、オーダー、シッピングなどのマイクロサービスへ接続し、AIエージェント機能ではAI/MCP Gatewayを通してLLMやAPIを利用する構成です。
デモでは、危険な内容を含むリクエストに対し、KongがBad Requestとしてブロックする様子も示されました。白石は、今回は「AI Semantic Prompt Guard」プラグインを使っているが暴力的・攻撃的な内容やプロンプトインジェクション攻撃に対して、ベクトル検索や正規表現、またはAWS Guardrails / Azure Contents Safety / Google Model Armor といったサードパーティ製品との連携をすることで複数の方法で防御できると説明しました。
加えて、APIとAIのキャッシュについても紹介されました。Kongのレイヤーでキャッシュを返すことで、後段のAPIへアクセスせずに応答できます。白石は「AIでも同様に、意味合いの近い質問に対してKong側で返すことで、トークン量や速度の改善が見込める」と説明しました。
また、Kongを各環境に配置し、Konnectから設定を配信することで、AWS、Google Cloud、Azure、オンプレミスなどにまたがる環境でも同じポリシーを適用できます。さらに、ログはGrafana、Prometheus、Tempoなどへ送信でき、AI、MCPサーバー、APIの通信をまとめて可視化できるとしました。
このデモで示された要点は、次の4つです。
- 危険なプロンプトや攻撃的な入力をゲートウェイで止める
- キャッシュによってAPI負荷やトークン消費を抑える
- クラウドやオンプレミスをまたいで同じポリシーを適用する
- AI・MCPサーバー・APIの通信をログで一元的に可視化する
デモの最後には、Kongの宣言的構成管理も紹介されました。Kongの設定をYAMLファイルとして管理し、設定を適用すると、アプリケーションを再ビルド・再起動せずに挙動を変更できます。
白石は「アプリケーション上にプロンプトや振る舞いの指示を書いていた場合、変更のたびにアプリケーション側のライフサイクルに巻き込まれる」と説明しました。
一方、Kongでは「プロンプトのライフサイクルとアプリのライフサイクルを切り離した」と説明。新たな攻撃や社内ルールの変更にも素早く対応できることがKongの魅力の1つだと述べました。
Kongの今後の展望：A2A通信とコンテキスト最適化
最後に白石は、Kongの今後の取り組みとして、次の項目に触れました。
- Agent GatewayとA2A（Agent-to-Agent）への対応
- MCP利用時のコンテキスト最適化
- Code Mode
- OpenAPI SpecからのMCPサーバー作成・登録の簡素化
特に「MCP利用時のコンテキスト最適化」については、「MCPレジストリと組み合わせ、Kong側で必要なツールだけを渡すことで、コンテキスト削減と回答精度向上を目指す」と説明しました。
セッションのまとめとして、AIエージェント時代には接続性が必要であり、MCPサーバーを自分で作成・運用する必要は基本的になくなると述べました。API、MCPサーバー、AIエージェントを通して統制を取り、情報漏えい対策と可観測性を適用することで、社内でのAI活用が進み、事業競争力の向上につながります。