Amazon Bedrock AgentCore Temporal Policiesが示すAIエージェント認可の新基準｜履歴を見てツール実行をどう止めるか

目次

---

1. AIエージェントは「前の行動」まで見て止める段階に入った

AIエージェントの権限設計で難しいのは、単発の操作だけを見ても安全性を判断できないことです。顧客情報を読む、見積書を作る、送金を依頼する、Slackに投稿する。どれも単独では許可できる操作かもしれません。しかし「どの情報を読んだ直後か」「承認を受けた後か」「同じセッションで何回実行したか」まで見ると、判断は変わります。

従来の業務アプリでは、こうした順序制御をアプリケーションの決定的なロジックに書き込めました。ところがAIエージェントは、実行時にどのツールを呼ぶか、どの順番で進めるか、どの引数を組み立てるかをモデルが判断します。だからこそ、ツールごとの静的な許可だけでは足りません。エージェントの「行動の軌跡」を見て、危ない流れを外側から止める仕組みが必要になります。

AWSは2026年8月6日、Amazon Bedrock AgentCoreでTemporal Policiesを使ったAIエージェントの保護方法を公式ブログで公開しました。AWSの説明によると、Temporal PoliciesはAgentCore Gatewayの境界で動き、現在のツール実行リクエストを、同じセッション内の過去イベントと照らし合わせて許可・拒否します。重要なのは、これがエージェント自身のコードの外側で強制される点です。モデルがどのような判断をしても、プロンプトで誘導されても、Gateway側の認可を迂回しにくい構成になります。

この発表は、新しいAWS機能の紹介にとどまりません。企業がAIエージェントを業務システムへ接続するとき、「誰が何をできるか」だけでなく、「どの流れなら実行してよいか」をポリシーとして表現する段階に入ったことを示しています。

2. AWSが発表したTemporal Policiesの要点

AWSの公式ブログでは、Temporal PoliciesはAgentCore Gatewayに届いたリクエストを、エージェントの過去のツール呼び出し履歴と合わせて評価する仕組みとして説明されています。従来のステートレスなポリシーは、「このユーザーがこのツールを呼べるか」「この条件なら許可するか」を現在のリクエストだけで判断します。一方、Temporal Policiesは「直近1時間以内に承認があったか」「同じセッションで累計金額が上限を超えていないか」「データ参照後に別の値を作り出していないか」のような、時間と順序を含む条件を扱います。

公式ドキュメントによると、Temporal PoliciesはDogwoodというポリシー言語で記述されます。DogwoodはCedarと互換性があり、既存のCedarポリシーをそのまま使いながら、セッション履歴を見る条件を追加できます。ポリシーの基本はpermitとforbidで、許可ルールが成立し、かつ拒否ルールが優先しない場合だけリクエストが通るという考え方です。

履歴の単位はポリシーセッションです。Gatewayへの呼び出しはセッションIDで束ねられ、その同じセッション内で記録されたイベントだけが評価対象になります。AWSの説明では、セッションIDを明示して渡すことも、Temporal Policiesが構成されている場合にGatewayがセッションを作成して返すこともできます。これにより、別ユーザーや別業務の履歴が混ざらないようにしつつ、同じ業務フロー内の順序だけを見られます。

使える条件も実務寄りです。ドキュメントでは、以前に特定イベントが発生したことを見るformerly within、あるイベント以降の状態を見るsince within、同一セッション内の回数を数えるcount、金額などの累計を見るsumが示されています。たとえば「承認ツールの結果がtrueだった場合だけ売却ツールを許可する」「送金操作の累計が上限を超えたら止める」「一定時間内に検索した顧客IDと、次の操作で使う顧客IDが一致する場合だけ許可する」といった制御に使えます。

提供面の事実も確認しておきたいところです。AWSのドキュメントでは、Temporal Policiesは東京リージョンを含む複数リージョンで利用可能とされています。また、ポリシーエンジンあたりのTemporal Policiesは25件、1ポリシーあたりのTemporal operatorは3件、Temporal conditionの最大時間窓は24時間と示されています。さらに、CloudWatchのメトリクスやspan属性でTemporal Policiesの評価状況を観測できることも説明されています。

3. なぜ企業のAIエージェント認可に効くのか

AIエージェントを業務に入れると、最初は「どのツールを使わせるか」が論点になります。しかし本番運用に近づくほど、「どの順番で使わせるか」「どの結果に基づいて次の操作を許すか」が重要になります。これは、RPAや通常のワークフローでも存在した課題ですが、AIエージェントではモデルが手順を動的に選ぶため、より露骨に表面化します。

たとえば営業支援AIがCRMを検索し、見積を作成し、顧客へメール案を生成するケースを考えます。CRM検索は許可、見積作成も許可、メール作成も許可という静的な権限だけでは、十分ではありません。検索した顧客と見積対象の顧客が一致しているか、直近の価格表を参照したか、マネージャー承認が必要な値引き率を超えていないか。このような条件は、過去のツール結果と現在のリクエストを合わせて見ないと判断できません。

金融や経理ではさらに深刻です。1回あたりの送金額は上限以下でも、同じセッションで何度も繰り返せば累計リスクは大きくなります。単発の操作だけを見る認可では「すべて正常」に見えても、行動の連なりとしては異常です。Temporal Policiesのcountやsumの考え方は、こうした累積リスクを業務フロー単位で見るための土台になります。

セキュリティ面では、プロンプトインジェクションやデータ汚染への備えにもつながります。外部Webや未信頼の文書を読んだ直後のエージェントに、社内システムの更新や外部送信を許すべきか。すべてを禁止すると業務は回りませんが、一定の条件で人間承認を挟む、未信頼ソース参照後は高権限ツールを制限する、といったセッション履歴ベースの制御は現実的です。

