TL;DR
- Claude Skills と Subagents は「再利用可能なプロンプト資産」という説明が似ているせいで混同されるが、コンテキスト境界・主目的・ツール権限・起動コスト の4観点で本質的に別物だ
- 使い分けは A コンテキスト独立性 / B 再利用主体 / C 権限制御 / D 出力サイズ / E 呼出頻度 の5軸で判定し、2つ以上が Subagent 寄りなら Subagent を選ぶ
- 87 個の Skill と 23 個の Subagent を実運用してわかった「司令塔は Subagent、定型レビュー手順は Skill」「執筆ペルソナは Subagent、品質基準は Skill」という具体実装と、相互移行のレシピを示す
なぜ Skill と Subagent は混同されるのか
「Skill と Subagent、どっちに何を載せればいいですか」——Claude Code を本格導入したチームから一番聞かれる質問がこれだ。両者とも .claude/ 配下の Markdown で書け、どちらも「再利用可能なプロンプト資産」と紹介される。ドキュメントの語彙が似すぎているせいで、初学者には責務差が見えない。
Anthropic は2025年に Claude Skills を発表し、同じ年に Claude Code Subagents も整備した。仕様は別々のページに公開されているが、「どう使い分けるか」の運用判断軸は公式 docs に書かれていない。仕様の説明と運用の判断は別物だからだ。
私たちは自リポジトリで Skill を 87 個、Subagent を 23 個実装してきた（経験則: 2026-05 時点）。両者を併用する中で見えてきた使い分けの基準を、本記事で 5軸テンプレに落とし込む。
関連: Claude Code subagentsの実運用パターン――粒度設計と責務分離で精度が変わる では Subagent 単独の粒度設計を、同じことを二度と言わないための「スキル定義ファイル」 では Skill の書き方を、それぞれ深掘りしている。本記事はその上位に位置する「どちらを選ぶか」の判断軸だ。
公式定義の差分を 4観点で整理
混同を避ける最短ルートは、公式仕様を 4観点の表にまとめてしまうことだ。
| 観点 | Skill | Subagent |
|---|---|---|
| コンテキスト境界 | 親と同一コンテキスト（読込時に prompt に追記） | 独立コンテキスト（汚染しない） |
| 主目的 | 手順・参照資料の 再利用 | タスクの 委譲・分業 |
| ツール権限 | 親エージェントの権限を継承 | 独自に設定可能（最小権限） |
| 起動コスト | プロンプト追記のみ（軽量） | 別セッション起動（重量） |
出典: Skills 公式ドキュメント / Subagents 公式ドキュメント（公式値）。
コンテキスト境界（同居 vs 独立）
Skill は 親エージェントが必要と判断したときに SKILL.md の中身を読み込んで自分のプロンプトに足す仕組みだ。読み込まれた瞬間から、Skill の指示は親の会話履歴と同じコンテキストに混ざる。読み込みの判断は description フィールドに基づく progressive disclosure（公式値、Anthropic 公式）。
Subagent は逆だ。親が Task ツールで起動した瞬間、子は完全に別のコンテキスト で動き出す。子は親の会話履歴を見ない。仕事を終えると、子は最終出力（要約文）だけを親に返す。中間出力は親の判断を汚染しない。
この差は「会話履歴を共有するか」の一点に集約される。共有したいなら Skill、絶対に共有したくないなら Subagent だ。
主目的（再利用 vs 委譲）
Skill の主目的は 手順・知識の再利用。同じ手順を別々の役割から呼び出したいときに使う。例えば「Markdown 校正のルール」を書いた Skill は、執筆エージェントからもレビューエージェントからも装備できる。
Subagent の主目的は タスクの委譲・分業。「この仕事はあなたに任せたい」という宣言が伴う。再利用というより、特定の役割を持たせた独立した働き手を増やすイメージだ。
ツール権限の制御範囲
Skill には ツール権限を絞る機能がない。Skill が動くのは親のコンテキストの中なので、親が持つツール権限がそのまま使える。
Subagent は YAML frontmatter の tools: フィールドで 使えるツールを明示できる。例えばレビュー用の Subagent には tools: Read, Grep, Glob だけを与えて読み取り専用にする、といった最小権限設計が可能だ。権限を絞りたいなら Subagent 一択になる。
関連: 権限設計の詳細は MCP 権限設計の判断基準 で扱った。
起動コストと並列性
Skill の起動コストは「プロンプトに追記する」だけなので軽い。Subagent は別セッションを起動するため重い。ただし Subagent は親と並列で複数走らせられる利点があり、独立タスクのファンアウトには Subagent が向く。
使い分けの 5軸判断テンプレで決める
公式差分を踏まえて、実運用で使っている 5軸判断テンプレ を提示する。各軸で「Skill 寄り / Subagent 寄り」のどちらかを選び、2つ以上が Subagent 寄りなら Subagent を選ぶ判定ルールだ（経験則）。
| 軸 | Skill 寄り | Subagent 寄り |
|---|---|---|
| A. コンテキスト独立性が必要か | No（親と同じ会話で十分） | Yes（汚染を絶対に避けたい） |
| B. 再利用性の主体 | 「手順・知識」の再利用 | 「役割・ペルソナ」の再利用 |
| C. ツール権限を絞りたいか | No（親に従う） | Yes（最小権限を別途設定） |
| D. 出力サイズの想定 | 小〜中（参照資料的） | 中〜大（独立タスクの完了報告） |
| E. 呼び出し頻度 | 高頻度・複数役割から共有 | 中〜低頻度・特定タスクのみ |
軸A コンテキスト独立性が必要か
レビューや探索のように 中間出力が大量に出る作業 は、独立性が必要だ。grep 結果、テストログ、思考の試行錯誤などが親の会話に混ざると、その後の判断品質が落ちる。独立性が必要なら Subagent。
逆に「Markdown のスタイルガイド」のような静的な参照資料は、親の会話に同居してもノイズにならない。独立性は不要なので Skill で十分だ。
軸B 再利用性の主体は手順か役割か
「同じ手順を 5つの役割から呼びたい」なら手順の再利用なので Skill。「同じ役割を 5つのワークフローから呼びたい」なら役割の再利用なので Subagent だ。
例: clean-code は手順の再利用なので Skill。article-writer は役割の再利用なので Subagent。
軸C ツール権限を絞りたいか
最小権限が必要なら Subagent しか選択肢はない。Skill にはツール制御機能がない（公式値）。
軸D 想定する出力サイズ
Skill は親のターンの一部として動くので、出力は親が読み続けられるサイズが望ましい。出力が長くなるとコンテキストを圧迫する。
Subagent は完了時に 要約だけを親に返す 設計なので、内部でいくら大きな処理をしても親のコンテキストは膨らまない。出力サイズが中〜大ならSubagent。
軸E 呼び出し頻度と共有先の数
呼び出し頻度が高く複数の役割から共有されるなら、軽量な Skill が有利だ。呼び出すたびに別セッションを起動する Subagent はコストが嵩む。
低頻度・特定タスク専用なら Subagent。
判定ルール「2つ以上 Subagent 寄り → Subagent」
5軸を埋めて、Subagent 寄りが 2つ以上なら Subagent を選ぶ。1つ以下なら Skill を選ぶ。これは経験則だが、実運用で迷う時間を最小化できる。
87 skill / 23 subagent を運用してわかった実例 3パターン
抽象論を実装に落としたものが、自リポの .agents/skills/（87 ディレクトリ、経験則）と .agents/agents/（23 ファイル、経験則）だ。代表的な 3パターンを示す。
司令塔は Subagent、定型レビュー手順は Skill（article-conductor × article-multi-review）
記事生成パイプラインの司令塔 article-conductor は Subagent として実装している。理由は軸A（独立性必要）と軸B（役割の再利用）が同時に成立するから。
実装の frontmatter 抜粋:
---
name: article-conductor
description: article-workflowのexecフェーズ（D-1〜D-12）を管理する司令塔。自らは記事を書かず、既存エージェントへのタスク委譲とフェーズ管理に徹する。
tools: Read, Grep, Glob, Bash, Agent, Write, Edit
model: inherit
skills: clean-code, article-preflight, article-self-review, article-4p-review, parallel-agents
---
注目したいのは skills: フィールドだ。Subagent は複数の Skill を装備できる。司令塔としての役割（ペルソナ・判断軸）は Subagent 本文に書き、定型レビュー手順は別 Skill（article-multi-review、article-4p-review）に切り出して装備する。これにより、レビュー手順は他の役割からも装備可能になる。
執筆ペルソナは Subagent、品質基準は Skill（article-writer × article-writing）
執筆を担う article-writer は Subagent。長文を生成する間、grep / 構成検討 / リサーチ参照などの中間出力が大量に出るため、独立コンテキストが必須（軸A）。さらに執筆ペルソナの再利用（軸B）。
---
name: article-writer
description: 企画書とリサーチ情報に基づき、article-writing 基準で読者の行動を促す高品質な初稿を執筆するエージェント。
tools: Read, Grep, Glob, Bash, Write, Edit
model: inherit
skills: clean-code, writer-agent, article-writing
---
一方で 「執筆品質の基準」（S0-S9 / V1-V3、SEO/GEO 必須要件など）は Skill article-writing に切り出してある。基準は他の役割（レビュー・改善）からも参照したいので、Skill として共有する設計だ。
共有メタ Skill を複数 Subagent から装備（clean-code を 5+ から参照）
clean-code Skill は SRP / DRY / KISS などの汎用コーディング規範を書いた手順 Skill だ。article-conductor、article-writer、article-planner など複数の Subagent から skills: clean-code, ... で装備されている。手順の再利用主体（軸B）と高頻度共有（軸E）の典型例 で、Subagent 化していたら同じ規範をコピペで撒くことになっていた。
メタ Skill を一箇所に固めておくと、規範の更新が一発で全 Subagent に伝播する利点もある。これは Skill の最大の運用メリットだ。
アンチパターン 3選
実装してきた中で踏んだ罠を 3つ紹介する。どれも 5軸テンプレで事前に避けられる。
Subagent に手順書を直書きして再利用不能になる
最初に作った Subagent には、執筆ガイド・レビュー観点・コミットルールまで全部 frontmatter 後の本文に直書きしていた。プロンプトが 800行を超え、似た規範を別 Subagent にコピペで撒く事態になった（社内データ: 2026-04 振り返り時点）。
修正: 共通規範を Skill に切り出し、Subagent からは skills: で装備するだけにした。プロンプト本文は 200行に収まり、Skill は 5+ の Subagent から共有されるようになった。
Skill に独立タスク全体を載せて親コンテキストを汚染する
逆方向の罠もある。「マルチレビュー」を Skill にして親エージェントから呼んだところ、3視点のレビュー過程の中間出力（grep / Read / 思考）がすべて親の会話に流れ込み、後続の判断が劣化した。
修正: マルチレビュー本体は Subagent 化（多重起動）し、Skill には 「Subagent への委譲手順とフォーマット標準」だけ を残した。中間出力は子コンテキストに閉じ込められ、親には要約だけが返る設計になった。
Skill にツール権限制御を期待してしまう
「この Skill は読み取り専用にしたい」と思っても、Skill にツール権限を絞る機能はない（公式値、Skills 公式 docs）。Skill は親の権限で動く以上、親が Write を持っていれば Skill 経由でも書けてしまう。
修正: 権限を絞りたい役割は最初から Subagent で実装し、tools: Read, Grep, Glob のように明示する。これは AI コーディングのセキュリティ設計 の最小権限原則とも整合する。
Skill と Subagent の相互移行レシピ
設計判断は最初から完璧でなくていい。運用しながら 5軸を満たさなくなったら移行する のが現実的だ。
Skill → Subagent への昇格条件と手順
昇格条件（経験則、いずれか1つ満たせば検討）:
- 起動時に毎回プロンプト全体を読み込ませており、親コンテキストの 30% 以上を専有している
- ツール権限を絞りたい（読み取り専用化など）
- 親と並列で動かしたい
手順:
- 既存 Skill の本文を Subagent 用に再構成（ペルソナ宣言・ツール権限・成果物形式を冒頭に）
.claude/agents/<name>.mdを新規作成し、frontmatter にname,description,tools,model,skillsを設定- 既存 Skill が「手順・規範」だけになるよう削ぎ落とす（再利用主体に戻す）
- 新 Subagent の
skills:に旧 Skill を装備して、規範の参照を維持
Subagent → Skill への分離条件と手順
分離条件（経験則、いずれか1つ満たせば検討）:
- 「手順」と「実行」が混ざっており、別の Subagent から再利用したい
- 動作プロトコルがチームで複数の Subagent に共通している（例: clean-code）
- 出力サイズが小さく、独立コンテキストの恩恵が薄い
手順:
- Subagent 本文から「再利用したい手順部分」だけを抽出して Skill 化
.claude/skills/<name>/SKILL.mdを作成し、descriptionを明確に書く（progressive disclosure の判断材料になる、公式値）- 元 Subagent の本文から該当箇所を削り、
skills:に追加して装備 - 別 Subagent の
skills:にも追加して共有
関連: 移行の運用設計は プロンプトエンジニアリングの終焉：「スキル定義ファイル」でAIを即戦力にする のスキル資産化の文脈とも噛み合う。
まとめ：判断は 5軸、実装は装備、運用は移行
整理すると 3つに集約される。
- 判断は 5軸: コンテキスト独立性 / 再利用主体 / 権限制御 / 出力サイズ / 呼出頻度。Subagent 寄りが 2つ以上なら Subagent を選ぶ
- 実装は装備: Subagent は
skills:フィールドで Skill を複数装備できる。共有規範は Skill 化して複数 Subagent から参照する - 運用は移行: 最初から完璧を狙わず、5軸が崩れたら相互移行する。昇格・分離の条件と手順をテンプレ化しておく
Skill か Subagent かで詰まっているなら、まず手元のワークフローを 5軸で採点してみてほしい。判断テンプレと実装パターンの設計支援が必要なら、気軽に相談してほしい。
FAQ
Skill と Subagent は同時に使えるか
Yes。Subagent の YAML frontmatter には skills: フィールドがあり、複数の Skill を装備できる（Subagents 公式 docs、公式値）。本記事の article-conductor は 5つの Skill を装備した実例だ。
Skill だけで Subagent を再現できるか
No。Skill は親と同じコンテキストで動くため、コンテキスト独立性は再現できない（公式値）。さらにツール権限の個別制御も Skill にはない。独立性または最小権限が必要なら Subagent が必要だ。
ツール権限はどちらで絞るか
Subagent 側で絞る。Subagent の tools: フィールドに使えるツールを列挙する設計が公式仕様（Subagents 公式 docs）。Skill には権限制御機能がない。
どちらを先に作るべきか
共通手順を整理したいなら Skill から。独立タスクを切り出したいなら Subagent から。判断に迷ったら 5軸で採点し、Subagent 寄りが 2つ以上なら Subagent を選ぶルールが目安になる（経験則）。
CLAUDE.md やシステムプロンプトとは何が違うか
CLAUDE.md は 常時 親プロンプトに含まれる。Skill は description を見て 必要時のみ 読み込まれる progressive disclosure 方式。Subagent は 別コンテキスト で動く独立セッションだ。常時必要な規範は CLAUDE.md、必要時の手順は Skill、別タスクは Subagent と整理できる。詳細は CLAUDE.md 最適化の実務 も参照。
