AWSがAgentCoreに時系列ポリシー追加 エージェント統制を強化
この記事の要点
AWSはAmazon Bedrock AgentCoreに、直前の操作を踏まえて権限を判定する時系列ポリシーと、AIへの流量を絞るレート制限を追加した。単体では安全な操作も文脈で危険になりうる。エージェントを本番で回す企業に、事故を防ぐ統制の手立てが増える。
結論
AWSはAmazon Bedrock AgentCoreに、エージェントの統制を強める2つの機能を追加した。1つは時系列ポリシーで、直前の操作を踏まえて権限を判定する。もう1つはレート制限で、AIに流れる量を利用者やグループごとに絞る。エージェントは自分で複数の手順を進めるため、1つの操作だけ見れば安全でも、直前の流れによっては危険になることがある。作業の順序を強制したり、特権的な操作の前に人の承認を求めたりできる。エージェントを本番で回す企業にとって、事故を防ぐ統制の手立てが増えた。
何が追加されたのか
時系列ポリシーは、各要求をそのセッションでの過去の行動の文脈で評価する。単体のツール呼び出しは安全でも、直前に何をしたかで危険度が変わるためだ。これにより、作業の順序を強制し、あるツールの引数が直前の出力と一致することを求め、特権的な操作の前に人の承認を挟み、データの新しさを保つことができる。エージェントが暴走したり、意図しない順序で動いたりするのを防ぐ設計だ。
レート制限は、ゲートウェイにつながるツールやモデル、エージェントへの流量を、利用者やグループごとに制御する。特定の利用者が大量の要求を出して費用が跳ねる事態を防げる。どちらも、派手な新機能ではなく、本番運用を支える統制のしくみだ。AIの利用を一元的に統制する動きは各社で進んでおり、SnowflakeがCortex AI Gatewayを発表 AIエージェントの統制を一元化でも同じ方向が見える。エージェントの基本はAIエージェントとは?生成AIとの違いと業務への影響で確認できる。
なぜ文脈を見た統制が要るのか
エージェントは、指示を受けて自分で判断し、複数の操作を続けて行う。1つずつの操作を許可制にするだけでは、危険を防ぎきれない。たとえば「データを読む」「外部に送る」という操作は、それぞれ単体では業務で普通に使う。だが、機密のデータを読んだ直後に外部へ送る流れは危うい。直前の行動を踏まえて判定できれば、この組み合わせを止められる。
特権的な操作の前に人の承認を挟めるのも重要だ。エージェントに任せる範囲を広げるほど、取り返しのつかない操作をどこで止めるかが問われる。人が確認する関門を、権限のしくみとして組み込めば、任せる範囲を広げつつ事故を抑えられる。この考え方は、AIを業務に組み込むときの基本になる。権限の設計は生成AIのアクセス権限管理 誰がどのAIを使えるかを組織で制御するにまとめている。
現場の実務にどう効くか
エージェントを本番で回す部署は、まず取り返しのつかない操作を洗い出したい。データの外部送信、削除、支払いに関わる操作は、人の承認を挟む対象になる。時系列ポリシーのようなしくみを使えば、これらを権限として組み込める。全部を止めるのではなく、危険な組み合わせと重い操作に絞って関門を置くのが現実的だ。
次に、レート制限で費用と負荷の暴走に備える。利用者ごとに上限を決めておけば、想定外の大量利用で費用が跳ねる事態を防げる。統制のしくみは、導入前にルールとして決めておくと後戻りが減る。AIを本番に移す前に、順序の強制と承認の関門、流量の上限をセットで検討したい。運用ルールの作り方は企業のAI利用ガイドライン作り方とテンプレートが参考になる。仕様は変わりうるため、最新は公式で確認してほしい。
まとめ
AgentCoreの時系列ポリシーとレート制限は、エージェントの統制を強める。直前の流れを見た判定と、特権操作の承認、流量の上限がそろう。取り返しのつかない操作に関門を置き、利用の上限を決めてから本番に移すのが安全だ。
出典
よくある質問
時系列ポリシーとは何ですか。
エージェントの各操作を、そのセッションでの直前の行動を踏まえて許可するかを判定するしくみです。1つの操作だけ見れば安全でも、直前の流れによっては危険になることがあります。作業の順序を強制したり、特権的な操作の前に人の承認を求めたり、直前の出力と引数の一致を求めたりできます。Amazon Bedrock AgentCoreに追加されました。
レート制限は何のためですか。
ツールやモデル、エージェントに流れる量を、利用者やグループごとに制御するためです。特定の利用者が大量の要求を出して費用が跳ねたり、システムに負荷がかかったりするのを防げます。統制と費用の両面で、本番運用の土台になります。仕様は変わりうるため、最新は公式で確認してください。