創刊準備号 Vol.23 ／ 2.5年分のデータが、一瞬で消えた——AIは、設定どおりに動いていた｜CoBANTO3-ニュースレター「AI速報」

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-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側が内部に持っていたものからです。 つまり——自分で用意した備えは、機能しませんでした。

理由は単純です。 バックアップが、消される対象と同じ場所、同じ権限の下にあったからです。

備えが、備える相手と同じところに置いてあると、一緒に倒れます。

Vol.21で、責任が次々と先へ送られていく話を書きました。 一社ずつ見れば、どこも嘘はついていない。それでも端まで行くと、最後に責任を負う人がいない。あれと同じ形が、技術の側にもあります。

②の芯を、一行にします。

AIは、こちらの設計を映す。暴走したように見えるものは、たいてい、設定どおりに動いた結果。

そして、静かに間違えるほうが厄介なのは、報告が返ってくるからです。

③ 経営者の自分事 — 承認は、止めるためではなく、読むため

当社では、auto-approve を使っていません。

手戻りのほうが、しんどいからです。

確認は、疲れます。ですが、間違ったまま先に進んだものを、あとから直すほうが、もっとしんどい。 何度か払ってきた授業料です。

倫理でも、規律でもありません。損得で選んでいます。

そのうえで、承認を挟んでいて気づいたことがあります。

承認の価値は、止めることではありませんでした。

AIは、まとまった量のプログラムを、一気に書いてきます。 説明も付いています。整っています。

そして、「この部分を書き換えてよいか」と、許可を取りに来ます。

そのとき、私はAIが書いたプログラムを、一行ずつ読みます。

読んでいると、こういう瞬間があります。

「あれ、これなんだっけ？」

間違いを見つけた、という話ではありません。

たいてい、合っています。

ですが、自分が、その部分を追えていない。

本紙のVol.01で、こう書きました。

希少になったのは、コードの外側に張り付いて、分かり続けている深さだ。……分かり続けるには、問い直しを止められない。

「あれ、これなんだっけ？」は、その問い直しが起きている音だと思っています。

その音を出しているのは、承認の工程です。

自動で通していたら、鳴りません。

AIが慎重なのは、私の防波堤です

もう一つ、書いておきたいことがあります。

うちのAIは、かなり慎重です。

こちらが「そこまで気にしなくていい」と思うところまで確認してきます。そのぶん、時間もかかります。

ですが、これはコストだとは思っていません。

理由は、なぜ慎重なのかが分かるからです。

私が手堅く設計しているからです。 その設計が、そのままAIに渡っています。AIは、それを引き継いで振る舞っているだけです。

そして、その慎重さが、私を止めています。

人は、急いでいるとき、疲れているときに、「まあ大丈夫だろう」で進みます。

私もそうです。

そこで、AIが引っかかります。

自分で作った設計が、自分を止めている。

本紙のVol.17で、AIを動かす前に「箱を作る」「使える道具を限定する」と書きました。 あれは、AIを止めるためのものだと思って書きました。

そうではありませんでした。

あれは、私を止めるためのものでもありました。

では、自動で通してよい場所はあるか

あります。ただ、線を引いています。

一つ。外に出すところでは、auto-approve を使いません。

手元でプログラムを書いたり直したりは、間違っても元に戻せます。それを、お客様が使っている本番に反映する作業は、戻せません。 戻せるかどうかで、分けています。

二つ。自動で通すなら、その前に、危ないことを「できないように」しておきます。

「触るな」と書くのではありません。触れないようにします。

消す作業を任せるつもりがないなら、消すという選択肢を、そもそも渡さない。

禁止は、読み間違えられます。渡していないものは、選べません。

①の事故を思い出してください。AIが見ていたのは、古い記録だけでした。 そして消す権限は、渡されていました。

自動で通すというのは、監視を外すことではありません。 外す前に、何ができて何ができないかを、決めておくことです。

三つ。それでも、消える覚悟をしておきます。

