GitHub Copilot | The .NET Blog

Azure DevOps MCP Server 4月アップデート: WIQLクエリ、PAT認証、実験的MCP Apps

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されています。オリジナル版はこちらをクリックしてください。

Azure DevOps MCP Serverは着実に改善されています。Dan Hellemの4月アップデートは両方のサーバーをカバーしています。

WIQLクエリサポート

新しいwit_query_by_wiqlツールにより、MCPクライアントから直接Work Item Query Languageクエリを実行できます。

Personal Access Tokens

ローカルサーバーでのPAT認証 — インタラクティブ認証が利用できない統合シナリオに重要。

MCPアノテーション

読み取り専用、破壊的、オープンワールドツールのメタデータタグ — エージェントの信頼性の基盤。

Wikiツールの統合

5つの別々のWikiツール → 2つのより有能なツール。ツールが少ない = LLMパフォーマンスが向上。

実験的: MCP Apps

MCSサーバー環境内でパッケージ化されたワークフロー。方向性は正しい。

Dan Hellemのオリジナルポスト: Azure DevOps MCP Server April Update。

VS Code 1.118: Copilot CLI にセッション名、モデルバッジ、TypeScript 7.0 ナイトリーオプトイン

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

Visual Studio Code 1.118 は小さめで焦点を絞ったリリース — 主に Copilot CLI の改良 — ですが、いくつか注目すべき点があります。

Copilot CLI: セッションに実際の名前が付く

Copilot CLI SDK のセッションタイトル API がセッション名の情報源として使用されるようになりました。自動生成されたラベルではなく、SDK の実際の名前が表示されます。

キーボードショートカットで素早くセッション切り替え

Agents アプリに Ctrl+1、Ctrl+2 などのセッション切り替えキーが割り当てられました。複数の Copilot CLI セッションを並行して実行している場合、マウスクリックが大幅に減ります。

チャットにモデルバッジ表示

チャットパネルの Copilot CLI レスポンスにモデルバッジが表示されるようになりました — どのモデルが各リクエストを処理したかひと目でわかります。

Copilot CLI に自動モデル選択

自動モデル選択機能 — 以前は Copilot の他の部分で使用可能だった — が Copilot CLI エージェントでも機能するようになりました。

TypeScript 7.0 ナイトリーのオプトイン

VS Code の設定から TypeScript 7.0 ナイトリーをテストするオプトインが可能になりました。TypeScript 7.0 は大規模リリースです（ベータ版が数日前にリリース）。

完全なリリースノートをご確認ください。

1日68分もコードを再説明している？解決策があります

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されています。オリジナル版はこちらをクリックしてください。

Copilotセッションが/compactに達し、エージェントが何をしていたか完全に忘れてしまう瞬間を知っていますか？次の5分間、ファイル構造、失敗したテスト、すでに試した3つのアプローチを再説明します。そしてまた同じことが起きます。

Desi Villanueva が計測しました：1日68分 — 再オリエンテーションだけに。コードを書くのでも、PRをレビューするのでもなく、AIがすでに知っていたことを再び教えるだけに。

コンテキストウィンドウの嘘

実際の計算：200Kのうち、MCAツールで65K、インストラクションファイルで10K消費され、言葉を入力する前に125Kしか残りません。そして60%の容量で壁に当たります。

有効な制限：45Kトークン — これが実際の制約です。

コンパクション税

残酷な部分：記憶はすでに存在します。 Copilot CLIは~/.copilot/session-store.dbにすべてのセッションを書き込みます。エージェントはただ読めないだけです。

auto-memory：リコールレイヤー

pip install auto-memory

~1,900行のPython。依存関係ゼロ。30秒でインストール完了。

grepの洪水の代わりに、10,000トークンではなく50トークンで昨日触れたファイルへの外科的アクセスを提供します。

まとめ

コンテキストロットは本物のアーキテクチャ的制約です。auto-memoryはエージェントに安価で正確なリコールメカニズムを与えることでこれを回避します。

チェックしてみてください：GitHubのauto-memory。オリジナル記事（Desi Villanueva著）：I Wasted 68 Minutes a Day。

azd + GitHub Copilot: AIによるプロジェクトセットアップとスマートなエラー解決

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。英語の原文はこちらからご覧いただけます。

