AIエージェントのリスク管理｜権限・ログ・人の承認をどう設計するか

梟〜GLEANINGS〜

2026年9月2日 21:30

AIエージェントを触ってみるところまでは進んだ。
けれど「会社として使っていいか」と聞かれると、答えに詰まる。
そういう段階の方が多いのではないかと思います。

止まる理由は、たいてい漠然とした不安です。
何かまずいことが起きそうな気はするけれど、具体的に何を決めればいいのかが分からない。

決めるべきことは、実はかなり具体的に言語化されています。
日本の行政文書にも、各国のサイバーセキュリティ当局が連名で出した文書にも書いてあります。
この記事では、その中身を見ていきます。

この記事は、各国当局の共同ガイダンスを含む、総務省・経済産業省・IPA・Five Eyes各国機関の一次資料をもとに、2026年9月時点の内容にしています。

怖いのは判断ミスではなく、連鎖

取り返しのつかなさが変わる

生成AIとAIエージェントの違いは、失敗したときの後始末の重さに出ます。

生成AIがメールの文面を1通おかしく書いても、送る前に読めば済みます。
人間が最後に必ず挟まる構造だからです。

AIエージェントは、その最後の1手まで自分で進みます。
発注、削除、送信、決済。
1つの判断ミスが、次の行動の前提になって連鎖していきます。
気づいたときには、取り消しの効かないところまで進んでいる。
これが自律性の裏側です。

だから対策の中心は「AIに間違えさせないこと」ではありません。
間違えることを前提に、どこで止まるようにしておくかを決めることです。

行政文書が挙げているリスク

総務省と経済産業省が2026年3月31日に公表した「AI事業者ガイドライン（第1.2版）」の別添は、AIエージェント特有のリスクとして次のような点を挙げています。

「AIエージェントでは、外部システムやクラウドサービスと自律的に連携して各種タスクを実行するケースが増えており、その過程で、脆弱性を突かれた攻撃等によってエージェントの挙動が不正に操作され、内部データが意図せず外部に送信されるなど、機密情報が漏洩する可能性がある」
「自律的な動作の中で人間の意図しない商品の注文やファイル削除等の動作を行う可能性」
「AIエージェントの自律性が高まるにつれ、人間による監視のみでは高速なAI間相互作用への対応が困難となる場合が十分に想定される」

3つめは、読み飛ばされがちですが重要です。
「人が見ていれば大丈夫」という前提が成り立たなくなる、と行政文書のほうから言っています。
人を1人張り付けても、AI同士がやり取りする速度には追いつけない。
監視の量を増やす方向では解けない問題だ、ということです。

日本のガイドラインは、どこまで書いているか

挙げられているのは3つ

第1.2版では、AI提供者向けの別添に、AIエージェントを念頭に置いた記述が加えられました。
総務省が公表した更新内容の資料は、その追記を次のように説明しています。

「AIエージェントやフィジカルAIは自律的に動作するため、人間の判断を介在させる仕組みの構築が重要である旨を追記」
「AIエージェントでは外部システムとの連携が増え、適切な連携ツール・システムの制限が重要である旨を追記」
「AIエージェントによる意図しない操作を防ぐために、適切な権限設定が重要である旨を追記」

人が判断に入る場所を決めておくこと。
つなぐ先を制限すること。
権限を適切に設定すること。
この3つが柱です。

方向性としては正しく、押さえるべき論点も外していません。
ただ、ここから先の「では具体的に何をするのか」は、読み手の側で埋める必要があります。
ログをどう取るか、権限をどう認証するか、判断に迷ったときエージェントに何をさせるか。
そこまでは書かれていません。

各国の当局は、もっと具体的に書いている

そこを埋めてくれる文書があります。

2026年5月、いわゆるFive Eyes（アメリカ、イギリス、オーストラリア、カナダ、ニュージーランド）の6つのサイバーセキュリティ機関が、「Careful adoption of agentic AI services」という共同ガイダンスを公表しました。
連名しているのは、オーストラリアのASD's ACSC、アメリカのCISAとNSA、カナダのCyber Centre、ニュージーランドのNCSC-NZ、イギリスのNCSC-UKです。

