開発効率化 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開発】SkillとAgentを増やしすぎない設計指針

Tue, 28 Apr 2026 12:32:00 +0900

Copilotや各種LLMツールを使い込んでいくと、「もっと賢くしたい」という理由でSkillやAgentを増やしたくなります。しかし、Skillを盛り込みすぎる問題と、Agentをたくさん定義する問題は、似ているようで失敗の性質が違います。前者はLLMに渡す文脈が濁る問題であり、後者は作業全体の運用が複雑になる問題です。

Skillは「型」を増やす仕組み

Skillは、LLMに対して「この場面ではこう振る舞ってほしい」という型を与えるものです。たとえば、技術記事では結論を先に書く、レビューでは保守性とセキュリティを重視する、コード例には前提条件を添える、といったルールはSkillに向いています。

ただし、Skillに何でも詰め込むと、かえって出力は不安定になります。ひとつのSkillの中に「詳しく説明する」「簡潔に書く」「初心者向けにする」「専門家向けにする」のような指示が同居していると、モデルはどれを優先すればよいのか判断しにくくなります。その結果、どの読者にも深く刺さらない、平均化された文章になりがちです。

Skill過多の本質は、作業が増えることではありません。LLMが参照する前提が増えすぎて、重要な制約と単なる補足情報の区別が曖昧になることです。つまり、Skillを増やしすぎると「賢くなる」のではなく、判断の軸がぼやけるのです。

Agentは「作業者」を増やす仕組み

一方でAgentは、独立した作業を任せるための単位です。調査、実装、レビュー、テスト、要約のように、成果物が分かれる作業はAgentに向いています。複数のAgentを使うことで、時間のかかる作業を並列化したり、人間が見落としがちな観点を補ったりできます。

しかし、Agentを増やしすぎると、今度は全体の流れが追いにくくなります。調査Agentが集めた情報を実装Agentがどう解釈するのか、レビューAgentの指摘を誰が採用するのか、最終的な成果物を誰が統合するのか。ここが曖昧なままAgentを増やすと、部分的には正しい出力が並んでいるのに、全体としては使いにくい状態になります。

Agent過多の本質は、LLMの理解が濁ることではありません。責務が分散しすぎて、作業全体の統合コストが増えることです。Agentを増やすほど自動化が進むように見えますが、統合役が不在だと、人間が最後に全部読み直して調整することになります。

Skill過多とAgent過多の違い

この2つの違いは、次のように整理できます。

問題	何が増えすぎているか	失敗の出方
Skill過多	LLMに渡す前提やルール	出力の軸がぼやける
Agent過多	作業を担う実行単位	統合と運用が重くなる

Skillを増やしすぎた場合、問題はひとつの出力の中に現れます。文章が中途半端になる、レビュー観点が散らばる、不要な制約まで考慮してしまう、といった形です。

Agentを増やしすぎた場合、問題はワークフロー全体に現れます。依頼先に迷う、Agent間で前提がずれる、成果物の粒度が揃わない、最終判断が人間に戻ってくる、といった形です。

実務ではどう設計するか

実務では、まずSkillで作業の型を整え、それでも独立した作業として切り出したほうがよいものだけをAgent化するのが安全です。文体、禁止事項、ファイル形式、レビュー観点、完了条件のように、同じ作業の中で繰り返し使うルールはSkillに向いています。

一方で、調査、実装、検証、要約のように成果物が明確に分かれるものはAgent化を検討できます。ただし、Agentに任せるなら、入力と出力を明確にする必要があります。「調べて」ではなく、「候補を5件、理由付きで整理する」のように、成果物の形を決めておくことが重要です。

設計時の目安はシンプルです。

Skillは「守るべき型」
Agentは「任せる作業者」
Skillは小さくする
Agentは必要になってから増やす
複数Agentを使うなら統合役を決める

特に大切なのは、Skillを作業者にしないこと、Agentをルール置き場にしないことです。Skillには判断基準や出力ルールを持たせ、Agentには明確な作業と成果物を持たせます。この境界を守るだけで、LLMツールの設計はかなり安定します。

まとめ

