タスクの分割とプロンプトの書き方

ワークフローがうまく動くかどうかは、タスクの分け方とプロンプトの書き方に大きく左右されます。どのタスクも新しいエージェントセッションが実行し、そのセッションが知っているのは、プロンプトと、自分でリポジトリから読んだファイルだけです（理由はタスクとセッションを参照）。タスクを分け、依存関係を組み、プロンプトを書くときに考えるべきことの多くは、ここから生じます。

タスクを分ける：1 つのタスクに 1 つの目標

1 つのタスクには、一文で言い表せて、完了後に検証できる目標を 1 つだけ持たせます。作業量は、1 つのセッションが余裕を持って終えられる範囲に収めます。分けるときには、2 つの点のバランスを取る必要があります。タスクが大きすぎると、セッションのコンテキストがいっぱいになります。小さすぎると、タスクの間で情報が失われます。

「プロジェクトの API にロールベースのアクセス制御を追加する」という作業を例にします。これを丸ごと 1 つのタスクにすると、エージェントは 1 つのセッションの中で、ルーティング、ミドルウェア、データモデルのコードを読み、計画を立て、テストを書き、実装し、テストを実行することになります。小さなプロジェクトなら、それでも問題ないかもしれません。しかしプロジェクトが大きくなると、コードを読むだけでコンテキストの大半を使ってしまい、実装に取りかかる頃には、先に決めた制約がコンテキストから消えているおそれがあります。より確実なのは、先にテストを書き、その後で実装する 3 つのタスクに分けることです。

1. アクセス制御の計画を立てる： ルーティング、ミドルウェア、データモデルに関するコードを読み、どんなロールを設けるか、各エンドポイントがどの権限を要求するか、チェックをどの層に入れるか、権限がない場合に何を返すか、さらに、どのファイルを変更し、どうテストするかを決めて、docs/plans/access-control.md に書きます。
2. 計画に沿ってテストを書く： 計画に沿って権限チェックのテストを書いて実行し、アクセス制御がまだ実装されていないために失敗することを確認します。
3. アクセス制御を実装してテストを通す： 計画に沿って、ロールのデータモデル、権限チェック、各エンドポイントへの組み込みを実装します。すべてのテストを実行し、全部通るまで修正します。

こう分けると、計画タスクは好きなだけコードを読めます。どれだけ読んでも、使うのは自分のコンテキストだけだからです。テストを書くタスクと実装するタスクは、どちらも書き上がった計画から始めるので、コンテキストには本当に必要なものしか入りません。テストが先に書かれているため、実装タスクの完了条件もすでに決まっています。そのテストを通すことです。計画ファイルは、確認を挟むのにちょうどよい区切りにもなります。実装に入る前に計画を確認したい場合は、計画タスクに autoAccepted: none を設定し、完了後に止めてレビューを待たせます（自動承認を参照）。

粒度が適切かどうかは、2 つの方向から確かめられます。

• 大きすぎる兆候： 同じ作業を普段の対話型セッションで進めると、コンテキストが自動で圧縮されるところまで行くことが多い場合や、いくつもの事柄を「かつ」でつながなければ目標を言い切れない場合です。こうしたタスクは、後半になるほど当初の意図からずれやすくなるので、段階ごと、またはモジュールごとにさらに分けます。
• 小さすぎる兆候： いくつかのステップが密接に結び付いていて、あるステップの成果物が、次のステップに渡す途中段階のものにすぎず、何度か行き来しないと終わらない場合です。たとえば「エラーを 1 つ直す」という作業を、「原因を調査して分析レポートを書く」と「分析レポートに従って修正する」の 2 つのタスクに分けたとします。最初の調査が正しいとは限りません。修正後にテストを実行してまだ問題が残っていれば、もう一度調査して修正することになりますが、タスクを分けてしまうと、こうした反復ができません。調査で考えたことも、いったんレポートにまとめなければ渡せず、その過程で抜け落ちやすくなります。さらに下流は、上流が読んだコードを読み直すことになり、その分エージェントの利用量が余計にかかります。増えたタスクの分、CodeDAG クレジットも 1 クレジット多く消費します（ワークフローのコストを見積もるを参照）。こうしたステップは、1 つのタスクにまとめるほうが適しています。

