worktree で複数のエージェントに独立した作業ツリーを与えると、ファイルレベルの競合はきれいに防げます。
でも、分離した後に気になってくるのが「誰がどのファイルを、どんな意図で触ったのか」という問いです。
ファイルの衝突はなくなった。可視性の問題はまだ残っている。
pacifio/atlas はそのギャップを埋めることを目指しているプロジェクトです。
Git との設計上の差分・セルフホスト手順・2エージェント並列実行から変更追跡まで、実際に動かす形で追っていきます。
worktree 分離の後に残る問題
worktree はあくまで物理的な分離の道具です。
「同じファイルを同時に書き換える」という衝突を防ぐのは得意ですが、それ以上のことはしてくれません。
実際に git log を眺めてみると、こういう状況になります。
author は自分の名前（あるいはエージェントのデフォルト名）で、コミットメッセージは "feat: update payment logic" "refactor: improve error handling" のような AI 生成の定型文が並ぶ。
エージェントAのセッションで生まれた変更と、エージェントBのセッションで生まれた変更が、ログの上では区別できない。
問題が本格的に表面化するのはマージのタイミングです。
2本のブランチを統合しようとしたとき、「この変更、なんでこうなってるんだっけ？」と聞く相手がいない。
どのプロンプトに起因して、どのファイルが変わったのかが追えないまま、コンフリクトの解消を判断しなければならない。
「エラーハンドリングを改善してほしい」というプロンプトから生まれた変更と、「パフォーマンスを最適化してほしい」から生まれた変更が、マージ後のコードの中では見分けがつかなくなります。
後から見ると、誰かが書いたコードがある。でも文脈がない。
これは Git の設計上どうにもならない部分です。
Git はそもそも 人間が意図的に打ったコミット を追う道具として作られています。
コミットメッセージは人間が書くことが前提で、その一行に変更の意図が凝縮されている設計です。
エージェントが自律的に量産するコミットを同じ文脈で扱うには、少し無理がある。
worktree という「物理的な箱」の整備が終わったあと、次の課題として浮上してくるのがこの可視性の問題です。
Atlas が埋めようとしているのは、ちょうどここです。
Atlas が Git に補完するもの
Atlas のリポジトリには「source control for coding agents」という一行があります。
"source control" という言葉をあえて使っているのが印象的です。
Git を置き換えようとしているわけではなく、エージェント時代に Git が見えていない層を可視化しようという意図が滲んでいます。
Git のコミット単位とエージェントのセッション単位は、構造が根本的に違います。
その対比を整理するとこうなります。
- Git のコミット は人間が「このタイミングで記録する」と判断して打つものです。コミットメッセージも人間が書く。変更の意図はそのメッセージに込められているという前提があります。
- Atlas のチェックポイント は agent run ごとに自動で紐付けられます。コミットに加えて、セッションID・プロンプト・ツールコール・reasoning がセットで記録される。
- 「なぜ」が残る という点が一番の違いです。「エージェントが何をしたか」だけでなく「どんな指示を受けて・どう考えて変更したか」まで遡れる構造になっています。
Atlas の内部では、一連の会話を「スレッド」という単位で管理しています。
スレッドはエージェントプロセスとは独立して存在しており、エージェントを切り替えても会話の文脈が失われません。
README に「switching agents mid-task doesn't mean starting over」とある通り、あるエージェントが途中まで進めたタスクを別のエージェントが引き継ぐという使い方ができます。
外部エージェントとの接続は ACP（Agent Communication Protocol）を介して行われます。
各エージェントが initialize 時に advertise した capability をもとに、Atlas がどのデータを取り込むかを決める仕組み（capability gating）で、あるエージェントが session/list に対応していれば Atlas がそのセッション履歴をインポートできます。
対応していなければスキップされる。
「エージェントによって取れる情報の粒度が違う」という現実を、プロトコルレベルで素直に扱っています。
Claude Code や Codex は ACP registry 経由でサポートされているため、比較的スムーズに接続できます。
Atlas は既存の Git ワークフローを壊しません。
ブランチも PR も今まで通り使えます。
Atlas はそのワークフローの横に、エージェントセッション単位の文脈を追加するレイヤーです。
セルフホストで動かすまでの最小手順
現時点では、Atlas はクラウド SaaS を提供していません。
試すにはセルフホストが前提です。
事前に必要なのは Rust のツールチェーンです。
cargo が入っていない場合は rustup でインストールしておきます。
以下は一般的な Rust プロジェクトのビルド手順に準じた最小コマンドです。
執筆時点の内容であり、最新の手順は 公式 README を確認してください。
# リポジトリを取得
git clone https://github.com/pacifio/atlas
cd atlas
# ビルド（初回は依存クレートの解決に時間がかかります）
cargo build --release
# 起動
./target/release/atlas
初回ビルドはそれなりに時間がかかります。
「止まっているのかな」と心配になるくらいには長いので、辛抱強く待ちます。
起動したらターミナルの出力に表示される URL を確認し、ブラウザでアクセスしてください。
UI の Agents タブ が表示されていれば、セットアップは完了です。
エージェントを接続すると、初回起動時に バックフィル と呼ばれる処理が走ります。
インストール済みエージェントのセッション履歴を ACP の session/list 経由で自動インポートする処理で、これが完了すると接続直後からある程度の履歴が UI 上に表示されます。
活発に開発が進んでいるプロジェクトなので、破壊的変更が入ることも珍しくありません。
本番環境への適用より前に、手元の開発環境で動作を確認しておくのが現実的です。
2エージェント並列実行と変更追跡の実演
実際に2つのエージェントを同一コードベースで走らせてみます。
前編で整備した worktree を使う場合は、エージェントAとエージェントBをそれぞれ別のブランチ・別の worktree ディレクトリに向けておきます。
git worktree list
# /path/to/project abcd123 [main]
# /path/to/project-agent-a efgh456 [feature/agent-a]
# /path/to/project-agent-b ijkl789 [feature/agent-b]
この状態でエージェントA（Claude Code）に「支払いロジックのエラーハンドリングを改善する」、エージェントB（Codex）に「同じモジュールのパフォーマンスを最適化する」というプロンプトを与えて並列に走らせます。
Git だけで見ると、こうなります。
* b3a1f22 (feature/agent-a) feat: improve payment error handling
* 9c4d8e1 (feature/agent-b) perf: optimize payment module
author が違う程度の差しかなく、どちらがどのファイルを触ったかは git diff を走らせないと分かりません。
まして「なぜその変更をしたのか」はこのログからは読み取れません。
Atlas の Agents タブを開くと、様子が変わります。
セッション単位の変更一覧が表示され、各セッションにはプロンプト・ツールコール・reasoning がセットで記録されています。
以下は 概念を示すための擬似的な出力例 です。
実際のフィールド名・表示フォーマットは Atlas の UI および実装に依存します。
動かした際の実際の画面とは異なる可能性がある点をご了承ください。
Session: a1b2c3 (Claude Code)
Prompt: "支払いロジックのエラーハンドリングを改善する"
Changed: payment/handler.ts (+24 -6), payment/types.ts (+3 -0)
Reasoning: [エージェントが記録した推論・変更意図]
Session: d4e5f6 (Codex)
Prompt: "同じモジュールのパフォーマンスを最適化する"
Changed: payment/handler.ts (+8 -12), payment/utils.ts (+15 -3)
Reasoning: [エージェントが記録した推論・変更意図]
payment/handler.ts を両エージェントが編集しているのが一目で分かります。
マージ前に「どちらの変更を優先すべきか」という判断を、文脈ゼロで行うのか・プロンプトと reasoning つきで行うのかでは、判断の質が変わってきます。
これは git log や git diff では絶対に得られない情報です。
worktree で物理的に分離しつつ Atlas で文脈を記録する。
この2段構えが揃ったとき、複数エージェントの変更を「あと追い」ではなく前向きに管理できるようになります。
今の段階で試す価値があるか
正直なところ、Atlas はまだ成熟したプロダクトではありません。
活発に開発が続いており、破壊的変更が定期的に入ります。
セルフホスト前提なので、運用の手間も発生します。
本番環境に組み込む前提で評価すると、現時点では荷が重いと感じる可能性が高いです。
一方で、「エージェントが増えるほど Git だけでは追えなくなる」という方向性は変わりません。
1つのエージェントを慎重にレビューしながら使う段階なら Git で十分です。
でも複数のエージェントを並列で走らせ始めると、変更の文脈が急速に失われていきます。
そのタイミングで「あのとき試しておけばよかった」と後悔するより、今のうちに手元で動かして運用感を掴んでおく価値はあります。
ツールとしての成熟度を評価するというより、「エージェント単位の変更追跡」というアプローチが自分のプロジェクトに合うかどうかを確認する、くらいの温度感で試してみるのが今の段階での適切な関わり方だと思います。
エージェントオーケストレーションがプロダクション開発の現場に広がるほど、こうした可視化レイヤーの需要は高くなっていくはずです。
株式会社ホコサキは山口県宇部市を拠点に、Web 制作・業務システム開発・AI 活用支援を手がけています。
複数エージェントの並列活用や変更管理の設計についてご相談があれば、お問い合わせ からお気軽にどうぞ。