ルールは既定であって上限ではない — AI の素の能力を縛らない運用

Claude Code と一緒に開発しながら、失敗のたびに運用ルールやメモを増やしてきました。ルールが溜まってきた頃、ふとこういう心配が湧きました。

Claude Code の素の能力は徐々に上がり続けているので、あまりそこを縛るようなルールをつけたくないと思っています。いまは Fable 5.1 になっています (少し前まで Fable 自体がなく、そのあと Fable 5 ができました)。そういう変遷もあるので、せっかく素の能力が上がっても、考えを制限したり方法を指示したりすると、その能力を活かしきれなくならないか、という心配です。

この心配を Claude Code 本人にぶつけたところ、返ってきた整理が腑に落ちたので、そのまま採用しました。以下は Claude Code の回答の要約です。

ルールには3種類あって、危険度が違う。

• ①好み・価値観・世界の住所録 — 例:「誇張した表現を使わない」。モデルがどれだけ賢くなっても自力では知り得ない情報で、賢いモデルほど上手に活かせる。恒久的に残してよい
• ②事故から生まれた工程の縛り — 例:「たくさんのファイルを直す時は、まず1件だけ直して確認してから全体へ」。半分は安全への好み、半分は過去のモデルの弱点へのパッチ
• ③方法の指定 — 例:「案は2〜3個に絞って出す」。ここが一番危険で、より良い方法を思いつける能力があっても、指定があると従ってしまう

対策は2つ。

その1: 「方法の指定は既定であって上限ではない」を大原則にする。 より良いやり方があると判断したら、黙って従わず・黙って破らず、逸脱案を添えて提案してよい — この一文を全セッション共通ルールの冒頭に置きました。これで方法系のルール全体が「縛り」から「たたき台」に変わります。無断では破らせないので、安全性は保たれます。

その2: モデルの世代が変わったらルールの棚卸しをする。 方法を縛る系のルール (見積りの補正倍率、工程の指定など) を数件ずつ試験的に外して、素の挙動と比較してから消すか残すかを決める。過去モデルへのパッチを、新しいモデルに引きずらないためです。

これを支えるのが、ルールに必ず理由 (Why) を書いておくことでした。理由つきのルールは、賢くなったモデルが「この理由はもう成立していない」と自分で判定できる — つまり自然に賞味期限が切れます。理由のないルールだけが檻になる、というのが Claude Code の弁です。