MCPが実験段階を抜け、企業インフラとして定着し始めました。
2026年4月2〜3日にニューヨークで開催された「MCP Dev Summit North America 2026」では、Amazon・Uber・Dockerなど大手企業が本番運用の設計パターンを共有しています。この記事では、1,200人が集まったサミットの要点を整理します。
この記事でわかること：
- MCP Dev Summitの位置づけと主要な発表内容
- Amazonが数万人のエンジニアにMCPを展開した手法
- Uberが毎週数万回のエージェント実行を支えるゲートウェイ設計
- 企業がMCPを導入する際に押さえるべきセキュリティの考え方
MCP Dev Summitとは何か
MCP Dev Summit North America 2026は、Linux Foundation傘下のAgentic AI Foundation（AAIF）が主催するMCPエコシステムの旗艦イベントです。会場はNew York Marriott Marquis、参加者は約1,200名でした。
MCPの共同開発者であるAnthropicのDavid Soria Parra氏が基調講演を行い、MCPの進化を振り返りました。ローカルのstdio接続のみだった初期から、リモートサーバー、認証、構造化出力、長時間タスク用のtasksプリミティブへと進化しています。最大の技術的変化は、SEP-1442で進行中のステートフルセッションからステートレスリクエストへの移行です。
Amazonの事例：数万人規模のMCP展開
AmazonのPrincipal Software EngineerであるJames Hood氏が「MCP @ Amazon Scale」と題した基調講演を行いました。Hood氏は16年のAmazon在籍経験を持ち、社内のAIパワーユーザーコミュニティを立ち上げた人物です。
Amazonが構築したのは、社内MCP発見インフラです。数百のMCPサーバーを一元管理するレジストリを設け、チケットシステムからアーキテクチャドキュメントまで、社内システムへのエージェント接続を標準化しました。
注目すべきは、MCPツール・エージェントスキル・コンテキストファイル・標準作業手順書（SOP）を「構成可能で共有可能なエージェント設定」としてバンドルする仕組みです。AWSはこの設計をオープンソースの「Strands Agent SOP」プロジェクトとして公開しています。
Agent SOPはMarkdownベースの指示セットで、AIエージェントに複雑なワークフローを自然言語で実行させます。パラメータ入力と制約ベースの実行をサポートし、MCPサーバーのプロンプトとして公開される仕組みです。
セキュリティ：「Lethal Trifecta」による分類
Hood氏のチームは、セキュリティ研究者Simon Willison氏が提唱した「Lethal Trifecta（致命的な三要素）」フレームワークを採用しています。これは以下の3条件が同時に揃うとき、AIエージェントが攻撃に対して脆弱になるという考え方です。
- プライベートデータへのアクセス
- 信頼できないコンテンツへの露出
- 外部への通信能力
Amazonの中央レジストリは、発見ツールであると同時にセキュリティツールでもあります。各MCPサーバーをこの3条件に照らして分類し、エージェント設定に危険な組み合わせがないか、デプロイ前にスキャンします。
Uberの事例：MCPゲートウェイによる制御
UberのAgentic Platformチームは「Operating MCPs at Enterprise Scale: Uber’s Journey」と題した講演で、本番運用の規模を明かしました。
Uberが構築したのはMCP GatewayとRegistryからなるコントロールプレーンです。社内の数千のThrift・Protobuf・HTTPエンドポイントを自動的にMCP経由でエージェントに公開します。すべてのエージェント通信はGoベースのGenAI Gatewayを経由し、外部モデルへのリクエスト送信前にPII（個人識別情報）のリダクションと内部識別子のスクラブを実行します。
毎週数万回のエージェント実行がこのプラットフォーム上で稼働しているとのことです。
ゲートウェイパターンが企業の標準設計に
AmazonとUberの事例に限らず、サミット全体を通じて「ゲートウェイ＋レジストリ」パターンが企業MCP運用の標準設計として浮上しました。AWS、Uber、Docker、Kong、Solo.ioなど複数の企業・スポンサーが同じ結論に収束しています。
Arcade.devの共同創業者Alex Salazar氏は、LLMが動作する推論レイヤーと、ガバナンス・認証・変更制御を担うアクションレイヤーを明確に分離すべきだと主張しました。ゲートウェイはこのアクションレイヤーの実装そのものです。
コンテキスト肥大化への対策
MCPツールの定義がモデルのコンテキストウィンドウを圧迫する「コンテキスト肥大化」問題も議論されました。複数の講演者が、これはプロトコルの欠陥ではなくクライアント側の実装課題だと位置づけています。
Claude Codeはすでにプログレッシブツール発見とMCPツール検索機能を実装しており、ツールの説明がコンテキストウィンドウの10%を超える場合は自動的に遅延読み込みします。Anthropicの公開ベンチマークでは、トークン使用量が約85%削減されたと報告されています。
MCPの次のフェーズ
サミットでは今後の進化の方向性も示されました。
Tasksプリミティブ（SEP-1686）は、長時間のバックグラウンド処理に対応する仕組みです。サーバーが即座にハンドルを返し、処理は裏側で継続します。リトライやタスクの有効期限ポリシーが議論の中心です。
Triggersは、MCPにおけるWebhookのような仕組みです。サーバーが新しいデータをクライアントに能動的に通知します。専用のワーキンググループが設立され、チャーターも公開されています。
導入を検討する企業が押さえるべきポイント
サミットの議論を踏まえると、企業がMCPを本番導入する際の設計指針は以下に集約されます。
中央レジストリの構築が出発点です。MCPサーバーの発見・バージョン管理・セキュリティ分類を一箇所で行います。
ゲートウェイの配置でエージェントと外部の境界を制御します。認証、PII除去、監査ログをゲートウェイ層に集約します。
Lethal Trifectaの評価を全MCPサーバーに適用し、危険な組み合わせを検出する仕組みを自動化します。
Agent SOPの活用で、複雑なワークフローをチーム間で共有可能にします。
MCPは個人の開発ツールから企業インフラへと段階を移しました。今回のサミットが示したのは、スケールに伴って生じるセキュリティとガバナンスの課題には、すでに実証済みのパターンがあるということです。