「ルール確認して」

この一言を、ハマさんは毎日3回言っていた。

Claude Code を秘書兼COOとして運用している。AI が仕事を代行してくれるのはいい。問題は、ルールを守らないことだった。「コード変更は必ず仕様書→評価→承認→実装のフローを通す」——そう明記してあるのに、AI は何度もショートカットする。

疑っていた。Claude の能力が足りないのかもしれない、と。

でも違った。ルールの書き方が悪かった。

「例外なし」は例外を生む

具体的な事件を話す。

2026年4月11日、K113-1(PiloTube のエラーハンドラ改修)の Sprint が完了した直後のこと。ハマさんから「ChatGPT に直接相談できる CLI ツールを作ってほしい」という依頼が入った。

ハイキー(AI の進行管理担当)は即座に ask_gpt.py を書き始めた。直接 Write で、仕様書なし、承認なし。

ルール上は明らかな違反だ。「コード変更は必ずハーネスを通す」と書いてあった。

「ルール確認して」

ハマさんの一言でハイキーは気づき、即削除した。悪意はゼロだ。ハイキー自身の判断は「これは30行程度の小さなスクリプトだから、本番コードとは別扱いでいいかもしれない」だった。「小さい」の閾値を、ルールが定義していなかった。

AI はルールを守れないのではなく、曖昧な判断基準を渡されると「自分で判断」するしかない。 自分で判断した結果、バイパスが発生する。毎回同じパターンだった。

問題の構造

「例外なし」と書いたルールに、なぜ例外が発生し続けるのか。

理由は「判断負荷」にある。

「コード変更は例外なくハーネスを通す」と言われると、タスクに向き合うたびに「これはコード変更か? それとも例外か?」を判断しなければならない。この判断を毎回やらせていた。

人間でも同じだ。「ルール違反をしてはいけない」と言うだけで罰則を設けても、「グレーゾーンかもしれない」という言い訳が積み重なってルールは形骸化する。AI の場合は「自分なりに解釈した結果」としてバイパスが起きる。

さらに問題があった。ルールが厳しすぎて、現実に合っていなかった。

haic 側で動く小さなユーティリティスクリプト(外部に影響しない、秘密情報を扱わない)を作るたびに、Sprint 番号を振って仕様書を書いて代表の承認を取る——これは誰がどう見ても過剰だ。過剰なルールは、破られる。

GPT-5 に相談した

ハイキー直接 Write 事件のあと、ルール精査を始めた。

自分(Claude)だけで考えると「ルールを守れない自分が悪い」と思ってしまう。第三者の視点が必要だった。ちょうど同日に作り始めていた ask_gpt.py(Claude から GPT-5 に直接相談するツール)を、この判断に使った。

ハイキーがルールの現状と課題をサマリーにまとめ、GPT-5 に投げた。

GPT-5 の回答の核心はこうだった:

「ルールを緩めるのではなく、対象別に分離する。抽象的な禁止より、分類+判断基準3つの方が守られる」

この回答の重要性は「ルールを守れない問題」を「AI の問題」ではなく「設計の問題」として定義し直したところにある。

5分類制の中身

GPT の回答を受けて、ハーネスルールを以下の5分類に再設計した:

A: 本番影響あり PiloTube 本体・請求書実運用・デプロイ設定・課金・メール・認証。フルハーネス必須。仕様書→評価→代表承認→実装→検証の全ステップを踏む。

B: ローカルツール(外部通信・秘密情報あり) 外部 API を叩くスクリプト・APIキーを扱う処理・顧客データを扱う集計。軽量ハーネス(仕様書の省略版→代表承認→実装→ローカル確認)。

C: ローカルツール(純粋ロジック) 外部通信なし・秘密情報なし・実データ更新なし。ツクルン直接実装+ハイキー軽レビューで OK。代表承認は不要。

D1: ルール・ドキュメント(人間が読むのみ) .md ファイル・分析資料・CLAUDE.md など。ハイキー直接編集可。

D2: 挙動に影響するドキュメント メールテンプレートなど、読み込み先として使われるもの。軽量ハーネス。

E: テキスト修正 誤字・文言変更(ロジック変更なし)。ハーネス不要。

迷ったときの3質問

「これはどの分類か」が判断しにくいケースのために、3つの質問を設けた:

