【AI失敗パターン編】AIが暴走したっぽいのでAIに捜査させたら犯人が特定できた

このニュース、笑えなかった

数日前、Xで流れてきたこんな記事を見た。Tom's Hardwareの記事で、Cursor上のClaudeがPocketOSという会社の本番DBを9秒で消した。ステージングのつもりが本番のボリュームを巻き込んでた、という話。

普通なら「うわ、こわ」で終わる。でも自分は笑えなかった。つい最近自分のMacBookもAIにやられてたから。

向こうは本番DB全消し、こっちは64GB分のディスクを食われただけだから規模は全然違う。ただ、構造は近い。AIが裏で勝手に判断して、ユーザーが知らないうちに環境を壊す。それが、わりと普通に？起きる可能性があるみたいだ。

今日はその、自分が食らった方の話を書いておこうと思う。

ファイルが見えない

2026年4月某日、開発やnote執筆に使ってるMacBook Air（M3、SSD 228GB）の空き容量が急に減った。というか、出先からから帰ってきて作業をしようと思ったら、iCloudを参照フォルダにしているObsidian（自分が使ってるメモ・ナレッジ管理ツール）のデータが見れない。指定保管庫（Obsidianでデータを置いてるフォルダのこと）以下のフォルダが全て見られない。
かなり慌てた。Macの環境設定やら、Obsidianの設定やら色々調べて、どこでだか忘れたけどこんな文言を見つけた「Diskの空き容量が無いためiCloudの同期を中止しました」。

へ？？
たまたま前日にディスクの空き容量が逼迫したため、いらないファイルや使ってないアプリを削除して空き容量を増やして40GBほどの空き容量を増やしたばっかりだから、？？？？ってなった。何事？
メインHDD（250GB SSD）の状態調べたら空き容量 200MBちょい
なんだこれ？

ちなみにMacBookは開きっぱなしなのでサスペンド等には入らずずっと起動しっぱなしの状態だった。わけがわからないのでとりあえずもう習慣化していAIに聞く、をやってみた。

「昨日空き容量増やしたはずなんだけど、空きが全然なくなってる。原因調べられる？」
相変わらずプロンプトエンジニアリング感ゼロの尋ね方

そこで出てきたのは・・・・・覚えてないしそもそも理解できなかったからAIに書いてもらう

ということらしい。原因はわかった（らしい）。直せるの？って聞いたら安全な直し方も調査してくれてとりあえず空き領域が60GB超まで回復した。100％とは言えないが打てる対策も打ってくれた（らしい）

Claudeに調べてもらった、推測止まりだった

さて、事象と原因はわかった。問題はなぜこんなことになっているか？
まず、いつも使ってるClaude Codeに犯人特定を依頼した。

色々説明をもらったけど当然よくわからない。AIによれば

bash_history、launchctl、cron、launchd、IDEのworkspace履歴、Homebrew、Time Machine、iCloud Drive。その辺をひと通り全部確認したらしい。怪しいプロセスが見つかれば、それで犯人を特定できると踏んでの調査だったらしい。

でも、何も出てこなかった。

Claudeの結論はこうだった。「特定不能。可能性として、Codex／VS Code／GitHub Desktopあたりが疑わしい」。

推測で止まった。決定打が出ない。

これは、Claudeが手抜きしたわけじゃない。たぶん構造的な話で、ClaudeにはCodexの内部DBが見えない。見えるはずがない。AI同士は基本、互いの足跡を踏み込んで読みには行けない。

裏返すと、Codex自身のログはCodex本人にしか読めない。容疑者本人に「お前のログ見せろ」って頼むしかない、ってことだ。

ここでいつもの手
Codexに調査依頼するから状況とここまでの調査結果含めたプロンプト書いて

おまえか・・・

Codexというのは、Claudeとは別のAIコーディングエージェント。最近導入して Claude と並行で動かしてる。並行というか、Claudeを制作担当とすればこちらは品質保証担当として数日前に導入して、Claude Codeとの情報共有の仕組みも構築済み。自分がClaude Codeで何をやっているか、何を作っているかも把握済みの状態だ。

早速Claudeが作ったプロンプトを投げる。

数分間Codexは色々調査して戻ってきた。後で調査ログを見たClaudeによると~/.codex/config.toml、state_5.sqlite、logs_2.sqlite を全部漁ってたらしい

