複数プロジェクトのビルドが赤くなったとき、.binlogをStructured Log Viewerで掘る作業に何時間も溶かした経験はありませんか。

2026年6月17日、Microsoftはプレビュー版のMicrosoft Binlog MCP Serverを公開しました。MSBuildのバイナリログ（.binlog）をAIアシスタントが直接読み取り、自然言語の質問だけでビルド失敗の原因追跡や性能ボトルネックの特定ができます（参考）。

この記事では、Binlog MCP Serverの仕組み、15個の専用ツール、導入方法、実務での使い方を整理します。

この記事でわかること

  • Binlog MCP Serverが解決するビルド診断の課題
  • 15個のbinlog_*ツールの役割分担
  • Visual Studio・VS Code・Claude Codeでの導入手順
  • ビルド比較や性能分析の具体的な活用法

手作業のログ解析がボトルネックになる理由

MSBuildのバイナリログには、プロパティ評価、ターゲット実行、タスク呼び出し、エラー、警告などビルドの全記録が詰まっています。公式ブログでも「複雑なマルチプロジェクトソリューションのデバッグでは、このデータを手動で辿るのは圧倒的に大変」と説明されています（参考）。

従来はMSBuild Structured Log Viewerというデスクトップアプリでノードを展開しながら調査するのが定石でした。CIで失敗したログをダウンロードし、何千行ものツリー構造を目視で追う作業は、原因がプロパティの上書きやインポートチェーンの奥深くにあるほど時間がかかります。InfoWorldの報道でも、開発者が「なぜビルドが失敗したのか」「何がビルドを遅くしているのか」とAIに直接聞ける点が強調されています（参考）。

Binlog MCP Serverは、この手作業をAIアシスタントに委ねるための橋渡しです。

MCPでビルドログをAIに渡す仕組み

MCP（Model Context Protocol）は、AIアシスタントが外部ツールを構造化された形で呼び出すためのオープン標準です。Binlog MCP Serverはこのプロトコル上で動作し、.binlogファイルを解析して15個の専用ツールをAIに公開します。

内部ではMSBuild Structured Log Viewerと同じエンジンであるStructuredLoggerライブラリを使っています。デスクトップアプリで見慣れたログ構造を、そのままAIがクエリできる形に変換しているイメージです。binlog_searchはStructuredLog Viewerの検索DSLにも対応し、$errorや$warningなどのノード種別フィルタ、under()による階層スコープ、引用符による完全一致検索が使えます（参考）。

公開パッケージ名はMicrosoft.AITools.BinlogMcpのdotnet toolです。配布は.NET Agent Skillsリポジトリ（dotnet/skills）のdotnet-msbuildプラグインにまとめられ、ビルド失敗診断や性能最適化向けのスキルとエージェントも同梱されています。

15個のツールが担う4つの仕事

https://devblogs.microsoft.com/dotnet/msbuild-binlog-mcp-server/

公式ドキュメントでは、15個のツールが4カテゴリに分類されています。

ビルド調査では、binlog_overviewがビルド状態・所要時間・プロジェクト数・エラー警告数の概要を返します。binlog_errorsはプロジェクト、ターゲット、タスク、ファイル、行番号まで含むエラー一覧を取得し、binlog_warningsは警告コードでフィルタ可能です。プロパティの値がどこで決まったかを追うbinlog_explain_propertyは、CIとローカルで結果が食い違うときに特に効きます。TargetFrameworkやNuGetフィードの設定がビルドエージェント上でどう解決されたかを、推測ではなく評価チェーンとして提示してくれます。

埋め込みファイルでは、binlog_filesとbinlog_search_filesがビルド時にキャプチャされたソースファイルの一覧取得や全文検索を担います。

性能分析では、binlog_expensive_projects、binlog_expensive_targets、binlog_expensive_tasksが排他的な所要時間でランキングを返し、遅いプロジェクトやターゲットを特定します。

ビルド比較のbinlog_compareは2つの.binlogを差分し、プロパティやパッケージの変化を洗い出します。ブランチ切り替え前後やSDKバージョン違いのビルドを並べて調べる用途に向いています。

導入はdotnet-msbuildプラグインが最短ルート

環境ごとの導入方法は次のとおりです。

Visual Studioでは、Visual Studio 2022 17.14以降でGitHub CopilotのエージェントモードがMCPサーバーをサポートします。dotnet-msbuildプラグインを入れると、Copilot ChatのエージェントモードがBinlog MCP Serverを自動検出し、ソリューション内の.binlogについてbinlog_*ツールが使えるようになります。

Visual Studio Codeでは、settings.jsonにマーケットプレイスを追加してプラグインをインストールする方法と、mcp.jsonに直接サーバーを書く方法があります。

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

起動時に特定のログを読み込ませたい場合は、--binlog引数を追加します。Cursorでもdotnet/skillsをマーケットプレイスとしてプラグインを導入できます（参考）。

ターミナル系AI（GitHub Copilot CLI、Claude Code）では、マーケットプレイスを追加してプラグインをインストールするだけです。

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

再起動後、/skillsで読み込みを確認できます。

実務での使い方

まずログを生成します。dotnet build、dotnet test、dotnet packのいずれにも/blフラグを付けられます。

dotnet build /bl

ファイル名を指定する場合はdotnet build /bl:build-a.binlogのように書きます。ログができたら、AIアシスタントに「ビルドが失敗した。msbuild.binlogを調べて原因を教えて」と依頼します。アシスタントはbinlog_overviewで全体像を掴み、binlog_errorsでエラー詳細を取得し、必要に応じてbinlog_explain_propertyやbinlog_searchで根本原因を追います。

性能調査では「何がビルドを遅くしているか」と聞くだけで、高コストなプロジェクトやタスクのランキングが返ります。2つのビルドを比較する場合は、mainブランチとfeatureブランチでそれぞれ/blを取り、「build-a.binlogとbuild-b.binlogを比較して、プロパティとパッケージの差分と性能への影響を教えて」と依頼するのが公式が推奨する試し方です（参考）。

テレメトリとプレビュー段階の注意点

サーバーは匿名の利用テレメトリ（ツール名、レイテンシ、結果サイズ、成功失敗）を送信します。.NET SDKと同様、デフォルトで有効で、DOTNET_CLI_TELEMETRY_OPTOUT=1でオプトアウトできます。binlogの中身、ファイルパス、生のエラーメッセージは収集されず、ファイル名のみHMAC-SHA256でハッシュ化されると公式に明記されています。

現時点ではプレビュー版です。改善要望はdotnet/skillsリポジトリにIssueを投げる形でフィードバックできます。MSBuildビルドとAIコーディングアシスタントを併用している開発者にとって、ログ解析の手間を会話に置き換える実用的な一手になります。