サブエージェントをいつ使うか迷ったら読む：Claude Code 5つのワークフローパターン

「サブエージェントを使えばいい」とドキュメントには書いてある。でも実際のタスクを前にすると、手が止まる。シンプルなプロンプト1本で済む話なのか、それとも複数のエージェントに分けるべきなのか。判断できないまま複雑な構成を組んで、1週間後には自分でもメンテできなくなった。そういう経験が一度はあるはずだ。

逆のケースもある。「1つのセッションでやればいい」と油断して、コンテキストが膨れ上がり、後半になるほど精度が落ちていく。どちらも困る。

この記事では、Claude Codeのワークフロー設計に使える5つのパターンを整理する。「いつ何を選ぶか」の判断軸を先に示してから、各パターンの具体的な実装に入る。

判断の前提：最もシンプルなものから始める
Sequential：出力を次の入力に渡し続ける
Operator：「脳」が計画し、ワーカーが実行する
Split-and-Merge：並列で走らせて最後にまとめる
Agent Teams：役割を持つエージェントが長期間協調する
Headless：人間が介在しない自律実行
パターンを選ぶとき、迷ったら

判断の前提：最もシンプルなものから始める

Claude Codeのアジェンティックワークフローを体系化した資料が共通して示す原則がある。

> "Pick the simplest pattern that gets the job done. Add complexity only when the simpler approach breaks." > — MindStudio: Beyond One-Shot Prompts: 5 Claude Code Workflow Patterns

複雑さは機能ではなく、コストだ。エージェントが増えるほど、調整のオーバーヘッド、エラー伝搬のリスク、デバッグの難易度が上がる。「最初はSequential、うまくいかなくなったら次の段階へ」という思考順序で選ぶといい。

5つのパターンと選択の目安を先にまとめる。

パターン	一言説明	使いどころ
Sequential	線形パイプライン	ステップ間に明確な依存がある、1〜2コンテキストで収まる
Operator	中央制御＋委譲	コンテキストウィンドウを超える規模、専門ごとに分けたい
Split-and-Merge	並列分割→統合	独立した大量タスクを速く処理したい
Agent Teams	役割固定チーム	複数セッションをまたぐ長期プロジェクト
Headless	人間不在の自律実行	定期実行、CI/CDトリガー、イベント駆動

Sequential：出力を次の入力に渡し続ける

最もシンプルなパターン。各ステップの出力が次のステップの入力になる線形パイプラインだ。

仕様書を読む → 関数を実装する → 単体テストを書く → テストを実行して結果を報告する、という流れがわかりやすい例。各ステップが前のステップに依存していて、順番を変えられない。

このブログ（enjoy-program.net）を動かしているblog-agentsパイプラインも、基本的にはSequentialだ。researcher → writer → tone-checker → plagiarism → auditor という5段階が順番に実行される。各エージェントがMarkdownファイルを受け取り、次のエージェントに渡す。

実装上の注意点は一つで、中間結果が大きくなるとコンテキストウィンドウに収まらなくなる。パイプラインが深くなるほどこのリスクが高まるため、その場合は次のパターンを検討する。

Operator：「脳」が計画し、ワーカーが実行する

コンテキストウィンドウ1つでは収まらない規模になったとき、あるいはサブタスクごとに必要な専門知識が大きく異なるとき、Operatorパターンが選択肢に入る。

中央のオペレーターエージェントが「何をどのエージェントに頼むか」を判断し、各ワーカーに委譲する。ワーカーの結果を収集して優先度付けし、最終的な出力を組み立てる。

コードベースのセキュリティ監査がよい例だ。オペレーターが認証コードのスキャンをSubagent A、DBクエリのスキャンをSubagent B、入力バリデーションの確認をSubagent Cに割り当てる。各サブエージェントは専門領域だけを見ればいい。

claude --allowedTools "Bash,Read,Write" -p "セキュリティ監査を実行してください"

--allowedTools でオペレーターの権限を絞ることがセキュリティ上の基本だ。オペレーターのコンテキストにサブエージェントの結果が積み上がりすぎると今度はオペレーター側のボトルネックになるため、返却するデータの粒度は設計時に決めておく。

Split-and-Merge：並列で走らせて最後にまとめる

独立したタスクが大量にあるとき、直列で処理するのは非効率だ。Split-and-Mergeは、コーディネーターがタスクをチャンク分割し、複数のClaudeインスタンスが並列実行し、最後に結果を統合する。

