社内の問い合わせ対応にAIエージェントを試したところ、動きはいい。ただ、外部のサービスに触るたびに「この操作を許可しますか」という確認が出る。最初の週は一つずつ読んで判断していた担当者が、三週目には内容を見ずに承認を押している。
これは担当者の怠慢ではなく、確認の設計が回数に耐えていないだけです。 1日に数十回、判断の材料が毎回ほとんど同じ確認を出せば、人はまとめて通すようになります。そして通すようになった時点で、確認は防御として機能していません。
止まらない確認をどう減らすかという話は、2026年8月に公開された仕組みで一段進みました。判断の粒度を「1回の操作」から「操作の並び」に移すという発想です。
1回ずつ見ても分からない形がある
いま多くの仕組みが採っている判定は、リクエストを1件ずつ見て許可か拒否かを返す方式です。この方式は明確で速い一方、単体では問題のない操作が並んだときに生まれるリスクを構造的に見られません。
たとえば次の三つは、どれも単独なら業務上ありふれた操作です。
- 顧客の一覧を検索する
- 検索結果を表形式のファイルにまとめる
- ファイルを社外のアドレスへ送る
1件ずつ判定する仕組みは、3番目を見たときに「ファイル送信の権限があるか」しか問えません。そのファイルの中身が直前に取得した顧客一覧であるという事実は、判定の視野の外にあります。 人間の担当者なら「さっきの一覧をそのまま外に出すのか」と気づく部分が、そのまま抜けます。
同じことは金額でも起きます。1回の送金上限を10万円に設定していても、8万円を12回に分ければ通ります。回数と合計を見ていないからです。AIエージェント開発の監査可能性で扱ったように、後から記録を追えることと、その場で止められることは別の話です。
「前に何をしたか」を条件に書けるようになった
AWS が2026年8月にオープンソースとして公開した Dogwood は、この隙間に手を入れるものです。
既存の認可記述言語 Cedar に対して、時間の条件を書ける拡張という位置づけになっています。Cedar が「いまのこのリクエストを許可するか」を判定するのに対し、Dogwood はエージェントのセッションの中で以前に行われたツール呼び出しとその応答を参照したうえで、現在の操作を許可するかどうかを決められます。ライセンスは Apache 2.0 で、Cedar との後方互換が保たれています。
書けるようになる条件として挙げられているのは、次のような類型です。
- 手順の順序 — 特定の操作を済ませていなければ次に進めない
- 人の承認をはさむ関門 — 承認を得た記録がある場合にのみ通す
- 引数の一致 — 承認された内容と、実際に実行しようとしている内容が同じかを照合する
- データの鮮度 — 取得してから一定時間を過ぎた情報にもとづく操作を止める
- 合計の上限 — 同時に走る複数のリクエストを横断して、累計額や回数で制限する
四つ目の「引数の一致」は地味ですが実務では効きます。承認画面で見た内容と、実際に実行される内容がずれるという事故は、人が承認する仕組みを入れたときに必ず候補に挙がる懸念だからです。
承認の回数が減ると、承認が機能し始める
こうした条件が書けることの本質的な効果は、確認を出す回数を減らせることにあります。
「順番として正しく、承認済みの内容と一致し、合計も上限内」という条件を機械側で判定できれば、人に確認を出す場面をそこから外せます。残るのは、機械では判断できない少数の場面だけです。1日30回の確認が3回になれば、その3回は読まれます。
逆に言えば、確認の回数を減らさないまま人の承認を積み増す設計は、安全性を上げているように見えて下げています。 AIエージェントを社内に入れるときの相談で、いちばん最初に整理すべきなのはここです。導入の全体像については業務で使うAIエージェントの考え方にまとめていますが、承認の設計はその中でも後回しにされやすい部分です。
導入をどう判断するか
温度感を正確に持っておく必要があります。
Dogwood は Amazon Bedrock AgentCore Policy で利用できる状態にありますが、公開されている参照実装については、検証と試用を想定したものであり本番運用向けではないと明示されています。 つまり「明日から自社の基盤に組み込む」段階のものではありません。
現時点で意味があるのは、次の二つです。
一つは、いま構築中または構築予定のエージェントについて、1件ずつの判定では捉えられないリスクが自社にあるかどうかを洗い出すこと。 顧客情報、送金、外部への送信、社外との契約に関わる操作。この四つのいずれかにエージェントが触れるなら、該当します。
もう一つは、発注時の要件として承認の設計を明示すること。 「危険な操作は人が承認する」という一文だけで発注すると、実装は1件ごとの確認ダイアログになります。それは冒頭の状態に戻る道です。要件として書くべきなのは、確認を出す条件と、確認を出さない条件の両方です。
発注する側が先に決めておくこと
見積もりを取る前に、社内で次の三点を決めておくと話が早く進みます。
一つ目は、エージェントに触らせない操作を列挙する。 認可の設計は「何を許すか」より「何は絶対に許さないか」を先に決めたほうが破綻しません。
二つ目は、人の承認を必須にする操作と、その承認者を決める。 誰が押すのかが決まっていないと、結局その場にいる人が押します。
三つ目は、合計で見るべき指標を決める。 金額、件数、外部送信の量。どれを累計で監視するかを先に決めておくと、実装時に「そこは見ていませんでした」が起きません。
この三点は技術的な検討ではなく、業務の決めごとです。発注側でしか決められないため、ここが空欄のまま開発が始まると、実装側は無難な方に倒します。 結果として確認が増え、承認が形骸化します。
次にやること
社内で稼働中、または検証中のAIエージェントについて、一連の作業で何回の確認が出ているかを数えてみてください。 1日あたり二桁に届いているなら、その確認は近いうちに読まれなくなります。
そのうえで、上に挙げた四つの領域（顧客情報・送金・外部送信・契約関連）にエージェントが触れているかを確認してください。触れていて、かつ確認が二桁出ているなら、承認の設計を作り直す段階にあります。
AIエージェントの権限設計、承認フローの見直し、既存システムとの連携を含む実装については、グリームハブの開発・AI・自動化のご相談で承っています。連携先の数と扱うデータの種類によって設計と工数が変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- AWS Open-Sources Dogwood, Extending Cedar to Govern Sequences of Agent Tool Calls — InfoQ
- Introducing Dogwood: runtime verification for AI agents — AWS Open Source Blog
- Securing AI agents with temporal policies in Amazon Bedrock AgentCore — AWS Machine Learning Blog
- AIエージェントの「認可疲れ」に効く処方箋 : 理論から実装まで — Zenn（AWS Japan）
