Windowsアプリ配布方式の選び方 - MSI/MSIX/ClickOnce/xcopy/独自更新

日英シート付きの Excel 判断ワークシートをダウンロード

Windows アプリの配布方式を決める場面では、つい「どれが新しいか」「どれが簡単か」で話を始めがちです。 ただ、実務で本当に効くのは別の軸です。

• 利用者単位で入れたいのか、マシン全体へ入れたいのか
• 更新を配布基盤に任せたいのか、自前で持ちたいのか
• サービス / ドライバ / shell extension / COM 登録のような OS 統合があるのか
• 閉域・オフライン・USB 配布に耐える必要があるのか
• package identity が要るのか、それとも素の Win32 として unrestricted に動かしたいのか

配布方式の選択は、インストーラ形式の好み ではなく、OS にどこまで触るか と 更新責任を誰が持つか の選択です。

この記事は、Windows デスクトップアプリを作っていて、配布方式をこれから決める、あるいは今の方式を見直したい 開発者と、その運用を引き取る情報システム担当者に向けて書いています。特定の言語やフレームワークは前提にしていません。英語のまま流通している用語が多い分野なので、それらは 1.1 にまとめました。冒頭のワークシートの中身は 1.2 に要約してあります。

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 バージョン条件を先に確認します

乱暴にまとめると、こうなります。

1. OS への登録が濃い → MSI 寄り
2. package identity と modern packaging を取りたい → MSIX
3. per-user の簡単配布と built-in 更新が欲しい → ClickOnce
4. 置くだけ配布が最優先 → xcopy
5. 更新基盤を自社で設計・運用する覚悟がある → 独自 updater

1.1 本文で出てくる用語

配布まわりは英語のまま流通している用語が多いので、先に並べておきます。

1.2 冒頭のワークシートに何が入っているか

先頭に置いた Excel ワークシートは、この記事の判断を 自分の案件に当てはめて記録するため のものです。日本語版と英語版があり、それぞれ 2 シート構成です。

Planner シート は 3 つのブロックに分かれています。

1. 入力シート: 次の 7 項目を埋めると、第一候補と理由を書き残せる形になっています
   • 配布スコープ … per-user / per-machine / 両方 / 未定
   • OS 統合要素 … なし / サービス / ドライバ / shell extension / COM 登録 / 複数
   • package identity … 必要 / 不要 / 判断できない
   • 標準ユーザー導入要件 … 必須 / 不要 / 条件による
   • 更新頻度 … 手動または稀 / 月次 / 週次 / それ以上
   • 対象環境 … 閉域・オフライン / 管理された新しい Windows / 旧世代混在の Windows / USB・現場
   • アプリ種別メモ … 社内 .NET デスクトップ / 商用製品 / ユーティリティ / 混在
2. 候補の見分け方: 5 方式それぞれの「まず強く見る条件」と「先に外しやすい条件」
3. 判断の流れ: 上の項目をどの順で見て、その結果どの方式へ寄りやすいか

Reference シート は、この記事の 3 章の判断表と 4 章の比較表をそのまま持ったものです。

つまり、記事の 3 章・4 章・7 章を、案件ごとに記入できる形にしたものです。読むだけで結論が出るならダウンロードは不要です。複数案件を比べたい、社内で判断の根拠を残したい、というときに使ってください。

この記事の知識マップ

Windowsアプリの配布方式は、インストーラー形式の好みではなく、OS統合の濃さと更新責任をどちらが持つかという2つの軸で選ばれます。MSIはWindowsサービスやCOM登録、ドライバーやシェル拡張のようにOSへ深く触る導入に向く一方でpackage identityは持たず、MSIXはpackage identityを実装しclean installと更新のきれいさを提供しますが、ドライバーやシェル拡張には基本的に向きません。ClickOnceは.NETアプリをper-userで簡単に配布・自動更新できますがWindowsサービスを含む製品には向かず、xcopy配布は置くだけで動く単純さが強みの代わりにpackage identityやサービスとの相性を持ちません。独自updaterは署名検証やコード署名証明書の管理までを自前で担う代わりに、更新の自由度と閉域配布への対応力を得る選択です。

