この記事は

初学者の個人的な学習記録が主な目的です。

同じ立場の人、これからエンジニアを目指している人に届けばと思って書いています。

⚠️ 楽しく書きたいので、所々言葉を崩しています、ご了承ください。

この記事は前回のスキル棚卸し記事「初学者による『AI Skillって全部把握できてる？』」の続編です。

もくじでち

TL;DR
きっかけ
Anthropicの新しいプラクティスを読んで固まった
「結局descriptionっていつ読まれるの？」を調べ直した
前提が間違っていたと気づいた
全部消して測った
ついでに、SkillSpectorの穴を見つけた
本当のまとめ
参考

TL;DR

1ヶ月前、スキル139個を把握するために SKILLS.md（人間向け説明書） と CLAUDE.mdへの14行追記 で解決した気になっていた
Anthropicが2026-07-24に「Claude Codeのシステムプロンプトを80%以上削除して性能低下なし」というプラクティスを打ち出し、自分がやったことの真逆だと気づいた
調べ直したら、前回の記事は同じ記事の中で矛盾していた。「nameとdescriptionが渡される」と書いた数段落後に「名前だけが渡される」と書いていて、結論は誤ったほうを採用していた
descriptionは常駐するが本文は発火時にしか読まれない。前提がここでズレていたので、SKILLS.mdもCLAUDE.mdの14行も「すでに払っているコストの上にもう一段払っていた」だけだった
実際に139個を精査して74個まで削り、164件→74件、9.9k→7.7kトークンまで下げた。ただし予測は5.4k削減のつもりで、2.5倍外れた
ついでにSkillSpector（NVIDIA製のセキュリティスキャナー）を拡張していて、.claude/settings.json の危険な設定は検出対象外だという穴を見つけた

きっかけ

1ヶ月前、「初学者による『AI Skillって全部把握できてる？』」という記事を書いた。

下記を実施

SkillSpector（NVIDIA製のセキュリティスキャナー）で139個全部スキャン
Opusで再精査する2段階フローを組んだ
名前だけじゃ何のスキルか分からない問題を、人間向けのフル説明書（SKILLS.md） と CLAUDE.mdへの一行説明14個の追記 で解決した

「これで安心して運用できるぞ」と思ってました。

んが！？

Anthropicの新しいプラクティスを読んで固まった

先週、Anthropicが出したこの記事を読んだ。

冒頭からいきなりこう書いてある。

We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.

（訳：Claude Opus 5やClaude Fable 5のようなモデル向けに、Claude Codeのシステムプロンプトを80%以上削除したが、コーディング評価において測定可能な性能低下はなかった）

🍥 「どういうことだってばよ」 🍥

私が1ヶ月前にやったのは、CLAUDE.mdにオラオラと追加しまくったという結果だけが残ったのだった。Anthropic様は真逆のことをやって、しかも性能が落ちなかったと言っている。

記事にはこうも書いてあった。

A common myth is that you want to make these a central repository for every known practice that you might run into, because Claude would not find it otherwise.

（訳：よくある誤解は、CLAUDE.mdやSKILL.mdを「知っているすべての慣習の中央リポジトリ」にしようとすることだ。そうしないとClaudeが見つけられない、と思い込んでいるからだが）

これ、まんま私です。SKILLS.mdを「全部載ってる説明書」として作った。名指しで「あなたですよ。そこのあなた」と言われている気分！

「結局descriptionっていつ読まれるの？」を調べ直した

ここで一度、自分の前回記事を読み返したところ、同じ記事の中で矛盾していたことに気づいた。

前半にはこう書いていた。

Claude Code が起動すると、インストール済みスキルの名前とdescriptionが system-reminder にまとめて渡される。

そして後半、まとめの直前にはこう書いていた。

Claude Code のスキルは名前だけが毎回読み込まれる。descriptions は Claude が推論できる、でも人間には読めない

なんか難しい言葉が交差してるので、簡単にいうと。

Claudeくんは、別にdescriptionを推論しない。ただ読んでるだけ。

ってことっす

公式ドキュメントを読むのが早い。うん。

該当箇所はこちら

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はcontextに読み込まれ、Claudeは何が使えるか把握している。ただしスキルの本文は、呼び出されたときにだけ読み込まれる）

前半が正しかった。 descriptionは毎セッション常駐する。本文（SKILL.mdの中身）だけが、発火したときに初めて読まれる。

Progressive Disclosure（段階的開示）のおさらい

