MCPに関する記事は数多く存在するが、その大半はプロトコルの紹介や接続したサーバーの数にとどまっている。
Pinterestのエンジニアリングチームは、実際の本番環境で稼働するMCPアーキテクチャを具体的なデータとともに公開した。詳細が豊富で、一読の価値がある。
アーキテクチャの選択：複数の専用サーバー、統合型は採用せず
Pinterestはすべてを処理する単一の巨大なMCPサーバーを構築しなかった。彼らのアプローチは、各コアデータシステムに独立したMCPサーバーを対応させるというものだ。
現在本番環境で稼働中のサーバー：
- Prestoサーバー：データクエリ
- Sparkサーバー：ジョブデバッグとログ分析
- Airflowサーバー：ワークフロー管理
- Knowledgeサーバー：内部ドキュメントとナレッジベース
なぜ統合サーバーにしなかったのか。
その理由は、複数のサーバーによって独立したアクセス制御が可能になり、各チームが対応するツールドメインにのみアクセスできるようになるため、単一サーバーでの過剰な権限を防げるからだ。同時に、各サーバーのツールセットは簡潔に保たれ、モデルが無関係なツールの山で混乱するのを防ぐ。
レジストリ：エージェントが利用可能なものを把握
Pinterestは、承認済みサーバーの信頼できる情報源として中央レジストリを構築した。
AIクライアントはツールを呼び出す前に、レジストリに問い合わせる。このサーバーは存在するか？使用する権限があるか？
これにより現実的な問題が解決される。すべてのデータツールを全従業員に開放すべきではないということだ。例えばPresto（大規模データクエリ）は、特定のビジネスグループのメンバーのみがAIツールを通じてアクセスできる。
セキュリティ設計の詳細
二層の認証：
- ユーザーJWTトークン：誰が操作しているかを検証（ヒューマン・イン・ザ・ループシナリオ）
- サービスメッシュID：サービス間の呼び出しにはメッシュIDを使用
彼らはMCP標準のOAuthフローを採用せず、既存の内部認証システムと統合する道を選んだ。その理由は、各サーバーに個別の認可を要求する際の摩擦を減らすためだ。
さらに、エリシテーションと呼ばれる設計もある。高リスクまたは高コストの操作を実行する前に、エージェントは人間のユーザーに確認を求めなければならず、承認がなければ実行されない。これは自動化とセキュリティのバランスを取るものだ。
本番環境の数字
2025年1月時点のデータ：
| 指標 | 数値 |
|---|---|
| 月間呼び出し回数 | 66,000回 |
| アクティブユーザー数 | 844人 |
| 月間推定節約時間 | 約7,000エンジニア時間 |
月間7,000時間——エンジニア1人あたりの月間稼働時間を約160時間とすると、約44人分の作業量に相当する。これは各ツール呼び出しあたりの推定節約時間を合計したものであり、正確な数値ではないが、規模感を示す参考値となる。
注目すべき点
Pinterestの記事にはこうある。このシステムはエンジニアが日常的に使うIDE、社内チャットプラットフォーム、そしてAIワークフローに統合されている——エンジニアがわざわざ使うための独立したAIポータルではない、と。
これこそがエンタープライズAI導入の成否を分ける鍵だ。ツールは作業者がいる場所に現れるべきであり、作業者に別の場所へ行くことを求めるべきではない。
出典：Pinterest Deploys Production-Scale Model Context Protocol Ecosystem for AI Agent Workflows（InfoQ）；CocoLoop、Building an MCP Ecosystem at Pinterest（Pinterest Engineering Blog / Medium）