多くの企業は、オンプレミスでもリモートでも、Windowsデバイスにアプリを配信するためにSCCM(Microsoft Configuration Manager)を利用しています。しかし、SCCMでのアプリ設定の信頼性は、それを支えるパッケージとルール次第です。
サイレントスイッチが正しくない場合、検出ルールがアプリと一致しない場合、または戻りコードがマッピングされていない場合、インストールが成功していても失敗として報告されることがあります(またはその逆もあります)。これは、Microsoft が年1回スケジュールの最初のリリースであるConfiguration Manager バージョン 2609をリリースした今、さらに重要になっています。SCCM を使い続けるチームには、すでに備わっている機能で確実に動作するアプリ配信が必要です。
それを踏まえて、SCCM のアプリケーションパッケージ化、アプリケーションの準備と設定方法、そして検出方法とリターンコードが SCCM のレポート内容をどのように決定するのかを見ていきましょう。
SCCMにおけるアプリケーションのパッケージ化とは何ですか?
アプリケーションのパッケージ化とは、SCCM が処理する前にアプリケーションを準備するための作業です。これには、インストールお よびアンインストールのコマンドの設定、サイレントインストールの有効化、構成の追加、そしてインストールをどのように確認するかの決定が含まれます。より広い概要については、アプリケーションのパッケージ化とは何かをご覧ください。
その後、SCCMが準備したアプリを設定します。SCCMはそれを1つ以上の設定タイプを持つアプリケーションとして保存し、コンテンツを配布ポイントにコピーして、提供されたファイルとルールを使って、いつ、どのようにインストールするかをクライアントに指示します。
SCCM は、与えられたものしか適用できないことを忘れないでください。そのため、Create Application ウィザードを開く前にインストールの信頼性の多くが決まるので、必要なルールや設定を使ってアプリケーションを適切に準備することが重要です。
SCCM におけるアプリケーション、パッケージ、プログラムの違い
こうした用語が次々と出てくると、少し混乱してしまうかもしれません。では、applications、packages、programs とは具体的に何を指すのでしょうか?違いは次のように整理できます。
属性 | アプリケーション | パッケージとプログラム |
アプリがインストールされているかどうかを認識 | はい、検出方法を使用します | 検出方法なし |
複数のインストール方法 | はい。要件によって選択された設定タイプが1つ以上あります | プログラムごとに1つのコマンドライン |
依存関係と置き換え | サポート対象 | 最初に別のプログラムを実行 |
最適な用途 | インストール、更新、コンプライアンス維持を行うソフトウェア | 管理者ツール、単発スクリプト、定期実行スクリプト |
こうした違いを踏まえ、Microsoft は、アプリをインストールしないツール、一度限りのスクリプト、繰り返し実行するスクリプトには、パッケージとプログラムを使うことを推奨しています。インストールして最新の状態に保つソフトウェアには、アプリケーションのほうが適しています。古いパッケージがある場合は、Package Conversion Manager を使ってアプリケーションに変換できます。
SCCM向けにアプリケーションをパッケージ化する方法
SCCM用にアプリケーションをパッケージ化する際は、いくつかの重要なステップに従う必要があります。適切なインストールに必要なコマンド、ラッパー、ルールをすべて含めることでスムーズな展開につながりますが、手順を1つでも欠かすと、インストールやレポートに問題が発生する可能性があります。
インストーラーの種類を特定する: MSI、セットアップEXE、またはMSIをラップしたEXEのいずれかであり、どれに該当するかによって以降のすべてに影響します。MSIとEXEインストーラーのガイドでは、その見分け方を解説しています。
サイレントインストールおよびアンインストールのコマンドを確認します。これらのコマンドの確認方法は、インストーラーの種類によって異なります。すべてのMSIは同じスイッチを使用しますが、EXEのスイッチはインストーラーの作成に使用されたツールによって異なります。msiexec サイレントインストールガイドとEXE サイレントインストールガイドをご覧ください。
ラップするかどうかを決めます: インストーラーで必要な場合は、PowerShell App Deployment Toolkit (PSADT) のラッパーを使用して、アプリ終了のプロンプト、延期、一貫したログ記録を追加できます。ツールキットの仕組みについては、PSADT ガイドをご覧ください。
クリーンなソースフォルダーを作成する: MSIベースのアプリケーションを作成すると、SCCM はそのフォルダー内のすべてのファイルをインポートして配布ポイントに送信するため、フォルダーにはインストールに必要なものだけを含めるようにしてください。Microsoft は、アプリケーションごとに最大20,000ファイルまで SCCM でテストしています。
アプリがインストールされていることを証明するものを記録します: MSI 製品コード、バージョン付きファイル、レジストリ値など、アプリがインストールされていることを示すものが必要です。これは、エンドポイント全体でインストールを確認するための検出方法になります。
クリーンなマシンでSYSTEMとしてコマンドをテストします: デバイス全体に設定する前にインストールとアンインストールをテストすることは、問題が深刻化する前に不具合を見つけるために不可欠です。指定したコマンドラインでシステムコンテキストにインストールされるアプリは、通常SCCM経由でもインストールできることを覚えておいてください。
SCCM アプリケーション設定のステップバイステップガイド
SCCM向けにアプリケーションをパッケージ化するのが最 初のステップですが、その後に設定する必要があります。アプリの設定にもいくつかの手順が必要ですが、慣れればシンプルなプロセスになります。
アプリケーションを作成します: Software Library に移動し、次に Application Management → Applications に進んで、Create Application を選択します。MSI の場合は、SCCM にファイルを読み取らせることができます。一方、setup EXE または PSADT ラッパーの場合は、Script Installer を選択し、詳細を手動で入力する必要があります。
設定タイプのコンテンツを設定する: このステップでは、インストールコマンドとアンインストールコマンド、さらにアプリが対応している場合は修復コマンドを入力します。コンテンツの場所がクリーンなソースフォルダーを指すようにしてください。
検出方法を追加します: 検出方法には、ルールベースの検出やスクリプト検出があり、アプリが正常にインストールされたことを示す特定の指標を確認できます。使用すべき具体的な検出方法は、アプリによって異なります。
ユーザーエクスペリエンスを設定:これには、システム向けにインストールするかユーザー向けにインストールするか、ログオン要件、プログラムの表示設定(サイレントインストールには Hidden を使用します)、最大実行時間など、さまざまな設定が含まれます。
要件と依存関係を追加:要件によって、どのデバイスにどの設定タイプを適用するかが決まり、依存関係チェーンは最大5階層までサポートされます。
コンテンツを配信します: すべてを配布ポイントまたは配布ポイントグループに送信し、対象のデバイスに届くようにします。
コレクションに設定する: [Install] を選択し、[Available](ユーザーが Software Center からインストール可能)または [Required](期限までに自動的にインストール)を選びます。意図した期間内に設定されるよう、利用可能時間と期限を忘れずに設定してください。
本格展開の前にテストする: アプリケーションを設定する前に、パイロットグループでシミュレーション設定を実行し、インストールせずに検出、要件、依存関係をテストします。すべて問題なければ、成功条件に基づいて段階的に展開するためにフェーズド設定を使用できます。
設定を監視する: Monitoring → Deployments に移動して展開状況を監視し、より広いデバイスグループに設定する前に、結果を確認してすべてが意図したとおりに動作していることを確認します。
SCCM では、アンインストール設定は自動的に「必須」に設定され、変更できないことに注意してください。期限時点で電源がオフだったデバイスについては、クライアント設定で 1 ~ 120 時間の猶予期間を設定し、その後各設定で有効にすることで、必要に応じて適用を遅らせることができます。
SCCMの検出方法の仕組み
検出とは、アプリケーションがインストールされているかどうかをSCCMが確認する方法です。SCCMクライアントは、何かをインストールする前にアプリが存在することを示すサインを確認するため、すでにあるアプリを再インストールしません。また、その後にもう一度確認して、インストールが正常に完了したことを確かめます。検出方法は次の2種類のいずれかです。
ルールベースの検出
ルールベースの検出では、SCCM クライアントがファイルシステム(ファイルまたはフォルダー)、レジストリ(キーまたは値)、または Windows Installer の製品コードを確認します。ルールを満たしている場合、SCCM はそのアプリがインストール済みであると判断します。
複数の句を「And」または「Or」で組み合わせ、さらにグループ化してより複雑なロジックを作成できます。どちらを使う場合でも、古いインストールが最新として報告されないように、製品コードやファイルバージョンなど、バージョンごとに変わる項目をルールで確認するようにしてください。
スクリプト検出
スクリプト検出では、PowerShell、VBScript、または JScript(最大 32 KB)でチェックを記述できます。SCCM はスクリプトの終了コードとその出力の両方を読み取ります。アプリは、スクリプトが 0 で終了し、STDOUT に何かを書き出した場合にのみ、インストール済みと見なされます。終了コードが 0 でも出力がない場合は未インストールを意味し、0 以外の終了コードでは状態は不明のままになります。実際には、アプリが見つかったときだけ出力を書き出し、常に 0 で終了するようにします。
終了コード | STDOUT | STDERR | 検出状 態 |
0 | 出力があります | いずれか | インストール済み |
0 | 空 | 空 | 未インストール |
0 | 空 | 出力があります | 不明 |
ゼロ以外 | いずれか | いずれか | 不明 |
検出が実行されるタイミング
SCCM はアプリケーションをインストールする前に検出を確認し、その直後にも再度確認します。インストール後にアプリが見つからない場合、ソフトウェアがデバイス上にあっても、SCCM はエラー 0x87D00324 を報告します。以下のトラブルシューティングセクションで、その修正方法を説明しています。
SCCMのリターンコードと再起動の動作
インストーラーの完了時には終了コードが返され、SCCMは設定タイプの戻りコード一覧を使って、インストールが成功したか、再起動が必要か、再試行すべきかを判断します。これらのコードを把握しておくことは、ITチームが結果を正しく解釈し、トラ ブルシューティングを行ううえでも役立ちます。
コードの意味は次のとおりです:
成功(再起動なし): アプリケーションは正常にインストールされ、再起動は不要です。
失敗(再起動なし): アプリケーションのインストールに失敗しました。
ハード再起動:アプリケーションはインストールされましたが、完了するにはデバイスの再起動が必要です。再起動が完了するまで、ほかのインストールは実行されません。
ソフト再起動:アプリケーションはインストールされており、デバイスの再起動が必要です。その間もほかのインストールは続行できます。
高速再試行:別のインストールが進行中のため、インストールはその完了を待つ必要があります。クライアントは2時間ごとに、最大10回まで再試行します
SCCMでは、設定タイプを作成するとこれらの既定のリターンコードが追加されます:
コード | Windows Installer (MSI) | スクリプトインストーラー |
0 | 成功 | 成功 |
1707 | 成功 | 未追加 |
3010 | ソフト再起動 | ソフト再起動 |
1641 | ハード再起動 | ハード再起動 |
1618 | 高速再試行 | 高速再試行 |
追加しない限り、その他の0以外のコードはすべて失敗として扱われます。たとえば、インストーラーが成功時に0ではなく1を返す場合は、SCCMが正しく判定できるように、1を「成功(再起動なし)」として追加します。
ラップされたインストールでも、コードのマッピングが必要です。ユーザーが PSADT インストールを延期すると、ツールキットは延期コード(既定では 1602)を返します。これを 1618 に変更するか、1602 を高速再試行コードとして追加すると、SCCM は失敗 হিসেবে記録する代わりに再試行します。延期については、PSADT ガイドでより詳しく説明しています。
忘れないでください。設定タイプのインストール後の動作設定によって、SCCMがデバイスを再起動するのか、インストーラーが再起動するのか、または再起動しないのかが決まります。
失敗した SCCM アプリケーション設定をトラブルシューティングする方法
SCCMのアプリ設定が失敗しても、慌てる必要はありません。一般的な問題は、少しトラブルシューティングするだけで原因を特定し、すばや く対処・軽減できます。
"インストール完了後にアプリケーションが検出されませんでした" (0x87D00324)
このエラーは、インストールは実行されたものの、検出方法でアプリケーションが見つからなかったことを意味します。この場合は、AppDiscovery.logとCIAgent.logを確認し、検出ルールをインストーラーが実際に書き込んだ内容と比較してください。
"アンインストール完了後もアプリケーションが引き続き検出されました" (0x87D00325)
このエラーは、アンインストールは完了したものの、検出ではまだアプリケーションが見つかっていることを意味します。まず AppEnforce.log を確認してどのアンインストールコマンドが実行されたかを確認し、次に AppDiscovery.log を確認して検出でまだ何が見つかっているかを確認し、それを検出ルールと比較してください。
インストールが失敗するのは SCCM 経由の場合のみ
SCCM でインストールに失敗する場合は、テストマシンでまったく同じコマンドを SYSTEM として実行し、そこで動作するか確認してみてください。また、サイレントスイッチも確認してください。指定されていないと、インストーラーがユーザー入力待ちになっている可能性があります。
一部のデバイスでは設定が開始されない
設定タイプの最大許容実行時間がデバイスのメンテナンスウィンドウより長い場合、その設定は開始されません。これに対処するには、実行時間を短くするか、メンテナンスウィンドウを延長してください。
2026年時点のSCCMアプリケーション設定の現状
ここで、現在の SCCM の状況を見てみましょう。バージョン 2609 は 2026年10月26日からすべての顧客が利用可能で、2503 以降を実行しているサイトに適用されます。また、これは新しいスケジュールでの最初のリリースでもあります。Microsoft は現在、SCCM の更新を年1回に変更しており、セキュリティと安定性を重視しつつ、新たなイノベーションは Intune で進められるとしています。
多くのチームでは、共同管理を通じて SCCM と Intune を一緒に運用しています。クライアントアプリのワークロードが Intune に移行すると、Intune から設定されたアプリは Company Portal に表示され、SCCM から設定されたアプリは Software Center に残ります。
SCCM向けに行ったパッケージ化の作業は、アプリをIntuneに移行する場合でも役立ちます。クリーンなサイレントインストール、信頼できる検出ロジック、マッピングされたリターンコードは、Intune Win32アプリでも同じように必要です。ただし、設定はIntuneであらためて行う必要があり、動作には少し違いがあります(たとえば、手動の検出ルールはすべて一致する必要があります)。その点については、Intune Win32 Content Prep Toolガイドをご覧ください。
Splashtop Agentic PackrがSCCMアプリケーションのパッ ケージ化を高速化する方法
アプリケーションを適切にパッケージ化することは重要ですが、反復的で時間のかかる手作業になりがちです。ただし、Splashtop Agentic Packr のようなツールがあれば、その必要はありません。
Agentic Packr は、アプリのパッケージ化を自動化する AI 搭載ツールです。このツールはインストーラーを読み取り、サイレントインストール用のスイッチを特定し、検出ルールと要件ルールを作成して、手動のスクリプト作成やパッケージ化の専門知識なしでパッケージを構築します。パッケージは PSADT 上で構築されるため、管理者は必要に応じて開いて確認し、調整できます。すべてのパッケージはクリーンな仮想マシン上で検証、スキャン、テストされ、IT 管理者がアプリケーションを設定する前に確認・承認できる QA スコアカードと実行ログが提供されます。
Splashtop Agentic Packr がアプリケーションをパッケージ化すると、そのインストール、更新、アンインストールのアクションをまとめて、SCCM で設定したり、任意の Windows マシンで手動実行したりできます。さらに、アプリの新しいバージョンがリリースされるたびに、Agentic Packr がそれを検出して更新済みパッケージを自動的に作成できるため、IT チームは新しいバージョンごとに手作業で再パッケージ化する必要がありません。
アプリを一度パッケージ化すれば、SCCM で自信を持って設定できます
SCCMのアプリケーション設定は、テスト済みのパッケージ、正確な検出、そして明確にマッピングされたリターンコードから始まり ます。これらが整っていれば、アプリや更新プログラムは必要なデバイスに届き、SCCMは実際に何が起きたかをレポートします。
Splashtop Agentic Packr は、サイレントインストール用スイッチの検出から、検出ルールの作成、各ビルドのテストまで、その準備作業の多くを担うため、IT チームはパッケージ化に費やす時間を減らし、展開管理そのものにより多くの時間を充てられます。
Splashtop Agentic Packr が、アプリケーションのパッケージ化を効率的かつ安全に支援する方法を見てみませんか?ぜひ今すぐ詳細をご確認ください。





