2 つ目のワークフロー：コードを変更させる

worktree を用意する

開発に使っていて、プロジェクトを動かしたことのある worktree がこのリポジトリにすでにある場合は、そのままステップ 2 に進んでください。

まだない場合は、ここで 1 つ作ります。2 つのタスクを同時に実行するには、タスクごとにワークスペースが 1 つ必要です。プライマリリポジトリが 1 つ分になるので、git worktree をもう 1 つ追加すれば足ります。理由はワークスペースを参照してください。

プライマリリポジトリのルートで次のコマンドを実行します。my-app は、自分のプロジェクトのディレクトリ名に置き換えてください。

git worktree add ../my-app-wt-1 -b wt-1

このコマンドは、プライマリリポジトリの隣に my-app-wt-1 ディレクトリを作り、新しいブランチ wt-1 をチェックアウトします。このブランチは単なるプレースホルダーで、タスクの開始時に、CodeDAG がこのディレクトリをタスクブランチに切り替えます。

新しいディレクトリにあるのは、バージョン管理されているファイルだけです。node_modules や Python の仮想環境のように、テストを実行する前に依存関係のインストールが必要なプロジェクトでは、新しいディレクトリでもいつもどおりインストールしてください。.env のようにコミットしていないローカルの設定ファイルも、コピーしておく必要があります。タスク 2 とタスク 3 はそれぞれのワークスペースでテストを実行するため、これらが欠けていると、worktree で実行されるほうのタスクはテストを動かせません。

worktree を CodeDAG に登録する

クイックスタートの Select your repository setup method で 1 または 2 を選んでいた場合は、このステップも省略できます。

4 を選んでいた場合は、プライマリリポジトリのルートに戻り、もう一度初期化を実行します。

cdg init

いくつかの質問が順に表示されます。最初の質問への答えが、クイックスタートのときとは異なります。

1. Select your repository setup method：1. I have set up git worktrees for this project を選びます。CodeDAG がこのリポジトリの worktree を自動的に見つけるので、パスを入力する必要はありません。続いて、レプリカとして登録する worktree にチェックを付ける画面になります。先ほど作った my-app-wt-1 にはデフォルトでチェックが付いているので、Enter で確定します。Claude Code や Codex が自身のセッション用に作った worktree には、デフォルトではチェックが付いていません。
2. File ".codedag/.gitignore" already exists. How would you like to handle this file?：3. Keep All を選びます。.codedag/ にある設定ファイルとテンプレートファイルはクイックスタートのときに生成されたもので、Keep All を選ぶと、すべてそのまま残ります。ローカル設定のファイルも残るため、今回はデフォルトのエージェントを尋ねられません。
3. Update maxConcurrency to 2?：このプロジェクトのワークスペースは 2 つになりましたが、残した設定では同時実行数の上限が 1 のままです。そのため、2 に変更するかどうかを尋ねられます。デフォルトは Yes なので、そのまま Enter を押します。

クイックスタートのときに CodeDAG Guide プラグインをインストールしなかった場合は、インストールするかどうかをもう一度尋ねられます。必要に応じて答えてください。完了すると、出力の冒頭は次のようになります。

✔ Project initialized successfully!

  Project Repository: /Users/you/my-app
  Project Git workflow stays unchanged.
  Associated Replica Repositories:
    - /Users/you/my-app-wt-1

Associated Replica Repositories の下に worktree のパスが表示されていれば、このプロジェクトのワークスペースとして登録されています。

同時実行数の上限についての質問に Yes と答えると、プロジェクト設定の上限がワークスペースの数に揃います。それでも、次のステップのワークフローファイルには maxConcurrency: 2 を明記します。こうしておけば、プロジェクト設定の値にかかわらず、このワークフローでは 2 つのタスクを同時に実行できます。worktree の代わりに clone を使う方法、レプリカをさらに用意する方法、ローカル設定の同時実行数を直接変更する方法は、並列実行とワークスペースを参照してください。

ワークフローファイルを書く

.codedag/dags/two-small-changes.yaml を新しく作り、使用するエージェントに合わせてどちらかのバージョンを選んで、そのまま貼り付けます。2 つのバージョンの違いは、各タスクの agent と mode だけです。

maxConcurrency: 2

