ClickOnce とは何か - 仕組み、更新、向いている場面・向いていない場面を実務目線で整理

Windows の .NET デスクトップアプリを配る話になると、MSI や MSIX の影で、地味に何度も名前が出てくるのが ClickOnce です。

ただ、ここで雑に

• 古い技術だからもう使わない
• 逆に、簡単そうだから何でも ClickOnce で行ける

のどちらかに振ると、だいたい外します。

ClickOnce は、何でもできる万能 installer ではありません。
一方で、社内向けの .NET 業務アプリを 標準ユーザーへ配り、更新まで含めて低コストで回したい 場面では、今でもかなり有力です。

この記事では、ClickOnce が何なのか、どう動くのか、何が優れていて、どこで無理が出るのかを、Mermaid 図を多めに入れながら実務目線で整理します。内容は 2026 年 4 月時点で確認できる Microsoft Learn の情報を主な前提にしています。

図は概念図です。Mermaid 対応の Markdown 環境では図として表示されます。

目次

1. まず結論
2. ClickOnce とは何か
3. ClickOnce を構成するもの
4. インストールから起動までの流れ
5. 更新の仕組み
6. ClickOnce が優れている点
7. 向いている場面
8. 向いていない場面
9. 実務でハマりやすい点
10. まとめ
11. 関連記事
12. 参考資料

1. まず結論

ClickOnce をひとことで言うと、.NET の Windows デスクトップアプリを、利用者単位で簡単に配り、自動更新まで含めて回すための配布技術 です。

向いているのは、たとえば次です。

• WinForms / WPF などの社内向け業務アプリ
• 標準ユーザーで導入したい
• per-user 配布で十分
• 更新を built-in で持ちたい
• 配布経路が Web サイトやファイル共有で足りる

逆に、次なら最初から別方式を見たほうが安全です。

• 全ユーザー向けの machine-wide install
• Windows service、driver、in-process shell extension、濃い COM 登録
• package identity が必要
• 更新チャネル、段階配信、独自 rollback UX まで握りたい
• インストーラとして OS へ深く入る責務が大きい

要するに ClickOnce は、簡単配布と簡単更新には強いが、OS 統合が重い案件には向かない 方式です。

まずは位置づけを一枚で見る

flowchart TD
    A["Windows アプリを配りたい"]
    B{"OS へ深く統合する要件があるか"}
    C["MSI / MSIX 側から考える"]
    D{".NET の Windows デスクトップアプリで<br/>per-user 配布で足りるか"}
    E{"標準ユーザーに配りたいか"}
    F{"built-in 更新で十分か"}
    G["ClickOnce が有力"]
    H["xcopy / 独自 updater も比較"]

    A --> B
    B -- はい --> C
    B -- いいえ --> D
    D -- いいえ --> H
    D -- はい --> E
    E -- いいえ --> H
    E -- はい --> F
    F -- はい --> G
    F -- いいえ --> H

2. ClickOnce とは何か

ClickOnce は Microsoft の Windows アプリ配布技術です。
公式には、最小限のユーザー操作でインストール・実行でき、自己更新できる Windows ベースアプリの配布技術 と説明されています。

ここで大事なのは、ClickOnce を単なる「インストーラの種類」と見ないことです。

実態としては、ClickOnce は次をまとめて面倒を見る 配布モデル です。

• どのバージョンを配るか
• どのファイルがそのバージョンに含まれるか
• どう更新を検出するか
• どこから更新を取得するか
• 利用者ごとの安全な場所にどう保持するか
• 起動時に整合性をどう確認するか

つまり ClickOnce の本体は、setup.exe そのものではありません。
マニフェストを中心に、配布・更新・キャッシュ管理をまとめて扱う仕組み と見たほうが本質に近いです。

現行の .NET でも ClickOnce 自体は普通に候補に入ります。Visual Studio では .NET Core 3.1 と .NET 5 以降向けに Publish tool が使われ、手動でマニフェストを扱う場合は dotnet-mage.exe を使う形になります。

