DevOps on hagizo.io

GitHub CopilotはVS CodeとCLIをどう使い分けるべきか: auto・クレジット・実務フロー整理

Thu, 30 Apr 2026 14:00:00 +0900

GitHub CopilotはVS CodeとCLIをどう使い分けるべきか

GitHub Copilot を使い込むほど、VS Code の拡張機能を軸にするか、Copilot CLI を軸にするかで迷います。両者は競合ではなく、編集中心かターミナル中心かで役割が分かれます。

導入

現場でよくあるのは、次のような迷いです。

エディタ内の修正は VS Code Copilot で十分なのか。
それとも Copilot CLI で一気に流したほうが速いのか。
auto は VS Code だけなのか、CLI でも使えるのか。
クレジット消費は IDE と CLI で変わるのか。

このあたりを曖昧なまま使うと、作業フローが毎回ぶれます。この記事では、VS Code Copilot と Copilot CLI の違い、auto モデル選択、プレミアムリクエストの考え方、シーン別の使い分けを、実務前提で短く整理します。

TL;DR

まず結論です。

エディタ内の細かい編集、差分確認、反復リファクタは VS Code Copilot が向いています。
ターミナル中心の調査、コマンド実行、ディレクトリ単位の変更、SSH 先やコンテナ内の作業は Copilot CLI が向いています。
auto は VS Code の Copilot Chat でも、Copilot CLI でも使えます。
クレジット消費は「IDE か CLI か」ではなく、どのモデルを使い、どれだけリクエストを発生させたかで決まります。

最初に押さえるべき完成形は次の 3 つです。

# 1. Copilot CLIで一時的にautoを使う
copilot --model auto -p "プロジェクトの設定差分を確認して改善点を提案して"

# 2. 対話モードでautoへ切り替える
/model auto

# 3. CLIでカスタムプロバイダー利用時に環境変数でモデル指定する
export COPILOT_MODEL=auto

GitHub Copilotの違い

VS Code Copilot は、Copilot Chat のモデル選択 UI やチャット応答のホバー確認など、エディタに統合された形で使う前提です。差分や修正結果を視覚的に追いやすく、小さく直して確認するループに強みがあります。

一方の Copilot CLI は、対話型とプログラム実行の両方を持ち、ターミナルから直接コード変更、Git 操作、GitHub 上の PR・Issue 操作まで扱えます。信頼済みディレクトリや許可ツールの概念があり、ローカルだけでなくコンテナや SSH 環境でも同じ操作感を持ち込みやすいのが特徴です。

使い分けの早見表

観点	VS Code Copilot	Copilot CLI
主戦場	エディタ内の編集とレビュー	ターミナル内の操作と自動化
得意な作業	小刻みな修正、差分確認、会話しながらの実装	コマンド実行、ログ調査、ディレクトリ単位の変更
モデル選択	モデルピッカーから `Auto` を選択	`/model` または `--model` で変更
実行場所	主に IDE 内	ローカル、WSL、macOS、Linux のターミナル
安全性の勘所	差分を見ながら止めやすい	信頼済みディレクトリとツール許可管理が重要

autoモデル選択

auto は VS Code でも CLI でも使えます。GitHub Docs では、Copilot Chat の IDE 利用時に Auto を選ぶと、利用可能なモデルからポリシーと契約に応じて自動選択すると説明されています。

CLI 側でも Auto が使え、利用した応答ごとに実際に使われたモデルがターミナルに表示されます。モデル候補は今後変わる可能性があるため、固定モデルが必要な作業だけ明示指定する運用が実務では安定します。

VS Codeでautoを使う手順

Copilot Chat を開く、理由はモデル選択 UI がここにあるためです。
モデルピッカーから Auto を選ぶ、理由は毎回モデルを意識せずに使えるためです。
応答ごとに使用モデルを確認したい場合は、レスポンス上でホバーする、理由は実際のルーティング先を確認できるためです。

Copilot CLIでautoを使う手順

単発実行で使う場合は --model auto を付ける、理由はその場だけ auto に切り替えられるためです。
対話モードでは /model を使って切り替える、理由は会話中にモデル戦略を変えられるためです。
実際の利用モデルはターミナル表示で確認する、理由は auto が常に同じモデルを選ぶとは限らないためです。

実務でそのまま使う例です。

