Skills を60個持つと Context は埋まるのか、SKILL.md 81万字を測った

Skills を増やしていくと、そのうち Context Window が埋まるのではないか。手元の Skills が60個まで増えたところで気になったので、60個を全部測って、公式ドキュメントの記述と突き合わせました(測定は2026年9月時点)。

結論から言うと、埋まりません。60個の SKILL.md 本文は合計81万字あって、tokens に直すと 200k Context の2倍を超えます。それでも埋まらないのは、Claude Code 側に「全部は載せない」機構が3つあるからです。数字より、その3つのほうが本題でした。

稼働率(60個のうち何個が実際に呼ばれているか)、CLAUDE.md のサイズ論、Context Window 長と精度の議論とは別軸の話です。測定は find と wc だけで、5分かかりません。

測り方

対象は 2026年9月時点の sns-operations/.claude/skills/ です(その後も増えているので、現在の数字は少し違います)。ディレクトリは62個ありますが、うち2個は他リポジトリへのシンボリックリンクで、下のコマンドは辿らないので対象は60個になります。

find ~/repos/sns-operations/.claude/skills -name "SKILL.md" -exec wc -m {} + | tail -1

wc -c ではなく wc -m です。日本語混在だとバイト数と文字数がずれます(手元では 1,165,892 バイト vs 812,844 文字、約1.4倍)。SKILL.md は英語主体なのでこの倍率で済んでいますが、日本語比率が上がると最大3倍まで開きます。文字数で測らないと、以降の tokens 換算がまるごとずれます。

tokens は「1文字 ≈ 0.5 tokens」で換算しました。日本語は1文字1 token に近く、英語はもっと効率が良いので、JP/EN 混在の SKILL.md ではこの係数は控えめな見積もりです。つまり以下の数字は、実際にはもう少し大きく出ます。

description のほうは frontmatter を抜き出す必要があるので、こちらを使いました。複数行の description と、argument-hint: のようにハイフンを含む次キーの両方を正しく扱わないと、値が過大に出ます(実際、私はこれを踏んで一度2割ほど多く数えました)。

find .claude/skills -name SKILL.md -exec awk '
  /^---$/ {f++; next}
  f==1 && /^description:/ {d=1; sub(/^description:[ \t]*/,""); printf "%s", $0; next}
  f==1 && d && /^[A-Za-z][A-Za-z0-9_-]*[ \t]*:/ {d=0}
  f==1 && d {printf " %s", $0}
' {} \; | wc -m

実測 — description は軽く、本文は重い

対象	合計	平均
frontmatter の description	12,252 字	204 字/skill
SKILL.md 本文	812,844 字	13,547 字/skill
SKILL.md 行数	23,186 行	中央値 336 行
tokens 換算 (description)	約6,100 tokens	102 tokens/skill
tokens 換算 (本文)	約40万 tokens	6,800 tokens/skill

最も重い SKILL.md は45,716字(avoid-ai-writing-es、約22,900 tokens)、最も軽いのは858字(notify)でした。50倍以上の開きがあります。

description の合計は約6,100 tokens で、200k Context の 3.1%。60個持っていても、この分だけなら誤差の範囲です。

一方、本文の合計は約40万 tokens。200k Context の2倍以上で、そもそも一度に載りません。

公式が持っている3つの機構

公式ドキュメント(Claude Code Skills)には、Context を守る機構が3つ書かれています。

1. 本文は呼び出したときだけ載る

In a regular session, skill descriptions are loaded into context so Claude knows what's available, but full skill content only loads when invoked.

起動時に載るのは description だけ。本文は呼び出し時です。40万字が常時載ることはありません。なお description は when_to_use と合わせて 1,536文字で truncate されます(手元の60個はすべて下回っていました)。

2. 同じ skill を呼び直しても二重に載らない

When Claude re-invokes a skill whose rendered content is identical to the copy already in context, Claude Code adds a short note that the skill is already loaded rather than a second copy of the content.

同一内容の再呼び出しは、本文のコピーではなく短い注記に置き換わります。「呼んだ回数 × 本文サイズ」で積み上がるわけではありません。

3. compaction 後の再アタッチには 25,000 tokens の上限がある

When the conversation is summarized to free context, Claude Code re-attaches the most recent invocation of each skill after the summary, keeping the first 5,000 tokens of each. Re-attached skills share a combined budget of 25,000 tokens. Claude Code fills this budget starting from the most recently invoked skill, so older skills can be dropped entirely after compaction if you have invoked many in one session.

これが決定打です。compact を挟んだあと、再アタッチされる各 skill は先頭5,000 tokens に切り詰められ、その上で全体が合計25,000 tokens の予算を共有し、直近に呼んだものから順に詰められて、溢れた古い skill は丸ごと落ちます。

手元の skill を実効サイズ(min(size, 5,000 tokens))で測ると平均約3,900 tokens なので、25,000 tokens は再アタッチで最大5〜6個分です。1個あたりが5,000 tokens 上限で刻まれるので、6,800 tokens の重い skill でも、compact 後に残るのは頭の5,000 tokens だけになります。

「全部載って埋まる」が起きにくい理由

3つを踏まえると、単純累積の見積もりは成立しません。

たとえば1セッションで10個の skill を呼んだ場合、素朴に計算すれば 6,800 × 10 = 68,000 tokens(200k の34%)ですが、実際には

• 同じ skill を何度も呼んでいれば、2回目以降は注記だけで積み上がらない
• compact が挟まれば、25,000 tokens の予算まで圧縮されて古い分は落ちる

