9月23日、InfoQが「APIs for Agents: Rethinking API Programs in the MCP Era」と題した記事を公開した。「去年のQConでは、Architecture as Codeで全サービスをデプロイすると宣言したが、その時点では何一つ実装していなかった」——Morgan StanleyのディスティングイッシュトエンジニアであるJim Goughはそう率直に振り返る。それから1年、同社は110本以上のAPIを本番環境でArchitecture as Codeによって継続的デプロイするまでに至った。本記事はそのQConセッションのレポートであり、MCPとCALM（Architecture as Code）を組み合わせたエンタープライズAPIプログラムの再設計を詳述している。
Morgan Stanleyが本番稼働させた「Architecture as Code × MCP」
このセッションの核心は、MCPとCALMという2つの技術の組み合わせにある。一方がエージェントとAPIを接続するプロトコルであり、もう一方がそのAPIをコードとして一貫管理するアーキテクチャ基盤だ。Morgan Stanleyはこの2つを組み合わせることで、エージェント対応のAPIプログラムを金融機関のガバナンス要件を満たしながらスケールさせようとしている。
CALMとは何か
CALM（Architecture as Code）は、FINOS（金融向けオープンソース財団）が主導するオープンソースプロジェクトだ。JSONスキーマでシステムのボックスとアローを表現し、その上に型情報を付加できる。
エンジニアが「新しいAPIを作りたい」となった場合、用意されたパターン（テンプレート）から一つ選び、自分の要件に合わせたアーキテクチャ定義を作る。パターン側にはプラットフォームとしての制約が組み込まれているため、開発者はそこから外れた構成を取れない。これがガードレールとしての機能だ。
Morgan Stanleyでは現在、パターンは3〜4種類しかないが、そこから110のデプロイメントが派生している。
CALMの主な構成要素：
- パターン：組織として正しい構成を定義したテンプレート
- アーキテクチャ：パターンを継承した個別サービスの定義
- テンプレート：アーキテクチャからTerraform・Helmチャート・Kustomizeなどを生成するHandlebars風の変換定義
- バンドル：テンプレートのまとまり
- デコレータ：アーキテクチャ定義が肥大化するのを防ぐため、メタデータを分離する仕組み（新機能）
- CALM Hub：アーキテクチャ・パターン・コントロールを管理するOSSのUIポータル（ArtifactoryのアーキテクチャER版に相当）
MCPをどう捉えるか
MCP（Model Context Protocol）は2024年11月にAnthropicが発表し、2025年初頭にOpenAIが採用、その後GitHubも対応したことで一気に普及した、LLMベースのアプリケーションとツール・データを接続するオープンプロトコルだ。
Goughは「OpenAPIスペックを見てビジネス側が興奮したのを見たことがない。だがMCPスペックには皆が飛びついている」と述べ、MCPが技術的な仕様というよりビジネス側とエンジニア側の両方がイメージしやすいインターフェースとして機能していると指摘する。
MCPの3要素：
| 要素 | 内容 |
|---|---|
| Tools | APIエンドポイントを「何ができるか」の単位でまとめた構造化オペレーション |
| Prompts | エージェントの振る舞いを誘導する再利用可能な指示テンプレート |
| Resources | エージェントにコンテキストを与えるドキュメント・データ |
ただし、単純に見えてスケールすると一気に難しくなる。ツールが1〜5個なら選択は容易だが、増えるにつれて定義が重複し始め、英語の自然言語による曖昧さも相まって選択精度が落ちる。さらに、ツールの定義・説明・レスポンスがすべてトークンを消費するため、コストがスパイラル的に上昇する構造を持つ。
実際のデモ：MCPサーバーをCALMでデプロイする
セッションでは5つのシナリオをライブデモで示した。最初のシナリオは「Trades API + MCPサーバー」の構成だ。
Andreea Niculcea（Morgan Stanley VP、プラットフォームエンジニアリング担当）が実演した構成は以下のとおり：
- Trades APIとMCPのアーキテクチャ定義をCALMパターンから生成
- CALMテンプレートからKubernetesマニフェスト（Deployment・Service・ConfigMap）を生成
kubectl applyでminikubeクラスターへデプロイ- Claude（エージェントホスト）から自然言語でクエリ
デモでは「Vodafoneのトップ10トレードを取得して」とClaudeに入力すると、エージェントがGetTradesツールを発見し、VOD→VOD.L→Vodafoneと試行錯誤した後、取引所プレフィックスLSE付きのシンボルで正しくデータを取得するまでのエージェントの推論プロセスが確認できた。Goughはこの挙動を「MCPの『おしゃべりな』性質」と表現し、これがトークンコスト増加につながる点も合わせて示した。
ガバナンスとコントロール
金融機関としてガバナンスは欠かせない。CALMのパターンにはコントロール（制約）を組み込む機能があり、開発者がパターンから逸脱した構成を取ろうとするとCLIで検証エラーになる仕組みだ。去年時点ではこのコントロール機能は存在せず、今年新たに加わったものだとGoughは説明している。
金融機関においてこうしたガバナンス機能が重視される背景には、監査証跡や変更管理に対する厳格な要件がある。アーキテクチャ定義をコードとして管理することは、システム構成の変更履歴をGitで追跡可能にし、レビュープロセスをPull Requestに乗せることを意味する。CALMのコントロール機能はその延長線上にあり、「承認済みパターン以外は物理的にデプロイできない」という強制力をプラットフォームレベルで担保する。これは規制環境下での開発において、人的レビューに依存しない統制の仕組みとして機能する。
将来の拡張：A2Aプロトコルへのフォワードルック
デモのプレビュー部分では、MCPの次に来る可能性のある標準としてA2A（Agent-to-Agent）プロトコルも使われている。A2AはGoogleが2025年に提唱したオープン仕様で、異なるフレームワーク・ベンダーのAIエージェント同士が相互に通信・協調するためのプロトコルだ。MCPがLLMアプリケーションとツール・データを接続することに主眼を置くのに対し、A2Aはエージェント同士がタスクを委譲し合う「エージェント間通信」を担う位置づけにある。
Morgan Stanleyの取り組みは「MCPに対応したら終わり」ではなく、プロトコルの変化に追従できるプラットフォームを構築することを目的としている点が特徴的だ。CALMのパターン・テンプレート構造はプロトコル非依存で設計されており、A2Aのような新たな標準が普及した場合でも、パターン定義を更新するだけで既存のデプロイメント群に展開できる設計思想を持つ。
詳細はAPIs for Agents: Rethinking API Programs in the MCP Eraを参照していただきたい。
