TL;DR（結論）
- AIエージェントのSkill（
SKILL.mdなどの指示定義）の質は、人間が持つ要求の質 × 要求を指示文へ翻訳する精度 × 指示をエージェントが実行する精度という3層の積で決まり、要求・翻訳・実行の順に、上流の層の質が下流の層で到達できる質の上限（天井）になる - どれほど精緻にSkillを書いても、「何を自動化すべきか」が間違っていれば「完璧に動くのに誰も使わないSkill」が生まれる
- AIエージェントにより実装コストが大幅に下がった結果、開発全体のボトルネックは「何を自動化すべきか」の解像度を持つ人間の認知能力に移りつつある
- 要求が事前に固まらない問題には、設計を一度で固めきろうとせず、境界を定義したうえで最小構成のSkillを動かし、使った体験で要求を研磨し続けることで対策できる
- Skillを書かせるモデルの選択は要求を指示文へ翻訳する精度に、Skillを動かすモデルの選択は指示をエージェントが実行する精度に直接効く。とくに Claude Fable では「旧モデル向けに書き込みすぎたSkillはかえって出力品質を下げる」と公式に明記されており、指示を細かく書くほど実行精度が上がるとは限らない
はじめに
Claude Code をはじめとする AIエージェントには、「Skill」という仕組みがあります。Skillとは、特定タスクの手順・判断基準・出力形式を SKILL.md として定義しておくと、/Skill名 と呼び出すだけでエージェントが自律的にタスクを実行してくれる仕組みです。
Skillを作るとは、毎回手動で行っていた AI への指示出しを「自動的に動く機械」として設計・固定化することであり、これにより自分の役割は、毎回指示を出すプレイヤーから、Skillの挙動を設計・検証する監督へと変わります。一人の監督が設計したSkillは何千回と再利用されるため、その効果は本人が個々の作業を直接こなすのとは比べ物になりません。
それでは、「質の高いSkill」はどう作ればよいのでしょうか？
本記事では、成果物の質を決める3層構造モデルを考えたうえで、AIエージェント用Skill（SKILL.md）の作成に適用します。
読後には、Skillが失敗する典型パターンとその処方箋が、1つのシンプルなモデルで整理できるようになります。
背景：完璧に動くのに、誰も使わないSkill
Skill設計者に「何を自動化すべきか」の解像度が欠如していると、SKILL.md の記述が精緻でSkillの実行が安定していても、誰からも呼び出されないSkillになります。動くのに使われないSkillは、コードベースに使われていない関数やクラスが散らばっているのと同種の技術的負債になってしまいます。呼び出されなくてもリポジトリには残り続けるため、他のSkillとの競合や誤発火の原因になり、「どのSkillが現役なのか」を判別する認知負荷を生みます。
Skillが生む成果物の質は次の3層の質で整理することができ、上位層の質が下位層で達成できる質の天井になります。
Q_{impl} \le Q_{spec} \le Q_{req}
| 層 | Skill作成における意味 |
|---|---|
| $Q_{req}$（要求の質） | 「何を自動化したいか」という意識の解像度 |
| $Q_{spec}$（仕様の質） | SKILL.md の品質（記述精度・自由度設計・粒度） |
| $Q_{impl}$（実装の質） | 実際に動かしたときの出力精度・安定性 |
Skillが最終的に生み出す成果物の質は、上記の3層構造モデルの各層間の変換係数を使って次の積で表せます。
Q_{out} = Q_{req} \times k_1 \times k_2
$k_1$ は「要求から SKILL.md へ」の翻訳精度、$k_2$ は「SKILL.md から実動作へ」の実現精度です。重要なのは、$k_1 = k_2 = 1$（完璧な翻訳・完璧な実装）でも、完成するSkillの価値は $Q_{req}$ という天井を超えないという点です。つまり、Skillが解くべき課題の設定が間違っていれば、仕様と実装が完璧に揃っても、課題に合わないSkillができるだけで価値はゼロになります。
3層それぞれの高め方
Skill化すべき対象を見極める
$Q_{req}$ は最初から仕様を確定しきれるとは限らず、Skill設計者が実装と検証を重ねることで育てていくものです。
- 観察：自分の仕事で繰り返しているパターンを見つける
- 記録：自分がタスクを実際にこなした際の手順・判断・出力を、言葉として書き出す
- 抽象化：そのSkillが本質的に何をしているかを一行で言える粒度まで、具体的な手順の記述を圧縮する
その上で、繰り返し頻度が高く、判断パターンが定まっており、出力を人間が簡単に検証できる業務だけをSkill化します。
一方、毎回文脈がまったく異なる業務や、高度な倫理判断を要する業務はSkill化には不適です。
要求と仕様の橋渡しを検証する
$k_1$ が落ちるのは、Skillの境界が曖昧なまま SKILL.md を書き始めたときです。入力がどこから来るのか、出力を誰が受け取るのかが決まっていないSkillは、前後の工程から孤立した処理となり、動いても使われない状態に陥りやすくなります。そのため SKILL.md を書き始める前に、この境界を言語化して固定します。
境界を固定する手段は1つに限りませんが、実践例の1つとして、製造業由来のフレームワークSIPOCの5列[Supplier（情報源）/ Input（入力形式）/ Process（主処理）/ Output（出力形式）/ Customer（出力の受け手）]を埋めて境界を固定することもできます。
レビュー観点を Linter として運用する
指示文への曖昧動詞の混入、I/O スキーマの未定義、スキップ条件の欠如により $k_2$ が低下し、エージェントが指示通りに動かない、毎回出力が変わる、作業の途中で迷走するといった症状として現れます。そのため私たちは、Skillの description の精度・手順設計・手順の粒度・指示の自由度・コンテキスト設計といった観点を Linter 的なレビューSkillとして定義し、他のSkillをレビューさせています。
（補足）モデル選択による違い
ここまでの3層は人間の側の営みとして書いてきましたが、$k_1$（要求 → SKILL.md）も $k_2$（SKILL.md → 実動作）も、実際にはどのモデルを使うかで値が変わります。例えば、Claude Opus 5とFable 5を比較してみると、両者の差の本質は単なる賢さではなく、Anthropic公式が推奨するプロンプトの書き方が逆方向である点にあります。
Skillを書かせるモデルの冗長性は、そのまま翻訳損失になる
$k_1$ は要求を SKILL.md へ翻訳する精度であり、要求に含まれない記述が混入した時点で悪化します。Anthropicの公式ガイドは Opus 5について、ディスクへ書き出すファイル（レポート・Markdown・サマリ）が旧モデルより長くなるため明示的な長さの指定が要ること、および依頼していない手順やセクションを自ら足してタスクのスコープを広げうることを挙げています [3]。
どちらも「要求になかったものが仕様に入る」現象であり、定義上そのまま $k_1$ の低下になります。
Fable 5については、無駄なコメントや大量の Markdown ファイルを書かないという第三者評価があり [6]、またタスクの途中で学んだ内容をもとにSkillをその場で更新するのが得意だと公式が述べています [2]。ただし断っておくと、両モデルに同一のSkillを書かせて比較した公開ベンチマークは執筆時点で存在しません。したがって $k_1$ に関する優位は、Opus 5側の冗長性とスコープ拡張が公式に認められているという事実からの間接推論であり、直接測定された差ではありません。
Fable では、書きすぎないこと
より重要なのは $k_2$ 側です。ここまで本記事は、曖昧動詞・I/O スキーマ未定義・スキップ条件の欠如という、記述が足りないことによる $k_2$ の低下だけを扱ってきました。暗黙に「書けば書くほど $k_2$ は上がり、いずれ飽和する」と仮定していたことになります。
Fable 5の公式ガイドはこの仮定を明示的に否定します。旧モデル向けに開発されたSkillは Fable 5に対して過度にプリスクリプティブであり、出力品質を劣化させうるため古い指示を削ることを検討せよ、と書かれています [2]。
Linter に追加すべき観点
この非単調性を運用へ落とすと、$k_2$ を守る Linter の観点は双方向になります。従来の「曖昧動詞を排除する」「I/O スキーマを定義する」に加え、次を検出対象へ加えます。
| 追加観点 | 検出するもの | 根拠 |
|---|---|---|
| 過剰な手順列挙 | 判断を要する工程への逐次的な手順指定 | 旧モデル向けのプリスクリプティブな記述は Fable では品質を下げる [2] |
| 検証スキャフォールド | 「ダブルチェックせよ」「サブエージェントで検証せよ」等のターン内検証指示 | 現行世代は指示なしで自己検証するため、残すと過剰検証になる [3] |
| 思考過程の再現要求 | 「思考過程を示せ」「推論を説明せよ」 | Fable では拒否カテゴリに該当し、別モデルへのフォールバックを誘発する [2] |
| 中間報告の強制 | 「N回のツール呼び出しごとに要約せよ」 | 現行世代は既定で適切に報告するため不要 [4] |
4つのいずれも、旧モデルの弱点を補うために書かれた記述です。モデルを上げたときに削り忘れると、そのまま $k_2$ の損失として残ります。Skillは書いた時点のモデルに最適化された資産であり、モデル更新のたびに棚卸しを要する点は、SKILL.md を書き足す作業と同じ重みで運用へ組み込むべきです。
要求の質への波及
Fable 5は時間単位の自律実行と並列サブエージェントの運用を前提に設計されており、公式ガイドはサブエージェントを頻繁に使い非同期で通信させること、長時間のランでは一定間隔ごとに別コンテキストの検証エージェントで仕様と突き合わせることを推奨しています [2]。次節で述べる「実装から要求への超高速フィードバック」は、この自律実行時間の長さの分だけ1サイクルあたりの探索量が増えます。設計したSkillを探針として走らせる戦略は、探針が長く走れるほど $Q_{req}$ の更新幅が大きくなります。
ただし単価は Opus 5のちょうど2倍（100万トークンあたり入力 10ドル 対 5ドル、出力 50ドル 対 25ドル）であり [5]、thinking を無効化できない、30日のデータ保持が必須で ZDR が使えない、拒否時のフォールバック構成が要る、といった制約も伴います [2][4]。Skillを書かせる用途はトークン量が小さく単価差の影響が限定的な一方、Skillを実行する用途では2倍差が直接効きます。オーサリングとターゲットでモデルを分けるのが現実的な運用になります。
設計を一度で固めきるのではなく、設計したうえで動かし、ブラッシュアップを続ける
AIエージェントの本質的なインパクトは、実装追従速度の極大化です。SKILL.md を書いてから動くSkillが手元に揃うまでの工数はほぼゼロです。
ただしこれが意味するのは「設計を飛ばしてよい」ではなく、「設計をしたうえで改善し続ける」ということです。
設計を飛ばして動かす進め方は、3層モデルの上では成立しません。境界を定義しないまま書いたSkillは $k_1$ が下がりますし、$Q_{spec}$ の天井は $Q_{req}$ である以上、要求も仕様も曖昧なまま動かして得られるのは「何が欲しかったのか分からないまま動く何か」です。動かした結果から学べるのは、そもそも何を期待していたかを設計として言語化していた場合に限られます。期待が書かれていなければ、出力が想定と違っても、何がどう違ったのかを言語化できません。
変わったのは設計の要否ではなく、設計の回数と粒度です。従来は一度の設計に賭けるほかありませんでしたが、いまは設計・実装・実行・設計の更新を何周も回せます。Skill開発の進め方をフィードバック経路として見ると、従来の「仕様から要求へ」（低速）・「実装から仕様へ」（高速）の2ループに加えて、AIエージェントによる高速な実装により、「実装から要求へ」の超高速な直接フィードバックが設計可能になります。
例えば「議事録からアクションアイテムを抽出するSkill」であれば、まず入力の出所と出力の受け手を確定させ、最小構成で作って実際に使ってみます。すると「抽出より先に『誰がいつまでに担当するか』の確認が欲しい」と気づき、この体験が $Q_{req}$ を更新して次の周回の設計の質を上げます。設計を一度で完璧にしようとせず、しかし毎周回きちんと設計する、というのが要点です。
新たなボトルネックは、人間がSkillへの要求を自ら認知できるかにある
AIエージェントによりSkill実装のコストが大幅に下がった結果、Skill開発のボトルネックは「Skillを書くコスト」から「何を自動化すべきかの解像度」へ移りつつあります。
そのため、Skillを設計・運用する人間が「何を自動化すべきか」という業務理解を更新する速度が、AIエージェントがSkillを作成する速度に追いつかないと、誰も使わない自動化Skillが蓄積していきます。
さらに、モデルの更新は $k_2$ を上げる一方で、旧モデル向けに書かれた記述を負債へ変えます。$D^{*}$ が左へ動く以上、Skill資産は放置すると相対的に「書きすぎ」の側へずれていきます。
Skillの棚卸しを、機能追加ではなくモデル更新をトリガーとして回す運用が要ります。
また、Skillを $n$ 個連鎖させるパイプラインでは各Skillの $k_2$ が掛け合わされ、上流Skillの品質低下が下流に累積するため、パイプライン上流に位置するSkillほど、その要求と定義を厳格にレビューすべきです。
まとめ
- Skillの質は要求の質 $Q_{req}$ × 翻訳精度 $k_1$ × 実現精度 $k_2$ の積で決まり、中でも $Q_{req}$ の解像度の欠如が、ほぼ常にSkill品質の最大の損失を生む
- $k_1$ は境界定義（実践例: SIPOC）で、$k_2$ は Linter 的なレビュー観点で守る
- AIエージェントのSkill開発では、設計を省くのではなく、設計・実装・実行・設計更新のサイクルを何周も回して要求と仕様を研磨し続ける進め方が有効である
- Skillを書かせるモデルと動かすモデルの選択は $k_1$・$k_2$ を直接動かす。例えば、Fable 5では $k_2$ が記述の細かさに対して単調増加しないため、Linter の観点を「曖昧さの検出」から「曖昧さと過剰記述の双方向の検出」へ拡張する必要がある
- 監督としての人間の仕事では、「何を自動化すべきか」を問い続けることが中心になる
参考
| ID | 文献 | 本文での参照箇所 |
|---|---|---|
| [1] | Agent Skills best practices - Claude Docs |
SKILL.md の本文500行以内という推奨 |
| [2] | Prompting Claude Fable 5 - Claude Docs | 過剰にプリスクリプティブな記述による品質劣化、Skillの逐次更新、サブエージェントの非同期運用と定期検証、推論再現要求の拒否、thinking とデータ保持の制約 |
| [3] | Prompting Claude Opus 5 - Claude Docs | 書き出しファイルの冗長化とスコープ拡張、指示なしでの自己検証 |
| [4] | Model migration guide - Claude Docs | 中間報告スキャフォールドの削除、モデル移行時の制約差 |
| [5] | Pricing - Claude Docs | 両モデルの単価 |
| [6] | Claude Opus 5 vs Claude Fable 5 実地比較 - Composio | Fable 5 の記述量に関する第三者評価 |
※いずれも2026年8月20日時点の参照情報となります。
IGSAについて
株式会社IGSA（イグサ）は、日本古来の畳のように、社会を温かく柔らかく持続的に支えるAIシステムにより、持続可能な幸せを目指す、東京大学松尾・岩澤研究室発のAIカンパニーです。音声と生体信号を扱うAIモデルを自社で開発し、そのモデルを載せた自社プロダクトと、企業・自治体のAIネイティブ化支援の二本立てで事業を営んでいます。主力事業は、業務と組織のあり方をAIを前提に再設計する「IGSA X」。データ土台の設計から、コーディングエージェントを中心にした基幹系・業務支援系システムとAIワークフローの高速実装、現場への定着と内製化までを一気通貫で担います。ヘルスケア領域では、音声発話から脳の健康状態を推定する技術を軸に、脳と心の健康習慣サービス「はなしてね」を開発、提供しています。