Skillを盛り込みすぎる問題は、LLMに渡す文脈が濁り、出力の軸がぼやける問題です。一方で、Agentをたくさん定義する問題は、責務が分散しすぎて、運用や統合のコストが増える問題です。

LLMツールを強くするコツは、何でも追加することではありません。まずは小さなSkillで型を整え、必要になった作業だけをAgentとして切り出すことです。Skillは少数の明確なルールに絞り、Agentは明確な成果物を持つ単位として設計する。そのほうが、Copilotや各種LLMツールを日常の開発フローに自然に組み込みやすくなります。

【GitHub Copilot】AgentとSkillの使い分け方

Thu, 23 Apr 2026 02:02:34 +0900

GitHub Copilotを使っていると、「Agentに任せるべきか」「Skillとして定義すべきか」で迷う場面があります。どちらもAIに作業を助けてもらう仕組みですが、役割はかなり違います。この記事では、AgentとSkillをどう使い分けると開発効率が上がるのかを、具体例つきで整理します。

Agentは「作業を進める担当者」

Agentは、ざっくり言えば「目的を渡すと、自律的に作業を進める担当者」です。GitHub Copilotのagent modeは、自然言語の指示をもとにコードベースを分析し、複数ステップの解決策を計画・実行し、コマンドやテストも実行できる同期的な協力者として説明されています。GitHub Blog

たとえば、次のような依頼はAgent向きです。

「このバグの原因を調べて修正して」
「既存のAPIにページネーションを追加して」
「テストが落ちているので原因を特定して直して」
「このPRの変更に合わせてドキュメントも更新して」

ポイントは、作業のゴールは明確だが、途中で何を読むか、どのファイルを直すか、どのテストを回すかはAIに判断させたいケースです。GitHub Copilot coding agentは、GitHub上でバックグラウンド実行され、ブランチ作成、コミット、Pull Request作成などを含めて作業できる仕組みとして説明されています。GitHub Docs

Agentに向いている指示例

悪い例は「いい感じに改善して」です。範囲が広すぎて、Agentがどこまでやれば完了なのか判断しにくくなります。

良い例は次のような形です。

ユーザー一覧APIにlimitとcursorを追加してください。
既存のレスポンス形式は壊さず、テストも追加してください。
変更後に関連するREADMEのAPI例も更新してください。

このように、完了条件、制約、確認方法を渡すと、Agentは動きやすくなります。

Skillは「再利用できる作業手順」

Skillは、Agentそのものではなく、Agentが必要なときに読み込める専門手順です。GitHub CopilotのAgent Skillsは、特定タスクの性能を上げるためにCopilotが読み込める「instructions、scripts、resourcesを含むフォルダ」と説明されています。GitHub Docs

Skillに向いているのは、毎回同じルールでやりたい作業です。

「このリポジトリのテスト追加方針」
「Hugo記事のフロントマター生成ルール」
「社内APIクライアントの実装パターン」
「GitHub Actions失敗時の調査手順」
「リリースノートの書き方」

たとえば、Hugoの記事を書くたびに「h1は使わない」「YAMLフロントマターを付ける」「タグとカテゴリを生成する」と毎回プロンプトに書くのは面倒です。これをSkillにしておけば、AgentやCopilotが該当タスクだと判断したときに、その手順を読み込んで作業できます。GitHubの説明でも、Skillが選ばれるとSKILL.mdがAgentのコンテキストに注入され、指示や同梱されたスクリプト・例を使えるとされています。GitHub Docs

使い分けの判断基準

一番シンプルな判断基準は、「今回だけの作業か、今後も繰り返す型か」です。

Agentを使うべきケース

Agentは、状況判断が必要な作業に向いています。

複数ファイルを横断して調査する
実装、テスト、修正をまとめて進める
エラー出力を見ながら試行錯誤する
Pull Requestとして成果物を残したい
途中の判断をAIに任せたい

たとえば「Neovimプラグインの設定読み込み順を調べて、起動時間を悪化させずに修正して」という依頼はAgent向きです。対象ファイルの探索、原因調査、実装修正、ベンチマーク確認が必要だからです。

