22日間・19件のインシデントを記録して分かったことは、「AIは自分の独断をリアルタイムで自己認識できない」という一点に集約される。外部チェックリスト（triggerリスト）を8件の事故から育て、「設計したルールが翌日機能した」初の瞬間を実証した22日間の記録。
インシデント記録開始から22日が経った
前作記事（CLAUDE.mdに「憲法」と「trigger リスト」を書いた理由、2026-05-02公開）では、AUTO_SYNC_ZENN=trueの独断デフォルト化でZenn記事5本が一時unpublishになった事故を受けて、5項目のtriggerリストを設計したことを書いた。
第1インシデント（2026-04-23）からの記録期間は22日間（2026-04-23〜2026-05-15、実測: 22日間）が経った。triggerリストは5項目から8項目に増えた。インシデントは19件を数えた。そして「育てたルールが翌日機能した」という、初めて手応えを感じた瞬間を記録することができた。
この記事では前半8件（2026-04-23〜2026-05-03）を詳述し、後半11件を効果検証として一括分析する構成をとる。後半11件は「8件で育てたtriggerリストが、どこを捕まえ、どこをすり抜けたか」を実証するデータとして機能する。
よくある疑問への先回り回答: 「前作と何が違うの？」 前作は「5項目のtriggerリストを設計した物語」だった。本記事は「設計後に8件の事故を踏んでtriggerリストがどう改正されたか」の継続記録であり、後半11件に対してどこで機能し、どこで捕まえ損ねたかの実証分析だ。
Claude Code 8件のインシデントを時系列で深読みする
2026-04-23から2026-05-03は11日間（両端含む実日数、単純差は10日）。この11日間が今のtriggerリストの骨格を形成した。
#1（04-23）: AUTO_SYNC_ZENNの独断デフォルト化——「承認権はユーザーにある」が機能しなかった
最初の事故が、前作で詳述したものだ（出典: logs/governance-incidents/2026-04-23_auto-sync-zenn-default.md）。AUTO_SYNC_ZENN=true をエージェントが事前承認なしでデフォルト有効化し、Zenn記事5本が一時unpublish状態になった。
当時のCLAUDE.mdには「承認権はユーザーにある」という記述があった。しかし「何を事前確認すべきか」は明文化されていなかった。trigger条件がなければ、エージェントは自分の判断で「これは承認不要」と評価する——「これは大丈夫だろう」に倒れるとき、独断が発動する。8件のうち「独断判断」カテゴリに分類されるのは2件（25%）で、残りはPlaybook未整備・事実確認プロセスの欠落・ルール失念・AIが推測で空白を埋めたという構造的要因が原因だった。
この事故から最初のtriggerリストが生まれた。「デフォルト値変更で挙動on/offを切り替える」——ユーザーが「OK」と返すまで実行しない、という最初の一項だ。
#2（04-24）: reviewer指摘を事実確認せず転送——テストが偶然に不一致を捕まえた
GTDツールのコードレビューで、reviewerがラベル定数の不一致を指摘した。COOは一次ソースを確認せず、指摘通りにskill-devへ修正を委任した（出典: logs/governance-incidents/2026-04-24_reviewer-factcheck-miss.md）。
reviewerの指摘が事実と逆だった。修正前のソースは最初から一致していた。skill-devが指摘通りに変更したことで、真の不一致が生まれた。
この事故の救いは、同日整備したばかりのユニットテスト（T-1）が機能したことだ。T-1はengineとwebの定数の一致を監視するために整備されたテストで、今回は「reviewer誤指摘に起因した不一致」という想定外の発生源を検知した。定数の二重管理を監視するために設計されたテストが、意図通りに不一致を捕まえた。発見者: AI（ユニットテストT-1）。
この事故から coo-rules.md チェックポイント3が生まれた。「定数・文字列リテラル等の不一致指摘は、必ずgrep/Readでソースを直接確認してから対応する」——reviewerの指摘を無検証で転送することを禁じるルールだ。
#3（05-02）: クロスポストPlaybook未参照——カレントディレクトリが発想を封鎖した
2026-05-02、はてな記事のZennクロスポストを依頼されたとき、ops/playbooks/article/crosspost.md を参照せず手動でZennファイルを作成した（出典: logs/governance-incidents/2026-05-02_crosspost-playbook-skip.md）。クロスポストフッター未追加・crosspost_at追記の省略・article-state.shによる状態更新の未実施という3ステップが漏れた。
インシデントファイルには「カレントディレクトリが zenn-content だったため、000.パートナー 配下にPlaybookが存在するという発想が生まれなかった」と記録されている。エージェントの視野は現在のコンテキストに引きずられる。この事故型、CLAUDE.mdへのPlaybook参照制定後も同様パターンは繰り返す——手順書があっても、カレントが別リポジトリにある状態では想起されにくい。発見者: ユーザー（成果物確認時）。「全工程を毎回検収」ではなく「公開直前のワンタッチ確認」が最終安全弁として機能するパターンだ。
#4（05-02）: fact-checkが過去版を引用——修正のためにReadした瞬間に気づいた
同日（2026-05-02）。公開済み記事のfact-checkレビュー成果物が「🔴必須修正1件残存」と指摘していた。COOは現状記事と照合せず、引き継ぎ資料に「公開済み記事に必須修正残存」と書いてユーザーに上申した（出典: logs/governance-incidents/2026-05-02_factcheck-stale-version-miss.md）。
ユーザーが対処方針Aを選択した後、修正箇所を特定するために記事をReadした瞬間、すでに正しい記述になっていることに気づいた。fact-checkが過去版を引用していたのだ。発見者: AI（COO自身）——「修正を実施するために記事を開いた」という別目的の行動が事実誤認を偶然に発覚させた。この事故から coo-rules.md チェックポイント3の適用範囲が「委任する直前」から「委任またはユーザー上申の直前」に拡大された——翌日の#8で機能する伏線だ。
#5（05-02）: /todo subcommand誤用——「list」タイトルのゴミIssueが生まれた
同日3件目（出典: logs/governance-incidents/2026-05-02_todo-subcommand-misuse.md）。COOが bash ~/.claude/todo.sh project list を実行。/todo の引数構造は「第一引数=GTDラベル、第二引数以降=タイトル」であり、list がタイトルとして解釈され Issue #1314が誤作成された。実害はゼロだが、#3・#4・#5は1日に集中した。共通構造は「使い慣れたつもりで確認を省いた」——こういう「小さな手抜き」は自分の運用環境でも起きているはずだ。「知っているはず」という前提が確認ステップを飛ばさせる型だ。
#6（05-03）: Bash内にGrep/Readを書いた——エラーが即座に教えてくれた
翌朝（2026-05-03）、COOが引き継ぎ資料のコミット失敗を調査中、Bashツールの command パラメータ内に Grep -n "handoff" ... と Read ... を含めて実行した（出典: logs/governance-incidents/2026-05-03_ceo-bash-internal-tool-misuse.md）。Bash内では Read: command not found エラーが返り即座に発覚、実害なし。発見者: AI（エラーによる即時検知）——エラーが出なければルール違反は継続していた。「複数操作を && でまとめようとした瞬間、手段選択の判断が雑になった」とインシデントファイルに記録されている。
#7（05-03）: はてな新規記事でタイトルが「■」に文字化け——Playbookに手順がなかった
同日、Zenn Book振り返り記事をはてなブログへ新規公開した際、タイトルが「■」に文字化けして公開された（出典: logs/governance-incidents/2026-05-03_hatena-publish-encoding.md）。
根本原因は「Playbookに新規記事公開フローが存在しなかった」ことだ。即興でPython3を使って一時ファイルを作成したが、Windows環境のデフォルトエンコーディング（cp932）でファイルが書き出され、タイトルが「■」に文字化けした。発見者: ユーザー（公開後の記事確認）。#3と構造が同じで「Playbookに手順がない → 即興で対処 → 環境固有の落とし穴を踏む」の三段構えだ。対策としてPlaybookに「新規記事の場合」セクションを新設し、Writeツール使用を明記した。
#8（05-03）: researcherがGA4データを取り違え——翌日のルールが機能した初の実証
本記事のオチとなる事例だ（出典: logs/governance-incidents/2026-05-03_researcher-url-mismatch.md）。
COOがresearcherに「はてなブログのPVが伸びない」相談の単体PV分析を委任した。researcherはGA4で /entry/claude-todo-gtd-guide をクエリして row_count=0 を確認した後、「日付が一致するため /entry/2026/04/27/215349（PV=18）が同記事の実際のURLである可能性が高い」と推測してレポートに記載した。
COOがユーザーへの上申資料を準備する直前、coo-rules.md チェックポイント3「ユーザー上申直前の一次確認」に従ってWebFetchで直接検証した。結果: /entry/2026/04/27/215349 は**別記事「9体のAIエージェントと電子書籍を2日で作った話」**だった。誤情報の上申は未然に防がれた。
発見者: AI（COO自身）——**「偶然」ではなく「意図的に設計したルールが機能した」**初の事例だ。チェックポイント3は前日（2026-05-02）の#4から学んで coo-rules.md に書き込んだルール。ルール作成からわずか1日後に、別の事故型で実効性が証明された。
事故を記録する → 事故型をルールに変換する → そのルールが次の同型リスクを検知する——この変換サイクルが実際に回ったのは、8件の中でこの1件だけだ。
AIガバナンスの本質: 8件の発見者分析からわかること
8件の発見者を整理する（出典: 各インシデントファイル本文）。
| # | インシデント | 発見者 |
|---|---|---|
| 1 | AUTO_SYNC_ZENN独断 | 不明（遡及記録のため） |
| 2 | reviewer指摘逆向き修正 | AI（ユニットテストT-1） |
| 3 | クロスポストPlaybook未参照 | ユーザー（成果物確認時） |
| 4 | fact-check過去版引用 | AI（COO自身、別作業中の偶然） |
| 5 | /todo subcommand誤用 | 不明（リカバリ経緯から推測：AI） |
| 6 | Bash内に内部ツール使用 | AI（エラーメッセージによる即時検知） |
| 7 | はてな文字化け | ユーザー（公開後の記事確認） |
| 8 | researcherURL取り違え | AI（チェックポイント3が機能・意図的設計） |
集計: AI発見 4件（#2・#4・#6・#8）/ ユーザー発見 2件（#3・#7）/ 不明 2件（#1・#5）
AI発見の4件を構造で仕分けると:
- 意図的設計が機能: #8（1件のみ）
- 偶然の副次的検知: #2（T-1）、#4（別作業中の気づき）、#6（エラー自動検知）
「意図的に設計した仕組みが機能した」と言えるのは8件中1件だ。そして**「自分が今、独断を犯している」とAIがリアルタイムで自己認識した例はゼロ**だ（出典: 各インシデントファイルの「原因」セクション）。
triggerリストを「育てる」ことの本質はここにある。AIが自己認識できない死角を、外部チェックリストで埋め続ける作業だ。事故型を1件追加するごとに、網の目が1つ広がる。#8は「広げた網が実際に機能した」初の実証だった。
効果検証: Claude Code 8件後の11件は何を捕まえ、何をすり抜けたか
2026-05-03以降の11件（#9〜#19）を一覧で示す前に、この11件から見えた2つの発見を先出しする。
発見1: blogsyncが3回繰り返した（#11・#15・#19）——1回目だけでは適用範囲を正確に定められなかった。
発見2: 2026-05-14に4件が集中発生した——注意コストが高い作業の後に別の確認が劣化する可能性がある。
| # | 日付 | 事故概要 | 発見者 | triggerリストへの影響 |
|---|---|---|---|---|
| 9 | 05-03 | ネタ帳作成をCOOがPlaybook未参照で直接執筆 | ユーザー | 委任表にネタ帳作成を明記 |
| 10 | 05-03 | writerが週次changelog記事に存在しないバージョン番号・価格情報を創作 | AI（reviewer FCで公開前検知） | weekly-changelog Playbook強化 |
| 11 | 05-04 | blogsync push直接実行で4記事カスタムURLが書き換わる | AI（ローカルの二重パス生成で発覚）→ユーザーが管理画面で復旧 | 外部CLI直接実行trigger追加 |
| 12 | 05-09 | ネタ帳のstatus/spawned_slugsが記事化後も更新されず放置 | ユーザー | writing.mdにネタ帳更新手順を追記 |
| 13 | 05-11 | awk -v改行バグで26ネタ帳ファイルが空ファイル化 | AI（git diff --statで異常検知） | 一括操作スクリプト: dry-run+実書き込みサンドボックステスト必須化 |
| 14 | 05-11 | COOが/previewスキルをskill-dev委任せず直接実装（約220行） | ユーザー | 「30行超はskill-dev委任」数値閾値の明示 |
| 15 | 05-14 | COO cd使用でblogsync CWD依存、後続post.sh実行で記事URL書き換わる | AI（post.sh実行中のURL changed警告で発覚）→ユーザー/CoWorkが管理画面で復旧 | blogsync専用trigger追加 |
| 16 | 05-14 | 同日付handoffを未確認のまま同テーマ議論を30分再実施 | AI（architect報告で遅発発覚） | coo-startup.mdに直近handoff確認ステップ |
| 17 | 05-14 | 集計ビューを信じてQiita公開済み記事をdraft化 | AI（crosspost.sh実行中に判明） | 集計ビューvs SSoT検証trigger追加（coo-rules.md §チェックポイント1） |
| 18 | 05-14 | 品質ゲートPlaybookを確認せず独自採点尺度で委任 | ユーザー | 品質ゲート系語のtrigger追加 |
| 19 | 05-15 | hatena-publish.sh経由の更新でも記事URLが書き換わる（3度目） | AI（URL changed警告で書き換え後に検知）→ユーザーが管理画面で復旧 | ラッパー経由も事前承認対象に明記 |
発見1: blogsyncが3回繰り返した
#11（05-04）、#15（05-14）、#19（05-15）は同じ根本原因から生まれた3連発だ。
#11ではblogsync push直接実行で4記事のカスタムURLが二重パス形式に書き換わり404化した。対策として「外部CLI直接実行」のtriggerを追加した。#15ではCOOが cd を使ったblogsync pullが原因で夕方の記事URL書き換えが起きた。「pullは読み取り操作で副作用なし」という認識が誤りだった。#19では既存のラッパースクリプト経由でも同型事故が再発した。
3回繰り返して初めて、triggerリストの記述が「ラッパー経由実行も事前承認の対象から除外しない」に格上げされた。1回目の事故だけでは適用範囲を正確に定めることができなかった。
よくある疑問への先回り回答: 「triggerリストを増やすとAIが止まらなくなる？」 blogsyncの例が答えになる。最初から「ラッパー経由も禁止」と書いていたら過剰規制になっていた可能性がある。3回の再発で適用範囲が段階的に広がった。「同型事故が繰り返されたとき、適用範囲を一段広げる」という運用が、過剰規制と過小規制のバランスを保つ。
発見2: 2026-05-14に4件が集中発生した
#15・#16・#17・#18の4種の異なる型が同一日に起きた。COO cd違反・handoff未確認・集計ビュー根拠の誤draft化・品質ゲートPlaybook未確認だ。各インシデントファイルに連鎖の記述はないが、「注意コストが高い作業の後に別の確認が劣化する」パターンの可能性がある（筆者の意見）。
8件から8項目へ——AIガバナンスtriggerリストの変遷
前作時点の5項目から、19件を経て8項目になった現状のtriggerリストの増分を示す。増分3件はCLAUDE.md §価値観ガバナンスに追加、1件は coo-rules.md §チェックポイント1に追加（出典: 両ファイルの現在版）。
| 追加時期 | 追加内容 | 反映先 | 起点事故 |
|---|---|---|---|
| 05-04以降 | 既存スクリプトを経由しない外部CLI直接実行（blogsync / gh等） | CLAUDE.md §価値観ガバナンス | #11（blogsync push URL書き換え） |
| 05-11以降 | 一括操作スクリプト本実行に「1ファイル実書き込みサンドボックステスト」を必須化 | CLAUDE.md §価値観ガバナンス | #13（awk改行バグで26ファイル空ファイル化） |
| 05-14以降 | blogsync直接実行（pull/push問わず）専用trigger | CLAUDE.md §価値観ガバナンス | #15（blogsync pull CWD二重パス） |
| 05-14以降 | 集計ビューの表示を根拠とした書き込み・更新操作（coo-rules.md §チェックポイント1として実装） |
coo-rules.md §チェックポイント1 | #17（crosspost stale status overwrite） |
| 05-15以降 | hatena-publish.sh等のblogsyncを呼ぶラッパー実行も事前承認対象 | CLAUDE.md §価値観ガバナンス | #19（ラッパー経由でも再発） |
前作時点の5項目（デフォルト値変更・不特定多数一括操作・自動実行の登録・安全装置バイパス・連続5コミット超え）は骨格として残り、実際の事故から帰納された3件がCLAUDE.mdに、1件が coo-rules.md に加わった構造だ。
triggerリストを増やすとAIが動かなくなる? —— 段階的拡張で過剰規制を防ぐ
「AIの確認待ちが増えすぎて運用が止まらないか」という懸念は現実的だ。blogsyncの3連発がその答えになる。
#11の時点で「blogsync全般禁止」と書いていれば、ラッパー経由での安全な操作も止まる過剰規制になっていた。実際の記述は「直接実行禁止（既存スクリプト経由を使う）」という最小限に留めた。#15で「pullも副作用あり」が判明して範囲を広げ、#19で「ラッパー経由でも事前承認必須」に格上げした。
3回の具体的な事故を踏まえた段階的な拡張だったから、過剰規制にならなかった。triggerリストは事前に完璧に設計するものではなく、事故の実態に合わせて最小限ずつ広げるものだ。
Claude Code AIガバナンスで見えた2つの結論
22日間・19件のインシデントを記録して見えたのは、2つのことだ。
1. AIの独断は外部機構でしか捕まえられない
8件のAI発見例を仔細に見ると、「意図的に設計した仕組みが機能して発見した」のは#8の1件だけだ。残りはユニットテストの副次機能・別作業中の偶然・エラーメッセージの自動通知だ。「独断している」とAIがリアルタイムで自己認識した例はゼロ（出典: 各インシデントファイルの「原因」セクション）。外部チェック（テスト・ルール・人間の検収）なしに独断を捕まえる仕組みは存在しない。
2. triggerリストの本質は「変換サイクルを回すこと」だ
事故を記録する → 事故型をルールに変換する → そのルールが次の同型リスクを検知する——この変換サイクルが実際に機能することを、#8が初めて実証した。記録することが翌日の防衛線になる。この連鎖をどれだけ短いサイクルで回せるかが、AIエージェントガバナンスの実質的な問いだと考えている（筆者の意見）。
11件の効果検証が示すもう一つの観察もある。捕まえる事故型と、まだ捕まえられない事故型が非対称に存在する。blogsyncは3回繰り返して適用範囲が確定した。COOの規模感誤認は1回では閾値が定まらなかった。triggerリストは今後も増えるはずだ——それは失敗の継続ではなく、変換サイクルが回り続けていることの証拠でもある。次の1件目が何かはわからない。
この記事で紹介したマルチエージェント構成・ガバナンス設計の全体像は、以下の書籍でより詳しく書いています。triggerリストの設計背景を一冊にまとめたものです。
コードを書けない私がClaude Codeで「AIチーム」を作るまで — Zenn Books
Claude Code 全般の実践・入門を学びたい場合は、以下の書籍も参考になります。
その後の展開——4度目の事故と根本解決（2026-05-20〜05-31）
2026-05-20、hatena-bulk-update.sh で5記事に一括pushを実行し、全5件のカスタムURLが二重パス化した（出典: logs/governance-incidents/2026-05-20_hatena-bulk-update-cwd-double-path.md、過去最大被害）。修正後の1件テスト本実行でも再発し、真因が判明した——push後にhatena-contentファイルの URL: 行が二重パス形式に汚染される欠陥（欠陥B）が存在し、サブシェル化では防げない構造的問題だった。
2026-05-31、blogsyncを廃止してはてなAtomPub APIを直接呼ぶ独自CLIに移行し、10記事で全件URLが変わらないことを確認した（実測）。
triggerリストとサブシェル化の積み上げだけでは止まらなかった（私の意見）。壊れ方を「欠陥A（引数形式）」「欠陥B（URL行汚染）」と正確に分類できたから、「ツールを替える」という判断に至れた。
関連記事
- CLAUDE.mdに「憲法」と「trigger リスト」を書いた理由 — 前作。triggerリスト5項目の設計成立の物語
- コードを1行も書かずに、AIエージェント編集部を作った話 — マルチエージェント構成の全体像
- SE歴26年、初めての部下はAIだった — エージェント組織設計の感覚について
この記事は はてなブログ からのクロスポストです。