目次

「スキルを入れすぎるとコンテキストを圧迫する」——よく言われます。半分は正しく、半分は間違いです。

公式ドキュメントによれば、スキル一覧が使うのはモデルの文脈窓の1%という決まった予算で、いくらスキルを増やしてもそこで頭打ちになります。膨らまないのです。かわりに起きるのは「呼ばれなくなる」こと——予算からあふれると、Claude Code は呼び出し回数の少ないスキルから説明文を削り、名前だけを残します。説明文が消えたスキルは、あなたの依頼と結び付かなくなります。

エラーは出ません。遅くもなりません。ただ静かに、使われなくなるだけです。この記事は、それを含めて「いま何がコンテキストを占めているのか」を推測ではなく数字で見る方法と、見たあとに何から削るかを扱います。

スキルを増やしたとき、何が起きるか

一覧の予算は文脈窓の1%で固定。あふれた分はトークンではなく「説明文」が削られる

予算の中
全部が説明文つき

名前＋説明が丸ごと載る。依頼の言い回しが多少ずれても、キーワードで拾われる

あふれた直後
使わない順に説明が消える

よく使うスキルは全文が残る。たまにしか使わないものから説明を失う

名前だけになると
存在するのに選ばれない

一覧には残る。しかし何のためのものか分からないので、依頼と結び付かない

出典: Claude Code 公式ドキュメント「Skills」

1. スキルは無限には膨らまない——1%の予算で頭打ちになる

Claude Code は、どんなスキルが使えるかを Claude に知らせるため、スキルの名前と説明の一覧をコンテキストに載せます。ここで効いてくるのが予算です。公式ドキュメントは「一覧には常にすべてのスキル名が入るが、スキルが多い場合、Claude Code は一覧の文字数予算に収まるよう説明を短くする」と書き、その予算を「モデルの文脈窓の1%」と定めています。

数字にすると分かりやすい。文脈窓が100万トークンのモデルなら、スキル一覧に割かれるのはその1%です。残り99%は会話・ファイル・ツール結果のためにある。スキルを50個入れても100個入れても、この1%は動きません。

では増やした分はどこへ行くのか。説明文が削られます。公式は削る順番まで明記しています——「一覧があふれると、Claude Code は呼び出し回数の少ないスキルから説明を落とし、よく使うスキルは全文が残るようにする」。

ここが実務上いちばん怖いところです。被害を受けるのは「たまにしか使わないスキル」で、それはたいてい「忘れた頃に必要になるスキル」と同じものだからです。四半期に一度の移行手順、年に数回のリリース作業——まさにそういうものが、最初に説明文を失います。

予算は変えられます。skillListingBudgetFraction に文脈窓に対する割合を書けば（例: 0.02 で2%）、一覧に使う枠を広げられます。1件あたりの説明文にも上限があり、説明と発動条件を合わせて1,536文字が既定です（skillListingMaxDescChars で変更可）。公式が「主要な用途を先頭に書け」と勧めているのは、この上限で後ろが切れるからです。

2. 測る道具は3つ——役割が違う

推測をやめて数字を見るための道具は3つあります。/context は以前からありますが、/usage のプロンプトキャッシュ行は v2.1.251（2026年8月28日）、/skill-doctor は v2.1.252（8月31日）で入った新しいものです。役割が違うので、3つとも覚えておく価値があります。

/context
いま何が入っているか

占有している中身の内訳を出す。Skills の行は予算適用後の大きさを報告するので、モデルが実際に受け取る量と一致する

/usage
それが何を消費したか

セッションのトークンと費用に加え、プロンプトキャッシュの状態と、スキル・サブエージェント・MCPサーバー別の使用量配分を出す

/skill-doctor
どれが元を取っているか

スキルごとのコストと呼ばれた頻度を出し、一度も呼ばれていないものに印を付ける。切る場所まで案内する