セッション起動時：全スキルの name + description が常時ロードされる
発火したとき：そのスキルの SKILL.md 本文が読まれる
必要に応じて：references/ 配下の追加ファイルが読まれる

コンテキストを節約しながら必要なときだけ詳細を展開する設計、という理解自体は前回から合っていた。ただ「常時ロードされる範囲」を自分の中で取り違えていた。

前提が間違っていたと気づいた

descriptionが常駐しているなら、話は変わってくる。

「名前だけじゃ何のスキルか分からない」という前回の問題意識自体は正しい。でも、その解決策として SKILLS.md（人間向けの別ファイル） と CLAUDE.mdの14行追記 を作ったのは、筋が違っていた。

考えてみれば当たり前で、description はすでに常駐してAIに読まれている。人間にとって読みにくいとか以前に、読む必要がないという事実にやっとこさ気付いた。

理解をするのに、将来的な認知負荷を上げてしまったという失敗例。

そこで改めて、私はどれほどClaude君に強制読書をさせる毒親なんだろうと、親の前に人として成長するべく、罪を認めるところから再スタートしてく、計算してみることにした。

全部消して測った

/context というコマンドで、実際にどれだけのトークンをスキル一覧に払っているか見られる。

計測してみたら、こうだった。

Skills · /skills
└ 164 skills · 9.9k tokens

139個から164個に増えていた（1ヶ月の間にまた増やしていたらしい）。この9.9kトークンは全部description。SKILLS.mdの中身は数えられていない、これとは別に常時食っている分だ。

そこで、claude doctor（/doctor）という診断コマンドを走らせた。全プロジェクト・直近50セッション・生涯438起動を横断で見て、「一度も使われていないスキル」を洗い出してくれる。

結果、14個のスキルが生涯使用回数ゼロだと分かった。うち何個かは「まだ出番が来ていないだけ」の可能性もあったので、剪定！

節操のない親で申し訳ないと猛省。

と同時に、無効化した後、もう一度測った。

Before: 9.9k tokens・164 skills
After : 7.7k tokens・74 skills

件数は90件減ったのに、トークンは2.2kしか減らなかった。

原因を自分なりに考えたけどわからん！

わからんものはさっさとClaudeくんに考えてもらった。こちらでございます💁🏼

Q. 見積もりが2.5倍外れたのはなぜ？

/context の表には「合計トークン ÷ 件数」しか出ていません。当時これで単価を出しました。

9.9k トークン ÷ 164件 = 1件あたり 約60トークン

これを「消す90件」にそのままかけました。

60トークン × 90件 = 5,400トークン（5.4k）減るはず

でも実測は2.2kしか減りませんでした。原因は、削除した90件と、残した74件で、1件あたりの重さがまったく違ったからです。

	件数	実際の内訳	1件あたり
消した90件	fullstack-dev-skillsなど	「Django開発に使う」のような一行	約20〜50トークン
残した74件	自作スキル中心	用途・使うタイミングまで書いた長文	約104トークン

「60トークン」という平均値は、軽い90件と重い74件を混ぜて割った数字なので、どちらの集団にも当てはまりません。実際に消した90件は平均よりずっと軽かった。だから90件消しても、期待したほど減らなかった、という話です。

例えるなら、「クラス全体の平均身長170cm」を知っていても、「今日休んだ小学生5人の身長合計」を「170cm × 5人」で見積もったら外れます。休んだのが低学年ばかりなら尚更です。「消した90件」は、たまたま軽いスキルに偏っていた集団でした。

件数で見積もると外れる。 安いスキルを大量に消しても、削減額は小さい。次に同じことをやるなら、件数ではなくdescriptionの文字数の合計で見積もるべきだった。

そりゃそうだよね。こんな当たり前のことを聞いて、小学生を比喩に使ってくるあたり、私相当株下がってますね。

ついでに、SkillSpectorの穴を見つけた

同じ日、SkillSpector（前回の記事で使った、NVIDIA製のセキュリティスキャナー）を触る機会があった。

改めて見ると、検出範囲がすごい。

Security scanner for AI agent skills. Detect vulnerabilities, malicious patterns, and security risks before installing agent skills.

検出パターンの中身（クリックで展開）

私の手元の版（2026-06クローン）では、こう書かれている。

64 vulnerability patterns across 16 categories: prompt injection, data exfiltration, privilege escalation, supply chain, excessive agency, output handling, system prompt leakage, memory poisoning, tool misuse, rogue agent, trigger abuse, dangerous code (AST), taint tracking, YARA signatures, MCP least privilege, and MCP tool poisoning

