Amazon AWS、市場監視エージェントにガードレールを導入

Amazon AWSは7月28日、6つのエージェントから成る市場監視アーキテクチャを公開した。ただし、その中心的な狙いは自律性を拡大することではなく、制限することにある。このシステムはLangGraphで実行を制御し、Strandsで選択されたステップ内の推論を行い、Amazon Bedrock AgentCoreでワークロードをホストする。この役割分担は、1つの自律エージェントが調査全体を管理すべきだという考え方に異を唱えるものだ。

このリファレンスアーキテクチャは、要求の厳しい金融ワークフローを対象としている。専門エージェントが証券、ブローカー、リスクシグナル、外部インテリジェンスを調査し、その後に別のコンポーネントが調査結果を統合する。チェックポイントは各ワークフローノードの後に進行状況を保存し、共有状態が次に実行する専門エージェントを決定する。

真の対抗軸は、計画、推論、ツール、メモリー、実行を1つの不確実なループにまとめるモノリシックなエージェントだ。Amazon AWSは代わりに、明示的なルートを持つ状態機械の内部に、局所化されたモデル判断を配置する。その結果は、自律的なアナリストというより、監督された調査パイプラインに近い。

Amazon AWS、1つの調査を6つのエージェントに分割

重要な変化はアーキテクチャにある。AWSはワークフロー制御とエージェントの判断を異なるソフトウェア層に割り当てている。

公開されたサンプルは、オーケストレーター、4つの専門エージェント、そして統合エージェントで構成される。LangGraphは、実行をノードと条件付きエッジとして表現する有向グラフを通じて、これらのコンポーネントを接続する。Strandsは、関連する各ノード内で推論とツール利用のループを実行する。

オーケストレーターはまず、ユーザーの質問を解釈し、調査に必要な専門エージェントを特定する。また、各専門エージェントに対する具体的な割り当てを、共有ワークフロー状態に配置する。LangGraphはその後、選択されたエージェントを経由して実行をルーティングし、統合された出力を統合エージェントに送る。

この構造が重要なのは、エージェントがアプリケーション全体をどのように進めるかを独自に決めないからだ。証券モニターは、特定の証券と取引日における活動を分析できる。ブローカーモニターはより長期的な価格とリスクの傾向を調査し、リスクモニターはブローカー活動を評価する。

インテリジェンスエージェントは外部の市場コンテキストを加える。最終的な統合エージェントは、これらの個別の調査結果を1つの回答にまとめる。各専門エージェントは、拡大し続ける1つの会話履歴を引き継ぐのではなく、それぞれ固有のシステムプロンプト、ツール、焦点を絞ったコンテキストを受け取る。

AWSは、AAPLの価格急騰に関する市場監視の質問を通じてこの設計を提示している。ほかの例では、どのブローカーが活動していたか、あるいは異常なTSLA取引が関連ニュースと一致していたかを問う。こうしたシナリオには複数の分析視点が必要だが、すべてのリクエストで全エージェントを必要とするわけではない。

この区別は実用的な利点を生む。グラフは、オーケストレーターが選択した専門エージェントだけを呼び出せる。また、現在実行中のエージェントと、すでに存在する出力を記録できる。

このサンプル実装により、設計を詳しく確認できる。共有状態には、元のクエリ、必要なエージェント、現在位置、専門エージェントの調査結果、最終統合結果が含まれる。リポジトリでは、デプロイメントファイル、エージェント定義、ツール、Streamlitクライアントも公開している。

ただし、このリポジトリは本番性能の証拠ではなく、リファレンス実装である。市場レコードは2024年3月の3銘柄を対象とするインメモリーのモックデータだ。列挙されるブローカー名は架空であり、プロジェクトは精度やレイテンシーのベンチマークを公開していない。

この制約がアーキテクチャ上のシグナルを消すわけではない。Amazon AWSは、顧客が実データを接続する前に、マルチエージェントアプリケーションをどのように分割すべきだと考えているかを企業に示している。次の問いは、なぜその分割が、より広範な自律性よりも明示的なオーケストレーションを優先するのかということだ。

