ルールを拘束力で階層化する（Rules Ranked by Binding Force）

全ルールが同じ重みだと、重要な制約が軽い好みに埋もれる。段が与えるのは衝突したときに何を先に譲るかの宣言であり、遵守の保証ではない — MUST は約束ではなく、優先順位である。

問題

命令ファイルは平らである。「タブでインデントする」と「本番 DB に触るな」が、同じ字面で、同じ大きさの箇条書きとして並ぶ。人間は後者が重いと知っているが、それは命令ファイルに書いてあるからではない — 読む側が既に知っているからである。モデルの側には、その重さを示す手がかりが無い。

しかも命令は強制ではなく、読ませるテキストである。だから守られ方は書き方に左右され、完全な遵守は約束されない（公式、具体例節。それぞれの原文が名指ししている対象は具体例節で示す）。つまり「どれかは落ちる」ことのほうが前提であり、平らなままだと何が落ちるかについて、こちらは何も言っていないことになる。落ちるのは、たまたま落ちたものである。

コンテキスト

適用する条件:

ルールが混在している — 絶対に譲れないもの、推奨、ただの好みが、一つのファイルに同居している
守られなかったときの代償に大きな差がある — 片方は書き直すだけ、片方は取り返しがつかない
重さを知っているのが書いた本人だけ — 暗黙の重み付けが、命令ファイルの外にある

適用しないケース:

機械で止められる制約 — 拘束力を言葉で盛るより、ゲートにするほうが確実である。公式も「linter や formatter が既に強制する規約は飛ばせ」と書いている（具体例節）
ルールが数個で、全部同じ重さのとき — 段を作るコストだけが残る。段は他の段との対比で意味を持つので、対比が無いなら段も無い

隣接パターンとの境界:

命令の階層化と適用範囲の限定 — どこに効かせるか（範囲）が同パターン、どれだけ強く効かせるか（拘束力）が本パターン。別の軸であり、併用する
失敗の制度記憶化 — 何を書くかが同パターン、それにどの拘束力を与えるかが本パターン。同パターンの判定を通らなかったものは、そもそも段に載せない
機械ゲートと意味ゲートの分離 — 本パターンの限界がここにある。 拘束力は言葉であり、言葉は非決定的にしか効かない。決定的に止めたいなら、言葉ではなくゲートにする
常駐物の棚卸し — 段を付けたルールも常駐物であり、毎ターンの家賃を払う。段は家賃を免除しない

解決

なぜ効くのか。出発点は、命令はコンテキストであって強制された設定ではないという一点である（公式、具体例節）。強制であれば、衝突は実行される前に弾かれる — 設定同士が矛盾していれば、どちらかが不正として撥ねられる。

読ませるテキストは違う。矛盾したまま両方が載り、衝突はモデルの中で、その場で解かれる。

ここが本パターンの土俵である。衝突は必ず解かれる。問題は、誰の基準で解かれるかである。

平らな命令群は、その解決をモデルに丸投げしている。「タブでインデントする」と「本番 DB に触るな」が両立しない場面に出くわしたとき、どちらを譲るべきかは、命令ファイルのどこにも書かれていない。書いた本人の頭にはある。書いていないものは、渡っていない。

拘束力を書くとは、衝突の解決規則を、衝突が起きる前に渡しておくことである。段は新しいルールを足さない。足すのはルール同士の順序である。

ここで取り違えが起きる。段を付けても、遵守は保証されない。 段の宣言もまた命令であり、命令は強制ではない — つまり段は、それ自身が非決定的にしか効かない材料である。この筋を通すと、本パターンが約束できることは狭くなる:

段が変えようとしているのは「守られるかどうか」ではなく、「衝突したときに何を先に譲るか」である。そして段は、その順序を宣言するだけで、保証はしない。

だから「MUST と書いたのに守られなかった」は、本パターンの失敗ではない。MUST は最初から保証ではない。優先順位の宣言である。

ここを取り違えたまま運用すると、守らせたい一心で段を盛り、やがて全部が MUST になる。そうなった時点で段は消えている — 全部が MUST なら、MUST は「これはルールである」としか言っておらず、平らな一覧に戻っている。

段の意味は、他の段との差でできている。だから段は、増やすほど薄まる。

そしてもう一つ。拘束力の語彙は、強さを伝えるが、なぜ強いかを伝えない。 「MUST」は「破るな」としか言わない。想定していなかった場面にモデルが出くわしたとき、語彙は「このルールはこの場面にも及ぶのか」を判断する材料にならない。

理由は、語彙の届かない場所で効く — 公式も、ルールの背後にある理由を書けば edge case での判断が良くなる、と明記している（具体例節）。段は順序を与え、理由は射程を与える。両方要る。

トレードオフ

利点

衝突の解決が、こちら側の宣言になる。 平らな一覧では、どちらを譲るかの判断は毎回モデルに委ねられ、根拠がこちらに無いので結果を検討することもできない。段があれば、少なくとも「何を渡したか」がこちらに残る。
重いルールが、軽い好みに埋もれない。 「本番 DB に触るな」がインデントの好みと同じ字面で並んでいる状態そのものを解消できる。重さは、読む側が既に知っているとは限らない。