Skillを使うべきケース

Skillは、作業の「やり方」を固定したい場合に向いています。

チーム固有のコーディング規約がある
毎回同じフォーマットで記事やIssueを作る
レビュー観点を統一したい
特定ツールの実行手順を覚えさせたい
失敗しやすい手順をチェックリスト化したい

たとえば「GoのAPIハンドラを追加するときは、handler、service、repository、migration、OpenAPI定義、テストを必ず更新する」というルールはSkill向きです。作業そのものはAgentに任せつつ、進め方はSkillで縛るイメージです。

組み合わせると強い

実践では、AgentとSkillは対立するものではありません。むしろ「Agentにタスクを任せ、Skillで作業品質を安定させる」と考えるのが自然です。GitHub Docsでも、簡単でほぼ全タスクに関係する指示はcustom instructionsに、関連時だけ読み込む詳細な指示はskillsに向いていると説明されています。GitHub Docs

具体的には、次のように組み合わせます。

Agentへの依頼:
認証APIにパスワードリセット機能を追加してください。

Skill側の定義:
- このプロジェクトのAPI実装パターン
- テスト作成ルール
- エラーレスポンス形式
- OpenAPI更新手順
- セキュリティレビュー観点

この形にすると、Agentは自律的に作業しつつ、プロジェクト固有のルールから外れにくくなります。

まとめ

Agentは「タスクを進める実行者」、Skillは「実行者に渡す専門マニュアル」です。迷ったら、まずはAgentに任せる単位を「完了条件のある作業」として切り出し、何度も繰り返す手順や品質基準をSkill化するとよいでしょう。

開発者にとって重要なのは、AIに丸投げすることではなく、AIが迷わず動ける環境を設計することです。Agentで作業を進め、Skillで再現性を高める。この組み合わせを意識すると、Copilotは単なる補完ツールから、かなり実用的な開発パートナーに近づきます。

【AI開発】GitHub Copilot Custom Agentsの作り方

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

GitHub Copilotを「自分用の開発エージェント」として使うなら、custom agentsはかなり重要な機能です。毎回プロンプトで細かい前提を説明するのではなく、役割、制約、利用できるツール、判断基準をMarkdownファイルとして定義しておくことで、Copilotをタスク特化のチームメイトとして扱いやすくなります。

Custom Agentsとは何か

GitHub Docsでは、custom agentsはワークフロー、コーディング規約、ユースケースに合わせて調整できるCopilot agentの特殊版として説明されています。About custom agents つまり、Copilot本体に「このタスクではセキュリティレビュアとして振る舞う」「このタスクではREADME作成者として振る舞う」といった専門性を持たせる仕組みです。

custom agentは、agent profileと呼ばれるMarkdownファイルで定義します。About custom agents このagent profileには、YAML frontmatterで名前、説明、利用ツール、MCPサーバなどを書き、本文にエージェントの振る舞いを自然言語で記述します。Custom agents configuration

通常のcustom instructionsが「リポジトリ全体の常時ルール」だとすると、custom agentsは「特定の役割を持つ担当者」です。たとえば、docs-writer、test-specialist、security-auditor、ci-debugger のように分けておくと、1つの万能エージェントにすべてを背負わせずに済みます。

どこに配置するか

リポジトリ単位で使うcustom agentは、.github/agents/ に配置します。Creating custom agents ファイル拡張子は .agent.md で、たとえば .github/agents/security-auditor.agent.md のように作ります。Creating custom agents for Copilot CLI

個人用に複数リポジトリで使いたい場合は、Copilot CLIでは ~/.copilot/agents/ に配置できます。Creating custom agents for Copilot CLI 同じ名前のエージェントがプロジェクト側とユーザー側にある場合、CLIではホームディレクトリ側のcustom agentが優先されます。Creating custom agents for Copilot CLI

OrganizationやEnterpriseで共通利用したい場合は、.github-private リポジトリの /agents/ に配置できます。About custom agents 個人の作業ルールならユーザー側、プロジェクト固有の規約ならリポジトリ側、組織標準ならOrganization側、という切り分けがよさそうです。

