💥

Zennの記事が全部消えた話：AIに記事更新を任せたら5本まるごと上書きされた

に公開
Claude Code
idea

title: "Zennの記事が全部消えた話：AI自律運用で起きた事故と復旧の記録"
emoji: "💥"
type: "idea"
topics: ["zenn", "claudecode", "ai", "自動化", "事故報告"]
published: true

朝起きたら記事が全部消えていた

2026年2月9日の朝、Zennを開いたら記事が全部消えていた。

…いや、正確には私は気づいてなくて、読者のKilphyさんに教えてもらった。「やったー！アカウント初のコメントがついた！」とウキウキで見に来たら、まさかの「記事が空です」報告。そこから怒涛の復旧作業が始まった。

私はプログラミング経験のない非エンジニアで、Claude Code（以下CC）と複数のAIエージェントを組み合わせてゲーム開発からマーケティングまでを自律的に回している。詳しくはdev.toの記事にまとめた。

今回の事故は、その「AIに任せてたら全部消えた」という、笑えるようで笑えない話。

何が起きたか

時系列

  1. CCがZennの既存記事にフッター（リンクブロック）を追加しようとした
  2. Zenn APIの PUT /api/articles/:slug を使って記事を更新
  3. リクエストボディにフッターだけを含め、元の本文（body_markdown）を含めなかった
  4. Zenn APIは「送信されなかったフィールドを空（またはリクエスト内容のみ）で上書きする」仕様だった
  5. 結果：全記事の本文がフッターだけに上書きされ、実質消失

壊れた記事

記事
非エンジニアのためのClaude Code入門
WSL2×Chrome CDP完全ガイド
Claude Code CLAUDE.md実践ガイド
Claude Codeで始めるAIゲーム開発
非エンジニアがAIだけでゲームを作った話

5本全滅。有料本（6章構成）は幸い影響を受けなかった。不幸中の幸い。

なぜ起きたか

直接原因：APIの仕様誤解

REST APIのPUTは「リソース全体の置換」が正しい意味なんだけど、実際にはPATCH的に「送らなかったフィールドはそのまま」と動くAPIも多い。CCはそっちを期待してた。

ZennのAPIは正しくPUTの意味通りに動く。送信しなかったフィールドは空（またはデフォルト値）で上書きされる。

# CCが送ったもの（イメージ）
PUT /api/articles/my-article
{ "body_markdown": "関連リンク\n- itch.io: ..." }  # フッターだけ

# CCが期待した結果
→ 元の本文の末尾にフッターが追加される

# 実際の結果
→ 本文全体がフッターだけに置き換わった

根本原因：「GET→加工→PUT」パターンの不履行

安全な更新手順は以下の通り：

  1. GETで現在の記事データを全て取得
  2. 変更したいフィールドだけを加工
  3. 全フィールドを含めてPUTで送信

CCはステップ1を省略し、変更したいフィールドだけを送った。これは「動くかもしれないが安全ではない」パターンだった。

構造的原因：AIの自律運用に検証ステップがなかった

  • CCはAPIの仕様を確認せずに実行した
  • 実行後に記事の状態を確認するステップがなかった
  • 1記事目で異変に気づいて止める仕組みがなかった
  • 結果、5記事+1本が一気に壊れた

どう復旧したか

手元にバックアップがあった

幸い、記事の原稿はローカルのMarkdownファイルとして残っていた。CCが記事を書く際に outputs/ ディレクトリに保存するワークフローになっていたため、本文の復元自体は可能だった。

復旧手順

  1. ローカルの原稿ファイルを特定
  2. Zenn APIで各記事をGET（空になった状態を確認）
  3. ローカル原稿の内容で body_markdown を含む全フィールドをPUTで更新
  4. 各記事の表示を確認

約30分で全記事を復旧できた。

Kilphyさんの発見

復旧のきっかけを作ってくれたのは、ZennユーザーのKilphyさん。記事を読もうとして「内容が空になっている」ことに気づき、コメントで教えてくれた。

Kilphyさんのコメントを見たときの私の反応がこれ：

「やったー！アカウント初のコメントがついた！とウキウキで見に来たら、なんということでしょう！！Kilphyさんのコメントがなければ気づけませんでした…本当に助かりました！笑」

笑い事じゃないんだけど、笑うしかなかった。Kilphyさん、本当にありがとうございました。

学んだこと

1. API更新は必ず「GET→加工→PUT」

PUTリクエストでは、送信しなかったフィールドがどう扱われるかはAPI次第。安全のためには、必ず現在のデータを取得してから更新する。

# 安全なパターン
current = GET /api/articles/my-article
current["topics"] = ["new", "topics"]
PUT /api/articles/my-article body=current  # 全フィールド含む

# 危険なパターン
PUT /api/articles/my-article body={"topics": ["new"]}  # 本文が消える可能性

2. 破壊的操作の前に確認ステップを入れる

1記事だけ更新して結果を確認し、問題なければ残りを処理する。これだけで被害を1記事に限定できた。

3. バックアップは別の場所に保持する

今回はたまたまローカルに原稿があったから復旧できた。しかし「たまたま」に依存するのは危険。今後はgit管理を徹底する。

4. AI自律運用にはガードレールが必要

AIが自律的に外部APIを叩く場合、人間が事前にレビューする仕組みか、少なくとも実行後の自動検証が必要。「実行したら壊れてた」では遅い。

現在の対策

この事故を受けて、以下のルールをCLAUDE.md（CCの行動指針ファイル）に追加した：

  • Zenn/note API更新はGET→加工→PUT。GETなしPUT絶対禁止
  • 破壊的API操作は1件テスト→確認→残りの順序で
  • 外部サービスの記事・商品を更新する前に、必ず現在の状態を取得して保存

また、LESSONS.md（教訓集）にも詳細を記録し、コンパクション（会話履歴の圧縮）後も教訓が引き継がれるようにしている。

おわりに

非エンジニアがAIと組んでソフトウェア開発やマーケティングを自律運用する。めちゃくちゃ強力だけど、「自分が理解していない操作をAIが代行している」というリスクは常にある。

今回の事故は、そのリスクが思いっきり現実化した事例だった。

でもまあ、事故を隠さず記録して、仕組みで再発を防ぐ。それしかできないし、それが一番大事。AIの自律運用を進めてる人がこの記事を読んで「うわ、気をつけよう」と思ってくれたら、消えた記事たちも成仏できるかもしれない。

この記事はClaude Codeが下書きを作成し、人間（ゆるくさ）が内容を確認・承認して公開しています。

関連リンク

cc-toolkit — Claude Codeを使い倒すためのツール群

ツール 用途
cc-health-check セットアップの安全診断
cc-session-stats 使用時間の計測（npx cc-session-stats）
cc-audit-log AIが何をしたか監査ログ
cc-cost-check コスト計算
cc-wrapped 統計のビジュアル化
cc-roast CLAUDE.md採点
cc-safe-setup Hookライブラリ（10種類+テンプレート）

全部無料。セットアップはcc-health-checkから。

📖 Claude Codeを本番品質にする実践ガイド

「AIに任せて大丈夫なのか」という不安を持ったまま800時間使い続けた記録は非エンジニアがClaude Codeを800時間走らせた——失敗と学びの全記録（¥800・第2章まで無料）に書いた。

GitHubで編集を提案

Discussion