Windows デスクトップアプリを顧客企業に提供するとき、避けて通れないのが「顧客企業の管理対象 PC にどう届けるか」という問題です。受け入れ側の IT 部門は、ほぼ確実に Microsoft Intune や Microsoft Configuration Manager、もしくは両者の Co-management でデスクトップアプリを束ねており、ベンダーから渡された MSI や EXE をそのまま全社展開できるかどうかで採用判断が変わります。

Intune まわりのアプリ配布は、2026 年時点で複数の前提が以前と異なります。Microsoft Store for Business / Education は廃止済みで、後継は新しい Microsoft Store アプリへ移行しています。SmartScreen はすべての署名を評判ベースで判定するため、EV コードサイニング証明書でも即時バイパスは効きません。OV コードサイニング証明書は HSM / ハードウェアトークンでの鍵保管が必須で、Microsoft 推奨の Azure Artifact Signing（旧 Trusted Signing） も日本法人からの Public Trust 利用ができない、というのが現状です。

本記事では、自社開発の Windows デスクトップアプリを顧客企業の Intune で配布したいソフトウェアベンダー視点で、Win32 アプリ／LOB／MSIX／Microsoft Store の使い分け、.intunewin の作り方と検出ルール、コード署名の現実、自動更新の責務分担、テナント設定の注入、顧客 IT 部門に渡す成果物まで、設計要点を一気に整理します。

なぜ Win32 アプリが新規の一次選択になるのか

2026 年時点で、Intune に新規アプリを乗せるときの「迷ったらこれ」は Win32 アプリ（.intunewin） です。これは Microsoft Learn、Andrew Taylor の解説、Patch My PC のガイド、Recast Software の検出ルール解説まで、業界の主要な情報源が一致しているところでもあります。

理由は、Win32 アプリだけが Intune Management Extension（IME） というサイドカーエージェント経由で配布されるため、以下を一貫して扱えるからです。

• カスタム検出ルール（MSI ProductCode、ファイルバージョン、レジストリ、PowerShell）
• 要件ルール（OS バージョン、アーキテクチャ、空き容量、メモリ、CPU、レジストリ、PS スクリプト）
• 依存関係（最大 100 個、自動インストール可）
• 置換動作（Supersedence、最大 10 個）
• リターンコードのカスタマイズと再起動制御
• 配信最適化（Delivery Optimization）の対象

一方、伝統的な LOB アプリ（業務アプリ） は OS 標準の MDM エージェントが直接処理するため、検出は MSI 製品コード固定で複数ファイルや依存関係を扱えません。新規アプリで LOB を選ぶ理由は、「単一の MSI で前提条件もなく、引数も実質ひとつで済む」場合に限られます。

Microsoft Store for Business / Education は廃止済みで、後継として現行の Microsoft Store アプリ（new） が Intune から WinGet マニフェスト経由で UWP / MSIX / Win32 を扱える形になっています。Intune が自動で最新版に追随する反面、Store 掲載と公開配布が前提になるので、エンタープライズ向け BtoB SaaS のクライアントアプリの一次選択にはなりにくい、というのが現実です。

ソフトウェアベンダーとしての結論はシンプルで、「新規アプリは Win32 アプリで Intune に乗せ、LOB はごく単純な MSI に限定し、Store はオプション扱いにする」が出発点になります。

MSIX を選ぶか、MSI ベースで Win32 化するか

Win32 アプリは「Intune の配布モデル」であって、その中身は MSI でも EXE でも PowerShell でも構いません。ベンダーがまず決めるのは「ソースのパッケージ形式を MSI 系にするか MSIX にするか」のほうです。

MSIX は UWP の後継として設計された比較的新しい形式で、コンテナ化、差分更新、クリーンアンインストール、.appinstaller による自動更新といった機能が魅力的です。ただし、MSIX のサンドボックスにはコンテナ起因の制約があり、以下の特徴をもつアプリには向きません。

• カーネルモードドライバーや一部のシェル拡張を含む
• HKLM への直接書き込みを前提にしている
• ユーザーごとに Windows サービスを登録する
• 起動時に常時 UAC 昇格を必要とする
• Outlook アドインや Office との深い COM 連携を持つ

