Codex NuGetの使い方と.NET開発の依存関係更新確認手順

Codex NuGetとは何をする組み合わせなのか

Codex NuGet という専用製品があるわけではない。ここで扱うのは、OpenAI Codex に .NET プロジェクトの NuGet 依存関係を読ませ、パッケージの追加、更新候補の確認、不要な参照の整理、ビルド失敗の原因調査を手伝わせる使い方だ。Codex CLI の公式ページでは、Codex がターミナルからコードを調べ、変更し、手元にあるツールを実行できると説明されている(出典: https://learn.chatgpt.com/docs/codex/cli)。.NET プロジェクトでは、.csproj、Directory.Packages.props、NuGet.Config、packages.lock.json のようなテキストファイルが依存関係の状態を表すため、Codex が読み解きやすい。人間が「このプロジェクトに必要な JSON ライブラリを足して」「古い Entity Framework Core を安全に上げたい」と頼むだけで、候補の調査、変更箇所の特定、検証コマンドの提案までつなげられる。

ただし、Codex に NuGet を任せるときは「パッケージを入れる係」とだけ考えないほうがよい。NuGet の変更はソースコードより小さく見えるが、実際にはターゲットフレームワーク、推移的依存関係、脆弱性情報、ライセンス、社内パッケージソース、ロックファイルまで影響が広がる。Codex の強みは、単発のコマンド実行よりも、これらの関連ファイルを横断して「なぜこの変更が必要か」「どこまで確認できたか」を言語化できる点にある。特に、複数プロジェクトを含む solution では、あるライブラリの更新がテストプロジェクトやツールプロジェクトにだけ必要なのか、本体にも必要なのかを見分ける作業が増える。Codex にはその判断材料を集めさせ、人間は最終的な採用判断に集中する、という分担が現実的だ。

なぜ今 NuGet まわりを Codex に任せやすくなったのか

OpenAI は 2026年7月9日の Codex changelog で、Codex が ChatGPT デスクトップアプリの一部になったことを案内している(出典: https://learn.chatgpt.com/docs/changelog)。これにより、ターミナルだけでなくデスクトップアプリ側からもプロジェクトや差分を扱う場面が増えた。NuGet のように「少しだけファイルを変え、すぐ検証する」作業は、まさにこの近さの恩恵を受けやすい。依存関係の追加は数行の変更で済むことが多いが、失敗したときは restore のログ、ターゲットフレームワーク、バージョン制約、パッケージソースを順に追う必要がある。Codex は、こうした確認の枝分かれを会話で整理しながら進められる。

.NET 側にも押さえるべき変化がある。Microsoft Learn の dotnet package add ページでは、.NET 10 以降では dotnet package add <PACKAGE_NAME> という名詞先頭形を使い、.NET 9 SDK 以前では従来の dotnet add package を使うと説明されている(出典: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-add)。つまり、古い記事や手元の記憶だけでコマンドを選ぶと、SDK の世代によって説明がずれる。Codex に最初に dotnet --version や solution 構成を確認させ、現在の SDK に合う表記で進めさせると、不要な往復を減らせる。記事を読む側も、「Codex が賢いから任せる」ではなく「SDK と公式コマンド体系を確認してから任せる」と考えるほうが安全だ。

始める前に確認したい NuGet の前提

NuGet の変更は、見た目以上にプロジェクト構造へ依存する。単一の .csproj だけで完結する小さなアプリなら、パッケージ追加は比較的単純だ。一方で、複数のクラスライブラリ、テストプロジェクト、共有 props ファイル、中央バージョン管理を持つ構成では、どこに参照を書くべきかを間違えると、ビルドは通っても運用上の意図から外れる。Codex に任せる前に、「対象プロジェクトはどれか」「バージョンは個別管理か中央管理か」「ロックファイルを使っているか」「社内フィードを含むか」を確認させると、変更の範囲を狭く保てる。NuGet は単なるダウンロード機構ではなく、ビルド入力そのものを決める仕組みだと捉えるべきだ。

Microsoft Learn の PackageReference の説明では、依存関係は <PackageReference> の MSBuild item としてプロジェクトファイル内に記録され、NuGet.Config の設定も引き続き適用されるとされている(出典: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files)。この仕組みを知っていると、Codex への依頼の粒度が変わる。「Newtonsoft.Json を入れて」とだけ頼むより、「対象は src/App/App.csproj、PackageReference で追加し、既存の props 管理があればそちらに合わせて」と伝えるほうが、意図に近い差分になりやすい。特に中央管理を使うチームでは、パッケージ名は各プロジェクト、バージョンは Directory.Packages.props に分かれることがある。Codex にはまず構成を読ませ、既存の書き方を確認させるのが出発点になる。

Step 1: プロジェクト構造を先に読ませる

最初の依頼では、いきなりパッケージを追加させず、solution とプロジェクトファイルの関係を Codex に説明させる。たとえば「この .NET solution の NuGet 管理方法を確認し、PackageReference、中央バージョン管理、ロックファイル、NuGet.Config の有無を短く整理して」と頼むとよい。Codex はファイルを横断して、どのプロジェクトが本体で、どれがテストやツールなのかを推測できる。ここで対象を誤ると、その後の dotnet package add も正しい場所に入らない。作業前の棚卸しに数分かけるほうが、後で参照の移動やバージョンの戻しをするより早い。

Step 2: SDK 世代に合うコマンドを選ばせる

次に、現在の .NET SDK に合わせて追加コマンドを決める。Microsoft Learn は .NET 10 以降の名詞先頭形として dotnet package add を案内し、.NET 9 以前では dotnet add package を使うと明記している(出典: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-add)。Codex には「SDK の世代を確認し、この環境で使うべきコマンド表記を選んで」と伝える。新しい構文を無理に使わせるより、手元の SDK で確実に通る表記を選ばせるほうが実務では強い。記事や社内メモを再利用するときも、この差を前提にすると混乱が減る。

Step 3: 追加と更新を分けて依頼する

パッケージ追加と既存パッケージ更新は、同じ NuGet 操作に見えて判断軸が違う。追加では「どのプロジェクトに入れるか」「ターゲットフレームワークに対応しているか」「既存コードに必要な using や設定があるか」が中心になる。更新では「破壊的変更がないか」「推移的依存関係が変わるか」「テストの失敗が起きないか」が中心になる。Codex に「まず追加だけ」「次に更新候補だけ」と分けて頼むと、差分の意味が読みやすい。Microsoft Learn の dotnet package list には、参照一覧、古いパッケージ、脆弱性のあるパッケージなどを確認する選択肢が示されているため、更新調査の入口として使いやすい(出典: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-list)。

Step 4: 差分と検証結果を同じ画面で読ませる

NuGet 変更後は、差分だけでなく、復元、ビルド、テストの結果を Codex に読ませる。重要なのは、成功したかどうかだけで終わらせないことだ。警告が増えていないか、意図しないプロジェクトファイルが変わっていないか、ロックファイルの差分が説明できるかを確認する。Codex には「今回の NuGet 変更で変わったファイルを分類し、必要な差分と不要そうな差分を分けて」と頼める。人間が見るべきポイントは、パッケージ名とバージョン、対象プロジェクト、ロックファイル、失敗ログの四つだ。この四点がそろえば、レビュー時にも「なぜこの変更が入ったか」を説明しやすい。

パッケージ追加を Codex に頼むときの依頼文

Codex に NuGet パッケージを追加させるときは、自然言語の依頼に「対象」「目的」「制約」「確認方法」を入れる。たとえば、対象が Web API なら「src/Api/Api.csproj に FluentValidation を追加し、既存の DI 登録パターンに合わせて最小のサンプル実装を入れ、ビルドと関連テストまで確認して」といった頼み方がよい。対象がテストだけなら、「本体プロジェクトには入れず、テストプロジェクトにだけ Moq を追加して」と明示する。Codex は文脈を読めるが、NuGet の参照先はプロジェクト単位で決まるため、対象を曖昧にすると余計なプロジェクトに入る可能性がある。

依頼文には、バージョン方針も入れておくとよい。最新安定版でよいのか、既存の major version に合わせるのか、プレビュー版を避けるのかで、Codex の選択は変わる。Microsoft Learn の dotnet package add には --version、--prerelease、--source などの選択肢が示されている(出典: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-add)。ただし、すべての選択肢を一度に使わせる必要はない。まずはプロジェクトの既存方針を読ませ、「同じ方針で追加して」と頼むほうが安定する。既存の .csproj が整っている場合、Codex は似た書き方に合わせやすい。

更新確認では outdated と vulnerable を混ぜない

NuGet 更新でよくある失敗は、古いパッケージの更新と脆弱性対応を同じ判断で扱ってしまうことだ。古いだけのパッケージは、互換性や開発予定を見て次のタイミングに回せる。一方で、脆弱性があるパッケージは、影響範囲と修正可能なバージョンを早めに調べる必要がある。Codex には「古いパッケージ」と「脆弱性のあるパッケージ」を別々に確認させ、それぞれの判断理由を分けて出させる。dotnet package list の公式ページでは、--outdated や --vulnerable のような確認に使える選択肢が説明されている(出典: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-list)。

実際の運用では、Codex に「まず一覧だけ出して、まだ変更しない」と頼むのが扱いやすい。更新候補を見たあとで、「patch だけ上げる」「minor まで許可する」「major は別タスクに分ける」といった方針を人間が決める。Codex は候補を整理し、影響しそうなコードを探し、失敗したテストのログを読む係に向いている。特に、Entity Framework Core、ASP.NET Core、Azure SDK のように複数パッケージの version がそろっていることに意味がある領域では、単体で一つだけ上げるより、関連パッケージのまとまりを見るほうが安全だ。更新作業は速さより説明可能性を優先したほうが、後で戻す判断もしやすい。

PackageReference とロックファイルをどう読ませるか

PackageReference は、NuGet 依存関係をプロジェクトファイルに直接書く方式だ。Microsoft Learn は、PackageReference が .csproj などのプロジェクトファイル内で依存関係を指定し、NuGet.Config の設定も適用されると説明している(出典: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files)。Codex に依存関係を読ませるときは、<PackageReference Include="..." Version="..." /> だけを見せるのではなく、プロジェクト全体の TargetFramework、ItemGroup の条件、Directory.Packages.props の有無も確認させる。条件付き参照や multi-targeting があるプロジェクトでは、単純な追加が片方の target にしか効かないこともある。

ロックファイルを使っている場合は、Codex に「このロックファイル差分は今回の変更から説明できるか」と聞くとよい。依存関係の更新では、直接追加したパッケージだけでなく、推移的に入るパッケージの version も変わる。ロックファイルの差分が大きいときは、必要な更新か、ソース設定や復元条件が変わった副作用かを切り分ける必要がある。Codex は大量の差分を読むのが得意だが、最終判断にはプロダクト側の互換性知識が必要になる。だから、Codex には「差分を分類して根拠を示す」役割を持たせ、人間は採用・延期・分割の判断を行う、という役割分担が向いている。

失敗ログを Codex に読ませるときのコツ

NuGet まわりの失敗は、エラーメッセージだけを見ると似ている。パッケージが見つからない、互換性がない、復元に失敗する、ターゲットフレームワークが合わない、社内フィードに接続できないなど、原因は複数ある。Codex にログを渡すときは、最後の一行だけではなく、直前に出たプロジェクト名、パッケージ名、source 名、target framework まで含めて読ませる。そうすると「パッケージ名の typo」「SDK 世代の不一致」「対象プロジェクトの誤り」「パッケージソース設定の問題」を切り分けやすい。ログは長くなりがちだが、Codex には「エラーの主因候補を三つ以内に絞り、次に確認すべきコマンドを一つだけ提案して」と頼むと、調査が散らかりにくい。

注意したいのは、社内フィードや商用パッケージを使う環境だ。Codex に設定ファイルを読ませる前に、接続先 URL や認証方式が記事や共有ログに出て困らない範囲かを確認する。本文やレビューコメントに出してよい情報と、出してはいけない情報を分けるのは人間の責任だ。Codex には「機密値は表示せず、設定の有無と種類だけ説明して」と指示できる。これなら、原因調査に必要な構造は保ちながら、不要な情報の露出を抑えられる。NuGet の設定は一見地味だが、依存関係の入口であり、チームの配布経路そのものでもある。扱いを軽く見ないことが大切だ。

Codex NuGetで使える依頼例

実際に頼むなら、依頼文は短くても構わないが、目的と境界は明確にする。たとえば「この solution の NuGet 管理方式を確認し、古いパッケージと脆弱性のあるパッケージを分けて一覧化して。まだファイルは変更しない」と頼めば、Codex は調査だけに集中できる。次に「patch 更新だけを候補にし、差分が出るファイルを先に予告して」と続けると、変更前に影響範囲を見られる。追加作業なら「src/Worker に Polly を追加し、既存の retry 実装に合わせて最小変更にして。完了後にビルド結果と変更ファイルを要約して」といった粒度が扱いやすい。重要なのは、Codex に「調査」「変更」「確認」「説明」を一度に混ぜすぎないことだ。

新しいパッケージを試す場合は、まず小さな枝で確認するのがよい。Codex にサンプル実装まで頼むと、パッケージが実際に使えるかを早く判断できる。ただし、採用前の検証では、不要になった参照やサンプルコードを戻す判断も必要になる。Codex には「このパッケージを採用しない場合、戻すべき差分を整理して」と頼める。NuGet の変更は、単純な追加よりも「戻しやすさ」まで設計しておくと失敗しにくい。Codex を使う価値は、追加の速さだけでなく、採用しない判断まで短い時間で確認できるところにもある。

まとめ

Codex NuGet の要点は、Codex にパッケージ操作を丸投げすることではなく、NuGet 変更の前提確認と検証を会話で細かく区切ることにある。OpenAI 公式の Codex CLI 説明が示すように、Codex はローカルのプロジェクトを読み、編集し、手元のコマンドで確認できる(出典: https://learn.chatgpt.com/docs/codex/cli)。そこに、Microsoft Learn が説明する dotnet package add、dotnet package list、PackageReference の仕組みを組み合わせれば、.NET の依存関係管理はかなり扱いやすくなる。特に .NET 10 以降と .NET 9 以前でコマンド表記が変わる点は、2026年時点の記事として必ず押さえたい。

実務では、最初に構成を読ませ、次に追加や更新候補を出させ、最後に差分と検証結果を説明させる流れが安定する。Codex は大量のファイルやログを読む補助役として強く、人間は対象プロジェクト、採用方針、公開してよい情報、リリース判断を握る。この分担を守れば、NuGet の依存関係更新は「怖い小変更」から「根拠を持って進められる保守作業」に変えられる。