代償

段を付けても保証にはならない。 公式は、すべての命令が毎回完全に守られるわけではないと明記している（具体例節。原文が名指ししている対象は具体例節で限定する）。段は順序を宣言するだけで、その宣言が読まれることも保証されていない。決定的に止めたい失敗は、言葉ではなく機械のゲートにする（「機械ゲートと意味ゲートの分離」）。
段は、埋めたくなる。 拘束力の階層はルールを増やす方向に働きやすい — 段を作ると、その段に何か入れたくなる。しかしモデルが既にやることを MUST で書いても、雑音が増えるだけである。 公式はこの種の記述を名指しで「効果を上げずに雑音を足す」と呼んでいる。理由は already optimized — モデルが既にやっているからである（具体例節）。ある個人リポジトリの監査も、独立にルールの model-babysitting 傾向を指摘している（測定ではなく監査者の判断である。具体例節）。
拘束力の構造は、中身の要否を免除しない。 本パターンが決めるのはどの段に置くかだけであり、そもそも書くべきかは失敗の制度記憶化の判定にかける。
この2つは軸が違う — 本パターンは拘束力の構造を扱い、同パターンはルールの中身を扱う。段を作ったことは、中身の判定を通した理由にならない。

GitHub Copilot での具体例

本パターンは道具非依存の実践であり、拘束力は命令ファイルという入れ物の中の書き方として実現する。 したがってこの節が示すのは機能名ではなく、Copilot でこの実践をどう行うか、および 公式が支持する粒度と、支持しない書き方である。

github.com — code review のカスタム命令

この節の公式引用が語る範囲

以下の原文はすべて Copilot code review のカスタム命令についての記述である。命令ファイル一般の目安として引かない。 数値も助言も、原文が名指ししている対象の外へ広げないこと。

出典: Using custom instructions to unlock the power of Copilot code review（取得日: 2026-07-16）。

公式は、命令が効くことについて三つの限界を並べている公式:

Non-deterministic behavior: Copilot may not follow every instruction perfectly every time.
Context limits: Very long instruction files may result in some instructions being overlooked.
Specificity matters: Clear, specific instructions work better than vague directives.
〔訳〕非決定的な挙動: Copilot は毎回すべての命令に完璧に従うとは限らない。コンテキストの限界: 命令ファイルが非常に長いと、一部の命令が見落とされることがある。具体性が重要: 曖昧な指示より、明確で具体的な指示のほうがよく機能する。

一つ目 — すべての命令が毎回完全に守られるとは限らない（may not follow every instruction perfectly every time）— が、本パターンの代償の根拠である。ただし原文が語っているのは code review のカスタム命令についてであり、命令一般ではない。 「解決」で置いた一般の前提（命令は強制ではない）の根拠は、後述の Claude Code 側の原文にある。

粒度も示されている公式:

Begin with 10–20 specific instructions that address your most common review needs, then test whether these are influencing Copilot code review in the way you intended.
〔訳〕まず、最も頻繁なレビュー要求に対応する10〜20個の具体的な命令から始め、それらが意図したとおりに Copilot code review に影響しているかを検証せよ。

10〜20 の specific instructions から始めて、意図どおり効いているかを試せ。 段を作る前に、まずこの規模である。段は順序の話であり、順序は数える対象が少ないほど付けやすい。

そして公式は、書いてはいけない命令を節として立てている公式:

Vague quality improvements:
Be more accurate
Don't miss any issues
Be consistent in your feedback
These types of instructions add noise without improving Copilot's effectiveness, as it's already optimized to provide accurate, consistent reviews.
〔訳〕曖昧な品質改善の指示の例 — 「もっと正確に」「見落としを無くせ」「フィードバックに一貫性を持たせよ」。この種の指示は、Copilot の効果を高めることなく雑音を増やすだけである。Copilot はすでに正確で一貫したレビューを提供するよう最適化されているためである。

これがトレードオフ「段は、埋めたくなる」の根拠である。 「正確であれ」に MUST を付けても、効果を上げずに雑音を足す（add noise without improving）ことは変わらない。理由も書かれている — already optimized、すなわちモデルが既にやっていることだからである。拘束力の段は、この判定を免除しない。

VS Code — カスタム命令の書き方

出典: VS Code — カスタム命令（取得日: 2026-07-16）。公式は書き方の助言を並べており、そのうち三つが本パターンに直接効く公式:

Keep your instructions short and self-contained. Each instruction should be a single, simple statement.
〔訳〕指示は短く自己完結にせよ。各指示は単一の単純な文であるべきである。

1ルール1文である。 これは段を付ける前の条件にあたる。一つの箇条書きに複数の主張が入っていると、そこに拘束力を割り当てられない — 「本番 DB に触るな、あとインデントはタブで」に、どの段を付けるのか。段を付けられる形になっていることが、段を付ける前提である。

Include the reasoning behind rules. When instructions explain why a convention exists, the AI makes better decisions in edge cases.
〔訳〕規則の背後にある理由を含めよ。指示が規約の存在理由を説明していると、AI は edge case でより良い判断を下す。

