.NET DevBlogs「Microsoft Binlog MCP Server」の変更点｜設定・影響・注意点

2026年6月17日、Microsoftは.NET DevBlogsで、MSBuildのバイナリログをAIアシスタントから調査できる「Microsoft Binlog MCP Server」をプレビュー公開しました。

結論として、今回の発表は.NETやMSBuildのビルド仕様を変更する強制アップデートではありません。既存の.binlog解析に、GitHub Copilotなどへ自然言語で質問できる新しい調査方法が追加されたものです。通常の.NET利用者に移行作業は不要ですが、ビルド障害の調査担当者や開発環境の管理者は、導入設定、ログの機密性、AIツールの利用ポリシーを確認する必要があります。(Microsoft for Developers)

.NET DevBlogsの新機能・変更点：AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server

「AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server」で発表された主な変更点は、MSBuildのバイナリログをAIアシスタントが専用ツール経由で読み取り、原因調査や性能分析を進められるようになったことです。

.NET DevBlogs自体の画面や料金体系が変わるわけではなく、DevBlogs上で新しい.NET開発ツールが告知されたと理解すると分かりやすいでしょう。

確認項目	2026年6月17日時点の内容
新機能	Microsoft Binlog MCP Server
提供状態	プレビュー
対象データ	MSBuildの`.binlog`ファイル
主な用途	ビルド失敗調査、プロパティ追跡、性能分析、ビルド比較
対応するAI環境の例	GitHub Copilot、Copilot CLI、Claude Codeなど
MSBuildへの影響	ビルドエンジンの仕様変更はない
必須対応	なし。利用する場合のみ設定が必要
移行期限	公式記事には記載なし
専用料金	公式記事には記載なし

従来はMSBuild Structured Log Viewerを開き、プロジェクト、ターゲット、タスク、プロパティを手作業でたどる必要がありました。Microsoft Binlog MCP Serverを使うと、「なぜビルドに失敗したのか」「どのターゲットが遅いのか」といった質問をAIアシスタントに伝え、必要な調査ツールを順番に呼び出させられます。(Microsoft for Developers)

Microsoft Binlog MCP Serverで何ができるのか

Microsoft Binlog MCP Serverは、Model Context Protocol（MCP）を通じて、AIアシスタントにMSBuildログ解析用の機能を提供します。

MCPは、AIアシスタントが外部ツールを一定の形式で呼び出すための仕組みです。AIが.binlogを推測だけで説明するのではなく、専用ツールからエラー、プロパティ、実行時間などを取得して回答できる点が重要です。

公開時点では15種類の解析ツールを提供

2026年6月17日の公開記事では、15種類のツールが次の4分野に分類されています。(Microsoft for Developers)

分野	主なツール	調査できること
ビルド調査	`binlog_overview`、`binlog_errors`、`binlog_warnings`、`binlog_search`	ビルド結果、エラー、警告、ログ内の文字列を調査
プロジェクト・設定調査	`binlog_projects`、`binlog_properties`、`binlog_items`、`binlog_imports`、`binlog_explain_property`	プロジェクト構成、プロパティ値、Item、読み込まれた`.props`や`.targets`、値の設定元を確認
埋め込みファイル調査	`binlog_files`、`binlog_search_files`	binlogに取り込まれたファイルの参照や検索
性能分析	`binlog_expensive_projects`、`binlog_expensive_targets`、`binlog_expensive_tasks`	時間のかかっているプロジェクト、ターゲット、タスクを特定
ビルド比較	`binlog_compare`	2つのbinlog間でプロパティやパッケージなどを比較

特に実務で効果が大きいのが、binlog_explain_propertyです。

MSBuildでは、同じプロパティがプロジェクトファイル、Directory.Build.props、SDK、ターゲット、コマンドラインなどから何度も設定されることがあります。このツールを使うと、最終的な値だけでなく、どのファイルや処理が値を設定したかを追跡できます。

Structured Log Viewerを完全に置き換えるものではない

Microsoft Binlog MCP Serverは、MSBuild Structured Log Viewerで使われているStructuredLoggerの仕組みを基盤としています。検索では、$error、$warning、$task、$targetなどのノード種別や、階層を絞り込む検索構文も利用できます。(Microsoft for Developers)

