リポジトリごとに 20 の MCP 設定を持つのではなく、すべてのエージェントに単一のエンドポイントを。

背景

このプラットフォームチームは、十数の製品スクワッドにまたがる約六十名のエンジニアを支援していた。MCP を採用した一年の間に、各スクワッドは必要なサーバー——GitHub、Postgres、Linear、Sentry、そして社内のデプロイツール——を、それぞれ Claude Code と Cursor の設定へ直接組み込んでいった。どのリポジトリも独自の mcp.json を抱え、新しいツールを一つ導入するには、それを求めるすべてのプロジェクトへプルリクエストを出す必要があった。

この方式はどうにか機能してはいたものの、規模には耐えなかった。二十余りのサーバーが今や数十の設定ファイルに重複し、バージョンはわずかずつ食い違い、認証情報は最初に設定した者が貼り付けたまま各所に残っていた。

課題

以下の三つの問題が、振り返りのたびに繰り返し浮上した。

• 設定の乱立。 サーバーを追加・更新するたびに、すべてのリポジトリへ手を入れる必要があった。設定は次第に食い違い、どのスクワッドがどのツールを持つのかを確信をもって言える者はいなかった。
• 認証情報の置き場所の誤り。 個人アクセストークンや API キーは開発者のマシンに散在し、時にはコミット済みの設定にまで紛れ込んだ。漏えいしたトークンの更新は、まさに宝探しの様相を呈した。
• 混み合ったコンテキストウィンドウ。 どの MCP サーバーも、リクエストごとにツールスキーマ一式をプロンプトへ押し込む。二十のサーバーが接続された状態では、エージェントは実際のタスクの一行目を目にする前に、コンテキストの大半をツール定義に費やしていた。

アプローチ

チームは単一の onemcp ポータルを立ち上げ、サーバーを一度だけそこへ追加し、各上流をその場で認証した。各クライアントがすべてのサーバーと個別に通信するのではなく、クライアントはポータルと通信し、ポータルが各上流へ振り分ける。

問題の形を変えたのは、次の二点である。

• 単一のエンドポイントが多数を置き換える。 リポジトリはもはやサーバーを列挙しない。Claude Code や Cursor をポータル URL に向けるだけで、厳選されたツール群全体を継承する。サーバーの差し替えや更新はポータルで一度行えばよい。
• Code Mode が定義の壁を置き換える。 ポータルはあらゆるツールスキーマを事前に注入するのではなく、三つのメタツール——search、describe、execute——のみを公開する。エージェントはタスクに必要なわずかなツールを自ら発見し、一度の往復で単一のスクリプトから呼び出す。

展開

移行はスクワッド単位で二週間かけて進められた。各リポジトリについて、チームはローカルのサーバー一覧を削除し、単一のポータル項目を置いた。認証情報はポータルが保持するため、開発者はその過程で自らのマシンからトークンを取り除いていった。

プラットフォームチームはポータルを唯一の管理点として保った。新しいサーバーは中央で精査のうえ追加され、アクセス権も数十の mcp.json に散らばるのではなく、一か所で管理された。

成果

• 20 余りのサーバーが単一エンドポイントの背後に。 各リポジトリは同一のポータル URL を参照する。ツールの追加はポータルの変更であって、全社的なプルリクエストではない。
• リクエストごとのツール負荷を約 90% 削減。 数百の事前読み込み定義を三つのメタツールに置き換えたことで、リクエストごとのツール負荷はおよそ 15,000 トークンから約 500 トークンへ低下した——エージェントはそのコンテキストをタスクそのものに充てる。
• 認証情報はホスト側へ。 上流の OAuth とトークンはポータル内に留まり、クライアント設定にもコミット済みのファイルにも決して入らない。更新は一か所での一度の作業で済む。

私たちはプルリクエストで MCP 設定を配布するのをやめた。今やリポジトリは 1 つのエンドポイントを指すだけで全ツールを得られ、トークンは私たちではなくセキュリティチームが管理している。

関連する事例研究

• ある AI サポートエージェントのトークン・ダイエット
• 認証情報を漏らさずセルフサービスのデータエージェントを実現する