PostmanのAIエージェント設計に学ぶ｜170超のツールを絞り込み、40以上で起きた選択ミスを改善

PostmanとAWSは2026年10月9日、API開発プラットフォームの「Agent Mode」を本番運用する際に得られた設計上の知見を公開しました。Postmanは4,000万人の開発者を抱えるサービスですが、この数字はAgent Modeの利用者数ではなく、製品全体の開発者コミュニティの規模です。

当初の課題はAIモデルの性能よりも、既存アプリケーションの複雑な操作をAIへどう伝えるかでした。小さな操作を個別のツールにすると呼び出し回数が増え、処理が遅くなります。Postmanの検証では、モデルへ見せるツールが約40を超えると、存在しないツールの呼び出しや引数の間違いが増えたと報告されています。

【ツールが多いほど賢くなるとは限らない】AIエージェントに多数の操作を一度に提示すると、似た名前のツールを取り違えたり、必要な引数を誤ったりする可能性があります。Postmanの事例は、モデルを大きくするだけでなく、現在の依頼に必要な操作だけを提示する設計が重要であることを示しています。

【170超から約15へ絞る設計】すべてのツールを毎回モデルへ渡すのではなく、依頼内容に応じて関連する候補を選別します。これによりモデルが比較する選択肢を減らせます。ただし必要なツールを除外してしまうとタスクが完了しないため、選別の再現率と実行成功率を併せて評価する必要があります。

【画面状態への依存を減らす】人間用UIでは、特定のタブが開いているか、どの画面が選択されているかによって操作が変わることがあります。エージェントに同じ手順を再現させるより、対象リソースを明示してデータを直接取得・更新できるインターフェースの方が、状態の取り違えを抑えられる場合があります。

【コンテキスト設計も品質を左右する】画面表示のための巨大なデータ構造をそのまま渡すと、不要な情報がモデルの判断を妨げることがあります。タスクに必要な項目を抽出し、識別子、制約、直近の状態を明確に示すことで、入力の量と解釈の複雑さを減らす設計が考えられます。

【承認と権限の境界】API仕様の検索と、コレクションや環境設定の変更ではリスクが異なります。参照操作は自動化しても、状態を変更する処理は変更内容を表示して利用者に承認を求めると、誤操作の影響を抑えやすくなります。モデルの指示だけで権限を拡大させないことも重要です。

【他社が参考にする際の指標】ツール呼び出しの正確さ、タスク完了率、平均呼び出し回数、応答時間、承認後の修正件数を継続して測ると改善の効果を把握できます。約40という境界値や約15という候補数はPostmanの環境での報告であり、あらゆる製品に共通する最適値ではありません。

【仕組みと背景】170を超えるツールをそのままモデルへ渡すと、選択の複雑さが増える可能性があります。Postmanは依頼に応じて候補を絞り込む設計を紹介しています。

【導入時の課題】AIに人間用の画面操作を模倣させるより、必要なデータと操作を明確なインターフェースで提供する方が安定する場合があります。

【検証と今後】状態変更に承認を求める設計は、操作の責任を明確にするために重要です。ツール選択精度だけでなく、誤操作の回復方法も評価する必要があります。

【今後の注目点】技術の新しさだけでなく、既存の作業へ無理なく組み込めるか、導入費用に見合う効果があるか、利用者が結果を検証できるかが普及を左右します。実際の運用事例と継続的な評価が、今後の判断材料になります。

現在の構成では170を超えるツールの候補から、依頼に関係する約15個へ動的に絞り込みます。さらに、画面のタブが開いているかどうかに依存する操作を減らし、データを直接扱う仕組みへ移行しています。AIエージェントに人間用UIの操作手順をそのまま模倣させないことがポイントです。

もう一つの教訓は、コンテキストの質です。Postmanは表示用のデータ構造を丸ごと渡すのではなく、エージェントの判断に必要な情報を抽出する専用処理を設計しました。Amazon Bedrockのモデル切り替え、地域を限定した推論、プロンプトキャッシュも活用しています。

重要な変更操作には利用者の承認を求め、個人情報の保護にはBedrock Guardrailsを利用します。製品にAIを組み込む企業にとって、モデル選定だけでなく、操作権限、コンテキスト、確認導線を一体で設計する必要があることを示す事例です。