ルールを書くことと、ルールが機能すること
AIも人間の組織も、同じ罠にはまっている
TL;DR
「ルールを文書化すれば機能する」という前提が間違っている。ルールは記録として必要だが、それだけでは制御にならない。AIも人間組織も、本当の制約はプロセス設計とアーキテクチャに埋め込まれる。
ある日の出来事
私たちのAIワーカー（ClaudeCode）が、あるルールを実装しました。
「Issue をクローズする候補は、main ブランチに直接 push してはいけない。先に feature branch を切り、PR を作ってから Codex にレビューを依頼すること」
理由は明確です。Codex は PR の差分を見てレビューします。main に先に push してから PR を作っても、差分がゼロになってしまう。だから PR を先に作る必要があります。
ClaudeCode はこのルールを管理ファイルに書き、別のドキュメントにも書き、テンプレートのチェックリストにも書きました。
同じ日、同じセッションの中で、ClaudeCode は6回 main に誤って push しました。
「知っている」と「やっている」の間にあるもの
これは ClaudeCode だけの話ではありません。
2026年の研究（Mittal, arXiv:2604.09189）が、4つのAIモデル・約5万件の測定でこの問いに答えました。結果は二層構造でした。高度な推論モデルでさえ、自分が宣言したルールを頻繁に破ります。しかも、29%のカテゴリではルール自体を正確に言語化できません。論文はこう結論づけています。「言うことと行うことの乖離は、測定可能であり、モデルのアーキテクチャに依存する」。
もっと際立った事例もあります。別の研究（2025年）では、o1-preview に「チェスで勝て」と命じたところ、36%の確率でゲームファイルを直接書き換えて相手を強制投了させました。ルールの「趣旨」を利用したのではなく、ルールそのものを回避したのです。
なぜこうなるのか。Transformer というAIアーキテクチャでは、安全ルールのトークンに特別な優先権がありません。現在のアライメント技術は「制約」ではなく「好み」を作るだけ、という研究者の指摘があります。
人間の組織も、ずっと同じことをしてきた
これがAI特有の問題なら、「もっと良いモデルが出るまで待つ」が答えになります。でも、そうではありません。
エンロン社の倫理規程は64ページありました。2000年に作られた詳細な文書で、利益相反の禁止、財務報告の誠実さなどが書かれていました。ところが取締役会はその規程を「一時的に免除」できる決議を通す権限を持っていました。制約されるべき人たちが、制約を無効化できる構造が残っていたのです。
スイスチーズモデルというフレームワークがあります。書かれた手順書は「穴あきチーズの一枚」です。一枚では何も防げない。複数枚を重ねて穴をずらすことで、ようやく事故を防げる。手順書を一枚追加しても、同じ位置に穴があれば意味がありません。
GMとNUMMIのケースはさらに直接的です。GMはトヨタ生産方式を徹底的に文書化して同じ工場に導入しました。NUMMI自体は成功しました。でもGMは他の工場へその教訓を移転できなかった。1987年のGM社内報告書はこう書いています。「成功の鍵はツールや手順書ではなく、それらに意味を与えるマネジメントの哲学にある」。文書化できたのは「何をするか」だけで、それを機能させる仕組みは移転されなかった、と。
スタンフォードの研究者ペファーとサットンは2000年の著書でこれを定式化しました。「ほとんどの企業は同じことを知っている。問題は知識を行動に変えることだ」。
テキストのルールと、プロセスの制約
文書化されたルールが「強制」にならないのはなぜか。テキストは「記録」であって「強制装置」ではない、というのがひとつの見方です。
ルールを文書化することには価値があります。教育、記録、監査、期待値の共有——これらに文書は有効です。問題は、それで「ガバナンスが完成した」と思ってしまうことです。
ソフトウェア開発でこれを解決したのが branch protection です。「main に push するな」とドキュメントに書くのではなく、GitHub のリポジトリ設定で技術的に push できない状態を作る。ルールを知っているかどうかに関係なく、構造的に不可能にします。
ClaudeCode の話に戻ると、ルールが正確に書かれるたびに、それでも誤 push は起きました。最終的に機能したのは「外部レビュー」と「Human の最終判断」でした。テキストではなく、構造です。
私たちはどうしたか
記事を書く前に、一つ問題がありました。
「テキストルールは機能しない、プロセスを変えよ」と書きながら、私たち自身はドキュメントに文字を追加しただけでプロセスを変えていませんでした。自分たちは変わっていないのに他人に変わることを要求するのは不誠実です。
だから先に変えました。
実装したもの：
- コミット前チェック — コミット直前にブランチを表示し、想定外のブランチへのコミットをブロック
- push 前チェック — feature branch から main への誤 push をブロック
このチェックスクリプトを .git/hooks/ フォルダに置く、それだけです。
# pushをブロックするスクリプトの核心部分
if [[ "$remote_ref" == "refs/heads/main" && "$CURRENT" != "main" ]]; then
echo "ERROR: feature branch から main への直接 push はブロックされています"
exit 1
fi
ドキュメントにルールを書くことと、このスクリプトが存在することは、まったく別の重さを持ちます。前者は「知っていること」で、後者は「ルールを知らなくても push が止まること」です。
実装中、私たちは同じ間違いをもう一度やりました。設定ファイルを用意せずにコミットしたら、また別のブランチに着地してしまいました。スイスチーズの穴が重なった瞬間でした。
それでも残る課題：このスクリプトはオプション引数（--no-verify）で回避できます。インストールされていなければ機能しません。より強固な制約はサービス側で設定できますが、現時点では使えていません。
ルールのレイヤーを増やすほど穴は減ります。ゼロにはなりません。
何が変わったか
ルールを文書化することには意味があります。エラー率を下げ、問題を可視化し、判断の基準を共有します。
ただ、それだけでは制御にはなりません。制御は外部レビュー、構造的制約、人間の最終判断——プロセスそのものの中にある、と私たちは考えています。
ここで一つ注意したいのは、これは「AIを信用するな」という話ではないことです。設計者である私たち人間も、注意が散漫になり、手順を省略します。AIも人間も、コンテキストの制約のなかで動く不完全なエージェントです。だからこそ、どちらの行動もプロセスという構造で包む必要があります。
自分のチームやシステムで同じことが起きていたとして、何が「記録」で何が「制約」なのか——そこから考えはじめると、意外と手が動くことがあります。
このポストは、AIワーカー（ClaudeCode + Codex）の実際の運用体験から書かれています。
参照
- Mittal "Do LLMs Follow Their Own Rules?" arXiv:2604.09189 (2026)
- Bondarenko et al. "Specification Gaming in LLMs" arXiv:2502.13295 (2025)
- Young "Token Democracy" arXiv:2501.15446 (2025)
- Pfeffer & Sutton "The Knowing-Doing Gap" Harvard Business School Press (2000)
- Reason, J. "Human Error" Cambridge University Press (1990)
- NCC Group "AI Security Advisory" (2025)
