AIエージェントをエンタープライズシステムに組み込むプラクティス 【MCPゲートウェイ / ツール・フェデレーション（MCP Gateway）】 💡 ポイント 「エージェント5つ × SaaS 10種 = 50本の個別統合。この掛け算地獄を解消するのがMCPゲートウェイです。」 エージェントが増え、接続先SaaSが増えるたびに統合コストが爆発します。ツール定義の乱立、スキーマの不整合、そしてSaaSのサイレント仕様変更による暗黙の破綻。これらをアーキテクチャレベルで解決します。 🔥 解決する課題 - N（エージェント）×M（SaaS）の統合コスト爆発 - 各エージェントが独自にツール定義を持つことによる重複・不整合 - ツール経由の間接プロンプトインジェクション - エージェントに見えるツールが多すぎることによる選択精度の劣化 - SaaSのサイレント仕様変更（APIレスポンス形式変更等）による暗黙の破綻 🏗️ 提案パターン 各SaaSコネクタをMCP（Model Context Protocol）サーバとして束ね、ゲートウェイがツールの発見・認可・呼び出し監査・スコープ制御を一元管理します。ツール許可リストを主体（部署×エージェント種別）で動的に絞り、エージェントに見えるツールを必要最小限にします。危険ツール（削除・送金・外部送信など不可逆操作）には承認フックを設置します。さらに、ツール定義/APIスキーマを「契約」としてバージョン管理し、定期的に実APIと突合してドリフト（乖離）を検知します。後方互換のないドリフトを検出した場合は、アラート＋該当ツールの一時無効化で安全側に倒します。 ✅ 選定条件 - 採用する場合：連携SaaSが10種以上。複数エージェントが共通ツールを使う。N×M統合の複雑さに困っている。 - 採用しない場合：ツールが2〜3個固定の単機能エージェント（直結のほうが堅牢でシンプル）。依存APIが安定していて変更頻度が極めて低い環境。 ⚠️ 落とし穴 - エージェントに露出するツールが20〜30を超えると選択精度が低下します。tool RAGで意図に応じて動的に絞るか、役割別サブエージェントに分割してください。 - 契約テスト（ドリフト検知）を導入しないと、SaaS側の仕様変更に気づかず、エージェントが誤ったデータを処理し続けます。Salesforce APIのフィールド変更などは実際に起きる頻度が高いです。 - MCPサーバの認可設計を後回しにすると、全エージェントが全ツールにアクセスできる状態が放置されます。 🛠️ 実装方針 - 各SaaS（Salesforce / ServiceNow / Jira / Slack / Box 等）のMCPサーバを構築します。公式MCPサーバがあればそれを採用し、なければOpenAPI定義からツールを自動生成して自作MCPサーバとして用意します。 - MCPゲートウェイを配置し、ツールレジストリ（カタログ）を構築します。各MCPサーバが提供するツールを一覧化し、部署×エージェント種別でアクセス可能なツールを動的にフィルタリングする許可リストを設定します。 - OAuth 2.1 ベースの認可と承認フックを設定します。不可逆操作（削除・送金・外部送信）を行うツールにはP09（動的認可PDP）と連携した承認ゲートを設置し、人間の承認なしに実行されない構成にします。 - 契約テスト（Pact等）とスキーマレジストリでドリフト検知パイプラインを構築します。週次でツール定義と実APIスキーマを突合し、後方互換のない変更を検出した場合はアラート＋該当ツールの自動無効化を行います。 - tool RAG または役割別サブエージェント分割で、各エージェントに露出するツール数を20以下に制御します。意図に応じて動的にツールを絞り込み、選択精度を維持します。 #AIエージェント# #エンタープライズアーキテクチャ#