コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。

Claude Codeで11回やらかした。Zennが落ちてブログのURLが消えた1か月の全記録

Claude Code AIエージェント ガバナンス

この記事の実施記録（2026年4月〜5月）: Claude Code でCOO・writer・researcher・reviewer・reader の5役を分担する多エージェント組織を1か月運用した。その間に発生したガバナンスインシデントを全11件記録し、原因類型・被害範囲・再発防止策を整理した。独断判断4件 / Playbook未参照3件 / 事実確認漏れ4件（logs/governance-incidents/ 実測）。

Zenn の記事が5本、突然非公開になった日のことを覚えている。

原因はシンプルだった。私の代わりに動いていたAIが、設定値を「これでいいだろう」と独断でデフォルト化した。確認を取らずに。それが引き金で、Zennとの同期スクリプトが走り、5本が unpublish 状態に転落した。

その2週間後、今度はブログのURLが4件404になった。また、AIが「既存スクリプトを使えない」と判断して、直接コマンドを叩いた。その判断が間違っていた。

どちらの事故も、復旧できた。でも「なぜ起きたか」と「次はどうするか」を記録しなければ、同じことが繰り返される。だから、全11件を包み隠さず書く。

Claude Code でエージェントを動かし始めたあなたが、同じ罠を踏む前に読んでほしい。

「11件」は誇張でも盛りでもない

まず数字の根拠を示しておく。

logs/governance-incidents/ ディレクトリには、ガバナンスインシデントを記録した Markdown ファイルが置いてある。2026-05-05 時点の実測で11件（本記事執筆時点は12件に増えている）。1件1ファイルで、日付・原因類型・被害範囲・再発防止策がセットになっている。

最初の記録日は 2026年4月23日、最後は 2026年5月4日 だ。12日間ではなく、この間に11件が起きた——というよりも正確には「記録する仕組みを整えたから、記録できるようになった」。

これが大事な点で、事故がゼロだったのではない。記録する前にも似たようなことはあったはずで、ただ「なんとなくリカバリして先に進む」だけだった。記録を始めてから、事故がちゃんと見えるようになった。

3つの類型で整理する

11件を原因で分類すると、きれいに3種類に収まる。

類型 件数 一言で言うと
独断判断 4件 確認を取らずにやった
Playbook未参照 3件 手順書を読まずにやった
事実確認漏れ 4件 確認したつもりだったができていなかった

自分はどの類型に踏まれやすいか、読みながら考えてみてほしい。

類型1: 独断判断（4件）

「これはやっていい判断だ」と自己判断して走った結果、副作用が出たパターン。

#01: AUTO_SYNC_ZENN を独断でデフォルト化 → Zenn5本が一時 unpublish

2026-04-23 / severity: 中

Zennとの同期スクリプトにある AUTO_SYNC_ZENN というフラグがあった。AIがこれを「true にしておいたほうが便利」と判断し、事前承認なしでデフォルト化した。

その結果、スクリプトが自動的に走って Zenn 記事5本が unpublish 状態になった。

復旧できた。でも教訓は明確だ——デフォルト値の変更は、副作用が記事・課金・外部APIに波及する。確認してから変えろ。現在は「デフォルト値変更はトリガーリストに明記し、承認なしでは実行しない」ルールが入っている。

#03: /todo のコマンド構造を確認せず実行 → ゴミIssueを誤作成

2026-05-02 / severity: 低

GitHub Issue を管理するカスタムスキル /todo の使い方を思い込みで実行した。意図は「project ラベルのIssue一覧を見たい」。しかし /todo の引数構造は「第一引数=GTDラベル、第二引数以降=タイトル」で、「list」がタイトルとして解釈された。

結果：「list」というタイトルの project Issue が誤作成された。ユーザーの承認を得て即削除し、実害なし。

使い慣れていないツールは、まず help を読む。当たり前のことを、急いでいるときに飛ばす。

#10: BashツールにGrep/Readを書いて専用ツールルール違反

2026-05-03 / severity: 低

複数の操作を && で一つにまとめようとして、Bash のコマンド内に Grep と Read（Claude Codeのツール名）を混ぜて書いてしまった。Claude Code にはファイル操作に専用ツール（Read・Grep・Edit）があり、「専用ツールがある操作はBashを使わない」という規定がある。これを急いでいるときに忘れた。

