チームで共有する

ワークフローファイルとプロジェクト設定は、どちらもプライマリリポジトリのルートにある .codedag/ に置かれます。これはプロジェクトのサイドカーリポジトリで、プロジェクトリポジトリから独立した Git リポジトリです。プロジェクトリポジトリをプッシュしても、一緒にプッシュされることはありません。そのため、自分が書いたワークフローをチームで使い回せるようにするには、.codedag を別のリモートリポジトリにプッシュする必要があります。共有されるのは、ワークフローファイルと共有設定だけです。各メンバーのキュー、ワークスペース、実行状態、ログは、それぞれのコンピューターにしかありません。ワークフローも、各メンバーが自分のアカウントで投入し、それぞれ実行します。

共有するものと、共有しないもの

.codedag/ の中のファイルは、local/ ディレクトリを除いて、すべてコミットして共有できます。local/ にあるのは、このコンピューターだけのものです。cdg init が生成する .codedag/.gitignore によって、すでにバージョン管理の対象から外されています。

.codedag をリモートにプッシュする

.codedag は通常の Git リポジトリなので、共有する方法はほかのリポジトリと同じです。コミットし、リモートを追加して、プッシュします。CodeDAG がこのリポジトリでコミット、プッシュ、プルをすることはなく、いつ同期するかは自分で決めます。

まず、チームで使っているコードホスティングサービスに、空のリポジトリを作ります。名前を <プロジェクト名>-codedag（たとえば my-app-codedag）にしておけば、どのプロジェクトと組になっているかがひと目でわかります。次に、プロジェクトのルートで以下のコマンドを実行します。.gitignore が local/ をすでに除外しているので、git add -A で追加されるのは、共有できるファイルだけです。

cd .codedag
git add -A
git commit -m "Share CodeDAG workflows and settings"
git remote add origin git@github.com:your-org/my-app-codedag.git
git branch -M main
git push -u origin main

それ以降は、ワークフローや共有設定を変更した人が .codedag でコミットしてプッシュし、ほかのメンバーがプルします。プルした新しいバージョンが影響するのは、そのあとに cdg dag submit で投入するワークフローだけです。すでにキューで待っているものや実行中のものは、投入した時点の定義のまま実行されます。

新しいメンバーのセットアップ

新しいメンバーは、まずチームの .codedag リポジトリをプロジェクトのルートにクローンし、それから cdg init を実行します。クローンしたファイルは、すべて .codedag リポジトリにコミット済みです。そのため、初期化ではこれらのファイルがそのまま残され、1 つずつ尋ねられることはありません。リポジトリのリモート URL とコミット履歴も、そのままです。このコンピューター用の設定は、別に local/ に生成されます。

始める前に、インストールとログインに従って CodeDAG をインストールし、アカウントにログインしておきます。チームのワークフローで指定されているエージェントも、インストールしておく必要があります。初期化のあとでインストールしたエージェントはそのまま使えるので、初期化し直す必要はありません。

git clone git@github.com:your-org/my-app.git
cd my-app
git clone git@github.com:your-org/my-app-codedag.git .codedag

cdg init

cdg dag validate review-changes

このリポジトリをすでに初期化している場合

以前にこのリポジトリで cdg init を実行したことがある場合は、.codedag がすでに存在するため、ステップ 1 のクローンは失敗します。先に、元の .codedag をプロジェクトリポジトリの外に移動します。たとえば mv .codedag ../my-app-codedag-old を実行します。それからチームのリポジトリをクローンし、ステップ 2 のとおりに初期化し直します。

初期化し直すと、ローカル設定が新しく生成されます。以前に手作業で変更していた箇所は、古いディレクトリの local/ にあるファイルと照らし合わせて、同じように変更し直してください。自分で書いたワークフローは、新しい .codedag/dags/ にコピーすれば、引き続き使えます。

共有設定に書くもの

レビューポリシーのように、チームで統一したいルールは、共有設定 .codedag/settings.jsonc に書きます。このコンピューターでのデフォルトのエージェントや同時実行数のように、あるメンバーだけチームと違う値にしたいものは、ローカル設定 .codedag/local/settings.local.jsonc に書きます。両方のファイルに同じフィールドを書いた場合は、ローカル設定が優先されます。

レビューポリシーの taskAutoAccepted と dagAutoAccepted は、個々のコンピューターには関係しないので、共有設定に書けば、すべてのメンバーのデフォルト値になります。defaultAgent と maxConcurrency は、共有設定に書くと、チームのデフォルト値になります。メンバーは、初期化のときに別のデフォルトのエージェントを選んだり、別の同時実行数の上限を決めたりしていなければ、チームの値をそのまま使い続けます。あとでチームが値を変更すれば、メンバーの側も一緒に変わります。availableAgents は、プロジェクトで使えるエージェントを制限したい場合にだけ書きます。たとえば、どのワークフローも、結果全体を人が確認して初めて終了とする、とチームで取り決める場合は、次のように書きます（レビューゲートを参照）。