flowchart LR
    accTitle: Windowsアプリ配布方式の知識マップ
    accDescr: MSI・MSIX・ClickOnce・xcopy・独自updaterがOS統合の濃さと更新責任の持ち方という2つの軸でどう使い分けられるかを示す図。
    msi["MSI(Windows Installer)"]
    msix["MSIX"]
    clickonce["ClickOnce"]
    windows_service["Windowsサービス"]
    driver_package["ドライバーパッケージ"]
    shell_extension["シェル拡張(エクスプローラー拡張)"]
    com["COM(コンポーネントオブジェクトモデル)"]
    closed_network["閉域ネットワーク"]
    package_identity["package identity"]
    code_signing_cert["コード署名証明書"]
    dotnet[".NET(Core以降)"]
    xcopy_deployment["xcopy配布"]
    custom_updater["独自updater"]
    msi -->|"推奨される対応"| windows_service
    msi -->|"推奨される対応"| driver_package
    msi -->|"推奨される対応"| shell_extension
    msi -.->|"利用する"| com
    msi -->|"推奨される対応"| closed_network
    msix -->|"実装を担う"| package_identity
    msix -->|"用いるのは非推奨"| driver_package
    msix -.->|"用いるのは非推奨"| shell_extension
    msix -.->|"推奨される対応"| closed_network
    msix -->|"前提とする"| code_signing_cert
    clickonce -.->|"前提とする"| dotnet
    clickonce -.->|"推奨される対応"| closed_network
    clickonce -->|"用いるのは非推奨"| windows_service
    xcopy_deployment -->|"用いるのは非推奨"| windows_service
    xcopy_deployment -->|"推奨される対応"| closed_network
    custom_updater -.->|"前提とする"| code_signing_cert
    custom_updater -.->|"推奨される対応"| closed_network

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全17件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 5 つは同じ土俵ではない

ここはかなり大事です。

MSI / MSIX / ClickOnce / xcopy は、主に どう入れるか の話です。 一方で 独自 updater は、主に どう更新責任を持つか の話です。

つまり実務では、2 層に分けて考えたほうが整理しやすいです。

図にするとこうなります。点線は「その導入方式なら、素直につながる更新手段」です。

flowchart TB
    APP["配布したい Windows アプリ"] --> Q1["まず: どう入れるか<br/>初回導入層"]
    APP --> Q2["次に: 誰が更新責任を持つか<br/>継続更新層"]

    Q1 --> MSI["MSI"]
    Q1 --> MSIX["MSIX"]
    Q1 --> CO["ClickOnce"]
    Q1 --> XC["xcopy"]

    Q2 --> AI["MSIX App Installer"]
    Q2 --> COU["ClickOnce の built-in 更新"]
    Q2 --> MAN["手動差し替え"]
    Q2 --> OWN["独自 updater"]

    MSIX -.-> AI
    CO -.-> COU
    MSI -.-> MAN
    XC -.-> MAN
    MSI -.-> OWN
    XC -.-> OWN

ClickOnce と MSIX は、上の層を決めると下の層もほぼ決まります。逆に MSI と xcopy は、下の層を別途決める必要があります。「更新をどうするか」が宙に浮きやすいのは、この 2 つを選んだとき です。

なので、独自 updater は最初に選ぶものではなく、既存の配布方式で足りない更新要件があるときに追加で選ぶもの だと思ったほうがぶれません。

3. 一枚で見る判断表

まずは、いちばん使いやすい判断表を置きます。

この表でいちばん大事なのは、「更新がある」だけで独自 updater に飛ばない ことです。

4. 観点別の比較

この表で見るべきなのは、何が最強か ではなく、何がいちばん摩擦が少ないか です。

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 を取りたくない構成

