タスクとワークフローをレビューする

タスクやワークフローがレビューゲートの前で止まると、実行は結論が出るまで待ち続け、それに依存する下流も一緒に待ちます。選べるのは、承認するかしないかだけではありません。結果がおおむね使えるなら、自分で何か所か直すことも、元のセッションに修正を続けさせることもできます。方向が間違っていれば、新しいセッションに最初からやり直させることもできます。本当に要らない結果であっても、変更はデフォルトでスナップショットに保存されるので、あとから取り出せます。

このページの例はすべて、feature という名前のワークフローを使います。タスク 1 は、新しい関数 sub のインターフェース契約を書きます。タスク 2 とタスク 3 はどちらもタスク 1 に依存し、一方がこの関数を実装し、もう一方がそのテストを書きます。

レビューが必要になるとき

デフォルトでは、タスクもワークフローも完了すると自動承認され、実行が止まることはありません。ゲートの前で止まってレビューを待つのは、次の 3 つの場合だけです。

• タスクレベルのゲートが閉じている。 タスクのレビュー設定が none の場合、タスクは完了後に done で止まります。この設定は、タスクの autoAccepted、ワークフローの taskAutoAccepted、プロジェクト設定、投入時の --task-auto-accepted none のいずれかで指定されたものです。
• タスクが変更を何も残さなかった。 分離ブランチモードでは、エージェントが実行するタスクがファイルを 1 つも変更せずに完了すると、ゲートが開いていても、止まって確認を待ちます。
• ワークフローレベルのゲートが閉じている。 ワークフローに dagAutoAccepted: none を設定している場合、すべてのタスクに結論が出て、結果が統合ブランチにマージされたあとで、ワークフロー全体が止まってレビューを待ちます。方法はワークフロー全体をレビューするを参照してください。

どのタスクがレビューを待っているかは、cdg dag status でわかります。次に示すのは、cdg dag status feature の出力です。タスク 1 には autoAccepted: none を設定してあり、すでに完了して [done] [done] で止まっています。タスク 1 に依存するタスク 2 とタスク 3 は [pending] [blocked] で止まり、タスク 1 の結論を待っています。変更を残さなかったために止まったタスクでは、その行の末尾に — zero output, awaiting manual review も表示されます。

[TZ: -04:00] 2026-09-30 11:07:25

Workflow: .codedag/dags/feature.yaml
  Phase: 📤 submitted
  Queue Position: 1
  Status: 🔘 pending
  Substatus: blocked

Submitted Tasks (3):
  🔵 [done]        [done]  Task 1: インターフェース契約を書く
  🔘 [pending]     [blocked]  Task 2: sub関数を実装
  🔘 [pending]     [blocked]  Task 3: subのテストを書く

Progress: 1/3 tasks completed (33%)

投入時に --attach を付けていた場合は、ログを追っているターミナルがここで止まり、その場にレビューメニューが表示されます。

レビューの前に結果を確認する

レビューの前に、タスクが残した変更と、タスク自身による作業の説明を確認します。変更はタスクのワークスペースに、説明はタスクのログの末尾にあります。それでも疑問が残る場合は、タスクのセッションに入って質問できます。以下の方法は、デフォルトの分離ブランチモードを対象にしています。共有ワークスペースモードでの確認方法は、共有ワークスペースモードでは、レビューはどう変わりますかを参照してください。

タスクがゲートの前で止まっている間、そのワークスペースはタスクブランチをチェックアウトしたままです。どこを見ればよいかは、cdg task status 1 -w feature の出力でわかります。Workspace: はタスクが実行されたディレクトリ、Branch: はそのタスクブランチ、Base Commit: はタスクのクリーンベースラインです。クリーンベースラインとは、上流の結果がすでにマージされていて、タスクがまだ何も手を付けていない時点のコミットのことです。

タスクが残した未コミットの変更は、タスクを承認したときに初めて、CodeDAG がタスクブランチにコミットします。そのため、タスクエージェントが自分でコミットしていなければ、このワークスペースで git status と git diff を実行して見えるものが、このタスクの変更のすべてです。タスクエージェントが自分でコミットしていた場合は、Base Commit と比較すれば変更全体を一度に確認でき、上流タスクの結果が混ざることもありません。