50個の関数にdocstringを追加する作業を例にとると、10バッチ（各5関数）に分割して10インスタンスを並列実行すれば、直列の10分の1の時間で完了する。ただしコストは並列数に比例するため、予算との兼ね合いが必要だ。

git worktreesとの相性がいい。コードベースを並列に変更する場合、ブランチを分けてworktreeを作れば競合を避けながら並列作業が進む。詳細はgit worktrees活用の記事（/2026/04/08/）を参照してほしい。

マージステップで詰まるのはたいてい出力スキーマの不統一だ。バラバラな形式で返ってくると統合処理が一気に複雑になるため、スキーマだけは先に決めておく。

Agent Teams：役割を持つエージェントが長期間協調する

Sequential × Operatorのハイブリッドとも言える構成で、役割が固定した専門エージェントが進行中のプロジェクトを横断して持続的に協調する。

ソフトウェア開発チームのアナロジーが近い。計画エージェントが目標と進捗を管理し、コードエージェントが実装し、テストエージェントが検証し、ドキュメントエージェントが変更後のdocsを更新する。各エージェントは固有のコンテキスト、ツールセット、役割を持ち、JSONなど定義されたフォーマットで通信する。

このブログのblog-agentsはまさにAgent Teamsの実例だ。5エージェントがそれぞれ .claude/agents/ に専用の設定ファイルを持ち、researcher はウェブリサーチ、writer は記事執筆、auditor は品質レビューに特化している。ドキュメントエージェントにシェル実行権限を与えないような「必要最小限のツールセット」の設計が、エージェント数が増えても安全に運用できる理由だ。

公式には agent teams としてドキュメント化されている（code.claude.com/docs/en/agent-teams）。ただし2026年5月時点では実験的機能扱いであり、利用には環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 の設定が必要だ。

マルチエージェントの概念的な導入については、以前のサブエージェント入門記事も参照してほしい。

Headless：人間が介在しない自律実行

cron、GitHub Actions、webhookなどでトリガーされ、Claudeが人間の介在なしにタスク完了または停止条件まで走り続ける。毎晩の依存関係スキャンとPR自動生成、CIトリガーでのテスト失敗診断、週次のAPI使用量監査あたりが筆者のよく使うケースだ。

-p（--print）フラグで非対話実行になる。CI/CD向けにはさらに --bare フラグを加えることが公式で推奨されている。--bare はhooks・skills・プラグイン・MCP・自動メモリ・CLAUDE.mdの自動検出をスキップし、起動を高速化する。

claude -p --bare \
  --allowedTools "Bash,Read,Write" \
  --permission-mode dontAsk \
  --output-format json \
  "依存関係を確認してセキュリティアップデートが必要なパッケージのPRを作成してください"

--output-format json で構造化出力を取得でき、total_cost_usd も含まれるため、コスト監視が自動化しやすい。

> ⚠️ 2026年6月15日以降の注意: Agent SDKおよび claude -p のサブスクリプション利用は、インタラクティブ利用枠とは別の新しい月次Agent SDKクレジットから引かれるようになる（公式ドキュメント参照）。Headlessでの定期実行を設計する際は、事前に予算計画に組み込んでおきたい。

Headlessは自動化の恩恵が最も大きいパターンだが、その分、設計が甘いと静かに壊れ続ける。設計前に確認しておきたいのは「失敗モードを自分が理解しているか」「操作は可逆か」「曖昧な判断が出たとき人間がレビューできるか」の3点だ。どれか1つでも怪しければ、まず小さいスコープで試す方がいい。

パターンを選ぶとき、迷ったら

5つ並べると選ぶのが難しく感じるかもしれないが、実際には次の順番に当てはめるだけだ。

1〜2コンテキストで収まるか → Sequential
規模が大きく、専門ごとに分けたいか → Operator
独立した大量タスクを速く処理したいか → Split-and-Merge
複数セッションをまたぐ長期プロジェクトか → Agent Teams
人間を介さず定期・イベント駆動で動かしたいか → Headless

前提として忘れてほしくないのが「シンプルなパターンで壊れるまで複雑にしない」という考え方だ。

blog-agentsを例にとると、5エージェントのSequential × Agent Teamsという構成は最初から設計したわけではなく、「1つのセッションで全部やると品質が安定しない」という問題が出てから専門分化した。複雑度を追加した理由が明確なので、メンテナンスの基準も明確になる。

まず、現在手動でやっている反復タスクを1つ選び、Sequentialパターンでスクリプト化してみてほしい。実際に詰まったとき、次のパターンへ移行する判断が初めて具体的になる。