各タスクの作業量は、おおむね揃えておくのが理想です。ほかより明らかに大きいタスクがあれば、たいていそれが、最も分ける価値のあるタスクです。並列に進む経路の中にあると、そのタスクを待つ下流を最も長く待たせることにもなります。

依存関係を組む：実際に必要な順序だけを表す

依存関係には、実際に存在する前後関係だけを書きます。あるタスクが別のタスクの成果物を使うなら、そのタスクに依存させます。使わないなら、つなげないでください。複数の経路の結果を合わせてまとめたり検証したりする必要があるときは、そのすべてに依存する合流タスクを追加します。

依存関係は、下流から何が見えるかを決めます。デフォルトの分離ブランチモードでは、依存関係を宣言していないタスクの変更は、そのタスクがすでに完了していても見えません（CodeDAG における依存関係とはを参照）。逆に、互いに関係のないタスクをつなげても、結果が良くなるわけではなく、後ろのタスクを無駄に待たせるだけです。

依存関係のよくある形は 3 つあります。

直列： どのステップも前のステップの結果を使います。先ほど分けた、計画、テスト作成、実装がその例です。

flowchart LR  t1["タスク 1<br/>アクセス制御の計画を立てる"] --> t2["タスク 2<br/>計画に沿ってテストを書く"]  t2 --> t3["タスク 3<br/>アクセス制御を実装して<br/>テストを通す"]

ファンアウト・ファンイン： 互いに関係のない複数の作業を同時に進め、最後に 1 つのタスクが結果をまとめます。たとえば、同じ変更をセキュリティ、パフォーマンス、可読性の 3 つの観点からそれぞれレビューし、1 つの問題点の一覧に集約します。

flowchart LR  t1["タスク 1<br/>セキュリティレビュー"] --> t4["タスク 4<br/>問題点の一覧をまとめる"]  t2["タスク 2<br/>パフォーマンスレビュー"] --> t4  t3["タスク 3<br/>可読性レビュー"] --> t4

ダイヤモンド： 並列に進む複数のタスクが同じ成果物を前提にし、最後に合流して検証します。アクセス制御の例も、この形に組めます。計画が書き上がった後、1 つのタスクが計画に沿ってテストを書き、別のタスクが計画に沿って実装します。この 2 つは同時に進み、最後のタスクがテストを実行して、全部通るまで修正します。

flowchart LR  t1["タスク 1<br/>アクセス制御の計画を立てる"] --> t2["タスク 2<br/>計画に沿ってテストを書く"]  t1 --> t3["タスク 3<br/>計画に沿って実装する"]  t2 --> t4["タスク 4<br/>テストを実行して修正"]  t3 --> t4

ブランチをマージするためだけのタスクを用意する必要はありません。タスクが複数の上流に依存している場合、CodeDAG はまず各上流の結果をそのタスクのブランチに自動でマージします。コンフリクトが起きた場合も、まず自動でエージェントに解決を任せます（合流ノードでのマージとコンフリクトを参照）。タスク自身の作業が始まるのは、その後です。複数の経路を合流させるタスクがない場合でも、各経路の結果は、ワークフローの終了時に統合ブランチにマージされます。そのため合流タスクは、実際の作業があるときにだけ追加します。まとめ、比較、テストの実行のように、複数の経路の結果を同時に使わなければできない作業です。

図の上では並列になっているタスクも、実際に同時に実行されるとは限りません。分離ブランチモードでは、同時に実行されるタスクの数が、利用できるワークスペースの数を超えることはありません。プライマリリポジトリしかない場合は順番に実行され、結果は同じですが、時間は余計にかかります。ワークスペースを増やす方法は、並列実行とワークスペースを参照してください。並列に進む経路が同じファイルを変更した場合に何が起きるかは、並列に実行される 2 つのタスクが同じファイルを変更した場合はどうなりますかを参照してください。

