CodeDAG について

概要

CodeDAG が何をするツールで、どのように動くのかを数分で把握し、手元の仕事に合うかどうかを判断します。

プライベートベータはまもなく開始します。CodeDAG はまだインストールできません。ウェイトリストに登録しておくと、招待を順次メールでお送りします。
GitHubで編集

CodeDAG とは

CodeDAG では、ひとまとまりの開発タスクをワークフローファイルに書いてキューに入れると、順番に実行されます。各タスクは新しい Claude Code または Codex のセッションが担当し、デフォルトではタスクごとのブランチで作業します。レビューを通った結果は、最後にそのワークフロー専用の統合ブランチにマージされます。メインブランチにいつマージするかは、自分で決めます。

Claude Code や Codex を直接使う場合、作業は 1 ターンずつ進みます。指示を出し、終わるのを待ち、結果を確認して、次の指示を出すという繰り返しです。セッションを増やせば複数の作業を同時に進められますが、ターミナルを行き来しながら、それぞれがどこまで進んだかを自分で把握しておかなければなりません。席を外せば、どのセッションも次の指示を待ったまま止まってしまいます。

CodeDAG では、「次に何をするか」をあらかじめワークフローに書いておきます。どのタスクを先に実行し、どのタスクがほかのタスクの完了を待ち、どのタスクを同時に進められるかを決めておくということです。投入したあとは、CodeDAG がその段取りに従ってタスクを起動し、上流の結果を下流に渡していくため、その場にいて 1 つずつ指示を出す必要はありません。進捗を確認する、実行を一時停止する、タスクのセッションに入ってエージェントと直接やり取りする、といったことはいつでもできますが、作業の流れそのものを自分で進める必要はなくなります。

CodeDAG 自体はコマンドラインツールで、コマンド名は cdg です。手元のコンピューターにある Git リポジトリの中で動作し、インストールとログインが済んでいる Claude Code または Codex を呼び出します。そのため、エージェント自体の利用量は、これまでどおり自分のアカウントに計上されます。CodeDAG を使うには、CodeDAG アカウントへのログインも必要です。ワークフローの順番が来て実行が始まるときに、タスク数に応じて CodeDAG クレジットが消費されます。1 タスクにつき 1 クレジットです。新しいアカウントには、登録時に無料クレジットが付与されます。詳しくはクレジット、サブスクリプション、課金を参照してください。

1 分でわかる CodeDAG

ワークフローを書いて投入すると、CodeDAG が依存関係に従ってタスクを起動します。各タスクはそれぞれのブランチで実行され、レビューを通った結果が下流に渡されて、最後にすべてが統合ブランチにマージされます。メインブランチにマージするかどうかは、自分で決めます。

%%{init: {"flowchart": {"padding": 10, "nodeSpacing": 30, "rankSpacing": 28}}}%%flowchart LR  s1["ワークフローを<br/>書く"] --> s2["投入する"]  s2 --> s3  subgraph engine["あとは CodeDAG が進める"]    s3["タスクを実行する<br/>新しいセッション、<br/>個別のブランチ"] --> s4["レビューする<br/>デフォルトでは<br/>自動承認"]    s4 --> s5["統合ブランチに<br/>マージする"]  end  s5 -.-> s6["メインブランチへの<br/>マージは自分で行う"]
  1. ワークフローを書く。 目標をいくつかのタスクに分け、タスクごとにエージェントへの指示を書いて、どのタスクの完了を待つ必要があるかを指定します。
  2. 投入する。 ワークフローはこのプロジェクトのキューに入り、順番が来るとバックグラウンドで実行が始まります。ターミナルを閉じても影響はありません。同じプロジェクトに複数のワークフローを投入した場合は、投入した順に 1 つずつ実行されます。
  3. タスクを実行する。 依存関係が満たされたタスクは、それぞれ新しい Claude Code または Codex のセッションを起動し、タスクごとのブランチで作業します。このブランチには、レビューを通った上流の結果があらかじめマージされています。タスク同士は会話を共有せず、リポジトリ内のファイルを介して情報を受け渡します。CodeDAG 用に追加の worktree または clone を用意しておけば、互いに依存しないタスクを同時に実行できます。
  4. レビューする。 タスクが終わっても、結果が承認されるまでは、そのタスクに依存するタスクには渡されません。デフォルトでは自動承認されるため、ワークフローは止まりません。指定したタスクを完了後に止めておくこともできます。その場合は、結果を確認してから、通すか、修正を依頼するか、取りやめるかを決めます。
  5. 統合ブランチにマージする。 すべてのタスクがレビューを通ると、CodeDAG はその結果をこのワークフローの統合ブランチにマージします。ワークフロー全体も 1 回レビューを受けますが、こちらもデフォルトでは自動承認されます。そのあとメインブランチにマージするかどうか、直接マージするかプルリクエストを作成するかは、自分で決めて自分で操作します。

