Microsoft Entra documentation updateで確認すべきIdentityスキャフォールディング修正

Microsoft Entra documentation updateとして確認しておきたい今回の変更は、Entra IDの条件付きアクセスやアプリ登録を変えるものではありません。結論からいうと、ASP.NET IdentityまたはBlazor Identityをスキャフォールディングしたプロジェクトに、EF Coreのマイグレーションで必要なMicrosoft.EntityFrameworkCore.Designが確実に入るようにする修正です。影響を受けやすいのは、.NET 10以降でIdentityスキャフォールディングを使い、dotnet ef migrations addやVisual Studio経由でマイグレーションを作成する開発・CI環境です。公式の修正では、パッケージ未追加によりdotnet ef migrations addが失敗する問題が説明されています。(GitHub)

Microsoft Entra documentation updateの要点

今回の更新を一言でまとめると、Identityスキャフォールディング後にEF Coreマイグレーションを実行できる状態まで、必要なNuGetパッケージを揃える修正です。

公式PRでは、ASP.NET IdentityまたはBlazor Identityをスキャフォールディングした際にMicrosoft.EntityFrameworkCore.Designがプロジェクトへ追加されていなかったこと、そしてこのパッケージがEF Core toolingによるマイグレーション実行に必要であることが説明されています。対象として言及されているのは、.NET 10.0以降のプロジェクトで、WithIdentityAddPackagesStepとWithBlazorIdentityAddPackagesStepのパッケージ一覧に不足があったケースです。(GitHub)

観点	内容	確認すべきポイント
変更対象	ASP.NET Identity / Blazor Identityのスキャフォールディング	dotnet aspnet-codegenerator identityやVisual StudioのIdentity追加機能を使っているか
追加されるパッケージ	Microsoft.EntityFrameworkCore.Design	.csprojまたはdotnet list packageで参照があるか
主な影響	dotnet ef migrations addの失敗を防ぐ	マイグレーション作成・DB更新の手順が通るか
影響しないもの	Microsoft Entra IDテナント設定そのもの	条件付きアクセス、アプリ登録、APIアクセス許可の変更は通常不要
注意点	既存プロジェクトへ自動で反映されるとは限らない	すでに作成済みのプロジェクトは手動確認が必要

Microsoft Entra IDの設定変更ではない点に注意

「Microsoft Entra documentation update」という文脈で見かけると、Entra ID側のセキュリティ設定変更を想像しやすいですが、今回の実体はASP.NET Core IdentityのスキャフォールディングとEF Core toolingに関する修正です。

Microsoft Learnでは、ASP.NET Core IdentityはUIログイン機能、ユーザー、パスワード、ロール、クレームなどを扱う仕組みであり、Microsoft identity platformとは別物であると説明されています。一方、Web APIやSPAを保護する選択肢としてMicrosoft Entra IDが示されています。(Microsoft Learn)

そのため、管理者と開発者で確認ポイントを分けると判断しやすくなります。

立場	今回見るべきポイント	基本的に不要な対応
Microsoft Entra管理者	認証方式の設計にASP.NET Core Identityが含まれているか	条件付きアクセス、アプリ登録、リダイレクトURIの即時変更
アプリ開発者	.csprojにMicrosoft.EntityFrameworkCore.Designが入っているか	Entra IDポータル側だけを確認して完了とすること
CI/CD管理者	dotnet ef、NuGet復元、マイグレーション生成がビルド環境で通るか	ローカル開発端末だけでの動作確認
リリース管理者	Identityスキーマ変更を本番DBへどう適用するか	スキャフォールディング成功だけで本番適用済みとみなすこと

影響を受ける可能性が高いプロジェクト

次のいずれかに当てはまる場合は、今回の更新を確認対象に入れるべきです。

プロジェクトの状態	影響度	理由
.NET 10以降でBlazor Identityをスキャフォールディングしている	高	PRでBlazor Identityのパッケージ追加ステップが修正対象になっているため
Razor Pages / MVCでASP.NET Core Identityを後から追加している	高	Identityスキャフォールディング後にマイグレーション作成が必要になるため
CIでdotnet ef migrations addやdotnet ef database updateを実行している	高	開発端末では通っても、CI環境でパッケージ不足が露呈しやすいため
Microsoft Entra IDのみで認証し、ASP.NET Core IdentityのDBを使っていない	低	今回の修正対象はIdentityスキャフォールディングとEF Core toolingのため
既存アプリで過去にIdentityスキーマを作成済みだが、今後もマイグレーションを追加する	中	既存の.csprojに不足が残っている可能性があるため