このアーキテクチャはモノリシックなエージェントを退ける

AWSは、制約のないエージェントの自律性を本番運用上のリスクとみなしている。特に、調査で再現可能なステップと復旧可能な状態が求められる場合はそうだ。

モノリシックなエージェントは通常、広範な目標を受け取り、ツールを選び、結果を解釈し、計画を修正し、作業完了のタイミングを判断する。このアプローチは探索的なタスクでは有効に機能し得る。しかし、すべての判断が後続の実行を変える場合、統制は難しくなる。

市場監視では、この弱点がすぐに表面化する。調査には取引記録、価格変動、ブローカーの行動、板情報、リスクスコア、公開情報が組み合わされる可能性がある。終盤で発生した失敗によって、それまでのすべてのクエリやモデル呼び出しを繰り返す必要があってはならない。

また、単一のコンテキストにツール出力が蓄積されるにつれ、指示の品質が低下する場合もある。エージェントが制約を見落としたり、2つの分析的役割を混同したり、無関係な情報を後続の推論に渡したりする可能性がある。履歴が大きくなるほど、デバッグと評価の両方が難しくなる。

新しいLangGraphとStrandsによるエージェント設計は、この不確実性を狭める。低レベルのオーケストレーションフレームワークであるLangGraphが、アプリケーションのルートと共有状態を担う。エージェントSDKであるStrandsは、境界を定めたノード内でモデル推論とツール利用を提供する。

LangGraphは、自身のアプローチを制御とエージェンシーのバランスを取るものと説明している。そのオーケストレーションモデルは、カスタマイズ可能な制御フロー、永続メモリー、ストリーミング、人によるレビューをサポートする。これらの機能は、停止、分岐、または継続前の承認を必要とする調査に適している。

グラフは依然として動的な振る舞いを許容する。オーケストレーターはリクエストに応じて専門エージェントを選択し、各Strandsエージェントは割り当てられたタスクについて推論する。ただし、その自由はアプリケーションが検査し、制約できるルートの内部に置かれている。

ここに本稿の中心的な緊張関係がある。完全自律型のエージェントは、モデルが計画を決めるため、アプリケーションコードを単純化できると約束する。AWSの設計は、より明確な状態、より狭いコンテキスト、識別可能な障害境界を得るために、より明示的なワークフローコードを受け入れる。

どちらのルートも不確実性をなくすわけではない。LangGraphノードも、弱い結論を出したり、不適切なツールを選択したり、取得データを誤読したりする可能性がある。明示的なルーティングは、その失敗の位置と結果を特定しやすくするだけだ。

このアーキテクチャはエンジニアリング上の負担も生む。チームは状態フィールド、ノード契約、ルーティング動作、専門エージェントのプロンプト、マージロジックを定義しなければならない。調査を変更するには、1つの汎用プロンプトではなく、複数のコンポーネントにわたる更新が必要になる場合がある。

Amazon AWSは実質的に、プロセスが運用面またはコンプライアンス上の影響を伴う場合、この負担は正当化されると主張している。これは、マルチエージェントシステムにより多くのエージェントが必要だと言う以上に強い主張だ。つまり、本番AIにはモデル判断を囲むソフトウェア上の境界が必要だということである。

したがって、圧力は汎用の自律エージェントを構築するチームにかかる。より広範なエージェンシーが、復旧、評価、制御を難しくするコストを相殺するだけの価値をもたらすことを示さなければならない。規制対象のワークフローでは、利便性だけでこの比較に決着はつかない。

LangGraphとStrandsはどのように作業を分担するか

この組み合わせが機能するのは、LangGraphが推論をどこで行うかを決め、Strandsがその境界のある場所で何を行うかを決めるためだ。

