レーン

サンパウロのある決済チームのエンジニア 2 人は、同じリポジトリ上で同じ Claude Code セッションを 40 分間走らせ続け、どちらも気付きませんでした。違うブランチ、違うターミナル、同じビルディングの違うフロアにいたのです。気付いて辻褄を合わせる頃には、エージェントのコミット 3 つが上書きされ、新しい 2 つは互いに矛盾し、オンコールエンジニアが flaky test に呼び出されていました — そのテストは flaky ではなく、どちらも概要を伝えていないモデルに書き換えられていたのです。

その種の衝突を防ぐために レーン は存在します。このページから一つだけ覚えるなら、レーンはフェンスです。レーンはワークスペース、エージェント、チームメイトに対し、この作業 が このスコープ で このパーミッション と共に、このラン がクローズするまで所有されると伝えます。2 つのレーンが同じファイルに重なることはありません。2 つのエージェントが同じレーンの中で動くこともありません。

主張: エージェント駆動エンジニアリングのカオスのほとんどはモデル品質ではなく、「これは私のものだから触らないで」と言うプリミティブの欠如です。レーンがそのプリミティブです。

レーンの実体

ストレージで言えば、レーンは lanes テーブルの行で、UUID、オーナー（人間またはエージェントの identity）、claim したパスのリスト、プロベナンス台帳への署名済み開始エントリ、そしてステータス — open、paused、merged、abandoned — を持ちます。普通は行のことは考えません。考えるのは Lanes パネルの カード: タイトル、スコープ、ライブ diff、下部の sign-off スロットです。

ランタイムで言えば、レーンは強制の境界です。レーン A の内部のエージェントが A の claim 済みスコープ外のファイルを read または write しようとすると、ワークスペースは file system が触られる前に LANE_SCOPE_DENIED エラーを返します。エージェントは tool log にエラーを見て、作業を狭めるかレーンオーナーに claim 拡張を頼みます。

監査で言えば、レーンはプロベナンス台帳上の自己完結した章です。レーン内のすべての read、write、モデル呼び出し、コマンド実行、sign-off は、レーンの開始エントリにチェーンします。SOC 2 や内部の post-mortem のエビデンスをエクスポートするとき、エクスポートするのは レーン であって、コミットではありません。

ブランチで足りないわけ

明らかな反論: 「git ブランチがすでにある。なぜレーンが必要なのか？」

ブランチは main からどのファイルが違うか に答えます。誰が作業しているか、どのツールを使っているか、過去 1 時間で同じパスを他の誰かが触ったか、この作業の中からエージェントは本番 DB を呼んでよいか には答えません。ブランチはスナップショットのプリミティブ。レーンはセッションのプリミティブです。

実際の運用では 1:1 の対応になることが多いでしょう — 1 つのレーンが 1 つのブランチを作り、1 つの PR にマージされる。しかしレーンはブランチより長生きします。レーンは、ブランチが削除された後もモデルログ、ツールコール、sign-off、プロベナンスを抱えます。6 か月後にはブランチは消えていますが、レーンはまだ照会可能です。

暗号学的プロベナンス

各レーンは署名済みエントリのチェーンを持ちます — BLAKE3 コンテンツハッシュへの Ed25519 署名を、追記専用の順序で。チェーンヘッドが前のヘッドに署名するため、過去のエントリを改ざんすると、それ以降のすべてのエントリが無効になります。これは、フェデレーションルートのサイナーがワークスペースのエビデンスバンドルに使うのと同じ構造です。

3 つの鍵が重要です。

鍵	保管場所	用途
Lane signing key	ワークスペース HSM	レーン内の tool-call エントリへの署名
Owner attestation key	ユーザーデバイス	レーンをクローズする sign-off エントリへの署名
Federation root key	ワークスペース所有者のみ	クローズ済みチェーンヘッドをエビデンスバンドルにスタンプ

通常のレーンでは、これらを手動で管理することはありません。外部 HSM（BYOK）を統合するとき、監査用エビデンスをエクスポートするとき、ワークスペース外からフェデレーションレシートを検証するときに登場します。

スコープクレームと衝突

スコープクレームは glob パターンのリストです: apps/api/auth/**、infra/terraform/networking/*.tf、package.json。2 つ目のレーンが open レーンと重なるパターンを claim しようとすると、ワークスペースは両方のレーンの UI に衝突を表示し、新しいレーンの開始を拒否します。新しいレーンのオーナーは既存オーナーの名前を見て、待つ、衝突パスのリリースを頼む、スコープを狭めるのいずれかを選べます。

知っておくべき 3 つの例外:

レーンは Share path で別のレーンと自発的にパスを共有できます。あまり使われません — 主に並行する 2 つの機能が両方触る共有設定ファイルのため。共有するとパスは直列化されたリソースになります。エージェントは単一の tool call の間ロックを取ります。
ワークスペースオーナーは停滞したレーンからパスを force-claim できます。これはオーバーライドを明示する sign-off エントリをログします。
README.md、CHANGELOG.md、.sprintloop/shared-paths にマッチする任意のパスは常に共有されます。すべてのレーンが追記できます。

レーンの作成

自動化の度合いが上がる順に 3 つの方法があります。

Lanes パネルから手動で。 New lane をクリック、1 行のタイトルを入力、リポジトリを選び、触る予定のパスを claim し、オーナーとして自分かエージェントを割り当てます。レーンは台帳にエントリがない Drafting 状態で開きます。
Issue から。 SprintLoop の Issue が In progress に移動すると、ワークスペースはリンクされたリポジトリに対し、Issue の受入基準を概要にプリロードしたレーンを立ち上げる提案をします。これはほとんどのチームが最初の週で落ち着くパスです。
エージェントハーネスから。 SprintLoop 内で動く Claude Code または Codex セッションは、最初のファイル read で自分のレーンを開きます。エージェントがオーナーで、セッションを開始した人間が sign-off authority です。レーンは最初のプロンプトから自動タイトル化され、最初のコミット後にリネームされます。

レーンのクローズ

レーンは、diff がマージされたとき、オーナーが明示的に放棄したとき、または 7 日間活動がなかったとき（ワークスペースごとに設定可能）にクローズします。クローズ時、レーンの台帳のチェーンヘッドはオーナーによって署名され、ワークスペースのフェデレーションルートにスタンプされます。ここで作業はアーカイブ的に証明可能になります — 公開検証キーを持つ誰でも、後でこの一連の変更が、この順序で、このオーナーにより、これらの tool call と共に、このコミットハッシュで終わったことを確認できます。

このあとさらに 1 ページ読むなら、Harness racing にしてください — 単一レーンが 2 つ以上のエージェントに並列でディスパッチされる仕組みです。