コストを抑える

CodeDAG でワークフローを実行すると、2 種類のコストがかかります。1 つは CodeDAG クレジット、もう 1 つはタスクエージェント自身の利用量です。後者は、Claude Code や Codex が消費するサブスクリプションの利用上限、または API の料金を指します。CodeDAG クレジットはタスクを数えれば計算でき、1 タスクにつき 1 クレジットです。エージェントの利用量は、モデル、推論エフォート、各タスクが読み書きするコンテキストによって決まるため、事前に正確には計算できず、試し実行で見積もることになります。

2 種類のコスト

CodeDAG クレジットはタスク数で計算され、タスクにかかった時間や使ったモデルとは関係ありません。エージェントの利用量は、手元のマシンの Claude Code と Codex のログイン方法に応じて、Anthropic と OpenAI がそれぞれ計算します。CodeDAG がその料金を代わりに徴収することも、利用量を表示することもありません。

タスクエージェントは、手元のマシンにある Claude Code や Codex そのものです。タスクの中での利用量は、自分で開いたセッションと同じアカウントに計上されます。上限の具体的なルールは、各社の説明に従います。Claude Code のコスト管理のドキュメントと、Codex の利用量の説明を参照してください。

ワークフローのコストを見積もる

CodeDAG クレジットは、タスクを数えるだけで計算できます。ワークフローファイルにあるタスクの数だけ、実行が始まるときにクレジットが差し引かれます。この数は実行が始まった時点で確定します。その後タスクの実行にどれだけ時間がかかっても、途中で何度手直しをしても、最終的に完了したタスクがいくつであっても変わりません。再投入は新しい実行として扱われ、実行が始まるときに、その回のタスク数の分が改めて差し引かれます。ルールはクレジットが差し引かれるタイミングを参照してください。

複数のワークフローを続けてキューに入れる場合は、タスク数の合計で見積もります。CodeDAG が投入のたびに確認するのは、その投入に必要なクレジットが足りるかどうかだけで、クレジットを確保しておくわけではありません。前に並んだワークフローが先に始まって先にクレジットを使うため、後ろのワークフローは、実行の順番が来たときにクレジット不足で止まる可能性があります。

エージェントの利用量は事前に正確には計算できませんが、タスクの分け方からおおよその大きさを判断できます。各タスクは新しいセッションなので、必要なコードやドキュメントを改めて読み込みます。そのため、同じファイル群を複数のタスクが読めば、読み込みの利用量もタスクの数だけかかります。タスクの中で起動したサブエージェントも、それぞれ利用量に計上されます。かといって、1 つのタスクに作業を詰め込みすぎても、節約になるとは限りません。セッションが長くなるほど、リクエストのたびに送られるコンテキストが増え、1 ターンあたりのコストが上がるからです。タスクの適切な分け方は、タスクを分ける：1 つのタスクに 1 つの目標を参照してください。

例として、4 つのタスクに、同じ変更をそれぞれ別の観点からレビューさせる場合を考えます。CodeDAG クレジットは 4 クレジットです。エージェント側では、4 つのセッションがそれぞれこの変更と関連するコードを読むため、利用量は、1 つのセッションが 1 回レビューする場合のおよそ 4 倍になります。1 つのタスクが実際にどれだけ使うかを知るには、まず一部だけを試し実行するのが最も確実です。

まず一部だけ試し実行する

タスクが多く、内容も互いに似ているワークフローでは、最初の 1、2 個のタスクだけを別のワークフローとして書き、先に実行してみるとよいでしょう。同じ種類の修正を 20 個のモジュールに適用するようなワークフローが、これに当たります。プロンプトの内容が明確か、mode の設定のせいでタスクが許可待ちで止まったままにならないか、成果物が期待どおりかを確認してから、残りを投入します。試し実行で消費するのは 1、2 クレジットだけです。一方、ワークフロー全体をそのまま投入すると、全タスク分のクレジットが実行開始時に差し引かれます。あとからプロンプトの問題に気づいても、差し引かれたクレジットが自動で返還されることはなく、エージェントの利用量もすでに使ってしまっています。

