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

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

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

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

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

flowchart TB
    accTitle: 配布方式を決める2つの軸
    accDescr: 配布方式の選択はどれが新しいか簡単かというインストーラ形式の好みではなく、OSにどこまで触るかと、更新責任を誰が持つかという2つの軸の選択であることを示す図。
    a0["「どれが新しいか・簡単か」"] -.-> a1["この軸では決めない"]
    a2["OSにどこまで触るか"] --> a4["配布方式が決まる"]
    a3["更新責任を誰が持つか"] --> a4

図1: 配布方式は好みではなく、OS統合の濃さと更新責任の2軸で決める。

この記事は、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

flowchart TB
    accTitle: 5方式の乱暴なまとめ
    accDescr: OSへの登録が濃いならMSI、package identityとmodern packagingを取りたいならMSIX、per-userの簡単配布とbuilt-in更新が欲しいならClickOnce、置くだけ配布が最優先ならxcopy、更新基盤を自社で設計・運用する覚悟があるなら独自updaterという対応を示す図。
    b1{"OSへの登録が濃いか"} -->|"はい"| b2["MSI寄り"]
    b1 -->|"いいえ"| b3{"package identityが欲しいか"}
    b3 -->|"はい"| b4["MSIX"]
    b3 -->|"いいえ"| b5{"per-user簡単配布+自動更新か"}
    b5 -->|"はい"| b6["ClickOnce"]
    b5 -->|"置くだけ最優先"| b7["xcopy"]
    b7 -.-> b8["更新基盤を自社で握る覚悟があるなら独自updater"]

図2: 迷ったら、登録の濃さ・identity・配布の簡単さの順で切り分ける。

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

flowchart TB
    accTitle: ワークシートの使い方
    accDescr: Plannerシートで7項目を埋め、候補の見分け方と判断の流れで方式へ寄せ、第一候補と理由を書き残すという、判断を案件ごとに記録するワークシートの流れを示す図。
    c1["入力シートの7項目を埋める"] --> c2["候補の見分け方で絞る"]
    c2 --> c3["判断の流れで方式へ寄せる"]
    c3 --> c4["第一候補と理由を書き残す"]
    c4 -.-> c5["Referenceシートは3章・4章の表"]

図3: ワークシートは記事の判断を、案件ごとの記録に変えるためのもの。

この記事の知識マップ

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

図4: 初回導入層と継続更新層の2層モデル。点線は素直につながる更新手段。

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

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

flowchart TB
    accTitle: 更新が宙に浮くのはMSIとxcopy
    accDescr: ClickOnceとMSIXは導入方式を決めると更新手段もほぼ決まるが、MSIとxcopyは継続更新層を別途決める必要があり、独自updaterはその更新要件が足りないときに追加で選ぶものであることを示す図。
    d1["ClickOnce / MSIXを選ぶ"] --> d2["更新手段もほぼ決まる"]
    d3["MSI / xcopyを選ぶ"] --> d4["更新をどうするかが宙に浮く"]
    d4 --> d5["継続更新層を別途決める"]
    d5 -.-> d6["足りないときに独自updaterを追加"]

図5: 独自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 が重くなりやすい

flowchart TB
    accTitle: MSIの強みと代償
    accDescr: MSIはアプリをOSにどう入れたかをWindowsの流儀で表現しやすい一方、authoringが難しく、custom actionを増やすほど壊れやすく、高頻度更新では更新UXが重くなりやすいことを示す図。
    e1["MSI"] --> e2["OSへの入れ方をWindowsの流儀で表現"]
    e2 --> e3["install / uninstall / repairが揃う"]
    e1 -.-> e4["authoringが地味に難しい"]
    e4 -.-> e5["custom actionを増やすほど壊れやすい"]

図6: MSIはOS統合の表現力と引き換えに、authoringの難しさを抱える。

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 では入らない、という形で後から出てきます。

flowchart TB
    accTitle: MSIXの制約は確認先まで決める
    accDescr: shell extensionやdriverなどMSIXで迷う4点は、それぞれ確認先の資料が違うため、無理らしいで止めず、どのバージョンからどういう宣言をすれば対応するかまで見ることで、検証機では動いたのに現場で入らない事故を防ぐことを示す図。
    f1["MSIXで迷う4点"] --> f2["「無理らしい」で止めない"]
    f2 --> f3["どの資料で決着するか決める"]
    f3 --> f4["どの版から・どの宣言で対応かまで見る"]
    f4 -.-> f5["検証機OK・現場NGを防ぐ"]

