GitHub Copilot on hagizo.io

【AIニュース】Microsoft初の推論モデル登場、GitHub Copilot課金刷新で波紋、MIT発の訓練高速化

Tue, 02 Jun 2026 00:00:00 +0900

2026年6月、AIインフラをめぐる三つの動きが同時進行している。Microsoftが年次開発者カンファレンス「Build 2026」でついに自社推論モデルを世界に示し、GitHubはCopilotの料金体系を刷新した。そしてMIT発の研究が推論モデルの訓練コストという根本課題に楔を打ち込もうとしている。

Microsoft Build 2026——MAI-Thinking-1、自社推論モデルの初陣

6月2日に開幕したMicrosoft Build 2026のキーノートで、Microsoftは同社初の推論特化モデル「MAI-Thinking-1」を発表した。

推論モデル（難問を解くために回答前に「考えるステップ」を積み重ねるAI）の競争はOpenAIのo系シリーズ、AnthropicのClaude Opus 4.8が先行してきたが、ここにMicrosoftが自前のモデルを引っさげて参入した形だ。

MAI-Thinking-1の主な特徴は次のとおりだ。

サイズと文脈長: アクティブパラメータ（実際の推論に使われる重み）は350億で、モデルとしては中規模に当たる。文脈ウィンドウは25.6万トークン（文庫本約500冊分）に対応する。

性能: コーディング能力を測るSWE-Bench Pro（実際のGitHubイシューを自力で修正する能力を評価するベンチマーク）でAnthropicのClaude Opus 4.6と同等の結果を示した。数学的推論ではAIME 2025（全米最難関の高校数学コンテスト問題集）で97.0%、AIME 2026で94.5%という水準に達している。

訓練方針: 第三者モデルからの知識蒸留（大きなモデルの出力を学習データに使う手法）を一切行わず、商用利用可能な独自データセットのみで訓練されたと明言している。企業導入時のライセンスリスクを意識した姿勢だ。

現時点ではMicrosoft Foundry（Microsoftのモデル開発・提供プラットフォーム）のプライベートプレビューとして提供が始まっており、Fireworks AI・Baseten・OpenRouterなどのサービス経由でも間もなく利用可能になる見通しだ。

実務上の示唆

中規模モデルがClaude Opus 4.6に匹敵するコーディング性能を出せるとすれば、推論コストを抑えた自動コードレビューや静的解析パイプラインの構築コストが下がる可能性がある。
商用データのみ訓練という点は、AIシステムの著作権リスクを重視する法務・調達部門にとって評価材料になる。ライセンスの透明性を重視する組織は優先的に検討する価値がある。
Foundryが基盤になることで、AzureやMicrosoft 365と密接に統合されたエージェントワークフローが組みやすくなると予想される。Microsoftエコシステムを既に使っている組織は早めに試用を検討したい。

GitHub Copilot AI Credits課金——1日で使い切った開発者たち

6月1日を境に、GitHub Copilotの全プランが「AI Credits（AIクレジット）」ベースの従量課金に切り替わった。1 AIクレジット＝0.01ドルで、チャット・コードレビューなどの機能が使用量に応じてクレジットを消費する仕組みだ。

プラン別の月間クレジット上限は以下のとおりだ。Copilot Pro+（月39ドル）には39ドル分のAIクレジットが含まれる。Copilot Business（ユーザーあたり月19ドル）には19ドル分、Copilot Enterprise（ユーザーあたり月39ドル）には39ドル分が付与される。上限を超えた分は追加購入で使い続けられる。

問題はその消費速度だ。The Registerの報道によると、Copilot Pro+を使う開発者がわずか2時間で月間クレジットの約8%を使い切ったと報告している。単純計算すると、フル稼働で約25時間で月額分を消費することになる。GitHubコミュニティには「以前と同じ使い方なのに大幅に値上がりする」「月の途中で機能が使えなくなる」という声が相次いでいる。

なお、コード補完（インラインでの次のコード提案）と「Next Edit Suggestions（次の編集候補）」は引き続きAIクレジットの対象外で、全有料プランで無制限に使える。大きく影響を受けるのはチャット機能とAgent Mode（複数ファイルを横断してコードを書き直すエージェント動作）だ。

