Agent Mentor Learn
エージェントワークフローの設計: 単発の会話からマルチステップ自動化へ · 第 1 回 / 全 6 回

レッスン1: 会話からワークフローへ: オーケストレーションが存在する理由

学習目標:

  • 単一の会話とワークフローの根本的な違いを理解する
  • ワークフローに適したタスクの特性を認識する
  • ワークフローオーケストレーションの核心的価値を把握する

前提: Claude Codeや類似のAIツールを使用したことがある | 次: レッスン2 >>

エージェントが壁にぶつかる

Claude Codeに大規模なコードベースのリファクタリングを依頼します。「この5,000行のモノリスをマイクロサービスに分割して」

Claudeは作業を開始します。ファイルを読み、モジュールの境界を特定し、依存関係を抽出し、そしてファイル47あたりで、コンテキストウィンドウがいっぱいになります。以前の作業を忘れ、最初からやり直し、ループに陥ります。1

あるいは「すべてのオープンなPRをレビューして、今週のリリースノートを書いて」と依頼します。Claudeは一度に1つのPRしか処理できないため、手動で20回実行し、毎回フォーマットルールを再説明することになります。

これが単一の会話の上限です。1つの会話、1つのコンテキストウィンドウ、1つの推論チェーン。複雑なタスクに対して、このパターンは破綻します。2

ワークフローとは何か

ワークフローは、複雑なタスクをステップに分解し、各ステップを新しいエージェントに委譲し、全体を自身で調整する実行可能なスクリプトです。3

主な違い:

次元単一の会話ワークフロー
制御フローエージェントが次に何をするかを決定スクリプトが次に何をするかを決定
コンテキストすべての履歴が1つのウィンドウに存在各ステップが独自のコンテキストを持つ
並列性順次実行多数のエージェントを同時起動可能
再現性実行ごとに異なる可能性固定スクリプト、決定論的実行
適合するスケール小規模タスク(数ファイル)大規模タスク(数百ファイル、複数の検証段階)

例えば、リファクタリングワークフローは次のようになります:

スクリプトがループ、分岐、中間結果を保持し、Claudeのコンテキストは最終的な答えだけを見ます。オーケストレーションは決定論的で、各ステップ内の作業のみがモデル駆動です。3

ワークフローが適合する場合

ワークフローに適したタスクを示す4つの特性:

  1. 1つの会話が調整できる以上のエージェントが必要。 単一の会話は3〜5個のサブエージェントを管理できます。それを超えると、ワークフローが必要です。
  2. オーケストレーションを読みやすく再利用可能なスクリプトとして成文化したい。 一度書けば、いつでも再実行できます。
  3. タスクが明確なフェーズに分割される。 解析、計画、実装、検証。
  4. 並列実行やクロスチェックが必要。 独立したサブタスク、敵対的検証、トーナメント式比較。

公式ドキュメントは明確に述べています: "Reach for a workflow when a task needs more agents than one conversation can coordinate, or when you want the orchestration codified as a script you can read and rerun."(1つの会話が調整できる以上のエージェントが必要なタスク、またはオーケストレーションを読み、再実行できるスクリプトとして成文化したい場合にワークフローを選択してください)2

典型的なシナリオ:

  • コードベース監査。 500ファイルをスキャンし、セキュリティ問題をチェックするファイルごとに1エージェント、その後結果を集約。
  • 大規模マイグレーション。 200個のコンポーネントをVue 2からVue 3へ並列アップグレードし、最後に統合を検証。
  • クロスチェック研究。 5つのエージェントに同じ質問を独立に調査させ、事実をクロスチェックし、一貫性レポートを生成。
  • 多角的設計レビュー。 設計を3つの角度(アーキテクチャ、パフォーマンス、コスト)から独立に評価し、その後マージ。2

ワークフローが間違ったツールである場合:

  • 単一ファイルの編集やコードレビューなど、直接の会話で十分なシンプルなタスク。
  • クリエイティブライティングやブレインストーミングのようなオープンエンドの作業。
  • 多くの人間の判断が必要で、ステップに還元できないタスク。

ワークフローの進化

ワークフローは突然現れたわけではありません。Claude Codeのオーケストレーション能力の第4段階です:1

段階1: モノリシックエージェント

┌─────────┐│ Claude  │  1つのコンテキストウィンドウがすべてを実行:└─────────┘  読み込み、計画、編集、テスト

段階2: サブエージェントファンアウト(Agentツール)

┌─────────┐│ Claude  │──→ agent: "コードベースを検索"│ (main)  │──→ agent: "これら40ファイルを読む"└─────────┘  結果が親エージェントに返る

段階3: エージェントチーム

┌─────────┐    ┌─────────┐    ┌─────────┐│ Planner │───→│ Coder   │───→│ Tester  │└─────────┘    └─────────┘    └─────────┘     各エージェントが独自の役割とコンテキストを保持

