開発者は、ステートファイルの書き換えや予期せぬファイルの競合を恐れることなく、複数のコーディングエージェント・セッションを同時に立ち上げることができるようになりました。アドバイザリ（助言型）の「シェア・ナッシング（共有なし）」パターンが、各エージェントのワークスペースを分離し、潜在的な競合を警告します。このアプローチでは、ハードロックの代わりに軽量なレジストリを採用することで、作業が重なる前にフラグを立て、セッションがクラッシュした場合でもパイプラインを停滞させずに継続させます。

なぜ並列エージェントは問題を引き起こすのか

単一のリポジトリで複数の自動コーディングアシスタントを実行することは、コード生成、テスト、またはリファクタリングを高速化します。しかし、実際にはすぐに2つの問題が発生します。

  • ステートの破損 – 2つのエージェントが同じステートファイルに書き込みを行い、後の書き込みが前の書き込みを上書きして、進捗が消えてしまう。
  • ファイルの衝突 – 2つのエージェントがお互いを認識せずに同じソースファイルを編集する。競合は、diffで変更内容の乖離が示されたときに後から判明する。

これらの問題はいずれも開発者の時間を浪費させ、追跡困難なバグを混入させる可能性があります。

「シェア・ナッシング」ルール

基本的な考え方はシンプルです。各エージェントにはディスク上に専用のプライベートなスクラッチパッドが割り当てられ、そのセッションに属するファイルにのみ書き込みを行います。ブランチごとに意図的に共有されるファイルは1つだけに制限され、「last-writer-wins（最後に書き込んだ者が勝つ）」ルールに従います。つまり、最後に書き込みを行ったエージェントが最終的な内容を決定します。

**プレゼンス・レイヤー（presence layer）**は、すべてのアクティブなセッションを追跡します：

  • ブランチ名
  • 操作対象のファイルリスト
  • 最終アクティビティのタイムスタンプ

新しいセッションが開始される際、レジストリを参照します。もし他のセッションがすでに同じファイルのいずれかを扱っている場合、作業が始まる前に開発者に警告が表示されます。

アドバイザリ vs ブロッキング・ロック

従来のロックファイルは行き止まりの道路のようなものです。一度ロックがかかると、他のプロセスはロックが解除されるまで待機します。もしロックを保持しているセッションがクラッシュすると、ロックがいつまでも残り続け、古いロックファイルをわざわざ手動で探して削除しなければならなくなります。

アドバイザリ・モデルはより柔軟です。潜在的な競合が検出されたときに警告を発しますが、新しいセッションを停止させることはありません。レジストリのエントリが古い（つまり、それを作成したプロセスがすでに存在しない）場合でも、システムは警告を出すにとどまり、続行するかどうかは開発者が判断します。

パターンの実装方法

  1. 書き手ごとにステートを分割する – 各エージェントに一時ファイルとステート用の専用ディレクトリを割り当てます。共有ファイルは真にグローバルなデータ用に確保し、「last-writer-wins」ルールはそこでのみ適用します。
  2. 起動時に認識を注入する – エージェントが開始する前に、プレゼンス・レジストリを読み取り、要求されたファイルリストと既存のエントリを比較します。重複が見つかった場合は、中断するか警告を出します。
  3. 読み取り時に生存確認を行う – レジストリのエントリを参照する際、記録されたプロセスIDがOS上でまだ実行されているかを確認します。終了したプロセスに属するエントリは破棄します。
  4. ブロッキングよりもアドバイザリを優先する – 開発者がコントロールを維持できるようにします。警告によって、開発者は続行、一時停止、またはキャンセルを選択でき、デッドロックを回避できます。
  5. 待機状態を追跡する – 多くのエージェントがアクティブになると、開発者の注意力がボトルネックになります。どのエージェントが人間の入力を待っているかを表示することで、作業の優先順位を再調整できるようにします。

これらすべては、単なるJSONファイルのディレクトリで構築可能です。外部のデータベースやメッセージバスは必要ありません。シンプルなストレージ形式により、システムの監査が容易になり、環境間でのポータビリティも確保されます。

リスクと反論

ハードロックの方が安全性を保証できると主張するチームもあるでしょう。つまり、2つのエージェントが同じファイルに書き込むことは決して起こりません。しかし、その代償として回復力（レジリエンス）が低下します。クラッシュしたセッションが孤立したロックを残し、ワークフロー全体を停滞させてしまうからです。

注意点

複数のAI駆動型コードアシスタントを使い分けている場合、「シェア・ナッシング」のアドバイザリ・パターンは、それらが互いの邪魔をしないようにするための実用的な道筋を提供します。ステートを分離し、意図を早期に明示し、続行の判断を人間に委ねることで、この手法は安全性と、現代の開発パイプラインが求める柔軟性のバランスを取っています。