介入と制御

ワークフローは、投入したあとバックグラウンドで自動的に進みますが、いつでも介入できます。タスクエージェントが何をしているかを見たいとき、追加の指示を出したいとき、許可リクエストに応答したいときは、cdg task view でそのセッションに入ります。このセッションは、普段ターミナルで開いている Claude Code や Codex と同じ種類のセッションです。実行を止めたいときは、pause か kill を使います。pause はタスクエージェントが手元の作業を終えるのを待ってから止め、kill はすぐに強制停止します。強制停止したタスクは、あとから recover を使って、元のセッションで続きから再開できます。

以下のコマンドでは、タスクが属するワークフローを -w <ワークフロー> で指定します。省略した場合はキューの先頭のワークフローが対象になり、通常はそれが実行中のワークフローです。例では、ワークフロー名を feature としています。一時停止、一時停止の解除、強制停止、復旧は、複数のタスクにまとめて適用することもできます。コマンドの後ろにタスク ID を複数並べるか、タスクセレクターを使って、依存関係をもとにタスクのまとまりを指定します。書き方は範囲の指定と一括制御を参照してください。

監視と修正の方法を選ぶ

進み具合を知りたいだけなら、ログを読めば十分です。実行中のタスクについて、ネイティブセッションの様子を見たいときや方向を修正したいときは、そのセッションに入ります。タスクがすでに完了してレビューを待っていて、今の結果をもとに修正を続けさせたいときは、修正を依頼します。

あとの 2 つは、どちらもタスクエージェントに修正を続けさせる方法で、違いはタイミングとやり取りの形にあります。セッションに入る方法は、実行途中のリアルタイムのやり取りに向いています。エージェントの動きを 1 つずつ見ながら、メッセージを続けて何通か送れます。やり取りを終えてセッションから抜けると、タスクは実行を続けます。修正を依頼する方法は、タスクが終わったあとに、要望を 1 回でまとめて伝えるのに向いています。分離ブランチモードでは、CodeDAG はデフォルトで、まず現在の変更を一度コミットし、それから依頼の内容をタスクエージェントに渡します。

2 つの方法は、それぞれの前提を満たしていれば、互いに代わりとして使えます。レビュー待ちのタスクでも、セッションに入って、エージェントにやり方について質問したり、その場で修正させたりできます。レビューの結論は、そのあとで自分で出します。実行中のタスクも、いったん強制停止するか、現在のステップを終えるのを待ってから、修正を依頼できます。後者の方法は、対話型ターミナルを必要としません。そのため、スクリプトやエージェントのシェルツールのような環境から、実行中のタスクの方向を修正したい場合に、代わりに使えます。書き方は実行中のタスクに request-changes を実行するを参照してください。CodeDAG Guide を入れたエージェントに操作を任せている場合は、そのエージェントが tmux を使ってセッションに入ることもできます。オーケストレーションエージェントが行うことを参照してください。

セッションに入る、修正する、抜ける

実際のターミナルで cdg task view を実行すると、タスクエージェントのネイティブセッションに入れます。エージェントが今何をしているかを見たり、メッセージを直接送って方向を修正したりできます。やり取りが済んだら Ctrl+C で抜けます。タスクはそのまま実行を続けます。

cdg task view 2 -w feature

セッションに入ると表示されるのは、Claude Code または Codex 自身の画面で、ターミナルで直接開いたときと同じです。キー入力はそのままエージェントに渡されるため、中での操作も普段と変わりません。メッセージを入力する、許可の選択肢を選ぶ、Esc で現在の動作を中断してから新しい指示を伝える、といった操作ができます。例外は Ctrl+C だけです。Ctrl+C はエージェントには渡されず、セッションから抜けるためのキーとして働きます。

このコマンドには、実際の対話型ターミナルが必要です。スクリプトやエージェントのシェルツールの中では、画面が崩れ、キー入力にも反応しません。その場合は、監視と修正の方法を選ぶで紹介した代わりの方法を使ってください。また、タスクの実行がすでに始まっている必要があります。まだ始まっていないタスクには入れるセッションがないため、コマンドは Task has not started yet. と表示してそのまま終了します。セッションに入れないそのほかのケースは、task view に接続できない、または反応しないを参照してください。コマンドのほかの引数と、セッションを特定する方法は、コマンドリファレンスを参照してください。

セッションで送ったメッセージは、そのままタスクエージェントに渡されます。CodeDAG が先に現在の変更をコミットしておくことはありません。分離ブランチモードでは、メッセージを送る前の変更も後の変更も、タスクの終了時に、そのタスクの結果としてまとめてコミットされます。方向を修正する前と後でそれぞれ何が変更されたかをあとで比べられるように、区切りを残しておきたい場合は、メッセージの中で、先にコミットするよう指示します。たとえば次のように書きます。