段階4: ワークフローオーケストレーション

    ┌─────────────────┐    │ Workflow Script │  ループ、分岐、状態を保持    └────────┬────────┘         ┌───┴───┬───────┬───────┐         ↓       ↓       ↓       ↓    agent()  agent() agent() agent()    各呼び出しが独立したサブエージェントを起動

ワークフローの核心的革新は制御フローの反転です: エージェントに「次に何をすべきか」を決めさせる代わりに、スクリプトが「次にどのエージェントを呼び出すか」を決定します。3

オーケストレーションの本質

オーケストレーションは文字通りの意味です: "Orchestration is exactly what it sounds like: one score, many musicians. A script deciding it — for loop, if statement — is orchestration."(オーケストレーションはまさにその通りの意味です: 1つの楽譜、多数の演奏者。スクリプトがそれを決定する — forループ、if文 — それがオーケストレーションです)1

ワークフローにおいて:

  • 楽譜 = あなたが書くJavaScript/TypeScriptスクリプト、そのforループ、if文、Promise.all呼び出し。
  • 演奏者 = 各agent()呼び出しが起動するサブエージェント。
  • 指揮者 = スクリプトの実行エンジン、楽譜に従ってエージェントを調整。

これがその区別を、それを命名したガイドの言葉で: "A normal agent decides the control flow as it goes. A workflow inverts that. You write the control flow as plain code, and each individual step is delegated to a fresh subagent."(通常のエージェントは進むにつれて制御フローを決定します。ワークフローはそれを反転させます。制御フローをプレーンなコードとして書き、個々のステップは新しいサブエージェントに委譲されます)

通常のエージェントは実行時に即興します: 「最初にAを実行し、その後BかCのどちらを実行するか決定」。ワークフローは制御フローをコードで固定します: 「A1〜A10を並列実行し、すべて完了したらBを実行。Bがscore > 0.8を返せばCを実行、そうでなければD」。

決定論的オーケストレーションが得られるもの:

  • 予測可能。 同じ入力、同じ実行パス。
  • デバッグ可能。 どのステップが失敗したかが明白。
  • 再実行可能。 スクリプトは.claude/workflows/に存在し、名前で呼び出せる。
  • スケーラブル。 10エージェントから100エージェントへの移行は、ループカウントの変更だけ。3

最初のワークフローシナリオ: コードレビューパイプライン

実際のケースを見てみましょう。チームには15個のPRがレビュー待ちで、各PRには4つのチェックが必要です:

  1. コードはスタイルガイドに従っているか?
  2. 明らかなバグはないか?
  3. テストカバレッジは十分か?
  4. 関連ドキュメントは更新されたか?

単一の会話では、15回実行し、毎回手動でPRを切り替えます。

ワークフローでは:

このワークフローが得られるもの:

  • 15個のPRを並列レビュー、順次より15倍高速。
  • 一貫したレビュー基準(すべてのPRが同じプロンプトを使用)。
  • 毎週自動実行可能、手動ステップなし。
  • スクリプトはGitにコミットされ、チーム全体で共有される。

次: レッスン2 >> — ワークフロー構成要素: ステップ、状態、分岐、ループ

Footnotes

  1. ClaudeWorld: What Is a Workflow? Multi-Agent Orchestration Explained — https://claude-world.com/articles/what-is-a-workflow-multi-agent-orchestration/ 2 3

  2. Claude Code 公式ドキュメント: Workflows — https://code.claude.com/docs/en/workflows 2 3

  3. Alex Op: Claude Code Workflows and Deterministic Orchestration — https://alexop.dev/posts/claude-code-workflows-deterministic-orchestration/ 2 3 4

練習

01

過去1週間の作業を振り返り、反復的なタスクを見つけ、それがワークフローに適合するか判断してください:

レベル1: 最初のワークフローシナリオを見つける

基準:

  • 多数の類似した入力を処理する必要がある(多数のファイル、多数のデータソース、多数のサービス)
  • 明確なフェーズがある(抽出、変換、検証、出力)
  • プロセスが毎回同じ方法で実行されることを望む
  • 部分的または完全に並列実行可能

記述内容:

  1. タスクを1文で
  2. 現在どのように実行しているか
  3. ワークフローを使用した場合、どのフェーズに分割されるか
  4. どれだけの時間を節約できると予想するか
完了基準 · ローカルでチェック
02

次の2つのシナリオの1つを選び、なぜ一方が単一の会話に適し、もう一方がワークフローに適するかを説明してください:

レベル2: 単一の会話とワークフローを比較

シナリオA: 明確なロジックを持つ50行の関数のバグを修正する。

シナリオB: 30個のコンポーネントのUIライブラリをMaterial-UI v4からv5にアップグレードする。

判断と理由を記述してください(各シナリオ2〜3文)。

完了基準 · ローカルでチェック