Skill・Agent・Workflow の使い分け

3つの道具を1本の軸でとらえる

Skill・Agent・Workflow は対立する別物ではなく、同じ「委任」の延長線上にある3段階の階段です。求められる規模と確信度が上がるほど、左から右へ進みます。

• Skill（知識を足す） … 同じ Claude に専門マニュアルを渡す。
• Agent（仕事を1つ任せる） … 別の頭脳に委任し、結論だけ受け取る。
• Workflow（大勢を統率する） … 多数の頭脳を台本（コード）で動かす。

まずはこの軸を頭に入れたうえで、「どれを選ぶか」の判断基準に進みます。

それぞれを選ぶ判断基準

📘 Skill を選ぶとき

メインの Claude 自身に、正しいやり方や知識を持たせたいときです。文脈（今の会話の流れ）を保ったまま続けられます。

• 知識・手順を足したい
• メインの Claude 自身に、正しいやり方で作業させたい
• 出力フォーマットや規約を統一したい
• 文脈を保ったまま続けたい

例：コミット規約、PDF処理手順、社内ドキュメント形式。

🤖 Agent を選ぶとき

独立した一塊の仕事を丸投げし、本体の文脈を汚さずに進めたいときです。

• 独立した一塊の仕事を丸投げしたい
• 大量の中間情報で本体の文脈を汚したくない
• 複数タスクを並列でこなしたい
• 役割・権限を分離した専門家に任せたい

例：広範な探索、独立した4観点レビュー、大規模移行。

📜 Workflow を選ぶとき

多数を統率し、ループ・検証・並列で網羅的・確信度高く・大規模に攻めたいときです。高コストなので明示的な依頼が原則になります。

• 同じ手順を正確に何度も繰り返したい
• 結果に応じて処理の形を変えたい（条件分岐）
• 数十体規模で網羅・徹底監査したい
• 予算制御や敵対的検証まで台本に書きたい

例：徹底監査、大規模移行、多視点検証。

判断フローチャート

上から順に「Yes」になったところで止まる、というだけの単純な分岐です。まず「自分で見れば済むか」を疑うのがコツです。

そのタスクは…
 │
 ├─ 1ファイルの場所/値を知るだけ？           ──→ Yes → 委任せず自分で見る
 │
 ├─ Claude に「やり方/知識」を教えたいだけ？  ──→ Yes → 📘 Skill
 │
 ├─ 独立した一塊の仕事を1〜数体に任せたい？   ──→ Yes → 🤖 Agent
 │
 └─ 多数を統率し、ループ/検証/並列で
    網羅・確信・大規模に攻めたい？（明示依頼） ──→ Yes → 📜 Workflow

比較表の要点

3つの違いを観点ごとに押さえます。

本質

• 📘 Skill … 同じ頭脳に知識を足す
• 🤖 Agent … 別の頭脳に委任する
• 📜 Workflow … 多数の頭脳を台本で統率する

文脈

• 📘 Skill … 共有（同じ会話の中）
• 🤖 Agent … 分離（結論だけ戻る）
• 📜 Workflow … 分離×多数＋結果を統合

規模・制御・起動

• 規模：Skill は規模の概念なし／Agent は1〜数体／Workflow は数十体（最大1000規模）。
• 制御：Skill は手順書／Agent は都度の判断／Workflow は決定論的コード（ループ・分岐）。
• 起動：Skill は自動 or /名前／Agent は自動 or 明示／Workflow は明示依頼が原則（高コスト）。

3段階の階段：Skill（知識を足す）→ Agent（仕事を1つ任せる）→ Workflow（大勢を統率する）。同じ「委任」の延長線上にあり、規模と確信度の要求が上がるほど右へ進む。

組み合わせる ── 最強の使い方

Skill と Agent は対立概念ではありません。組み合わせてこそ威力が出ます。典型は「Agent に Skill を持たせる」パターンです。専門エージェントの行動指針（システムプロンプト）の中で、特定の Skill を使うよう促せます。

例：レビュー専門 Agent × code-review Skill

1. 司令塔が「PR をレビューして」と受ける。
2. レビュー専門 Agent を起動（独立文脈で大量の差分を読む）。
3. その Agent が code-review Skill の手順に従って精査する。
4. Agent は結論（指摘リスト）だけを司令塔に返す。

こうすると、文脈を汚さず（Agent）、一貫した品質で（Skill）レビューできます。

3層フル活用