実務上の示唆

Agent Mode（ファイル横断で大規模なコード変更を自律的に実行する機能）は消費量が特に大きいとされる。チームで多用している場合は月次コストが予算を超えるリスクがある。まず組織内の使用量モニタリング設定を確認することを勧める。
GitHubは組織・企業向けに「ユーザーレベルの予算設定」機能を提供している。部門ごとにクレジット上限を設けてコストを管理する運用設計が必要になってくる。
競合のCursor・Windsurf・JetBrains AI Assistantは固定料金モデルを維持しているケースも多い。コスト構造を比較した上でツール選定を再評価するタイミングかもしれない。

MITの推論モデル訓練高速化——遊休プロセッサ問題を解消

推論モデル（ステップごとに論理を展開して難問を解くAI）の訓練には膨大な計算コストがかかる。その原因のひとつが「遊休プロセッサ問題」だ。複雑な問題を処理しているGPUが全力稼働している一方で、簡単な問題を担当するGPUが手待ち状態になる。クラスタ全体では大量の計算資源が無駄になっている。

MITの研究チーム（MIT・NVIDIA・ETH Zurichの共同研究、主著者はMITポスドクのQinghao Hu氏）は、この問題を「スペキュレーティブ訓練（推測的訓練）」と呼ぶ手法で解決した。

仕組みはこうだ。大きな推論モデルの出力を「予測」する小型の補助モデルをもう1つ訓練し、大型モデルはその予測を検証することに集中する。小型モデルが高精度な予測を出してくれれば、大型モデルが全ステップを自力で計算しなくて済む。遊休状態のプロセッサが小型モデルの推測を担当するため、クラスタ全体の稼働率が上がる仕組みだ。

実験では訓練速度が70〜210%向上し（モデルにより差がある）、最終的な精度は維持された。さらに嬉しい副産物として、訓練で生まれた小型モデルは、本番推論時のスペキュレーティブデコーディング（大型モデルの出力を小型モデルで先読みして高速化する既存手法）にそのまま再利用できることも確認された。訓練と推論の両方のコストを下げられる一石二鳥の効果だ。

実務上の示唆

この手法が実用化されれば、推論モデルの訓練コストが大幅に削減される可能性がある。訓練コスト低下は最終的にAPIの利用料金にも波及するため、LLMを活用したサービスのコスト見通しを見直す材料になりうる。
副産物の小型モデルをそのまま推論高速化に使えることは、クラウドコストが支配的なLLMアプリケーション運営者にとって大きなインパクトになりうる。自社でモデルをホストしている組織は特に注目したい。
エネルギー効率の改善はAIシステムのCO2排出量報告にも関わる。サステナビリティ要件を重視する組織にとっても、今後のモデル選定・訓練戦略の参考になる研究だ。

まとめ

今週のAI業界は、モデルの性能向上よりも「コストと経済圏」への注目が高まった。MicrosoftのMAI-Thinking-1は「自前で推論モデルを持つ」時代の始まりを告げ、GitHub Copilotの課金変更は開発ツールの経済設計が転換点を迎えていることを示した。そしてMITの研究は、将来の推論モデル訓練コストを根本から変える可能性を示唆している。AIを「いかに安く・効率よく使うか」という問いが、2026年後半の最重要テーマになりそうだ。

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 を使う時間そのものよりも、実装とレビューに使える時間を増やしやすくなります。

Copilotに複数リポジトリを解析させるならVS CodeのMulti-root Workspaceが便利

Wed, 29 Apr 2026 08:59:00 +0900

GitHub Copilotを使って複数のプロジェクトを比較・解析したい場合、VS CodeのMulti-root Workspaceがかなり便利です。別ウィンドウで左右に並べる方法もありますが、Copilotに両方のコードベースを参照させたいなら、1つのワークスペースにまとめるほうが扱いやすくなります。本記事では、Copilotに複数リポジトリを解析させる前提で、Multi-root Workspaceの使い方と活用ポイントを整理します。

Multi-root Workspaceとは

Multi-root Workspaceは、VS Codeの1つのウィンドウに複数のフォルダを追加して扱う機能です。通常は1つのプロジェクトフォルダを開いて作業しますが、Multi-root Workspaceを使うと、複数のリポジトリや関連プロジェクトを同じVS Code上でまとめて開けます Zenn。

