AI が API を書く時代に、 私たちは何を設計すべきか AI 駆動開発 × API — 契約・検証・統治という人間の仕事 草薙 昭彦 テクノロジーエバンジェリスト All rights reserved by Postman Inc 

草薙 昭彦 テクノロジーエバンジェリスト Postman 株式会社 @nagix @postman_japan 

はじめに 私は Postman の人間です 01 最後の5分は Postman プラットフォームをご紹介します 02 最初の35分は どのツールを使う人にも役立つ話をします 今日、１つだけ持ち帰るなら AI が書くほど、契約の設計・検証・統治が希少スキルになる @postman_japan 

キーノートでは「コーディングの終わり」が語られた Cognition AI Anysphere GitHub コーディングの終わりと、 ソフトウェア開発の始まり Building Your Own Software Factory 2億人の開発者と、 エージェントの時代 では、人間の仕事は何が残るのか？ @postman_japan 

残るのは「契約」を決める仕事 Andrej Karpathy — Software 3.0 すべての製品判断に、いまや “人間版ˮ と “エージェント版 ˮ の 2つがある。 エージェントネイティブな製品の特徴 Markdown ドキュメント CLI と API MCP サーバー 機械可読なスキーマ Sequoia Ascent 2026 @postman_japan 

「人間に読める API」と「エージェントが使える API」は違う 人 人間には読める API AI エージェントが使える API • README 中心 • OpenAPI／機械可読スキーマ • 暗黙知に依存 • Examples とエラースキーマ • 分からなければ Slack で聞く • Auth スコープが明示 • サンプル不足でも補完できる • 契約テストが付随 曖昧さを人間は経験で埋める。エージェントは埋めない。だから明確さ・一貫性・良いエラーはより重要になる。 @postman_japan 

見たことありませんか 雑な API（半分は HTTP ステータス、半分は200＋本文にエラー）に、エージェントが挑む agent-session.log › 試行 1 ステータスコードでエラー判定 → ある呼び出しで壊れる FAIL › 試行 2 本文のエラー解析を追加 → 別の200レスポンスで過剰修正 FAIL › 試行 3 両方に対応するハックを継ぎ足す→ やっと通る PASS 人間なら一度で気づく食い違いが、エージェントでは “リトライとトークン浪費のループ ˮ になる @postman_japan 

正直、こう思っていませんか？ “ モデルが賢くなれば、 API 設計 の重要性は下がるのでは？ ✓ “ MCP やエージェントがあれば、 API 管理ツールは要らないので は？ “ 別ツールを起動して書いて保存 … それ、手間では？ その通りです 単一リポジトリ・コードレベルの単体／結合テストは、コードの隣（ pytest/vitest）が正解。個人〜少人数・１リ ポジトリなら、エージェント＋Git で十分。プラットフォームはむしろ過剰です。 @postman_japan 

でも、現場のデータはこう言っている 89 24 % ↔ 開発者が AI を使っている AI エージェント向けに API を設計している ＝ AI 活用の速度に、 API 設計と統治が追いついていない 出典： Postman 2025 State of the API（5,700名調査） @postman_japan % 51% が「無認可・過剰なエー ジェントの API 呼び出し」 を最大の懸念に 

その直感が壊れる２つの理由 理由 1 ／ 規模 数百回 理由 2 ／ 学習カットオフ ／セッション 8090 ／100 人間は API とたまに接する。エージェントは１セッ ションで数百回叩く。設計の乱れがリトライ・トークン 浪費・回避策として急速に累積する。 LLM は学習時点で凍結。ライブラリは破壊的変更 で進化 → 呼ぶ API が、入っているバージョンに存 在しない。主要3 SDK でこのスコア、新メジャー直 後が最悪。 DORA： AI は既存能力を “増幅 ˮ する。自動では解決しない。 出典：SDKProof 2026 / DEV・AWS 2026 / DORA 2025 @postman_japan 

だから、握るべきは３つ 1 2 3 契約 検証 統治 Contract Verification Governance 仕様・スキーマを 単一の真実に 契約テスト・実行可能 テストを CI に 誰が所有し、テスト・監視 されているかを一覧に ＝ AI 駆動開発で「人間が設計する対象」。ここから先は、この３つのキーワードで進みます。 @postman_japan 

