2026年5月21日に確認対象となった「Microsoft Purview documentation update: [release/11.0-preview5] Use publicly available version of ServiceDiscovery package in blazor-wasm-servicedefaults template」は、Microsoft Purview本体のDLPポリシーや秘密度ラベルを変更するセキュリティ更新ではありません。実態は、ASP.NET Coreの.NET 11 Preview 5向けテンプレートで、Microsoft.Extensions.ServiceDiscovery の参照バージョンを公開済みパッケージに固定する修正です。公式PRでは release/11.0-preview5 ブランチへバックポートされ、対象ファイルは BlazorWasmServiceDefaults-CSharp.csproj.in の1ファイル、差分は1追加・1削除でした。(GitHub)
Microsoft Purview管理者がまず押さえるべき点は、Purviewポータル、DLP、Information Protection、eDiscovery、監査、保持ラベルなどのテナント設定を急いで変更する必要は基本的にないことです。一方で、Purview SDK/APIと連携する社内アプリ、AIアプリ、管理画面をBlazor WebAssemblyや.NET Aspire構成で開発しているチームは、CI/CDやNuGet復元で失敗しないように依存パッケージを確認する必要があります。
Microsoft Purview documentation updateの結論：Purview本体ではなく.NETテンプレートの修正
今回の更新は、名称だけを見るとMicrosoft Purviewのセキュリティ更新に見えますが、主ソースであるGitHub PRの内容は dotnet/aspnetcore リポジトリのテンプレート修正です。PR #66755は、元PR #66698を release/11.0-preview5 にバックポートするもので、blazor-wasm-servicedefaults テンプレート内の Microsoft.Extensions.ServiceDiscovery 参照を、リポジトリ管理の変数から 10.6.0 に変更しています。(GitHub)
| 確認項目 | 内容 | 実務上の見方 |
|---|---|---|
| 対象 | ASP.NET Coreの blazor-wasm-servicedefaults テンプレート | Purviewポータルの設定変更ではない |
| ブランチ | release/11.0-preview5 | .NET 11 Preview 5向けの修正として扱う |
| 変更ファイル | src/ProjectTemplates/Web.ProjectTemplates/BlazorWasmServiceDefaults-CSharp.csproj.in | 既存アプリでは .csproj や社内テンプレートを確認 |
| 変更内容 | Microsoft.Extensions.ServiceDiscovery を 10.6.0 に固定 | NuGetから復元できる公開パッケージを参照 |
| 主な目的 | テンプレート生成後のパッケージ復元失敗を避ける | CI/CD、開発端末、社内NuGetミラーで確認 |
背景には、dotnet new blazor-wasm-servicedefaults で作成したプロジェクトが、公開フィードで見つからない Microsoft.Extensions.ServiceDiscovery のプレビュー版を参照し、NU1102 で復元に失敗する問題がありました。関連Issueでは、Windows、macOS、Linuxを対象に再現手順が示され、実際のエラーとして Unable to find package Microsoft.Extensions.ServiceDiscovery with version (>= 10.6.0-preview.1.26210.2) が記録されています。(GitHub)
Microsoft Purviewとの関係は「開発者連携アプリ」に限定して考える
Microsoft Purviewは、データガバナンス、データセキュリティ、データコンプライアンスを扱う製品群です。Microsoft公式ドキュメントでも、Unified Catalog、Data Map、DLP、Information Protection、Insider Risk Management、Audit、eDiscoveryなどがPurviewの主要領域として整理されています。(Microsoft Learn)
ただし、今回のServiceDiscovery修正は、これらのPurview機能そのものを変更するものではありません。影響が出る可能性があるのは、Microsoft PurviewのAPI、SDK、Microsoft Graph連携、社内のデータ保護アプリ、AIエージェント連携などを.NETで開発しているケースです。Microsoft Purview Developer Platformは、アプリやエージェントにPurviewのガバナンス、保護、データ管理機能を統合するための機能を提供しています。(Microsoft Learn)
| 影響を受ける可能性があるもの | 影響を受けにくいもの |
|---|---|
| Purview APIと連携する.NET製の社内管理画面 | Microsoft PurviewポータルのDLP設定 |
| Blazor WebAssemblyで作ったデータ分類・申請UI | 秘密度ラベル、保持ラベル、監査ログの既存設定 |
| .NET Aspire構成の開発テンプレート | Microsoft 365管理センターやPurview管理センターの標準操作 |
blazor-wasm-servicedefaults を使う新規プロジェクト | 既に本番稼働しており該当テンプレートを使っていないアプリ |
| 社内NuGetミラーやロックファイルを使うCI/CD | ノーコードでPurviewを運用している管理者 |
つまり、Purview管理者だけで完結する話ではなく、Purviewを利用するアプリを開発・展開しているチームが確認すべき更新です。
変更点：ServiceDiscoveryパッケージの参照が公開版の10.6.0に固定された
差分の中心は、Microsoft.Extensions.ServiceDiscovery のバージョン指定です。変更前は ${MicrosoftExtensionsServiceDiscoveryVersion} というリポジトリ側の変数を参照していましたが、変更後は Version="10.6.0" が直接指定されています。(GitHub)
変更イメージは次のとおりです。
<PackageReference Include="Microsoft.Extensions.ServiceDiscovery" Version="10.6.0" />NuGet Galleryでは、Microsoft.Extensions.ServiceDiscovery 10.6.0 が公開されており、dotnet add package Microsoft.Extensions.ServiceDiscovery --version 10.6.0 や PackageReference での参照例も掲載されています。([NuGet][6])
Service Discoveryは、分散システムやマイクロサービス構成でサービス名からエンドポイントを解決するための仕組みです。NuGetの説明では、HttpClient に AddServiceDiscovery を組み合わせ、構成済みプロバイダーからサービスエンドポイントを解決する用途が示されています。([NuGet][6])
Purview連携アプリで考えると、たとえば次のような構成で関係します。
| 利用シーン | ServiceDiscoveryが関係する可能性 |
|---|---|
| Purview APIを呼び出す社内ポータル | フロントエンドからバックエンドAPIへ接続する構成で使う場合がある |
| データ分類やラベル適用の申請ワークフロー | 複数APIをサービス名で解決する設計なら関係する |
| AIアプリやエージェントのPurview連携 | Aspire構成で複数サービスを組み合わせている場合に確認が必要 |
| ローカル検証環境 | テンプレート作成直後の dotnet restore で失敗する可能性がある |
管理者が確認すべき影響範囲
Microsoft Purview管理者は、今回の更新を「Purview設定変更の依頼」として扱うよりも、「Purview連携アプリの開発・展開基盤に関する確認事項」として扱うのが適切です。
Purviewテナント設定は原則変更不要
今回のPRから読み取れる範囲では、PurviewのDLPポリシー、秘密度ラベル、保持ポリシー、監査、eDiscovery、Data Map、Unified Catalogなどの設定変更は求められていません。PR本文の Customer Impact や Risk などの欄はテンプレート文のまま残っており、具体的なPurview管理機能への影響は記載されていません。(GitHub)
そのため、管理者がすぐに実施すべきことは次の3つです。
| 確認項目 | 対応内容 |
|---|---|
| Purview標準機能だけを利用しているか | 標準機能のみなら、今回の修正で設定変更は不要 |
| Purview API/SDK連携アプリがあるか | 開発チームまたはベンダーに.NET構成を確認する |
| 社内テンプレートやCI/CDに.NET 11 Previewを使っているか | 該当する場合は依存関係と復元テストを実施する |
開発チームに確認すべき質問
管理者が開発チームへ確認する場合は、「今回のPurview更新に対応済みですか」と聞くより、次のように具体化すると話が早くなります。
| 質問 | 確認したい理由 |
|---|---|
| Purview連携アプリでBlazor WebAssemblyを使っていますか | 今回の対象テンプレートに該当する可能性がある |
.NET 11 Preview または release/11.0-preview5 系のSDKを使っていますか | 修正対象のブランチと関係する |
blazor-wasm-servicedefaults テンプレートを使いましたか | 直接影響する可能性が高い |
Microsoft.Extensions.ServiceDiscovery の参照がありますか | 依存関係の確認ポイントになる |
社内NuGetミラーに 10.6.0 が同期されていますか | CI/CDだけ失敗する典型例を避けられる |
開発者向け：確認すべき設定と手順
該当する可能性がある開発者は、まず依存関係を確認します。既存プロジェクト、テンプレートから生成した直後の検証プロジェクト、CI/CDの3か所で確認すると漏れを防げます。
既存プロジェクトのPackageReferenceを確認する
プロジェクト内で Microsoft.Extensions.ServiceDiscovery を検索します。
grep -R "Microsoft.Extensions.ServiceDiscovery" .Windows PowerShellでは次のように確認できます。
Select-String -Path .\* -Pattern "Microsoft.Extensions.ServiceDiscovery" -Recurse.csproj に次のような参照がある場合は、今回の修正内容に沿っています。
<PackageReference Include="Microsoft.Extensions.ServiceDiscovery" Version="10.6.0" />一方で、次のようにプレビュー版や社内変数を経由している場合は、復元できるパッケージか確認が必要です。
<PackageReference Include="Microsoft.Extensions.ServiceDiscovery" Version="10.6.0-preview.1.26210.2" />Central Package Managementを使っている場合
Directory.Packages.props でパッケージバージョンを集中管理している場合は、プロジェクトファイルではなく管理ファイル側を確認します。
<ItemGroup>
<PackageVersion Include="Microsoft.Extensions.ServiceDiscovery" Version="10.6.0" />
</ItemGroup>この場合、個別の .csproj にはバージョンを書かない運用もあります。プロジェクト単位で修正すると、社内のバージョン管理ルールと衝突することがあるため、まずリポジトリのパッケージ管理方針を確認してください。
クリーンな環境でrestoreを実行する
ローカル端末ではキャッシュの影響で成功しても、CI/CDのクリーンエージェントでは失敗することがあります。特に、社内NuGetミラー、プロキシ、閉域ネットワークを使っている環境では、10.6.0 が取得できるかを確認してください。
dotnet restore
dotnet build再現確認用にテンプレートから新規作成する場合は、次の流れで検証します。
dotnet new blazor-wasm-servicedefaults -o servicedefaults-check
cd servicedefaults-check
dotnet restore
dotnet buildNU1102 が出る場合は、生成された .csproj が古い参照を持っている、利用しているSDKやテンプレートが更新前である、またはパッケージソースに該当バージョンが存在しない可能性があります。
移行・展開時に失敗しやすいポイント
今回の更新は小さな差分ですが、社内開発基盤では意外に詰まりやすい種類の変更です。特に、テンプレート、NuGetフィード、ロックファイル、プレビューSDKが絡む環境では注意が必要です。
| 失敗パターン | 起きること | 対応 |
|---|---|---|
| 古いテンプレートから生成している | 10.6.0-preview... のような見つからないパッケージを参照する | SDKまたはテンプレートを更新し、生成物を確認する |
| 社内NuGetミラーに未同期 | ローカルでは成功、CIだけ失敗する | Microsoft.Extensions.ServiceDiscovery 10.6.0 をミラーに同期する |
Directory.Packages.props と .csproj が不整合 | 参照バージョンが二重管理になる | 集中管理ルールに合わせて片方へ寄せる |
| パッケージロックファイルが古い | 復元結果が想定とずれる | ロックファイルを更新し、CIでは再現性を確認する |
| Preview SDKを本番扱いで展開する | 後続Previewで再修正が必要になる | 検証環境と本番環境を分け、変更管理に記録する |
元PR #66698では、この修正が「適切なdarc channelを判断するまでの回避策」と説明され、Preview 5ではこの対応を入れ、Preview 6までに依存関係の流れを直す趣旨のコメントも残されています。つまり、長期的な最終仕様として固定的に見るより、Preview段階の復元問題を回避するための実務的な修正として扱うのが安全です。(GitHub)
また、バックポートPRのマージ時には、変更自体はmainで検証済みとしつつ、Mac環境の一部チェックが利用できない状況だった旨のコメントもあります。macOS開発者を含むチームでは、Windowsだけで確認を終えず、実際に利用するOSごとに dotnet restore と dotnet build を実行しておくと安心です。(GitHub)
Purview連携アプリで確認すべきセキュリティ観点
今回の変更自体は、Purviewのセキュリティポリシーを強化する更新ではありません。それでも、Purview連携アプリは機密データ、ラベル、監査、コンプライアンス制御に関係することが多いため、依存関係の変更を軽く扱うべきではありません。
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| パッケージソース | nuget.orgまたは承認済み社内フィードから取得しているか |
| 依存関係レビュー | Microsoft.Extensions.ServiceDiscovery と関連パッケージのバージョン差異がないか |
| SBOM/脆弱性スキャン | パッケージ更新後のスキャン結果に問題がないか |
| 通信先制御 | Service Discoveryで解決されるAPIエンドポイントが想定どおりか |
| 監査証跡 | Purview連携アプリの変更としてチケットやリリースノートに残しているか |
特に、Service Discoveryはサービス名からエンドポイントを解決する仕組みです。構成ミスがあると、ビルドは通っても実行時に別環境のAPIへ接続する、ローカルでは動くが検証環境では解決できない、といった問題が起きます。NuGetの説明でも、構成ベースのエンドポイント解決、HttpClient との連携、appsettings.json などの構成ソースを使う仕組みが示されています。([NuGet][6])
エラーが出たときの切り分け
開発環境やCI/CDで失敗した場合は、Purviewのポリシー設定を疑う前に、.NETのパッケージ復元とテンプレート生成物を確認してください。
| 症状 | 可能性が高い原因 | 最初に見る場所 |
|---|---|---|
NU1102 Unable to find package Microsoft.Extensions.ServiceDiscovery | 公開フィードにないバージョンを参照している | .csproj、Directory.Packages.props |
| ローカルでは成功し、CIで失敗 | 社内NuGetミラーやプロキシが未同期 | nuget.config、CIログ |
| 新規作成したプロジェクトだけ失敗 | 古いSDKまたはテンプレートを使っている | dotnet --list-sdks、テンプレート一覧 |
| ビルド後にAPI接続で失敗 | Service Discoveryの構成不備 | appsettings.json、環境変数、Aspire AppHost |
| Purview API呼び出しだけ失敗 | 認証・権限・Graph API側の問題 | Entra IDアプリ登録、APIアクセス許可、トークン |
重要なのは、NU1102 はPurviewの権限不足やDLPブロックではなく、NuGetパッケージの復元問題として切り分けることです。Purview側のポリシーを緩めても、この種類のエラーは解決しません。
管理者・開発者・DevOpsの役割分担
今回のような更新は、誰か一人が対応するより、役割ごとに確認範囲を分けると早く片付きます。
| 役割 | やること |
|---|---|
| Microsoft Purview管理者 | Purview本体の設定変更が不要であることを確認し、連携アプリの有無を棚卸しする |
| アプリ開発者 | .csproj、Directory.Packages.props、dotnet restore の結果を確認する |
| DevOps担当 | CI/CD、社内NuGetミラー、テンプレート、ロックファイルを更新する |
| セキュリティ担当 | パッケージ取得元、SBOM、脆弱性スキャン、変更記録を確認する |
| ベンダー管理担当 | 外部委託しているPurview連携アプリが該当テンプレートを使っていないか確認する |
実務では、Purview管理者が「自分には関係ない」と判断して終わるのではなく、社内にPurview連携アプリがあるかどうかを確認するところまで行うと安全です。特に、AIアプリ、データ分類ポータル、ラベル適用支援ツール、監査レポート自動化ツールを内製している組織では、開発チームへ確認を回す価値があります。
今回の更新で次に取るべき行動
今回のMicrosoft Purview documentation updateは、Purviewの管理画面やセキュリティポリシーを直接変更するものではなく、.NET 11 Preview 5のBlazor WebAssembly Service Defaultsテンプレートに関する依存関係修正です。管理者はPurviewテナント設定を急いで変更する必要はありませんが、Purview APIやSDKと連携する社内アプリがある場合は、開発・DevOpsチームに確認を依頼してください。
まず行うべきことは、次の3つです。
- Purview連携アプリで
blazor-wasm-servicedefaultsや .NET 11 Previewを使っているか確認する Microsoft.Extensions.ServiceDiscoveryの参照が10.6.0など復元可能な公開パッケージになっているか確認する- ローカル端末だけでなく、CI/CDのクリーン環境でも
dotnet restoreとdotnet buildを実行する
この更新をPurview本体のセキュリティ変更と誤解せず、Purview連携アプリの依存関係と展開基盤を点検するきっかけとして扱うのが、最も実務的な対応です。
[6]: https://www.nuget.org/packages/Microsoft.Extensions.ServiceDiscovery/10.6.0 “
NuGet Gallery
| Microsoft.Extensions.ServiceDiscovery 10.6.0
“
コメント