Claude Codeのエージェントワークフローパターン5選 — 自分の作業に合うパターンは?

Claude Codeを使い始めた頃、私はすべてをシンプルに考えていた。ターミナルを開いて「この機能を実装して」と打ち込み、結果を受け取る。ところが作業が複雑になるにつれ、このシンプルな方法は限界に当たった。ある作業は時間がかかりすぎ、あるものはコンテキストが混乱し、あるものはClaude Codeが方向を見失った。

調べていくうちにパターンが見えてきた。Claude Codeの「使い方」によって効率が劇的に変わる5つの方式だ。このポストではその5つのエージェントワークフローパターンをまとめる。

5つのパターン早見表

パターン	エージェント数	人の介入	主な用途
Sequential（順次）	1	各ステップ	段階的な作業、ドキュメント生成
Operator（オペレーター）	1	最小限	ツール活用、単一の複雑な作業
Parallel（並列）	複数	作業前後	独立した複数作業の同時処理
Teams（チーム）	複数	オーケストレーターのみ	役割分担が必要な複雑な作業
Autonomous（自律）	複数	ほぼなし	繰り返し・バッチ・クロン作業

最初はこの区別が学術的すぎると感じた。実際に使ってみて初めて違いがわかる。

パターン1: Sequential（順次）

最もシンプルで直感的なパターンだ。人が途中で介入しながら段階的に作業を進める。

# 例: コードレビュー → 修正 → テスト → ドキュメント化
claude "このPRのコードレビューをして"
# レビュー確認後、必要な修正を指示
claude "さっきレビューしたA、B項目を修正して"
# 修正確認後
claude "修正したコードのテストコードを追加して"

人が毎ステップ結果を確認し、次の指示を出す方式だ。遅いが、コントロールが最も高い。

いつ使うか: 成果物の品質をステップごとに検証する必要があるとき、または作業の間に判断が必要なとき。特に初めて見るコードベースを探索するとき、このパターンが安全だ。

率直な評価: 繰り返し作業では疲労度が高い。5ステップの作業なら5回画面を確認しなければならない。

パターン2: Operator（オペレーター）

単一エージェントにMCPツールやBash実行権限を与え、複雑な作業一つを任せる方式だ。

# CLAUDE.mdに権限範囲を明確に定義した後
claude "src/フォルダのすべてのTypeScriptファイルを分析して
        型エラーのリストをreport.mdにまとめ、
        修正可能なものは修正して"

核心は権限範囲を明確に定義することだ。.claude/settings.jsonやCLAUDE.mdに、どのファイルを触れてよいか、どのコマンドを実行できるかを事前定義する必要がある。

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Read", "Edit"],
    "deny": ["Bash(rm *)", "Bash(git push *)"]
  }
}

いつ使うか: コンテキストが明確で範囲がよく定義された単一の複雑な作業。例:「このモジュールのすべての関数にJSDocを追加」「このディレクトリのファイル名をすべてkebab-caseに変換」

Claude Codeのベストプラクティスでは、CLAUDE.mdを通じた権限設計を詳しく解説しているので、合わせて参照するといいだろう。

パターン3: Parallel（並列）

互いに依存関係のない複数の作業を同時に処理するパターンだ。Git Worktreeを活用して独立した作業環境を作る。

# 3つの独立したworktreeを作成
git worktree add ../feature-auth feature/auth
git worktree add ../feature-dashboard feature/dashboard
git worktree add ../docs-update docs/update

# 各worktreeで別々のClaude Codeセッションを実行
cd ../feature-auth && claude "JWT認証を実装して"
cd ../feature-dashboard && claude "ダッシュボードコンポーネントを最適化して"
cd ../docs-update && claude "APIドキュメントを最新化して"

この方式に切り替えてから、個人の生産性が目に見えて変わった。特にCIパイプラインを待っている時間に別のブランチ作業を進められるのは、実質的に大きい。