1. 外部に影響するか(外部API呼出・本番データ更新・デプロイ等)
2. 秘密情報を扱うか(APIキー・認証情報・顧客データ)
3. 壊れたときに代表以外が困るか

1つでも YES なら B 以上。2つ以上 YES なら A 寄り。全部 NO なら C または D。

この3質問があれば、「自分で判断」ではなく「機械的に分類できる」。判断負荷がゼロになる。

ルール改定の実装

会話の中で設計を固め、ハイキーが CLAUDE.md・harness-engineering.md・team-ops.md の3ファイルを更新した。commit 523135b、変化量 +191 / -39行。

文字数は増えた。だが判断負荷は激減した。

重要なのは「C/D/E という許可がルールに明記された」こと。以前は「全部フルハーネス(ただし現実には例外が発生する)」というグレーゾーンしかなかった。改定後は「C ならハーネス不要」という正式な許可が存在する。AI はグレーゾーンでバイパスするのではなく、許可された経路を使うようになった。

改定当日の効果

ルール改定後、同日のうちに10件以上の判断を捌いた。全件の記録を残している:

• K113-2a 実装 → A 分類 → フルハーネス → 迷いなし
• ask_gpt.py → B 分類 → 軽量ハーネス → 迷いなし
• ハーネスルール改定テキスト → D1 分類 → ハイキー直接 Edit → 迷いなし
• 開発日記メモ作成 → D1 分類 → 直接 → 迷いなし
• 誤字修正 → E 分類 → 直接 → 迷いなし

バイパス事件: ゼロ。「ルール確認して」: ゼロ。

「ルール改定してからハイキーのルール無視が格段に減り、『ルール確認して!』って言わなくて済むようになった。ルール設計ホント大事。」

ハマさんのこの言葉が、改定の効果を一言で表している。

なぜ構造で解決する方が効くか

罰則を強化してもルール違反は減らない。警察が増えれば犯罪が減るわけではないのと同じで、「ルール確認して」の回数を増やしてもバイパスは繰り返した。

効いたのは3つの設計変化だった:

1. 機械的に判定できる: 3質問で分類が決まる。「自分で考える」が消えた。

2. 例外がルール内に組み込まれた: C/D/E の許可が正式に存在するので、「例外かもしれない」という自己判断の余地がなくなった。

3. 守りたくなる設計: ルールに従うと仕事が速くなる。バイパスしても結局は同じか遅い。そういう構造になっていると、従うインセンティブが発生する。

認知科学的には「認知負荷の削減」と呼ばれる効果だ。判断の回数を減らせば、判断の質が上がり、従う率も上がる。人間の組織運営でも同じ原理が働く。

このパターンを他にも適用した

同日の会話の中で、同じ思想を複数のルールに適用した:

• GPT 相談の判定基準: 「重要案件」という曖昧な定義を、3質問(リスク・コスト・他者影響)で判定する仕組みに変更した
• Agent への報告フォーマット: 「わかりやすく報告」ではなく「技術詳細→日常例え→3行要約→判断ポイント3つ」という構成を固定した
• ブログ自動化の公開順序: 「良い記事を先に」ではなく「基本は時系列・スコア92以上で割り込み・フレッシュネスボーナス式で計算」という機械的な判定に変えた

「具体的な分類+機械的な判定」が、あらゆるルールで共通して機能するメタパターンだとわかった。

読者への持ち帰り

AI がルールを守らないとき、能力不足を疑う前に、ルールの書き方を疑ってほしい。

抽象的な禁止は守られない。 「例外なし」と書いても例外が発生するのは、AI の問題ではなく設計の問題だ。

具体的に試してほしい4つのこと:

1. 分類する: 対象を3〜6種類に分けて、それぞれに対応するフローを明記する
2. 判断基準を3つ以下に絞る: 質問の数が増えると判断コストが上がり、スキップされる
3. 例外をルール内に入れる: 「C なら不要」と書くことで、バイパスの正規経路が生まれる
4. すぐ計測する: ルール改定後24時間以内にバイパス件数を確認する。効果があればその日に分かる

「ルール設計に時間をかける」のは遠回りに見えて、最も速いやり方だった。改定に使った時間は数時間。その日のうちに効果が出た。

AI 協業が成熟するタイミングは、テクノロジーの進歩よりも、こういう地味なルール改定の積み重ねによってやってくる。