GitHub Copilot の Local・Copilot・Cloud の使い分けと検証エージェント設計

GitHub Copilot（以下、Copilot）を使い続けていると、ある時から「書いてもらうこと」より「書かれた内容が妥当か確認すること」の方が重くなってきます。

最近の LLM は、変更できる範囲も、一度に扱える情報量も増えました。その結果、人が Copilot Chat の回答、変更差分、テスト結果を毎回すべて読み直す運用では、AI が速くなるほど確認する側が忙しくなります。

そこで重要になるのが、モデルを選ぶことだけではなく、どの Agent Harness（エージェントハーネス）で動かし、誰に実装させ、誰に検証させるかを設計することです。

この記事では、Visual Studio Code（以下、VS Code）の Session Target にある Local、Copilot、Cloud の違いを整理します。その上で、VS Code 内で対話しながら進める場合と、Copilot CLI（以下、CLI）を使って独立した検証エージェントに任せる場合の、チェックの進め方を比較します。

目次

• 先に結論
• Local・Copilot・Cloud は同じ軸の名前ではない
• Local と Copilot はどちらも開発 PC 上で動く
• VS Code 内の対話は人が確認に加わりやすい
• CLI ではチェックを独立した仕事にしやすい
• チェックエージェントを作るだけでは足りない
• 実装と検証を分ける最小構成
• マルチエージェント化する判断基準
• 人が確認する量をどう減らすか
• まとめ

先に結論

Local、Copilot、Cloud は、単純な「ローカルかクラウドか」の 3 択ではありません。

• Local は、VS Code の Extension Host で動く組み込みハーネスです。現在のワークスペースと、VS Code や拡張機能が提供するツールを密接に使う対話に向いています
• Copilot は、開発 PC 上の Agent Host で動く Copilot ハーネスです。現在のフォルダーに加え、Git worktree、バックグラウンドセッション、複数チャットなど、自律的な作業を分離して進める機能に向いています
• Cloud は、利用可能な Cloud Agent をリモート環境で動かすターゲットです。GitHub リポジトリを対象に独立して作業し、変更を Pull Request として受け取る仕事に向いています

そして、チェック疲れを減らす本質は、VS Code から CLI へ操作画面を変えることではありません。

つまり、会話の中で同じエージェントへ「もう一度チェックして」と頼む状態から、独立したコンテキストと観測可能な完了条件を持つ検証工程へ移すことが重要です。

Local・Copilot・Cloud は同じ軸の名前ではない

VS Code の公式ドキュメントでは、Agent Harness はツール呼び出し、コンテキスト、コード変更など、エージェントセッションを調整する仕組みと説明されています。

VS Code のハーネス選択ガイドでは、Session Target を次のように整理しています。

ここで紛らわしいのは、Local だけがローカル実行という意味ではないことです。Copilot、Claude、Codex も開発 PC 上で動かせます。Local は実行場所の総称ではなく、VS Code 組み込みハーネスの名前です。

また、ツールの実行場所と LLM のホスティング先は別です。開発 PC 上のファイルを読み、ローカルのターミナルでテストを実行していても、推論リクエストはホストされたモデルへ送られる場合があります。Local を選んだだけでモデル処理までローカルになるわけではありません。

Local と Copilot はどちらも開発 PC 上で動く

Local と Copilot の違いは、場所よりも実行基盤とセッションの性格にあります。

VS Code Agent Host の公式説明によると、Agent Host はエージェントを Extension Host から分離した専用プロセスです。複数のクライアントから同じセッションを扱うこと、Editor が接続されていない間も処理を続けること、複数の Agent Runtime を共通のセッションとして扱うことを目的としています。

どちらが上位という関係ではありません。VS Code の診断、ブラウザー、拡張機能固有のツールを使いながら一緒に考えたいなら Local が適しています。実装や検証を独立したセッションへ分け、必要なら worktree で変更を隔離したいなら Copilot が扱いやすくなります。

VS Code 内の対話は人が確認に加わりやすい

VS Code 内の Copilot Chat では、人と AI が一つの文脈を共有しながら進められます。

