Systems Design Meditation · Edition 2
API のその先へ
MCP が示す新しいインフラストラクチャ層
Edward Calderón
ソフトウェアアーキテクト
API はソフトウェア同士をつないだ。エージェントは、どのソフトウェアに接続するかを自ら決定しなければならないソフトウェアをもたらす。
従来のインテグレーションは知識から始まる。開発者がエンドポイントを選び、そのスキーマを調べ、その周りに決定論的なコードを書く。呼び出し側はサービスを知っており、通常は操作も知っている。エージェント的なソフトウェアはこの前提を変える。ケーパビリティを発見し、その説明を理解し、それらの中から選択し、境界を越えてコンテキストを引き継ぐ必要があるかもしれない。
呼び出しからディスカバリーへ
REST、RPC、イベントストリームは今も不可欠である。MCP はそれらを時代遅れにするものではない。MCP が扱うのは別の層、つまり共有インターフェースを通じて、モデル駆動のクライアントにツール、リソース、プロンプトを提示する層である。基盤となる操作は、依然として API 呼び出し、データベースクエリ、ローカルプロセスでありうる。
この区別は重要だ。ディスカバリーは単なる使いやすい SDK ではない。ケーパビリティを選択するマシンには、正しい推論を支える名前と説明、入力を制約するスキーマ、そして明示的なセキュリティ境界が必要である。曖昧なツールの説明はアーキテクチャ上の欠陥である。なぜなら、それは選択の振る舞いを変えてしまうからだ。
MCP の仕様は、クライアント・ホスト・サーバーのアーキテクチャとケーパビリティネゴシエーションを定義している。また、実装者に対して、同意、データプライバシー、ツールの安全性を守るよう警告している。これらは新しい層についての手がかりである。コンテキストの交換は権限から切り離せないのだ。
私が興味を持つのは、MCP が最終的なプロトコルになるかどうかではない。エージェントとシステムの相互作用が、プロトコル層を必要とするほど重要になったという事実である。プロトコルは変わりうる。しかし、その必要性は残る。
ツールを取り巻くコントロールプレーン
有用なエージェント用ツールのエコシステムには、カタログ以上のものが必要である。ライフサイクルとガバナンスが必要だ。誰がツールを登録したのか? どのバージョンが有効なのか? どのテナントがそれを見られるのか? ディスカバリーは権限を意味するのか、それとも単なる認知にすぎないのか? 結果はどのように信頼できないものとしてマークされるのか? ワークフローの途中でサーバーが消えたらどうなるのか?
これらは分散システムの問いである。サービスは独立に障害を起こす。スキーマは進化する。リトライは副作用を重複させうる。エージェントは古いコンテキストを保持しているかもしれない。モデルにとってアトミックに見えるツール呼び出しも、その下では複数の非アトミックな操作にまたがっているかもしれない。
テレメトリの読み取り、インシデントの作成、キャパシティの変更というツールの中から選ぶ運用エージェントを想像してほしい。ディスカバリーは3つすべてのケーパビリティを公開すべきだが、認可は一律であるべきではない。読み取りは広く許可してよい。インシデントの作成は冪等であるべきだ。キャパシティの変更は、より強固なポリシーを必要とし、制限された範囲を含めるべきである。共有プロトコルはインターフェースの記述を助けるが、境界の強制はプラットフォームが担わなければならない。
ベンダー間の境界がこれをさらに重要にする。組織は複数のモデルプロバイダーと、数百の社内外のサービスを使うことになる。特注のアダプターは双方向に結合を生み出す。プロトコル層があれば、すべてのクライアントが個別のプライベートなインテグレーションを学ぶことなくツールを進化させられ、各サービスを書き換えることなくクライアントを変更できる。
神話なき標準化
重要なエコシステムは、インターフェースが予測可能になると加速することが多い。しかし、類推は説明する以上に隠してしまうことがある。MCP は単なる「新しい HTTP」ではない。HTTP はネットワーク化されたコンポーネント間で表現を転送する。MCP は、モデル向けのコンテキストとケーパビリティのための規約を定義し、その下では一般的に既存のトランスポートを使う。
有用なアーキテクチャ上の主張は、もっと狭い。標準インターフェースは、コンポーネントが協調するために必要な二者間合意の数を減らす。レジストリ、ゲートウェイ、ポリシーエンジン、テストハーネス、オブザーバビリティといったツール群のための空間を生み出す。また、障害を比較可能にする。
標準化は自動的に相互運用性を生まない。2つのサーバーが同じプロトコルを実装しながら、互換性のないセマンティクスを使うことがありうる。`search` という名前のツールは、顧客のドキュメント、公開ウェブ、あるいは運用データベースを検索するかもしれない。セマンティックな品質、来歴、信頼は依然としてシステム上の課題である。
これは層状の設計を示唆している。ディスカバリーと交換にはプロトコルを使う。認可にはアイデンティティとポリシーを使う。意味にはドメイン契約を使う。説明責任にはトレーシングと監査記録を使う。信頼性のある実行には通常の API とキューを使う。どの単一の層も、他の層を解決するふりをすべきではない。
開発者にとって、MCP の当面の価値は、したがって普遍性の約束ではない。モデルのクライアントをツールの実装から疎結合にする実践的な圧力である。それは実験のコストを下げ、置き換えをより可逆的にする。
プロトコルが重要なのは、システムが独立に進化できるようにするからである。