tasks:
  - id: 1
    title: TODOを2つ選ぶ
    agent: claude
    mode: bypassPermissions
    prompt: |
      目標：
      このプロジェクトの中から、最も早く片付けられる TODO を 2 つ見つけ、それぞれについて簡潔な実装計画を書いてください。計画は、後続の 2 つのセッションに渡し、1 つずつ実装させます。

      詳細：
      - TODO は、私の役割と担当範囲に合わせて絞り込んでください。コード中の TODO や FIXME コメント、ドキュメント内の TODO リスト、スキップされているテストのほか、GitHub Issues、Linear、Jira など、アクセスできる issue トラッカーから選んでもかまいません。
      - 適切な TODO が見つからない場合は、このプロジェクトの製品としての位置づけと現状、および私の職務を踏まえて、代わりに小さな変更を 2 つ提案してください。

      完了条件：
      計画は docs/plans/two-small-changes.md に書きます（ファイルがすでにある場合は、そのまま上書きします）。「1 つ目」と「2 つ目」の 2 つの節に分け、各節に次の内容を明記してください。
      - 目標：何を実現するのか。1〜2 文で書きます。
      - 対象ファイル：変更または追加するファイルのパス。テストファイルも含めます。
      - 完了条件：何をもって完了とするか。先に書く最小限のテストと、そのテストを実行するコマンドも含めます。

      制約：
      - この計画以外のファイルは、新しく作ることも変更することもしないでください。

  - id: 2
    title: 1つ目を実装
    dependencies: [1]
    agent: claude
    mode: bypassPermissions
    prompt: |
      目標：
      docs/plans/two-small-changes.md の「1 つ目」に書かれている TODO を実装してください。

      コンテキストと必読資料：
      - docs/plans/two-small-changes.md は、前のタスクが書いた計画です。「1 つ目」の節に、目標、対象ファイル、完了条件が書かれています。

      完了条件：
      - 「1 つ目」に書かれている完了条件を満たすこと。まず最小限のテストを書き、そのテストが通るまで実装します。

      制約：
      - 変更するのは、「1 つ目」に挙げられているファイルだけにしてください。計画ファイルは変更せず、「2 つ目」の内容も実装しないでください。

      注意事項：
      - 別のセッションが、別のブランチで「2 つ目」を同時に実装しています。その変更は、あなたからは見えません。両方の結果は、後で CodeDAG がマージします。

  - id: 3
    title: 2つ目を実装
    dependencies: [1]
    agent: claude
    mode: bypassPermissions
    prompt: |
      目標：
      docs/plans/two-small-changes.md の「2 つ目」に書かれている TODO を実装してください。

      コンテキストと必読資料：
      - docs/plans/two-small-changes.md は、前のタスクが書いた計画です。「2 つ目」の節に、目標、対象ファイル、完了条件が書かれています。

      完了条件：
      - 「2 つ目」に書かれている完了条件を満たすこと。まず最小限のテストを書き、そのテストが通るまで実装します。

      制約：
      - 変更するのは、「2 つ目」に挙げられているファイルだけにしてください。計画ファイルは変更せず、「1 つ目」の内容も実装しないでください。

      注意事項：
      - 別のセッションが、別のブランチで「1 つ目」を同時に実装しています。その変更は、あなたからは見えません。両方の結果は、後で CodeDAG がマージします。

maxConcurrency: 2

tasks:
  - id: 1
    title: TODOを2つ選ぶ
    agent: codex
    mode: yolo
    prompt: |
      目標：
      このプロジェクトの中から、最も早く片付けられる TODO を 2 つ見つけ、それぞれについて簡潔な実装計画を書いてください。計画は、後続の 2 つのセッションに渡し、1 つずつ実装させます。

      詳細：
      - TODO は、私の役割と担当範囲に合わせて絞り込んでください。コード中の TODO や FIXME コメント、ドキュメント内の TODO リスト、スキップされているテストのほか、GitHub Issues、Linear、Jira など、アクセスできる issue トラッカーから選んでもかまいません。
      - 適切な TODO が見つからない場合は、このプロジェクトの製品としての位置づけと現状、および私の職務を踏まえて、代わりに小さな変更を 2 つ提案してください。

      完了条件：
      計画は docs/plans/two-small-changes.md に書きます（ファイルがすでにある場合は、そのまま上書きします）。「1 つ目」と「2 つ目」の 2 つの節に分け、各節に次の内容を明記してください。
      - 目標：何を実現するのか。1〜2 文で書きます。
      - 対象ファイル：変更または追加するファイルのパス。テストファイルも含めます。
      - 完了条件：何をもって完了とするか。先に書く最小限のテストと、そのテストを実行するコマンドも含めます。

      制約：
      - この計画以外のファイルは、新しく作ることも変更することもしないでください。

  - id: 2
    title: 1つ目を実装
    dependencies: [1]
    agent: codex
    mode: yolo
    prompt: |
      目標：
      docs/plans/two-small-changes.md の「1 つ目」に書かれている TODO を実装してください。

      コンテキストと必読資料：
      - docs/plans/two-small-changes.md は、前のタスクが書いた計画です。「1 つ目」の節に、目標、対象ファイル、完了条件が書かれています。

      完了条件：
      - 「1 つ目」に書かれている完了条件を満たすこと。まず最小限のテストを書き、そのテストが通るまで実装します。

      制約：
      - 変更するのは、「1 つ目」に挙げられているファイルだけにしてください。計画ファイルは変更せず、「2 つ目」の内容も実装しないでください。

      注意事項：
      - 別のセッションが、別のブランチで「2 つ目」を同時に実装しています。その変更は、あなたからは見えません。両方の結果は、後で CodeDAG がマージします。

  - id: 3
    title: 2つ目を実装
    dependencies: [1]
    agent: codex
    mode: yolo
    prompt: |
      目標：
      docs/plans/two-small-changes.md の「2 つ目」に書かれている TODO を実装してください。

      コンテキストと必読資料：
      - docs/plans/two-small-changes.md は、前のタスクが書いた計画です。「2 つ目」の節に、目標、対象ファイル、完了条件が書かれています。

      完了条件：
      - 「2 つ目」に書かれている完了条件を満たすこと。まず最小限のテストを書き、そのテストが通るまで実装します。

      制約：
      - 変更するのは、「2 つ目」に挙げられているファイルだけにしてください。計画ファイルは変更せず、「1 つ目」の内容も実装しないでください。

      注意事項：
      - 別のセッションが、別のブランチで「1 つ目」を同時に実装しています。その変更は、あなたからは見えません。両方の結果は、後で CodeDAG がマージします。

