ルールを守らせる手段は散文・手続き・機械の 3 種しかない。mixednuts はこれを L1〜L6 の 6 レベルに割り当て、同種の失敗が累計 2 件か実害 100 ドル超の類型を、警告型（L4）か実行前ブロック型（L6）へ上げる。ルール文書自体の書き換えは CEO 同意ゲートの対象とし、同意が取れない時間帯は編集せずキューに積む。
書いたルールが守られないとき、何を変えるのか？
ルールを守らせる手段は散文・手続き・機械の 3 種しかなく、当社はこれを L1〜L6 の 6 レベルに割り当てている（業界標準ではなく当社独自の分類）。手順は、既存ルールにレベルを付ける → 同種の失敗が累計 2 件になるか実害が 100 ドルを超えた類型を抜き出す → 注意喚起で足りるものは L4、不可逆な操作は L6 に上げる、の 3 段階。例外は、誤検知の実害が違反の実害を上回る領域で、そこは機械化しない。
| レベル | 強制手段 | 誰が・いつ | 何をする | 違反したとき |
|---|---|---|---|---|
| L1 | 散文 | 担当者が必要と判断時 | 該当文書を読みに行く | 気づかなければ何も起きない |
| L2 | 散文 | 全セッション起動時 | 常時読み込む文書 | 「今回は例外」の解釈余地 |
| L3 | 手続き | 成果物の提出時 | 定型項目の記入を必須 | 記入漏れとして事後に分かる |
| L4 | 機械（警告型） | 作業の節目に自動で | 警告文を差し込む | 警告は出るが作業は続行できる |
| L5 | 手続き＋第三者 | 成果物ができた後 | 別エージェントが批評 | 見落とせば差し戻しは起きない |
| L6 | 機械（遮断型） | 操作の実行直前 | 中身を解析して合否 | 実行前にブロックされ続行不能 |
強制手段は散文（L1・L2）・手続き（L3・L5）・機械（L4・L6）の 3 種で、L1〜L6 はこれを「実行までに何へ依存するか」で並べた当社独自の 6 段階だ（外部標準ではない）。番号は強さの一列でもなく、L5 は機械が判定できない意味の誤りを捕まえる網であって、L4 より必ず強いとは限らない。
散文は解釈され、機械は実行される
2026 年 7 月、自社の運用ルール文書 85 本（常時ロード 10 / 領域別 21 / 失敗から書き起こした学習メモ 54）に上表のレベルを付けて棚卸しした集計日 2026-07-27、分類は社内で実施[1]。機械的な強制（L4 以上）が紐づいていたのは 5 本。実害や再発を記録した学習ほど、読むかどうかがセッション側の自己判断に委ねられる L1 にあった。実行されない構造の主因は、ルールの不足ではなく強制手段の偏りだった。
L4 と L6 は何が違うのか？ — 警告で済む層と、実行前に止まる層
外形はどちらも「作業の節目に自動で走るプログラム（開発現場では hook と呼ぶ。以下、作業節目の自動介入）」で、実装を見ても区別がつかない。区別は挙動で定義する。L4 は警告を出したうえで作業を続行させる。L6 は実行前に止め、その操作を続行させない。 判定を製品非依存の擬似コードで書くと次の十数行になる。
# 作業節目の自動介入：L4（警告型）と L6（遮断型）の分岐
on_before_action(action, context):
rule = match_rule(action) # 監視対象の操作か
if rule is None: return ALLOW
if context.approval_token in rule.approved_exceptions:
log(action, rule, "approved") # 例外承認は必ず記録して通す
return ALLOW
if rule.level >= 6:
log(action, rule, "blocked")
return BLOCK(rule.message) # 非ゼロ終了。操作は実行されない
if rule.level >= 4:
log(action, rule, "warned")
notify(rule.message) # 警告のみ。作業は続行される
return ALLOW要点は 3 つ。例外承認の経路を最初から設ける（抜け道のない遮断は、正当な操作を止めた瞬間に判定ごと外される）。警告も遮断も監査ログに残す（L4 の警告回数が、L6 へ上げるべきかの唯一の観測値になる）。判定は操作の中身を解析する（文字列パターンで書くと、引数の順序を変えた同型の操作が素通りする）。当社は遮断型に迂回パターンを含む回帰テストを 15 ケース持たせている。
いつ散文から機械へ上げるのか？ — 判定式と「2 件」の数え方
機械化には実装コストがあり、誤検知（本来許可すべき操作を止める）が別の形で業務を止める。そこで昇格の起点を式で決めている。同一類型の事象が累計 2 件に達した場合、または単一事象の実害が 100 ドル（当社の基準値）を超えた場合、その類型を L4 以上への昇格候補として起票する。
数え方を定義しないと、同じ事故が毎回「初回」として処理される。
- 1 件: 実害（金額・手戻り時間・対外影響）が出たか、CEO の差し戻しが入った事象。未然に止めたヒヤリハットは数えない。
- 累計 2 件: 初回を含めて 2 件（初回 + 再発 1 回）。「2 回再発してから」ではない。
- 同種: 同じ条項に紐づき、かつ同じ経路で起きたもの。経路が違えば有効な手段も違うため別類型として数え直す。
- 窓: 棚卸しの単位である四半期に合わせる。
昇格先は一律にしない。警告で止まらない類型に警告を積んでも実効性は上がらないためだ。実害が不可逆なもの（消失・送金・対外送信・漏洩）は L6、気づけば直せる可逆な失敗は L4、機械では測れない意味・論理の誤りは L5 を既定とし、誤検知の実害が違反の実害を上回る領域は昇格させない。
起票は式が起こすが、実装は自動ではない。どのレベルにどう実装するかは後述の同意ゲートを通る。自動昇格にすると、エージェントが自分への制約を自分で設計する経路が開く。
観測できた範囲では、実行モデルの指定漏れによるコスト超過と、破壊的なバージョン管理操作の 2 類型が、散文への明記だけでは再発し、機械層へ上げた後は観測期間中に同じ経路での再発が確認されていないn=2、観測期間 2026-07〜2026-08、金額は非公開[2]。因果の証明ではないが、並びは両類型で一致した。
ルール自体を書き換える権限は誰が持つか？ — 承認者が 1 人であることの弱点
ルールの機械ゲート化をエージェントが自己判断で行えるなら、自分への制約を自分で緩める経路が同時に開く。当社は行動規範を定義する文書群（ルール層）の書き換えを、金銭操作や破壊的操作と同格の CEO 明示同意ゲートの対象にした。提案は結論・差分・理由・影響範囲の 4 点で示し、同意を得てから編集する。夜間や自律実行の時間帯は編集せず、承認待ちとして積む。
承認者が 1 人であることは、統制の強さと引き換えに単一障害点をつくる。補完は 3 つ置いている。
- 不在時は編集しない。 人間が 1 人の組織では代理承認が実質的に無承認と同じになるため、キューに積んで止める設計にした。複数人の組織なら、代理承認者と二者承認に置き換えるのが本来の形になる。
- 同意の出典を記録に残す。 承認はチャットで交わされ記録に残らない。変更記録には同意の出典を 1 行必ず書く。これが無いと、事後監査で「同意済みだが未記載」と「無承認」を区別できない。
- 承認とは別経路で事後に読む。 承認者が遵守も検査する構造では誤承認が検出されない。作業から独立した監督を日次で走らせ、差分と成果物を別の文脈で読み直し、違反・ルールの欠落・ルール自体の不良の 3 分類で決裁へ戻す。
FAQ
Q. エージェントが遮断（L6）を迂回した場合はどうなるか？ A. 迂回は起きる前提で設計している。判定を文字列パターンで書くと、引数の順序を変えた同型の操作が通る。対策は、操作の中身を解析して判定すること、迂回パターンを回帰テストに入れること、通過した操作も監査ログに残して事後に突合できることの 3 点になる。
Q. 自動介入の仕組み自体が壊れたらどう検知するのか？ A. 沈黙した遮断型は正常時と外形が同じで、最も危険な故障になる。発火自体を確認するテストを実装側に持たせ、別経路の監督が定期的に成果物を読む二重化にしている。原則は「壊れたら止める」側に倒すが、業務が全面停止する領域では、通したうえで警告を最大化する判断もありうる。
Q. 誤って承認してしまった変更はどう戻すのか？ A. 1 変更 = 1 コミットの粒度を守り、単独で巻き戻せる状態を保つ。変更した文書の冒頭に改訂の日付・理由・根拠を残し、承認の出典を変更記録に 1 行入れる。誤承認は防ぐより、短時間で検出して戻す設計にしている。
Q. 承認者が承認疲れを起こして中身を見なくなるのでは？ A. 起きるリスクとして扱っている。緩和は、提示単位を最小の差分に絞ること、影響範囲の一覧を提案側に必ず添えさせること、承認対象をルール層に限定し通常の実装へ広げないことの 3 点。承認対象が増えるほど 1 件あたりの審査は薄くなる。
Q. 最初のレベルは誰が付けるのか？ 見立てを誤ったらどうなるか？ A. 初回はルールを書いた側が付け、四半期の棚卸しで見直す。低く見積もれば再発が起きて判定式が起票するため事後に補正され、高く見積もれば誤検知で業務が止まり即座に発覚する。誤りの方向で検出までの時間が違う点を前提にしておくとよい。
参考文献 / Sources
mixednuts 社内実測（観測期間 2026-07〜2026-08）:
- 強制レベルの棚卸し[1] — 対象 85 本、集計日 2026-07-27。内訳と定義は本文に同じ
- 再発事例の観測ログ[2] — 2 類型（n=2）。金額は非公開
- 昇格第 1 陣の実装記録 — L4 / L5 / L6 へ上げた 6 件、遮断型の回帰テスト 15 ケース
公開資料:
- Claude Code Hooks reference — 作業節目の自動介入の仕様（終了コードによる警告と遮断の区別）
関連記事（委任設計 → ルール強制 → 成果物チェックの 3 部作）:
- AI エージェントの役割重複を減らす方法 — 委任表による 105 体 → 40 体の再編 — 誰に任せるかを一意に決める委任設計
- コンサル資料の『型』を官公庁 28 本から抽出する方法 — スライド文法 10 条と自動体裁チェック 3 項目 — 成果物の体裁を自動体裁チェック（lint）へ移す設計
知見を、事業の実装へ。
60分の無料相談で、貴社に適した論点と次の一手を整理します。