プロンプトを書く：新しいセッションが単独でやり遂げられるようにする

タスクのプロンプトの書き方は、時間のかかる作業を普段エージェントに任せ、単独でやり遂げさせるときと変わりません。普段どおりの書き方、普段どおりの言語で書いてください。CodeDAG には、プロンプトの形式についての決まりはありません。気をつけたいのは、タスクのセッションが普段の対話型セッションと異なる、次の点です。

• ゼロから始まる。 タスクエージェントが知っているのは、プロンプトと、自分でリポジトリから読んだファイルだけです。ユーザーがほかの人と交わした議論も、ワークフロー内のほかのタスクも見えません。なぜこの作業をするのか、上流タスクが結果をどこに書いたのか、別のタスクが同時に別の部分を進めているのかどうかは、プロンプトに書かなければ伝わりません。
• エージェントが作業を終えれば、タスクは完了になる。 CodeDAG は、エージェントが作業を終えたことをもってタスクの完了と判断し、結果が基準を満たしているかどうかは確認しません。どこまでやれば完了なのかは、具体的に書いておく価値があります。「少し最適化する」ではなく、「プロジェクトのすべてのテストを実行し、すべて通す」のように、検証できる結果として書くのが理想です。
• 質問しても、答える人がいないことがある。 無人実行では、エージェントが止まって人を待つと、タスクはそこで止まったままになります。探しているものが見つからないなど、起こりうると予想できる事態については、あらかじめ対処の道筋を示しておくのが確実です。代替策を明記するか、適切と考える方法で自分で対処してよいと伝えておきます。ある状況で複数の要件が互いに矛盾する場合も、エージェントは止まります。どんな状況でも制約を同時に満たせるようにするを参照してください。
• エージェントが読むのは、手元にあるファイルと同じとは限らない。 デフォルトの分離ブランチモードでは、タスクが読めるのは自分のタスクブランチにある内容だけで、このブランチにない変更は、デフォルトでは読めません。必読資料をタスクが読めるようにするを参照してください。

参考にできる構成

この種のタスクのプロンプトを書き慣れていない場合は、次の 4 つの項目を出発点にできます。

目標：
何を実現するのかを、1〜2 文で書きます。無人実行のタスクでは、「無人実行で……を実装してください」とそのまま書いてもかまいません。

コンテキストと必読資料：
- なぜこの目標を実現するのか、結果をどう使うつもりなのか。
- エージェントが読むとは限らないが、必ず読ませたい資料。上流タスクが書いたファイルなど、具体的な場所を書きます。

完了条件：
- 成果物：どんな変更を加えるのか、またはどのパスにどんな内容のファイルを書くのか。
- 完了の確認方法：どのコマンドを実行し、どんな結果になればよいのか。

制約：
- 変更してよい範囲と、触れてはいけない箇所。

目標の「無人実行で……を実装してください」という書き方は、タスクが無人実行になることがはっきりしていて、手動レビューも設定していない場合に適しています。質問できる相手がいないことを、エージェントに伝えられます。

「コンテキストと必読資料」には、目標だけからは得られない情報を補います。目標を実現する過程でどのみち読むことになる内容は、書く必要がありません。たとえば目標がログイン API のタイムアウトの修正であれば、「まずログイン関連のコードを読むこと」と書き添える必要はありません。

項目は、タスクに合わせて増やしたり減らしたりできます。書く内容のない項目は省き、4 つの項目に収まらない内容は、新しい項目にします。たとえば、次のようにします。

• 目標が複雑な場合： 目標の後ろに項目を追加し、1〜2 文に収まらない内容を詳しく書きます。項目の名前は、内容に合わせて付けます。
  • 詳細： 目標を理解する助けになる補足情報。たとえば 2 つ目のワークフローのタスク 1 のプロンプトでは、この項目で、「TODO」が何を指すのか、適切な TODO が見つからない場合に何で代えるのかを説明しています。
  • 要件： 目標とは別に、必ず満たすべき、または満たすことが望ましい要件。たとえばクイックスタートのタスク 1 のプロンプトでは、この項目で、どの会話履歴を読むか、最大でどれだけ読むかを限定しています。
