outdated

/outdated

概要

3 層構成の依存関係ヘルスレポートです。

1. インベントリ — MCP ツール get_nuget_packages を使用して、プロジェクトごとのすべての PackageReference を TFM と集中型パッケージ管理の情報とともに取得します（ネットワーク不要、トークン消費はわずかです）。
2. 古さと脆弱性 — dotnet CLI を使用して、現在のバージョンと最新の安定版、および既知の CVE を確認します。
3. ライセンスチェック — 商用ライセンスに移行したパッケージにフラグを付けることで、意図しない dotnet outdated --upgrade により法的な立場がひそかに変わるのを防ぎます。

出力は、脆弱性、ライセンス上の注意点、古さの順に優先度を付けた単一のテーブルで、各行に推奨アクションを示します。

実施するタイミング

• 「古いパッケージを確認」「パッケージ監査」「依存関係の健全性」を調べるとき
• .NET バージョンのアップグレード前（/migrate の Flow B と組み合わせます）
• 不慣れなコードベースを引き継いだ後
• Dependabot／NuGet の監査警告が表示され、全体像を把握したいとき
• 長期間運用しているプロジェクトで定期的に実施するとき — 四半期ごとが適切な頻度です

手順

ステップ 1：インベントリ（MCP、ネットワーク不要）

get_nuget_packages()                          -- whole solution
get_nuget_packages(projectFilter: "Api")      -- or one project

プロジェクトごとに {Name, TargetFramework, Cpm, Packages: [{Id, Version}]} を返します。 Cpm: true の場合、更新先は csproj ではなく Directory.Packages.props です。この機会に、プロジェクト間で TFM が混在していないか確認してください。

ステップ 2：古さと脆弱性（CLI）

dotnet list package --outdated
dotnet list package --vulnerable --include-transitive

どちらも、先に正常な restore が完了している必要があります。restore が失敗する場合は、監査の前に修正してください。ロック状態が壊れていると、バージョン情報の信頼性が損なわれます。

ステップ 3：ライセンスチェック

インベントリを既知の商用ライセンスへの移行と照合します（詳しい根拠は knowledge/package-recommendations.md を参照してください）。

パッケージ	商用化されたバージョン	無料の代替
MediatR	13+（Lucky Penny、RPL）	Mediator（martinothamar）— ソース生成、MIT
MassTransit	9+（v8 は Apache、パッチ提供は 2026 年に終了し、その後 EOL）	Wolverine 6.x、または短期的には v8 を継続
FluentAssertions	8+（v7 は Apache のまま、更新停止）	xUnit 組み込みの Assert（kit のデフォルト）、Shouldly、AwesomeAssertions
AutoMapper	15+（Lucky Penny）	手動マッピング（kit のデフォルト）または Mapperly（MIT）

プロジェクトが無料のメジャーバージョンを使用していて、安易な「すべて更新」により境界を越える場合に、ライセンスフラグが発生します。このステップは、その落とし穴を防ぐためのものです。

ステップ 4：レポート

優先度順に並べた単一のテーブルです。

優先度	意味	アクション
VULNERABLE	現在のバージョンに既知の CVE があります	今すぐ更新し、テストして、デプロイします
LICENSE	次のメジャーバージョンで商用ライセンスの境界を越えます	境界より前のバージョンに固定するか、移行を計画します
MAJOR	メジャーバージョンが遅れています（破壊的変更の可能性があります）	1 つずつ更新し、先にリリースノートを確認します
MINOR/PATCH	通常の遅れです	パッチはまとめて適用し、マイナー更新は1つずつ行います

ステップ 5：対応（任意）

/migrate の Flow C を通じて更新を実行するか確認します。各パッケージを1つずつ更新し、その都度 dotnet build && dotnet test を実行します。メジャー更新をまとめて適用してはいけません。まとめて失敗すると、原因を特定できなくなります。

使用する MCP ツール

• get_nuget_packages — インベントリ、CPM の検出、TFM の監査
• get_diagnostics — 更新後もソリューションが正常にコンパイルされることを確認

例

User: /outdated

Claude: Inventorying packages (get_nuget_packages)...
  3 projects, CPM enabled (Directory.Packages.props), all net10.0.

  Checking versions and CVEs...

  | Package                  | Current | Latest  | Priority   | Action                          |
  |--------------------------|---------|---------|------------|---------------------------------|
  | System.Text.Json (trans.)| 10.0.2  | 10.0.10 | VULNERABLE | Update now (CVE-2026-XXXX)      |
  | MassTransit              | 8.3.0   | 9.1.2   | LICENSE    | v9 is commercial. Stay on v8    |
  |                          |         |         |            | (EOL end 2026) or plan Wolverine|
  | Serilog.AspNetCore       | 9.0.0   | 10.0.0  | MAJOR      | Update alone, check sink compat |
  | FluentValidation         | 12.0.1  | 12.1.1  | PATCH      | Batch with other patches        |

  1 vulnerability, 1 license trap, 1 major, 1 patch.
  Want me to apply these via /migrate Flow C?

関連項目

• /migrate — Flow C で、このレポートが推奨する更新を実行します
• knowledge/package-recommendations.md — 精査済みパッケージとライセンスの詳細
• knowledge/mediatr-to-mediator-migration.md — MediatR からの移行手順
• /verify — 更新適用後のパイプライン全体の検証