Windowsシングルバイナリ化の限界と実践
まず結論
Windows で「シングルバイナリにしたい」には、実は次の4つの意味が混ざっています:
- 配布物を1個にしたい
- .NET や VC++ ランタイムの事前インストールを不要にしたい
- インストーラや管理者権限なしで置くだけで動かしたい
- 対象 Windows の違いに依存したくない
配布物を 1 EXE に寄せることはかなりできる。でも、対象 Windows への依存をゼロにすることはできない。これが実務的な境界線です。
「シングルバイナリ」の4段階
レベルA: 配布物が1個
見た目の配布単位の話。実際には起動時に一時展開していても、OS の DLL に依存していても満たせる。
レベルB: 言語ランタイムの事前インストール不要
- C/C++ の静的リンク
- .NET の self-contained / single-file / Native AOT
このレベルになると「単体で持っていける」感じが強くなる。
レベルC: インストールや登録が不要
ここから急に難しくなる。Shell 拡張、Windows サービス、ドライバ、COM 登録は「置くだけ」では済まない。
レベルD: 対象 Windows に依存しない
Windows では無理。アプリは最終的に Windows の API、ローダー、セキュリティモデルの上で動くから。
1 EXE にしやすい領域
次のようなアプリは 1 EXE に寄せやすい:
- 単独起動のデスクトップツール
- EXE 自身が UI と処理を持つ業務アプリ
- 通信、ファイル処理、ログ収集、監視、装置制御ツール
- Explorer や Office のホスト統合を必要としないもの
実務では app.exe 1個、または app.exe + 隣接 DLL 数個で xcopy 配布できる形のほうが、無理に 1 EXE に圧縮するより保守しやすいことも多いです。
1 EXE でも消えない Windows 依存
- OS バージョン依存: API の最低サポート OS、x64/Arm64 の違い
- システム DLL 依存: kernel32.dll, user32.dll などは OS 側の責任範囲
- セキュリティモデル依存: UAC、ファイル ACL、サービス制御マネージャなど
- ホストやランタイム依存: WebView2 Runtime、Windows App SDK など
技術別の現実的な落としどころ
| 技術 | 現実度 | 注意点 |
|---|---|---|
| ネイティブ C/C++ | 高い | 静的リンク可能、UCRT の扱いに注意 |
| .NET (single-file) | 高い | 配布物のまとまりは良くなるが OS 依存は変わらない |
| .NET (Native AOT) | 高い | 起動時依存は減るが機能制約あり |
| WebView2 | 低〜中 | Runtime 配布方式が本題。EXE の数より Runtime の扱い |
| WinUI 3 | 中 | UI 技術の選択がそのまま配布方式の選択になる |
本質的に「登録・依存」が必要な領域
- Shell 拡張: Explorer への登録が必要。置くだけでは動かない
- Windows サービス: SCM への登録、権限、起動アカウントの設計が必要
- ドライバ: INF、署名、インストール手順まで含めて成立。single binary の土俵に乗りにくい
実務での判断表
| 作りたいもの | 1 EXE 現実度 | 先に考えるべきこと |
|---|---|---|
| 単独起動 Win32/C++ ツール | 高い | 静的リンク、対象 OS/arch |
| WinForms/WPF ツール | 高い | self-contained、single-file、Native AOT |
| WinUI 3 アプリ | 中 | 配布モード、追加依存 |
| WebView2 デスクトップ UI | 低〜中 | Runtime 配布方式 |
| Shell 拡張 | 低い | COM/レジストリ登録 |
| Windows サービス | 中 | SCM 登録、権限、更新手順 |
| ドライバ同梱アプリ | 低い | INF、署名、インストール |
配布設計で先に決めるべきこと
- 何を1個にしたいのかを決める - 配布物か、ランタイム不要化か、インストーラ不要化か
- 最低サポート Windows と arch を最初に固定する - 曖昧なまま進めると最後に詰まる
- 「同梱するもの」と「Windows に任せるもの」を明文化する
- single binary を優先するなら、ホスト統合を減らす - Shell 拡張やサービス化を避けるほど近づく
まとめ
- アプリを 1 EXE にすることはできるが、依存する Windows まで 1 EXE にすることはできない
- 単独起動の普通の EXE なら、かなり 1ファイル配布へ寄せられる
- OS バージョン、arch、システム DLL、セキュリティモデルへの依存は消えない
- Shell 拡張、サービス、ドライバ、WebView2、WinUI 3 は OS 登録や追加ランタイムが本題
- single binary を強く優先するなら、技術選定の時点で OS との結合度を下げる方向で設計する
参考資料
- Microsoft Learn, Create a single file for application deployment
- Microsoft Learn, Native AOT deployment overview
- Microsoft Learn, C runtime (CRT) and C++ standard library (STL) lib files
- Microsoft Learn, Dynamic-link library search order
- Microsoft Learn, Targeting your application for Windows
- Microsoft Learn, Creating Registration-Free COM Objects
- Microsoft Learn, Registering Shell Extension Handlers
- Microsoft Learn, CreateServiceW function
- Microsoft Learn, Overview of INF Files
- Microsoft Learn, Windows driver signing tutorial
- Microsoft Learn, Distribute your app and the WebView2 Runtime
- Microsoft Learn, Windows App SDK deployment guide for self-contained apps
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
ClickOnce 入門：配布・更新・選定基準
ClickOnce の仕組みと向き不向きを実務目線で整理します。マニフェスト、自動更新、キャッシュ分離、署名、配布経路の注意点に加え、社内業務アプリで強い理由と MSI/MSIX が適するケースの見分け方が分かります。
子プロセスを安全に扱うためのチェックリスト
Windows アプリで子プロセスを安全に扱うための設計指針を、プロセス木の所有権・終了伝播・標準入出力・watchdog 配置の4観点で整理し、Job Object を基準にした典型構成と落とし穴をまとめます。
Windowsはなぜ今の形になったのか：開発者から見た歴代Windowsの進化
Windows 95からWindows 11までの変化を、見た目の年表ではなく、互換性、安定性、権限管理、ドライバ、Win32、.NET、セキュリティなどWindowsアプリ開発者の視点で整理します。
Windowsで「Windows によって PC が保護されました」が出る理由
Windowsアプリ配布時にSmartScreen警告が出る理由を、コード署名、EV/OV証明書、Azure Artifact Signing、MSIX、Microsoft Store、ClickOnce、社内配布、App Controlまで実務目線で整理します。
IEモード依存システムの脱却ガイド
Microsoft Edge の IE モード依存をかかえた社内 Web システムを安全に延命しつつ脱却する実務手順を、サイトリスト集中管理、ニュートラルサイト、WebView2 ラッパー、段階的リファクタリング、VDI 隔離、ガバナンス設計まで読者がそのまま着手できる粒度...
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。