比較項目	Microsoft Binlog MCP Server	Structured Log Viewer
操作方法	AIとの自然言語による会話	ツリーや検索画面を手動操作
得意な用途	原因候補の整理、複数ツールを使った横断調査	ログの詳細確認、特定ノードの目視検証
利用環境	MCP対応AIアシスタント	専用アプリまたは対応ビューアー
注意点	AIの説明内容を検証する必要がある	MSBuildの構造に関する知識が必要
提供状態	プレビュー	既存のログ解析手段

実務では、最初の切り分けをAIに任せ、最終確認をStructured Log Viewerで行う使い分けが安全です。

誰に影響する変更なのか

影響の大きさは、MSBuildログを日常的に調査しているかどうかで変わります。

対象者	影響	確認すべきこと
.NET開発者	ビルドエラーの初動調査を短縮できる	対応するAI環境とMCP設定
ビルド・CI担当者	遅いターゲットやタスクを抽出しやすくなる	CIで取得したbinlogの保存・持ち出しルール
ライブラリ管理者	SDKやパッケージ変更前後の比較に使える	比較条件をそろえたbinlogの取得
開発環境管理者	新しいMCPサーバーを組織環境に追加する判断が必要	Copilotポリシー、許可リスト、テレメトリ
AIアシスタントを使わない利用者	原則として影響なし	対応不要
MSBuildを使わない利用者	影響なし	対応不要

今回の機能は任意導入です。既存のプロジェクトファイルやCIパイプラインを直ちに書き換える必要はありません。

導入前に確認したい利用条件

利用環境ごとの主な条件は次のとおりです。

Visual Studio

Visual Studioでは、GitHub CopilotのエージェントモードからMCPサーバーを使用します。公式記事ではVisual Studio 17.14以降が必要とされ、dotnet-msbuildプラグインの導入後にBinlog MCP Serverが自動検出されると説明されています。(Microsoft for Developers)

確認するポイントは次の3つです。

Visual Studio 17.14以降を利用している
GitHub Copilotへサインインできている
Copilot Chatをエージェントモードに切り替えている

MCPサーバーが表示されない場合は、Copilot Chatのツール一覧、組織ポリシー、MCP設定ファイルを確認します。

Visual Studio Code

VS Codeでは、プラグイン機能とdotnet/skillsマーケットプレイスを有効にします。

{
  "chat.plugins.enabled": true,
  "chat.plugins.marketplaces": [
    "dotnet/skills"
  ]
}

設定後、プラグイン一覧からdotnet-msbuildをインストールします。VS Codeのプラグイン対応はプレビュー機能であり、今後設定方法が変わる可能性があります。(Microsoft for Developers)

MCPサーバーを直接登録する場合は、.vscode/mcp.jsonに次のような設定を追加します。

{
  "servers": {
    "binlog-mcp": {
      "type": "stdio",
      "command": "dotnet",
      "args": [
        "tool",
        "run",
        "Microsoft.AITools.BinlogMcp"
      ]
    }
  }
}

特定のbinlogを起動時に読み込ませる場合は、--binlog引数を指定できます。

{
  "servers": {
    "binlog-mcp": {
      "type": "stdio",
      "command": "dotnet",
      "args": [
        "tool",
        "run",
        "Microsoft.AITools.BinlogMcp",
        "--",
        "--binlog",
        "msbuild.binlog"
      ]
    }
  }
}

直接設定が正常に動かない場合は、先に公式推奨のdotnet-msbuildプラグイン方式を試すのが確実です。(Microsoft for Developers)

Copilot CLIやClaude Code

ターミナル型のAIアシスタントでは、dotnet/skillsマーケットプレイスからプラグインをインストールします。

/plugin marketplace add dotnet/skills
/plugin install dotnet-msbuild@dotnet-agent-skills

インストール後にAIアシスタントを再起動し、/skillsで読み込まれていることを確認します。(Microsoft for Developers)

binlogを作成してAIに調査させる手順

binlogを生成する

プロジェクトまたはソリューションのディレクトリで、次のコマンドを実行します。

dotnet build -bl:msbuild.binlog

ファイル名を省略した場合は、通常、現在のディレクトリにmsbuild.binlogが作成されます。dotnet testやdotnet packなど、MSBuildを利用する処理でもバイナリロガーを指定できます。(Microsoft Learn)

比較調査では、同じファイル名で上書きしないようにします。

