PinterestがAIエージェント向けの本番MCPエコシステムを構築した方法

• MCPをAIエージェントのツール接続標準として採用し、IDE・社内チャット・AIエージェントなど実際のエンジニアリングワークフローに本番レベルで統合したPinterestの構築経験
• 単一のモノリシックサーバーではなく、ドメイン別の複数のMCPサーバー（Presto、Spark、Airflowなど）と中央レジストリを組み合わせたアーキテクチャを選択
• エンドユーザーJWT + SPIFFEメッシュアイデンティティの二重認証レイヤーとビジネスグループベースのアクセス制御により、機密データに対する最小権限の原則を適用
• 月間66,000件の呼び出し、844人の月間アクティブユーザー、推定月7,000時間削減という定量的な成果を達成
• MCPを単なる実験ではなくエンジニア生産性インフラとして定着させた鍵は、セキュリティ優先設計、統合デプロイパイプライン、そして従業員がすでに使っているツールへの直接統合

---

MCP導入の背景

• Model Context Protocol(MCP) は、LLMがツール・データソースと通信する際に、モデル・ツールごとに個別の統合を実装する代わりに統一されたクライアント・サーバープロトコルを使うオープンソース標準
• PinterestはMCPを単純なQ&Aではなく、エンジニアリング作業の自動化の基盤として活用——「ログを読んで問題を見つける」から「バグチケットを分析して修正PRを提案する」までを目標に設定

初期アーキテクチャ設計

ローカルではなくクラウドホスティング

• ローカルMCPサーバー（stdio通信）方式もサポートするが、社内クラウドでホストするMCPサーバーを標準ルート（paved path）として採用
  • 社内ルーティング・セキュリティロジックを適用しやすい環境で運用することが目的
  • ローカルサーバーは実験用途に限って許可

複数の小型サーバー vs. 単一モノリシックサーバー

• 単一の巨大サーバーではなく、ドメイン別の小型MCPサーバーを多数選択
  • サーバーごとに異なるアクセス制御を適用可能
  • モデルのコンテキストが不要に埋まってしまう問題を防止
• 初期フィードバック: 新しいMCPサーバーの構築には、デプロイパイプライン・サービス設定・運用セットアップなど事前作業が多すぎるという指摘
  • 解決策として統合デプロイパイプラインを構築——チームはツールロジックだけ定義すれば、プラットフォームがデプロイ・スケーリングを自動処理

社内MCPレジストリ

• 承認済みMCPサーバーの一覧と接続方法を管理する単一の信頼できる情報源（source of truth）
• Web UI: 人がサーバーを探索し、所有チーム、サポートチャネル、セキュリティ体制、稼働状況、利用可能なツールを確認
• API: AIクライアント（社内AIチャット、IDE統合、エージェント）がサーバーの探索・検証や、「このユーザーはサーバーXを利用できるか」の判定に活用
• レジストリに登録されたサーバーのみを本番承認サーバーとして認定——ガバナンスのバックボーンとして機能

運用中のMCPサーバーの状況

主要サーバー（利用量ベース）

• Presto MCPサーバー: トラフィックベースで最も利用されるサーバー——エージェント（AI支援IDEを含む）がPrestoベースのデータをオンデマンドで照会し、ダッシュボードに切り替えることなくワークフロー内で直接データを活用
• Spark MCPサーバー: AIによるSparkデバッグ体験の基盤——Sparkジョブ失敗の診断、ログ要約、構造化された根本原因分析の記録を支援し、運用スレッドを再利用可能な知識へ変換
• Knowledge MCPサーバー: 汎用知識エンドポイント——社内AIボットが社内知識・Q&A、文書、デバッグ質問に活用

Pinterest社内サービスとの統合

• 多くのPinterest従業員が毎日使う社内LLM WebチャットインターフェースにMCPツールを統合
  • フロントエンドが自動的にOAuthフローを処理した後、現在のユーザーに許可されたツール一覧を返す
  • AIチャットエージェントがMCPツールをエージェントのツールセットに直接バインドし、通常のツール呼び出しと同じ体験を提供
