Meta Muse Codeのworktree分離——同時編集を防いでも、統合は残る

Muse Codeが約束するもの——サブタスク分割とworktree分離

2体のAIエージェントに、同じリポジトリの別々の作業を同時に任せたとします。

片方は注文APIに引数を1つ追加し、その呼び出し側もあわせて直します。

もう片方は、引数が追加される前の仕様のまま、管理画面の実装を進めます。

この2体は別々の場所でファイルを編集しているので、作業中は一度もぶつかりません。

同じファイルを同時に書き換えることも、互いの編集を上書きすることもありません。

問題が出るのは、両方の変更を1つのコードベースへ統合した後です。

ビルドが通らないか、通っても結合テストで落ちます。

この事故の原因は「同時に同じファイルを書いた」ことではありません。

「同じ前提を共有しないまま、それぞれ単体では正しい変更を作った」ことです。

大規模なコードベースほど変更の依存関係は見渡しにくくなるので、この形の食い違いは起きやすくなります。

2026年8月5日、Metaはこの並行作業を正面から扱うコーディングエージェント「Muse Code」を公開しました。

発表から2週間余りが経ち、製品ページとドキュメントまで含めて一次情報が出そろったので、本稿ではその設計を読み直します。

Metaの説明によれば、Muse Codeはターミナルで動作する（CLI型の）コーディングエージェントで、コーディング向けに最適化したモデル「Muse Spark 1.2」の上で動きます。

長時間にわたる複数エージェントのコーディング作業と、透明性のある監査可能性を狙って作られた、と同社は説明しています。

同社のブログ記事「Build with Muse Code」（2026年8月5日付）は、作業が十分に大きい場合の挙動をこう説明しています。

Muse Codeは作業をサブタスクへ分割し、子エージェントそれぞれに固有のGit worktree（ワークツリー）を与える。

worktreeは .muse/worktrees/ の下に、親のHEADから切り出したdetached-HEAD状態で作られる。

そのため並行して動く子エージェントが同じファイルで衝突することはなく、利用者の作業コピーは触られない、と記載されています。

製品ページでも「複数のサブエージェントを隔離されたworktreeへ立ち上げ、作業途中の衝突なしに並行作業を進める」と説明されています。

同じブログ記事には、統合について次の記述もあります。

各子エージェントは自分のブランチに成果をコミットするので、親は1つずつレビューまたはマージできる、というものです。

つまりMeta自身の説明においても、統合の判断は消えておらず、親の作業として残っています。

Metaは検証例として、あるゲーム開発のデモで6つのサブタスクにサブエージェントを立ち上げた様子を紹介しています。

ただしこれはMeta自身のデモであり、第三者による検証ではありません。

またこの説明での「衝突」は、作業コピー上の編集衝突を指しています。

同ブログには、そのホストでは同時実行の上限が4となり4件が即座に走り、5番目と6番目は枠が空き次第開始した、とも書かれています。

6つが文字どおり同時に走ったわけではなく、統合後に仕様が両立するかを検証した結果でもない、という点は押さえておく必要があります。

価格は公表されています。

Muse Spark 1.2には2つのティアがあり、片方は単価が低い代わりに「製品改善に利用される」、もう片方は「製品改善に利用されない」と明記されています。

本稿では単価の数値を並べません。

課金単位・プラン・含まれる機能が製品ごとに異なるため、単価の比較だけで優劣が決まるものではないからです。

機密性の高いコードを扱う場合は、価格とデータの利用条件を別々の項目として確認しておく必要があります。

安いティアを選ぶという判断は、同時にデータの扱いを選ぶという判断でもあります。

本稿が扱うのは、複数エージェントの並行実行と統合にまつわる設計上の論点です。

モデルの生成品質の比較、導入手順、料金の詳細な試算は対象にしていません。

Git worktreeが防ぐ衝突、防がない衝突

Git worktreeは、Muse Codeのために作られた仕組みではありません。

同じリポジトリの履歴やブランチの情報を共有したまま、作業用のファイル一式を別のディレクトリにもう一組用意する、Gitの標準機能です。

並行作業のためにこれを使う設計も、Muse Code固有ではありません。