Microsoft 自身、Microsoft Store 版の Microsoft 365 Apps（MSIX 配布）を サポート終了の方針 としており、こうしたコンテナ起因の制約に向き合う必要が出てきています。Office のような複雑な COM / Add-in / 連携アプリには MSIX のサンドボックスが向かなかった、と Advanced Installer のブログ などが解説しています。

逆に、MSIX に乗ると以下の利点があり、新規アプリで深い OS 統合がない場合は十分に候補になります。

• 署名された整合性保護（改ざん検知）
• 差分更新による帯域削減
• アンインストール時に仮想レジストリと仮想ファイルが綺麗に消える
• .appinstaller で OS が起動時 / 定期チェックでアップデートしてくれる

ソフトウェアベンダー視点での実務判定は、「ドライバー・サービス・シェル拡張・HKLM 書き込み・常時昇格の有無を確認し、いずれもなければ MSIX を検討、ひとつでもあれば MSI を WiX で生成して .intunewin に包む Win32 アプリを選ぶ」になります。Electron や WPF のような新しめの GUI フレームワークで、深い OS 統合がない場合だけ MSIX が現実解、という整理です。

flowchart TD
    Start[配布したい Windows アプリ] --> Q1{ドライバー / シェル拡張 / HKLM / ユーザーサービス / 常時昇格?}
    Q1 -- いずれかあり --> MSI[MSI を生成し Win32 で配布]
    Q1 -- なし --> Q2{Store 公開を許容できる?}
    Q2 -- できる --> Store[Microsoft Store アプリ - new]
    Q2 -- できない --> Q3{OS 統合は浅い?}
    Q3 -- 浅い --> MSIX[MSIX を Win32 / LOB で配布]
    Q3 -- 深い --> MSI

Electron アプリでは、electron-builder の NSIS インストーラが既定で %LOCALAPPDATA% への per-user 配置になり（oneClick: false + perMachine: true の追加設定で per-machine 化は可能ですが、既定ではない）、エンタープライズ配布で詰みやすいため、electron-wix-msi で ALLUSERS=1 の per-machine MSI を作るのが第一候補です。Microsoft ISE の事例（Packaging an Electron app for managed distribution）でも、Intune での Electron アプリ配布のために WiX Toolset で MSI を作り、.intunewin 化しています。.NET 系（WPF / WinForms / WinUI 3）も同じく WiX や Advanced Installer で MSI を生成し、Self-contained で .NET ランタイムを同梱するか別アプリ依存関係にするかを IT 部門と握る、という運用が無難です。

.intunewin 化と検出ルール

ソース形式が決まったら、Intune に渡す .intunewin を作ります。これは Microsoft Win32 Content Prep Tool（IntuneWinAppUtil.exe） で生成するもので、指定したフォルダ配下のファイル一式を暗号化 ZIP として包みます。

IntuneWinAppUtil.exe -c <SourceFolder> -s <SetupFile> -o <OutputFolder> [-q]

実務での落とし穴は 2 つあります。1 つは「Content Prep Tool 自体を SourceFolder に含めない」こと（含めると .intunewin の中に同梱されてしまいます）。もう 1 つは「アプリサイズ上限 30 GB」と「サイレントインストール対応必須」という制約で、この 2 つを満たさない場合は Intune にそもそも乗りません。

検出ルールは Intune が「インストールに成功したか」を判断する基準で、ここを誤ると、インストール済みの端末で再インストールが走り続けたり、逆に失敗しているのに成功と報告されたりします。Win32 で使える検出ルールは 4 種類あり、用途で使い分けます。

ベンダー視点での要点は、「ProductCode はバージョンごとに新規生成し、UpgradeCode は製品の生涯を通じて固定」というセオリーを WiX の <MajorUpgrade> 要素 で正しく宣言することです。これにより MSI ベースの Supersedence が成立し、Intune の Win32 でも自然にアップグレードが走ります。version-aware にしないと旧版が「インストール済み」と判定されてしまい、新版のインストールが起動しません。