• 社内チャットプラットフォームのAIボットにもMCPツールを搭載
  • レジストリAPIを通じた認証・認可を処理
  • 特定のMCPツールを特定チャネルに制限する機能をサポート（例: Spark MCPツールはAirflowサポートチャネルでのみ利用可能）

セキュリティ・ガバナンス・ポリシー

MCPセキュリティ標準

• MCP Security Standard を別途定義——実験用でないすべてのMCPサーバーは、所有チームの指定、社内レジストリ登録、セキュリティ/法務・プライバシー保護/（該当する場合）GenAIレビューのチケット承認が必須
• レビュー結果に応じて、サーバーにアクセスできるユーザーグループなどのセキュリティポリシーを決定

認証(AuthN)および認可(AuthZ)の二重レイヤー

• エンドユーザーJWTベースのフロー

  1. ユーザーがAIチャット、IDEプラグイン、AIボットなどのサーフェスで操作
  2. クライアントが社内認証スタック向けにOAuthフローを実行し、その後JWTをMCPレジストリ・対象サーバーへ渡す
  3. EnvoyがJWTを検証し、X-Forwarded-User、X-Forwarded-Groupsヘッダーへマッピングしたうえで、大まかなセキュリティポリシーを適用
  4. サーバー内部では@authorize_tool(policy='…')デコレーターで細かな権限制御を実施（例: get_revenue_metricsはAds-engグループのみ呼び出し可能）

• ビジネスグループベースのアクセス制御ゲート

  • 認証済みのPinterest従業員・契約者全員に一律アクセスを許可するのではなく、機密サーバーについてはJWTからビジネスグループの所属情報を抽出し、承認済みグループに属しているかを検証
  • Presto MCPサーバーは幅広いサーフェスから技術的にはアクセス可能だが、Ads・Finance・特定のインフラチームなど承認済みグループのみセッション確立および高権限ツールの実行が可能

• サービス専用のSPIFFEベースフロー

  • 低リスク・読み取り専用シナリオでは、SPIFFEベース認証（メッシュアイデンティティ）のみで処理
  • ループ内にエンドユーザーが存在せず、影響範囲が厳密に限定される場合にのみ使用

MCP OAuth標準との違い

• MCP公式仕様ではサーバーごとのOAuth 2.0認証フロー（同意画面、サーバーごとのトークン管理）を定義しているが、Pinterestは既存セッションを再利用する方式を採用
  • ユーザーはAIチャットなどのサーフェスを開く時点で、すでに社内認証スタックで認証済み——追加のログインプロンプトや同意ダイアログは不要
  • Envoyとポリシーデコレーターがバックグラウンドで透過的に認可を処理

Human-in-the-Loop

• MCPサーバーは自動化アクションを可能にするため、手動操作に比べて影響範囲が大きい
• エージェントガイダンスに従い、機密性が高い、またはコストの大きいアクションの前には人による承認を必須化——エージェントがアクションを提案し、人が（バッチ処理も可能）承認・拒否
• elicitationを活用し、危険なアクション（例: テーブルデータの上書き）の前に確認を要求

可観測性と成果指標

• すべてのMCPサーバーにライブラリ関数を適用——入出力ログ、呼び出し回数、例外追跡、テレメトリを標準提供
• エコシステム全体の測定指標: 登録済みMCPサーバー・ツール数、全サーバー呼び出し数、呼び出しあたりの想定削減時間（サーバー所有者が軽量なユーザーフィードバックや従来の手作業ワークフローとの比較に基づいて算定）
• 単一のノーススター指標: 削減時間(time saved)——呼び出し回数 × 1回あたりの削減分数で影響度を概算
• 月間66,000件の呼び出し、844人の月間アクティブユーザー、推定月7,000時間削減