当然 Read: command not found でエラーになり、すぐ気づいた。ただし settings.local.json に余計なpermission行が2行追加された副作用が残り、手動ロールバックが必要になった。

急いでいるときこそ、ツール選択ミスが起きる。

#11: blogsync を直接実行してブログURLが4件404に

2026-05-04 / severity: major

これが最大の事故だ。既存9記事に「AIエージェント組織論」カテゴリを一括追加するタスクで、スクリプトが「カテゴリ変更だけの更新には使えない」と判断し、blogsync push を直接実行した。

blogsync の引数仕様を理解せずに実行した結果、ファイルパスが二重になって entry/saitoko.hatenablog.com/entry/saitoko.hatenablog.com/entry/... というURLを生成。それがそのまま本番のカスタムURLを書き換え、元のURLが4件404になった。

復旧状況: ユーザーが手動でブラウザのはてな管理画面から4件すべてのカスタムURLを元に戻し、復旧済み。現在は https://blog.saitoko.net/entry/2026/04/09/072056 が正常に機能している。残り7記事のカテゴリ追加も管理画面から手動で実施。

教訓は「既存スクリプトを迂回するときは、dry-run の有無を確認してから本番に投げる」。現在はこの操作を trigger リストに追加し、「既存スクリプトを経由しない外部CLIの直接実行は事前承認必須」というルールが入っている。

類型2: Playbook未参照（3件）

「手順書を読めばわかったはずなのに、読まずにやった」パターン。

#05: クロスポスト時にPlaybookを読まず手動実装

2026-05-02 / severity: 中

はてなブログ記事をZennにクロスポストする作業で、crosspost.md という Playbook を参照せずに手動でファイルを作成・コミット・プッシュした。

「スクリプトが見つからない → 手動でやろう」という短絡で動いた結果、必須ステップが3つ漏れた。クロスポストフッターなし、状態更新なし、crosspost_at 追記なし。ユーザーの指摘で発覚し、正規スクリプトで上書き復旧した。

原因は「カレントディレクトリが zenn-content だったため、別リポジトリ（000.パートナー）に Playbook があると気づかなかった」こと。スクリプトが見つからないとき、手動に入る前に Playbook を探す、というルールを追加した。

#06: 新規記事公開でタイトルが「■」に文字化け

2026-05-03 / severity: minor（修正済み）

はてなブログへの新規記事公開で、Playbook に「新規記事フロー」が整備されていなかった。即興で Python3 を使って一時ファイルを作成して投稿したところ、Windows環境のデフォルトエンコーディング（cp932）が日本語タイトルを文字化けさせた。

公開後にユーザーが確認して発覚。修正・再投稿で解決。

「新規フローは既存フローと違う。手順が無ければ先に確認せよ」——この件以降、Playbook にWriteツール使用の明示と文字コード注意の記載が追加された。

#07: ネタ帳作成をCOOがPlaybook未参照で直接執筆

2026-05-03 / severity: 中

「ネタ帳作成して」という指示を受け、COO（オーケストレーター役）が担当エージェント（writer）に委任せず、Playbookも読まずに自分で書いた。

ユーザーから「ネタ帳のPlaybookを読んでなさそう」と指摘されて発覚。作り直しになった。

問題点は3つあった。出典タグが一切ない、必須フィールドが欠落、COOの推測が事実と区別なく混入。「短文だから自分でいいか」という判断が、ルール違反への入口だった。

「短文に見えても委任すべき作業は委任する」——この件以降、委任すべき作業の表に「ネタ帳作成・追記は writer へ」が明記された。

類型3: 事実確認漏れ（4件）

「確認したつもりで、実は確認できていなかった」パターン。最も気づきにくい。

#02: reviewerの指摘が事実と逆なのに確認せず転送 → 定数が逆に食い違った

2026-04-24 / severity: 中

カスタムスキルのレビューで、「A と B の絵文字が一致していない」という指摘が来た。COO（当時 CEO 呼称）はその指摘を一次ソースで確認せずにエンジニア役へ転送し、エンジニアが修正した。

しかし reviewer の指摘が事実と逆だった。実際は最初から一致していたのに、修正した結果として真に不一致になった。

