単一のアクションを越えてエージェントの振る舞いとコストを制御する: Amazon Bedrock AgentCore の新機能

本記事は 2026 年 8 月 6 日に公開された「Control agent behaviors and cost beyond a single action: new capabilities in Amazon Bedrock AgentCore」を翻訳したものです。

エージェントの自律性は高まり、各チームが運用するエージェントの数も増え続けています。しかし、信頼性とセキュリティはその速度に追いついていません。McKinsey によると、およそ 80% の組織がすでに AI エージェントによるリスクのある振る舞いに遭遇しています。その結果、セキュリティとリスクへの懸念が、エージェント型 AI をスケールさせる際の最大の障壁となっています (McKinsey の State of AI Trust in 2026 および Trust in the age of AI agents 2026)。

つまり、信頼こそがエージェントのイノベーションと導入のペースを決める要因です。そして信頼を獲得するには、アイデンティティ、アクセス、オブザーバビリティ、評価、トレーサビリティといった広い範囲にわたる制御が必要になります。私たちは、信頼とセキュリティへの投資こそがエンタープライズにおけるエージェント導入を加速させると考えています。ガードレールが確実に機能するようになれば、新しいエージェントを承認することは個別の交渉ごとではなくなり、プラットフォームがスケールして処理できる作業になります。

課題は、今日のガードレールの多くが、予測可能な振る舞いをするソフトウェアを前提に設計されていることです。エージェントは実行しながら自ら進む道を決めるため、個々のステップはそれぞれ問題なく通過する一方で、全体としての形は検証されないままになります。あるエージェントが顧客のアカウントを照会した後、別の口座番号へ送金してしまう。それは、各呼び出しが単独で判断されたからです。あるエージェントが承認しきい値を下回る注文を次々と発行してしまう。それは、合計額を予算と照らし合わせて追跡しているものが何もないからです。あるエージェントが失敗するツールに当たり、夜通しリトライを繰り返してトークン予算を使い切ってしまう。それは、消費量に上限を設けているものが何もないからです。これらのリクエストはいずれも、それ自体は正当なものです。問題はパターンとして初めて現れます。そして、それを捉える役割を任せるのに最もふさわしくない存在が、エージェント自身なのです。

私たちは、チームがインフラストラクチャを自ら組み上げることなく、大規模にエージェントを構築・接続・最適化できるようにするために Amazon Bedrock AgentCore を開発しました。当初から一貫している原則が 1 つあります。それは、セキュリティ制御は、各チームが異なる方法で実装するアプリケーションコードではなく、インフラストラクチャレイヤーに置き、すべてのエージェントに対して一貫して適用すべきだということです。

AgentCore のゲートウェイは、この考えを具体的な形にしたものです。ゲートウェイは AI トラフィックのためのフルマネージドかつサーバーレスなエントリポイントであり、リクエストを Model Context Protocol (MCP) サーバー、大規模言語モデル (LLM)、エージェント、ナレッジベースへルーティングします。すべての呼び出しがゲートウェイを通過するため、ゲートウェイは、エージェントがどのように振る舞っても揺るがない制限を適用するのに最適な場所です。本日、私たちはこの取り組みを新機能によってさらに前進させます。AI エージェント向けに専用設計された新しいオープンソースのポリシー言語 Dogwood を基盤とする時系列ポリシー (temporal policies)、そしてゲートウェイにおけるレート制限です。

時系列ポリシーによって、個々のアクションだけでなく一連のアクションに境界を設ける

現在の AgentCore のポリシーは、エージェントの振る舞いに対する決定論的な制御を提供します。すべてのアクションを実行前にチェックし、誰がどのツールをどのような条件で呼び出せるかを評価します。これらのチェックは、設計上ステートレスです。各リクエストはそれ自体の内容に基づいて、高速かつ証明可能な形で判断されます。これは認可に常に求められてきた性質です。一方で、エージェントがより長いタスクをより少ない監督のもとで担うようになると、別の問いが生じます。それは、エージェントのアクションを合わせて見たときに、それが許容されるべきものになっているのかという問いです。これは、個々のアクションだけでなく一連のアクションを見て初めて分かることです。

時系列ポリシーは、AgentCore のポリシーを拡張してこのギャップを埋めます。リクエストを単独で判断するのではなく、ポリシーエンジンがそのセッション内でエージェントがすでに実行した内容も参照し、その一連のアクションに基づいて呼び出しを許可または拒否します。誤った口座番号を使った送金は、ある呼び出しに渡される値が、それ以前の呼び出しが返した値と一致することを要求するポリシーによってブロックできます。また、あるセッション内でエージェントが使った金額を集計し、たとえその購入が個別の上限を下回っていても、予算に達した時点で次の購入をブロックするポリシーも作れます。さらに、ステップが決められた順序で実行されることや、重要なアクションには記録された人間による承認が必要であることを要求できます。人が関与しなくなった時点で、権限を自動的に狭めることも可能です。

時系列ポリシーは、エージェント自身のコードの外側、ゲートウェイレイヤーで適用されます。エージェントはポリシーのロジックを認識できず、どのようなプロンプトが与えられても、あるいはどのような欠陥を抱えていても、その裏をかくような推論はできません。自律システムの承認を求められているセキュリティリーダーにとって、これは決定的な違いです。エージェントが正しく振る舞うことを信じるのか、それとも一連のアクションを通じて境界が保たれることを確かに知っているのか、その違いです。判断は決定論的で、デフォルトは拒否であり、その背後にある完全なコンテキストとともにログに記録されます。レビュー担当者は、呼び出しがブロックされたという事実だけでなく、その理由まで確認できます。

