スキルを入れすぎて重くなる仕組み｜470 件を実測した文脈の予算

まず結論

説明文の中央値（入れた全件ぶん、常に載る）

373 文字

本文の中央値（発動したとき丸ごと載る）

7,922 バイト

収録中で最大の本文

235,809 バイト

本文から別の .md を参照しているスキル

200 件（43%）

スキルを入れると、2 種類のコストが別々にかかります。

つまり入れた数が効くのは説明文で、当たり外れが大きいのは本文です。

470 件の実測から出る目安

収録 470 件の実測値から、目安はこうなります。

• スキルを 20 件入れると、説明文だけで常時 7,000 文字前後
• そのうち 1 件が発動すると、さらに 8,000 バイト前後が載る
• ただし本文には 235,809 バイト（収録中の最大）のものもある

以下は 2026年9月19日時点、収録 470 件の SKILL.md を機械的に読んだ結果です。

説明文は常に載る

起動時に全スキルぶん読まれる

エージェントは起動時に、入っている全スキルの name と description を読みます。どれを使うか判断するために必要なので、発動しなくても載ります。共通の仕様も、この 2 つは起動時に全スキルぶん読み、本文は発動したときに丸ごと読む、と定めています（2026-10-09 確認）。

収録 470 件の description を測りました。

中央値 373 文字は想像より長い

中央値 373 文字は、多くの人の想像より長いはずです。理由はSKILL.md の書き方に書いたとおりで、description は紹介文ではなく呼び出しの条件式として書かれているためです。

入れた数でどう増えるか

実際の値で見ると、総合上位 20 件を全部入れた場合は 7,164 文字でした。概算とほぼ一致します。

収録 470 件を全部入れると 192,396 文字です。現実的な話ではありませんが、上限の感覚としては持っておいてよい数字です。

説明文は削るところではない

ここが大事なところです。説明文を短くして節約しようとしないでください。

説明文を削ると、そのスキルが呼ばれなくなります。呼ばれないスキルは入れている意味がないので、文脈は消費したまま効果がゼロになる、一番損な状態です（スキルが呼ばれないときの直し方）。

入れすぎると、実行環境が説明文を落とす

説明文の一覧には上限があります（どちらも公式ドキュメント、2026-10-09 確認）。

説明文が外れたスキルは、名前しか手がかりが無くなり、呼ばれにくくなります。入れすぎの害は、文脈が減ることだけではありません。

本文は発動したときに丸ごと載る

分布の裾が極端に長い

こちらが効き方の大きいほうです。

分布の裾が極端に長い。90% 点は中央値の約 3 倍、最大は中央値の約 30 倍（90% 点の約 10 倍）です。

特に厚い 8 件

どちらも frontmatter を除いた本文のバイト数です。10 月 22 日の原本では、design-taste-frontend が 38,458 バイト、huashu-design が 15,558 バイト（どちらもファイル全体）に縮み、詳しい中身は同梱の資料に移りました。imagegen-frontend-mobile は、公開元が 10 月 19 日に別のリポジトリ（Leonxlnx/imagegen-skills）へ移しました。各スキルの解説ページはファイル全体の大きさを書いているので、数百バイト大きく出ます。claude-api は 3 週間で約 17,000 バイト増え、2 位に上がりました。wonda-cli は 2026-10-22 に原本で測ると 250,076 バイトで、さらに増えていました。talking-head-recut は 2026-10-21 に公開元が配布をやめています。

32KB を超える 17 件で 1MB

32KB を超えるものは 17 件で、その合計は 1,006,794 バイトです。17 件で 1MB。この 17 件を全部入れて全部発動させると、それだけで会話の余地がほとんど残りません。

9 月 19 日時点で、wonda-cli の 235,809 バイトは収録中で唯一 100KB を超えており、2 位の 2.7 倍でした。10 月 9 日には claude-api も 100KB を超え、差は 2.4 倍です（claude-api は 10 月 17 日に 105,146 バイト）。wonda-cli は使うのに Wonda の有料プランが要るので、入れる前に解説で前提を確かめてください。詳しくは動画・画像を作るスキルの選び方に書いています。

厚い本文が悪いわけではない

厚いこと自体は品質の問題ではありません。参照すべき情報が本当に多い領域はあります。

問題になるのは意図せず発動したときです。別の作業をしているのに、説明文が広すぎて引っかかり、40KB の本文が載る。これが一番もったいない消費です。

段階的に読ませる作りが効く

本文には振り分けだけを書く

厚さの問題を、作り手の側で解いているスキルがあります。本文には振り分けだけを書き、詳細は別ファイルに置いて、必要になったときだけ読ませる方式です。

実測では 470 件のうち 200 件（43%）が、本文から別の .md を参照しています。

いちばん徹底しているのは Remotion 系

remotion-best-practices の解説ページにある 4,215 バイトは、frontmatter を含めたファイル全体の大きさです。

入口の remotion-best-practices は「新規作成なら remotion-create/REFERENCE.md を読む」のように条件ごとに読む先を指しているだけです。

1KB 未満の 23 件のうち 12 件が別ファイルを参照

本文が 1KB 未満のスキルは 23 件あり、そのうち 12 件が別ファイルを参照しています。残りの 11 件は単に短いスキルです。

