MCP改訂でAPI設計が機械解釈可能な仕様へ移行

このコラムは、MCPの2026年7月の改訂でMCPサーバーがステートレスになったという前回の指摘を踏まえ、著者はそれをMCPが特別な構成物であることをやめ、APIの世界に加わる通常のHTTP部品になったことだと位置づけ直している。そこから企業の実践的な道筋は既存のOpenAPI仕様から始めることだ。Speakeasy、FastMCP、openapi-mcp-generatorなどのツールがその仕様を読み取り、エンドポイントをエージェント向けのツール定義に変換するため、バックエンドAPIを書き換える必要はない。

著者は従来の機械処理とAIを対比させる。SDK生成は固定されたルールに従うが、エージェントは説明文の意味を解釈し、目標と状況に応じてどの操作を使うかを決める。MCPを「究極のAPI消費者」と表現したKevin Swiberの言葉がこの関係を捉えている。その結果、単に機械可読なだけの仕様では不十分であり、AIがツールに何ができ、いつ使うべきかを判断できるよう説明文を磨く必要がある。

コラムはまた、自動生成は便利な出発点だが、特に大規模なAPIでは必ずしも本番投入に適した状態になるとは限らないと指摘する。認可とエラー処理、複数のエンドポイントをツールにまとめること、説明文の作成は生成後に人が対応する作業として残る。MCP周辺では、2026年1月26日に最初の公式MCP拡張としてMCP Appsが公開されたこと、2026年7月28日の改訂で拡張機能の正式な枠組みが仕様内に位置づけられたことに触れ、GoogleのA2UIやAG-UIといった関連する取り組みはまだ整理が進んでいないとする。次回は、エージェントがAPIを呼び出し、商品を選び、支払いを完了するエージェント型コマースを扱う予定だ。