こんにちは、家のサーバーのネットワークトラブルを GitHub Copilot に直させようとしているアーキテクトのやまぱんです 😊
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
TL;DR
- GitHub Copilot Agent (VS Code) が 2 台の PC にいて、Git リポジトリ経由でメッセージをやり取り しながらミッションを協調実行するテンプレートを作った
- Copilot Scheduler で定期 pull を組み合わせると 完全自律運転 になる
- 実際に「家 LAN で RDP が突然死んだ問題」を 2 台協調調査して原因特定（犯人は Global Secure Access Client だった）
- テンプレートは公開中 → gh-copilot-multi-agent-mission-board
マルチエージェントとは？
AI が複数の「エージェント」に役割分担させ、互いに連携しながらタスクをこなす仕組みを マルチエージェント（Multi-Agent） または Agent Teams と呼びます。
Microsoft の世界では Copilot Studio のマルチエージェント オーケストレーション (公式ドキュメント) が代表例で、オーケストレーター（司令塔）がサブエージェント（実行担当）に指示を出し、結果を集約します。AutoGen や Azure AI Foundry にも同様の概念があります。
[オーケストレーター]
├── サブエージェント A（調査担当）
├── サブエージェント B（実行担当）
└── サブエージェント C（検証担当）
これらのサービスはクラウド上の API やメッセージバスでエージェント同士が通信する設計のため、企業テナントや専用環境が前提です。個人の PC 同士や、LAN 内で疎通が断たれた 2 台の PC の間で使うにはハードルが高い です。
きっかけ：「疎通が取れない 2 台の PC でも GitHub Copilot を協調させられないか？」
2026 年 2 月、家の LAN 内のおうちサーバー（JAM）に Windows クライアントから突然 RDP できなくなりました。再起動しても治らず、原因がしばらく分からない状態が続きました。
そこでふと思ったのが、「GitHub Copilot を使ったクラウド上のエージェント連携みたいなことを、LAN 内の疎通が取れない 2 台の PC 間でもできないか？」 ということです。どちらの PC もインターネットには繋がっている。それなら Git リポジトリを介してメッセージをやり取りすれば、両方の Copilot Agent が協調できるはずです。
私は GitHub が大好きなので、「Git リポジトリをメッセージ基盤にする」 という発想は自分にとってとても自然でした 😊
その発想で作ったのが GH-Copilot Multi Agent Mission Board です。
GH-Copilot Multi Agent Mission Board のアーキテクチャ
コンセプト：「Git リポジトリ = 掲示板」
一般的なエージェント連携は API や専用メッセージバスで Agent 同士が通信します。
GH-Copilot Multi Agent Mission Board は GitHub リポジトリのファイルを「掲示板」として使うシンプルな仕組み です。
- メッセージは Markdown ファイルとして
missions/<名前>/messages/に保存される - Agent は Git push/pull でメッセージを交換する
- 特定の API も専用サービスも不要 — GitHub へのインターネット接続と GitHub Copilot だけ
ミッション構造
mission-board/
├── missions/
│ └── rdp-fix/ ← ミッション単位
│ ├── GOAL.md ← 目標・タスク一覧
│ ├── PLAN.md ← 担当・スケジュール
│ ├── messages/ ← Agent 間メッセージ
│ ├── scripts/ ← 調査・修復スクリプト
│ └── SUMMARY.md ← 完了サマリー
├── registry.md ← 参加端末一覧（ハートビート）
└── GOAL.md ← アクティブミッション一覧
スラッシュコマンド
| コマンド | 内容 |
|---|---|
/mission <テーマ> |
ミッション自動生成（GOAL.md・PLAN.md 作成） |
/work |
自分担当タスクを PLAN.md に従い自律実行 |
/pull（/sync） |
git pull → 新着読んで対応 → push（一気通貫） |
/post |
ミッション内にメッセージ投稿 |
/check |
ミッション一覧・進捗・未読メッセージ確認 |
/troubleshoot |
新着確認 → 調査 → 結果投稿 → push |
Copilot Scheduler で「完全自律運転」に
Copilot Scheduler は私が作った VS Code 拡張機能で、GitHub Copilot のプロンプトを Cron 式でスケジュール実行できます。詳しくは以前の記事 → ⏰Copilot Scheduler 🚀 GitHub Copilot をスケジュール実行する VS Code 拡張機能を作った
/pull を cron 定期実行することで、このボードを完全自律化できます。
// .vscode/settings.json の例
{
"copilotScheduler.jobs": [
{
"cron": "*/30 * * * *",
"prompt": "/pull",
"mode": "agent"
}
]
}
これを両 PC に設定しておくと：
- PC-A が
/missionでミッション投稿 → push - PC-B が 30 分以内に
/pullを自動実行 → 新着を読んでタスク実行 → push - PC-A が次の
/pullで結果を受信 → 確認・次の指示投稿
VS Code を起動したまま席を外しても勝手に進んでいく。
実際、外出中におおかたの調査が終わっていました 😄
ただし「徹底的に調べる」ためには、それなりのプロンプトやエージェント定義を事前に整備しておく必要があります。ボードはあくまでメッセージ基盤なので、何を調べさせるかは人間が設計する部分です。
実際に使ってみた：RDP 突然死の協調調査
症状
2026-02-21、家の LAN で Windows Server（JAM）への RDP/SMB/SSH が突然全滅。
# ポートは open に見える（偽陽性）
Test-NetConnection <おうちサーバーのIP> -Port 3389 # → True
Test-NetConnection <おうちサーバーのIP> -Port 55555 # → True（未使用ポートなのに！）
# でも mstsc はタイムアウト……
GSA ドライバが NIC レベルで SYN パケットに応答するため、宛先サービスの有無に関わらず
Test-NetConnectionが True を返す偽陽性が発生します（自環境で確認）。
/mission RDP接続復旧 を起票して、おうちサーバー側 Agent に調査を依頼。
2 台の Agent が役割分担して調査
| 端末 | 実施内容 |
|---|---|
| おうちサーバー側 |
pktmon でパケットキャプチャ |
| クライアント端末側 | NIC バインディングや GSA サービス調査 |
おうちサーバー側の調査結果：クライアント端末からの SYN がおうちサーバーの NIC に 一切届いていない → 問題はクライアント側にある。
クライアント端末側の調査結果：
Get-NetAdapterBinding | Where-Object Enabled -eq $true
イーサネット GlobalSecureAccessDriver Global Secure Access ← ！
Microsoft Entra Global Secure Access (GSA) Client が TCP をインターセプトしていた。
Global Secure Access（GSA）とは？
Microsoft Entra の ZTNA（ゼロトラストネットワークアクセス）機能の一部です。クライアント PC に GSA Client（NIC ドライバ）をインストールし、指定したトラフィックを Microsoft クラウド経由でトンネリングします。設計上はインターネット・M365・プライベートアクセス向けですが、Traffic Forwarding の設定によってはローカル LAN 宛のパケットも巻き込む ことがあります（Traffic forwarding profiles | Microsoft Learn）。
GSA サービスを停止 → 偽陽性が消え → mstsc 接続成功。原因確定。
暫定対処スクリプト
# Toggle-GSA.ps1（管理者権限で実行）
param([ValidateSet("pause","resume","rdp","status")][string]$Action = "status")
$services = @(
"GlobalSecureAccessTunnelingService",
"GlobalSecureAccessEngineService",
"GlobalSecureAccessForwardingProfileService"
)
switch ($Action) {
"pause" { $services | ForEach-Object { Stop-Service $_ -Force -ErrorAction SilentlyContinue } }
"resume" { $services | ForEach-Object { Start-Service $_ -ErrorAction SilentlyContinue } }
"rdp" {
$services | ForEach-Object { Stop-Service $_ -Force -ErrorAction SilentlyContinue }
Start-Process mstsc -ArgumentList "/v:<おうちサーバーのIP>" -Wait
$services | ForEach-Object { Start-Service $_ -ErrorAction SilentlyContinue }
}
"status" { $services | ForEach-Object { Get-Service $_ } | Select-Object Name, Status }
}
一旦 LAN に繋ぐだけなら、GSA のプライベートネットワークアクセスを一時的に無効化すれば OK でした。
上記スクリプトの pause / rdp アクションがまさにそれです。
恒久対応（LAN を常時 bypass させる設定）は Entra 管理センターの Traffic Forwarding ポリシーで対応できると思いますが、テナント管理者権限が必要になるかと思います。
2 台が「おうちサーバー側キャプチャ ⇔ クライアント端末側調査」を同時並行でほったらかし実施できたのが早期原因特定につながりました。「手が離せない間も Agent が勝手に調査を進めてくれる」というのが GH-Copilot Multi Agent Mission Board の一番の使用感でした 😊
使い方
👉 gh-copilot-multi-agent-mission-board
テンプレートリポジトリなので、Use this template で自分のリポジトリを作成して自由に使ってください！
ライセンスは CC BY-NC-SA 4.0（表示・非営利・継承）です。改変・公開の際はクレジット表記をお忘れなく 🙏
前提条件
- VS Code + GitHub Copilot（Agent mode 対応プラン）
- Git
- GitHub アカウント（リポジトリの push/pull 権限）
- （任意）GitHub CLI — テンプレートからのリポジトリ作成が楽になる
- （推奨）Copilot Scheduler —
/pullの定期自動実行 -
Auto-approve 設定（重要）：Agent mode はファイル編集・ターミナル実行のたびに確認ダイアログが出る。自律で動かすには VS Code の設定
chat.tools.autoApproveを有効にしておく必要がある（Settings で「Auto-approve tools」で検索）
クイックスタート
# 1. テンプレートから自分のリポジトリを作成
gh repo create my-mission-board --template aktsmm/gh-copilot-multi-agent-mission-board --clone
cd my-mission-board
# 2. registry.md に参加端末を記入してコミット・プッシュ
# 3. もう一台の PC でも同じリポジトリをクローン
# 4. 両 PC で VS Code を開き、Copilot Scheduler を設定
まとめ
| 項目 | 内容 |
|---|---|
| 仕組み | Git リポジトリをメッセージ掲示板として Copilot Agent が協調 |
| 追加インフラ | Git + GitHub のみ（専用 API・サービス不要） |
| 自律化 | Copilot Scheduler で /pull を定期実行 |
| 実証 | GSA 起因の RDP 全滅を 2 台協調で原因特定・暫定回避 |
「Agent Teams を個人環境で試したい」「複数 PC の GitHub Copilot に調査させたい」という方はぜひ使ってみてください！