ワークフローは型付けされた共有状態から始まる。そこにはユーザークエリ、セッション識別子、専門エージェントの割り当て、必要なエージェント、現在のルーティング位置、各エージェントの調査結果が保存される。ノードは部分更新を返し、LangGraphがそれらを状態にマージする。

条件付きエッジは、オーケストレーターと各専門エージェントの後に状態を検査する。選択された専門エージェントがまだ残っていれば、実行はそこへ移る。リストが完了すると、グラフは統合エージェントへルーティングされ、その後終了する。

この仕組みにより、システムは可視化された実行モデルを得る。オペレーターは、どのノードが完了したか、何を返したか、どのルートが続いたかを確認できる。これは、1つのエージェントの会話トランスクリプトから暗黙の計画を再構成するよりも具体的だ。

各ノード内のStrandsエージェントは、独立した推論とツール利用のループを実行する。ノードに割り当てられたタスクを受け取り、許可されたツールを呼び出し、その結果を解釈し、最終回答をストリーミングする。次にノードは、その回答を適切な状態フィールドへ書き込む。

コンテキストの分離はこの設計の中心だ。証券モニターは、インテリジェンスアナリストに利用可能なすべての指示やツールを必要としない。各専門エージェントにより狭いコンテキストを与えることで、無関係な選択肢を減らし、あるエージェントの履歴が別のエージェントに与える影響を抑えられる。

ツール設計はさらに別の境界を加える。サンプルは、レポートの探索、スキーマ取得、レポート実行を分離している。エージェントはまず許可されたレポートを発見し、次に許可されたフィールドを取得し、最後に検証済みパラメーターを送信する。

公開例では、モデルが任意のSQLを書くことはない。アプリケーションコードが選択されたレポートスキーマに対してフィルター名を確認し、パラメーター化されたクエリを作成する。未知のフィールドは拒否され、結果件数の上限は定義された範囲内でなければならない。

これはプロンプトインジェクションやデータ汚染を排除するものではない。信頼できないモデル出力が、制約のないデータベースクエリになる経路の1つを減らすものだ。実際のデプロイでは、依然としてアイデンティティ制御、認可、データ分類、出力検証が必要になる。

サンプルではAmazon Bedrockを通じてAnthropic Claudeモデルを設定しているが、Strandsはフレームワークレベルではモデルに依存しない。その公開agent SDKは、ツール、モデルプロバイダー、マルチエージェントパターン、セッション管理、可観測性統合をサポートしている。

このフレームワーク選択はAWSにとって興味深い立場を与える。既存のオーケストレーション層を使うLangGraph顧客に放棄を求めることなく、Strandsによる推論を推進できる。AgentCoreも複数のフレームワークをサポートしているため、ホスティングサービスがこの組み合わせに依存するわけではない。

この分割は、アプリケーション制御と確率的推論をすでに分離しているチームにとって、特に魅力的かもしれない。そうしたチームは、各Strandsノードを特化した分析関数として扱える。グラフを別のシステムとして評価しながら、その入力と出力をテストできる。

エージェントはワークフロー状態とモデル駆動の振る舞いを共有するため、これは従来型のマイクロサービス設計ではない。それでも同じ原則が見られる。小さなコンポーネントは、より明確な契約と障害ドメインを生み出す。代償は、調整コードと維持すべきインターフェースの増加だ。

こうした契約を文書化するエンジニアにとって、検索可能なエンジニアリングナレッジベースは、プロンプト、スキーマ、評価、運用上の判断を結び付けられる。複数の専門エージェントが共有状態の定義に依存する場合、この文書化は重要になる。

チェックポイントが復旧をワークフロー機能に変える

チェックポイントベースの復旧は、単一のモデル呼び出しの外部に調査状態を保持するため、このアーキテクチャにおける最も強力な本番運用上の論拠だ。

LangGraphは、各ノードの完了後にチェックポイントを保存できる。チェックポイントには、過去のメッセージ、ノード出力、実行メタデータ、ワークフロー内の位置など、グラフの現在状態が記録される。アプリケーションは後から、その保存された地点から再開できる。

