Claude Codeのスキル・サブエージェントはいつ作るべき？「毎回対話で頼む」から卒業する判断基準
Claude Codeへの依頼、毎回チャットで指示していませんか？一回きりの作業ならそれが最速ですが、繰り返す定型業務を対話だけでこなし続けるのは、再現性・品質・チーム共有の面で損をしています。この記事では「どのタイミングで対話をスキルやサブエージェントに昇格させるべきか」の判断基準と、具体的な作り方・共有方法を解説します。
結論：対話は「試作」、スキル・エージェントは「本番」
先に結論を示します。対話形式とスキル化は対立するものではなく、フェーズが違うと考えるのが正解です。
- 対話形式＝試作（プロトタイピング）。要件が曖昧なうち、正解の手順を探している段階では最強のインターフェース
- スキル・サブエージェント＝本番（プロダクション）。手順が固まった定型業務を、誰がやっても同じ品質で回すための仕組み
つまり「対話でうまくいくやり方を見つけたら、その手順をスキルに昇格させる」のが基本の流れです。一回きりの作業や探索的な調査までスキル化する必要はまったくありません。
定型業務を「毎回対話」でこなすことの4つの問題
週次のリリース作業、問い合わせ対応の下書き、定例レポートの生成——こうした「枠が決まった仕事」を毎回チャットで指示していると、次の問題が積み重なります。
① 再現性がない
同じ仕事でも、指示の言い回し・伝え忘れた条件・そのときの文脈によって結果が揺れます。先週うまくいった依頼の「効いていた一言」を今週は書き忘れる、といったことが普通に起きます。
② 品質が「依頼者のプロンプト力」に依存する
対話運用では、成果物の品質上限がその場の指示の質で決まります。仕事の手順や注意点がプロンプトとして毎回ゼロから組み立てられるため、属人性がAI時代の形で温存されてしまいます。
③ 改善が蓄積しない
「この条件を足したらうまくいった」という発見が会話ログに埋もれ、次回に引き継がれません。手順が形式知としてどこにも残らないのが、対話運用の最大の弱点です。
④ 他の人に渡せない
同じ業務を他のメンバーに任せるとき、渡せるものが「会話のコツの口伝」しかありません。完成したスキルやエージェント定義があれば、ファイルを共有するだけで同じ対応を再現してもらえます。
Claude Codeの公式ドキュメントは、スキルを作るタイミングを「同じ指示・チェックリスト・複数ステップの手順を何度もチャットに貼り付けているとき」「CLAUDE.mdの一部が『事実』ではなく『手順』に育ってしまったとき」と説明しています。逆に言えば、それまでは対話で十分ということです。
判断基準：「3回ルール」で考える
実務的には、次のシンプルな基準で判断するのがおすすめです。
| 状況 | 推奨 |
|---|---|
| 初めての作業・要件が曖昧・探索的な調査 | 対話で進める（スキル化は時期尚早） |
| 同じ種類の依頼を2回した | 対話でよいが、うまくいった手順をメモしておく |
| 同じ種類の依頼を3回した／今後も繰り返すと確定した | スキル化する |
| その業務を他の人にもやってもらう予定がある | 回数に関係なくスキル化して共有する |
| 毎回同じ種類の「作業者」を同じ指示で立ち上げている | サブエージェント化する |
ポイントは、スキル化のコストがほぼゼロに近いことです。後述するように、うまくいった対話の直後に「今の手順をスキルにまとめて」とClaude自身に頼めば、数分で作れます。「3回目に入る前の1分投資」と考えれば、迷う理由はほとんどありません。
仕組み化の道具は4つ：CLAUDE.md・スキル・サブエージェント・MCP
Claude Codeで「仕組みに落とす」方法は1つではありません。それぞれ役割が違います。
| 道具 | 役割 | 置き場所 | 読み込まれ方 |
|---|---|---|---|
| CLAUDE.md | 常に守るべき「事実・ルール」（コーディング規約、禁止事項、プロジェクトの前提） | プロジェクト直下 | 毎セッション常時読み込み |
| スキル | 特定の仕事の「手順書」（チェックリスト、定型ワークフロー） | .claude/skills/名前/SKILL.md | 使うときだけ読み込み（/名前で呼ぶ or 自動発動） |
| サブエージェント | 専門の「担当者」（独立したコンテキスト・ツール制限・モデル指定を持つ） | .claude/agents/名前.md | 該当タスクをClaudeが委任 or 明示的に指名 |
| MCP | 外部システムへの「接続」（Zendesk、DB、社内APIなどの操作ツール） | MCP設定 | ツールとして常時利用可能 |
覚え方はシンプルです。「知識・ルール」はCLAUDE.md、「手順」はスキル、「役割・分担」はサブエージェント、「外部への手足」はMCP。定型業務の仕組み化で最初に作るべきは、ほとんどの場合スキルです。
CLAUDE.mdは毎セッション読み込まれるため、長い手順を書くほど全セッションのコンテキストを圧迫します。スキルの本文は使うときにしか読み込まれないので、長い手順書はスキルに置くのが正解です。公式ドキュメントも「CLAUDE.mdのセクションが手順に育ったらスキルに切り出す」ことを推奨しています。
スキルの作り方：まずは1ファイルから
スキルの実体は、フォルダ1つとMarkdownファイル1つだけです。ディレクトリ名がそのままコマンド名（/名前）になります。
# プロジェクト共有ならプロジェクト内に
mkdir -p .claude/skills/weekly-report
# 自分専用なら（全プロジェクト共通）
mkdir -p ~/.claude/skills/weekly-reportSKILL.mdは、YAMLフロントマター（いつ使うスキルかの説明）と、本文（実行する手順）の2部構成です。
---
description: 週次レポートの下書きを作成する。ユーザーが「週報」「今週のまとめ」を依頼したときに使う。
---
## 手順
1. `reports/` フォルダの今週分のCSVを読み込む
2. 前週比の増減を計算する（データがない項目は「計測なし」と明記。推測で埋めない）
3. 以下のテンプレートに沿ってMarkdownで出力する
- 冒頭に3行サマリー
- 数値は表形式、増減には▲▼を付ける
- 最後に「要確認事項」を箇条書き
## 禁止事項
- 元データにない数値を書かない
- 前週のレポートの文面をそのままコピーしないdescriptionはClaudeが「このスキルを自動で使うべきか」を判断する材料になるため、どんな依頼のときに使うのかを具体的に書くのがコツです。/weekly-reportと明示的に呼び出すこともできます。
作るのが面倒？——Claudeに書かせればいい
スキル作成で最も効率的な方法は、うまくいった対話の直後に、その会話の中で頼むことです。
「今やってもらった手順を、次回から再現できるように.claude/skills/のスキルにまとめて。私が途中で出した修正指示も手順に反映して」
Claudeは直前の会話（試行錯誤の過程と、何が正解だったか）を知っているので、人間がゼロから手順書を書くより正確なスキルができます。これが「対話は試作、スキルは本番」を実践する具体的な形です。
サブエージェントの作り方：スキルとの違いは「隔離」
サブエージェントも実体はMarkdownファイル（.claude/agents/名前.md、個人用は~/.claude/agents/）です。スキルとの本質的な違いは、独立したコンテキストと権限を持つことです。
---
name: log-analyzer
description: エラーログの調査を担当。障害調査やログ解析の依頼で使う。
tools: Read, Grep, Glob
model: haiku
---
あなたはログ解析の専門家です。指定されたログから
エラーの発生時刻・頻度・原因候補を特定し、
結論を3行以内で報告してください。
調査過程の生ログは報告に含めないこと。スキルではなくサブエージェントを選ぶべきなのは、次のような場合です。
- メイン会話を汚したくない：大量のログや検索結果を読む作業を別コンテキストに隔離し、結論だけ受け取る
- ツールを制限したい：上の例のように読み取り専用ツールだけを許可すれば、調査担当が誤ってファイルを書き換える事故を構造的に防げる
- コストを下げたい：定型的な作業は
model: haikuのような安いモデルに割り当てられる - 毎回同じ種類の作業者を同じ指示で立ち上げている：公式ドキュメントがサブエージェント化の目安として挙げている状況です
なお、スキルとサブエージェントは組み合わせられます。「手順はスキル、実行役はツール制限付きのサブエージェント」という構成が、定型業務では最も安全です。
チームで共有する：.claude/をGitにコミットするだけ
冒頭の問題意識「他の人にも同じ対応をしてもらいたい」への答えがここです。プロジェクトの.claude/skills/と.claude/agents/をリポジトリにコミットすれば、チーム全員が同じスキル・エージェントを使えます。
これには、単なる共有以上の効果があります。
- 業務手順書がコードと同じ場所で管理される：改善はプルリクエストで提案・レビューでき、変更履歴が残る
- オンボーディングが変わる：新メンバーへの引き継ぎが「口頭でコツを教える」から「
/対応フローを実行して」になる - 個人の発見がチームの資産になる：誰かが対話で見つけた「うまいやり方」がスキル改善のコミットとして全員に還元される
Claude CodeのスキルはAgent Skillsというオープン標準に準拠しており、対応する他のAIツールでも同じSKILL.mdが機能します。チームでツールが混在していても、手順書の資産は無駄になりません。なお同名スキルが複数レベルにある場合は、エンタープライズ設定＞個人（~/.claude/）＞プロジェクト（.claude/）の優先順で上書きされます。
運用のコツと注意点
- 小さく始める：最初から完璧な手順書を目指さず、「対話で3回成功した手順」をそのまま書き起こす程度で十分。使いながらPRで育てる
- 禁止事項を必ず書く：スキルには「やること」だけでなく「やってはいけないこと」（推測で数値を埋めない、外部送信しない等）を明記する。品質の安定は制約から生まれます
- 危険な操作は仕組み側で防ぐ：削除・公開・送信などの不可逆操作は、スキルの手順に含めるとしても「人間の確認を待つ」ステップを挟む。サブエージェントならtools指定で権限自体を絞る
- スキルの重複・肥大化に注意：似たスキルが乱立したら統合する。スキル一覧が「どれを使えばいいか分からない」状態になると本末転倒です
よくある質問
Q. カスタムコマンド（.claude/commands/）とスキルはどう違うのですか？
現在は統合されています。.claude/commands/deploy.mdと.claude/skills/deploy/SKILL.mdはどちらも/deployとして機能し、既存のcommandsファイルもそのまま動きます。スキル形式には補助ファイル用のディレクトリ、自動発動、呼び出し制御などの追加機能があるため、新規に作るならスキル形式がおすすめです。
Q. スキルとサブエージェント、迷ったらどちらを作るべきですか？
まずスキルです。ほとんどの定型業務は「手順書」で解決します。サブエージェントが必要になるのは、コンテキストの隔離・ツール制限・モデルの使い分けという「実行環境の分離」が欲しくなったときです。スキルを運用してみて必要性を感じてからで遅くありません。
Q. 全部仕組み化したら、対話で使う意味はなくなりますか？
なくなりません。新しい種類の仕事・要件が固まっていない仕事では、対話の柔軟性が最も価値を発揮します。仕組み化の対象はあくまで「枠が決まった繰り返しの仕事」です。むしろ定型業務をスキルに任せることで、対話は本来得意な探索・試作に集中できます。
Q. スキル化した手順が古くなったらどうしますか？
スキルはただのMarkdownなので、対話と同じ方法で更新できます。「/weekly-reportの手順、今日変えた部分を反映して更新して」と頼めばClaudeがスキルファイルを書き換えてくれます。Gitで管理していれば変更履歴も残ります。
まとめ
- 対話形式は「試作」、スキル・サブエージェントは「本番」。対立ではなくフェーズの違い
- 毎回対話の定型業務は、再現性・品質の属人化・改善の非蓄積・共有不能という4つの損をしている
- 判断基準は「3回ルール」＋「他の人にもやってもらうなら回数に関係なくスキル化」
- 知識はCLAUDE.md、手順はスキル、役割の分離はサブエージェント、外部接続はMCP
- スキルはうまくいった対話の直後に「今の手順をスキルにまとめて」とClaude自身に書かせるのが最速
.claude/をGitにコミットすれば、業務手順書がレビュー可能なチーム資産になる
まずは、直近1か月で3回以上Claude Codeに頼んだ仕事を1つ思い出してください。次にその仕事を頼むとき、終わった直後に「今の手順をスキルにまとめて」と一言添える——仕組み化はそこから始まります。