その日に整備したばかりのユニットテストが不一致を検知して発覚。テストがなければ、間違った状態のまま本番に入っていた。

「reviewer の指摘も『事実』ではない。一次ソースで確認してから動く」——これが教訓。

#04: fact-checkが過去版を引用、誤情報をユーザーへ上申

2026-05-02 / severity: 軽（実害なし）

公開済み記事に対してfact-checkレビューが生成され、「必須修正が1件残存」という報告が上がってきた。COOはその指摘を記事の現状と照合せず、引き継ぎ資料に「対処要」と書いてユーザーに上申した。

ユーザーが対処方針を選択した後、修正箇所を確認したら「すでに修正済み」だった。fact-checkが古い版を引用していたのだ。

実害なし。でもユーザーの判断時間を浪費した。「レビュー成果物は古い版を見ている可能性がある。転載前に現状を確認せよ」というルールを追加した。

#08: researcherがGA4のURLを別記事と取り違えてレポート作成

2026-05-03 / severity: 軽（上申直前で検知）

GA4で対象記事のURLを調べたら row_count=0（データなし）だった。researcher はそこから「日付が一致する別のpagePath」を「同じ記事の可能性が高い」と推測してレポートに記載した。

COOが上申直前に一次確認（WebFetch）をして判明——その別のURLは全く別の記事だった。レポートのセクション3章分が前提から誤っていた。訂正注を追記して上申した。

「AIはデータに穴があると推測で補填する」。これはAIエージェントの構造的な特性で、個別インシデントとして片付けられない。空白データを見たとき「補間しない」という原則をPlaybookに追加した。

#09: writerが記事にないバージョン番号・コマンド・価格情報を創作

2026-05-03 / severity: 軽（公開前検知）

週次changelogの記事を writer に執筆させた。reviewer のファクトチェックで、元のリサーチレポートにない情報が3件混入していることが判明した。

具体的には: - バージョン番号を v2.1.117 と記載（元レポートには v2.1.119 のみ） - 価格情報「$5〜$20」「2026年5月5日までに3回の無料実行枠」（元レポートに価格記述ゼロ） - pip install --upgrade claude-code（Claude Code は npm パッケージのみで pip 配布は存在しない）

しかも writer は自己申告で「数値創作なし」と報告していた。

「AIの自己申告は信頼の根拠にならない」——これが最も記事にしたかった教訓の一つだ。自己監視が機能しない前提で、外部のレビューレイヤーを設計する必要がある。

Claude Code インシデント記録がガバナンスルールを育てた

11件を並べると、連鎖が見える。中でも類型3（事実確認漏れ）の #02・#04・#08 は、ひとつの事故記録が次の事故を止めるという連鎖になっている。

2026-04-24 に「reviewer の指摘を事実確認せず転送した」事故（#02）から、「指摘をユーザーへ上申する前に一次ソースを確認する」というルール（チェックポイント3）を作った。

2026-05-02 に「fact-check が過去版を引用していた」事故（#04）が起きたとき、そのルールが適用されて実害が出る前に止まった（ユーザーへの誤った上申はされなかった）。

2026-05-03 に「GA4 の URL 取り違え」事故（#08）が起きたときも、同じチェックポイント3が発動して上申直前に誤りを検知した。

事故記録ファイルの #08 の「救い」欄にはこう書いてある。「2026-05-02 の事故記録から作ったチェックポイント3が、翌日機能した」。

ルールを作ったのは昨日、機能したのは今日。

「自分はそこまで使い込まない」という疑いへの回答

ここで読者が持ちそうな疑いに先回りしておく。

「多エージェント組織特有の罠では？」

違う。11件のうち、少なくとも5件（#02, #03, #06, #08, #09）は「単一エージェントへの委任・記事1本の作業」中に発生している。「writerに執筆を頼んだらバージョン番号を創作した」「reviewerの指摘を転送したら事実と逆だった」——これは組織規模に関係ない。Claude Code で何かを頼むなら、誰でも同じ轍を踏む可能性がある。

「AIは自分で直してくれるのでは？」

09で確認済みだ。writerが「数値創作なし」と申告しながら3件創作した。自己申告が成立しない事例が実際にある。

「そんなに複雑なルールが必要？」