• 出力形式に指定がある場合： ファイルをどの節に分けるかを決めるだけのような簡単な指定であれば、完了条件に書けば足ります。複雑な指定は、「出力形式」という項目を別に設けてもかまいません。
• 作業の手順に明確な指定がある場合： 制約の後ろに手順の項目を追加し、ステップを順番に書きます。たとえば不具合を修正するときに、まず問題を再現し、次にその問題を捉えて失敗するテストを書き、それから修正して、最後にすべてのテストを実行する、といった手順です。推奨にとどまる場合は「推奨手順」、必ず従わせる場合は「必須手順」と名付けます。
• 見落とされやすい点がある場合： ここまでの項目で触れておらず、エージェントが気づくとは限らず、見落とすと結果に明らかな影響が出ると予想される点は、「注意事項」という項目にまとめて書けます。たとえば、あるディレクトリのファイルは自動生成されるため、直接変更しても上書きされる、といった点です。

次は、2 つ目のワークフローのチュートリアルにあるタスク 2 のプロンプトです。上流のタスク 1 が 2 つの TODO の計画をすでにファイルに書いており、タスク 2 がそのうちの 1 つ目を実装します。同時に、タスク 3 が別のワークスペースで 2 つ目を実装します。

目標：
docs/plans/two-small-changes.md の「1 つ目」に書かれている TODO を実装してください。

コンテキストと必読資料：
- docs/plans/two-small-changes.md は、前のタスクが書いた計画です。「1 つ目」の節に、目標、対象ファイル、完了条件が書かれています。

完了条件：
- 「1 つ目」に書かれている完了条件を満たすこと。まず最小限のテストを書き、そのテストが通るまで実装します。

制約：
- 変更するのは、「1 つ目」に挙げられているファイルだけにしてください。計画ファイルは変更せず、「2 つ目」の内容も実装しないでください。

注意事項：
- 別のセッションが、別のブランチで「2 つ目」を同時に実装しています。その変更は、あなたからは見えません。両方の結果は、後で CodeDAG がマージします。

目標では、TODO の内容を繰り返さず、計画ファイルの節を指し示しています。具体的に何をするかは上流タスクが決めるため、それに合わせてプロンプトを書き直す必要がありません。注意事項には、エージェントが自分では気づけないこと、つまり、もう一方の TODO を別のセッションが同時に実装していることを書いています。

どんな状況でも制約を同時に満たせるようにする

プロンプトを書き終えたら、その中の各要件が、どんな状況でも制約と同時に満たせるかどうかを、もう一度確認しておくとよいでしょう。タスクエージェントは、互いに矛盾する要件に行き当たると、どうすべきかを人に尋ねて止まることがよくあります。無人実行では答える人がいないため、タスクはそこで止まったままになります。対処方法は、エージェントが許可または回答を待っているを参照してください。

最も見落としやすいのは、再実行の場合です。たとえば、完了条件が「計画を docs/plans/two-small-changes.md に書く」ことを求め、制約に「既存のファイルは一切変更しない」と書かれているとします。初回の実行では問題ありません。しかし再実行のときには、このファイルがすでに存在するため、2 つの要件が衝突します。完了条件に「ファイルがすでにある場合は、そのまま上書きする」と書き足し、制約を「この計画以外のファイルは、新しく作ることも変更することもしない」に変えれば、どちらの場合にも対応できます。古いファイルを上書きせず、毎回の結果を残しておきたい場合は、あらかじめ決めたファイルに書くを参照してください。

必読資料をタスクが読めるようにする

プロンプトで読むよう指定した資料は、タスクが実際に読める状態にしておく必要があります。デフォルトの分離ブランチモードでは、タスクが読むのは自分のタスクブランチにある内容です。つまり、今回のワークフローのベースコミットに、承認済みの上流の結果を加えたものです（タスクエージェントに見えるものを参照）。このブランチにない変更は、デフォルトでは読めません。ワークフローの開始後にユーザーが手元で続けた変更も、そのタスクが依存していないほかのタスクの変更も同じです。そのため必読資料は、ワークフローの開始前にコミットしておくか、上流タスクに作らせるかのどちらかにします。書いたばかりの要件ドキュメントは、まず git commit で現在のブランチにコミットし、それからワークフローを投入してください。

