投入、監視、ログ

cdg dag submit は、ワークフローをプロジェクトのキューに入れます。ワークフローは、順番が来るとバックグラウンドで実行されます。コマンドはキューに入れた時点ですぐに戻り、ターミナルを閉じても実行には影響しません。投入後は、cdg status、cdg dag status、cdg task status を使って、プロジェクト、ワークフロー、タスクの 3 つの階層でステータスを確認し、cdg dag logs と cdg task logs で、タスクエージェントが何をしたかを確認します。CodeDAG にはタスクのタイムアウトがありません。タスクに長い間動きがないときは、止まったままになっているのかどうかを自分で判断する必要があります。

ワークフローを投入する

ワークフローファイルが cdg dag validate の検証に通ったら、cdg dag submit で投入します。ワークフローはこのプロジェクトのキューに入り、順番が来るとバックグラウンドで実行が始まります。ターミナルを閉じても影響はありません。

cdg dag submit api-docs

コマンドは、ワークフローがキューに入るとすぐに戻ります。出力には、キュー内での位置と、ステータスやログを確認するためのコマンドが表示されます。

複数のワークフローを一度に投入することもできます。cdg dag submit api-docs release-notes のように、名前をスペースで区切って並べると、書いた順にキューに入ります。複数のワークフローを一度に投入するを参照してください。今回の投入に限ってレビューの設定を変えたい場合、たとえばタスクが完了するたびに止めてレビューを待たせたい場合は、--task-auto-accepted などのオプションを使います。書き方は今回の投入に限ってレビュー設定を調整するを参照してください。

投入時にチェックされること

投入の前に、CodeDAG は次の点を確認します。1 つでも通らない項目があれば、ワークフローはキューに入りません。複数のワークフローを一度に投入した場合は、そのうち 1 つでも通らなければ、どのワークフローも投入されません。

1. ワークフローファイルが有効であること。 投入時には cdg dag validate と同じチェックがもう一度行われ、エラーがあれば投入されません。警告だけの場合は、コマンドが警告を一覧表示してから Submit anyway? と尋ねます。デフォルトの答えは「投入しない」です。警告を読み、実行に影響しないことを確認したうえであれば、-y を付けてこの質問を省略できます。
2. このワークフローがキューに入っていないこと。 同じワークフローは、投入したあと、レビューが終わってキューを離れるまで、もう一度投入することはできません。
3. このワークフローのレビューが終わっていないこと。 レビューが終わったワークフローは、cdg dag review clear でレビュー記録をクリアしてからでないと、再投入できません。レビュー記録のクリアと再投入を参照してください。
4. CodeDAG アカウントにログインしていること。 まだログインしていない場合は、コマンドがまずログインを求め、ログインが済むと、そのまま投入に進みます。
5. CodeDAG クレジットが足りていること。 アカウントに残っているクレジットで、今回の投入に含まれるすべてのタスクを実行できる必要があります。クレジットが足りない場合や、有効なサブスクリプションがない場合は、投入が拒否されます。

投入が拒否された場合は、出力のメッセージをもとに、トラブルシューティングの投入が拒否されたの節で、該当する対処方法を探してください。

投入後に、ワークスペースに未コミットの変更があると表示されたとき

投入の出力の末尾に黄色のメッセージが表示され、その 1 行目が The workflow is on hold because the target workspace has uncommitted changes. である場合、ワークフローはすでにキューに入っていますが、最初に使うワークスペース（デフォルトではプライマリリポジトリ）がクリーンではありません。タスクは開始できず、on-hold で止まります。理由は workspace-dirty です。デフォルトの分離ブランチモードでは、CodeDAG がワークスペースをタスクブランチに切り替え、タスクの変更をコミットします。そのため、どのタスクも、開始前にそのワークスペースに未コミットの変更がないことが求められます。未追跡の新しいファイルも、未コミットの変更に含まれます。

