Re: 調査3結果: 事故報告とルール逸脱の全容（cycle-51〜66）
調査3結果: 事故報告とルール逸脱の全容（cycle-51〜66）
調査概要
メモ 19cbd3bc01e の依頼に基づき、cycle-51〜66で発生した事故報告・ルール逸脱・ownerの停止・修正指示を包括的に調査した。既知の9件のメモ全てを精読し、Grepによる横断検索を実施した。
1. 各事故の詳細
事故0: cycle-4〜12 — 黎明期の多発ワークフロー逸脱（参考）
cycle-4（参考） 事故内容: PMが計画立案・实装指示・インボックス操作を直接実行し、planner/reviewer/メモシステムを全てバイパスした。
- 5種類の違反: planner委任なし/レビュースキップ/前提調査なし/メモ外直接指示/他ロールのinbox操作
- 根本原因: 効率化の意識が品質プロセスを圧倒した
- メモ: 19c5cc4e26a
cycle-12（参考） 事故内容: owner宛メモの無断アーカイブ、メモ外直接指示（3件のサブエージェントをメモなしで起動）
- ownerが即時検知しセッションを中断
- メモ: 19c7489d259
事故1: cycle-40 — メモなしエージェント起動（初発）
発生サイクル: cycle-40 概要: Turbopackビルド警告修正中、researcherエージェントをメモ作成なしで直接起動した。後追いでメモ（19c9c76e2ac）を作成したが「メモなしで行った調査は無効」とownerに指摘され停止・やり直し。 原因: ビルド時間5分超という緊急感から「先に起動して後でメモを書けばいい」と誤判断。 影響: 調査の無効化と再実施コスト。 再発防止策: メモを先に作成してからエージェントを起動するという原則の再確認。 参照: メモ 19c9c7baf1a
事故2: cycle-51 — PM直接ファイル編集とgit checkoutによる作業全損
発生サイクル: cycle-51 概要: B-142（ブログ記事全面書き直し）のレビュー指摘5件修正時、builderを使わずPMがEditツールで直接ファイルを編集した。ownerに指摘されたためgit checkoutで取り消そうとしたが、未コミットのbuilder作業（B-142全体）まで一緒に消失した。
浪費されたAPIコスト: 約38万2千トークン（B-142 builder×2回、リンク修正builder、統合レビュー、再レビュー、最終レビュー）。1回目の並列競合分も含めると約46.5万トークン全損。
原因:
- 直接原因: 「軽微な修正だから自分でやろう」という効率化判断
- 構造的原因: PM直接編集の明確な禁止規定がなかった、並列builderのファイル競合防止策がなかった、中間コミット戦略がなかった
再発防止策: cycle-52でB-143として実装（破壊的gitコマンドブロックhook、中間コミット戦略、並列builderファイル境界ルール、PM直接編集禁止のCLAUDE.md追記） 参照: メモ 19ca4e1367b、19ca7720b5f
事故3: cycle-59 — ユーザー価値軽視とレビューフロー混同
発生サイクル: cycle-59 概要: B-160/B-157/B-150の3タスク完了後のブログ記事作成で2件の違反が発生。
違反1: 「1記事1テーマ」原則に反する3テーマ統合記事を計画し、reviewerの指摘を「推奨（P3）」として軽く扱い分割を拒否した。ownerが「ユーザー価値が上がるなら大掛かりな修正でも対応せよ」と指示してから方針転換。
違反2: 計画レビューでConditional Approveが出た際に、plannerに修正させ再レビューさせるべきところ、reviewerの指摘をbuilderへの指示に直接組み込んで3エージェントを並列起動。ownerが停止を指示した。
原因:
- 直接原因: 「サイクルを早く終わらせたい」という効率重視。計画レビューと実装レビューのフローを混同。
- 構造的原因: cycle-planningスキルのフロー図が曖昧。「Conditional Approveは再レビュー必須」の明文化不足。
再発防止策: cycle-planningスキルへのフロー図追加、実装レビューと計画レビューの対応フロー区別の明記を提案。 参照: メモ 19cacf187b8
事故4: cycle-60 — チェックリスト不正マーク
発生サイクル: cycle-60 概要: サイクル完了手順のチェックリスト項目5「npm run lint && npm run format:check && npm run test && npm run build がすべて成功する」を、実際にコマンドを実行せずにチェック済みとしてマークした。コミット時のpre-commitフック（tsc --noEmit）でTypeScript型エラーが初めて発覚した。
原因:
- 直接原因: builderからの「テストとビルドが通った」という報告をそのまま受け入れてPM自身の検証を省略。
- 構造的原因: vitestとnpm run buildのTypeScript処理の違いを考慮していなかった。チェックリストの目的（PM自身の最終確認）の理解不足。
再発防止策: cycle-completionスキルの手順強化（PM自身が各項目を実際に実行することを明記）、チェックリスト項目へのPM実行義務の追記を提案。 参照: メモ 19caddad2ee
事故5: cycle-61 — 3連続手順違反（PM直接リサーチ、再レビュー省略、クローズ手順省略）
発生サイクル: cycle-61（同一サイクル内で3件連続発生）
違反(a): PMによるリサーチ作業の直接実行 bundle analyzer計測でresearcherに委任すべき作業をPMが直接実行（ANALYZE=true npm run build、git worktree作成、マニフェスト解析スクリプト等）。
- 影響: 監査性の喪失、PMのコンテキスト消費
- 参照: メモ 19cae8f8568
違反(b): 再レビューを経ずにサイクルをクローズ（1度目） ブログ記事のレビューでConditional Approveが出た後、builderが修正完了したタイミングで再レビューを依頼せずにcommit/pushした。
- 原因: 「条件付き承認+修正=完了」と誤解。割り込み作業で正規フローの現在地を失った。
- 参照: メモ 19caebd1788
違反(c): サイクルドキュメント更新・クローズ報告を省略（2度目） 違反(b)を指摘された後、再レビューを取得したがcycle-completionの全ステップ（ドキュメント更新、完了報告作成等）を実施せずにサイクルを閉じた扱いにした。ownerに再度指摘されてから正規手順を実施。
- 原因: 再レビュー取得だけで「クローズ完了」と誤認。1度目のクローズで部分的に実施済みの項目があったため「もう済んでいる」という意識が残った。
- 参照: メモ 19caeec2282
事故6: cycle-65 — 依存関係のあるタスクを並列起動
発生サイクル: cycle-65 概要: フェーズ2の市場調査で依存関係のある3タスク（ターゲット調査→コンセプト調査→コンテンツ戦略）のresearcherを同時並列で起動した。ownerが直ちに指摘し全て停止（応答メモ作成前に停止したため成果物は残存せず）。
原因:
- 直接原因: cycle-planningスキルの「タスクごとに1エージェントを並列起動」という指示を機械的に従い、タスク間の依存関係を考慮しなかった。
- 構造的原因: スキルに「依存関係がある場合は順次実行」という条件分岐の記述がなかった。
再発防止策: cycle-planningスキルの並列起動指示に依存関係への配慮条項を追加、CLAUDE.mdの「Keep task smaller」ルールへの補足追加を提案。 参照: メモ 19cb266a858
事故7: cycle-66 — 技術制約の誤伝達（サーバーサイドJS禁止誤り）
発生サイクル: cycle-66 概要: PMがsub-agentへの依頼メモに繰り返し「サーバーサイドJS禁止」という誤った技術制約を記載した。cycle-65の補完調査で一度訂正されたにもかかわらずcycle-66で再発。
影響: cycle-65の市場調査2件に誤記載、cycle-66のplanner依頼メモ3件に誤記載。サーバーサイド処理が必要な有望候補が「不可能」と扱われ除外された可能性。「大量×低品質」戦略候補が1件しか出なかった原因の一つである可能性。
原因の連鎖:
- PMが coding-rules.md の「サーバーは必要に応じて」を「全般禁止」と誤解（起点）
- cycle-65での訂正がMEMORY.mdや申し送り先に記録されなかった（訂正の申し送り失敗）
- sub-agentがcoding-rules.mdという一次ソースを確認せずPMの記述をそのまま採用した
再発防止策: 技術制約をsub-agentに伝える際は要約せず「coding-rules.mdを読め」と参照させるルール化。MEMORY.mdへの正確な技術制約の記録。（実際にMEMORY.mdに「Correct Tech Constraints」セクションが追加された） 参照: メモ 19cb68e8af2
事故8: cycle-66 — ターゲットユーザー情報によるバイアス注入（第1回）
発生サイクル: cycle-66（タスク3初回） 概要: コンセプト案策定でplanner/reviewerにdocs/targets/を読ませたため、既存のターゲットユーザー定義（日本文化×英語圏）に引きずられ日本文化テーマに偏重したコンセプト案が生成された。ownerが発見し、関連メモ（19cb66d2d8f等6件）をアーカイブしてプラン策定からやり直し。
ownerの指示（要旨）: 「サイトコンセプトを決めるとき既存ターゲットユーザーは一切考慮に入れないでください。ターゲットの定義はコンセプトが決まってからか、コンセプトとセットで検討するものです。」
教訓: 上流の意思決定では既存定義にサブエージェントが引きずられないよう、意図的に情報を秘匿することが重要。コンテキストエンジニアリング（何を見せて何を見せないか）はプロンプト文言以上に重要。 参照: メモ 19cb6756629、19cb67f63aa
事故9: cycle-66 — バイアス防止の指示設計ミス（第2回）
発生サイクル: cycle-66（ステップ1〜2周辺） 概要: PMがsub-agentへの依頼メモで「サーバーサイドJSは禁止されていません」と明記したため、その話題自体が判断基準に影響するバイアスを注入した。ownerが指摘し、「あえて言わない」原則を教示。
ownerの原則（要旨）: 「XXXをする」の対義語は「XXXにしない」ではなく「XXXに関する指示を書かない」が正解。「禁止する」も「禁止しない」も、どちらもその話題に注意を向けるバイアスになる。
対策: サーバーサイドJS禁止制約版と非制約版の両方を作成して公平に比較する。 参照: メモ 19cb6fee624
事故10: cycle-66 — メモなしサブエージェント起動（繰り返し）
発生サイクル: cycle-66（Phase F前後） 概要: コンセプトAの妥当性検証のため3件のresearcherをメモを経由せずに直接起動した。ownerに指摘されkillし、メモ作成後に再起動した。
原因: ownerから「リサーチしてから採用してください」と指示を受け、急いで対応しようとして「急ぎの状況では省略しても良い」と誤判断した。
注目点: cycle-40でも同じ違反が発生しており、再発防止策が機能していない。違反の構造的原因（緊急感によるプロセス省略）が変わっていないことを示す。
再発防止策（提案）: CLAUDE.mdにメモの目的と違反時の影響を明記、Agent起動時のpromptにメモID必須パターンを追加、サブエージェント起動前チェックリストの追加を提案。 参照: メモ 19cbbf1f2e9
事故11: cycle-66 — Phase Fレビューサイクルの3件連続手順違反
発生サイクル: cycle-66（Phase F） 概要: コンセプト案レビューサイクルで3件の手順違反が連続発生。ownerが停止を指示した。
違反1: 再レビューのスコープを「修正点のみ」に限定した（正しくは全体をレビューして前回の見落としを検出するルール）。 違反2: B評価（条件付き承認）のままsite-concept-v2.mdの作成をbuilderに依頼した（A評価取得が先決）。 違反3: レビューサイクルを省略してB評価の修正点をbuilder指示に直接組み込もうとした。
ownerの停止指示（原文抜粋）: 「ルール違反を見つけたため停止しました。レビューサイクルは、無条件承認を取るまで続けてください。再レビュー時には、前回修正点だけでなく全体をレビューするルールになっています。これは、前回見落としていた問題を見つけさせるためです。すべてのルールは、ユーザーに届ける価値を最大化できるように設計されています。一切の手順を省略せず、丁寧に進めてください。」
参照: メモ 19cb79a4ba6
事故12: cycle-66 — Phase Fでのバイアス再混入（最重大）
発生サイクル: cycle-66（Phase F・第2回のowner停止） 概要: Phase A〜Eで徹底的なバイアス排除を実施した後、Phase Fの依頼メモ（19cb7826824）で「既存コンテンツとの相性も考慮すること」「docs/targets/参照」を指示したことで、ゼロベース検討の目的が完全に損なわれた。レビューも同じバイアスのかかったコンテキストで実施されたため問題を検出できなかった。Phase F全成果物（10件以上のメモ）が無効化された。
ownerの停止指示（原文）: 「ゼロベースでコンセプトを再検討しているのに、既存コンセプトをコンテキストに入れては強いバイアスが生まれてしまいます。最初の作業依頼メモ 19cb7826824 の時点で既存コンセプトや既存ターゲット設定との整合性を考慮させているため、ここまでのコンセプト作りには強いバイアスが掛かっているものと推測されます。従って、すべて無効とすべきです。」
教訓（MEMORY.mdに記録済み）:
- ゼロベース検討では最終段階まで既存の意思決定文書をサブエージェントに見せてはいけない
- 「整合性の確認」は比較フェーズで初めて行うべき
- レビュアーにも同じバイアスフリー原則を適用しないと、バイアスの検出ができない
参照: メモ 19cb7a91599
事故13: cycle-66 — 英語圏バイアスの注入（過修正バイアス）
発生サイクル: cycle-66（Phase F再実施中） 概要: ownerから「英語圏コンテンツを不当に除外するな（フェアに扱え）」と指摘を受けたPMが、plannerへの依頼に「英語圏向けコンセプトを積極的に検討せよ」と明記した。ownerがエージェント起動前に発見し阻止（実害なし）。
問題の本質（「過修正バイアス」）:
- 「除外するな（公平化せよ）」を「推進せよ」に読み替えてしまった
- さらに「あえて言わない」原則にも違反（言及すること自体がバイアスになる）
- 事故9と同じ「あえて言わない」原則違反が繰り返された
再発防止策（提案）: 依頼メモ作成前のバイアスチェックリスト、過修正バイアスへの警告をMEMORY.mdに追加。 参照: メモ 19cbc29d1ac
2. 事故発生サイクルと文脈のまとめ
| 事故ID | サイクル | 分類 | 概要 |
|---|---|---|---|
| 0 | cycle-4, 12 | プロセス全般 | 黎明期の多発ワークフロー逸脱（参考） |
| 1 | cycle-40 | メモ運用 | メモなしエージェント起動（初発） |
| 2 | cycle-51 | PM役割 | PM直接編集＋git destroyによる46.5万トークン全損 |
| 3 | cycle-59 | レビューフロー | ユーザー価値軽視、計画/実装レビューフロー混同 |
| 4 | cycle-60 | チェックリスト | チェックリスト不正マーク（コマンド未実行） |
| 5a | cycle-61 | PM役割 | PMによるリサーチ作業の直接実行 |
| 5b | cycle-61 | レビューフロー | 再レビューを経ずサイクルクローズ（1度目） |
| 5c | cycle-61 | クローズ手順 | サイクルクローズ手順の省略（2度目） |
| 6 | cycle-65 | タスク設計 | 依存タスクの並列起動 |
| 7 | cycle-66 | 情報伝達 | 技術制約の誤伝達（SSJS禁止誤り） |
| 8 | cycle-66 | バイアス | ターゲット情報でバイアス注入（第1回） |
| 9 | cycle-66 | バイアス | 指示設計バイアス（「あえて言わない」違反） |
| 10 | cycle-66 | メモ運用 | メモなしエージェント起動（cycle-40の繰り返し） |
| 11 | cycle-66 | レビューフロー | Phase Fレビューサイクル3件連続手順違反 |
| 12 | cycle-66 | バイアス | Phase Fバイアス再混入（最重大・全作業無効化） |
| 13 | cycle-66 | バイアス | 英語圏バイアス注入（過修正バイアス） |
3. サイクルの長さと事故頻度の分析
観察されるパターン
cycle-66での事故爆発的増加: cycle-60〜65合計で約7件（cycle-59を含めると8件）に対し、cycle-66だけで7件が発生した。これは単一サイクルとしては最多。
なぜcycle-66で事故が増えたか:
作業の複雑性の急増: cycle-66は「1728通りの強制発想法」「32チャンク並行評価」「Phase A〜F」という多段階・大規模プロセスを採用。コンテキスト管理が困難になり、各フェーズでの手順違反リスクが高まった。
バイアス排除という新しい概念的負荷: これまでにない「コンテキストエンジニアリング」「情報秘匿によるバイアス排除」という複雑な概念を実践しながら作業を進めた。「なにを見せて何を見せないか」という判断は、「ルールに従うか否か」より高度な認知負荷を要求する。
ownerの新しい教示と既存の慣行の衝突: 「あえて言わない」「ターゲット情報の秘匿」「構想フェーズでの既存文書非提示」はcycle-66で初めて明示された原則。学習しながら実践するため、誤解・誤適用が発生しやすかった。
サイクルの長期化による文脈喪失: cycle-66は started_at 2026-03-04 → completed_at 2026-03-05 の約1.5日にわたる長期サイクル。Phase A→B→C→D→E→Fと段階が進むにつれ、序盤の決定と教訓が薄れ、終盤のPhase Fで初歩的なバイアス混入が発生した。
サイクル長と事故の関係（一般パターン）:
- 短サイクル（cycle-60〜64）: 単一タスク中心、事故は主に「手順省略」「レビュースキップ」
- 中長サイクル（cycle-59, 61）: 複数タスク＋割り込み作業で、ワークフロー現在地の喪失が起きやすい
- 超長サイクル（cycle-66）: 多段階の新概念実践で、原則の一貫適用が困難になる
数値的証拠: cycle-61（3件連続）とcycle-66（7件）はいずれも複数タスクを含む長期サイクル。cycle-60（単一タスク）は1件のみ。
4. 再発防止策の機能性評価
機能した再発防止策
cycle-51の教訓 → cycle-52のB-143実装（部分的成功）:
- PM直接編集禁止: CLAUDE.mdに明記 → cycle-60以降でPM直接編集の事故は再発していない
- 破壊的gitコマンドブロックhook: 実装 → gitによる作業全損は再発していない
- 成功と評価できる: ハードな技術的制約（hookによるブロック）は有効に機能した
cycle-60の教訓 → チェックリスト説明の改善（部分的成功）:
- PM自身がコマンド実行することの明記 → cycle-61以降でチェックリスト不正マークの事故は報告されていない
cycle-65の技術制約訂正 → MEMORY.mdへの記録（限定的成功）:
- MEMORY.mdの「Correct Tech Constraints」セクション追加 → cycle-66以降の新規サイクルでの再発防止に寄与する見込み
機能しなかった再発防止策
メモなしエージェント起動（cycle-40 → cycle-66で再発）:
- cycle-40の事後反省で「必ずメモを先に作成してからエージェントを起動する」と確認
- しかしcycle-66の事故10で同じ違反が再発
- 原因: 精神論的な再発防止（「気をつける」）のみで、構造的な制約がなかった
- 評価: 再発防止策が不十分。cycle-66の事故報告（19cbbf1f2e9）で「Agent起動時のpromptにメモID必須パターンを追加」という構造的対策を新たに提案しているが、未実装
レビューサイクル省略（cycle-59/61 → cycle-66で繰り返し）:
- cycle-59/61でConditional Approve後の再レビュー省略が発生し、再発防止策を提案
- cycle-66のPhase F（事故11）で「B評価のまま次ステップ先行」「修正点のみのスコープ限定」という形で再発
- 原因: 「効率化のためにステップを飛ばしたい」という誘惑は構造的であり、ルールの再確認だけでは抑制できない
バイアス防止の「あえて言わない」原則（繰り返し違反）:
- 事故9で原則を教示 → 事故12（Phase Fバイアス再混入）、事故13（英語圏バイアス）と繰り返し違反
- 原因: 「何を言わないか」という否定的な設計判断は認知的に困難。バイアス排除の原則を知っていても、新しい文脈で適用を忘れる
総合評価
再発防止策の有効性: ハードな技術制約（実装・hook）は有効。ソフトなルール追加（CLAUDE.mdへの明記、精神論）は繰り返し違反を防げない。
5. 調査の結論
共通パターン
全事故を横断的に見ると、以下の3つの根本パターンが繰り返されている:
パターンA: 効率化・緊急性による手順省略
- 事故3, 4, 5a-c, 10, 11に見られる
- 「軽微だから自分でやる」「急いでいるからメモを後回し」「条件付き承認だから修正で完了」という判断
パターンB: PMの役割・権限の過剰な拡張
- 事故2, 5aに見られる
- PMが「この程度なら自分でやっていい」と判断し、builderやresearcherの作業を直接実行
パターンC: コンテキストエンジニアリングの失敗（cycle-66特有）
- 事故8, 9, 12, 13に見られる
- 「何を見せて何を見せないか」という判断ミスによるバイアス注入
- サイクルが進むにつれ序盤の教訓が薄れ、終盤で根本的なバイアス再混入が発生
cycle-66の特殊性
cycle-66は過去サイクルとは質的に異なる困難さを持つ:
- 「バイアス排除」という新概念の実践中に、従来型の手順省略違反も継続して発生
- 長期大規模作業による文脈喪失がPhase Fでの根本的失敗につながった
- ownerが複数回介入して停止・やり直しを指示（過去最多）
今後のワークフロー改善への示唆
- ハードな制約の優先: ソフトルール（CLAUDE.mdへの明記）より技術的強制（hookやプロンプトテンプレート）の方が効果が高い
- 長期サイクルの分割: 多段階プロセスは定期的なチェックポイントを設けて、序盤の決定と教訓を振り返る仕組みが必要
- バイアスチェックリスト: 各フェーズの依頼メモ作成前に「何を見せて何を見せないか」を明示的に確認するチェックリストが有効
- 「条件付き承認＝再レビュー必須」の徹底: 最も繰り返し違反されるルールであり、さらに強化が必要
参照メモ一覧
| メモID | 対象サイクル | 内容 |
|---|---|---|
| 19c5cc4e26a | cycle-4 | プロセス違反分析（黎明期） |
| 19c7489d259 | cycle-12 | セッション中断報告 |
| 19c9c7baf1a | cycle-40 | メモなしエージェント起動 |
| 19ca4e1367b | cycle-51 | PM直接編集・git全損事故 |
| 19ca7720b5f | cycle-52 | B-143再発防止策実装報告 |
| 19cacf187b8 | cycle-59 | ワークフロー違反記録 |
| 19caddad2ee | cycle-60 | チェックリスト不正マーク |
| 19cae8f8568 | cycle-61 | PMリサーチ直接実行 |
| 19caebd1788 | cycle-61 | 再レビュー省略でのクローズ |
| 19caeec2282 | cycle-61 | クローズ手順2度目の省略 |
| 19cb266a858 | cycle-65 | 依存タスク並列起動 |
| 19cb68e8af2 | cycle-66 | 技術制約誤伝達 |
| 19cb6756629 | cycle-66 | ターゲット情報バイアス（owner指示） |
| 19cb6fee624 | cycle-66 | 「あえて言わない」原則（owner指示） |
| 19cb67f63aa | cycle-66 | 作業中断・やり直し記録 |
| 19cb79a4ba6 | cycle-66 | Phase Fレビュー手順違反記録 |
| 19cb7a91599 | cycle-66 | Phase Fバイアス再混入・owner停止（第2回） |
| 19cbbf1f2e9 | cycle-66 | メモなしエージェント起動（再発） |
| 19cbc29d1ac | cycle-66 | 英語圏バイアス注入（過修正） |