Gitワークツリーと権限の分離で複数のAIコーディングエージェントを安全に実行する方法

各コーディングエージェントに専用のブランチと作業ディレクトリを割り当て、プロセスがアクセスできるファイル、認証情報、ネットワークは別途制限してください。Git worktreeは、編集作業どうしの偶発的な干渉を減らしますが、セキュリティサンドボックスではありません。安全な並行作業には、把握しやすいリポジトリ状態と、強制可能な実行権限の両方が必要です。

このガイドでは、ローカルのworktreeコマンド、タスク単位のアクセス、独立したテスト環境、人がレビューする統合手順を紹介します。自分が所有する、または変更を許可されているリポジトリを使い、まずは破棄できるタスクから始めてください。この手順は特定のツールに依存しません。コーディングエージェントのインターフェースで一部を自動化できる場合もありますが、基盤となる境界は引き続き確認する必要があります。

エージェントが同じワークスペースを共有すると、何が問題になる？

2つのエージェントが未コミットの変更を上書きしたり、同じ依存関係ファイルを変更したり、別のタスクの一時的な状態をプロジェクトの意図された設計だと解釈したりすることがあります。また、テストの実行中に内容が変わるディレクトリを対象にテストを実行することもあります。どちらのエージェントも安定したリビジョンでテストしていないため、結果として起きた失敗を再現するのが難しくなる場合があります。

問題はソースファイルだけにとどまりません。共有ポート、データベース名、キャッシュ、フィクスチャディレクトリ、バックグラウンドプロセスは、差分が別々のモジュールにあっても干渉を引き起こすことがあります。あるエージェントが、別のエージェントが使用中のサービスを停止したり、スキーマの編集中にファイルを再生成したりする可能性があります。

マルチエージェント連携の解説では、タスクの境界と依存関係によって、こうした干渉を減らす方法を説明しています。エージェントを増やす前に、各担当の成果物、編集が許可される範囲、依存関係、受け入れテストを明記してください。「同じ機能を一緒に作業する」だけでは、変更を個別に進めるための取り決めとして不十分です。

ディレクトリを分けると、誤って互いの作業に干渉する可能性が低くなります。セキュリティコンテキストを分けると、プロセスがアクセスできる範囲を制御できます。ブランチをうまく分離できたことを、プライベートファイルや本番サービスの保護と取り違えないよう、この2つの目的は区別してください。

別々にcloneする代わりにworktreeを使うべきなのはどんなとき？

Git worktreeは、1つのリポジトリの複数のブランチで、同時に別々の作業ディレクトリが必要な場合に便利です。実験でより独立したリポジトリ設定や別のリモート設定が必要なら、別々にcloneするほうが適している場合があります。どちらの方法も、それだけではOSユーザーがシークレットやほかのディレクトリにアクセスするのを制限できません。

実際のワークフローに応じて選択してください。worktreeを使うとブランチ単位のレビューがしやすくなる一方、別々にcloneすると、リポジトリレベルで破壊的な実験を隔離しやすくなる場合があります。信頼できないコードや、より広範な実行リスクがある場合は、ソースのチェックアウト方法にかかわらず、適切に隔離された実行環境を使用してください。

この表は計画の参考資料であり、セキュリティ認証ではありません。エージェントが実際に使用するシェルから見えるファイルやサービスも含め、依拠する予定の境界をテストしてください。

表紙: Conductor公式ブランドキットのワードマーク。編集上の識別のために変更せず使用しています。製品のマークはそれぞれの所有者に帰属し、提携関係を示すものではありません。

エージェントごとにブランチとワークツリーを作成するには？

既知のレビュー済みベースから開始します。ブランチを切り替える前に既存の作業を保存し、作業ディレクトリをクリーンだと思い込まず、実際に確認します。次の例は、レビュー済みのベースがmainであるローカルリポジトリを想定しています。プロジェクトに適したベースを使用してください。ブランチ名が間違ったコマンドをコピーして、無理に実行しないでください。

git status --short
git branch --show-current
git worktree list
git switch main
git worktree add -b agent/docs ../agent-docs main
git worktree add -b agent/tests ../agent-tests main
git worktree list

各エージェントに専用ワークツリーのパスと範囲を限定したタスクを割り当てます。ベースのコミットを記録し、共有ファイルのうち、どれに調整が必要かを説明します。手軽だからといって、個人の開発環境全体を各ディレクトリにコピーしないでください。認証情報や無関係な個人情報まで複製されるおそれがあります。

次の一連の手順を実行します。