CodeDAG がメインブランチにコミットすることはなく、リモートリポジトリへのプッシュも、リモートリポジトリからのプルも行いません。ただしデフォルトでは、実行中にリポジトリを各タスクブランチへ切り替えます。終了後のリポジトリは統合ブランチをチェックアウトした状態になり、元のブランチには戻りません。

向いている仕事、向いていない仕事

CodeDAG が向いているのは、手順が多くて時間がかかり、ターミナルの前にずっと張り付いていたくはない開発タスクです。主に次のようなものです。

  • 最初に段取りをまとめて決めておける、手順が多く時間のかかる作業。 たとえば、まず計画を書き、その計画に沿ってテストを書き、最後に実装してテストが通るまで修正する、といった作業です。ワークフローを書いてしまえば、席を離れて、戻ってから結果を確認できます。
  • 同時に進めたい複数の変更。 それぞれの変更は、独立したブランチとコードのコピーで並列に実行され、完了すると自動的に 1 つにマージされます。複数のセッションの間を行き来して調整する必要はありません。
  • 別のモデルにチェックさせたい品質管理のプロセス。 たとえば、Claude Code に実装させて Codex にレビューさせる、2 つのモデルにそれぞれ案を書かせてから 1 つにまとめる、といった進め方です。同じワークフローの中でも、タスクごとに異なるエージェントとモデルを指定できます。

次のような仕事は、CodeDAG には向いていません。

  • 数行で済む小さな修正。 Claude Code や Codex で直接直すほうが早く済みます。
  • 進めながら方向を決めていく探索。 まず対話型セッションで方針を固めてから、続けて進められる部分をワークフローにします。
  • 一歩ごとに人が結果を見なければ、次を決められない仕事。 結果の見通しが立たず、最初にすべてを計画しておくことができないうえに、次の一手が重要で、エージェントの判断にそのまま任せるわけにはいかない仕事です。たとえば、プロトタイプをいくつか作り、実際の出来を見てから製品の方向を決める場合がこれに当たります。この判断を誤ると、後から直すのに大きなコストがかかります。こうした仕事は、Claude Code や Codex で一歩ずつ進めるほうが向いています。

CodeDAG と今のやり方を項目ごとに比べたい場合は、CodeDAG を使う場面を参照してください。Claude Code Dynamic Workflow との違いや、現時点でできないことも取り上げています。

2 つの使い方

普段の使い方は 2 通りあります。1 つは、CodeDAG Guide プラグインを入れた Claude Code または Codex に目標をそのまま伝え、ワークフローの作成、投入、進捗の追跡を任せる方法です。もう 1 つは、ワークフローファイルを自分で書く方法です。どちらの方法でもできあがるのは同じ種類のワークフローで、実行のされ方に違いはなく、2 つを組み合わせて使えます。

つまり、ワークフローの書き方を覚えなくても CodeDAG は使い始められます。CodeDAG Guide プラグインはエージェントに cdg の使い方を教えるもので、プロジェクトを初期化するときにあわせてインストールできます。インストール後は、やりたいことを説明するだけです。エージェントが目標をタスクに分けてワークフローを書き、投入し、実行中は代わりに進捗を確認して、終わったら結果がどこにあるかを知らせます。一方、自分で書く方法は、仕組みを学ぶときや細かく調整したいときに向いています。ワークフローファイルは通常 YAML で書き、タスクごとに ID、タイトル、エージェントへの指示、依存するタスクを記述するため、細部まで自分で決められます。

2 つの方法は無理なく組み合わせられます。エージェントにワークフローを起草させ、ファイルを開いていくつかのタスクを調整してから投入させてもよいですし、自分で書いて投入したあと、実行の見守りをエージェントに任せてもかまいません。

主にエージェントに任せるつもりでも、まずはクイックスタートに沿って、小さなワークフローを自分の手で 1 つ書いてみることをおすすめします。ワークフローファイルを一度通して見ておけば、エージェントが書いたものをずっと速く読めるようになり、おかしな箇所にも気づきやすくなります。

次のステップ

エージェントにこのサイトを参照させる場合は、/llms.txt のページ一覧から始められます。各ページの URL の末尾に .md を付けると、本文を Markdown で取得できます。フィールドやコマンドの正確な書き方は、ワークフローファイルリファレンスとコマンド一覧を参照してください。


最終更新