GitHub Copilot Appのマルチエージェント設定｜並行開発

GitHub公式ドキュメントでは、GitHub Copilot AppのセッションモードとしてInteractive、Plan、Autopilotの3種類が案内されています。(docs.github.com)

症状： 複数のIssueを同時に処理したいのに、同じファイルを触るAgentが増えてレビューと修正が混乱する。
最短解： 最初は低結合の2タスクだけを別セッション、別ブランチで動かし、実行場所、権限、テスト、マージ担当を先に固定してください。

この手順は、複数のIssueを切り替える個人開発者、バグ・テスト・ドキュメントを並行処理する保守担当者、Agent用の専用算力や共有開発環境を整えたいプラットフォームチーム向けです。コアモジュールを複数Agentで同時に再設計したい段階なら、先に停止条件とレビュー体制を作る必要があります。

最初の2セッションを低結合タスクで組む

GitHub Copilot Appのマルチエージェント運用では、最初から「実装Agentを増やす」より、変更範囲が重ならない仕事を選ぶ方が安全です。候補は、独立したテスト追加、限定的なドキュメント更新、小さな不具合修正です。

たとえば、Session Aには「失敗している単体テストの原因調査と修正」、Session Bには「同じ機能の利用手順の更新」を割り当てます。入力ファイル、変更してよいディレクトリ、禁止事項、完了条件をそれぞれ明記してください。

項目 Session A：不具合修正 Session B：ドキュメント更新
入力 Issue、再現手順、対象テスト 既存仕様、変更後の利用例
変更範囲 実装ファイルと関連テスト READMEやdocs配下
禁止事項 公開APIの変更、依存更新 実装コード、設定ファイル
完了条件 再現テスト成功、差分説明 手順確認、リンク確認
人の確認 ロジックと回帰範囲 技術的な正確性と表現

最初の実行では、各セッションに同じリポジトリを渡しても、作業場所は分けます。GitHubの案内では、セッションごとに独立したワークスペースを作成し、新しいGit worktree、ローカルリポジトリ、クラウドサンドボックスから実行場所を選べます。(docs.github.com)

セッション作成の手順

  1. GitHub Copilot Appを開き、対象リポジトリを選びます。
  2. Sessionsの追加操作から、新しいAgent Sessionを作成します。
  3. Session Aは新しいGit worktree、Session Bも別のGit worktreeを選びます。
  4. それぞれに専用のブランチ名を付け、タスクの入力、禁止範囲、完了条件を書きます。
  5. 最初はPlanで計画を確認し、変更が限定的ならInteractiveへ移します。
  6. テスト結果、変更ファイル、未解決のリスクをセッションの最後に出力させます。
  7. 2つの差分を人が確認してから、PRの作成と統合順を決めます。

GitHub Copilot AppはGitHubのIssueやPull Request、チェック結果とAgent作業を同じ流れで扱える設計です。したがって、セッションの完了をそのままマージ許可と考えず、PRとCIを人の判定地点として残してください。(github.blog)

同じリポジトリの衝突をGit worktreeで抑える

複数のAgentが同じリポジトリを変更すると、物理的なファイル衝突と、意味上の論理衝突が起きます。Git worktreeは前者を抑えるための仕組みであり、同じ関数の責務を別々に変更した結果まで自動的に解決するものではありません。

特に危険なのは、複数Agentが同時に次の領域へ入るケースです。

  • ルーティングや認証など、依存先が多いコアモジュール
  • 共通の型定義やAPIスキーマ
  • マイグレーション、リリース設定、CIの基盤ファイル
  • 大規模な依存パッケージ更新
  • 同じテストフィクスチャを前提にするテスト群

タスクを登録する前に、ファイル責任境界を表にしてください。変更範囲が重なる場合は、並行を止めるか、先に契約となるインターフェースを人が決めます。

状況 選択 理由 停止条件
docsと独立テスト 別worktree 変更範囲が分離しやすい 同じ設定ファイルを触り始めたら停止
UIと同一APIの変更 Plan後に順番実行 契約変更が連鎖する API仕様が未確定なら並行しない
コア実装の再設計 1セッションに限定 論理衝突の確認が難しい Agent同士の設計判断が分かれたら停止
PRレビュー対応とテスト修正 別セッションも可 役割を分けやすい 同じ失敗原因を修正したら統合

コミットは大きな完成品を一度に出させるより、目的が追跡できる単位に分けます。「テスト追加」「実装修正」「ドキュメント更新」を混ぜない方が、PRレビューで返却理由を説明しやすくなります。