dotnet build -c Release -bl:release-before.binlog
dotnet build -c Release -bl:release-after.binlog

SDK、構成、ブランチなど、比較対象以外の条件をそろえることが重要です。条件が異なると、AIが見つけた差分が変更の影響なのか、単なるビルド条件の違いなのか判断しにくくなります。

AIアシスタントに調査を依頼する

単に「エラーを直して」と依頼するより、調査条件と出力形式を指定したほうが精度を上げやすくなります。

ビルド失敗を調査する例は次のとおりです。

msbuild.binlogを調査してください。
最初に発生した根本エラーと、その後に連鎖して発生したエラーを分けてください。
関係するプロジェクト、ターゲット、タスク、ファイル、行番号を示し、
修正候補を優先度順に整理してください。

プロパティの設定元を確認する場合は、次のように依頼します。

msbuild.binlog内のRuntimeIdentifierについて、
最終値と、その値を設定または上書きしたファイルやターゲットを追跡してください。

ビルド性能を調査する例です。

msbuild.binlogを分析し、
排他的実行時間が長いプロジェクト、ターゲット、タスクを上位10件示してください。
待機時間と実処理時間を混同せず、改善候補も説明してください。

2つのビルドを比較する場合は、次のように指定します。

release-before.binlogとrelease-after.binlogを比較してください。
変更されたMSBuildプロパティとパッケージを抽出し、
ビルド時間の増加と関係しそうな差分を根拠付きで示してください。

更新・移行・料金・期限で確認すべきこと

項目	対応方針
設定	利用する開発環境に`dotnet-msbuild`プラグインまたはMCP設定を追加する
更新	プレビュー期間中はプラグイン、起動コマンド、ツール構成の変更を想定する
移行	既存のMSBuildやStructured Log Viewerからの強制移行はない
料金	MCP Server専用の料金は公式発表に記載されていない。AIアシスタント側の契約条件は別途確認する
期限	導入期限、移行期限、旧機能の終了日は発表されていない
本番導入	小規模な検証環境で動作と回答品質を確認してから展開する

Copilot CLIやClaude Codeでプラグインを更新する場合は、公式リポジトリで次のコマンドが案内されています。

/plugin update dotnet-msbuild@dotnet-agent-skills

dotnet/skillsリポジトリはMITライセンスで公開されています。一方、利用するGitHub Copilotやその他のAIアシスタントについては、組織の契約、利用上限、データ処理条件を別に確認する必要があります。(GitHub)

管理者が確認すべきセキュリティとテレメトリ

binlogは通常のエラーログより多くの情報を含む

binlogには、ビルド中に評価されたプロパティ、Item、実行されたタスク、その入出力、読み込まれたプロジェクトファイルや.props、.targetsなどが記録されます。ビルド中に参照された環境変数が含まれる場合もあります。

APIトークンや証明書関連の値を環境変数やMSBuildプロパティで渡している環境では、binlogを外部へ共有する前に内容を確認してください。(Microsoft Learn)

外部共有用として、インポートファイルを埋め込まないbinlogを作成する方法もあります。

dotnet build "-bl:msbuild.binlog;ProjectImports=None"

ただし、.propsや.targetsの内容が含まれなくなるため、プロパティの設定元やインポート関係の調査能力は下がります。通常の社内調査用と、外部共有用のログを分ける運用が現実的です。(Microsoft Learn)

利用状況テレメトリは標準で有効

公式記事によると、Microsoft Binlog MCP Serverは次の匿名テレメトリを送信します。

呼び出されたツール名
処理時間
結果サイズ
成功または失敗

binlogの内容、ファイルパス、生のエラーメッセージは収集せず、ファイル名は相関確認用にHMAC-SHA256でハッシュ化すると説明されています。(Microsoft for Developers)

テレメトリを無効にする場合は、.NET CLIと共通の環境変数を設定します。

LinuxやmacOSでは次のとおりです。

export DOTNET_CLI_TELEMETRY_OPTOUT=1

PowerShellでは次のように設定できます。

$env:DOTNET_CLI_TELEMETRY_OPTOUT = "1"

恒久的に無効化する場合は、OSや端末管理ツールの環境変数設定へ反映します。

組織ではMCPサーバーの許可範囲を決める