AWSの例では、AgentCoreMemorySaverがLangGraphのチェックポイントをAgentCore Memoryに接続する。グラフはそのチェックポインターを使ってコンパイルされ、各呼び出しにはスレッド識別子とアクター識別子が渡される。これらの識別子は、保存された状態を特定のセッションとユーザーに関連付ける。

専門エージェントが、先行するエージェントの完了後に失敗した場合でも、ワークフローは直近のチェックポイントから再開できる。すべての先行調査結果を新たなモデル呼び出しで再構築する必要はない。これにより、完全な再実行時の重複作業を減らし、異なる回答が混入することを避けられる。

チェックポイントは、アナリストの介入にも対応する。ワークフローは機微なステップの後で一時停止し、レビューのために中間状態を公開し、承認後に再開できる。これにより、人間によるレビューは、エージェントとの場当たり的な対話ではなく、明示的な状態遷移となる。

長時間に及ぶ調査も同じ仕組みから恩恵を受ける。案件は、新しい情報、外部承認、または一時的に利用できないサービスを待つ場合がある。永続化されたグラフ状態があれば、単一のプロセスを途切れなく動かし続けなくても、その待機に対応できる。

AgentCore Memoryは、短期的なワークフローチェックポイントに加えて、もう一つの概念を導入する。そのメモリストアは、やり取りをまたいで長期的な情報を抽出・取得できる。AWSは、各セッションをコンテキストなしで始めるのではなく、洞察や設定を保持するための手段だと説明している。

チームは、これらの役割を混同すべきではない。チェックポイントは、特定のグラフ実行を復旧するために存在する。長期記憶は、後続のやり取りに選別された情報を提供する。明確な保持ルールなしに両者を組み合わせると、プライバシー、関連性、ガバナンスの問題を引き起こしかねない。

Amazon Bedrock AgentCoreは、ワークフローを取り巻くマネージドランタイムを提供する。アプリケーションはAgentCore SDKでエントリポイントをラップし、その後コンテナ化したエージェントをデプロイする。Runtimeは、セッション分離、スケーリング、認証の仕組み、監視統合を提供する。

このサービスはフレームワークに依存しない。AgentCore documentationによれば、RuntimeはLangGraph、Strands、CrewAI、LlamaIndex、Google ADK、その他のエージェントフレームワークをホストできる。また、Amazon Bedrockの内外を問わずモデルをサポートする。

この柔軟性は競争の構図を変える。AWSは、開発者にあらゆるフレームワークを単一の垂直統合スタックへ置き換えるよう求めているわけではない。チームが選ぶオーケストレーションおよび推論ツールの下位で動く運用レイヤーとして、AgentCoreを位置付けている。

ただし、マネージドホスティングだけでアプリケーションが本番対応になるわけではない。チームは依然として、プロンプト、ツール権限、状態スキーマ、評価基準、ビジネスロジック、データアクセスを管理する責任を負う。どの障害をリトライ対象とし、どの障害に人間のレビューを要するかも決めなければならない。

復旧は、良い状態と同じ忠実さで悪い状態も保持しうる。初期の専門エージェントが裏付けのない結論を保存した場合、後続ノードは再起動のたびにそれを前提として処理を進める可能性がある。チェックポイントには、検証ゲート、バージョニング、古い状態や安全でない状態を無効化するポリシーが必要だ。

したがって、この設計は一つの信頼性問題を、より管理しやすい複数のエンジニアリング上の判断へと変換する。実行を再開し、検査するための場所を提供する。しかし、保存された推論が信頼に値するかどうかは判断しない。

可観測性は役立つが、コンプライアンスを証明するものではない

このサンプルはトレーサビリティを向上させるが、結果として得られる監視判断が、規制対象機関の正確性やガバナンス要件を満たすことを示す証拠はない。

