パッケージ化の概要

パッケージ化は、アプリのインストール、更新、およびWindowsとの統合方法を定義します。 WinUI 3 アプリは既定でパッケージ化されますが、従来の Win32 アプリケーションなどの多くのデスクトップアプリはパッケージ化されていない状態で実行されます。 パッケージアプリとパッケージ化されていないアプリのどちらを選択するかは、使用できる機能、依存するデプロイモデル、顧客が得る全体的なエクスペリエンスに影響します。

注

新しい WinUI 3 アプリをビルドしますか? 既定で既にパッケージ化されています。以下のガイダンスは、明示的な選択を行う必要がある開発者に最も関連しています。通常は、既存のアプリの移植、エンタープライズコンピューターへのデプロイ、最初にパッケージ化されていないアプリへのWindows機能の追加を行う場合です。

アプリのパッケージ化が重要な理由

パッケージアプリは、クリーンインストールモデル、自動更新、およびバックグラウンドタスク、通知、コンテキストメニュー拡張機能、共有ターゲット、その他の拡張ポイントなど、パッケージ ID を必要とするWindows機能へのアクセスを利用できます。パッケージ化は、Microsoft Storeやエンタープライズ展開ツールなどのチャネルを通じて、よりクリーンな展開、信頼性の高い更新プログラム、合理化された配布を保証するのにも役立ちます。

パッケージ ID が必要な機能

これらのWindows機能は、パッケージIDを持つアプリでのみ機能します。完全なMSIXパッケージングまたは外部ロケーションを用いたスパースパッケージングのいずれかを通じて。

特徴	説明
バックグラウンドタスク	アプリがフォアグラウンドでないときにコードを実行します。たとえば、データの同期、ダウンロードの処理、システムイベントへの応答などです。
Windows AI API (Phi Silica、OCR など)	ローカル言語モデル、テキスト認識、画像分析などのデバイス上の AI 機能にアクセスします。
プッシュ通知 (WNS)	Windows Notification Service を使用して、クラウドサービスからリアルタイム通知を受信します。
共有ターゲット	システム共有シートを使用して、ユーザーが他のアプリのコンテンツを直接自分のアプリに共有できるようにします。
カスタムコンテキストメニュー拡張機能	エクスプローラーやその他のシェルサーフェスの右クリックメニューにアプリのアクションを追加します。
ファイルの種類とプロトコルの関連付け	特定のファイルの種類または URI プロトコル (たとえば、 `yourapp://`) のハンドラーとしてアプリを登録します。
スタートアップタスク	ユーザーがWindowsにサインインすると、アプリが自動的に起動します。
アプリサービス	他のアプリが呼び出すことができるバックグラウンドサービスを公開し、アプリ間通信を有効にします。

ヒント

Windows API を呼び出すときにパッケージ化を解除して E_ILLEGAL_METHOD_CALL または APPMODEL_ERROR_NO_PACKAGE エラーが発生した場合は、それがパッケージ ID の要件です。最も摩擦の少ない修正プログラムとして、外部の場所を使用したパッケージ化 (スパースパッケージ) を参照してください。

詳細については、「パッケージ ID を必要とする機能」を参照してください。

モデルをひとめでパッケージ化する

Model	パッケージ ID	インストーラー	対象となるストア	最適な用途
パッケージ化 (MSIX)	✅ はい	MSIX がインストーラーを置き換える	✅ はい (MSIX 提出)	新しいアプリ, ストアの発行, エンタープライズ MDM
外部の場所を使用したパッケージ化	✅ はい	既存のインストーラー	✅ はい (MSI/EXE 申請)	独自のインストーラーを持つ既存のアプリ、独立系ソフトウェアベンダー (ISV)
梱包されていない	❌ いいえ	MSI または EXE インストーラー (XCopy または Store 以外の配布用スクリプトも)	✅ はい (MSI/EXE の提出 — サイレントインストールのサポートを備えた MSI または EXE インストーラーが必要)	広範な Win32 配布、内部ツール

パッケージアプリ (MSIX)

パッケージ化されたアプリは MSIX を使用し、package ID を持ちます。これは、多くのWindows拡張ポイントに必要です。パッケージ ID を使用すると、Windowsがプラットフォーム API の呼び出し元を確実に識別できるため、これらの機能はそれに依存しています。

パッケージ化されたアプリは、通常、ファイルシステムとレジストリの仮想化を備えた軽量のアプリコンテナーで実行されます (レガシアプリと MSIX AppContainer アプリの AppContainer を参照)。
必要に応じて、アプリコンテナーで実行 しないように アプリを構成することもできます。
MSIX はパッケージ化とインストールの両方に使用されます ( MSIX とはを参照してください)。

外部の場所を使用したパッケージ化 (スパースパッケージ)

外部の場所 ( スパースパッケージとも呼ばれます) を使用してパッケージ化すると、インストーラー、バイナリの場所、または更新プロセスを変更することなく、既存のアプリと共に小さな ID パッケージを登録できます。 Windows 10 バージョン 2004 (ビルド 19041) で導入されました。