内容は、日本のガイドラインが方向性で止めた部分を、そのまま作業項目に落としたものになっています。
主なものを見ていきます。

人の承認をどこに挟むか

「Human in the loop」という見出しの下に、次のような項目が並んでいます。

「Ensure decisions about when human approval is required are determined by system designers or operators, not delegated to the agentic AI system」

人の承認がどこで必要かは、設計者か運用者が決めることであって、エージェント自身に委ねてはいけない。
これが最初に来ます。
エージェントに「重要そうなときは聞いてね」と指示するのは、判断そのものをエージェントに任せているのと同じだ、という指摘です。

「Prevent agents from autonomously executing high impact actions or outputs without prior human approval」

影響の大きい行動や出力は、事前の人間の承認なしに自律実行させない。

「Insert human-in-the-loop review or approval checkpoints for actions where the cost of error is high, such as system resets, network egress or deletion of critical records.」

間違いの代償が大きい行動には、確認や承認のチェックポイントを挟む。
例として挙がっているのは、システムのリセット、ネットワーク外部への送信、重要な記録の削除の3つです。

ログを消させない

同じ節に、こういう項目もあります。

「Quarantine requests to delete logs or audit records until reviewed and approved by a human」

ログや監査記録の削除要求は、人間が確認して承認するまで隔離する。

これは実務的にかなり鋭い指摘です。
攻撃者がシステムに入ったとき、最初にやることのひとつが痕跡の消去だからです。
エージェントが「不要なファイルを整理して」という指示を素直に受け取ってログを消してしまえば、後から何が起きたか分からなくなります。
削除要求だけは別扱いにする、という発想です。

そのログを何日分残すのかは、別の記事で扱っています。
1年という目安と、気づかないうちに消えてしまう3つの理由をまとめています。
https://note.com/yunta_fukurou/n/n25176ae28da1

ログそのものについては「Accountability」の節にこうあります。

「Integrate unified audit logs for all inter-agent interactions to maintain observability of all agent exchanges」

エージェント間のやり取りをすべて追えるように、統合された監査ログを組み込む。
エージェント1台ごとのログではなく、エージェント同士の会話まで含めて1本につなげておく、ということです。
複数のエージェントを連携させる構成では、どこで話がねじれたのかが1台のログだけでは追えません。

権限と、そのつど認証する

「Privileges and authentication」の節はこうです。

「Limit privileges of AI agents to the minimum required for its task」

エージェントの権限は、そのタスクに必要な最小限に絞る。
最小権限の原則そのものです。

これはガイドラインの「適切な権限設定」と同じことを言っていますが、続く項目に踏み込みがあります。

「Authenticate agents with fresh cryptographic proofs before every privileged call」

特権を伴う呼び出しのたびに、新しい暗号学的な証明でエージェントを認証する。

一度ログインしたら以降は通す、という作りにしない。
呼び出しごとに認証をやり直す。
エージェントは長時間動き続け、その間に外から与えられた情報で行動が変わりうるため、最初に確認した「本人らしさ」が途中で意味を失う可能性があるからです。

迷ったら止まる

「Secure by default」の節に、設計の既定値についての項目があります。

「Set system configurations to fail-safe by default requiring agents to stop and escalate issues to human reviewers in uncertain scenarios」

システムの設定は、既定でフェイルセーフにする。
判断がつかない場面では、エージェントは止まって人に上げる。

ここが実は一番大事かもしれません。
エージェントは、多くの場合「なんとかやり遂げる」ように作られています。
ツールの呼び出しに失敗したら別の方法を試し、情報が足りなければ推測で埋める。
その粘り強さが、想定外の場面では暴走に変わります。
既定値を「止まる」側に倒しておく、というのはその逆張りです。

日本のガイドラインが「人間の判断を介在させる仕組みの構築」と書いたところに、この文書は「どの行動に」「誰が決めて」「迷ったらどうするか」まで書き込んでいます。
実務で設計を始めるなら、こちらのほうが手が動きます。

攻撃する側から見たとき

国内の脅威ランキングに、いきなり3位で入った

