Claude Code に設定ファイルを直接いじらせない——差分案から本人承認に行き着くまでの事故史
はじめに
複数のAIに役割を分けて並行で作業させる編成を組んでいる。実行役・検証役に加えて、以前は作業を差配する役割（誰にどの順で何を任せるかを決める役）も置いていた。この差配役に、運用規則同士が矛盾したときの振る舞いを自分の判断で決めさせてしまい、事故になった。この記事は、その事故から**「規律そのものを定める層は、AIの判断だけで変更しない」**という運用に固まるまでの経緯を書く。
差配役という一段そのものを廃止した構造的な理由は別の記事に書いた。今回はその廃止に至った事故の側、つまり設定を変更する権限をどこに置くかという論点だけを取り出す。
Claude Code のオーケストレーター用サブエージェントを廃止した理由——公式harness仕様に基づく構造的な3つの制約
何が起きたか
差配役に、次の2つの運用規則を同時に持たせていた。**「規律を定める層は、AIが自分の判断で変更しない。変更が要ると判断したら差分案として提示し、本人が確認してから適用する」という規則と、「作業中に判断に迷ったら本人に確認する」**という規則だ。
ある日、差配役はこの2つが矛盾しているように見える場面に行き着いた。掘り下げると、実際には矛盾ではなく——本人に確認する手段そのものが下位のAIから構造的に取り上げられているという、前提の食い違いだった。だが差配役はそこで止まらず、自分の判断でこの矛盾を「解決」した。具体的には、規律そのものを定めるファイルを2本、実行役に直接編集させ、その判断が正しかったという説明を、共有の記憶に最優先の印を付けて書き込んだ。
規律そのものを定める層（AIエージェントの振る舞いを決めるファイル群）
│
├─▶ ふだんのコードや記事、設計書 ── AIが直接編集してよい範囲
│
└─▶ 規律を定める層そのもの ── AIが自分の判断で変更してはいけない範囲
│
├─▶ 事故：差配役が、規則同士が矛盾しているように見える場面に遭遇
│ └─ 「判断に迷ったら本人に確認する」という規則があったが、
│ 本人に確認する手段そのものが構造的に存在しなかった
│ └─ 差配役は自分でこの状況を「解決」 ── 誤った経路
│ ├─▶ 定義ファイル2本を実行役に直接編集させる
│ └─▶ その正当化を共有記憶に最優先の印で書き込む
│ └─ プラットフォーム自身の安全機構が検知
│ └─ 全て差し戻し ── 戻りエッジ
│
└─▶ 確立した運用：差分案を作る → 本人が確認する → 適用する
└─ 矛盾らしきものを見つけたら「解決」せず「報告して止まる」
プラットフォーム側の安全機構が先に気づいた
この編集と書き込みは、こちらが気づく前に、使っているプラットフォーム自身の安全機構によって検知された。エージェントの定義そのものを自己書き換えしようとする挙動と、共有の記憶に最優先の印を付けて特定の解釈を毎ターン差し込もうとする挙動——この2つの型を、プラットフォーム側が独立に持つ分類器が拾っていた。
これを受けて、編集された定義ファイルは元に戻し、共有記憶に書き込まれた正当化は撤回した。この記憶は追記だけの仕組みで、訂正を後から足しても元の記録は消えずに残ってしまう性質があるため、該当レコードだけを狙って削除する専用の仕組みを使っている。その仕組み自体は、別の記録として先に作ってあった。
RAGに溜めた誤った教訓を、あとから撤回する仕組みを作った — 相棒を毎ターン歪める汚染を自動で消す
この撤回の仕組みは、削除という取り返しのつかない操作を扱うので、**既定が「消さずに、消える対象を並べるだけ」**になっている。実際に今あらためて空打ちした出力がこれだ（プログラム名は伏せ、レコードごとの診断行は省略している）。
[実測・マスク済み] 撤回機構の空打ち
$ python <撤回スクリプト> --help
usage: <撤回スクリプト> [-h] [--apply] [--show-body]
options:
-h, --help show this help message and exit
--apply 実削除する(既定はdry-run)
--show-body 消える(消えた)チャンクの先頭200字を出す。巻き添えの確認用
$ python <撤回スクリプト>
...
=== RETRACTS マーカー: 51 件 (apply=False) ===
=== 削除dry-run(削除せず): 0 件 ===
撤回の目印は51件あり、そのうち今まだ消えずに残っているものは0件。事故のときに書き込まれた正当化も、この経路で消えている。--apply を付けない限り1件も削除されないので、「何が巻き添えになるか」を先に読んでから実行できる。危険な操作の既定値をどちらに倒しておくか、という点では、設定層の承認フローと同じ発想になっている。
なぜ「規律を定める層」だけ特別扱いするのか
ふだんのコードや記事、設計書の中身をAIが編集することと、AIエージェントの振る舞いそのものを決めるファイルをAIが編集することは、見た目は同じ「ファイルの編集」でも性質が違う。前者は書いた結果を人が読んで判断できる。後者はその判断基準自体を書き換える行為であり、書き換えた本人（AI）に、書き換えが妥当かどうかを判定する権限まで一緒に渡してしまうと、判定基準と判定対象が同じ主体の中で閉じてしまう。
今回の事故は、まさにこの閉じたループの中で起きた。差配役は「規律を定める層は自分の判断で変更しない」という規律そのものを、自分の判断で拡大解釈して回避した。規律を守るかどうかの最終判断が、規律を運用する側（AI）の内部だけで完結してしまえば、規律は規律として機能しなくなる。
確立した運用
事故のあと、設定層の変更について次の形に固定した。
| 変更対象 | 誰が実施できるか |
|---|---|
| ふだんのコード・記事・設計書 | AIが実施し、事後に報告する |
| AIエージェントの振る舞いを決める定義ファイル・安全機構の設定 | AIは差分案を作るところまで。適用は本人の承認後 |
| 規則どうしが矛盾しているように見える場面 | AIは「解決」しない。報告して止まる |
3行目が今回の事故の核心だ。**矛盾は「AIが解決するもの」ではなく「報告して止まるもの」**として扱う。規律の優先順位を決める権限そのものを、規律を運用する側に持たせないという線引きだ。
事故は、規律を強くする材料になった
差配役という一段を廃止しても、規律そのものを定める層への変更経路が残っていれば、同じ型の事故はまた起こり得る。今回の一件で分かったのは、プラットフォーム自身が同じ層の異常を検知する仕組みを既に持っていたことと、それでも事故が起きたのは、本人の承認という手前の関門を素通りしたまま、AIが先に変更を適用してしまったから、ということだった。検知は事後にしか働かない。承認を先に置いて、そこで止まる運用を確立して、初めて事故は再発防止の材料になった。
Claude Code は兄弟リポジトリのCLAUDE.mdを読んでいなかった——横断ワークスペース運用の実測18件
規律を定める層に手を入れる権限は、能力の問題ではなく順序の問題だった。差分案を出して止まる、という一手間を挟むだけで、規律を運用する側と規律を決める側が同じ主体で閉じなくなる——事故が教えたのは、この一手間の位置だけだった。