まず現在の変更を一度コミットしてください。コミットメッセージは「方向を調整する前の進捗」とします。そのあとは src/legacy/ にあるファイルを変更せず、代わりに新しいモジュールで同じ機能を実装してください。

やり取りが済んだら、早めにセッションから抜けてください。セッションに接続している間、CodeDAG はタスクが完了したと判定しません。エージェントがすでに作業を終え、入力待ちで止まっていても、タスクは working と表示されたままで、そのタスクに依存する下流は始まりません。Ctrl+C でセッションから抜けて初めて、タスクは通常の流れで終了します。

許可リクエストに応答する

タスクエージェントが止まって許可を待っているときは、cdg task view 2 -w feature を実行してそのセッションに入ります。エージェントが何を実行しようとしているかを確かめ、画面に表示されているキーで許可または拒否してから、Ctrl+C で抜けます。タスクはそのまま実行を続けます。エージェントが質問をして回答を待っている場合も、対処方法は同じです。

CodeDAG は、「許可待ち」を表す専用のステータスを表示しません。タスクは working のままで、いつまでたっても進展がなく、ログの末尾がエージェントの確認画面で止まっているだけです。エージェントが応答を待っているのかどうかを確かめる方法は、止まったままかどうかを見分けるにはを参照してください。

今回の実行で出る許可リクエストには、この方法で 1 つずつ応答する必要があります。各タスクの権限モードは、投入時にすでに確定しているからです。今後のワークフローが許可待ちで止まらないようにするには、ワークフローファイルで、タスクに適切な mode を書きます。アクセスレベルごとのトレードオフは、無人実行か有人実行かを決めるを参照してください。フルアクセスを使っていても、Claude Code は一部の操作については、やはりユーザーに確認を求めます。エージェントが許可または回答を待っているを参照してください。

一時停止する：pause と unpause

pause は、作業中のタスクエージェントを中断せず、手元の作業を終えるのを待ってから止めます。まだ始まっていないタスクはすぐに一時停止され、起動されなくなります。unpause は、タスクの一時停止を解除して続行させます。

# ワークフロー全体を一時停止する
cdg dag pause feature
# ワークフロー feature のタスク 2 だけを一時停止する
cdg task pause 2 -w feature

実行中のタスクの場合は、タスクが draining（ドレイン中）に入ったことが表示されます。

Pausing task 2 in .codedag/dags/feature.yaml...

Task draining: [Task 2] ログインAPIを実装
  Task will pause gracefully after current step completes.

→ Use 'cdg task unpause 2 -w feature' to unpause this task
→ Use 'cdg task kill 2 -w feature' to kill this task immediately (may cause unintended side effects, requires more complex recovery)
→ Use 'cdg task logs 2 -w feature -f' to view task logs
→ Use 'cdg task status 2 -w feature --watch' to view task status

draining は、一時停止がすでに有効になっていて、タスクエージェントが現在のステップを終えるのを待っている状態を表します。この間もエージェントは作業を続けており、ファイルを変更することもあります。エージェントが現在のターンを終えて止まると、タスクは paused になります。レビューには入らず、下流も始まりません。

一時停止したタスクを続行させるには、cdg dag unpause feature または cdg task unpause 2 -w feature を使います。unpause が効くのは一時停止されたタスクだけで、強制停止された（killed）タスクや保留になった（on-hold）タスクには recover を使います。一時停止を解除したあとの動きは、その時点のタスクの状況によって決まります。

• 開始前に一時停止された場合： タスクは待機に戻り、条件が整えば通常どおり起動されます。
• 一時停止の時点で実行中で、すでにそのターンを終えて paused で止まっている場合： タスクは完了したものとして扱われ、done になってレビューに入ります（デフォルトでは自動承認されます）。それに続いて、下流が始まります。
• まだ draining の場合： タスクは working に戻り、通常どおり完了します。

そのため pause は、「手元の作業は終わらせてよいが、その先へはまだ進めたくない」という場面に向いています。しばらく席を離れるときや、ほかのことを先に片付けてからワークフローを続行させたいときなどです。エージェントを作業の途中で止め、あとで続きから再開させたい場合は、kill と recover を使います。

すぐに止める：kill

kill は、作業中のタスクエージェントをその場で中断します。タスクは killed になります。これは、エージェントの画面で Esc を押すのと同じです。エージェントの現在の応答と操作は中断されますが、エージェントのプロセスもセッションも残るので、あとから元のセッションで続きから再開できます。

# ワークフロー feature のタスク 2 を強制停止する
cdg task kill 2 -w feature
# ワークフロー全体を強制停止する
cdg dag kill feature