Win32 アプリの PowerShell スクリプトインストーラーオプション（インストールロジックを .intunewin から分離して Intune 管理センター上で編集できる機能）も活用できます。コアバイナリだけを .intunewin 化し、顧客ごとの設定は PowerShell 側で持つ、といった運用が可能になります。

検出ルールの例を顧客 IT 部門に渡す形式まで含めると、こうなります。

# Intune Win32 検出ルール例（MSI 用）
detection_rules:
  type: MSI
  msi_product_code: "{12345678-90AB-CDEF-1234-567890ABCDEF}"
  msi_product_version_check: yes
  msi_product_version_operator: greater_than_or_equal
  msi_product_version_value: "1.2.3.0"
 
# 代替: ファイルバージョン検出
alternative:
  type: File
  path: "%ProgramFiles%\\YourCompany\\YourApp"
  file: "YourApp.exe"
  detection_method: version_greater_than_or_equal
  version: "1.2.3.0"
  associated_with_32bit: false

インストールコンテキストとサイレントインストール

Win32 アプリの「インストール動作（Install behavior）」は System / User の 2 択ですが、エンタープライズ配布では System コンテキストが標準です。理由は次のとおりです。

• 全ユーザーで使える per-machine 配置になる
• Windows サービスの登録、Defender 除外、HKLM への書き込みが可能
• Autopilot Enrollment Status Page（ESP） のデバイスフェーズで完了でき、ユーザーログオンを待たない
• Microsoft Entra 登録済みデバイスでは System が事実上の前提

System コンテキストを選ぶと、MSI には ALLUSERS=1（既定）が渡されます。ベンダーとしては、MSIINSTALLPERUSER=1 のような per-user フラグを暗黙に有効化しないこと、ALLUSERS で動かなくなるカスタムアクションを書かないことを CI で検証しておくのが安全です。

Intune は 対話型インストールをサポートしません。途中で UI ボタン押下や UAC 応答を要求するセットアップは、System コンテキストでハングアップして失敗します。Microsoft も serviceui.exe のような方法でユーザーセッションとの対話を強制する手法をサポート対象外と明記しています。検証時は Sysinternals の psexec で psexec -s -i cmd.exe を起動し、SYSTEM プロンプトの中でサイレントインストールが完走することを確認するのが定番です。

サイレントインストールのコマンドは、ベンダーの責務として必ずドキュメント化します。

:: 標準サイレントインストール（最小要件）
msiexec /i "YourApp-1.2.3.msi" /qn /norestart /l*v "%TEMP%\yourapp-install.log"
 
:: 設定注入付き
msiexec /i "YourApp-1.2.3.msi" /qn /norestart ^
  TENANT_ID="acme-corp" ^
  API_BASE_URL="https://api.example.com" ^
  ALLUSERS=1
 
:: アンインストール
msiexec /x {YOUR-PRODUCT-CODE-GUID} /qn /norestart /l*v "%TEMP%\yourapp-uninstall.log"

EXE インストーラーの場合は /silent、/S、/quiet、/qn が乱立しているので、自社の選択を一覧表として明示します。これを書いていない MSI / EXE は、IT 部門の検証段階で必ず止まります。

依存関係、Supersedence、自動更新の責務分担

Win32 アプリの依存関係は最大 100 個まで指定でき、ターゲットアプリのインストール前に自動的に依存先がインストールされます。ベンダー視点での実務指針は「依存グラフを薄く保つ」ことで、.NET Desktop Runtime、VC++ Redistributable x64、VC++ Redistributable x86 程度の最小構成に絞り、それぞれを Intune の別アプリとして登録した上で Win32 の依存関係に紐づけてもらう、という設計が安定します。

.NET Desktop Runtime は WPF / WinForms を動かすために必要で、純粋な .NET Runtime では足りません。C++ アプリでは 最新の Visual C++ 再頒布可能パッケージ が必要で、ビルドに使った MSVC ツールセット以上に新しいバージョンを入れる必要があります。アーキテクチャ（x64 / x86 / ARM64）も一致させます。

Supersedence（置換動作） は旧版を新版に置き換える設定で、1 つのアプリに対して最大 10 個まで連結できます。「Uninstall previous version」のフラグで挙動が変わります。