# 単発の調査
copilot --model auto -p "このリポジトリのテスト失敗原因を調査して"

# 対話モード開始
copilot
# 対話中に入力
/model auto

補足です。GitHub Docs で COPILOT_MODEL 環境変数は、独自のモデルプロバイダーを使う場合の設定項目として説明されています。標準の GitHub ホストモデルを常時 auto に固定する用途は、まず CLI のモデル選択機能と最新リリースノートで確認するのが安全です。

クレジット消費

プレミアムリクエストは、使った機能とモデルの multiplier に基づいて消費されます。GitHub Docs では CLI でも、プロンプト送信ごとにモデル一覧の括弧内 multiplier 分だけ毎月のプレミアムリクエスト枠が減ると説明されています。

そのため、VS Code だから安い、CLI だから高い、とは言い切れません。コスト差の本体は、どのモデルを選んだか、そして 1 タスクの裏で何回リクエストが走ったかです。

実務で差が出るポイント

VS Code Copilot は、小さい修正を複数回に分けて投げやすいです。結果として、1 回あたりの制御はしやすい一方で、往復回数は増えやすくなります。
Copilot CLI は、対話型でもプログラム実行でも大きめの仕事をまとめて依頼しやすいです。コード変更やシェル実行まで進むため、1 タスクあたりの総消費が見えにくくなることがあります。
auto には paid plan の Copilot Chat で 10% の multiplier discount があると GitHub Docs に明記されています。ただしこの割引説明は Copilot Chat 向けで、CLI に同じ条件がそのまま適用されるとは限らないため、課金判断は最新ドキュメント基準で見るべきです。

コストを抑える運用

VS Code では、関数単位・ファイル単位で区切って投げる、理由は差分確認で不要な広がりを止めやすいためです。
CLI では、いきなり --allow-all-tools で広く任せない、理由は変更範囲と副作用が大きくなりやすいためです。
大きい変更は CLI に下書きさせて、最終レビューと細部調整は VS Code で行う、理由は生産性と制御のバランスがよいためです。

実務フロー

おすすめは、VS Code と Copilot CLI を分業させる形です。設計相談、差分確認、局所的な修正は VS Code に寄せ、ログ調査、設定変更、リポジトリ横断の作業は CLI に寄せると迷いが減ります。

VS Code Copilotを選ぶ場面

複数ファイルをまたぐが、差分を目で追いながら進めたいとき。
テスト追加、軽いリファクタ、関数単位の修正を高速に回したいとき。
モデルを意識しすぎず Auto で会話し、必要時だけ実モデルを確認したいとき。

Copilot CLIを選ぶ場面

SSH 先、コンテナ、WSL、Linux/macOS ターミナルで完結したいとき。
ログ解析、設定ファイル整理、Git 操作、PR 作成のようにシェルと GitHub 操作が近いとき。
リポジトリ内のまとまった変更を一気に進めたいとき。

両方を組み合わせる形

VS Code でワークスペースを開く、理由は差分確認と最終編集を速くするためです。
統合ターミナルから Copilot CLI を起動する、理由はそのままプロジェクト文脈を渡せるためです。
CLI に大きめの変更を依頼する、理由は初速を上げるためです。
VS Code 側で差分を確認して局所修正する、理由は品質を落とさずに仕上げられるためです。

ハマりどころ

auto は便利ですが、選ばれるモデルは時間やポリシーで変わります。再現性が必要な検証では固定モデルを使うほうが安全です。
Copilot CLI は信頼済みディレクトリと許可ツールの設計を誤ると、意図しない変更を広げやすいです。特に --allow-all-tools は限定環境で使うべきです。
COPILOT_MODEL を見て標準 CLI 全体の常設設定だと解釈しがちですが、ドキュメント上は独自プロバイダー設定の文脈です。標準運用では /model、--model、最新リリースノート確認を優先したほうが混乱しません。

まとめ

VS Code Copilot は、編集、差分確認、細かい反復に強いです。Copilot CLI は、ターミナル中心の調査、自動化、大きめの変更に強いです。

重要なのは、どちらか一方に寄せ切ることではありません。auto とプレミアムリクエストの仕組みを理解したうえで、作業粒度ごとに役割を分けると、Copilot の強みを無駄なく引き出せます。