たとえば、ライブラリ本体とそれを利用するアプリケーション、旧リポジトリと新リポジトリ、バックエンドとフロントエンド、移植元と移植先のような組み合わせを1つの作業空間にできます。VS Codeでは、それぞれのフォルダを独立したルートとして扱えるため、Gitの状態もプロジェクトごとに分けて確認できます Qiita。

Copilotに両方を見せたい場合に向いている

Copilot Chatに「この実装を別プロジェクトに移植したい」「AリポジトリとBリポジトリの構成差分を見てほしい」「このライブラリの使い方を利用側アプリから推測して」と依頼する場合、関連するフォルダが同じVS Codeワークスペースに入っているほうが自然です。

別ウィンドウで開いている場合、人間は左右を見比べられますが、Copilotにとっては文脈が分断されやすくなります。一方、Multi-root Workspaceでは、複数フォルダを同じ作業単位として扱えるため、Copilot Chatに対象ファイルやフォルダを指定しながら質問しやすくなります。

たとえば、次のような依頼がしやすくなります。

repo-aの認証処理を参考に、repo-bの実装方針を提案して

frontendとbackendのAPI定義にズレがないか確認して

旧プロジェクトのこの機能を、新プロジェクトの構成に合わせて移植する手順を出して

このように、Copilotを単なる補完ツールではなく、複数コードベースをまたいだ分析役として使うなら、Multi-root Workspaceはかなり相性がよい構成です。

設定方法

設定方法はシンプルです。まずVS Codeで1つ目のプロジェクトを開きます。その後、メニューから「File > Add Folder to Workspace…」を選び、比較したい別プロジェクトを追加します。必要に応じて、ワークスペースを .code-workspace ファイルとして保存できます atmarkIT。

.code-workspace として保存しておくと、次回から同じ組み合わせをすぐに開けます。たとえば、移植作業用、モノレポ分割作業用、ライブラリ検証用のように、目的別のワークスペースを作っておくと便利です。

構成例としては、次のようなイメージです。

my-migration.code-workspace
- old-service
- new-service
- shared-library

この状態でVS Codeを開けば、Copilotに対して「old-serviceの実装を参考にnew-service側の設計を見直して」といった質問をしやすくなります。

同じリポジトリの別ブランチならGit worktreeと組み合わせる

同じリポジトリの別ブランチを比較したい場合は、Multi-root WorkspaceだけでなくGit worktreeを組み合わせると便利です。Git worktreeを使うと、同じリポジトリの別ブランチを別ディレクトリとして展開できます Qiita。

たとえば、次のように実行します。

git worktree add ../feature-branch feature-branch

その後、元のブランチのディレクトリと、worktreeで作成したディレクトリを同じMulti-root Workspaceに追加します。これにより、Copilotに「mainブランチとfeatureブランチの設計差分を見て」「feature側の変更をmain側の構成に合わせるにはどうすればよいか」といった相談がしやすくなります。

この方法は、リファクタリング前後の比較、長期ブランチの差分確認、実験実装と本番実装の比較に向いています。単にGit diffを見るだけでなく、Copilotに設計意図や移植方針まで考えさせたい場合に効果的です。

運用時の注意点

Multi-root Workspaceに多くのリポジトリを入れすぎると、検索結果やファイル候補が増えすぎて、逆に作業しづらくなることがあります。Copilotに解析させたい対象だけをワークスペースに入れるのが基本です。

また、似た名前のファイルが複数ある場合は、Copilotへの指示でフォルダ名を明示すると誤解が減ります。「srcの実装を見て」ではなく、「old-service/srcの実装を参考に、new-service/srcへ移植する方針を出して」のように書くと、対象が明確になります。

Gitの変更もフォルダごとに分かれるため、コミット対象を間違えないように注意が必要です。VS Code上では複数リポジトリの変更が同じSource Controlビューに出ることがあるため、どのリポジトリに対する変更か確認してからコミットすると安全です。

まとめ

Copilotに複数のプロジェクトやリポジトリを解析させたいなら、VS CodeのMulti-root Workspaceを使うのが最も扱いやすい方法です。別ウィンドウでの比較は人間の目視には便利ですが、Copilotに両方のコードベースを意識させる用途では、1つのワークスペースにまとめるほうが自然です。