規約が存在する理由を書けば、edge case での判断が良くなる。 「解決」で述べた「語彙は強さを伝えるが、なぜ強いかを伝えない」に、公式の側から対応する助言である。edge case という限定に注意したい — 理由が効くのは、まさに拘束力の語彙が届かない場所である。段と理由は競合しない。段が順序を与え、理由が射程を与える。

Focus on non-obvious rules. Skip conventions that standard linters or formatters already enforce.
〔訳〕自明でない規則に焦点を当てよ。標準的な linter や formatter がすでに強制している規約は省略せよ。

linter や formatter が既に強制する規約は飛ばせ。 これが「コンテキスト」節の「機械で止められる制約には適用しない」の根拠である。公式が言っているのは、機械が強制できるものを命令に書くのは置き場所の誤りだ、ということである。強制できるものを、強制でないもので書き直しても、弱くなるだけである。

他ツールでの対応物 — Claude Code の命令ファイル

「解決」の出発点に置いた一般の前提は、Anthropic 側の原文にある（出典: code.claude.com/docs/en/memory、取得日: 2026-07-16）公式:

CLAUDE.md files are loaded into the context window at the start of every session, consuming tokens alongside your conversation. ... Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best.
〔訳〕CLAUDE.md ファイルは各セッションの開始時にコンテキストウィンドウへ読み込まれ、会話とともにトークンを消費する。(中略)強制された設定ではなくコンテキストであるため、命令の書き方は Claude がどれだけ確実にそれに従うかに影響する。具体的で簡潔で、よく構造化された指示が最も効果的である。

context rather than enforced configuration — 命令は、強制された設定ではなくコンテキストである。だからこそ書き方が遵守の度合いを左右する（how you write instructions affects how reliably Claude follows them）。本パターンは、この「書き方」の一つに拘束力を数える。

ただし原文は「拘束力を書け」とは言っていない。 言っているのは specific・concise・well-structured までである。「段を付ければ遵守が上がる」の根拠として、この原文を使わない — この原文が支えるのは「命令は強制ではない／書き方が遵守に影響する」までであり、本パターンの中核（拘束力の段が衝突の材料になる）は、そこから先の道具非依存の議論として「解決」に置いた。

二つのベンダーが、別々の資料で、同じ形を書いている

GitHub は code review のカスタム命令について「すべての命令が毎回完全に守られるとは限らない」と書き、Anthropic は CLAUDE.md について「強制された設定ではなくコンテキストであり、書き方が遵守の度合いを左右する」と書く。それぞれの原文が名指ししている対象は違い、片方をもう片方の範囲へ広げることはできない。 それでも両者は、同じ一点で一致している — 命令の遵守は保証されない。 本パターンの代償（段は保証ではない）は、この一致の上に立っている。

実運用での観測

ある個人リポジトリの監査（2026-07-07 時点、Claude Code 環境、n=1）は、ルールの model-babysitting 傾向を指摘している。「テストが通るまで完了と主張するな」の類は現行モデルの既定挙動であるため、書いても限界効用は小さいという判定である。

これは測定ではなく、監査者の判断である。 反実仮想は回っていない — その種のルールを外して運用し、挙動が変わるかを誰も数えていない。実測を貼れるのは、反実仮想を回さずに見えることだけであり、この判定はそれに当たらない。 それでも記す価値はある。公式の「add noise ... already optimized」〔訳: 雑音を足す……すでに最適化されている〕と、独立した個人環境の監査が、同じ結論に達している — 拘束力の段を作っても、モデルが既にやることを段に入れる理由にはならない、という結論である。根拠の重みは、一致それ自体から来る。

別名

呼称	出典
憲法パターン	通説 — コミュニティで流布しているが、一次出典を辿れない（下記）
MUST・SHOULD・WON'T	通説 — 同上。拘束力の語彙として流布しているが、確立した出典を確認できていない
ルールを拘束力で階層化する / Rules Ranked by Binding Force	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

「憲法パターン」も「MUST・SHOULD・WON'T」も、コミュニティでは通用する。しかし本カタログは、どちらについても一次出典を辿れなかった。 辿れないことは「誤りである」という意味ではなく、「素性を示せない」という意味である。素性を示せない呼称を、示せるものとして書かない。

この区別は実務に効く。「憲法パターン」という名は、規範に権威があるかのように響く — 憲法は、破れば無効になる規範である。だが「解決」で見たとおり、命令ファイルの段は破っても何も無効にならない。名前が約束している強さと、機構が持っている強さが食い違っている。 語彙のほうも同じ危うさを持つ。大文字の MUST は、どこかで定義された規格用語のように見えるが、本カタログはその出典を確認できていない。 そのため本カタログは、機構の実際の強さに合わせた記述的な名前を与えた。拘束力で階層化するとは、階層を宣言することであり、強制することではない。

ルールを拘束力で階層化する（Rules Ranked by Binding Force） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

github.com — code review のカスタム命令 ​

VS Code — カスタム命令の書き方 ​

他ツールでの対応物 — Claude Code の命令ファイル ​

実運用での観測 ​

別名 ​

関連 ​