普段の開発で「この作業は VS Code」「この作業は CLI」と先に線引きしておくと、判断の迷いが減ります。その結果、AI を使う時間そのものよりも、実装とレビューに使える時間を増やしやすくなります。

【AI開発】GitHub Copilotで自分用エージェントを作る考え方

Wed, 22 Apr 2026 01:32:00 +0900

前回は、エージェントAIの設計パターンを「ゴールと計画」「推論と自己改善」「協調」「安全性ガード」の4レイヤで整理しました。今回はその考え方を、GitHub Copilotで実際に使える形へ落とし込みます。ポイントは、Copilotを単なる補完ツールではなく、指示、ツール、権限、検証手順を与えた「開発ワークフロー用エージェント」として設計することです。

Copilotで作れるエージェントの種類

まず、Copilotには大きく2つの使い方があります。VS CodeなどのIDEで使うagent modeと、GitHub上で動くCopilot cloud agentです。GitHub Docsでは、cloud agentはリポジトリを調査し、実装計画を作り、ブランチ上で変更し、必要に応じてPull Requestを作れると説明されています。About GitHub Copilot cloud agent

一方、VS Codeのagent modeはローカル開発環境の中で動く自律的なペアプログラマです。VS Codeのブログでは、agent modeはコードベースを分析し、ファイル編集を提案し、ターミナルコマンドを実行し、コンパイルやlintエラーを見て修正ループを回せると説明されています。VS Code Agent mode

ざっくり分けると、ローカルで一緒に試行錯誤するならIDEのagent mode、IssueやPR単位で非同期に任せるならcloud agentが向いています。

1. ゴール定義はプロンプトとinstructionsで作る

エージェント設計の最初の層は、曖昧な依頼を実行可能なタスクへ変換することです。Copilotでは、ここをプロンプトとcustom instructionsで作ります。

リポジトリ全体の前提は .github/copilot-instructions.md に書けます。GitHub Docsでは、リポジトリ全体のcustom instructionsとしてこのファイルを作り、プロジェクト構造、ビルド方法、テスト方法、コーディング規約などをMarkdownで記述できると説明されています。Adding repository custom instructions

たとえばDevOps系リポジトリなら、次のような情報を入れておきます。

# Repository instructions

- 変更前に対象サービス、環境、影響範囲を確認する
- CI/CD関連の変更では `.github/workflows/` と `scripts/` を必ず確認する
- 破壊的操作や本番反映は実行せず、計画と差分だけ提示する
- 変更後は `make test` と `make lint` を実行する

これは、前回の記事でいうPassive Goal CreatorとGuardrailsを、Copilot向けの常時コンテキストとして実装しているイメージです。

2. パス別instructionsで役割を分ける

リポジトリ全体の指示だけだと、フロントエンド、バックエンド、インフラ、ドキュメントでルールが混ざります。そこで .github/instructions/*.instructions.md を使います。GitHub Docsでは、applyTo frontmatterで対象パスを指定するpath-specific custom instructionsを作れると説明されています。Adding repository custom instructions

たとえばHugoブログなら、記事用のinstructionsを次のように分けられます。

---
applyTo: "content/posts/**/*.md"
---

# Blog post rules

- frontmatterには title, slug, draft, date, tags, categories, description を含める
- 本文では h1 を使わず、h2/h3 で構成する
- 外部情報を使った場合はMarkdownリンクで出典を残す
- draft は明示がなければ false にする

これにより、Copilotは「記事編集時のエージェント」と「コード編集時のエージェント」で振る舞いを変えやすくなります。

3. custom agentsで専門エージェント化する

さらに踏み込むなら、custom agentsを使います。GitHubのcustomization cheat sheetでは、custom agentsは独自のinstructions、tool restrictions、contextを持つ専門ペルソナで、.github/agents/AGENT-NAME.md などに置けると整理されています。Copilot customization cheat sheet

たとえば、次のようなエージェントを用意できます。

docs-writer: README、ADR、ブログ記事、リリースノートを書く
test-generator: 既存コードを読んでユニットテストを追加する
ci-debugger: GitHub Actionsの失敗ログを読み、再現手順と修正案を出す
security-reviewer: 依存関係、権限、シークレット混入を確認する

