CLAUDE.md やプロンプトに「守らせたいルール」を書き足していくと、なぜか以前より出力が雑になったり、本来書かれていたはずの「完了条件」や「前提の確認」が抜け落ちたりした経験はないでしょうか。多くの開発者が「AIに正確に動いてほしいから」とルールを足し続けますが、実はプロンプトに規則を足しすぎると、モデルが指示なしでも自発的に行っている良い振る舞いを「押しのけて」しまうことがあります。

規則の押しのけ（Prompt Rule Displacement）とは、プロンプトに明示的な制約や指示を過剰に追加した結果、LLM がプロンプト指定なしの既定状態で自律的に行っていた望ましい振る舞いが出力されなくなる現象です。

本記事では、架空の引き継ぎ題材3種を固定し、「規則なし」「8規則」「2規則」の各条件で claude -p に出力させた実測ログ（計75本）をもとに、規則過多による押しのけという現象を観測します。そして、プロンプトを「あり・なし」で並べて数え、何もしなくても守られる不要なルール（no-op 規則）を削ぎ落として最小限の規則だけを選ぶ実践手順を提示します。

検証環境と調査スコープ

調査の客観性と再現性を担保するため、実行環境・使用ツール・題材の境界を以下のように設定しました。

  • 実行環境: macOS（Apple Silicon）
  • 実行 CLI / モデル: claude -p（Claude Code CLI、当時のデフォルトモデル。モデル名・CLI バージョン・実行日は、本記事の元になった記録からは特定できません。作業ディレクトリのプロジェクト設定（project / local スコープの CLAUDE.md）の有無も未確認）
  • 実行オプション: --disallowedTools 'Bash,Edit,Write,Read,WebFetch,WebSearch,Agent,Glob,Grep'（ツール実行を遮断し、純粋なテキスト生成として比較）
  • 実験の題材: 架空の引き継ぎメモ3種（A: ログイン画面エラーのチケット、B: 画像 WebP 化の Taskwarrior タスク、C: 設定ファイル整理のサブエージェント委譲文）

なお、本記事の調査スコープは「プロンプトにおける文の規則選定」に特化しています。英語の制限言語規格（ASD-STE100）自体の詳細仕様や日本語翻案の議論は本記事の対象外とし、手元の作業ディレクトリで作成した文の規則スキルを検証した一次ログに基づき分析を進めます。

プロンプト過多の病理とアテンション予算の限界

なぜルールを足しすぎると出力が崩れてしまうのでしょうか。Anthropic の公式ドキュメントや最新の学術研究から、その背景理論を整理します。

公式が警告する過剰指定アンチパターン

Anthropic の公式ドキュメント「Best practices for Claude Code」では、典型的なアンチパターンとして「The over-specified CLAUDE.md（過剰に指定された CLAUDE.md）」を挙げています。ファイルが長すぎると、重要な規則がノイズに埋もれてしまい「モデルがルールの半分を無視する（ignores half of it because important rules get lost in the noise）」と明記されています。その解決策として提示されているのは「冷徹に削る（Ruthlessly prune）」ことであり、指示なしで最初から正しく行えているなら削除すべきだと勧告されています1。

また、ドキュメント「How Claude remembers your project」では、CLAUDE.md の推奨サイズとして「1ファイルあたり200行以下（target under 200 lines per CLAUDE.md file）」を目標とすることが明記されています。200行を超えるような長いファイルは余計なコンテキストを消費するだけでなく、指示の遵守率（adherence）を低下させうると説明されています2。

アテンション予算と指示数増加による急落カーブ

Anthropic の技術記事「Effective context engineering for AI agents」では、LLM の内部挙動として「アテンション予算（attention budget）」の概念が解説されています。LLM には有限のアテンション予算が存在し、コンテキストに新しいトークンが追加されるたびに予算が消費され、想起精度が低下する「コンテキストロット（context rot）」が発生します。そのため、システムプロンプトは硬直的な if-else ルールを詰め込むのではなく、適切な高度（right altitude）で設計すべきとされています3。

