PostmanがAgent ModeをAmazon Bedrockで運用、設計課題を公開

Agent Modeとは何か

Postmanは、APIのテスト、ドキュメント作成、APIの探索、実装をAIネイティブな方法で行うための「Agent Mode」を提供している。ユーザーが画面を操作して情報を探すのではなく、エージェントがデータに対して推論する点が従来と異なる。記事によれば、Postmanは11年かけて製品を成長させており、開発者やユーザーはサイドバーやタブをたどって情報を見つける方法を身につけてきた。その前提をエージェント向けに作り直す過程で、APIやユーザー体験に埋め込まれた構造的な思い込みが表面化したという。

Agent ModeはAmazon Bedrock上で動作し、基盤モデル（土台となる大規模言語モデル）へのマネージドなアクセスを利用する。世界的な開発者コミュニティを支えるため、トラフィックは変動が大きくレイテンシに敏感で、急激なバーストが発生する。Postmanは自社でモデル推論基盤を運用することなく、モデル選択の柔軟性やスループット、地理的な処理、コストの制御を保ちながら、この本番ワークロードをスケールさせていると説明している。

ツールスプロールへの対処

Agent Modeでは、エージェントがPostman内部でどう振る舞うかを「ツール」が定義する。初期のチームは、リクエストを開く、1つのフィールドを更新する、特定のメタデータを取得するといった小さく精密な「原子的なツール」を志向していた。この方針は初期の正しさと制御に寄与したが、実際のワークフローは長いツール呼び出しの連鎖を必要とすることが分かった。各ステップが速くても、次の動作の前に毎回モデルへ戻るため、ユーザーには遅く感じられたという。

Postmanの検証では、可視ツールセットが約40を超えたあたりからツール選択のエラーが増加した。存在しないツールを呼ぶ、スキーマは正しいのに引数を誤る、文脈上は誤りだが意味的には妥当に見えるツールを選ぶ、といった事例が起きた。より大きく新しいモデルはこの挙動を減らしたが、なくなりはしなかったとされる。現在のアーキテクチャでは、ルートエージェントがツール埋め込みのベクトルデータベースに問い合わせ、170以上あるツールをリクエストに関連する約15に絞り込み、コンテキストを分離したサブエージェントに渡す。モデルはタスクに必要なツールだけを見る。

スキーマ読み取りとコンテキスト

APIカタログのような製品では、Postmanは複数の狭いビューを単一のクエリツールに統合した。サービスの稼働状況、テスト結果、エンドポイントの応答時間といった構造化データが対象である。基盤となるClickHouseテーブルのスキーマが与えられていれば、エージェントはJOINやWHERE句を含む複雑なクエリを生成できる。記事では、サービスごとのリクエスト数やエラー率、平均レイテンシ、p95レイテンシを集計するSQLの例が示されている。

Postmanは当初、ツールの不足が最大の障壁になると想定していたが、実際には欠落や不完全なコンテキストによる失敗のほうが多かったと報告している。コンテキストとは、ユーザーがPostmanのどこにいて、どのエンティティが有効で、どのような状態が確立済みかをエージェントが理解していることだ。既存のインターフェースのデータモデルをそのまま渡しても有用なコンテキストにはならない。それらは推論ではなく描画とデータ転送のために形作られているためで、Postmanはエンティティごとに専用のコンテキストハンドラを用意し、エージェントに必要な情報へ蒸留する方式を採った。

オブジェクトが増えるにつれて切り詰め（トランケーション）が次の課題になった。リクエストの説明やOpenAPI仕様、リクエストのペイロードなど、ユーザーが生成する終わりのないデータがコンテキストウィンドウを圧迫する。チームは、各ハンドラが個別の切り詰め・展開ロジックを持たなくて済むファイルシステムベースの方式を検討しているという。

Bedrock上での実行と制御

Agent Modeは3つの要素を組み合わせる。Postmanアプリケーション内に置かれ、リクエストの開始や設定変更、コレクションの実行、認証の検査といった最終的な操作を担うクライアント側ツール、エージェントの積極性や不確実性の伝え方、基礎的な製品知識を定義する汎用的なエージェント指示、そしてRAG（検索拡張生成）によるナレッジベースである。全製品領域を静的なプロンプトに書き込むのは現実的ではなく、大半は個々のクエリに関係しないため、実行時にクエリとコンテキストに応じて記事を選ぶ仕組みにしている。

人間による監督は本番設計の一部だ。Agent Modeはアプリケーションの状態を変更する操作の前にユーザーの承認を要求する。エンタープライズの管理者は、基盤となるLLMに到達する前に個人情報を伏せ字化するAmazon Bedrock GuardrailsをAgent Modeのガードレール設定から有効にできる。AWSはBedrockの4つの機能として、Claudeファミリー間のモデル柔軟性、地理的にスコープされたクロスリージョン推論、モデル依存のゼロデータ保持、多層のプロンプトキャッシュを挙げている。対応するAnthropic Claudeモデル間の移動は、新しい統合ではなく主に設定変更で済むと説明されている。

現時点で分かっていないこと

今回の記事では、4つのBedrock機能のうちモデルの柔軟性については比較的詳しく説明されている。一方、地理的にスコープされたクロスリージョン推論、モデル依存のゼロデータ保持、多層のプロンプトキャッシュについては名称と位置づけの言及にとどまり、具体的な設定方法や効果の数値は示されていない。Agent Modeが利用できるリージョン、日本語を含む各言語での品質、料金体系も原文には記載がない。

ツール選択エラーが増える閾値として示された「約40」や、170以上から約15への絞り込みも、Postmanの検証における値であり、他の製品やエージェントにそのまま当てはまる保証はない。記事が示すのは、成熟した製品にエージェントを組み込む際の設計原則であり、導入を検討するチームは自社のツール数とコンテキスト設計を前提に検証する必要がある。