Amazon Web Services（AWS）は9月30日、AIエージェントによるツール操作を過去の実行履歴に照らして許可・拒否する「Dogwood Local Engine」を、Apache 2.0ライセンスで公開した。Rust製のライブラリをエージェントの実行基盤に組み込むことで、「直近15分以内にテストが成功し、その後に失敗していない場合だけコードを送信する」といった条件を、操作の直前に判定できる。
8月に公開したポリシー言語Dogwoodに、クラッシュ後も判定状態を引き継げるローカル実行エンジンを加えた形だ。ただし、エンジンが行うのは許可・拒否の判定までで、その結果に従って実際に操作を止めたり、実行結果を正確に記録したりする責任は、組み込む側のソフトウェアに残る。
15分以内にテスト成功、その後失敗がなければpushを許可
Dogwoodは、現在の操作だけでなく、それ以前に何が起きたかも踏まえて許可・拒否を判断できるポリシー言語である。AWSは8月6日の公開時に、Amazon Bedrock AgentCoreのポリシー機能にも対応を追加した。認可言語Cedarとの互換性を保ちながら、操作の順序や、一定時間内の回数・累計値といった条件を加えられる。
今回公開されたLocal Engineは、イベントを受け取るたびにポリシーを評価し、その後の判断に必要な状態をディスクへ保存する。
従来のDogwoodの参照インタープリターは、言語仕様やサンプルの挙動を確認するためのもので、本番環境の認可処理に直接使うことは想定されていなかった。今回、継続的に届く操作を処理し、再起動後も過去の状態を踏まえて判定を続けられるライブラリが加わった。
名称にある「Local」は、この判定エンジンを利用者側の実行基盤へ組み込めることを意味する。LLM自体をローカル環境で動かすという意味ではない。
AWSが示したコード開発の例では、テストの実行そのものは常に許可する。一方、Gitで変更をリモートリポジトリへ送るpushについては、「15分以内にテストが成功しており、それ以降に失敗したテストがないこと」を条件とする。
テストに失敗した直後のpushは拒否され、修正後のテストが成功した5秒後なら許可される。最後の成功から17分が経過すると、再び拒否される。
履歴として扱うのは、ツールの呼び出し要求と、その実行結果という2種類のイベントだ。エンジンが許可・拒否を判定するのは要求イベントであり、結果イベントはその後の判断材料として履歴に加えられる。
そのため、「テストを実行した」という要求だけでは条件を満たさない。テストツールから返された成功・失敗の結果まで記録されて初めて、その後のpushを正しく判定できる。
判定するエンジンと、実際に止める実行基盤を分ける
Dogwood Local Engine自体には、拒否したコマンドの実行を止める機能はない。
ツール呼び出しを仲介する実行基盤が要求をエンジンへ渡し、許可された場合にだけツールを実行する。実行後は、その結果を再びエンジンへ送る。拒否された要求ではツール自体が実行されないため、結果イベントも発生しない。
つまり、判定とクラッシュ後の状態復旧を担当するのがLocal Engineで、実際の操作を遮断し、必要な監査記録を残すのは組み込み先の実行基盤となる。
公式の実装説明とAPI文書を整理すると、役割は次のように分けられる。
| 処理 | 主に担う側 | 成立するための条件・限界 |
|---|---|---|
| 操作の許可・拒否 | エンジン | 必要なイベントが漏れなく、正確な内容で届くこと |
| 拒否された操作の遮断 | 実行基盤 | エンジンが許可したツール呼び出しだけを実行すること |
| クラッシュ後の判定状態の復旧 | エンジン | 保護されたスナップショットや残存ログから、判定に必要な状態を復元できること |
| 過去の操作や判断の監査 | 実行基盤 | エンジン内部の永続化データとは別に、完全な監査記録を保存すること |
この表は、2026年10月2日時点で公開されている1.0系の説明を、判定・遮断・復旧・監査の4項目に整理したものだ。前提となるのは、必要なイベントが正確に入力され、実行基盤側で判定結果を確実に適用できることであり、攻撃に対する耐性そのものを測定した評価ではない。
導入時には、単にエンジンの判定結果を受け取れるようにするだけでは不十分だ。AIエージェントがDogwoodの判定を経由せず、別の経路から同じ操作を実行できないかも確認する必要がある。
イベントそのものを信用できることも前提となる。
Local Engineは、「誰が操作したのか」「テストが本当に成功したのか」といった内容を独力では検証できない。呼び出し元の認証や、実行結果を正確に記録する仕組みは実行基盤側で用意する必要がある。
シェルを操作できるAIエージェントであれば、保存ファイルやエンジンのメモリをツール経由で改変されないよう、OSのアクセス制御やサンドボックスなどで保護する必要もある。
コード開発の例では、もう一つ注意点がある。AWSが示した条件はテストの成功・失敗を確認しているが、テストしたコードとpushしようとしているコードが同じかどうかまでは確認していない。
実運用で「検証済みの変更だけを送信する」という条件にしたい場合は、コミットIDなどコードの版を識別する情報をイベントへ含め、同じ対象に対するテスト成功だったかを照合する設計が必要になる。「15分以内に成功した」という時間条件だけでは、そこまでは保証されない。
並行処理では「要求した時点」と「完了した時点」の違いが重要になる
複数のツール呼び出しが同時に届いた場合、Local Engineはロックを使って一件ずつ処理する。
イベントに時刻を付け、ログへ追記してディスクへの同期を終えてからポリシーを評価する。判定が終わるまでロックを保持するため、後から届いた要求は、それ以前に記録されたイベントを含む状態を基に評価される。
ただし、ここで順序が保証されるのは、あくまで判定に使うイベントの記録順である。外部で実行されるツールが、一つずつ順番に完了することまで保証するわけではない。
たとえば、あるテストがまだ実行中の段階でpushの要求が届いた場合、そのテストが後から失敗しても、pushを判定した時点では失敗結果がまだ履歴に存在していない。
「テストが実行中である間もpushを禁止する」というルールにしたければ、「テスト開始済みだが、まだ完了していない」という状態も条件として表現する必要がある。
AWSは8月のDogwood発表で、並行処理において何を集計対象にするかの違いを、「1時間に5,000ドルまで」という送金上限の例で説明していた。
2,000ドルの送金要求を3件連続して出し、いずれもまだ完了していない状況を考える。
完了した送金の結果だけを合計するポリシーでは、3件目を判定する時点でも「完了済みの送金額」はゼロである。そのため、2,000ドルの要求を3件とも許可してしまい、合計6,000ドルの送金が成立する可能性がある。
一方、送金の要求イベントを合計するポリシーなら、現在判定している要求も集計に含まれる。3件目では要求額の合計が6,000ドルになるため、そこで拒否できる。
ただし、この方法では拒否された要求も履歴に残る。したがって、「実際に送金された金額」の上限とは意味が異なる。
失敗や拒否も含めた「試行額」を数えるのか、実際に完了した「取引額」を数えるのか。同じ5,000ドルという上限でも、どのイベントを対象にするかによって挙動は変わる。
Local Engineによって、並行して届くイベントを一貫した順序で評価できるようになった。ただし、業務上どの段階のイベントをルールの対象とするかは、利用者側で決める必要がある。
ルールを変更すると、更新前の成功は新しい条件に引き継がれない
稼働中にポリシーを変更する場合にも、時間条件特有の注意点がある。
新しく追加したポリシーや、時間条件を変更したポリシーは、原則として更新後に届いたイベントを使って評価される。更新前の出来事を、新しい条件の履歴としてさかのぼって取り込むことはない。
一方、API文書によれば、変更されていないポリシーについては、それまで蓄積していた判定状態が維持される。
AWSは、コードの静的検査であるlintを例に説明している。
まずlintが成功した後に、「lintに成功してからでなければコミットできない」というルールを追加したとする。この場合、ルール追加直後のコミットは拒否される。
lintにはすでに成功しているが、それは新しいルールが有効になる前の出来事だからだ。ポリシー更新後にもう一度lintを実行して成功すれば、その後のコミットは許可される。
この仕様は、Local Engineが過去のイベントを永久にすべて保持する設計ではないこととも関係している。
エンジンは、現在の時間条件を評価するために必要な情報をメモリ内の状態としてまとめ、定期的にスナップショットへ保存する。すでにスナップショットへ反映された古いログは削減されるため、新しく追加された条件が必要とする情報が、過去の完全なイベント履歴として残っているとは限らない。
新しい条件をポリシー更新後のイベントだけで評価することで、この問題を避けている。
ポリシー更新そのものもイベントと同じログへ記録され、通常の要求との順序関係が決められる。これにより、一つの要求が古いポリシーと新しいポリシーを混在させた状態で判定されることを防ぐ。
再起動時には、ポリシー更新も順番に再生される。
ただし、ポリシー更新に失敗した場合、エンジンは直前まで使っていたポリシーで動き続ける。利用者が「変更に成功した」と誤解しないよう、更新エラーを運用者へ通知する仕組みを、組み込み側で用意する必要がある。
また、状態を永続化できることと、すべての操作について監査記録を残せることは別の話である。
公式の実装説明では、内部ログは定期的にスナップショットへまとめられ、その後削減される。また、許可・拒否といった判定結果そのものも監査用には記録されない。
つまり、クラッシュ後に判定を続けるための状態は復旧できるが、「過去に誰が何を試し、なぜ拒否されたのか」をすべて追跡したい場合は、別途監査ログを用意する必要がある。
判定速度を左右する時間窓の長さと操作の粒度
AWSの性能測定では、時間条件が参照する期間を長くすると、評価にかかる時間も大きく増えた。
毎時360件のイベントが発生するセッションをシミュレートしたところ、15分の時間窓では対象が直近90イベントに限られるため、セッションが長くなっても評価時間は一定の水準で頭打ちになった。
一方、24時間の時間窓では参照対象が増え続け、12時間のセッション時点で1回の評価に約6ミリ秒かかった。これは15分の場合の約300倍だったという。
この測定はサーバークラスのホスト1台で行われ、各測定点について200回評価した中央値を使っている。繰り返し測定の差は5％以内だったとAWSは説明している。
ただし、この数値が示しているのはポリシー条件そのものの評価時間である。
イベントをディスクへ同期する時間はストレージ性能に左右されるため、AIエージェントから見た判定全体の待ち時間をそのまま示しているわけではない。実際のツール処理を含めたシステム全体の性能として読むこともできない。
操作をどの程度細かく分けるかも性能へ影響する。
AWSは、100本のポリシーを5種類のGit操作へ20本ずつ割り当てた条件を使い、2種類の定義方法を比較した。
一つのgit操作としてまとめ、引数を見てpushやcommitを区別する場合、pushの要求でも100本すべてのポリシーを評価する必要がある。
一方、git:pushやgit:commitのように操作そのものを分けて定義すれば、push時には関連する20本だけを評価できる。このシミュレーションでは、後者が約5倍高速だったという。
ただし、性能を上げるために時間窓を短くすればよいわけではない。
たとえば「直近24時間の累計額を制限する」という業務ルールを、性能上の理由だけで15分へ短縮すれば、そもそもルールの意味が変わってしまう。
また、時間条件には数学的な定義が与えられているものの、AWSは8月の発表で、Cedarが備える自動推論による解析機能はDogwoodの時間条件には対応していないと説明している。
つまり、Dogwoodで記述した業務ルールそのものが意図どおりかどうかまで、自動的に証明してくれるわけではない。
導入を検討する際には、実際の負荷を使ってディスク同期を含む待ち時間を測定し、並行した要求やポリシー変更後でも、想定した条件が正しく働くかを確認する必要がある。
そうした前提を満たし、実行基盤側でも操作の遮断と記録を確実に行えるなら、Dogwood Local Engineは、AIエージェントにどこまでツール操作を任せるかを、過去の実行結果まで含めて制御するための基盤として利用できる。