移植元と移植先、ライブラリと利用側アプリ、frontendとbackend、同一リポジトリの別ブランチなどをMulti-root Workspaceにまとめることで、Copilotに横断的な分析や実装方針の提案を依頼しやすくなります。複数コードベースを扱う作業では、まずMulti-root Workspaceを作り、必要に応じてGit worktreeを組み合わせる構成を基本にするとよいでしょう。

CopilotのAgent・SubAgent・Skillをポケモンに例えて理解する

Sat, 25 Apr 2026 09:30:00 +0900

GitHub CopilotのAgent、SubAgent、Skillという用語は、公式ドキュメントを読んでもすぐには頭に入ってこない。特に「Agentの中でSubAgentが動き、Skillが読み込まれる」という階層構造は、文字で追うと混乱しやすい。ところが、これをポケモンに例えた瞬間、全体像がすっきり見えてくる。この記事では、その比喩を通じて三者の役割と使い分けを整理する。

Agentはトレーナー

Agentの役割は、目的を持ち、状況を判断し、手持ちを動かす存在である。これはポケモンのトレーナーそのものだ。たとえばサトシとゴウは、同じ世界を歩いていても目的がまったく違う。サトシは「ポケモンマスターになる」ことを目指し、ゴウは「すべてのポケモンを捕まえる」ことを目指している。目的が違えば、選ぶポケモンも、戦い方も、旅のルートも変わる。

Agentが存在する理由は、ここにある。「バグを直したい」「新機能を設計したい」「リリースノートを書きたい」という目的ごとに、最適な進め方は違う。Agentは、その目的を受け取り、どのSubAgentにどう動いてもらうかを判断する司令塔の役割を担う。

トレーナーとしてのAgentの仕事

トレーナーは自分で技を出すわけではない。代わりに、場面に応じて手持ちを選び、指示を出す。Agentも同じで、自分で細かい作業をこなすより、タスクの分解と委譲が主な仕事になる。

目的を設定する
タスクをどう分割するかを決める
どのSubAgentに任せるかを選ぶ
結果を受け取って次の手を考える

SubAgentはポケモン

SubAgentは、Agentに呼び出されて特定の仕事をこなす専門家である。これはポケモンに当たる。ピカチュウは電気技が得意で、リザードンは炎と飛行が得意、ゲンガーはゴーストとエスパー対策に強い、というように、ポケモンごとに得意分野がはっきりしている。

SubAgentも同じで、「コードレビュー担当」「テスト作成担当」「ドキュメント整備担当」「セキュリティ監査担当」のように、役割ごとに専門化されている。Agentはタスクの性質を見て、適切なSubAgentを選んで呼び出す。これは、岩タイプ相手にはミズタイプを出す、という戦略と構造的に同じだ。

手持ちを揃えるという発想

ポケモンバトルで手持ちを6匹編成するように、Agentも複数のSubAgentを組み合わせて運用すると強い。単一の万能SubAgentを作ろうとするより、役割を分けておいた方が、プロンプトもコンテキストもシンプルに保てる。結果として、一匹あたりの判断精度が上がる。

Skillは技

Skillは、SubAgentが実行する具体的な動きである。これはポケモンの技に相当する。ここが比喩のキモで、技はポケモンに固有ではない。たとえば「でんこうせっか」はピカチュウも覚えるし、ニャースも覚える。「かみなり」はピカチュウだけでなく、サンダースやエレブーも使える。

Skillも同じで、「Hugoフロントマター生成ルール」「PR説明文テンプレート」「テスト追加手順」といったSkillは、特定のSubAgentに紐付いているわけではなく、必要に応じて複数のSubAgentから再利用できる。これが「Skillは再利用可能な手順」と言われる理由だ。

技マシンとしてのSkill

ポケモンは技マシンを使うことで新しい技を覚えられる。Skillもこれに近い。SubAgentは自分の得意分野のコア能力を持ちつつ、必要なときにSkillを読み込んで能力を拡張する。Copilotの世界では、Agent Skillsが関連タスクのときだけコンテキストに注入される仕組みになっており、これはまさに「戦闘中に必要な技だけ繰り出す」構造と一致する。

