MCPゲートウェイレジストリ:AIエージェントのためのエンタープライズコントロールプレーン
.webp)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
チャットボットの段階は過ぎました。今、あなたのチームは、社内データベースにアクセスし、Jiraを照会し、GitHubを更新し、Slackメッセージを送信し、カスタムAPIを呼び出すといった、人間の手を借りずにすべてを行う自律型AIエージェントを構築しています。これらの驚くべきエージェントワークフローは、真の生産性向上をもたらしますが、ほとんどのチームが見過ごしがちなガバナンスの複雑さも生じさせます。
最初は、この設定でうまくいきます。開発者が1つのエージェントを1つのツールに接続し、それがスムーズに動作するという興味深い実験として始まります。やがて、VS Code拡張機能、コミュニティサーバー、または社内ビルドから提供された、より多くのエージェントとMCPツールが追加されます。間もなく、IT部門は、いくつの接続が存在するのか、資格情報がどこに保存されているのか、どのエージェントが何にアクセスできるのかを把握できなくなります。
これは単なる技術的な頭痛の種ではありません。それは、いつ発生してもおかしくないセキュリティおよびコンプライアンスのリスクでもあります。
Anthropicは2024年11月にモデルコンテキストプロトコル(MCP)を発表し、AIエージェントが外部ツールと接続する方法を標準化しました。MCPは統合言語の問題を解決しますが、ガバナンスには対応していません。それは、エンタープライズ規模で多数のエージェントにわたる何百ものツール接続を管理するのに役立ちません。
ここでMCPゲートウェイレジストリが役立ちます。このレジストリとは何か、本番環境で機能するために何が必要か、競合他社がどこで的を外しているか、そしてなぜTrueFoundryがより優れた、費用対効果の高い選択肢なのかを見てみましょう。
.webp)
レジストリ導入前の混乱:ポイントツーポイントのツール統合
企業が中央レジストリなしでAIエージェントの構築を開始すると、ほとんどの場合、同じ道をたどります。最初のいくつかの統合はシンプルです。その後、予測可能な形で問題が発生し始めます。
- ハードコードされた依存関係: 開発者はエージェントを特定のMCPサーバーに直接接続します。各エージェントは、ツールの場所、呼び出し方法、使用する資格情報を知っています。この設定は単一のソースでは機能します。しかし、バックエンドツールのAPIが変更されると、それに依存するすべてのエージェントが一度に機能しなくなります。変更を処理するためのバッファがないため、プラットフォームチームは同じ問題を修正するために複数のコードベースを更新する必要があります。
- 資格情報の乱立: 各エージェントが独自の認証を管理します。APIキーは環境ファイルにハードコードされます。OAuthフローは個々のサーバーや開発者ノートブックに保存されます。サービスアカウントの資格情報はチーム間で重複してしまいます。キーをローテーションする必要がある場合、それが存在するすべての場所を追跡して更新しなければなりません。1つのインスタンスが見落とされた場合、それがセキュリティ上の脆弱性となります。大規模になると、安全な資格情報のローテーションを保証することはほぼ不可能になります。
- 一元的な可視性の欠如: ITおよびセキュリティチームは、確認するための一元的なアクセスポイントを持っていません。彼らは、どのMCPツールやデータソースをエージェントが使用できるのか、どのエージェントがどのツールを使用しているのか、データベースがどれくらいの頻度で照会されているのか、あるいはエージェントがアクセスすべきではないデータにアクセスしているのか、といった質問に簡単に答えることができません。コンプライアンス監査では、多くのシステムからログを収集する必要があり、異常を発見することはほぼ不可能です。
これらは特殊なケースではなく、シャドーAIの露出の主要な原因となっています。これらは、コントロールプレーンなしでエージェントインフラストラクチャを拡張しようとするすべての企業で発生します。ポイントツーポイントモデルは、個々のエージェントを試している初期導入者には機能します。しかし、本番環境では機能しません。
MCPゲートウェイレジストリとは?
MCPゲートウェイレジストリは、あなたの組織内の中心的なカタログです。 MCPゲートウェイこれは、組織内の承認されたすべてのツールに対する唯一の信頼できる情報源として機能します。ここは、承認されたすべてのMCPサーバーと外部ツールが登録され、記述され、バージョン管理され、組織全体のエージェントから発見可能になる唯一の場所です。
AIツールインフラのディレクトリだと考えてください。マイクロサービスカタログが個々のサービスエンドポイントを抽象化するのと同様に、レジストリはエージェント開発者から生のプロトコルサポートの複雑さを抽象化します。サービスカタログが開発チームにマイクロサービス設定でどのAPIが存在するかを示すように、MCPゲートウェイレジストリはAIエージェントにどのMCPツールを使用できるか、それらをどのように呼び出すか、そしてどのような権限を持っているかを伝えます。
- 一元的な公開: プラットフォームエンジニアは、公式MCPレジストリにツールを一度登録します。その後、組織内の認可されたエージェントは、検索、ドキュメント取得、内部APIアクセスなどの一般的なユーティリティを含め、エンジニアが各チームに接続詳細を送信することなく、そのツールを見つけて使用できます。レジストリは、各エージェントが管理する個々のツールではなく、ツールのデプロイメントターゲットとなります。
- リアルタイム検出: エージェントはハードコードされたツール設定を使用しません。代わりに、実行時にレジストリをクエリして、使用が許可されているツールの最新のスキーマ、説明、および指示を取得します。この動的なツール検出により、バックエンドAPIが変更されると、レジストリが更新され、エージェントは自動的にその変更を認識します。ツールが変更されるたびにプロンプトを更新する必要がなくなります。
- 単一の情報源: セキュリティチームは統合されたインベントリを取得します。組織内のすべてのAIアクセス可能なツールは、所有権、アクセス制御ポリシー、使用履歴とともに一箇所に登録されます。すべてが可視化され、隠れて動作するものはありません。これが、すべてのエージェントアクセス可能なツールにとって真の記録システムとなります。
.webp)
エンタープライズレジストリの主要機能
すべてのツールレジストリがエンタープライズ用途向けに構築されているわけではありません。ツールとエンドポイントをリストする基本的なカタログは出発点であり、解決策ではありません。本番環境では、以下の4つの機能が、 最高のMCPゲートウェイ レジストリを、適切に整理された設定ファイルと区別します。
きめ細かなロールベースアクセス制御 (RBAC)
実際の組織では、異なるAIエージェントが異なる機能を果たし、異なるレベルのアクセス制御で運用されるべきです。顧客サポートエージェントは、注文記録を検索し、チケットをエスカレートする必要がありますが、データベース管理コマンドへの可視性を持つべきではありません。財務エージェントは支払いシステムへのアクセスが必要ですが、デプロイメントパイプラインをトリガーできるべきではありません。
エンタープライズレジストリは、実行レベルだけでなく、可視性レベルでこれを強制します。AIエージェントは、使用が許可されていないMCPツールを見ることはありません。アクセス制御ポリシーと制御ロジックは、呼び出し試行が失敗した後ではなく、検出前に適用されます。これは、ポリシーの強制が後付けのガードレールではないことを意味します。それは、ツールがどのように表面化されるかというアーキテクチャに組み込まれています。
適切なレジストリにおけるRBACは、IDに紐付けられています。Okta、Azure AD、またはカスタムSSO設定など、既存のエンタープライズIDプロバイダーと統合され、AIエージェントが継承する権限が、組織全体の人間のアクセスを管理するのと同じポリシーによって統制されるようにします。
シームレスなツールバージョン管理
バックエンドAPIは変更されます。それは避けるべきリスクではなく、管理すべき現実です。エンタープライズレジストリは、プラットフォームチームがツールの複数のバージョンを同時に公開できるようにすることで、これに対応します。
バージョン1はレジストリに残り、それに依存するエージェントにサービスを提供し続けます。バージョン2はそれと並行して登録されます。開発チームは、特定のエージェントをバージョン2に向けてテストできます。チームが更新の安定性を確信したら、本番エージェントは独自のスケジュールで移行します。強制的な切り替え、ダウンタイム、そして警告なしにツールが変更されたことによるエージェントの破損はありません。
この並行バージョン管理モデルは、成熟したインフラストラクチャチームが共有依存関係を管理する方法です。プラットフォームエンジニアにとって最も良い点は、強制的なアップグレード期間を調整する必要がなくなることです。レジストリは、AIエージェントとそのMCPツールにも同じ規律をもたらします。
一元的な認証保管
ダイレクトコネクトモデルでは、各エージェントが自身の認証情報ストレージを担当します。これは、APIキー、OAuthトークン、データベース接続文字列が、他のソフトウェアアーティファクトとともに、環境変数や設定ファイルとしてインフラストラクチャ全体のエージェントコードベースに散在していることを意味します。単一のキーをローテーションするには、それが存在するすべての場所を見つける必要があります。一つでも見落とすと、脆弱性の窓が生まれます。
一元化された認証情報保管庫を持つレジストリは、この問題を解消します。バックエンドの認証情報は一箇所に保存され、ゲートウェイによって管理されます。エージェントがツールを呼び出す際、ゲートウェイは実行時に適切な認証情報を注入します。エージェントが生のキーを見ることはありません。開発者は、呼び出すツールの下流認証を管理する必要がなくなります。トークンの更新は自動的に行われます。ローテーションは保管庫で一度行われるだけで、すべてのエージェントがすぐにその恩恵を受けます。
個々のユーザーは、単一のトークンを使用してMCPゲートウェイに一度認証します。ゲートウェイは、特定のバックエンドツールで必要とされるカスタムヘッダーの注入を含め、彼らに代わってすべての下流MCP認証を処理します。
完全な監査証跡と可観測性
従来のインフラストラクチャでは、サーバーからログを取得してインシデント中に何が起こったかを理解できます。しかし、分散型のエージェントとツールの連携では、一元的な収集ポイントがない場合、それがはるかに困難になります。
エンタープライズレジストリは、その収集ポイントを提供します。包括的な監査ログは、エージェントの識別情報、リクエストを行ったユーザーまたはサービス、渡された引数、返された応答、およびインタラクションの遅延とともに、すべてのツール呼び出しを記録します。問題が発生した場合、エージェントが何を行い、どのような順序で、各ツールが何を返したかを正確に追跡できます。コンプライアンスチームは、個々のツールごとにカスタム計測を構築することなく、監査可能な記録を得ることができます。
.webp)
競合他社のレジストリに潜む欠陥
MCPサーバーを大規模に管理するためのいくつかの選択肢が存在します。それらのほとんどは問題の一部を解決しますが、どこが不十分であるかを理解することは、組織にとって適切なレジストリを評価する際に実際に何が必要かを明確にするのに役立ちます。
- 設定ファイルの悪夢: JFrog MCPレジストリやその他のオープンソースMCPプロキシツールなどのコミュニティレジストリは、Docker ComposeやNginxリバースプロキシのセットアップを中心としたアプローチを含め、静的なYAMLまたはJSON設定ファイルを介してツール登録を管理します。新しいMCPサーバーごとに、手動でのファイル編集、コミット、再デプロイが必要です。小規模であればこれは機能しますが、MCPツールの数が増え、チームが多岐にわたるにつれて、ボトルネックとなります。非エンジニアがツールを登録するためのUIはなく、承認ワークフローもなく、レジストリの現在の状態を一目で確認する方法もありません。設定ファイルが唯一の情報源となりますが、常に現実から一つ更新が遅れています。
- エンタープライズペイウォール: いくつかのAIインフラストラクチャSaaSプラットフォームは、基本的なMCPゲートウェイルーティングを無料で提供しますが、本当に重要な機能はエンタープライズ契約の裏に隠しています。RBAC、SSO統合、ツールバージョン管理、包括的な監査ログは高度な機能ではありません。それらは、あらゆる本番環境へのデプロイにおける基本的な要件です。これらの機能が予測不能な料金体系の裏に閉じ込められている場合、ガバナンスの姿勢は技術的な決定ではなく、予算に関する話し合いに左右されます。
- データ流出と主権のリスク: クラウドホスト型SaaSレジストリは、お客様が制御できないインフラストラクチャを介して、エージェントの動的なツール検出リクエストを処理します。規制対象業界では、これは即座のセキュリティリスクを生み出します。すべての検出リクエストは、お客様の内部システム、AIエージェントが使用するツール、およびそれらがアクセスしている機密データに関するメタデータを含む可能性があります。これはデータリスクであると同時にサプライチェーンの懸念でもあります。信頼できるサードパーティのクラウドであっても、そこを経由してルーティングすることは、単一のツールが呼び出される前に、お客様自身のデータレジデンシー要件に違反する可能性があります。MCPサーバーをソフトウェアサプライチェーンのコンポーネントとして扱うことは、サードパーティのコード依存関係と同様の厳格な精査を適用することを意味します。これは、セキュリティチームが常に指摘する主要な運用リスクです。
.webp)
TrueFoundryがツール管理を簡素化する方法
TrueFoundryは、AIエージェントを実験段階から本番環境へ移行する際に企業が直面する真の課題を解決するためにレジストリを設計しました。最大のブレークスルーは、ガバナンスに別途ツールレイヤーが不要であり、お客様自身のインフラ内で動作することです。このアーキテクチャは、データ主権、運用の簡素化、そして開発者の速度を低下させないガバナンスという3つの優先事項に焦点を当てています。
絶対的なデータ主権(VPC内デプロイ)
TrueFoundryは、レジストリとMCPゲートウェイ全体を、AWS、GCP、Azureのいずれであっても、お客様自身のクラウドアカウント内で実行します。ツールトラフィック、エージェントのテレメトリ、認証情報、動的なツール検出リクエストは、お客様のネットワーク内に留まります。TrueFoundryのインフラを経由したり、パブリックインターネットに触れたりすることはありません。
SOC 2、HIPAA、または内部データレジデンシーの要件を持つ組織にとって、これは単なるチェックボックスではありません。これは、お客様のMCPセキュリティモデルに適合するプラットフォームと、使用前に長い例外処理プロセスを必要とするプラットフォームとの違いを意味します。すべてがお客様のVPC内で実行されるため、セキュリティチームは自社のインフラストラクチャのみをレビューすればよいのです。単一のコントロールプレーンは、お客様のセキュリティ境界内に完全に留まります。
透明性の高い、コンピューティングベースの経済性
TrueFoundryは、企業により高額な料金を請求するために機能制限を使用することはありません。きめ細かなRBAC、認証情報ストレージ、完全な動的ツール検出、および包括的な監査ログは標準機能であり、高額な料金プランの追加機能ではありません。
費用は実際のコンピューティング使用量に基づきます。エージェントインフラを拡張するにつれて、使用したコンピューティングに対して支払うことになり、標準であるべきガバナンス機能へのアクセスに対してではありません。これは、本番環境で安全に運用するために必要な機能が、契約ティアに関わらず初日からMCPサーバーのガバナンス機能として利用可能であることを意味します。
開発者の生産性向上のために構築
ツールの公開、テスト、バージョン管理に、YAMLファイルの編集や、デプロイパイプラインを介した設定変更の提出は不要です。開発者は、直感的なUIまたはCLIを通じて公式のMCPレジストリとやり取りします。プラットフォームチームは、利用するすべてのチームに手作業を発生させることなく、新しいMCPサーバーエントリの登録、アクセス制御ポリシーの設定、および更新のプッシュを行うことができます。
TrueFoundryは、MCPサーバーをMCPサーバーグループを使用して論理的なグループに編成します。これにより、チームは環境、機能、またはセキュリティティアごとにツールセットを分離できます。開発チームは、本番レジストリでアクセスを開放することなく、ツールを試すことができます。異なるグループは独自のRBACポリシーと承認フローを持つため、リスクの高い機密システムでは、エージェントがそれらを呼び出すことを許可する前に、明示的な承認が必要です。
このプラットフォームは、On-Behalf-Of (OBO) MCP認証もサポートしています。AIエージェントが一般的なサービスアカウントで動作するのではなく、MCPクライアントツールの呼び出しは、エージェントと対話する実際の人間ユーザーのIDと権限を反映できます。MCPツールは、その人物が企業システム内の他の場所で持っているのと同じアクセス境界を尊重します。
.webp)
結論:ツールをインフラとして扱う
AIエージェントを概念実証段階を超えてスケールさせた企業全体で、このパターンは一貫しています。エージェントとツールの間のポイントツーポイント接続は、ある時点までは機能しますが、やがて破綻します。本番環境で少数のエージェントを超える数のエージェントが動作し始めた瞬間、中央レジストリの不在は理論上のリスクではなく、日常的な運用上の問題となります。
企業全体でのMCPの広範な採用により、このインフラ層はますます不可欠になっています。MCPゲートウェイレジストリは、エージェントアーキテクチャの上に「あれば良い」という層ではありません。組織が単一エージェントから協調的なマルチエージェントシステムへと導入曲線をたどるにつれて、レジストリは他のすべてが依存する基盤となります。
それはエージェントインフラを統制するコントロールプレーンです。ITチームが可視性を得る方法であり、セキュリティチームがポリシーを強制する方法であり、ツールにアクセスしたいすべてのチームに手作業を発生させることなく、開発者がツールを出荷する方法です。
TrueFoundryは、そのすべてをあなたの環境内に保持します。あなたの会社のシステムは保護され、データがクラウドの境界を離れることはありません。MCPレジストリはあなたのVPC内で動作します。認証情報はあなたのボールトに保管されます。監査証跡はあなたのものです。そして、本番環境で安全に運用するために必要な機能は、料金に関する交渉なしで利用できます。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