既存のアプリをAzureにデプロイしようとして、空の azure.yaml を眺めながら「Express APIにはContainer AppsとApp Serviceのどちらを使えばいいんだっけ？」と頭を抱えた経験はありませんか？そんな場面が、これからは格段に短くなります。

Azure Developer CLI（azd）がGitHub Copilotと2つの形で統合されました。azd init 実行時のAIによるプロジェクトスキャフォールディングと、デプロイ失敗時のインテリジェントなエラートラブルシューティングです。どちらの機能もターミナル内で完結します。

azd init でのCopilotセットアップ

azd init を実行すると、「Set up with GitHub Copilot (Preview)」という選択肢が表示されます。選択すると、Copilotがコードベースを分析し、実際のコードに基づいて azure.yaml、インフラテンプレート、Bicepモジュールを生成します。

azd init
# 選択: "Set up with GitHub Copilot (Preview)"

必要なもの：

azd 1.23.11以降 — azd version で確認、azd update で更新
有効なGitHub Copilotサブスクリプション（Individual、Business、またはEnterprise）
GitHub CLI（gh） — 必要に応じてログインを求められます

この機能の優れた点は双方向に機能することです。ゼロから構築する場合はAzureサービスの適切なセットアップを支援し、既存のアプリをデプロイしたい場合はコードを分析して設定を生成します。構造を変更する必要はありません。

実際に何をするのか

Node.js ExpressのAPIにPostgreSQLの依存関係がある場合を例にしましょう。Container AppsかApp Serviceかを手動で決め、BicepをゼロからT書く代わりに、Copilotはスタックを検出して以下を生成します：

適切な language、host、build 設定を持つ azure.yaml
Azure Container Apps用のBicepモジュール
Azure Database for PostgreSQL用のBicepモジュール

変更前に事前チェックも実行されます。gitの作業ディレクトリがクリーンかどうか確認し、MCPサーバーツールへの同意を事前に求めます。何が変わるか把握した上でのみ処理が進みます。

Copilotによるエラートラブルシューティング

デプロイエラーは避けられません。パラメーターの欠落、権限の問題、SKUの可用性問題など。エラーメッセージが修正方法を教えてくれることはほとんどありません。

Copilotなしの場合のループ：エラーをコピー → ドキュメントを検索 → 関係ないStack Overflowの回答を3つ読む → az CLIコマンドを実行 → 再試行して祈る。azd にCopilotが統合されると、このループが消えます。azd コマンドが失敗すると、即座に4つの選択肢が提示されます：

Explain — 何が起きたかをわかりやすく説明
Guidance — 修正のステップバイステップの手順
Diagnose and Guide — 完全な分析 + Copilotが修正を適用（承認後）+ 再試行オプション
Skip — 自分で対処

重要な点：Copilotはすでにプロジェクト、失敗したコマンド、エラー出力のコンテキストを持っています。提案は あなたの状況 に特化したものです。

デフォルト動作の設定

常に同じオプションを選ぶなら、インタラクティブなプロンプトをスキップできます：

azd config set copilot.errorHandling.category troubleshoot

値：explain、guidance、troubleshoot、fix、skip。自動修正と再試行も有効にできます：

azd config set copilot.errorHandling.fix allow

いつでもインタラクティブモードに戻せます：

azd config unset copilot.errorHandling.category

まとめ

azd update で最新バージョンに更新し、次のプロジェクトで azd init を試してみてください。本当に価値のあるCopilot統合です。

元の発表はこちらをご覧ください。

VS Code 1.117：エージェントが専用のGitブランチを持つようになった、これは最高だ

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。原文はこちらをご覧ください。

「AIアシスタント」と「AIチームメイト」の境界線はどんどん薄くなっている。VS Code 1.117がリリースされ、完全なリリースノートは盛りだくさんだが、ストーリーは明確だ：エージェントが開発ワークフローのファーストクラスの市民になりつつある。

本当に重要なことはこれだ。

Autopilotモードがついに設定を記憶するように

以前は、新しいセッションを開始するたびにAutopilotを再度有効にする必要があった。面倒だった。今では権限モードがセッション間で保持され、デフォルトも設定できる。

Agent Hostは3つのセッション設定をサポートしている：

Default — ツールは実行前に確認を求める
Bypass — すべてを自動承認する
Autopilot — 完全自律型、自分の質問に答えて作業を続ける