たとえば、画面を見て「この余白は少し広い」「この表現は自分らしくない」と返し、その場で修正してもらう流れです。正解を先に決めにくい UI、文章、設計の探索では、この近さが大きな利点です。

一方で、同じ会話の中で実装とレビューを繰り返すと、次の問題が起きます。

• 実装時に置いた前提を、レビュー時にも引き継ぐ
• 長い会話の中に、現在の要求と古い判断が混在する
• 「変更した本人」が、自分の意図に沿って差分を説明する
• 人が会話、差分、コマンド出力を順番に確認する必要がある

これは VS Code 内の Copilot Chat が弱いという話ではありません。発見のための会話と、反証するためのレビューでは、必要なコンテキストが違うという話です。

VS Code 内の対話は、次のようなチェックに向いています。

• 実際の画面を一緒に見て、見た目や操作感を判断する
• VS Code の診断や拡張機能固有の解析結果を使う
• 未コミットの変更を含む現在のワークスペースを確認する
• 人が途中で方向を変えながら、探索的に修正する

ここでは人が Human-in-the-loop として深く参加します。チェック結果は合否だけではなく、次に何を作るかを決める材料にもなります。

CLI ではチェックを独立した仕事にしやすい

CLI の強みは、ターミナル表示そのものではありません。検証を再実行可能なコマンドと、独立したエージェントの仕事として切り出しやすいことです。

GitHub の公式ドキュメントでは、CLI から /review で変更をレビューでき、対象パスや追加の観点を指定できると説明されています。

また、CLI のカスタムエージェントは、一時的な SubAgent として実行され、メインエージェントとは別の Context Window を持ちます。大きな作業の一部を別コンテキストへ移し、メインエージェントは計画と調整へ集中できます。

この性質は、チェック役と相性が良いです。

メインセッション
  ├─ 実装エージェント：要求を実装する
  ├─ レビューエージェント：要求と差分だけを読む
  └─ 検証エージェント：決められたコマンドを実行し、失敗原因を要約する

