先に結論
PostmanとAWSによる運用事例を読むと、まずはツール露出を限定した限定導入を行うことが日本企業の現実的な第一歩です。モデル品質だけでなく、ツールカタログ、コンテキスト設計、地理的推論ポリシー、キャッシュ戦略を先に決め、PoCで誤動作率と運用コストを計測してください。
GLOBAL AI BRIEF ・ COMPARISON
どの条件でAgent Modeを拡張するか？
- STEP 01起点：業務を限定する例：APIドキュメントの自動生成
- STEP 02ツール管理：露出は小さく始める目安：40未満を初期上限
- STEP 03コンテキスト：目的に特化したハンドラを作るレンダリングデータはそのまま渡さない
- STEP 04モデル／リージョン：用途と法規で分けるBedrockのInference Profileを利用
- STEP 05キャッシュ：二層でコストを下げる長期＝1時間、短期＝5分（Postman案）
この記事で答える問い
誰が対象か：日本企業でAIエージェントを製品・社内運用へ移行しようとする担当者。
読後にできること：Postmanの公開情報を根拠に、自社PoCの対象、評価指標、運用上の必須設計を具体的に決められる。
一次情報の範囲と出典
一次情報はAWS Machine Learning Blog上のPostman共著記事（How Postman runs Agent Mode for 40 million developers on Amazon Bedrock、2026‑10‑09公開）です。本文で用いる主な事実は、同稿によると、という帰属で示します。
確認日：2026-10-12（同稿の公開日と本文を参照して編集部が整理）
何が公表されたか（固有事実の抜粋）
Postmanは、約4,000万の開発者ユーザー向けにAgent Modeを運用していると報告しています（同稿によると）。
公開情報には、実運用で着目すべき次の設計要素が並びます：ツールの動的選択、スキーマベースのクエリ、目的に応じたモデル選択、クロスリージョン推論の利用、二層のキャッシュTTLなど（同稿によると）。
Postmanのテストで、可視ツール数が約40を超えるとツール選択の誤りが増えたという観察があります（同稿によると）。
大規模なツール集合を扱う際、root agentがベクトル埋め込みで170件超のツールを絞り込み、約15件の関連ツールに限定してからサブエージェントに渡す運用パターンが示されています（同稿によると）。
設計の仕組み（概要）
Postman事例は三つの技術的柱で本番を支えています。第一にツールを業務ごとに動的に絞ること。第二にスキーマ化された読み取り（schema-aware reads）で、データ層の問合せを行うこと。第三にモデルとリージョンを用途別に選ぶ運用（Bedrockの機能を利用）です（同稿によると）。
動的ツール選択は、ルートエージェント→ツール埋め込みベクトル検索→関連ツールの切り出し→サブエージェント実行、という流れです。これによりモデルの認知負荷を下げます（同稿によると）。
スキーマベースの読み取りは、データベースや分析エンジンのスキーマを前提にエージェントが自由なSQLや集計を生成できる設計で、ツール数を増やすよりデータモデリングに工数を集中するという判断が示されています（同稿によると）。
実運用で明示された数値と閾値
主な公開数値は次の通りです（同稿によると）：
- ユーザー規模：40,000,000人
- ツール誤選択の閾値：およそ40ツール
- ツール絞り込み：170件→約15件
- キャッシュ戦略のTTL：長期層=1時間、短期層=5分
なぜツールを「絞る」設計が有効か
Postmanの検証では、ツールカタログをむやみに増やすとモデルが「正しく選ぶ」確率が下がり、誤ったツールを呼ぶ頻度が上昇します（同稿によると）。
これは、ツールの多さがコンテキストのノイズとなり、モデルの選択確率を分散させるためです。したがってツールは用途別に限定し、必要に応じて動的に露出するルールを設けることが重要です。
モデル選択・リージョン・データ保持の判断（運用面）
Postmanは機能別にモデルを分け、負荷や精度の要件に応じてBedrock上のClaude系などを使い分けています（同稿によると）。
また、クロスリージョン推論の利用はAmazon Bedrockのプロファイルを使い、地理的処理境界とスループットのバランスを取る設計が示されています（同稿によると）。
企業が日本で採用する際は、データ処理の地理境界（国内処理／グローバル処理）と契約上のデータ保持設定（例：zero data retention）をモデル毎にチェックする必要があります。
運用コスト削減のためのキャッシュ設計
Postmanは、安定したプレフィックスは1時間、より可変な層は5分のキャッシュTTLで二層キャッシュを使い分けることで、入力トークンとレイテンシを抑えています（同稿によると）。
この設計の実務的意義は、頻繁に送る「変わらない」部分を省略してコストを下げる点にあります。PoCではキャッシュヒット率と経済効果を必ず計測してください。
日本企業が先に決めるべき5つの条件（実務判断）
1) 対象ユーザーと業務を限定すること（例：APIドキュメント参照・オンボーディング）
2) 公開するツールの最大上限（最初は40ツール以下を推奨）と動的絞り込みルール
3) コンテキストハンドラの設計——レンダリングデータをそのまま投げないで、目的形の要約を作ること
4) 地理的推論ポリシーとデータ保持（BedrockのInference Profile、retention設定の確認）
5) 評価指標：誤選択率、タスク完了率、キャッシュヒット率、平均応答レイテンシ、コスト/1件
比較表：選定判断に使う軸
| 判断軸 | 低リスク（初期） | 高スケール（拡張） |
|---|---|---|
| ツール数 | <=40（限定） | >40（動的絞り込みが必要） |
| コンテキスト形 | ハンドラで要約・最小化 | 多数ハンドラ＋ファイルシステム管理 |
| モデル選択 | 単一モデルで検証 | 用途別に複数モデルを切替 |
| リージョン処理 | 国内処理を優先 | クロスリージョンでスループット確保 |
| キャッシュ | 短期TTL優先（5分） | 二層TTL（1時間＋5分） |
PoC設計の具体案（8週間）
Week 0: 対象業務と成功定義の合意（KPIを5つに絞る）。
Week 1-2: ツールカタログの設計・ベクトル埋め込みとツール埋め込みの準備。
Week 3-4: コンテキストハンドラの実装とschema-aware readの簡易版を用意。
Week 5-6: キャッシュとモデル切替のベンチ。キャッシュヒット率を記録。
Week 7-8: 本番類似負荷で誤選択率、完了率、コストを計測し、拡張基準を判定。
適用しない条件・未検証の範囲
Postmanの事例は「開発者向け製品でのスケール事例」に特化しています。したがって、業務ドメインが高度に安全性要求のある金融決済や医療の臨床判断である場合、同一の設計がそのまま適用できるとは限りません。
また、同稿は運用上の定量コスト（総TCO）や誤選択の業務被害額の完全な内訳までは示していません。これらは自社PoCで確認する必要があります（同稿によると）。
編集部の実務判断（まとめ）
まずはツール露出を限定したPoCで運用の再現性を試すことを推奨します。モデル・データ境界・ツール制御・キャッシュを事前にルール化できない場合は拡張を急がないことが安全です。
コンテキストを目的形へ変換できないなら導入を保留してください。レンダリングデータをそのまま与えると不要なノイズで誤動作が増えます。
スキーマベースの読み取りを優先し、ツール数を減らす設計が長期的な運用性を高める、というのがPostman事例からの主要な教訓です。
よくある質問（FAQ）
Q1: ツールを30〜40に絞ると機能制約が多くなりませんか？
A1: 初期は業務ごとに最小セットを定め、必要な追加は動的絞り込みルールで対応します。機能不足はサブエージェントやschema-queryで補えます。
Q2: キャッシュTTLはどのように決めればよいですか？
A2: 変更頻度と情報鮮度要件で決めます。Postmanは1時間／5分の二層を採り、安全側は短TTL、コスト効率は長TTLでバランスします（同稿によると）。
Q3: クロスリージョン推論は必須ですか？
A3: 必須ではありません。スループットが問題になるか、法令や契約で処理地域を限定できない場合に有用です。国内要件が厳しい業務は国内処理を優先してください。
出典・証拠
主な一次情報：AWS Machine Learning Blog, “How Postman runs Agent Mode for 40 million developers on Amazon Bedrock”（2026-10-09公開、2026-10-12確認、PostmanとAWSによると）。
検証範囲と更新条件
検証範囲：同稿に記載されたアーキテクチャ、設計パターン、PoC上の観察。
未検証：貴社固有環境での誤選択が及ぼす業務影響、総TCO、法規適合性。公式情報更新時に再確認が必要です。