• No: 上書きアップグレード（自分でハンドルできるアプリ向け、MSI の <MajorUpgrade> で動く）
• Yes: 旧版アンインストール → 新版インストール（クリーンに切り替えたいとき）

ここで現場が引っかかるのが、Available 割り当てに Auto-update トグルと Supersedence を組み合わせて初めて自動更新が走り、反映には 2 回のチェックインが必要で、通常 8〜16 時間かかる という点です。「リリース当日に全端末が新バージョンに切り替わる」前提で運用すると、ヘルプデスクへの問い合わせが集中します。CS や顧客 IT 管理者に「反映ラグを織り込んだ波状運用」を事前共有するのがベンダーのマナーです。

自動更新は、ソフトウェアベンダー視点で姿勢を反転させるべきポイントです。Squirrel.Windows、electron-updater、自前の MSI ダウンローダーといった「アプリ内の自動更新機構」を有効にしたままエンタープライズに送ると、以下の理由で嫌われます。

• 検証済みのバージョンを固定したい（金融、医療、自治体）
• WSUS / Intune / SCCM のリングで段階展開している
• 帯域、プロキシ、TLS インスペクションがアップデーターと相性が悪い

ベンダーの推奨デフォルトとしては、

1. アプリ内自動更新を 既定で OFF にする
2. レジストリキーまたは ADMX で EnableAutoUpdate=1 のときだけ ON
3. Intune の Supersedence でリプレースする運用を「正」とする
4. 中小顧客向けに Stable / Beta のチャネル分けを別途提供

の 4 点を抑えるのが現実解です。

コード署名 — SmartScreen と HSM と日本企業の事情

コード署名は、出所証明、改ざん検知、SmartScreen 警告の軽減、AppLocker / WDAC のポリシー許可、PowerShell 実行ポリシー（AllSigned）の通過まで、複数の運用に効く基盤です。2026 年時点で押さえておくべき前提が 3 つあります。

1 つ目は、EV コードサイニング証明書でも SmartScreen の即時バイパスは効かない ことです。SmartScreen はすべての署名を評判ベースで判定するため、新規ビルドは OV / EV / Azure Artifact Signing のどれで署名しても、評判が蓄積するまで Windows protected your PC 警告が出る可能性があります。EV を新規取得しても SmartScreen 緩和には寄与しません。

2 つ目は、OV コードサイニング証明書は HSM / ハードウェアトークン必須 であることです。CA / Browser Forum Baseline Requirements により、新規 / 再発行される OV 証明書は FIPS 140-2 Level 2 / Common Criteria EAL 4+ 準拠ハードウェアで秘密鍵を生成する必要があり、CSR 経由のブラウザ申請はできません。CI / CD への組み込みは、CA が発送する USB トークンをビルドサーバーに物理接続するか、DigiCert KeyLocker や Sectigo Cloud Signing のようなクラウド HSM サービスに切り替えるかの二択です。

3 つ目は、Microsoft が推奨する Azure Artifact Signing（旧 Trusted Signing） は、Public Trust 利用が米国・カナダ・EU・英国の組織に限定されている ことです（Artifact Signing FAQ 参照）。日本法人は Public Trust 対象外で、Private Trust 用途（社内 PKI 想定）でしか使えません。日本のソフトウェアベンダーが顧客企業に外部配布する場合の現実解は、当面は国内で OV コードサイニング証明書を取得する形になります。

国内での購入経路としては、GMO グローバルサイン のコードサイニング証明書が無難です。USB トークンを国内発送するため海外開発拠点には送れない制約があるものの、日本語の手順書とサポート、HSM 格納タイプ（自動署名サーバー用途で 2023 年に新設）、法人実在性審査の登記簿・帝国データバンクとの連携など、日本企業向けの実務が揃っています。クロストラスト、GeoTrust ジャパン、Sectigo 系の代理店も選択肢で、複数 CA を比較したい場合に向きます。

署名時のセオリーは、SHA-256 + RFC 3161 タイムスタンプを必ず付与することです。タイムスタンプを付けると、コードサイニング証明書の有効期限が切れた後も Authenticode 署名が有効と検証されます。

