Azure SDKの「Migrate NoWarn to inline suppressions for 10 projects」は、SDK利用者向けのAPI変更ではなく、Azure SDK for .NETリポジトリ内で警告抑制の方法を整理するメンテナンス変更です。結論から言うと、NuGetでAzure SDKを利用しているだけの開発者は、基本的に直接対応する必要はありません。一方で、Azure SDKへコントリビュートしている人、forkを保守している人、自社の.NETライブラリで<NoWarn>を多用している人は、今回の変更方針を確認しておく価値があります。
今回のポイントは、プロジェクトファイルの<NoWarn>で警告をまとめて隠すのではなく、実際に必要な場所だけに#pragma warning disableや[SuppressMessage]を置くことです。対象PRは当初「10 projects」として始まりましたが、その後「first batch」として整理され、37プロジェクト・7つのサービスディレクトリにまたがる変更として説明されています。PRタイトルも2026年5月5日に「Migrate NoWarn to inline suppressions first batch」へ変更されています。(GitHub)
Azure SDKのNoWarn移行で何が変わったのか
今回のAzure SDK for .NETの変更は、各.csprojに書かれていた<NoWarn>を削除し、警告が本当に発生している箇所だけを狭い範囲で抑制するものです。PRの説明では、34個のcsprojファイルから<NoWarn>が削除され、3つの手書きコードにはインラインの#pragma warning disableが追加され、9つのGlobalSuppressions.csには生成コード向けの[SuppressMessage]が追加または更新されたとされています。(GitHub)
| 変更前 | 変更後 | 目的 |
|---|---|---|
.csprojの<NoWarn>で警告をプロジェクト単位で抑制 | 不要な<NoWarn>は削除 | 古い抑制設定を残さない |
| 手書きコードの警告もプロジェクト全体で抑制 | 対象クラスやメンバー付近で#pragma warning disableを使用 | 抑制範囲を最小化する |
生成コードの警告も<NoWarn>で抑制 | GlobalSuppressions.csに[SuppressMessage]を追加 | Generated/配下を直接編集せずに抑制する |
| 過去に必要だった警告抑制を残したままにする | ビルドで実際に発生する警告だけを残す | CIやレビューで不要な例外設定を減らす |
MicrosoftのC#コンパイラオプションでは、NoWarnは1つ以上の警告を表示しないようにする設定です。つまり、便利ではあるものの、設定した警告がプロジェクト全体で見えなくなります。警告を特定箇所だけで抑制したい場合は、コード内で#pragma warningを使う方法が案内されています。(Microsoft Learn)
「10プロジェクト」から「Batch 1」へ広がった対象範囲
この変更は、最初のコミットでは「Migrate NoWarn to inline suppressions for 10 projects」として、Key Vault、Communication、Maps、DevCenter、Health Insights、Anomaly Detector、Confidential Ledger関連のプロジェクトが挙げられていました。その後、同じサービスディレクトリ内の残りの<NoWarn>も対象に加えられ、Batch 1として37プロジェクトに拡大されています。(GitHub)
PR本文で示されているサービスディレクトリごとの影響範囲は、次の通りです。
| サービスディレクトリ | 対象プロジェクトの概要 | 主な状況 |
|---|---|---|
| keyvault | 5 src + 1 provisioning | すべてstale、実際の警告なし |
| communication | 6 src + 1 test + 1 provisioning | AZC0034、AZC0035が一部でlive |
| maps | 3 src + 6 tests | AZC0035、AZC0012が一部でlive |
| devcenter | 1 src + 2 tests | AZC0034がlive |
| healthinsights | 3 tests | すべてstale |
| confidentialledger | 1 src + 1 test | AZC0034、AZC0035が一部でlive |
| anomalydetector | 1 src | AZC0012がlive |
ここでいうstaleは、過去には必要だった可能性があるものの、現在は削除しても警告が発生しない抑制設定を指します。関連Issueでは、Batch 1で約70%のNoWarnエントリがstaleだったこと、残り約200プロジェクトが今後の対象として残っていることも示されています。(GitHub)
誰が対応すべきか
この変更はAzure SDKの内部品質管理に近い内容です。すべてのAzure SDK利用者が作業する必要はありませんが、関わり方によって確認すべきポイントが変わります。
| 立場 | 対応の必要性 | 確認すべきこと |
|---|---|---|
| Azure SDKをアプリから利用している開発者 | 低い | 通常はNuGetパッケージの利用方法に影響しない |
| Azure SDK for .NETへPRを出す開発者 | 高い | 新規<NoWarn>追加ではなく、最小範囲の抑制を使う |
| Azure SDKのforkを保守しているチーム | 中〜高 | upstream取り込み時にGlobalSuppressions.csや#pragmaの差分を確認する |
| 自社.NET SDKやライブラリの保守担当 | 中 | 自社リポジトリでもstaleな<NoWarn>が残っていないか確認する |
| CI/CDや品質ゲートの担当者 | 中 | TreatWarningsAsErrors環境で警告抑制削除がビルド失敗につながらないか確認する |
特に注意したいのは、Azure SDKリポジトリでは警告がエラーとして扱われる前提がある点です。関連Issueでは、TreatWarningsAsErrors=trueにより、NoWarnを削除すると実際に残っている警告がビルドエラーとして表面化すると説明されています。(GitHub)
NoWarnを減らすべき理由
<NoWarn>は、短期的にはビルドを通すために便利です。しかし、長期運用では次のような問題が起きやすくなります。
| 問題 | 実務で起きること | 結果 |
|---|---|---|
| 抑制範囲が広すぎる | 1つの警告を避けるために、同じ警告コード全体が見えなくなる | 新しい問題を検知しにくくなる |
| staleな設定が残る | 既に修正済みの警告コードがcsprojに残り続ける | レビュー時に本当に必要な抑制か判断しづらい |
| 抑制理由がコードから離れる | .csprojだけを見ても、どの型・メンバーのための抑制か分からない | 保守担当者が削除可否を判断できない |
| CIとローカルで見え方が変わる | ターゲットフレームワークやAnalyzerの差で警告が出たり出なかったりする | リリース直前にビルド失敗が起きる |
Microsoftのドキュメントでも、SuppressMessageAttributeはソースファイルやGlobalSuppressions.csで、プロジェクトやファイルの特定部分に対して警告を抑制する方法として説明されています。プロジェクト全体で黙らせるより、抑制対象をコードに近づけるほうが、後から理由を追いやすくなります。(Microsoft Learn)
移行時の判断基準
Azure SDKの関連Issueでは、抑制の優先順位として「可能なら根本原因を修正する」「手書きコードでは#pragma warning disableを使う」「生成コードではGlobalSuppressions.csを使う」という方針が示されています。(GitHub)
実務では、次の順番で判断すると迷いにくくなります。
| 状況 | 推奨対応 | 理由 |
|---|---|---|
| ドキュメント不足、ヘッダー不足など簡単に直せる警告 | コードやコメントを修正する | 抑制より修正のほうが安全 |
| 既に警告が出ていない | <NoWarn>を削除する | staleな設定を減らせる |
| 手書きコードの特定クラスだけで警告が出る | クラスやメンバー付近に#pragma warning disableを置く | 影響範囲を最小化できる |
| 生成コードで警告が出る | GlobalSuppressions.csに[SuppressMessage]を追加する | 生成ファイルを直接編集せずに済む |
| 型名変更などが破壊的変更になり得る | 根本修正ではなく、理由付きで抑制する | SDKの互換性を守る必要がある |
| 共有propsで広く抑制している | 本当に全体抑制が必要か見直す | 将来の警告を隠すリスクがある |
ポイントは、警告を消すことではなく、警告を見える状態に戻したうえで、例外だけを説明可能にすることです。
自社リポジトリで確認する手順
Azure SDKの変更をそのまま自社プロジェクトに適用する場合は、いきなり全削除するのではなく、サービス単位やプロジェクト単位で進めるのが安全です。
| 手順 | 作業内容 | 確認ポイント |
| -: | ———————— | —————————————————————- |
| 1 | <NoWarn>の使用箇所を洗い出す | .csproj、Directory.Build.props、Directory.Build.targetsを確認する |
| 2 | 対象コードごとに削除候補を決める | まずは影響範囲の小さいプロジェクトから始める |
| 3 | <NoWarn>を一時的に削除してビルドする | 警告が出なければstaleとして削除できる |
| 4 | liveな警告を分類する | 手書きコードか、生成コードか、修正可能かを見る |
| 5 | 必要最小限の抑制を追加する | #pragmaまたはGlobalSuppressions.csを使い分ける |
| 6 | 抑制理由を残す | 将来のレビューで削除可否を判断できるようにする |
| 7 | CIで再ビルドする | ローカルだけでなく、複数ターゲットやAnalyzer差分も確認する |
検索には、例えば次のようなコマンドが使えます。
git grep -n "<NoWarn>" -- "*.csproj" "*Directory.Build*.props" "*Directory.Build*.targets"<NoWarn>を削除した後にビルドが通るなら、その抑制は現在不要になっている可能性があります。逆にビルドが失敗する場合は、警告がまだ生きているため、修正するか、より狭い範囲で抑制します。
Before/Afterで見る移行イメージ
変更前は、プロジェクトファイルに警告コードをまとめて書く形です。
<PropertyGroup>
<NoWarn>$(NoWarn);AZC0035</NoWarn>
</PropertyGroup>この書き方では、AZC0035がどの型のために必要なのか、プロジェクトファイルだけでは分かりません。将来、別の型で同じ警告が出ても見逃す可能性があります。
手書きコードで特定の型だけを抑制する場合は、次のように対象付近へ寄せます。
#pragma warning disable AZC0035 // 既存API互換性を維持するため、この型ではモデルファクトリ警告を抑制する
public partial class ExampleResult
{
// 既存実装
}
#pragma warning restore AZC0035生成コードで警告が出る場合は、生成ファイルを直接編集せず、GlobalSuppressions.csで管理します。
using System.Diagnostics.CodeAnalysis;
[assembly: SuppressMessage(
"Usage",
"AZC0035: Missing model factory method",
Justification = "Generated code. The Generated directory is not edited directly.",
Scope = "type",
Target = "~T:Azure.Example.GeneratedExampleResult")]実際のCategory、CheckId、Scope、Targetは、Analyzerの出力や既存の抑制形式に合わせて設定します。SuppressMessageAttributeにはカテゴリやルールID、正当化理由、対象範囲などのプロパティがあり、どこに対する抑制なのかを明示できます。(Microsoft Learn)
失敗しやすいポイント
<NoWarn>を消すだけで終わらせる
staleな警告なら削除だけで問題ありません。しかし、liveな警告まで削除すると、TreatWarningsAsErrors環境ではビルドエラーになります。削除後に必ずビルドし、残った警告を分類する必要があります。
生成コードに直接#pragmaを入れる
生成コードは再生成で上書きされる可能性があります。Azure SDKのPRでも、生成コードの警告にはGlobalSuppressions.csを使い、手書きコードには#pragma warning disableを使う方針が示されています。(GitHub)
#pragma warning restoreを忘れる
#pragma warning disableだけを書いてrestoreを忘れると、意図した範囲を超えて警告が抑制されることがあります。クラス単位やメンバー単位で使う場合でも、抑制の終わりを明確にしておくとレビューしやすくなります。
削除した<NoWarn>のコメントだけが残る
今回のPRでは、削除されたNoWarnに紐づく孤立コメントや末尾改行の整備も行われています。機能変更ではない小さな差分に見えますが、保守性を上げるうえでは重要です。(GitHub)
抑制理由を書かない
[SuppressMessage]や#pragmaは、理由がないと将来の担当者が削除してよいか判断できません。特に「互換性維持のため」「生成コードのため」「Analyzerの既知の誤検知のため」のように、なぜ修正ではなく抑制を選んだのかを短く残すことが大切です。
Azure SDK関連PRとして確認すべき点
このPRは、記事執筆時点でDraftとして表示されています。つまり、Azure SDKの利用者向けにリリースされた仕様変更というより、リポジトリ内の開発品質を整える作業として見るべきです。PRはIssue #58243「Move all existing NoWarn to inline suppressions」の一部であり、Batch 1の後にも残りのプロジェクトが続く可能性があります。(GitHub)
Azure SDK for .NETの変更を追う場合は、次の順に確認すると誤解を避けられます。
| 確認項目 | 見るべきポイント |
|---|---|
| PRの状態 | Draftか、Ready for reviewか、merge済みか |
| Files changed | 自分が関わるサービスディレクトリが含まれているか |
| 関連Issue | Batch全体の方針や残作業が説明されているか |
| 変更内容 | API変更なのか、ビルド・Analyzer・品質管理の変更なのか |
| CI結果 | NoWarn削除後に警告がエラー化していないか |
特に、PR名だけを見ると「10プロジェクトの移行」に見えますが、現在の説明ではBatch 1として37プロジェクトに広がっています。古いコミット名やタイトルだけで判断せず、PR本文と関連Issueを合わせて確認することが重要です。
まとめ：Azure SDKのNoWarn移行は「警告を隠す」から「理由付きで管理する」への変更
Azure SDKの「Migrate NoWarn to inline suppressions」は、エンドユーザー向けの機能追加ではなく、Azure SDK for .NETの警告抑制を整理するための変更です。NuGetでAzure SDKを使っているだけなら、通常は対応不要です。
一方で、Azure SDKへコントリビュートする開発者や、自社.NETライブラリで<NoWarn>を多用しているチームにとっては、実務上かなり参考になる変更です。まずは自分のリポジトリで<NoWarn>を検索し、削除しても警告が出ないstaleな設定を減らしましょう。警告が残る場合は、根本修正を優先し、それが難しいときだけ#pragma warning disableやGlobalSuppressions.csで最小範囲に抑制します。
次に取るべき行動はシンプルです。<NoWarn>の棚卸しを行い、「本当に必要な抑制か」「どのコードのための抑制か」「理由がレビューできる形で残っているか」を確認してください。それだけで、CIの信頼性とコードレビューの見通しは大きく改善します。
コメント