git -C <Workspace> diff <Base Commit>

何をしたのか、なぜそうしたのかを知りたいときは、タスクのログの末尾を見ます。タスクエージェントは通常、作業を終える前に自分の作業を要約します。

cdg task logs 1 -w feature -n 50

それでも疑問が残る場合は、cdg task view 1 -w feature でこのタスクのセッションに入り、直接質問できます。セッションへの入り方と抜け方は、セッションに入る、修正する、抜けるを参照してください。

判断に応じてアクションを選ぶ

レビューアクションは 2 種類に分かれます。accept（承認）、cancel（キャンセル）、defer（見送り）は最終的な結論を出すもので、タスクは reviewed になり、そこで終わります。revise（自分で修正）、request-changes（修正依頼）、rework（やり直し）は結論を出さないもので、タスクは修正を続け、修正が終わると再びゲートの前に戻ります。結果をどう判断したかに応じて、次のように選びます。

コマンドは cdg task review <アクション> <タスク ID> -w <ワークフロー> の形式で書きます。review は省略でき、たとえば cdg task accept 1 -w feature と書けます。

そのまま承認する：accept

accept は結果を承認します。タスクは reviewed になり、そのタスクに依存する下流は開始できるようになって、この結果をもとに作業します。

cdg task review accept 1 -w feature

承認すると、CodeDAG はタスクのワークスペースにある未コミットの変更を、タスクブランチにコミットします。コミットメッセージは、デフォルトではタスクのタイトルです。-m でレビューメモを書いた場合は、それがコミットメッセージにも使われます。承認は最終的な結論で、あとから変更することはできません。理由はレビューの結論は変更できないを参照してください。承認したあとで結果の問題に気づいた場合の対処方法は、タスクにレビューの結論が出たあとで問題に気づいたを参照してください。

自分で修正する

タスクがゲートの前で止まっているときは、そのワークスペースで直接修正し、修正が済んだら accept で承認します。自分の修正は、タスクエージェントの変更と一緒にタスクブランチにコミットされます。修正している間は、このワークスペースでタスクブランチをチェックアウトしたままにしてください。CodeDAG は、タスクを承認するときにこの点を確認します。

このとき、先に revise を実行する必要はありません。タスクはすでに done で止まっているので、実行しても何も変わりません。revise を使うのは、エージェントの変更をいったんスナップショットに保存するか、そのまま破棄して、自分で最初から書きたい場合だけです。その場合は、--code snapshot または --code discard を付けます。それぞれの値の意味は、--code を参照してください。

cdg task review revise 1 -w feature --code snapshot

今の結果をもとに修正を続けさせる：request-changes

結果がおおむね使えるものの、まだ足りない点がある場合は、request-changes で修正依頼の内容を元のセッションに渡し、今の結果をもとに修正を続けさせます。修正が終わると、タスクは再びゲートの前に戻ります。

cdg task review request-changes 1 -w feature -m "既存の関数シグネチャと戻り値の説明はそのまま残してください。a、b が数値でない場合の sub の動作を追記し、呼び出し例を 2 つ示してください。"

-m の内容は、そのままタスクエージェントに渡されます。書き方はプロンプトと同じで、今の結果のうち何を残すのか、どこをどう直すのか、どこまで直せば完了なのかを明確にします。-m を書かない場合、CodeDAG は組み込みの依頼文を送ります。エージェントに元のタスクを読み直させ、まだ満たしていない点を自分で見つけて修正を続けさせるものです。結果が不十分だとはわかっていても、具体的な問題を挙げられないときに使えます。

修正を依頼すると、タスクは working に戻ります。修正を始める前に、CodeDAG はデフォルトで、現在の変更をタスクブランチにコミットします。そのため、今回の修正で何が変わったかを、あとから git diff で切り分けて確認できます。先にコミットしたくない場合は、--code none を付けます。

修正が終わると、タスクは再び done になり、元のレビュー設定に従ってもう一度レビューされます。ゲートが閉じている場合、タスクは再び止まってレビューを待つので、納得できるまで続けて修正を依頼できます。ゲートが開いていて、変更を残さなかったという理由だけで止まっていたタスクは、今回は変更を残しているので、自動承認されます。