三者の関係を一枚絵で

ここまでの対応関係を整理すると次のようになる。

Agent = トレーナー：目的を持ち、戦略を決める
SubAgent = ポケモン：得意分野を持つ専門家
Skill = 技：複数のポケモンで共有できる具体的な動き

バトルの流れに置き換えるなら、「トレーナーが目的に応じてポケモンを選び、場面に応じて技を指示する」という構造になる。実務に置き換えれば、「Agentがタスクを分解し、適切なSubAgentを呼び、SubAgentが必要なSkillを読み込んで実行する」となる。

比喩が効く理由

この比喩がわかりやすいのは、役割の粒度と再利用性がきれいに対応しているからだ。トレーナー同士は目的が違うから入れ替えにくい。ポケモンは得意分野で役割分担する。技はポケモンを跨いで共有できる。Copilotの三階層も、同じ粒度設計になっている。

比喩が崩れるところ

ただし、この比喩には一点だけ素直に対応しないところがある。ポケモンの世界ではトレーナーが直接技を繰り出すことはなく、技を出すのはあくまでポケモンだ。一方Copilotでは、AgentもSubAgentと同じようにSkillを読み込んで自分で実行できる。小さなタスクであればSubAgentを介さず、Agentがその場でSkillを使ってしまう方が速い場面も多い。トレーナーが必要に応じて自分でも技マシンを使えるイメージだと思っておくと、設計時にミスマッチが起きにくい。

設計で迷ったときは、この比喩に戻ると判断しやすい。「これはトレーナーの仕事か、ポケモンの仕事か、それとも技か」と問い直すだけで、Agentに書くべきこと、SubAgentに閉じ込めるべきこと、Skillとして切り出すべきことが見えてくる。AIエージェントの設計は抽象的になりがちだが、手に馴染んだ比喩を一つ持っておくと、チームでの議論もかなり速くなる。

【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は単なる補完ツールではなく、リポジトリの文脈とチームの作法を理解した専門家チームに近づきます。

【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に渡す文脈を整えるほど、単なる補完ツールから、頼れる開発パートナーに近づいていきます。

GitHub Copilot on hagizo.io

【AIニュース】Microsoft初の推論モデル登場、GitHub Copilot課金刷新で波紋、MIT発の訓練高速化

Microsoft Build 2026——MAI-Thinking-1、自社推論モデルの初陣

実務上の示唆

GitHub Copilot AI Credits課金——1日で使い切った開発者たち

実務上の示唆

MITの推論モデル訓練高速化——遊休プロセッサ問題を解消

実務上の示唆

まとめ

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

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

導入

TL;DR

GitHub Copilotの違い

使い分けの早見表

autoモデル選択

VS Codeでautoを使う手順

Copilot CLIでautoを使う手順

クレジット消費

実務で差が出るポイント

コストを抑える運用

実務フロー

VS Code Copilotを選ぶ場面

Copilot CLIを選ぶ場面

両方を組み合わせる形

ハマりどころ

まとめ

Copilotに複数リポジトリを解析させるならVS CodeのMulti-root Workspaceが便利

Multi-root Workspaceとは

Copilotに両方を見せたい場合に向いている

設定方法

同じリポジトリの別ブランチならGit worktreeと組み合わせる

運用時の注意点

まとめ

CopilotのAgent・SubAgent・Skillをポケモンに例えて理解する

Agentはトレーナー

トレーナーとしてのAgentの仕事

SubAgentはポケモン

手持ちを揃えるという発想

Skillは技

技マシンとしてのSkill

三者の関係を一枚絵で

比喩が効く理由

比喩が崩れるところ

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

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

Agentに向いている指示例

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

使い分けの判断基準

Agentを使うべきケース

Skillを使うべきケース

組み合わせると強い

まとめ

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

Custom Agentsとは何か

どこに配置するか

最小のagent profile

toolsで権限を絞る

MCPをagent専用にする

targetとmodelを使い分ける

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

CLIで作る流れ

おすすめの設計パターン

docs-writer

test-specialist

ci-debugger

作るときの注意点

まとめ

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

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

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

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

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

4. MCPでツールを増やす

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

最小構成のおすすめ