OpenAIのCodexアプリの公式ドキュメントは、worktreeをリポジトリの2つ目のチェックアウトと説明し、ローカルのチェックアウトから同時変更を隔離したい場合はworktreeでタスクを開始するよう案内しています。

AnthropicのClaude Codeの公式ドキュメントにも「worktreeで並列セッションを走らせる」という項があり、claude --worktree に名前を渡して別のターミナルで実行すると隔離された並列セッションになる、と書かれています。

私たちが2026年8月に一次で確認できたのは、この2製品です。

したがってMuse Codeに固有なのはworktreeそのものではなく、大きな作業をサブタスクへ分割し、サブエージェントを隔離worktreeへ自動で展開する流れを、製品の主要な挙動として前面に出した点だと私たちは受け止めています。

ここで、言葉の使い方を分けておきます。

並行実行の安全性を1つの「隔離」という語で語ると、性質の違う3つが混ざります。

私たちは次の3軸に分けて考えています。

• 軸1：作業ツリーの分離 — 別のworktree・別のブランチで作業し、同じ作業ディレクトリを直接書き換えない。
• 軸2：実行環境の分離 — プロセス、ポート、データベース、環境変数、認証情報、外部サービスへの書き込みが分かれているか。
• 軸3：統合時の整合性 — マージした後に、ビルド・テスト・仕様・API契約が両立するか。

Git worktreeが構造的に担うのは軸1です。

軸1が効いている範囲では、同じ作業ツリーへの同時書き込みは起こりません。

一方、Git worktreeが自動的に分けてくれないものを並べると、プロセスやコンテナ、ネットワーク、ポート、データベース、環境変数やAPIキー、外部サービスへの書き込み、そして複数の変更が意味として両立するかどうか、が挙がります。

最後の1つが軸3で、それ以外はすべて軸2に属します。

この線引きは、他社の公式ドキュメントの記述からも読み取れます。

OpenAIのCodexアプリの公式ドキュメントは、新しく作ったworktreeには依存関係や、.env のようなGit管理外のファイルが揃っていない場合があるとして、セットアップスクリプトや、コピー対象を列挙する設定ファイルで補う方法を案内しています。

裏を返せば、そこで同じ .env を各worktreeへ配れば、作業ファイルは別々でも接続先の認証情報は同一になります。

作業ツリーを分けることと、実行環境を分けることは、別々に設計する必要があるということです。

作業ツリーが別でも共有されるもの——プロセス・データベース・外部状態

軸2を具体で見ていきます。

エージェントがコードを書くだけで止まらず、ビルド・起動・テスト・外部API呼び出しまで行う場合、作業ツリーが別でも共有されたままの資源があります。

たとえば開発用のデータベースです。

2体のエージェントがそれぞれ別のマイグレーションを流せば、スキーマは1つしかないので後勝ちになります。

片方のテストが、もう片方の変更したスキーマの上で走ることになります。

開発サーバのポートも同じです。

同じポートで起動しようとすれば片方が起動に失敗し、失敗した側は「自分の変更が壊れている」と誤って解釈する余地があります。

外部サービスも共有されます。

同じテスト用アカウントで決済のサンドボックスに書き込む、同じキューにジョブを投入する、同じメール送信サービスを叩く。

いずれも作業ツリーの分離とは無関係に、1つの相手へ2つの流れが届きます。

Muse Codeについて私たちが2026年8月に確認した範囲の一次資料には、プロセスやネットワーク、ポート、データベースの分離、あるいはサンドボックスの仕組みについての説明は見当たりませんでした。

記載が無いことは、その機能が無いことの証明にはなりません。

ただ、公表されている説明が扱っているのは作業ツリーの分離であり、実行環境の分離までを製品が引き受けると読むのは早いと考えています。

私たちの見方はこうです。

並行実行を試すときは、「何が分離されているか」に加えて「何が共有されたままか」を数えると、輪郭が早く見えます。

共有されている資源の数が、そのままエージェントを増やしたときに起きうる干渉の種類の数になるからです。

統合後に初めて現れる不整合

冒頭の例に戻ります。

エージェントAが注文APIの引数を1つ増やし、呼び出し側も更新した。

エージェントBは、引数が増える前の仕様を前提に管理画面を実装した。

どちらも自分の作業ツリーの中では筋が通っています。