ClickOnce が面倒を見る責務

flowchart LR
    CO["ClickOnce"]
    V["どの版を配るか"]
    U["どこから更新を取るか"]
    S["利用者ごとの安全な場所へ保持"]
    I["整合性を確認して起動"]

    CO --> V
    CO --> U
    CO --> S
    CO --> I

3. ClickOnce を構成するもの

ClickOnce の仕組みを理解するときは、次の 4 つを見るとかなり整理しやすいです。

ここで中核になるのは 2 種類のマニフェスト です。

• 配置マニフェスト は、「このアプリの今の正解はどの版か」を表す
• アプリケーションマニフェスト は、「その版の中身は何か」を表す

つまり、ClickOnce の更新判定はまず配置マニフェストから始まり、実際に何を落とすかはアプリケーションマニフェストが握ります。

4 要素の関係

flowchart LR
    Setup["setup.exe<br/>任意<br/>前提条件の確認 / 導入"]
    Deploy["配置マニフェスト (.application)<br/>どの版を配るか<br/>更新場所 / 更新条件"]
    App["アプリケーションマニフェスト (*.exe.manifest)<br/>その版の中身<br/>ファイル一覧 / ハッシュ / エントリポイント"]
    Files["アプリ本体<br/>exe / dll / config / data"]
    Cache["ClickOnce キャッシュ<br/>per-user / per-application"]

    Setup --> Deploy
    Deploy --> App
    App --> Files
    Files --> Cache

setup.exe は主役ではなく補助

setup.exe はよく目立ちますが、ClickOnce の主役ではありません。
これは 前提条件を確認・導入する補助役 です。

たとえば、正しい .NET ランタイムや追加の再頒布コンポーネントが必要なときは、setup.exe が先にそれを整え、その後で ClickOnce 本体の配布に入ります。

4. インストールから起動までの流れ

ClickOnce の流れを、実務向けにかなり単純化すると次です。

1. ユーザーが Web ページやファイル共有上の setup.exe または .application を開く
2. setup.exe を使う構成なら、前提条件を確認して不足分を入れる
3. ClickOnce が配置マニフェストを読む
4. 配置マニフェストが指すアプリケーションマニフェストを読む
5. 必要なファイルを取得し、利用者ごとの ClickOnce キャッシュへ配置する
6. オフライン利用ありの構成なら、スタートメニューやアプリ一覧へ登録する
7. その後は ClickOnce 管理下からアプリを起動する

ポイントは、Program Files に普通の installer のように置く発想ではない ことです。

ClickOnce アプリは、利用者ごとの安全なキャッシュ領域 に入り、アプリごと・利用者ごとに分離されます。ここが ClickOnce のかなり大きな特徴です。

インストールから初回起動まで

sequenceDiagram
    participant U as 利用者
    participant P as setup.exe / .application
    participant D as 配置マニフェスト
    participant A as アプリケーションマニフェスト
    participant C as ClickOnce キャッシュ
    participant X as アプリ本体

    U->>P: 開く
    Note over U,P: setup.exe を使う構成では<br/>前提条件確認が先に入る
    P->>D: 取得して読む
    D->>A: 対象版を参照
    A->>C: 必要ファイルを取得・整合性確認
    C->>X: 配置して起動

オンライン専用とオフライン利用あり

ClickOnce には、大きく 2 つの見せ方があります。

• オンライン専用: 公開場所を起点に実行する形。常設インストール感は薄い
• オフライン利用あり: 利用者の端末へ導入され、スタートメニューからも起動できる形

社内業務アプリでは、実務上は オフライン利用あり を選ぶことが多いです。

flowchart LR
    subgraph Online[オンライン専用]
        O1["公開場所を起点に起動"]
        O2["常設インストール感は薄い"]
        O3["ネットワーク前提になりやすい"]
        O1 --> O2 --> O3
    end

    subgraph Offline[オフライン利用あり]
        F1["ユーザー領域へ導入"]
        F2["スタートメニュー登録"]
        F3["ローカルから起動"]
        F4["指定タイミングで更新確認"]
        F1 --> F2 --> F3 --> F4
    end

