Skip to content
← すべての章

章 05

リポジトリのアーキタイプ

エージェントが一行のコードも変更する前に、それ以降のすべてを形作る一つの決定を下します。このリポジトリはどの種類か？　推測されたアーキタイプが、取り組み全体を通じてエージェントが推論する境界を定めます。どうオンボーディングするか、計画がどこまで及ぶか、そして状態がどこに置かれるか、です。判断を誤ると、エージェントは誤った対象範囲に作業をスコープします。これは長期的なタスクにおけるドリフトの最も一般的な原因です。正しく判断できれば、計画・オンボーディング・状態がすべてコードの実際の形に合致するため、何時間も自律的に動き続けられます。

DWP は二つのアーキタイプを認識します。ほとんどのリポジトリは最初のアーキタイプです。二つ目は、多数のリポジトリを調整するチームのために存在します。

個別リポジトリ

一般的なケース：自己完結したコードベース、すなわちアプリケーション、ライブラリ、サービスです。推論すべき一つの一貫した対象があるため、計画はリポジトリ内のコードに直接作用し、オンボーディングはリポジトリ自身の構造と規約を読みます。エージェントはコードベース全体をコンテキストとして保持し、端から端まで処理します。

特徴：

  • 単一の一貫したコードベース。
  • 計画はこのリポジトリ内のファイルを変更する。
  • .dwp/ 作業領域はリポジトリのルートに存在する。

オーケストレーターハブ

調整のケース：他のリポジトリを管理することを職務とするリポジトリです。ここでの作業単位はファイルではなく子リポジトリであるため、計画はサブリポジトリの中に子計画を生成することがあり、オンボーディングは単一のコードベースではなく、ハブが管理するリポジトリのレジストリを読みます。エージェントは境界と引き継ぎについて推論します。どのリポジトリがどの作業を担うか、そしてそれらの状態をどう一貫させるか、です。

特徴：

  • 複数のサブリポジトリを調整する。
  • 計画は子計画へ委譲することがある。
  • 管理対象リポジトリのレジストリを維持する。
  • ハブのルートにある .dwp/ 作業領域がリポジトリ横断の状態を追跡する。

分類のヒューリスティック

二つのアーキタイプはディスク上での見た目が異なり、エージェントは告げられたラベルではなく、自分で検証できる手がかりをもとに判断します。以下のデシジョンツリーがその道筋を示します。簡潔に言えば、証拠がそれを求める場合にのみリポジトリをオーケストレーターハブとして扱い、そうでなければ個別リポジトリとして扱ってください。

エージェントは、複数の入れ子になった git リポジトリやサブモジュール、管理対象リポジトリのレジストリやマニフェスト、あるいは外部リポジトリを指す設定を見つけたとき、リポジトリをオーケストレーターハブとして分類すべきです。そうした手がかりがなければ、リポジトリを個別リポジトリとして扱います。これが安全なデフォルトです。存在しない境界をまたいで計画を過剰にスコープすることは、実在する境界の内側で作業するよりも悪い結果をもたらすからです。

オンボーディングはどう異なるか

アーキタイプは装飾的なラベルではありません。エージェントが読むもの、計画が触れられるもの、そして状態が記録される場所を変えます。

観点 個別 オーケストレーター
スコープ このリポジトリ 複数のリポジトリ
オンボーディング リポジトリの構造 ハブのレジストリ
計画の対象 ローカルのファイル 子計画
状態 ローカルの .dwp/ リポジトリ横断の .dwp/

実際の効果として、個別リポジトリのエージェントは一つのコードベースを端から端まで推論し、オーケストレーターのエージェントは調整について推論します。どの子リポジトリがどの作業を担うか、そしてリポジトリ横断の状態をどう一貫させるか、です。

アーキタイプを最初に固定することこそが、エージェントが監督なしに何時間も自律的に働けるようにします。計画、オンボーディング、状態を適切な境界に合わせて定めることで、エージェントは最初のタスクから最後まで、正しい対象範囲で動きます。