特に注意したいのは、「スキャフォールディングは成功したのに、その後のマイグレーションで失敗する」パターンです。コード生成の時点では問題が見えず、DBスキーマを作成する段階で初めて止まるため、リリース直前に発覚しやすい不具合です。

まず確認すべき設定

開発者が最初に見るべき場所は、Microsoft Entra管理センターではなく、対象アプリの.csprojです。

パッケージ参照を確認する

プロジェクトのルートで、次のコマンドを実行します。

dotnet list package

Windowsのコマンドプロンプトで絞り込む場合は、次のように確認できます。

dotnet list package | findstr Microsoft.EntityFrameworkCore.Design

PowerShellでは次の形でも確認できます。

dotnet list package | Select-String "Microsoft.EntityFrameworkCore.Design"

Microsoft.EntityFrameworkCore.Designが表示されない場合は、対象プロジェクトに追加します。

dotnet add package Microsoft.EntityFrameworkCore.Design

EF Coreの公式CLIリファレンスでも、特定のプロジェクトでツールを使う前にMicrosoft.EntityFrameworkCore.Designパッケージを追加する必要があると案内されています。(Microsoft Learn)

.csprojで確認する場合

dotnet list packageだけでなく、.csprojも直接確認します。パッケージ管理を中央管理している場合はDirectory.Packages.propsも確認対象です。

<ItemGroup>
  <PackageReference Include="Microsoft.EntityFrameworkCore.Design">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
  </PackageReference>
</ItemGroup>

NuGet Galleryでは、Microsoft.EntityFrameworkCore.DesignはEF Core toolsのデザイン時タスクで使われ、マイグレーション管理やDbContextのスキャフォールディングに利用されると説明されています。また、公開アプリにツール用アセンブリを含めないため、PrivateAssets="all"を付ける例も示されています。([NuGet][4])

マイグレーションが通るか検証する手順

パッケージを追加したら、実際にEF Core toolingが動作するか確認します。既存の本番ブランチで不要なマイグレーションを作るのではなく、検証用ブランチまたは作業ブランチで実施してください。

手順	コマンド例	確認内容
依存関係を復元	dotnet restore	NuGetパッケージが取得できるか
ビルド	dotnet build	Identity関連コードがコンパイルできるか
EFツール確認	dotnet ef	dotnet-efが利用可能か
マイグレーション一覧	dotnet ef migrations list	DbContextを認識できるか
マイグレーション作成	dotnet ef migrations add CreateIdentitySchema	Designパッケージ不足で止まらないか
DB更新	dotnet ef database update	ローカルまたは検証DBへ適用できるか

DbContextが複数ある場合は、--contextを明示します。

dotnet ef migrations add CreateIdentitySchema --context ApplicationDbContext
dotnet ef database update --context ApplicationDbContext

ターゲットプロジェクトとスタートアッププロジェクトが分かれている構成では、次のように指定します。

dotnet ef migrations add CreateIdentitySchema \
  --project ./src/MyApp.Infrastructure \
  --startup-project ./src/MyApp.Web \
  --context ApplicationDbContext

EF Coreのマイグレーションは、モデル変更に対応する移行ファイルを生成し、データベーススキーマを段階的に更新する仕組みです。生成されたマイグレーションファイルはソース管理に含め、レビュー対象にするのが実務上の基本です。(Microsoft Learn)

Visual Studioで作業している場合の注意点

Visual Studioの「Add > New Scaffolded Item」からIdentityを追加している場合も、最終的にはプロジェクトに必要なNuGetパッケージが入っているかを確認してください。

Microsoft LearnのIdentityスキャフォールディング手順では、Blazorプロジェクト向けにdotnet-aspnet-codegenerator、dotnet-ef、Microsoft.EntityFrameworkCore.Design、Microsoft.VisualStudio.Web.CodeGeneration.Design、DBプロバイダー、Microsoft.EntityFrameworkCore.Toolsなどを追加する流れが示されています。また、生成されたIdentityのデータベースコードはEF Core Migrationsを必要とし、dotnet ef migrations addとdotnet ef database updateで移行を作成・適用する手順が案内されています。(Microsoft Learn)

Visual Studioで失敗する場合、次の順に切り分けると原因を見つけやすくなります。

