スキル（Skill）
エージェントが再利用できるよう抽象化した手順·契約の単位。プロンプトより硬く、ツールより柔らかい中間層
一行定義
エージェントが再利用できるよう抽象化した手順·契約の単位。プロンプトより硬く、ツールより柔らかい中間層
全体システムの中での役割
スキルは「プロンプトの保存版」ではない。反復する業務を再利用可能な契約（contract） として圧縮した運営 artifact だ。
エージェント運用の階層をざっくり並べるとこうなる。
プロンプトは「一回の試行」に最適化される。スキルは「同じ作業を N 回回しても品質が崩れない」ことを目指す。だから中身は文章の美しさではなく、以下の 5 つが揃っているかで決まる。
1. Trigger — いつこのスキルを呼ぶか / いつ呼ばないか
2. Read order — 先に読むべき正本文書·テンプレ·ソース
3. Inputs / outputs — 必要な入力と、成功した出力の形
4. Boundaries — スキル側で決めてはいけない領域、止まるべき条件
5. Failure checks — 破棄·再検討すべき出力の判定基準
この 5 つを持てば、同じタスクが別の人·別のセッション·別のエージェントで走っても結果が近い範囲に収束する。これが「長いプロンプト」との決定的な違い。
Agent Skills は、この抽象概念を Claude Code が先行実装した具体の instance だ。本ページは上位の一般概念を扱い、Claude Code 特有の仕様（/skill-name 呼び出し·ディレクトリ配置など）は別ページ側に切り分けている。
よくある誤解
- 誤解 1：スキル = 長く練ったプロンプト、と思われがち。
– 実際には、長さは本質ではなく「反復性」と「契約性」が本質。長くても trigger と failure check が抜けていれば folklore（言い伝え）に留まる。
- 誤解 2：一度上手くいったプロンプトはすぐ
SKILL.mdに昇格すべき、と考えがち。
– 実際には、1〜2 回の成功はまだ prompt hypothesis の段階。eval surface と representative input が無いまま昇格させると、隠れ依存（hidden input dependency）が固まって後で崩れる。昇格には eval harness の通過が必要。
- 誤解 3：スキルを増やせばエージェントが賢くなる、と期待されがち。
– 実際には、スキルは「特定タスクで品質を安定させる」ための道具。関係ないスキルまで載せると本体の判断がむしろ濁る。棚卸し（demotion）もセットで運用する。
この用語が重要な理由
スキルを「長いプロンプト」ではなく「運営契約」として扱えると、AI 開発の議論のレベルが一段上がる。
- どの作業が反復性を獲得したか
- 何を成功と定義し、何を失敗として弾くか
- どこで人間のレビューを挟むか
- 使われなくなったスキルをいつ降格させるか
これらに答えを持てるチームは、モデルが新しくなっても artifact が資産として残る。逆に「便利プロンプト集」止まりのチームは、モデル更新のたびにゼロからやり直す。prompt engineering から harness engineering へ移行する途中の中間単位、それがスキルだ。
実務上の判断例：
- Claude Code の Skills 機能（agent-skills）を導入するか迷ったとき、「この作業は本当に契約化できるほど反復するか」を先に問う
- 既存のプロンプト集を棚卸しするとき、「失敗判定基準が書けないものは skill に昇格しない」と決める
eval theater（comparator 無しで「良くなった」と言い張る）の罠を避けるため、昇格時は必ず比較対象を取る
この用語が登場する記事
- ハーネスエンジニアリング、Agent Skills、Claude Code 関連記事
次に読むべき用語 3 つ
- Agent Skills — Claude Code の具体実装。本ページの一般概念が、特定プロダクトでどう落ちるかを示す。
- prompt — スキルの前段階。仮説層であって契約ではない。
- eval harness — スキル昇格を判定する測定装置。