この 4 点は、それぞれ確認先が違います。「MSIX は無理らしい」で止めず、どの資料を見れば決着するかまで決めておくと早いです。

いずれも 9 章の参考資料にリンクを置いてあります。判断のときは、「対応しているか」ではなく「どのバージョンから、どういう宣言をすれば対応するか」 まで見てください。ここを OS バージョン条件込みで押さえておかないと、検証機では動いたのに現場の古い Windows では入らない、という形で後から出てきます。

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 自身の更新

つまり、自由度ではなく責任が増える ということです。

5.6 方式を決めたあと、次に何を調べるか

「MSI で行く」と決めても、そこから何を調べればよいか分からないと止まります。代表的な入口を並べておきます。どれも「これを使え」ではなく、その方式を選んだなら、まず名前を知っておくとよいもの です。

ここで注意したいのは、ツールを選ぶことと方式を選ぶことは別 だという点です。たとえば Inno Setup は扱いやすいですが、できあがるのは MSI ではないので、Windows Installer 前提の運用、たとえばグループポリシーでのソフトウェア配布や msiexec による修復には乗りません。5.1 で MSI を選んだ理由がそこにあるなら、ツールもそれに合わせる必要があります。

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 問

1. そのアプリは current user だけでよいか、machine-wide に入れる必要があるか
2. service / driver / shell extension / COM 登録はあるか
3. package identity が必要な Windows 機能を使うか
4. 標準ユーザーだけで導入したいか
5. 更新頻度は月次か、週次か、もっと高いか
6. 対象環境は閉域か、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

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

MSIとMSIXの違いは何ですか？

MSI は Windows の伝統的なインストーラ形式で、per-machine 導入、Windows サービス、COM 登録、shell extension のような OS へ深く触る導入と相性がよく、install / uninstall / repair を Windows の流儀で表現できます。MSIX は Windows 10/11 前提の modern packaging で、clean install / clean uninstall、頻繁な更新、package identity が強みです。一方で MSIX はドライバに不向きで、in-process shell extension は Windows 11 21H2 以降で条件付き対応、unrestricted な古い Win32 前提にも向きません。OS への登録が濃いなら MSI、package identity と更新のきれいさを取りたいなら MSIX が起点です。

MSIXとClickOnceはどちらを選ぶべきですか？

per-user の .NET 社内業務アプリを簡単に配って自動更新したいなら、ClickOnce が今でもかなり強い選択です。built-in の更新モデルが使いやすく、標準ユーザーのまま導入でき、更新 UX を作り込む必要もありません。一方、package identity が必要な Windows 機能を使いたい、clean install / uninstall を重視したい、Intune や App Installer に寄せたい場合は MSIX が有力です。どちらも OS へ深く触るタイプの製品には向かないため、サービスやドライバがあるなら MSI 側から考えます。

ClickOnceは今でも使えますか？古い技術ではないのですか？

今でも使えますし、向いている場面ではかなり強い選択肢です。.NET の社内向けデスクトップアプリを、利用者単位（per-user）で、標準ユーザー権限のまま素早く配布し、built-in の更新モデルで回したい場合に有効です。逆に、Windows サービスやドライバ、shell extension のような OS へ深く触る製品や、複数の前提物を束ねるインストーラ的な役割までは期待しないほうが安全です。更新頻度の観点では、月次から週次程度の更新であれば ClickOnce や MSIX でかなり楽に回せます。

独自updaterはどんなときに検討すべきですか？

独自 updater は最初に選ぶものではなく、既存の配布方式で足りない更新要件があるときに追加で選ぶものです。検討する価値が出るのは、更新頻度が高い、stable / beta / preview のようなチャネルを持ちたい、段階配信やロールアウト率を制御したい、更新 telemetry や crash recovery を自前で見たい、といった要件があるときです。ただし、署名検証、配信 manifest、再試行、rollback、壊れた更新の復旧、updater 自身の更新まで自分たちで設計・運用する責任を負うことになるため、自由度ではなく責任が増える選択だと考えるべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。