統合すると、運が良ければビルドが失敗します。

次に運が良ければ、ビルドは通っても結合テストが落ちます。

落ちてくれれば気づけるので、これはまだ良い側の結末です。

厄介なのは、どこも落ちない場合です。

たとえば追加した引数に既定値があれば、旧仕様のままの呼び出しもエラーにはならず、挙動だけが想定と変わります。

この種の不整合は、作業ツリーの分離では検出できません。

分離が働いた結果として、統合の瞬間まで両者が互いの前提を知らないままだったからです。

先に引いたとおり、Metaの説明でも各子エージェントは自分のブランチにコミットし、親が1つずつレビューまたはマージします。

製品が構造的に消しているのは軸1の衝突であり、軸3の判断は利用する側に残っています。

そして、並行して進む変更の範囲や依存関係が増えるほど、統合時の調整と検証の負荷も大きくなり得ます。

エージェントを1体増やすことと、レビューを1件増やすことは、必ずしも同じ重さではありません。

触る境界が重ならなければ負荷はあまり増えず、同じAPIやスキーマに複数の変更が集まれば急に重くなります。

私たちは、AIは間違える前提で仕組みを組む、という立場を取っています。

ただし同じ理由から、仕組みが担う範囲を実際より広く見積もることも危ういと考えています。

「分離されているから大丈夫」という理解は、分離が防いでいない種類の食い違いに対しては、むしろ油断を作ります。

変更を分離する設計は上流の事故を減らしますが、下流の検証を減らしてよい理由にはなりません。

実務上の目安として私たちが置いているのは、統合前に人が見る範囲を、エージェントの台数ではなく変更が触る境界で決める、という考え方です。

API、データベースのスキーマ、共有設定、認証まわり。

ここに複数のエージェントの変更が集まっているなら、台数が2体でも人が見る。

逆に境界が重ならない変更であれば、台数が増えても統合前の確認は軽く済みます。

Muse Codeのイベントログと再開機能

追跡可能性について、Muse Codeは具体的な実装を持っています。

Metaのドキュメントに記載があるので、機能として存在すること自体は確認できます（私たち自身が動作を検証したわけではありません）。

同ドキュメントによれば、Muse Codeはすべての実行を追記専用（append-only）のイベントログとして記録します。

記録される対象として挙げられているのは、モデルの呼び出し、ツールの呼び出しとその結果、そして承認の判断です。

前述のブログ記事では、このログがディスク上のプレーンなJSONLであり grep できること、セッション・エージェントの起動・アクション・サブエージェントが下したそれぞれの判断が残ることも説明されています。

並行して動くエージェントが増えるほど、どのエージェントが、いつ、どの範囲を変更したかを後から言えることの重要性は増すので、ここが具体的に設計されている点は評価できます。

同ドキュメントは再開についても説明しています。

セッションがイベントソース方式で記録されているため、中断あるいはクラッシュした実行は /resume で再生でき、会話を再構築し、中断されたターンを閉じて続行する、というものです。

ここで重要なのは、同じドキュメントが明示している留保です。

再開された破壊的な操作は「確認してから続ける（verify, then continue）」ものとして扱うこと、そして再開は実行中だった作業の重複排除を行わないこと、が書かれています。

ファイル書き込みのような副作用が実行の途中で中断された場合、その副作用は結果不明として記録され、エージェントには再試行の前に実際の状態を確認するよう伝える、とも記載されています。

この留保は、本稿の論点と同じ形をしています。

ログは「何が起きたか」を後から言えるようにしますが、「起きたことが正しいか」「今どういう状態か」までは言ってくれません。

分離が統合の正しさを保証しないのと同じく、追跡可能性はそれ自体では状態の整合性を保証しません。

だからこそ、記録が残っていることと、再開後にまず状態を確認する手順を持っていることは、別々に用意する必要があります。

そのうえで、導入検討時に確認すべきことは「イベントログがあるかどうか」ではありません。

Muse Codeには実装されています。

確認すべきなのは、そのログをどれだけの期間保持するか、社内の分析基盤や監視基盤へ持ち出せるか、誰が閲覧できるか、後から改変されないことをどう担保するか、といった運用側の設計です。