IPAが2026年1月29日に公表した「情報セキュリティ10大脅威 2026」の組織編で、「AIの利用をめぐるサイバーリスク」が3位に入りました。
初選出です。

上位は1位がランサム攻撃による被害（11年連続11回目）、2位がサプライチェーンや委託先を狙った攻撃（8年連続8回目）。
長年上位に居座っている常連の直下に、初登場の項目が入り込んだ形です。

このランキングは、IPAが候補を選び、研究者や実務担当者が投票して決めています。
つまり、現場の人たちが「これは来ている」と感じているということです。

何が狙われるのか

攻撃手法の整理としては、OWASPのGen AI Security Projectが2025年12月9日に公開した「OWASP Top 10 for Agentic Applications 2026」があります。
エージェント特有の攻撃を10種類に整理したもので、内容は次のとおりです。

ASI01: Agent Goal Hijack（エージェントの目標の乗っ取り）
ASI02: Tool Misuse and Exploitation（ツールの悪用）
ASI03: Identity and Privilege Abuse（身元と権限の濫用）
ASI04: Agentic Supply Chain Vulnerabilities（サプライチェーンの脆弱性）
ASI05: Unexpected Code Execution（意図しないコード実行）
ASI06: Memory & Context Poisoning（記憶と文脈の汚染）
ASI07: Insecure Inter-Agent Communication（エージェント間通信の脆弱性）
ASI08: Cascading Failures（障害の連鎖）
ASI09: Human-Agent Trust Exploitation（人とエージェントの信頼関係の悪用）
ASI10: Rogue Agents（不正なエージェント）

並べてみると、1位が「目標の乗っ取り」であることが目を引きます。
システムを壊すのではなく、エージェントが目指しているものをすり替える。
エージェントは与えられた目標に向かって自分で手段を選ぶので、目標さえ書き換えれば、あとは本人が熱心に働いてくれるわけです。

8位の「障害の連鎖」も、冒頭で触れた話と同じ構図です。
1つの失敗が次の行動の前提になって広がっていく。

会社が把握していないエージェント

生成AIの利用では、会社が知らないうちに従業員が業務で使っている「シャドーAI」が問題になりました。
同じことがエージェントでも起きます。

しかも、こちらのほうが厄介です。
生成AIのシャドー利用は、社外にデータが出ることが主な問題でした。
エージェントは外部のツールと自律的につながって動くので、把握されないまま業務に組み込まれると、権限も、つなぎ先も、行動履歴も、誰も見ていない状態になります。

どの部署が、どのエージェントを、どんな権限で使っているか。
この一覧を持っていない状態は、対策以前の問題です。

生成AIのほうのシャドー利用は、別の記事で扱っています。
入力した情報の行き先と、個人プランの業務利用をまとめています。
https://note.com/yunta_fukurou/n/n0b6b85bdcbb4

今日から決められること

ここまでの一次資料を、実際に着手できる順に並べ直すと次のようになります。

どのエージェントが、どの部署で、どんな権限で動いているかを一覧にする
影響の大きい行動を洗い出す。金額の大きい取引、対外的な発信、重要なデータの削除・変更、システム設定の変更
その手前に人の承認を挟む。どこに挟むかは、設計する側が決める。エージェントに判断させない
権限を、そのタスクに必要な最小限まで落とす
行動履歴を残す。エージェントが複数あるなら、やり取りを1本のログにまとめる
ログや監査記録の削除だけは、必ず人の承認を通す
判断がつかないときの既定の動作を「止まって人に上げる」に決めておく

上から3つまでで、事故の大半は防げます。
全部を一度にやろうとして動けなくなるより、権限の棚卸しと承認ポイントの設定から始めるほうが現実的です。

この7つを社内の文書にするときのひな形を、別の記事で配っています。
条文と、権限と承認をどこに置くかの判断フローをまとめています。

2026年9月時点の最新状況

この1年の動きを時系列で並べます。

