常駐物の棚卸し（Resident Context Inventory）

命令ファイル、ツール定義、MCP サーバ — 一度置けば毎ターン載る物を、項目ごとに数える。減らす目的はトークン代ではなく、残した常駐物が効くようにすることである。ただし数えても減らせない項目があり、棚卸しの底はゼロにならない。

問題

常駐物は、置くときは1回の判断で済むが、支払いは毎ターン発生する。しかも力は増える方向にしか働かない — 事故が起きれば命令が足され、便利そうなサーバを繋げばそのツール定義が足され、誰かの作法が足される。減らす理由を持ち込む者がいない。 置いた本人は置いた瞬間の判断だけを覚えていて、以降のターンで払い続けていることを見ていない。そして席が埋まった代償は、請求書ではなく品質の側に出る — 命令ファイルが長くなると、一部の命令は読み飛ばされうる（公式、具体例節）。効かない命令に毎ターン家賃を払っている状態が、誰にも気づかれないまま続く。

コンテキスト

適用する条件:

常駐が伸び続けている — 足した覚えはあるが、減らした覚えが無い
ツールや MCP サーバを足した覚えがある — 足したのは1つでも、載るのはそのサーバが提供するツールの定義である
「前に書いた命令が効いていない」感じがする — 席が埋まった代償は、まずここに出る

適用しないケース:

常駐がまだ小さいとき。 数える手間そのものがタダではない
捨ててよいかを判断する材料が無いとき。 なぜ置いたのか分からない常駐物は、棚卸しにかけても「たぶん要る」で残る。先に失敗の制度記憶化の形 — 具体で書く — を当てるほうが順序として正しい
作業の途中で思いついたとき。 棚卸しは前置きを動かす操作であり、キャッシュを一度壊す。区切りでまとめて行うほうが安い

隣接パターンとの境界:

失敗の制度記憶化 — 同パターンは常駐を増やし、本パターンは減らす。正面から緊張する（解き方は「解決」節）
読み捨ての隔離 — 毎ターン載り続ける物を減らすのが本パターン、その場で急に膨らむ物を追い出すのが同パターン
セッション境界の設計 — 同パターンが扱うのは会話（積み上がる側）、本パターンが扱うのは常駐（毎ターン載る側）。同じコンテキストウィンドウの別の区画である
命令の階層化と適用範囲の限定 — 適用範囲を切ることは常駐を減らす一手段である。同パターンが切り方、本パターンが数え方と捨て方
前置きを壊さない（キャッシュ） — 棚卸しは前置きを動かす。実施の頻度と単位は同パターンの制約を受ける

解決

なぜ効くのか。まず、常駐物の費用は掛け算である。 置く判断は1回、支払いはターン数だけ発生する。この2つは時間的に離れている — 置くときには安く見え、払っているときには誰も見ていない。棚卸しが効くのは新しい規律を導入するからではなく、この非対称を「見る」という行為だけで埋めるからである。数えた瞬間に、1回の判断と毎ターンの支払いが同じ画面に並ぶ。

数え方は項目ごとである。合計だけを見ても何も捨てられない。項目に分けて初めて、どこまでが底で、どこから上が自分の判断かが分かる。そして底はゼロではない — 公式は、システム命令とツール定義について「常に存在し、コンテキストウィンドウの一定部分を占める」と書いている（公式、具体例節）。棚卸しは「全部減らせる」という主張ではない。 減らせない項目を減らそうとする努力と、減らせる項目を放置する怠慢は、どちらも同じ「数えていない」から来る。

次に、動機を取り違えないこと。常駐を減らす理由はトークン代だと思われがちだが、本題は効き目である。公式は長い命令ファイルについて「一部の命令が見落とされうる」と書き、別のベンダーは「長いファイルはより多くのコンテキストを消費し、遵守を下げる」と書く（いずれも公式、具体例節）。二社が別々に、長さと品質を結んでいる。 つまり常駐物を減らすことは、残した常駐物が効くようにすることである。 費用の話に見えて、品質の話である。

だから判定基準は「これは高いか」ではなく、**「これは、毎ターン読ませる価値があるか」**になる。

この基準は新しくない。失敗の制度記憶化が「モデルが知りえないことだけを書く」と言うのと、同じ一つの基準である。あちらは置く前に当て、こちらは置いた後に当てる。だから2つのパターンは争わない — 本パターンは「増やすな」とは言っていない。条件を満たす記憶は増やしてよく、棚卸しの対象は家賃に見合わない常駐物のほうである。ただし争いが解けても費用は消えない。 モデルが知りえない記憶であっても、家賃は毎ターン発生する。条件を満たす常駐物が増え続ければ、いずれ適用範囲を切る（命令の階層化と適用範囲の限定）か、底に近いことを認めるしかない。

