PostmanはAIに170超のツールをどう使わせるか｜2026年10月14日版
AIエージェントに使える道具を増やしても、仕事が正確になるとは限りません。Postmanが公開した設計では、170超のツールから依頼に関係する約15個を選び、作業を担当するエージェントに渡しています。核心は、AIに見せる選択肢と情報を、仕事ごとに絞ることです。
PostmanとAWSは2026年10月9日、API開発を支援する「Agent Mode」の本番設計を公開しました。2026年10月14日、日本時間時点で確認できる公式情報をもとに、既存アプリへAIを組み込む際の仕組みと実務への意味を整理します。
- ツールは全件を並べず、依頼に応じて選ぶ。
- アプリの画面表示用データを、そのままAIへの入力にしない。
- 導入評価では、モデルの性能とともに作業対象の渡し方を確かめる。
公開されたのは、API開発エージェントの本番設計
Agent Modeは、Postmanの操作を自然言語で進める機能です。
公式ドキュメントでは、リクエストやモックサーバーの作成・管理、エラーの調査、テストの作成・更新などを対象としています。利用にはAI機能への同意が必要です。
また、Agent Mode on Cloudは、コードリポジトリの更新やテスト実行など、時間のかかる作業を分離されたサンドボックスで進め、実行ごとの監査記録を残す仕組みとして説明されています。
今回の発表で重要なのは、新しいモデルの点数ではありません。既存の開発ツールにある多数の操作を、AIが扱える形へ組み直した実装の説明です。
170超から約15へ、ツールを選んで渡す
ツールとは、AIが呼び出せる操作の窓口です。説明と引数の形式を読み、どの操作を実行するか選びます。
AWSの技術記事によると、Postmanの検証では、見えるツールが約40個を超えると選択ミスが増えました。現在の設計は、ツールの埋め込み表現を格納したベクトルデータベースを検索し、170超から依頼に関係する約15個へ絞ります。その集合を、文脈を分離したサブエージェントへ渡します。
約40個は、すべてのAIに共通する上限ではありません。 Postmanの検証で得た結果です。自社システムでは、操作の似通い方や依頼の種類を含めて測る必要があります。
この設計から得られる実務上の示唆は明確です。顧客検索、請求確認、契約更新などをAIに任せる場合、全操作を毎回提示する設計と、必要な操作だけ提示する設計を比較する価値があります。
評価する項目も、回答の自然さだけでは足りません。
- 正しい操作を選べたか。
- 引数に正しい対象を指定できたか。
- 不要な操作を挟まず完了できたか。
画面のデータを、そのままAIに渡さない
操作が正しくても、対象を取り違えれば仕事は失敗します。
Postmanは、画面描画用のデータをそのまま渡す方式から、対象ごとに必要な情報を抽出する専用の処理へ進みました。背景情報と、ユーザーが選択した対象の詳しい情報を分けて扱う設計です。
ここでいう文脈は、長い会話履歴だけを指しません。どのリクエストを調べているのか、どの環境を対象にするのか、といった作業の前提です。
日本の開発現場でも、検証環境と本番環境、同名のAPI、複数のコレクションを扱う場面があります。導入試験では「テストを書けたか」に加え、意図した対象へ変更したかを確認したいところです。
日本の利用者は、実行環境と管理設定を確認する
自動化する作業の範囲は、利用するモードによって変わります。
公式ドキュメントは、アプリ内での作業と、クラウド上で長時間の作業を進める機能を区別しています。企業で評価する際は、次の順で対象を具体化すると判断しやすくなります。
- 作業範囲： テスト生成、エラー調査、リポジトリ更新のどこまでを任せるか。
- 対象データ： どのコレクションやリポジトリを参照させるか。
- 確認方法： 変更差分と実行記録を誰が確認するか。
これらは導入評価の観点です。特定の設定で必ず安全になるという保証ではありません。まず変更内容を確認しやすい作業から試し、対象の取り違えや不要な操作が起きる条件を記録する方法が現実的です。
継続ウォッチ
次に確かめたいのは、ツールを絞る設計が、自社の作業でも効果を出すかです。
- 関連ツールの選択段階で、必要な操作を落としていないか。
- 入力情報を削った結果、作業対象の識別に必要な情報まで失っていないか。
- アプリの機能追加に合わせて、ツール説明と参照情報を更新できるか。
AIエージェントの導入試験では、同じ依頼を「全ツールを提示する条件」と「必要なツールを選ぶ条件」で実行し、成功率、操作回数、対象の取り違えを比べたい。Postmanの事例が示すのは、その比較をモデル選定と同じくらい具体的に進める必要性です。