結論を下流に渡す

上流はあらかじめ決めたファイルに結論を書き、下流のプロンプトでは、そのファイルを読むよう明記します。タスク同士が共有できるのはリポジトリ内のファイルだけで、依存関係が保証するのは、下流の開始時に上流のファイルが揃っていることだけです（依存関係を参照）。どのファイルのどの部分を読むかは、下流のプロンプトで伝える必要があります。分析、調査、レビューのようにコードを変更しないタスクも例外ではありません。結論が会話の中にしか残っていなければ、下流には知る手段がありません。

あらかじめ決めたファイルに書く

上流のプロンプトの完了条件にファイルパスと内容の構成を明記し、下流のプロンプトの必読資料に同じパスを書きます。このパスが、2 つのタスクの間のインターフェースになります。アクセス制御の例では、計画タスクの完了条件に「計画を docs/plans/access-control.md に書き、『ロールと権限』『変更箇所』『テストの要点』の 3 つの節に分ける」と書きます。実装タスクの必読資料には、「docs/plans/access-control.md は前のタスクが書いた計画です。そのうち『ロールと権限』と『変更箇所』の 2 つの節に沿って実装してください」と書きます。節をあらかじめ決めておけば、下流は節の名前で参照でき、プロンプトで内容を繰り返す必要がなくなります。

こうしたファイルも、コードの変更と同じように、タスクの結果の一部として統合ブランチに入ります。メインブランチに入れたくない場合は、メインブランチにマージする前に削除してください。

同じワークフローを繰り返し実行すると、固定のパスに書いたファイルは、次の実行で上書きされます。共有ワークスペースモードでは CodeDAG がコミットを作らないため、上書きされた古い内容は、自分でコミットしていた場合にしか取り戻せません。毎回の結果を残しておく必要がある場合は、固定のパスの代わりに、ルールを取り決めておく方法があります。たとえばクイックスタートでは、上流タスクが実行のたびに連番のディレクトリを新しく作り、下流タスクは番号が最も大きいものを読みます。

複数のタスクが共有する背景情報を .codedag/context/ に置く

要件や規約のように、どのタスクの成果物でもないのに複数のタスクが読む必要のある資料は、プロジェクトリポジトリにコミットしてもよいですし、.codedag/context/ に置くこともできます。.codedag/ は、プロジェクトリポジトリから独立した Git リポジトリです。そのため、ここに置いたファイルはプロジェクトにコミットする必要がなく、プライマリリポジトリのワークスペースがクリーンでなくなることも、タスクの変更や統合ブランチに含まれることもありません。.codedag リポジトリと一緒に、チームで共有することもできます（チームで共有するを参照）。context/ ディレクトリは、自分で作る必要があります。CodeDAG がその内容をタスクに自動で渡すことはないので、読むファイルをプロンプトで指定する必要があることに変わりはありません。

.codedag/ があるのは、プライマリリポジトリだけです。レプリカで実行されるタスクのワークスペースには、.codedag/ がありません。そのため、プロジェクトにレプリカを登録している場合は、レプリカからプライマリリポジトリをたどれるパスをプロンプトに書く必要があります。レプリカとプライマリリポジトリが同じディレクトリの下に並んでいる場合は、レプリカから見たプライマリリポジトリの相対パスを書けば足ります。たとえば ../my-app/.codedag/context/access-control-spec.md です。このパスはプライマリリポジトリの中からでも有効なので、タスクがどのワークスペースに割り当てられても読めます。プライマリリポジトリに対するレプリカの位置がそれぞれ違う場合は、代わりに絶対パスを書きます。たとえば /Users/you/my-app/.codedag/context/access-control-spec.md です。どちらの書き方も手元のマシンのディレクトリ構成に依存し、絶対パスはさらに、リポジトリの置き場所にも依存します。ワークフローをチームで共有する場合は、共有するワークフローをどのコンピューターでも実行できるようにするを参照してください。