5. 更新の仕組み

ClickOnce のいちばん分かりやすい強みは、やはり 更新モデルが built-in であることです。

更新判定は配置マニフェストから始まる

ClickOnce アプリは、配置マニフェストを読んで、

• 新しい版があるか
• 必須更新か
• どこから取得するか

を確認します。

そのうえで更新が始まると、ClickOnce は file patching を使って冗長な再ダウンロードを避けます。感覚としては、新版のアプリケーションマニフェストと現行版を見比べて、変わったファイルだけを取りに行く と思っておくと実務では理解しやすいです。

更新確認の考え方としては、次の 3 パターンで整理すると分かりやすいです。

• 起動前に確認する
• 起動後に確認する
• アプリ側で「更新確認」UI を用意する

ただし、.NET Framework と .NET 5+ では使える API や設定 UI に差があります。古い ClickOnce 記事の記憶だけで実装に入らない のが大事です。

更新の流れ

flowchart TD
    Start["アプリ起動"]
    Check["配置マニフェストを確認"]
    New{"新しい版があるか"}
    Run["そのまま起動"]
    Get["新版のアプリケーションマニフェストを取得"]
    Compare["ファイルの署名 / ハッシュを比較"]
    Download["変わった分を取得"]
    Switch["新版を成立させて切り替え"]
    Restart["必要なら再起動後に新版で実行"]

    Start --> Check --> New
    New -- いいえ --> Run
    New -- はい --> Get --> Compare --> Download --> Switch --> Restart

ネットワーク接続がない場合は、更新確認をせずそのまま実行される、という前提も押さえておくと実務で混乱しにくいです。

版は分離して保持される

ClickOnce は、「今のファイルをその場で上書きする」というより、新版を正しい形で成立させてから切り替える 発想に近いです。

さらに、ClickOnce キャッシュには 現行版と前版 が分離して保持されます。これは、環境を汚しにくく、版の衝突を避けやすい理由のひとつです。

flowchart TB
    subgraph UA[利用者A の ClickOnce キャッシュ]
        APrev["前版"]
        ACur["現行版"]
        AData["設定 / データ"]
    end

    subgraph UB[利用者B の ClickOnce キャッシュ]
        BPrev["前版"]
        BCur["現行版"]
        BData["設定 / データ"]
    end

    APrev --> ACur
    AData --> ACur
    BPrev --> BCur
    BData --> BCur

ここでのポイントは 2 つです。

• 別ユーザーと混ざりにくい
• 別バージョンと衝突しにくい

いわゆる DLL Hell を避けやすいのは、この構造が大きいです。

6. ClickOnce が優れている点

ClickOnce の良さは、「簡単に配れる」だけではありません。実務で効くのは、だいたい次です。

6.1 標準ユーザーに配りやすい

ClickOnce は per-user 前提の配布と相性がよく、管理者権限なしで導入しやすい のが大きいです。

社内業務アプリでよくあるのは、

• 利用者は標準ユーザー
• IT 部門へ毎回インストール依頼したくない
• でも更新は止めたくない

という状況です。

この条件では、ClickOnce はかなり強いです。
「各利用者の領域へ、安全に、更新込みで入る」という前提が最初から合っています。

6.2 更新を自前実装しなくてよい

自動更新をゼロから作ると、見た目以上にやることが増えます。

• 新版確認
• ダウンロード
• 整合性確認
• 旧版との切り替え
• 失敗時の復旧
• 更新 UI
• updater 自身の扱い

ClickOnce はこのうちのかなりの部分を既存のモデルで持っています。

