「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を本当に機能させる条件だと感じました。