これは、前回の4レイヤでいう「協調」レイヤです。最初から巨大な万能エージェントを作るより、役割ごとに分けるほうがレビューしやすくなります。

4. MCPでツールを増やす

Copilotを本当のエージェントらしくするには、外部ツールへのアクセスが重要です。GitHub Docsでは、MCPを使うとCopilot agent modeが外部データソース、API、ツールへアクセスでき、調査、計画、実装、検証のループを回しやすくなると説明されています。Enhancing GitHub Copilot agent mode with MCP

開発者向けには、まず次のようなMCPサーバから始めるのが現実的です。

GitHub MCP: Issue、PR、ブランチ、Actionsの情報を見る
Playwright MCP: UIを操作してE2Eやアクセシビリティを確認する
Figma MCP: デザイン仕様を読み、実装との差分を確認する
独自MCP: 社内API、ログ、メトリクス、デプロイ情報を読む

MCPを足すときは、いきなり全部つなげないほうが安全です。公式ドキュメントでも、目的に合うサーバを選び、シンプルに始め、接続確認をしてからagent modeのタスクに使うことが推奨されています。Enhancing GitHub Copilot agent mode with MCP

5. 変更前にフェーズを分ける

Copilotにいきなり「全部直して」と頼むと、どの設計判断が正しかったのか追いづらくなります。おすすめは、Research、Plan、Implement、Validateの4フェーズに分けることです。

1. Research: まず関連ファイル、Issue、CIログを調べて、原因候補を列挙して。まだ変更しない。
2. Plan: 修正方針を2案出し、リスク、影響範囲、検証方法を比較して。
3. Implement: 採用した方針で最小差分を実装して。関係ない整形はしない。
4. Validate: テスト、lint、手動確認項目を実行し、結果をまとめて。

これはPlan & Execute、Prompt Chaining、Evaluator-OptimizerをCopilot上で手動フェーズ化したものです。特に本番系やCI/CD系の変更では、「まだ変更しない」「PRを作る前に計画だけ出す」「破壊的操作はしない」と明示するだけで事故を減らせます。

最小構成のおすすめ

まず作るなら、次の3点で十分です。

1つ目は .github/copilot-instructions.md です。リポジトリ概要、セットアップ、テスト、禁止事項、レビュー観点を書きます。

2つ目は .github/instructions/ です。frontend.instructions.md、backend.instructions.md、docs.instructions.md のように、パスごとのルールを分けます。

3つ目はMCPを1つだけ足すことです。GitHub連携かPlaywright連携のように、普段の開発で効果が見えやすいものから始めます。

この構成なら、単一エージェントでも「ゴール定義」「推論と実行」「安全性ガード」までかなり表現できます。必要になったタイミングで、custom agentsやagent skillsを追加し、docs-writer、ci-debugger、security-reviewerのような専門エージェントへ分割すればよいです。

Copilotでエージェントを作るとは、特別なAI基盤を最初から作ることではありません。自分の開発プロセスを、instructions、prompt、agent、MCP、承認フローとして明文化することです。設計パターンを意識してCopilotに渡す文脈を整えるほど、単なる補完ツールから、頼れる開発パートナーに近づいていきます。

【AI開発】エージェントAI設計パターンを4レイヤで整理する

Wed, 22 Apr 2026 01:19:00 +0900

前回は、エージェントAIの基本パターンとして ReAct、Reflection、Planning、Multi-Agent をざっくり整理しました。今回はもう一歩踏み込み、実装時に「どの責務をどの層に置くか」という視点で、設計パターンを4つのレイヤに分けて考えます。

1. ゴールと計画のレイヤ

最初に切り出すべきなのは、ユーザーの曖昧な依頼を実行可能なタスクへ変換する層です。DeepSquareの記事では、Passive Goal Creator と Proactive Goal Creator が、目標設定と計画生成のパターンとして紹介されています。Yue Liu氏らのAIエージェントデザインパターン解説では、ユーザーの明示的な指示を対話で明確化する方式と、コンテキストからエージェント側が目標を提案する方式が整理されています。

開発者視点では、この層は「タスク定義器」です。入力は自然言語でも、出力は goal、constraints、success_criteria、allowed_tools のような構造化データにしておくと、後続の実行層が安定します。