自分でスキルを書くなら、この形を真似する価値があります。書き方はSKILL.md の書き方にまとめています。

リポジトリ単位で入れると何が起きるか

大きな公開元は 1 つのリポジトリに多数のスキルを置いています。まとめて入れると、説明文が全部常時載ります。

heygen-com/hyperframes は 2026-10-21 に公開元が 14 件を廃止し、配っているのは 7 件です。2026-10-22 に原本で測ると、7 件の本文は合計 39,619 バイトでした（heygen-com/hyperframes の地図）。

件数が近くても重さは 5 倍以上違う

mattpocock/skills は 35 件で 5,269 文字、coreyhaines31/marketingskills は 43 件で 29,415 文字。合計で 5.6 倍、1 件あたりでは 150 文字対 684 文字（約 4.5 倍）です。

短すぎる説明文にも問題がある

googleworkspace/cli の 15 件は合計 684 文字。1 件あたり 46 文字で、極端に短い。短すぎる説明文は呼ばれない側の問題を抱えます。

手動呼び出しに寄せる

disable-model-invocation で自動の発動を止める

意図しない発動を止める仕組みが frontmatter にあります。

disable-model-invocation: true

これを付けると自動では呼ばれなくなり、/名前 で手で呼ぶ形になります。Claude Code の拡張項目です。

mattpocock/skills の説明によれば、この印を付けたスキルは、エージェントに渡す一覧そのものから外れます（2026-10-09 確認）。自動で呼ばれない代わりに、説明文の分の文脈も使いません。

使っているのはほとんど mattpocock/skills

実測では 470 件のうち 23 件が使っていて、そのほとんどが mattpocock/skills でした。

• wayfinder課題管理システムに地図と子課題を作る
• triage課題と外部 PR にラベルを付けてコメントを投稿する
• setup-matt-pocock-skills課題管理システム・ラベルの語彙・ドメイン文書の置き場をリポジトリに設定する

並びを見ると方針が読める

どれも外部に書き込むか、作業の流れを支配するスキルです。意図せず発動すると困るものを手動に寄せています。

user-invocable という項目もありますが、使っているのは 7 件で、false（メニューから隠す）にしているのは 2 件だけです。

自分で書くスキルなら、影響の大きいものには付ける価値があります。

削るときの順番

実測を踏まえると、こうなります。

1. 使っていないスキルを消す説明文が常時載っているだけの状態
2. 本文が厚くて、たまにしか使わないものを外す使う会話だけで入れ直す
3. リポジトリ単位で入れたものを、工程単位に絞る使う工程のものだけ残す
4. 影響の大きいものに disable-model-invocation を付ける自作スキルの場合
5. 説明文は削らない削ると呼ばれなくなる

よくある質問

何件までなら入れて大丈夫ですか

件数では決まりません。説明文の合計と、本文の厚さで決まります。

実測でいうと、googleworkspace/cli の 15 件（合計 684 文字）と coreyhaines31/marketingskills の 43 件（合計 29,415 文字）では、43 倍の差があります。

目安を 1 つ出すなら、説明文の合計を把握しておくことです。入れているスキルの SKILL.md の frontmatter を見れば数えられます。

バイト数はトークン数にどう換算できますか

正確な換算はできません。使うモデルの分割器によって変わり、英語と日本語でも比率が違います。

この記事がバイトと文字数で書いているのはそのためです。桁の感覚を持つための数字として読んでください。「90% 点は中央値の約 3 倍、最大は約 30 倍」という比率のほうが判断に使えます。

発動していないスキルの本文は載りませんか

載りません。エージェントは説明文を読んで使うと判断したときに本文を読み込みます。

ただし「発動しない」と「発動しないはず」は違います。説明文が広すぎるスキルは、関係のない依頼でも引っかかります。そこが意図しない消費の入口です。

原因の切り分けはスキルが呼ばれないときの直し方の逆側として読めます。

同梱ファイルは文脈に載りますか

参照されたときだけです。実測では同梱ファイルの中央値は 2 件、平均 10 件。多いものは次のとおりです。

上の 2 件を「200 以上」と書いているのは、当サイトの取り込みが一覧を 200 件で打ち切っているためです。実際は 200 件より多い可能性があります（件数だけは打ち切らずに数えています）。

何件あっても、全部が文脈に載るわけではありません。本文が名指しした資料だけが読み込まれます。これが段階的に読ませる作りの利点です。

この数字はどうやって数えましたか

当サイトが GitHub から取得して保存している 470 件の SKILL.md を機械的に読みました。2026年9月19日時点です。

• description は YAML のブロック記法（> |）を展開してから文字数を数えています
• 本文は frontmatter を除いたあとのバイト数です
• 「別ファイルを参照」は本文中の Markdown リンクに .md が含まれるものです
• 同梱ファイルの一覧は 200 件で打ち切って保存しています。件数だけは打ち切らずに数えているので、一覧と件数は一致しないことがあります
• リポジトリ単位の合計は、当サイトが収録しているスキルだけの合計です（収録は上位 500 件と編集部による追加収録なので、そのリポジトリの全スキルとは一致しません）