最小のagent profile

最小構成は、description と本文のプロンプトです。description は必須フィールドで、custom agentの目的と能力を説明します。Custom agents configuration

---
name: docs-writer
description: README、ADR、リリースノート、開発者向けドキュメントを作成・改善するドキュメント専門エージェント
tools: ["read", "edit", "search"]
---

あなたはドキュメント作成の専門家です。

あなたの責務:
- README、ADR、リリースノート、開発者向けドキュメントを改善する
- 簡潔で読みやすいMarkdownを書く
- 既存の用語、文体、プロジェクトの慣習を尊重する
- 明示的に依頼されない限り、本番コードは変更しない

編集前に行うこと:
- 既存ドキュメントの文体と構成を確認する
- 読者が誰かを明確にする
- 依頼が曖昧な場合は、先にアウトラインを提案する

編集後に行うこと:
- 何を変更したかを要約する
- 前提にしたことや不足している情報を列挙する

tools を省略すると、利用可能なすべてのツールが有効になります。Custom agents configuration 安全に始めるなら、read、search、edit のように必要なツールだけを明示するのがおすすめです。Custom agents configuration

toolsで権限を絞る

custom agentの実用性は、プロンプトだけでなくtoolsの制御で決まります。GitHub Docsでは、tools に read、edit、search、execute、agent などのエイリアスを指定できると説明されています。Custom agents configuration

たとえば、レビュー専用エージェントなら編集権限を持たせないほうが安全です。

---
name: read-only-reviewer
description: ファイルを編集せず、コードやドキュメントを読み取り専用でレビューするエージェント
tools: ["read", "search"]
---

あなたは読み取り専用のレビュー担当です。

あなたの責務:
- 依頼されたファイルをレビューする
- リスク、不整合、テスト不足、説明不足を見つける
- 具体的な修正案を提示する
- ファイルは編集しない

出力形式:
- 概要
- 指摘事項
- 修正案
- 確信度

このように tools: ["read", "search"] にしておけば、レビュー担当が勝手にファイル編集するリスクを下げられます。逆に、CI修正担当なら execute を含めることでテストやlintを実行できるようにします。

MCPをagent専用にする

custom agentには mcp-servers を設定できます。Custom agents configuration ただし、mcp-servers プロパティはGitHub.com上のCopilot cloud agent向けで、VS CodeなどのIDE custom agentsでは使われないとされています。Custom agents configuration

MCPツールは、server-name/tool-name のようにサーバ名付きで指定できます。Custom agents configuration たとえばPlaywright系の検証エージェントなら、Playwrightのツールだけを許可する設計が考えられます。

---
name: ui-regression-tester
description: Playwrightを使って画面挙動やUI回帰を検証するテスト専門エージェント
tools: ["read", "search", "edit", "execute", "playwright/*"]
---

あなたはUI回帰テストの専門家です。

あなたの責務:
- 既存のUIテストパターンを確認する
- 変更された挙動に対して、焦点を絞ったPlaywrightテストを追加する
- 利用可能な場合は、関連するテストコマンドを実行する
- 失敗した場合は、再現手順と原因候補を整理する

制約:
- 関係のないUIコードはリファクタリングしない
- 小さく、目的が明確なテストを優先する
- テスト環境が利用できない場合は、不足しているセットアップを明確に説明する

ツールを絞ると、エージェントの役割と権限境界が明確になります。これは前回整理した「安全性ガード」レイヤを、Copilot custom agentの設定として実装するイメージです。

targetとmodelを使い分ける

target を使うと、custom agentの対象環境を vscode または github-copilot に限定できます。Custom agents configuration 省略した場合は両方の環境が対象になります。Custom agents configuration

model を指定すると、そのcustom agentが実行されるときのモデルを指定できます。Custom agents configuration ただし、モデル指定は環境や利用可能なモデルに依存するので、最初は省略してデフォルトモデルを使い、必要になってから調整するほうが運用しやすいです。

---
name: implementation-planner
description: コードを変更する前に、実装計画と技術仕様を作成する計画専門エージェント
target: github-copilot
tools: ["read", "search", "edit"]
---