指示が増えるほど守られにくくなる傾向を定量的に示したのが、東京大学の研究グループ（Keno Harada et al.）によるベンチマーク研究「ManyIFEval」です。10種類の主要 LLM を横断して評価した結果、プロンプトに与える指示の数が増えるにつれて、全指示の同時遵守率が一貫して大幅に低下することが示されています（これは「全指示の同時遵守率」の話で、本記事で見る「既定の良い振る舞いが消える」現象の直接の証拠ではありません）。論文が評価した Claude 系モデルの1つでも、指示数 n = 1 のとき 95% だった遵守率が、n = 8 で 62%、n = 10 では 48% へ急落します。コード制約ベンチマーク（StyleMBPP）に至っては、制約数 n = 6 で遵守率が 1% まで崩壊します4。

本記事では、手元で収集した出力ログを以下の2つの評価軸で検証します。

  1. 完了条件の出現: 出力テキスト内に 完了条件|完了の条件|完了とする|終わったと|Done を含む件数。
  2. no-op 規則の判別: 規則を与えなくても、モデルが自発的に満たしている不要なルールの有無。

3つの比較実験で観測された挙動と実測値

手元の環境で実施した3つの実験（計75本）の生ログから、規則過多による押しのけ、既定動作の切り分け、そして2規則への絞り込みの効果を実証します。

第1回実験: 8規則による「完了条件」の半減と no-op 規則の判別

第1回実験では、架空の題材3種（A: チケット、B: タスク、C: 委譲文）に対し、「規則なし（base: 9本）」と「8つの文の規則あり（rules: 9本）」の計18本を生成して比較しました。

その結果、規則なしの base 条件では、完了条件が 9本中9本（100%） すべてに出現していました。しかし、8規則を与えた rules 条件では、完了条件の出現が 9本中4本（44.4%） へ激減しました。8つの規則を足したことで、規則なしでは9本すべてに出ていた「完了条件」が出なくなりました。8規則が出力の型を縛ったのか、出力そのものが短くなった（1本あたり平均 846.3 字から 633.0 字）ためなのかは、この実験では切り分けていません。

さらに、8規則の遵守状況を調べると重要な事実が判明しました。「実施する・行うを避ける」という文体規則について、避けるべき表現（を実施|を行う|を行い|を行って|を行わ）は、規則なしの base 条件（全9本）において出現回数が 0回 でした（規則ありの rules 条件では1回）。つまり、この規則はプロンプトで指示しなくても全9本で守られており、プロンプトに書く必要のない「no-op 規則」だったと判断できます。

第1回実験で使用した並列実行スクリプト（run.sh）は以下の通りです。

#!/bin/zsh
cd ${0:a:h}
for m in A B C; do for c in base rules; do for i in 1 2 3; do
  p="次のメモを、別の担当者が読んで、書き手に質問せずに作業できる文章に書き直してください。出力は書き直した本文だけにしてください。

$(cat memo_$m.txt)"
  [ $c = rules ] && p="$p

$(cat rules.txt)"
  ( print -r -- "$p" | claude -p --disallowedTools 'Bash,Edit,Write,Read,WebFetch,WebSearch,Agent,Glob,Grep' > out/$m-$c-$i.md 2> out/$m-$c-$i.err ) &
done; done; done
wait
ls -la out | head -40

上記スクリプトを実行し、生成された全18本の出力を集計した実行結果ログは以下の通りです。

base 完了条件:        9
base 報告内容:        3
rules 完了条件:        4
rules 報告内容:        5
A-rules-1.md:11
A-rules-2.md:6
C-rules-2.md:0
A-rules-3.md:7
B-rules-3.md:0
C-rules-1.md:0
C-rules-3.md:0
B-rules-2.md:0
B-rules-1.md:5

集計ログが示す通り、base では 9本中9本に出現していた完了条件が、rules では 4本に半減しています。

第2回実験: 完了条件は「設定」ではなくモデルの「既定の振る舞い」

ここで一つの疑問が生じます。「完了条件が出現していたのは、ローカル環境の ~/.claude/CLAUDE.md などのユーザー設定にそうした指示が入っていたからではないか」という点です。

