Windowsアプリ配布方式の選び方 - MSI/MSIX/ClickOnce/xcopy/独自更新
· 小村 豪 · Windows, 配布, MSI, MSIX, ClickOnce, xcopy, updater
日英シート付きの Excel 判断ワークシートをダウンロード
Windows アプリの配布方式を決める場面では、つい「どれが新しいか」「どれが簡単か」で話を始めがちです。 ただ、実務で本当に効くのは別の軸です。
- 利用者単位で入れたいのか、マシン全体へ入れたいのか
- 更新を配布基盤に任せたいのか、自前で持ちたいのか
- サービス / ドライバ / shell extension / COM 登録のような OS 統合があるのか
- 閉域・オフライン・USB 配布に耐える必要があるのか
- package identity が要るのか、それとも素の Win32 として unrestricted に動かしたいのか
配布方式の選択は、インストーラ形式の好み ではなく、OS にどこまで触るか と 更新責任を誰が持つか の選択です。
1. まず結論
かなり雑に、でも実務で使いやすく言うとこうです。
- マシン全体へ入れる、サービスや COM 登録、前提物の導入がある なら、まずは MSI を起点に考えます
- Windows 10/11 前提で、clean install / clean uninstall、頻繁な更新、package identity が欲しい なら、MSIX が有力です
- .NET の社内向けデスクトップアプリを、利用者単位で簡単に配って自動更新したい なら、ClickOnce は今でもかなり強いです
- 置くだけで動くツール、閉域、USB 配布、管理者権限なし を優先するなら、xcopy がいちばん素直です
- 更新 UX、チャネル、段階配信、telemetry、復旧戦略まで自分たちで握りたい なら、独自 updater です
- ドライバが必要 なら、最初から MSIX 中心で考えないほうが安全です
- Explorer の in-process shell extension が必要 なら、MSIX で対応可能な範囲と OS バージョン条件を先に確認します
乱暴にまとめると、こうなります。
- OS への登録が濃い → MSI 寄り
- package identity と modern packaging を取りたい → MSIX
- per-user の簡単配布と built-in 更新が欲しい → ClickOnce
- 置くだけ配布が最優先 → xcopy
- 更新基盤を自社で設計・運用する覚悟がある → 独自 updater
2. 5 つは同じ土俵ではない
ここはかなり大事です。
MSI / MSIX / ClickOnce / xcopy は、主に どう入れるか の話です。 一方で 独自 updater は、主に どう更新責任を持つか の話です。
つまり実務では、2 層に分けて考えたほうが整理しやすいです。
| 層 | 主な候補 | 決めること |
|---|---|---|
| 初回導入 | MSI / MSIX / ClickOnce / xcopy | どこへ配置するか、何を登録するか、権限、アンインストール |
| 継続更新 | MSIX App Installer / ClickOnce / 手動差し替え / 独自 updater | 更新確認、配信元、署名検証、rollback、チャネル、UI |
なので、独自 updater は最初に選ぶものではなく、既存の配布方式で足りない更新要件があるときに追加で選ぶもの だと思ったほうがぶれません。
3. 一枚で見る判断表
まずは、いちばん使いやすい判断表を置きます。
| 状況 | まず選ぶもの | 理由 |
|---|---|---|
| 全ユーザー向けで、サービス、COM 登録、machine-wide な設定がある | MSI | Windows Installer の土俵に素直に乗るほうが事故が少ない |
| Windows 10/11 前提で、clean install / uninstall、頻繁な更新、package identity が欲しい | MSIX | modern packaging と update モデルに寄せやすい |
| .NET の社内業務アプリを per-user で簡単配布したい | ClickOnce | built-in の更新モデルが使いやすい |
| 置くだけで動くツール、閉域、USB、管理者権限なし | xcopy | install という概念をできるだけ持ち込まない |
| 商用製品で、更新 UX やチャネルを自分たちで握りたい | 独自 updater | built-in 更新より自由度が高い |
| ドライバが必要 | MSI か専用 installer 寄り | driver package は別問題で、MSIX は不向き |
| in-process shell extension が必要 | MSI か専用 installer 寄り | Windows 11 21H2 以降では MSIX で legacy context menu handler などを登録できるが、条件確認が必要 |
この表でいちばん大事なのは、「更新がある」だけで独自 updater に飛ばない ことです。
4. 観点別の比較
| 観点 | MSI | MSIX | ClickOnce | xcopy | 独自 updater |
|---|---|---|---|---|---|
| per-user 導入のしやすさ | ○ | ○ | ◎ | ◎ | ○ |
| per-machine 導入のしやすさ | ◎ | ○ | △ | × | ○ |
| built-in 更新 | △ | ◎ | ◎ | × | ◎ |
| package identity | × | ◎ | × | × | × |
| サービスとの相性 | ◎ | △ | × | × | ○ |
| ドライバとの相性 | △ | × | × | × | ○ |
| shell extension との相性 | ◎ | △ | × | × | ○ |
| 閉域・オフライン配布 | ◎ | ○ | ○ | ◎ | ◎ |
| 実装・運用コスト | ○ | ○ | ◎ | ◎ | × |
| 更新 UX の自由度 | △ | ○ | △ | × | ◎ |
この表で見るべきなのは、何が最強か ではなく、何がいちばん摩擦が少ないか です。
5. それぞれ、どういう案件に向くか
5.1 MSI
MSI は、Windows の伝統的なデスクトップアプリを、きちんと install / uninstall / repair したい ときの基準点です。
特に向いているのは、こういう案件です。
- 全ユーザー向けの業務アプリ
- Windows サービスを含むアプリ
- COM 登録、file association、machine-wide な設定を伴うアプリ
- 既存の installer 運用がすでにある製品
MSI の強みは、「アプリを OS にどう入れたか」を Windows の流儀で表現しやすい ことです。
一方で、弱いところもはっきりしています。
- authoring が地味に難しい
- upgrade / patch を雑に設計すると後で苦しみやすい
- custom action を増やすほど壊れやすい
- 高頻度更新の製品では更新 UX が重くなりやすい
5.2 MSIX
MSIX は、modern packaging と clean update / uninstall を取りたい 選択です。package identity が必要な Windows 機能を使いたいときにも意味が大きくなります。
向いているのはこのあたりです。
- Windows 10/11 を前提にできるデスクトップアプリ
- 更新頻度が高めの業務アプリ
- package identity が効く Windows 機能を使いたいアプリ
- Intune や App Installer に寄せたい案件
MSIX の強みは、更新とアンインストールのきれいさ です。
ただし、何でも入るわけではありません。特にこの 4 点は最初に確認したほうが安全です。
- in-process shell extension（Windows 11 21H2 以降の MSIX では legacy context menu handler などを登録できるが、マニフェスト宣言と対象 OS の確認が必要）
- driver
- unrestricted な古い Win32 前提
- package identity を取りたくない構成
5.3 ClickOnce
ClickOnce は、.NET の社内向けデスクトップアプリを、per-user で、素早く、更新込みで回したい ときに今でもかなり強いです。
向いているのは、こんな場面です。
- 社内向けの業務アプリ
- 標準ユーザーで導入したい
- 利用者単位での配布で十分
- 更新 UX をそこまで作り込みたくない
逆に、OS へ深く触るタイプの製品や、複数前提物を束ねる installer 的な役割まで期待しないほうが安全です。
5.4 xcopy
xcopy は、install ではなく deploy です。レジストリ登録も、修復機能も、package identity もありません。その代わり、置くだけで済む なら最強クラスに単純です。
持ち味が出るのは、こういうツール類です。
- 診断ツール
- 装置設定ツール
- ログ収集ツール
- 現場へ USB で渡すユーティリティ
- side-by-side で複数版を共存させたいケース
xcopy の強みは、失敗の仕方が分かりやすい ことです。フォルダごと差し替える、戻したければ前の版へ戻す、という運用がしやすいです。
ただし当然、弱い面もあります。
- Start menu / ARP / repair
- file association / service / shell extension / driver
- built-in 更新
5.5 独自 updater
独自 updater は、自由度の選択 というより 責任の選択 です。
検討する価値が出るのは、こういう要件があるときです。
- 更新頻度が高い
- stable / beta / preview のようなチャネルを持ちたい
- 段階配信やロールアウト率を制御したい
- 背景ダウンロード、通知、メンテナンス時間帯を細かく制御したい
- 更新 telemetry や crash recovery を自前で見たい
強みは大きいですが、支払うものも大きいです。
- 署名検証
- 配信 manifest
- 再試行 / resume
- proxy / firewall / 閉域対応
- rollback
- 壊れた更新の復旧
- updater 自身の更新
つまり、自由度ではなく責任が増える ということです。
6. 迷いやすい論点
6.1 package identity が要るか
もし欲しいのが package identity 前提の Windows 機能なら、MSIX の価値は一気に上がります。
逆に、
- unrestricted な file system access
- unrestricted な registry access
- elevation / process model の自由度
- 古い Win32 前提をそのまま残したい
なら、unpackaged 寄りの方式のほうが自然です。
6.2 サービス / ドライバ / shell extension があるか
この 3 つは、配布方式を一気に重くします。
- driver: MSIX では不向き
- in-process shell extension: MSIX では不向き
- Windows service: MSI は自然、MSIX でも条件付きで比較対象
OS と深く結びつく要素があるほど、見た目が簡単な配布 より 正しく導入・更新・削除できるか が主題になります。
6.3 per-user か per-machine か
ここを曖昧にしたまま進めると、あとで必ず揉めます。
- per-user に寄せたい
- ClickOnce
- xcopy
- 一部の MSIX
- per-machine に寄せたい
- MSI
- 条件が合えば MSIX
「管理者権限なしで入れたい」と「全ユーザーが同じ場所から使いたい」は同じではありません。
6.4 更新頻度と運用責任
更新頻度の感覚で見ると、ざっくりこうです。
- 四半期から月次更新: MSI でも十分回る
- 月次から週次更新: MSIX / ClickOnce がかなり楽
- 週次から日次更新: 独自 updater を検討する理由が出る
- 更新は手動でよい / 配置側が制御する: xcopy でも十分
配布方式は、技術選定 であると同時に 運用設計 でもあります。
6.5 閉域・オフライン配布
閉域では、きれいな auto-update より 単純さ が勝つことが多いです。
- xcopy は強い
- MSI も強い
- ClickOnce も file share や removable media で使える
- MSIX も App Installer の使い方次第で回る
ただし閉域で頻繁に更新するなら、「誰が、どこへ、新版を置き、旧版をどう残すか」まで決めないと、方式だけ選んでも運用が崩れやすいです。
7. 迷ったときに最後に見る 6 問
- そのアプリは current user だけでよいか、machine-wide に入れる必要があるか
- service / driver / shell extension / COM 登録はあるか
- package identity が必要な Windows 機能を使うか
- 標準ユーザーだけで導入したいか
- 更新頻度は月次か、週次か、もっと高いか
- 対象環境は閉域か、OS バージョンはそろっているか
この 6 問に答えるだけで、だいたい着地点が見えます。
- 2 が「はい」 → まず MSI 側から考える
- 3 が「はい」 → MSIX を優先検討
- 1 が current user、4 が「はい」、かつ .NET desktop app → ClickOnce が有力
- 4 が「はい」、2 が「いいえ」、置くだけ運用でよい → xcopy が有力
- 5 が高く、更新 UX を製品価値として握りたい → 独自 updater を比較対象へ入れる
8. まとめ
Windows アプリの配布方式は、次の一文にかなり集約できます。
初回導入をどう成立させるか と 継続更新を誰が責任を持って回すか を分けて決める。
そのうえで、ざっくりした実務判断はこうです。
- MSI: OS へ深く入れる伝統的 desktop app
- MSIX: package identity と modern packaging / update を取りたい app
- ClickOnce: per-user の .NET 業務アプリを簡単に配って更新したい
- xcopy: 置くだけでよい自己完結ツール
- 独自 updater: 更新自体を自社で設計・運用する覚悟がある製品
そして、いちばん大事なのはこれです。
- driver / shell extension / service があるなら、配布方式は最後の見た目ではなく、OS 統合の方式から決まる
- package identity が必要なら、MSIX の意味が大きい
- 独自 updater は最後の切り札であって、最初の選択肢ではない
- 閉域 では、賢さより単純さが勝つことが多い
もし迷っているなら、まずは per-user か per-machine か、OS へ何を登録するか、更新頻度はどのくらいか の 3 つだけでも先に固定すると、話がかなり前に進みます。
9. 参考資料
- Microsoft Learn, Windows Installer
- Microsoft Learn, What is MSIX?
- Microsoft Learn, Packaging overview for Windows apps
- Microsoft Learn, MSIX features and supported platforms
- Microsoft Learn, Support legacy context menus for packaged apps
- Microsoft Learn, App Installer file overview
- Microsoft Learn, Prepare to package a desktop application
- Microsoft Learn, Know your installer
- Microsoft Learn, Convert an installer that includes services
- Microsoft Learn, ClickOnce deployment and security
- Microsoft Learn, Manage updates for a ClickOnce application
- Microsoft Learn, Choosing a ClickOnce deployment strategy
- Microsoft Learn, ClickOnce cache overview
- Microsoft Learn, Windows App SDK deployment guide for self-contained apps
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
Windowsで「Windows によって PC が保護されました」が出る理由
Windowsアプリ配布時にSmartScreen警告が出る理由を、コード署名、EV/OV証明書、Azure Artifact Signing、MSIX、Microsoft Store、ClickOnce、社内配布、App Controlまで実務目線で整理します。
ClickOnce とは何か - 仕組み、更新、向いている場面・向いていない場面を実務目線で整理
.NET の Windows デスクトップアプリ配布で使われる ClickOnce について、マニフェスト、更新、キャッシュ、署名、向いている案件・向いていない案件を Mermaid 図つきで整理します。
自動アップデートのセキュリティ設計 - HTTPSだけでは足りない理由
自動アップデートを信頼境界として扱い、署名付きメタデータ、クライアント側検証、鍵分離、ロールバック対策、fail-closed を実務目線で整理します。
Windowsアプリ 外注・受託開発を依頼する前に整理したいこと
Windowsアプリの外注・受託開発を依頼する前に、既存ソフト改修、装置連携、COM/ActiveX、配布・更新、保守の整理ポイントを解説します。
Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方
Windows で管理者特権が必要になる場面を、UAC、保護領域、サービス、ドライバ、per-user/per-machine 設計の観点から実務向けに整理します。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
Windows アプリの配布では、サービス、ドライバ、WebView2、WinUI、企業内運用まで含めて方式を選ぶ必要があり、実装前の整理が効きます。
技術相談・設計レビュー
MSI / MSIX / ClickOnce / xcopy / 独自 updater は、インストーラの好みではなく更新責任と OS 統合の設計なので、要件の切り分けから見直すと判断しやすくなります。
著者プロフィール
記事の著者プロフィールページです。
小村 豪
合同会社小村ソフト 代表
Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。
公開リンク