契約 API を “実行可能な契約 ˮ にする 仕様が、生成・検証・実行の起点になる Executable API Contract Spec Tests Mock Contract test SDK MCP tool Docs CI 検証 ２つの仕様 OpenAPI API 構造を表現 Arazzo 複数 API 呼び出しのワークフロー を表現 これは古くからの議論のテーマ。 2002 Bezos API Mandate（全機能をインターフェースで公開）／Vogels：実装 が漏れると利用者が内部実装に依存し変更できなくなる（Hyrum の法則）。 @postman_japan 

検証 研究はここまで来た、なのに現場は ── AI による API の生成・検証（先端研究） OOPS (arXiv, 2026 ソースから OpenAPI を LLM 生成 エンドポイント推論 F1 98%超 LlamaRestTest IBM, ICSE'25 小型量子化 Llama で現実的なテスト入力＋依存を生成 現場の契約テスト実施率 17 % Vilnius Univ. 202526 自然言語要件 → 実行可能な pytest （全エンドポイント到達） @postman_japan 研究と現場のギャップこそ、いま埋めるべき場所 

統治への橋 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 

統治が決める 成否を分けるのは「野心」ではなく「統治」 1114% エンタープライズのエージェント AI パイロットで、本番 に到達する割合 出典： The Agentics “Enterprise MCP Guide 2026ˮ @postman_japan 実験にとどまってしまう理由 アイデンティティのギャップ 監査証跡の欠如 アクセス制御の不備 しかも規制：EU AI Act の高リスク条項は 20260802 施行、 連鎖する各エージェントまで適合境界が及ぶ 

契約と権限を設計したから、本番に乗った 社内／ Block 75% 外部／ Shopify 約13 のエンジニアが 週810h+ を節約 goose × 社内 API の MCP 化（12,000人・15職 種）。全 MCP 内製、ツールを“読み取り専用／破壊 的ˮで注釈、権限を設計。 同じ方向： @postman_japan Bloomberg（本番投入 数日 →数分） AI 検索経由の注文（前年比） Storefront MCP を GA。作法は「読み取り専用で 始め、書き込みをツール単位で段階解放」。 Stripe PayPal Agoda 

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 

その “手間ˮ は、もう別物になっている 争点は「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 が読み書きする 

設計すべきは４つのレイヤー Build-time API 契約 — 仕様とテスト Access-time API アクセス権 Runtime AI トラフィック制御 Team-time エージェント運用 @postman_japan Native Git ・ API Catalog Passport（early access） Fabric Gateway（early access） （beta） 

エージェントに “鍵ˮ を渡す危険 Postman Passport ⚠ 今：本物の API キーを配る 約8 箇所 / 台 に複製（GitGuardian） .env IDE 設定 CI キャッシュ ドキュメント Slack 鍵に直接触れ、外部通信もできる= Simon Willison「lethal trifecta」 @postman_japan これから：アクセスを付与する 本物のキーの代わりに 資格情報リファレンス（保持者 に暗号的に束ねられ、他人が使えば無意味） Agent Proxy VPC Vault 鍵は vault から出ない。エージェントが別エージェ ントを生む時は、権限の“厳格な部分集合ˮを短命 identity で引き継ぐ。 

Postman の顧客でも、規律は成果を出している 96h → 56h 2週間スプリントのテスト時間 時間 → 分 Time to First Call（最初の疎通までの時間） 69週 → 24週 機能リードタイム 4h → 1h 複数チームのテスト 100% の開発者が「協働が向上した」 適応的ガバナンス ＋ CLI リンティングを CI に組み込み コントラクトベースの並行開発 ＋ Newman ＋ モック ※ いずれも AI以前からの “API-first ＋ テスト/ガバナンスˮ の実測値。 @postman_japan 

明日からできること 製品に依存しない、どのツールを使う人にも効く６つ ✓ API をエージェント向けに設計（明確なエラー・一貫した命名／意味論・機械可読スキーマ） ✓ /llms.txt ・ AGENTS.md を置く ✓ 契約テストを CI に組み込む（人間もエージェントも同じ検証） ✓ 書き込みは read-only → 段階解放 ✓ 「誰が所有し、テスト・監視されているか」を一覧化 ✓ シークレットは配らず、“アクセスを付与するˮ 発想へ @postman_japan 

AI が書く。あなたは、契約を設計する。 価値は「書く」から「決める・検証する・統治する」へ移った。それは小さくなった仕事ではない。それが、仕事そのもの になった。 では人間は何を？ 契約を設計し、ランタイムまで統治する ── 契約・検証・統治 @postman_japan 

ありがとうございました @postman_japan 

参考文献・出典 • 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)