これは、独自のインストーラー (NSIS、WiX、InstallShield など) を介して出荷され、MSIX に置き換えたくない既存の Win32/WPF/WinForms アプリのスイートスポットです。軽量 ID パッケージを登録すると、バイナリは現在の場所に留まり、パッケージ ID によって制限されている Windows の機能をすべて利用できるようになります。

能力	MSIX	外部の場所
インストーラーを置き換えます	はい	いいえ
パッケージ内のバイナリ	はい	いいえ (外部)
対象となるストア	はい (MSIX 提出)	はい (MSI/EXE 申請)
パッケージ ID	はい	はい
更新メカニズム	MSIX の更新	既存のメカニズム

→完全なチュートリアル: 外部の場所でパッケージ化してパッケージ ID を付与する

パッケージ化されていないアプリ

パッケージ化されていないアプリは MSIX を使用せず、 パッケージ ID も持っていません。つまり、上記の機能にアクセスできません。

これらは、API サーフェス、ファイルシステムへのアクセス、レジストリへのアクセス、管理者権限の昇格、およびプロセスモデルに関して、全く制限されていません。
インストールと更新は、 .exe、 .msi、カスタムインストーラー、ClickOnce、または xcopy 配置に依存します。

パッケージ化解除にコミットする前に、上記の機能の表をロードマップと照らして確認してください。通知、バックグラウンドタスク、または AI API が提供される場合は、パッケージ化の開始を検討してください。

シナリオ別に選択する

シナリオ	推奨されるモデル	詳細情報
Indie 開発者が Microsoft Store に発行する	パッケージ化 (MSIX) をお勧めします	MSIX は推奨パスであり、ストアで管理される更新プログラム、差分ダウンロード、クリーンアンインストールを有効にします。 WinUI 3 アプリは既定でパッケージ化されています。コード署名はストアによって無料で処理されます。パッケージアプリの配布→ 既存の MSI または EXE インストーラーを使用する Win32 アプリは、MSI/EXE 申請パスを介してストアに発行することもできますが、ストアは既存のユーザーに更新プログラムをプッシュしません。更新プログラムはアプリまたはインストーラーで処理する必要があります。
Intune または Configuration Manager 経由で展開されたエンタープライズアプリ	既存のインストーラー用のパッケージまたは外部の場所	新しいアプリでは MSIX を使用する必要があります。独自のインストーラーを持つ既存のアプリでは、外部の場所でパッケージ化を使用できます。 Code signing:自己署名証明書 (Intune、グループポリシー、またはConfiguration Managerによって信頼された) またはAzure Artifact Signing (旧Trusted Signing)を使用します。パッケージアプリの展開→
独自のインストーラーを使用して直接ダウンロードを出荷する ISV	外部の場所でのパッケージ化	既存のインストーラーと共に軽量 ID パッケージを登録します。コード署名: ストア以外の配布には、CA 信頼証明書が必要です。 Azure アーティファクト署名 (以前の信頼できる署名) は、推奨される低コストオプションです。 → パッケージ ID の付与または、 MSI/EXE 送信パスを使用して、既存のインストーラーをストアに送信します。
内部ツールまたは開発者ユーティリティ	Unpackaged	ビルドとデプロイが最も簡単です。 Windows アプリ SDKは NuGet 経由で動作しますが、一部の機能は使用できません。

ヒント

コード署名コストがわからない場合 Microsoft Storeを使用してMSIX パッケージを発行すると、Microsoft がパッケージに再署名するため、エンドユーザーの信頼のための証明書を個別に取得または管理する必要はありません。ストアを介して Win32 MSI/EXE インストーラーを発行するには、Microsoft信頼されたルートプログラム; の CA への証明書チェーンが必要です。自己署名は受け付けできません。他の配布パスの場合、署名方法は展開コンテキストに依存します。エンタープライズ環境ではデバイス管理を通じて自己署名証明書を信頼できますが、より広範な非ストア配布には通常、CA で信頼されたコード署名ソリューションが必要です。 Azure成果物署名 (以前の信頼された署名) は、ハードウェアトークンを必要とせず、Microsoftの推奨オプション (pricing を参照) です。

フレームワークに依存するデプロイと自己完結型のデプロイ

パッケージ化モデルとは別に、Windows アプリ SDKを使用するアプリは、ランタイムの依存関係を伝達する方法を選択します。

フレームワークに依存する: その Windows アプリ SDK ランタイムをユーザーのPCにインストールする必要があります。アプリのフットプリントが小さいのは、ランタイムが存在するか自動インストールされることに依存しているためです。
自己完結型: すべてのWindows アプリ SDK バイナリはアプリに付属しています。より大きなフットプリント。外部ランタイムの要件はありません。ロックダウンされたエンタープライズ環境に適しています。

→自己完結型アプリをデプロイする

MSIX を使用して始めましょう

Win32 デスクトップアプリ (classic デスクトップアプリ とも呼ばれます) または.NET アプリ (Windows Presentation Foundation (WPF) や Windows フォーム (WinForms) など) をビルドする場合は、MSIX を使用してアプリをパッケージ化して展開できます。

その他のインストールテクノロジ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-21