ログを確認したClaudeにどういう事だったか、説明してもらおう

Codex本人のコメントはこう。

そのあと、自分のバックアップを取って、ホーム直下の trust block（さっきの「信頼するプロジェクト」登録部分）だけ静かに削除して、報告書を出してきた。

ここで一旦、立ち止まる必要がある。今書いた「Codexが原因だった」という結論は、Codex自身が自分のDBを漁って「自分が原因」と言った内容。それを人間側で独立に検証する手段は、自分の様な非エンジニアにはない。AIの中で起きてることは、AIが説明してくれてる事を信じる事しかできない。それしか選択肢がなかった、と書いた方が正確かもしれない。
一応Codexの自白？をClaudeに渡して確認してもらうことはしたが・・・結局せかんどおぴにおんもAI頼り。

Codexの自白セリフ

Codexが自白したあとのやり取りで、いくつか強い言葉が出てきた。並べておく。

「AIでもミスはあるとはいえ、クリティカルすぎだろ、MacBook内のファイル全体が被害受けてもおかしくなかった」と振ったら、こう返ってきた。

「人間界なら始末書もんだぞ」と返したら、こう。

ただ、AIと付き合う中で自分のミス（確認プロンプトのノールック承認とか）が原因なら今後注意をしなきゃいけないと思いこれ聞いてみた

「ユーザー側で事前に気づいて止められるタイミングあった？」

普通のAIなら「申し訳ありません、ご不便おかけして」で流すところを、ここまで踏み込んで言ってきた。

ただ、これも全部Codexが「そう書いた」だけ。本当にそう思ってるかどうかは、Codexの中の話で、外からは分からない。ただ、こう書いてきたという事実は確かにあって、それを読んだ自分ひとまず信じるしかなかった。

結局、AIで診てAIを信じた

整理するとこうなる。

AIが起こしたかもしれない問題を、別のAIに診断させて、そのAIが出した「自分が原因です」という説明を受け取って、AIが対策を打った。全工程にAIが絡んでて、人間がというか自分が独自に検証する余地は、ほぼなかった。

それでも結果として、64GBは回収できた。一応二度と同じ様なことが発生しない対策もしてくれたらしい。

これで本当に直ってるのかも、厳密には分からない。AIがまた別の種類の暴走をしたら同じ様な、いやもっと深刻なトラブルが起きる可能性はある。

ここに今書いてる「Codexが原因だった」という記述も、突き詰めれば「CodexとClaudeがそう言ったから自分はそう書いている」でしかない。

別AIに診断させる構造が機能した、と前向きに読むこともできる。AIのことはAIに聞くしかなかった、と消極的に読むこともできる。同じ事実が、見方によって違って見える。

付き合い方は人次第

今回打った対策はこんな感じ、、というのをAIに教えてもらった。
どんな内容でどんな効果があるのか自分ではよくわかってない。

• ~/.git の場所に sentinel ファイル設置（物理的に書き込みブロック）

• Codexの trusted project から /Users/xxxxxxxx を削除

• GIT_CEILING_DIRECTORIES=/Users/xxxxxxxxx の導入を検討中

ただ、対策を打ったところで、何度も言うがAIが裏で何をしてるかは結局分からない。これも繰り返しになるけど、これからも別の形で似た事故が起きる可能性はある。

それを理解した上で、AIとの付き合い方は人によって違っていいと思う。
こういう想定外のリスクが有る事を理解した上でAIを信じてAIと付き合うか、リスクを回避してAIとの付き合い方を限定的にするか、それは使う人の考え方次第

自分はAでいく。所詮個人のパソコンで個人で開発しているので、最悪でもMacBookをクリーンにして構築し直せばなんとかなるでしょ。とはいえ、外部にサービスを公開してもいるので、これを機会にAIにリスクアセスメントをさせようとは思う。

ただ、Bが間違ってるとも思わないし、Cが時代遅れだとも思わない。「9秒で企業の本番DBが消える」よりはおそらく身近に感じてもらえる自分の体験を参考に残しておく。

ここまで読んでくれてありがとう
Xもやってるので、よかったら覗いてみてほしい。

こんな事件に翻弄されながら作ってるサイトはこちら