AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI ​​era

Presentation slides: AI時代の開発品質をどう守るか (Postman x CodeRabbit 共催セミナー ) 2026.09.08
Session title: AI時代のAPI品質を支えるガードレール

Transcript

1. AI時代のAPI品質を 支えるガードレール Postman x CodeRabbit共催セミナー 2026.9.8 川崎庸市 テクノロジーエバンジェリスト
2. 川崎 庸市 / Yoichi Kawasaki テクノロジーエバンジェリスト Postman株式会社 @yokawasa @postman_japan
3. 話すこと • • • • なぜAPIの品質が大切なのか AI時代のAPI品質を支えるガードレール AI時代のAPI品質を支えるPostman まとめ
4. なぜAPIの品質が大切なのか
5. APIとは契約に基づいた責任の境界線 APIとは利用者に責任の受け渡しを行うためのインターフェース（契約） • • 内部実装は入れ替えられる（リファクタ・言語変更・ AIによる再生成） APIは入れ替えられない（利用者が既に依存している） Web / Mobile Partner AI Agent 利用側はインターフェースに依存 Interface API 入れ替え不可（同一バージョンの場合） 契約に基づいた責任の境界線 Business Logic 内部実装は入れ替え可能 Database
6. APIとは契約に基づいた責任の境界線 API（責任の境界線）が分けている境界にはいくつか種類があり、その境界を越える瞬間に責任が移る 境界 APIが分けているもの 組織の境界 開発チーム / QA / ベンダー / 運用 契約の境界 「約束したこと」と「実装したこと」 障害の境界 誰の変更が、誰の障害になったか 信頼の境界 内側は検証済み、外側は検証されていない 境界は責任の受け渡し地点 –「境界で何を保証したか」は組織の説明責任そのもの マイクロサービス、ベンダー委託、パートナー連携——境界が増えるほど検証コストが増える
7. APIとはプロダクトの共通骨格層 • • APIはプロダクト能力を一貫して提供するための 共通の骨格層 接点の品質は、その奥の骨格層（ API）・データ基盤層に強く依存 利用者層 人間ユーザー チャット UI AIエージェント 開発者・システム連携 パートナー・外部開発者 ブラウザ・モバイル ChatGPT・Claude など 自律的にタスク実行 自社システム・iPaaS 外部との連携 接点層 Web UI MCPサーバー CLI （Tools・Resources・Prompts） 開発・運用の自動化 価値の重心 骨格層 （API） SDK／ライブラリ Webhook 通知・リアルタイム連携 プロダクト能力の共通骨格 認証・認可 ビジネスロジック データアクセス ID・権限管理 業務ルール・計算 CRUD・検索 ワークフロー／ オーケストレーション 監査・ログ 可観測性 価値の重心 データ 基盤層 業務データ 顧客・注文・契約 メタデータ／ カタログ 検索インデックス キャッシュ／ セッションストア バックアップ／ リカバリ データガバナンス／ コンプライアンス
8. 補足 API品質の保証ポイント 個別のAPIテストでOKなもものから、ライフサイクル全体での取り組みが必要になるものもある # 保証対象 1 構造 (スキーマ) リクエスト・レスポンスは仕様通りの形か 2 振る舞い 正常系・異常系で期待した結果を返すか 3 契約 (コントラクト) 仕様と実装が一致しているか 4 互換性 バージョンアップなどの変更が既存利用者を壊さないか 5 セキュリティ/ 権限 認証・認可・公開範囲が意図通りか 6 パフォーマンス 目標レイテンシ・スループットを満たしているか 7 継続性 いつでも同じ振る舞いになっているか 問い
9. AI時代のAPI品質を支えるガードレール
10. AIエージェントの3つの性質 AIエージェントは自律的に動く。だが、その振る舞いは確率的で、常に予測できるとは限らない。しかも、人間の 認知を超えて高速・大量に実行される • • • 自律的: 人の判断を介さず動く 確率的: 振る舞いは予測しきれない 高速・大量: 人のレビューが追いつかない AIは「増幅器（amplifier）」。強い組織を強くし、脆い組 織の弱点をあぶり出す。 制御システム（自動テスト・バージョン管理・速いフィー ドバック）がなければ、変更量の増加は そのまま"不安定さ"に直結する。 出典（脚注）： DORA「State of AI-assisted Software Development」2025
11. 必要なのは ガードレール / 逸脱を起こさせない環境 • • 高速道路でドライバー全員を監視する代わりに、ガードレールとセンターラインを引く。 AI開発も同じで、出 力を信じるのではなく、逸脱できない環境を作る この考え方・手法を Harness Engineeringとも呼んでいる ⭕ 逸脱できない環境 ❌ 効かない対策 • • • • レビュー担当を増やす 目視確認 チェックリストの整備 出力制御のためのプロンプト強化
12. 信頼性のあるガードレールに必要な3要素 1. 検証可能な制約 2. 継続的な検証 3. 生成主体から独立した検証
13. 信頼性のあるガードレールに必要な要素 #1 検証可能な制約 要素 テスト 説明・例 期待される振る舞いを定義し、出力の正誤を機械的に判定する 例：ユニットテスト、コントラクトテスト、E2Eテスト リンター 命名・書式・設計ルール違反を機械的に検出し、規約を明文化 例：Spectral（OpenAPI検査）、ESLint、APIスタイルガイド自動チェック 型システム 入出力の構造を事前に制約し、不正な形式を実行前に弾く 例：OpenAPIスキーマ 権限・スコープ 利用者が「できること」の範囲を事前に絞る 例：ポリシー、OAuthスコープ、RBAC レートリミット・クォータ 高速・大量の実行を量の側から制限し、暴走を防ぐ 例：同時実行数の制限
14. 信頼性のあるガードレールに必要な要素 #2 継続的な検証 • • 検証が「一回きり」、「一時的」では意味がない 「継続的に検証できること 」、「その結果を追跡できること 」が大切 要素 CI/CD 説明・例 変更を自動検証し、問題があれば先へ進ませない関門 例：プルリクエスト時の自動テスト実行、デプロイ前のゲートチェック 監視・観測・監査 継続的に環境を検証し、その詳細を後からトレースできる仕組み 例：モニタリング、トレーシング、監査ログ、アラート
15. 信頼性のあるガードレールに必要な要素 #3 生成主体から独立した検証 - なぜ独立が大切？ 検証可能な制約（テスト、リンター、型システム、 etc.）があり、それらを継続的に実施できるからといって、「信頼 できるガードレール」というわけではない 実装とテストを同じ人が生成すると AIは、これらを高速に生成できる。しかし、それら が適正に検証されているわけではない • • • 仕様、ドキュメント 実装 テストコード AIが生成できる ≠ 信頼できる 同じAI / コンテキスト 実装 テスト 生成された振る舞い 生成された期待値 ✅ PASS 同じ誤解を共有していてもPASSする (自分の答案を自分で採点しているのと同じ)
16. 信頼性のあるガードレールに必要な要素 #3 生成主体から独立した検証 組織がそれを信頼できるようにするには、 組織が合意した制約を、生成主体から独立して実行・再利用・追跡で きる仕組み・環境が必要 要件 意味 独立している 実装を書いた AI／人とは別の基準で検証される 再利用できる 開発・QA・ベンダー・運用が同じものを再利用できる 追跡できる いつ・誰が・何を通したかが残っている
17. AI時代のAPI品質を支えるPostman
18. ガードレール一覧 グループ 要素 説明・例 検証可能な制約 テスト 期待される振る舞いを定義し、出力の正誤を機械的に判定する 検証可能な制約 リンター 命名・書式・設計ルール違反を機械的に検出し、規約を明文化 検証可能な制約 型システム 入出力の構造を事前に制約し、不正な形式を実行前に弾く 検証可能な制約 権限・スコープ 利用者が「できること」の範囲を事前に絞る 検証可能な制約 レートリミット・クォータ 高速・大量の実行を量の側から制限し、暴走を防ぐ 継続的な検証 CI/CD 変更を自動検証し、問題があれば先へ進ませない関門 継続的な検証 監視・観測・監査 継続的に環境を検証し、詳細を後からトレースできる仕組み 生成主体から独立 独立している 実装を書いたAI／人とは別の基準で検証される 生成主体から独立 再利用できる 開発・QA・ベンダー・運用が同じものを再利用できる 生成主体から独立 追跡できる いつ・誰が・何を通したかが残っている
19. Postmanはこれら全てを検証または実現可能 グループ 要素 説明・例 検証可能な制約 テスト 期待される振る舞いを定義し、出力の正誤を機械的に判定する ⭕ 検証可能な制約 リンター 命名・書式・設計ルール違反を機械的に検出し、規約を明文化 ⭕ 検証可能な制約 型システム 入出力の構造を事前に制約し、不正な形式を実行前に弾く ⭕ 検証可能な制約 権限・スコープ 利用者が「できること」の範囲を事前に絞る ⭕ 検証可能な制約 レートリミット・クォータ 高速・大量の実行を量の側から制限し、暴走を防ぐ ⭕ 継続的な検証 CI/CD 変更を自動検証し、問題があれば先へ進ませない関門 ⭕ 継続的な検証 監視・観測・監査 継続的に環境を検証し、詳細を後からトレースできる仕組み ⭕ 生成主体から独立 独立している 実装を書いたAI／人とは別の基準で検証される ⭕ 生成主体から独立 再利用できる 開発・QA・ベンダー・運用が同じものを再利用できる ⭕ 生成主体から独立 追跡できる いつ・誰が・何を通したかが残っている ⭕
20. Postman The AI-Native API Platform 組織がAPIを大規模に標準化、 ガバナンス、運用化できるよう にします。 統一された Unified Source of Truth 信頼できる情報源 標準化 ガバナンス Postman powered by AI
21. Postmanとは（ガバナンス観点） APIを、 ライフサイクルSDLCにわたり継続的に検証し、組織として 信頼できるAPIの実現を支援するプラットフォーム
22. SDLCにわたる継続的な検証を実現する仕組み フィードバックループ CI/CDで自動化 設計 開発 テスト デプロイ 監視 アーキテクト、 API プロダクトマネージャー ソフトウェアエンジニア 品質エンジニア DevOps、プラットフォーム エンジニア プラットフォームエンジニア SpecHub による API 仕様 Postman CLI によるコント ラクトテスト AI による仕様作成とガバナンス用 Lintingルール モックサーバー デプロイ前に検証 お好みの IDE で開発し、Linting ルールでマージ前に「破壊的変 更」を検出 コレクションランナー Postman モニター AI エージェントを使い、コントラクト から基本テストの生成を自動化 パブリック API テスト・パフォーマンス レポート モニターランナー ポートフォリオスコアカード ファイアウォール内の内部 API インサイト パフォーマンステスト 固定・ランプ・スパイク・ピーク エージェントモードと AI エンジニア すべての段階で仕様・ルール・テストの生成、異常検知の学習、根本原因の分析、テストの自動修復を行う。 API カタログ ガバナンスルール: Spectral、破壊的変更検知。 トラフィックに基づくギャップ検知
23. 組織が合意した制約を 生成主体から独立した検証を実現できる環境 組織内コラボレーション パートナーコラボレーション 開発・QA・運用者が同じものを扱い、レ ビュー・共同開発・テストを行う パートナー・ベンダーとのレビュー・共同開 発・テスト 検証内容とその結果 チームで共通資産として保存され、再利 用や追跡ができる
24. APIカタログ - 組織全体のAPIの検証状況を可視化 • • 組織のAPI全体の運用・管理状況を見渡せるダッシュボード どのAPIが存在し、その所有者、仕様のガイドライン遵守状況、テスト実施状況、監視状況など、組織全 体のAPIの検証状況を可視化する
25. 補足 検証可能な制約の例 コントラクトテスト ― 仕様と実装の乖離を防ぐ • • APIが合意された「コントラクト」API仕様)通りに振る舞うかを検証するテスト CI/CD経由、モニターによる継続的なコントラクト実行を通じ仕様と実装の乖離を防ぐ 仕様と実装の乖離（APIドリフト）の例 • • • • レスポンス構造の変更 必須フィールドの欠落 型の不整合 ステータスコード、エラーの変更
26. 補足 検証可能な制約の例 リンターでAPIスタイルガイドの自動チェック スタイルガイドの文書作成だけで終わらせず、CIで自動チェックできる状態にする APIスタイルガイド Spectralルール化 リンターで自動チェック 設計原則一覧を文書化 extends: ["spectral:oas"] Postmanのガバナンスルール検証例 ✓ パスは kebab-case 例: /user-profiles rules: path-kebab-case: description: パス命名を統一 severity: error given: $.paths[*]~ then: function: pattern functionOptions: match: "^/[a-z0-9-/{}/]+$" ✓ 全operationにsummary API利用者が意図を読める ✓ エラー形式を統一 code / message / details ✓ 認証方式を明記 security を必須化 ✓ 破壊的変更を検出 version / deprecation operation-summary: severity: warn given: $.paths[*][*] then: field: summary function: truthy 違反箇所を行単位で返す PR前に設計不整合を検出
27. クロージング
28. まとめ • • • • APIの品質が大切 ◦ APIは責任の境界線であり、プロダクトの共通骨格 AIは自律的・確率的・高速。構築を劇的に加速する一方で容易に「逸脱」する ◦ 逸脱を起こさせない環境（ガードレール）が必要 信頼性のあるガードレール（3要素） ◦ 検証可能な制約 ◦ 継続的な検証 ◦ 生成主体から独立した検証 PostmanはAI時代のAPI品質を支えるAPIプラットフォーム ◦ SDLCにわたり継続的に検証し、組織として信頼できるAPIの実現を支援する Create faster with AI. Ship safely with Postman
29. ありがとうございました 本日の内容にご興味をお持ちの方は、お気軽に下記までご連絡ください。 info-jp@postman.com @postman_japan
30. API 最新情報や Postman プラットフォームをもっと知りたい Postman オンライン ワークショップ 無料のハンズオン講習 Postman API Night Postman Launchpad API 関連トークのミートアップ https://postman.connpass.com ランチタイムの Postman 最新情報 https://postman.connpass.com https://postman.connpass.com Postman Japanコミュニテ Discord https://discord.gg/G4SQWDDqVa Postman Japan Youtubeチャンネル https://www.youtube.com/PostmanJapan @postman_japan Postman Qiita https://qiita.com/organizations/postmanjapan Postman Japan X https://x.com/postman_japan
31. Postman AI-Native API Platform Fortune 500 の 98% が選ぶ、AI Agent時代に不可欠な世界標準ツール 3億以上 4500万人以上 1日あたりの API 取引件数 Postman Network 開 発者 98% Fortune 500 51% 36% 21% 50% オンボーディング の迅速化 リリースサイクル の短縮 テストサイクル の高速化 サポート対応の 削減 Postman Business Value across 18 customers 第三者機関が認めたリーダーシップ 規制・標準への準拠
32. The Postman エンタープライズ プラットフォーム API Catalog MANAGEMENT PLANE リーダーシップ | プラット フォーム | DevOps API環境の管理、監査、および監視 API提供者向けの内部カタログ。 すべてのサービス、仕様、テス ト、CI 結果が一か所にまとめら れ、検索可能 Private API Network API 利用者向けの内部カタログ。 開発者のオンボードを短縮するこ とを目的 ACTIVITY PLANE 本番環境のトラフィック検出、CI の合格率、コンプライアンス―― これらすべてに、ダッシュボード またはプログラム経由でアクセス 可能 Governance Rules 組織、チーム、またはワークス ペースグループごとに適用範囲を 限定したサービス動作の強制 Local + Remote Git Sync Partner Workspaces すべてのコミット、すべてのブラン チ、すべての環境でコードと同期 サービスドキュメントやテストス イートを直感的に整理。ワークス ペースはそれぞれ異なる目的を果 たすワークスペース エンジニアリング & 品質保証 APIの構築、テスト、リリース、およ び監視 Reports & Insights API Client and Collections 業界標準の収集形式を用いて、API リクエストを個別に、あるいはまと めて送信、テスト、記録、およびデ バッグ Spec Hub API定義の作成、バージョン管理、 および検証。デザインファーストで もコードファーストでも適用可能 Postman API and CLI Postmanエンティティのプログラ ムによる大規模な作成、管理、お よび実行 Multi-Source Integration CSP、ゲートウェイ、ソースコード 管理プロバイダー全体にわたる一 元的な可視性 Collection Runner テストスイートを、ローカル、クラ ウド、CI、または定期的なスケ ジュールに従って実行 Mock Servers インジェストやエジェストの設定や 追加費用を一切かけずに、社内外の サービスとの連携検証が可能 Agent Mode for the Management Plane すべてのサービスにわたるガバナン スの遵守状況、障害の発生パター ン、およびチームの健全性を調査 Agent Mode for the Activity Plane テストや仕様書の生成、サービス のデバッグ、エンドポイントの追 加など、コマンドプロンプトから Postmanエンティティを管理
33. API DLCの各ステージでのPostman活用 定義 外部の OpenAPI 設計 インポート 開発 テスト デプロイ OpenAPI 設計 (Spec Hub) 監視・観測 配布 Gitサービス (GitHub/GitLab) DASTツール 連携テスト (OWASP ZAP) 生成 要件定義 PRD セキュリティ ガバナンス チェック (API Lint) コード変更 trigger クライアントSDK 生成 コントラクト テスト コレクションに テストコード追加 ドキュメント - ガバナンスチェック - コントラクトテスト - シナリオテスト - セキュリティテスト - パフォーマンス - リグレッション - UI + APIテスト - コントラクトテスト - シナリオテスト - セキュリティテスト - リグレッション APIカタログ セキュリティ テスト (スクリプトベース) シナリオ テスト パフォーマンス テスト リグレッション テスト モックAPI (モックサーバー) APIテスト スケジュール実行 (モニター） (Playwright連携) Postman コレクション パブリックAPI ネットワーク CI/CD経由でAPI テスト自動実行 (Postman CLI） UI+APIテスト 自動生成 プライベートAPI ネットワーク 同一のテストを Postman CLI経由 で実行 同一のテストを モニター経由で実行 モックAPI (モックサーバー) Postman AIエージェント(Agent Mode) Postmanで扱うあらやる設定、コンポート（API仕様、コレクション、テスト、ドキュメントな ど）の設定・生成補助、デバッグ支援 APIドキュメント trigger アラート通知 メトリクス 連携 APMサービス (New Relic, Datadog, etc.)