これを切り分けるため、第2回実験では「依頼文の言い回し（strict: 質問せずに作業できる文章に / plain: チケットの本文に）」と「ユーザー設定の有無（user: 通常設定 / nouser: 設定除外）」の 2×2＝4条件×各3回＝計12本を生成しました。

ユーザー設定の除外には、Claude Code CLI の --setting-sources project,local フラグを使用し、グローバルの個人設定（user スコープ）を完全に遮断しました5。

第2回実験の集計コマンドおよび実行結果ログは以下の通りです。

plain-nouser-1.md            完了条件:1 着手前/確認事項:0 文字:443
plain-nouser-2.md            完了条件:1 着手前/確認事項:0 文字:360
plain-nouser-3.md            完了条件:1 着手前/確認事項:0 文字:352
plain-user-1.md              完了条件:0 着手前/確認事項:0 文字:316
plain-user-2.md              完了条件:1 着手前/確認事項:0 文字:480
plain-user-3.md              完了条件:1 着手前/確認事項:0 文字:467
strict-nouser-1.md           完了条件:1 着手前/確認事項:1 文字:848
strict-nouser-2.md           完了条件:1 着手前/確認事項:0 文字:898
strict-nouser-3.md           完了条件:1 着手前/確認事項:0 文字:938
strict-user-1.md             完了条件:2 着手前/確認事項:0 文字:777
strict-user-2.md             完了条件:1 着手前/確認事項:0 文字:828
strict-user-3.md             完了条件:2 着手前/確認事項:1 文字:928

集計結果から以下の2点が実証されました。

  1. 完了条件はモデル既定の振る舞い: グローバル設定を遮断した nouser 条件でも、6本中6本（100%） すべてで完了条件が出現しました（12本全体でも11本で出現）。完了条件の提示は、ユーザー設定ファイルによるものではなく、Claude がこの依頼文のもとで指示なしでも行う動作であることが確認されました（依頼文そのものが完了条件を誘発している可能性は、この実験では切り分けていません）。
  2. 依頼文の一言が持つ強いレバレッジ: 「書き手に質問せずに作業できる文章に」という一言を含めるだけで、出力文字数が平均 385〜421字（plain の2条件）から平均 844〜895字（strict の2条件）へと約2倍に伸びました。また、「着手前に確認すること」という構成要素は strict の6本中2本で見られ、plain の6本では見られませんでした。

第3回実験: 2規則に絞ると完了条件は100%維持され、小細工の上乗せ効果は観測されなかった

第1回実験と第2回実験の結果を受けて、「指示に規則を追加すると、たとえ規則が2つと少なくても、モデルが『その規則だけを守る』ことになり、完了条件が抜けてしまうのではないか」という懸念が持ち上がりました。

そこで第3回実験では、no-op 規則等を除外して「主語の明示」と「条件を先に書く」の2規則に絞り込み、以下の4条件×題材3種×各3回＝計36本（これに条件Bの下書き9本を加えた45本。第1回の18本・第2回の12本と合わせて計75本）を生成して比較しました。

  • 条件D（2規則そのまま）: 2つの規則をそのまま渡す。
  • 条件A（前置き）: 「普段どおりに書いたうえで、次の2点を足してください」と前置きする。
  • 条件B（下書き後修正）: 一度通常どおり下書きを出力させた後、2規則を適用して書き直させる。
  • 条件C（完了条件明記）: 2規則に加え、「完了条件を書くこと」を明示的に指示する。

第3回実験の実行スクリプト（run3.sh）は以下の通りです。