Git Worktreeで並列セッションを運用する具体的な方法は別のポストでステップごとに解説した。初めて設定するなら、そちらを先に見る方が早い。

いつ使うか: 独立したフィーチャー開発、多言語翻訳、テストコード作成など、互いにコードベースを共有しなくていい作業。

注意: 同じファイルを触る作業を並列で動かすと衝突が生じる。作業間の依存関係の確認が前提だ。

パターン4: Teams（チーム）

オーケストレーターエージェント一つが複数のサブエージェントに作業を委任するパターンだ。Claude Codeのサブエージェント機能を活用する。

# オーケストレーターに渡すプロンプト例
以下の作業を順番に処理して:
1. @researcher: このトピックに関する最新技術トレンドを調査
2. @writer: 調査結果をもとにブログ記事の草案を作成
3. @editor: 草案のSEO最適化と校正
4. @publisher: 完成した記事を4言語に翻訳してファイル保存

チームパターンの核心は役割分離だ。各エージェントは自分の領域だけを知り、オーケストレーターが全体の流れを調整する。

実際にこの方式は、一つのエージェントのコンテキスト長の限界を分散させる効果もある。大きな作業を一つのエージェントに任せるとコンテキストウィンドウが爆発するが、チームに分けると各自が自分の作業コンテキストだけを維持すればよい。

OpenClaw環境でエージェントチームを実際に構成・運用した経験をまとめたポストがある。役割設計からtmuxベースのモニタリングまで具体的に書いてある。

いつ使うか: 順次的だが複雑なマルチステップ作業。コンテンツパイプライン、コードレビュー → 修正 → テスト → デプロイサイクルなど。

実際にマルチエージェントオーケストレーションをブログシステムに適用したときの失敗と改善プロセスを見ると、役割の境界が不明確だとエージェント同士が衝突したり、無限ループに陥ったりすることを実感した。

パターン5: Autonomous（自律）

人の介入なしにクロンやイベントトリガーで実行される完全自律パターンだ。このブログの日次投稿パイプラインがこの方式で運用されている。

# launchdまたはcronで実行
#!/bin/bash
cd ~/workspace/blog
claude --no-interactive "
  今日の技術トレンドを調査し、
  ブログ記事を4言語で作成して、
  ビルド検証後git pushまで完了させて。
  失敗時はTelegramで通知送信。
"

このパターンを使うには前提条件がある:

• 明確な成功/失敗基準の定義が必須
• ロールバックメカニズムの準備（git revertなど）
• モニタリングと通知の設定（Hooksのstopイベント活用）

正直に言うと、自律パターンは最初は過信しやすい。うまく動くときは魔法のようだが、エージェントが間違った方向に走り出すと止めるのが思ったより難しい。特にファイルシステムを触ったり外部サービスに書き込んだりする作業は、必ずdry-runモードで先に検証することを勧める。

どのパターンを選ぶべきか

私がパターンを選ぶときに使う基準だ:

作業を途中で確認する必要があるか?

• Yes → Sequential

作業が複数あり、互いに独立しているか?

• Yes → Parallel

役割が明確に区分された複雑なパイプラインか?

• Yes → Teams

繰り返し・スケジュール実行が必要で、十分に検証されているか?

• Yes → Autonomous

その他の単一の複雑な作業?

• Operator

シンプルに見えるが、実際には複合パターンが多い。例えばこのブログの自動化パイプラインはTeams + Autonomousの組み合わせだ — チームパターンでコンテンツを生成し、そのパイプライン全体が自律でスケジュール実行される。

パターン選択より重要なこと

エージェントパターンをどれだけうまく設計しても、CLAUDE.mdと権限設定がずさんでは意味がない。私が経験した失敗パターンで最も多かったのは「範囲が広すぎるOperator」だった。エージェントが触ってはいけないファイルを修正したり、予期しないbashコマンドを実行したりした。

各パターンを最初に導入するときは、作業範囲を狭く始めて徐々に広げていくのが安全だ。パターン自体よりも境界設定が核心だ。