試し実行は、エージェントの利用量を見積もる最も直接的な方法でもあります。そのアカウントでほかのセッションが動いていないときに、試し実行の前後で Claude Code の /usage または Codex の /status を 1 回ずつ確認すれば、1 つのタスクが上限のどれくらいを使うかがおおよそわかります。それにタスク数を掛け、残りの上限と比べれば、ワークフロー全体を 1 つのウィンドウの中で実行し終えられるかどうかを判断できます。

試し実行の結果に満足できれば、そのまま活用できます。本番のワークフローには、残りのタスクだけを書きます。baseRef を書かず、プライマリリポジトリを別のブランチに切り替えてもいなければ、本番のワークフローは試し実行の結果の続きから始まります（ベースを参照）。この場合、2 回で消費するクレジットの合計は、全タスクを一度に投入した場合と同じになります。

タスクごとにモデルを選ぶ

モデルと推論エフォートは、エージェントの利用量を左右する主な要因の 1 つです。ワークフローでは、これらをタスクごとに設定できます。model と effort を使って、機械的なタスクにはコストの低い設定を割り当て、判断が必要なタスクにだけ高性能なモデルと高めの推論エフォートを使います。CodeDAG クレジットには影響せず、1 タスクにつき 1 クレジットのままです。

この 2 つのフィールドを書かない場合、すべてのタスクが、エージェント側で設定されているデフォルトのモデルと推論エフォートを使います。普段のデフォルトが最も高性能なモデルであれば、ワークフローのすべてのタスクが、そのモデルで利用量を消費します。検索や整理をするだけのタスクや、計画に沿って 1 か所ずつ修正するだけのタスクも例外ではありません。

次のワークフローは、まずリポジトリ内の TODO コメントを洗い出し、次にどれから着手するかを評価します。2 つのタスクには、それぞれ別の設定を使っています。

executionMode: shared-workspace   # どちらのタスクもレポートファイルを書くだけなので、ブランチは不要
tasks:
  - id: 1
    title: TODOコメントを洗い出す
    agent: claude
    mode: bypassPermissions
    model: sonnet                 # 機械的な検索と整理なので、コストの低いモデルを使う
    effort: low
    prompt: |
      リポジトリ内の TODO コメントと FIXME コメントをすべて見つけてください
      （依存パッケージのディレクトリとビルド成果物は除きます）。
      ファイルごとに表にまとめ、各行にファイルパス、行番号、コメントの原文を書いて、
      docs/todo-triage/inventory.md に書き込んでください（すでにある場合はそのまま上書きします）。
      ほかのファイルは変更しないでください。
  - id: 2
    title: 優先度を評価する
    dependencies: [1]
    agent: claude
    mode: bypassPermissions
    model: opus                   # コードを踏まえた判断が必要なので、より高性能なモデルを使う
    effort: high
    prompt: |
      docs/todo-triage/inventory.md を読み、関連するコードも踏まえて、
      各 TODO の影響と作業量を判断してください。
      先に取り組む価値が最も高い 5 件を選んで理由を説明し、
      docs/todo-triage/priorities.md に書き込んでください（すでにある場合はそのまま上書きします）。
      ほかのファイルは変更しないでください。

一般に、リストに沿った検索、書式の整理、できあがった計画に沿った 1 か所ずつの修正、決まった形式のドキュメントの生成には、コストの低い設定が向いています。計画の立案、レビュー、複数の結果のまとめ、難しい問題の原因調査には、高性能なモデルを使う価値があります。2 つのフィールドの書き方と、各エージェントで指定できる値は、モデルと推論エフォートを選ぶを参照してください。

同時実行と利用上限

