Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIがAPIを書く時代に、私たちは何を設計すべきか

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

 AIがAPIを書く時代に、私たちは何を設計すべきか

コーディングエージェントによってAPIの設計・実装・テスト生成までが高速化する一方で、生成されたAPIをチームでどう信頼し、壊さず、再利用可能に保つかが新たな課題になっています。本セッションでは、APIを単なる実装対象ではなく、AIエージェントと人間が共有する「実行可能な契約」と捉え、OpenAPI、テスト、モック、認証、Git/CI、監視、カタログをどう設計すべきかを整理します。最後に、AIが速く作り、人間とプラットフォームが検証し、チームが安全にスケールさせるためのAI-Ready APIの設計原則と実践パターンを紹介します。AI駆動開発カンファレンス 2026夏での発表資料です。

Avatar for 草薙昭彦

草薙昭彦

July 30, 2026

More Decks by 草薙昭彦

Other Decks in Technology

Transcript

  1. AI が API を書く時代に、 私たちは何を設計すべきか AI 駆動開発 × API —

    契約・検証・統治という人間の仕事 草薙 昭彦 テクノロジーエバンジェリスト All rights reserved by Postman Inc
  2. はじめに 私は Postman の人間です 01 最後の5分は Postman プラットフォームをご紹介します 02 最初の35分は

    どのツールを使う人にも役立つ話をします 今日、1つだけ持ち帰るなら AI が書くほど、契約の設計・検証・統治が希少スキルになる @postman_japan
  3. キーノートでは「コーディングの終わり」が語られた Cognition AI Anysphere GitHub コーディングの終わりと、 ソフトウェア開発の始まり Building Your Own

    Software Factory 2億人の開発者と、 エージェントの時代 では、人間の仕事は何が残るのか? @postman_japan
  4. 残るのは「契約」を決める仕事 Andrej Karpathy — Software 3.0 すべての製品判断に、いまや “人間版ˮ と “エージェント版

    ˮ の 2つがある。 エージェントネイティブな製品の特徴 Markdown ドキュメント CLI と API MCP サーバー 機械可読なスキーマ Sequoia Ascent 2026 @postman_japan
  5. 「人間に読める API」と「エージェントが使える API」は違う 人 人間には読める API AI エージェントが使える API •

    README 中心 • OpenAPI/機械可読スキーマ • 暗黙知に依存 • Examples とエラースキーマ • 分からなければ Slack で聞く • Auth スコープが明示 • サンプル不足でも補完できる • 契約テストが付随 曖昧さを人間は経験で埋める。エージェントは埋めない。だから明確さ・一貫性・良いエラーはより重要になる。 @postman_japan
  6. 見たことありませんか 雑な API(半分は HTTP ステータス、半分は200+本文にエラー)に、エージェントが挑む agent-session.log › 試行 1 ステータスコードでエラー判定

    → ある呼び出しで壊れる FAIL › 試行 2 本文のエラー解析を追加 → 別の200レスポンスで過剰修正 FAIL › 試行 3 両方に対応するハックを継ぎ足す→ やっと通る PASS 人間なら一度で気づく食い違いが、エージェントでは “リトライとトークン浪費のループ ˮ になる @postman_japan
  7. 正直、こう思っていませんか? “ モデルが賢くなれば、 API 設計 の重要性は下がるのでは? ✓ “ MCP やエージェントがあれば、

    API 管理ツールは要らないので は? “ 別ツールを起動して書いて保存 … それ、手間では? その通りです 単一リポジトリ・コードレベルの単体/結合テストは、コードの隣( pytest/vitest)が正解。個人〜少人数・1リ ポジトリなら、エージェント+Git で十分。プラットフォームはむしろ過剰です。 @postman_japan
  8. でも、現場のデータはこう言っている 89 24 % ↔ 開発者が AI を使っている AI エージェント向けに

    API を設計している = AI 活用の速度に、 API 設計と統治が追いついていない 出典: Postman 2025 State of the API(5,700名調査) @postman_japan % 51% が「無認可・過剰なエー ジェントの API 呼び出し」 を最大の懸念に
  9. その直感が壊れる2つの理由 理由 1 / 規模 数百回 理由 2 / 学習カットオフ

    /セッション 8090 /100 人間は API とたまに接する。エージェントは1セッ ションで数百回叩く。設計の乱れがリトライ・トークン 浪費・回避策として急速に累積する。 LLM は学習時点で凍結。ライブラリは破壊的変更 で進化 → 呼ぶ API が、入っているバージョンに存 在しない。主要3 SDK でこのスコア、新メジャー直 後が最悪。 DORA: AI は既存能力を “増幅 ˮ する。自動では解決しない。 出典:SDKProof 2026 / DEV・AWS 2026 / DORA 2025 @postman_japan
  10. だから、握るべきは3つ 1 2 3 契約 検証 統治 Contract Verification Governance

    仕様・スキーマを 単一の真実に 契約テスト・実行可能 テストを CI に 誰が所有し、テスト・監視 されているかを一覧に = AI 駆動開発で「人間が設計する対象」。ここから先は、この3つのキーワードで進みます。 @postman_japan
  11. 契約 API を “実行可能な契約 ˮ にする 仕様が、生成・検証・実行の起点になる Executable API Contract

    Spec Tests Mock Contract test SDK MCP tool Docs CI 検証 2つの仕様 OpenAPI API 構造を表現 Arazzo 複数 API 呼び出しのワークフロー を表現 これは古くからの議論のテーマ。 2002 Bezos API Mandate(全機能をインターフェースで公開)/Vogels:実装 が漏れると利用者が内部実装に依存し変更できなくなる(Hyrum の法則)。 @postman_japan
  12. 検証 研究はここまで来た、なのに現場は ── AI による API の生成・検証(先端研究) OOPS (arXiv, 2026

    ソースから OpenAPI を LLM 生成 エンドポイント推論 F1 98%超 LlamaRestTest IBM, ICSE'25 小型量子化 Llama で現実的なテスト入力+依存を生成 現場の契約テスト実施率 17 % Vilnius Univ. 202526 自然言語要件 → 実行可能な pytest (全エンドポイント到達) @postman_japan 研究と現場のギャップこそ、いま埋めるべき場所
  13. 統治への橋 MCP は APIを消さない、 API を “ツール化 ˮ する API

    MCP Tool AI Agent Bad API → Bad Tool Good API → Reliable Tool 雑な契約は、そのまま壊れやすいツールになる API 資産の品質が、そのままツール品質になる MCP 認知 70% ・ 常用 10%(Postman 2025 State of the API)= まだ整備の余地 @postman_japan
  14. 統治が決める 成否を分けるのは「野心」ではなく「統治」 1114% エンタープライズのエージェント AI パイロットで、本番 に到達する割合 出典: The Agentics

    “Enterprise MCP Guide 2026ˮ @postman_japan 実験にとどまってしまう理由 アイデンティティのギャップ 監査証跡の欠如 アクセス制御の不備 しかも規制:EU AI Act の高リスク条項は 20260802 施行、 連鎖する各エージェントまで適合境界が及ぶ
  15. 契約と権限を設計したから、本番に乗った 社内/ Block 75% 外部/ Shopify 約13 のエンジニアが 週810h+ を節約

    goose × 社内 API の MCP 化(12,000人・15職 種)。全 MCP 内製、ツールを“読み取り専用/破壊 的ˮで注釈、権限を設計。 同じ方向: @postman_japan Bloomberg(本番投入 数日 →数分) AI 検索経由の注文(前年比) Storefront MCP を GA。作法は「読み取り専用で 始め、書き込みをツール単位で段階解放」。 Stripe PayPal Agoda
  16. AI Is Powered by APIs. APIs Are Powered by Postman.

    Trusted 4,000万 開発者 Complete 98% Fortune 500 企業 Connected 3億 トランザクション /日 9/10 日常的に使うアプリ Secure 100万 Postman Network 上にある API
  17. その “手間ˮ は、もう別物になっている 争点は「GUI か Git か」ではない。 この契約は “1リポジトリの私的資産 ˮ

    か、“組織の共有契約ˮ か。 your-service/ src/ .postman/ collections.yaml スペック・コレクション・環境・モック・テストが、コードの隣 の YAML として同居 差分が見え、同じ Pull Request でレビューされる openapi.yaml environments.yaml CLI で、ローカルも CI も同じ資産を実行 tests.yaml mocks.yaml @postman_japan Agent Mode が読み書きする
  18. 設計すべきは4つのレイヤー Build-time API 契約 — 仕様とテスト Access-time API アクセス権 Runtime

    AI トラフィック制御 Team-time エージェント運用 @postman_japan Native Git ・ API Catalog Passport(early access) Fabric Gateway(early access) (beta)
  19. エージェントに “鍵ˮ を渡す危険 Postman Passport ⚠ 今:本物の API キーを配る 約8

    箇所 / 台 に複製(GitGuardian) .env IDE 設定 CI キャッシュ ドキュメント Slack 鍵に直接触れ、外部通信もできる= Simon Willison「lethal trifecta」 @postman_japan これから:アクセスを付与する 本物のキーの代わりに 資格情報リファレンス(保持者 に暗号的に束ねられ、他人が使えば無意味) Agent Proxy VPC Vault 鍵は vault から出ない。エージェントが別エージェ ントを生む時は、権限の“厳格な部分集合ˮを短命 identity で引き継ぐ。
  20. Postman の顧客でも、規律は成果を出している 96h → 56h 2週間スプリントのテスト時間 時間 → 分 Time

    to First Call(最初の疎通までの時間) 69週 → 24週 機能リードタイム 4h → 1h 複数チームのテスト 100% の開発者が「協働が向上した」 適応的ガバナンス + CLI リンティングを CI に組み込み コントラクトベースの並行開発 + Newman + モック ※ いずれも AI以前からの “API-first + テスト/ガバナンスˮ の実測値。 @postman_japan
  21. 明日からできること 製品に依存しない、どのツールを使う人にも効く6つ ✓ API をエージェント向けに設計(明確なエラー・一貫した命名/意味論・機械可読スキーマ) ✓ /llms.txt ・ AGENTS.md を置く

    ✓ 契約テストを CI に組み込む(人間もエージェントも同じ検証) ✓ 書き込みは read-only → 段階解放 ✓ 「誰が所有し、テスト・監視されているか」を一覧化 ✓ シークレットは配らず、“アクセスを付与するˮ 発想へ @postman_japan
  22. 参考文献・出典 • Karpathy “Software 3.0ˮ / Sequoia Ascent 2026 •

    OpenAPI / Arazzo Specification • Apideck “API Design Principles for the Agentic Eraˮ 2026 • Anthropic “Introducing the Model Context Protocolˮ • The New Stack “Build APIs for AIˮ 2025 • Bezos API Mandate(2002)/ Vogels, AWS re:Invent 2021 • DORA 2025 State of AI-assisted Software Dev(Google) • Postman 2025 State of the API(89/24・契約テスト 17%・51%・MCP 70/10) • DEV/AWS “AI Agents Are Your API's Biggest Consumerˮ 2026 • The Agentics “Enterprise MCP Guide 2026ˮ • SDKProof 2026 • Block × goose / Shopify Q1 2026 earnings / Bloomberg MCP • OOPS(arXiv:2601.12735, 2026) • Postman Customer Stories:WGU / TotalEnergies • LlamaRestTest(IBM, ICSE'25)/ Vilnius University 202526 • GitGuardian “State of Secrets Sprawl 2026ˮ / Simon Willison “The lethal trifectaˮ 2025 • Postman v12 / Passport EA / Fabric Gateway EA / Astro AI (beta)