1. リポジトリの状態がクリーンであるか、安全に保持されていることを確認し、レビュー済みのベースを選びます。
2. 割り当てごとに固有のブランチとワークツリーを作成します。
3. タスクに必要なコンテキストだけを伝え、明確な完了条件を示します。
4. タスクで必要な場合に限り、専用の範囲を限定した認証情報を設定します。
5. 各テストに、個別の一時パス、ポート、破棄可能なサービス状態を割り当てます。
6. 統合を提案する前に、各差分とテスト結果を確認します。
7. プロジェクトの人間によるレビューとリポジトリの管理手順を経てマージします。
8. 必要な証拠を保持し、完了したワークツリーは通常どおり削除し、一時的なアクセス権を取り消します。

これらのコマンドはリポジトリの状態を作成するものであり、サンドボックスを設定するものではありません。エージェントツールに独自のワークスペース管理機能がある場合は、結果として生成されるブランチとパスを確認し、インターフェース外でも同じ契約を理解できるようにしてください。

キー、環境ファイル、トークンを分離するには？

ワークツリーに開発者の認証情報一式を引き継がせてはいけません。タスクに必要なリポジトリとサービスの権限だけを持つ専用のIDを使用してください。シークレットは承認済みのストレージに保管し、プロンプト、タスクファイル、またはコミット済みの.envファイルに記載せず、ツールがサポートする方法で渡してください。

GitHubのトークンに関するドキュメントでは、トークンの権限とライフサイクルについて説明されています。実用上可能な範囲で最も限定的なスコープと、適切な有効期限を選び、取り消し方法も用意してください。ソースの読み取りに必要なトークンがあっても、ワークフローファイルの変更、プルリクエストのマージ、リポジトリの管理まで許可する必要はありません。

環境変数は値を渡す手段であり、完全な隔離境界ではありません。子プロセスに継承される場合があり、デバッグコマンドやログから漏れることもあります。各ワーカーに渡る変数を確認し、本番環境の値をテスト環境と共有しないようにしてください。シミュレーション可能なサービスには、テスト用の認証情報を使用してください。

OWASPのシークレット管理ガイダンスでは、アクセス制御とローテーションの背景が説明されています。エージェントが必要としていないシークレットを読み取った場合、情報漏えいが確認されていなくても、設定上の問題として扱ってください。環境側で不要なアクセスを不可能にするか、意図的に制限するべきであり、モデルが注意をそらさないことに頼るべきではありません。

コンテナやサンドボックスでアクセスを制限するには？

実際の設定を確認してください。ユーザーID、マウントされたパス、ネットワークポリシー、権限、ソケット、利用可能な認証情報などです。ホストのホームディレクトリとコンテナエンジンのソケットがマウントされたコンテナは、タスク用フォルダーを大きく超える範囲にアクセスできる可能性があります。「サンドボックス」というラベルは、それらのリソースが制限されている証拠にはなりません。

Dockerのセキュリティ概要では、重要なランタイム上の考慮事項が説明されています。プラットフォームがサポートする制御を使って権限を減らし、必要なデータだけをマウントし、サービスの状態を分離してください。ワーカーが範囲外であるべき場所にアクセスできるかどうかをテストしてください。アクセス拒否に成功すれば、制御が有効であることを示す有用な証拠になります。

ネットワークアクセスは、割り当てられたタスクに応じたものにしてください。タスクによっては、パッケージレジストリとリポジトリホストへのアクセスが必要でも、任意の外部接続先や本番データベースへのアクセスは必要ありません。強制可能なレイヤーで制御を適用し、例外を文書化してください。依存関係のインストールを可能にするために証明書チェックを無効にせず、実際の信頼性または接続性の問題を解決してください。

rootless Docker のドキュメントでは、デーモンとコンテナの権限を抑えるための選択肢を紹介しています。ただし、すべてのワークロードが無害になるわけでも、マウントやシークレットのレビューが不要になるわけでもありません。実行するコードとホスト環境の価値に応じて、適切な隔離方法を選んでください。

変更はどのようにレビューしてマージすべきか？

コミットだけでなく、未コミットの作業もレビューしてください。エージェントは、関連ファイルをコミットせずに残したまま、あるいは提案ブランチとは異なる作業ディレクトリをテストしたまま、タスク完了を報告することがあります。実際の成果物を特定するよう求めたうえで、独立して確認してください。

git -C ../agent-docs status --short
git -C ../agent-tests status --short
git diff --stat main...agent/docs
git diff main...agent/docs
git diff --stat main...agent/tests
git diff main...agent/tests