同時実行によって CodeDAG クレジットは変わらず、エージェントの利用量の合計もほとんど変わりません。変わるのは、その利用量が消費される速さです。同時に実行されるタスクはそれぞれ独立したセッションであり、同じアカウントの上限を一緒に消費します。

同時実行数が多いほど、1 つのウィンドウの上限を早く使い切ります。しかも使い切った時点で、実行中のタスクがまとめて止まります。ワークフロー全体の利用量が 1 つのウィンドウで使える量を超える場合は、maxConcurrency を下げて、同じ利用量をより長い時間に分散させます。そうすれば、5 時間のような短いウィンドウの上限に途中で達しにくくなります。その代わり、ワークフローの実行には時間がかかるようになり、週ごとの上限が増えるわけでもありません。API キーを使う場合も、同時実行数が多いほど、1 分あたりのリクエスト数やトークン数のレート制限に達しやすくなります。

Claude Code と Codex を組み合わせると、利用量を、互いに独立した 2 つの上限に分けられます。一方が上限に達しても、もう一方のタスクは通常どおり実行されます。2 つのエージェントの利用上限は互いに影響しないを参照してください。

エージェントにオーケストレーションを任せる場合、オーケストレーションエージェント自身のセッションも、そのエージェントが使っているアカウントの上限を消費します。オーケストレーションエージェントとタスクが同じエージェントを使っていると、長時間にわたる監視が、タスクに回せたはずの上限の一部を使ってしまいます。

上限に達したあと、影響を受けたタスクをどう見つけ、どう被害を抑えて作業を続けるかは、トラブルシューティングのエージェントの利用上限またはレート制限を参照してください。

要所で手直しし、全体の再実行を減らす

1 回の実行の中で結果を修正する分には、CodeDAG クレジットは追加で消費されません。結果をいったん通してしまい、全体を再投入するしかなくなると、全タスク分をもう一度支払うことになります。そのため、以降の作業すべての土台になるノードでレビューゲートを閉じておけば、少しの待ち時間と引き換えに、全体を再実行するリスクをなくせます。

ゲートが閉じていると、タスクは完了後に止まってレビューを待ちます。結果に納得できなければ、request-changes で元のセッションに今の結果の続きから修正させることも、rework でタスク開始前のクリーンベースラインからやり直させることもできます。2 つのアクションの使い方は、判断に応じてアクションを選ぶを参照してください。どちらの手直しでも CodeDAG クレジットは増えず、消費するのはエージェントの利用量だけです。このうち rework は新しいセッションを開くため、利用量はそのタスクをもう一度実行するのとほぼ同じになります。

ゲートが開いていると、結果は完了と同時に自動承認され、下流がすぐにその結果をもとに作業を始めます。あとから問題に気づいても、結論はもう変更できません。理由はレビューの結論は変更できないを参照してください。この場合、やり直しが必要なタスクが少数であれば、それらだけを新しいワークフローとして書いて続きを進めます。消費するクレジットはそのタスクの分だけなので、レビュー記録をクリアしてワークフロー全体を再投入するよりも少なくて済みます。手順はタスクにレビューの結論が出たあとで問題に気づいたを参照してください。

ゲートを閉じることにも代償があります。止まってレビューを待っているタスクは下流を待たせ続け、分離ブランチモードでは自分のワークスペースも占有し続けます。閉じたゲートが多いほど、ワークフローの実行は遅くなります。そのため、ゲートを閉じる価値があるのは、失敗したときの損失が最も大きい少数のノードだけです。ゲートを閉じる価値があるノードを参照してください。

関連ページ

• クレジット、サブスクリプション、課金：無料クレジット、サブスクリプション、課金ルールを詳しく説明しています。
• エージェント、モデル、権限モードを選ぶ：タスクごとに、エージェント、モデル、推論エフォート、権限モードを選びます。
• トラブルシューティング：エージェントの利用上限またはレート制限：Claude Code または Codex の利用上限に達したあとの対処方法を説明しています。