Recent Blogs
Frequently asked questions
MCPゲートウェイレジストリとAPIデベロッパーポータルにはどのような違いがありますか?
APIデベロッパーポータルは、従来のアプリケーション統合のためにRESTエンドポイントを探索し、ドキュメントを参照したいと考える開発者のために構築されています。これは、どのAPIを使用し、どのように活用するかを判断する主体が人間であることを前提としています。
MCPゲートウェイレジストリは、実行時にリアルタイムで判断を下すAIエージェントのために構築されています。エージェントはドキュメントを読みません。エージェントはレジストリに動的にクエリを投げて使用可能なツールを探索し、最新のスキーマを取得して、その瞬間に適切な機能を呼び出します。また、このレジストリは、従来のデベロッパーポータルでは対応できなかったエージェント固有の要件(呼び出しごとの認可、実行時の認証情報注入、稼働中のエージェントに向けたツールバージョニング、すべてのやり取りに関する構造化された監査ログなど)も管理します。
MCPゲートウェイ・レジストリは、社内のカスタムエンタープライズツールに対応していますか?
はい。これはレジストリを選択する前に確認すべき非常に重要な機能の一つです。TrueFoundryは、公開されているMCPサーバーと、チームが社内で構築した完全にカスタムなセルフホスト型ツールの両方をサポートしています。
TrueFoundryのSDK、またはチームが既に使用しているバックエンドスタックを使用してMCPサーバーを構築できます。コンテナ化してKubernetesやクラウドネイティブなインフラストラクチャにデプロイすれば、サーバーはゲートウェイに登録され、RBAC(ロールベースのアクセス制御)、フェデレーション認証、オブザーバビリティ、認証情報管理といったプラットフォームレベルの機能を即座に利用できるようになります。社内ツールは、公開されている統合機能と同様に、レジストリ内でファーストクラスの機能として扱われます。
レジストリはどのようにしてプロンプトインジェクションの脆弱性を防ぐのでしょうか?
プロンプトインジェクション攻撃は、本来意図されていない動作をエージェントに実行させることで成立することがよくあります。防御策の一つとして、エージェントが試行できる範囲を制限することが挙げられます。レジストリレベルでツールの可視性を制御すれば、エージェントは明示的にアクセス権が付与されたツールのみを検出し、呼び出すことが可能になります。悪意のあるプロンプトが入力されたとしても、データベース削除コマンドのようなツールがエージェントの許可リストに含まれていなければ、その実行を指示することはできません。
これだけでプロンプトインジェクションのリスクを完全に排除できるわけではありませんが、被害範囲を大幅に限定できます。結果サイズの制限、レート制限、高リスク操作に対する承認フローといったゲートウェイレベルのガードレールと組み合わせることで、レジストリは攻撃者が侵害されたプロンプトを通じて実行可能なアクションを最小限に抑えます。
MCPツールレジストリでは、どのようにバージョン管理が行われますか?
プラットフォームチームがツールを更新する際、既存のバージョンを残したまま、新しいバージョンをレジストリに公開します。両方のバージョンが同時に利用可能な状態となるため、バージョン1で稼働中のエージェントはそのまま変更なしで動作し続けます。新しいバージョンをテストしたいチームは、本番環境に影響を与えることなく、特定のエージェントを新しいバージョンに向けることができます。
更新されたバージョンの検証が完了したら、各チームはそれぞれのスケジュールでエージェントを移行します。古いバージョンは即座に削除するのではなく、猶予期間を設けてから廃止することが可能です。これにより、バックエンドツールの変更時にバージョン管理層が存在せず、強制的なアップグレードや予期せぬ不具合が発生しがちな直接接続型アーキテクチャの課題を解消できます。












.webp)
.webp)


.png)

.png)