計画生成では、Plan & Execute、Single-path Plan Generator、Multi-path Plan Generator を使い分けます。Google Cloudのガイドも、パターン選定ではタスクの複雑さ、レイテンシ、費用、人間の関与を評価すると説明しています。Google Cloudの設計パターン比較単純なCRUDならSingle-pathで十分ですが、仕様策定や技術調査のように正解が一つでないタスクでは、複数案を出して比較する価値があります。

2. 推論と自己改善のレイヤ

次の層は、計画を実際の推論と行動に落とし込む部分です。Anthropicの設計ガイドを要約した記事では、Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer といったワークフローが紹介されています。効果的なAIエージェント設計方法の整理を見ると、いきなり自律エージェントにするより、まず工程を分けて安定させるのが現実的です。

Prompt Chainingは「要件整理、設計、実装、テスト」のようにフェーズを分けるパターンです。ReActは、思考、ツール実行、観察を繰り返すループです。実装では、1回のLLM呼び出しにすべてを詰めるより、状態を短く保ち、各ステップでツール結果を観察させるほうが失敗を回収しやすくなります。

品質を上げたい場合は、Self-Reflective または Evaluator-Optimizer を足します。Qiitaの設計パターン整理では、Self-Reflectiveは軽量な自己内省、Evaluator-Optimizerは生成と評価を分離するループとして扱われています。AIエージェントデザインパターン完全ガイドコード生成ならテスト、文章生成ならチェックリスト、調査なら出典の網羅性を評価軸にすると、単なる「もう一回考えて」よりも効果が出ます。

3. 協調のレイヤ

単一エージェントが大きくなりすぎたら、協調レイヤを導入します。Orchestrator-Workersは、中央のオーケストレータがタスクを分解し、調査、実装、レビューなどのワーカーに渡す構成です。Weights & Biases Japanの記事では、Planning と Multi-Agent Collaboration の組み合わせが、論文調査や分析、執筆のような複雑タスクに向く例として説明されています。AIエージェントのデザインパターン

協調パターンには、役割ベース、投票ベース、討論ベースがあります。役割ベースはソフトウェア開発と相性がよく、プランナー、実装者、レビューアを分けるだけでも責務が明確になります。投票ベースは不確実な分類や候補選定に向き、討論ベースは戦略判断のように反論が価値を持つ場面で使います。

ただし、マルチエージェントは万能ではありません。共有状態、書き込み権限、失敗時のリトライ、最終判断者を決めないまま導入すると、単一エージェントよりデバッグが難しくなります。まず単一エージェント＋ツールで詰まりを見つけ、明確なボトルネックが出たところだけ分割するのが安全です。

4. 入出力と安全性ガードのレイヤ

最後の層は、入出力と安全性を制御する部分です。Zennの記事では、最小構成から始めること、マルチレイヤのガードレール、人間の介入、ツール定義の標準化が強調されています。失敗しないAIエージェント設計

Guardrailsは、プロンプト、ツール呼び出し、最終出力をチェックする仕組みです。社内API、個人情報、削除や送信のような不可逆操作を扱うなら、ルールベースの検証、人間承認、操作ログを必ず入れます。

Agent Adapterも重要です。LLMから見るツールインターフェイスを統一しておくと、裏側のAPIやモデルを差し替えてもワークフロー全体を壊しにくくなります。引数名、入力形式、失敗時の戻り値、権限境界まで含めて設計することで、ツール誤用を減らせます。

実装時の最小構成

実務で始めるなら、最初の構成は大きくしすぎないほうがよいです。おすすめは、ゴール定義器、Plan & Execute、ReAct風ツールループ、軽いEvaluator、Guardrails、Adapterの組み合わせです。

たとえばDevOps自動化なら、まずユーザー依頼を「対象サービス、環境、許可された操作、成功条件」に正規化します。次に、調査、変更案作成、確認、実行、検証というPlanを作ります。各ステップではログ検索、CI確認、設定ファイル編集などのツールを呼び、最後にEvaluatorが「本当に成功条件を満たしたか」を確認します。デプロイや削除のような操作だけはHuman-in-the-Loopで止めます。

このように見ると、エージェントAIの設計パターンは流行語ではなく、責務分離のための部品です。ゴール、推論、協調、安全性を別々に設計しておくと、最初は単一エージェントでも、あとからマルチエージェントや評価基盤へ拡張しやすくなります。