まだ始まっていないタスクには中断できるセッションがないため、kill の効果は一時停止と同じになります。タスクは paused になり、起動されなくなります。そのため、cdg dag kill でワークフロー全体を止めると、実行中のタスクは強制停止され、まだ始まっていないタスクもすべて起動されなくなります。

kill が何かを削除することはありません。セッションのコンテキストは残り、エージェントがすでにワークスペースに書き込んだ変更もそのまま残ります。巻き戻されることも、コミットされることもありません。注意が必要なのは、中断されたステップが途中までしか終わっていない可能性があることです。コマンドの実行が途中で止まっている、ファイルの一部だけが変更されている、といった場合です。続行する前に、タスクのワークスペースで git status と git diff を実行して、確認しておくとよいでしょう。

強制停止したあと、どこで止まったかを確認したいだけなら、cdg task logs 2 -w feature でログを読みます。強制停止されたタスクのセッションに cdg task view で入ろうとすると、コマンドはまず、セッションに入るにはこのタスクを復旧する必要があることを説明し、復旧するかどうかを尋ねます。タスクが実行を続けるのは、確認したあとです。復旧しないことを選んだ場合は、何も変わりません。詳しくはコマンドリファレンスを参照してください。

強制停止されたタスクが自動的に続行されることはありません。止まったままのタスクが残っているかぎり、そのワークフローは終了せず、キューの後ろに並んだワークフローも待ち続けます。一時停止したタスクについても同じです。キューを先へ進めるには、recover でこれらのタスクを復旧するか、もう必要がなければ、レビューコマンドの cancel または defer でタスクを終わらせます。タスクがゲートの前で止まっていない場合を参照してください。

復旧する：recover

recover は、止まっているタスクを続行させます。強制停止されたタスクは元のセッションで続きから再開し、一時停止されたタスクには unpause と同じ効果があり、保留になったタスクは、原因に対処したあとで続行します。

# ワークフロー feature のタスク 2 を復旧する
cdg task recover 2 -w feature
# ワークフロー全体で、復旧できるタスクをすべて復旧する
cdg dag recover feature

強制停止されたタスクを復旧すると、CodeDAG は元のセッションで、エージェントに continue というメッセージを送ります。エージェントはそれまでのコンテキストを保ったまま、中断されたところから作業を続けるので、最初からやり直す必要はありません。cdg dag kill でワークフロー全体を止めたあとは、cdg dag recover ですべてのタスクを一度に復旧するのが最も手軽です。復旧によって CodeDAG クレジットが再び消費されることはありません。

保留になった（on-hold）タスクは、先に原因に対処する必要があります。cdg task status 2 -w feature の出力にある Reason: 行を確認し、その理由に応じて対処してから、recover を実行します。recover が具体的に何をするかは、理由によって異なります。たとえば、予期せず終了したセッションを開き直す、届かなかった修正依頼の内容を送り直す、開始できなかったタスクにもう一度開始を試みさせる、といった動作です。原因が解消されていなければ、タスクは再び on-hold で止まります。理由ごとの対処手順は、タスクまたはワークフローが on-hold で止まっているを参照してください。

よくある質問

タスクを止めても、ほかのタスクが開始されないのはなぜですか

分離ブランチモードでは、実行が始まったタスクは、割り当てられたワークスペースと同時実行枠を占有し続け、レビューが終わって初めて解放します。pause と kill はタスクの作業を止めるだけで、この占有までは解除しません。そのため、ほかの独立したタスクが、それによって早く始まることはありません。コマンドの出力にも、そのようなタスクについて、ワークスペースと同時実行枠を引き続き占有していることが表示されます。ほかのタスクを先に実行させたい場合は、このタスクを最後まで実行させてからレビューするか、cdg task review cancel または defer でタスクを終わらせます。タスクがゲートの前で止まっていない場合を参照してください。

一時停止や強制停止のときに Workflow startup billing is being committed と表示される

ワークフローの実行を始める順番が来た直後で、CodeDAG がそのワークフローの CodeDAG クレジットを差し引いている最中は、pause と kill が一時的に拒否され、このメッセージが表示されます。この時間は通常数秒だけですが、ネットワークの状態が悪いと、約 3 分まで続くことがあります。少し待ってから、もう一度実行してください。

関連ページ

• タスクとワークフローをレビューする：タスクの完了後に結果を確認し、修正を依頼するか、結論を出します。
• トラブルシューティング：タスクが on-hold で止まったときや、いつまでたっても進展がないときに、症状から対処手順を探せます。
• 制御と介入：各制御コマンドの完全な書き方と適用範囲、復旧がうまく進まないときに使うオプション。