人間もAIも同じリポジトリを同時にいじる — 衝突しないコーディングキャンバス「Murmell」

エージェントを1体だけ走らせているうちは、何も問題は起きない。壁にぶつかるのは、2体目を起動した瞬間だ。

片方が utils.ts を書き換えている最中に、もう片方が同じファイルに手を入れる。数分後、あなたのgitはコンフリクトマークだらけになっている。マルチエージェント開発を少しでも真面目にやった人なら、この光景に見覚えがあるはずだ。並列で速くなるどころか、衝突の後始末で時間が溶ける。

Murmell は、この「並列にすると壊れる」という問題を正面から解こうとしているツールだ。

何をするツールなのか

Murmell は、チームメンバーと複数のAIコーディングエージェントが、同じリポジトリの上で同時に作業できるクラウド上の共有キャンバスを提供する。ブラウザで開く1枚の作業場に、人間もエージェントも同居する。

今の時点で一緒に走らせられるのは Claude Code、Codex、Kimi、OpenCode の4種類。今後 OpenClaw や Hermes なども追加予定だという。どれも各社の実物のコーディングエージェントで、Murmellはそれらを束ねて同じ土俵に立たせる「場」の役割を担う。

実行はローカルではなくクラウドマシン上で行われる。だからノートPCを閉じても作業は止まらない。エージェントが夜通し動き、朝になって結果を見る、という使い方が前提に置かれている。そして書かれたコードは最終的にそのまま git に反映される。作業場はあくまで作業場で、成果物の置き場は普段どおりのリポジトリだ。

肝は「書く前に場所を取る」

Murmellの一番の工夫は、拍子抜けするほど素朴だ。エージェントは、ファイルに書き込む前にそのファイルを「クレーム（占有）」する。

誰かが auth.ts を占有している間、他のエージェントや人間はそのファイルに同時には書き込めない。つまり、後から衝突を検出して直すのではなく、そもそも衝突が起きない状態を先に作る。データベースの排他ロックを、コーディングエージェントの世界に持ち込んだと考えると分かりやすい。

一見あたりまえに聞こえるが、これが効くのはマルチエージェントの失敗の大半が「同じ場所を同時に触った」ことに起因するからだ。gitのマージは事後処理としては優秀でも、AIが生成した大きな差分同士がぶつかると、どちらを正とするかの判断は結局人間に戻ってくる。その判断コストをゼロにする、という方向性は理にかなっている。

なぜ今この手のツールが増えているのか

2026年に入って、コーディングの主戦場は「1体の賢いエージェントをどう使うか」から「複数のエージェントをどう並べて回すか」へ移りつつある。Claude Codeのサブエージェント、各種のオーケストレーション機能、クラウド実行環境——キーワードは揃って「並列」だ。

ただ、並列化には避けて通れない副作用がある。協調の問題だ。人間のチーム開発がブランチ戦略やレビュー文化で衝突を捌いてきたのと同じで、エージェントを何体も走らせるなら、それらが互いを踏まないための仕組みが要る。Murmellが「ファイル占有」という交通整理に賭けているのは、この空白地帯を突いているからだろう。

料金と使い所

ローンチ特典として、最初の2週間は無料、さらに Claude Code クレジット $60分（約9,000円相当）が付いてくる。恒常的な価格体系はまだ固まりきっていない印象で、この点は後述する懸念とも重なる。

向いているのは、こんな場面だと思う。

• 複数のエージェントに機能を分担させて、一気に実装を進めたいチーム
• 「エージェントが夜間に作業して、朝レビューする」というクラウド前提のワークフローを試したい個人
• Claude CodeとCodexを併用していて、両者を1つの画面で回したい人

逆に、エージェントを1体しか使わない、あるいはローカル完結で十分という人には、今のMurmellの価値はほとんど響かない。このツールの旨味は、あくまで「複数を同時に走らせる」ところに集中している。

正直な評価

コンセプトは素直に良い。並列化のボトルネックが協調にあると見抜いて、そこに一点突破で手を打った設計は筋が通っている。ファイル占有という枯れた発想を持ってきたのも、奇をてらわず堅実で好感が持てる。

一方で、気になる点もある。まず、作業がクラウドマシン上で完結する以上、自分のコードを外部の実行環境に預けることになる。企業のプライベートリポジトリを扱うなら、ここのセキュリティとデータ取り扱いは慎重に確認したい。ローンチ直後で、料金体系も対応エージェントもまだ流動的だ。今飛び込むのは早期採用者の楽しみと引き換えのリスクがある、という段階だと見ておくのが正直なところだ。

それでも、ここが面白くなる可能性は指摘しておきたい。ファイル占有という「調停役」が挟まると、単に衝突を防ぐだけでなく、エージェント同士の役割分担を明示的に設計できる土台になる。たとえば「フロントエンド担当のエージェント」と「テスト担当のエージェント」が互いのファイル領域を尊重しながら並走する——そんな、人間のチームに近い分業がコードレベルで実現するかもしれない。もしMurmellがこの調停レイヤーを洗練させていけば、「AIエージェントのチーム開発OS」とでも呼ぶべきポジションを狙える。そこまで届くかは、これからの作り込み次第だ。