.NETプロジェクトをマイグレーション、Docker、CIと一緒にスキャフォールディングするなら、Autopilotに一度設定すればあとは忘れていい。その設定はそのまま維持される。

エージェントセッションのworktreeとgit分離

これが本命だ。エージェントセッションが完全なworktreeとgit分離をサポートするようになった。つまり、エージェントがタスクに取り組むとき、専用のブランチと作業ディレクトリが割り当てられる。メインブランチは一切影響を受けない。

さらに良いことに、Copilot CLIがこれらのworktreeセッションに意味のあるブランチ名を生成してくれる。もうagent-session-abc123は終わりだ。エージェントが何をしているかを実際に説明する名前が付けられる。

複数のフィーチャーブランチを管理したり、長いスキャフォールディングタスクの実行中にバグを修正している.NET開発者にとって、これはゲームチェンジャーだ。あるworktreeでエージェントにAPIコントローラーを構築させながら、別のworktreeでサービスレイヤーの問題をデバッグできる。コンフリクトなし。スタッシュなし。混乱なし。

サブエージェントとエージェントチーム

Agent Host Protocolがサブエージェントをサポートするようになった。エージェントがタスクの一部を処理するために他のエージェントを起動できる。委任と考えればいい — メインエージェントが調整し、専門エージェントが各部分を担当する。

まだ初期段階だが、.NETワークフローへの可能性は明らかだ。あるエージェントがEF Coreのマイグレーションを処理し、別のエージェントが統合テストをセットアップする姿を想像してみてほしい。まだ完全には到達していないが、プロトコルサポートが今入ったということは、ツールもすぐに続くということだ。

エージェントが入力を送信するとターミナル出力が自動的に含まれるように

小さいが意味がある。エージェントがターミナルに入力を送信すると、ターミナル出力が自動的にコンテキストに含まれるようになった。以前は、エージェントが何が起きたかを読むために余分なターンが必要だった。

エージェントがdotnet buildを実行し、失敗し、エラーを確認するためだけにもう一回往復するのを見たことがあるなら — そのフリクションはなくなった。出力を即座に確認して反応する。

macOSのAgentsアプリが自動更新に

macOSのスタンドアロンAgentsアプリが自動更新されるようになった。新しいバージョンを手動でダウンロードする必要はもうない。常に最新の状態が保たれる。

知っておく価値のある小さなこと

package.jsonのホバーがインストール済みバージョンと最新の利用可能なバージョンの両方を表示するようになった。.NETプロジェクトと一緒にnpmツールを管理している場合に便利。
JSDocコメント内の画像がホバーや補完で正しくレンダリングされるようになった。
Copilot CLIセッションがVS Codeで作成されたか外部で作成されたかを表示するようになった — ターミナル間を行き来するときに便利。
Copilot CLI、Claude Code、Gemini CLIがシェルタイプとして認識されるようになった。エディタが何を実行しているか把握している。

まとめ

VS Code 1.117は派手な機能のダンプではない。インフラだ。worktree分離、永続的な権限、サブエージェントプロトコル — これらは、エージェントがコードを踏むことなく実際の並列タスクを処理するワークフローのための基盤だ。

.NETで開発していてエージェント型ワークフローにまだ踏み込んでいないなら、正直、今が始めるときだ。

Docker Sandboxで、Copilotエージェントがマシンをリスクにさらさずにコードをリファクタリングできるようになった

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。原文はこちらをご覧ください。

Copilotのエージェントモードを小さな編集以上のことに使ったことがあるなら、あの煩わしさは知っているはずです。ファイルへの書き込みのたびに、ターミナルコマンドのたびに、また許可プロンプト。これを50プロジェクトで想像してみてください。楽しくないですよね。

AzureチームがGitHub CopilotエージェントのためのDocker Sandboxに関する記事を公開しました。正直に言って、これはエージェンティックツーリングで見た中で最も実用的な改善の一つです。マイクロVMを使ってCopilotに完全に隔離された環境を提供し、パッケージのインストール、ビルドの実行、テストの実行まで、ホストシステムに一切触れずに自由に作業できます。

Docker Sandboxが実際に提供するもの

コアのアイデアはシンプルです：完全なLinux環境を持つ軽量なマイクロVMを起動し、ワークスペースをその中に同期させ、Copilotエージェントを内部で自由に動かす。完了したら変更が同期されて戻ってくる。