signtool sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a "YourApp.msi"

# MSIX
signtool sign /fd SHA256 /td SHA256 /f .\codesign.pfx /p <password> /tr <timestamp-url> .\YourApp.msix
signtool verify /pa /v .\YourApp.msix

テナント設定とライセンスの注入 — MSI プロパティと ADMX

BtoB SaaS のクライアントアプリは、ほぼ必ず「テナント ID」「API ベース URL」「ライセンスキー」を顧客ごとに渡す必要があります。注入ポイントの設計は、配布手段とアプリ側の読み出しタイミングの両方に効きます。

ベンダー側の推奨デフォルトは、「MSI のパブリックプロパティで初期値を入れ、ADMX / ADML でランタイム上書きを許す、最終フォールバックはアプリ初回起動時のオンライン認証」という三段構えです。

MSI のパブリックプロパティは大文字命名（TENANT_ID、LICENSE_KEY、API_BASE_URL）にします。小文字だと secured property になり、コマンドラインから渡せません。WiX では <Property Id="TENANT_ID" Secure="yes"/> で定義し、CustomAction でレジストリや設定ファイルに書き出します。

ADMX / ADML の Intune 取り込み は、エンタープライズ顧客にとっての標準的な設定配布経路です。ベンダー側で YourProduct.admx と多言語対応の .adml を提供しておけば、顧客 IT 部門は GPO と Intune の両方で同じテンプレートを使えます。Intune 側ではカスタム構成プロファイルで以下の OMA-URI を設定します。

./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/<ProductName>/Policy/<ProductName>Admx

そして個別のポリシーは：

./Device/Vendor/MSFT/Policy/Config/<ProductName>~Policy~<Category>/<SettingName>

アプリ側は HKLM\SOFTWARE\Policies\<Vendor>\<Product> を最優先で読み、フォールバックとして HKLM\SOFTWARE\<Vendor>\<Product> → HKCU\SOFTWARE\<Vendor>\<Product> の順に読む設計にすると、顧客が GPO で強制ポリシーをかけたとき期待どおりに優先されます。

ネットワーク、配信最適化、プロキシの罠

Intune 配布は、IME（Intune Management Extension）が .intunewin をクラウドからダウンロードし、C:\Windows\IMECache\ に展開してインストールします。大量配布時のボトルネックは帯域なので、Delivery Optimization（配信最適化） を理解しておきます。

Delivery Optimization は同一ネットワーク内の PC 同士で P2P 転送するキャッシュ技術で、Intune 配信の Win32 アプリは自動的に対象になります。設定の要は「ダウンロードモード」で、推奨は次のとおりです。

ベンダー側で意識すべきは、.intunewin 1 ファイルあたりが小さければ Delivery Optimization の P2P 効果が薄いという点です。50 MB 未満のアプリは P2P をすり抜けて全端末が直接ダウンロードしますが、これはほとんどの BtoB SaaS のクライアントには許容範囲です。逆に 500 MB を超えるアプリは P2P 設計を顧客に提示しないと帯域が枯れます。

プロキシの罠も知っておきます。IME は SYSTEM アカウントで動作するため、ユーザーがブラウザで設定したプロキシ情報はその文脈では使われません。多くの企業環境で「ユーザーは Web を閲覧できているのに、Intune のアプリだけダウンロードに失敗する」という現象は、これが原因です。対策は次のいずれかです。

1. *.manage.microsoft.com や *.delivery.mp.microsoft.com などの Intune の必要エンドポイント を、認証不要かつプロキシ経由なしで直接通信できるようファイアウォールで許可する（推奨）
2. netsh winhttp set proxy で OS レベル（SYSTEM 含む）に静的なプロキシを設定する
3. WPAD で自動発見する

ベンダー側のドキュメントには、自社アプリ側の通信先 FQDN / プロトコル / ポート / 証明書情報を必ず一覧化します。

[インストール時]
- なし、ローカルのみで完結
 
[初回起動時]
- https://api.example.com/auth (TCP 443, TLS 1.2/1.3)
- https://login.microsoftonline.com (TCP 443, MSAL)
 