やり取りを重ねながら修正させたい場合は、タスクのセッションに入って直接伝えることもできます。2 つの方法の選び方は、監視と修正の方法を選ぶを参照してください。

最初からやり直させる：rework

rework は、現在の結果をスナップショットブランチに保存し、タスクブランチをタスク開始前のクリーンベースラインに巻き戻したうえで、新しいセッションを起動してこのタスクをやり直させます。フィードバックも、あわせて新しいセッションに渡されます。

cdg task review rework 2 -w feature -m "前回は、ついでに既存の関数まで変更していました。今回は sub の追加だけにして、引数はインターフェース契約どおりに処理し、ほかの関数は変更しないでください。"

クリーンベースラインには、上流タスクからマージされた結果が残っています。巻き戻されるのは、このタスク自身の変更だけです。詳しくは結果に納得できないときの備えを参照してください。新しいセッションが受け取るのは、元のプロンプトと、このタスクにこれまで出したすべてのフィードバックです。やり直しが始まったあとは、cdg task view で入るセッションも、この新しいセッションになります。

前回の結果はスナップショットブランチに残るので、比較に使ったり、役に立つ部分を取り出したりできます。スナップショットから一部の変更を取り出すを参照してください。記録として残す必要がないとわかっている場合は、--code discard を付けて、そのまま破棄します。

request-changes と違い、rework は前回の考え方や会話の影響を受けません。方向が間違っていて、元の結果に手を入れるよりも最初からやり直したほうがよい場合に向いています。やり直しで CodeDAG クレジットが追加で消費されることはありません。要所で手直しし、全体の再実行を減らすを参照してください。rework は、分離ブランチモードでしか使えません。

このタスクを取りやめる：cancel

cancel はタスクを終わらせ、その変更を下流に渡しません。キャンセルするときには、そのタスクに依存する下流をどうするかも決める必要があります。

# タスク 1 をキャンセルし、タスク 1 に依存するタスク 2、3 もまとめてキャンセルする
cdg task review cancel 1 -w feature --downstream cascade

タスクに変更がある場合、CodeDAG はデフォルトで、まず変更をスナップショットブランチに保存し、それからタスクブランチをクリーンベースラインに巻き戻します。スナップショットブランチの名前は、cdg/<ワークフロー名>/snapshots/t<タスク ID>-<タイトル>-<日時> の形式です。そのため、キャンセルしたあとは、リポジトリにこのようなブランチが 1 本増えます。あとで考えが変わっても、そこから変更を取り出せます。スナップショットから一部の変更を取り出すを参照してください。必要ないとわかっている場合は、--code discard を付けます。変更はそのまま破棄され、スナップショットブランチは作られません。

下流の扱いは、--downstream で指定します。

• proceed（続行）：下流は、このタスクが存在しなかったかのように、通常どおり実行されます。下流が受け取るのは、キャンセルされたタスクの上流の結果で、キャンセルされたタスク自身の変更は含まれません。
• hold（保留）：このタスクに直接依存する下流が on-hold で止まり、判断を待ちます。やはり実行する場合は、cdg task recover --below 1 -w feature で保留を解除します。要らない場合は、同じようにキャンセルするか見送ります。下流が保留になったを参照してください。
• cascade（カスケード）：このタスクに直接または間接的に依存する下流タスクが、すべてまとめてキャンセルされ、実行されなくなります。

--downstream を書かなかった場合、このタスクに依存する下流があれば、コマンドはターミナルで選択を求めます。スクリプトの中や、エージェントに実行させる場合のように、対話型ターミナルがない場面では、コマンドは何も変更せずにエラーになります。そのため、こうした場面ではこのオプションを明記してください。

いったん後回しにする：defer

defer は、このステップを今回は行わず、あとで対処することを表します。コードの扱いは cancel と同じで、変更はデフォルトでスナップショットブランチに保存され、下流には渡されません。違うのは、--downstream を書かない場合のデフォルトが cascade で、このタスクに依存する下流がすべてまとめて見送られる点です。このタスクだけを見送り、下流を通常どおり実行させたい場合は、--downstream proceed を明記します。

