クイックスタート：最初のワークフロー
自分の Git リポジトリで最初のワークフローを最後まで実行します。新しいファイルを追加するだけで、既存のコードは変更しません。
このチュートリアルで行うこと
このチュートリアルで書くワークフローは、順番に実行される 2 つのタスクからなります。タスク 1 は、直近 1 週間の Claude Code または Codex との会話履歴を読み、HTML のレポートを書きます。レポートでは、現在エージェントをどのように開発に使っているか、どの作業が CodeDAG に向いているかを分析し、シナリオごとに、そのまま使えるワークフローファイルを添えます。タスク 2 では、別のエージェントがこのレポートをレビューします。両方のエージェントをインストールしていればもう一方を使い、片方だけであれば別のモデルを使います。タスク 2 は、レビューコメントと、書き直したレポートを残します。2 つのレポートは、どちらも書き上がると自動的にブラウザーで開きます。3 つのファイルはすべて docs/codedag-reports/run-<番号>/ に書き込まれます。初回の実行では run-1 が作られ、もう一度実行すると新しく run-2 が作られるので、前回の結果は上書きされません。
flowchart LR t1["タスク 1<br/>直近1週間のエージェントとの会話を分析<br/>レポートを書く"] --> t2["タスク 2<br/>別のモデルでレビュー<br/>レビューコメントと書き直し版を書く"]このワークフローは既存のコードに手を加えません。共有ワークスペースモード（shared-workspace）を使うためです。タスクは現在の作業ディレクトリでそのまま実行され、CodeDAG はブランチの作成も、マージも、コミットもしません。タスクエージェントがどのファイルを書くかはプロンプトで決まります。この例のプロンプトが認めているのは、ディレクトリを 1 つ新しく作り、その中にレポートファイルを書くことだけです。CodeDAG のデフォルトである分離ブランチモードでは、タスクごとにブランチが作られ、変更がコミットされます。こちらは 2 つ目のワークフローで試します。2 つの実行モードの違いは、実行モードを参照してください。
このワークフローを実行すると、CodeDAG クレジットを 2 クレジット消費します。1 タスクにつき 1 クレジットです。所要時間は、主に読み込む会話履歴の量と使用するモデルによって変わります。タスク 1 のプロンプトでは、読むセッションをサンプリングで 20 件程度に絞るよう指定してあります。
YAML を手で書きたくない場合は、エージェントに書かせることもできます。Claude Code または Codex に CodeDAG Guide プラグインが入っていれば（インストールするかどうかはステップ 1 で尋ねられます）、このセクションで説明した 2 つのタスクを伝えるだけで、同じワークフローを書き、投入と進捗の追跡まで行ってくれます。方法はエージェントにオーケストレーションを任せるを参照してください。一度自分の手で書いておくと、エージェントが書いたワークフローを読んで修正できるようになります。
準備
- CodeDAG とエージェントをインストールしておく。 インストールとログインを済ませ、Claude Code と Codex の少なくとも一方が問題なく使える状態にしておきます。
- コミットのある Git リポジトリを選ぶ。 コミットが 1 つ以上ある Git リポジトリであれば、どれでもかまいません。そのルートディレクトリでターミナルを開いておきます。ワークフローは開始時点のコミットをベースにするため、まだコミットが 1 つもない新しいリポジトリでは開始できません。
- Claude Code がリポジトリ外のファイルを読めるようにしておく。 Claude Code を使っていて、auto モードでリポジトリ外のファイルを読ませたことがない場合にだけ必要です。このチュートリアルのタスクは、リポジトリの外にある会話履歴を読みます。Claude Code は、初めてこのような読み取りをするときに、許可するかどうかを一度尋ねます。この確認がタスクの実行中に初めて表示されると、タスクはそこで止まって応答を待ちます。これを避けたい場合は、あらかじめターミナルで
claude --permission-mode autoを一度実行し、リポジトリ外のファイルを 1 つ読ませてください。確認が表示されたら「Yes, and keep allowing any reads outside the working directories」を選び、終了します。詳しくは Claude Code に作業ディレクトリ外のファイルの読み取りをあらかじめ許可するを参照してください。
プロジェクトを初期化する
リポジトリのルートで次のコマンドを実行します。
cdg initまだログインしていない場合、cdg init はまずブラウザーを開いてログインを求めます。続いて、いくつかの質問が順に表示されます。
Select your repository setup method：4. I don't need concurrent tasks, only sequential executionを選びます。このチュートリアルの 2 つのタスクは順番に実行されるので、プライマリリポジトリだけで足ります。並列実行に必要なレプリカのワークスペースは、2 つ目のワークフローで用意します。このリポジトリにすでに worktree または clone のレプリカがある場合は、それに合わせて 1 または 2 を選んでもかまいません。Which agent would you like to set as the default for this project?：Claude Code と Codex の両方がインストールされている場合にだけ尋ねられます。どちらを選んでもかまいません。デフォルトのエージェントは、agentフィールドのないタスクをどのエージェントが実行するかを決めるだけで、このチュートリアルのタスクにはすべてagentを明記しているからです。Install the CodeDAG plugin for Claude Code?と、Codex についての同じ質問：このコンピューターにインストールされているエージェントの数だけ尋ねられます。どれもSkipではなくUser-levelを選んでください。このプラグインを入れると、Claude Code と Codex がcdgの操作とワークフローファイルの書き方を身につけます。User スコープにインストールすれば、自分のすべてのプロジェクトで使えます。このチュートリアルのタスクは、このプラグインを使って、そのまま使えるワークフローファイルを書きます。
完了すると、次のような出力が表示されます。
✔ Project initialized successfully!
Project Repository: /Users/you/my-app
Project Git workflow stays unchanged.
Associated Replica Repositories:
CodeDAG Sidecar Repository: /Users/you/my-app/.codedag
The project repository and the `.codedag` sidecar repository are separate Git repositories, so manage them independently.
Use Git inside `.codedag` to manage team-shared workflows and shared settings.初期化によって、リポジトリのルートに .codedag/ ディレクトリが作られます。このディレクトリ自体が独立した Git リポジトリで、dags/ にはワークフローファイルを置き、settings.jsonc と local/settings.local.jsonc がプロジェクト設定です。プロジェクトリポジトリは .git/info/exclude でこのディレクトリを無視しているため、git status には表示されず、追跡中のファイルにも変更は一切ありません。.codedag/ を別のリポジトリにしている理由は、サイドカーリポジトリを参照してください。
続いて cdg plugin status を実行し、プラグインがインストールされていることを確認します。使用する各エージェントの下で、Plugin installed と Enabled がどちらも true になっているはずです。未インストールと表示された場合は、cdg plugin install --scope user を実行してインストールします。詳しくは CodeDAG Guide プラグインを管理するを参照してください。
ワークフローファイルを書く
.codedag/dags/ フォルダーに first-run.yaml というファイルを新しく作ります。インストールしているエージェントに合わせて次のいずれかのバージョンを選び、そのまま貼り付けてください。ワークフローファイルを置けるのは、プライマリリポジトリの .codedag/dags/ だけです。ファイル名がそのままワークフローの名前になるので、以降のコマンドではこのワークフローを first-run と指定します。
executionMode: shared-workspace
tasks:
- id: 1
title: 直近1週間のエージェントとの会話を分析
agent: claude
mode: auto
prompt: |
目標：
直近 7 日間の私と Claude Code および Codex との会話履歴を読み、HTML 形式のレポートを書いてブラウザーで開いてください。レポートでは、私が現在エージェントをどのように開発に使っているか、どの作業が CodeDAG のワークフローに向いているか、具体的にどう進めればよいかを説明します。
要件：
- 読むのは直近 7 日間の会話履歴だけです。どちらかのエージェントの履歴が見つからなければ、そのエージェントは飛ばしてください。このタスク自身のセッションも飛ばします。セッションが多い場合はサンプリングして読み、現在のリポジトリのセッションを優先して、合計 20 件程度に抑えてください。
コンテキストと必読資料：
- 書き始める前に、CodeDAG Guide プラグインの codedag-guide スキルを使って、CodeDAG がどんな作業に向いているかと、ワークフローファイルのフィールドや書き方を把握してください。
完了条件：
docs/codedag-reports/ の下に run-<番号> というディレクトリを新しく作ります。番号は、既存の run-* ディレクトリの最大の番号に 1 を足した値とし、既存のものがなければ 1 にします。レポートは、このディレクトリ内の HTML ファイル workflow-review.html として書き、次の 3 部構成にしてください。
1. 利用傾向：私がよく行うタスクの種類、セッションの長さとターン数、繰り返し現れる手順を簡潔に説明します。傾向の説明と統計の数字は第 2 部の裏付けになるものだけにとどめ、そこから導かれる結論、つまり現在のやり方のうちどれをワークフローに置き換えられるかを中心に書きます。
2. ワークフローに向いている 3〜5 つのシナリオ：シナリオごとに、現在のどのやり方を置き換えるのか、タスクをどう分割するか、タスク間の依存関係、何が省けると見込まれるかを書き、そのままコピーして使えるワークフローファイルを添えます。
3. 引き続き対話型セッションで進めるのが適している作業と、その理由。
結論にはそれぞれ、根拠にしたセッションを明記します（日付とプロジェクト名だけでかまいません）。
ワークフローファイルは codedag-guide スキルの説明に従って書き、推奨するファイル名を添えます。最初のシナリオのワークフローファイルはデフォルトで展開し、残りのシナリオのものはデフォルトで折りたたんで、クリックで展開できるようにします。各ファイルにはコピーボタンを付けます。
HTML レポートは単一のファイルとし、スタイルとスクリプトはファイル内に書いて、外部リソースは参照しないでください。書き終えたら、私がすぐに読めるように、システムのデフォルトブラウザーで開いてください。macOS では open、Linux では xdg-open を使います。
このコンピューターに GUI がない場合や、開くのに失敗した場合は、代替策として、同じ内容の Markdown ファイル workflow-review.md も書いてください。
制約：
- 新しく作るのは、上記のディレクトリとその中のレポートファイルだけです。リポジトリにある既存のファイルは、一切変更も削除もしないでください。
- キー、トークン、パスワードなどの機密情報をレポートに書き写さないでください。
- id: 2
title: レポートをレビューして書き直す
dependencies: [1]
agent: codex
mode: auto
prompt: |
目標：
docs/codedag-reports/ にある最新のレポートをレビューし、レビューコメントを書いたうえで、改善した完全版を作成してください。
コンテキストと必読資料：
- 各回の実行結果は docs/codedag-reports/run-<番号>/ に置かれています。番号が最も大きいディレクトリが最新の回で、その中の workflow-review.html がレポートです。
- このレポートは、別のエージェントが、直近 7 日間の私と Claude Code および Codex との会話履歴をもとに書いたものです。結論の後ろには根拠にしたセッションが明記されているので、重要な結論を確かめるときは、それらのセッションをいくつか抜き出して確認してかまいません。
- レポートには、シナリオごとにワークフローファイルが添えられています。そのまま使えるかどうかを確かめる前に、CodeDAG Guide プラグインの codedag-guide スキルを使って、ワークフローファイルのフィールドと書き方を把握してください。
完了条件：
- レビューコメントは、同じディレクトリの workflow-review-comments.md に書きます。事実の誤り、根拠が不十分な結論、抜けている重要なシナリオ、実行しにくい提案、そのままでは使えないワークフローファイルを 1 件ずつ挙げ、それぞれ理由を説明してください。
- 改善した完全版のレポートは、同じディレクトリの HTML ファイル workflow-review-v2.html として書きます。妥当なレビューコメントをすべて反映し、元のレポートの 3 部構成は保ってください。第 1 部は簡潔なままにして、第 2 部の裏付けになる内容だけを残します。第 2 部では、シナリオごとに、そのままコピーして使えるワークフローファイルを添えます。最初の 1 つはデフォルトで展開し、残りはデフォルトで折りたたんで、それぞれにコピーボタンを付けます。レポートは単一のファイルとし、スタイルとスクリプトはファイル内に書いて、外部リソースは参照しないでください。書き終えたら、私がすぐに読めるように、システムのデフォルトブラウザーで開いてください。macOS では open、Linux では xdg-open を使います。
- このコンピューターに GUI がない場合や、開くのに失敗した場合は、代替策として、同じ内容の Markdown ファイル workflow-review-v2.md も書いてください。
制約：
- 新しく作るのは、上記のファイルだけです。元のレポートは変更せず、リポジトリにあるほかのファイルも一切変更・削除しないでください。
- キー、トークン、パスワードなどの機密情報をレポートに書き写さないでください。executionMode: shared-workspace
tasks:
- id: 1
title: 直近1週間のエージェントとの会話を分析
agent: claude
mode: auto
model: sonnet
prompt: |
目標：
直近 7 日間の私と Claude Code および Codex との会話履歴を読み、HTML 形式のレポートを書いてブラウザーで開いてください。レポートでは、私が現在エージェントをどのように開発に使っているか、どの作業が CodeDAG のワークフローに向いているか、具体的にどう進めればよいかを説明します。
要件：
- 読むのは直近 7 日間の会話履歴だけです。どちらかのエージェントの履歴が見つからなければ、そのエージェントは飛ばしてください。このタスク自身のセッションも飛ばします。セッションが多い場合はサンプリングして読み、現在のリポジトリのセッションを優先して、合計 20 件程度に抑えてください。
コンテキストと必読資料：
- 書き始める前に、CodeDAG Guide プラグインの codedag-guide スキルを使って、CodeDAG がどんな作業に向いているかと、ワークフローファイルのフィールドや書き方を把握してください。
完了条件：
docs/codedag-reports/ の下に run-<番号> というディレクトリを新しく作ります。番号は、既存の run-* ディレクトリの最大の番号に 1 を足した値とし、既存のものがなければ 1 にします。レポートは、このディレクトリ内の HTML ファイル workflow-review.html として書き、次の 3 部構成にしてください。
1. 利用傾向：私がよく行うタスクの種類、セッションの長さとターン数、繰り返し現れる手順を簡潔に説明します。傾向の説明と統計の数字は第 2 部の裏付けになるものだけにとどめ、そこから導かれる結論、つまり現在のやり方のうちどれをワークフローに置き換えられるかを中心に書きます。
2. ワークフローに向いている 3〜5 つのシナリオ：シナリオごとに、現在のどのやり方を置き換えるのか、タスクをどう分割するか、タスク間の依存関係、何が省けると見込まれるかを書き、そのままコピーして使えるワークフローファイルを添えます。
3. 引き続き対話型セッションで進めるのが適している作業と、その理由。
結論にはそれぞれ、根拠にしたセッションを明記します（日付とプロジェクト名だけでかまいません）。
ワークフローファイルは codedag-guide スキルの説明に従って書き、推奨するファイル名を添えます。最初のシナリオのワークフローファイルはデフォルトで展開し、残りのシナリオのものはデフォルトで折りたたんで、クリックで展開できるようにします。各ファイルにはコピーボタンを付けます。
HTML レポートは単一のファイルとし、スタイルとスクリプトはファイル内に書いて、外部リソースは参照しないでください。書き終えたら、私がすぐに読めるように、システムのデフォルトブラウザーで開いてください。macOS では open、Linux では xdg-open を使います。
このコンピューターに GUI がない場合や、開くのに失敗した場合は、代替策として、同じ内容の Markdown ファイル workflow-review.md も書いてください。
制約：
- 新しく作るのは、上記のディレクトリとその中のレポートファイルだけです。リポジトリにある既存のファイルは、一切変更も削除もしないでください。
- キー、トークン、パスワードなどの機密情報をレポートに書き写さないでください。
- id: 2
title: レポートをレビューして書き直す
dependencies: [1]
agent: claude
mode: auto
model: opus
prompt: |
目標：
docs/codedag-reports/ にある最新のレポートをレビューし、レビューコメントを書いたうえで、改善した完全版を作成してください。
コンテキストと必読資料：
- 各回の実行結果は docs/codedag-reports/run-<番号>/ に置かれています。番号が最も大きいディレクトリが最新の回で、その中の workflow-review.html がレポートです。
- このレポートは、別のエージェントが、直近 7 日間の私と Claude Code および Codex との会話履歴をもとに書いたものです。結論の後ろには根拠にしたセッションが明記されているので、重要な結論を確かめるときは、それらのセッションをいくつか抜き出して確認してかまいません。
- レポートには、シナリオごとにワークフローファイルが添えられています。そのまま使えるかどうかを確かめる前に、CodeDAG Guide プラグインの codedag-guide スキルを使って、ワークフローファイルのフィールドと書き方を把握してください。
完了条件：
- レビューコメントは、同じディレクトリの workflow-review-comments.md に書きます。事実の誤り、根拠が不十分な結論、抜けている重要なシナリオ、実行しにくい提案、そのままでは使えないワークフローファイルを 1 件ずつ挙げ、それぞれ理由を説明してください。
- 改善した完全版のレポートは、同じディレクトリの HTML ファイル workflow-review-v2.html として書きます。妥当なレビューコメントをすべて反映し、元のレポートの 3 部構成は保ってください。第 1 部は簡潔なままにして、第 2 部の裏付けになる内容だけを残します。第 2 部では、シナリオごとに、そのままコピーして使えるワークフローファイルを添えます。最初の 1 つはデフォルトで展開し、残りはデフォルトで折りたたんで、それぞれにコピーボタンを付けます。レポートは単一のファイルとし、スタイルとスクリプトはファイル内に書いて、外部リソースは参照しないでください。書き終えたら、私がすぐに読めるように、システムのデフォルトブラウザーで開いてください。macOS では open、Linux では xdg-open を使います。
- このコンピューターに GUI がない場合や、開くのに失敗した場合は、代替策として、同じ内容の Markdown ファイル workflow-review-v2.md も書いてください。
制約：
- 新しく作るのは、上記のファイルだけです。元のレポートは変更せず、リポジトリにあるほかのファイルも一切変更・削除しないでください。
- キー、トークン、パスワードなどの機密情報をレポートに書き写さないでください。executionMode: shared-workspace
tasks:
- id: 1
title: 直近1週間のエージェントとの会話を分析
agent: codex
mode: auto
prompt: |
目標：
直近 7 日間の私と Claude Code および Codex との会話履歴を読み、HTML 形式のレポートを書いてブラウザーで開いてください。レポートでは、私が現在エージェントをどのように開発に使っているか、どの作業が CodeDAG のワークフローに向いているか、具体的にどう進めればよいかを説明します。
要件：
- 読むのは直近 7 日間の会話履歴だけです。どちらかのエージェントの履歴が見つからなければ、そのエージェントは飛ばしてください。このタスク自身のセッションも飛ばします。セッションが多い場合はサンプリングして読み、現在のリポジトリのセッションを優先して、合計 20 件程度に抑えてください。
コンテキストと必読資料：
- 書き始める前に、CodeDAG Guide プラグインの codedag-guide スキルを使って、CodeDAG がどんな作業に向いているかと、ワークフローファイルのフィールドや書き方を把握してください。
完了条件：
docs/codedag-reports/ の下に run-<番号> というディレクトリを新しく作ります。番号は、既存の run-* ディレクトリの最大の番号に 1 を足した値とし、既存のものがなければ 1 にします。レポートは、このディレクトリ内の HTML ファイル workflow-review.html として書き、次の 3 部構成にしてください。
1. 利用傾向：私がよく行うタスクの種類、セッションの長さとターン数、繰り返し現れる手順を簡潔に説明します。傾向の説明と統計の数字は第 2 部の裏付けになるものだけにとどめ、そこから導かれる結論、つまり現在のやり方のうちどれをワークフローに置き換えられるかを中心に書きます。
2. ワークフローに向いている 3〜5 つのシナリオ：シナリオごとに、現在のどのやり方を置き換えるのか、タスクをどう分割するか、タスク間の依存関係、何が省けると見込まれるかを書き、そのままコピーして使えるワークフローファイルを添えます。
3. 引き続き対話型セッションで進めるのが適している作業と、その理由。
結論にはそれぞれ、根拠にしたセッションを明記します（日付とプロジェクト名だけでかまいません）。
ワークフローファイルは codedag-guide スキルの説明に従って書き、推奨するファイル名を添えます。最初のシナリオのワークフローファイルはデフォルトで展開し、残りのシナリオのものはデフォルトで折りたたんで、クリックで展開できるようにします。各ファイルにはコピーボタンを付けます。
HTML レポートは単一のファイルとし、スタイルとスクリプトはファイル内に書いて、外部リソースは参照しないでください。書き終えたら、私がすぐに読めるように、システムのデフォルトブラウザーで開いてください。macOS では open、Linux では xdg-open を使います。
このコンピューターに GUI がない場合や、開くのに失敗した場合は、代替策として、同じ内容の Markdown ファイル workflow-review.md も書いてください。
制約：
- 新しく作るのは、上記のディレクトリとその中のレポートファイルだけです。リポジトリにある既存のファイルは、一切変更も削除もしないでください。
- キー、トークン、パスワードなどの機密情報をレポートに書き写さないでください。
- id: 2
title: レポートをレビューして書き直す
dependencies: [1]
agent: codex
mode: auto
model: gpt-6-sol
prompt: |
目標：
docs/codedag-reports/ にある最新のレポートをレビューし、レビューコメントを書いたうえで、改善した完全版を作成してください。
コンテキストと必読資料：
- 各回の実行結果は docs/codedag-reports/run-<番号>/ に置かれています。番号が最も大きいディレクトリが最新の回で、その中の workflow-review.html がレポートです。
- このレポートは、別のエージェントが、直近 7 日間の私と Claude Code および Codex との会話履歴をもとに書いたものです。結論の後ろには根拠にしたセッションが明記されているので、重要な結論を確かめるときは、それらのセッションをいくつか抜き出して確認してかまいません。
- レポートには、シナリオごとにワークフローファイルが添えられています。そのまま使えるかどうかを確かめる前に、CodeDAG Guide プラグインの codedag-guide スキルを使って、ワークフローファイルのフィールドと書き方を把握してください。
完了条件：
- レビューコメントは、同じディレクトリの workflow-review-comments.md に書きます。事実の誤り、根拠が不十分な結論、抜けている重要なシナリオ、実行しにくい提案、そのままでは使えないワークフローファイルを 1 件ずつ挙げ、それぞれ理由を説明してください。
- 改善した完全版のレポートは、同じディレクトリの HTML ファイル workflow-review-v2.html として書きます。妥当なレビューコメントをすべて反映し、元のレポートの 3 部構成は保ってください。第 1 部は簡潔なままにして、第 2 部の裏付けになる内容だけを残します。第 2 部では、シナリオごとに、そのままコピーして使えるワークフローファイルを添えます。最初の 1 つはデフォルトで展開し、残りはデフォルトで折りたたんで、それぞれにコピーボタンを付けます。レポートは単一のファイルとし、スタイルとスクリプトはファイル内に書いて、外部リソースは参照しないでください。書き終えたら、私がすぐに読めるように、システムのデフォルトブラウザーで開いてください。macOS では open、Linux では xdg-open を使います。
- このコンピューターに GUI がない場合や、開くのに失敗した場合は、代替策として、同じ内容の Markdown ファイル workflow-review-v2.md も書いてください。
制約：
- 新しく作るのは、上記のファイルだけです。元のレポートは変更せず、リポジトリにあるほかのファイルも一切変更・削除しないでください。
- キー、トークン、パスワードなどの機密情報をレポートに書き写さないでください。「Codex のみ」のバージョンでは、タスク 1 は Codex のデフォルトモデルを使い、タスク 2 には gpt-6-sol を指定しています。2 つのタスクで異なるモデルを使うことだけが目的です。Codex のモデル一覧は頻繁に更新されるため、この名前が自分のアカウントで使えない場合は、Codex の /model メニューにある別のモデルに置き換えてください。
このファイルで使っているフィールドは 8 つだけです。executionMode はワークフロー全体に対する設定で、それ以外はすべて各タスクの下に書きます。
| フィールド | このワークフローでの役割 |
|---|---|
executionMode | shared-workspace に設定しているため、すべてのタスクが現在の作業ディレクトリで実行され、ブランチの作成もコミットも行われません。省略すると、デフォルトの分離ブランチモードになります。 |
id | タスクの番号。ワークフロー内で一意の正の整数です。コマンドや dependencies では、この番号でタスクを指定します。 |
title | 人が読むための短いタイトル。ステータスボードに表示されます。 |
prompt | タスクエージェントのセッションが最初に受け取るメッセージ。ワークフローから受け取る指示は、これがすべてです。 |
dependencies | このタスクを開始する前に、完了して承認されている必要があるタスク。タスク 2 には [1] と書いています。 |
agent | タスクを実行するエージェント。claude は Claude Code、codex は Codex を指します。 |
mode | タスクエージェントの権限モード。この例では、どちらのエージェントにも auto を指定しています。通常の操作はそのまま実行され、リスクのある操作はエージェントに備わる自動レビューがチェックするため、タスクが実行中に許可待ちで止まることは通常ありません。 |
model | エージェントにそのまま渡されるモデル名。省略すると、エージェント側で設定されているデフォルトモデルが使われます。 |
タスク 2 のプロンプトには、レポートのパスを明記しています。この記述は省けません。2 つのタスクは互いにつながりのない別々のセッションで、タスク 2 からはタスク 1 の会話が見えず、タスク 1 がリポジトリに残したファイルしか読めないからです。すべてのフィールドの詳しい説明は、ワークフローファイルリファレンスを参照してください。
auto を指定すると、操作を 1 つずつ人が許可する代わりに、エージェントに備わる自動レビューが使われます。Claude Code では Claude Code 自身の auto 権限モードにあたり、安全分類器がバックグラウンドで操作をレビューします。Codex では Codex の Approve for me 権限に相当します。Codex はワークスペースにしか書き込めないサンドボックスの中で動作し、サンドボックスの外に出る操作は、まず自動レビューに回されます。安全な操作はそのまま実行され、リスクのある操作はブロックされます。まれに、それでもタスクが止まって応答を待つことがあります。その場合の対処はステップ 4 で説明します。誰も見ていない間もワークフローを最後まで実行させたい場合は、フルアクセスに切り替える必要があります。アクセスレベルごとのトレードオフは、無人実行か有人実行かを決めるを参照してください。
検証して投入する
まず、ワークフローファイルを検証します。
cdg dag validate first-run検証に通ると、次のように出力されます。
✔ Validation passed: .codedag/dags/first-run.yamlエラーが出た場合は、メッセージに従ってファイルを修正し、もう一度検証します。検証に通ったら投入し、このターミナルでそのままログを追います。
cdg dag submit first-run --attach✔ Submitted successfully: .codedag/dags/first-run.yaml
Queue position:
#1 .codedag/dags/first-run.yaml (now running in background)
📊 Following logs... (Ctrl+C to detach logs, Ctrl+\ to kill current workflow)--attach を付けると、投入後もこのターミナルに 2 つのタスクのログが流れ続けます。各行の先頭には、タスク番号と時刻が付きます。Ctrl+C を押しても、ターミナルがログを追うのをやめるだけで、ワークフローはバックグラウンドで実行を続けます。ターミナルを閉じても影響はありません。
実行を監視する
別のターミナルを開いて同じリポジトリに移動すれば、進捗を確認できます。まず cdg status でプロジェクト全体を見ます。first-run は Submitted Workflows のグループにあり、ステータスは [in-progress] [working] です。Planning Workflows のグループにある untitled_dag.yaml は、初期化のときに生成されたテンプレートです。
ワークフロー内の各タスクの状況を見るには、次のコマンドを実行します。
cdg dag status first-run --watchタスク 1 の実行中、ステータスボードは次のようになります。
[TZ: +08:00] 2026-10-08 10:02:15
Workflow: .codedag/dags/first-run.yaml
Phase: 📤 submitted
Queue Position: 1
Status: 🟢 in-progress
Substatus: working
Submitted Tasks (2):
🟢 [in-progress] [working] Task 1: 直近1週間のエージェントとの会話を分析
🔘 [pending] [blocked] Task 2: レポートをレビューして書き直す
Progress: 0/2 tasks completed (0%)タスクは 1 行ずつ表示され、ステータス、サブステータスの順に並びます。[in-progress] [working] は、タスクエージェントが作業中であることを表します。[pending] [blocked] は上流待ちを表し、タスク 2 は、タスク 1 が完了して承認されるまで開始されません。タスク 1 が終わると、ステータスはいったん done になり、すぐに自動承認されて、ステータスボード下部の Reviewed Tasks のグループに移り、[auto-accepted] と表示されます。続いて、タスク 2 が [in-progress] [working] になります。--watch を付けると、ワークフローが終了するまで表示が更新され続けます。ステータスボードに表示されるほかの状態の意味は、状態の意味を参照してください。
ステップ 3 で --attach を付けなかった場合や、すでに Ctrl+C でログから離れた場合は、cdg dag logs first-run -f でもう一度ログを追えます。
タスクエージェント自身の画面を直接見たいときは、実際のターミナルで cdg task view 1 -w first-run を実行して、そのセッションに入ります。見終わったら Ctrl+C で抜けてください。タスクはそのまま実行を続けます。どんなときにこの方法で介入するのがよいかは、監視と修正の方法を選ぶを参照してください。タスクが止まって応答を待っているときも、同じコマンドでセッションに入って応答します。止まっている間も、ステータスボードの表示は [in-progress] [working] のままです。見分け方は、止まったままかどうかを見分けるにはを参照してください。
結果を読む
2 つのタスクがどちらも完了すると、ワークフローは自動承認されます。ステップ 3 のターミナルがまだログを追っていれば、そこでログの表示も終わり、最後の行は次のようになります。
✔ Workflow auto-accepted: .codedag/dags/first-run.yaml2 つのレポートは、それぞれ書き上がった時点で、デフォルトブラウザーで開かれています。先に開くのがタスク 1 の初版、次がタスク 2 の書き直し版です。ファイルはすべて docs/codedag-reports/run-1/ にあります。以前にこのチュートリアルを実行したことがある場合は、番号が最も大きいディレクトリを見てください。
workflow-review.html：タスク 1 が書いたレポート。workflow-review-comments.md：タスク 2 のレビューコメント。workflow-review-v2.html：タスク 2 が書き直したレポート。
このコンピューターに GUI がないなどの理由でブラウザーが開かなかった場合、タスクはプロンプトに書かれた代替策に従い、同じディレクトリに同名の .md ファイルも書きます。こちらは、ターミナルやエディターでそのまま読めます。
まずレビューコメントを読み、それから書き直し版を読むことをおすすめします。レビューコメントには、初版のどこで根拠が足りなかったか、どこで判断を誤っていたかが指摘されています。これを踏まえて v2 を読むと、それぞれの変更の理由が分かりやすくなります。
レポートの第 2 部では、シナリオごとにワークフローファイルが添えられています。最初の 1 つは展開された状態で、残りはクリックすると展開され、どれもワンクリックでコピーできます。試してみたいものがあれば、.codedag/dags/ に YAML ファイルとして保存し、まず cdg dag validate で検証して、通ってから投入してください。これらのファイルはエージェントが生成したものなので、投入する前に、プロンプトと権限モードに一度目を通しておきます。
タスクが書いたファイルは、どれもコミットされていません。共有ワークスペースモードでは、タスクの成果物は作業ディレクトリにそのまま残り、もともとあった未コミットの変更にも手は加えられません。コミットするかどうかは自分で決めます。レポートには、ほかのプロジェクトでの会話の内容が要約されている可能性があるため、コミットや共有の前に全体を読んでおいてください。
何が起きたのか
- どのタスクも、新しいセッションで実行される。 タスク 2 のエージェントは、起動した時点ではタスク 1 が何をしたかをまったく知りません。最初に受け取るメッセージがプロンプトです。そのためプロンプトは、事情を何も知らないセッションでも単独で作業をやり遂げられるように書く必要があります。このような設計にしている理由は、タスクとセッションを参照してください。
- タスク間の情報は、リポジトリ内のファイルで受け渡す。 タスク 1 は結論を
workflow-review.htmlに書き、タスク 2 のプロンプトは、そのファイルを名指しして読ませます。そしてdependencies: [1]があるので、読む時点でファイルは必ず書き上がっています。プロンプトで取り決めたファイルパスが、タスク間のインターフェースになります。 - 完了したタスクはデフォルトで自動承認され、ワークフローは先へ進む。 タスク 1 は完了するとすぐに承認され、続いてタスク 2 が開始され、最後にワークフロー全体も自動承認されました。この間、操作は何も必要ありません。あるタスクの後でいったん止めて結果を確認したい場合は、そのタスクの自動承認をオフにします。詳しくは自動承認を参照してください。
次のステップ
- 2 つ目のワークフロー：コードを変更させる：デフォルトの分離ブランチモードで 2 つの TODO を並列に片付け、タスクブランチ、自動マージ、統合ブランチを実際に確認します。
- エージェントにオーケストレーションを任せる：CodeDAG Guide プラグインを入れた Claude Code または Codex に目標を伝え、ワークフローの作成、投入、追跡を任せます。
- CodeDAG の仕組み：ワークフロー、キュー、状態、プロジェクトがどのように組み合わさっているか。
最終更新