ので、この数字は上限であって実測値ではありません。「60個全部呼んだら Overflow する」も同じ理由で起きにくい。登録数を数えても、呼び出し回数を数えても、Context の埋まり具合は説明できません。効くのは compact を挟まない区間で、直近に呼んだ数個の本文がどれだけ大きいか だけです。

だから対策は「1個あたりの本文を小さく保つ」に尽きます。登録数をいくら削っても、重い skill が1個残っていれば予算は同じだけ食われます。25,000 tokens の予算を、5,000 tokens 上限で刻まれた重い skill 5個で使い切るのか、2,000 tokens の skill 12個で回せるのかの差です。5,000 tokens を切っておくと truncate されず、そのまま予算に載ります。

公式推奨で自分の60個を監査したら、18個が違反していた

公式には具体的な上限が1つ書かれています。

Keep SKILL.md under 500 lines. Move detailed reference material to separate files.

この基準で手元の60個を測りました。

find .claude/skills -name "SKILL.md" -exec wc -l {} \; | awk '$1>500'

-exec ... + ではなく -exec ... \; を使っています。+ だと最後に合計行が付き、その値(23,186)も500超として数えてしまうためです(日本語ロケールでは total ではなく 合計 と出るので grep -v total では消せません)。

結果は 18個が500行超。合計23,186行、中央値336行に対して、最長は ship-x の1,178行でした。中央値は基準内なのに、上位が大きく伸びている分布です。

500行を超えた skill に共通していたのは、次の3つでした。

• 実例コードや出力サンプルをインラインで大量に持っている
• 言語・プラットフォーム別の分岐が多い(検出ルール、書き換え例、false positive 例)
• 手順が20以上のフェーズに分かれ、各フェーズに詳細な指示がある

上位の重い skill は、そのまま「25,000 tokens の予算を5,000 tokens 分食いつつ、頭切りで末尾の情報が落ちる候補」です。監査の優先順位としては、登録数を数えるより、この超過リストを見るほうが直接効きます。

Context を小さく保つ3パターン

パターン1: reference ファイルに切り出す

公式が明示的に推奨している形です。

Skills can include multiple files in their directory. This keeps SKILL.md focused on the essentials while letting Claude access detailed reference material only when needed.

SKILL.md 本文には概要と手順だけを置き、詳細なテンプレートや検出ルール表は reference/*.md に出して、必要なときだけ読ませます。検出ルールやテンプレート集を持つ skill は、切り出すかどうかで本文サイズが数倍変わります。

パターン2: 言語別・用途別に分割する

avoid-ai-writing 系のように言語ごとの分岐が大きい skill は、-ja -en -pt -es -ko に分けたほうが軽くなります。実際、手元の最重量45,716字も avoid-ai-writing-es でした。分割すると、その記事に必要な言語のぶんだけが載ります。detect と rewrite のペアに分けるのも同じ発想です。

パターン3: 重い skill から順に潰す

平均を見ても意味がありません。中央値336行に対して最長1,178行という分布なので、上位数個を削るだけで合計が大きく動きます。500行超の18個をリスト化して、上から reference 切り出しを当てるのが最短です。

CI に入れる

1個あたりのサイズは放っておくと伸びるので、機械に見張らせます。

# 500行を超えた SKILL.md があれば落ちる
find .claude/skills -name "SKILL.md" -exec wc -l {} \; \
  | awk '$1>500 {print; f=1} END {exit f}'

合計サイズより、1個あたりの上限を見るほうが実態に合っています。合計が大きくても全部が同時に載ることはなく、効くのは「直近に呼ばれた数個の大きさ」だからです。

検算 — 別リポジトリでも測る

harness-ops 側の SKILL.md も測りました。27個で合計145,959字、平均5,406字。sns-operations 側の平均13,547字に対して4割です。

用途が違うと平均サイズも変わります(harness-ops は cron オーケストレーション、sns-operations は記事執筆補助で分岐と実例が多い)。リポジトリをまたいで同じ基準を当てると、どちらが太っているかがすぐ出ます。

まとめ

• SKILL.md 60個の本文は合計812,844字(約40万 tokens、200k Context の2倍以上)。それでも埋まらない
• 起動時に載るのは description だけで、合計12,252字 = 約6,100 tokens = Context の3.1%
• 本文は呼び出し時ロード、同一内容の再呼び出しは二重に載らない、compact 後の再アタッチは各 skill が先頭5,000 tokens に切られた上で合計25,000 tokens 上限、古い順に落ちる
• 25,000 tokens は手元の実効サイズで5〜6個分。ここで効いてくるのが1個あたりの本文サイズで、5,000 tokens を超えると頭が切られる
• 公式は「SKILL.md は500行以内」。手元の60個を測ったら18個が超過、最長1,178行だった
• 測るときは wc -c ではなく wc -m。日本語混在だとバイト数と文字数がずれる(SKILL.md 60個では 1.4倍、純日本語なら最大3倍)

Skills は持っているだけでは食いません。数を絞る前に、500行超のリストを出して、上から reference に切り出す。これだけで Context の心配はほぼ消えます。

Skills の設計と運用は、書籍のほうで章を割いて扱っています。

Claude Code Mastery

参考

• Anthropic 公式: Claude Code Skills
• 測定コマンド: find ~/repos/sns-operations/.claude/skills -name SKILL.md -exec wc -m {} +