このデフォルト値を除けば、見送りとキャンセルの効果は、今回の実行の中では同じです。違うのは記録される結論で、deferred はあとで行うことを、cancelled は要らないことを表します。見送った部分をあとで進めるときは、新しいワークフローに書きます。一部のタスクだけをあとから実行するを参照してください。

タスクがゲートの前で止まっていない場合

レビューアクションを使えるのは、完了してゲートの前で止まっているタスクだけではありません。次のようなタスクも、そのままレビューできます。

• 強制停止または一時停止されたタスク： 先に復旧する必要はありません。すでにある結果をそのまま承認することも、タスクを終わらせることも、request-changes で依頼を渡して作業を続けさせることもできます。revise を実行すると、タスクは done に戻り、ユーザーが修正を済ませて結論を出すのを待ちます。
• まだ実行中のタスク： レビューコマンドに -k を付けると、先に強制停止してからレビューします。-p を付けると、現在のステップが終わるのを待ってからレビューします。-k と -p の説明を参照してください。方向を調整したいだけであれば、タスクのセッションに入って直接伝えることもできます。監視と修正の方法を選ぶを参照してください。
• 開始前に保留になったタスク： ワークスペースがクリーンでない、固定のブランチ名がすでに使われているなどの理由で、開始前の準備の段階で止まったタスクには、レビューできる結果がまだありません。それでも、cancel または defer でそのまま終わらせることはできます。先にワークスペースを片付ける必要はなく、CodeDAG がそのワークスペースの変更に手を付けることもありません。accept、revise、request-changes、rework は、こうしたタスクでは拒否されます。先に原因に対処して、タスクを復旧する必要があります。タスクまたはワークフローが on-hold で止まっているを参照してください。

複数のタスクをまとめてレビューする

コマンドには、タスク ID を複数並べて指定できます。タスクセレクターを使って、依存関係をもとにタスクをまとめて選ぶこともできます。選ばれたタスクには、同じアクションと同じオプションが適用されます。次の 2 つのコマンドは、どちらもタスク 2 とタスク 3 を選びます。

cdg task accept 2 3 -w feature
# --below 1 はタスク 1 のすべての下流を選ぶ。タスク 1 自身は含まない
cdg task accept --below 1 -w feature

レビューコマンドでは、--only を除き、各セレクターに指定できるタスク ID は 1 つだけです。選ばれたタスクの中にすでに結論が出ているものがある場合、コマンドはそれらをスキップし、残りのタスクの処理を続けるかどうかを先に尋ねます。セレクターで選ばれたタスクの中にまだ実行を開始していないものがある場合、accept はさらに、それらを実行せずに承認済みとして記録するかどうかを尋ねます。デフォルトでは承認しません。ID を 1 つずつ指定したタスクについては、この質問はありません。対話型ターミナルがなく、質問に答えられない場合は、どちらの質問でもコマンドがエラーになります。そのとおりに処理してよいと確認できているなら、-y を付けてください。セレクターの書き方の詳細は、タスクセレクターを参照してください。

ワークフロー全体をレビューする：dag review

ワークフローレベルのレビューでは、結果全体に結論を出します。accept、cancel、defer のいずれかを実行すると、ワークフローは reviewed になってキューを離れ、そこで初めて、後ろに並んでいるワークフローが始まります。タスクレベルのレビューとの関係は、レビューゲートを参照してください。

dagAutoAccepted: none を設定したワークフローは、すべてのタスクに結論が出て、結果が統合ブランチにマージされたあと、ゲートの前で止まります。このとき、cdg status では [done] [done] と表示され、cdg dag status では、すべてのタスクが Reviewed Tasks に並んでいます。統合ブランチにはマージ済みの結果がすでにあるので、結論を出す前にそこで確認します。cdg dag status の出力には、Integration Workspace:（統合ブランチがチェックアウトされているディレクトリ）、Integration Branch:、そしてワークフローのベースを示す Base Commit: があります。これらをもとに、変更全体を比較します。方法は統合ブランチの結果を確認するを参照してください。

