Intune で WinGet アプリを設定したい場合、そのプロセスはシンプルであるはずです。結局のところ、WinGet はすでに数千もの Windows アプリについて、インストーラーの URL、バージョン、サイレントスイッチを把握しているのですから、Intune でそのカタログを指定して設定できるはずですよね？
ただし、落とし穴があります。Intune には、WinGet community repository から直接設定できるアプリの種類がなく、Microsoft Store のアプリにしか対応していません。さらに厄介なのは、スクリプトが SYSTEM として実行される場合、WinGet のコマンドラインツールはサポートされないことです。これは、アプリのインストール動作が System に設定されているときに Intune が使用するコンテキストです。
それを踏まえて、IntuneでWinGetを設定するにはどうすればよいのでしょうか？設定を簡単にできる4つの方法を特定しました。それぞれの内容、コスト、設定方法、そして発生する可能性のある問題への対処方法を確認していきましょう。
Intune は WinGet アプリをネイティブに展開できますか？
一部です。Intune のMicrosoft Store app (new)タイプでは、Windows Package Manager を使用して Microsoft Store からアプリを検索し、インストールします。ほとんどの WinGet ガイドで使われている公開カタログである WinGet community repository にはアクセスできず、Intune のどのアプリタイプもそこから設定することはできません。community repository のアプリを設定するには、スクリプトラッパーまたは Win32 パッケージが必要です。
その違いは、WinGetがどのように構成されているかに起因します。アプリは、Microsoft Store（msstore）とGitHub上のWinGetコミュニティリポジトリという2つの主要なソースから取得されます。廃止されたMicrosoft Store for Businessに代わるIntuneのStore統合は、最初のソースにのみ接続します。
Intune WinGetに関する議論では、MicrosoftのEnterprise App Catalogについても言及されることがあります。これはMicrosoftが用意してホストしているWin32アプリの別個のライブラリであり、MicrosoftはWinGetを使用していないと述べています。また、Intune Plan 1またはPlan 2に加えて、別途サブスクリプションも必要です。
IntuneでWinGetを使う4つの方法
Intune で WinGet アプリを設定したい場合でも、まだ実現する方法はあります。以下は、WinGet を Intune で使用する最も一般的な 4 つの方法です。それぞれの最適な用途と制限事項も含めてご紹介します。
方法 | アプリのソース | 追加ライセンス | 主な制限 | 最適な用途 |
1. Microsoft Store アプリ（新規） | Microsoft Store（msstore） | Intune以外はありません | Store に掲載されているアプリのみ。Win32 Store アプリは現在もプレビュー版です | ベンダーがMicrosoft Storeに公開しているアプリ |
2. WinGetスクリプトをラップしたWin32アプリ | WinGetコミュニティリポジトリ | Intune以外はありません | インストール、検出、アンインストールのスクリプトを作成して保守します。WinGet は検出され、SYSTEM の下で実行される必要があります | コミュニティアプリの短いリストと、PowerShellに慣れたチーム |
3. WinGet アップグレードを実行する修復 | WinGetコミュニティリポジトリ | Windows Enterprise E3/E5 または Education A3/A5 | インストール済みアプリを最新の状態に保てますが、初回インストールには対応していません | すでにアプリがインストールされているデバイスの更新管理 |
4. インストーラーから作成されたネイティブWin32パッケージ | WinGet マニフェストまたはベンダーを通じて見つかったインストーラー | Intune以外はありません | あらゆるアプリとバージョンに対応するパッケージ化、検出ルール、テスト | 大規模環境でも制御された、テスト済みの設定 |
各方法の仕組みを、ステップごとにご紹介します。
方法 1: Microsoft Store app (new) タイプで Microsoft Store アプリを設定する
アプリを設定する最初の方法（そしておそらく最も簡単な方法）は、Microsoft Storeアプリを使うことです。これは、いくつかの簡単なステップですばやく行えます。
Intune管理センターで、［アプリ］→［すべてのアプリ］→［作成］の順に移動し、［ストアアプリ］で［Microsoft Store app (new)］を選択します。
「Search the Microsoft Store app」を選択し、名前、発行元、または Store app ID で必要なアプリを検索します。結果には、各アプリが Win32 か UWP かが表示されます。
事前入力されたアプリ情報を確認し、[インストールの動作] を [システム] または [ユーザー] に設定し（一方しかサポートしていないアプリもあります）、Company Portal オプション（おすすめアプリやカテゴリなど）を設定します。
アプリを［必須］、［登録済みデバイスで使用可能］、または［アンインストール］として割り当て、エンドユーザー通知、再起動の猶予期間、インストール期限を設定します。
確認して作成します。Intune は、新しいバージョンが公開されるとアプリを最新の状態に保ちます。
とはいえ、いくつかの制限事項や前提条件があるため、把握しておく必要があります。これらによってプロセスが複雑になることがあり、別の方法を試す必要が生じる場合があります。
デバイスには、Intune Management Extension、少なくとも2つのプロセッサコア、およびStoreと発行元のコンテンツへのネットワークアクセスが必要です。
Store の Win32 アプリはまだプレビュー版で、すべての Win32 アプリを検索できるわけではありません。同様に、有料アプリと ARM64 インストーラーには対応していません。
Store からの Win32 アプリは、Intune で割り当てられている間だけ更新された状態が維持されます。
Entra に登録されたデバイスでは、インストール動作に [System] を使用する必要があります（そのため [User] は選択できません）。
方法2：WinGetコマンドをWin32アプリにラップする
Microsoft Storeアプリが要件に合わない場合は、WinGetコマンドをWin32アプリにラップして、Intune経由でWinGetを設定できます。このような場合、Win32アプリにはステータス検出、リターンコード、アンインストールコマンドが含まれており、1行スクリプトの設定にはそれらがないため、通常のプラットフォームスクリプトよりも信頼性が高くなります。
Intune が SYSTEM として実行されると WinGet が失敗する理由
Win32アプリのインストール動作が System に設定されている場合、Intune はそのインストールコマンドを SYSTEM として実行します。WinGet が機能しなくなるのはそのためです。WinGet CLI は SYSTEM コンテキストではサポートされていません。これは、WinGet CLI がユーザーごとに登録されるパッケージ化された（MSIX）アプリである App Installer に含まれているためです。その結果、通常、SYSTEM は WinGet を見つけられないため、SYSTEM スクリプト内で WinGet を名前で呼び出しても失敗します。
いくつかの回避策があります。コミュニティスクリプトでは通常、C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe 配下の winget.exe を特定することでこの問題に対応しますが、これは Microsoft がサポートしている方法ではありません。Microsoft がサポートしている方法は、Microsoft.WinGet.Client PowerShell モジュールを使うことです。これは、マシン全体にインストールされたアプリに対して system コンテキストで動作します。
インストールスクリプトを作成する
インストールスクリプトを作成するには、まずパッケージ ID を見つけてから、コミュニティリポジトリでその正確な ID を指定してインストールします。ID は winget search <app name> で検索するか、コマンドラインを使わずに、Splashtop の無料 WinGet カタログブラウザー winstall で確認できます。ID がわかったら、インストールコマンドは次のようになります。winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements
SYSTEMインストールでは、--scope machine を含めることをおすすめします。なお、MicrosoftはEXEインストーラーではscopeが一貫して処理されないと警告しています。
Microsoft Intuneでは、インストールコマンドに最大50 KBのPowerShellスクリプトを指定できます。コマンド欄でpowershell.exeを使用すると32ビット版が起動し、Sysnativeパスを使用すると64ビット版のPowerShellを利用できます。
検出スクリプトを追加
アプリが正しくインストールされたことを検出して確認するスクリプトを必ず追加してください。Intuneがアプリをインストール済みとしてカウントするのは、スクリプトがコード0で終了し、STDOUTに出力を書き込んだ場合のみです。STDERRへの出力がある場合は、未インストールと判定されます。このスクリプトでは通常、アプリのインストールフォルダー、ファイルバージョン、またはアンインストール用のレジストリキーを確認します。winget list で確認すると同じSYSTEMの問題に当たるため、ファイルまたはレジストリのチェックを使うほうが適切です。
スクリプトをパッケージ化して Win32 アプリをアップロード
最後に、Microsoft Win32 Content Prep Tool でスクリプトをパッケージ化し、.intunewinファイルを生成します。その後、Apps → All apps → Add → Windows app (Win32) でそのファイルを追加し、インストールの動作を System に設定して、アンインストールコマンド、検出スクリプト、要件を追加できます。Intune はそこでは環境変数を展開しないため、アンインストールコマンドではフルパスを使用してください。
すべてのアプリにはそれぞれ専用のスクリプトセットと更新が必要であり、WinGet はインストール先の各デバイスに存在し、正常に動作している必要があることに留意してください。そのため、この方法は他の方法よりも保守の負荷が高くなる傾向があります。
方法3: Intune RemediationsでWinGetアプリを最新の状態に保つ
Intune Remediations では、検出スクリプトと修復スクリプトを組み合わせることができます。WinGet の場合、検出スクリプトはインストール済みアプリに新しいバージョンがあるかどうかを確認し、ある場合は修復スクリプトがそのパッケージ ID に対して winget upgrade を実行します。これは方法 2 および 4 と組み合わせる更新方法としては機能しますが、初回インストールには対応していません。
まず確認すべきはライセンスです。Intune Remediations には Windows Enterprise E3 または E5（Microsoft 365 F3、E3、または E5 に含まれます）、もしくは Windows Education A3 または A5 が必要です。また、デバイスは Intune 管理または共同管理されており、Windows Enterprise、Professional、または Education を実行している必要があります。
Intune Remediations でアプリを最新の状態に保つには、いくつかの簡単な手順に従うだけです。
Intune 管理センターで、[デバイス] → [デバイスの管理] → [スクリプトと修復] に移動します。
利用可能なアップグレードがあるかどうかを確認するために、パッケージ ID をチェックする検出スクリプトを含むスクリプトパッケージを作成します。
そのIDに対して
--silentと両方の--acceptフラグを使用してアップグレードを実行する修復スクリプトを追加します。これをデバイスグループに割り当て、更新を確認するスケジュールを設定します。
アップグレードしたい特定のパッケージ ID を対象にしていることを確認してください。winget upgrade --all を使用することもできますが、その場合は WinGet が認識するすべてのアプリが更新され、IT 部門が承認またはテストしていないものまで含まれます。また、WinGet はリポジトリ内の最新バージョンをインストールするため、IT チームがテストする前に更新が展開される可能性がある点にも注意してください。修復スクリプトが SYSTEM として実行される場合、方法 2 で説明したのと同じ WinGet の制限に当たります。
方法4：インストーラーをネイティブWin32アプリとしてパッケージ化する
インストーラーをネイティブ Win32 アプリとして再パッケージ化することも可能です。この場合、WinGet はアプリ自体ではなく、アプリ情報のソースとして機能します。WinGet マニフェストを使用してインストーラーとそのサイレントスイッチを見つけることで、インストーラーを標準の Win32 アプリとして設定できます。
つまり、デバイスは動作する WinGet クライアントがなくてもアプリを設定でき、SYSTEM コンテキストの問題も当てはまらず、Intune の Win32 機能をフルに利用できます。
インストーラーは数ステップでWin32アプリとしてパッケージ化できます。
winget searchでパッケージIDを見つけるか、winstall で確認し、インストーラーの種類、ダウンロードURL、サイレントスイッチについてマニフェストを確認します。（WinGetでは、一覧に含まれるすべてのインストーラーがサイレントインストールに対応している必要があります。）WinGet またはベンダーからインストーラーをダウンロードします。
そのインストーラーの種類に対応するサイレントインストールコマンドを確認してください。MSI サイレントインストールとEXE サイレントインストールに関するガイドでは、各インストーラーの種類に対応するスイッチを紹介しています。
Microsoft Win32 Content Prep Tool でインストーラーをラップして、.intunewinファイルを作成します。
インストールコマンドとアンインストールコマンド、検出ルール（MSI 製品コード、ファイル、またはレジストリによる）、要件、リターンコードを含めて、Windows アプリ（Win32）として追加します。
より多くのデバイスに展開する前に、クリーンなテストデバイスで、アプリのインストール、インストール完了の検出、アンインストールがどの程度うまく機能するかをテストしてください。
新しいバージョンがリリースされるたびに、ビルドをやり直し、置き換え機能を使って古いアプリを置き換える必要があります。
このオプションでは、IT チームが最も細かくカスタマイズして制御できますが、その一方で、アプリやアップデートごとにこのプロセスを繰り返す必要があります。その結果、アプリカタログが大規模なチームでは、作業負荷に対応しきれない可能性があります。
では、最も効果的な方法はどれでしょうか？それぞれを整理して、どのような場合にそのトレードオフに見合うのか、またどのような場合に別の方法のほうが適しているのかを見ていきましょう。
Intune における WinGet と Win32 アプリの比較：最適なアプローチはどれか
重要な選択肢は、デバイスがインストール時に WinGet を実行するか、事前にパッケージ化した Win32 アプリを受け取るかです。2 つの違いは次のとおりです。
比較項目 | インストール時の WinGet（方法 2 および 3） | パッケージ化されたWin32アプリ（方法4） |
デバイス上の WinGet クライアント | 必須であり、SYSTEM の下で動作する必要があります | 不要 |
インストーラーの入手元 | マニフェスト内のURLから各デバイスにダウンロード | 一度 .intunewin として Intune にアップロードファイル |
インストールされるバージョン | リポジトリに記載されている内容が何であっても、 | パッケージ化してテストした正確なビルド |
検出 | 自分で作成して管理するスクリプト | 組み込みのMSI、ファイル、レジストリのルール、またはスクリプト |
更新 | 修復、またはアプリごとの新しいスクリプト | 新しいパッケージと置き換え設定 |
事前の手間 | アプリごとの負荷が低い | アプリごとのコストが高い |
各オプションを比較すると、いくつかの重要なポイントが見えてきます。リスクの低い少数のユーティリティであれば、WinGetスクリプトは迅速に使え、事前の手間も少なくて済みます。業務アプリ、規制対象のデバイス、または大規模なカタログでは、展開前にバージョンを予測可能な形で管理し、テストも行えるため、パッケージ化されたWin32アプリの方が信頼性に優れています。
アプリが Microsoft Store に掲載されている場合、通常は方法 1 が最も手軽な選択肢です。
Intune で WinGet アプリを設定する際によくある問題
適切な方法を使っても、Intune で WinGet アプリを設定するには課題があります。IT チームはアプリの設定時に一般的な問題に直面することがありますが、それらを特定して対処できます。
よくある問題は次のとおりです。
1. IntuneスクリプトでWinGetが認識されない
スクリプトで winget が認識されないと報告される場合、そのスクリプトは SYSTEM として実行されている可能性が高く、App Installer はユーザーごとに登録されるため、その環境では WinGet CLI はサポートされていません。この問題には、winget.exe をフルパスで指定して解決するか、方法 2 で説明した Microsoft.WinGet.Client PowerShell モジュールを使用することで対応できます。
2. アプリが誤ったユーザー向け、または誤った場所にインストールされる
アプリが誤った場所にインストールされたり、誤ったユーザー向けにインストールされたりする場合は、インストールスコープの問題です。SYSTEM では、ユーザースコープは SYSTEM 自身のプロファイルに解決される一方、EXE インストーラーでは、ユーザー向けかマシン向けかのスコープ処理に一貫性がありません。これを修正するには、SYSTEM インストールで --scope machine を使用します（アプリをより広く展開する前に、必ず先にテストしてください）。
3. ダウンロードが 403 Forbidden エラーで失敗する
ダウンロード時に403 Forbiddenエラーが返される場合は、ソフトウェアベンダーがダウンロードサーバーでWinGetのユーザーエージェントをブロックしている可能性があります。ブラウザーではインストーラーを問題なくダウンロードできる場合は、それが原因である可能性が高いです。その場合は、インストーラーを直接ダウンロードし、方法4で説明したように、パッケージ化されたWin32アプリとして設定できます。
4. Store アプリが Intune の検索結果に表示されない
Store アプリが検索しても表示されない場合、原因は次の 3 つのいずれかである可能性があります。1. お住まいの地域では利用できない、2. 有料アプリのためサポートされていない、3. プラットフォームがサポートされていない。原因にかかわらず、まずはアプリの掲載情報を確認し、アクセスできない場合は方法 2 または 4 を使ってインストールしてください。
5. UWP Store アプリで「インストール後に検出されませんでした」(0x87D1041C) と表示される
このアラートが表示された場合、すでにそのアプリがあるデバイスに、Systemのインストール動作でUWPアプリが割り当てられていることを意味します。この場合も心配はいりません。アプリは正しくインストールされています。Microsoftも、同じアプリでユーザーコンテキストとシステムコンテキストを混在させないことを推奨しています。
6. WinGet のインストールが失敗した理由を確認する
WinGet のインストールが失敗し、理由がわからない場合は、原因を調査して特定し、対処できます。コマンドに --verbose-logs を追加すると完全なログを取得でき、winget error <code> を実行すると終了コードを説明文に変換できます。これは WinGet、MSIX、MSI のコードを対象としていますが、多くの EXE インストーラーでは標準外のコードが使われることがあります。それらの見つけ方については、EXE silent install guideをご覧ください。
Splashtop Agentic Packr が WinGet アプリをテスト済みの Intune パッケージに変える方法
Intune で WinGet アプリを設定するのは複雑になりがちですが、そうである必要はありません。適切な自動化により、チームは IT リソースを圧迫することなく、インストーラーをすばやく効率的にパッケージ化できます。
そこで登場するのが、最新のITチーム向けに設計された、AI搭載のアプリケーションパッケージ化および設定ツールSplashtop Agentic Packrです。Splashtop Agentic Packrを使えば、Microsoft Intune、SCCMなどを通じて、はるかに少ない手作業でアプリケーションをパッケージ化、検証、設定できます。
Splashtop Agentic Packr には、次のような複数の機能とメリットがあります。
1. ソースとしての WinGet。デバイスに WinGet クライアントは不要
Splashtop Agentic Packr は、検証済みの WinGet カタログ、WinGet または Chocolatey のパッケージ ID、あるいは独自のインストーラーからアプリをパッケージ化できます。Intune ネイティブの Win32 アプリを構築するため、ユーザーがよく直面する WinGet や SYSTEM コンテキストの問題を気にする必要はありません。
2. 配布前に作成・テストされた検出ルール
AI搭載エージェントがインストーラーを読み取ると、検出ルールを作成し、クリーンな仮想マシン上でビルドをテストします。これらのテストでは、インストール、検出、アンインストールが正しく機能するかを確認し、マルウェアスキャンを実行したうえで、アプリがIntuneに届いてデバイス全体に設定される前に、IT管理者が確認できるQAスコアカードとログを生成します。
3. 手動で再ビルドしなくても公開と新しいバージョンに対応
Splashtop Agentic Packr を使えば、新しいアップデートが出るたびにパッケージを手動で再構築する必要がなくなります。Intune テナントへのワンクリック Express 接続と自動バージョン更新により、Agentic Packr は新しいアップデートを検出し、パッケージ化し、テストし、管理者が各アップデートを手動で処理しなくても更新済みパッケージを展開します。
4. ユーザーに表示される内容のコントロール
Splashtop Agentic Packr を使うと、インストールやアップデートをユーザーにどのように表示するかを IT 部門でコントロールできます。チームはエンドユーザー向け通知、延期、再起動プロンプト、猶予期間をカスタマイズできるため、必須のインストールやアップデートによってユーザーの作業が途中で中断される可能性を減らせます。
スクリプトを維持管理することなく WinGet アプリを Intune に設定
WinGet はアプリ情報の強力なソースであり、Intune はアプリの設定に非常に優れていますが、Intune から WinGet コミュニティ リポジトリを直接使って設定することはできません。スケールしやすい方法は、WinGet のエントリをテスト済みの Win32 パッケージに変換することです。
Splashtop Agentic Packr を使えば、アプリパッケージの作成、テスト、公開を、はるかに少ない手作業で行えます。Agentic Packr なら、1 つのコンソールでアプリのパッケージ化、設定、アップデートを行いながら、管理者のコントロールを維持したまま、パッケージ化をより迅速かつ簡単に行えます。
手間をかけずにIntuneでWinGetアプリを設定したいですか？Splashtop Agentic Packrが今すぐどのように役立つかをご覧ください。
