多数のエージェントを動かす

一つの計画を一つのエージェントで進めるのが既定であり、ほとんどの作業はそれで足ります。しかし一つのセッションに収まらない作業もあります。複数のリポジトリにまたがる変更、順序どおりに出す必要のあるリリース、一つのエージェントでは何日もかかるバックログなどです。DWP は契約を変えずにこうした作業へ拡張できます。計画は引き続き信頼できる唯一の情報源であり、各タスクは引き続き自身のゲートで完了し、追加のエージェントはリード（lead）が調整するレーン（lane）になります。

この章ではそのモデルを説明します。三つのオプションのアドオンを使います。ペインとピアのための Herdr、アカウントのための agentkit、コンテナのための devcontainer です。単一エージェントの計画にはどれも必要ありません。

リードとそのレーン

リードは親計画を所有します。レーンを決め、各レーンにスコープを渡し、マイルストーンを集め、レーンにマージやリリースを許可する合図を出します。他のレーンのコードは書きません。

レーンは、一つのスコープ（通常は一つのリポジトリ）を担う一つのエージェントです。そのリポジトリの AGENTS.md を読み、そのリポジトリのゲートを実行し、自身の計画をリポジトリ内に保持します。オーケストレーターハブでは、親計画はハブの .dwp/plans/ に子の追跡表とともに置かれ、各レーンの計画はそれぞれのリポジトリに置かれ、そのリポジトリの計画 ID とゲートを使います。

レーンが動く場所

レーンはターミナルのペインで動くエージェントであり、ペインはいくつかの場所に置けます。Herdr は各エージェントをペインに収め、SSH で他のマシンにも届くため、リードはすべてのレーンを一つのサイドバーで見渡せます。

• ホスト上。レーンごとに一つのペインを、リードと並べて置きます。最も手早い構成で、開発者がすでに作業しているリポジトリに向いています。
• コンテナ内。devcontainer-kit のコンテナは dck up の時点で Herdr のメッシュに加わります。中のエージェントはホストや他のコンテナに届き、ホストからも届きます。コンテナそのものがサンドボックスなので、中のエージェントは自律モードで動かせます。
• 別のマシン上。Herdr が SSH で届く任意のマシンで、同じようにレーンを動かせます。そのマシンにも herdr-peers をインストールしておきます。

場所が変えるのは分離の度合いであり、プロトコルではありません。コンテナ内のレーンもホスト上のレーンも、同じ方法でリードと調整します。

余裕で選ぶアカウントとベンダー

多数のエージェントはクォータを速く消費します。各レーンは自分のアカウント、つまり coding-agents-kit の一つの CLI と一つのプロファイルで動きます。そのためレーン同士が同じウィンドウを使い切ることはなく、一つのアカウントが上限に達しても止まるのはそのレーンだけです。

• ak usage は、すべてのアカウントとプロファイルの残りクォータを表示します。バッチごとに一度実行します。
• ak pick <kind> --count N は、余裕の大きい順に N 個のアカウントを返します。--exclude は使用中のアカウントを除外し、--model は一つのモデルのウィンドウで数え、--need は余裕が足りなければ開始を拒みます。
• ak <kind> @<profile> は、そのアカウントでレーンのエージェントをそのペインに起動します。

ベンダーも同じように混在させられます。Claude のレーンが書き、Codex のレーンがレビューする、といった形で、それぞれ ak pick がその種類のために選んだアカウントを使います。コンテナ内のレーンはホストのアカウントを使えます。開発者の devcontainer-kit ホストプロファイルで host_profiles を有効にすると、コンテナはリポジトリがインストールする CLI のホストプロファイルを受け取ります。Claude はプロファイルごとの長期トークンで、Codex は認証ファイルで受け取るため、コンテナ内でのログインは不要です。使うのは自分のアカウントだけにし、各ベンダーの規約の範囲内に留めてください。作業はアカウントに分散させ、上限を回避するためにアカウントを切り替えることは決してしません。

人手なしでレーンを起動し、詰まりを解く

リードは、キーボードの前に誰もいなくてもレーンを起動し、動かし続けられます。開発者が無人運用を許可したら（継続的な指示か計画の事前承認）、起動のたびに改めて承認を得る必要はありません。リードが使うのは Herdr 自身のコマンドで、キットのコードがキー入力を送ることはありません。手順の順序は決まっています。一度だけ準備し、プロンプトを避け、停止を検知し、キー入力は一つの場合に限って送り、それ以外はエスカレーションします。

1. 一度だけ、開発者として準備する。Claude Code は、プロファイルごとに一度、権限バイパス（bypass-permissions）モードの確認を求めます。この確認は開発者自身の手順であり、プロファイルを作成するときに行います。devcontainer-kit のコンテナでは、キットがコンテナ自身の home にだけそれを書き込みます。どのエージェントも、この確認のためにキーを送ることは決してありません。
2. 避ける。ak pick <kind> が余裕の最も大きいアカウントを選び、herdr pane run <pane> 'ak <kind> @<profile> --trust-cwd' がレーン自身のフォルダでそれを起動します。--trust-cwd（または AGENTKIT_TRUST_CWD=1）がそのフォルダを事前に信頼するため、Claude と Codex はキー入力なしでフォルダ信頼の画面を通過します。
3. 検知する。herdr-peers lanes（または herdr agent list）は各レーンを作業中、アイドル、ブロック中、完了のいずれかで表示します。ブロック中のレーン、または出力のないままアイドルのレーンについては、herdr-peers status <pane> がそのレーンのいる画面（フォルダ信頼、権限バイパスの確認、ログイン、権限要求、不明）を分類して文書化された次の手順を示し、herdr pane read <pane> がその画面を表示します。
4. キー入力は一つの場合だけ。リードが送ってよいキーは、フォルダ信頼の画面への応答だけです。それも、自分で起動したペインで、--trust-cwd が使えなかった場合に限ります。キーを送る前に画面を読み、応答に必要な最小限のキーを送り、もう一度読みます。
5. それ以外はすべて読み、記録し、エスカレーションする。Claude の権限バイパスの確認、ログインや認証情報のプロンプト、操作ごとの権限要求、破壊的な確認、支払いやプランのプロンプト、未知の画面、リードが作成していないペインは、キー入力ではなくブロックのマイルストーンとして開発者に渡します。
6. オプトアウトが優先する。AGENTKIT_PERMISSIONS=ask が設定されていれば、レーンは行動の前に確認を求め、リードはオプトアウトがもたらすプロンプトを決して回避しません。
7. 再起動する。エージェントが終了したら、リードは同じアカウントで再起動するか、別のアカウントを選びます。ログインが失われた場合は認証情報のプロンプトとして扱い、エスカレーションします。

