レッスン1: 会話からワークフローへ: オーケストレーションが存在する理由
学習目標:
- 単一の会話とワークフローの根本的な違いを理解する
- ワークフローに適したタスクの特性を認識する
- ワークフローオーケストレーションの核心的価値を把握する
前提: Claude Codeや類似のAIツールを使用したことがある | 次: レッスン2 >>
エージェントが壁にぶつかる
Claude Codeに大規模なコードベースのリファクタリングを依頼します。「この5,000行のモノリスをマイクロサービスに分割して」
Claudeは作業を開始します。ファイルを読み、モジュールの境界を特定し、依存関係を抽出し、そしてファイル47あたりで、コンテキストウィンドウがいっぱいになります。以前の作業を忘れ、最初からやり直し、ループに陥ります。1
あるいは「すべてのオープンなPRをレビューして、今週のリリースノートを書いて」と依頼します。Claudeは一度に1つのPRしか処理できないため、手動で20回実行し、毎回フォーマットルールを再説明することになります。
これが単一の会話の上限です。1つの会話、1つのコンテキストウィンドウ、1つの推論チェーン。複雑なタスクに対して、このパターンは破綻します。2
ワークフローとは何か
ワークフローは、複雑なタスクをステップに分解し、各ステップを新しいエージェントに委譲し、全体を自身で調整する実行可能なスクリプトです。3
主な違い:
例えば、リファクタリングワークフローは次のようになります:
スクリプトがループ、分岐、中間結果を保持し、Claudeのコンテキストは最終的な答えだけを見ます。オーケストレーションは決定論的で、各ステップ内の作業のみがモデル駆動です。3
ワークフローが適合する場合
ワークフローに適したタスクを示す4つの特性:
- 1つの会話が調整できる以上のエージェントが必要。 単一の会話は3〜5個のサブエージェントを管理できます。それを超えると、ワークフローが必要です。
- オーケストレーションを読みやすく再利用可能なスクリプトとして成文化したい。 一度書けば、いつでも再実行できます。
- タスクが明確なフェーズに分割される。 解析、計画、実装、検証。
- 並列実行やクロスチェックが必要。 独立したサブタスク、敵対的検証、トーナメント式比較。
公式ドキュメントは明確に述べています: "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: モノリシックエージェント
段階2: サブエージェントファンアウト(Agentツール)
段階3: エージェントチーム
段階4: ワークフローオーケストレーション
ワークフローの核心的革新は制御フローの反転です: エージェントに「次に何をすべきか」を決めさせる代わりに、スクリプトが「次にどのエージェントを呼び出すか」を決定します。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つのチェックが必要です:
- コードはスタイルガイドに従っているか?
- 明らかなバグはないか?
- テストカバレッジは十分か?
- 関連ドキュメントは更新されたか?
単一の会話では、15回実行し、毎回手動でPRを切り替えます。
ワークフローでは:
このワークフローが得られるもの:
- 15個のPRを並列レビュー、順次より15倍高速。
- 一貫したレビュー基準(すべてのPRが同じプロンプトを使用)。
- 毎週自動実行可能、手動ステップなし。
- スクリプトはGitにコミットされ、チーム全体で共有される。
次: レッスン2 >> — ワークフロー構成要素: ステップ、状態、分岐、ループ