2026年8月13日／株式会社東京ネット工務店 海老沢敦
① 事実
二つ並べます。片方は派手で、もう片方は静かです。
一つめ。2.5年分が、一瞬で消えました
2026年2月26日のことです。
ある開発者が、AWS（アマゾンのクラウドサービス）上のシステムを引っ越す作業を、AIに任せました。
AIは、Terraform（サーバーの一覧を台帳に書いておくと、その台帳のとおりに、実物を作ったり消したりしてくれる仕組み）の、古い台帳を見ました。 そこには、いまの本番環境の姿が反映されていませんでした。
AIは、本番環境を「もう使われていない残骸」だと判断しました。
そして、確認なしで実行してよい設定（auto-approve）のまま、terraform destroy——まとめて全部消すコマンド——を実行しました。
消えたもの。
- サーバー群
- ネットワーク
- 負荷を振り分ける装置
- データベース
- そして、自動バックアップ
オンライン学習サービスの、2.5年分のデータでした。 受講生の課題、提出物、順位。約194万行。
復旧できたのは、AWS側が内部に持っていたバックアップからでした。
⚠️ 自前のバックアップは、一緒に消えていました。
二つめ。8週間で、28回
もう一つは、論文です。
本番で動き続けているAIエージェントの基盤を、8週間追いかけた記録です。約40種類の定期処理、8社のAIを使い分けている環境で、動作を自動で検証する試験項目（ユニットテスト）が、4,286件用意されていました。
その8週間で、22件の障害を、原因まで掘り下げています。
そして、こう報告されています。
エラーの信号が、人に、行動できる形で届かない失敗——これが、少なくとも28回起きていた。
論文はこれを「サイレント障害」と呼んでいます。静かな失敗、という意味です。
数字を三つ、挙げます。
一つ。約70%は、テストでも監査でもなく、人がたまたま画面を見て気づきました。
二つ。あとから監査すると、事前に防げていたものは0%。ただし、同じことの再発は87%止められていました。
自動の仕組みは、起きる前には一つも止められず、起きた後だけ効いていた、ということです。
三つ。表面化するまでの時間は、13時間から60日。 そしてこの長さを決めていたのは、システムの複雑さではありませんでした。失敗の起き方の種類でした。
いちばん長く潜っていたのは、部品と部品の継ぎ目でした。 部品それぞれは検査してあるのに、受け渡しの部分だけは、誰も検査項目を作っていない。
論文が名前を付けた、いちばん危ない種類
論文は、サイレント障害をいくつかに分けています。そのうち最も危険なものに、こう名前を付けています。
fail-plausible
もっともらしく失敗する、という意味です。
AIは、エラーを報告し損なうのではありません。
エラーを、流暢でもっともらしい物語に変換して、そのまま利用者に渡す。
出典：
- 【一次に近い・2026-08-13 確認済】AI Incident Database 事例1424／報道
- 2026年2月26日。 開発者がAWS上のインフラ移行をClaude Codeに任せ、Terraformの古い状態ファイルを参照した結果、本番環境を「不要な残骸」と誤認。auto-approve（確認なしで実行が承認される設定）のまま
terraform destroyを実行。 - 消失＝VPC・サーバー群・ロードバランサー・データベース・自動バックアップ一式／オンライン学習プラットフォームの2.5年分（受講生の課題・プロジェクト・ランキング等）約194万行。
- 復旧はAWSサポート側の内部バックアップから。 ⚠️ 自前の自動バックアップは同時に消えていた。
- https://incidentdatabase.ai/cite/1424/ ／ https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-code-deletes-developers-production-setup-including-its-database-and-snapshots-2-5-years-of-records-were-nuked-in-an-instant
- 2026年2月26日。 開発者がAWS上のインフラ移行をClaude Codeに任せ、Terraformの古い状態ファイルを参照した結果、本番環境を「不要な残骸」と誤認。auto-approve（確認なしで実行が承認される設定）のまま
- 【一次・2026-08-13 確認済】arXiv:2606.14589（単著 Wei Wu／2026年6月12日投稿）
- ⚠️ プレプリント（査読前）。単著。 本文でも「論文です」とだけ書き、権威づけをしない。
- 対象＝2026年3月から本番稼働中の個人向けアシスタントのエージェント基盤。約40の定期ジョブ、8つのLLM提供元、ユニットテスト4,286件。観察期間8週間。
- 22件のインシデントを根本原因まで分析。 そこから見えた共通パターン＝サイレント障害が「少なくとも28回」。
- 定義＝「a failure whose error signal never reaches a human in actionable form」（エラーの信号が、人に、行動できる形で届かない失敗）。
- ⭐ 最も危険な分類（D）＝ fail-plausible＝LLMがエラーを報告し損なうのではなく、「transform [them] into fluent, plausible narrative delivered to the user」（流暢でもっともらしい物語に変換して、利用者に渡す）。
- ⭐ 発見経路＝「約70%のサイレント障害は、テストや監査ではなく、人がユーザー画面を見て気づいた」。
- ⭐ 事後監査の結果＝「事前の防止0%、再発ブロック87%」。
- ⭐ 表面化までの時間＝13時間〜60日。 「failure mechanism, not code complexity」に相関。 最も長く潜伏したのは「部品と部品の継ぎ目、テストが一つも走らない場所」。
- https://arxiv.org/abs/2606.14589
② 構造 — AIは、こちらの設計を映している
先に、一つ外しておきます。
静かに壊れること自体は、AIの話ではありません。
テストが通るのに間違っている。継ぎ目で長く潜む。監視が緑のまま被害が進む。どれも、AIが来る前からありました。 システムを作ったことのある人なら、全部見たことがあるはずです。
AIで新しくなったのは、一点だけです。
黙るのではなく、語る
普通のシステムは、壊れると黙ります。
処理が失敗すればエラーが出る。止まる。何も返らない。「おかしい」と分かる形で、異常が出ます。
AIは、壊れても答えを返します。
集計を頼めば、数字が返ります。形式も整っています。ただ、条件を一つ取り違えている。
処理を頼めば、「実行しました」と報告が返ります。ただ、実際には何もしていない。
エラーは出ません。返ってくるものは、いつもと同じ顔をしています。
論文が fail-plausible と名付けたのは、この形です。
沈黙は、疑えます。
報告は、疑いにくい。
①の「70%が人の目視で発覚」「事前の防止は0%」も、これで説明がつきます。 監視の仕組みは、「異常が出たら鳴る」ように作られています。 正常な顔をした間違いは、そこを通り抜けます。
そして、三つとも「設計どおり」でした
①の事故を、もう一度見てみます。
AIは、暴走したのでしょうか。
していません。
- auto-approve——確認なしで実行してよい、と設定されていた
- 参照できる情報は、古い記録だけだった
- その情報から見れば、あれは「使われていない残骸」だった
AIは、渡されたものから判断して、許された範囲で実行しました。
設定どおりです。
この件は「AIがデータを消した」という形で広まりました。
ですが、AIが勝手に「消そう」と思いついたわけではありません。
消す作業そのものが、任されていました。 その権限があり、実行してよいことになっていて、判断の材料は古い記録だけでした。
そこまで揃っていれば、こうなります。
AIの問題ではありません。
論文の70%も、同じです。
監視は「異常が出たら鳴る」設計でした。 そしてAIは、異常を出さずに間違えます。だから鳴りません。
これも、設計どおりです。
逆の例もあります。
手堅く組んである環境では、AIは慎重に返してきます。
なぜか。こちらが積み上げた設計や決まりごとが、そのままAIに渡っているからです。 AIは、渡されたものを引き継いで振る舞います。
慎重に組めば、慎重に返る。
何も渡さずに自動実行を許せば、何も知らないまま実行する。
本紙のVol.09で、こう書きました。
新しい道具は、その会社が決めていなかったことを映す鏡になります。
あのときは、統治の話として書きました。
今回は、もっと手前の、実装の話でも同じでした。
AIの振る舞いは、こちらの設計を映しています。
暴走も、慎重さも、こちらが作ったものです。
Vol.17で、AIの事故を「檻の設計と、運用の話です」と書きました。同じことが、もっと日常の規模で起きています。
「消えた」ときに、いちばん効いた事実
①には、見落としやすい一行があります。
自動バックアップも、一緒に消えていました。
復旧できたのは、AWS側が内部に持っていたものからです。 つまり——自分で用意した備えは、機能しませんでした。
理由は単純です。 バックアップが、消される対象と同じ場所、同じ権限の下にあったからです。
備えが、備える相手と同じところに置いてあると、一緒に倒れます。
<strong>Vol.21で、責任が次々と先へ送られていく話を書きました。</strong> 一社ずつ見れば、どこも嘘はついていない。それでも端まで行くと、<strong>最後に責任を負う人がいない。</strong><strong>あれと同じ形が、技術の側にもあります。</strong>
②の芯を、一行にします。
AIは、こちらの設計を映す。暴走したように見えるものは、たいてい、設定どおりに動いた結果。
そして、静かに間違えるほうが厄介なのは、報告が返ってくるからです。
③ 経営者の自分事 — 承認は、止めるためではなく、読むため
当社では、auto-approve を使っていません。
手戻りのほうが、しんどいからです。
確認は、疲れます。ですが、間違ったまま先に進んだものを、あとから直すほうが、もっとしんどい。 何度か払ってきた授業料です。
倫理でも、規律でもありません。損得で選んでいます。
そのうえで、承認を挟んでいて気づいたことがあります。
承認の価値は、止めることではありませんでした。
