公開：2026年10月10日, 最終更新：2026年10月10日
30秒サマリー
- PostmanがAgent Mode（AIエージェント機能）の本番運用アーキテクチャをAWS公式ブログで詳説
- ツール数・コンテキスト管理・モデル選択の3点が大規模運用の核心課題と判明
- スキーマベースの読み取りや動的ツールスコーピングなど、既存製品へのAI組み込み設計パターンを公開
何が起きたか
PostmanとAWSは、API開発ツール「Postman」に組み込まれたAIエージェント機能「Agent Mode」の本番運用アーキテクチャについて、AWS Machine Learning Blogで詳細な解説記事を公開した。Agent ModeはAmazon Bedrockを基盤とし、世界4000万人の開発者ユーザーを対象に稼働している。
Agent Modeの設計で浮上した最大の課題は、ツールの肥大化とコンテキスト管理だった。ツール数が約40を超えると、エージェントが存在しないツールを呼び出したり、文脈上は不正確なツールを選択するエラーが増加した。現在のアーキテクチャでは、170以上のツールをベクトルデータベースで管理し、リクエストごとに関連する約15ツールのみをサブエージェントに渡す動的スコーピングを採用している。
構造化データへのアクセスにはスキーマベースのクエリツールを採用した。ClickHouseのテーブルスキーマをエージェントに提供し、結合や条件付きクエリを自律生成させることで、個別ツールの数を大幅に削減している。一方、コンテキスト面では「ツール不足よりコンテキスト不足の方が多くの障害を引き起こした」と明記されており、UIの描画用データモデルをそのままエージェントに渡しても有効に機能しないことが判明。エンティティごとに専用のコンテキストハンドラーを構築している。
Amazon Bedrockの活用では、Anthropic Claudeファミリーの複数モデルへのルーティング、地理的スコープを持つクロスリージョン推論、モデル依存のゼロデータリテンション設定、多段階プロンプトキャッシュの4機能を活用していると説明されている。ユーザーの個人情報保護にはAmazon Bedrock Guardrailsを使い、LLMに到達する前にPIIを削除する仕組みを実装。アプリケーション状態を変更するアクションには必ずユーザー承認を要求する設計としている。
原典ハイライト
「ツール選択エラーはツール数が約40を超えると増加し、170超のツールを動的に約15に絞り込むことで対応した」「コンテキスト不足はツール不足より多くの障害を引き起こした」「UIの描画用データモデルはエージェントの推論に適さず、専用ハンドラーが必要だった」の3点が実運用から得られた核心知見として強調されている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
デモ環境で動くAIエージェントと、数千万人規模の本番ユーザーを支えるエージェントは根本的に異なる設計問題であることが、Postmanの事例で具体的に示された。モデルの性能や精度よりも、既存製品の内部データ構造・ツール設計・コンテキスト設計の方がボトルネックになりやすいという知見は、AI機能を自社プロダクトに組み込もうとする企業に直接適用可能な教訓となる。
日本企業への示唆
自社サービスへのAIエージェント組み込みを検討する日本企業にとって、三つの設計原則が参考になる。第一に、ツール数は少なく保ち動的スコーピングで対応すること。第二に、構造化データにはスキーマ公開＋クエリ生成の方式が個別ツール増設より拡張性が高いこと。第三に、既存UIのデータモデルをそのままエージェントに渡さず、推論用コンテキストハンドラーを別途設計すること。また、Amazon Bedrockのゼロデータリテンション設定やGuardrailsによるPIIリダクションは、個人情報保護規制への対応が必要な日本企業にとって評価すべき機能要件となり得る。
背景・経緯
Postmanは11年以上の歴史を持つAPIプラットフォームで、インターフェース操作を前提に設計・進化してきた。Agent Modeはこの既存製品をAIエイジェントが直接操作できる形に再設計する取り組みとして開発されており、本記事はその本番運用から得た設計パターンをAWSとの共同発信として公開したもの。