図7: MSIXの制約は、OSバージョン条件と宣言方法まで確認して決着させる。

5.3 ClickOnce

ClickOnce は、.NET の社内向けデスクトップアプリを、per-user で、素早く、更新込みで回したい ときに今でもかなり強いです。

向いているのは、こんな場面です。

• 社内向けの業務アプリ
• 標準ユーザーで導入したい
• 利用者単位での配布で十分
• 更新 UX をそこまで作り込みたくない

逆に、OS へ深く触るタイプの製品や、複数前提物を束ねる installer 的な役割まで期待しないほうが安全です。

5.4 xcopy

xcopy は、install ではなく deploy です。レジストリ登録も、修復機能も、package identity もありません。その代わり、置くだけで済む なら最強クラスに単純です。

持ち味が出るのは、こういうツール類です。

• 診断ツール
• 装置設定ツール
• ログ収集ツール
• 現場へ USB で渡すユーティリティ
• side-by-side で複数版を共存させたいケース

xcopy の強みは、失敗の仕方が分かりやすい ことです。フォルダごと差し替える、戻したければ前の版へ戻す、という運用がしやすいです。

flowchart TB
    accTitle: xcopyはinstallではなくdeploy
    accDescr: xcopyはレジストリ登録も修復機能もpackage identityも持たない代わりに、置くだけで済み、フォルダごと差し替えて戻したければ前の版へ戻すという、失敗の仕方が分かりやすい運用ができることを示す図。
    g1["フォルダごと置く"] --> g2["そのまま動く"]
    g2 --> g3["更新はフォルダごと差し替え"]
    g3 --> g4["戻すのは前の版に差し戻し"]
    g1 -.-> g5["登録・修復・identityは持たない"]

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

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

flowchart TB
    accTitle: 独自updaterは責任の選択
    accDescr: 独自updaterはチャネルや段階配信、telemetryのような自由度を得る代わりに、署名検証、配信manifest、rollback、壊れた更新の復旧、updater自身の更新までを自分たちで設計・運用する責任を負う選択であることを示す図。
    h1["得るもの: チャネル・段階配信・telemetry"] --> h3["独自updater"]
    h2["支払うもの: 署名検証・rollback・復旧"] --> h3
    h3 --> h4["自由度ではなく責任が増える"]
    h2 -.-> h5["updater自身の更新も自分の仕事"]

図9: 独自updaterで増えるのは自由度ではなく、更新基盤の運用責任。

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

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

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

flowchart TB
    accTitle: ツール選びと方式選びは別
    accDescr: Inno Setupは扱いやすいが、できあがるのはMSIではないため、グループポリシーでのソフトウェア配布やmsiexecによる修復には乗らず、方式を選んだ理由に合わせてツールを選ぶ必要があることを示す図。
    i1["方式を決める"] --> i2["ツールを決める"]
    i2 -.-> i3["Inno SetupはMSIを作らない"]
    i3 -.-> i4["GPO配布やmsiexec修復に乗らない"]
    i4 -.-> i5["方式を選んだ理由にツールを合わせる"]

図10: 便利なツールが、選んだ方式の土俵に乗るとは限らない。

6. 迷いやすい論点

6.1 package identity が要るか

もし欲しいのが package identity 前提の Windows 機能なら、MSIX の価値は一気に上がります。

逆に、

• unrestricted な file system access
• unrestricted な registry access
• elevation / process model の自由度
• 古い Win32 前提をそのまま残したい

なら、unpackaged 寄りの方式のほうが自然です。

flowchart TB
    accTitle: package identityの要否で分ける
    accDescr: package identity前提のWindows機能が欲しいならMSIXの価値が一気に上がり、unrestrictedなファイルやレジストリへのアクセス、古いWin32前提をそのまま残したいならunpackaged寄りの方式が自然であることを示す図。
    j1{"package identity前提の機能が欲しいか"} -->|"はい"| j2["MSIXの価値が一気に上がる"]
    j1 -->|"unrestrictedに動かしたい"| j3["unpackaged寄りの方式が自然"]

図11: identityの要否は、packagedと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

「管理者権限なしで入れたい」と「全ユーザーが同じ場所から使いたい」は同じではありません。

