AI に書かせたその API、 “信頼” できますか？

AIがAPIを書く時代、生成は一瞬で終わるようになりました。しかし「壊れないか」「エージェントが正しく使えるか」「誰が責任を持つのか」を決める仕事は、むしろ人間に残された希少なスキルになっています。一人の開発から組織の本番運用まで地続きで効く「契約・検証・統治」の考え方と、それをPostmanでどう実装するかを、具体例とデモを交えてお話しします。Developers Summit 2026 FUKUOKAでの発表資料です。

Transcript

1. AI に書かせたその API、 “信頼ˮ できますか？ 個人開発から本番まで通じる契約・検証・統治 草薙 昭彦 テクノロジーエバンジェリスト All rights reserved by Postman Inc
2. 草薙 昭彦 テクノロジーエバンジェリスト Postman 株式会社 @nagix @postman_japan
3. はじめに 私は Postman の人間です 後半は Postman プラットフォームをご紹介します 前半は どのツールを使う人にも役立つ話をします 今日、１つだけ持ち帰るなら AI が書くほど、契約の設計・検証・統治が希少スキルになる @postman_japan
4. 「人間に読める API」と「エージェントが使える API」は違う 人間には読める API エージェントが使える API ⚠ README 中心 ✅ OpenAPI／機械可読スキーマ ⚠ 暗黙知に依存 ✅ Examples とエラースキーマ ⚠ 分からなければ Slack で聞く ✅ Auth スコープが明示 ⚠ サンプル不足でも補完できる ✅ 契約テストが付随 曖昧さを人間は経験で埋める。エージェントは埋めない。したがって、明確さ・一貫性・良いエラーはより重要になる。 @postman_japan
5. 見たことありませんか 雑な API（半分は HTTP ステータス、半分は200＋本文にエラー）に、エージェントが接続を試みる agent-session.log › 試行 1 ステータスコードでエラー判定 → ある呼び出しで動作がおかしくなる FAIL › 試行 2 本文のエラー解析を追加 → 別の200レスポンスで過剰修正 FAIL › 試行 3 両方に対応するハックを継ぎ足す→ やっと動作するようになる PASS 人間なら一度で気づく食い違いが、エージェントでは “リトライとトークン浪費のループ ˮ になる @postman_japan
6. 正直、こう思っていませんか？ “ モデルが賢くなれば、 API 設計 の重要性は下がるのでは？ ✓ “ MCP やエージェントがあれば、 API 管理ツールは要らないので は？ “ 別ツールを起動して書いて保存 … それ、手間では？ その通りです 単一リポジトリ・コードレベルの単体／結合テストは、コードの隣（ pytest/vitest）が正解。個人〜少人数・１リ ポジトリなら、エージェント＋Git で十分。プラットフォームはむしろ過剰 @postman_japan
7. でも、現場のデータはこう言っている 89 24 % ↔ 開発者が AI を使っている % AI エージェント向けに API を設計している ＝ AI 活用の速度に、 API 設計と統治が追いついていない 出典： Postman 2025 State of the API（5,700名調査） @postman_japan 51% が「無認可・過剰なエー ジェントの API 呼び出し」 を最大の懸念に
8. その直感が壊れる２つの理由 理由 1 ／ 規模 数百回 理由 2 ／ 学習カットオフ ／セッション 8090 ／100 人間は API とたまに接する。エージェントは１セッ ションで数百回叩く。設計の乱れがリトライ・トークン 浪費・回避策として急速に累積する。 LLM は学習時点で凍結。ライブラリは破壊的変更 で進化 → 呼ぶ API が、入っているバージョンに存 在しない。主要3 SDK でこのスコア、新メジャー直 後が最悪。 DORA： AI は既存能力を “増幅 ˮ する。自動では解決しない。 出典：SDKProof 2026 / DEV・AWS 2026 / DORA 2025 @postman_japan
9. 握るべきは３つ 契約 検証 統治 Contract Verification Governance 仕様・スキーマを 単一の真実に 契約テスト・実行可能 テストを CI に 誰が所有し、テスト・監視 されているかを一覧に ＝ AI 駆動開発で「人間が設計する対象」 @postman_japan
10. AI Is Powered by APIs. APIs Are Powered by Postman. Trusted 4,500万 開発者 Complete 98% Fortune 500 企業 Connected 3億 トランザクション /日 9/10 日常的に使うアプリ Secure 100万 Postman Network 上にある API
11. その手間は、もう別物になっている 争点は「GUI か Git か」ではない。 この契約は「１リポジトリの私的資産」か、「組織の共有契約」か。 your-service/ src/ .postman/ collections.yaml スペック・コレクション・環境・モック・テストが、コードの隣 の YAML として同居 差分が見え、同じ Pull Request でレビューされる openapi.yaml environments.yaml CLI で、ローカルも CI も同じ資産を実行 tests.yaml mocks.yaml @postman_japan Agent Mode が読み書きする
12. 設計すべきは４つのレイヤー Build-time API 契約 — 仕様とテスト Access-time API アクセス権 Runtime AI トラフィック制御 Team-time エージェント運用 @postman_japan Native Git API Catalog Passport（early access） Fabric Gateway（early access） （beta）
13. エージェントに鍵を渡す危険 Postman Passport ⚠ 今：本物の API キーを配る 約8 箇所 / 台 に複製（GitGuardian） .env IDE 設定 CI キャッシュ ドキュメント 鍵に直接触れ、外部通信もできる = Simon Willison「lethal trifecta」 @postman_japan Slack これから：アクセスを付与する 本物のキーの代わりに 資格情報リファレンス（保持者 に暗号的に束ねられ、他人が使えば無意味） Agent Proxy VPC Vault 鍵は vault から出ない。エージェントが別エージェ ントを生む時は、権限の“厳格な部分集合ˮを短命 identity で引き継ぐ。
14. 【デモ】自然言語から、契約・検証・統治まで
15. 【デモ】自然言語から、契約・検証・統治まで
16. 契約と権限を設計したから、本番に乗った 社内／Block 75% 外部／Shopify 約13 のエンジニアが 週810h+ を節約 goose × 社内 API の MCP 化（12,000人・15職 種）。全 MCP 内製、ツールを“読み取り専用／破壊 的ˮで注釈、権限を設計。 同じ方向： @postman_japan Bloomberg（本番投入 数日 →数分） AI 検索経由の注文（前年比） Storefront MCP を GA。作法は「読み取り専用で 始め、書き込みをツール単位で段階解放」。 Stripe PayPal Agoda
17. 明日からできること 製品に依存しない、どのツールを使う人にも効く６つ ✓ API をエージェント向けに設計（明確なエラー・一貫した命名／意味論・機械可読スキーマ） ✓ /llms.txt ・ AGENTS.md を置く ✓ 契約テストを CI に組み込む（人間もエージェントも同じ検証） ✓ 書き込みは read-only → 段階解放 ✓ 「誰が所有し、テスト・監視されているか」を一覧化 ✓ シークレットは配らず、“アクセスを付与するˮ 発想へ @postman_japan
18. AI が書く。あなたは、契約を設計する。 価値は「書く」から「決める・検証する・統治する」へ移った。それは小さくなった仕事ではない。それが、仕事そのもの になった。 では人間は何を？ 契約を設計し、ランタイムまで統治する ── 契約・検証・統治 @postman_japan
19. ありがとうございました @postman_japan