単なる「コンテナ内で実行する」以上のものにしているポイントはこちらです：

双方向ワークスペース同期で絶対パスが保持されます。プロジェクト構造はサンドボックス内でも同一に見えます。パス関連のビルドエラーはありません。
プライベートDockerデーモンがマイクロVM内で稼働。エージェントはホストのDockerソケットをマウントすることなくコンテナのビルドと実行が可能です。セキュリティ面で大きな進歩です。
HTTP/HTTPSフィルタリングプロキシがエージェントのネットワークアクセスを制御。どのレジストリとエンドポイントを許可するかはあなたが決められます。サンドボックス内の悪意あるnpm installによるサプライチェーン攻撃？ブロックされます。
YOLOモード — はい、本当にそう呼ばれています。エージェントは許可プロンプトなしで実行されます。なぜなら、文字通りホストを壊すことができないからです。すべての破壊的アクションが封じ込められています。

.NET開発者が注目すべき理由

今まさに多くのチームが直面しているモダナイゼーション作業を考えてみてください。30プロジェクトを含む.NET Frameworkソリューションがあり、.NET 9に移行する必要がある。数百のファイル変更が必要です — プロジェクトファイル、名前空間の更新、APIの置き換え、NuGetの移行。

Docker Sandboxを使えば、CopilotエージェントをプロジェクトにポイントしてマイクロVM内で自由にリファクタリングさせ、dotnet buildとdotnet testで検証し、実際に動作する変更だけを受け入れることができます。実験中にローカル開発環境を誤って壊してしまうリスクはありません。

記事では並列エージェントのフリートの運用も説明されています — それぞれが独自のサンドボックスで、異なるプロジェクトに同時に取り組みます。大規模な.NETソリューションやマイクロサービスアーキテクチャにとって、これは膨大な時間の節約になります。サービスごとに1エージェント、すべて隔離して実行、すべて独立して検証。

セキュリティの観点が重要

多くの人が見落としているポイントがあります：AIエージェントに任意のコマンドの実行を許可するということは、マシン全体を信頼して預けるということです。Docker Sandboxはそのモデルを逆転させます。エージェントは使い捨て環境内で完全な自律性を得ます。ネットワークプロキシが承認されたソースからのみダウンロードできることを保証します。ホストのファイルシステム、Dockerデーモン、認証情報は手つかずのままです。

コンプライアンス要件を持つチーム — そしてそれはほとんどのエンタープライズ.NET企業に当てはまります — にとって、これは「エージェンティックAIは使えない」と「安全に導入できる」の違いです。

まとめ

Docker Sandboxはエージェンティックコーディングの根本的なジレンマを解決します：エージェントは有用であるために自由が必要ですが、ホストマシンでの自由は危険です。マイクロVMは両方を実現します。大規模な.NETリファクタリングやモダナイゼーションを計画しているなら、今すぐセットアップする価値があります。Copilotのコードインテリジェンスとセキュアな実行環境の組み合わせは、まさにプロダクションチームが待ち望んでいたものです。

GitHub Copilotのモダナイゼーション評価は、まだ使っていない最高の移行ツール

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

レガシーな.NET Frameworkアプリをモダンな.NETに移行することは、誰もがやるべきだと知っているのに誰も始めたがらないタスクの一つです。「ターゲットフレームワークを変えるだけ」では済みません。消えたAPI、もう存在しないパッケージ、まったく異なる動作をするホスティングモデル、そして何をコンテナ化し、何を書き直し、何をそのままにするかについての無数の小さな決断があります。

Jeffrey FritzがGitHub Copilotのモダナイゼーション評価の詳細な解説を公開しましたが、正直なところ、.NET向けで見た中で最高の移行ツーリングです。コード生成のためではありません — それは今や当たり前です。生成される評価ドキュメントのためです。

単なるコード提案エンジンではない

VS Code拡張機能は評価 → 計画 → 実行モデルに従います。評価フェーズはコードベース全体を分析し、すべてをキャプチャする構造化ドキュメントを生成します：何を変更する必要があるか、どのAzureリソースをプロビジョニングするか、どのデプロイモデルを使用するか。その後のすべて — Infrastructure as Code、コンテナ化、デプロイマニフェスト — は評価結果から流れます。