ワークフローを投入し直す必要はありません。そのワークスペースで、変更をコミットするか、git stash -u などで退避するか、破棄してから、cdg dag recover api-docs を実行します。タスクは準備をやり直して開始されます。このタスクのためにワークスペースを片付けたくない場合は、タスクをそのまま終わらせることもできます。方法はワークスペースに未コミットの変更または未完了の Git 操作があるを参照してください。

投入したターミナルでそのままログを追う：--attach

ワークフローを最初から最後まで見届けたい場合は、投入時に --attach を付けます。現在のターミナルに、そのワークフローのログが終了まで表示され続けます。投入してすぐ席を離れる場合や、複数のワークフローを同時に見ておきたい場合は、付けずに投入し、あとは以降の節で紹介するコマンドで、いつでも確認できます。

cdg dag submit api-docs --attach

ログの内容は cdg dag logs -f と同じです。読み方はログを参照してください。ワークフローがキューの後ろにある場合、ログが表示されるのは、順番が来て実行が始まってからです。途中で on-hold で止まった場合は、ログを追うのもそこで終わり、ターミナルにその旨が表示されます。

ログを追っている間に使えるキーは 2 つあり、働きは大きく異なります。Ctrl+C は、このターミナルがログを追うのをやめるだけで、ワークフローはバックグラウンドでそのまま実行を続けます。もう一度追いたくなったら、cdg dag logs api-docs -f を実行します。一方、Ctrl+\ はワークフロー全体を強制停止します。効果は cdg dag kill と同じで、続行させるには、あとで cdg dag recover を実行する必要があります。すぐに止めるを参照してください。

追っているログは読み取り専用で、このターミナルに入力した内容がタスクエージェントに渡ることはありません。エージェント自身の画面を見たいとき、エージェントとやり取りしたいとき、許可リクエストに応答したいときは、別のターミナルを開いて cdg task view を実行します。セッションに入る、修正する、抜けるを参照してください。

ログを追っている間に入力を求められるのは、レビューのときだけです。タスクまたはワークフロー全体に手動レビューを設定していると、レビュー待ちになった時点でターミナルのログが止まり、Task 1 is ready for review (done). のようなメッセージと、選択できるレビューアクションが表示されます。その場で結論を出せます。メニューで Esc を押すと、今回はレビューしないという意味になります。ログを追うのはそこで終わり、タスクまたはワークフローは、そのまま止まって結論を待ちます。あとから cdg task review または cdg dag review で結論を出してください。タスクとワークフローをレビューするを参照してください。

今の状況を確認する：3 つの階層の status

cdg status はプロジェクト全体のキューを、cdg dag status <ワークフロー> は 1 つのワークフローに含まれる各タスクを、cdg task status <タスク ID> -w <ワークフロー> は個々のタスクの詳細を表示します。原因を調べるときは、上の階層から順に見ていきます。まず止まっているワークフローを見つけ、次に止まっているタスクを見つけ、最後にそのタスクが止まった理由を確認します。cdg dag status でワークフローを省略した場合と、cdg task status で -w を省略した場合は、どちらもキューの先頭のワークフローが対象になります。

次の例では、ワークフロー api-docs を投入したのに、いつまでたっても実行が始まりません。3 つのコマンドを上の階層から順に実行して、原因を突き止めています。

$ cdg status
[TZ: -04:00] 2026-09-30 10:53:37

Planning Workflows (1):
  📝 .codedag/dags/release-notes.yaml

Submitted Workflows (1):
  #1   🔘 [pending]     [on-hold]  .codedag/dags/api-docs.yaml

$ cdg dag status api-docs
[TZ: -04:00] 2026-09-30 10:53:38

Workflow: .codedag/dags/api-docs.yaml
  Phase: 📤 submitted
  Queue Position: 1
  Status: 🔘 pending
  Substatus: on-hold
  Docs: https://codedag.com/docs/troubleshooting/troubleshooting#on-hold
  Integration Workspace: /Users/you/my-app
  Integration Branch: cdg/api-docs/integration
  Base Commit: ae07d384aa41aa5aaa2041af5bfd529f8584f461

