Microsoft Copilot関連の今回の更新で最初に押さえるべき点は、一般ユーザー向けのMicrosoft 365 Copilotの画面変更ではなく、.NETでMicrosoft Agent FrameworkのGitHub Copilotエージェントを実装している開発者向けの破壊的変更だということです。
特に影響が大きいのは、GitHub.Copilot.SDKを0.1.29から0.3.0へ上げる対応です。OnPermissionRequestの扱い、MCP関連の型名、添付ファイル関連の型名、PermissionRequestResultKindの指定方法が変わるため、既存コードをそのまま更新するとビルドエラーや実行時例外につながる可能性があります。対象リポジトリのPRでは、Microsoft.Agents.AI.GitHub.CopilotをSDK 0.3.0へ適合させるための変更として整理されています。(GitHub)
Microsoft Copilot documentation updateの位置づけ
今回の「Microsoft Copilot documentation update: [BREAKING] .NET: Bump up GitHub.Copilot.SDK to 0.3.0 version」は、Microsoft Copilot全体の利用者向け告知というより、GitHub Copilot SDKをバックエンドに使う.NETエージェント実装の互換性対応として見るのが適切です。
Microsoft LearnのGitHub Copilotエージェント解説では、Microsoft Agent FrameworkがGitHub Copilot SDKをバックエンドとして使うエージェント作成をサポートし、シェルコマンド実行、ファイル操作、URL取得、MCPサーバー統合などの機能にアクセスできると説明されています。あわせて、GitHub Copilot CLIのインストールと認証、シェルやファイルアクセス権限を持つエージェントをコンテナー環境で動かす推奨も示されています。(Microsoft Learn)
つまり、今回確認すべき読者は次のような人です。
| 対象者 | 対応の必要性 |
|---|---|
| Microsoft 365 CopilotをWord、Excel、Teamsなどで使っている一般ユーザー | 基本的に対応不要 |
| GitHub Copilotをエディター補完だけで使っている開発者 | 直接の影響は限定的 |
.NETでMicrosoft.Agents.AI.GitHub.Copilotを使っている開発者 | 対応が必要になる可能性が高い |
| MCPサーバー、ツール実行、ファイル操作、セッション再開を使うエージェント開発者 | 重点的に確認が必要 |
SDK 0.3.0限定機能、特にセッション単位のGitHubTokenを使いたい開発者 | 更新内容の確認が必須 |
何が変わったのか
今回の中心は、Microsoft.Agents.AI.GitHub.Copilotが以前のGitHub.Copilot.SDK 0.1.29前提でビルドされていた点を、SDK 0.3.0へ合わせる変更です。PRでは、SDK 0.3.0でGA前の広範な型名整理が行われ、添付ファイル型、MCP設定型、セッション作成時のOnPermissionRequest必須化などが含まれると説明されています。SDK 0.3.0を取り込んだ利用者は、GitHubCopilotAgent.RunStreamingAsync呼び出し時にTypeLoadExceptionへ到達する可能性がある、という文脈で修正されています。(GitHub)
主な変更点は次のとおりです。
| 変更領域 | 変更内容 | 影響 |
|---|---|---|
| SDKバージョン | GitHub.Copilot.SDKを0.1.29から0.3.0へ更新 | 依存関係の整合性確認が必要 |
| 権限ハンドラー | OnPermissionRequestがセッション作成時に必須 | 未指定だとセッション作成時に例外の可能性 |
| 添付ファイル型 | UserMessageDataAttachmentsItem系からUserMessageAttachment系へ変更 | ファイル添付処理のコード修正が必要 |
| MCP設定型 | McpLocalServerConfig、McpRemoteServerConfigなどが変更 | MCPサーバー設定コードの修正が必要 |
| 権限結果 | 文字列指定からPermissionRequestResultKind enumへ変更 | "approved"のような文字列返却は見直し |
| セッション設定 | GitHubTokenなどSDK 0.3.0の新しい設定項目を転送 | マルチユーザー、セッション単位認証で重要 |
最も重要なのはOnPermissionRequestの必須化
実務上、最初に確認すべきなのはOnPermissionRequestです。
GitHub Copilotエージェントは、シェルコマンド実行、ファイル読み書き、URL取得、MCPツール呼び出しなど、開発環境に強い影響を与える操作を扱います。そのため、権限要求をどう許可・拒否するかを明示するハンドラーが重要になります。Microsoft Learnでも、既定ではシェルコマンド、ファイル読み書き、URLフェッチを実行できず、これらを有効にするにはSessionConfigでアクセス許可ハンドラーを指定すると説明されています。(Microsoft Learn)
今回の更新では、この考え方がさらに明確になっています。PRでは、SDK 0.3.0がすべてのCreateSessionAsync呼び出しでOnPermissionRequestを要求し、ハンドラーが指定されていない場合はSDKがセッション作成時に例外を投げる、と説明されています。隠れたデフォルトを注入せず、呼び出し側に明示させる設計です。(GitHub)
変更前に起きやすい失敗
たとえば、以前の感覚で次のように「とりあえずエージェントを作る」コードを書いている場合、SDK 0.3.0以降では見直しが必要です。
await using CopilotClient client = new();
await client.StartAsync();
AIAgent agent = client.AsAIAgent();
Console.WriteLine(await agent.RunAsync("List files in this directory"));問題は、権限要求を受け取ったときに「許可するのか、拒否するのか、ユーザーに確認するのか」が明示されていない点です。特に本番環境や共有開発環境では、安易な全許可は避けるべきです。
修正の考え方
安全寄りにするなら、最初はユーザー確認型または拒否中心のハンドラーから始めます。
static Task<PermissionRequestResult> PromptPermission(
PermissionRequest request,
PermissionInvocation invocation)
{
Console.WriteLine($"Permission request: {request.Kind}");
Console.Write("Approve? (y/n): ");
string? input = Console.ReadLine()?.Trim().ToUpperInvariant();
var kind = input is "Y" or "YES"
? PermissionRequestResultKind.Approved
: PermissionRequestResultKind.Rejected;
return Task.FromResult(new PermissionRequestResult { Kind = kind });
}
await using CopilotClient client = new();
await client.StartAsync();
SessionConfig sessionConfig = new()
{
OnPermissionRequest = PromptPermission,
};
AIAgent agent = client.AsAIAgent(sessionConfig);
Console.WriteLine(await agent.RunAsync("List files in the current directory"));ポイントは、PermissionRequestResult.Kindに文字列ではなくPermissionRequestResultKindを使うことです。PR内のサンプル差分でも、"approved"のような文字列指定からPermissionRequestResultKind.Approvedへ変更されています。(GitHub)
影響範囲は「エージェント実装」に集中する
今回の更新は、Microsoft Copilotという名前が含まれていても、すべてのCopilot利用者が対応するものではありません。影響が集中するのは、次のようなコードです。
| 確認すべきコード | 見るべきポイント |
|---|---|
CopilotClient.AsAIAgent() | SessionConfigまたはonPermissionRequestを渡しているか |
new GitHubCopilotAgent(...) | 古いコンストラクター呼び出しになっていないか |
CreateSessionAsync() | OnPermissionRequestを含む設定が渡る設計になっているか |
RunStreamingAsync() | SDK型の不一致で実行時例外が出ないか |
| MCP設定 | 旧型名を使っていないか |
| 添付ファイル処理 | 旧Attachment型を参照していないか |
| セッション再開 | GitHubTokenや新しいセッション設定がコピーされるか |
特に注意したいのは、ビルドが通っても実行時に落ちるケースです。依存関係の解決によってSDK 0.3.0が入っているのに、Agent Framework側のコードや自作ラッパーが古い型名を前提にしていると、呼び出しタイミングで例外が表面化する可能性があります。
GitHub Copilot SDK側のIssueでも、OnPermissionRequestがセッション作成時に必要であるため、AIAgent.CreateSessionAsync()経由で設定を渡せないと実行時例外になる、という報告が出ています。そこでは、OnPermissionRequestハンドラーが必要であり、CreateSessionAsync(new() { OnPermissionRequest = ... })のような指定例が示されています。(GitHub)
型名変更で確認すべきポイント
SDK 0.3.0では、GA前の整理として型名の見直しが入っています。今回のPRで明示されている代表的な変更は次のとおりです。(GitHub)
| 旧名称 | 新名称 | 用途 |
|---|---|---|
UserMessageDataAttachmentsItem | UserMessageAttachment | ユーザーメッセージの添付情報 |
UserMessageDataAttachmentsItemFile | UserMessageAttachmentFile | ファイル添付 |
McpLocalServerConfig | McpStdioServerConfig | ローカルstdio型MCPサーバー |
McpRemoteServerConfig | McpHttpServerConfig | HTTP型MCPサーバー |
PermissionRequestResultKindの文字列指定 | enum指定 | 権限リクエスト結果 |
この変更は単なる名前の置き換えに見えますが、実務では影響が広がりやすい箇所です。
たとえば、MCPサーバー設定を共通ライブラリ化している場合、アプリ本体ではなく社内パッケージ側に旧型名が残ることがあります。また、添付ファイル処理はチャットメッセージ変換や一時ファイル保存処理と結びついていることが多いため、単純な検索置換だけではテスト不足になりがちです。
MCPサーバーを使っている場合の確認
MCP連携を使っている開発チームは、今回の更新を軽視しないほうがよいでしょう。
Microsoft LearnのGitHub Copilotエージェント解説では、ローカルstdioまたはリモートHTTPのMCPサーバーに接続して拡張できると説明されています。更新前のサンプルではMcpLocalServerConfigやMcpRemoteServerConfigが使われていますが、今回のPRではSDK 0.3.0に合わせてMcpStdioServerConfig、McpHttpServerConfigへの変更が示されています。(Microsoft Learn)
修正イメージは次のようになります。
SessionConfig sessionConfig = new()
{
OnPermissionRequest = PromptPermission,
McpServers = new Dictionary<string, McpServerConfig>
{
["filesystem"] = new McpStdioServerConfig
{
Type = "stdio",
Command = "npx",
Args = ["-y", "@modelcontextprotocol/server-filesystem", "."],
Tools = ["*"],
},
["microsoft-learn"] = new McpHttpServerConfig
{
Type = "http",
Url = "https://learn.microsoft.com/api/mcp",
Tools = ["*"],
},
},
};ここで重要なのは、MCPサーバー設定の型だけでなく、McpServersの辞書型も確認することです。PRの差分では、Dictionary<string, object>からDictionary<string, McpServerConfig>へ変更されている箇所があります。(GitHub)
SessionConfigのコピー処理も見直すべき
自作のラッパーや共通基盤でSessionConfigをコピーしている場合は、SDK 0.3.0の新しいプロパティを落としていないか確認してください。
PRでは、CopySessionConfigやCopyResumeSessionConfigを通じて、SDK 0.3.0で追加・重要化された複数のプロパティを転送する対応が入っています。例として、SessionId、ClientName、ModelCapabilities、EnableConfigDiscovery、IncludeSubAgentStreamingEvents、DefaultAgent、Agent、OnElicitationRequest、OnEvent、CreateSessionFsHandler、Commands、GitHubTokenなどが挙げられています。(GitHub)
この部分は、見落とすと症状が分かりにくくなります。
| 落としやすい設定 | 起こり得る問題 |
|---|---|
GitHubToken | セッション単位の認証が期待どおり動かない |
Commands | カスタムコマンドが利用できない |
OnElicitationRequest | UI確認や入力要求の処理が失われる |
EnableConfigDiscovery | MCPやスキルの自動検出が効かない |
CreateSessionFsHandler | セッションファイルシステムのカスタム処理が使われない |
ModelCapabilities | モデル機能の上書きが反映されない |
特にマルチユーザーのホステッド環境では、GitHubTokenの扱いが重要です。PRの動機でも、SDK 0.3.0限定機能としてセッション単位のGitHubTokenに触れられています。(GitHub)
移行前にやるべき確認手順
SDK更新は、NuGetパッケージのバージョンを上げるだけで終わらせないほうが安全です。次の順番で確認すると、実行時トラブルを減らせます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 依存関係を確認する | GitHub.Copilot.SDKがどのバージョンで解決されているか |
| 2 | Agent Framework側のバージョンを確認する | SDK 0.3.0対応済みのパッケージか |
| 3 | OnPermissionRequestを検索する | すべてのセッション作成経路で設定されているか |
| 4 | 旧型名を検索する | McpLocalServerConfigなどが残っていないか |
| 5 | 権限結果の文字列指定を検索する | "approved"などをenumに直せるか |
| 6 | MCPとツール呼び出しをテストする | 単純な会話だけでなく、実際のツール実行まで確認する |
| 7 | ストリーミング応答をテストする | RunStreamingAsyncで例外が出ないか |
| 8 | セッション再開をテストする | CreateSessionAsync(sessionId)やresume系で設定が維持されるか |
検索するときは、次のキーワードを使うと効率的です。
AsAIAgent(
GitHubCopilotAgent
CreateSessionAsync
RunStreamingAsync
OnPermissionRequest
PermissionRequestResult
McpLocalServerConfig
McpRemoteServerConfig
UserMessageDataAttachmentsItem
GitHubToken本番環境で避けたい実装
移行時にやりがちな失敗は、OnPermissionRequestを満たすためだけに全許可へ寄せることです。
開発中のローカル検証では、ApproveAll相当の実装が便利な場合もあります。しかし、本番環境やCI、共有サーバーでエージェントがシェルコマンドやファイル操作を実行できる場合、全許可はリスクが高くなります。
避けたいパターンは次のとおりです。
| 避けたい実装 | 理由 |
|---|---|
| すべての権限要求を無条件に許可する | 意図しないコマンド実行やファイルアクセスにつながる |
| 権限要求の内容をログに残さない | 後から原因調査できない |
| ユーザー単位のトークンを共通化する | 操作主体の追跡が難しくなる |
MCPサーバーのTools = ["*"]を無制限に使う | 利用可能ツールが広がりすぎる |
| コンテナー外の作業ディレクトリを直接触らせる | ホスト環境への影響が大きい |
実務では、まず開発環境で明示確認型のハンドラーを使い、ステージングでは許可対象を限定し、本番では操作ログとユーザー単位の認可を組み合わせるのが現実的です。
すぐ確認できる移行チェックリスト
今回のMicrosoft Copilot documentation updateを受けて、.NET開発者がすぐ確認すべき項目を整理します。
| チェック項目 | 判定 |
|---|---|
GitHub.Copilot.SDK 0.3.0を使う予定がある | 影響あり |
Microsoft.Agents.AI.GitHub.Copilotを使っている | 影響あり |
OnPermissionRequestを設定していない | 修正が必要 |
| MCPサーバー設定で旧型名を使っている | 修正が必要 |
PermissionRequestResult.Kindに文字列を入れている | enumへの変更を検討 |
| 添付ファイル処理で旧Attachment型を参照している | 修正が必要 |
| セッション設定を独自にコピーしている | 新プロパティの転送漏れを確認 |
| 単純なチャット応答だけをテストしている | ツール実行、MCP、ストリーミングもテスト |
まだPR段階である点にも注意
今回の情報は、GitHub上のPRとして公開・更新されている内容に基づきます。該当PRは[BREAKING]が付いた.NET向け変更で、2026年5月5日にレビューや追加コミットが行われています。一方で、取得時点のPR表示ではオープン状態で、マージには少なくとも2件の承認レビューが必要と表示されています。(GitHub)
そのため、実際に対応する際は次の3点を確認してください。
- 利用中のNuGetパッケージに該当変更が反映されているか
- Microsoft Learnのサンプルが最新のSDK 0.3.0表記に更新されているか
- GitHub Copilot SDK側のリリースノートやIssueで追加の既知問題がないか
特に、SDKやCLIの組み合わせによって権限応答の扱いに問題が出るケースも報告されています。別Issueでは、@github/copilot CLIのバージョンによってunexpected user permission responseが発生する再現情報が示され、SDKバージョンだけでなくCLI側のバージョンも要因になり得るとされています。(GitHub)
まとめ：.NETのGitHub Copilotエージェントは権限処理から確認する
今回のMicrosoft Copilot関連アップデートは、.NETでGitHub Copilotエージェントを作っている開発者にとって、単なる依存関係更新ではありません。GitHub.Copilot.SDK 0.3.0への対応により、OnPermissionRequestの必須化、型名変更、MCP設定の見直し、セッション設定の転送項目追加が発生します。
最初にやるべきことは明確です。自分のコードでAsAIAgent、GitHubCopilotAgent、CreateSessionAsync、OnPermissionRequestを検索し、すべてのセッション作成経路で権限ハンドラーが明示されているか確認してください。そのうえで、MCP設定、添付ファイル処理、PermissionRequestResultKind、GitHubTokenなどの新しいセッション設定を順番に確認すると、安全に移行しやすくなります。
コメント