Loom：並列AIコーディング向けGit層

Loomはgit上に座る調整層で、具体的なワークフロー問題を解決するよう設計されている：複数のAIコーディングエージェント（Claude Codeセッションなど）が並列に同一リポジトリで作業する場合、互いの変更を上書きして競合をマージもしくはCI時にのみ発見し、その時点で修正は高額になるという問題である。

メカニズムはシンプルである。エージェントが作業を開始するとき、目標とファイルスコープ（例：「認証を新しいセッションモデルに移す」、スコープ`src/auth/**`）を指定して`loom lease`を呼び出す。Loomはエージェントに独自のgit worktreeを割り当て、作業ディレクトリを返す。2番目のエージェントのリースが1番目のスコープと重複する場合、Loomはその重複を即座に報告する（「つま先踏み」警告）。エージェントは例えば代わりに非交差スコープを宣言することで再交渉する機会を得る。両エージェントが進む場合でも、別のworktreeで作業するため、何も潰されない。1番目のエージェントが終了する場合、`loom stitch`（削除をtombstoneとして記録するチェックポイント操作）と`loom propose`（スクラッチコピーで検証して人間の同意を求める）を実行する。2番目のエージェントが提案するとき、Loomは共有メインラインが移動したかをチェック。移動していれば、提案は「fabric moved under you — rebase」というメッセージで拒否され、エージェントはスレッドをリベースして再提案する。重要な洞察：競合は両エージェントのトークン予算が消費された後ではなく、1つのツール呼び出しの処理コストで名前（どのファイルが移動したか）で表面化させる。

システムはClaude Codeおよび他のMCPクライアントと統合される。エージェントの典型的なフローは：`loom_status`（誰が何をしているか確認）、`loom_lease`（意図宣言）、返されたworktreeで編集、数編集ごとに`loom_stitch`（チェックポイント化とリース心拍）、`loom_propose`（検証と同意要求）、競合時は`loom_rebase`（worktreeで調整）と再提案。死んだスレッドは孤立としてマークされ、`loom adopt`経由で要求可能で、目標、基準、チェックポイント付きである。謎のブランチではなくスケジュール可能な作業である。

マルチマシン協業の場合、Loomは隠しgit ref（`refs/loom/*`）を通じて同期し、サーバーやデーモンは不要である。両ユーザーは`loom init --verify <test-cmd>`と`loom sync --remote origin`を実行し、シングルマシンの場合と全く同じに作業できる：リース、編集、stitch、提案、同期。編集はスレッドごとのworktreeと共有ラインに住み（「fabric」）、アドバンスは compare-and-swap ref pushのみを通じ、refが移動していると拒否される。本文は強調する：「あなたも相手も互いを上書きできない。編集がスレッドごとのworktreeに住み、共有ラインが ref の下で移動するとそれを拒否する compare-and-swap ref push のみで前に進むからである」。

Loomは3つの設定可能なgit履歴モードで出荷される：`squash`（デフォルト、完了目標ごとに1コミット）、`stitches`（スレッドごとのブランチのすべてのチェックポイントとマージコミット）、`both`（両方保存）。何も決してプッシュされない。ブリッジはローカル投影のみである。削除はファーストクラスであり、削除ファイルは削除として着地し、削除対編集競合は他の競合のように拒否される。8MiBを超える大きいファイルは、キャップが上げられるか`.loomignore`ファイルが使用されない限り、名前を付けて無視される。検証ゲートはスクラッチコピーで実行され、ハードタイムアウトを備え、赤色コードは決して着地しない。ツールは`cargo install --path .`経由で利用可能であり、既にテスト済みである（シングルマシン使用向けに45テスト出荷）。数人が共有リモートで作業するサポート付きで、多数ピアによるゴシッププロトコル上でのサポートは設計段階である。

Loomが解決する根本的な問題は、複数エージェントが共有コードベースで実行される直接的な結果である：Gitは競合をマージもしくはCI時にのみ報告し、その時点で両エージェントは潜在的に競合する作業にトークンを消費済みである。2つのエージェントが異なる意図で重複するファイルを同時に書き直す場合、着地する方が先の方の作業を無言のうちに消し、結果的なバグのデバッグはコンテキストなしで3番目のエージェントが行うことになる。早期検出で防げたであろう高額なトークン消費である。

Loomの設計はこのタイムラインを反転させる。エージェントに意図を事前宣言させることで（目標とファイルグロブを含むリース）、競合は編集が起こる前に知ることができる。システムは2番目のエージェントに即座に警告し、非重複スコープに自己分割するか明示的に続行するかを選ばせる。重要な点として、リースは警告であってブロックではない。唯一の強固なゲートは着地時である：worktreeによる分離は何も上書きされないことを保証し、同意ゲート（人間または承認キュー）は緑色のコードのみがメインブランチに到達することを保証する。本文はこれを高額な事後的調整から早期交渉と稀なリベースへの根本的シフトとして述べる。

システムはGitプリミティブ（worktree、ref、compare-and-swap ref push）の上に構築され、マルチマシン調整のための隠しrefを使用する同期メカニズムを備えて出荷される。デーモンや中央サーバーは不要である。トレードオフは明確である：Loomは儀式（リース、明示的調整）を追加するが、重要なところでのみ：高速エージェントのフロートもしくは人間がエージェント速で作業する場合である。本文は明示的に、2人の慎重な人間がゆっくり作業する場合、もしくはN個のエージェントが同一タスクを競う場合（ジャッジ／トーナメントハーネスが必要）には向いていないと述べている。

まだコメントがありません。最初のコメントを投稿しましょう！