壁紙アプリ4本を一人で保守していると、いちばん地味に時間を奪われるのが「ブランチの切り替え」でした。アプリAの依存更新をエージェントに任せている最中に、アプリBで小さなバグ報告が届く。git stash して切り替え、戻ってきたら作業の文脈を思い出し直す。この往復が一日のうちに何度も発生していました。
私は2014年から個人でアプリを作り続けていて、累計5,000万ダウンロードほどになった壁紙・癒し系アプリを今も保守しています。新作を作るより、既存の4本を落とさず回し続けることのほうが、実は神経を使う作業です。この2ヶ月、Antigravity のエージェントと git worktree を組み合わせて、その往復をなくす運用を試してきました。その記録を書きます。
なぜ worktree だったのか
最初に手を出したのは、ブランチを増やす方向ではありませんでした。Antigravity のエージェントに複数タスクを同時に投げれば済むだろう、と考えていたのです。
ところが同じ作業ツリーの上で2つのエージェント作業を走らせると、片方が触ったファイルをもう片方が前提にしてしまい、差分が混ざることがありました。依存の更新と機能修正が一つのコミットに同居して、あとからレビューしづらくなる。エージェントは速く動くぶん、作業の境界が曖昧だと、その曖昧さもそのまま速度で広げてしまいます。
そこで発想を変えて、タスクごとに物理的に別のディレクトリを用意することにしました。git worktree は、一つのリポジトリから複数の作業ツリーを切り出す仕組みです。ブランチごとにフォルダが分かれるので、エージェントには「このフォルダの中だけで作業して」と伝えれば、作業領域が物理的に隔離されます。
両家の祖父がともに宮大工だったこともあり、私は道具と材料を作業ごとに分けて置くという感覚が体に染みついています。一つの台の上で複数の仕事を同時に進めると、必ずどこかで木屑が混ざる。worktree を使ったときの安心感は、それに近いものでした。
実際のセットアップ
手順そのものは拍子抜けするほど簡単でした。メインのクローンとは別に、タスク用のツリーを切り出します。
# メインリポジトリの中で実行
cd ~/apps/wallpaper-app-a
# 依存更新用のツリーを別フォルダに作る
git worktree add ../wallpaper-app-a-deps -b chore/deps-update
# バグ修正用のツリーをもう一つ
git worktree add ../wallpaper-app-a-hotfix -b fix/crash-on-launchこれで ~/apps/ の下に、ブランチごとの独立したフォルダが並びます。あとは Antigravity でそれぞれのフォルダを別ウィンドウとして開き、エージェントには担当フォルダのパスを明示して作業を指示します。
エージェントへの指示で効いたのは、作業範囲をフォルダ単位で固定する一文を AGENTS.md に書いておくことでした。各 worktree のルートに、そのブランチの目的だけを書いた短いファイルを置きます。
# このツリーの役割
このフォルダは「依存ライブラリの更新」専用です。
- 依存バージョンの変更とロックファイルの更新のみ
- 機能追加・UI変更はこのツリーで行わない
- 変更後は必ずビルドが通ることを確認してから提案する役割を一行で渡しておくと、エージェントが余計な範囲に手を伸ばす頻度がはっきり下がりました。同じモデルでも、作業の枠が明確なほうが提案の精度が上がるという感触があります。
ぶつかった壁
うまくいった話だけ書くのは不誠実なので、つまずいた点も残しておきます。
一つめは、ネイティブ依存のキャッシュでした。worktree はソースを分けてくれますが、ビルド成果物やパッケージキャッシュまでは分けてくれません。複数のツリーで同時にビルドを走らせると、キャッシュの取り合いでビルドが不安定になる場面がありました。これはツリーごとにビルド出力先を分ける設定を入れて回避しています。
二つめは、自分自身が「今どのフォルダを見ているか」を見失う問題でした。4本のアプリ × 2〜3 ツリーになると、フォルダ数が一気に増えます。私はターミナルとエディタのタイトルにブランチ名を出す設定を入れて、視覚的に迷子にならないようにしました。エージェントが速いぶん、人間側の状態管理が追いつかなくなる、という典型的な落とし穴でした。
三つめは、worktree の消し忘れです。作業が終わったツリーを残したまま新しいツリーを足していくと、いつの間にか古いブランチのフォルダが散らかります。週末に git worktree list で棚卸しし、終わったものは git worktree remove で片付ける習慣にしました。
一日の流れがどう変わったか
具体的な一日を切り出すと、変化がわかりやすいかもしれません。
worktree を使う前の典型的な午前は、こんな順序でした。アプリAの依存更新をエージェントに依頼し、提案を待つ間に別の作業をしようとして、結局そわそわして手につかない。途中でアプリBのレビューの星が1つ減った通知が来て、原因を調べようと切り替え、戻ったらアプリAのどこを見ていたか思い出せない。一つの作業を終えるのに、実際の作業時間の何割かを「文脈の復帰」に使っていました。
worktree を入れたあとは、こうなりました。アプリAの依存更新ツリーでエージェントを走らせたまま、別ウィンドウでアプリBのクラッシュ調査ツリーを開く。アプリBの調査をエージェントに任せ、その間にアプリAの提案差分をレビューする。二つの作業が、互いの文脈を壊さずに進みます。切り替えのたびに git stash を打つ習慣が、ほぼ消えました。
数字にしづらい変化ですが、一日の終わりに感じる疲労がはっきり軽くなりました。同時にいくつも抱えること自体ではなく、抱えたものが頭の中で混ざることが、消耗の正体だったのだと思います。
2ヶ月使って気づいたこと
数えてみると、この2ヶ月で worktree を使った並行作業は60回ほどになりました。いちばん変わったのは、心理的な負荷でした。
以前は「アプリAの作業を中断したくないから、アプリBの報告は後回し」という判断をよくしていました。中断のコストが高かったからです。worktree でツリーを分けてからは、アプリBのツリーを開いてエージェントに調査を任せ、その間にアプリAのレビューを続けられます。中断ではなく並走になったことで、後回しにする報告が減りました。
エージェントの提案品質も、作業範囲を物理的に絞ったほうが安定しました。一つのツリーに一つの目的、という制約が、結果的にコミットの粒度をきれいに保ってくれます。レビューする側としても、差分の意図が読みやすくなりました。
一方で、これは万能な型ではないとも感じています。小さな修正一つに worktree を切るのは明らかにやりすぎで、セットアップの手間が見合いません。私は「半日以上かかりそうな作業」「他の作業と並走させたい作業」の二つの条件のどちらかを満たすときだけ、ツリーを切るようにしています。
これから取り組むこと
次に試したいのは、worktree の作成と片付けを定型化することです。毎回手で git worktree add を打つのは、決まりきった作業なので、ブランチ名を渡すと役割入りの AGENTS.md まで一緒に用意してくれる小さなスクリプトにまとめようと考えています。
個人開発は、新しく作る楽しさと同じくらい、すでにあるものを静かに守り続ける時間でできています。エージェントが速くなるほど、その速さに振り回されず、作業の境界を自分の手で引いておくことが大事になってきました。worktree は、その境界を物理的なフォルダとして目に見える形にしてくれる、地味で頼もしい道具だと感じています。
同じように複数プロジェクトを一人で抱えている方の、運用の一案になれば嬉しいです。お読みいただきありがとうございました。