3 つのコマンドはどれも review を省略でき、たとえば cdg dag accept feature と書けます。ここでの --downstream は、キューでこのワークフローの後ろに並んでいるすべてのワークフローに適用されます。proceed では、後ろのワークフローが通常どおり開始されます。hold では on-hold で止まり、あとから cdg dag recover <ワークフロー> で保留を解除します。cascade では、後ろのワークフローにも同じ結論が付き、実行されなくなります。

共有ワークスペースモードには統合ブランチがありません。ワークフローレベルのレビューがどう違うかは、共有ワークスペースモードでは、レビューはどう変わりますかを参照してください。

dag review は、ワークフローレベルのゲートまで待たなくても使え、いつでも実行を終わらせられます。すでに結論が出ているタスクは、その結論のままです。実行はされたものの、まだ結論が出ていないタスクには、ワークフローと同じ結論が付きます。たとえば cdg dag review accept は、こうしたタスクを承認します。まだ開始していないタスクは実行されなくなり、レビュー結果も付きません。実行中のタスクが残っている場合は、-k を付けて先に強制停止するか、-p を付けて現在のステップが終わるのを待ちます。-k と -p の説明を参照してください。

よくある質問

結論を出したタスクをさらに修正したい場合は、どうすればよいですか

いったん出した結論は、その実行の中では変更できません。あとから手直しできるのはコードの結果であって、レビューの結論ではありません。今回の実行が終了してから、Git でそのタスクの変更を処理し、やり直す部分を新しいワークフローに書きます。方法はタスクにレビューの結論が出たあとで問題に気づいたを参照してください。

修正を依頼したあと、タスクが on-hold で止まった

request-changes または rework の依頼をタスクエージェントに渡せなかった場合、タスクは on-hold で止まり、cdg task status 1 -w feature の Reason: の行に continuation-dispatch-failed と表示されます。cdg task recover 1 -w feature を実行すると、CodeDAG が同じ依頼をもう一度送るので、依頼し直す必要はありません。ほかの理由の場合の対処方法は、エージェントセッションの問題を参照してください。

共有ワークスペースモードでは、レビューはどう変わりますか

共有ワークスペースモードにはタスクブランチがなく、すべてのタスクが同じワークスペース（デフォルトではプライマリリポジトリ）に直接ファイルを書きます。そのため、レビューは実行をどう続けるかを決めるだけで、ファイルには手を付けません。

• タスクレベルでは、accept、cancel、defer、revise、request-changes を使えますが、rework は使えません。--code は、タスクレベルでもワークフローレベルでも付けられません。
• 変更を残さなかったタスクは、止まって確認を待つことなく、通常どおり自動承認されます。タスクの実行中にワークスペースが変化しなかった場合は、cdg dag status のタスクの行の末尾に — zero output と表示され、タスクのログにも警告が 1 件書かれます。実行中にほかのタスクやユーザーがこのワークスペースを変更していると、この表示は出ません。成果物を残さなかったタスクを確実に止めたい場合は、分離ブランチモードを使うか、taskAutoAccepted: none を設定して、タスクを 1 つずつ手動でレビューします。
• タスクをキャンセルしても見送っても、そのタスクが書いたファイルは取り消されず、下流からもそのまま見えます。取り消す必要がある場合は、ワークスペースの変更を自分で Git を使って処理します。
• レビューの前にワークスペースで git status を実行して見えるのは、すべてのタスクの変更で、タスクごとには区別できません。プロンプトで取り決めた出力ファイルと照らし合わせて、1 つずつ確認できます。
• 統合ブランチがないため、ワークフローレベルのレビューも、同じように実行の流れについての結論を出すだけです。ファイルはワークスペースに残ったままなので、確認したうえで、自分でコミットするか取り消します。

関連ページ

• レビューゲートと自動承認：レビューゲートがどこにあるか、自動承認をどう設定するか、2 種類のレビューアクションがどう違うか。
• 仕上げ、マージ、クリーンアップ：ワークフローのレビューが終了したあとに、統合ブランチを確認し、メインブランチにマージし、もう一度実行する方法。
• レビュー：レビューコマンドのすべてのオプション、デフォルト値、使える組み合わせ。