flowchart LR
    subgraph Custom[自前 updater で持つ責務]
        C1["新版検出"]
        C2["ダウンロード"]
        C3["整合性確認"]
        C4["切り替え"]
        C5["失敗時復旧"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[ClickOnce に寄せられる責務]
        K1["新版検出"]
        K2["取得と検証"]
        K3["切り替え"]
        K1 --> K2 --> K3
    end

もちろん何でも自由にできるわけではありません。
ただ、社内向けアプリで必要な「十分な更新」 はかなり満たしやすいです。

6.3 アプリ同士が衝突しにくい

ClickOnce アプリは アプリごと・利用者ごと・バージョンごとに分離 されます。

このため、昔ながらの

• 共有コンポーネントのバージョン競合
• どこかの DLL を上書きして別アプリが壊れる
• 手動差し替えで環境が汚れる

といった事故を起こしにくいです。

6.4 Visual Studio から出しやすい

ClickOnce は Visual Studio の発行機能と相性がよく、配布までの距離が短い のも利点です。

MSI authoring のような別の難しさに入る前に、

• まず発行して
• まず配って
• まず更新を回して
• まず現場のフィードバックを得る

という流れを作りやすいです。

6.5 設定持ち越しも比較的素直

既定のアプリケーション設定プロバイダを使っている場合、ClickOnce は更新時に 前版の設定を新版へマージ する仕組みを持っています。

ただし、ここは 既定の設定プロバイダ前提 です。独自設定保存や独自プロバイダ、保存先の変更まで入ると、当然そのままでは済みません。

7. 向いている場面

ClickOnce が特に向いているのは、だいたい次のような案件です。

実務でかなり相性がよい具体例を挙げると、次です。

• 社内の業務入力アプリ
• 見積・受発注・在庫などのデスクトップ業務ツール
• 装置設定用の補助アプリ
• 営業所・工場・バックオフィスへ配る社内専用クライアント
• 更新は欲しいが、専用 updater を作るほどではないアプリ

こういうアプリでは、配布と更新をシンプルにすること自体が価値 です。ClickOnce はその価値にかなり素直に応えます。

向くかどうかの判断木

flowchart TD
    S["要件を整理する"]
    Q1{"WinForms / WPF などの<br/>.NET デスクトップアプリか"}
    Q2{"per-user 配布で足りるか"}
    Q3{"標準ユーザーに入れたいか"}
    Q4{"Web / ファイル共有で配れるか"}
    Q5{"更新 UX を作り込みすぎなくてよいか"}
    G["ClickOnce がかなり有力"]
    O["他方式を比較"]

    S --> Q1
    Q1 -- いいえ --> O
    Q1 -- はい --> Q2
    Q2 -- いいえ --> O
    Q2 -- はい --> Q3
    Q3 -- いいえ --> O
    Q3 -- はい --> Q4
    Q4 -- いいえ --> O
    Q4 -- はい --> Q5
    Q5 -- はい --> G
    Q5 -- いいえ --> O

8. 向いていない場面

一方で、ClickOnce を無理に使わないほうがよい場面もはっきりしています。

8.1 machine-wide install が必要

ClickOnce は per-user が基本です。

• 全ユーザー共通で入れたい
• Program Files 前提で入れたい
• 端末全体へ導入・管理したい

なら、ClickOnce ではなく MSI などのほうが自然です。

8.2 Windows service / driver / shell extension / 濃い COM 登録

このあたりは、OS へ深く触る 話です。

• Windows service
• driver
• in-process shell extension
• 機械的な COM 登録を前提にする構成

まで入ってくると、ClickOnce の「軽く配る」世界観から外れてきます。

8.3 package identity が欲しい

MSIX を選ぶ理由のひとつに、package identity を取りたいという要件があります。

ClickOnce はこの方向ではありません。欲しいのが modern packaging や Windows の package identity 前提機能なら、MSIX を優先したほうがよいです。

8.4 更新 UX や配信チャネルを製品として握りたい

たとえば、

• stable / beta / preview のチャネル
• 段階配信
• telemetry を見ながらロールアウト率調整
• 背景ダウンロードの細かい制御
• 独自の rollback 戦略
• updater 自体の複雑なライフサイクル

まで欲しくなると、ClickOnce の built-in 更新では足りなくなります。

8.5 置くだけ運用で十分なツール

逆に、もっと単純でよいケースもあります。

• フォルダごと置けば動く
• 更新も手動差し替えでよい
• USB で渡す
• 閉域で単純さが最優先

なら、xcopy 配布のほうが摩擦が少ないこともあります。

どの要件なら別方式へ寄るか

flowchart LR
    A1["全ユーザー向け導入"] --> B1["MSI / 一部 MSIX"]
    A2["service / driver / shell extension / 濃い COM"] --> B2["MSI / 専用 installer"]
    A3["package identity が必要"] --> B3["MSIX"]
    A4["段階配信 / チャネル / 独自 UX"] --> B4["独自 updater"]
    A5["置くだけで十分"] --> B5["xcopy"]

つまり ClickOnce は、上にも下にも万能ではありません。
ちょうどよい複雑さの案件に強い 方式です。

9. 実務でハマりやすい点

ClickOnce は便利ですが、雑に入ると少しハマります。特に次は先に押さえておくと楽です。

9.1 「普通の installer」と同じ感覚で見ない

ClickOnce は、固定のインストール先へ人間が直接管理しやすい形で置くモデルではありません。

実体は ClickOnce の管理するキャッシュに入り、版ごとに分離されます。
そのため、

• 固定 EXE パスを前提にした運用
• 手で直接上書きする運用
• 実体ファイルの場所を人が握る運用

とは相性がよくありません。

ClickOnce は ファイル配置を人が管理する方式ではなく、配布状態をマニフェストで管理する方式 です。

9.2 古い ClickOnce 記事は .NET Framework 前提のものが多い

ここはかなり大事です。

今でも検索上位には、.NET Framework 時代の ClickOnce 記事が多く出てきます。
ただ、今の .NET では事情が少し違います。

• .NET Core 3.1 / .NET 5 / .NET 6 では ApplicationDeployment API をそのままは使えない
• .NET 7 以降では一部の配置プロパティを環境変数経由で読める
• 手動でマニフェストを扱うなら dotnet-mage.exe が前提になる
• Visual Studio 側も昔の Publish Wizard 前提の話がそのまま通らないことがある

つまり、「ClickOnce は知っている」つもりでも、古い記憶のまま実装しない ほうが安全です。

9.3 前提条件は別で考える

ClickOnce 自体は配布モデルですが、アプリが動くには前提条件が必要なことがあります。

• 対応ランタイム
• 追加の再頒布コンポーネント
• その他の依存物

このとき setup.exe を使う bootstrapper 構成が効きます。逆にここを曖昧にすると、「ClickOnce で配れたのに動かない」が起きます。

9.4 設定の持ち越しは“何をどう保存しているか”次第

既定の設定プロバイダなら更新時の設定移行は比較的素直です。
ただし、

• 独自設定プロバイダ
• roaming 前提
• 設定保存先を自前で変えている
• 版差分で設定構造を大きく変えている

なら、当然そのままでは済みません。

9.5 署名と更新経路を軽く見ない

ClickOnce は配布と更新の仕組みを持っていますが、だからといってセキュリティの責任が消えるわけではありません。

特に本番では、

• 署名証明書をどう管理するか
• 発行者名をどう見せるか
• 更新元をどう管理するか
• テスト用の自己署名と本番署名をどう分けるか

は最初に整理したほうがよいです。

flowchart TD
    Cert["コード署名証明書"]
    AppMan["アプリケーションマニフェスト"]
    DepMan["配置マニフェスト"]
    Verify["クライアント側で検証"]
    Run["更新 / 実行"]
    Tamper["マニフェスト改ざん"]
    Stop["検証失敗で止める"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. 検証失敗 .-> Stop

「自動更新がある = 安心」ではなく、何を信頼し、その信頼をどう維持するか は別で考える必要があります。

9.6 配置先を動かすなら deploymentProvider を見直す

これは地味ですが、実務ではかなりハマります。

インストール済み ClickOnce アプリは、配置マニフェスト内の deploymentProvider が指す場所を更新元として見にいきます。
つまり、公開フォルダを丸ごと別 URL や別共有へコピーしても、deploymentProvider を更新しなければ クライアントは元の場所を見続ける ことがあります。

そして、マニフェストを手で変えたら 再署名 が必要です。

発行から更新反映までの運用フロー

flowchart TD
    Build["ビルド"]
    AppManifest["新しいアプリケーションマニフェスト生成"]
    SignApp["アプリケーションマニフェストへ署名"]
    UpdateDep["配置マニフェストを新しい版へ更新"]
    SignDep["配置マニフェストへ署名"]
    Publish["公開先へ配置"]
    Client["クライアントが更新検出"]

    Build --> AppManifest --> SignApp --> UpdateDep --> SignDep --> Publish --> Client

要するに、ClickOnce の運用で大事なのは ファイルを置いたかどうか よりも、マニフェストと署名の整合性が取れているか です。

10. まとめ

ClickOnce は、ひとことで言えば

.NET の Windows デスクトップアプリを、
per-user で簡単に配り、更新まで低コストで回すための仕組み

です。

優れているのは、主に次の点です。

• 標準ユーザーへ配りやすい
• built-in の更新モデルがある
• 変更分だけの更新がしやすい
• アプリとバージョンを分離しやすい
• Visual Studio から発行しやすい
• 社内向け業務アプリと相性がよい

ただし、万能ではありません。

• machine-wide install
• service / driver / shell extension
• 濃い COM 登録
• package identity
• 独自チャネルや段階配信
• 更新 UX を製品価値として作り込む

といった要件があるなら、ClickOnce ではなく MSI / MSIX / 独自 updater 側から考えるべきです。

つまり ClickOnce は、何でも入る簡易 installer ではありません。
その代わり、向く案件では今でもかなり強い です。

もし配りたいのが

• .NET の Windows 業務アプリで
• 利用者単位の導入で足りて
• 標準ユーザーへ配りたくて
• 更新を自前で持ちたくない

なら、ClickOnce はかなり有力な候補に入ります。

11. 関連記事

• Windows アプリの配布方式をどう選ぶか - MSI / MSIX / ClickOnce / xcopy / 独自 updater の判断表
• 自動アップデータは信頼境界です - HTTPS だけでは足りない理由
• Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方

関連トピック

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

Windows技術トピック

Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。

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

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

Windowsアプリ開発

社内向け業務アプリ、装置設定ツール、既存ソフト改修などで、ClickOnce / MSI / MSIX / xcopy のどれがいちばん摩擦が少ないかは、実装前の整理でかなり変わります。

サービスを見る お問い合わせ

技術相談・設計レビュー

「ClickOnce で十分なのか」「MSIX や MSI へ寄せるべきか」「自動更新を built-in で済ませるか、自前で持つか」といった切り分けは、実装前に整理すると判断しやすくなります。

サービスを見る お問い合わせ

著者プロフィール

小村 豪

合同会社小村ソフト 代表

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

プロフィールを見る お問い合わせ

12. 参考資料

• Microsoft Learn - ClickOnce deployment and security
• Microsoft Learn - ClickOnce for .NET on Windows
• Microsoft Learn - How ClickOnce performs application updates
• Microsoft Learn - Choosing a ClickOnce update strategy
• Microsoft Learn - ClickOnce deployment manifest
• Microsoft Learn - ClickOnce application manifest
• Microsoft Learn - ClickOnce cache overview
• Microsoft Learn - ClickOnce and application settings
• Microsoft Learn - Install prerequisites with a ClickOnce application
• Microsoft Learn - ClickOnce and Authenticode
• Microsoft Learn - Security, versioning, and manifest issues in ClickOnce deployments