評価はプロジェクトの.github/modernize/assessment/に保存されます。各実行は独立したレポートを生成するため、履歴が蓄積され、Issueを修正するにつれて移行の態勢がどう進化しているか追跡できます。

2つの始め方

推奨評価 — 素早い方法。キュレーションされたドメイン（Java/.NETアップグレード、Cloud Readiness、セキュリティ）から選び、設定をいじらずに意味のある結果を得ます。アプリがどこにいるかの最初の確認に最適です。

カスタム評価 — ターゲットを絞った方法。何を分析するか正確に設定：ターゲットコンピュート（App Service、AKS、Container Apps）、ターゲットOS、コンテナ化分析。複数のAzureターゲットを選んで移行アプローチを並べて比較できます。

その比較ビューは本当に便利です。App Serviceで必須Issueが3つのアプリが、AKSでは7つかもしれません。両方を見ることで、移行パスにコミットする前にホスティングの決定を導けます。

Issueの内訳はアクション可能

各Issueには重大度レベルが付いています：

必須 — 修正しなければ移行が失敗
潜在的 — 移行に影響する可能性あり、人間の判断が必要
オプション — 推奨される改善、移行をブロックしない

そして各Issueは影響を受けるファイルと行番号にリンクし、何が問題でなぜターゲットプラットフォームにとって重要なのかの詳細な説明を提供し、具体的な修正手順を示し（「これを直して」だけでなく）、公式ドキュメントへのリンクを含みます。

個々のIssueを開発者に渡すことができ、彼らにはアクションに必要なすべてが揃っています。これが「問題がある」と伝えるツールと「解決方法」を伝えるツールの違いです。

カバーされるアップグレードパス

.NET向け具体的に：

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

各アップグレードパスには、どのAPIが削除されたか、どのパターンに直接の等価物がないか、どのセキュリティ問題に注意が必要かを知る検出ルールがあります。

複数のアプリを管理するチーム向けには、マルチレポのバッチ評価をサポートするCLIもあります — すべてのリポをクローンし、すべてを評価し、アプリごとのレポートと集約されたポートフォリオビューを取得できます。

私の見解

レガシーな.NET Frameworkアプリを抱えているなら（そして正直に言って、ほとんどのエンタープライズチームがそうです）、これが始めるための最適なツールです。評価ドキュメントだけでも時間の価値があります — 漠然とした「モダナイズすべき」を、明確な前進の道筋を持つ具体的で優先順位付けされた作業項目リストに変えてくれます。

コラボレーティブなワークフローも賢いです：評価をエクスポートし、チームと共有し、再実行せずにインポート。意思決定者がツールを実行する人ではないアーキテクチャレビュー？カバーされています。

まとめ

GitHub Copilotのモダナイゼーション評価は、.NETの移行を怖い未定義のプロジェクトから構造化された追跡可能なプロセスに変えます。推奨評価から始めて現在地を確認し、カスタム評価でAzureターゲットを比較して移行計画を構築しましょう。

完全なウォークスルーを読み、VS Code拡張機能を入手して自分のコードベースで試してみてください。

エージェンティックなプラットフォームエンジニアリングが現実になりつつある — Git-APEがその方法を示す

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

プラットフォームエンジニアリングは、カンファレンスでは素晴らしく聞こえるけど、実際には「内部ポータルとTerraformラッパーを作りました」という意味になりがちな用語の一つです。本当の約束 — 安全で、ガバナンスが効いていて、高速なセルフサービスインフラ — はいつもあと数歩先にありました。

Azureチームがエージェンティックなプラットフォームエンジニアリングシリーズのパート2を公開しました。今回はハンズオンの実装がテーマです。彼らはこれをGit-APEと呼んでいます（はい、頭字語は意図的です）。これはGitHub CopilotエージェントとAzure MCPサーバーを使って、自然言語のリクエストを検証済みでデプロイされたインフラに変換するオープンソースプロジェクトです。

Git-APEが実際にやること

コアアイデア：開発者がTerraformモジュールを学んだり、ポータルUIをナビゲートしたり、プラットフォームチームにチケットを切る代わりに、Copilotエージェントに話しかけます。エージェントが意図を解釈し、Infrastructure-as-Codeを生成し、ポリシーに対して検証し、デプロイします — すべてVS Code内で。

セットアップはこちら：

git clone https://github.com/Azure/git-ape
cd git-ape