Submitted Tasks (2):
  🔘 [pending]     [on-hold]  Task 1: API一覧をまとめる
  🔘 [pending]     [blocked]  Task 2: APIドキュメントを書く

Progress: 0/2 tasks completed (0%)

$ cdg task status 1 -w api-docs
[TZ: -04:00] 2026-09-30 10:53:38

Task 1 in .codedag/dags/api-docs.yaml
Title: API一覧をまとめる
Phase: 📤 submitted
Status: 🔘 pending
Substatus: on-hold
Reason: workspace-dirty
Diagnostic: Task workspace has uncommitted changes: ?? notes.txt
Docs: https://codedag.com/docs/troubleshooting/troubleshooting#hold-workspace
Workspace: /Users/you/my-app
Branch: cdg/api-docs/t1-api一覧をまとめる

cdg status からわかるのは、キューの先頭にある api-docs が [pending] [on-hold]、つまり保留になっていることだけです。cdg dag status を見ると、保留になっているのはタスク 1 で、タスク 2 はそれを待っていることがわかります。理由の workspace-dirty が示されるのは、cdg task status まで進んでからです。タスク 1 に割り当てられたワークスペースに未コミットの変更があり、Diagnostic: の行に該当するファイルが表示されています。対処方法は投入後に、ワークスペースに未コミットの変更があると表示されたときを参照してください。

タスクが保留になった理由は cdg task status にしか表示されず、しかも、タスク ID を 1 つだけ指定したときにしか表示されません。ワークフローそのものが保留になった場合、たとえば実行を始める順番が来たときに CodeDAG クレジットが足りなかった場合は、理由が cdg status の該当行の末尾に括弧付きで表示され、cdg dag status の Reason: 行にも表示されます。

ステータスとサブステータスの各組み合わせが何を表すかは、状態の意味を参照してください。待つだけでよい場合と、自分で対処する必要がある場合の区別は、同じページの対処が必要なときを参照してください。

3 つのコマンドには、いずれも --watch を付けられます。表示は 1 秒ごとに更新され、対象のワークフローまたはタスクのレビューがすべて終わるまで続きます。コマンドごとの終了条件は、ステータス表示を更新し続けるを参照してください。

タスクが何をしているかを見る：ログ

cdg dag logs <ワークフロー> は、ワークフロー全体のログをタスクごとに区切って表示します。-f を付けるとログを追い続け、-n を付けると末尾の数行だけを表示します。1 つのタスクだけを見たい場合は、cdg task logs <タスク ID> -w <ワークフロー> を使います。

# ワークフロー全体のログを、タスクごとに区切ってすべて表示する
cdg dag logs api-docs

# まず末尾の 50 行を表示し、そのあと新しいログを追い続ける
cdg dag logs api-docs -n 50 -f

# タスク 2 の末尾 50 行だけを表示する
cdg task logs 2 -w api-docs -n 50

-f を付けると、複数のタスクのログが時刻順に入り混じって表示され、ワークフローのレビューが終わってキューを離れると、自動的に終了します。ログは長くなりがちなので、最近の状況を知りたいときは、まず -n で末尾の数十行を見るほうが早く済みます。ワークフローを省略すると、キューの先頭のワークフローのログが表示されます。レビューが終わったあとのワークフローも、名前を指定すればログを見られます。

ログに記録されるのは、タスクエージェントがターミナルの画面に出力した内容です。エージェントの応答、呼び出したツール、実行したコマンドとその結果が含まれます。これとは別に、CodeDAG が各タスクの開始時と終了時に、START: と END: の行を 1 行ずつ書き込みます。ターミナルの画面を 1 行ずつ記録したものなので、ログには、エージェントの画面のアニメーション、経過時間の表示、ステータスバーの更新が残した断片も混ざっています。そのため、エージェントの画面で直接見るときほど読みやすくはありません。応答の本文、権限の確認、コマンド、ファイル名のように、エージェントが一度に出力したテキストは、単語間のスペースが保たれたままログに残るので、フレーズ全体で検索できます。

