Morgan Stanley、MCPでAPI戦略を再構築！エージェント連携のコストとガバナンス課題を深掘り

• モルガン・スタンレーがAIエージェント向けAPI戦略をMCPとArchitecture as Codeで刷新し、110以上のAPIを本番デプロイ。
• MCPはLLMとツール・データを接続するオープンプロトコルで、OpenAPIにはない「プロンプト」や「リソース」概念を導入。
• エージェントのチャッティネスによるトークンコスト増大やツール選択の曖昧性が新たな課題となり、専門ゲートウェイとガバナンス強化が急務。

我々エンジニアが日々直面するのは、ビジネスサイドからの「もっと早く、もっと柔軟に」という要求と、既存システムの複雑性との板挟みだ。特にAPI開発の現場では、OpenAPIのような詳細な仕様書を整備しても、それが直接ビジネス価値に結びつく実感を得にくいというジレンマを抱えてきた。しかし、ここにきて「MCP（Model Context Protocol）」という新たな波が、その風景を一変させようとしている。モルガン・スタンレーのJim Gough氏が指摘するように、私自身、OpenAPIの仕様書でビジネスサイドが熱狂する姿を見たことはない。だが、MCPは違う。このプロトコルは、LLM（大規模言語モデル）ベースのアプリケーションを、既存のツールやデータに接続するためのオープンな架け橋として登場し、そのシンプルさゆえにビジネスサイドの期待値を一気に高めているのだ。

MCPの核心は、エージェントが利用可能な「ツール」を発見し、それを呼び出し、結果を検証するという一連のサイクルにある。従来のAPIが「何ができるか」を記述するのに対し、MCPの「ツール」は、複数のAPIエンドポイントを組み合わせて特定のビジネス課題を解決する「構造化された操作」として定義される。さらに特筆すべきは、「プロンプト」と「リソース」という概念の導入だ。プロンプトは再利用可能なパラメーター化された指示パターンであり、エージェントの振る舞いをガイドする。リソースは、エージェントに提供されるドキュメントやデータであり、全体的なコンテキストを補強する役割を果たす。これにより、エージェントは単なるAPI呼び出しの自動化を超え、より複雑なタスクを自律的に実行できるようになる。

このMCPの登場は、まさに電光石火の勢いで業界に浸透している。2024年11月に発表され、2025年にはOpenAIが採用を開始、GitHubも追随したことで、開発者の日常に急速に食い込んできた。Yahoo Financeが報じたPresentations.AIの事例のように、具体的なサービスがMCPサーバー経由でAIエージェントに公開され始めているのは、その実用性の証左だろう。また、Publickeyが報じたGoogleの「Managed Agent API」が、APIコール一発でLinux環境付きのAIエージェントを起動し、Markdownでカスタム指示を可能にするという動向は、MCPの「プロンプト」概念と深く共鳴する。これは、エージェントへの指示がより柔軟かつプログラム可能になる未来を示唆している。しかし、この熱狂の裏には、我々エンジニアが直視すべき新たな複雑性が潜んでいる。プロトコル自体はシンプルでも、エージェントが多数のツールをオーケストレーションする際の「ツール選択の曖昧性」や、エージェントの「チャッティネス」によるトークンコストの増大は、従来のAPI管理では経験しなかった新たな課題として、我々の前に立ちはだかるだろう。

金融業界という、極めて厳格な規制とセキュリティ要件に縛られる環境で、APIプログラムを刷新することは並大抵のことではない。深夜の障害対応に追われ、スパゲッティコードの悪夢にうなされるような状況は、金融システムでは許されない。モルガン・スタンレーのJim Gough氏とAndreea Niculcea氏が推進する「Architecture as Code」と「CALM」の組み合わせは、まさにこの課題に対する彼らの回答だ。彼らは、サービスやインフラのデプロイをコードとして管理することで、わずか1年で110以上のAPIを本番環境にデプロイするという驚異的な実績を上げている。これは、単なる自動化に留まらず、アーキテクチャ、プラットフォーム、セキュリティを一体化した独自のデプロイメントパイプラインを構築した結果である。

