CodeDAG を使う場面
CodeDAG が今のやり方とどう違い、どのような仕事に向いているのか、そして現時点でできないことを説明します。
Claude Code と Codex は、それ自体で複数の作業を同時に進められ、サブエージェントを起動することもできます。Claude Code には Dynamic Workflow もあります。これらの方法にはそれぞれ得意な範囲があり、CodeDAG はその代わりになるものではありません。CodeDAG が対象にしているのは、そのうちの 1 種類の仕事です。互いに関連する複数のタスクが 1 つのワークフローを成していて、依存関係に従って最後まで実行する必要があり、途中で人が見ている必要はなく、結果をレビューでき、元に戻すこともできる、という仕事です。数行で済む小さな変更や、進めながら方向を決めていく探索には、Claude Code や Codex を直接使うほうが向いています。
すでに使っているかもしれない方法
| 方法 | 向いている場面 | 限界 | CodeDAG の場合 |
|---|---|---|---|
| すべてのタスクを 1 つの大きなプロンプトに書き、1 つのエージェントに任せる | 数ステップで終わる、前後のつながりが強い作業。準備は何もいらず、エージェントが常に経緯のすべてを把握しています。 | ステップが増えるとセッションが長くなり、前に読んだファイルや、もう古くなった途中の結論がコンテキストに溜まって、後の判断ほど当てにならなくなります。作業も 1 つずつ順番にしか進められません。 | 各タスクは新しいセッションから始まり、コンテキストにはそのタスクに必要な内容しか入りません。互いに依存しないタスクは同時に実行できます。 |
| プロンプトを次々とキューに入れておく | 順序がはっきりした一連の小さなステップ。エージェントが作業している間に続きの指示を入れておけるので、張り付いて 1 つずつ指示する必要がありません。 | すべての指示は同じセッションの中で順に実行されます。並列には実行できず、一部のステップを別のエージェントやモデルに任せることもできません。 | 順序は依存関係で決まり、依存関係のないタスクは同時に実行されます。エージェントとモデルは、タスクごとに指定できます。 |
| メインエージェントに subagents や agent teams をオーケストレーションさせる | 規模が大きくなく、進めながら判断する必要がある作業。メインエージェントが進み具合に応じて、いつでも分担を調整できます。 | 次に何をするかは、メインエージェントがターンごとに決めます。タスクと依存関係が増えると、計画とそれぞれの進捗を同時に覚えておかなければならず、依存関係を見落としたり、先へ進めるタイミングを見誤ったりしやすくなります。同じ内容をそのままもう一度実行することもできません。また、agent teams のメンバー同士は worktree で分離されていないため、担当するファイルを分けてコンフリクトを避ける必要があります。 | タスクと依存関係はあらかじめワークフローファイルに書いておき、CodeDAG が定義どおりに進めます。規模が大きくなっても定義から外れることはなく、同じワークフローを繰り返し実行できます。デフォルトでは、各タスクがそれぞれのブランチで作業します。 |
Ralph loop、または claude -p や codex exec を使ったスクリプトのループ | 同じ作業を、基準を満たすまで繰り返す場合や、決まったいくつかのステップをつなげる場合。やり方をすべて自分で決められ、既存のスクリプトやツールチェーンにも組み込みやすい方法です。 | 一時停止、止まった箇所からの再開、失敗時のリトライ、並列実行時の分離は、すべて自分でスクリプトに実装しなければなりません。非対話形式で動くエージェントは、途中で口を挟んで軌道修正するのも困難です。 | ワークフローもその中の各タスクも、一時停止、強制停止、復旧ができ、復旧すると元のセッションで続きから作業します。各タスクは対話型セッションなので、実行中に入って直接やり取りできます。 |
| 並列ワークスペースを備えたエージェント向けカンバンツールを使う | 互いに関係のない複数の作業を同時に進める場合。作業はそれぞれ専用の worktree やセッションで進み、自分で割り振ったうえで、進捗と変更を 1 つずつ確認します。 | これらのツールは、独立した個々のタスクや issue を単位にしています。タスク同士に依存関係がある場合、次のタスクをいつ始めるか、前のタスクの結果をどう渡すか、最後にどう 1 つにまとめるかは、すべて自分で段取りしなければなりません。 | 関連する複数のタスクから成るワークフロー全体を単位にします。デフォルトでは、上流が承認されると、CodeDAG がその結果を下流のブランチにマージしてから下流を起動し、最後にすべての結果を 1 つの統合ブランチにマージします。 |
| Claude Code Dynamic Workflow | 明確なテストや検証方法があることを前提に、Claude がスクリプトを書いて進める大量の移行やリファクタリング。 | 動かせるのは Claude のサブエージェントだけです。実行の詳細は見えにくく、実行中は、人による途中の介入や軌道修正を受け付けません。 | CodeDAG に最も近い方法です。詳しい違いは次の節を参照してください。 |
Claude Code Dynamic Workflow との比較
Dynamic Workflow は Claude Code に組み込まれたオーケストレーションの方法で、CodeDAG に最も近いものです。どちらも、「次に何をするか」をモデルにターンごとに判断させるのではなく、あらかじめ書いておいた定義に従って実行します。
両者の違いは、どこまでを受け持つかにあります。Dynamic Workflow は、1 つの Claude Code セッションの中の機能です。そのセッションのサブエージェントを動かし、開始後はユーザーの入力を受け付けず、途中で見られる実行の詳細もごくわずかです。CodeDAG が受け持つのは、ひとまとまりの開発作業の、キューでの待機から実行、レビュー、マージまでの全過程です。タスクはそれぞれ Claude Code または Codex に任せられ、どのタスクも中に入ってやり取りできるセッションです。変更はタスクごとのブランチに入り、指定した箇所で止まってレビューを待ちます。一時停止したあとは、実行し直すことなく、元のセッションで続きから作業できます。
| CodeDAG | Claude Code Dynamic Workflow | |
|---|---|---|
| エージェントとモデル | 各タスクを Claude Code または Codex に任せられ（今後、対応するエージェントを増やす予定です）、モデルもタスクごとに指定できます。たとえば、あるモデルに実装させ、別のモデルにレビューさせることができます。 | 動かせるのは Claude Code 自身のサブエージェントだけで、モデルは Claude シリーズに限られます。 |
| 実行中の介入 | 各タスクはネイティブセッションです。実行中はいつでも中に入り、エージェントに新しい指示を直接出せます。 | 実行中はユーザーの入力を受け付けないことが、公式に明記されています。 |
| 手動レビュー | 任意のタスク、またはワークフロー全体を、完了後に止めてレビューを待たせることができます。結果に納得できなければ、エージェントに続けて修正させることも、最初からやり直させることも、自分で修正することもでき、納得してから通します。 | 実行中に手動レビューの段階はありません。 |
| ブランチ、マージ、ロールバック | 各タスクはそれぞれのブランチでコードを変更し、結果は自動でマージされます。メインブランチは変更されません。不要な変更は、その分だけ破棄できます。 | サブエージェントは、デフォルトでは同じコードを直接変更します。追加の設定で分離した変更であっても、自動ではマージされません。 |
| 進捗とステータス | ステータスは進捗だけでなく、対処が必要かどうかも示します。問題が起きたタスクは止まって原因を表示し、対処すれば続きから進みます。 | ステータスが示すのは実行の進捗だけで、問題が起きたエージェントはそのまま失敗として終了します。 |
| 実行トレース | 各タスクの開始から終了までの完全なトレースを確認できます。実行中でも終了後でも確認できます。 | 各エージェントについて確認できるのは、直近 3 回のツール呼び出しと最終結果だけです。 |
| 一時停止と再開 | ワークフローも個々のタスクも、一時停止、強制停止、復旧ができます。復旧すると、途中まで進んでいたセッションで続きから作業できます。 | 一時停止できるのはワークフロー単位だけで、特定のタスクを指定して一時停止することはできません。再開時には、途中まで進んでいたセッションを実行し直す必要があります。 |
| 定義の方法 | タスクと依存関係を宣言する YAML ファイル。どんなタスクがあり、どれがどれに依存しているかがひと目でわかります。 | Claude が書く JavaScript のスクリプト。あまり直感的ではなく、JavaScript に慣れていないユーザーには扱いづらいものです。 |
まとめると、両者の最も根本的な違いは、制御を自分の手元に置いておきたいかどうかです。Dynamic Workflow は、一度きりの外注に似ています。仕事を Claude Code に渡し、終わるのを待って、結果を受け取ります。途中で手を出すことはできず、作業するのも Claude だけです。CodeDAG は、自分でチームを率いてプロジェクトを進めるのに似ています。途中でいつでも状況を確認し、作業を引き継ぎ、結果をチェックできます。各ステップを Claude Code と Codex のどちらに任せるか、どのモデルを使うかも自分で決められます。CodeDAG はこれらのエージェントから独立したツールであり、特定のベンダーに縛られないからです。エージェントに仕事を最後まで任せたいが、過程の制御とエージェントを選ぶ自由は手放したくない、という場合には CodeDAG を使ってください。
CodeDAG を使うからといって、Dynamic Workflow を諦める必要はありません。タスクエージェントは通常の Claude Code または Codex のセッションなので、自分のタスクの中でこれまでどおりサブエージェントを起動したり、Dynamic Workflow を開始したりできます。CodeDAG は、それらがすべて終わってからタスクの完了を判定します。多数の同種の対象に同じ処理をする仕事で、順序に依存せず、ブランチの分離も必要ないものには、この組み合わせが使えます。すべてのルートを点検する、数百個のファイルを移行する、といった仕事です。対象ごとに展開する部分を 1 つのタスクとして書き、タスク内のメインエージェントにサブエージェントを動かさせれば、このタスクで消費する CodeDAG クレジットは 1 クレジットだけです。その前の計画や、後のテストとコードレビューは引き続き CodeDAG のタスクなので、手動レビューも、一時停止と再開も、これまでどおり使えます。
種類の異なる製品
n8n、Dify、Zapier のようなワークフロープラットフォームも、ノードと接続線でフローを組み立てます。ただし、1 つのノードは通常、1 回のモデル呼び出しか 1 回の API リクエストです。フローはサーバーやクラウドで動き、扱うのはデータやメッセージであって、ローカルのリポジトリでコードを変更するわけではありません。Airflow のようなデータパイプラインのオーケストレーションツールも DAG でタスクを組み立てますが、成果物はデータであり、コードではありません。CodeDAG では、どのノードも 1 つの完結したコーディングエージェントのセッションです。手元のマシンの Git リポジトリで作業し、成果物はブランチ上のコード変更です。
CodeDAG を使うべきかどうかを判断する
ある仕事を CodeDAG に任せるかどうかは、3 つの問いに順に答えることで判断できます。その仕事を任せられるか、オーケストレーションする価値があるか、CodeDAG の対応範囲に収まるか、の 3 つです。コードの変更を並列に進められるかどうかや、手動レビューを設けるかどうかは、前提条件ではありません。順番に進むだけで、最初から最後まで自動承認されるワークフローも、CodeDAG のごく普通の使い方です。
- これから任せる仕事の目標と成果物を、はっきり説明できますか。 各ステップをどう実装するかまで、あらかじめ決めておく必要はありません。それはタスクエージェント自身が判断することです。ただし、各タスクがどこまでできれば完了なのか、結果をどこに残すのかは、説明できなければなりません。それができて初めて、エージェントはターンごとの確認を待たずに作業を進められます。目標やトレードオフについてまだ何度も議論が必要なら、まず対話型セッションで詰めてから、どの部分にオーケストレーションする価値があるかを決めます。
- オーケストレーションによって、今回の仕事の実際の負担は軽くなりますか。 よくある負担は、「ステップ同士に依存関係があり、後のステップが前のステップの結果を待たなければならない」「同時に進められるタスクがまとまってある」「別のエージェントに独立してレビューさせたい」「実行に長い時間がかかり、その間ずっと張り付いていたくはない」「進捗の確認、一時停止、再開をいつでもできるようにしたい、あるいは要所で結果を確認したい」といったものです。このうち 1 つでも当てはまり、しかも省ける手間が、ワークフローの準備とタスクごとのクレジット消費に見合うなら、オーケストレーションする価値があります。ワークフローを自分で書く必要もありません。CodeDAG Guide プラグインを入れたエージェントが、代わりに書いて投入できます。エージェントにオーケストレーションを任せるを参照してください。1 回きりの質問や、すぐに済む小さな変更は、Claude Code や Codex に直接任せるほうが手間がかかりません。
- 目標の達成に欠かせないやり方は、CodeDAG の現在の対応範囲に収まっていますか。 CodeDAG は 1 つのローカル Git プロジェクトの中で動作し、タスク同士の関係は投入前に決めておく必要があります。実行中にタスクを動的に追加・削除する、複数のリポジトリを自動でつなぐ、結果を自動でプッシュする、といったことが目標に欠かせない場合は、CodeDAG が担える部分だけを切り出して任せ、残りは自分で対処するか、別のツールを使います。このうち、実行途中でのタスクの追加・削除についての回避策は、CodeDAG の現在の制限を参照してください。
3 つの問いすべてに「はい」と答えられるなら、その仕事は CodeDAG に向いています。続けて任せられるひとまとまりの仕事があり、オーケストレーションで得られる効果が手間に見合い、目標の妨げになる製品上の制約もない、ということだからです。
CodeDAG の現在の制限
以下は CodeDAG の現時点での制限で、いずれも今後のバージョンで対応する計画に入っています。対応されるまでは、表の回避策を使えます。
| 制限 | 説明 | 回避策 |
|---|---|---|
| 条件分岐とループがない | タスクと依存関係は投入時に固定されます。CodeDAG が実行結果に応じて実行するタスクを決めることはなく、前のタスクに戻って実行し直すこともありません。 | 使う可能性のあるタスクをすべてあらかじめ並べておき、判断の条件をプロンプトに書きます。繰り返し試す必要がある作業は、1 つのタスクの中で完結させます。よくある質問を参照してください。 |
| 実行中にタスクを追加・削除できない | ワークフローは、投入時の内容のまま最後まで実行されます。 | 前後 2 つのワークフローに分けます。1 つ目が結論をファイルに書き出し、それをもとに、自分またはオーケストレーションエージェントが 2 つ目を書いて投入します。 |
| GUI がない | ステータスとログは、どちらもターミナルで確認します。 | cdg status でプロジェクト全体のキューを、cdg dag status でワークフロー内の各タスクを確認できます。--watch を付けると、表示が更新され続けます。今の状況を確認する：3 つの階層の status を参照してください。 |
次のステップ
- インストールとログイン：
cdgをインストールし、CodeDAG アカウントにログインします。 - クイックスタート：最初のワークフロー：新しいファイルを追加するだけで既存のコードは変更しないワークフローを、自分のリポジトリで最後まで実行します。
- 設計理念：CodeDAG がなぜこのように設計されているのか、それぞれの選択にどんな代償があるのかを説明します。
最終更新