Foremerge - 並列コーディングエージェントの意図衝突を事前検知
Show HN: Foremerge – Catch Intent Conflicts Between Parallel Coding Agents
Foremergeは、複数のAIコーディングエージェントが同じプロジェクトで並行作業する際に、コードが衝突する前に「意図の衝突」を検出するオープンソースの調整プロトコルです。Gitの上に構築され、各エージェントが編集前に変更対象を宣言し、共有データベースで他のエージェントの計画を確認。例えば、一方がPaymentServiceをStripePaymentServiceに置き換え、他方がPayPalサポートを追加しようとすると、ファイルが重ならなくても依存関係の衝突をHIGH警告として通知します。ファイルロックやモデル判定に頼らず、決定論的でアドバイザリな警告を提供。CLI、JSON API、MCPサーバーを備え、Claude Code、Codex、Cursorなどと連携可能。ローカルファーストのMVPで、Rust製。
Gitはテキストを比較するが意図は比較しない。Foremergeは、エージェントがコードを書く前に計画を共有し、衝突を事前に知らせる。
HNでの議論
15- adityamishra241
これは面白い。検出された衝突が実際にエージェントを止める価値があるかどうかをどうやって判断するのですか？重複する変更の一部はまったく問題ない場合もあると思います。
- naw103
私がよく受ける質問をいくつか挙げます：
エージェントはそれをどう使うのか？
エージェントは、変更しようとしている内容の意図とスコープを（開始時と、異なる変更を行う直前）に公開します。Foremergeは、異なるworktree（異なるブランチや同じworktreeでも）ですでに進行中の関連作業と、それに取り組んでいるエージェント/人間のシグナルを返します。エージェントはその後、コードを書いたり競合を生成したりする前に解決策について交渉でき、Foremergeはコミット前に（人間が定義した）受け入れチェックを実行します。
なぜロックではなくアドバイザリな主張なのか？
リポジトリが忙しくなると、ロックはキューとデッドロックに変わります。エージェントが理由を確認できないロックは最悪のシナリオなので、ハードゲートは開始時ではなく受け入れ時になります。
ギャップは何か？
最終的にForemergeは決定論的（判定モデルを使用しない）なので、いくつかの偽陽性と偽陰性を検出する可能性がありますが、それはごくまれで、最悪の場合でもForemergeがなければ見逃されていたでしょう。また、受け入れは現在デフォルトで実際のdiffを比較せず、プッシュ通知もないため、以前のエージェントは次のステータスチェックで初めて競合を知ります（どちらも次のバージョンのロードマップにあります）。
さらに多くの質問と回答はこちら：https://foremerge.com/blog/31-questions-coordinating-paralle...
- ttoinou
この問題に対する皆さんのカスタムソリューションは何か知りたいです。AI以前とAI以降で。
エージェントAIコーディング以前から、私にとってはすでに問題でした：複数の開発者が重複するコードに取り組むことができ、常に誰かがすべてを適切にマージする必要があります。重複がごく小さくても、開発に負担がかかります。その人がAIを使って競合を解決するなら95%のケースではもはや問題ではありませんが、今や「他の開発者」がAIエージェントの群れであるため、この問題は簡単には解決できません。