「Skillsを入れればAIは賢くなる」と聞いて、とりあえず入れてみたことがある。でも実際に効果を感じたかと言われると、よくわからなかった。そんなモヤモヤを抱えていたところ、ClaudeCampというオンライン勉強会に参加した。テーマはSkill活用術。この記事はそこで得た学びをまとめたものだ。
Skillsとは何か
Skillsは、AIエージェントが必要なときに明示的に呼び出す専門知識の塊だ。最初からすべてを読み込むのではなく、タスクに応じて動的にロードされる。この設計思想を「Progressive Disclosure（段階的開示）」と呼ぶ。
仕組みはシンプルだ。
- Discovery — インストールされた全Skillの
nameとdescriptionだけを常時読み込む（約50〜100トークン） - Activation — タスクが一致したと判断したとき、
SKILL.mdの全文をコンテキストにロードする - Execution — 必要なら
scripts/やreferences/をさらに読み込んで実行する
つまりSkillsは、「AIをより賢くする」のではなく、コンテキストを効率的に使いまわすための戦略だ。Steve Kinney はこう書いている。
エージェントの信頼性が低い場合、問題はモデルではなく、コンテキスト戦略にある。
Skillsは能力を追加するのではなく、ノイズを減らして構造を与える。
Skillsは入れれば効果が出るわけではない
勉強会で一番刺さったのがこの話だった。Skillsの効果を研究したベンチマーク（Archiveというサイトが公開している）によると、扱うドメインによって効果が大きく変わるという結果が出ている。
特に興味深かったのが次の2点だ。
AIに書かせたSkillsは素のプロンプトとほぼ変わらない。
AIは自分が知っていることしか書けない。だからAIに生成させたSkillには、AIがすでに知っている情報しか入らない。モデルを上回る情報がなければ、Skillsの効果は出ない。
医療系ドメインのSkillsは効果が高い。
なぜか。医療の専門知識はモデルが十分に持っていないからだ。逆に開発系のSkillsは、ベースモデルがすでに高いレベルで知っているため、上乗せ効果が薄い。
まとめると、**Skillsが効くのは「AIが知らないことを教えるとき」**だ。誰もが知っていることをSkillsに書いても意味がない。
効果のあるSkillの書き方
勉強会では、良いSkillの要件として次の4つが挙げられた。
エージェントがすでに知っていることは書かない
これが一番重要な点だ。「この業務でしか知らない情報」「自社システムの挙動」——そういう情報こそがSkillsに書くべきことだ。一般的なベストプラクティスをSkillsに書いても、AIはすでに知っているのでノイズにしかならない。
選択肢を並べない
A・B・Cと並べると、AIは迷う。Skillsは応用を広げるものではなく、特定の文脈で確実に動かすものだ。「この場合はこれ」と1つに絞ることで効果が出る。
直感に反する事実を書く——毎回ハマるところ
「なぜかいつもここで失敗する」「知らないとつまずく挙動」——そういう情報がSkillsの核心だ。Skillsに価値があるのは、モデルが知らない業務固有の罠を教えられるからに他ならない。
個別の答えではなく、手続きとして書く
「こうしなさい」ではなく「次にこれをして、確認して、次へ進む」という形で書く。手続きとして記述することで、AIが状況に合わせて自律的に動けるようになる。
descriptionがルーティングキーになる
Skillsが実際に呼び出されるかどうかは、description の書き方にかかっている。具体的なトリガーフレーズと「何ができるか」を明記しなければ、Skillsはそもそも起動しない。kgsiさんがAnthropicの公式ガイドをまとめた記事でも、descriptionが最重要と強調されていた。
Skillsの効果をどう測るか
「誰でも作れる」からこそ、効果を測る仕組みが必要になる。
シンプルな方法は、Skillsを使ったときと使わないときの比較だ。成功率・リトライ回数・手動修正の量・完了までの時間を Before/After で見る。Claude CodeにはSkill Creator（/skill-creator）というツールがあり、テスト実行とベンチマーク計測ができる。
Microsoftが公開している waza というCLIフレームワークも、Skillsの作成・テスト・品質測定に使えるツールとして紹介されていた。
もう一点、mizchiさんが公開しているSkillファイルが参考になった。自分が書いたプロンプトを自分で評価するとバイアスがかかる。そこで第三者による実行と両面評価（自己申告＋定量メトリクス）を組み合わせて反復改善する、Empirical Prompt Tuning という手法だ。Skillsの改善にもそのまま応用できる考え方だと感じた。
Skillsを配置するときの注意点
効果的なSkillsが書けても、配置を間違えると意味がない。
プロジェクト固有のSkillsはプロジェクトの中に閉じる。
Next.jsのSkillsをグローバルに置くと、関係ないプロジェクトでも読み込まれてノイズになる。Next.jsの使い方はプロジェクトごとに異なることも多く、別プロジェクトに持ち込むと逆効果になりかねない。.claude/skills/ はそのリポジトリだけで有効になるので、プロジェクト固有の知識はここに入れる。
グローバルに置くのは、プロジェクトを跨いで使える汎用Skillsだけ。
コードレビューの流れや、ドキュメント整理の手順など、汎用的な手続きは ~/.claude/skills/ に置く。プロジェクトを跨いで使い回せる。
参考になったのがfreeeのMCPの事例だ。
freeeの公式MCPにはSkillsが付属しているが、それに加えて自前でfreee専用のSkillsを用意しているケースがあるという。公式が提供する汎用手順だけでは、自社の業務フローや運用上のクセまでは拾えない。そこに独自のSkillsを重ねることで、業務固有の知識をAIに渡している。
また、「未知の問題」や「再現性のない作業」をSkills化しても効果はほぼ出ない。絵を描けない人がSkillsを書いても、出てくるのはAIがすでに持っている情報だけだ——勉強会でこう表現されていて、腑に落ちた。
勉強会を経て考えたこと
Skillsの本質は、自分のドメイン知識をAIに渡すための形式だと理解した。自分が知らないことはSkillsにできない。逆に言えば、ドメインエキスパートが書いたSkillsは、ベースモデルを大きく上回る可能性がある。
デザインのプロセスと同じだという話が印象的だった。どのドメインでやるか決めて、構造化して、具体化して、検証する。Skillsもその繰り返しだ。
「毎回プロンプトでやっていることを手順化してSkillsにする」——それが最初の一歩として最も現実的だ。今まで何度も同じことを書いていたプロンプトを、Skillsとして整理することから始める。
そして今回の勉強会でいちばん持ち帰りたかったのは、評価することの重要性だ。Skillsは作って終わりではない。使う前と後で何が変わったかを測り、改善するサイクルがなければ、良いSkillsは育たない。感覚で「なんとなく良くなった気がする」で終わらせず、数値で検証する習慣を持つこと。それがSkillsを本当に機能させる鍵だと感じた。