この15,000文字という予算は、すべてのClaudeCodeバージョンで同じですか？
この数字は現行バージョンのデフォルト値であり、Skill機能がリリースされた当初から固定されていたわけではない。この種のシステムレベルの予算上限は、ClaudeCodeのバージョン更新の中で比較的調整されやすいパラメータの一つで、コミュニティでもバージョンによってこのしきい値がわずかに変動していることが観察されている。固定された数字を覚えるより、--debugや/doctorで実際にチェックする習慣を身につける方が確実だ——そうすれば、公式が将来この上限をどう調整しても、あなたの調査方法が古くなることはない。
予算上限を引き上げれば、この問題は永久に解決しますか？
予算を引き上げることは問題の再発を先延ばしにするだけで、永久的な解決策ではない。この上限がそもそも存在する理由は、本質的にシステムプロンプト自体の品質を守るためだ——上限がまったくなければ、数百のSkillを稼働させているユーザーは、Skillリストそのものだけでかなりのコンテキスト空間を消費し、実際にタスク処理に必要な内容を押しのけてしまう可能性がある。上限を引き上げるということは、「この空間をどのSkillに割り当てるか」という判断責任を、システムの自動削除メカニズムから自分自身へと移すことを意味する——引き上げた予算を実際に活かすには、依然としてインストール済みリストを定期的に見直し、もう使わないSkillを能動的に整理する必要がある。そうしなければ、拡大した予算も新しいSkill群にすぐ埋め尽くされてしまう。
説明が削除される以外に、インストールしたはずのSkillがトリガーされない原因には何がありますか？
説明の予算超過はその原因の一つに過ぎない。コミュニティがまとめたよくある原因には他にも、YAMLフロントマター冒頭の---マーカーの前に余分な空白やテキストがあり、ファイル全体がフロントマターなしとして扱われてしまうケース、説明内に引用符のないコロンがあってYAML解析が失敗するケース、説明自体が曖昧すぎてユーザーが実際に使う言い回しをカバーしていないケース、そして異なるインストール場所（例えば個人レベルとプロジェクトレベル）に同じ名前だが内容の異なるSkillが存在し、実際に有効になっているバージョンが編集しているつもりのものと違うケースなどがある。
これらの原因はいずれも似たような現象を引き起こす——エラーメッセージはなく、Skillが静かに存在しないだけだ。そのため調査の際は、最初から説明の書き方が悪いと決めつけるのではなく、この順序でチェックしていくことが望ましい。
私はまだ3つか4つしかSkillをインストールしていませんが、この問題を心配する必要がありますか？
現時点で一桁台のSkillしかインストールしていないなら、説明の長さだけで15,000文字のしきい値に達することは通常考えにくい——各説明が異常に長くない限りは。この問題が表面化しやすいのは、十数個から二十個ほどのSkillやカスタムスラッシュコマンドを徐々に蓄積した場合、あるいは一度のインストールで十数個のサブスキルをまとめて導入するようなサードパーティ製のSkillバンドル（マーケットプレイスのパッケージなど）をインストールした場合だ。
現在の使用量がしきい値にまったく届いていなくても、新しくインストールしたSkillが--debugでシステムプロンプトに含まれているかを確認する習慣を身につけておく価値はある——そうすれば、実際に問題に遭遇する前に自分の調査ツールの使い方をあらかじめ理解でき、いずれSkillの数が本当に積み上がったときに、エラーメッセージが一切ない静かな障害に初めて直面することにはならない。
Skillをインストールし、YAMLフロントマターのdescriptionを具体的かつ文法的に正しく書いてテストしたのに、Claudeがまったくトリガーしない——エラーメッセージも警告もなく、対話上ではまるでそのSkillが最初から存在しなかったかのように見える。多くの人の最初の直感はdescriptionを書き直すことだが、実際の問題が別の場所にあるなら、何度書き直しても効果はない。
ClaudeCodeは対話開始のたびに、インストール済みのすべてのSkillとスラッシュコマンドのnameとdescriptionを一つのリストにまとめ、システムプロンプトに注入する。このリストには文字数の総予算上限があり、現在のデフォルト値は15,000文字（約4,000トークン）だ。インストール済みのSkillとコマンドの数が十分に多く、合計した説明の長さがこの上限を超えると、ClaudeCodeはエラーを出さず、画面上に何の警告も表示しない——単にリストから説明を削り始め、その削除の優先順位は、トリガー回数が最も少ないSkillから始まる。
この削除メカニズムは特に誤解を招きやすい結果を生む：まだ一度もトリガーされたことのない新規インストールのSkillは、トリガー履歴がゼロであるため、生まれながらにして削除リストの最前列に並ぶ。つまり、新しいSkillが正しく動作するかテストしたいと思うほど、予算超過によってシステムプロンプトにまったく載らなくなる可能性が高くなる——あなたが目にする「トリガーされない」は、最初から最後まで説明の書き方が不十分だったのではなく、Claudeが今回の対話でその説明をそもそも一度も見ていなかった、ということかもしれない。
これはもう一つのよくある疑問も説明する：同じSkillが昨日は問題なくトリガーされていたのに、今日突然動かなくなった理由だ。昨日から今日の間にSkillやコマンドをいくつか追加インストールしていれば、合計文字数がちょうど15,000文字のしきい値を超え、トリガー回数の少ないSkillがリストから押し出された可能性がある。この変動は画面上に何の表示もなく、Claude自体が「不安定になった」「賢さが落ちた」と誤解されやすい。
Skillがトリガーされない状況に遭遇した場合、公式ドキュメントが推奨する調査順序は、まずclaude --debugで起動してSkillの読み込み状態を確認するか、/doctorを実行して設定チェックを行い、そのSkillの説明が今回の対話でシステムプロンプトに実際に送られたかどうかを確認することだ——そもそも届いていないのであれば、descriptionをどんなバージョンに書き直しても効果はない。なぜなら問題はそもそもテキストの内容にはなかったからだ。説明が確かに届いており、Claudeがそれを読んだにもかかわらずトリガーされなかったことを確認できた場合にのみ、次に説明自体が十分に具体的か、ユーザーが実際に使う言い回しをカバーしているかを確認する段階に進む。
大量のSkillとコマンドを同時に稼働させる必要が本当にある場合、ClaudeCodeはこの予算上限を引き上げる環境変数を提供しており、より多くの説明がシステムプロンプトに含まれるチャンスを得られる。しかし単に上限を引き上げるだけでは、問題が再発するタイミングを先延ばしにするに過ぎない——Skillの数が増え続ければ、いずれまた予算を超過する。より根本的な対策は、インストール済みのSkillを定期的に棚卸しし、長期間トリガーされていないものや他のSkillと機能が重複しているものを削除し、予算を本当に使うSkillに回すことだ。
プロジェクトや個人環境にインストールされているSkillの数がすでに十数個を超えている場合、次の習慣を身につける価値がある：新しくインストールしたSkillの成否を「トリガーされるはずという感覚」だけで判断せず、実際に--debugや/doctorを使って、それがその対話のシステムプロンプトに含まれていたかを確認することだ。このチェックには1分もかからないが、「Skillがそもそも届いていない」のか「descriptionが十分に具体的でない」のかという、まったく異なる解決策を必要とする二つの問題を切り分けられるようになり、見当違いの箇所を何度も修正する事態を避けられる。