[テレメトリ - opt-in]
- https://telemetry.example.com (TCP 443)

TLS インスペクション を行っている顧客プロキシで、アプリが証明書ピン留めをしていると通信が壊れます。ピン留めの有無、無効化方法、WinHTTP / Schannel がシステム証明書ストアを使うことを前提にしている、といった情報も併記します。

監視とトラブルシュートの初動

Intune 管理センターでは、アプリごとに Installed / Not installed / Failed / Pending / Not applicable の状態が見られ、デバイス単位の最終チェックインとアプリバージョンも確認できます。ベンダーが顧客 IT 部門のサポート対応をするときは、これに加えて IME のクライアントログを取りに行きます。

ビューワは CMTrace または OneTrace が読みやすく、Intune 管理センターから「Collect diagnostics」でリモート 250 MB までログ取得もできます。

頻発するエラーコードのうち、ベンダー側で防げるものは次の 2 つです。

• 0x87D1BC26（検出エラー）: インストールは成功しているのに検出ルールが正しくないため Failed と報告される。インストール先パスにバージョン番号を含めない、ProductCode と UpgradeCode の運用を間違えない、で多くは防げます
• 0x87D300C9（未監視プロセスのタイムアウト）: インストーラがバックグラウンドで UI を待っている。System コンテキストでサイレント検証を CI に組み込んでいれば回避できます

Defender 等のセキュリティ製品で C:\Program Files (x86)\Microsoft Intune Management Extension\Content と C:\Windows\IMECache をスキャン除外する ことが Microsoft Learn でも推奨されており、配布が遅い・失敗するという報告があったらまずこの 2 か所の除外設定を顧客 IT 部門に確認します。

顧客 IT 部門に渡す成果物リスト

ベンダー視点の最終成果物として、ISO 27001 / SOC2 / 個人情報保護法対応も含めて顧客 IT 部門に渡すべき一式は次のとおりです。これが揃っていれば、Intune だけでなく SCCM、GPO、Workspace ONE、ManageEngine Endpoint Central、PDQ Deploy のいずれでも IT 部門が運用に乗せられます。

1. 署名済み MSI（SHA-256 + RFC 3161 タイムスタンプ）
2. .intunewin 化スクリプト（または事前生成済みの .intunewin）
3. 検出ルール例（MSI ProductCode、ファイルバージョン、レジストリの 3 通り）
4. サイレントインストール / アンインストールコマンド一覧
5. ADMX / ADML テンプレート（多言語対応）
6. MSI パブリックプロパティ一覧（TENANT_ID、API_BASE_URL、LICENSE_KEY、ENABLE_AUTO_UPDATE、TELEMETRY_OPTOUT）
7. 動作環境ドキュメント（OS、.NET、VC++ 再頒布可能パッケージ）
8. 通信要件（FQDN、ポート、TLS バージョン、ピン留めの有無）
9. AppLocker / WDAC ポリシー雛形（Publisher ベースの Allow ルール）
10. SBOM（CycloneDX または SPDX、各リリース毎）
11. 脆弱性対応ポリシー（Critical 7 日 / High 14 日 / Medium 30 日 / Low 90 日）
12. サポートポリシー（N-2 メジャーバージョン、最低 12 か月の EOL 通知）
13. Intune 配布手順書（日本語、スクリーンショット付き）

加えて、自社製品が Intune Enterprise App Catalog に取り込まれれば、IT 部門のパッケージング負担を最小化できる、という選択肢もあります。Microsoft があらかじめインストールコマンド・要件・検出ルールの既定値を検証したうえでホストし、Guided Update Supersedence による自動更新が利用できます。ベンダーが直接申請するモデルではなく、Microsoft 側のキュレーションあるいは Patch My PC のような EAM パッケージングパートナー経由でカタログ化されるのが実態です。なお、このカタログは Intune Suite 内の Enterprise App Management（EAM）アドオンが必要な有償機能で、顧客側のライセンスが前提になる点は併せて補足したうえで提案します。日本のソフトウェアベンダーにとっては、この経路が「顧客 IT 部門の運用工数を最小化する」プレミアムなオプションになります。