順番があります。/context で内訳を見て、/usage でそれが実際にいくら使ったかを確かめ、/skill-doctor で削る候補を特定する。逆から入ると、削る根拠がないまま消すことになります。

なお /context の Skills 行については、公式が過去の挙動まで書いています——v2.1.196 より前は全説明文の文字数を数えており、設定した予算の何倍もの値を表示することがあった。古い記憶で「スキルがコンテキストを食っている」と思っている場合、その数字自体が実態より大きかった可能性があります。

3. 使われていないスキルを名指しさせる

/skill-doctor は Claude Code v2.1.252（2026年8月31日）以降で使えます。公式の説明は「各スキルのコストと呼ばれる頻度を見て、どれを切るか決められる」。挙動でおさえておくべき点が4つあります。

/skill-doctor の前提

  • 対話セッションでは /plugin マネージャの Stats タブに開く。 -p を付けた非対話モードではテキストで出力される
  • 同梱スキルと組織配布スキルは対象外。 自分で足したものだけが並ぶ
  • 一度も呼ばれていないスキルには印が付き、どこで切るかまで表示される
  • スマートフォンやブラウザからのリモート操作では実行できず、エラーが返る

結果の読み方はひとつだけ意識しておくと迷いません。「一度も呼ばれていない」は「不要」と同義ではありません。前節のとおり、呼ばれない理由が説明文を削られて見つけてもらえないからという場合があるからです。

切る前に、そのスキルを名指しで呼んでみるのが確実です。名指しなら動くのに自動では選ばれない、というときは、不要なのではなく説明文が予算に負けている。対処は削除ではなく、説明の書き直し（主要な用途を先頭へ）か、予算の引き上げです。

4. 容量より効くのはキャッシュミス

ここからは、コンテキストの「大きさ」とは別の軸の話です。同じ大きさの会話でも、キャッシュが効いているかどうかで請求はまるで違います。

Claude Code v2.1.251（2026年8月28日）以降、/usage のセッション欄にプロンプトキャッシュの行が出ます。公式が載せている実例はこうです。

Prompt cache (main):   14 requests · 91% of input tokens from cache ·
2 misses (last 6m 10s ago, 310.2k tokens re-cached) ·
1 expected rebuild (compaction or tool-result clearing) ·
warm (1h TTL, last activity 40s ago)

読み方の要点は3つです。

MISSES
5% かつ 2,000トークン

キャッシュから読めたはずの内容を、この量を超えて読み直した要求がミスとして数えられる。少しの差し替えではミスにならない

EXPECTED REBUILD
自分で壊した分

コンパクトや古いツール結果の消去で Claude Code 自身が会話を書き換えたときは、ミスではなく予期された再構築として別に数える

WARM / COLD
寿命の内か外か

キャッシュ済みの前半部分がまだ生きているか。冷えている場合はどれだけ放置していたかが表示される

v2.1.260 以降は、直近のミスに心当たりがある場合その原因まで書きます（例: likely cause: tool definitions changed）。MCPサーバーを足した・スキルを入れ替えた——といった変更は、会話の先頭に近い部分を書き換えるので、その後ろ全部のキャッシュを無効にします。「作業を始める前に構成をいじる」のが安い理由がこれです。

ひとつ注意点があります。この行が見ているのはメインの会話だけで、サブエージェントは含みません。サブエージェントに重い処理を投げる運用をしている場合、ここの数字は全体像ではありません。

5. キャッシュの寿命は1時間とは限らない

ここは請求に直結するのに、あまり知られていません。プロンプトキャッシュの寿命は、契約形態と状況で変わります。

サブスクリプション
1時間

昼休みを挟んでも、戻ってきたときにキャッシュが生きている

追加利用枠を使い始めた後／APIキー・クラウド経由
5分

少し席を離れただけで冷える。次の1通が全文脈を読み直す

出典: Claude Code 公式ドキュメント「Manage costs effectively」（キャッシュ寿命の規定）

公式は「寿命はサブスクリプションでは1時間で、追加利用枠（usage credits）を使い始めると5分に下がる。APIキーやクラウドプロバイダ経由では既定で5分」と書いています。上限に達して追加枠に入った瞬間、キャッシュの寿命が12分の1になる——つまり「上限に達したあと」は、単価が変わるだけでなくキャッシュの効き方も変わります。なお、追加利用枠を使いながら1時間の寿命を保つ方法として、公式はTTLを自分で指定する手段を案内しています。

6. MCPは既定で遅延読み込み。それでもCLIが軽い理由

「MCPサーバーを入れるとコンテキストを食う」も、いまは前提が変わっています。公式によればMCPのツール定義は既定で遅延読み込みされ、Claude が特定のツールを使うまではツール名とサーバーの説明しかコンテキストに入りません。

それでも公式はgh・aws・gcloud・sentry-cli のようなCLIツールのほうが依然としてコンテキスト効率が良いと書いています。理由は明快で、CLIはツール一覧をまったく追加しないからです。Claude はコマンドを直接実行できるので、名前すら載せる必要がない。

実務的な結論はこうなります。同じことがCLIでできるなら、MCPを選ぶ理由はコンテキストの外側にあるべきです（認証の一元化、構造化された結果、権限制御など）。「なんとなく便利そうだから入れた」サーバーは、/mcp で一覧を見て切る候補になります。

7. 毎ターン必ず乗るもの——CLAUDE.mdと会話そのもの

スキルもMCPも条件付きで載りますが、無条件で毎回載るものが2つあります。

ひとつは CLAUDE.md。セッション開始時にコンテキストへ読み込まれるので、そこに書いたワークフロー手順は関係ない作業をしている間もずっと居座ります。公式は対策として「特定のワークフロー向けの詳細な指示はスキルへ移す」ことを勧め、「CLAUDE.md は200行以下を目安に、要点だけ」という具体的な目標まで示しています。スキルは呼ばれたときだけ読み込まれるので、同じ内容でも常時負担にならないという理屈です。

もうひとつは会話そのもの。公式の説明が的確です——「Claude Code は毎回の要求で会話全体を送り、Claude がツールを使うたびに、そのツール結果を載せた別の要求をまた送る」。だから一日じゅう開いていたセッションでの一行の質問も、会話全体ぶんの使用量を引き起こします。キャッシュがあるので単価は下がりますが、ゼロにはなりません。

ここが /clear と /compact の使い分けに直結します。公式は「/compact は要約する対象の会話を読むので、大きな文脈のコンパクトはそれ自体が大きな要求になる。継続ではなく仕切り直しが欲しいなら /clear はコストがかからない」と書いています。「とりあえずコンパクト」は無料ではありません。押しどころの判断はClaude Codeの/compactは手動で定期的にやるべきかで詳しく扱っています。

8. 何もしていないのに使用量が伸びる

「席を外していただけなのに使用量が進んでいる」——これには具体的な理由があり、公式が列挙しています。いずれも共通して「アイドル中でも全文脈を送る新しいターンが始まる」という形をしています。

アイドル中に使用量を進めるもの

  • スケジュールされたタスク——セッションが遊んでいても間隔ごとに発火し、そのたび全文脈を送る
  • 他セッションからのメッセージ——アイドル時に新しいターンとして配送される。crossSessionInbound を hold にすれば保留できる
  • ゴールの経過確認——バックグラウンド作業の待ち中に確認のターンが立つ。プロンプトの合間に最大3回まで
  • エージェントチームの各メンバー——終了するまでトークンを消費し続ける
  • キャッシュの期限切れ——休憩明けの1通目が全文脈を読み直す

エージェントチームには具体的な倍率も示されています。公式は「エージェントチームはメンバーがプランモードで動くとき、通常のセッションの約7倍のトークンを使う」と書いています。各メンバーが自分の文脈窓を持つためで、人数にほぼ比例します。公式の推奨も明快で、メンバーには Sonnet を使い、チームは小さく保ち、終わったら落とす。