CLI では、カスタムエージェントを .github/agents/*.agent.md または ~/.copilot/agents/*.agent.md として定義できます。明示的にエージェントを指定するだけでなく、説明に合う仕事を Copilot が推論して SubAgent へ委任することもできます。

ただし、CLI を使えば回答が自動的に正しくなるわけではありません。同じ曖昧な要求を渡せば、チェック結果も曖昧になります。CLI で改善できるのは、誰が、何を入力として、どの証拠を使い、何を出力するかを固定しやすい点です。

チェックエージェントを作るだけでは足りない

レビューエージェントへ「内容が妥当かチェックして」とだけ頼むと、もっともらしい感想が返ってくるだけになりがちです。

チェック役には、少なくとも次を定義します。

特に重要なのは、LLM のレビューと実行可能な検証を分けることです。

• LLM が得意な確認：要求の抜け、設計上の矛盾、読みやすさ、未知のリスク候補
• ツールが得意な確認：ビルド、テスト、型検査、Lint、依存関係監査、ブラウザー操作
• 人が担う確認：目的への適合、UX の好み、許容できるリスク、費用、公開判断

LLM に「テストが通りそうか」を推測させるのではなく、テストを実行させます。テストが通ったことだけで要件を満たしたと判断せず、別のレビューエージェントに要件との対応を確認させます。

実装と検証を分ける最小構成

最初から多数のエージェントを並列実行する必要はありません。まずは実装役とレビュー役を分けるだけでも効果があります。

1. 人が目的、外せない条件、完了条件を決める
2. 実装エージェントが変更し、対象テストを実行する
3. 独立したレビューエージェントへ要求と差分を渡す
4. レビュー結果に基づいて実装エージェントが修正する
5. 検証コマンドを再実行する
6. 人は重要な指摘、証拠、残余リスクを確認する

レビュー役には、実装中の長い会話をそのまま渡さない方が効果的です。必要なのは、なぜその実装を選んだかという自己説明より、要求、制約、実際の差分、テスト結果です。

CLI でカスタムエージェントを明示する場合は、たとえば次のように呼び出せます。

copilot --agent change-reviewer --prompt "Issue の要求と現在の差分を照合し、重大度順に指摘して。コードは変更せず、各指摘に証拠を付けて"

複数の独立した作業を並行化できる場合、CLI には SubAgent へ仕事を分ける /fleet もあります。ただし、同じファイルを変更する仕事や、判断が互いに依存する仕事を無理に並列化すると、統合コストが増えます。

最初は、次の 3 役で十分です。

ビルドやテストの出力が大きい場合だけ、結果を要約する Validator を追加します。

マルチエージェント化する判断基準

エージェントの数を増やせば、品質が比例して上がるわけではありません。分離する価値があるのは、役割によって必要なコンテキスト、ツール、評価基準が違う場合です。

GitHub Copilot Cloud Agent の公式説明によると、Cloud Agent は GitHub Actions ベースの一時的な開発環境で、リポジトリの調査、変更、テストを行います。GitHub 上で処理が進むため、開発 PC を起動し続ける必要はありません。出発前にタスクを委任し、移動中に作業を任せ、到着後に結果を確認する使い方もできます。

ただし、ローカルの未コミット変更、開発 PC にしかないファイルやサービス、対話中の画面が必要なタスクには向きません。Issue とリポジトリだけで完結し、チームが PR でレビューできるタスクなら、人の作業から切り離して進められます。

人が確認する量をどう減らすか

人の確認をゼロにすることが目標ではありません。人が読む対象を、生成物の全量から意思決定に必要な差分へ変えることが目標です。

レビューエージェントの最終出力を、次の形に固定すると確認しやすくなります。

判定: pass / pass with risks / fail

重要な指摘:
- 重大度、場所、問題、根拠、修正案

実行証拠:
- 実行したコマンドと結果

未確認事項:
- 実行環境がなく確認できなかったこと

人の判断が必要:
- UX、費用、公開、破壊的変更など

ここまで整えると、人は数百行のログを読む代わりに、失敗したチェックと判断が必要な点へ集中できます。

以前の記事「Human-in-the-loop と Loop Engineering を組み合わせる Memolog の AI 開発」では、人と AI が正解を発見する外側のループと、AI が実装と検証を繰り返す内側のループを整理しました。

今回のハーネス選択と検証エージェントの分離は、その内側のループを具体的に設計する方法です。

• Local で人と AI が目的や違和感を発見する
• Copilot または CLI で、実装と検証を独立した仕事へ分ける
• Cloud へ渡せるほど境界が明確な仕事は、Issue と PR の単位で委任する
• 証拠が不足した場合や重要な判断が必要な場合は、人へ戻す

この境界を設計することが、Human-in-the-loop から Human-on-the-loop、さらにマルチエージェントへ踏み出すときの土台になります。

まとめ

Local、Copilot、Cloud の違いは、単なる画面や実行場所の違いではありません。どのハーネスがセッションを調整し、どこでツールを動かし、どのように変更を分離するかの違いです。

• Local は、VS Code と密接につながった対話と探索に向く
• Copilot は、Agent Host を使ったバックグラウンド実行、worktree、複数セッションに向く
• Cloud は、GitHub 上で独立して処理し、PR として受け取る仕事に向く
• CLI は、チェックを再実行可能なコマンドと独立した SubAgent へ分けやすい
• CLI に変えるだけでは妥当性は保証されず、入力、観点、証拠、出力、停止条件の設計が必要
• 実装者とレビュー担当のコンテキストを分け、テストは推測せず実行する
• 人は全出力ではなく、重要な指摘、実行証拠、未確認事項、残余リスクを確認する

LLM が賢くなるほど、人がすべての出力を細かく追い続ける方法は苦しくなります。次に必要なのは、さらに注意深く読むことだけではありません。

AI が検証できる仕組みを作り、その証拠と例外を人が判断することです。モデルへの指示から、エージェントが働くハーネスとループの設計へ視点を移すと、Copilot は「確認するものを増やす相手」から「確認可能な仕事を分担するチーム」へ変わります。