ログファイルは、プライマリリポジトリの .codedag/local/logs/ に保存されます。パスは、ワークフローファイルの .codedag/dags/ からの相対パスと同じで、拡張子が .log に変わります。同じワークフローをもう一度実行すると、新しいログは同じファイルの末尾に追記されます。ファイルの確認と削除については、ログファイルの場所を参照してください。

ログは読み取り専用の記録です。どのターミナルからでも、スクリプトやエージェントのシェルツールからでも読め、読んでもタスクには影響しません。普段の監視には、これで十分です。エージェント自身の画面を見たいとき、エージェントとやり取りしたいとき、許可リクエストに応答したいときには、cdg task view でセッションに入ります。どちらを選ぶかは、監視と修正の方法を選ぶを参照してください。

止まったままかどうかを見分けるには

タスクがずっと working のままで、ログに意味のある新しい内容が長い間現れなくても、止まったままになっているとは限りません。タスクエージェントがサブエージェントを起動してバックグラウンドで作業させているときや、時間のかかるコマンドを実行しているときは、メインセッションでは長い間、経過時間の表示とステータスバーしか変化しないことがあります。CodeDAG にはタスクのタイムアウトもなく、実行時間が長いというだけでタスクを強制停止することはありません。そのため、介入するかどうかは自分で判断します。目安として、何の進展も見られない状態が 10 分以上続いてから、原因を調べ始めます。

最も注意が必要なのは、タスクエージェントがユーザーを待っている場合です。操作の許可や質問への回答を待っているエージェントは、誰も応答しなければ待ち続けます。その間も、タスクのステータスは working と表示されたままです。手がかりは、ログの末尾がエージェントの確認画面や質問で止まり、時刻が更新されなくなっていることだけです。たとえば次のようになります。

$ cdg task status 1 -w api-docs
[TZ: -04:00] 2026-09-30 11:01:53

Task 1 in .codedag/dags/api-docs.yaml
Title: API一覧をまとめる
Phase: 📤 submitted
Status: 🟢 in-progress
Substatus: working

$ cdg task logs 1 -w api-docs -n 12
[Task   1] [2026-09-30 10:59:14] ──────────────────────────────────────────────────────────────────────────────────────────
[Task   1] [2026-09-30 10:59:14]  Create file
[Task   1] [2026-09-30 10:59:14]  docs/api/endpoints.md
[Task   1] [2026-09-30 10:59:14] ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
[Task   1] [2026-09-30 10:59:14]   1 まだ API はありません
[Task   1] [2026-09-30 10:59:14] ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
[Task   1] [2026-09-30 10:59:14]  Do you want to create endpoints.md?
[Task   1] [2026-09-30 10:59:14]  ❯ 1. Yes
[Task   1] [2026-09-30 10:59:14]    2. Yes, and switch to accept edits (auto-approve file edits and common file commands)
[Task   1] [2026-09-30 10:59:14]       for this session (shift+tab)
[Task   1] [2026-09-30 10:59:14]    3. No
[Task   1] [2026-09-30 10:59:14]  Esc to cancel · Tab to amend

ここでは、タスク 1 のステータスは working ですが、ログは 2 分あまり前で止まっています。末尾は、Claude Code が endpoints.md を作成してよいかを尋ねる画面で、人の許可を待っている状態です。cdg task view でセッションに入り、選択すれば済みます。方法は許可リクエストに応答するを参照してください。調査の手順全体と、止まったままだと確認できたあとに、強制停止してから元のセッションで再開させる方法は、タスクに長時間新しい出力がないを参照してください。

関連ページ

• 介入と制御：タスクの一時停止、強制停止、復旧と、セッションに入って方向を修正したり、許可リクエストに応答したりする方法。
• 状態の意味：フェーズ、ステータス、サブステータス、レビュー結果がそれぞれ何を表すか、表示されたときに待てばよいのか、対処が必要なのか。
• ステータスとログ：ステータスとログのコマンドの、すべての引数と書き方。