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だった — エージェント組織設計の感覚について

この記事ははてなブログからのクロスポストです。