AgentCoreは、監視のためにAmazon CloudWatchおよびAWS X-Rayと統合される。LangGraphはOpenTelemetryイベントを出力でき、Strandsはエージェントおよびツールの活動を対象とした計装をサポートする。これらのシグナルを組み合わせることで、ワークフローのルートを個々のモデルおよびツール操作と結び付けられる。

AWSのドキュメントによれば、AgentCore Runtimeは呼び出し、セッション、レイテンシ、スロットル、エラーメトリクスを公開する。CPUとメモリの消費量も報告できる。構造化されたスパンは、ランタイムリクエスト、セッション、エンドポイント、レイテンシ、リージョン、エラーカテゴリーを特定する。

この可視性は、運用担当者が実務的な問いに答える助けとなる。遅い専門エージェントを見つけ、スロットルされたモデル呼び出しを特定し、セッション間のリソース使用量を比較できる。また、結果を生成する前にエージェントがどのツールを呼び出したかも追跡できる。

observability guideは重要な留保を加えている。Runtimeでホストされるエージェントには自動的にOpenTelemetry計装が適用されるが、チームはCloudWatch Transaction Searchを設定しなければならない。一部のメモリログおよびトレースには追加設定が必要となる。

運用テレメトリは、意思決定の品質と同じではない。完全なトレースは、誤った結論がどのように生じたかを示せるが、その結論を許容可能にするわけではない。監視チームには、見逃したシグナル、誤警報、裏付けのない主張、一貫性のない分類を対象とする評価データが必要だ。

このサンプルは、それらの測定値を一切公表していない。適合率、再現率、偽陽性率、復旧成功率、エンドツーエンドのレイテンシ、モデルコストを報告していない。また、6エージェントのワークフローを単一のモノリシックなエージェントとも比較していない。

データの制約も同様に重要だ。このリポジトリは、AAPL、MSFT、TSLAについて1か月分のモックレコードを使用している。これは再現可能なデモンストレーションを支えるが、分断された実際の市場、変化する手口、不完全な記録、機関固有の統制を近似するものではない。

外部インテリジェンスエージェントは、別の不確実性をもたらす。公開ウェブ上の情報には、虚偽の主張、操作されたナラティブ、自動分析に影響を与えることを目的としたコンテンツが含まれうる。本番システムには、ソースポリシー、来歴追跡、間接的なプロンプトインジェクションへの防御が必要となる。

シンセサイザーは、さらなる集中点を生み出す。専門エージェントの所見を受け取り、最終回答を生成するため、統合時のエラーが本来は正確な作業を歪める可能性がある。チームは各専門エージェントと統合レポートの両方を評価しなければならない。

メモリもガバナンス上の問題を提起する。保存された状態には、市場データ、アナリストのID、調査の詳細、機微な結論が含まれる可能性がある。保持期間、アクセス制御、リージョン要件、削除手順、監査責任には、明確な責任主体が必要だ。

モデルの推論は、アップグレード後に変わる可能性もある。グラフとプロンプトが一定でも、新たに構成されたモデルが証拠を異なる形で解釈することがある。そのため、モデル、プロンプト、ツール、スキーマ、ルーティングロジックへの変更には、バージョン管理された評価を伴わせるべきだ。

Amazon AWSのアーキテクチャでは、コンポーネントの境界が可視化されているため、このようなテストを容易に行える。チームは固定された状態に対して一つのノードを再実行したり、保存された専門エージェントの所見を用いてシンセサイザーの出力を比較したりできる。それでも、公表されたプロジェクトはその評価プログラムを実証していない。

これが中心となる懐疑的な論点だ。AWSが提供したのは信頼できる本番用の基盤であり、検証済みの市場監視製品ではない。企業は「本番対応」を、依然としてドメイン固有の統制と測定された証拠を必要とするアーキテクチャ上の目標として読むべきだ。

次のAgentCoreデプロイメントが証明すべきこと