※ 2026-07-26時点のGitHub最新版を確認したところ「68パターン・17カテゴリ」に増えていた。日々アップデートされているらしい。

根拠にしている論文も見つけた。

Based on research from "Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale" (Liu et al., 2026)
Dataset: 42,447 skills / Vulnerable: 26.1% / High-severity: 5.2%

4万件を超えるスキルを調べて、4件に1件は脆弱性ありという結果らしい。

prompt injection（プロンプト注入）もmemory poisoning（記憶汚染）もMCP tool poisoning（MCP経由の毒入れ）も見てくれる、なかなか本格的なツール。

でも、.claude/settings.json は見ていなかった。

Claude Codeには permissions.defaultMode という設定がある。これが acceptEdits になっていると、ファイル編集が確認なしで走る。しかもこの値、リポジトリの .claude/settings.json に書いておけば、git clone した人の環境でそのまま有効になる。

試しに手元の claude doctor の仕様書を読んだら、こう書かれていた。

only the VALUE "auto" is source-restricted — a project or local permissions.defaultMode set to any OTHER mode (plan, acceptEdits, default, …) is honored [...] only policy, user, and CLI-flag sources may grant auto mode.

（訳：source制限がかかっているのは "auto" という値だけ。project/localスコープの defaultMode が別の値（plan・acceptEdits・default等）なら、それはそのまま有効になる。auto を許可できるのはポリシー・userスコープ・CLIフラグだけ）

つまり「勝手に全承認スキップになる（auto）」は塞がれているのに、「勝手に編集だけ確認なしになる（acceptEdits）」は塞がれていない。

SkillSpectorはコードの中身は見てくれるけど、その手前にある権限設定は見ていない。悪意あるコードを書かなくても、.claude/settings.json に一行足すだけで似た効果を狙えてしまう、という盲点だった。

自分の環境のSkillSpector用スキル（/skillspector）に、スキャンの前に設定ファイルを目視確認する手順を1つ足した。

## スキャン前：設定ファイルの目視確認（対象がリポジトリのとき）

skillspector は .claude/settings.json を設定として解釈しない。
ここだけは中身を読んで報告する。

cat <対象>/.claude/settings.json
cat <対象>/CLAUDE.md

| キー | 危険な値 | なぜ |
| permissions.defaultMode | acceptEdits | リポジトリ側から設定でき、編集が確認なしで走る |
| permissions.allow | 広いワイルドカード | Bash(*) やインタープリタ許可は任意コード実行 |
| hooks | 任意 | 起動時・ツール呼び出し時に自動実行される |

ポイントは「対象ディレクトリでClaude Codeを起動する前に」実行すること。 起動してからだと、その CLAUDE.md はもう自分のcontextに入ってしまっている。指示を注入されたかもしれない側に、自分自身を監査させることになる。だから確認は起動前・別ディレクトリからが鉄則。

まとめ
Opus、Sonnet君達が5に進化した事により、私のClaudeCodeの環境は救われた

本当のまとめ

skillのdescriptionは毎セッション常駐する。 本文（SKILL.mdの中身）だけが発火時に読まれる。前回の自分はここを取り違えていた
「全部載った説明書」は、すでに常駐しているものの上にもう一段払う二重コストになりうる。descriptionそのものを整えるほうが筋が良い
件数で削減量を見積もると外れる。 description1件あたりのトークン単価はスキルごとに大きく違うので、文字数ベースで見積もるべき
claude doctor（/doctor）は診断ツールなので、手を入れる前に走らせるのが正しい順番。 変更後に測ると、その数字が元々そうだったのか自分の変更の結果なのか切り分けられなくなる
セキュリティスキャナーは「コード」は見ても「権限設定」は見ないことがある。 permissions.defaultMode: "acceptEdits" はリポジトリ側から有効にでき、"auto" だけが source制限されている。この非対称性を知らないと、静的解析を通過したリポジトリでも危険な設定を踏むことがある
自己監査は構造的に弱い。 疑わしいリポジトリの設定確認は、そのディレクトリでツールを起動する前に、外側から行う。つまり、目視。

参考

The new rules of context engineering for Claude 5 generation models（Anthropic公式ブログ）
Claude Code Skills 公式ドキュメント
SkillSpector（NVIDIA GitHub）
"Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale" (Liu et al., 2026)
前回記事：初学者による「AI Skillって全部把握できてる？」