2026年4月30日の公式更新「Fix false claim: app notifications do not require package identity」を確認するうえで、最初に押さえるべき結論は明確です。これはMicrosoft Entra IDそのものの認証仕様変更ではなく、Windows App SDKの通知機能に関する公式ドキュメントの誤った説明を修正した更新です。Microsoft Entra IDはAzure ADの新名称であり、既存のログインURL、API、PowerShellコマンドレット、MSALなどは名称変更後も継続利用できます。今回の論点は「Microsoft Entraのアプリ登録」と「Windowsアプリのpackage identity」を混同しないことです。(Microsoft Learn)
特に重要なのは、AppNotificationManagerを使うapp notificationsについて、「package identityが必須」と一律に判断しないことです。Microsoftの更新では、WPF、WinForms、WinApp CLI、AI Build関連ドキュメントから、通知にはpackage identityが必要と読める記述が削除・修正されました。一方で、プッシュ通知、バックグラウンド配信、COM activation、PFN mapping、Microsoft Entraのアプリ登録は別の確認ポイントとして残ります。(GitHub)
公式更新で何が変わったか
今回のコミットは、MicrosoftDocsのwindows-dev-docsリポジトリに対するドキュメント修正です。対象はMicrosoft Entra IDの管理画面そのものではなく、Windows App SDKを使うWindowsアプリ開発者向けドキュメントです。
修正の中心は、次の誤解を取り除くことです。
app notificationsを使うには、必ずpackage identityが必要である
公式更新では、Windows App SDK AppNotificationManager supports both packaged and unpackaged appsという趣旨が示され、WPF/WinFormsの移行ドキュメントやWinApp CLIの説明から、通知をpackage identity必須機能の例として扱う記述が削除されました。AI Build関連ページでも、通知を追加する前にwinapp create-debug-identityでdebug identityを作る手順が削除されています。(GitHub)
この変更を、単に「通知はすべてpackage identity不要になった」と読むのは危険です。正しくは、ローカルのapp notificationsと、クラウド経由のpush notificationsを分けて判断する必要があります。
package identityとMicrosoft Entraのアプリ登録は別物
セキュリティ管理者やコンプライアンス担当が混同しやすいのが、次の2つです。
| 項目 | 主な役割 | 今回の確認ポイント |
|---|---|---|
| package identity | WindowsアプリがMSIXなどのパッケージとして実行時IDを持つ状態 | app notificationsで必須とは限らない |
| Microsoft Entraのアプリ登録 | アプリとMicrosoft IDプラットフォームの信頼関係を作る設定 | push notificationsやトークン取得で必要になる場合がある |
| PFN mapping | パッケージ化されたWindowsアプリのPackage Family NameとAzure AppIdを関連付ける手続き | packaged push notificationsでは事前計画が必要 |
| client secret / certificate | アクセストークン取得などで使う資格情報 | 管理・ローテーション・保管方法を監査対象にする |
Microsoft Entraのアプリ登録は、アプリとMicrosoft IDプラットフォームの信頼関係を確立するための設定です。アプリ登録時にはサポートされるアカウント種別を選択し、単一テナント、マルチテナント、個人Microsoftアカウント対応などを用途に応じて決めます。(Microsoft Learn)
一方、package identityはWindowsアプリのパッケージングや実行時の識別に関わる概念です。つまり、Microsoft Entra IDでアプリ登録しているからといって、そのアプリがWindows上でpackage identityを持つわけではありません。逆に、MSIXでパッケージ化していても、Microsoft Entraのアプリ登録が不要なローカル通知シナリオもあります。
通知の種類別に確認すべき仕様
今回の更新後は、「通知」という言葉だけで判断せず、どの通知方式を使っているかを切り分けることが重要です。
| 通知の種類 | 代表的な用途 | package identityの考え方 | Microsoft Entra側の確認 |
|---|---|---|---|
| ローカルapp notifications | アプリ内処理の完了、保存完了、リマインダー表示 | AppNotificationManagerはpackaged/unpackagedの両方で利用対象 | 通常はアプリ登録そのものが主論点ではない |
| push notifications | クラウドサービスからWindowsアプリへ通知 | truly unpackagedも限定的に対応するが、本番で多いバックグラウンド配信やCOM activationではpackage identityが必要 | Azure account、アプリ登録、AppId、ObjectId、secretを確認 |
| バックグラウンド配信 | アプリが起動していない状態での受信・処理 | package identityが必要になるケースがある | PFN mappingとAppIdの整合性を確認 |
| Microsoft Store向けMSIX配布 | Store配布、企業内配布、サイドロード | MSIXベースの提出ではMSIX packagingが関係する | Entra設定とは別に配布方式を確認 |
Microsoft Learnの通知概要では、WinUI 3やWindows App SDKの新規開発にはAppNotificationManagerが推奨され、WPF、WinForms、unpackaged Win32でもAppNotificationManager via NuGetが示されています。また、比較表ではAppNotificationManagerのpackage identity requirementが「No」と整理されています。(Microsoft Learn)
ただし、push notificationsでは話が変わります。Windows App SDKのpush notificationsはAzure App Registration identitiesを使い、Azure資格情報がWNS Channel URIの要求やアクセストークン取得で必要になります。さらに、packagedアプリではPFNとAzure AppIdのmappingが必要で、処理にはリードタイムを見込む必要があります。(Microsoft Learn)
セキュリティ管理者が最優先で確認すべき点
Microsoft Entraのアプリ登録が不要になったわけではない
今回の更新は「app notificationsにpackage identityが必須という説明は誤り」という修正であり、「push notificationsでMicrosoft Entraのアプリ登録が不要になる」という意味ではありません。
push notificationsを使う場合は、Microsoft Entra側で次の情報を正確に管理する必要があります。
| 確認項目 | 見るべき場所 | 確認内容 |
|---|---|---|
| Application ID / Client ID | アプリ登録の概要 | コード、COM activation、PFN mappingで参照するIDと一致しているか |
| Directory / Tenant ID | アプリ登録の概要 | トークン要求先のテナントと運用テナントが一致しているか |
| Object ID | Enterprise application側 | Channel URI要求で使うObject IDを誤っていないか |
| Supported account types | アプリ登録作成時の設定 | マルチテナントが本当に必要か、社内アプリなのに広く開きすぎていないか |
| Client secret / certificate | Certificates & secrets | 有効期限、保管場所、ローテーション、不要な資格情報の有無を確認 |
Windows App SDKのpush通知クイックスタートでは、Azure AppId、TenantId、ObjectIdの記録やclient secretの作成が手順に含まれます。secretは作成直後しか表示されないため、安全な保管が前提です。(Microsoft Learn)
client secretの扱いを監査する
Microsoftのセキュリティベストプラクティスでは、可能な場合はマネージドIDを使い、できない場合は証明書資格情報を検討し、password credentials、つまりclient secretは誤管理や漏えいのリスクがあるため避けるべきとされています。また、使われていない資格情報や期限切れ間近の資格情報を定期的に見直すことも推奨されています。(Microsoft Learn)
実務では、次のような状態が危険です。
- 開発用secretを本番アプリ登録に残している
- GitHub ActionsやAzure DevOpsの変数に長期secretを保存している
- 複数アプリで同じsecretを使い回している
- 退職者や外部委託先が作成したアプリ登録の所有者が残っている
- desktop appなのに不要なclient secretが設定されている
特にデスクトップアプリやモバイルアプリのようなpublic client用途では、アプリケーションオブジェクトに資格情報を持たせないことがベストプラクティスとして示されています。今回の更新をきっかけに、通知機能の仕様確認だけでなく、アプリ登録の棚卸しまで進めるべきです。(Microsoft Learn)
開発・運用チームが行うべき確認手順
まず通知機能を棚卸しする
最初に、対象アプリがどの通知を使っているかを分類します。
| 質問 | 判断基準 | 次のアクション |
|---|---|---|
| 通知はアプリ内処理から直接表示するだけか | 保存完了、処理完了などローカルイベントが起点 | AppNotificationManagerでunpackaged実行を検証 |
| クラウドから端末へ通知するか | サーバー側からWNS経由で送信 | Microsoft Entraアプリ登録とWNS設定を確認 |
| アプリ未起動時にも受信・処理したいか | バックグラウンド配信、COM activationが必要 | package identity、PFN mapping、manifest設定を確認 |
| Store配布やMSIX配布が前提か | Microsoft Store、社内MSIX、サイドロード | 配布方式とpackage identity要件を別途確認 |
| 管理者権限で実行しているか | elevated appとして起動する業務アプリ | 通知が表示されない可能性をテスト |
Windows App SDKのapp notificationsは、管理者権限で実行されているアプリではサポートされない制限があります。業務アプリでは「管理者として実行」が運用手順に含まれていることがあるため、通知が出ない原因をpackage identity不足と誤診しないように注意が必要です。(Microsoft Learn)
次にコードとドキュメントの古い前提を直す
古い社内手順書や設計書に、次のような記述があれば修正対象です。
| 古い記述例 | 修正後の考え方 |
|---|---|
| Windows通知を使うにはMSIX化が必須 | ローカルapp notificationsとpush notificationsを分けて判断する |
AppNotificationManagerはpackage identityなしでは例外になる | 最新ドキュメントでは一律の例外前提ではない |
| 通知対応のために必ずdebug identityを作る | ローカル通知だけなら不要な場合がある |
| Store配布には必ずpackage化が必要 | MSIXベースの提出とMSI/EXE提出を分けて考える |
| Entraアプリ登録があればWindows側のpackage identityもある | Entraのアプリ登録とWindowsのpackage identityは別概念 |
今回のコミットでは、Microsoft Store配布に関する説明も補足されました。StoreはMSI/EXE提出も受け付けるため、「Store distributionにはpackagingが必要」と一律に表現するのは不正確であり、MSIXベースの提出に限定する形へ修正されています。(GitHub)
移行準備で見るべき実務ポイント
WPF/WinFormsの既存アプリは「MSIX化ありき」で進めない
WPFやWinFormsの既存アプリで通知機能を追加する場合、今回の更新前の情報だけを見ていると、不要なMSIX化やpackaged app with external locationへの移行を計画してしまう可能性があります。
WPFアプリの公式手順では、unpackagedアプリがWindows App SDKを使う場合にRuntimeの依存関係やWindowsPackageTypeの設定を確認する流れが示されています。package identityが必要かどうかとは別に、Windows App SDK Runtimeの初期化やNuGetパッケージのバージョン整合性は確認が必要です。(Microsoft Learn)
判断の目安は次の通りです。
| アプリの状態 | 推奨される進め方 |
|---|---|
| 既存のWPF/WinFormsでローカル通知だけ追加したい | まずunpackagedのままAppNotificationManagerで検証する |
| 未起動時のpush受信やCOM activationが必要 | package identity、manifest、PFN mappingを含めて設計する |
| Store配布を予定している | MSIX、MSI/EXE、企業内配布のどれを使うかを先に決める |
| セキュリティレビュー対象の業務アプリ | Entraアプリ登録、secret、所有者、権限、監査ログを同時に確認する |
push notificationsではPFN mappingのリードタイムを入れる
packagedアプリでpush notificationsを使う場合、PFNとAzure AppIdのmappingが必要です。公式手順では、mapping requestはメールで提出し、週次で処理されると説明されています。リリース直前に気づくと、検証や本番切り替えのスケジュールに影響します。(Microsoft Learn)
また、WNS Channel URIは30日で期限切れになるため、古いURIを固定的に保存して使い続ける設計は避けるべきです。起動時に新しいURIを要求し、バックエンドに保存済みのURIと異なる場合は更新する設計にしておくと、通知不達の原因を減らせます。(Microsoft Learn)
コンプライアンス担当が確認すべき監査観点
今回の更新は小さなドキュメント修正に見えますが、監査観点では「誤った前提に基づく過剰設定」と「必要なID管理の見落とし」の両方を防ぐきっかけになります。
| 監査観点 | 確認内容 | リスク |
|---|---|---|
| 最小権限 | 通知のためだけに不要なEntra権限を付けていないか | 不要な同意、過剰なAPI権限 |
| 資格情報管理 | secretの期限、保管先、所有者、ローテーション手順があるか | secret漏えい、期限切れ障害 |
| テナント範囲 | マルチテナント設定が本当に必要か | 外部テナントからの利用リスク |
| 所有者管理 | アプリ登録のownerが適切か | 退職者・委託先依存 |
| 変更管理 | ドキュメント更新に伴い設計書・手順書を更新したか | 古い手順による誤実装 |
| 配布方式 | MSIX、MSI/EXE、Store、社内配布の前提が明確か | リリース遅延、PFN mapping漏れ |
Microsoftのベストプラクティスでは、アプリの誤構成は停止や侵害につながる可能性があり、アプリのセキュリティと健全性を定期的に評価することが重要とされています。今回のような公式ドキュメント更新は、設計書やリスク評価表を見直す良いタイミングです。(Microsoft Learn)
よくある誤解と失敗しやすいポイント
「通知はpackage identity不要」と雑に一般化する
今回の修正で分かるのは、AppNotificationManagerによるapp notificationsをpackage identity必須と断定するのは誤り、という点です。push notifications、バックグラウンド配信、COM activationまで含めてすべて不要と判断してはいけません。
古いToastNotificationManagerの記事をそのまま使う
検索で見つかる古いサンプルには、Windows.UI.Notifications名前空間のToastNotificationManagerを使うものがあります。Microsoft Learnでは、新しいWindows App SDKアプリではAppNotificationManagerを使うことが推奨されています。既存サンプルを流用する場合は、対象APIとアプリ種別を必ず確認してください。(Microsoft Learn)
Entraのアプリ登録を「WindowsパッケージID」と同じものとして扱う
Microsoft Entraのアプリ登録は、Microsoft IDプラットフォームとの信頼関係を作る設定です。Windowsのpackage identityは、アプリがWindows上でパッケージとして識別される状態です。名称に「identity」が含まれるため混同しがちですが、設計書では必ず分けて記載しましょう。
リリース直前にPFN mappingへ気づく
push notificationsをpackagedアプリで使う場合、PFN mappingの手続きが必要になることがあります。開発完了後に初めて気づくと、リリース日程に影響します。通知機能を要件定義に入れた段階で、Entraアプリ登録、PFN、AppId、ObjectId、secret、manifestをセットで確認してください。
まとめ：今回の更新後に取るべき行動
今回のMicrosoftDocs公式更新は、Microsoft Entra IDの認証仕様変更ではなく、Windows App SDKのapp notificationsとpackage identityに関する説明の誤りを直すものです。実務では、次の順番で確認すると迷いません。
まず、対象アプリの通知がローカルapp notificationsなのか、クラウド経由のpush notificationsなのかを分類します。次に、package identityが必要な機能を使っているかを確認します。そのうえで、Microsoft Entraのアプリ登録、client secret、PFN mapping、テナント範囲、所有者、社内手順書を見直します。
セキュリティ管理者、コンプライアンス担当、エンタープライズIT担当にとって重要なのは、「package identity不要」という一文に飛びつくことではありません。通知方式、配布方式、Microsoft EntraのID管理を分けて整理し、不要な移行を避けつつ、必要な認証・資格情報管理を確実に押さえることです。
コメント