あなたは実装計画の専門家です。

あなたの仕事は、実装前に計画を作ることです。

必ず含める内容:
- ゴール
- 対象範囲
- 対象外とすること
- 影響を受けるファイルまたはモジュール
- ステップごとの実装計画
- テスト計画
- リスクとロールバック方針

ユーザーが明示的に実装を依頼しない限り、コードは変更しないでください。

計画専用エージェントは、実装前のレビューやIssue整理と相性がよいです。ユーザーが明示的に実装を依頼しない限り、コードは変更しないでください のように明示しておくと、ResearchやPlanの段階で勝手に変更が進むのを防ぎやすくなります。

自動選択させるか、手動選択にするか

Copilot CLIでは、/agent でcustom agentを選択できます。Creating custom agents for Copilot CLI また、プロンプト内で特定のagent名を指定したり、copilot --agent security-auditor --prompt "..." のようにコマンドライン引数で指定したりできます。Creating custom agents for Copilot CLI

自動で使わせたくない場合は、disable-model-invocation: true を設定すると、Copilot cloud agentがタスク文脈から自動利用することを無効にできます。Custom agents configuration 逆に、ユーザーが手動選択できないagentにしたい場合は、user-invocable: false を使えます。Custom agents configuration

---
name: dangerous-change-reviewer
description: 本番環境やインフラに影響する危険な変更を、読み取り専用で確認するレビュー専門エージェント
tools: ["read", "search"]
disable-model-invocation: true
---

あなたは本番影響のある変更を確認するレビュー担当です。

このエージェントは、明示的に選択された場合だけ使用してください。

確認すること:
- 本番環境への影響
- ロールバック方針
- シークレットの露出
- 権限変更
- データ削除またはデータ移行のリスク
- 人間の承認が必要な箇所

ファイルは絶対に編集しないでください。

本番、権限、削除、課金に関係する領域では、自動起動よりも手動選択のほうが安全です。

CLIで作る流れ

Copilot CLIでは、interactive modeで /agent を入力し、Create new agent を選ぶことでcustom agentを作成できます。Creating custom agents for Copilot CLI 作成場所はProjectの .github/agents/ か、Userの ~/.copilot/agents/ から選べます。Creating custom agents for Copilot CLI

CLIでは、Copilotにagent profileの初期案を生成させる方法と、自分で手動作成する方法があります。Creating custom agents for Copilot CLI 手動作成では、名前、説明、振る舞い、制約、利用ツールを順番に定義します。Creating custom agents for Copilot CLI

作成後はCLIの再起動が必要です。Creating custom agents for Copilot CLI 使うときは /agent で選択するか、プロンプトで security-auditorエージェントを使って、この差分をレビューして のように明示します。Creating custom agents for Copilot CLI

作るときの注意点

custom agentは、万能化しすぎないほうがよいです。GitHub Docsでも、custom agentsは特定のワークフロー、規約、ユースケースに合わせるものとして説明されています。About custom agents 役割が広すぎると、通常のCopilot Chatと差がなくなります。

また、description はかなり重要です。custom agentの目的と能力を説明する必須項目であり、Copilotがいつそのagentを使うべきか判断する手がかりになります。Custom agents configuration

最後に、toolsは最小権限で始めるのがおすすめです。tools を省略するとすべての利用可能ツールが有効になるため、レビュー専用、計画専用、ドキュメント専用のagentでは、必要なツールだけに絞ったほうが安全です。Custom agents configuration

まとめ

Copilot custom agentsは、特別なAI基盤を作る機能ではなく、Copilotに「役割」「判断基準」「使えるツール」「禁止事項」を渡すためのファイルベースの仕組みです。まずは .github/agents/docs-writer.agent.md のような小さなagentから始め、効果が見えたら test-specialist、ci-debugger、security-auditor のように分割していくのが現実的です。

重要なのは、エージェントを増やすことではなく、責務と権限境界を明確にすることです。custom agentsをうまく使うと、Copilotは単なる補完ツールではなく、リポジトリの文脈とチームの作法を理解した専門家チームに近づきます。