各作業ツリーでプロジェクトに関連するチェックを実行し、相互作用が重要な場合は、統合後のリビジョンでも再度実行します。共有される仕様、生成ファイル、依存関係の更新をレビューしてください。レビュー中にベースが変更された場合は、どの根拠が古くなったのかを特定します。承認対象のコードを変更しながら、承認済みであるかのように見せてはいけません。

GitHub のブランチ保護に関するドキュメントでは、ワークフローを補完できるリポジトリ側の制御について説明しています。重大な変更の人間による承認と、エージェントが提案を作成する権限は分けてください。レビューエージェントは別の視点を提供できますが、マージの唯一の判断者にしてはいけません。

agentic-autofix レビューガイドでは、関連する受け入れチェックリストを紹介しています。競合が生じた場合は、まず意図された動作を解決してください。契約を説明せずに競合マーカーの削除をモデルに依頼すると、ファイルはきれいになっても、統合後の動作が誤っている可能性があります。

承認された作業を安全に保全し、統合した後で、通常のクリーンアップを行います：

git worktree list
git worktree remove ../agent-docs
git worktree remove ../agent-tests
git branch -d agent/docs
git branch -d agent/tests

拒否を回避するために強制フラグを追加しないでください。作業ツリーに未コミットの変更がある場合や、Gitがマージ済みと判断していないブランチは、調査が必要です。削除するものを決める前に、未完了の変更を保全し、履歴を確認してください。

並列実行中に何を監視すべきか？

タスクの所有者、プロセスの稼働時間、リソース使用量、外部リクエスト、レビュー待ちの結果キューを監視します。タスク終了後もワーカーが動作し続けると、認証情報を使ったり、共有サービスを変更したりする可能性があります。ワーカーの停止方法と、実際に停止したことの確認方法を明確にしてください。

各タスクに適切な予算とエスカレーション条件を設定してください。依存関係の失敗が繰り返された場合、予期しない権限が要求された場合、または範囲外の編集が行われた場合は、無制限に再試行するのではなく調査してください。ログは役立つ内容にとどめつつ、シークレットの値や不要なプライベートコンテンツを記録しないようにしてください。

パーソナルエージェントの権限チェックリストは、アクセスレビューの準備に役立ちます。また、Conductorの移行分析では、作業のポータビリティを保つべき理由も示されています。オーケストレーション製品を変更しても、コミット、タスクの状態、レビューの証拠を引き継ぐ必要があります。

次のバッチを開始する前に、必要に応じて一時認証情報が取り消されていること、バックグラウンドサービスが把握されていること、完了したブランチの処置が決まっていることを確認してください。エージェントの稼働数だけでなく、受け入れられた作業量とレビューにかかる労力を測定してください。統合がボトルネックなら、キューにさらに成果を追加するのではなく、進行中の作業を減らしてください。

クリーンアップの前に、Gitの履歴にないデータについて復元可能なファイルのワークフローを確認してください。未追跡のデータセット、ローカル設定ファイル、外部サービスの状態には、個別の復旧計画が必要になる場合があります。

よくある質問

2つのエージェントが1つのブランチを安全に使えますか？

共有作業の調整は可能ですが、通常は独立したエージェントに別々のブランチと作業ディレクトリを割り当てるべきです。そうしないと、編集内容やテスト結果の帰属がわかりにくくなり、再現も難しくなります。

.envを.gitignoreに追加すれば、エージェントからその内容を保護できますか？

いいえ。無視ルールが制御するのはGitの追跡であり、ファイルシステムの読み取り権限ではありません。不要なシークレットは、ワーカーがアクセスできる環境の外に保管してください。

すべてのエージェントに変更をマージできるトークンを持たせるべきですか？

いいえ。タスクに必要な権限だけを付与してください。変更案を作成する権限と、それを保護されたブランチに取り込む権限は別です。

ワークツリーの削除が拒否された場合はどうすればよいですか？

ディレクトリを調べ、コミットされていない作業や未追跡の作業があれば、重要なものを保全してください。強制操作を日常的なクリーンアップ手段として使わないでください。

各ブランチでテストに合格すれば十分ですか？

変更が相互に影響する場合は不十分です。実際に統合したリビジョンに対して関連するチェックを実行し、境界をまたぐ動作を確認してください。

結論

安全な並行コーディングには、ソースの分離に加えて、実行環境と認証情報の管理が必要です。ワークツリーを使うと変更を分離してレビューしやすくなり、適切に設定した専用権限とサンドボックスによって、エージェントがアクセスできる範囲を制限できます。

クリーンなベースから始め、各タスクに明確な担当者と契約を設定し、レビュー可能な成果だけを統合します。クリーンアップの前に証拠を保全し、一時アクセスを取り消します。調整コストに見合う成果が確認できた場合にのみ、並行作業を拡大します。