Git worktreeの扱いに慣れていない場合は、先にGit worktreeの衝突処理に関する設定ガイドを確認し、作業ディレクトリとブランチの対応を記録しておくと、セッション切り替え時の取り違えを防げます。

注意：worktreeが分かれていても、同じ仕様を別解釈で実装すれば論理衝突になります。ファイルが衝突していないことを、変更が安全である証拠にしないでください。

ローカル、worktree、クラウドの使い分け

Copilot Appの実行場所は、単なる速度比較ではなく、必要なツール、秘密情報、OS、継続時間で決めます。クラウドサンドボックスは分離されたLinux環境で、公開プレビューとして提供されています。(github.blog)

実行場所 向いている仕事 強み 注意点
ローカルリポジトリ 小さな修正、対話的な調査 手元のツールと状態を使いやすい 現在の作業ツリーを汚しやすい
新しいGit worktree 独立した実装、テスト、docs ブランチとファイルを分離できる 論理衝突と依存関係は残る
クラウドサンドボックス 長いテスト、複数タスク、端末をまたぐ作業 ローカル資源を使わず、セッションを継続しやすい Linux前提、公開プレビュー、秘密情報の扱いを確認
macOS上の専用環境 XcodeやmacOS固有のビルド 必要なSDKと署名環境を使える 専用Macの権限、費用、接続方式が必要

「Copilot Appのworktreeとクラウドサンドボックスのどちらを使うか」は、次の条件で決めてください。

  • macOSやXcode、Apple SDK、物理デバイスが必要なら、ローカルまたは管理下のMac環境を選びます。 Linuxのクラウドサンドボックスを代替扱いにしません。
  • 依存関係の導入やテストがLinuxで完結し、手元の作業を軽くしたいなら、クラウドサンドボックスを選びます。
  • 変更を目視しながら細かく指示したいなら、Git worktreeとInteractiveを選びます。
  • 環境の再現性や端末をまたいだ継続が優先なら、クラウド側を候補にします。
  • 秘密情報、社内ネットワーク、未承認の外部サービスが必要なら、組織のポリシーを確認できるまでクラウド実行を止めます。

GitHubはクラウドサンドボックスについて、ローカル資源を使わず複数タスクを並行実行できること、別の端末からセッションを続けられることを説明しています。一方で、公開プレビューであり、仕様や利用条件が変わる可能性は残ります。(github.blog)

複数リポジトリの依存関係を先に固定する

主リポジトリと依存リポジトリを同時にAgentへ渡す場合、先にインターフェース契約を決めます。主リポジトリの呼び出し側を変更してから依存側の実装を変えるのか、依存側の新しい契約を先に用意するのかを曖昧にすると、各Sessionが別の前提で進みます。

推奨する順番は次の通りです。

  1. 主リポジトリと依存リポジトリの現在のブランチ、タグ、コミットを記録します。
  2. API、型、CLI引数、生成物など、両者をつなぐ契約を文章化します。
  3. 依存側の変更が必要なら、契約変更用の小さなPRを先に作ります。
  4. 主リポジトリ側では、固定した契約に対するテストを用意します。
  5. 各Agentに、アクセスしてよいリポジトリと禁止する操作を指定します。
  6. 依存の取得方法を、SSH、トークン、パッケージレジストリなど実際の方式で開始前に検証します。
  7. 片方のPRがマージされるまで、もう片方が未確定のAPIを前提にしないようにします。

複数の非公開リポジトリを読むSessionでは、必要なリポジトリ、ブランチ、パッケージだけを許可します。管理対象のチームでは、2026年7月27日からGitHub Copilot App専用のアクセス制御ポリシーも案内されています。組織で使う場合は、CLIの設定だけでなくApp側のポリシーと利用可能なプラグインを確認してください。(github.blog)

モードとモデルをリスクに合わせる

GitHub Copilot AppにはInteractive、Plan、Autopilotの3モードがあります。Interactiveは確認を挟みながら進める方式、Planは計画を作って承認してから実行する方式、AutopilotはAgentが継続的に作業する方式です。(docs.github.com)

