Subagent のコンテキストはどう分離される？

Subagentは本体とは別のClaudeインスタンスです。ファイルシステム経由で情報受け渡しし、本体のコンテキスト履歴はSubagentに渡りません。

フリーランスエンジニアの Claude Code Subagents 活用術 2026 — 1人運営で並列処理を最大化する設計パターン

Q: Subagents は Claude Code Max プランでなくても使える？

使えます。Proプラン ($20/月) でもSubagent起動可能ですが、並列起動数が制限されます。重い並列処理（5+並列）を頻繁にやるならMax 5x ($100/月) 以上が現実的です。

Q: Subagent の指示はどこに置く？

~/.claude/agents/{name}.md (個人用) または .claude/agents/{name}.md (プロジェクト用) です。Skillsと似た配置ですが別ディレクトリです。

Q: Subagent と Skills の見分け方は？

実行体が必要かで判断します。「手順をルール化したい」ならSkills、「実際にタスクを実行させる」ならSubagent。両方併用が普通（SubagentがSkillを実行する形）です。

Q: Subagent 起動コストは？

トークン消費は通常のClaude呼び出しと同じです。Maxプランの月額枠でSubagent起動回数も消費されます。1日100回など乱用すると枠を食います。

Q: チーム共有はどうする？

プロジェクト用Subagentは .claude/agents/ にcommitしてgitで共有。個人用Subagentは ~/.claude/agents/ をdotfilesリポジトリで管理するのが標準です。

Q: Subagent が無限ループしたら？

Claude Code本体が監視しており、ステップ数上限で停止します。心配ならCLAUDE.mdに「Subagentは最大10ステップで停止」のような制約を書きます。

Home / Blog / フリーランスエンジニアの Claude Code Subagents 活用術 2026 — 1人運営で並列処理を最大化する設計パターン

フリーランスエンジニアの Claude Code Subagents 活用術 2026 — 1人運営で並列処理を最大化する設計パターン

Claude Code Subagents は1人運営フリーランスにとって最強の戦力倍増装置。汎用エージェントと専門エージェントの使い分け、自作Subagent実装パターン、Skills/Hooks/MCP との連携、コンテキスト分離戦略まで、エンジニア視点の運用ノウハウを実例ベースで解説（2026年5月版）。

エンジニアのゆとです。

Claude Code Subagents が登場してから、フリーランス1人運営の 「同時に複数のことができない」問題 が解けた。

僕は今、Claude Code でブログ運営・経理・営業・顧客対応・自動化スクリプト整備の5領域を1人で回している。Subagents を使う前は「全部自分が判断する」で1日が終わっていた。今は 専門領域ごとに Subagent を持って並列で動かすことで、同じ8時間の中で2-3倍の仕事が回るようになった。

ただし「Subagent を作れば自動で楽になる」は嘘で、作り方を間違えると逆にコンテキスト爆発で遅くなる。本記事では、フリーランス1人運営という極端な条件で Subagent を運用してわかった「実用ノウハウ」を書く。

結論：30秒で Subagents が必要な理由

メインのClaude Codeコンテキストを守る — 細かいタスクで本体の100万トークンを圧迫しない
専門知識を分業化 — 「ブログ公開担当」「経理担当」「コード生成担当」を分離
並列実行で時間圧縮 — 5タスクを5 Subagent で同時に走らせる
品質基準が安定する — 同じ Subagent に同じプロンプトで毎回同じ品質

CLAUDE.md は「会社の憲法」、Skills は「専門部署のマニュアル」、Subagents は「実際に動く専門スタッフ」。フリーランスにとって最後の1つが一番効く。

Claude Code Subagents とは（簡潔）

Subagent は、Claude Code 本体が別の Claude インスタンスを起動して、特定のタスクを委譲する仕組み。

# ~/.claude/agents/blog-publisher.md または .claude/agents/blog-publisher.md
---
name: blog-publisher
description: ブログ記事を Astro でビルドして公開する専門エージェント
tools: Bash, Read, Edit
---

# ブログ公開エージェント

あなたは Astro ブログの公開を担当する専門エージェントです。

1. RELEASE_SCHEDULE.json から対象記事を取得
2. heroImage / cardImage 存在確認
3. npm run build でエラーなしを確認
4. git add / commit / push
5. HTTP 200 確認

問題があれば本体に報告して停止します。

これだけで、メインの Claude Code から Use the blog-publisher subagent to publish today's article と呼べる。

詳しい仕様は

記事が見つかりません: claude-code-subagents-2026-guide

で（書いてなければPSの公式リファレンスを参照）。

フリーランスが Subagents を使うべき5つの理由

1. メインコンテキストが汚れない

Claude Code は1セッション100万トークンだが、複雑な調査やデバッグで一気に消費する。Subagent に「コードベース調査」「公式docs精読」を委譲すれば、本体は要約だけ受け取る。本体のコンテキスト消費が10分の1に。

2. 専門領域ごとに「人格」を持てる

blog-publisher: ブログ公開専門
invoice-handler: 請求書発行専門
code-reviewer: コードレビュー専門
research-lead: 競合分析・公式docs読み込み専門

各 Subagent に異なる文体・判断基準を持たせられる。blog-publisher には敬語・SEO重視、code-reviewer には厳しい指摘モードを設定する。

3. 並列実行で時間圧縮

1つのプロンプトで複数 Subagent を同時起動できる。「ブログ記事3本を別々の Subagent で同時に書かせる」とかが可能。1本ずつ書くと3時間、並列なら1時間で終わる。

4. ミスが本体に波及しない

Subagent が変な変更をしてもメインのコンテキストや作業環境に影響しにくい。サンドボックス的な使い方ができる。