下流に上流の変更を直接確認させる

上流の成果物がコードそのものである場合、下流は Git を使って何が変更されたかを確認できるので、説明を別に書く必要はありません。分離ブランチモードでは、承認された上流の結果が、コミットとして下流のブランチにマージされます。下流のプロンプトには、何と比較するかを書くだけで足ります。たとえばレビュータスクには、「git diff main...HEAD を実行し、今回のワークフローの開始以降のすべての変更をレビューしてください」と書きます。特定のファイルだけを見たい場合は、コマンドの末尾に -- <ファイルパス> を付けます。今回のワークフローが main から始まっていない場合は、コマンドの main を、ベースのあるブランチに置き換えてください。共有ワークスペースモードでは CodeDAG がコミットを作らないため、git diff で見えるのは、すべてのタスクの未コミットの変更が混ざったものです。どの部分がどのタスクによるものかは区別できません。

既存のスキルとルールを再利用する

タスクのセッションは、リポジトリのワークスペースで起動される、通常の Claude Code または Codex のセッションです。CLAUDE.md、AGENTS.md、エージェントに設定したルール、インストールしたスキルは、いずれも普段どおり有効なので、プロンプトに書き写す必要はありません。あるタスクで特定のスキルを使わせたい場合は、「今回のレビューには〇〇スキルを使ってください」のように、プロンプトでスキル名を指定します。

Claude Code の hooks は、タスクのセッションでも同じように発火します。たとえば、Stop hook を使って、終了前に必ずテストを最後まで実行させている場合、タスクの中でもそのとおりに動作します。CodeDAG は、Claude Code が本当に停止するのを待ってから、タスクを完了と判断します。

よくある質問

プロンプトに cdg コマンドを書くとどうなりますか

タスクエージェントはそのとおりに実行し、コマンドは実際のキューに作用します。タスクのセッションは、手元のターミナルと同じように cdg を実行でき、CodeDAG Guide プラグインが入っていれば、使い方も知っています。タスクの中から投入されたワークフローは同じプロジェクトのキューに入り、現在のワークフローが終了してから開始されます。開始時には、通常どおりタスク数の分のクレジットが消費されます。レビュー、一時停止、強制停止などのコマンドは実行中のワークフローに作用するため、そのタスク自身まで止めてしまうおそれがあります。

そもそも、ワークフローを進めるのにタスクエージェントが関わる必要はありません。次のタスクがいつ始まるかは依存関係が決め、結果を通すかどうかはレビューゲートが決めます。投入、レビュー、介入は、オーケストレーターがワークフローの外から行います（誰が何を担当するかを参照）。プロンプトには、そのタスク自身の作業だけを書きます。あるタスクの後で止めて確認したい場合は、プロンプトに「完了したら私の確認を待ってください」と書くのではなく、そのタスクに autoAccepted: none を設定します。

オーケストレーションエージェントへの要望は、そのままタスクのプロンプトに書くべきですか

そのまま書き写してはいけません。オーケストレーションエージェントへの要望の多くは、ワークフローをどう組み立てるかについてのものです。こうした要望は、特定のタスクのプロンプトに書くのではなく、タスクの分け方とフィールドに反映させます。たとえば「実装が終わったら、別のモデルにレビューさせる」という要望は、実装タスクに依存し、もう一方のエージェントが実行するレビュータスクにします。「どのステップも、私が確認してから先へ進める」という要望は、ワークフローの taskAutoAccepted: none にします。こうした文をタスクのプロンプトに書き写しても、タスクエージェントはタスクを追加することも、レビューの設定を変えることもできません。文面から意図を推測するしかなく、自分で cdg を実行してしまうことさえあります（プロンプトに cdg コマンドを書くとどうなりますかを参照）。

