並列AIの作業場はworktreeで分ける

🧵共有した作業場で、他のセッションの変更を巻き込みかけた

複数の AI を同じ場所で動かしたら、片方が用意したファイルが、もう片方のコミットに紛れ込みかけました。

最初は、並列で動かすセッションを全部、同じ作業ディレクトリ（共有のチェックアウト）に同居させていました。 同じフォルダで、複数の書き手が同時に手を動かしていた、ということです。

あるセッションが変更を途中まで作り、別のセッションが「今ある変更をまとめてコミット」を実行した瞬間、意図していないファイルまで一緒に取り込まれかけました。 幸い、コミット前に気づいて事なきを得ました。

原因ははっきりしていました。作業場が 1 つなのに、書き手が複数いた。 「今ある変更」という言葉の意味が、書いた本人の想定とズレていく。それだけの話です。

🌳git worktree で「作業場」を物理的に分ける

同じリポジトリでも、worktree を使えば、セッションごとに独立した作業ディレクトリを持てます。

そこで運用を変えました。並列で動かすセッションには、git の worktree 機能を使って、それぞれ別のフォルダを割り当てる、と。git worktreeは、1 つのリポジトリから複数の作業ツリーを切り出せる標準機能です。

ブランチごとに物理的な作業フォルダが分かれるので、片方の未保存の変更が、もう片方から見えることはありません。 私たちのエージェント実行の仕組みにも、セッションを隔離した worktree で動かす選択肢があって、独立したタスクを並列で回すときは、これを既定にしています。

大きく捉えると、これは「机を分ける」話です。2 人が同じ紙に同時に書けば、字は混ざる。 紙を 2 枚に分ければ混ざらない。worktree は、その 2 枚目の紙です。

📌コミットは「このファイルだけ」を指定する

「今ある変更を全部」ではなく、対象のパスを明示してコミットする。並列では特に効きます。

worktree で作業場を分けても、もう 1 つ足したルールがあります。コミットのとき、対象のパスを明示的に指定する、と。

git add . のように「今ある変更を全部」ではなく、git commit -- <ファイルパス> の形で、何を含めるかを自分で選ぶ。こうすると、たとえ同じ場所に別の変更が混ざっていても、意図したファイルだけがコミットに入ります。

地味ですが、並列運用では効きます。何を含めるかを、機械の「今ある全部」ではなく、書き手が指定する。この一手間で、混線したコミットの多くは防げます。

🗂️並列で動かす前に決めておくこと

並列で AI を走らせるなら、始める前に決めておくと安全なことがあります。

私たちが並列運用で守っている点を挙げます。

• 独立して進められるタスクだけを並列にする。結果が互いに依存するものは、順番に回す。
• セッションごとに worktree で作業ディレクトリを分ける。共有チェックアウトに複数のセッションを同居させない。
• コミットはパス束縛で。「全部」ではなく「このファイル」を指定する。
• 各セッションに、担当ファイルの範囲を最初に渡す。他のセッションの担当領域は触らせない。

もう 1 つ、地味だけど効くのが後片付けです。worktree は使い終わったら削除する。放置すると、どのフォルダが何用だったのか分からなくなり、次に並列で走らせるとき、また混線の芽になります。 変更を含まない worktree は自動で片付く仕組みにして、手元に残すのは「今まさに動いているセッションの分」だけにしています。

逆に、並列にしない判断も同じくらい大事です。1 つのファイルを続けて編集する作業や、調査から実装へ地続きで進む作業は、無理に分けず 1 つのセッションでやります。分けるコストのほうが高いからです。

🧭並列でAIに任せる人へ

並列は速さのためというより、混線を避ける設計とセットで、はじめて安心して使えます。

AI に任せる範囲を広げると、「同時に何本も走らせたい」場面は自然に増えます。 そのとき最初にケアすべきは、賢さより作業場の分離でした。

私たちが使っている Claude Code のようなエージェント型ツールは、自分でコマンドを実行し、ファイルを書き換えます（Claude Code の公式ドキュメント）。力が強いぶん、複数が同じ場所に手を入れると、壊し合いも速い。

worktree で机を分け、コミットで持ち物を指定する。この 2 つを先に決めておくと、並列の速さを、混線のこわさに相殺されずに使えます。

あなたも、複数の AI を同時に動かしていますか。 もしそうなら――まず「作業場は分かれているか」を、確かめてみてください。