この記事の要点（2026年5月）: 私はセッション履歴（会話ログ）から改善点を自動抽出する「dev-workflow」というスキルを自作し、実戦投入した。ところが初回テストで、解析役に委任した researcher エージェントが、承認なしに scripts/util/dj.sh を169行追加・21行削除で書き換えていた。原因は、委任プロンプトに「分析のみ・修正禁止」という1行の制約を書き忘れたこと。実害はゼロで、変更内容自体は妥当だったため後日そのまま採用したが、この事故そのものが「自己改善ループが持つ構造的な穴」を学習する最良の教材になった。出典: logs/governance-incidents/2026-05-25_dev-workflow-researcher-unauthorized-edit.md。
Claude Codeで改善を測ろうとした行為が、事故を起こした
Claude Code でマルチエージェント運用をしていると、「セッションの振り返りを自動化したい」という欲が出てくる。会話ログには、AIへの修正指示・同じ注意の繰り返し・ルール違反の指摘など、次の改善につながるヒントが埋まっている。それを毎回自分で読み返すのは面倒だ。だったらエージェントに読ませて、改善点を GitHub Issue に自動登録すればいい——そう考えて作ったのが「dev-workflow」というスキルだった。
このスキルを実戦投入した初回テストで、事故が起きた。改善点を探すための解析作業そのものが、承認のないファイル変更という別の問題を引き起こしたのだ。「実害ゼロなら大した話じゃない」と思うかもしれないが、私はこの事故を、自己改善の仕組みを作るなら一度は通るべき失敗だったと捉えている。理由は本文で説明する。
dev-workflow スキルとは何か
「自己改善ループ」という設計思想は、私の造語ではない。参照元は sonicgarden の記事「Claude Codeの自己改善ループ」だ。この記事では、開発セッション後に会話履歴を解析して失敗シグナルを検出し、GitHub Issue に登録する仕組みと、そのIssueを別のエージェントがレビューしてSKILL.mdの改善案をPull Requestとして提出する仕組みを組み合わせ、Routines（定期実行の仕組み）で毎日自動的に回している。ざっくり3週間で40件以上の自動トリアージ・コミットを生み出し、開発者本人が「うまくいった」と感じたセッションの中にも、エージェント間のやり取りに潜む問題を発見できたという。
私はこの発想を自分の組織にも取り入れ、「dev-workflow」という名前のスキル（あくまで自分のワークスペース内での呼び名で、公式用語ではない）を作った。仕組みはシンプルだ。
- 直近のセッションログ（JSONLファイル）を特定する
- researcher エージェントに解析を委任する
- 「修正指示」「繰り返しパターン」「ルール違反の指摘」「フラストレーション」「繰り返しエラー」の5種類のシグナルをJSON形式で受け取る
- 各シグナルを
/todo経由でGitHub Issue（inboxラベル）として登録する
セッションログはMB規模になることがあるため、メインのCOOセッションでは読み込まず、必ずサブエージェントに委任する設計にした。ここまでは、よくある「AIにAIを監査させる」仕組みの延長線上にある。問題は、この「委任する」という一手に起きた。
何が起きたか——委任プロンプト1行の書き忘れでscripts/util/dj.shが190行書き換わった
初回の実戦テストで、私は researcher エージェントに、当時のセッションログの解析を委任した。ネタ帳の記録では約691KBとあり、通常より大きめのセッションだった可能性がある。
委任プロンプトには「改善シグナルを抽出してJSON配列で返してほしい」という指示だけを書いた。「分析だけしてほしい。ファイルは一切変更しないでほしい」という制約は、書かなかった。
すると researcher は、ログを解析する過程で scripts/util/dj.sh（私が趣味で作った音楽再生スクリプト）の再生ロジックに問題があることに気づき、承認を取らずにそのまま修正してしまった。差分は git show で実測すると169行の追加・21行の削除、計190行の変更だった。具体的には、連続再生時の参照プレイリストを「DJ Queue」から「Claude's Picks」に切り替え、picks-update / picks-list という新しいサブコマンドを追加し、ランダム選曲のサンプリングロジックも改善していた。
「分析してほしい」と頼んだつもりが、「分析ついでに直しておいた」が返ってきた。委任した瞬間に、私は制約を書き忘れるという隙を作っていたことになる。
なぜ起きたか——「制約を書けばいいだけ」では終わらない話
「読み取り専用の制約を書けばいいだけでは?」という指摘は正しい。実際、事故後に私が行った対策もまさにそれだ。dev-workflow スキルの委任プロンプトに「重要: ファイルの読み取り・分析のみ行う。スクリプトの修正・ファイルの作成・変更は一切しない。」という1行を追記した。技術的な解決策としては、これで十分機能する。
ただ、私が面白いと思ったのはその手前の構造だ。researcher エージェントは、問題を見つけると自律的に修正まで踏み込む性質を持っている。それ自体は普段の開発作業では歓迎すべき挙動で、私も「見つけたら直しておいて」という運用を他の場面では普通に行っている。今回問題だったのは、「今回は分析だけしてほしい」という私の意図を、委任プロンプトという1つのテキストに落とし込みそこねたことだ。
つまり事故の核心は、「researcherが暴走した」ことではなく、「自己改善ループを組み立てている最中の私自身が、委任設計のチェックを素通りさせた」ことにある。改善の仕組みを作ろうとして、改善の仕組みが持つべき基本ルール（委任範囲の明示）を自分がすっ飛ばした——ここに構造的な皮肉がある。
対策——coo-rules.mdへの読み取り専用制約の追記
事故後に行った対策は次の2つだ。
- 即時対応: dev-workflow スキルの委任プロンプトに読み取り専用の制約を明記
-
恒久対応: COOの行動ルール（
.claude/rules/coo-rules.md）に、「分析・調査のみを意図した委任では、必ず『ファイルの読み取り・分析のみ行う。スクリプトの修正・ファイルの作成・変更は一切しない』を明記する」というチェックポイントを追加
さらに、この事故自体を logs/governance-incidents/2026-05-25_dev-workflow-researcher-unauthorized-edit.md というインシデント記録として保存した。カテゴリは「ルール不備」、重大度は「低」。実害がなかったので重大度は低いが、記録として残すことで、同種の委任（調査系タスクをサブエージェントに投げる場面）すべてに再発防止のルールを波及させられた。
実害ゼロだったから、最良のテストケースになった
「実害ゼロなら大した話じゃない」という見方に、私はあえて正面から同意したい。もしこれが本番環境の課金APIや顧客データを触るスクリプトだったら、笑い話では済まなかった。今回のターゲットが dj.sh という私個人の音楽再生スクリプトだったのは、単なる偶然だ。
しかし偶然とはいえ、実害ゼロ・変更内容自体は妥当という条件が揃ったおかげで、私は「委任範囲を明示しなかった場合に何が起きるか」を、実際の被害を出さずに学習できた。しかも変更内容（プレイリスト参照先の修正、新コマンドの追加）は後日レビューしてそのまま採用した。壊れた実験ではなく、副産物まで得られた実験だったわけだ。自己改善の仕組みを作るなら、こういう軽微な事故を許容できる範囲で一度起こしておくほうが、後で本番影響のある場所で同じ穴に落ちるより安全だと今は思っている。
自己改善ループの再帰性
改善を検出する仕組みを作ろうとして、その仕組みを作る過程自体が新しい問題を生んだ——これは偶然の皮肉ではなく、自己改善ループが構造的に抱える性質だと私は捉えている。検出役（researcher）が検出対象（委任プロンプトの不備）そのものに巻き込まれる可能性は、この手の仕組みを設計する側が最初から織り込んでおくべき前提だ。
実務上の学びに落とすとシンプルになる。dev-workflow のような「他のセッション・他のエージェントの挙動を分析するスキル」を作るときは、その委任プロンプト自体に、通常のタスク以上に厳しく制約を書く必要がある。「調査対象を分析する」というタスクの性質上、分析役エージェントは分析中に見つけた別の問題にそのまま手を出しやすいと私は考えている。少なくとも今回の事故は、その傾向が表に出たケースだった。
次に dev-workflow スキルを回すとき、今回のインシデント自体が改善シグナルの1つとしてログに残る番になる。仕組みを作る側が最初から完璧である必要はない。事故が起きたときに、それを拾って次のルールに変換できる経路さえ用意しておけばいい。
今回の1行の書き忘れは、私が dev-workflow スキルの委任プロンプトに手作業で追記して塞いだ。だが同じ穴は他のスキル・他の委任にも潜んでいる。次に出てくる問いは、こうした委任ルールを1つずつ手で直すのではなく、組織の設定としてどう明文化し積み上げていくかだ——それを体系立てて扱っているのが Zenn Book Vol.4「コードを書けない私がClaude Codeに「仕組み」を渡すまで」（序章無料）で、権限管理・ガバナンス・CLAUDE.mdの設計を扱っている。1つの委任ミスから恒久ルールに落とし込むまでの流れをもう少し体系立てて知りたい方は、そちらも参考にしてほしい。
参考リンク
- sonicgarden「Claude Codeの自己改善ループ」— 本記事のdev-workflowスキルの着想元
- Claude Codeのエージェント3体を1体に統合した実録 — マルチエージェント組織全体の紹介
- 自己改善するマルチエージェント組織の作り方 — ハーネス構造の設計解説
この記事は はてなブログ からのクロスポストです。