目次
AIエージェントの統制について、このブログではこれまで、権限・時間・原価・承認・証跡・退役・出典・復旧と、設計すべき対象を1つずつ取り上げてきた。いずれも「その能力を、どこまで絞るか」という問いである。
だが、1つずつ絞っても防げない問題がある。それぞれは妥当な権限なのに、組み合わさった瞬間に危険になるという問題だ。
外部から届いたメールを読む。これは問題ない。顧客台帳を参照する。これも業務上必要だ。基幹システムに登録する。これも自動化の目的そのものだ。だが、この3つを同じエージェントが、同じ文脈の中で持った瞬間、外部の誰かが書いた一文が、顧客台帳の中身を外に持ち出す命令に化けうる。
個別の権限審査では、この組み合わせは見えない。審査は能力ごと、部門ごとに行われるからだ。
2026年9月14日、スペインの規制当局に届いた「最初の1件」
2026年9月にスペインのデータ保護当局AEPDへ届いた初のAIエージェント侵害届出の概要。9月14日に届出を受理し、9月15日にFrancisco Pérez Bes副局長が当局ブログで公表した。攻撃の流れは、①汎用ファイルから脆弱性を探索、②ログインに成功、③アプリケーション内の脆弱性を自律的に探索、④発見した欠陥を突いて個人データを改変、⑤請求書にアクセス。組織名・使用モデル・業種・影響人数は非公表。当局の見立ては、AIは新しい脅威を生むのではなく既知の手口の速度・規模・適応性を増幅し、検知と封じ込めに使える時間を縮めるというもの。同じ週の9月22日にはCisco Talosが人間のオペレーターなしで動く自律型C2インプラントCLOSEDQUORUMを公表した
2026年9月14日、スペインのデータ保護当局であるAEPD（Agencia Española de Protección de Datos）は、自律型AIエージェントが関与したデータ侵害の届出を初めて正式に受理した。翌15日、同当局のFrancisco Pérez Bes副局長が当局のブログでこれを公表している。
当局が明らかにした経緯は短い。攻撃側のエージェントは、まず汎用的なファイル群から脆弱性を探し、ログインに成功した。システムに入ったあとは、アプリケーション内の脆弱性を自律的に探し始め、見つけた欠陥を突いて個人データを改変し、請求書にアクセスした。
組織名、使われた言語モデル、業種、影響を受けた人数は公表されていない。副局長自身も「結論を出す前に、さらなる分析が必要だ」と述べている。
それでも当局の結論ははっきりしていた。「AIに支援された攻撃は、もはや理論上のリスクではない」。そして、AIは全く新しい脅威を生むのではなく、既知の手口の速度・規模・適応性を増幅し、検知と封じ込めに使える時間を縮めるのだと整理した。対策の方向としては、「人による監督は引き続き不可欠だが、十分な速さで動く検知・封じ込め・対応の仕組みに支えられていなければならない」としている。
同じ週の9月22日には、Cisco Talosが「CLOSEDQUORUM」と名付けたマルウェアを公表した。DeepSeek、Qwen、Mistral、Geminiの4つの商用モデルに攻撃手順を多数決で決めさせる実装で、人間のオペレーターからの継続的な指示も、攻撃者が運用する専用のC2サーバーも必要としない。実環境での展開は確認されておらず、配布物にはダミーのAPIキーが入ったテンプレート段階のものだったが、Talosの指摘は明快だ。「攻撃の一段階を実行できるAIは、オペレーターが見ていなくても動き続ける。攻撃者が眠っても止まらない」。
ここから引き出すべき示唆は、「攻撃が高度化した」という一般論ではない。自社のエージェントが読む「外部からの入力」を、機械が、機械の速度と量で書くようになったという事実である。
規制当局は7ヶ月前に線を引いていた ― 「3つのうち、2つまで」
「3つのうち2つまで」の原則。3つの性質は、[A
注目すべきは、この届出を受けたAEPD自身が、7ヶ月前にこの種のリスクへの線を引いていたことだ。
2026年2月18日、AEPDは「データ保護の観点から見たエージェント型AIに関する指針（Orientaciones sobre Inteligencia Artificial agéntica desde la perspectiva de protección de datos）」を公表した。その中核にあるのが「2のルール（regla de 2）」である。次の3つの状況は、同時に成り立つのは最大2つまでとする。
- 管理されていない情報を受け取りうること
- 機微な情報に制限なくアクセスできること
- 実際に効果を持つ自動的な行動を実行できること
AEPD自身、これは単純化した整理であり「出発点」にすぎないと認めている。だが、出発点として置かれた意味は大きい。規制当局が、個々の能力ではなく「組み合わせ」を審査の単位として示したからだ。
この考え方の原型は、Metaが2025年10月31日に公表した「Agents Rule of Two」にある。Metaは3つの性質を、[A]信頼できない入力を処理できる、[B]機微なシステムや個人データにアクセスできる、[C]状態を変更するか外部と通信できる、と定義し、1つのセッションで満たしてよいのは2つまでとした。そして3つ全部が必要な場合、そのエージェントは自律的に動かしてはならず、少なくとも人による承認か、それに代わる信頼できる検証の下に置くべきだとしている。
Metaが挙げた例は、そのまま設計のひな形になる。旅行予約のエージェントはWebを検索し（A）、利用者の予約情報に触れる（B）が、予約を確定する前には人が確認する。Webリサーチのエージェントは任意のURLを読み（A）、リクエストを実行する（C）が、機微データには触れない。社内のコーディングエージェントは本番環境に触れ（B）、変更を加える（C）が、信頼できる入力源しか読まない。そして、外部のメールを読み、受信箱の中身に触れ、返信を送るメールボットは、3つ全部を持っている。
このルールが優れているのは、防御の前提を「エージェントは騙されない」に置いていない点だ。プロンプトインジェクションを検知する分類器がどれだけ優秀でも、いずれどこかで騙される。問うべきは、騙されたときにエージェントが何に手を届かせられるかである。3本の脚のうち1本を外せば、注入された指示は攻撃として完結しない。
では、3つ全部を持ったエージェントは、どこにいるのか。答えは、すでに市場の最前線にいる。
9月8日にMetaが公開した消費者向けエージェント「Muse」は、公開から1週間で米国のiPhone無料アプリ1位になった。メール、カレンダー、決済、買い物までを代行する。Webを読み、利用者のアカウントに入り、購入を実行する。典型的な3つ全部の構成である。9月20日、Amazonは自社サイトでのMuseの利用を遮断した。自動化されたエージェントであることを名乗らずにアクセスし、アカウントページや注文履歴に入り、取引を処理していることを理由に挙げている。
背景には広告収益（Amazonの前年の広告売上は680億ドル超）をめぐる商業的な対立もあり、どちらが正しいかをここで判定するつもりはない。Meta側は、ログイン情報は安全な保管領域に入り、エージェント本体からは見えない設計だと説明している。これは「持たせない」ではなく「見せない」という形で[B]を切り離す実装であり、それ自体は2つまでの原則に沿った工夫と言える。
大企業にとっての論点は別のところにある。3つ全部を持ったエージェントは、自社が作るものだけではない。顧客の側から、取引先の側から、攻撃者の側から、自社のシステムに向かってやってくる。
それでも3つ全部が要るとき ― Anthropicが公開した「監督の3つの数字」
Anthropicが2026年9月17日に公表した社内エージェント監督の数字（自己申告・第三者監査なし）。社内の研究・開発基盤で約3万体のエージェントが稼働し、2026年8月の判断は10億件超。オンライン監視は実行前に全アクションの100%を通常数秒以内に確認し、ブロックしたのは0.002%（約4万7000件に1件、月約2万件）。オフライン監視は1000件に1〜2件の割合で記録を抽出し週約10万件を追加の自動レビューに回す。最終的に人が確認するのは最優先の週約50件。監督の3つの指標はカバレッジ（監視を通過する行動の割合）、レビュー遅延（行動から確認までの時間）、エスカレーション率（止めた・人に回した割合）。論点は、3つ全部を持つ設計を人の目で支えるなら、人が見る件数は誰がどう決めたのか
とはいえ、業務の現場では3つ全部が必要になる場面は避けられない。問い合わせメールを読み、顧客情報を照会し、回答を送る。これは多くの企業がまさに自動化したい業務である。原則は「その場合は自律実行させず、監督下に置く」だった。では、監督下に置くとは、具体的にどういう状態なのか。
この問いに、珍しく実数で答えた資料がある。2026年9月17日、Anthropicは「フロンティアラボ内部のAI開発ペースを理解するための計測」と題した文書で、自社の研究・開発基盤で動くエージェントの監督状況を公開した。
- 社内の研究・開発基盤で稼働するエージェントは約3万体
- 2026年8月に分析したエージェントの判断は10億件超
- 基盤上の全アクションは、実行前にオンライン監視を100%通過し、確認は通常数秒以内
- オンライン監視がブロックしたのは0.002%（約4万7000件に1件）。単純計算で月約2万件
- 事後のオフライン監視は、1000件に1〜2件の割合で記録を抽出し、週約10万件を追加の自動レビューに回す
- そのうち人が確認するのは、最優先の週約50件
同文書は、監督の状態を3つの指標で表している。カバレッジ（監視を通過する行動の割合）、レビュー遅延（行動から確認までの時間）、エスカレーション率（止めた、あるいは人に回した割合）である。
注意点は2つある。第一に、数字はすべて自己申告で、第三者による監査は受けていない。ブロックは「実行すべきでない」という監視側の判断であって、実害が確認された件数ではない。見逃し率も検証されていない。第二に、対象は1つの社内基盤に限られる。
それでも、この数字が示す構造は、どの企業にもそのまま当てはまる。10億件の判断を支えている人の目は、週50件分しかない。残りはすべて、機械による監視と、機械による絞り込みで回っている。
つまり「人による監督」とは、人がすべてを見ることではない。機械がどこまでを見て、何を人に回すかを設計することである。そして、その設計がなされていない「承認フロー」は、件数が増えた時点で形骸化する。このブログで扱った承認の形骸化と同じ構造だ。
ここで経営として問うべきは、自社の3つ全部を持つエージェントについて、次の3つの数字を答えられるかどうかである。何割の行動が監視を通っているか。止めた行動を人が見るまでに何時間かかっているか。月に何件を止め、何件を人に回しているか。 答えられないなら、そのエージェントは「監督下」ではなく、単に「監督の意図があるだけ」の状態にある。
日本企業で「3つ全部」が生まれやすい3つの理由
日本企業で3つ全部が生まれやすい3つの理由。理由①PoCは追加要望で育つ：最初は社内文書の要約だけ、次に取引先メールも読ませたい、次に顧客台帳も参照させたい、最後に基幹へ自動登録まで。1回ずつの変更は小さく、各段階の審査は通るが、気づくと3つ全部が揃っている。理由②外部から届く文書が業務の主役：受発注の注文書、取引先のPDF、問い合わせフォームの自由記述、FAXのOCR結果。自動化したい業務ほど入力の出どころが社外にある。理由③審査が能力別・部門別に分かれている：情報セキュリティ部門はデータ区分を、業務部門は自動化範囲を、情報システム部門は接続先を見る。誰も組み合わせを見ていない。どの部門の審査にも落ちないまま3つ全部が本番に出る
この原則は海外の規制の話に見えるかもしれない。だが、3つ全部を持つエージェントが生まれやすい条件は、むしろ日本の大企業のほうに揃っている。
第一に、PoCは「追加要望」で育つ。
多くのPoCは、社内文書の要約や検索といった、2つ以下の構成から始まる。そこから段階的に要望が足される。「取引先から届くメールも読ませたい」（Aが加わる）。「回答の精度を上げたいので顧客台帳も参照させたい」（Bが加わる）。「人が転記している部分も、基幹システムへ自動登録させたい」（Cが加わる）。
1回ずつの変更は小さく、それぞれの段階で個別の審査は通る。だが、気づいたときには3つ全部が揃っている。株式会社Merの調査（2026年6月実施、従業員100名以上の生成AI活用企業548名）で、エージェントに業務システムへの自動反映まで任せている企業は27.2%だった。この比率は、今後の横展開とともに確実に上がっていく。
第二に、自動化したい業務ほど、入力の出どころが社外にある。
受発注の注文書、取引先から届くPDFの見積書、問い合わせフォームの自由記述、FAXをOCRにかけた結果。日本の大企業で「人手がかかっている」と言われる業務の多くは、社外から届く文書を読み、社内のシステムに反映する業務である。これはAの性質を持った入力が、業務の主役であることを意味する。
しかも、その文書を書く側にも、これからはエージェントが入ってくる。取引先の見積書をエージェントが作り、自社の受付エージェントがそれを読む。そこに悪意ある第三者の一文が紛れ込んだとき、それを「業務文書」と「命令」に見分ける仕組みは、エージェントの内側にはない。
第三に、審査が能力別・部門別に分かれている。
情報セキュリティ部門はデータ区分（B）を見る。業務部門は自動化の範囲（C）を見る。情報システム部門は接続先を見る。外部入力の信頼性（A）は、多くの場合どこの審査項目にも明示的には入っていない。
それぞれの審査は妥当に行われている。だが、誰も組み合わせを見ていない。その結果、どの部門の審査にも落ちないまま、3つ全部を持ったエージェントが本番に出る。これは担当者の怠慢ではなく、審査様式の設計の問題である。
国内の指針も、エージェントを明示的に扱い始めている。経済産業省・総務省の「AI事業者ガイドライン」第1.2版（2026年3月31日）は自律型AIエージェントを定義に加え、入出力や判断根拠のログを求めている。AIセーフティ・インスティテュート（J-AISI）も2026年7月7日、「AIセーフティに関する評価観点ガイド」を第1.20版に改訂し、エージェントシステムの普及を踏まえて評価観点と評価項目例を拡充した。ただし、「どの能力を組み合わせてはいけないか」を審査の単位として示すところまでは、まだ踏み込んでいない。そこは各社が自ら決める領域として残っている。
本番化基準に書き足す5つのこと
本番化基準に書き足す5つのこと。①エージェントごとにA・B・Cの3文字を台帳に書く：案件単位ではなくエージェント単位で、信頼できない入力・機微データ・状態変更のどれを持つかを記録する。②3つ揃う設計はセッションを割って2つに落とす：外部文書を読む係は機微データにも書き込みにも触れず決められた形式の抽出結果だけを渡す。「持たせない」だけでなく「見せない」でも切り離せる。③社内から届いたものも信頼できない入力として既定する：取引先メール・添付ファイル・チケットの自由記述・他エージェントの出力。④3つ全部が残るものは監督の3つの数字を先に決める：カバレッジ・レビュー遅延・エスカレーション率を本番化の前に合意し、人が見る件数を設計する。⑤追加要望のたびに3文字を再判定する：新しいデータ源・新しい接続先・新しい書き込み権限を変更管理のトリガーにする
これまでの8つの設計対象（権限・時間・原価・承認・証跡・退役・出典・復旧）が、それぞれ1つの能力をどう扱うかの設計だったとすれば、9つ目は組み合わせの設計である。
① エージェントごとに「A・B・C」の3文字を台帳に書く。
案件単位ではなく、エージェント単位で記録する。そのエージェントは信頼できない入力を読むか（A）、機微なデータやシステムに触れるか（B）、状態を変えるか外部と通信するか（C）。台帳の1列に「AB」「BC」「ABC」と書くだけでよい。
地味な作業だが、これが組み合わせを審査の単位にする唯一の方法である。3文字が書かれていない限り、各部門の審査は能力ごとに分断されたまま、誰も全体を見ない。
② 3つ揃う設計は、セッションを割って2つに落とす。
問い合わせ対応であれば、外部のメールを読んで要件を抽出する係（A）と、顧客台帳を照会して回答案を作り登録する係（BC）を分ける。前者は機微データにも書き込み権限にも触れず、あらかじめ決めた形式の抽出結果だけを後者に渡す。後者は自由文を受け取らない。
Metaの原則が「新しいセッションを始めずに3つ全部が必要なら」と条件を付けているのは、このためだ。文脈を切れば、注入された指示は次の段に持ち越されない。また、Museの例のように、資格情報を保管領域に置いてエージェント本体から見えなくするという、「持たせない」ではなく「見せない」という切り離し方もある。
③ 「社内から届いたもの」も、信頼できない入力として既定する。
Aの判定で最も見落とされやすいのが、社内の経路を通ってきた外部入力である。取引先から届いて社内で転送されたメール、共有フォルダに置かれた添付ファイル、チケットシステムの自由記述欄、そして他のエージェントの出力。
経路が社内であることは、中身が信頼できることを意味しない。判定の既定値は「信頼できない」に置き、信頼できる入力源を明示的に列挙する方式にする。逆ではない。
④ 3つ全部が残るものは、「監督の3つの数字」を先に決める。
どうしても分割できず、3つ全部を持ったまま本番に出すエージェントには、本番化の前に3つの数字を合意する。カバレッジ（監視を通る行動の割合）、レビュー遅延（止めた行動を人が見るまでの時間）、エスカレーション率（止める・人に回す割合の想定値と上限）。
そして、人が確認する件数を「週に何件まで」と設計する。Anthropicの例では、10億件の判断に対して人の目は週50件だった。人の処理能力を超える件数が人に回る設計は、監督ではなく、形骸化の予約である。
⑤ 追加要望のたびに、3文字を再判定する。
新しいデータ源の追加、新しい接続先の追加、新しい書き込み権限の付与。この3つを、変更管理のトリガーとして明示する。「AB」だったエージェントに書き込み権限を1つ足す変更は、軽微な機能追加ではなく、別のエージェントへの作り替えとして扱う。
第一の理由で見たとおり、3つ全部は一度に生まれるのではなく、追加要望の積み重ねで生まれる。だから、判定は本番化のときに一度だけ行うのでは足りない。変更のたびに行う必要がある。
まとめ
AIエージェントの統制をめぐる議論は、これまで「その能力をどこまで絞るか」に集中してきた。どれも必要な議論である。だが、1つずつ絞った権限でも、組み合わされば危険になる。統制の単位は、能力ではなく組み合わせである。
スペインのAEPDに届いた初の届出は、攻撃側のエージェントが、人間の速度を超えて脆弱性を探し、データを改変するところまで来ていることを示した。そしてその7ヶ月前に、同じ当局は「3つのうち2つまで」という、驚くほど単純な線を引いていた。
この線の価値は、単純さにある。技術の専門家でなくても、台帳の1列を見れば、そのエージェントが危険な組み合わせを持っているかどうかが分かる。経営会議で問えるAIのリスク指標は、実はそう多くない。「3つ全部を持つエージェントは何体あり、それぞれ誰が、どの数字で監督しているか」は、その数少ない1つになりうる。
そして、この線引きは本番化を止めるためのものではない。2つまでに収まる設計であれば、自律実行の範囲をむしろ広く取れる。3つ全部を避ける設計こそが、人の承認を減らし、エージェントを増やすための前提条件になる。
Wizitは、PoCで止まったAIを本番運用とROIまで動かし切る実装パートナーとして、大企業の現場でこの種の「本番化の直前で止まる論点」に向き合っています。エージェントの組み合わせの棚卸しから、分割の設計、監督の数字の合意まで、業務部門と情報システム部門の間に入って手を動かす形でご支援しています。
---
出典:
- Agencia Española de Protección de Datos（AEPD）副局長 Francisco Pérez Bes による当局ブログでの公表（2026年9月15日、9月14日受理の届出について）ならびに Help Net Security（2026年9月17日）、BleepingComputer・SecurityWeek（2026年9月16日）による報道
- AEPD「Orientaciones sobre Inteligencia Artificial agéntica desde la perspectiva de protección de datos」（2026年2月18日公表）
- Meta AI「Agents Rule of Two: A Practical Approach to AI Agent Security」（2025年10月31日）
- Anthropic「Measurements for understanding the pace of AI development inside frontier labs」（2026年9月17日）
- Cisco Talos「The Closed Quorum: Inside the first reported autonomous AI C2 implant」（2026年9月22日）
- GeekWire・Bloomberg による Amazon の Meta Muse 遮断に関する報道（2026年9月20〜22日）
- 経済産業省・総務省「AI事業者ガイドライン」第1.2版（2026年3月31日）
- AIセーフティ・インスティテュート「AIセーフティに関する評価観点ガイド」第1.20版（2026年7月7日）
- 株式会社Mer「Japan AI Operations Report 2026 Summer」（2026年6月調査、従業員100名以上の生成AI活用企業548名）