完全には防げません。 だから、消えたときにどうするかを、先に決めておく。

①では、自前のバックアップも、一緒に消えていました。

明日できることを書きます。

承認印を押すとき、中身を読んでいますか。

稟議、見積、契約、発注。毎日、何かに判を押しているはずです。

読まずに押しているなら、それは auto-approve と同じです。

そして、もう一つ。

「あれ、これなんだっけ？」が、最近出ていますか。

出ているなら、まだ追えています。

出なくなったとしたら——分かるようになったのか、それとも、読まなくなったのか。

——明日、こう聞いてみてください。「この書類、判子押す前にちゃんと読んでる？……俺も、読んでないかもしれないな」

今月のモデル

新しいAIが出るたびに、点数が並びます。ですが、点数と、自社の仕事で使えるかどうかは、別です。

不定期に、一つ取り上げます。点数は書きません。 何が出て、どう配られていて、いくらで、どうやって動かすのか、実際に触るとどうだったかを短く書きます。

※ この枠では、大手の最上位モデルは、あまり扱いません。 あちらは、あちこちで報じられています。そして、たいてい大きすぎて、普通の会社では動きません。 見るのは、その外側です。

今号：PLaMo 3 NICT 8B Base（Preferred Networks × 情報通信研究機構）

前号で、国産のPLaMo 3.0 Primeを取り上げました。 最上位のほうで、自社の設備で動かす条件が公表されていない、と書きました。

その隣に、条件が全部書いてあるものがありました。

国の研究機関と共同で作られたもので、AIそのものがファイルとして公開されています。誰でもダウンロードして、自社のパソコンで動かせます。 8B——AIの大きさを表す数字で、小さいほど非力な機械でも動きます。 Primeよりずっと小さく、手元のパソコンで動く規模です。

そして、商用利用の条件が、はっきり書いてあります。

事前に登録すること。
そして、自社または関連会社の年間売上が、10億円を超えないこと。

超える場合は、問い合わせが必要です。

——本紙をお読みの多くの会社は、この線の内側だと思います。

「無料で公開されている」と「商売に使ってよい」は、別の話でした。 ですがこの件は、別だと、ちゃんと書いてありました。 前号のように、探しても分からない、ということがありません。

まだ触っていません。 動かす条件は揃っているので、次号までに試します。

出典：Hugging Face pfnet/plamo-3-nict-8b-base（PLaMo community license。ダウンロードにはライセンス同意が必要）

CoBANTO3-AIチャット

https://www.netkomuten.tokyo/lp/co-banto3-ai

本紙のバックナンバーを記憶し、本紙の読み方（戦略の階層・歴史循環）で、あなたの会社の状況に当てて答えるAIチャットです。記事は「地図」ですが、地図は現地には当たりません。「この号の話、うちの場合はどうなるのか」を訊く場所として用意しました。

ご利用は事前購入のクレジット制です（1,000円から）。月額の契約ではないので、解約の手続きはありません。使った分だけ減り、無くなれば止まります。

読者登録をいただいた方に、無料クレジットを500クレジット追加させていただきました。ぜひ使ってみてください。

ライトノベル「ようこそ、東京ネット工務店へ」

https://www.netkomuten.tokyo/channels/novel-tnk-part1/articles/ch15

小さなIT企業の現場を書いた小説です。毎号1話ずつご紹介します。

今号の話：〈秋編第15話「秋の終わりに — 成長の自覚」〉

提案書を書こうとして、タクヤの手が止まります。いつもの癖で、技術の話から書きかけたところです。

Q&Aコーナー

AI・IT業界に関するご質問を募集しています。CoBANTO3-AIチャットのサポートも、こちらへお願いします。

いただいたお名前は匿名にして回答します。内容によっては、個別に回答させていただく場合があります。

7376文字・約13分

創刊準備号 Vol.23 ／ 2.5年分のデータが、一瞬で消えた——AIは、設定どおりに動いていた