命令の階層化と適用範囲の限定（Instruction Layering and Scoping）
命令を、いつ載るかとどのファイルに効くかを宣言して置く。狙いは常に効く命令とその場だけの命令を分けることであり、総量を削ることではない — 効くのは、関係あるものだけが残るからである。
問題
命令は書いた瞬間から、全部が常に載る。SQL を1本書くだけの作業に、別言語の命名規則もリリース手順も一緒に付いてくる。関係ない作法まで持ち出されるのはモデルが不注意だからではない — その命令が「いつ効くか」を、誰も言っていないからである。書いた側は文脈で分かっているが、命令ファイルにその文脈は書かれていない。
しかも常駐は無料ではない。長い命令ファイルでは、書いたはずの命令が見落とされる。これは推測ではなく、二つのベンダーが、それぞれ別の資料で、長さと遵守の低下を結んでいる（公式、具体例節。それぞれの原文が名指ししている対象は具体例節で示す）。
つまり一段に積み続けると、足したことが減らすことになる。次に足す一行が、既にある一行を薄める。
コンテキスト
適用する条件:
- 命令が育ってきた — 書き足すたびに、どこに何が書いてあるか分からなくなってきた
- ファイル種別ごとに作法が違う — 言語・レイヤ・生成物ごとに、守るべきものが別である
- 一部の命令が特定の作業でしか要らない — リリースの段取り、移行の手順、特定サービスの癖
適用しないケース:
- 命令が数個しかない — 階層を作るコストが、分ける利得を上回る。数個なら全部読ませればよい
- 全ファイルに等しく効くべき制約 — 秘密情報の扱い、破壊的操作の禁止。範囲を切ると、切った先が穴になる。 範囲の限定は、限定してよいものにだけ効く
- 範囲が言葉で書けない — 「重要なファイルのとき」は範囲ではない。照合できない宣言は、宣言しないのと変わらない
隣接パターンとの境界:
- ルールを拘束力で階層化する — どこに効かせるか（範囲）が本パターン、どれだけ強く効かせるか（拘束力）が同パターン。別の軸であり、併用する
- 常駐物の棚卸し — 範囲を切って常駐を減らすのが本パターン、数えて捨てるのが同パターン
- 失敗の制度記憶化 — 何を書くかが同パターン、それをどこに効かせるかが本パターン
- 検証対象の明示 — どの命令を適用するかが本パターン、何を検証させるかが同パターン。同じ範囲の宣言が、別の目的に使われる
- 命令の正本を一つにする — 階層を作ると正本が割れやすくなる。同パターンはその副作用を扱う
解決
なぜ効くのか。出発点は、命令はコンテキストであって強制ではないという一点である（公式、具体例節）。設定でも制約でもなく、モデルに読ませるテキストである。
ここが分かれ目になる — 強制であれば、増やしても既存のものは弱まらない。読ませるものは違う。読ませるものが増えれば、一つあたりの読まれ方は薄くなる。
だから命令ファイルは、足し算の場所ではなく席の取り合いの場所である。いま関係のない命令も、関係のある命令と同じ席に座る。範囲を宣言するとは、その命令が要らない場面で、席を空けることである。
空いた席は、いま関係のある命令が使う。これが本パターンの効き目のすべてであり、総量が減ることではない — 範囲を宣言しても、範囲に当たった場面では同じだけ載る。変わるのは当たらない場面のほうである。
宣言する軸は二つある。
- 時間軸 — 常駐するのか、呼ばれたときに載るのか
- 範囲軸 — どのファイル、どの作業に効くのか
二つは独立している。常に効くべき制約は「常駐・全範囲」、特定種別の作法は「範囲つき」、稀にしか要らない段取りは「呼ばれたら」。
一つの命令ファイルに全部を入れると、この三種が一つの段に潰れる。 潰れた段には、区別を書く場所がない。
この設計には、直感に反する非対称がある。範囲を宣言し忘れた命令は、効かないほうに倒れる（公式、具体例節）。宣言は「絞り込み」ではなく「有効化」であり、既定は効かない側である。
階層化とは命令を弱めていく作業ではなく、どこで効くかを一つずつ引き受けていく作業である。引き受けなかったものは、静かに黙る。
トレードオフ
利点
- 関係ない作法が持ち出されない。 SQL を書いている最中に、別言語の命名規則が根拠として出てこない。範囲を宣言した命令は、範囲の外では黙る。
- 残った命令が読まれやすくなる。 長い命令ファイルでは一部の命令が見落とされうる、と公式が書いている（公式、具体例節。原文が名指しする対象は具体例節で限定する）。常駐を減らすことは、残したものの読まれ方を上げる側に働く。
代償
- 宣言し忘れた命令は効かない。 既定は効かない側である（公式、具体例節）。書いたのに効かない命令は、書いていない命令より始末が悪い — 書いた本人は、効いているつもりでいる。
- どれが効いているか分からなくなる。 階層が増えるほど、いまの応答がどの命令に従った結果なのかを人間が言えなくなる。層を足すことは、追跡の難度を上げることでもある（「命令の正本を一つにする」）。
GitHub Copilot での具体例
Copilot は単一の製品ではない。範囲の宣言は VS Code と Copilot CLI の双方にあり、意味論は一致している。面ごとに原文で示す。
VS Code — applyTo が範囲を宣言する
出典: VS Code — カスタム命令（取得日: 2026-07-16）。命令ファイルの applyTo プロパティの定義は次のとおりである 公式:
Glob pattern that defines which files the instructions apply to automatically, relative to the workspace root. Use
**to apply to all files. If not specified, the instructions are not applied automatically, but you can still add them manually to a chat request.〔訳〕ワークスペースのルートを基準に、どのファイルに命令を自動適用するかを定義する glob パターンである。
**を使うと全ファイルに適用される。指定しない場合、命令は自動適用されないが、チャットのリクエストに手動で追加することはできる。
glob で「どのファイルに自動適用するか」を宣言する。** で全ファイル。そして — 宣言しなければ自動適用されない（If not specified, the instructions are not applied automatically）。「解決」で述べた非対称が、製品の仕様としてそのまま書かれている。手で足すことはできる（you can still add them manually）が、それは人間が毎回思い出せた場合の話である。
適用の決まり方は glob だけではない 公式:
The agent determines which instructions files to apply based on the file patterns specified in the
applyToproperty in the instructions file header or semantic matching of the instruction description to the current task.〔訳〕エージェントは、命令ファイルのヘッダーにある
applyToプロパティで指定されたファイルパターン、または命令の説明文といまの作業内容との意味的な一致に基づいて、どの命令ファイルを適用するかを決定する。
applyTo の glob または description と作業内容の意味的な一致（semantic matching）で決まる。範囲軸には入口が二つあり、片方は文字列の照合、もう片方は説明文の書き方である。範囲の宣言は glob を書くことだけではない — description をどう書くかも、範囲の宣言である。
公式は分割そのものを推奨している 公式:
For task or language-specific instructions, use multiple
*.instructions.mdfiles per topic and apply them selectively by using theapplyToproperty.〔訳〕タスク固有または言語固有の命令には、トピックごとに複数の
*.instructions.mdファイルを用意し、applyToプロパティを使って選択的に適用せよ。
一つの大きなファイルではなく、トピックごとに複数のファイルへ分け、applyTo で選択的に適用せよ — 本パターンの手順が、公式の助言としても現れている。
Copilot CLI — 同じ意味論が、別の面にもある
出典: Copilot CLI — カスタム命令の追加（取得日: 2026-07-16）公式:
Path-specific instructions are included only when their
applyTovalue matches a file that Copilot CLI is working with. An instruction file that you disable using/instructionsis not included.〔訳〕パス指定の命令は、その
applyToの値が Copilot CLI が扱っているファイルに一致したときだけ含まれる。/instructionsで無効化した命令ファイルは含まれない。
applyTo がいま扱っているファイルに一致したときだけ含まれる（included only when ... matches）。VS Code と同じ意味論が、別の面で、同じプロパティ名のまま成立している。移植性はここで確認できる — 本パターンは一つの面の機能ではない。
CLI にはもう一つ、階層を人間が直接覗く口がある 公式:
Use the
/instructionscommand to view the instruction files discovered for the current session and enable or disable individual files.〔訳〕
/instructionsコマンドを使うと、現在のセッションで見つかった命令ファイルを表示し、個々のファイルを有効・無効に切り替えられる。
いまのセッションでどの命令ファイルが見つかっているかを一覧し、個別に有効・無効を切り替えられる。「どれが効いているか分からなくなる」という代償を、この面は一覧という形で戻している。
面による違い
| 面 | 範囲の宣言 | いま効いている命令を人間が覗けるか |
|---|---|---|
| VS Code | applyTo の glob、または description と作業内容の意味的一致。宣言しなければ自動適用されない | 本カタログでは確認していない。無いという主張ではない |
| Copilot CLI | applyTo の glob。いま扱っているファイルに一致したときだけ含まれる | /instructions で一覧・個別の切り替え |
出典はいずれも上記の各面の docs である。機構としては同じ「範囲つきの命令」でありながら、階層を人間が覗けるかは、確認できた範囲では面によって違う。
量の目安
読者が最も知りたいのに、公式は自社の数字しか出せない領域である。幅ごと・出所つきで見せる。数値を1つに丸めない。
この節の GitHub 側 公式 引用が語る範囲
以下の GitHub の原文は、すべて Copilot code review のカスタム命令についての記述である。命令ファイル一般の目安として引かない。 1,000行も 10〜20命令も、code review の話である。
| 対象 | 目安 | ラベル | 出所 |
|---|---|---|---|
| 命令ファイル（Copilot code review のカスタム命令） | 約1,000行を上限。超えると応答品質が劣化しうる | 公式 | customize-code-review（取得日: 2026-07-16） |
| 命令の個数（Copilot code review のカスタム命令） | 開始は 10〜20 specific instructions | 公式 | 同上 |
CLAUDE.md（Claude Code） | target under 200 lines — 目標であって上限ではない | 公式 | code.claude.com/docs/en/memory（取得日: 2026-07-16） |
CLAUDE.md | 60〜80行が「業界のベストプラクティス」 | 通説 | 一次出典を辿れない（下記） |
| グローバル層 | 15行以下 | 通説 | 出典不明（同上） |
SKILL.md | 4,000トークンを超えると肥大 | 通説 | 出典不明（同上） |
| 実運用の一例 | ある個人リポジトリでは project CLAUDE.md が 86行、スキル本文のうち常駐は description のみで約9% | 実測 | 個人環境の観測（下記）。一般法則として書かない |
GitHub の原文（上記 customize-code-review、取得日: 2026-07-16）公式:
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 に影響しているかをテストせよ。
Best practice: Limit any single instruction file to a maximum of about 1,000 lines. Beyond this, the quality of responses may deteriorate.
〔訳〕ベストプラクティス: 単一の指示ファイルは最大約1,000行までに制限すること。これを超えると、応答の品質が劣化する場合がある。
同ページは、長さが何を起こすのかも書いている 公式:
- Context limits: Very long instruction files may result in some instructions being overlooked.
〔訳〕文脈の制限: 非常に長い指示ファイルでは一部の指示が見落とされることがある。
この一文が、「問題」と「トレードオフ」で述べた見落としの根拠である。 ただし上の警告のとおり、原文が名指ししているのは code review のカスタム命令であり、命令ファイル一般ではない。
Claude Code 側の原文（code.claude.com/docs/en/memory、取得日: 2026-07-16）公式:
Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence. If your instructions are growing large, use path-scoped rules so instructions load only when Claude works with matching files.
〔訳〕サイズ: CLAUDE.md ファイル1つあたり200行未満を目標とする。ファイルが長くなるほど消費するコンテキストが増え、遵守率が下がる。命令が大きくなってきたら、一致するファイルを Claude が扱うときだけ読み込まれるよう path-scoped rules を使うこと。
"target under"（目標）であって上限ではない。 「200行未満に収めよ」と読ませない。そして後半 — 命令が大きくなってきたら path-scoped rules を使い、一致するファイルを扱うときだけ読み込ませよ — は、applyTo と同じことを、別のベンダーが別の名前で言っている。範囲の限定は、一つの製品の発明ではない。
同ページは、なぜ効くのかも書いている 公式:
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 — 「解決」の出発点に置いた一点が、公式 の言葉で書かれている稀な箇所である。強制された設定ではないからこそ、書き方が遵守の度合いを変える。
「200」を取り違えない
同じページには別の 200 がある。自動メモリ MEMORY.md の読み込み打ち切り閾値である 公式:
The first 200 lines of
MEMORY.md, or the first 25KB, whichever comes first, are loaded at the start of every conversation. Content beyond that threshold is not loaded at session start.〔訳〕
MEMORY.mdの最初の200行、または最初の25KBのうちいずれか早く達したほうまでが、すべての会話の開始時に読み込まれる。その閾値を超えた内容はセッション開始時には読み込まれない。
CLAUDE.md の 200 は目標（推奨）、MEMORY.md の 200 はハードな打ち切りである。 前者は超えても読まれる（ただし adherence が落ちる、と原文は書く）。後者は超えた分が読まれない。同じ数字で、意味が違う。混ぜると誤りになる。
通説 3行の素性
60〜80行・15行以下・4,000トークンは、コミュニティで流布しているが一次出典を辿れない。
これらの数値を含む文書は、同時に実在しない GitHub Action の所有者名を事実として書いていた（本カタログが 404 を確認済み）。検証していない主張を、事実として書く傾向のある文書である。出所としての信頼度は低い。
それでも数値は落とさない。 落とせば読者は「公式の 200 だけが答えである」と受け取る。公式は200行を目標と書き、コミュニティにはより厳しい60〜80行説もある（ただし出典は辿れない） — 両方を見せ、片方だけを正解として提示しない。素性を明記した上で載せるほうが、黙って捨てるより読者は判断できる。
実運用の一例 実測
ある個人リポジトリ（2026-07-07 時点の監査、Claude Code 環境、n=1）では、project CLAUDE.md が 86行であり、スキル本文のうち常駐しているのは description だけで、割合にして約9%だった。残りは呼ばれた時点で載る。時間軸の階層が、一つの環境で実際にこの比率で運用されていた、という観測である。
ここから「階層化すればトークンが減る」を導かない。 比率は反実仮想を回さずに見えるが、「階層化しなかった場合にいくらだったか」は、階層化せずに運用して数えない限り見えない。誰も数えていない。実測 が覆えるのは、反実仮想を回さずに見えることだけである。
他ツールでの対応物 — 二つの軸に、別々の名前が付いている
Anthropic 側には本パターンの両軸に 公式 の記述があるが、別々の資料にある。範囲軸は上記の CLAUDE.md の path-scoped rules である。時間軸のほうには名前が付いている（出典: Anthropic — Agent Skills、取得日: 2026-07-16）公式:
This filesystem-based architecture enables progressive disclosure: Claude loads information in stages as needed, rather than consuming context upfront.
〔訳〕このファイルシステムに基づくアーキテクチャは progressive disclosure(段階的開示)を可能にする — Claude は前もってコンテキストを消費するのではなく、必要になった段階で情報を読み込む。
段階的に、必要になった時点で読み込む（loads information in stages as needed）— 前もってコンテキストを食うのではなく。これが時間軸そのものである。同ページはスキルの内容を3種類に分け、"each loaded at a different time" と書く。第1段の見出しは "Level 1: Metadata (always loaded)" であり、常駐するのはメタデータだけである。
この二つを、一つの型として束ねているのは本カタログである。 progressive disclosure は Agent Skills の docs にあり、path-scoped rules は memory の docs にある。束ねる理由は「解決」に書いた — 二つは独立した軸であり、片方だけでは、もう片方の場面で漏れる。
別名
| 呼称 | 出典 |
|---|---|
| Progressive disclosure | 一次 — Anthropic が Agent Skills の docs で、段階的ロードにこの名を与えている（出典は具体例節）。時間軸だけの名である（下記） |
| 命令の階層化と適用範囲の限定 / Instruction Layering and Scoping | 記述 — 本カタログの記述的呼称であり、一次資料に出典は無い |
progressive disclosure を本パターンの別名として等号で結ばない。 原文が言っているのは「Claude loads information in stages as needed」— いつ読み込むかである。本パターンはそれに加えて、どのファイルに効かせるかを含む。前者は時間軸、後者は範囲軸であり、近いが、同じではない。
差は実務で出る。段階的ロードは「全部を最初に載せない」を実現するが、それだけでは「この命令は SQL を扱うときにだけ効く」を言えない。範囲の宣言（applyTo / path-scoped rules。いずれも具体例節）が担っているのはこちら側である。片方の名を全体の名として使うと、もう片方が見えなくなる。 そのため本カタログは、両軸を含む記述的な名前を与えた。
関連
- 失敗の制度記憶化 — 何を書くかが同パターン、それをどこに効かせるかが本パターン。同パターンが「モデルが知りえないことだけを書け」と絞った記憶を、本パターンは「その記憶が要る場面でだけ載る」ようにする
- ルールを拘束力で階層化する — どこに効かせるか（範囲）が本パターン、どれだけ強く効かせるか（拘束力）が同パターン。別の軸であり、併用する
- 常駐物の棚卸し — 範囲を切って常駐を減らすのが本パターン、数えて捨てるのが同パターン。範囲の宣言は、捨てる判断をする前にできることである
- 検証対象の明示 — どの命令を適用するかが本パターン、何を検証させるかが同パターン。同じ範囲の宣言が、別の目的に使われる
- 命令の正本を一つにする — 階層を作るほど、どれが効いているのかが分かりにくくなる。同パターンはその副作用を扱う
- まず次に読むなら ルールを拘束力で階層化する — 適用範囲を絞ったら、次は拘束力で並べる番である