症状	よくある原因	対応
Identity追加後にマイグレーション作成で失敗する	Microsoft.EntityFrameworkCore.Designがない	.csprojへ追加して復元
dotnet efが認識されない	dotnet-efが未インストール	dotnet tool install --global dotnet-efまたはローカルツール化
DbContextが見つからない	スタートアッププロジェクトが違う	--projectと--startup-projectを指定
DbContextが複数あり選べない	複数のContextが存在する	--contextで明示
ローカルでは通るがCIで失敗する	CI環境のSDK・ツール・NuGetフィード差分	CIイメージとNuGet設定を更新

管理者が確認すべき展開上のポイント

今回の更新は「パッケージが追加されるから安全」という単純な話ではありません。Identityは認証・ユーザー管理に関わるため、DBスキーマ変更、CI/CD、権限管理、レビュー手順まで含めて確認する必要があります。

NuGetフィードと依存関係の許可

企業環境では、NuGet.orgを直接参照せず、Azure Artifactsや社内ミラーを使うことがあります。この場合、Microsoft.EntityFrameworkCore.Designが社内フィードで利用可能かを確認してください。

確認すべき項目は次のとおりです。

確認項目	判断基準
パッケージ取得元	CIと開発端末で同じNuGet設定を使っているか
バージョン整合性	Microsoft.EntityFrameworkCore.*系のメジャーバージョンが揃っているか
ロックファイル	packages.lock.jsonを使っている場合、追加後に更新されているか
セキュリティスキャン	新規依存関係として検知・承認されているか
オフラインビルド	ビルドエージェントが必要パッケージを取得できるか

本番DBへの適用は別管理にする

dotnet ef database updateはローカル開発や検証環境では便利ですが、本番環境でそのまま実行するかは組織の運用ルールに合わせるべきです。EF Core公式ドキュメントでも、dotnet ef database updateによる適用はローカル開発には適している一方、本番環境では別の適用方法を検討すべき旨が示されています。(Microsoft Learn)

本番展開では、少なくとも次の流れを推奨します。

dotnet ef migrations script --idempotent --output identity-migration.sql

生成したSQLをDBAまたはレビュー担当者が確認し、検証環境で適用してから本番に反映します。認証テーブルはユーザー登録、ログイン、ロール、クレームに関係するため、安易な削除・リネーム・再作成は避けてください。

セキュリティ面で誤解しやすいポイント

今回の修正は、直接的な脆弱性修正というより、Identityスキャフォールディング後の開発体験とマイグレーション実行に関する修正です。ただし、認証機能の導入途中でマイグレーションが失敗すると、以下のような運用上のリスクにつながります。

リスク	起きやすい状況	対策
認証テーブルが未作成のままデプロイされる	スキャフォールディング成功だけで完了と判断する	マイグレーション適用確認をリリース条件に入れる
2FAやメール確認が未実装のまま公開される	Identity UIだけ生成して周辺サービスを未設定	メール送信、トークン、2FA要件を別途確認
開発環境と本番環境で挙動が違う	ローカルDBだけ更新され、本番DBに未反映	SQLスクリプト化し、環境別に適用履歴を管理
CIだけ失敗する	CIにdotnet-efやNuGetパッケージがない	ビルド定義にツール復元とパッケージ復元を明記
Entra ID側だけ確認して完了にする	ASP.NET Core IdentityとEntra IDを混同する	アプリコード、DB、Entra設定を分けて確認

Microsoft Learnでも、Identityスキャフォールディングでは2FA、アカウント確認、パスワード回復などのセキュリティ機能に必要なサービスやスタブは自動生成されないため、必要なサービスを手動で追加する必要があると説明されています。(Microsoft Learn)

既存プロジェクトでの対応手順

すでにIdentityスキャフォールディング済みのプロジェクトでは、次の順序で対応すると安全です。

作業ブランチを作成する

まず、既存ブランチへ直接変更せず、作業ブランチを作成します。

git checkout -b fix-identity-ef-design

パッケージ参照を確認・追加する

dotnet list package
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet restore
dotnet build

バージョンを明示しているプロジェクトでは、既存のMicrosoft.EntityFrameworkCore.SqlServer、Microsoft.EntityFrameworkCore.Tools、Microsoft.AspNetCore.Identity.EntityFrameworkCoreなどとメジャーバージョンを揃えます。

マイグレーションを検証する

dotnet ef migrations list --context ApplicationDbContext
dotnet ef migrations add CreateIdentitySchema --context ApplicationDbContext

