.NET の「MCP Beyond the Chat Window: Build Diagnostics in CI」は、MCPをチャット画面だけで使うものではなく、CI上で.NET / MSBuildのビルド失敗を自動解析する実践例として重要な更新です。2026年6月30日の.NET公式ブログでは、Binlog MCP ServerをGitHub Actionsのワークフローに組み込み、失敗したPRビルドの原因をエージェントがbinlogから読み取り、PRコメントとして返す流れが紹介されました。(Microsoft for Developers)
結論から言うと、この更新は「.NETのビルド診断をAIに相談する」段階から、「CIで失敗した瞬間に、原因・該当ファイル・修正候補を自動で返す」段階へ進めるものです。ただし、公式情報では本番の必須ゲートを置き換えるものではなく、あくまで既存のビルド判定を補助する“助言型の自動化”として扱われています。(Microsoft for Developers)
.NET の「MCP Beyond the Chat Window: Build Diagnostics in CI」で何が変わったのか
今回のポイントは、Model Context Protocol、いわゆるMCPを、開発者がエディタやチャットで使うだけでなく、CI/CDパイプラインの中で自動実行する例が示されたことです。公式ブログでは、Microsoftの公開リポジトリである microsoft/testfx を例に、PRビルドが失敗したときだけエージェントが起動し、MSBuildのバイナリログをBinlog MCP Server経由で調査する流れが紹介されています。(Microsoft for Developers)
従来の.NETビルド障害対応では、開発者やビルド担当者がCIログを開き、必要に応じて .binlog をダウンロードし、Structured Log Viewerなどで失敗箇所を追う作業が必要でした。今回の構成では、CI内で生成されたbinlogをエージェントが読み取り、失敗したターゲット、タスク、エラーコード、ファイル、行番号などを構造化データとして取得し、PR上に原因を要約します。(Microsoft for Developers)
実務上の価値は、AIが単にログ全文を読むのではなく、MSBuildの診断に特化したMCPツールを使って、必要な情報を直接問い合わせられる点にあります。これは、長大な生ログをLLMに渡して推測させる方式よりも、原因特定の精度・再現性・コスト管理の面で扱いやすいアプローチです。(Microsoft for Developers)
影響範囲：対象になるチームとそうでないチーム
この更新の影響を受けやすいのは、GitHub Actionsで.NETプロジェクトをビルドしており、PR単位のビルド失敗調査に時間がかかっているチームです。特に、マルチプロジェクト構成、複数ターゲットフレームワーク、独自MSBuildターゲット、Roslynアナライザー、NuGet依存関係が絡むリポジトリでは効果が出やすくなります。公式ブログでも、ビルド失敗時に binlog_overview、binlog_errors、binlog_target_reasons、binlog_task_details などを組み合わせて原因を絞り込む例が示されています。(Microsoft for Developers)
一方で、単一プロジェクトでビルド時間が短く、失敗原因もコンパイルエラー中心という小規模なリポジトリでは、導入効果は限定的です。その場合は、まず dotnet build /bl でbinlogを取得し、手元のAIアシスタントやツールで調査するところから始めるほうが現実的です。公式ブログでも、dotnet build、dotnet test、dotnet pack に /bl を追加することでバイナリログを生成できると説明されています。(Microsoft for Developers)
| 対象 | 影響度 | 理由 |
|---|---|---|
| GitHub Actionsで.NETのPRビルドを運用しているチーム | 高 | 失敗時にbinlog解析とPRコメント化を自動化できる |
| MSBuildターゲットやprops/targetsを独自拡張しているチーム | 高 | ターゲット実行理由やタスク詳細を追いやすくなる |
| NuGet依存関係やアナライザーが多い大規模リポジトリ | 中〜高 | 復元、アナライザー、依存グラフ、競合の調査に使える |
| Azure DevOpsや他CIのみを使っているチーム | 中 | 考え方は応用できるが、公式例はGitHub Actions中心 |
| 小規模な単一プロジェクト | 低〜中 | 手動のbinlog解析で十分なケースも多い |
GitHub Actionsでの動き：失敗時だけAIエージェントがbinlogを読む
公式例では、microsoft/testfx の build-failure-analysis ワークフローがPRごとにビルドを実行し、ビルドが失敗した場合にだけ build-failure-analyst エージェントへ処理を委譲します。このエージェントは、コンテナ化された binlog-mcp MCPサーバー経由でbinlogを読み、根本原因を特定してPRコメントを投稿します。(Microsoft for Developers)
重要なのは、この仕組みがマージ可否を判定するゲートではない点です。公式ブログでは、通常の必須ビルドワークフローはそのままマージゲートとして残し、MCPを使ったワークフローは失敗分析とコメント投稿だけを担当すると説明されています。(Microsoft for Developers)
参考例では、binlogは /tmp/build.binlog からコンテナ内の /data/build.binlog に読み取り専用でマウントされます。MCPサーバーのコンテナには mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64 が使われ、ワークフロー側ではbinlogの検索、ステージング、アーティファクトアップロード、エージェント実行のための環境変数設定が行われています。(Microsoft for Developers)
mcp-servers:
binlog-mcp:
container: "mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64"
mounts:
- "/tmp/build.binlog:/data/build.binlog:ro"
allowed: ["*"]この構成をそのままコピーする前に、自社リポジトリでは「どのビルドコマンドでbinlogを出すか」「binlogをどこに保存するか」「PRコメントを投稿できる権限をどこまで与えるか」を整理する必要があります。AIエージェントがリポジトリを読み取り、PRにコメントする以上、最初はフォークPRや外部コントリビューターの権限境界を厳しめに設計するのが安全です。
追加されたBinlog MCPツール群の見どころ
公式ブログでは、以前の記事で紹介された15個のツールに加え、今回の投稿で触れられていなかった23個の binlog_ ツールが整理されています。記事公開時点でサーバーのソースツリーには合計38個の binlog_ ツールがあるとされていますが、正確なツールセットは変わる可能性があり、利用環境で実際に何が使えるかは binlog_capabilities で確認する必要があります。(Microsoft for Developers)
ターゲット・タスク調査
MSBuildでは「なぜこのターゲットが実行されたのか」「なぜスキップされたのか」が分からず、調査が長引くことがあります。今回紹介されたツールには、特定プロジェクトで実行されたターゲットを列挙する binlog_project_targets、ターゲット名を横断検索する binlog_search_targets、ターゲットの実行・スキップ理由を見る binlog_target_reasons、タスク詳細を見る binlog_task_details などがあります。(Microsoft for Developers)
実務では、インクリメンタルビルドが効かない、特定ターゲットが毎回走る、CIだけで異なるターゲットが動く、といった問題の切り分けに使えます。ログを上から読んでいくより、「このターゲットはなぜ動いたのか」という問いから入れるため、原因の探索範囲を小さくできます。
プロパティ・評価の確認
.NETのビルドでよくある「ローカルでは通るがCIでは落ちる」問題は、MSBuildプロパティやグローバルプロパティの差分が原因になることがあります。今回のツール群には、2つのbinlog間で単一プロパティを比較する binlog_compare_property、完全に展開されたプロジェクトを見る binlog_preprocess、評価ごとのプロパティやグローバルプロパティを確認する binlog_evaluation_properties、binlog_evaluation_global_properties などが含まれています。(Microsoft for Developers)
たとえば、CIだけ ContinuousIntegrationBuild=true になっている、特定の TargetFramework だけ失敗する、LangVersion や DefineConstants が想定と違う、といったケースでは、ログの文字検索よりもプロパティ比較のほうが早く原因へ到達できます。
パフォーマンス分析
ビルドが失敗していなくても、CIの待ち時間が長い場合はbinlogが役立ちます。公式ブログでは、遅いRoslynアナライザーやソースジェネレーターを確認する binlog_expensive_analyzers、アナライザー実行の概要を見る binlog_analyzer_summary、ターゲット単位の時間を見る binlog_project_target_times、スキップ・再実行の状況を見る binlog_incremental_analysis が紹介されています。(Microsoft for Developers)
特に大規模リポジトリでは、「ビルドが遅い」ではなく「どのプロジェクトのどのターゲット、どのアナライザーが時間を使っているか」まで分解できることが重要です。CI時間の短縮は開発者体験だけでなく、実行分数やクラウドコストにも直結します。
依存関係・グラフ・ツールチェーン
依存関係の調査では、プロジェクト依存グラフやクリティカルパスを見る binlog_build_graph、実行ターゲットのタイムラインを見る binlog_target_graph、NuGet復元情報を見る binlog_nuget、アセンブリ競合を調べる binlog_assembly_conflicts、コンパイラ呼び出しを確認する binlog_compiler、複数タスクによる同一ファイル書き込みを検出する binlog_double_writes などが紹介されています。(Microsoft for Developers)
この領域は、フレークテストや非決定的なビルド失敗の調査で特に有効です。たとえば、同じファイルを複数のターゲットが書き換える、依存関係の順序によって成果物が変わる、NuGet復元時間が急に伸びる、といった問題は、通常のコンソールログだけでは見落としやすくなります。
評価データから見る効果：速くなるが、過信は禁物
公式ブログでは、MSBuild診断シナリオに対する公開評価ハーネスの結果も紹介されています。記事執筆時点の102回の実行では、ツールなしの plain が平均スコア3.25、平均349.8秒、平均入力トークン1,268,501だったのに対し、binlog-mcp は平均スコア3.68、平均196.1秒、平均入力トークン1,141,426でした。skill-mcp は平均スコア3.60、平均166.7秒、平均入力トークン879,205とされています。(Microsoft for Developers)
| 構成 | 平均スコア | 平均時間 | 平均入力トークン | 読み取り方 |
|---|---|---|---|---|
plain | 3.25 | 349.8秒 | 1,268,501 | ツールなしの基準 |
binlog-mcp | 3.68 | 196.1秒 | 1,141,426 | 品質・時間ともに改善傾向 |
skill-mcp | 3.60 | 166.7秒 | 879,205 | 最速・低トークンだがスコアはbinlog-mcp単独より少し低い |
ただし、この数値は小規模かつ進化中の評価ハーネスによる方向性の確認であり、すべてのリポジトリで同じ効果が出ることを保証するものではありません。公式ブログも、結果はシナリオや実行ごとに変わるため、ライブダッシュボードで確認すべきと説明しています。(Microsoft for Developers)
導入判断では、平均スコアだけを見るのではなく、次のような現場指標で効果を測るのが現実的です。
| 確認する指標 | 導入前に測るもの | 導入後に見る変化 |
|---|---|---|
| PRビルド失敗から初回コメントまでの時間 | 人が調査を始めるまでの待ち時間 | AIコメントで初動が短縮されたか |
| ビルド担当者への問い合わせ数 | SlackやTeamsでの相談件数 | 定型的な失敗が自己解決されたか |
| CIの再実行回数 | 原因不明でrerunする回数 | 根本原因の把握で無駄なrerunが減ったか |
| 修正PRの往復回数 | レビュー中の修正回数 | 具体的な行番号・提案で修正が早くなったか |
| 誤ったAIコメントの件数 | なし | 誤診や不要な提案が許容範囲か |
設定変更で確認すべきポイント
導入時に必要になる主な変更は、ビルド時のbinlog出力、GitHub ActionsでのMCPサーバー設定、PRコメント投稿権限、エージェントのプロンプト・ツール許可範囲です。公式例では、./build.sh --binaryLog でビルドし、生成された .binlog を探して /tmp/build.binlog にコピーし、コンテナへ読み取り専用でマウントしています。(GitHub)
最初に確認すべきなのは、既存ビルドコマンドがbinlogを確実に生成できるかです。SDKスタイルプロジェクトなら dotnet build /bl のように指定できますが、独自スクリプトや複数ステップのビルドでは、どの工程のログを解析対象にするかを決める必要があります。公式ブログでは、dotnet build /bl のほか、dotnet test や dotnet pack にも /bl を追加できると説明されています。(Microsoft for Developers)
| 設定項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| binlog生成 | dotnet build /bl などで .binlog が出るか | 独自スクリプト内の実際の失敗箇所でbinlogが出ていない |
| 保存場所 | CI内でbinlogを特定できるか | 複数binlogのうち古いものを解析してしまう |
| コンテナマウント | 読み取り専用でMCPサーバーへ渡せるか | パスがホスト側とコンテナ側で混同される |
| 権限 | PRコメント、レビューコメントに必要な権限だけ付与する | 書き込み権限を広げすぎる |
| 実行条件 | ビルド失敗時だけ起動するか | 成功時にもAI処理が走りコストが増える |
| アーティファクト | binlogと補助ログの保持期間を決める | 機密情報を長期間保存してしまう |
管理者が確認すべきセキュリティと運用の論点
管理者が最初に見るべき論点は、AIエージェントに何を読ませ、何を実行させ、どこへ出力させるかです。公式例では、エージェントはbinlogをMCP経由で読み、PRにコメントやsuggestion blockを投稿します。また、build-failure-analyst の説明では、リポジトリに対して読み取り専用であり、結果は安全な出力ツール経由で返す設計になっています。(GitHub)
binlogには、ビルド設定、パス、プロパティ、パッケージ情報、場合によっては環境由来の値が含まれます。シークレットそのものをログに出さない運用は従来どおり必須ですが、AIエージェントが解析する前提では、ログに残してよい情報の基準をより明確にする必要があります。特にグローバル企業では、リポジトリの地域、データ分類、外部コントリビューターの有無、AI処理に関する社内ポリシーを確認してから展開するべきです。
権限面では、最初から全リポジトリへ横展開するのではなく、内部リポジトリまたは限定チームでパイロット運用するのが安全です。PRコメントの投稿は便利ですが、誤ったsuggestionが開発者に採用される可能性もあります。マージ判定は既存CIに残し、AIコメントは「参考情報」と明示する設計が現実的です。公式例でも、MCPによる分析ワークフローは助言型であり、PRの合否を決めるものではありません。(Microsoft for Developers)
移行期限はあるのか
今回の公式情報では、.NET SDKやMSBuildの既存機能に対する移行期限、廃止期限、強制的な設定変更は示されていません。したがって、すぐに既存のCIを変更しなければならない種類の更新ではありません。(Microsoft for Developers)
ただし、GitHub Agentic Workflowsについては、公式ブログ内で「進化中」であり、すべてのリポジトリでそのまま使える完成済み機能としてではなく、参照実装として扱うべきと説明されています。導入する場合は、ワークフローやCLI、MCPサーバーの仕様が変わる可能性を前提に、検証用ブランチや限定リポジトリから始めるのが妥当です。(Microsoft for Developers)
導入するならどの順番で進めるべきか
いきなりCIにAIエージェントを入れるより、まずはbinlogを安定して取得し、次にローカルまたは手動でMCP診断を試し、最後にPRコメント自動化へ進むのがおすすめです。公式ブログでも、dotnet-msbuild プラグインの導入、/bl によるbinlog取得、GitHub Agentic Workflowへの展開という順序が示されています。(Microsoft for Developers)
最小構成で試す手順
まず、失敗しやすい.NETリポジトリを1つ選びます。最初から全社共通テンプレートに入れるのではなく、過去にビルド障害が多かったが、機密性が高すぎないリポジトリが向いています。
次に、CIまたはローカルでbinlogを出力します。
dotnet build /blテストやパッケージングが失敗しやすい場合は、以下のように対象コマンドを変えます。
dotnet test /bl
dotnet pack /blその後、AIアシスタントや対応するプラグイン環境で、binlogの概要、エラー一覧、ターゲット実行理由を確認します。公式情報では、dotnet-msbuild プラグインがVisual Studio、VS Code、Copilot CLIで利用できる土台として紹介されています。(Microsoft for Developers)
CIへ組み込む段階では、GitHub Actions上で「ビルド失敗時だけAI分析を動かす」「binlogは読み取り専用でMCPサーバーに渡す」「AIコメントはマージゲートにしない」という3点を守ると、既存運用への影響を抑えられます。(Microsoft for Developers)
活用シーン別の使い分け
MCPによる.NETビルド診断は、すべての障害を自動修正するための仕組みではありません。効果が出やすい場面と、人間が判断すべき場面を分けて考える必要があります。
| シーン | 向いている使い方 | 人間が見るべき点 |
|---|---|---|
| コンパイルエラー | エラーコード、ファイル、行番号の要約 | 修正方針が設計意図に合うか |
| MSBuildターゲット失敗 | 実行理由、失敗タスク、依存関係の確認 | 独自ターゲットの仕様変更が必要か |
| NuGet復元エラー | 依存関係、ソース、バージョン競合の整理 | パッケージ更新方針や脆弱性対応 |
| アナライザー違反 | WarnAsErrorやルール違反の特定 | ルールを直すか抑制するか |
| ビルド遅延 | 遅いターゲットやアナライザーのランキング | CI設計やキャッシュ戦略の見直し |
| フレークなビルド | 二重書き込みや非決定的な依存関係の発見 | 再現条件と恒久対策の設計 |
特に有効なのは、若手開発者が「なぜCIだけ落ちたのか」を自力で把握しやすくなる点です。PRに原因候補と修正例が出るだけで、ビルド担当者への問い合わせ前に自分で確認できる範囲が広がります。
導入時に避けたい失敗
よくある失敗は、AIコメントをいきなり信頼しすぎることです。Binlog MCP Serverは構造化されたビルド情報を取得できますが、最終的な判断にはリポジトリ固有の設計意図や運用ルールが関わります。たとえば、Public API変更、Analyzer抑制、NuGetバージョン更新、ターゲット順序の変更は、単にビルドを通せばよいわけではありません。
次に、権限を広げすぎる失敗があります。PRコメントを投稿するための権限は必要ですが、コードの直接変更、任意コマンドの広範な実行、外部送信の許可は慎重に制限するべきです。公式例でも、エージェントは読み取り専用で分析し、安全な出力ツールを通じて結果を返す設計が示されています。(GitHub)
また、binlogが生成されないケースへの備えも必要です。公式例のエージェント手順では、binlogがない場合は「ビルドは失敗したがバイナリログが生成されなかった」とコメントし、rawログへの参照にフォールバックする流れが用意されています。(GitHub)
管理者向けチェックリスト
本格導入前に、管理者は次の項目を確認しておくと安全です。
| 確認項目 | 判断基準 |
|---|---|
| 対象リポジトリ | まずは内部向け、機密度が比較的低い.NETリポジトリから始める |
| binlog出力 | 失敗時に必ず .binlog が残るようにする |
| データ分類 | binlogにシークレットや不要な環境情報が出ていないか確認する |
| 権限 | PRコメントに必要な最小権限だけを付与する |
| 外部PR | フォークPRでは実行条件や権限を制限する |
| コスト | 成功時にはAI分析を走らせず、失敗時だけ実行する |
| 品質評価 | 誤診、不要コメント、修正提案の採用率を定期的に確認する |
| 運用ルール | AIコメントは参考情報であり、既存CIゲートを置き換えないと明記する |
| 更新追跡 | binlog_capabilities で実際のツールセットを確認する |
まず何をすべきか
.NET の「MCP Beyond the Chat Window: Build Diagnostics in CI」は、今すぐ全CIを置き換えるための発表ではなく、.NETビルド診断をCIの中で自動化するための実用的な参照例です。移行期限や強制対応は示されていないため、既存環境に急いで手を入れる必要はありません。(Microsoft for Developers)
次に取るべき行動は、まず対象リポジトリを1つ選び、dotnet build /bl でbinlogを取得できる状態にすることです。そのうえで、手動診断で binlog_overview や binlog_errors 相当の出力が役立つかを確認し、効果が見えたらGitHub Actions上で失敗時だけ自動分析する構成を検証します。(Microsoft for Developers)
CIの赤いビルドを「誰かがログを読むまで待つ状態」から、「失敗直後に原因候補がPRへ返る状態」に変えられるかどうかが、この更新の本質です。大規模な.NET開発チームほど、ビルド担当者の属人化を減らし、PRレビューの滞留を短くする効果が期待できます。
コメント