OpenBridgeの読者にとって重要なのは、これを「AWSだけの機能」としてではなく、AIエージェント設計のパターンとして捉えることです。モデルに安全な振る舞いをお願いするだけでは足りません。ツール実行の境界に、履歴を見て判断する認可層を置く。さらに、その判断をログとして残し、後から監査できるようにする。この発想が、AIエージェントをPoCから本番へ移す際の基準になります。

4. 導入時に決めるべき設計ポイント

第一に、守りたい業務フローを先に決めることです。Temporal Policiesのような仕組みは、抽象的に「安全にする」ためではなく、具体的な事故シナリオを止めるために使います。顧客IDの取り違えを防ぐ、承認前の実行を防ぐ、累計金額を超えた操作を止める、未信頼データ参照後の高権限ツール実行を制限する。こうしたシナリオを業務部門と一緒に洗い出すところから始めるべきです。

第二に、セッションの切り方を設計します。Temporal Policiesは同じセッション内の履歴を見ます。したがって、セッションが短すぎると必要な履歴を参照できず、長すぎると無関係な行動まで条件に入ってしまいます。問い合わせ1件、見積1件、申請1件、調査タスク1件のように、業務上の責任単位に合わせてセッションを切ることが重要です。

第三に、ポリシーを最初から強制しすぎないことです。AWSのドキュメントでは、Temporal PolicyをLOG_ONLYモードで観測してからENFORCEへ移す運用が示されています。これは実務でも有効です。最初はログだけで「本当に止めるべきリクエストか」「正常業務まで止めていないか」を確認し、ルールの粒度を調整してから強制に移る。AIエージェントは行動パターンが固定しにくいため、この観測期間がないと業務影響を読み違えます。

第四に、人間承認と組み合わせることです。Temporal Policiesは、承認済みイベントが過去にある場合だけ次の操作を許可する、といったルールに向いています。高額な発注、外部送信、権限変更、顧客への最終回答など、人間の責任が残る操作では、承認ツールを明示的に挟み、その承認結果を次の操作の条件にする設計が現実的です。

第五に、ログとメトリクスを運用に入れることです。ポリシーが拒否したという事実だけでなく、どのセッションで、どの条件により、どのツール呼び出しが止まったのかを追える必要があります。CloudWatch側の評価メトリクスと、業務アプリ側の利用者・案件・承認履歴を結びつけることで、単なる技術ログではなく、業務監査に使える記録になります。

導入時の論点は、次のように整理できます。

5. 過信しないための注意点

Temporal Policiesは強力ですが、万能ではありません。第一の注意点は、セッション履歴の外側は見えないことです。AWSのドキュメントでも、countベースの制限は単一セッション内の回数を数えると説明されています。ユーザーや攻撃者が新しいセッションを始めれば、セッション内の累計はリセットされます。全社的な日次上限やユーザー単位の長期制限は、別のレート制御やリスク管理と組み合わせる必要があります。

第二に、ポリシーの前提となるイベントが正しく記録される必要があります。ある操作の結果に基づいて次の操作を許可する場合、前の操作が許可され、完了し、履歴に記録されていなければ条件は成立しません。非同期処理や並列実行が多いエージェントでは、依存する操作が完了してから次の操作を出すようにワークフローを設計する必要があります。

第三に、ポリシー変更時のセッション扱いです。AWSのドキュメントでは、Temporal Policiesを追加・更新すると、既存のTemporal Policyセッションは無効化され、古いセッションを再利用した次のリクエストは競合エラーになると説明されています。これは一貫性を守るためには合理的ですが、本番運用では利用者体験に影響します。ポリシー更新のタイミング、再試行、ユーザーへの案内を決めておくべきです。

第四に、ポリシーを増やしすぎないことです。ポリシーエンジンあたり25件、1ポリシーあたり3つのTemporal operatorという制約は、設計を整理するための目安にもなります。業務ルールを細かく分けすぎると、どのルールが何を守っているのか分からなくなります。重大な事故シナリオを優先し、ポリシー名、意図、対象ツール、責任者を台帳化して管理することが大切です。

最後に、AIエージェントの安全性はポリシーだけで完成しません。モデルの指示設計、ツールの入力検証、データ分類、RAGのアクセス制御、人間承認、監査ログ、インシデント対応までが一体です。Temporal Policiesはその中の「行動の流れを見て止める」層です。ここを導入したから安心ではなく、他の層と組み合わせて初めて意味を持ちます。

6. まとめ

AWSが2026年8月6日に公開したAmazon Bedrock AgentCoreのTemporal Policiesは、AIエージェントの認可を「現在のリクエストだけ」から「セッション内の行動履歴」へ広げる重要な発表です。AgentCore Gatewayの境界で、承認、順序、累計、回数、データの対応関係を評価できるため、モデルやエージェントコードの内側に頼りきらない統制を設計しやすくなります。

企業が見るべきポイントは、機能名そのものではありません。自社のAIエージェントで、どの行動の連なりが危ないのか。どの単位でセッションを切るのか。どこで人間承認を挟むのか。LOG_ONLYからENFORCEへどう移すのか。拒否ログを業務監査にどうつなげるのか。ここまで決めることが、本番AIエージェントの認可設計です。

OpenBridgeでは、生成AI、AIエージェント、RAG、MCP、権限設計、監査ログ、Human-in-the-loopを組み合わせたAIシステム開発を支援しています。AIエージェントに業務ツールを渡すなら、ツールをつなぐだけでは不十分です。行動の流れを見て止める仕組みまで含めて設計することが、信頼できる業務AIへの近道になります。