2025年12月9日：OWASPが「OWASP Top 10 for Agentic Applications 2026」を公開
2026年1月29日：IPAが「情報セキュリティ10大脅威 2026」を公表。「AIの利用をめぐるサイバーリスク」が組織編3位に初選出
2026年3月31日：総務省・経済産業省が「AI事業者ガイドライン（第1.2版）」を公表。AIエージェントの定義と、別添にリスクの記述が入る
2026年5月：Five Eyes6機関が「Careful adoption of agentic AI services」を公表
2026年7月14日：政府が第Ⅱ期の人工知能基本計画を閣議決定し、「エージェント型AIを軸に」という方針を打ち出す

法規制の側では、EUのAI Actに「AIエージェント」という独立したカテゴリはありません。
第3条の定義が「varying levels of autonomy」（さまざまな度合いの自律性）を持つ機械ベースのシステムと書いているため、新しいカテゴリを作らなくてもエージェントが含まれる構成になっています。
なお高リスクAIへの義務の適用開始は、2026年7月に成立した改正規則（Digital Omnibus on AI）によって、附属書IIIの高リスクが2027年12月2日、附属書Iの高リスクが2028年8月2日に変更されています。

推進の方針と、安全側の要求が、同じ時期に並行して固まってきた1年でした。

まとめ

AIエージェントで怖いのは1回の判断ミスではなく、それが次の行動の前提になって連鎖することです
AI事業者ガイドラインは、人の判断を挟む仕組み、つなぎ先の制限、適切な権限設定という3つを挙げています。方向性は示していますが、具体的な手順までは書かれていません
別添は「人間による監視のみでは高速なAI間相互作用への対応が困難となる」とも書いています。人を張り付ける方向では解けません
Five Eyes6機関の共同ガイダンスは、承認ポイント、監査ログ、最小権限、呼び出しごとの再認証、既定値のフェイルセーフまで具体的に書いています。設計を始めるならこちらが手が動きます
ログの削除要求だけは人の承認を通す、という項目は特に効きます。痕跡を消されると、後から何も追えなくなります
IPAの「情報セキュリティ10大脅威 2026」で、AI利用をめぐるリスクが組織編3位に初選出されました
まずは権限の棚卸しと、承認を挟む場所の決定から。全部を一度にやろうとしないことです

生成AIとの違い、自律的に動く仕組み、使い分けと製品選び、そしてリスク管理。
この連載では、この順で一通り扱ってきました。
noteでは3本に分けています。

皆さんの職場では、AIに任せてよい範囲はもう決まっているでしょうか。
それとも、まだ誰も決めていない状態でしょうか。

参考・引用元

経済産業省・総務省「AI事業者ガイドライン（第1.2版）」（令和8年3月31日） https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html
総務省「AI事業者ガイドラインの令和7年度更新内容」（令和8年3月12日） https://www.soumu.go.jp/main_content/001059300.pdf
同本編PDF https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf
同別添（溶け込み版）PDF https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_3.pdf
ASD's ACSC、CISA、NSA、Cyber Centre、NCSC-NZ、NCSC-UK「Careful adoption of agentic AI services」 https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services
同 PDF（NZ NCSC） https://www.ncsc.govt.nz/assets/guidance/Documents/Careful-adoption-of-agentic-AI-services_FINAL.pdf
NCSC-UK「Thinking carefully before adopting agentic AI」（2026年5月15日） https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai
IPA「情報セキュリティ10大脅威 2026」（2026年1月29日） https://www.ipa.go.jp/security/10threats/10threats2026.html
OWASP Gen AI Security Project「OWASP Top 10 for Agentic Applications 2026」（2025年12月9日） https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
内閣府「人工知能基本計画（第Ⅱ期）」（令和8年7月14日閣議決定） https://www8.cao.go.jp/cstp/ai/ai_plan/aiplan_20260714.pdf
EU「Regulation (EU) 2024/1689（AI Act）」 https://eur-lex.europa.eu/eli/reg/2024/1689
EU「Regulation (EU) 2026/1744（Digital Omnibus on AI）」 https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
書籍：日経BP「生成AIの法的リスクと対策増補改訂版」 https://bookplus.nikkei.com/atcl/catalog/25/12/11/02376/
ブクログ（同書のレビュー） https://booklog.jp/item/1/4296209795

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40