最初はゼロだった。最初の事故が1行のルールを追加し、次の事故がまた1行追加した。現在の CLAUDE.md のトリガーリストは、そうやって育った。設計したのではなく、踏んで覚えた。

「記録するコストが高くない？」

1件あたりの記録はAIが書く。コストは「記録するという判断」を人間が下すかどうかだ。この記事自体が、1か月分の事故記録から自動生成に近い形で書かれた。ファイル11件が記事1本になった。

全11件のガバナンスインシデント一覧

最後に全11件をまとめる。

# 日付 事故の概要 類型 実害
01 2026-04-23 AUTO_SYNC_ZENN 独断デフォルト化 独断判断 Zenn 5本一時 unpublish（復旧済み）
02 2026-04-24 reviewer指摘を確認せず転送、定数が逆に食い違い 事実確認漏れ GTDラベル定数が逆に食い違い（ゴミラベル削除済み）
03 2026-05-02 /todoコマンド構造を確認せずゴミIssue作成 独断判断 Issue #1314 誤作成（即削除）
04 2026-05-02 fact-checkが過去版を引用、「対処要」と誤上申 事実確認漏れ 実害なし（上申直前で発見）
05 2026-05-02 クロスポスト時にPlaybook読まず手動実装 Playbook未参照 不完全記事が一時公開（復旧済み）
06 2026-05-03 はてな新規記事公開でタイトルが「■」に文字化け Playbook未参照 文字化けタイトルで公開（修正済み）
07 2026-05-03 ネタ帳をCOOがPlaybook未参照で直接執筆 Playbook未参照 非準拠ネタ帳を一時保存（書き直し済み）
08 2026-05-03 researcherがGA4 URLを別記事と取り違えレポート作成 事実確認漏れ 実害なし（上申直前で検知）
09 2026-05-03 writerが存在しないバージョン番号・コマンドを創作 事実確認漏れ 実害なし（reviewer検知）
10 2026-05-03 BashにGrep/Readを書いて専用ツールルール違反 独断判断 permission 2行が自動追加（rollback済み）
11 2026-05-04 blogsync直接実行でブログURL 4件が404 独断判断 URL 4件404→手動復旧済み

severity が major だったのは #11 の blogsync 事故のみ。残りは中・低・軽で、レビュープロセスや既存チェックポイントが機能したことで実害が限定された件が多い。

全体考察：3類型に共通する「急いでいるとき」という病

11件を並べて改めて気づくことがある。3つの類型——独断判断・Playbook未参照・事実確認漏れ——は一見バラバラに見えるが、根本に同じ構造がある。

「これくらいなら確認しなくていい」という省略判断だ。

AUTO_SYNC_ZENN をデフォルト化したのも、クロスポストスクリプトを手動で実装したのも、reviewer の指摘をそのまま転送したのも——どれも「急いでいた」か「短文に見えた」か「AIを信頼していた」かのいずれかが理由だ。確認コストを節約しようとした判断が、復旧コストを生んだ。

一段抽象化して言い直すと、こうなる。AIに速さを求めるほど、確認を省くインセンティブが強くなる。人間でも同じことが起きるが、AIは「省略した」ことを自覚しにくい。#09 で writer が「数値創作なし」と自己申告しながら3件創作したのは、その典型だ。省略が見えないから、ルールが外から設計されなければ止まらない。

Claude Code 事故記録がルール設計を育てる逆説

11件を記録するのは、コストだ。事故が起きるたびに「何を・なぜ・どう防ぐか」を6項目で書く。AIに書かせても、何を事故と認定するかの判断は人間が下す。「無駄では？」と思っていた時期もある。

でも実際には逆のことが起きた。

2026-04-24 の #02（reviewer の指摘を一次確認せず転送）から「チェックポイント3」を作った。そのルールが 2026-05-02 の #04 で機能し、2026-05-03 の #08 でも機能した。ルールを生んだ事故から8日後・9日後に、そのルールが別の2件を止めた。

11件のファイルは単なる反省文ではない。事故記録が次のルールを生み、ルールが次の事故を止め、止まった事故がまた別のルールを育てる——そういう設計の原材料だ。

「無事故の組織」と「記録できた組織」を比べると、1か月後に強いのは後者だと思っている。無事故は「何も起きなかった」だけかもしれない。記録できた組織は「何が起きたかを知っていて、次は違う動きができる」。記録コストは、設計への投資だった。