次の段階は、実データ、再現可能な評価、そしてフレームワークの柔軟性がエンタープライズガバナンスの下でも維持されるという証拠によって判断される。

最初のシグナルは、代表性のある金融データを用いたデプロイメントである。信頼できる事例であれば、認証済みのデータソースに接続し、機関固有の権限を強制し、現実的な市場環境で稼働するだろう。また、アナリストがどのようにアラートをレビューし、解決するかも文書化する必要がある。

チェックポイントによる復旧が、無効な所見を保持せずに重複作業を削減できるなら、そのようなデプロイメントはAWSの主張を強める。また、専門エージェント間の境界が、調査の品質または運用効率を向上させることも示す必要がある。測定可能な成果を伴わない非公開パイロットの主張では、ほとんど意味がない。

第二のシグナルは、アーキテクチャを比較する公開評価だ。チームには、同一タスクにおけるLangGraphおよびStrandsのエージェントパターンと、モノリシックなエージェントの比較に関する証拠が必要である。有用な指標には、裏付けのない主張、ツールエラー、ルーティングミス、見逃した証拠、復旧挙動、アナリストによる修正が含まれる。

好ましい比較結果は、決定論的なオーケストレーションがモデルの不確実性を抑制するという主張を支える。中立的な結果は、追加された状態管理とルーティングコードの価値が限定的であることを示唆する。より悪い結果であれば、より大きなアーキテクチャ上の複雑性を受け入れる主な理由を弱めることになる。

第三のシグナルは、AgentCore、LangGraph、Strands間におけるより深い相互運用性だ。フレームワーク非依存のホスティングは魅力的に聞こえるが、本番システムは安定したチェックポイント形式、テレメトリの規約、ID伝播、アップグレード時の挙動に依存する。

3つのプロジェクトすべてが進化するなかで、統合が維持され続けるかを注視すべきだ。また、顧客がガバナンス統制を再構築せずにモデルやエージェントフレームワークを変更できるかも見守る必要がある。デモコードを超えてポータビリティが機能すれば、AgentCoreはより説得力のある運用レイヤーとなる。

開発者は、サンプルをコピーする前にその境界も検討すべきだ。スキーマ検証済みのクエリツールは有用なパターンを示すが、モックレポートは完全な監視データモデルを表していない。デフォルトのプロンプトと専門エージェントの役割は出発点であり、コンプライアンス統制ではない。

エンタープライズの購買担当者は、各意思決定の境界を誰が担うのかを問うべきだ。グラフは調査をルーティングし、モデルは証拠を解釈し、AgentCoreは状態を保持するかもしれない。これらのレイヤーのいずれも、最終結論に対する説明責任を自動的に割り当てるものではない。

ナレッジワーカーにとっても重要なのは、同じアーキテクチャが金融以外にも適用できることだ。文書レビュー、カスタマーサポート、コンプライアンス分析、リサーチのワークフローも、固定された手順と不確実な判断を組み合わせている。組織が推論を許可する場所と、決定論的な統制を要求する場所が問われる。

したがってAmazon AWSにとって、市場監視エージェントは一つの疑わしい取引を検出することより、エンタープライズ向けエージェントパターンを定義することにある。モデルの判断の周囲に明示的なソフトウェア構造を置き、その構造を稼働させ続けるためにマネージドメモリとテレメトリを活用する。

このパターンが有望なのは、障害の発生箇所を可視化し、復旧を意図的に行えるようにするためだ。公開された証拠がモックデータとアーキテクチャ上の主張にとどまるため、その限界も同様に明確である。本番での採用は、顧客が測定された成果を公表するかどうかにかかっている。

この設計を採用する前に、重要なワークフローを一つ選び、許容できる障害時の挙動を定義してほしい。次に、専門化されたエージェント、チェックポイント、トレースが、より単純なベースラインと比べてそのワークフローを改善するかをテストする。真にモデルの推論を必要とする判断はどれで、どの判断をコード内で固定したままにすべきだろうか。