5. 引き継ぎ可能

Subagent 定義は markdown ファイル。git で管理してチーム共有・他PCへの移植が楽。「自分のノウハウを Subagent として外部化」が可能。

CLAUDE.md / Skills / Subagents の使い分けマトリクス

実運用での判断基準。

性質	CLAUDE.md	Skills	Subagents
いつ読まれる	毎セッション	名詞で呼ばれた時	タスク委譲時
コンテキスト	本体に常駐	本体に常駐 (必要時)	別インスタンスに隔離
並列実行	×	×	○
例	「ファイル整理ルール」	「ブログ公開フロー」	「ブログ公開を実行」
出力	振る舞いに反映	振る舞いに反映	最終結果のみ本体に返す

3層思考:

CLAUDE.md: 「何が大事か」の価値観・規約 → 全タスク共通
Skills: 「どう進めるか」の手順書 → 特定タスクの呼び出し時
Subagents: 「実際に進める実行体」 → 並列・分離が必要な時

フリーランス1人運営での Subagent 設計パターン

実際に運用してる Subagent 5つを共有する。

パターン1: blog-publisher（ブログ公開専門）

---
name: blog-publisher
description: yuto-lab.com のブログ記事を Astro でビルド・公開する
tools: Bash, Read, Edit
---
# ブログ公開エージェント
- frontmatter 完全性チェック (heroImage / pubDate / draft)
- npm run build エラー確認
- git add / commit "publish: 記事タイトル"
- git push
- HTTP 200 確認 + 失敗時のリトライ判断

効果: 毎日のブログ公開フローを 1コマンドで完了。手作業ミスゼロ。

パターン2: research-lead（リサーチ専門）

---
name: research-lead
description: 競合分析・公式docs精読・GSC データ取得を行うリサーチ専門
tools: WebSearch, WebFetch, Bash, Read
---
# リサーチ専門
- 競合記事 TOP3-5 を WebFetch で全文取得
- 公式 docs (Anthropic / OpenAI / GitHub) を精読
- GSC データから対象クエリの imp / pos / CTR を取得
- 出力: 差別化軸 3-5個 + 構成案

効果: メインの Claude Code はリサーチ結果サマリだけ受け取る。本体のコンテキスト浪費が激減。

パターン3: code-reviewer（コードレビュー専門）

---
name: code-reviewer
description: コード変更を厳しくレビューし、セキュリティ・パフォーマンス・可読性の問題を指摘
tools: Read, Bash, Grep, Glob
---
# 厳しいレビュアー
- 変更ファイル全部 Read
- セキュリティ: ハードコードシークレット / SQL injection / XSS
- パフォーマンス: N+1 / 不要な再レンダリング
- 可読性: 命名 / 抽象化レベル
- 出力: 重要度別の指摘リスト

効果: 別人格のClaudeにレビューさせるので、書いた本人の盲点を埋められる。

パターン4: invoice-handler（経理専門）

---
name: invoice-handler
description: クライアント別の請求書発行と freee 連携を担当
tools: Bash, Read, Write
---
# 経理担当
- 案件管理 JSON から今月分の請求対象を抽出
- クライアント別に請求書 PDF を生成
- freee API に取引登録
- 送付メール下書き作成

効果: 月末の半日仕事が30分に圧縮。

パターン5: keikou-original（X 投稿下書き専門）

---
name: keikou-original
description: X (@diewithlight) のオリジナル投稿下書きをトレンド起点で生成
tools: Bash, Read, Write
---
# X 投稿下書き
- トレンド収集スクリプト実行
- 型カタログから 5-7 件選定
- 文体被り回避で下書き生成
- CDP 9223 投稿画面に入力

効果: 朝の Xポスト準備 30分 → 5分。

Subagents 連携の3パターン

1. 直列パターン（依存あり）

本体 → research-lead → 本体 → blog-publisher

リサーチ結果を踏まえてブログ書く、というフロー。

2. 並列パターン（独立）

本体 → [research-lead, code-reviewer, invoice-handler] 同時起動

独立した3タスクを同時に処理。3倍速。

3. 階層パターン（マスター + ワーカー）

本体 → master-agent
        ├─ worker-1
        ├─ worker-2
        └─ worker-3

master-agent が複数 worker を統括して結果集約。

よくある失敗パターン

失敗1: Subagent を作りすぎる

「専門化」を意識しすぎて 20個以上の Subagent を作るとメンテ不能。5-7個に厳選して、汎用 Subagent + 特化 Subagent の組み合わせがバランス良い。

失敗2: Subagent の指示が長すぎる

CLAUDE.md と同じく、200-500行以内にする。長すぎると Subagent 自体のコンテキストが圧迫されて品質低下。

失敗3: 並列で同じファイル編集

並列実行の Subagent が同じファイルを編集すると競合する。ファイル単位・ディレクトリ単位で担当を分けるか、最後に merge する設計に。

失敗4: Hooks との連携忘れ

Subagent が実行する Bash コマンドにも Hooks が走る。PreToolUse / PostToolUse で Subagent の挙動を制御できることを忘れがち。

Subagents と Hooks / Skills / MCP の連携

組み合わせ	用途
Subagent + Hooks	Subagent 実行時に自動 lint / test / commit
Subagent + Skills	Subagent が Skill を呼んで処理 (例: blog-publisher が `/blog-publish` Skill を実行)
Subagent + MCP	Subagent が外部 API (Notion / Slack) を呼ぶ

最強パターン: master-agent が CLAUDE.md の価値観に従って、複数の Subagent を呼び、各 Subagent が Skills と MCP を組み合わせてタスク実行。