タスクの性質 推奨モード モデル選択の考え方 人が確認する地点
仕様が曖昧な不具合調査 Plan 推論を重視 計画、変更範囲、再現条件
小さなdocs更新 Interactive 軽量なモデルでも可 差分とリンク
独立テストの追加 InteractiveからAutopilot 既存パターンに合うモデル テスト結果と対象範囲
複数手順のCI修正 Plan後にAutopilot 失敗ログを扱えるモデル 権限、実行ログ、PR
DB移行、公開、鍵操作 Interactive 自動選択に任せず慎重に選ぶ 各コマンドの直前

データベース移行、リリース、秘密鍵、未知のインストールスクリプトは、速度を理由にAutopilotへ移さないでください。Copilot CLIの公式説明でも、Autopilotは複数ステップを継続しますが、権限が必要な操作は明示的な許可が関係します。自動化の範囲を広げる前に、作業の可逆性と停止方法を決める必要があります。(docs.github.com)

「高性能モデルを全Sessionに割り当てる」運用も避けます。単純な表記修正や既存テストの横展開は軽いモデル、設計判断や複数モジュールのデバッグは高い推論力を持つモデルというように、仕事の難易度で分けます。GitHubも、タスクの複雑さに応じてモデルとモードを合わせる運用を推奨しています。(docs.github.com)

長時間テストとMac環境の切り分け

「マルチエージェントに必要なローカル資源」は、Agentの数だけで決まりません。リポジトリの大きさ、依存パッケージ、ビルドキャッシュ、テストが利用するデータベース、同時に開く開発ツールで負荷が変わります。

ローカルで複数Sessionを動かす場合は、次の症状が出た時点でクラウドまたは専用Mac環境へ切り替えます。

  • ビルドやテストの待ち時間で、対話的な確認ができない
  • 複数worktreeで依存ファイルやキャッシュが重複する
  • Agentの実行中にエディター、シミュレーター、Dockerなどが不安定になる
  • バッテリー、排熱、ディスク容量が開発作業の停止要因になる
  • 長時間のジョブを端末のスリープや回線切断で失う

ただし、macOS固有のビルド、Xcode、署名、Apple SDK、シミュレーターが完了条件に含まれるなら、Linuxのクラウドサンドボックスだけでは納品条件を満たせません。長いテストをクラウドへ逃がす前に、どの工程がOS固有なのかを分割してください。

リモートのMac環境を候補にする場合は、まず遠隔Macの並行開発環境に関する案内を読み、必要な接続方法、アクセス権、ビルド成果物の回収方法を決めます。長時間ジョブだけを移し、対話的な設計作業は手元に残す分離も有効です。

PR統合と停止条件

各Agent Sessionの終了時には、必ず次の形式で報告させます。

  • 変更したファイルと変更理由
  • 実行したテスト、未実行のテスト
  • 失敗したコマンドと再現条件
  • 既知のリスク、仮定、未解決事項
  • PRに含めるべき変更と、含めない変更

マージ順は、依存関係の下流から決めません。まず契約変更や基盤変更を人が確認し、その後に実装、テスト、ドキュメントの順で差分を再確認します。同じファイルを変更していなくても、APIの意味やテストデータの前提が変わっていれば、先に一方を統合してもう一方をリベースします。

並行開発の評価指標は、起動したAgent数ではありません。次の3点を記録してください。

  • PRで発生した衝突と、衝突を人が解決するまでの理由
  • 返却された主な原因が、仕様不足、テスト不足、実装ミスのどれだったか
  • 人が差分、ログ、セキュリティ上の懸念を確認するのに要した時間

衝突率やレビュー負荷が増えた場合は、同時実行を止めてタスクを直列化します。GitHub Copilot Appのマルチエージェントは、常にAgentを増やす仕組みではなく、依存の少ない仕事を安全に分離する仕組みとして使う方が効果を測りやすいです。

現在の環境からMac環境へ移す判断

手元のMacだけで短い修正を処理するなら、追加環境を借りる必要はありません。一方で、複数のAgent Sessionsを長時間動かすと、ローカルのCPU・メモリ・ディスクを取り合い、端末のスリープや回線切断でジョブが止まり、macOS固有のビルドと通常のLinuxテストを同じ場所で管理しにくくなります。

クラウドLinuxだけに寄せる場合も、Xcodeや署名、Apple SDKを含む工程を別に残す必要があります。そこで、最初の2タスクを終えた後に、ローカル資源の逼迫またはmacOSビルドの待ち時間がボトルネックになった場合だけ、Macstripeのレンタル環境を比較してください。専用のMac環境へ処理を分ければ、手元の作業を止めずに長時間のテストや複数リポジトリのビルドを管理しやすくなります。