しかし、MCP時代の到来は、この堅牢なシステムにも新たな挑戦を突きつける。Jim Gough氏が指摘するように、MCPプロトコル自体は「ダムパイプ」であり、真の複雑性は、その上で動くエージェントが情報をオーケストレーションする部分にある。例えば、エージェントが利用できるツールが1つや2つであれば、その選択は容易だ。しかし、そのコレクションが拡大し、機能が重複するツールが増えればどうなるか。自然言語で記述されたツールの定義は、たちまち曖昧になり、エージェントは適切なツールを選択するために「無限ループ」のような試行錯誤を繰り返すことになる。これは、OpenAIがGPT-6向けにプロンプトキャッシングの改善に取り組んでいる（Related Global Insight 2）ことからもわかるように、LLMの推論コストと密接に結びついている。

さらに深刻なのは、エージェントの「チャッティネス」によるトークンコストの増大だ。エージェントは、ツールの定義を読み込み、プロンプトを解釈し、応答を生成するたびにトークンを消費する。この対話的な性質は、従来のAPIコールと比較して、はるかに高いコストを発生させる可能性がある。モルガン・スタンレーのような大規模なエンタープライズでは、このコストは無視できないレベルに達するだろう。この課題に対処するため、彼らは「専門のゲートウェイとコントロールプレーン」の必要性を強調している。従来のAPIゲートウェイがビジネスロジックから切り離されるべきだという原則は、エージェントエコノミーにおいては再考を迫られる。エージェントの振る舞いを最適化し、コストを抑制するためには、ゲートウェイがツール選択のロジックやプロンプトのキャッシュ、さらにはセキュリティとガバナンスの自動化（デプロイゲート）に深く関与する必要があるのだ。我々エンジニアは、単にプロトコルを実装するだけでなく、その上で動くエージェント群が引き起こす「無限ループ」のようなコスト増大や、意図せぬ動作を防ぐための「デッドロック」回避策を講じなければならない。

「API不要」という言葉が、我々APIエンジニアの耳に届くたびに、一抹の不安を覚えるのは私だけではないだろう。AWS WorkSpacesがAIエージェントによるレガシー・デスクトップアプリケーション操作をAPI不要で可能にする（関連する日本国内の動向 1）というニュースは、エージェントの適用範囲が従来のAPI中心主義を越え、より広範な領域に及ぶ可能性を示唆している。MCPはAPIを前提とするが、この動向は、エージェントが「道具」としてAPIをどう利用するか、その「意図」を理解する視点が、これからのAPI設計者には不可欠であることを教えてくれる。

MCPが提示する新たなアーキテクチャパラダイムは、APIが単なる「スマートなパイプ」から、エージェントがタスクを遂行するための「道具箱」へと変貌することを意味する。この変革期において、我々エンジニアは、いくつかの根本的な問いに直面せざるを得ない。第一に、「APIエコノミーは、エージェントエコノミーへと完全に移行するのか？その際、従来のAPI設計原則はどこまで通用するのか？」という問いだ。RESTful原則やマイクロサービスアーキテクチャの知見は、エージェント間のA2A（Agent-to-Agent）通信が主流になった時、どのように再解釈されるべきだろうか。第二に、「自然言語によるインターフェースが普及する中で、技術的負債の可視化や、ガバナンスの自動化は、より一層困難になるのではないか？」という懸念だ。自然言語の曖昧さは、システムの振る舞いを予測不能にし、デバッグや監査を複雑にする可能性がある。

この未曾有の変革期を乗り越えるため、我々エンジニアには具体的な処方箋が必要だ。まず、MCPや関連プロトコルの動向を注視し、自社システムへの適用可能性を早期に検証すること。モルガン・スタンレーが実践するArchitecture as Codeのような、自動化されたガバナンスとデプロイメントの仕組みを強化することは、エージェントエコノミーにおける複雑性を管理する上で不可欠となる。次に、エージェントの「チャッティネス」によるコスト増大を意識し、プロンプトエンジニアリングやキャッシュ戦略（OpenAIのプロンプトキャッシング改善の動向は示唆に富む）を深く学ぶこと。これは、単なる技術的スキルに留まらず、ビジネスコストに直結する重要な知見となる。そして何より、従来のAPI設計者も、エージェントが「道具」としてAPIをどう利用するか、その「意図」を理解する視点を持つことだ。APIはもはや人間が直接利用するだけでなく、AIエージェントが自律的に発見し、組み合わせて利用する対象となる。そのための「使いやすさ」とは何かを再定義する必要があるだろう。

この変革期において、我々エンジニアは単なる実装者ではなく、未来のシステムアーキテクチャをデザインする「先駆者」としての役割を強く求められている。この問いにどう答えるか、それが我々のキャリアを左右するだろう。エージェントエコノミーは、我々に新たな技術的挑戦と、ビジネスへの深い洞察を要求しているのだ。