意味が希薄化した用語をAgent Skillsで定義する
はじめに
Claude CodeのAgent Skillsは、Markdownファイルに記載した特定の作業手順や前提知識を、必要になったときにAIが自動で読み込んでくれる機能です。 私も、この機能が2025年10月にリリースされてから、Skillsの導入や自作を通じて、使い方を模索してきました。 今回は、その試行錯誤の過程で気づいたおすすめの運用を紹介します。
用語の希薄化
ある用語が多くの人の耳に入るにつれて、本来の定義から一部が抜け落ちた解釈が広がってしまうことがあります。この現象をここでは「希薄化」と呼ぶことにします。（希「薄」化とはいうものの、実際には本来の定義から「薄まる」だけでなく、「異なる」こともあります。）
ソフトウェア開発に関連する用語も例外ではありません。例えば「テスト駆動開発（TDD：Test-Driven Development）」という用語は、（残念ながら）希薄化した意味が広がってしまいがちなものの一つだと思います。
（この記事で私が誤った解釈を伝えてしまう可能性も当然あるので、執筆にあたっては最大限注意しないといけないところです）
TDDはKent Beck氏が考案したプログラミングの手法なのですが、各所にある解説などを観察してみると、それぞれが微妙に異なった書きぶりをしていることがわかります。 ある所では「プロダクトコードを実装する前にテストコードを書く」と書かれていたり、「Red → Green → Refactorを繰り返す」と書かれていたり。 TDDが何たるものなのかという解説はこの記事の趣旨ではないので割愛しますが、Kent Beck氏による本来の定義と照らし合わせて見てみると、意味が一部抜け落ちている記載がよく見られます。
このように意味の希薄化が進行している用語は、AIの学習データにも希薄化した解釈が大量に含まれるため、AIの回答も希薄化している可能性があります。 これを利用してしまうと、本来の定義に基づいて最適化されたノウハウが正しく適用されず、望んだアウトプットを得られなくなってしまいます。
私は、自分が扱いたい用語がこのような状態である場合に、その本来の定義をSkillsで明確にすることが効果的だと考えています。
Skillsを入れずにAIへ聞いてみる
TDDに関するSkillsを入れていない状態で、どのようなアウトプットが得られるのか試してみます。
入力したプロンプト：
次に追加する機能をTDDで開発します。どのような手順で進めるべきか教えてください。Opus 4.6の回答：
TDDの基本手順は以下の通りです：
1. Red — 失敗するテストを先に書く
2. Green — テストを通す最小限の実装をする
3. Refactor — コードを整理する（テストは通ったまま）私は、この回答が「部分的には正しいが、本来の定義から一部が抜け落ちている」ものだと認識しています。
AIがこの認識のままで開発を進めてしまうと、本来受けられるはずだったTDDによる恩恵も部分的に抜け落ちてしまいます。
Skillsを入れてAIへ聞いてみる
次に、TDDの定義を可能な限り本来の定義に沿ってまとめたSkillsを用意し、コンテキストをクリアしたうえで同じ質問をしてみました。
入力したプロンプト：
次に追加する機能をTDDで開発します。どのような手順で進めるべきか教えてください。Opus 4.6の回答：
次の機能をTDDで開発するなら、Kent Beck の TDD に沿って次の手順で進めるのがよいです。
テストリストを作る
まず、これから追加する機能で「期待される振る舞い」を箇条書きで洗い出します。
- 正常系のシナリオ
- 境界値・異常系のシナリオ
- 既存の振る舞いを壊さないか確認したいケース
この段階では「どう実装するか」は一切考えず、「何ができてほしいか」だけを列挙します。実装の設計判断を混ぜないのがポイントです。
テストを一つだけ書く
リストから一つだけ選び、実行可能なテストコードに翻訳して、失敗することを確認します。
- 全部を一気にテストコード化しない（最初のテストで設計をやり直すと書き直しになるため）
- ここで決めるのはインターフェース（呼び出し方）の設計だけ。実装の中身はまだ考えない
- アサーションのない「カバレッジ稼ぎ」のテストは書かない
テストを成功させる
失敗するテストを通すために、プロダクトコードを書きます。
- リファクタリングはここで混ぜない。まず「正しく動く」ことだけを目指す
- 実行結果の値をそのまま期待値にコピペしない。期待値は自分の頭で検証して書く（ダブルチェック）
- 途中で新しいテストの必要に気づいたら、テストリストに追記する
必要に応じてリファクタリングする
テストが通って安全網ができた状態で、実装の設計を改善します。
- 過剰なリファクタリングはしない（今必要な分だけ）
- テストが通り続けることを確認しながら進める
リストが空になるまで繰り返す
テストリストから次の一つを選び、「テストを書く → 通す →
リファクタリング」を繰り返します。リストが空になり、コードに対する不安がなくなったら完了です。
この「Red（失敗するテスト）→ Green（通す）→ Refactor（整える）」の小さなサイクルを、機能を薄くスライスして何度も回すのが本質です。最初のテストに何を選ぶかだけ決まれば、あとはリズムに乗れます。
最初の機能の内容を教えてもらえれば、一緒にテストリストの作成から始められます。日本語が気になるところもややありますが、Skillsを設定したことにより、本来の定義に沿った回答が返ってくるようになりました。
TDDという用語の本来の定義をAIに認識させたことで、先ほどのSkillsを入れていない状態と比較して、TDDによる恩恵をより受けながら開発できそうです。
今回は実験目的でプロンプトをわざわざ打ってAIに聞きましたが、例えば/tddのようにSkillsを直接読み込んでも同じ結果を得られます。
また、これと似たような話で、「○○氏が提唱するやり方で進めて」と指示すると上手くいきやすい、というテクニックがあります。用語の定義を明確化するという点で両者のやっていることは同じで、それがプロンプト直打ちではなくSkillsというツールでできるようになった、という話だと考えています。
さいごに
今回はTDDを例にしましたが、ソフトウェア開発に関連する他の用語でも同じような効果が得られると考えています。
ただし、あらゆる用語をSkillsに再定義するのは、あまりにも無駄が多いです。自分が扱いたい開発手法などがあって、AIがそれを正しく認識できていない場合に、今回の運用が役に立つことがあるのではないでしょうか。
よければ、参考にしてみてください。
以上