{
  // すべてのタスクのレビューが終わると、ワークフローはワークフローレベルのレビューゲートで止まり、人が結論を出すのを待つ
  "dagAutoAccepted": "none"
}

共有設定はあくまでチームのデフォルト値で、強制されるものではありません。メンバーがローカル設定に同じ名前のフィールドを書いた場合、ワークフローファイルに対応するフィールドを書いた場合、投入時に --dag-auto-accepted オプションを付けた場合は、いずれも共有設定が上書きされます。優先順位の全体はデフォルト値と優先順位、各フィールドに指定できる値はプロジェクト設定を参照してください。

共有するワークフローをどのコンピューターでも実行できるようにする

同じワークフローファイルが、各メンバーのコンピューターでそれぞれ実行されます。ファイルの中で手元のコンピューターの状況に依存している書き方は、別のコンピューターではエラーになることがあります。最もよくあるのは、エージェントとパスの 2 つです。

共有するワークフローでは、すべてのタスクに agent を明記しておくことをおすすめします。mode を書いたタスクでは、なおさらです。書き方はエージェントを選ぶを参照してください。agent を書いていないタスクは、プロジェクトのデフォルトのエージェントに任されます。チームが共有設定に defaultAgent を書いていれば、それが各メンバーのデフォルト値になります。書いていなければ、デフォルトのエージェントは、各メンバーが初期化のときにそれぞれ選んだものです。そのため、自分の環境では Claude Code が実行するタスクを、ほかのメンバーの環境では Codex が実行することがあります。しかも、mode の書き方は 2 つのエージェントで異なります。たとえば mode: bypassPermissions は Claude Code の書き方で、デフォルトのエージェントが Codex のメンバーがこのワークフローを検証すると、Invalid codex mode 'bypassPermissions' と表示されます。

どのメンバーのタスクも読む必要がある資料は、ワークフローを始める前にプロジェクトリポジトリにコミットしておくのが最も確実です。こうしておけば、タスクはどのワークスペースで実行されても、相対パスで資料を読めます。プロンプトに書いた絶対パスは、自分のコンピューターでしか通用しません。この問題に最も当たりやすいのは、.codedag/context/ に置いた資料です。.codedag/ はプライマリリポジトリにしかないため、レプリカで実行されるタスクは、プライマリリポジトリを指すパスを使わないと資料を読めません。こうしたパスは、相対パスで書いても絶対パスで書いても、手元のコンピューターのディレクトリ構成に依存します（複数のタスクが共有する背景情報を参照）。

メンバーがそれぞれ実行する

キュー、ワークスペース、実行状態は、どれも各メンバーのコンピューターにしかありません。そのため、複数のメンバーが同じワークフローを同時に実行しても、互いに影響しません。メンバーの間で共有されるのは、ワークフローファイルと共有設定だけです。自分が投入したワークフローは、自分のキューにだけ並び、自分が登録したワークスペースでだけ実行され、ほかのメンバーのワークフローを待つことはありません。その状態、ログ、レビュー結果も自分のコンピューターにだけ保存され、ほかのメンバーからは見えません。

実行の結果も、同じようにローカルに残ります。CodeDAG はワークフローの名前をもとにブランチ名を付けるため、2 人が同じワークフローを実行すると、それぞれのリポジトリに同じ名前の cdg/<ワークフロー名>/ ブランチができます。ローカルでは互いに干渉しませんが、そのままチームのプロジェクトのリモートにプッシュすると、ほかのメンバーがプッシュした同じ名前のブランチとぶつかります。先に結果を自分のブランチにマージしてからプッシュすれば、名前は衝突しません。マージの方法は、メインブランチにマージするを参照してください。

CodeDAG クレジットは、アカウントごとに計算されます。ワークフローが消費するのは、それを投入したアカウントのクレジットです。各メンバーが自分のアカウントで投入すれば、それぞれ自分のクレジットを消費します。

関連ページ

• CodeDAG の仕組み：サイドカーリポジトリ：.codedag/ が独立した Git リポジトリになっている理由。
• プロジェクト設定：共有設定とローカル設定のすべてのフィールド、指定できる値、上書きのルール。
• CodeDAG Guide プラグインを管理する：チームメンバーの Claude Code と Codex が CodeDAG を使えるようにします。