最後に、棚卸しできるかどうかは、棚卸しの日ではなく置いた日に決まっている。 「注意深く確認すること」のように抽象的に書かれた常駐物は、いつ不要になったのかを誰も判断できず、棚卸しにかけても残る。捨てられるのは、どの条件で要るのかが書いてある常駐物だけである。

トレードオフ

利点

残した常駐物が効きやすくなる。 これは費用の改善ではなく遵守の改善である。長さと遵守を因果で結んでいるのは公式の側であり（公式、具体例節）、本カタログの推測ではない。
空きが増える。 空きそれ自体は目的ではない — 本題に使える席である。長い会話も、急に膨らむ調査も、そこに座る。常駐を薄く保つことは、他のパターンが働く余地を作ることでもある。

代償

捨てた常駐物は、次に必要になったとき誰も気づかない。 常駐は「有ること」は数えられるが、「無いこと」は見えない。捨てて効かなくなったことは、失敗として現れるまで観測できない。だから捨てる判断の側に、捨ててよい条件が書かれている必要がある（失敗の制度記憶化の三つ組がその形である）。
棚卸しは前置きを壊す。 常駐物は前置きの先頭に置かれるため、動かせばそこから先が作り直しになる。棚卸しには、この作り直しの費用が毎回付く（前置きを壊さない（キャッシュ））。「気づいたら随時」ではなく「区切りでまとめて」が合理的になるのはこのためである。

GitHub Copilot での具体例

Copilot は単一の製品ではない。本パターンにとって最も重要な面差は、常駐物を「見る手段」が面ごとに違うことである。Copilot CLI は項目別の内訳を出し、VS Code は合計と内訳をチャット入力欄から出す。

Copilot CLI — 棚卸しが、そのまま製品機能になっている

出典: Copilot CLI のコンテキスト管理（取得日: 2026-07-16）。

同ページは、何が常駐するかを定義している公式:

System instructions and tool definitions: The built-in instructions that tell Copilot how to behave, plus the schemas of all available tools. These are always present and take up a fixed portion of the context window.
〔訳〕システム命令とツール定義: Copilot の振る舞いを指示する組み込みの命令と、利用可能なすべてのツールのスキーマ。これらは常に存在し、コンテキストウィンドウの一定部分を占める。

組み込みの命令と、利用可能なすべてのツールのスキーマが、常に存在し（always present）、コンテキストウィンドウの一定部分を占める（take up a fixed portion）。「解決」で述べた「底はゼロにならない」が、公式の定義そのものとして書かれている。同時にこれは、ツール定義には**「載せるが薄くする」という選択肢が無い**ことも意味している — スキーマが載る理由は、そのツールが利用可能だからである。

そして /context の内訳が、本パターンの請求書そのものになっている公式:

System Prompt: the base system prompt.
Custom Instructions: your loaded custom instructions (shown only when present).
System Tools: built-in tool definitions.
MCP Tools: tool definitions contributed by MCP servers.
Messages: your conversation history.
Free Space: unused context still available.
Buffer: capacity reserved for the model's response and headroom.
〔訳〕System Prompt は基本のシステムプロンプト、Custom Instructions は読み込まれたカスタム命令(存在する場合のみ表示)、System Tools は組み込みのツール定義、MCP Tools は MCP サーバが提供するツール定義、Messages は会話履歴、Free Space は未使用で利用可能なコンテキスト、Buffer はモデルの応答と余裕のために確保された容量である。

「常駐物を項目ごとに数える」という本パターンの実践が、製品機能として実在する。 注目すべきは3点である。第一に、MCP Tools が独立した項目である — MCP サーバを1つ足すことは、そのサーバが提供するツールの定義を、以降のすべてのターンに載せることである。項目が独立しているのは、そこが太るからである。第二に、Custom Instructions は shown only when present、すなわち置いた者だけが払う項目である。第三に、7項目のうち System Prompt と Buffer は利用者が置いたものではない — 数えても、そこは減らせない。

見る手段と外す手段の両方が用意されている（出典: Copilot CLI のコマンドリファレンス、取得日: 2026-07-16）公式:

コマンド・フラグ	原文（逐語）
`/context`	Show the context window token usage and visualization. …
`/instructions`	View and toggle custom instruction files.
`--no-custom-instructions`	Disable loading of custom instructions from `AGENTS.md` and related files.

/instructions が toggle（有効・無効の切り替え）であることは、棚卸しの実務にそのまま効く。捨てる前に、外して様子を見られる。

VS Code — 外す操作と、見る場所

出典: VS Code の AI 利用の最適化（取得日: 2026-07-16）公式。同ページは、棚卸しそのものを推奨している:

