.NET Code Analysis (CA)
.NETのコード分析（Code Analysis）は、コードの品質、スタイル、パフォーマンス、セキュリティの問題を検出し、開発の初期段階で修正するための静的解析機能です。現代の.NET開発では、Roslynコンパイラプラットフォームに基づいた「Roslyn Analyzers」が標準的に使用されています。
Code Analysis (CA) とは
Code Analysisは、コンパイル時にソースコードを検査し、潜在的なバグやコーディング規約違反を報告する仕組みです。
主な特徴
- リアルタイムフィードバック: Visual StudioやVS CodeなどのIDEで、コードを書いている最中に警告やエラーが表示されます。
- ビルド時の検証: CI/CDパイプライン上でコードの品質を強制することができます。
- カスタマイズ可能: ルールの有効/無効や重大度（Severity）を細かく設定できます。
従来のFxCopとの違い
かつては「FxCop」と呼ばれる静的解析ツールが使われていましたが、現在はRoslyn Analyzers（.NET Analyzer）に統合されています。FxCopはコンパイル後のアセンブリを解析していましたが、Roslyn Analyzersはソースコードを解析するため、よりリッチで高速なフィードバックが可能です。
ルールの種類
.NET SDKには数多くの分析ルールが含まれています。これらは主に以下のカテゴリに分類されます。
1. コード品質ルール (CAxxxx)
API設計、セキュリティ、パフォーマンス、信頼性などの問題を検出します。
- Design: ライブラリ設計のガイドラインに従っているか（例: インターフェイスの実装方法）。
- Performance: パフォーマンスに悪影響を与えるコードを検出（例: 不必要な文字列連結）。
- Security: セキュリティホールになり得る脆弱なコードを検出。
- Reliability: アプリケーションの動作を不安定にする可能性のある記述を検出。
- Usage: Frameworkの正しい使用方法に関わるルール。
2. コードスタイルルール (IDExxxx)
コードの可読性やフォーマットの一貫性に関わるルールです。
varの使用方針- 中括弧
{}の省略可否 - 名前空間の宣言スタイル（File-scoped namespaceなど）
3. サードパーティ製アナライザー
NuGetパッケージとして導入できる追加のアナライザーもあります。
- StyleCop.Analyzers: 厳しいスタイルガイドラインを適用したい場合。
- SonarAnalyzer.CSharp: SonarQube準拠の詳細な解析。
- xUnit.Analyzers: テストコード専用のベストプラクティスチェック。
設定と構成
.NETのコード分析の動作は、主にプロジェクトファイル（.csproj）と.editorconfigファイルで制御します。
プロジェクトファイルでの設定
プロジェクト全体に対する分析レベルを設定します。
<PropertyGroup>
<!-- すべての警告をエラーとして扱う（推奨） -->
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<!-- .NETのコード分析機能を有効化（.NET 5以降はデフォルトでtrue） -->
<EnableNETAnalyzers>true</EnableNETAnalyzers>
<!-- 分析レベルの指定（latestは最新のSDK推奨設定を使用） -->
<AnalysisLevel>latest</AnalysisLevel>
<!-- 推奨設定をすべて有効にするかどうか -->
<AnalysisMode>All</AnalysisMode>
</PropertyGroup>
.editorconfig による詳細設定
.editorconfig を使用すると、個別のルールごとに重大度（Severity）を設定できます。リポジトリのルートに配置することで、すべてのプロジェクトに適用されます。
重大度 (Severity) のレベル
- error: ビルドを失敗させる。直ちに修正が必要。
- warning: ビルドは成功するが警告を表示する（
TreatWarningsAsErrorsが有効ならビルド失敗）。 - suggestion: IDE上で「・・・」のようなヒントを表示する。ビルドログには残らない。
- silent: エディタ上での強調表示はしないが、修正案（電球アイコン）としては利用可能。
- none: ルールを無効にする。
設定例
# .editorconfig
# ファイルごとの設定
[*.cs]
#### コア分析ルール ####
# CA1062: パブリックメソッドの引数のnullチェックを検証
dotnet_diagnostic.CA1062.severity = error
# CA1822: 静的メンバーとしてマークできるメンバーを指摘
dotnet_diagnostic.CA1822.severity = warning
# CA2007: ConfigureAwait を使用するかどうかのチェック（ASP.NET Coreでは不要なので無効化）
dotnet_diagnostic.CA2007.severity = none
#### スタイルルール ####
# var の使用を強制 (csharp_style_var_for_built_in_types)
csharp_style_var_for_built_in_types = true:suggestion
# File-scoped namespaceの使用を推奨
csharp_style_namespace_declarations = file_scoped:warning
ベストプラクティス
1. 警告ゼロを目指す (TreatWarningsAsErrors)
本番品質のコードでは、<TreatWarningsAsErrors>true</TreatWarningsAsErrors> を設定し、警告をエラーとして扱うことを推奨します。警告を放置すると、重要な問題が見逃される「割れ窓理論」のような状態になります。
2. .editorconfig を階層的に管理する
- ルートディレクトリ: 全体共通の厳格なルール。
- テストプロジェクト: 一部のルール（命名規則やドキュメント要否など）を緩和する設定で上書きする。
3. AnalysisLevel の定期更新
.NET SDK のアップデートに伴い、新しいルールが追加されます。<AnalysisLevel>latest</AnalysisLevel> にしておくと自動的に新しいルールが適用されますが、SDK更新時にビルドが壊れるリスクがあります。安定性を重視する場合は <AnalysisLevel>8.0</AnalysisLevel> のようにバージョンを固定し、計画的にバージョンを上げましょう。
4. チームでの合意形成
すべてのルールを有効にすると開発速度が落ちる可能性があります。チームにとって「ノイズ」となるルールは躊躇なく none に設定し、本当に守るべきルールだけを error や warning に設定しましょう。
まとめ
適切なコード分析の導入は、コードレビューの負担を減らし、品質を自動的に担保するための強力な手段です。.NET標準の機能と .editorconfig を活用して、チームに合った解析環境を構築しましょう。