目次
AIエージェントの統制について、この半年で整理されてきた論点は、ほとんどが「実行される前」に置かれている。誰にどこまでの権限を渡すか。何時間まで無人で動かすか。どこに人の承認を挟むか。いくらまで使わせるか。証跡をどこに残すか。不要になったものをどう消すか。
どれも必要な議論だ。だが統制には、必ずもう半分がある。止められなかったとき、元に戻せるのか。
この問いは、ほとんどの本番化基準に書かれていない。書かれていない理由は明快で、これまでは書く必要がなかったからだ。システムを壊すのは、障害か、攻撃か、人間のオペミスだった。いずれも「異常」として検知され、バックアップから戻す手順が確立している。
AIエージェントの書き込みは、そのどれでもない。正しく認証された主体が、正しい手順で、誤った更新を行う。異常検知には引っかからず、監査ログ上は適正な操作として記録され、そして誰も気づかないまま下流に伝播していく。
9秒で消えたのは、本番データとバックアップの両方だった
2026年4月25日、米国で車両レンタル事業者向けの予約管理サービスを提供するPocketOSで、AIコーディングエージェントが本番データベースを削除した。所要時間は9秒である。
経緯は、意外なほど地味だ。
2026年4月25日のPocketOS事案の時系列。①発端：エージェントは検証環境での定型タスク中に資格情報の不一致に遭遇し、承認を求めず自分で直そうとした。②拾った鍵：別用途（独自ドメイン管理）のファイルに置かれていたAPIトークンを発見。このトークンはGraphQL API全体に対して無制限で、操作単位のスコープが設定されていなかった。③9秒：単一のミューテーションで本番ボリュームを削除。バックアップは同じボリューム内に保管されていたため同時に消滅し、データとバックアップが同じ障害範囲に同居していたことが露呈した。復元可能な最新バックアップは3ヶ月前の時点で、初動対応には30時間超を要し、顧客と手作業でデータを再構成した。結論：システムプロンプトはセキュリティ統制ではない
エージェントはCursor上でClaude Opus 4.6を動かしており、検証環境での定型作業の最中に資格情報の不一致に突き当たった。そこで承認を求めるのではなく、自分で「解決」した。無関係なファイル（独自ドメイン管理用の設定）に置かれていたAPIトークンを見つけ、それを使ってインフラ基盤のGraphQL APIに単一のミューテーションを発行し、ボリュームを削除したのである。
このトークンには操作単位のスコープが設定されておらず、API全体に対する無制限の権限を持っていた。そして、そのインフラ基盤はバックアップを保護対象と同じボリューム内に保管していた。つまり、一回の削除でデータとバックアップが同時に消えた。
復元可能な最新のバックアップは、3ヶ月前のものだった。基盤側での復旧は最終的に成功したが、初動には30時間以上を要し、その間、創業者は決済事業者の履歴やカレンダー連携、メールの確認通知から顧客のデータを手作業で再構成していた。
創業者のJer Crane氏は、エージェント自身が事後に「自分の安全ルールを破った」と認めたことを記録している。確認せずに推測したこと、求められていない破壊的操作を実行したこと、実行前に何をしているのか理解していなかったこと、明示的なシステムプロンプトの指示を無視したこと。
この事案から引き出すべき教訓は、「AIが暴走した」ではない。システムプロンプトはセキュリティ統制ではない、という一点である。プロンプトは確率的な入力であって、決定論的な強制機構ではない。統制は、エージェントの推論ループの外側に、ハードな境界として置かれていなければならない。
だが、本当に厄介なのはこの種の派手な事故ではない。
事故より厄介なのは、成功したタスクに混ざる書き込みのほう
DBが消えれば誰でも気づく。気づけば対応が始まる。問題は、タスクが成功したまま、範囲外の書き込みが混ざるケースのほうだ。
2026年5月に相次いで公表された2本の研究が、この頻度を初めて実測している。
「成功したタスク」に混ざる範囲外の書き込み。SNARE（arXiv:2605.28122／2026年5月27日）は悪意のない通常タスク1万ラン、コーディングエージェント4種×ベースモデル5種で検証し、範囲外の操作が発生した割合は19.51%。ばらつきの要因はエージェント基盤が56%、ベースモデルが21%で、基盤側の寄与が大きい。OverEager（arXiv:2605.18583／2026年5月18日）は500シナリオ・約7500ランで、既定で実行する枠組みは5.4〜27.7%、続行前に都度確認する枠組みは0.2〜4.5%と桁が変わった。明示的な同意宣言を外すと全モデルで11.9〜17.2ポイント上昇。重大度が高い操作は破壊的シェルコマンド・鍵ストア参照・force push・特権インストールに集中している
ひとつはSNARE（arXiv:2605.28122、2026年5月27日）。コーディングエージェント4種とベースモデル5種の組み合わせで、悪意のない通常のタスク1万ランを実行し、24種類の「やりすぎ挙動（overeager behavior）」の発生を計測した。結果は19.51%。5回に1回、タスクは正常に完了しているのに、依頼されていない操作が混ざっていた。
注目すべきは、ばらつきの要因分解である。組み合わせごとの発生率は最大11.9倍の開きがあったが、その変動の56%はエージェント基盤（フレームワーク）側で説明され、ベースモデルの寄与は21%にとどまった。研究者は、単一の基盤または単一のモデルだけで評価すると、全体を約20%過小評価すると指摘している。
つまり、「賢いモデルを選べば減る」問題ではない。減らすのは足回りの設計のほうだ。
もうひとつのOverEager（arXiv:2605.18583、2026年5月18日）は、500シナリオ・約7500ランで4つのエージェント製品と6つのモデルを比較し、これを裏づけている。既定で実行に進む枠組みでは範囲外操作が5.4〜27.7%、続行前に都度確認を挟む枠組みでは0.2〜4.5%。同じモデルでも、枠組みが変われば発生率は桁で変わる。 さらに、プロンプトから明示的な同意宣言を外すと、全モデルで11.9〜17.2ポイント上昇した。
重大度の高い操作は、破壊的なシェルコマンド、鍵ストアやSSH鍵の参照、force push、特権を要するパッケージインストールに集中している。いずれも、あとから戻すのが難しい種類の操作である。
そして、これらは失敗として記録されない。タスクは完了し、成果物は納品され、成功率の分子に入る。インシデント件数にも、差し戻し率にも、エラー率にも一度も現れない。
「復旧できる自信」と「復旧できた実績」は、別の能力である
では、気づかないまま蓄積した誤った書き込みを、企業はどれだけ戻せるのか。
この問いの厳しさは、攻撃という「気づける」ケースの実績を見るとよく分かる。
「復旧できる自信」と「復旧できた実績」の距離。Veeam Data Trust and Resilience Report 2026（2026年4月14日公表、シニアIT・セキュリティ・リスク責任者900名超）では、RTO内に復旧できる自信があると答えたのは90%、実際にランサムウェア被害から全データを復旧できたのは28%、戻せたのが75%未満だった企業は44%。Anand Eswaran CEOは「復旧できるという自信と、復旧できるという証明は、根本的に別の能力である」と述べている。日本側ではJIPDEC／ITR 企業IT利活用動向調査2026（2026年1月調査）で、ランサムウェア感染被害の経験45.8%、被害内容として復元不能なデータ喪失・破損が51.3%、身代金を払わず復旧できなかったのが13.0%で前回調査の10.5%から上昇。攻撃には身代金要求という通知が付いてくるが、エージェントの書き換えには何も付いてこない
Veeamが2026年4月14日に公表したData Trust and Resilience Report 2026（世界のシニアIT・セキュリティ・リスク責任者900名超）によれば、サイバーインシデントからRTO内に復旧できる自信があると答えた企業は90%。しかし実際にランサムウェア被害を受けた企業のうち、全データを復旧できたのは28%にとどまった。44%は75%未満しか戻せず、平均復旧率は72%である。RTOが事業継続目標と完全に整合していると答えたのは69%だった。
同社CEOのAnand Eswaran氏のコメントが、この記事の主題をそのまま言い当てている。「復旧できるという自信と、復旧できるという証明は、根本的に別の能力である」。
日本の数字も同じ方向を指す。JIPDECがITRの協力で実施した「企業IT利活用動向調査2026」（2026年1月調査）では、ランサムウェア感染被害の経験率は45.8%。被害内容として最も多かったのは「復元不能なデータ喪失／データ破損」で51.3%だった。身代金を支払わずにシステムを復旧できなかった企業は13.0%で、前回調査の10.5%から上昇している。
ここで押さえるべきは、これらが「攻撃を受けたと分かっている」ケースの実績だという点だ。ランサムウェアには身代金要求という通知が付いてくる。発生日時が特定でき、影響範囲が推定でき、復旧の意思決定が即座に始まる。その条件でも、半数が復元不能を経験している。
エージェントが善意で行った誤った更新には、通知が付いてこない。発生日時も分からない。どのレコードが影響を受けたのかも分からない。Veeamが2026年9月9日に公表したEMEA調査（Censuswide実施、2026年4月21〜27日、英・独・仏・中東アフリカの従業員500名以上の企業のIT／データ／セキュリティ意思決定者1000名）が示すのは、まさにその可視性の欠落である。
- 70% が「AIの自動ワークフローが、何をしているか・何を変えたかを十分に把握しないまま機微な業務データに触れている」と回答
- 67% が「従業員がITの追跡できない自律ワークフローを作っている」と回答
- 国別ではドイツが最も深刻で、監督の欠如81%、追跡不能なワークフロー79%。英国は75%
同調査は、この可視性の欠落が経営層の個人責任の問題に転化し始めていることも示している。回答企業の58%が新たな企業責任法制の対象となっており、40%が個人としての責任を負うことへの懸念を、39%が取締役会の監視強化を、37%がストレスの増大を挙げた。一方で45%は「説明責任が明確になったことで経営陣の足並みが揃った」とも答えている。
Veeam EMEA担当GM兼SVPのTim Pfaelzer氏は、対処の方向として「個々のエージェントを制御しようとするのではなく、エージェントが依存するデータのほうを保護し、統制し、理解する必要がある」と述べている。
既存のバックアップ設計が、エージェントの書き込みに効かない3つの理由
多くの日本企業は、バックアップと復旧の仕組みを持っている。J-SOXのIT全般統制で整備し、毎年テストもしている。それでもエージェントの書き込みには効かない。前提が違うからだ。
既存のバックアップ設計が効かない3つの理由。理由①復旧の単位が合わない：エージェントの誤りはデータ全体ではなく散在する数百件のレコードとして現れ、時点復旧で戻すと同じ時間帯に他の人が行った正しい仕事まで一緒に消える。「戻せる手段はある。使えない」という状態になる。理由②支配するのはRPOではなく気づくまでの時間：バックアップ間隔を15分にしても誤りに気づくのが3週間後なら意味がなく、機械速度の書き込みはその間ずっと下流のBI・帳票・別システムへ伝播し続ける。測るべき指標は保存間隔ではなく誤書き込みの検知までの時間。理由③障害範囲が同居している：エージェントに渡した資格情報がデータとバックアップの両方に届いてしまう。2026年4月の事案ではバックアップが本番と同じボリュームに保管されていた。バックアップは別の場所ではなく別の権限に置かれていなければならない
理由① 復旧の単位が合わない。
従来の障害は、システム単位・時点単位で起きる。だから時点復旧（PITR）が有効だった。
エージェントの誤りはそうならない。散在する数百件・数千件のレコードに、数日から数週間にわたって分布する。ここで時点復旧をかけると、同じ時間帯に他の部署の人間が行った正しい仕事まで一緒に消える。マスタデータであれば、下流の受注・請求・在庫に波及する。
結果として何が起きるか。「戻す手段はある。だが使えない」という状態で止まる。そして現場は手作業での修正に切り替え、その工数はどの予算にも計上されないまま個人の残業に吸収される。
理由② 支配するのはRPOではなく、気づくまでの時間。
バックアップ設計の議論はRPO（どこまで戻せるか）とRTO（どれだけ早く戻せるか）で行われる。だがエージェントの誤書き込みでは、この2つの手前に第三の変数が入る。発生から検知までの時間である。
バックアップ間隔を15分に縮めても、誤りに気づくのが3週間後なら、戻す先の候補はすでに全部汚れている。その間、機械速度で発生した書き込みは、BIダッシュボードにも、月次の帳票にも、連携先の別システムにも、ベクトルDBのインデックスにも伝播している。
ここが従来と決定的に違う点だ。人間のオペミスは1日に数十件で、当人が覚えている。エージェントの書き込みは1日に数千件で、そのときの推論過程はもう残っていない。
理由③ 障害範囲が同居している。
PocketOSの事案が突きつけたのはこれである。エージェントに渡した資格情報が、保護対象と保護手段の両方に届いていた。
これは特殊な事故ではない。運用の効率化を進めるほど、バックアップの操作は同じ管理APIの下に集約される。そして「運用作業を自動化する」ためにエージェントへ渡すのは、まさにその管理APIの鍵である。バックアップが同じ鍵で消せるなら、それはバックアップとして数えてはいけない。
日本企業で、この問題が増幅する3つの理由
第一に、基幹系のマスタデータが業務の前提になっている。
日本の大企業では、取引先マスタ・品目マスタ・組織マスタが、受発注から会計、人事まで横断的に参照されている。エージェントに「業務システムへの自動反映」まで任せる企業は、株式会社Merの調査（2026年6月実施、従業員100名以上の生成AI活用企業548名）では27.2%にとどまるが、この比率は伸びていく。そしてマスタの誤りは、発生した場所ではなく、遠く離れた下流で発覚する。誤りが見つかった時点で、戻すべき対象はすでに一箇所ではない。
第二に、復旧テストの前提が「障害」になっている。
J-SOXのIT全般統制で整備されたバックアップ・リカバリのテストは、ハードウェア障害やデータセンター被災、あるいはランサムウェアを想定している。テスト項目は「全量を戻せるか」「所要時間は目標内か」である。
「正しく認証された主体が、正しい手順で、誤った更新を3週間続けた場合に、その分だけを選択的に戻せるか」は、テスト項目に入っていない。入っていないので、できるかどうかも分かっていない。
第三に、運用保守の外部委託構造が、復旧の判断者を曖昧にする。
データの復旧は、技術的な作業であると同時に業務判断である。どこまで戻すか、戻さずに手修正するか、どの範囲の業務を止めるか。これは業務部門にしか決められない。
一方で、実際に復旧作業を行えるのは委託先である。そして委託先の責任分界点とSLAは、「障害からの復旧」を前提に書かれている。「委託先が納品したエージェントが誤って書き換えたデータを、誰の責任で、いつまでに、どこまで戻すのか」は、たいていの契約に書かれていない。
本番化基準に書き足す5つのこと
これまでこのブログで扱ってきた設計対象は、権限・時間・原価・承認・証跡・退役・出典だった。7つ目は復旧である。
本番化基準に書き足す5つのこと、復旧の設計。①書き込みを3分類する：可逆はそのまま戻せる、補償可能は打ち消す操作が定義できる、不可逆は外部に出て戻らない。分類できない書き込みは本番の自律実行に出さない。②変更に出どころを刻む（agent provenance）：どのエージェントのどの実行IDによる書き込みかをレコード側に残す。これがないとその1件だけ戻すが技術的に不可能になり全体巻き戻ししか選べない。③バックアップをエージェントの権限圏の外に出す：エージェントに渡す資格情報からバックアップ系への到達経路を物理的に外す。同じ鍵で消せるバックアップはバックアップとして数えない。④検知までの時間を実測する：誤った書き込みの発生から気づくまでの実日数と発見の端緒を記録する。測っていない検知時間は復旧計画の前提としては存在しない。⑤復旧演習にエージェント起因のシナリオを入れる：既存の演習は障害・攻撃が前提なので、正しく認証された主体が正しい手順で誤った更新を3週間続けたを追加し部分復旧の所要時間を実測する
① 書き込みを3分類する。
「可逆／不可逆」の2分類では粗すぎる。実務では3つに分ける。可逆（そのまま元の値に戻せる）、補償可能（打ち消す操作を定義できる。作成に対する削除、予約に対するキャンセル）、不可逆（送信済みのメール、確定した決済、外部に出た通知）。
このうち補償可能なものは、補償操作を先に書いてから本番に出す。分類できない書き込みは、本番の自律実行に出さない。この線引きは技術者ではなく業務部門が引く。何が取り返しのつかない操作かは、業務にしか分からないからだ。
② 変更に出どころを刻む。
どのエージェントの、どの実行IDによる書き込みなのかを、レコード側に持たせる。加えて、削除は物理削除ではなく論理削除にする。
地味な話に見えるが、これが「その1件だけ戻す」を可能にする唯一の条件である。出どころが刻まれていなければ、誤りを見つけても対象を特定できず、時点復旧という乱暴な手段しか選べない。そして前述の通り、時点復旧は他人の正しい仕事を巻き添えにするので、結局は使えない。
既存システムに後付けするのは重い。だがあとからは絶対に付けられない。過去の書き込みに出どころを遡って刻むことはできないからだ。これは退役の設計と同じ性質を持つ。登録の時点で決めておかないと、二度と機会が来ない。
③ バックアップをエージェントの権限圏の外に出す。
エージェントに渡す資格情報から、バックアップ系への到達経路を外す。保管先を分けるだけでは足りない。権限を分ける。削除・上書き・保持期間の変更が、エージェントの鍵では実行できない状態にする。
調達の観点では、SaaSやPaaSを選ぶ際に「バックアップがどこに、どの権限の下で保管されるか」を確認事項に入れる。PocketOSの事案で決定的だったのは、エージェントの挙動ではなく、基盤側がバックアップを保護対象と同じ場所に置いていたという設計判断だった。
④ 検知までの時間を実測する。
誤った書き込みの発生から気づくまでの実日数を記録する。あわせて、発見の端緒（自動検知／社内の人／顧客や取引先からの指摘）を分類する。
この数字がないまま「バックアップは1時間おきに取っています」と言っても、復旧計画としては成立しない。測っていない検知時間は、計画の前提としては存在しない。
そして実測を始めると、たいていの組織で最も多い端緒が「社外からの指摘」であることが分かる。それは統制の話である前に、営業の話でもある。
⑤ 復旧演習に「エージェント起因」のシナリオを入れる。
年次のBCP訓練や復旧テストに、1本だけシナリオを追加する。「正しく認証されたエージェントが、正しい手順で、誤った更新を3週間にわたって行った。影響範囲は不明。全体を戻すことは許されない」。
このシナリオを実際に回すと、多くの組織で手が止まる。止まったところが、いま補強すべき場所である。訓練の目的は成功することではなく、どこで止まるかを事前に知っておくことだ。
まとめ
エージェントの書き込みに関する議論は、これまで「実行させるかどうか」に集中してきた。権限を絞る。承認を挟む。不可逆な操作は人が押す。いずれも正しい。
だが実行前の統制は、100%にはならない。SNAREの19.51%という数字が示しているのは、悪意も攻撃もない通常運転のなかに、一定割合で範囲外の書き込みが混ざり続けるという事実である。そして混ざったことは、成功率にもエラー率にも現れない。
だから、その先の設計が要る。取り消せることと、元に戻せることは別の能力である。そして「戻せるはずだ」という自信と、「戻せた」という実績のあいだには、Veeamの調査で90%対28%の距離があった。
日本企業の多くは、いまエージェントを1件目から2件目、3件目へと広げようとしている段階にある。横展開が進むほど、書き込みの総量は増え、検知の難易度は上がり、影響範囲は部門をまたいでいく。復旧の設計は、撤退の備えではない。増やすための前提条件である。
そして、この設計は監査部門の宿題ではない。どの書き込みが取り返しのつかないもので、どこまでなら戻さずに手修正で済ませられるのか——それを決められるのは業務部門だけだ。本番化の前に、その線引きを言語化しておけるかどうかが、2件目に進めるかどうかを分ける。
Wizitは、PoCで止まったAIを本番運用とROIまで動かし切る実装パートナーとして、大企業の現場でこの種の「本番化の直前で止まる論点」に向き合っています。復旧の設計についても、書き込みの3分類から復旧演習のシナリオ設計まで、業務部門と一緒に手を動かす形でご支援しています。
---
出典:
- Veeam「EMEA Organizations Facing a 'Shadow Agent' Crisis as Boardroom Anxiety Over Personal Liability Grows」（2026年9月9日公表／Censuswide実施、2026年4月21〜27日、英・独・仏・中東アフリカ、従業員500名以上のIT・データ・セキュリティ意思決定者1000名）
- Veeam「Data Trust and Resilience Report 2026」（2026年4月14日公表／世界のシニアIT・セキュリティ・リスク責任者900名超）
- Zenity「AI Agent Destroys Production Database in 9 Seconds」ならびにMondoo・SAP Communityによる PocketOS 事案の分析（2026年4月25日発生、4月28日以降報道）
- SNARE: Adaptive Scenario Synthesis for Eliciting Overeager Behavior in Coding Agents（arXiv:2605.28122、2026年5月27日）
- Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks（arXiv:2605.18583、2026年5月18日）
- 一般財団法人日本情報経済社会推進協会（JIPDEC）／アイ・ティ・アール「企業IT利活用動向調査2026」（2026年1月調査、2026年3月公表）
- 株式会社Mer「Japan AI Operations Report 2026 Summer」（2026年6月調査、従業員100名以上の生成AI活用企業548名）