国内事情で踏むべきポイント

国内のエンタープライズで多い構成は、オンプレ Active Directory + Microsoft Entra Connect 同期 + Microsoft Entra ハイブリッド参加です。Cloud-Native Join への移行は進んでいますが、ファイルサーバー、内製 AD 認証アプリ、Kerberos 連携の都合でハイブリッド構成が当面残ります。ベンダー側のアプリは Hybrid Join / Cloud-Native Join のどちらでも動くこと、AD CS のクライアント証明書を要求しないこと、SaaS 側は Microsoft Entra ID 認証を前提にすることを設計に組み込みます。

日本語パスとロケールも踏みやすい地雷です。C:\Program Files\株式会社YourCompany\ のような日本語インストール先は推奨しませんが、%USERPROFILE% には日本語ユーザー名が入りえます。ファイル I/O は UTF-8 / UTF-16LE で統一し、Shift_JIS 依存は避けます。Win32 Content Prep Tool は v1.7 で Unicode サポートが改善されましたが、Source パスに日本語を含めない運用が安全です。

最後に、顧客 IT 部門は情シス兼務の少人数チームであることが多く、英語の Microsoft Learn を読みこなして配布する余裕がないケースが現場では珍しくありません。ベンダー側で日本語の Intune 配布手順書（スクリーンショット付き）を 1 本用意するだけで、採用ハードルがはっきり下がる、というのが実際のところです。

まとめ

Windows デスクトップアプリを顧客企業の Intune で配布するときの設計は、複数の選択肢を比較しているように見えて、実は出発点がほぼ収束しています。

• 新規アプリは Win32 アプリ（.intunewin）に統一する。LOB は単純な MSI に限定し、Microsoft Store for Business は廃止済み、Microsoft Store アプリ（new）は公開配布が許せる場合のみ
• MSIX に乗るかどうかは「ドライバー / シェル拡張 / HKLM / ユーザーサービス / 常時昇格の有無」で判定する。乗らなければ MSI を WiX で生成して .intunewin に包む
• コード署名は SHA-256 + RFC 3161 タイムスタンプ。EV 証明書でも SmartScreen の即時バイパスは効かず、OV は HSM / ハードウェアトークン必須、Azure Artifact Signing は日本法人が Public Trust 利用不可。国内では GMO グローバルサインの OV + USB トークンが現実解
• インストールコンテキストは System、サイレントインストール必須、UAC 応答不要が前提
• 自動更新は既定で OFF、IT 部門に Supersedence で更新してもらう運用を「正」にする
• MSI パブリックプロパティ + ADMX / ADML で設定を注入する。アプリ側は HKLM\SOFTWARE\Policies\<Vendor>\<Product> を最優先で読む
• 顧客 IT 部門には MSI、.intunewin、検出ルール、ADMX、SBOM、サポートポリシー、日本語の配布手順書まで一式渡す

これらが揃って初めて、ソフトウェアベンダーとしての「うちのアプリを Intune で配ってください」が、顧客 IT 部門にとって意思決定できる提案になります。逆にどれかが欠けていると、たとえ技術的に動くアプリでも、エンタープライズ案件の調達ゲートで止まりやすくなります。

以上、自社プロダクトとして Windows デスクトップアプリを出荷したい BtoB SaaS ベンダー視点で、Intune 配布のベストプラクティスを整理しました。MDM 経由配布の言語選定については、姉妹記事の MDM 経由でスクリプトを配布するのに最適な言語を選ぶ も併せて参照してください。

以上、Windows デスクトップアプリを顧客企業の Intune で配布するベストプラクティスをソフトウェアベンダー視点で整理した、現場からお送りしました。

参考情報

• Win32 アプリの管理（Microsoft Learn）
• Microsoft Win32 Content Prep Tool（GitHub）
• Windows 基幹業務（LOB）アプリの追加
• Microsoft Store アプリ（new）の追加
• Intune Enterprise App Catalog
• Win32 アプリ Supersedence の構成
• Delivery Optimization（配信最適化）
• MSIX とは（Microsoft Learn）
• Azure Artifact Signing の概要
• WiX Toolset 公式ドキュメント