このファイルには executionMode を書いていないので、デフォルトの分離ブランチモードが使われます。次の点に注目してください。

• maxConcurrency: 2 は、最大 2 つのタスクの同時実行を許可します。実際に同時に実行できるタスクの数は、利用できるワークスペースの数にも制限されます。ここではプライマリリポジトリと worktree 1 つで、ちょうど 2 つです。詳しくは maxConcurrency を参照してください。
• タスク 2 とタスク 3 には、どちらも dependencies: [1] を書いている。 どちらもタスク 1 が完了して承認されるまで開始されませんが、互いには依存していません。そのため、タスク 1 が承認されるとすぐに、2 つが同時に開始されます。
• タスク 2 とタスク 3 は、docs/plans/two-small-changes.md を直接読む。 このファイルは、タスク 1 が自分のブランチで書いたものです。タスク 1 が承認されると、CodeDAG はまずその結果をタスク 2 とタスク 3 のタスクブランチにマージし、それから 2 つのタスクを開始します。そのため、どちらのタスクも最初から、それぞれのワークスペースでこのファイルを読めます。依存関係が情報を受け渡す経路にもなる理由は、依存関係を参照してください。
• 並列に実行する 2 つのタスクは、変更範囲が重なってもかまわない。 タスク 2 とタスク 3 はそれぞれのタスクブランチで変更するため、実行中に影響し合うことはありません。両方の結果をマージするときに同じ箇所のコードがぶつかった場合、CodeDAG はまずコンフリクトの解決をエージェントに任せます。詳しくは合流ノードでのマージとコンフリクトを参照してください。このため、タスク 1 は TODO を選ぶときに、同じ箇所を変更することになる 2 つを避ける必要がありません。タスク 2 とタスク 3 の制約も、それぞれの作業を自分の担当分に限定しているだけです。

検証して投入する

まず、ワークフローファイルを検証します。

cdg dag validate two-small-changes

✔ Validation passed: .codedag/dags/two-small-changes.yaml

検証に通ったら投入し、このターミナルでそのままログを追います。

cdg dag submit two-small-changes --attach

✔ Submitted successfully: .codedag/dags/two-small-changes.yaml

Queue position:
  #1  .codedag/dags/two-small-changes.yaml (now running in background)

📊 Following logs... (Ctrl+C to detach logs, Ctrl+\ to kill current workflow)

まずタスク 1 がプライマリリポジトリで実行されます。タスク 1 が終わって自動承認されると、ログにタスク 2 とタスク 3 の開始行が続けて表示されます。

[Task   1] [2026-09-30 10:39:32] END: TODOを2つ選ぶ
[Task   2] [2026-09-30 10:39:36] START: 1つ目を実装
[Task   3] [2026-09-30 10:39:36] START: 2つ目を実装

これ以降は、2 つのタスクのログが入り混じって流れます。クイックスタートのときと同じく、Ctrl+C を押しても、ターミナルがログを追うのをやめるだけで、ワークフローはバックグラウンドで実行を続けます。

並列に動く 2 つのタスクを監視する

別のターミナルを開いてプライマリリポジトリに移動し、このワークフローのステータスボードを表示します。

cdg dag status two-small-changes --watch

タスク 2 とタスク 3 の実行中、ステータスボードは次のようになります。

[TZ: -04:00] 2026-09-30 10:39:39

Workflow: .codedag/dags/two-small-changes.yaml
  Phase: 📤 submitted
  Queue Position: 1
  Status: 🟢 in-progress
  Substatus: working

