7月29日、Postmanが「AI-Ready APIs: Agents Are the New Audience」と題した記事を公開した。この記事では、AIエージェントが主要なAPIコンシューマーとなった時代に向けて、APIをエージェント対応にするための設計指針と評価手法について詳しく紹介されている。

APIの「読者」が人間からエージェントに変わった

これまでAPIの主な利用者は開発者だった。開発者はドキュメントを読み、詰まればサポートにメールを送り、記載のない挙動は試行錯誤で乗り越えた。いわば「resilient reader（粘り強い読者）」として、ドキュメントの隙間を自分で埋めてきた。

だが今、その構図が変わっている。開発者がゴールを指示すると、コーディングエージェントが代わりに調査・評価・統合を行う。どのAPIを使うかの選定も、認証の設定も、エンドポイントの呼び出しも、エージェントが処理する。開発者がAPIのウェブサイトにアクセスすることすら、もはや必須ではない。

問題はここにある。人間が詰まればチケットを起票する。エージェントが詰まれば黙って競合APIに切り替える。 その離脱はログにも、放棄されたサインアップ画面にも残らない。ドキュメントに説明がない認証、HTMLで返ってくる500エラー、曖昧なパラメータ名——人間が「まあいっか」と乗り越えてきたギャップが、エージェントにとってはすべて「ハードストップ」になる。

Postmanのチームは過去6ヶ月間、世界最大規模のAPIプログラムを持つ企業の内部に入り込み、この実態を観察した。そこから生まれたのが「AI-Ready APIs」という評価フレームワークだ。

2層構造で捉えるエージェント対応

Postmanはエージェント対応を2つの層に整理している。

第1層：API Product Foundations（API製品の土台）

バージョン管理されたAPI仕様、型付きスキーマ、ドキュメント、クイックスタート、コードサンプル、SDK——多くのAPIプログラムがすでに投資してきた領域だ。エージェント専用ではないが、エージェントのすべての動作はこの土台に依存する。ここを整えていれば、次の層に乗り越えていくだけでいい。

第2層：Agent Journey Optimizations（エージェント体験の最適化）

これが新しく必要になる層であり、人間のユーザーには見えない部分だ。

• **llms.txt**：エージェントがAPIを発見するための機械可読なエントリーポイント。「エージェント向けのSEO」と位置づけられる
• Markdownドキュメント：JavaScriptでレンダリングされたページではなく、エージェントが直接フェッチできるテキスト形式
• RFC 9457 problem-detail形式のエラー：HTMLの壁ではなく、エージェントがパースできる構造化エラー
• **AGENTS.md**：APIの使い方をエージェント向けに説明したファイル
• 認証メタデータの明示：エージェントが推測できる形で認証方式を公開する

人間のユーザーはこれらを意識しない。しかしエージェントにとっては、あるかどうかが「使えるか、使えないか」を分ける。

25項目・5カテゴリの評価スコア

AI-Ready APIはドメインを指定するだけで、エージェントが実際にたどる経路（API仕様、ドキュメント、SDK、CLI、MCPサーバー、well-knownファイルなど）を自動で探索し、25の具体的なチェックを実行してスコアを返す。内部アクセスや認証情報は不要で、エージェントが実際に見える公開情報だけを対象にする。

スコアは上から「Agent-Optimized」「AI-Ready」「Advancing」「Building」「Emerging」「Not AI-Ready」の6段階。pass/failではなくグラデーションなので、スコアがそのままロードマップになる。

評価の5カテゴリは次のとおりだ。

1. API Design：スキーマが型付きで完備されているか、バージョン管理されているか、認証が機械可読な形で宣言されているか。エージェントのfunction-callingはここが土台になる。

2. Developer Experience：ポータル、クイックスタート、コードサンプル。人間がまだ選定・保守を行うため引き続き重要で、エージェントの初回コール成功にも直結する。

3. Agent Discovery：エージェントがAPIを発見できるか。llms.txtの存在、MCPおよびパッケージレジストリへの登録、ログイン不要でアクセスできるドキュメント。

4. Agent Understanding：エージェントがAPIを正しく解釈できるか。RFC 9457形式のエラー、明確なオペレーション説明、仕様・ドキュメント・SDK間の記述一貫性。仕様とドキュメントで同じエンドポイントの説明が微妙に異なると、エージェントは「どちらが正しいか」を推測することになる。

5. Agent Usability：実際の呼び出しが安全に機能するか。冪等性の明記（エージェントのリトライで二重課金を防ぐ）、レートリミットヘッダー、一貫したページネーション、サンドボックス環境。このカテゴリが最も高いウェイトを持つ。

スコアの設計で面白いのは、単一のAPI仕様ファイルを過度に重視しない点だ。Anthropicのように「優れたドキュメント・成熟したSDK・CLIはあるが公開仕様はない」APIも、エージェントにとっては十分に使いやすい。そのためスコアは、複数のサーフェス全体で「最も強いエビデンス」を採用する。仕様がなくてもSDKで証明できれば評価される。

ギャップを埋めるためのツール

スコアが出たあとの改善は、APIサーフェスごとに分解できる。

Postmanのガバナンス機能はAPI仕様をリントし、CIで一貫したルールを強制する。仕様を修正すれば、そこから生成されるドキュメント・SDK・CLIのすべてが連動して改善される。

仕様から各サーフェスを自動生成するツールとして、PostmanはFernとの連携を提供している。FernはPostmanのパートナー・統合ツールとして位置づけられており、デフォルトでllms.txtを出力するドキュメント、9言語対応のSDK、エージェント向けのJSON出力モードを持つCLIを一つの仕様から生成できる。

Claude Code、Cursor、Codexといったコーディングエージェントは、Postmanのパブリックワークスペースから仕様・サンプル・テストを直接取得できる。モックサーバーとサンドボックスは、エージェントが本番に影響を与えず試行できる環境を提供する。

自分のAPIのスコアはpostman.com/ai/ai-ready-apisから確認できる。詳細はAI-Ready APIs: Agents Are the New Audienceを参照していただきたい。