Every tool call produces output that consumes space in the context window and contributes to credit consumption. Disable tools you don't need for the current task to prevent unnecessary calls.
〔訳〕すべてのツール呼び出しは、コンテキストウィンドウの容量を消費し、クレジット消費に寄与する出力を生む。不要な呼び出しを防ぐため、現在のタスクに要らないツールは無効にする。

「今のタスクに要らないツールは無効にせよ」— 公式が、ツールを外すことを推している。ただしこの原文が言うのは、ツール呼び出しの出力が席を食うところまでである。 定義（スキーマ）そのものが常駐するという話は、上の Copilot CLI の面が書いている。同じ「ツールを外せ」でも、面によって書かれている理由が違う。

見る場所は、項目別の一覧ではなくチャット入力欄である公式:

To view the cumulative cost and token breakdown for the entire session, hover over or select the context window control in the chat input.
〔訳〕セッション全体の累積コストとトークンの内訳を見るには、チャット入力欄のコンテキストウィンドウ表示にカーソルを合わせるか、選択する。

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

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

以下の原文は Copilot code review のカスタム命令についての記述である。命令ファイル一般の目安として引かない。

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

Context limits: Very long instruction files may result in some instructions being overlooked.
〔訳〕コンテキストの制限: 非常に長い命令ファイルは、一部の命令が見落とされる結果につながりうる。

長さが効き目を下げる、と公式が書いている。ただし原文が名指ししているのは code review のカスタム命令であり、この一文から命令ファイル一般の行数目安は出ない。出るのは向きだけである — 長くすれば、見落とされる側に動く。

他ツールでの対応物

Claude Code の docs は、常駐の費用と効き目を1か所で結んでいる（出典: Claude Code のメモリ（CLAUDE.md）、取得日: 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 がどれだけ確実に従うかが変わる。具体的で簡潔かつ構造化された指示が最もよく機能する。

毎セッションの開始時にコンテキストウィンドウへ読み込まれ、会話と並んでトークンを消費する（consuming tokens alongside your conversation）。これが「常駐」の、他ツールでの対応物である。同ページはさらに、長さと遵守を因果で結ぶ公式:

Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence. …
〔訳〕サイズ: CLAUDE.md ファイル1つあたり200行未満を目標とする。長いファイルはより多くのコンテキストを消費し、遵守を低下させる。

⚠ 原文は target under（目標）であって上限ではない。「200行を超えたら違反」と読ませない。本カタログが採るのは因果のほうである — 長いファイルはより多くのコンテキストを消費し、遵守を下げる（reduce adherence）。GitHub の overlooked と Anthropic の reduce adherence は、別々の会社が、別々の製品について、同じ向きを書いている。 常駐を減らす理由が費用ではなく効き目であるという本パターンの主張は、この一致に立っている。

実運用での観測

ある個人リポジトリ（2026-07-07 時点の観測、Claude Code 環境、n=1）で、常駐の量が実際に測られている。一般法則としては書かない。

観測できたこと実測

project の CLAUDE.md は 86行である
スキルは本文を持つが、常駐するのは description だけであり、本文全体に対する割合は**約9%**である

観測ではないこと（監査者の判断であり、実測ではない）

この構成が効いている、とは観測していない。 常駐を2倍にした場合の遵守を誰も数えていないため、反実仮想が無い。効き目の根拠は実測ではなく、公式の側（overlooked / reduce adherence）にある
86行は、他のリポジトリの目標にならない。 見えているのは「この環境では、常駐が目安の半分以下に保たれている」ことだけであり、それが適量であることは観測していない

数えることと、捨てることは別である

行数も割合も、反実仮想を回さずに見える。「だから効いている」は見えない。棚卸しが提供するのは前者だけである — 数字は、捨てる判断を助けるが、その代わりにはならない。

別名

呼称	出典
コンテキストの内訳表示（`/context`）	一次 — ただしこれは観測手段の呼称であり、本パターン（数えて、捨てる実践）の呼称ではない（出典は具体例節）
常駐物の棚卸し / Resident Context Inventory	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

公式が名前を与えているのは見る手段までである。/context は内訳を出すが、「この項目は毎ターン読ませる価値があるか」とは訊かない。 道具は数字を出すところで止まり、捨てる判断は利用者の側に残る。失敗の制度記憶化の別名節と同じ構図である — あちらでは道具が入れ物を与えて中身を決めず、こちらでは道具が数字を与えて判断を決めない。名前が無いのは、いつも道具が終わるところから先である。

常駐物の棚卸し（Resident Context Inventory） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

Copilot CLI — 棚卸しが、そのまま製品機能になっている ​

VS Code — 外す操作と、見る場所 ​

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

他ツールでの対応物 ​

実運用での観測 ​

別名 ​

関連 ​