すでにIdentityスキーマ用のマイグレーションがある場合、不要なマイグレーションを追加しないようにしてください。確認目的で作成したマイグレーションが不要なら、レビュー前に戻します。

dotnet ef migrations remove --context ApplicationDbContext

CI/CDを更新する

CIでdotnet efを使う場合は、グローバルツールに依存しすぎない構成が望ましいです。チーム開発ではローカルツールマニフェストを使うと、ツールバージョンをリポジトリ側で管理しやすくなります。

dotnet new tool-manifest
dotnet tool install dotnet-ef
dotnet tool restore

CIでは次のように実行します。

dotnet tool restore
dotnet restore
dotnet build
dotnet ef migrations list --context ApplicationDbContext

新規プロジェクトでの推奨チェックリスト

これからMicrosoft Entra IDやASP.NET Core Identityを組み合わせたアプリを作る場合は、認証方式を先に整理してから実装に入ると手戻りを減らせます。

チェック項目	推奨判断
社内ユーザーのみをEntra IDで認証する	Microsoft Entra ID中心で設計し、ASP.NET Core Identity DBが必要かを慎重に判断
一般ユーザーの登録・ログインを自前で持つ	ASP.NET Core Identityの採用を検討
ローカルアカウントと外部IdPを併用する	Identity DB、外部ログイン、Entra ID連携の責務を分ける
Blazor Web AppでIdentity UIを使う	Blazor Identityスキャフォールディング後にEF Coreマイグレーションまで確認
本番でDB変更が厳格に管理される	マイグレーションSQLを生成し、レビュー・承認フローに載せる

重要なのは、「Microsoft Entra IDを使うか」「ASP.NET Core Identityを使うか」を二択で雑に決めないことです。Entra IDは組織IDや外部IdPとの連携に強く、ASP.NET Core Identityはアプリ内のユーザー管理やローカルアカウントに向いています。どちらを使う場合でも、認証方式、ユーザーデータの保存場所、DBスキーマ変更の運用を明確にしておく必要があります。

よくある質問

Microsoft Entra IDだけを使っているアプリも対応が必要ですか？

ASP.NET Core IdentityのスキャフォールディングやIdentity用DbContextを使っていないなら、今回の修正による直接影響は小さいと考えられます。ただし、アプリ内にIdentityのコードやApplicationDbContext、AspNetUsersなどのテーブルがある場合は確認対象です。

Microsoft.EntityFrameworkCore.Toolsがあれば十分ですか？

十分とは限りません。EF Core toolingを使う対象プロジェクトにはMicrosoft.EntityFrameworkCore.Designが必要です。NuGet Galleryでも、このパッケージはコマンドラインまたはPackage Manager Consoleベースの tooling に必要と説明されています。([NuGet][4])

パッケージを追加すると本番アプリに余計なDLLが含まれますか？

通常はPrivateAssets="all"を付けることで、ツール用の依存関係を公開アプリへ伝播させない構成にします。既存の.csprojで中央管理やテンプレート管理をしている場合は、チームの標準に合わせてください。

スキャフォールディングをやり直す必要はありますか？

多くの場合、やり直しよりも.csprojの確認と不足パッケージの追加で対応できます。ただし、過去のスキャフォールディングで生成されたIdentityコードを大きくカスタマイズしている場合は、再実行で既存コードを上書きしないように差分確認が必須です。Microsoft Learnでも、Identityスキャフォールディング後はソース管理で変更を確認し、必要に応じて戻せるようにすることが推奨されています。(Microsoft Learn)

まとめ：今すぐ確認すべきこと

今回のMicrosoft Entra documentation updateで重要なのは、Entra IDの管理画面を変更することではなく、ASP.NET Core Identity / Blazor Identityを使うアプリの開発・移行手順が正しく完走するかを確認することです。

最初にやるべきことはシンプルです。対象リポジトリでMicrosoft.EntityFrameworkCore.Designの参照を確認し、なければ追加します。そのうえで、dotnet restore、dotnet build、dotnet ef migrations list、必要に応じてdotnet ef migrations addまでを検証してください。

本番展開では、マイグレーションを作成できることと、DBへ安全に適用できることは別問題です。Identity関連のDB変更は、SQLスクリプト化、レビュー、検証環境での適用確認を経てから本番へ反映するのが安全です。

[4]: https://www.nuget.org/packages/microsoft.entityframeworkcore.design/ “
NuGet Gallery
| Microsoft.EntityFrameworkCore.Design 10.0.8
“