目安として、公式は企業導入での平均を1人あたり1稼働日 約$13、月$150〜250とし、利用者の90%は1稼働日あたり$30を下回ると書いています。自分の数字がこの帯から大きく外れているなら、上のどれかが効いている可能性があります。

9. 測ったあと、何から削るか

数字を見たら、効果の大きい順に手を付けます。公式が挙げている対策を、効果が出るのが早い順に並べ直すとこうなります。

今すぐ・無料
関係ない作業に移るとき /clear

古い文脈は以後の全メッセージで課金され続ける。/rename してから消せば後で /resume で戻れる

構成を1回直す
CLAUDE.md を200行以下へ

特定作業の手順はスキルへ移す。常時載るものが減り、全セッションに効く

出力を絞る
フックとサブエージェント

1万行のログを読ませる代わりに、フックが該当行だけ返す。冗長な処理はサブエージェント側に閉じ込める

単価を下げる
モデルと思考量を仕事に合わせる

大半のコーディングは Sonnet で足りる。単純な作業は /effort で思考量を下げる

順番に意味があります。1番目は今日から効いて、しかもタダ。2番目は一度直せば全セッションに効きます。3番目と4番目は設定と習慣の話なので、効くまでに少し時間がかかります。スキルの削除が上位に来ていないのは、前節までで見たとおり、そこが最大の要因になることは実は多くないからです。

逆に、いじる前に測るべきという一点だけは動きません。公式の /usage は、直近の使用量の10%以上を占める挙動に印を付けます（長すぎる文脈、キャッシュミスなど）。印が付いていないものを削っても、体感は変わりません。

FAQ

Q1. スキルは何個までなら安全ですか。
個数に上限はありません。効いてくるのは一覧の文字数予算（文脈窓の1%）に収まるかです。同じ10個でも、説明が長ければあふれ、短ければ収まります。個数を数えるより /context の Skills 行と /skill-doctor を見るほうが正確です。

Q2. 一度も呼ばれていないスキルは消していいですか。
消す前に、名指しで呼んでみてください。名指しなら動くのに自動では選ばれないなら、不要なのではなく説明文が予算に負けています。その場合の対処は、削除ではなく説明の書き直し（主要な用途を先頭へ）か予算の引き上げです。

Q3. /compact をこまめに押せば安くなりますか。
なりません。コンパクトは要約する会話を読むので、大きな文脈ではそれ自体が大きな要求になります。継続が要らない場面なら /clear のほうが安く（コストゼロ）、確実です。

Q4. キャッシュのヒット率はどれくらいあれば良いですか。
公式は合格ラインを示していないので、絶対値ではなく変化を見てください。同じ作業の仕方で率が落ちたなら、直前に構成（MCP・スキル・ツール定義）を変えた可能性が高い。v2.1.260 以降は行が原因を推定して表示します。

Q5. MCPサーバーは減らすべきですか。
ツール定義は既定で遅延読み込みなので、置いてあるだけの負担は以前より小さいです。ただし同じことが gh のようなCLIでできるなら、CLIのほうが軽い（ツール一覧を一切追加しない）。使っていないサーバーは /mcp で切れます。

Q6. サブエージェントを使えばコンテキストは節約できますか。
できます。公式も冗長な処理（テスト実行、ドキュメント取得、ログ処理）はサブエージェントに委ね、詳細はそちらの文脈に留めて要約だけ戻すことを勧めています。ただし /usage のキャッシュ行はメイン会話しか見ていないので、サブエージェント中心の運用ではその数字は全体像になりません。

Q7. /skill-doctor が使えません。
Claude Code v2.1.252 以降が必要です。またスマートフォンやブラウザからのリモート操作では実行できず、エラーが返ります。対話セッションでは /plugin マネージャの Stats タブに開くので、テキスト出力が欲しい場合は -p を付けた非対話モードで実行してください。

出典