これらの多くは製品の機能ではなく、利用する会社が決める領域にあります。

製品が出力する材料と、会社が組み立てる運用を同じ欄に書かないほうが、判断を誤りません。

自社環境で試すなら、何を壊してみるか

並行実行するコーディングエージェントは、機能一覧を読んでも境界の位置が分かりません。

分かるのは、壊してみたときです。

以下は私たちが妥当だと考える検証シナリオの一例で、規範ではありません。

どこまで試すか、何を許容するかは、各社のリスク許容度・開発体制・扱うコードの機密性に合わせて決めるものです。

1. 同じファイルを、別々のエージェントに変更させる。 作業中に編集が衝突しないことを確認したうえで、統合の段になって何が起きるかまで見ます。軸1が効いている範囲を、自分の目で確かめる試行です。
2. 片方にAPI仕様の変更を、片方に旧仕様を前提とした実装をさせる。 統合後にビルドやテストで検出できるのか、それとも黙って通ってしまうのかを見ます。通ってしまう場合は、自社のテストの網の目が粗いという情報が得られます。
3. 同じポート・同じ開発用データベース・同じテスト環境を使わせる。 実行環境が共有されたままだと、どこがどう壊れるかを見ます。エラーメッセージが原因を素直に指すかどうかも、あわせて確認する価値があります。
4. 処理の途中でセッションを停止させる。 再開が何を復元し、何を結果不明として残すかを見ます。ファイル書き込みや外部サービスへの送信といった、取り消しにくい操作の最中に止めるのが要点です。
5. 複数の変更のうち1つだけを却下し、巻き戻す。 却下した変更に依存した箇所が他に残らないか、取り消しの単位がブランチ単位で足りるかを見ます。

5つに共通する狙いは、自社の環境で軸1・軸2・軸3の境界が実際どこにあるかを、図に描けるようにすることです。

製品に点数を付けることが主目的ではありません。

境界の位置が分かれば、統合前に人が見る範囲も、エージェントを何体まで同時に走らせるかも、根拠を持って決められます。

まとめ——worktreeは安全性の完成形ではなく、一つの境界である

Muse Codeの発表は、並行実行を前提としたコーディングエージェントが、作業ツリーの分離を主要な設計として前に出す流れの中にあります。

Git worktreeによる分離自体は既に複数の製品が採用しており、Muse Codeはそれをサブタスク分割とセットで自動化して見せた製品だと私たちは捉えています。

worktreeによる分離は有効です。

同じ作業ツリーへの同時書き込みという種類の事故を、構造的に起こらなくします。

同時にそれは3つある軸のうちの1つであり、実行環境の分離と統合時の整合性は、別の設計として残ります。

モデルの性能や単価だけを並べた比較表では、この境界の位置は見えません。

見えないまま台数を増やすと、防げている事故と防げていない事故が、同じ「隔離されているから安全」という理解の下にまとめられてしまいます。

私たちが評価の場面で心がけているのは、「何が分離されているか」と同じ重さで「何が分離されていないか」を書き出すことです。

並行実行するエージェントの導入を検討する際は、分離の仕組みそのものに加えて、実行環境で何が共有されたままか、統合前に誰が何を確認するか、問題が起きたときにどの単位で巻き戻せるかを、自社の運用としてあわせて設計しておくとよいと考えています。

情報確認について

本記事は2026年8月確認時点の情報をもとに作成しています。

一次資料として、Metaの公式情報（Meta AI Developersブログ「Build with Muse Code」〔2026年8月5日付、著者 Matthias Reso・Josh Walters〕、Muse Code 製品ページ、Muse Code ドキュメント「Interactive」、Muse Spark モデルページ）を参照し、本文を確認しました。

補助資料として、TechCrunch「Meta launches Muse Code, an AI agent for large code bases」（2026年8月5日）を参照しています。

他製品でのGit worktreeの扱いは、OpenAIのCodexアプリ公式ドキュメント「Worktrees」およびAnthropicのClaude Code公式ドキュメント「Common workflows」で確認しました。

Muse Codeは本稿執筆時点でベータ提供中と報じられており、機能範囲・提供条件・価格体系・データの利用条件は今後変更される可能性があります。

導入を検討される際は、提供元の最新の説明をご確認ください。