MCPレジストリとは何か？そして、なぜそれなしではエージェントを実行できないのか

Anthropicの Model Context Protocol (MCP)を試しているなら、おそらく「localhostの壁」にぶつかったことがあるでしょう。

リポジトリをクローンし、npx @modelcontextprotocol/server-postgresを実行してClaude Desktopに接続すると、まるで魔法のように感じられます。LLMが突然データベースと対話できるようになるのです。しかし、50のエージェント、20のデータソース、厳格なIAMロールが存在するプロダクション環境にそのアーキテクチャを導入しようとした途端、その「魔法」は分散システムの悪夢へと変わります。

必要なのはプロトコルだけではありません。電話帳が必要です。すべてのツールがどこにあるか、誰がそれを呼び出すことを許可されているか、そして現在正常に動作しているかを知っているブローカーが必要なのです。

業界では、この概念は MCP Registryとして定着しつつあります。

TrueFoundryでは、レジストリを単なるURLの静的なリストとして扱っているわけではありません。私たちはそれを、私たちが呼ぶところの、アクティブなルーティングインフラ層として実装しています。 Virtual MCP Serversとして実装しています。レジストリが、おそらくあなたが無視している最も重要なコンポーネントである理由を深く掘り下げて解説します。

問題：「N x M」接続マトリックス

中央レジストリがなければ、エージェントシステムのトポロジーは混乱状態になります。

例えば、3つのエージェント（サポート、セールス、DevOps）と3つのツール（Jira、Salesforce、AWS）があるとします。それらを直接接続する場合、すべてのツールのエンドポイントと認証情報を、各エージェントの設定にハードコードする必要があります。

DevOpsチームがJiraツールを新しいクラスターに移動した場合、すべてエージェントが機能しなくなります。SalesforceのAPIキーをローテーションした場合も、すべてエージェントを再デプロイする必要があります。

この MCP Registry は、を分離することでこれを解決します。 コンシューマー （エージェント）から プロバイダー （ツール）へ。エージェントはレジストリに接続し、レジストリはリクエストを適切なツールにルーティングします。

トポロジーの違いは以下の通りです。

図1：直接接続とレジストリトポロジーのワークフロー

TrueFoundryのアプローチ：「仮想」レジストリ

私たちは、「 Virtual MCP Server」と呼ばれる機能を使用してレジストリパターンを実装しました。これにより、ゲートウェイは統合された MCPレジストリおよびAIゲートウェイとなり、エージェントシステムのための単一のコントロールプレーンに、検出、セキュリティ、ランタイムルーティングを統合します。

エージェントがクエリする必要がある個別の「カタログ」データベースを構築する代わりに、レジストリをネットワークパスに直接組み込みました。TrueFoundry AI Gatewayは、実際のバックエンドサービスの前に位置する「仮想」MCPサーバーとして機能します。

で説明されているように、 TrueFoundryのVirtual MCP Serversに関するドキュメント：

「Virtual MCP Serverは、複数のMCP Serverを単一のMCP Serverに集約します。これにより、MCPクライアントは単一のエンドポイントに接続し、複数のMCP Serverからツール/プロンプト/リソースにアクセスできるようになります。」

これは、些細ながらも大きな変化です。エージェントにとって、ゲートウェイは無限の機能を備えた巨大なMCPサーバーのように見えます。舞台裏では、ゲートウェイはCluster Aのpostgres-mcpポッドとCluster Bのslack-mcpポッドにトラフィックをルーティングしています。

アクティブなレジストリの機能

適切なレジストリは、単にツールをリストするだけではありません。それはインタラクションのライフサイクルを管理します。

1. 動的ディスカバリ

エージェントがTrueFoundry Gatewayに接続する際、どのようなツールが存在するかを事前に知る必要はありません。接続にはServer-Sent Events (SSE)が使用されます。ハンドシェイク時に、GatewayはエージェントのIDを検査し、エージェントが利用可能なツールリストを動的に構築します。

新しい ベクトル検索ツール を明日デプロイした場合でも、Gatewayの設定に追加するだけです。次回エージェントが接続した際には、新しいツールが自動的に利用可能になります。エージェント側でのコード変更は不要です。

2. 一元化された認証（ バウンサー）

これは情報セキュリティ部門を満足させる部分です。生のMCPを実行する場合、エージェントはデータベースの認証情報を必要とします。それはセキュリティ上、受け入れがたいことです。

レジストリベースのアプローチでは、 Gateway認証とセキュリティを活用します。エージェントはTrueFoundry APIキーのみを保持します。Gatewayが実際のダウンストリームサービス用のシークレットを保持します。

「GatewayはクライアントのAPIキーを検証し...その後、セキュアなヘッダーを使用してリクエストをバックエンドのMCPサーバーにプロキシします。」

3. シャドーイングとガバナンス

すべてのツール呼び出しがレジストリ（Gateway）を経由するため、一元化された監査ログが得られます。どのエージェントがいつdelete_userツールを呼び出したかを正確に確認できます。また、エージェント内の暴走ループが本番データベースをクラッシュさせないように、レート制限を適用することもできます。

表1：レジストリタイプの比較

統合：コードでの表現

この抽象化の利点は、クライアントコードがいかにすっきりするかです。インフラについて心配する必要がなくなります。

ガイドで詳しく説明されているように エージェントでMCP Gatewayを使用する、MCPクライアントを仮想エンドポイントに向けるだけです。

なぜこれが重要なのか

AIは「チャットボット」フェーズから「エージェント」フェーズへと移行しています。実際には、これは次のことを意味します。 LLMエージェント は、ツールを発見し、権限を適用し、複数の環境で確実に実行するために、MCPレジストリのようなインフラ層に依存するようになりました。この新しい世界では、 社内APIは、最も価値のある資産です。

LLMに安全に公開することは、モデリングの問題ではなく、インフラの問題です。これが理由の一つです。 MCP対RAG は、エンタープライズエージェントのワークフローを設計する際に重要になります。

を扱うことで、 MCPレジストリ をインフラの中核として（TrueFoundryの仮想MCPサーバーを介して管理される）、ツールをマイクロサービスのように扱う能力を得ます。それらに依存するエージェントを壊すことなく、デプロイ、スケーリング、セキュリティ保護、非推奨化を行うことができます。

これにより、Pythonスクリプトのスパゲッティ状態が、構成可能なエンタープライズアーキテクチャへと変わります。

‍

‍