すべての介入（画面に何が表示され、どのキーを送り、その後どうなったか）は親計画に記録されます。

herdr-peers による調整

レーンとリードは herdr-peers を通じてやり取りします。ask はちょうど一つの reply を許可するスタンプを持ち、すべてのやり取りが記録されます。リードはプロトコルを小さく保ちます。

• マイルストーンは上へ。各レーンは決まった節目（計画の準備完了、プルリクエストの作成、ブロック、完了）で報告し、その間は返事を待たずに作業を続けます。
• 質問は ask で。判断が必要なレーンはリードに ask を送り、リードは一つの reply で答えます。
• 深さは一。reply に返信することはなく、レーンがさらに先へ委任することもありません。呼び出し元ごとのファンアウトには上限があり、既定では四つのピアです。
• 指示ではなくデータ。reply は、受け手がもともと持っていなかったものを何も与えません。ゲートを通過したというレーンの主張は、ゲートを実行して確認します。
• 誰が何をしたかの記録。すべての委任記録にはレーンのアカウントとベンダーが記されるため、親計画にはどのアカウントがどの作業を担ったかが残ります。
• Codex のレーンは自分のペインを指定します。 Codex は、そのアカウントの全セッションが共有するバックグラウンドサーバーからレーンのコマンドを実行するため、引き継いだペイン ID が別のレーンのものである場合があります。Codex のレーンは、リードの指示にある自分のペインを、すべての herdr-peers コマンド（ask, reply, notify, check, wait, lanes, cancel）で --pane <pane> として渡します。

リードはオーケストラ全体を一度に見渡せます。herdr-peers lanes はすべてのレーンを状態とともに一覧表示し、DeepWorkPlan Vim はオーケストレーター計画のレーンを計画そのものの隣に表示します（:DwpLanes）。

リポジトリごとに一つのブランチ、一つのリリース

多数のレーンをレビュー可能に保つ規則は単純です。リポジトリごとに一つのレーンを、そのベースのチェックアウトで動かし、変更全体で一つのブランチ、一つのプルリクエスト、一つのリリースとします。レーンは作業を複数のブランチや worktree に分けません。worktree を使うのは、二つの書き手が一つのリポジトリを共有しなければならない場合だけです。それぞれが自分の worktree を持ち、どのパスにも書き手が一人だけになるようにします。

プルリクエストは、リードの GO まで、開いたまま、チェックが通った状態で、レビュー用のラベルを付けておきます。GO が出たらレーンがマージしてタグを付け、そのタグを報告します。

リリース順序

リポジトリは互いに依存するため、依存の順にリリースします。まずツール、次にそれを固定するもの、次に結果を説明するドキュメント、最後にそれを採用する利用側です。リードが順序を握り、一度に一つのリポジトリへ GO を出します。他のリポジトリのリリースを固定するレーンは、そのタグが存在するまで固定の記述を待つため、存在しないリリースを指す固定は生まれません。

チェックポイント

親計画は報告ではなく証拠によって完了します。

1. レーンごと。各レーンのゲートが自身のブランチで通過し、プルリクエストのレビューに指摘が残っていないこと。レビューはそれ自体を一つのレーンにできます。AI Diff Reviewer が各レーンのプルリクエストをレビューし、Dailybot アドオンがあれば各レーンが自分の進捗をチームに報告します。
2. リリースごと。各タグが存在し、次のリポジトリが必要とするものを固定していること。
3. 統合。最後のリリースの後、チェックポイントがリリース済みのバージョンで利用側を動かし、その判定を親計画の analysis_results/ に記録すること。
4. 最終レビュー。親計画の完了前に、境界をまたいだもの、とりわけコンテナに共有したアカウント、トークン、ファイルをセキュリティの観点で確認すること。

安全

• ask、プロンプト、ログに鍵、トークン、シークレットを決して含めず、変数は名前で参照します。
• 共有リソースにはロックを使います。レーンはコンテナのビルドなど重い手順の前にロックを取り、終わったら解放します。
• 権限のオプトアウトが設定されていれば、すべてのレーンと、レーンが起動するすべてのエージェントに対して優先します。
• 続行できないレーンは、ブロックのマイルストーンとしてそれを伝えて停止し、判断はリードが行います。

アカウントやリードが尽きたとき

長い実行は、どのアカウントよりも長く続きます。coding-agents-kit (v0.7.1) と herdr-peers (v0.3.2) 以降、レーンはタスクの境目ごとに自分のキャパシティを確認し、アカウントが尽きる前にパケットを通じて作業を引き渡します。リードはリーダーシップを引き渡すか、代理に交代し、開発者に届くのはクリティカルな事項だけです。スウォームの自律性では、そのループ、パケット、継承、エスカレーションのクラスを説明しています。