C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断

結合は単に減らせば良いのではなく、強さ・距離・変動性のバランスが重要です。
本セッションではRustのcargo-couplingから着想を得たdotnet-couplingを題材に、namespaceやproject境界、interfaceやなどC#のプロジェクト構造をどのように数値化し、設計改善の判断材料にするかを具体例をお話しします。
https://github.com/dora56/dotnet-coupling

Transcript

1. C# KAIGI 2026 2026/09/19 C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断 花岡 龍 / dora56
2. 自己紹介 ◼ 花岡 龍 ◼ 株式会社 オルターブース ◼ Azure, GitHub 導入支援 @karyu721 @dora56 /r-hanaoka
3. INTRODUCTION はじめに AI時代のリファクタリングを、どう検証するか 03
4. INTRODUCTION AI時代のリファクタリング 01 02 03 生成・変更できるコード量 が増えた レビューで方向性を確かめ る負荷も増えた AIに広いコードを読ませる ほどトークンを消費する 04
5. INTRODUCTION ツールで絞り込みたいもの 01 02 03 変更が波及しそうな依存 境界を越えて共有している 知識 AIと人が先に読むべきソー ス位置 05
6. TOOL dotnet-coupling C#の結合を、根拠までたどれる形で可視化するCLI SCAN PRIORITIZE 強度・距離・変動性 RoslynとGit履歴から依存を観測 issue / hotspots リファクタリング候補を絞り込む INVESTIGATE SHARE & GATE impact / trace 変更の波及と呼び出し元をたどる JSON・SARIF・AI・CI レビューと品質ゲートへ接続する SOURCE / DOCS github.com/dora56/ dotnet-coupling dotnet tool install --global dotnet-coupling 06
7. COUPLING BALANCE 結合を読む3つの観点 この本から借りた判断軸 統合強度 相手の何を知っているか 距離 共同変更の調整に何が必要か 変動性 上流がどれくらい変わるか 07
8. COUPLING BALANCE 強度と距離の4つの組み合わせ 強度 ＼ 距離 近い 遠い 低い 局所的複雑性 疎結合 高い 高凝集 大域的複雑性 近くに置くなら強い関係 遠くに置くなら弱い関係 弱い関係を近くに集めると、局所的複雑性が増える 出典：Vlad Khononov『ソフトウェア設計の結合バランス』p.181 表10.3をもとに作成 08
9. COUPLING BALANCE 統合強度は構文だけでは決まらない Contract Model 統合用の知識だけを共有 内部の業務モデルを共有 Functional Intrusive 業務ルール・機能を共有 意図しない内部実装に依存 interfaceやメソッド呼び出しは、統合強度を読むための手がかり 09
10. COUPLING BALANCE 距離が変える2つのコスト ↑ コスト CHANGE COST 変更のコスト 遠くなるほど変更の調整コスト は増える。 近いほどビルド・テスト・デプ ロイを共有する。 DISTANCE 組織、所有者、実行時の依存も距 離に影響する。 ライフサイクル結合 距離 → 文脈 メンバー プロジェク ト パッケージ 名前空間 ／ライブラ リ サービス システム 出典：Vlad Khononov『ソフトウェア設計の結合バランス』p.152 図8.4をもとに作図 10
11. COUPLING BALANCE 変動性はGit履歴から近似する LOW MEDIUM 0–2回 3–10回 HIGH 11回以上 OBSERVATION 変更回数は、変更理由や 将来の変化そのものではな い 既定の観測期間：6か月 11
12. COUPLING BALANCE 書籍の均衡度とツールのscore 01 02 03 書籍 強度と距離の差を、 低い変動性が補う ツール 構文から得た 段階値を独自式で計算 同じ言葉を使っても、 数値モデルは別 12
13. ROSLYN ANALYSIS 内部結合のBalance Score STRENGTH DISTANCE VOLATILITY Contract 0.25 Model 0.50 Functional 0.75 Intrusive 1.00 Same namespace 0.25 Different namespace 0.50 Project 0.75 External 1.00 Low 0.00 Medium 0.50 High 1.00 alignment × volatilityImpact → Balance Score（0.00〜1.00） 13
14. ROSLYN ANALYSIS Balance Scoreの読み方 BALANCED NEEDS REFACTORING Contract 0.25 × Different project 0.75 Low volatility 0.00 Functional 0.75 × Different project 0.75 × High volatility 1.00 alignment = 1 - |0.25 - (1 - 0.75)| = 1.00 volatilityImpact = 1 - (0.00 × 0.25) = 1.00 score = 1.00 × 1.00 = 1.00 alignment = 1 - |0.75 - (1 - 0.75)| = 0.50 volatilityImpact = 1 - (1.00 × 0.75) = 0.25 score = 0.50 × 0.25 = 0.125 → 0.13 Score 1.00 Score 0.13 強い依存は近くに、遠い依存は契約越しに Scoreは結合単位の参考値。Gradeはissue densityで別に判定する 14
15. ROSLYN ANALYSIS Roslyn解析の流れ 01 02 03 04 COLLECT RESOLVE ENRICH REPORT 構文木から 型と利用箇所 → 参照先と 依存を分類 → Git履歴と ドメイン設定 → score・issue・ ソース位置 観測 → 解釈 → 判断材料 13
16. ROSLYN ANALYSIS syntaxとsemantic-preview syntax（既定） semantic-preview（明示して有効化） ディレクトリから短時間で候補を拾う 型・呼び出し先を解決する project / solutionとworkspace環境が必 要 14
17. ROSLYN ANALYSIS semantic mode：workspaceからsymbolへ 01 02 03 04 05 INPUT REGISTER LOAD RESOLVE OBSERVE .csproj .sln / .slnx → MSBuild Locator → MSBuild Workspace → Project / Document SemanticModel → symbol identity 依存として記録 GetSymbolInfo / GetTypeInfo / GetOperation 15
18. ROSLYN ANALYSIS semantic mode：増える観測と残る境界 RESOLVED CONSERVATIVE BOUNDARY IDENTITY alias / global using / partial / generic CALLS extension・連鎖・条件付き呼び出し field / property / inferred local source typeが不明な dynamic parameter BOUNDARIES project / assembly / NuGet package workspaceを 読み込めない環境 INDIRECT typeof / nameof / Activator / service locator 具体型を追えるdynamic 具体型を示さない Type変数 依存を捏造しない preview / opt-in dotnet-coupling --mode semantic ./MyApp.sln 16
19. ROSLYN ANALYSIS 別namespaceの具象型を生成する namespace Fixture.Global.Api; public sealed class Handler { public void Handle() { _ = new Repository(); } } 17
20. ROSLYN ANALYSIS レポートを根拠まで読む Grade C Avg Score 0.75 DETECTED INTERPRET 別namespaceの具象型を 直接生成している Gradeと平均scoreは 別の計算 分類：GlobalComplexity issue種別とソース位置へ戻る 内部結合 1本 Medium 1件 数値だけで結論を出さず、検出根拠を読む 18
21. DESIGN DECISION ドメインコンテキストによる補正 OBSERVED CONTEXT CALIBRATE Git履歴 observedChurn 変更回数の事実 subdomain expectedVolatility technicalRole effective coupling score・severity・Grade へ反映 → → 実際に見つけた依存グラフは保持し、解釈だけを補正する 19
22. DESIGN DECISION ドメインコンテキストによる補正(tomlによる設定) [[domain.subdomains]] name = "CoreRules" category = "core" paths = ["src/DotnetCoupling.Core/Domain/**"] expected_volatility = "high" [[domain.subdomains]] name = "CoreContracts" category = "supporting" paths = ["src/DotnetCoupling.Core/Contracts/**"] expected_volatility = "medium"
23. OSS EVALUATION OSS例：CommandLine Parserを読む 対象：commandlineparser / commandline Phase 3 OSS syntax / semantic compare SYNTAX SEMANTIC PREVIEW Grade C 502 internal couplings High 1 / Medium 30 Grade C 2,005 internal couplings High 1 / Medium 30 診断 6件 観測する結合は増えたが、Gradeとissue件数は変わらなかった 20
24. OSS EVALUATION OSS例：レポートから分かること 観測範囲 結果の安定性 環境の診断 semanticはsymbol解決で 結合候補を増やす Gradeとissue件数は このOSS例では不変 対象の.NET Framework 開発パック不足を6件報告 モードを比較するときは、結合数の増加とworkspace診断を一緒に読む 21
25. DESIGN DECISION interfaceは契約の候補 // 利用側が必要な知識だけを受け取る public sealed class Handler(IRepository repository) { public void Handle() => repository.Save(); } // 具体型の生成はcomposition rootへ 22
26. DESIGN DECISION 境界の選択 同じ理由で変わる強い関係 別々の理由で変わる遠い関係 近くに置いて共同変更しやすくする 統合用の契約で共有知識を絞る 23
27. DESIGN DECISION AIに渡すレビューの根拠 01 02 03 検出した依存とソース位置 境界を保つ理由と 変えてよい範囲 変更後のテストと同条件で の再解析 24
28. DESIGN DECISION 解析が届かない依存 実行時DI・reflection・dynamicの一部 02 共有DBや通信先などコード外の契約 業務上の変更理由 検出0件はリスク0件を意味しない 25
29. DESIGN DECISION 自分のコードで調べる dotnet-coupling --summary ./src dotnet-coupling --hotspots 5 ./src dotnet-coupling --ai ./src 26
30. DESIGN DECISION 自分のコードで調べる 26
31. CLOSING おわりに 観測から始めて、境界の判断へ戻る 27
32. CLOSING リファクタリングの方向性を検証する 1 絞る 2 依存の候補と ソース位置 → 確かめる 共有知識と 変更理由 3 → 比べる テストと 同条件の再解析 数値は結論ではなく、レビューを始める場所 28
33. Q&A Q&A 設計判断・Roslyn解析・OSS評価 5 min github.com/dora56/ dotnet-coupling 29
34. BACKUP 補足：書籍の式とツールの式 書籍：B = max(|S - D|, 10 - V) + 1 ツール：alignment = 1 - |s - (1 - d)| score = alignment × (1 - v × s) 両者は別の数値モデル 30
35. BACKUP 補足：ツールの距離推定 1 既知のprojectが異なる：0.75 02 2 同じnamespace：0.25 3 namespace共通先頭が2区切り以上 ：0.50 4 それ以外：0.75 業務上の距離との一致は人が確かめる 31
36. BACKUP 補足：候補と影響範囲を絞る dotnet-coupling --hotspots 5 ./src dotnet-coupling --impact Order --depth 2 ./src dotnet-coupling --trace Repository.Save \ --mode semantic ./MyApp.sln 32
37. BACKUP 補足：出典と確認範囲 Vlad Khononov cargo-coupling / dotnet-coupling 03 『ソフトウェア設計の結合 バランス』 実装・テスト・設計文書 OSS compare：2026-0628 33