VS Codeでワークスペースを開くと、エージェント設定ファイルがGitHub Copilotによって自動検出されます。エージェントと直接やり取りします：

@git-ape deploy a function app with storage in West Europe

エージェントは内部でAzure MCPサーバーを使ってAzureサービスとやり取りします。VS Code設定のMCP構成で特定の機能を有効にします：

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

なぜこれが重要か

Azureで構築している私たちにとって、これはプラットフォームエンジニアリングの議論を「ポータルをどう構築するか」から「ガードレールをどうAPIとして記述するか」にシフトさせます。プラットフォームのインターフェースがAIエージェントになると、制約とポリシーの品質がプロダクトになります。

パート1のブログは理論を提示しました：よく記述されたAPI、コントロールスキーマ、明示的なガードレールがプラットフォームをエージェント対応にします。パート2は実際のツールを提供することでそれが機能することを証明しています。エージェントはリソースを盲目的に生成するのではなく、ベストプラクティスに対して検証し、命名規則を尊重し、組織のポリシーを適用します。

クリーンアップも同様に簡単です：

@git-ape destroy my-resource-group

私の見解

正直に言うと、これは特定のツールよりもパターンについてです。Git-APE自体はデモ/リファレンスアーキテクチャです。しかし根底にあるアイデア — プラットフォームへのインターフェースとしてのエージェント、プロトコルとしてのMCP、ホストとしてのGitHub Copilot — これがエンタープライズの開発者体験が向かう方向です。

内部ツールをエージェントフレンドリーにする方法を探しているプラットフォームチームなら、これ以上の出発点はありません。そして.NET開発者として自分の世界とどう繋がるか気になるなら：Azure MCPサーバーとGitHub Copilotエージェントはどんなのワークロードでも動作します。ASP.NET Core API、.NET Aspireスタック、コンテナ化されたマイクロサービス — すべてがエージェンティックなデプロイフローのターゲットになり得ます。

まとめ

Git-APEは、エージェンティックなプラットフォームエンジニアリングの実践における初期だが具体的な姿です。リポジトリをクローンし、デモを試し、プラットフォームのAPIとポリシーがエージェントに安全に使われるためにどうあるべきか考え始めてください。

完全な記事でウォークスルーとデモ動画をご覧ください。

Visual Studioの3月アップデートでカスタムCopilotエージェントが作成可能に — find_symbolが大きな進化

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

Visual Studioが最も重要なCopilotアップデートを受けました。Mark Downieが3月リリースを発表し、見出しはカスタムエージェントですが、正直なところfind_symbolツールがワークフローを最も変える機能かもしれません。

リポジトリ内のカスタムCopilotエージェント

Copilotにチームのコーディング標準に従わせたい？カスタムエージェントはリポジトリの.github/agents/に.agent.mdファイルとして定義されます。各エージェントはワークスペース認識、コード理解、ツール、優先モデル、MCP接続へのフルアクセスを持ちます。

エージェントスキル：再利用可能なインストラクションパック

スキルはリポジトリの.github/skills/またはプロファイルの~/.copilot/skills/から自動的にロードされます。

find_symbol：言語対応ナビゲーション

新しいfind_symbolツールはCopilotのエージェントモードに言語サービスベースのシンボルナビゲーションを提供します。テキスト検索の代わりに、シンボルのすべての参照を見つけ、型情報やスコープにアクセスできます。

.NET開発者にとって、これは大きな改善です — 深い型階層を持つC#コードベースが大きく恩恵を受けます。

Copilotでテストをプロファイル

Test ExplorerのコンテキストメニューにProfile with Copilotが追加されました。Profiling Agentがテストを実行し、パフォーマンスを自動分析します。

ライブデバッグ中のPerf Tips

パフォーマンス最適化がデバッグ中に行われるようになりました。Visual Studioがインラインで実行時間を表示します。遅い行を見つけたら、Perf Tipをクリックして最適化の提案をCopilotに依頼できます。

Solution ExplorerからNuGet脆弱性を修正

NuGetパッケージの脆弱性が検出されると、Solution Explorerに直接Fix with GitHub Copilotリンクが表示されます。

まとめ

カスタムエージェントとスキルが見出しですが、find_symbolが隠れた逸品です — .NETコードのリファクタリング時のCopilotの精度を根本的に変えます。Visual Studio 2026 Insidersをダウンロードしてお試しください。