subagent と skills の役割分担。Claude Code の役割設計を仕上げる
ハーネス設計シリーズ4本目（最終回）は、境界（permissions）と仕掛け（hooks）の上に載せる「役割分担」の話です。subagent と skills を別物として覚えるのではなく、組み合わせる前提で設計すると、ハーネスがひとつの作業環境として完成します。個別機能の解説ではなく、組み合わせ方を整理します。
はじめに
Step 5 ハーネス設計シリーズの4本目、最終回です。1本目「Claude Code のハーネスとは何か」で全体像を、2本目「permissions と settings.json の設計」で境界の引き方を、3本目「hooks による自動化設計」で仕掛けの作り方を扱いました。
本記事では、ハーネスの最後のひと品——subagent と skills の役割分担を扱います。境界と仕掛けの上に 役割分担 を載せると、ハーネスがひとつの作業環境として完成します。
subagent と skills の 個別の使い方 は、すでに別記事で扱い終えています。概念は「Claude SubAgent とは何か」「Claude Skills とは何か」、自作は「SubAgent の活用例」「Skills を自作する」を参照してください。本記事はそれらの 次の段階——使い方を知っている前提で、どう役割分担させて組み合わせるか を整理します。
読み終えたあとには、自分のハーネスの中で「この仕事は skill にして渡す」「この仕事は subagent に切り出す」「この2つは組み合わせる」の判断軸がつかめるはずです。
subagent と skills を1枚で見渡す
最初に、2つの道具を並べて性格の違いを確認します。
役割を一行で言い切ると、こうなります。
| 道具 | 役割 | 動く場所 |
|---|---|---|
| skills | 専門知識のパッケージを渡す | メイン Claude のコンテキスト（inline） |
| subagent | 別働の Claude を独立した文脈で走らせる | 別コンテキスト（隔離） |
同じ「Claude を強化する」道具でも、知識を増やすか、人手を増やすか という点で根本が違います。skills は本棚を増やす、subagent は部下を雇う——そんな対比です。Web 制作で例えるなら、skills は新しい CSS フレームワークを @import で取り込む話、subagent は別ターミナルでビルドプロセスを走らせる話に近いです。
この性格の違いを最初に押さえておかないと、組み合わせの議論がぼんやりします。
役割分担の3つの軸
どちらを選ぶか迷ったときは、次の3つの軸で考えると判断がぶれません。
軸1：知識か、実行か
「Claude に新しい知識を持たせたい」なら skills、「重い作業を別働でやらせたい」なら subagent です。
「マギのクロゼミの記事の書き方ルール」のような 読まれて参照されるもの は、skill にする方が自然です。一方、「コードベースを30ファイル調査する」のような 実行して結果だけほしいもの は、subagent に切り出す方が自然です。
判断に迷ったら「これは 読み物 なのか、作業 なのか」と自問します。読み物なら skill、作業なら subagent。
軸2：軽い参照か、重い隔離か
skills は 軽い。索引（description）が起動時に読み込まれているだけで、本体（SKILL.md）は呼ばれたときだけ inline で展開されます。
subagent は 重い。別コンテキストを立ち上げ、別の Claude を走らせ、終わったらサマリだけ返してくる——この往復にコストがかかります。代わりに、メイン会話のコンテキストを汚さない という強い恩恵が得られます。
軽い参照で済むなら skill、コンテキストの汚染を避けたいほど重いなら subagent。どちらが軽いか ではなく、どちらの重さが受け入れられるか で判断します。
軸3：知識（reference）か、手順（task）か
公式ドキュメントは skill の中身を reference content（参照型） と task content（手順型） の2種類に分けて整理しています。
- reference：「API 設計の規約」「BEM 命名のルール」のように、Claude が会話の中で参照する知識
- task：「デプロイの手順」「コミットの手順」のように、ユーザーが
/skill-nameで発火させる手順
reference 型の skill は、自然に skill 単独で機能します。task 型の skill は、本記事の後半で扱う subagent との組み合わせ で真価を発揮することが多いです。
3軸はバラバラに動くわけではありません。知識・軽さ・参照型 が揃えば skill、実行・隔離・手順型 が揃えば subagent、と思っておけば大方間違いません。
どっちを選ぶかの判断フロー
3軸を踏まえて、最初に手を伸ばす道具を選ぶフローを並べます。
| 状況 | 選ぶ道具 |
|---|---|
| 同じ前置き（規約・口調・命名）を毎回コピペしている | skill（reference 型） |
| 30ファイル読まないと判断できない調査が頻発する | subagent（Explore など内蔵を活用） |
「コミットして」「デプロイして」のような手順を /コマンド 化したい | skill（task 型・disable-model-invocation: true） |
| 大きな実装の前に「設計だけ別働で考えてほしい」 | subagent（Plan を明示呼び出し） |
| メイン会話を汚さずに重い処理を回したい | subagent |
| 既に対象ファイルが分かっている小さな修正 | どちらも不要（メインで直接 Read） |
最後の行が大事です。何でも skill か subagent にするのが正解ではありません。日常の小さな修正は素のメイン会話のままが最速で最安です。skill / subagent は 同じ依頼の繰り返し か 重さに耐えかねる場面 にだけ手を伸ばす道具、と覚えておきます。
組み合わせる2つのパターン
ここからが本記事の核心です。subagent と skills は 別々に使うだけでなく、組み合わせる こともできます。公式ドキュメントは、双方向の組み合わせ を以下の対比で説明しています。
| 組み合わせ方 | 起点 | やりたいこと |
|---|---|---|
| subagent に skills を pre-load | subagent 側 | 自作 subagent に、決まった専門知識を最初から持たせたい |
| skill から subagent を fork | skill 側 | 手順型の skill を、メインの会話を汚さず別コンテキストで走らせたい |
パターン A：subagent に skills を pre-load する
subagent の frontmatter に skills フィールドを書くと、subagent の起動時に skill の中身（SKILL.md 全文）が subagent のコンテキストに inject されます。
---
name: api-developer
description: API 実装に特化した subagent。team の規約に沿って実装する
skills:
- api-conventions
- error-handling-patterns
---
API エンドポイントを実装してください。pre-load された skill の規約に従ってください。ここでの大事な性質が2つあります。ひとつめは、subagent は 親会話から skills を継承しない。明示的にリストしたものだけが入ります。ふたつめは、リストした skill の 本体（SKILL.md 全文）が起動時に injected される——通常の skill のように「呼ばれたときだけ展開」ではなく、最初から全部読んでいる状態 で subagent が動き始めます。
この組み合わせは、「特定の役割の subagent に、その役割専用の知識を最初から持たせたい」ときに効きます。たとえば「コードレビュー専用 subagent」に「うちのコーディング規約の skill」を pre-load しておけば、毎回ゼロから規約を説明する必要がなくなります。
パターン B：skill から subagent を fork する
skill の frontmatter に context: fork を書くと、その skill は メイン Claude ではなく subagent の独立コンテキストで実行 されます。
---
name: deep-research
description: 指定したテーマを徹底的に調査する
context: fork
agent: Explore
---
$ARGUMENTS について徹底的に調査してください：
1. 関連ファイルを Glob と Grep で探す
2. コードを読んで分析する
3. 具体的なファイル参照とともに結果をまとめるagent: Explore で、どの subagent 設定（内蔵 or 自作）で走らせるかを指定します。skill の本文が subagent への依頼文（task） として渡され、サマリだけがメイン会話に返ってきます。
この組み合わせは、「手順型の skill を /コマンド で叩きたいが、メイン会話のコンテキストは汚したくない」ときに効きます。/deep-research auth と打つだけで、メインを巻き込まずに調査が走ってサマリが戻ってくる——という体感になります。
2つのパターンの違いを整理
A と B は どちらが上位 という話ではなく、起点が違う だけです。
| システムプロンプト | 実行する仕事 | 一緒に読まれるもの | |
|---|---|---|---|
| A. subagent に skills | subagent の本文 | Claude からの依頼メッセージ | pre-load された skills + CLAUDE.md |
| B. skill が context: fork | agent タイプの本文（Explore 等） | SKILL.md の本文 | CLAUDE.md |
A は subagent が主役で、skills が補強材。B は skill が主役で、subagent が実行環境。自分が何を主役にしたいかで、どちらから書き始めるかが決まります。
設計の手順：3ステップ
役割分担の設計は、次の順で進めると無駄が出ません。
Step 1. 「いつもの前置き」と「いつもの重い作業」を書き出す
まず、自分が Claude に 繰り返し渡している前置き（規約・口調・テンプレ）と、繰り返し頼んでいる重い作業（広範な調査・大量ファイル読み込み）を別々のリストにします。
前置き側は skills の候補、重い作業側は subagent の候補 です。最初は分けて整理する方が、頭が混乱しません。
Step 2. それぞれを reference / task / subagent に振り分ける
skills 候補をさらに2つに分けます。「会話の流れの中で参照されるもの」は reference 型、「/コマンド で叩きたい手順」は task 型 です。
subagent 候補は、ほとんどの場合 内蔵の Explore / Plan / general-purpose で間に合います。最初から自作に走らないこと。「内蔵で足りないか？」を3回は自問してから自作の検討に入ると、無駄なファイルが増えません。
Step 3. 組み合わせるべきものを見つける
振り分けが終わったら、リストを横断して 組み合わせ候補 を探します。判断のしどころは2つ。
ひとつめ：「ある subagent を起動するたびに、毎回同じ前置きを言っている」 → その前置きは skill にして、subagent に pre-load する（パターン A）。
ふたつめ：「ある手順型 skill が、メインのコンテキストを大きく汚している」 → その skill に context: fork を足して subagent に逃がす（パターン B）。
最初から組み合わせを設計しようとせず、単独で動かしてみて困りごとが見えたら組み合わせる くらいの順序がちょうど良いです。これは hooks の設計（前回記事「hooks による自動化設計」で扱った「最小から仕掛ける」）と同じ思想です。
ありがちな失敗
ふたつだけ、ありがちな失敗を共有しておきます。
ひとつめは subagent を作りすぎる こと。「コードレビュー専用」「ドキュメント執筆専用」「テスト作成専用」と特化 subagent を量産すると、メイン Claude が どれを呼ぶべきか判断に迷う 状態になります。SubAgent は 内蔵3つ（Explore / Plan / general-purpose）で7割の仕事は片付く と思っておくのが安全です。自作は「内蔵では明らかに不足」が見えてからで遅くありません。
ふたつめは skills の description を曖昧に書く こと。skill が起動するかどうかは description の書き方で決まります（Skills 自作編 で詳述）。「コーディング規約」のような曖昧な description だと、Claude が呼ぶべき場面で呼んでくれません。「LP のコーディングを依頼されたとき」「API エンドポイントを実装するとき」のように、トリガーになる場面を具体的に書く——これだけで起動率がぐっと上がります。pre-load の場合（パターン A）は description よりも skills フィールドの明示が効くので影響は薄いですが、通常の skill 利用ではここがいちばんの落とし穴です。
ハーネスの完成——シリーズ全体の振り返り
本記事をもって、Step 5 ハーネス設計シリーズは終わりです。最後に、4本を通してハーネスがどう組み上がったかを振り返ります。
1本目で ハーネスとは何か——7つの部品（settings.json / permissions / hooks / CLAUDE.md / skills / subagents / MCP）を1つの設計として束ねる視点を導入しました。
2本目で 境界——permissions と settings.json で「どこまで Claude に許すか」を設計する手順を整理しました。
3本目で 仕掛け——hooks で「いつ・何を自動的に動かすか」を設計する3軸（確実性 / 観察 / ガード）を整理しました。
そして本記事で 役割分担——subagent と skills を、単独でも組み合わせでも使い分ける判断軸を整理しました。
境界 → 仕掛け → 役割分担。この順で揃えると、Claude Code は「素のままの便利な道具」から「自分の作業環境」に変わります。1本目の冒頭で書いた「人の作業環境を覗くと別物に見える、あの違和感」の正体は、まさにこの3層の有無の差です。
完成したハーネスは、Git で ~/.claude/ を管理しておけば 新しいマシン・新しいプロジェクトでもすぐに同じ環境が立ち上がる 状態になります。これが Step 4 の スタイルガイド と組み合わさると、自分の流儀がそのまま外に持ち出せる——という1本目で予告した姿に着地します。
まとめ
要点を振り返ります。
- skills と subagent は 別物：skills は知識のパッケージ、subagent は別働の Claude
- 判断は 3軸（知識 vs 実行／軽い vs 重い／参照型 vs 手順型）で考える
- 内蔵 subagent（Explore / Plan / general-purpose）で7割は片付く。自作は不足が見えてから
- 組み合わせは 2方向：subagent に skills を pre-load する／skill が context: fork で subagent を呼ぶ
- 設計手順は 書き出す → 振り分ける → 組み合わせを見つける
- 単独で動かして困りごとが見えてから組み合わせる。最初から組み合わせを設計しようとしない
- skills の起動率は description の具体性 で決まる
- ハーネスは 境界 → 仕掛け → 役割分担 の3層で完成する
これで Step 5 ハーネス設計シリーズは完結です。次のステップは、本シリーズで身につけた「設計の視点」を 自分のハーネスに当てて、実際に ~/.claude/ を整える段階に進むこと。学習マップでいえば、Step 5 の残り（Skills 自作・MCP 自作・Hooks の書き方・SubAgent 活用例）を、本シリーズで得た 設計の地図 とともに読み直すと、見え方が変わっているはずです。
WordPressを実際に動かしてきたサーバー：ロリポップ
Claude Code でWordPressサイトを組み立てるとき、最初に置く先として無理のないレンタルサーバー。月数百円から始められ、WordPressの自動インストールにも対応しています。設定で詰まりがちな初期段階の時間をかなり減らせます。