プロンプトに書くのは、タスクエージェントが実際に行い、読み、守る必要のある内容だけです。CodeDAG Guide も、オーケストレーションエージェントにこの区別を求めています。オーケストレーションエージェントが書いたワークフローを確認するときは、こうした要望がそのままプロンプトに紛れ込んでいないかも、あわせて見ておくとよいでしょう。

上流が結論を会話の中にしか残さなかった場合はどうすればよいですか

上流がまだ承認されていないうちに、元のセッションに結論をファイルへ書かせます。autoAccepted: none を設定していた場合や、分離ブランチモードで変更を何も残さなかったタスクである場合など、上流がレビューゲートで止まっているときは、request-changes で元のセッションに依頼します。

cdg task review request-changes 1 -w access-control -m "結論を docs/plans/access-control.md に書き、ロールと権限、変更箇所、テストの要点の 3 つの節に分けてください"

元のセッションには、そのときの会話が残っています。ファイルを書き終えると、タスクはレビューゲートに戻ります。内容を確認して承認すると、下流が開始されます。方法は今の結果をもとに修正を続けさせる：request-changes を参照してください。

上流がすでに承認されている場合、下流はこの結論がないまま開始されており、今回の実行の中では取り返しがつきません（レビューの結論は変更できないを参照）。共有ワークスペースモードのタスクは、何も書かなくても自動承認されるため、こうした状況がいっそう起こりやすくなります。この場合は、cdg task logs <タスク ID> -w <ワークフロー> で上流が会話の中で返した回答を読み、必要な結論をファイルにまとめたうえで、影響を受けた作業を新しいワークフローに入れて続きを進めます。承認済みの結果に問題があるを参照してください。

並列に実行される 2 つのタスクが同じファイルを変更した場合はどうなりますか

ほとんどの場合、特別な対処は必要ありません。2 つのタスクが変更するのは同じファイルの別々の箇所で、変更は 1 つにまとまります。問題になるのは一部の場合だけで、それがどんな場合かは実行モードによって異なります。

• 分離ブランチモード： 2 つのタスクはそれぞれ自分のブランチで変更するため、実行中に影響し合うことはありません。両者の結果は、合流タスクの開始前、または統合ブランチにマージされるときに合わされます。変更箇所が別々であれば自動でマージされ、同じ箇所を変更した場合にだけコンフリクトになります。コンフリクトが発生すると、CodeDAG はまず自動でエージェントに解決を任せ、3 回試みても解決しなかった場合にだけ、on-hold で止まって対処を待ちます。合流ノードでのマージとコンフリクトとトラブルシューティングのマージコンフリクトを参照してください。
• 共有ワークスペースモード： 2 つのタスクが、同じディレクトリにある同じファイルを直接変更します。エージェントが一度に変更するのは、通常、ファイルのごく一部です。両者の変更箇所が別々であれば、変更はそのまま積み重なります。たまたま同じ箇所を変更しようとした場合は、後から変更する側の編集が、置き換えようとした元のテキストがすでに変わっているために失敗します。その側は、ファイルを読み直してから、もう一度編集します。実際に影響し合うのは、別の場合です。一方のタスクがコードを変更している途中で、もう一方のタスクがコンパイルやテストの実行を始めると、書きかけのコードがその結果に影響します。CodeDAG はこれを検出せず、警告も出しません。

2 つのタスクが同じ箇所を大きく変更すると見込まれる場合は、タスクを分ける段階で避けられます。まず、それぞれの制約に、変更してよいファイルを明記します。どうしても同じ箇所を変更する必要があるなら、一方のタスクをもう一方に依存させ、順番に実行させます。1 つの結果にまとめる必要がある場合は、それぞれに別のファイルを書かせ、合流タスクに内容をまとめさせます。コードの変更とテストの実行を同時に行う複数のタスクには、デフォルトの分離ブランチモードのほうが適しています。実行モードを参照してください。

関連ページ

• タスクとセッション：どのタスクも新しいセッションになる理由と、依存関係が上流の結果を下流に届ける仕組み。
• ワークフローファイルを書く：分けたタスクとプロンプトをワークフローファイルに書き、投入前に検証します。