Amazon Bedrock AgentCore Ambient Agents、AIをチャットプロンプトの先へ
Amazonは2026年10月1日、人がプロンプトを入力するのを待たずにAIエージェントがイベントへ反応できるリファレンスアーキテクチャを発表した。Amazon Bedrock AgentCoreのアンビエントエージェントパターンは、Amazon S3へのアップロードまたはスケジュールイベントを追跡可能なジョブに変換する。その後、エージェントを自動実行することも、人によるレビューのためにジョブを保留することもできる。
この変更は、チャットベースのエージェントにある基本的な制約を対象としている。チャットボットは曖昧さを解釈できるが、誰かがイベントに気づき、インターフェースを開き、何が起きたかを説明しなければならない。従来のワークフローエンジンは即座に反応するものの、事前定義された分岐に従うため、未知の文書や不明瞭なアラートを自律的に推論することはできない。
AWSはAgentCoreをこの2つのアプローチの中間に位置付けている。この設計はイベント駆動型インフラストラクチャとモデルベースの推論を組み合わせ、承認、質問、結果、エラーを確認できる単一のJobsページをレビュー担当者に提供する。最も重要な主張は完全な自律性ではない。イベント駆動型エージェントを実用的にしながら、重要な判断から人を排除しないために、制御された単一の中断メカニズムが役立つという点だ。
Amazon Bedrock AgentCore Ambient Agents、イベントをジョブに変換
イベントがプロンプトとなり、永続的なジョブレコードが運用上の制御点となる。
アンビエントエージェントのアーキテクチャは、別のシステムからのシグナルで始まる。付属する文書シナリオでは、ファイルが到着するとAmazon S3がオブジェクト作成通知を発行する。Signal Processor関数はそのイベントを受け取り、設定済みのシグナルがバケットとオブジェクトパスに一致するかを確認する。
一致するたびに、Amazon DynamoDB内にジョブが作成される。そのジョブには、関連するイベント詳細や識別子を含め、エージェントを呼び出すために必要なコンテキストが格納される。Amazon SQSはジョブの受け付けと実行を分離するため、モデルが入力を分析している間もパブリックAPIは開いたままにならない。
Job Execution関数はキューに入った作業を読み取り、AgentCore Runtime上でホストされたエージェントを呼び出す。結果はDynamoDBに戻され、フロントエンドが取得できる。Amazon S3およびAmazon CloudFrontを介して配信されるReactインターフェースは、統合されたJobsページで状態を表示する。
このサンプルにはスケジュールされた作業も含まれる。スケジューラーは毎分、期限が到来したジョブを確認し、イベント起点のタスクと同じSQSキューへ投入する。この共通の実行経路により、運用担当者が維持すべき異なるオーケストレーションパターンの数を減らせる。
AWSはリファレンス実装でS3およびスケジューリングの経路を提供している。Webhookやデータベース変更は、完成済みの統合ではなく拡張ポイントだ。これらのソースからジョブを作成するには、チームがハンドラー関数と設定フィールドを追加する必要がある。
この区別は重要である。なぜなら「アンビエント」は普遍的なイベントコネクターではなく、インタラクションパターンを表すからだ。リファレンスシステムは再利用可能な受け付け、状態管理、実行、レビューのコンポーネントを提供する。しかし、組織内のあらゆるイベントソースを自動的に理解するわけではない。
シグナルには、初期の自律性レベルを決めるautoExecute設定が含まれる。デフォルトのfalseでは、人が開始するのを待つアイドル状態のジョブが作成される。trueに設定すると、ジョブは直接ワーカーキューへ送られる。
これは実用的な導入経路を提供する。チームはレビュー優先の運用から始め、エージェントの挙動を検証したうえで、慣れたケースを後から自動化できる。初回のデプロイ時に広範な自律性を付与する必要はない。
このアーキテクチャは、繰り返し失敗する作業向けにSQSデッドレターキューも使用する。このキューは不可欠である。イベント駆動型エージェントは、セッションを見守るアクティブユーザーがいないまま、不正な入力、権限不足、利用できないモデル、コード障害に遭遇しうるからだ。
その結果は、別のアシスタントウィンドウというより運用システムに近い。イベントが到着し、ジョブが状態を持ち、ワーカーが処理し、例外が可視化される。推論は製品全体ではなく、そのシステム内の1つの段階となる。
より良いチャットから、より速い対応へと圧力が移る
エージェント開発者は、継続的なプロンプトなしにシステムが作業を検知し、統制し、完了できることを示すよう求められる。
チャットは探索的な質問や直接的な協働には引き続き適している。しかし、あらゆるワークフローに人による検知のステップを追加する。エージェントが支援する前に、誰かが新しい文書に気づき、アラートを認識し、あるいは予定されたレビューを思い出さなければならない。
この遅延は、文書受け付け、コンプライアンスレビュー、インフラストラクチャ監視、定期分析では大きなコストとなる。モデルは割り当てられた推論をすばやく終えられるかもしれないが、誰も会話を開始していないため、周辺プロセスは何時間も待機しうる。
アンビエントエージェントはこの順序を逆転させる。インフラストラクチャが先にイベントを検知し、モデルは構造化されたジョブを自動的に受け取る。人が関与するのは、ポリシーまたは不確実性によって判断が必要になる場合だけだ。
これは、会話をトリガーとワークスペースの両方として扱うチャット優先のエージェント製品に圧力をかける。バックグラウンド活動を支援するには、APIの背後にチャットボットを隠すだけでは不十分だ。製品には永続的な状態、リトライ処理、セッション分離、アクセス制御、そして人が保留中の判断を確認できる場所が必要になる。
従来のワークフローシステムは別の圧力に直面する。すべての分岐が決定論的である場合、AWS Step Functionsや類似のオーケストレーターは依然としてより適した選択肢だ。その実行は予測可能で、検査しやすく、モデル駆動の判断よりテストも容易である。
一方、受信した素材に意味的な解釈が必要になると、それらは使いにくくなる。固定されたワークフローはフィールドの存在を検証できるが、追加のロジックなしに、曖昧な契約条項をすべて確実に判断したり、馴染みのない運用アラートを説明したりすることはできない。
したがってAgentCoreの提案は、確立された2つの経路に同時に挑戦する。推論エージェントには自動起動を加え、イベントパイプラインには柔軟な解釈を加える。信頼できる市場は、会話だけでも厳格なステートマシンだけでも問題全体を解決できない領域だ。
とはいえ、トリガーされるすべてのタスクがエージェントタスクになるわけではない。ファイル変換、スキーマ検証、固定された承認チェーンは、通常は決定論的なままにすべきだ。言語モデルを加えても必要な判断をもたらさず、レイテンシー、変動性、運用コストを増やすことになる。
より適切な境界は曖昧さにある。次のステップが入力の意味、不完全なコンテキスト、または開発者が安定したルールに還元できない評価に依存するとき、エージェントは有用になる。
エンジニアリング組織にとって、この境界はプラットフォーム要件を変える。チームは、キュー、アイデンティティポリシー、ジョブレコード、障害状態と並行して、プロンプトとツールを管理する必要がある。また、エージェントの推奨を調査するレビュー担当者にとって、検索可能なエンジニアリングナレッジベースが重要になるように、永続的な技術コンテキストも必要だ。
したがって、この圧力は技術面だけでなく組織面にも及ぶ。プロダクトチームは、どのイベントに推論の価値があるか、どの判断に承認が必要か、どのアクションをエージェントに決して利用可能にしてはならないかを決めなければならない。こうした選択が、アンビエント自動化が作業を減らすのか、それともより速いレビュー依頼の流れを作るだけなのかを左右する。
1つの人間向けツールがコントロールプレーンを簡素化する
AWSは人との対話を1つの`ask_human`ツールに集約するが、その周囲にあるジョブ状態がこの単純なインターフェースに運用上の意味を与える。
リファレンスエージェントは、質問、承認要求、結果報告、エラー表示のために別々のツールを実装していない。実行に人が必要になるたびにask_humanを呼び出す。文言とジョブ状態が、レビュー担当者が何をすべきかをインターフェースに伝える。
応答は、エージェント間で共有される標準的な応答構造である正規のエンベロープに従う。そのステータスはcompleted、interrupted、またはerrorである。対応するペイロードには、結果、質問、またはエラーの説明が含まれる。
各応答にはセッション識別子とジョブ識別子も含まれる。これらの値により、プラットフォームは後続の入力を正しい実行に結び付けられる。これらはエージェントの基盤となるビジネスロジックの要件ではなく、相関メタデータである。
応答がinterruptedの場合、プラットフォームはジョブをその状態としてマークし、requiresActionをtrueに設定する。Jobsページは、その項目を警告インジケーター付きでInterruptedタブに表示する。レビュー担当者は別個の承認受信箱を監視する必要がない。
AWSは、この契約の上に構築された4つの対話規約を説明している。通知は結果を報告する。質問は不足情報を尋ねる。レビュー要求はアクションを提案し、承認、却下、または修正を求める。エラーは失敗を記録し、人が再試行するかどうかを判断できるようにする。
これらは4つのランタイムモードではなく、表示上の規約である。プラットフォームには依然として1つの中断経路と1つの応答エンベロープしかない。このため、周辺システムがフレームワーク固有の制御オブジェクトではなく小さな契約に依存するため、エージェントフレームワークを交換可能にできる。
この設計は、特にレビュー要求で有用だ。エージェントは文書を検査し、分類または後続アクションを提案し、外部システムを変更する前に停止できる。レビュー担当者は会話履歴とともに提案を確認し、承認または軌道修正できる。
これは、すべてのタスクの後に承認ステップを挿入するより強力な制御である。必須レビューは監督を維持するが、時間面での利点の大部分を失わせる。条件付きの中断は、低リスクのジョブを完了させつつ、不確実または重要なケースを人へ回すことができる。
難しいのは、エージェントがいつツールを呼び出すべきかを決めることだ。システムプロンプトは承認の境界を説明できるが、指示だけで完全なセキュリティメカニズムにはならない。影響の大きいツールは、モデルの外側でも認可とポリシーを強制すべきである。
AgentCore Identityは、エージェント向けのワークロードアイデンティティと認証情報管理を通じて、この要件の一部に対応する。AWSによれば、そのエージェントアイデンティティ管理は、監査証跡を維持しながらAWSリソースおよびサードパーティサービスへのアクセスを統制できる。
チームはそれでも、各エージェントの権限を最小限に抑えるべきだ。文書を読むだけのアナライザーに、ソースバケットを変更する権限は不要である。チケット更新を提案するエージェントにも、両方のアクションが同じワークフローを共有しているというだけで、本番デプロイの認証情報を与えるべきではない。
単一ツールのアプローチには、ユーザー体験上のリスクもある。エージェントが頻繁に中断すると、Jobsページは別の過負荷キューになる。中断が少なすぎると、実行後になって初めて人が危険または誤ったアクションに気づく可能性がある。
そのため、有用なヒューマン・イン・ザ・ループのワークフローには、測定可能なエスカレーションポリシーが必要となる。チームは、レビュー担当者がどの質問に答えているか、提案をどの程度却下しているか、類似のジョブが同じ確認を繰り返し求めていないかを追跡する必要がある。こうしたシグナルは、エージェントが安定したプロセスを学んでいるのか、それとも不確実性を従業員へ移しているのかを示す。
仕組みはキュー、ステートストア、隔離されたランタイム
モデルは判断を担うが、Amazon Bedrock AgentCoreのアンビエントエージェントの信頼性は、一般的な分散システムコンポーネントに依存している。
Amazon SQS は、ジョブ送信とモデル実行を分離します。その役割は見た目だけのものではありません。キューイングにより、エージェントの完了前に API が応答でき、流入イベントの急増を吸収し、失敗したメッセージに明確な再試行経路を与えます。
Job Execution Lambda 関数には、2 つの起動経路があります。API リクエストは作業をキューに投入し、SQS イベントソースはワーカー側を呼び出します。ワーカーは保存済みのコンテキストを使って AgentCore Runtime を呼び出し、その応答を DynamoDB に書き戻します。
この共有関数により、手動ジョブとアンビエントジョブは単一の実行経路に集約されます。そのため、インターフェースから開始されたジョブと S3 シグナルによって作成されたジョブは、同じランタイム契約に到達できます。これにより、テスト時と自動運用時の振る舞いの差異が抑えられます。
DynamoDB は最終回答だけを保存するものではありません。このサンプルでは、エージェントレジストリ、ジョブ、シグナル定義、チャットスレッド、会話履歴、冪等性レコードに使用されています。冪等性により、同一イベントが繰り返し配信されても、同じ副作用が意図せず二度発生することを防ぎます。
会話メッセージでは、list_append を用いたアトミックな DynamoDB 更新が使われます。複数のプロセスがほぼ同時にジョブへ書き込む場合、アトミック更新は重要です。これがなければ、ワーカーとレビュアーが互いの履歴への追記を上書きしてしまう可能性があります。
AgentCore Runtime は、分離されたコンテナ内でエージェントコードをホストします。サンプルでは Amazon Bedrock 経由で Anthropic Claude Sonnet 4.5 をデフォルトとして使用しますが、AWS によれば、開発者はモデル識別子を変更し、別の互換性のあるツール呼び出しモデルを利用できます。
これは、フレームワーク非依存という主張を補強します。運用上のインターフェースはエージェントの外側に置かれ、エージェント内部のフレームワークやモデルは変更できます。このアーキテクチャは、特定のオーケストレーションライブラリよりも、呼び出しと応答の契約に強く依存しています。
リファレンス実装では、個々のエージェントターンを Lambda の 15 分間の実行制限内に収めています。これは、AgentCore Runtime がより広くサポートする長時間実行の作業と同じではありません。これはサンプルの Lambda ワーカーパスによって導入された制約です。
AWS は、初期応答後も継続できる非同期 AgentCore タスクを別途文書化しています。Runtime のヘルス状態では、アイドル状態のセッションとバックグラウンド作業を処理中のセッションが区別されます。ビジー状態のセッションは、通常のアイドルタイムアウトを超えてアクティブなまま維持できます。
この違いは、本番環境向けの適応では重要になります。1 回の Lambda 呼び出し内で完了する文書分析はサンプルに適合します。数時間続くリサーチプロセスには、非同期設計、チェックポイント、あるいは別の実行境界が必要です。
サンプルのフロントエンドは、更新情報を取得するために API Gateway と Lambda の管理レイヤーをポーリングします。5 つの管理関数が、エージェント、ジョブ、シグナル、チャット、会話を公開します。別のワーカーがチャット実行を非同期で処理するため、チャット向け API 呼び出しは迅速に応答できます。
これは単一エージェントのデプロイではなく、本格的なアプリケーションです。ユーザーアクセスのための Amazon Cognito、CloudFront 配信、API エンドポイント、テーブル、キュー、関数、ストレージ、コンテナイメージ、ランタイムリソースが含まれます。
この広がりは利点である一方、注意点でもあります。チームは、デモで省略されがちな地味なインフラまでカバーした具体的なパターンを得られます。同時に、単純なチャットボットより多くのコンポーネント、権限、ログ、障害モードも引き継ぐことになります。
このアーキテクチャは、多数のジョブのためのコントロールプレーンとして捉えると最も説得力があります。セッション分離により同時発生するイベントは互いに分離され、ジョブ識別子は永続的な追跡を可能にします。Jobs ページは、エージェントやトリガーの種類をまたぐ共通インターフェースとなります。
人によるレビューは本番リスクを取り除かない
レビューボタンはリスクを下げますが、正しい推論、完全なコンテキスト、安全な操作、または適時の監督を保証するものではありません。
AWS は、最小権限の IAM 権限、暗号化、CloudTrail ロギング、さらに詳細なライフサイクル監査のための任意の DynamoDB ストリームを推奨しています。また、調査結果がレビュアーに届く前、またはアクションが進む前に Amazon Bedrock Guardrails を適用することも提案しています。
これらの制御は役立ちますが、アンビエントな運用は攻撃対象領域を広げます。アップロードされた文書には、モデルの誘導先を変更しようとする悪意ある指示が含まれる可能性があります。これは一般に間接プロンプトインジェクションと呼ばれます。信頼できないファイルを自動処理することは、この脅威を通常の受け入れ経路の一部にします。
エージェントは文書内容を権限ではなくデータとして扱うべきです。ツールポリシーは、ファイル内のテキストが権限を拡大したり、承認ルールを変更したり、認証情報を選択したりすることを防がなければなりません。機密性の高い操作には、モデルが生成した推論の外部で検証が必要です。
イベントの重複も懸念事項です。S3 通知とキューは耐障害性のある配信パターンをサポートしますが、耐障害性のある配信は同じイベントを複数回受信することを意味し得ます。冪等性レコードはジョブ作成だけでなく、エージェントがトリガーできるあらゆる外部アクションを対象にする必要があります。
人によるレビューも、誤った安心感を生むことがあります。レビュアーは元の文書を開かずに、もっともらしい要約を承認するかもしれません。特に大半の推奨が定型的に見える場合、ジョブ量の増加は迅速な確認を促しかねません。
責任あるデプロイでは、提案された各アクションの根拠を示す必要があります。レビュアーは、ソース資料、抽出された事実、要求された権限、予想される効果を確認できるべきです。顧客、資金、アクセス、規制対象データに関わる判断では、承認ボタンだけでは不十分です。
運用チームは、停滞した中断への対応も計画しなければなりません。人を無期限に待つジョブは、ランタイムが正しく動作していても完了とは言えません。サービスレベル目標には、レビュー待機時間、エスカレーション、再割り当て、最終的なキャンセルを含めるべきです。
作業が直接的なユーザー監督なしに始まると、可観測性は極めて重要になります。AWS によれば、AgentCore observabilityは、セッション、レイテンシ、実行時間、トークン使用量、エラーに関する CloudWatch メトリクスを公開します。計装されたアプリケーションは、個々のステップを示すトレースを追加できます。
それでも、これらのメトリクスにはビジネス上のコンテキストが必要です。エラー率が低いからといって、分類が正しいとは限りません。チームは、レビュアーの却下率、繰り返される追加確認リクエスト、重複アクション、見逃されたエスカレーション、完了後に行われた修正を測定すべきです。
コストも予想外の形で増える可能性があります。イベントソースが突然の急増を生んだり、広すぎるプレフィックスルールによって無関係なファイルがモデルに送られたりするかもしれません。予約済み Lambda 同時実行数は下流の呼び出しを制限でき、S3 通知フィルターは明らかに無関係なトラフィックを減らせます。
リファレンスアーキテクチャでは、古い会話を期限切れにする DynamoDB の TTL 設定と、処理済み文書の S3 ライフサイクルポリシーを推奨しています。保持ルールは、コスト目標だけでなく、法的要件と運用要件に従うべきです。会話履歴には、機密性の高いソース資料やレビュアーの判断が含まれることがあります。
フレームワーク非依存には、別のテスト課題もあります。モデル変更は設定の 1 行だけで済むかもしれませんが、振る舞いが自動的に同等のままになるわけではありません。ツール選択、中断頻度、書式、注入された指示への感度は、モデル間で変化する可能性があります。
本番チームには、代表的なイベントから構築した回帰テストスイートが必要です。各モデルまたはプロンプトの変更は、期待されるジョブ状態、必要な承認ポイント、ツール権限、最終アクションに対してテストする必要があります。ランタイム抽象化は、振る舞いの検証に取って代わるものではありません。
したがって、中心的な不確実性はガバナンスの質です。AWS は、シグナルからレビュー可能なジョブに至る信頼できる技術的経路を示しました。それでも各導入者は、自らの領域における許容可能な自律性、エスカレーション基準、根拠要件、復旧手順を定義しなければなりません。
リファレンス公開後に注目すべきこと
次の試金石は、チームがエージェントの周囲に手動キューを再構築せず、このアーキテクチャを信頼できる運用へ変えられるかどうかです。
最初に注目すべき兆候は、文書受け入れやスケジュールを超えた導入です。AWS は、webhook、データベースイベント、外部統合を拡張ポイントとして挙げています。これらのソース向けに再利用可能なコネクターが提供されれば、このパターンがより幅広い運用ワークフローを支えるまでに必要なカスタム作業を減らせます。
チームが一貫してこうした統合を構築するなら、アンビエントモデルは汎用的なエージェントアーキテクチャとしての信頼性を高めます。ほとんどのデプロイが S3 アップロードを使ったデモにとどまるなら、実用的な適用範囲はより狭く見えるでしょう。
2 つ目の兆候は、完了したジョブと人による中断の比率です。このアーキテクチャの価値は、必要なときだけ支援を求めることに依存しています。中断率が高い場合、トリガーが自動化されていても、システムは継続的な人間の注意に依存していることになります。
この指標は、イベントタイプとリスクごとに分類する必要があります。支払い関連のすべてのアクションに承認を求めるエージェントは、意図どおりに機能している可能性があります。定型文書ごとに追加確認を求めるエージェントは、おそらくコンテキストが不足しているか、タスク定義が不明確です。
組織は、中断後の応答時間も測定すべきです。レビューリクエストが放置されたタブで待機するなら、イベント検知が高速でも運用上の利点はほとんどありません。通知、担当割り当て、エスカレーション機能によって、Jobs ページが実用的なコントロールサーフェスになるかが決まります。
3 つ目の兆候は、アイデンティティ、監査、可観測性のデータが実際の調査を支えられるかどうかです。運用担当者は、どのイベントがジョブを開始したか、どのモデルと設定が実行されたか、どのツールが呼び出されたか、レビュアーが何を見たか、誰がアクションを承認したかを再構築できる必要があります。
AWS はすでに複数の基盤要素を提供しています。CloudTrail はサービス API のアクティビティを記録し、CloudWatch は AgentCore テレメトリーを保存します。リファレンス設計は DynamoDB にジョブ履歴を維持します。本番実装では、これらの記録を理解可能な監査証跡へ接続しなければなりません。
競合各社の対応も重要です。LangChain はアンビエントエージェントという枠組みの普及に貢献し、他のエージェントプラットフォームもバックグラウンドタスク、永続的な実行、承認チェックポイントをますますサポートしています。顧客がすでに S3、Lambda、SQS、DynamoDB、IAM、CloudWatch を利用している領域では、AWS に優位性があります。
この優位性は、インフラ層でのロックインも生み得ます。エージェントフレームワークとモデルは置き換え可能なままかもしれませんが、周辺のイベントパイプライン、アイデンティティ設定、運用コンソールは AWS サービスに密接に結び付く可能性があります。
この公開を最も妥当に読むなら、チャットインターフェースが消えるということではありません。人が問題を探索したり、対話的に作業を指示したりする際には、会話は依然として価値があります。アンビエント実行が担うのは、誰かが依頼する前に、ソフトウェアが作業の存在に気付かなければならない別の場面です。
Amazon Bedrock AgentCore のアンビエントエージェントを評価するチームは、境界の明確なイベントを 1 つ、読み取り中心のタスクを 1 つ、明確に定義された承認境界を 1 つから始めるべきです。自律性を拡大する前に、すべての中断と却下を記録すべきです。
決定的な問いは、エージェントが S3 アップロードに応答できるかどうかではありません。サンプルは、それが可能であることを示しています。問われるのは、イベント量が増え、入力が統制されたデモのように見えなくなったときにも、結果として生じるジョブが理解可能で、レビュー可能で、回復可能なままであるかどうかです。