Submitted Tasks (2):
  🟢 [in-progress] [working]  Task 2: 1つ目を実装
  🟢 [in-progress] [working]  Task 3: 2つ目を実装

Reviewed Tasks (1):
  🤖☑️ [auto-accepted]  Task 1: TODOを2つ選ぶ

Progress: 1/3 tasks completed (33%), 1 reviewed

タスク 1 はすでに自動承認され、Reviewed Tasks に移っています。タスク 2 とタスク 3 はどちらも [in-progress] [working] で、それぞれワークスペースを 1 つずつ使っています。それぞれがどこで実行されているかを確かめるには、各ワークスペースで現在チェックアウトされているブランチを見ます。

git worktree list

/Users/you/my-app       9a2b3bc [cdg/two-small-changes/t2-1つ目を実装]
/Users/you/my-app-wt-1  9a2b3bc [cdg/two-small-changes/t3-2つ目を実装]

プライマリリポジトリはタスク 2 のブランチに、worktree はタスク 3 のブランチに切り替わっています。タスクブランチの名前は、cdg/<ワークフロー名>/t<タスク ID>-<タイトル> の形式です。2 行のコミットは同じで、どちらも CodeDAG がタスク 1 を承認したときに作成したコミットです。つまり、2 つのタスクはどちらも、タスク 1 の結果から作業を始めています。

結果を確認してメインブランチにマージする

2 つのタスクがどちらも完了すると、CodeDAG は両方を自動承認し、2 本のタスクブランチを統合ブランチにマージします。続いて、ワークフロー全体も自動承認されます。ログを追っていたターミナルの表示もそこで終わり、最後の行は次のようになります。

✔ Workflow auto-accepted: .codedag/dags/two-small-changes.yaml

2 つのタスクが同じ箇所のコードを変更していた場合は、統合ブランチへのマージでコンフリクトが発生します。CodeDAG は、まずエージェントに解決を任せます。3 回試みても解決しなかった場合は、上の行は表示されず、ワークフローは on-hold で止まって対処を待ちます。対処方法は、マージコンフリクトを参照してください。

ワークフローが終了すると、プライマリリポジトリは統合ブランチをチェックアウトした状態になっており、git branch --show-current を実行すると cdg/two-small-changes/integration と表示されます。まず、統合ブランチにあって main にはないコミットを確認します。

git log --oneline main..HEAD

ba8ab12 Merge task 3 into cdg/two-small-changes/integration
b99fcd0 1つ目を実装
d6077f1 2つ目を実装
9a2b3bc TODOを2つ選ぶ

CodeDAG は、タスクを承認するときに、そのタスクが残した変更をタスクブランチにコミットします。コミットメッセージは、タスクのタイトルそのものです。一番上のマージコミットは、CodeDAG がタスク 3 のブランチを統合ブランチにマージしたときのものです。次に、どのファイルが変更されたかを確認します。

git diff main...HEAD --stat

マージする前に、変更をファイルごとに一通り読み、統合ブランチでプロジェクトのテストを実行してください。CodeDAG は、タスクエージェントが作業を終えたことをもって、タスクが完了したと判断します。自動承認もテストの結果は見ません。変更が正しいかどうかは、自分で確認する必要があります。タスク 1 が書いた docs/plans/two-small-changes.md も、この変更に含まれています。メインブランチに入れたくない場合は、先に削除してコミットしておきます。

確認が済んだら、結果をメインブランチにマージできます。チームで開発している場合は、通常プルリクエストを経由します。統合ブランチは main から作られており、今回の変更がすべて入っています。ここから自分用のブランチを新しく作ってリモートにプッシュし、いつもどおりプルリクエストを作成してください。ブランチ名はチームの規約に合わせて付けます。ここでは feat/two-small-changes とします。

git checkout -b feat/two-small-changes cdg/two-small-changes/integration
git push -u origin feat/two-small-changes
git checkout main

プッシュは自分で行います。CodeDAG がリモートリポジトリにプッシュしたり、リモートリポジトリからプルしたりすることは一切ありません。最後のコマンドはプライマリリポジトリを main に戻すもので、次のワークフローがどこから始まるかも、これで決まります。ワークフローは、実行開始時にプライマリリポジトリでチェックアウトされているコミットをベースにします。プライマリリポジトリが統合ブランチやこの新しいブランチのままだと、次のワークフローは今回の結果の続きから作業することになります。詳しくはタスクブランチ、統合ブランチ、ベースを参照してください。

個人プロジェクトなどでコードレビューが不要な場合は、ローカルで直接マージすることもできます。git checkout main でメインブランチに戻り、続けて git merge cdg/two-small-changes/integration を実行します。この間に main に新しいコミットがなければ、fast-forward マージになります。ほかのマージ方法は、メインブランチにマージするを参照してください。