AI時代のAPIファースト開発

LLMの普及によりアプリケーションへのAI導入が活発になっている一方で、APIの重要性がこれまで以上に高まっています。本講演では、AIの手足として機能するための「AI-Ready」なAPIが求められている中、有用な指針となる「APIファースト」開発のコンセプトを振り返るとともに、AI特有の考慮ポイントも合わせて解説します。2025年12月22日発売の書籍「APIファースト Postmanで学ぶ効率的かつ柔軟な開発アプローチ」（川崎 庸市・草薙 昭彦 著、翔泳社）のエッセンスも凝縮してお話しします。Developers Summit 2026での発表資料です。

Transcript

1. All rights reserved by Postman Inc 草薙 昭彦 テクノロジーエバンジェリスト AI 時代の API ファースト開発 #devsumi
2. テクノロジーエバンジェリスト Postman 株式会社 草薙 昭彦 @postman_japan @nagix
3. 本日のトピック • ソフトウェアの価値が転換する • AI-Ready な API：仕様とテストの両輪 • コンセプトを振り返る：なぜ今「API ファースト」なのか • Postman：AI 時代の資産を構築するプラットフォーム • 結びに代えて @postman_japan
4. ソフトウェアの価値が 転換する @postman_japan
5. 2026年、私たちが目撃している「 UI の死」 @postman_japan ヘッドレス SaaS の時代？ SaaS の価値は「使い勝手」から「接続性」へ ユーザーは画面を操作せず AI エージェントに目的を伝える
6. ソフトウェア市場の主役が人間から AI へ 2030年にはソフトウェア市場の利 益の 60% 以上を AI エージェント が占める @postman_japan 参考: 大手金融機関によるソフトウェア市場予測（ 2024） “ “ 大規模言語モデル（ LLM）は、AI エージェントを介してワークフロー や API と接続する
7. 実装は安価になり、使い捨てられる • AI によってコード生成が極限まで高速化した結果、 苦労して書いた実装コードそのものの希少価値は低下した @postman_japan
8. 仕様はガードレールにならない @postman_japan 仕様を形にすることも重要だが、そ れはエージェントに対するガード レール（強制力）にはならない
9. テストコードの価値が「跳ね上がる」 @postman_japan 実装に価値はなくなるが、テスト コードさえあれば理論上その仕様 を再現できる テストこそが唯一の資産 になる時 代
10. AI-Ready な API： 仕様とテストの両輪 @postman_japan
11. AI エージェントを制御する二つの鍵 • 仕様（Spec）： AI に「何をすべきか」を正しく伝える地図 • テスト（Test）： AI が「正しく動いているか」を保証するガードレール @postman_japan
12. AI エージェントの行動モデルと統計的な制約 • ReAct (Reasoning and Acting) 行動モデル ◦ 目標とコンテキストから出発し、推論と行動を繰り返して達成に向かう • 動作は統計的・確率的 。コンテキストウィンドウという記憶の限界 LLM（頭脳） - 推論 - 計画立案 AI エージェント - LLM に問い合わせ - 外部ツール実行 - コンテキスト管理 インプット アウトプット @postman_japan
13. API は AI 時代の最適な抽象化レイヤー • API は、中身の複雑さを隠蔽し、AI が理解し やすいサイズにパッケージングされた「知能の ための手足」である • AI は API を部品として扱うことで、コンテキス トウィンドウの制約を回避し、より複雑なシステ ムの構築が可能になる • 開発者の仕事は低レイヤーの実装から高レイ ヤーの境界設計へシフトする @postman_japan 境界としての API 複雑なサービス実装 AI の意図 AI エージェント or AI 生成実装
14. AI-Ready な API 設計の考慮ポイント • 機械可読な標準仕様の採用 • 型情報やスキーマ構造の明確化 • 一貫性のある設計 • セマンティックな命名 • 説明やメタデータの充実 @postman_japan API コントラクト API 提供者 API 利用者 API リクエスト 参照 参照 API レスポンス OpenAPI 型 意味 OpenAPI 仕様の例：上の要素を備えた API 仕様は AI に明確なコンテキストを提供する MCP (Model Context Protocol) はさらに AI に最適化したプロトコル
15. 非決定的な AI を、決定的な仕様とテストで制御する • 曖昧な仕様をテストケースで縛ることで、AI エージェントおよび AI が生成した実装 の誤操作を論理的に遮断する @postman_japan API クライアント側 自動テストのロジック（コード） を用意し、AI の出力が期待通 りかを常に検証するガード レールを作る。 API サーバー側 仕様に基づいた厳格なバリ デーションを行う。仕様にない 値が来たら、即座にエラーと 詳細な修正ヒントを返す。
16. 資産としてのテストシナリオ • 複雑なビジネスロジックをテストシナリオとして記述し、AIに「これを通せ」と命じる開 発スタイル @postman_japan
17. AI-Ready API の再定義 • 「型（厳密性）」 「意味（セマンティクス）」「テスト （信頼性）」 が揃って初めて、AI は API を使 える @postman_japan 型 （厳密性） 意味 （セマンティクス） テスト （信頼性） AI-Ready
18. コンセプトを振り返る： なぜ今「APIファースト」 なのか @postman_japan
19. API ファーストの二つの側面 @postman_japan 開発アプローチ 実装より先に設計し、 API を「真実のソース」とする ビジネス戦略 API を機能の提供手段ではなく、 価値を生むプロダクトとして扱う
20. API 仕様作成 モック作成 テスト作成 ドキュメント作成 API 実装 コーディング テスト API 統合 フィードバック 仮説検証 API 設計 API ファースト開発アプローチ • 実装の前にフィードバックループを回して仕様を洗練させる • 合意された仕様をもとに、実装、テストを独立・並行に進める @postman_japan
21. API-as-a-Product（製品としての API） • UI が消える世界では、外部（AI エージェ ント）があなたの会社を評価する唯一の 接点は API ◦ API が使いにくい＝プロダクトが存 在しないのと同じ ◦ API を製品として磨くことが、AI 時 代のマーケティングであり、ビジネス 戦略になる @postman_japan
22. 実装（How）から設計（ What）へ • 実装（コード）は AI が生成できる。人間が担うべきは「何を提供するか」というプロダ クトとしての定義（仕様とテスト） @postman_japan
23. Postman：AI 時代の資産を 構築するプラットフォーム @postman_japan
24. Postman - AI 時代の資産「テストと仕様」の管理基盤 @postman_japan 標準化 ↑ （API 再利用の向上、 ドキュメントの標準化、テスト 自動化） API 機能障害 ↓ （ドキュメントの標準化、テス ト自動化、 ワークフロー効率化） 開発生産性 ↑ （仕様の再利用、 環境の標準化、API コレクションの共有） 統合 API 管理プラットフォーム 仕様設計 テスト ガバナンス CI/CD 標準化された API ライフサイクルと変更管理
25. 【設計】AI が理解可能な高精細な API 仕様の作成 • 機械にも人間にも伝わる、最適な説明（description）やサンプル（example）を含む 仕様の編集と管理 @postman_japan SpecHub：ビジュアルな API 仕様編集・管理ツール
26. 【検証】AI のガードレールとしてのガバナンス • セキュリティや一貫性が保たれているかを Linting で常に自動検証 @postman_japan 豊富なビルトインガバナンスルール カスタムルールの定義も可能 開発者が自律的にガバナンス状況を意識す る
27. 【テスト】資産としてのテストコレクション • 仕様からテストスクリプトを自動生成 • AI エージェントの動作の不確実さを許さない強固な API を作る @postman_japan テストシナリオの管理 AI がテストを生成
28. 【共有】AI エージェントへの接続 • Postman に蓄積された「テスト済みの API 知見」を AI エージェントに直接受け渡 す @postman_japan Agent Mode：Postman に 組み込まれたエージェントに よる作業の自律実行 Postman プラットフォーム AI エージェント MCP 外部の AI エージェントによる Postman API 資産の活用 ファイル & ディレクトリ ファイルアクセス API 資産の同期
29. デモ：AI-Ready な API 開発フロー @postman_japan
30. 結びに代えて @postman_japan
31. 実装者から「境界の設計者」へ • コードを書く苦労から解放され、より本質的な価値の定義（仕様とテスト）に集中す る • 私たちの役割は、AI という巨大な力を、API という契約（仕様とテスト）で導くこと @postman_japan
32. まとめ • UI が消える世界で、API は製品そのものになる • AI 時代、実装の価値は下がっても「仕様とテスト」は資産として残り続ける • Postman で、AI を制御し、価値を創出する API 開発を @postman_japan
33. 本を書きました @postman_japan
34. API ファースト開発アプローチについて学べる書籍 https://amzn.asia/d/0SdTMlO @postman_japan
35. ありがとうございました @postman_japan