AgentCore Temporal Policiesとは
Amazon Bedrock AgentCoreのTemporal Policiesは、現在の1リクエストだけでなく、同じセッションでそれ以前に実行されたアクションの履歴を使って、次のツール実行を許可・拒否する仕組みです。「承認後だけ送金する」「テスト成功後だけデプロイする」「5分以内の実行回数や合計金額を制限する」といった、複数アクションにまたがる規則をポリシーとして表現できます。
ポリシーはオープンソースのDogwoodで記述します。DogwoodはCedarの認可モデルと互換性を保ちながら、formerly、since、count、sumなど、過去イベントを見るための時間演算を追加しています。単なる時刻制限ではなく、「このセッションで何が起きたか」を判断に使う点が特徴です。
Temporal PoliciesとGatewayレート制限の違い
| 比較軸 | Temporal Policies | Gatewayレート制限 |
|---|---|---|
| 主な目的 | アクションの順序、承認、回数、累計値を認可判断へ反映 | 呼び出し量、トークン量、接続数を一定の速度内へ抑える |
| 判断の単位 | 同じポリシーセッションのイベント履歴 | caller、target、toolなどのdimensionで分けたバケット |
| 代表例 | テスト成功後だけDeploy、1承認につき1実行、セッション内3回まで | ユーザー別RPM、モデル別TPM、同時接続数、特定callerの遮断 |
| 境界 | 新しいsession IDでは履歴と回数がリセット | 設定したdimensionと秒／分のウィンドウで集計 |
| 注意点 | session ID、認証主体、同一account／Region、WAT伝播が重要 | 既定はfail-openで、サービス上限を超える設定はできない |
Temporal Policiesは「何をどの順で実行してよいか」を守る
アクションの意味と履歴を評価します。回数制限も作れますが、その集計は同じsession IDの中だけです。新しいセッションを開始すればカウントも新しくなるため、全ユーザー・全セッションを通じたグローバルな流量制御にはなりません。
Gatewayレート制限は「どれだけ速く消費してよいか」を守る
リクエスト、モデルのトークン、接続数などをcaller・target・tool単位で制限します。複数の有効なレート制限はすべて通過する必要があり、customer-defined limitとサービス側上限のうち小さい値が実効上限になります。ただしfail-openが既定なので、認証・認可や業務上の安全条件をレート制限だけへ任せません。
どちらを使うかの判断表
- 承認、順序、成功結果が前提：Temporal Policies
- セッション内の回数や累計金額：Temporal Policies
- ユーザー・チーム別のRPMやTPM：Gatewayレート制限
- バックエンド保護や接続数の抑制：Gatewayレート制限
- 高リスクな本番エージェント：両方を併用し、IAM、認証、業務側検証、監視も重ねる
二者択一ではありません。Temporal Policiesを「意味のある操作の境界」、Gatewayレート制限を「消費速度の境界」として重ねると、プロンプトやエージェント実装が変わってもGateway側で共通制御を維持しやすくなります。
実務例：デプロイエージェントを二層で制御する
| 段階 | 守りたい条件 | 使う制御 |
|---|---|---|
| 1 | RunTestsが同じセッションで成功している | Temporal Policyで成功responseを確認 |
| 2 | 成功から15分以内だけDeployを許可 | Temporal Policyの時間ウィンドウ |
| 3 | 1回の承認でDeployは1回だけ | sinceで承認の使い回しを防止 |
| 4 | チーム別の呼び出し急増を抑える | Gatewayレート制限 |
| 5 | 拒否、遅延、429、コストを追跡する | CloudWatch metrics／traces |
エージェントコード内のif文だけで順序を守ると、別のオーケストレーターや新しいツール経路から呼ばれた場合に抜けが生じます。Gatewayでポリシーと流量制御を適用し、ツール側でも入力検証、冪等性、権限確認を維持します。
導入の7ステップ
- 操作を分類する：読み取り、更新、外部送信、決済など、失敗時の影響を整理する
- 二つの境界を分ける：順序・承認・累計値と、RPM・TPM・接続数を別要件にする
- GatewayとPolicy Engineを準備する：同じAWS account／Regionに配置し、対象Regionを確認する
- 認証とIAMを設定する：GatewayのPolicy権限と
GetWorkloadAccessTokenを最小権限で付与する - session IDを明示送信する：論理的な会話ごとに生成し、最初のリクエストから同じ値を渡す
- LOG_ONLYで試す：正常順序、逆順、期限切れ、回数超過、新規セッションをテストする
- レート制限と監視を追加する：dimension、entry、実効上限、fail-open時の補完策、アラートを確認してからENFORCEへ進む
session ID設計で間違えやすい点
- 同じ会話では同じID：途中で変えると履歴が切れ、順序や回数を評価できない
- ユーザー間で共有しない：認証なしで同じIDを共有すると、異なるcallerのイベントが同じ履歴に入る場合がある
- 広すぎる期間にしない：会話単位を基本にし、日次・ユーザー単位が必要なら要件と失効方法を別途設計する
- ポリシー変更後は新規ID：Temporal Policyの追加・更新は既存セッションを無効化し、再利用時にHTTP 409となる
AWS公式ドキュメントには、session IDを省略した場合について「Gatewayは生成しない」と「生成してレスポンスで返す」という異なる説明があります。仕様差や更新途中の可能性があるため、本番設計では省略動作へ依存せず、アプリ側でIDを生成して最初から明示送信し、利用Regionの実環境で確認します。
本番導入前の注意点
- account／Region：Temporal Policyはcross-account・cross-Regionへ自動伝播しません。Gatewayと対象を同一account／Regionへ揃えます。
- WATとIAM：
GetWorkloadAccessTokenがないとTemporal Policy有効時の呼び出しが失敗します。 - 現在リクエストの数え方：同じactionを数える条件では、認可中の現在リクエストもcountへ含まれます。境界値テストが必要です。
- response条件：成功完了したactionだけがresponseイベントになります。前提actionを許可する別policyも必要です。
- fail-open：Gatewayレート制限は既定でfail-openです。認可や不正防止の唯一の境界にしません。
- service quota：customer-defined limitを高くしても、サービス側上限を超えて利用できません。
- 変動する仕様：対応Region、quota、API、session IDの動作は導入時に公式情報と実環境で再確認します。
監視とテストで確認すること
- LOG_ONLYとENFORCEで同じテストシナリオを実行する
- 正常順序、逆順、期限切れ、4回目、新session ID、policy更新後409を確認する
TemporalLatency、評価回数、Gateway rate limit metrics、429、バックエンド負荷を確認する- dimensionを解決できない場合や制御サービス障害時の補完策を確認する
- 拒否ログへ入力内容や秘密情報を過剰に残さない
どんなチームに向いているか
- 決済、外部送信、デプロイなど複数手順を守るエージェントを運用する
- ユーザーやチーム別にAI利用量の急増を抑えたい
- エージェント実装から認可・流量制御を分離して共通化したい
- 監査で「どの規則が、どの履歴を見て拒否したか」を説明したい
単一の読み取りツールだけを低頻度で使う場合は、Temporal Policyまで導入すると運用負荷が上回ることがあります。まずIAMとGateway認証、ツール側検証を整え、履歴をまたぐ規則や流量制御が本当に必要かを判断します。
公式情報
関連する記事と支援
自然言語からポリシーを作る機能はAgentCoreのDogwoodポリシー作成、検証可能なルール設計はAutomated Reasoning Policiesの記事も参考にしてください。操作分類、脅威・コスト要件、評価シナリオ、監視まで含めて小さく検証する場合は、AI活用・業務効率化支援で要件整理を支援しています。