最大構成では Workflow が複数の Agent を扇形に並列展開し、各 Agent が code-review などの Skill の手順で作業し、最後に結果を統合します。3つが入れ子に重なった、Claude のオーケストレーションの最終形です。

ベストプラクティス集

Skill 作成

• description は具体的に＋「いつ使うか」を必ず書く。発動精度の9割はここで決まる。
• SKILL.md 本文は短く。詳細は別ファイルに分けて段階的開示を活かす。
• 1 Skill = 1 目的。あれもこれも詰め込まない。発動条件が曖昧になる。
• 名前は内容を表す kebab-case。pdf-processing は良い、util は悪い。
• allowed-tools で最小権限。不要な書き込み権限は与えない。

Agent 運用

• 「返してほしい結論」を明示。中間ログは戻らない前提で発注する。
• 読み取り探索は Explore、設計は Plan。用途に合った組込を選ぶ。
• 軽い作業は haiku モデル。速くて安い。重い推論だけ opus にする。
• 書き込み並列には worktree 隔離。競合事故を防ぐ。
• 1ファイル確認程度なら委任しない。自分で見た方が速い。

Workflow 設計

• 迷ったら pipeline。parallel は「全結果が揃わないと進めない」時だけ。
• 構造化が要るなら schema を渡す。文字列パースより堅牢で自動リトライも効く。
• 依頼の重さに規模を合わせる。軽い確認に数十体は過剰。徹底監査なら惜しまない。
• 確信が要る結論は敵対的検証を通す。「反証せよ」と指示した複数票で確定する。
• 打ち切り（top-N・サンプリング）は log() で必ず明示。黙って削ると「全部見た」と誤読される。
• 試行錯誤は resume を活用。台本を編集して再実行すれば変更箇所以降だけ走る。

アンチパターン

やりがちな失敗を避けるだけで、コストも品質も大きく改善します。

• description が抽象的で Skill が発動しない／誤発動する。
• 何でも Agent に丸投げして、かえって遅く・追いにくくなる。
• 巨大な SKILL.md を1枚で書いて、段階的開示の利点を捨てる。
• 何でも Workflow にして大量のトークンを浪費する（普通のタスクは Agent 1〜数体で十分）。
• flatten/filter したいだけなのに parallel のバリアを挟み、速い枠を無駄に待たせる。

よくある質問（FAQ）

Q. Skill と CLAUDE.md はどう違う？

CLAUDE.md は常時読まれるプロジェクト全体のルール。Skill は必要時だけ開く特定タスクの手順書です。常に効かせたい前提は CLAUDE.md、出番が限定的な手順は Skill に置きます。

Q. Skill は手動で呼ばないと使われない？

いいえ。description にマッチすれば Claude が自動発動します。確実に使いたいときは /スキル名 で明示呼び出しも可能です。

Q. Subagent の作業内容は見られる？

最終結論は司令塔（とユーザー）に返りますが、途中の試行錯誤は基本的に隔離されます。だからこそ「何を成果物として返すか」を指示で固めるのが重要です。

Q. Skill とプラグインの関係は？

プラグインは Skill・Agent・コマンド等をまとめて配布する仕組みです。チームで配るならプラグイン化が便利です。

Q. Workflow と「複数 Agent の並列」は何が違う？

並列 Agent は司令塔がその場で同時起動するだけ。Workflow は台本（コード）で決定論的にループ・条件分岐・段階処理・予算制御まで記述できます。「同じ手順を正確に繰り返す」「結果に応じて形を変える」のが Workflow の強みです。

Q. Workflow は自分から勝手に起動する？

いいえ。高コストなためユーザーの明示的な意思表示が原則です（メッセージに「workflow」と入れる、「マルチエージェントで」と頼む、専用スキル経由など）。

Q. pipeline と parallel、結局どっちを使えば？

原則 pipeline。「stage N が stage N-1 の全結果を必要とする」時だけ parallel（バリア）にします。重複除去・合計0件での早期終了・相互参照がその典型です。

3行まとめ

• 📘 Skill＝必要な時だけ開く「専門マニュアル」。同じ Claude に知識を足す。
• 🤖 Agent＝独立文脈の「専門の部下」。仕事を委任し結論だけ受け取る。並列可。
• 🎯 使い分け＝知識を足すなら Skill、仕事を任せ文脈を守るなら Agent、多数を統率するなら Workflow。組み合わせが最強。