Visual Studioでは、GitHub Copilotの管理ポリシーやMCPサーバーの許可リストを利用し、接続を認めるサーバーを制御できます。管理対象端末へ展開する場合は、利用者が任意のMCPサーバーを追加できる状態にするのではなく、承認済みサーバーと設定例を管理者側で定義するのが安全です。(Microsoft Learn)

最低限、次のルールを決めておきましょう。

binlogを保存できる場所
ログの保存期間と削除方法
外部AIサービスへ渡してよいプロジェクトの範囲
利用を許可するMCPサーバー
AIが提示した修正を適用する前のレビュー手順

導入時に失敗しやすいポイント

症状	主な原因	対処
`binlog_*`ツールが表示されない	エージェントモードになっていない	Copilot Chatのモードとツール一覧を確認
Visual Studioで認識されない	バージョンが古い	Visual Studio 17.14以降へ更新
VS Codeでプラグインが見つからない	プラグイン機能やマーケットプレイスが未設定	`settings.json`を確認して再起動
CLIでインストール後も利用できない	プラグインが再読み込みされていない	AIアシスタントを再起動し、`/skills`を実行
比較結果に大量の差分が出る	SDK、構成、ブランチなどの条件が違う	比較対象以外の条件を固定して再取得
AIが表面的なエラーだけを回答する	調査条件が曖昧	最初の根本エラーと派生エラーを分けるよう指定
機密情報を含むログを共有してしまう	binlogの収録範囲を確認していない	共有前にログを検査し、必要なら`ProjectImports=None`を使用
AIの修正で別のビルドが壊れる	提案を検証せず適用した	差分レビューと再ビルドを必須にする

まずは1件の失敗ビルドで効果を確認する

Microsoft Binlog MCP Serverは、複雑なMSBuildログを自然言語から調査できる実用的な新機能です。一方、2026年6月17日時点ではプレビューであり、既存のログ解析手段を直ちに置き換えるものではありません。

導入する場合は、まず機密情報を含まないテスト用リポジトリでbinlogを生成し、同じログをAIとStructured Log Viewerの両方で調査してください。原因特定の正確さ、調査時間、不要な提案の有無を確認したうえで、ログ管理ルールとMCP利用ポリシーを整備します。

一般の.NET利用者には対応不要です。ビルド障害や性能問題の調査に時間を取られているチームは、最初の検証対象として、再現性のある失敗ビルドを1件選ぶと効果を判断しやすくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

.NET DevBlogs「Microsoft Binlog MCP Server」の変更点｜設定・影響・注意点

.NET DevBlogsの新機能・変更点：AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server

Microsoft Binlog MCP Serverで何ができるのか

公開時点では15種類の解析ツールを提供

Structured Log Viewerを完全に置き換えるものではない

誰に影響する変更なのか

導入前に確認したい利用条件

Visual Studio

Visual Studio Code

Copilot CLIやClaude Code

binlogを作成してAIに調査させる手順

binlogを生成する

AIアシスタントに調査を依頼する

更新・移行・料金・期限で確認すべきこと

管理者が確認すべきセキュリティとテレメトリ

binlogは通常のエラーログより多くの情報を含む

利用状況テレメトリは標準で有効

組織ではMCPサーバーの許可範囲を決める

導入時に失敗しやすいポイント

まずは1件の失敗ビルドで効果を確認する

この記事を書いた人

コメント

コメントするコメントをキャンセル

.NET DevBlogs「Microsoft Binlog MCP Server」の変更点｜設定・影響・注意点

.NET DevBlogsの新機能・変更点：AI-Powered MSBuild Investigation with the Microsoft Binlog MCP Server

Microsoft Binlog MCP Serverで何ができるのか

公開時点では15種類の解析ツールを提供

Structured Log Viewerを完全に置き換えるものではない

誰に影響する変更なのか

導入前に確認したい利用条件

Visual Studio

Visual Studio Code

Copilot CLIやClaude Code

binlogを作成してAIに調査させる手順

binlogを生成する

AIアシスタントに調査を依頼する

更新・移行・料金・期限で確認すべきこと

管理者が確認すべきセキュリティとテレメトリ

binlogは通常のエラーログより多くの情報を含む

利用状況テレメトリは標準で有効

組織ではMCPサーバーの許可範囲を決める

導入時に失敗しやすいポイント

まずは1件の失敗ビルドで効果を確認する

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル