Claude Skillで使う2種類のサブエージェントー context: fork と agents/ ディレクトリの違いを精査する

はじめに
前提：スキルとサブエージェントの既定の動き
仕組み1：context: fork ―― スキル自身をサブエージェント化する
仕組み2：agents/xx.md ―― スキルが指揮役として複数を束ねる
決定的な違い：サブエージェントは入れ子にできない
比較表
使い分けの指針
つまずきやすいポイント
おわりに

はじめに

ClaudeでSkillを書いていると、重い処理や独立した調査を、コンテキストを節約する観点でサブエージェントにまかせたい場面がよくあります。

その手段として、SKILL.mdのfrontmatterに context: fork を書く方法と、スキルフォルダの agents/ 配下にエージェント定義ファイル（agents/xx.md）を置く方法の2つを目にします。どちらも「サブエージェントを起動する」仕組みに見えますが、実際には別のレイヤーの話であり、できることも使いどころも違います。

この記事では両者を公式ドキュメントの仕様に沿って精査し、どちらをいつ使うべきかをはっきりさせます。すでにClaudeでskillsを書いているみなさんにとって参考となれば幸いです。

結論を先に言うと、両者の関係は次のとおりです。

context: fork ＝ スキル自身を1個のサブエージェントとして走らせる宣言（実行モード）
agents/xx.md ＝ スキルが指揮役となって複数のサブエージェントに役割を配るための定義（オーケストレーション）

前提：スキルとサブエージェントの既定の動き

整理の土台として、2つの既定動作を押さえておきましょう。

スキルは、既定ではメイン会話のコンテキスト内でインラインに動きます。SKILL.mdの内容が会話に差し込まれ、そのままの文脈で実行されます。

サブエージェントは、独立したコンテキストウィンドウを持ちます。親の会話履歴は見えず、作業の途中経過は親に流れ込まず、最後に要約だけが返ってきます。検索結果やログで主会話を汚さずに済むのが利点です。そしてもう一つ重要な制約として、サブエージェントはさらにサブエージェントを起動できません（入れ子不可）。この制約が後で効いてきます。

仕組み1：`context: fork` ―― スキル自身をサブエージェント化する

frontmatterに context: fork を書くと、そのスキルはフォークされた（隔離された）サブエージェントのコンテキストで実行されます。ポイントは、SKILL.md本文そのものがサブエージェントへのプロンプト（タスク）になることです。隔離されているため、サブエージェントは主会話の履歴を参照できません。

組み合わせて使うのが agent フィールドで、どのサブエージェント構成（システムプロンプト・ツール・モデル）で実行するかを指定します。

---
name: deep-research
description: トピックを徹底的に調査する
context: fork
agent: Explore
---

$ARGUMENTS について徹底的に調査せよ：

1. Glob / Grep で関連ファイルを特定する
2. コードを読み解く
3. ファイル名を添えて所見をまとめる

agent に指定できるのは、組み込みエージェント（Explore / Plan / general-purpose）か、.claude/agents/ に置いた任意のカスタムサブエージェントです。省略時は general-purpose になります。システムプロンプトは選んだエージェント側から来て、CLAUDE.mdも読み込まれます（ただし Explore と Plan はコンテキストを小さく保つためCLAUDE.mdとgit statusをスキップします）。*1

動作の流れは次のとおりです。

新しい隔離コンテキストが作られます
サブエージェントがSKILL.md本文をプロンプトとして受け取ります
agent が実行環境（モデル・ツール・権限）を決めます
結果が要約されて主会話に返ります

注意点が1つあります。context: fork は実行可能なタスクが本文にあるスキルでしか意味をなしません。「このAPI規約に従え」のようなガイドライン（reference）だけのスキルをforkしても、サブエージェントは指示を受け取るだけで、actionableなプロンプトがないため何も生み出さずに返ってきます。

要するに context: fork は、1回の起動につき1個のforkです。スキルが「自分を1個のサブエージェントとして隔離実行する」宣言であり、フロントマター1行で完結する宣言的（declarative）な仕組みです。

仕組み2：`agents/xx.md` ―― スキルが指揮役として複数を束ねる

もう一方は構造が逆になります。スキル本体はメインコンテキストに残ったまま「コーディネーター（指揮役）」として動き、agents/ 配下の役割定義ファイルを使って、Agent ツールで複数のサブエージェントを起動します。多くの場合、独立した観点を同一ターンで並列に起こします。

実例として、社内の project-init スキル（プロジェクト立上げ）はこの形を採っています。スキルフォルダの構成は次のとおりです。

project-init/
├── SKILL.md                         # コーディネーター本体
├── agents/
│   ├── s1-project-overview.md       # S1 概要シート 専任
│   ├── s2-stakeholder-org-chart.md  # S2 体制図 専任
│   ├── s3-initial-risk.md           # S3 リスク 専任
│   └── s4-communication-plan.md     # S4 コミュニケーション計画 専任
└── references/
    └── output-template.md

SKILL.md本文には「agents/ 配下に4つの専任サブエージェント定義がある。必ず同一ターンで4つ並列に Agent ツールを発火する」と明記され、各サブエージェントには「役割定義は次のファイルを最初に読め: <絶対パス>/agents/sN-...md」というプロンプトを渡します。4本の結果が戻ってきたら、コーディネーターがテンプレートに沿って統合します。

ここで実装上の重要なニュアンスがあります。agents/xx.md が「名前付きサブエージェント」として自動登録されるかどうかは、そのフォルダがプラグインかどうかで決まります。

スキルフォルダに .claude-plugin/plugin.json がある（skills-dirプラグイン）か、プラグインのルート agents/ に置いた場合 ―― plugin:agent のようなスコープ付きの名前で自動登録され、エージェント種別として呼べます（自動委譲・@メンション・後述の agent フィールドからの参照）。*2
plugin.json を持たない素のスキルフォルダの場合 ―― agents/*.md は単なるサポートファイル（役割定義ドキュメント）にすぎません。自動登録はされないので、上の project-init のようにコーディネーターが汎用 Agent を起動し、各サブエージェントへパスでファイルを読ませる形で「手動」に束ねます。

project-init には plugin.json がないため、後者のパターンです。つまり agents/ フォルダは「並列で配る役割の置き場」であり、束ねるロジックはSKILL.md本文が命令的（imperative）に書いています。

決定的な違い：サブエージェントは入れ子にできない

ここが両者を分ける核心です。前提で触れたとおり、サブエージェントはさらにサブエージェントを起動できません。*3

この制約を context: fork に当てはめると、forkされたスキルはそれ自体が1個のサブエージェントなので、その中からさらに複数のサブエージェントへファンアウトすることはできません。

だから「独立した観点をN個並列に走らせて最後に統合したい」ワークフローでは、指揮役のスキルはインラインで動かす必要があり、context: fork を付けてはいけません。project-init のコーディネーターがあえてインライン実行なのは、まさにこの理由によります。逆に、自己完結した重いタスクを1個隔離したいだけなら、context: fork がいちばん素直な隔離手段になります。

比較表

観点	`context: fork`	`agents/xx.md` + 本文の指揮
レイヤー	スキルの実行モード	スキルが配る役割の定義
書き方	frontmatter 1行（宣言的）	SKILL.md本文で `Agent` 起動（命令的）
サブエージェント数	1スキル＝1個（fork）	1スキルからN個（並列可）
スキル本体の居場所	隔離コンテキストへ移動	メインに残り指揮役を務める
プロンプトの出所	SKILL.md本文がそのままタスク	コーディネーターが各役割に指示を生成
ファンアウト	不可（入れ子禁止のため）	可能（並列実行が主目的）
主な用途	重い単一タスクの隔離・コンテキスト保護	独立観点の並列処理→統合

使い分けの指針

自己完結した重い処理を1つ、主会話を汚さず隔離したい（深い調査、長いログ処理、レポート生成など）→ context: fork。agent で Explore などを選べば軽量・読み取り専用で走ります。
独立した複数の観点を並列に処理して最後に統合したい → スキルはインラインのコーディネーターにし、agents/ の役割定義を Agent ツールで並列起動します。
役割を再利用・配布したい（チームで共有、複数スキルから参照）→ スキルフォルダをプラグイン化して agents/ を名前付き登録し、context: fork の agent フィールドから参照します。

最後の項目が示すとおり、2つは排他ではなく組み合わせられます。context: fork の agent フィールドは、.claude/agents/（やプラグインの agents/）に定義したエージェントを名指しできます。つまり「agents/ で定義したエージェント」を「context: fork で実行する」という橋渡しが成立します。agent フィールドこそ、2つの仕組みをつなぐ接点です。

つまずきやすいポイント

タスクのないスキルをforkする ―― ガイドラインだけのreferenceスキルに context: fork を付けても無意味な空振りになります。actionableな指示を本文に書きましょう。
agents/ を置けば自動で呼べると思い込む ―― plugin.json がない素のスキルでは自動登録されません。コーディネーター本文から明示的に起動する設計にしましょう。
指揮役スキルをforkしてしまう ―― 複数サブエージェントへ配りたいスキルに context: fork を付けると、入れ子禁止で破綻します。指揮役は必ずインラインに保ちましょう。

おわりに

context: fork と agents/xx.md は「どちらでサブエージェントを起こすか」という二択ではなく、「スキル自身をサブエージェント化する（fork）」のか「スキルが指揮役として複数サブエージェントを束ねる（agents/）」のかという、役割の違いでした。判断の決め手は「ファンアウトが要るか」と「サブエージェントは入れ子にできない」という制約に尽きます。

筆者は普段から project-init をはじめとする並列オーケストレーション型のスキルを運用していますが、この2つを混同すると「forkしたのに並列に配れない」という詰みに必ず一度はぶつかります。設計の最初に「このスキルは隔離されたい側か、指揮する側か」を決めておくと迷いません。

※ なお本記事の仕様は2026年6月3日時点のClaude Codeの公式ドキュメント（skills / sub-agents / plugins reference）に基づきますが、フォーク周りは更新が早い領域でもあります。挙動が変わったと感じたら一次情報での確認をおすすめします。