Postmanが4000万開発者向けAgent ModeをAmazon Bedrockで運用する設計思想
ニュース概要
AWS Machine Learning Blogが、API開発プラットフォームPostmanが自社のAgent Modeを4000万人の開発者向けにAmazon Bedrock上でどう運用しているかを紹介した。デモレベルで動くAIエージェントと、実際に大規模なユーザーベースで安定稼働させるエージェントは全く異なる問題であるという前提のもと、Postmanが直面した課題と解決のためのアーキテクチャパターンが共有されている。具体的には、ツールの乱立（tool sprawl）の制御、スキーマベースの読み取り処理の公開、そしてコンテキストこそが真のボトルネックであるという認識の3点が核心となっている。
何が変わったか
従来のAIエージェント開発の議論は、どのLLMを使うか、どんなプロンプトを書くかといったモデル中心の話題に偏りがちだった。しかし本記事が示すのは、本番運用フェーズでは「エージェントに何をさせるか」よりも「エージェントに何を見せ、何を触らせないか」という設計の方が支配的な課題になるという転換である。Postmanはツールの数を無制限に増やすのではなく、スキーマを介した構造化された読み取りインターフェースを用意することで、エージェントの意思決定の不確実性を減らしている。また、長時間動作するエージェントほどコンテキストウィンドウの圧迫が致命的になるため、コンテキスト管理そのものをシステム設計の中心に据える必要があるという視点が明確に打ち出されている。
開発者への影響
自社サービスにAIエージェント機能を組み込もうとする開発者にとって、この事例は非常に実践的な指針となる。特にBtoB SaaSや開発者向けツールを提供する企業では、ユーザー数が数百万〜数千万規模になった時点で、デモで使っていた「とりあえず全部のAPIをツールとして渡す」というアプローチが破綻することが明示された形だ。ツールの設計をAPI仕様レベルから見直し、スキーマファーストでエージェントに公開するインターフェースを絞り込む設計思想は、今後のエージェント実装におけるベストプラクティスとして広く参照されるだろう。Amazon Bedrockを使う開発者にとっては、スケール運用時のアーキテクチャパターンとして直接活用できる情報でもある。
KusaBase視点の考察
KusaBase編集部として注目したいのは、この事例が「エージェントの賢さ」ではなく「エージェントの運用設計」にフォーカスしている点だ。多くのAIエージェント関連の報道はモデルの性能向上やベンチマークスコアに偏りがちだが、実際にプロダクトとして数千万人規模で稼働させる段になると、問題の本質はモデルではなくシステムアーキテクチャに移る。これはちょうど、Webアプリケーション開発が初期のプロトタイプ段階からスケーラブルな本番システムへ移行する際に直面する課題と酷似している。つまり「AIエージェント開発」は今や新しい分野というより、分散システム設計やAPI設計のノウハウが応用される領域になりつつあるということだ。日本国内でもエージェント機能を自社プロダクトに組み込む企業が増えているが、こうした地味だが重要な設計論点（ツール数の制御、コンテキスト予算管理）への関心はまだ薄い印象がある。モデル選定の議論以上に、こうした運用設計の知見こそ今後国内でも共有されるべきだろう。
今後の予測
今後、AIエージェントの実装に関する議論は「どのLLMが優秀か」という段階から「どう運用可能な形に設計するか」という段階へと重心が移っていくと予想される。特にツールの数が増え続けるMCP（Model Context Protocol）エコシステムの拡大とともに、Postmanが示したようなスキーマベースのツール公開やコンテキスト管理の手法は、デファクトスタンダードとして確立されていく可能性が高い。Amazon BedrockをはじめとするクラウドベンダーもAIエージェントの大規模運用を支援する機能やベストプラクティス集を今後さらに充実させていくとみられ、エージェント運用のためのオブザーバビリティやコンテキスト管理専用ツールの登場も加速するだろう。
