AI Ready API ─ AI時代に求められるAPI設計とは？/ AI-Ready API - Designing MCP and APIs in the AI Era

Presentation slides for Azure OpenAI Service Dev Day 2025
Session title: AI Ready API ─ AI時代に求められるAPI設計とは？
Date: 2025/07/18

Transcript

1. All rights reserved by Postman Inc 川崎庸市 テクノロジー・エバンジェリスト AOAI Dev Day 2025 資料 2025.07.23 AIReady API 〜 AI時代に求められるAPI設計とは？
2. テクノロジーエバンジェリスト Postman株式会社 川崎 庸市 / Yoichi Kawasaki @postman_japan @yokawasa
3. はじめに @postman_japan
4. 最近、MCPというキーワードを聞かない日は 無い気がしませんか？
5. MCP Model Context Protocol) Anthropic社が開発したLLMが外部ツールとやり取りするための標準化されたプロトコル Tools Resources Prompts MCP Server MCP Client JSONRPC 2.0 モデルが実行する機能 /関数APIリクエスト、ファイル書き込み ) ユーザー向けの定義済みテンプレート (slashコマンド、Q&A モデルへの追加コンテキストのためのデータ File、DBレコード) Prompts, resources, toolsを利用 コンテキストと機能 Capabilities)を提供す るサービス 機能 Capabilities) MCP spec https://modelcontextprotocol.io/specification/20250618 双方向接続
6. Before MCP AIのデータソースとの連携において新しいものが増えるたびに独自のカスタム実装が必要となり、真に連 携したシステムの拡張が困難になっていた。この課題解決のためにMCPはつくられた As AI assistants gain mainstream adoption, the industry has invested heavily in model capabilities, achieving rapid advances in reasoning and quality. Yet even the most sophisticated models are constrained by their isolation from data—trapped behind information silos and legacy systems. Every new data source requires its own custom implementation, making truly connected systems difficult to scale. MCP addresses this challenge. It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. Introducing the Model Context Protocol by anthropic https://www.anthropic.com/news/model-context-protocol ChatGPT Claude My Agent Calendar Service Database Service Email Service それぞれの連携がカスタム実装されていた
7. After MCP • LLMがさまざまな外部ツールと標準化されたプロトコルで連携できるようになった • MCPは外部ツールとのインタラクションを簡素化する、アダプターとして機能 ChatGPT Claude My Agent Calendar Service Database Service Email Service MCP server for Email MCP server for Database MCP server for Calendar 一度MCPサーバーを構築すれば、どこでも活用可能
8. アダプターとしてだけではない MCPが提供する価値 • 外部ツールとのインタラクションの簡素化:標準プロトコルにより、LLMと外部リソースやアプリとの統 合が容易になる（アダプター） • 動的なツールの選択と呼び出しができる: LLMがユーザーのプロンプトに基づいて使用するツール を動的に選択できる。LLM はハードコードされた API 呼び出しを必要としなくなる • コンテキストを保持したツール活用がしやすくなる: LLM側で会話履歴を保持しつつ、動的にMCP各 ツールを使うことで、マルチステップのワークフローを管理しやすくなる LLM 外部ツール MCP 推論 / 動的な判断 コンテキスト管理 アダプター API、DBなど User: 東京の天気は？ → LLM MCPツールに "location=東京" を入力して呼び出す User: それじゃあ、明日は？ → LLM 「東京」という地名を前のやりとり から再利用 LLMがコンテキストを保持しつつ、動的 にMCPツールを活用するシーン
9. MCPはAPIを置き換えるものなのか？
10. MCPとAPIはレイヤーが異なる 項目 API MCP 役割 機能やデータへのイ ンターフェース AIがAPIなどを使うた めのアダプター 利用者 人間、アプリ AI • APIはシステムとデータを外部と接続するコントラクト（契約）を持つインターフェース • 一方、MCPはAIによるAPIを含む外部ツール利用のための新しい手段 (アダプター) • 今後はAIからのAPIアクセスはMCP経由が主流になるでしょう • しかし、多くの業務処理やビジネスロジックはAPIを経由しなければ実行できない LLM API MCP 人間 App LLMは新しいAPIのClient と捉えることができる 今後AIAPIアクセスは MCP経由が主流に
11. MCPはAPIを置き換えるものではない。 むしろ、MCPを通じてAPIエコシステムは 新しい利用層AI に開かれ、拡大していく
12. AIReady API ⇒ AI時代のMCPとAPIの設計の話 • AI の利用に最適なMCPの設計はどうすればよいでしょうか？ • 人間ばかりでなくAIに適したAPIをどのように設計すればよいでしょうか?
13. AIReadyのための基本 @postman_japan
14. APIの使い方: 人間 vs. AIエージェント 人間は「何をしたいのか、どのAPIを使うか」が明確だが、AIは「目標とコンテキスト」から出発 目標とコンテキスト 何をすべきか思考 ツール選択と順序決定 動的にAPI呼び出し (目標) やりたいことが明確 どのAPIか分かっている API仕様書読んで、詳細決定 決められた順序でAPI呼び出し Reasoning 推論
15. AIエージェントの行動モデル 多くのAIエージェントの行動モデルはReAct的 • ユーザーの目標やプロンプトを受け取る • → 内部で思考プロセス Chain-of-Thought) を展開 • → 必要に応じてツール API、DB、検索など)を実行 • → 観察（Observation） • → 次のステップを決定 ReAct Reaction + Action) ReAct: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS (Yao et al., 2022) https://arxiv.org/pdf/2210.03629 AIエージェントの行動モデルを助ける情報が大切 • 意味や目的が明確な情報 • 一貫性・予測可能性がある情報 ※ ReAct的とはあくまで行動と思考の対話ループを持つという意味で Start Thought Action Observati on End
16. Affordance (アフォーダンス) • UX・デザイン文脈で「ある物体がどのように使えるかを直感的に示す特性」として知られている。例：ボ タンは「押すもの」、椅子は「座るもの」 • LLMにとってAffordance力が高いとは、 意味や目的の理解のための明確な情報（ヒントや構造）が 含まれていること ⇒ 機械可読、自己記述的、セマンティックな情報 “Affordances provide strong clues to the operations of things. Plates are for pushing. Knobs are for turning. Slots are for inserting things into. Balls are for throwing or bouncing. When affordances are taken advantage of, the user knows what to do just by looking: no picture, label, or instruction needed.ˮ Affordanceが正しく活用されていれば、ユーザーは見るだけで何を すべきか分かる。図もラベルも説明書も不要 — Donald A. Norman, “The Design of Everyday Thingsˮ 1988 ※自己記述的 = Self-descriptive そのまま読んでわかる ※セマンティック = 意味や目的が明確
17. 推論コスト・トークン制限対策 LLMの推論コスト、トークン制限を考えてデータを提供する必要がある LLMの性能をより効果的に引き出すには、大量の生データをそのまま渡すのではなく、LLMが扱いやす いように集計・加工・構造化されたなデータを渡すのが効果的 LLMが苦手なデータ • 大量データ • ノイズの多いデータ • 一貫性のないデータ • 構造化されてないデータ 対策（集計・加工） • 絞り込み • ノイズ除去 • 構造化 • フォーマット変換 効果 • 応答速度向上 • 推論の精度向上 • コスト削減 Materialized Viewパターンは 有効なアプローチの１つ Materialized View pattern　 https://learn.microsoft.com/en-us/azure/arc hitecture/patterns/materialized-view
18. OpenAPI 仕様 OAS OpenAPI （ 最新は2021年２月リリースの3.1）は、RESTful APIのためのAPI記述形式で、HTTP API機能を 人間とコンピュータが理解できるようにするためのプログラム言語に依存しない仕様形式 OpenAPI Specification 3.1 記述形式：JSON、YAML info メタデータ (バージョン、タイトル、ライセンス ) webhooks tags externalDocs servers APIサーバーURLや環境 security 認証認可 OAuth2, APIキー) paths APIエンドポイント、 HTTPメソッドなど定義 components 再利用可能なスキーマ、リクエスト・レスポンスモデルなど
19. Postmanコレクション仕様 Postmanコレクションの記述形式。コレクションに含まれるAPIリクエストのAPIエンドポイント、リクエスト、 レスポンス、テストなどの情報やAPI 呼び出しのシーケンスを定義できます 記述形式：JSON Postman Collection v2.1
20. 効果的なMCPサーバー設計・構築 のための考慮事項 @postman_japan
21. MCPサーバーの自動生成ツール MCPサーバーのコード自動生成ツールはいろいろある • OpenAPIを元に自動生成するアプローチが多い • PostmanはPostmanコレクション（公開限定）を元に MCPサーバーコードの自動生成ツールを公開 Postman MCPサーバーGenerator https://www.postman.com/explore/mcp-generator https://nordicapis.com/10-tools-for-building-mcp-servers/
22. APIからMCPの自動生成の落とし穴 APIとMCPには本質的なギャップがあるので、安易な自動生成は危険 • APIとMCPでは設計指向が異なる: リソース指向REST) vs. 能力指向MCP • APIの粒度でMCP化するといろいろ問題がある ◦ LLMはツールが多いのが苦手 ◦ LLMからの無駄なツール呼び出しが増える • 人が使う前提で記述されたAPIの説明はLLMには向いていないかもしれない ◦ 説明が曖昧だとLLMはハルシネーションを起こす可能性がある ◦ LLMは曖昧なツール名を判断できないかもしれない API MCP自動生成ツールを使うにしても、ボイラープレート的なものを生成して いると認識し、その後のギャップを埋めるため補完対応が不可欠
23. リソース指向 REST) vs. 能力指向 MCP REST APIとMCPのインターフェースのあり方の違い（リソース vs. 能力、データ vs. 目的） リソース指向（REST API） 能力指向　MCP 目的 リソース・データの操作（CRUD） 目的の達成 → 能力・タスクの実行 表現形式 HTTPメソッド + パス GET /users/{id} ツール名 getUserProfile インターフェース粒度 リソース単位 (エンドポイント: user, product) 能力・タスク単位 (ツールとして定義: getUserProfile) 意味づけ方法 API仕様、APIドキュメント 自然言語でツールの意味・目的を説明 主な使い手 人間（＋今後はAI） AI
24. APIとMCPにおける抽象化の粒度の違い • APIとMCPは目的・設計指向が異なるため、適切な抽象化の粒度には違いがある ◦ API このリソース・データを操作したい ◦ MCP この目的を実現するためにこのタスク（能力）を実行したい https://x.com/yokawasa/status/1918200532424172021 クレームと返金処理の例: クレームで返金 API リソース・データ操作用のCRUD群 GET /claims/{id} POST /refunds PATCH /refunds/{id} GET /refunds/{id} MCP クレーム返金のためのタスク(能力) refundOrderForClaim(claim_id)
25. Affordance (アフォーダンス)力が大切 Affordance力が低いとLLMはハルシネーションを起こすかもしれない • 不明瞭なツール説明:ツール名が曖昧だったり、各ツールの目的が明示的に説明されていないと、 LLM はどのツールをいつ使用するかを判断できない • 曖昧なパラメータ説明: パラメータの説明が曖昧だと、LLM が期待される形式や値を誤って判断し、 ツールの本来の目的について誤った想定をする可能性がある • 欠落したコンテキスト: 実際のレスポンス内容の例がないと、LLMは予想されるデータがどのように なるかを推測できず、ツールの動作について誤った仮定が生じる • 不十分なエラーガイダンス: エラーのドキュメントが不十分だと、LLM は次のアクションを判断でき ず、さらにハルシネーションが生じる可能性がある
26. MCPサーバーの主要な考慮事項 • 抽象化の粒度 ( ツールを目的ベースの実用的なタスク単位にする) • Affordance力 (ツール名、メタデータ、エラーメッセージなど） • 推論コスト・トークン制限対策（的確な結果・ツールに絞る） • セキュリティ
27. MCPサーバーの主要な考慮事項 - ツールの粒度調整 ツールをAIが実現したい目的ベースの実用的なタスク単位にする（≠ APIのCRUD群の粒度） • AIが目的達成のために必要な処理か？ • AIが少ない試行回数で目的を達成できるか？ クレームと返金処理の例: クレームで返金 API リソース・データ操作用のCRUD群 GET /claims/{id} POST /refunds PATCH /refunds/{id} GET /refunds/{id} MCP クレーム返金のためのタスク(能力) refundOrderForClaim(claim_id) GET /claims/{id} POST /refunds PATCH /refunds/{id} GET /refunds/{id} API MCP Server AI App refundOrderForClaim
28. MCPサーバーの主要な考慮事項 - ツールの数 • 2025/07時点でAIエージェントによってはMCP Tools数に制限がある • ツール数とLLMパフォーマンス (プロンプト負荷など) の関係は定かではないが、ツールが多くなる と、Affordance力の低いツールによりLLMの混乱が生ずる可能性が高くなる • 現時点では、ツール数を増やしすぎないほうがよさそう GitHub Copilotの 128ツール制限
29. MCPサーバー考慮事項 - Affordance力を高める ツール名・説明、エラーメッセージなどを機械可読、自己記述的、セマンティックに Postman API MCPのget-tagged-entitiesツール情報 明確なツール名 ツールの意図や 詳細の説明 入力スキーマ： 型、範囲、制限、説明、 必須、など Annotations: ヒント＋追加メタ情報 Postman API MCPのget-collectionのエラー エラーの原因説明と対 策情報
30. MCPサーバー考慮事項 - 推論・トークンコスト対策 LLMの推論コスト・トークンコストを考慮し、不要なデータ・ノイズの多いデータを渡さない • LLMが迷わず正しく推論できるよう、必要なデータのみに絞る ◦ フィールド数・ツール呼び出し回数が多いと、推論・トークンコストが増大 ◦ まとめて必要な分だけ取る仕組みがあるとよい（GraphQLのようなイメージ） • 同じ意図・機能のツールを複数作らない ◦ get_user_info, fetch_user_profile, lookup_user どれもユーザー情報取得だけど名前・説明が微妙に違う ◦ LLMがどれを使えばよいか迷い、意図しない、無駄なTool Callを選択する ◦ affordance力が低い曖昧な名前・説明のツールセットも同様に無駄なTool Callの選択につながる ◦ GET /users API MCP Server AI App getUsers JSON Filtered JSON LLM どれを使えばいいのか？ • get_user_info • fetch_user_profile • lookup_user
31. MCP実装を評価する モデルに何か依頼して、間違った情報が返されたり、間違ったツールを選択してほしくないですよね？ 作ったMCPサーバーの実装を定量的に評価しましょう • MCPは、LLMがアクションを要求し、結果を受け取るための標準的な仕組みなので、LLMがツールに適切にアクセスし、そ れを使用できることが大切 • MCP 実装の評価: LLMに提供されるツールが正しく、一貫して機能するか？ 評価ツール: mcp-evalsの評価プロセスとスコア例 1. MCPツールの評価シナリオを作成 2. シナリオをMCPサーバーに対して実行 3. LLMは、事前に定義された基準に基づいて回答を評価 4. 実装を改善のためのスコアとフィードバック取得 mcp-evals https://github.com/mclenhard/mcp-evals 5つの指標で5段階評価 正確性、完全性、関連性、明確性、推 論の健全性
32. MCPサーバー考慮事項 - セキュリティ MCPにおける新たな脅威例 • ツールポイズニング：ツール説明の改ざんでAIを騙すリスク • データ漏洩：安全でないツール経由で機密情報流出の恐れ • Command & Control C2攻撃：MCP経由で隠れた通信チャネルの悪用 • アイデンティティ破壊：認証・認可の欠陥から不正アクセスリスク MCPサーバーを安全に運用するためのポイント • インフラ：安全なネットワークと必要な計算リソースの準備 • サーバーソフトウェア：MCP仕様に準拠した信頼できるソフトウェア実装 • ツール統合：外部ツール・内部システムとの安全な連携 • 認証・認可：クライアント認証＆ポリシーに基づくアクセス制御（MCPサーバー OAuth2.1実装の義務化） Enterprise-Grade Security for the Model Context Protocol MCP Frameworks and Mitigation Strategies • https://genai.owasp.org/2025/04/22/securing-ais-new-frontier-the-power-of-open-collaboration-on-mcp-security/ • https://arxiv.org/html/2504.08623v2
33. MCP 認可 仕様 MCP 20250618版でセキュリティ仕様が強化され、MCPサーバーをOAuthリソースサーバー（ OAuth 2.1 サポート）として明確に分類 MCP Authorization　 https://modelcontextprotocol.io/specification/20250618/basic/authorization • PKCE implementation MUST: All MCP clients must use Proof Key for Code Exchange PKCE) to prevent authorization code interception attacks. • Metadata discovery support SHOULD: MCP servers should support RFC8414 for automatic endpoint discovery. • Dynamic client registration SHOULD: MCP servers should support RFC7591 to enable seamless client onboarding. • Standardized error handling MUST: MCP servers must respond with specific HTTP status codes (401, 403, 400) for different authorization scenarios.
34. AI時代のAPIどう設計すべきか？ @postman_japan
35. 良いAPIとは? Good APIs tend to offer clarity (of purpose, design, and context), flexibility (ability to be adapted to different use cases), power (completeness of the solution offered), hackability (ability to pick up quickly through iteration and experimentation), and documentation. In a book - Designing Web APIs - building that developers love by Chris Messina, developer experience lead at Uber (意訳) 通常、良いAPIは、目的・設計・文脈が明確であり、 柔軟性があり、提供されるソリューションに完全性があり、 すぐに理解できて、ドキュメントが提供されています。
36. 良いAPIに求められる特性 - 変わらないもの 設計特性 • モジュール性 • 機械可読性 • 構成可能性 • 適応性 Adaptability) • 構成可能性 Composability) 利用者にとって必要な特性 • 利用者ニーズを満たす • 開発者体験が良い • 発見しやすい • 一貫性がある • 信頼性がある
37. AI時代に特に考慮が必要な特性 • Affordance力 (機械可読で明確なドキュメント、メタデータ、エラーメッセージ、など） • 一貫性 AIにとって予測可能性がある命名規則、スキーマ構造、など) • 冪等性 (何回実行しても結果が変わらないこと) • 発見可能性 (見つけやすいこと) • パフォーマンス・セキュリティ • 推論コスト・トークン制限対策（専用のタスク用API、的確な結果に絞れるオプション）
38. API仕様 = Single Source of Truth • API (仕様) ファーストの世界では、API仕様はSingle Source of Truth (信頼できる唯一の情報) として、それを元にモック、テスト、SDK、スタブコードを構築する重要な情報源 • AIにとってもAPI仕様はAPIのAffordance力や発見可能性を支える重要な情報源 • これまでも自動生成の観点で機械可読であることは重要だったが、AI時代では機械可読であること は必須となったと言える 人間だけが読めるAPI仕様 PDF、独自フォーマット、神エクセル)は卒業し、AIも使えるAPI仕様へ。 AI時代のAPIは、標準化・機械可読な形式が鍵です
39. APIのAIReady対策 - Affordance力を高める • 機械可読・自己記述的・セマンティックなAPI仕様ドキュメントの整備 ◦ OpenAPI、Postmanコレクション、GraphQL schemaなど • メタデータの整備 ◦ OperationId (操作識別用文字列) を明確化 OpenAPIの場合) ◦ 説明フィールド (summary, description ) ◦ パラメーター・スキーマ構造詳細 ◦ サンプルデータ ◦ 認証・認可 • エラーハンドリング用の情報 ◦ ステータスコード ◦ エラーメッセージ
40. APIのAIReady対策 - Affordance力を高める OpenAPIのメタデータ整備：OperationId、説明フィールド、パラーメータ・スキーマ構造 明確なoperationId (操作識別用文字列) 説明フィールド (summary, description） パラメータの詳細 （説明、型、制限、など） Stripe API OpenAPI https://github.com/stripe/openapi/blob/master/openapi/spec3.yaml
41. APIのAIReady対策 - Affordance力を高める エラーハンドリング用の情報の提供: ステータスコード, エラーメッセージ • HTTP標準のステータスコード（400, 500…） • エラーの原因 (明確かつ具体的な自然言語での説明) • 次のアクションを判断できる情報 (再試行、回避可能性、など) • エラーのサンプル Stripe APIのRate Limitエラー（HTTP ステータスコード: 429） Stripe API error handling https://stripe.com/docs/error-handling
42. APIのAIReady対策 - 一貫性 命名規則、スキーマ構造など一貫性 (予測可能性) のあるAPIの提供 • AIエージェントの行動モデルはReAct的で、パターン・規則性に従い判断する • 一貫性が崩れるとAPIを正しく認識できなくなる可能性がある 一貫性のポイント • 命名の一貫性: API探索・目的理解が ◦ 悪例: /v1/users/{id} vs. /api/2/orders/{id} • 引数の一貫性: パラメータ設定の誤りを防げる ◦ 悪例: uid vs. user_id • エラー構造の一貫性: 後続のアクション（リトライなど）の判断が容易になる • レスポンス形式の一貫性: 後続のアクションの推論がスムーズになる
43. APIのAIReady対策 - 冪等性 冪等性 Idempotency、何回実行しても結果が変わらない特性)を担保する • AIエージェントは推論の過程で同じ処理を繰り返し実行(リトライ)する傾向がある • 冪等性がないAPIは想定しないデータの不整合を起こす可能性がある ◦ 重複注文・送金、大量のメール誤送信・・・ APIのCRUD処理における冪等性 • 一般的に冪等性のあるメソッド: GET, PUT, DELETE, HEAD, OPTIONS • POSTでも冪等性キーIdempotency-key)を活用した冪等性の担保は可能 ◦ Stripe APIでは冪等性キーを活用したPOSTの冪等性も標準的にサポート ◦ Stripe APIの冪等リクエスト https://docs.stripe.com/api/idempotent_requests
44. APIのAIReady対策 - 発見可能性 • AIにとって発見可能性 Discoverability) のないAPIは存在しないも同然 • 機械可読で分かりやすいメタデータ、発見可能なエンドポイントが必要 Postman Developers Guide to AIReady APIs https://www.postman.com/ai/ai-ready-apis/ 発見可能性のポイント • 機械可読なAPI仕様の公開 ◦ OpenAPI、Postman コレクション、GraphQL Schema、など • APIカタログへの登録・カタログ整備 ◦ AI用API探索のベースとなるAPIカタログに登録（Postman API Network, SwaggerHub、など） • Affordance力の高いメタデータ ◦ セマンティックで自己記述的なメタデータ ◦ 認証・認可のわかりやすさ・使いやすさは特に大切
45. APIのAIReady対策 - 推論コスト・トークン制限対策 LLMの推論コスト・トークン制限対策として、有効と思われる案 • タスク特化型APIの用意 ◦ リソース指向ではなくなるものの、LLMが目的特化型で要求できるAPIの用意 • 検索APIの用意 ◦ ピンポイントな結果が取得できるAPIの用意 • 出力フィルター・オプションの追加 ◦ fieldsクエリパラメータで出力フィールド制御 ◦ LLM向けに要約 or 少量データを返すオプションを用意 GET /users/{id}?fields=id,name { "id": "12345", "name": "My Example" } GET /users/{id} { "id": "12345", "name": "My Example", "email": "my@example.com", "address": { "street": "123 Some St", "city": "Example City" }, … "created_at": "20250718T120000Z" }
46. Postmanが支援できること @postman_japan
47. AI時代の今もWeb APIはすべての基盤 人間とAIの両方が使える高品質なAPIが必要
48. Postmanは高品質なWeb APIの開発〜運用まで 単一ツールセットで支援できるAPIプラットフォーム • APIライフサイクルの管理 • APIガバナンスの策定・実施 • コラボレーションの促進 What is an API platform? https://www.postman.com/api-platform/ API利用者と提供者に対して次のことを支援：
49. APIプラットフォーム Postmanの API開発ライフサイクルにおける各ステージでの活用例 定義 設計 開発 テスト セキュリティ デプロイ 監視・観測 ビジネス システム Security ・・・ ドキュメント コード管理 システム設定 モック API Contracts (スキーマ) APIサーバー 開発 API Gateway 開発 トラフィック キャプチャ セキュリティ テスト 要件 Postman コレクション generate パフォーマンス テスト Contracts テスト E2E テスト ソースコード 成果物 commit 自動テスト APIサーバー Build/Deploy API Gateway Build/Deploy CI/CD ・・・ 配布 モニター アラート APM レポート APIカタログ API 開発ポータル trigger integration trigger ユーザー フィードバック Feedback loop UIテスト Stub generate @postman_japan
50. 多様なAPIアーキテクチャスタイルをサポート
51. MCP Model Context Protocol) リクエスト MCPのためのインターフェース STDIO、SSE、ストリーミング HTTPを介したMCP操作が可能 任意のMCPサーバに動作確認や デバッグができる MCP OAuth認可にも対応 MCP
52. MCPサーバー生成ツール Postman APIネットワークに公開されたAPIからMCPサーバーを自動生成 Postman APIネットワークに公開さ れたAPIを選択してビルドするだけ。 追加設定、コードは不要 Postman MCPクライアントで動作 確認して、 Claude、Cursorなどか ら使用できる MCP
53. Spec Hubによる高品質なAPI仕様の設計・管理 Spec Hubの主要機能 • API 設計 ◦ OpenAPI3.0とAsyncAPI2.0 ◦ スキーマ定義（インポート可能） ◦ API定義の自動バリデーション ◦ ガバナンスポリシーのチェック ◦ コレクション生成（テスト、ドキュメント が可能な形式） ◦ ドキュメントのライブプレビュー • チーム開発支援 ◦ API共同設計 ◦ ロールベースのアクセス制御 SpecHub https://www.postman.com/product/spec-hub/ API設計 ボタンクリックで仕様から コレクション生成
54. モックサーバーを活用したAPIプロトタイピングと仮説検証 • モックサーバー（PostmanのモックAPIサービス）を活用することで API実装前にAPIの検証をすすめること ができる（APIプロトタイピング開発） • API設計段階でモックAPIを通じた検証を通じて、 API仕様を洗練化させることができる @postman_japan API設計 要件 / ゴール API定義 コレクション ドキュメント作 成 モック作成 (モックサーバー） テスト作成 インポート 直接コレクションを作成 （プロトタイピング） 外部でAPI定義を作成 API定義 API定義からコレクションを生成
55. コレクションを中心としたリッチなドキュメント体験 • Postmanはコレクションを中心としたリッチで充実したAPIドキュメント体験を提供 • コレクションを一言でいうと、実行可能なAPIドキュメント ◦ API仕様ドキュメント参照からシームレスに自由度高くAPIリクエスト送信が可能 ドキュメント
56. Postmanを活用したAPIテストのカバーエリア • UIテスト • E2Eテスト • リグレッションテスト • シナリオテスト • インテグレーションテスト • コントラクトテスト • ユニットテスト • セキュリティテスト • ユーザビリティテスト • パフォーマンステスト 機能要件テスト 非機能要件テスト E2E Integration API Unit コスト 実行時間 不確実要素 テスト数 テストのピラミッド テスト @postman_japan
57. 実行 実行結果詳細表示 サマリー結果表示 順番入れ替え可能 実行方法選択 手動 / スケジュール実行 イテレーション数 遅延秒数 データファイル 指定可能 選択 コレクションメニュー コレクションランナー実行方法設定 @postman_japan テスト シナリオテスト・データ駆動テスト コレクションランナーにより複数APIで構成されるテストの手動・定期実行が可能
58. コレクションもしくはフォルダーに登録されている APIリクエスト群（シナリオ）に対して、手軽に APIクライアントか ら負荷をかけ、APIの性能フィードバックをリアルタイムで取得可能 実行 コレクションランナー実行タイプ設定 テスト Postman パフォーマンステスト 複数APIリクエストで構成されるシナリオに対してパフォーマンステスト実行
59. AI アシスタント Postbot @postman_japan テストコード自動生成 ドキュメント自動生成 利用ガイド、デバッグ支援 テスト
60. CLIを活用したCI/CDからの継続的テスト実行 GitHub ActionsでのPostmanテストの実行イメージ Postman CLI からのコレクションテスト実行 テスト @postman_japan
61. Postmanモニターで定期的にAPIの健全性をテスト • コレクションごとにモニターを設定 • テスト実行頻度 ◦ 5分毎〜設定可能。ただし無料プランは一時間毎〜 • テスト実行リージョン選択 ◦ 複数リージョンからの APIテスト実行が可能 • スタティックIPを持つモニター指定 ◦ 要Professional / Enterpriseプラン • アラート通知設定 ◦ メール通知、or インテグレーション設定 でslack、 PagerDutyなど他チャンネルへの通知も可能 • リトライ、タイムアウトなど設定可能 リクエスト元リージョンの選択 Setup a monitor in Postman https://learning.postman.com/docs/monitoring-your-api/setting-up-monitor/ 監視・観測 @postman_japan テスト
62. オブザーバービリティサービスとのインテグレーション インテグレーション設定により Postmanモニターで閾値を越えたテスト失敗数が確認されたら外部オブザーバー ビリティサービスにイベントの送信が可能 イベント 送信 PagerDuty Datadog NewRelic Observe your API performance using monitor integrations https://learning.postman.com/docs/designing-and-developing-your-api/observing-an-api/observing-an-api/ @postman_japan Datadog dashboardイメージ 監視・観測 テスト
63. Postman InsightsでAPIオブザーバビリティ API エンドポイントの発見と稼働状況（レイテンシー、カウント、エラーなど）の情報提供 @postman_japan https://www.postman.com/product/postman-insights/ API エンドポイントの発見 API エンドポイントの稼働状 況を可視化 サポートプラットフォーム 監視・観測 Open Beta 2025/07時点)
64. 継続的なAPIセキュリティとガバナンスの検証 代表的なチェック・管理内容。各フェーズやCI/CDなどからの継続的な実施が可能 APIセキュリティ • セキュリティ衛生状態 • 認証と認可の脆弱性 • クォータとスロットリングの実装 • 適切なセキュリティヘッダー • ロギングとモニタリングの実践 • API文書の適切な管理 • カスタムルール、etc. https://www.postman.com/api-platform/api-security/ APIガバナンス • 全体統制の設定 ◦ APIの文書化、テスト実施、メンテナンス状 況、誤ってトークンを公開していないか、な ど • カスタムルール、etc. https://www.postman.com/api-platform/api-governance/ セキュリティ ガバナンス @postman_japan
65. Postman Enterprise: 大規模で安全なコラボレーションの実現 コラボレーション機能 ✦ フォーク ✦ バージョン管理 ✦ Pullリクエスト ✦ コメント ✦ 共有 ✦ グループ ✦ ワークスペース セキュリティ機能 ✦ SSO ✦ SCIM ✦ きめ細かいRBAC ✦ 公開リンク機能 ✦ ドメインキャプチャ ✦ シークレットスキャナー プライマリーコレクション・ワークスペース プライベート APIネットワーク パブリック APIネットワーク チーム B ワークスペース チーム C ワークスペース チーム Dワークスペース チーム Eワークスペース チームAワークスペース 外部のワークスペース コラボレーション
66. APIカタログ- API発見・探索・共有 @postman_japan プライベート API ネットワーク パブリック API ネットワーク • チームメンバーに限定 • チーム内の機能重複の排除 • API 知見やノウハウの共有 • チーム内の API 利用動向の把握 • 多くの利用者・開発者に知ってもらう • 利用者の Time To First Call の短縮 • 利用者からのフィードバックと改善 API発見・共有
67. MCPサーバーのカタログもあります MCP発見・共有
68. Agent mode 会話型エージェントを通じたPostmanの操作・管理 ウェイティングリスト 2025.07時点) Agent Mode is coming soon ウェイトリストはこちら 👇
69. API 最新情報や Postman プラットフォームをもっと知りたい @postman_japan Postman API Night API 関連トークのミートアップ https://postman.connpass.com Postman Japan コミュニティ Discord https://discord.gg/G4SQWDDqVa Postman Qiita https://qiita.com/organizations/postmanjapan Postman Japan X https://x.com/postman_japan Postman Launchpad ランチタイムの Postman 最新情報 https://postman.connpass.com Postman オンライン ワークショップ 無料のハンズオン講習 https://postman.connpass.com
70. まとめ @postman_japan
71. まとめ • MCPの登場でLLMは様々な外部ツールと標準化されたプロトコルで連携できるようになった • APIのエコシステムはMCPを通じて新しい利用層AI に開かれ、拡大していく • AIReady化のためには、AIエージェントの行動モデルを理解し、好みのデータAffordance力の高 いデータ)、制限 (推論・トークンコスト)を意識することが大切 • APIとMCPはそもそも指向、適切な粒度が違うのでAPIからMCPの自動生成は気をつけよう • MCPサーバーの主要な考慮事項として、抽象化の粒度、Affodance力、推論コスト・トークン制限、 セキュリティがある • APIにおいてはいろんな考慮事項があるものの、AI時代に特に必要な考慮事項としてAffordance 力、一貫性・冪等性、発見可能性などがある • AI時代の今もWeb APIはすべての基盤であり、人間とAIの両方が使える高品質なAPIが必要 • Postmanは高品質なWeb APIの開発〜運用をご支援できるAPIプラットフォーム
72. ご清聴いただき、ありがとうございました。 @postman_japan