#!/bin/zsh
cd ${0:a:h}
H="次のメモを、別の担当者が読んで、書き手に質問せずに作業できる文章に書き直してください。出力は書き直した本文だけにしてください。"
CL=(claude -p --disallowedTools 'Bash,Edit,Write,Read,WebFetch,WebSearch,Agent,Glob,Grep')
for m in A B C; do for i in 1 2 3; do
  M="$(cat memo_$m.txt)"; R="$(cat rules2.txt)"
  ( print -r -- "$H

$M

次の規則に従って書いてください。
$R" | $CL > out3/$m-D-$i.md 2>&1 ) &
  ( print -r -- "$H

$M

普段どおりに書いたうえで、次の2点を足してください。
$R" | $CL > out3/$m-A-$i.md 2>&1 ) &
  ( print -r -- "$H

$M

次の規則に従って書いてください。
$R

完了条件を必ず含めてください。" | $CL > out3/$m-C-$i.md 2>&1 ) &
done; done
wait

各条件の出力を集計した実行結果ログは以下の通りです。

条件 | 完了条件(9本中) | 主語/本 | 条件先/本 | 条件後/本 | 字/本
base(既存) | 9 /9 | 0.3 2.3 0.1 846.3
rules8(既存) | 4 /9 | 9.6 3.6 0.0 633.0
D 2規則 | 9 /9 | 4.3 4.1 0.0 749.2
A 追加 | 8 /9 | 5.8 3.9 0.0 739.3
B 下書き | 8 /9 | 0.1 2.9 0.0 824.6
B 修正後 | 8 /9 | 5.1 3.1 0.0 865.9
C 2規則+完了 | 9 /9 | 5.7 4.4 0.0 838.1

実測の結果、2規則をそのまま渡した条件Dにおいて、完了条件は 9本中9本（100%） すべてで維持されました。

さらに、「普段どおりに書いたうえで」と前置きした条件A（8/9）や、2段階で下書きを修正させた条件B（8/9）といった小細工は、2規則をそのまま渡した結果（9/9）を上回りませんでした。各条件9本のため、小さな差は判別できません。

規則数と指示方法による出力品質の比較マトリクス

一連の比較実験を通じて得られた各条件の出力挙動を俯瞰すると、規則数は「少なければ少ないほど良い」という単純な話ではなく、モデルの既定動作を邪魔しない最小限の境界を見極めることが肝要であることが分かります。

条件規則数完了条件の出現率（各9本）no-op 規則の扱いプロンプトの保守性総合評価・判定
規則なし (base)09 / 9 (100%)規則なしでも自発的に満たす最高（記述不要）既定の良い振る舞いは最大だが、固有の文体統制はできない
8規則 (rules8)84 / 9 (44.4%)no-op 規則まで含めて過剰指定最低（ノイズ化・肥大化）❌ 押しのけ発生。完了条件が半減し指示無視を招く
2規則そのまま (条件D)29 / 9 (100%)振る舞いが変わる規則のみに絞る高（2行のみ）⭕ 本実験の範囲では推奨。既定動作を損なわずに文体を統制
2規則＋前置き (条件A)28 / 9 (88.9%)「普段どおりに書いたうえで」を追加中（前置き指示の追加）⚠️ 上乗せ効果は観測されず。2規則そのまま（9/9）と差がなかった
2規則＋下書き後修正 (条件B)28 / 9 (88.9%)2段階生成で修正指示低（2回生成でコスト2倍）⚠️ 上乗せ効果は観測されず。2段階の手順を踏んでも改善せずコスト増
2規則＋完了条件明記 (条件C)29 / 9 (100%)「完了条件を書け」と明示指示中（指示の冗長化）⚠️ 上乗せ効果は観測されず。明示しなくても条件Dで9/9出ている

上表のとおり、2規則に絞り込んだ条件Dでは完了条件が9本中9本で維持されました。「普段どおりに書いて」と前置きする（条件A）、下書き後に直させる（条件B）、完了条件を念押し明記する（条件C）といった手当てを足しても、この実験（各9本・1モデル・3題材）では上乗せの効果は観測されませんでした。

既定の振る舞いを活かすプロンプト規則の選定ステップ

手元の CLAUDE.md やシステムプロンプトから不要なルールを削り落とし、モデルの既定動作を最大限に活かすための実践的な3ステップを紹介します。

ステップ1: 「規則なし」で数える

まず、代表的なタスク題材を3つ程度固定し、ルールを一切入れないプレーンなプロンプトで複数回（3〜5回）出力させます。出力結果を観察し、指示しなくても自発的に満たされている要件（no-op 規則）を洗い出してプロンプトから除外します。

ステップ2: 「振る舞いが変わる規則」だけに絞る

指示を与えることによって初めて挙動が変わるコアな規則（主語の明示、条件の位置など）だけを2〜3個選定します。

以下は本実験の直接の裏づけではなく、関連する経験則として共有されている知見です。GMOペパボでは、約2000行あった CLAUDE.md からモデルが既知の原則（SOLID や DRY など）を削ぎ落とし、3層構造（CLAUDE.md 150行、rules/、skills/）へ分割することで、起動時トークン消費を 114,847 から 19,232 へと 83% 削減した実績が報告されています6。また、ENECHANGE の開発者ブログでは「削除の判断に迷ったときは、『これを削除したらClaudeがミスをするだろうか？』と質問してみてください」という運用基準が提示されています7。Qiita でも R61 氏が「プロンプトは“書き続けるもの”ではなく“削り続けるもの”」として、エッジケース追記ループによる巨大化の弊害を指摘しています8。さらに、ikuo00uk 氏の実運用の知見でも「禁止事項を10個以上並べると後半ほど無視されるため、最重要ルールは3つ以内に絞る」ことが推奨されています9。

ステップ3: 「押しのけ」の有無をカウントする

規則を追加した後の出力を並べて数え、以前のプレーンな状態で自発的に出力されていた良い要素（完了条件、前提確認、丁寧なステップ分けなど）が抜け落ちていないかを点検します。もし抜け落ち（押しのけ）が発生しているなら、規則数を減らすか、指示の表現をより抽象度の高い目的志向（「〜のために」）へ書き換えます（本実験では試していない対処案です）。

以下は、本実験の結果を踏まえた最小限の文の規則ファイルの推奨構成例です。

1. 誰が行うのかが変わる箇所では、主語を書く。
2. 条件があるときは、条件を指示より先に書く。

指示はあれこれ細かく書き連ねるのではなく、モデルの自発的な良さを邪魔しない「振る舞いが変わる2行」に留めるのが最も安定します。

実測データの詳細と検証の限界

本記事の実測データから客観的に裏付けられた範囲（書けること）と、過度な一般化を避けるべき検証の限界（書けないこと）を誠実に明記します。

書けること

  • 8規則を渡した条件下（9本中4本、44.4%）において、規則なし（9本中9本、100%）と比較して完了条件の出現率が半減したこと。
  • 振る舞いが変わる2規則に絞ってそのまま渡した条件下（条件D: 9本中9本、100%）において、完了条件が 100% 維持されたこと。
  • 完了条件の生成は、グローバル設定ファイルを排除しても 6本中6本（100%）で自発的に出力されるモデル既定の振る舞いであること。

書けないこと

  • 各条件9本の比較なので、8/9 と 9/9 の差は偶然との区別がつかないこと。完了条件の判定は語句の一致（完了条件|完了の条件|完了とする|終わったと|Done）であり、言い換えられた完了条件や、語は出ていても実質が伴わないものは区別していないこと。
  • 8規則で完了条件が減った理由が、規則の数なのか、規則の内容が完了条件と競合したのか、出力が短くなったためなのか（切り分けていない）。2規則が残ったのが「数が少ないから」か「この2規則が競合しない内容だから」かも同じく未分離であること。
  • 実験は引き継ぎ文の書き直しという文書タスクの文体規則だけで、コーディング規約やテスト規則など他の種類の規則では未検証であること。
  • 規則数が 3〜7 個のどの境界値から押しのけが始まり、遵守率が崩れるのか（手元では未検証であり、今後の調査課題であること）。
  • 他社モデル（OpenAI や Google のモデル等）においても全く同一の既定動作や押しのけの比率が現れるかどうか（本実験は Claude による実測であり、モデルやタスク固有の閾値は未測定であること）。

よくある質問（FAQ）

Q. プロンプトにルールを細かく書いた方が、AIの出力は正確になるのではないでしょうか？

A. 結論から言うと、ルールを増やすほど出力が正確になるとは限りません。東京大学の研究（ManyIFEval）が示すように、制約ルールが増えるほど LLM の全指示同時遵守率は大幅に低下します。さらに、ルール過多はモデルが自律的に行っていた良い振る舞い（完了条件の提示など）を押しのけてしまうため、指示は「既定と比べて振る舞いが変わる最小限のもの」に絞る方が安定します。

Q. どのルールが不要な「no-op 規則」なのか、どうやって見分ければよいですか？

A. 結論から言うと、そのルールを外した状態で題材を3〜5回出力させ、自律的に守られているかを数えて確認します。例えば本実験では、「実施する・行うを避ける」という文体ルールは、指示なしでも全9本で守られていました。ルールを外しても結果が変わらないものは no-op（無駄な規則）と判断して削除できます。

まとめ

本記事の実測から言えることは以下の通りです。

  • 実測では、8規則を足すと完了条件の出現が9本中9本から4本に減った（因果の説明は未検証。アテンション予算の消費は、公式資料が挙げる背景理論の1つです）。
  • 指示なしでも最初から自発的に守られている規則（no-op 規則）は、プロンプトから冷徹に削ぎ落とす。
  • 規則は「あり・なし」の出力を並べて数え、振る舞いが変わる最小限（この実験では2個）に絞った条件で、完了条件が9本中9本で維持された。

自社の CLAUDE.md やスキル定義の肥大化・品質改善、エージェントパイプラインの標準化についてのご相談は、ぜひ コンタクトフォーム よりお気軽にお問い合わせください。

Footnotes

  1. Best practices for Claude Code Claude Code Docs (Anthropic), 2026年10月確認。アンチパターン「The over-specified CLAUDE.md」（長すぎると重要な規則がノイズに埋もれ半分を無視する、L457）、解決策としての「冷徹に削る（Ruthlessly prune）」（L458）。 ↩

  2. How Claude remembers your project Claude Code Docs (Anthropic), 2026年9月確認。推奨サイズは1ファイルあたり200行以下（L78）、200行超過によるコンテキスト消費増と遵守率（adherence）低下（L78, L569）、@path インポートはコンテキスト削減にならない点（L78, L569）。 ↩

  3. Effective context engineering for AI agents Anthropic (Engineering), 2025年9月29日。有限のアテンション予算（attention budget）、コンテキストロット（context rot）の定義、システムプロンプトの適切な高度（right altitude）。 ↩

  4. When Instructions Multiply: Measuring and Estimating LLM Capabilities of Multiple Instructions Following Keno Harada, Yudai Yamazaki, Masachika Taniguchi, Edison Marrese-Taylor, Takeshi Kojima, Yusuke Iwasawa, Yutaka Matsuo (The University of Tokyo), 2025年9月25日公開 (arXiv:2509.21051)。指示数 n = 1〜10 で全指示遵守率が大幅に低下（ManyIFEval、Table 8）、個別指示遵守率とのギャップ（Table 9）、コード制約 StyleMBPP での急落（Table 11）。 ↩

  5. CLI reference Claude Code Docs (Anthropic), 2026年10月確認。--setting-sources フラグの仕様（カンマ区切りで user, project, local を指定、L127）。 ↩

  6. CLAUDE.md の肥大化を 3 層構造で 83% 軽くした — 実測と試行錯誤の記録 GMOペパボ株式会社, 2026年4月21日。2000行の CLAUDE.md による起動時 114,847 トークン消費、既知原則削除や rules/skills 分割による 19,232 トークンへの 83% 削減実測値。 ↩

  7. 【Claude Code】CLAUDE.mdが肥大化する問題とその解決策 ENECHANGE株式会社 開発者ブログ (柿), 2026年3月24日。公式の200行制限引用と「これを削除したらClaudeがミスをするだろうか？」と問う運用基準。 ↩

  8. プロンプトは”書き続けるもの”ではなく”削り続けるもの” ── システムプロンプト肥大化問題と対策 R61, 2026年3月7日。エッジケース追記ループによる巨大化の病理、認知過負荷と引き算のプロンプトエンジニアリング。 ↩

  9. CLAUDE.mdの育て方 — 半年間の実運用で見つけた設計パターン ikuo00uk, 2026年4月18日。禁止事項を10個以上並べると後半ほど無視される実体験、最重要ルールを3つ以内に絞る設計。 ↩