flowchart TB
    accTitle: per-userとper-machineを混同しない
    accDescr: per-userに寄せたいならClickOnceやxcopyや一部のMSIX、per-machineに寄せたいならMSIや条件が合えばMSIXが候補になり、管理者権限なしで入れたいことと全ユーザーが同じ場所から使いたいことは同じではないことを示す図。
    k1["per-userに寄せたい"] --> k2["ClickOnce / xcopy / 一部のMSIX"]
    k3["per-machineに寄せたい"] --> k4["MSI / 条件が合えばMSIX"]
    k1 -.-> k5["権限なし導入と全員共通の場所は別の話"]

図12: 導入スコープを曖昧にしたまま進めると、あとで必ず揉める。

6.4 更新頻度と運用責任

更新頻度の感覚で見ると、ざっくりこうです。

• 四半期から月次更新: MSI でも十分回る
• 月次から週次更新: MSIX / ClickOnce がかなり楽
• 週次から日次更新: 独自 updater を検討する理由が出る
• 更新は手動でよい / 配置側が制御する: xcopy でも十分

配布方式は、技術選定 であると同時に 運用設計 でもあります。

flowchart TB
    accTitle: 更新頻度の階段
    accDescr: 四半期から月次更新ならMSIでも十分回り、月次から週次ならMSIXやClickOnceがかなり楽になり、週次から日次なら独自updaterを検討する理由が出て、更新が手動でよいならxcopyでも十分という更新頻度の目安を示す図。
    m1["四半期〜月次: MSIでも十分"] --> m2["月次〜週次: MSIX / ClickOnceが楽"]
    m2 --> m3["週次〜日次: 独自updaterの検討理由が出る"]
    m1 -.-> m4["手動でよいならxcopyでも十分"]

図13: 更新頻度が上がるほど、built-in更新や独自基盤の価値が増す。

6.5 閉域・オフライン配布

閉域では、きれいな auto-update より 単純さ が勝つことが多いです。

• xcopy は強い
• MSI も強い
• ClickOnce も file share や removable media で使える
• MSIX も App Installer の使い方次第で回る

ただし閉域で頻繁に更新するなら、「誰が、どこへ、新版を置き、旧版をどう残すか」まで決めないと、方式だけ選んでも運用が崩れやすいです。

flowchart TB
    accTitle: 閉域では単純さが勝つ
    accDescr: 閉域ではきれいなauto-updateより単純さが勝つことが多く、頻繁に更新するなら、誰が、どこへ、新版を置き、旧版をどう残すかまで決めないと、方式だけ選んでも運用が崩れやすいことを示す図。
    n1["閉域・オフライン環境"] --> n2["きれいなauto-updateより単純さ"]
    n2 --> n3["xcopyやMSIが強い"]
    n2 -.-> n4["誰が・どこへ新版を置くかまで決める"]
    n4 -.-> n5["旧版をどう残すかも決める"]

図14: 閉域では方式選びより先に、新版と旧版の置き方の運用を決める。

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 を比較対象へ入れる

flowchart TB
    accTitle: 6問からの着地点
    accDescr: サービスやドライバなどのOS統合があるならまずMSI側、package identityが必要ならMSIXを優先検討、current userで標準ユーザー導入の.NETデスクトップアプリならClickOnce、置くだけ運用でよいならxcopy、更新頻度が高く更新UXを握りたいなら独自updaterを比較対象に入れるという着地を示す図。
    p1{"OS統合（サービス等）があるか"} -->|"はい"| p2["まずMSI側から考える"]
    p1 -->|"いいえ"| p3{"package identityが必要か"}
    p3 -->|"はい"| p4["MSIXを優先検討"]
    p3 -->|"いいえ"| p5{"per-user+標準ユーザー導入か"}
    p5 -->|".NETデスクトップなら"| p6["ClickOnceが有力"]
    p5 -->|"置くだけ運用なら"| p7["xcopyが有力"]
    p6 -.-> p8["更新UXを握りたいなら独自updaterも比較"]

図15: 6問の答えをこの順にたどると、着地点がだいたい見える。

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 つだけでも先に固定すると、話がかなり前に進みます。

flowchart TB
    accTitle: 先に固定する3つ
    accDescr: 迷っているなら、per-userかper-machineか、OSへ何を登録するか、更新頻度はどのくらいかの3つだけでも先に固定すると、配布方式の話がかなり前に進むことを示す図。
    q1["per-userかper-machineか"] --> q4["先に固定する"]
    q2["OSへ何を登録するか"] --> q4
    q3["更新頻度はどのくらいか"] --> q4
    q4 --> q5["話がかなり前に進む"]

図16: 方式で迷ったら、この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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。