時系列ポリシーを支えているのが、AI エージェント向けに専用設計された新しいポリシー言語 Dogwood です。Cedar を基盤として構築された Dogwood は、エージェント制御における新しい次元、すなわち一連のエージェントのアクションが展開していく過程で、それがポリシーに適合しているかを評価するという課題に対応するために設計されました。Dogwood は Cedar を内包しつつ、レート制限、時間ウィンドウ、前提となるステップ、エスカレーションのトリガーなど、エージェントガバナンスのための時系列的な構成要素を追加しています。Dogwood は、Apache 2.0 のもとでオープンソースの仕様およびリファレンス実装として利用できます。これにより、お客様は自身のポリシーがどのように評価されるのかを完全に把握できるようになり、より広いエコシステムが周辺ツールを構築できるようになります。

ゲートウェイのレート制限で、エージェントの消費量を制御する

AI のコストはそれ自体がガバナンスの課題であり、エージェントの場合、それはトークンや呼び出しをどれだけ速く消費するかという点から始まります。エージェントは自らが必要と判断した数のステップを実行するため、あるタスクにかかるコストは、あらかじめ決まったレートではなく、エージェントがどう進めるかを選ぶかによって決まります。上限がなければ、リトライループや異常に負荷の高いセッションが、エージェントの決めた速度でリソースを消費し続けます。この予測できなさは、承認における現実的な制約になります。Forrester は、エージェント型 AI がスケールに至ることがまれである理由の第一がコストであることを明らかにしています (The State Of Agentic AI In 2026)。エージェントがどのように振る舞っても揺るがない上限が、チームには必要です。

本日より、こうした上限を AgentCore のゲートウェイに直接設定できます。レート制限を使うと、OAuth や IAM ですでに管理しているアイデンティティを用いて、ゲートウェイの背後にあるすべてのツール、モデル、エージェントにわたり、ユーザーごとに消費量の上限を設定できます。制限の対象には、あるユーザーが発行するリクエスト数、そのユーザーのためにモデルが処理するトークン数、そして接続を開いたまま保持する時間が含まれます。この 3 つがすべて揃っていることが重要なのは、エージェントがコストを積み上げる経路がさまざまだからです。リトライループはリクエスト量として現れ、推論が重いタスクはトークンとして現れ、長時間のリサーチセッションは、ほとんどトラフィックが流れないまま接続が保持され続ける形で現れます。どれか 1 つの指標だけでは、制限に触れずにサービスを消耗させる抜け道が残ってしまいます。

制限は秒単位および分単位のウィンドウで適用されます。これは、チームが実際に直面する障害モード、すなわち誰も意図していない速度でエージェントが消費を続け、それが事後に発覚するという事態を封じ込めるためです。レート制限は設定した時点で有効になり、エージェントのコードを変更する必要はありません。キャパシティの割り当ては、プラットフォームチームが構築するものではなく、設定するものになります。ユーザー、チーム、ツール、モデルごとに異なる上限を持たせることができ、そのいずれにもスロットリングのロジックを書き込む必要はありません。

今後の方向性

モデルは進化を続けており、その進歩こそがエージェントをデプロイする価値を生み出しています。同時にそれは、より高い能力を持つエージェントが、より少ない監督のもとでより重大な結果を伴うアクションを実行するという意味で、リスクの大きさも引き上げます。より優れたモデルからエンタープライズが得られる成果は、本番環境のほかのあらゆるものに適用しているのと同じ規律をもって、そのエージェントを運用できるかどうかにかかっています。

エージェントへの信頼とは、実のところモデルに対する評価ではありません。それは、モデルが動作しているシステムに対する評価であり、エージェントが予期しない振る舞いをしたときにそのシステムが揺るがずにいられるかという評価です。そうしたシステムを構築することはまだ若い分野であり、お客様が今持ち込んでくださる問いは、1 年前のものと比べて明らかに洗練されています。私たちはこの領域で今後も素早く前進していくつもりであり、あわせてアイデンティティ、オブザーバビリティ、評価、トレーサビリティへの投資も続けていきます。アプリケーションコードからプラットフォームへ移されたすべての制御は、エージェントごとに個別に作り直し、レビューし、信頼する必要があるものが 1 つ減ることを意味します。プラットフォームが、エージェントの実行内容と消費量をより確実に制限できるようになるほど、ためらいなく委ねられる自律性は大きくなります。

いずれの機能も、すでに本番環境で稼働しているエージェントの再設計を必要とせず、どちらか一方だけを採用することもできます。詳細については、AgentCore のドキュメントと料金ページをご覧いただき、Dogwood のリファレンス実装もぜひお試しください。

著者について

Madhu Parthasarathy は Amazon Bedrock AgentCore の General Manager であり、企業が本番環境の AI エージェントを構築・接続・最適化するために利用するプラットフォームを開発するチームを率いています。大規模分散インフラストラクチャの構築において 20 年以上の経験を持ち、そのうち 16 年以上を Amazon で過ごし、Amazon Retail、Elastic Block Store (EBS)、そして現在の AgentCore にわたる主要な取り組みをリードしてきました。Amazon に戻る前は、LinkedIn でシニアリーダーシップの役割を担い、LinkedIn のすべてのエンタープライズ事業を支えるエンタープライズプラットフォームを率いました。また、ネオクラウドのスタートアップでは AI インフラストラクチャを統括し、セキュリティと開発者体験のビジョンを策定しました。現在はカリフォルニア州サンタクララを拠点としています。