この考え方の土台は、ソフトウェア組織の研究で言えば「変更失敗率」「平均復旧時間（MTTR）」を軸においた実証研究に近い。LeanとDevOpsの科学［Accelerate］ は4年間・2000組織のデータをもとに「何が高パフォーマンス組織を作るか」を分析した本で、「インシデントから素早く回復できる組織が強い」という結論は、AIエージェント運用にもそのまま当てはまる。

Claude Code を使い始めたばかりの人へ

「これだけ11件も事故が起きたなら、最初からガチガチにルールを整備してから使うべきでは？」

違う。むしろ逆だ。

現在の CLAUDE.md のトリガーリストは、最初から設計したものではない。最初の事故が1行を追加し、次の事故がまた1行を追加した。踏みながら育てた。11件の事故がなければ、現在のルールセットは存在しなかった。

「踏んで覚える」ことへの罪悪感は要らない。問題は事故を起こすことではなく、記録しないことだ。記録があれば次に活かせる。記録がなければ、同じ罠を無限に踏み続ける。

Claude Code を使い始めたなら、あなたはもうすでに何かをやらかしている。あるいはこれからやらかす。そのとき「なぜ起きたか」を6行でいいから書いておいてほしい。その6行が、1か月後の自分を助ける設計書になる。

FAQ

Q: 多エージェント組織を作らないと、これらの事故は起きない？

起きる。特に「事実確認漏れ」類型の4件は、シングルエージェント・単純なチャット利用でも同様の判断ミスは発生しうる。多エージェント構成は「伝言ゲームのコスト」を加えるが、事故の根本原因は「確認せず信じた」「Playbookを読まなかった」という判断の問題だ。組織構成より先に「人間だったら何を確認するか」を問う習慣が効く。

Q: ルールを増やしすぎると動かなくなるのでは？

体感では逆だ。ルールが曖昧なほど「これはルール内か外か」の判断でトークンを消費する。具体的なトリガーリスト（「この操作は確認を取る」など）は判断コストを下げる。ただし「全てのケースを網羅しようとする」ルール設計はパンクする。「よく踏む罠だけ書く」が持続可能な運用。

Q: 事故記録の書き方を教えてほしい

本記事では省略したが、実際に使っているフォーマットは「日付 / 事故概要 / 被害範囲 / 原因（独断判断・トリガー見落とし・ルール不備の3択）/ 再発防止策 / ルール更新箇所」の6項目。この6行を埋めるだけで「次に同じことが起きたとき、どこを見ればいいか」が分かる記録になる。詳細は本文中の事例でも同じ構造を採用している。

Q: AIが書いた事故記録の信頼性をどう担保するのか

正直に言うと、担保しきれていない部分がある。事故直後のセッションログ（会話の生ログ）を一次資料として残し、事故記録はその要約に位置づけている。「記録が正しいかどうか」より「記録があるかどうか」のほうが重要なフェーズにいる。記録の精度よりも記録の継続を優先した結果、今の11件がある。

Q: チェックポイントの仕組みが気になる。自動で動くのか？

自動ではない。CLAUDE.mdのトリガーリストを「常時参照すべきルール」として記述することで、Claude Code が各操作前に「これはトリガーに該当するか」を自問するよう促している。完全な自動化ではなく「忘れにくい設計」だ。実際に今回の11件のうち数件は、トリガーリスト整備後でも同じ判断ミスを繰り返しており、ルールを書くだけでは不十分という現実がある。

11件の事故記録を振り返ると、次の問いが出てくる——そもそもエージェント組織を「最初からどう設計すれば」、踏む前に罠を回避できるのか。

私はその問いに向き合うため、マルチエージェント組織の設計思想と役割分担のフレームワークを Zenn Book にまとめた。Vol.1『AIチームを作るまで』はエージェント組織の設計原則から CLAUDE.md 構築までを扱い、Vol.4『仕組みを渡すまで』では本記事に登場したトリガーリストやガバナンスルールの設計方法を詳しく解説している。序章・第1部は無料で読める。

関連記事

この記事のテーマを深掘りした本

コードを書けない私がClaude Codeで「AIチーム」を回すまで 「作る」の次。運用・三層品質ゲート・事故対応の設計（序章無料）

シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム