【保存版】アプリのサイレントインストール一覧と終了コード3010の対処法
※本記事には広告を含みます。
はじめに
社内のWindows端末へIntuneやPowerShell、資産管理ツール(SkyseaやLanScope等)を使ってアプリケーションを一括配布する際、インストーラーごとのサイレントスイッチが分からなかったり、インストール成功後に勝手に再起動されて困った経験はないでしょうか。
私も過去に、パッケージング作業中にサイレントオプションを誤認して全社PCに突然再起動がかかり、業務を中断させてしまうという冷や汗ものの失敗をしたことがあります。また、配布スクリプトで終了コード「3010」が返ってきて「エラー」として扱ってしまい、正常にインストールされていたのに失敗アラートが鳴り響いた経験もあります。
Windowsのインストーラーは、開発フレームワーク(MSI、InstallShield、Inno Setup、NSIS等)によってサイレント引数がまったく異なります。また、終了コード「3010」はエラーではなく「再起動待ちの成功」という重要な仕様です。
この記事では、主要なインストーラー形式ごとのサイレントスイッチ一覧表と、終了コード3010をスクリプトやIntuneで正しくハンドリングする実践テクニックを徹底解説します。
読み終えるころには、どんなインストーラーが来ても迷わず無人インストールパッケージを作成できるようになります。
この記事の要点
- インストーラーの種類(MSI, InstallShield, Inno Setup, NSIS, Burn)によってサイレントスイッチは完全に異なる
- 終了コード「3010(ERROR_SUCCESS_REBOOT_REQUIRED)」は処理成功であり、スクリプト側でエラー判定してはならない
- Intuneやスクリプトでは、再起動を抑制する引数(
REBOOT=ReallySuppress等)を必ず併用して業務中の強制再起動を防ぐ
| 項目 | 動作確認・検証環境 |
|---|---|
| 検証年月 | 2026年3月 |
| 対象OS | Windows 11 Pro 23H2 / 24H2, Windows Server 2022 |
| 対象インストーラー | MSI, EXE (InstallShield, Inno Setup, NSIS, WiX Burn) |
| 実行権限 | ローカル管理者権限(Administrators)またはSYSTEM |
結論:インストーラー種別の見分け方とサイレントオプション早見表
結論からお伝えすると、無人インストールを組む際は「まずインストーラーのエンジンを特定し、対応するサイレント引数と再起動抑制引数をセットで渡す」のが鉄則 です。
ファイルのプロパティや、コマンドプロンプトで /? または /help を実行した際に出るヘルプ画面のレイアウトから、どのインストーラーエンジンで作られているかを特定できます。
主要インストーラー形式別オプション対照表
| エンジン種類 | 主な拡張子 | サイレント引数 | ログ出力引数 | 再起動抑制(強制禁止) |
|---|---|---|---|---|
| Windows Installer (MSI) | .msi |
/qn または /quiet |
/l*v "C:\log.txt" |
REBOOT=ReallySuppress |
| Inno Setup | .exe |
/VERYSILENT /SUPPRESSMSGBOXES |
/LOG="C:\log.txt" |
/NORESTART |
| NSIS (Nullsoft) | .exe |
/S(大文字必須) |
(標準なし) | (標準なし) |
| InstallShield | .exe |
/s /v"/qn REBOOT=ReallySuppress" |
/v"/l*v C:\log.txt" |
/v"REBOOT=ReallySuppress" |
| WiX Burn | .exe |
/quiet または /passive |
/log "C:\log.txt" |
/norestart |
上記の中で特に注意すべきは NSISの /S です。小文字の /s ではサイレントにならず画面が表示されてしまいます。大文字・小文字を厳密に区別してください。
終了コード「3010」の正体とスクリプトでの正しい処理
アプリの配布自動化で最も開発者を悩ませるのが、コマンド実行後に返ってくる終了コード(Exit Code / $LASTEXITCODE)「3010」です。
3010の正体:エラーではなく「再起動待ちの成功」
Windowsのシステムエラーコード定義において、3010は以下のように定義されています。
3010 (0xBC2) = ERROR_SUCCESS_REBOOT_REQUIRED
「要求された操作は成功しました。変更を有効にするには、システムを再起動する必要があります。」
つまり、インストール処理自体は100%成功 しています。しかし、使用中のシステムファイル(DLLやドライバ等)の置き換えが必要なため、「次回再起動時にファイル置換を完了させる予約」を行った状態を意味します。
スクリプトでエラー扱いしてはいけない(PowerShell実装例)
一般的なスクリプトでは if ($LASTEXITCODE -ne 0) でエラー判定しがちですが、3010を拾うと失敗アラートとして検知されてしまいます。
PowerShellでパッケージングする場合は、以下のように 「0」と「3010」の両方を成功ステータスとして処理 します。
$InstallerPath = ".\Setup.exe"
$Arguments = "/quiet /norestart"
# プロセスを起動し、完了まで待機
$Process = Start-Process -FilePath $InstallerPath -ArgumentList $Arguments -Wait -PassThru -NoNewWindow
$ExitCode = $Process.ExitCode
switch ($ExitCode) {
0 {
Write-Output "インストールが正常に完了しました。(再起動不要)"
exit 0
}
3010 {
Write-Output "インストールは正常に完了しました。(要再起動)"
# 資産管理システムやIntuneには3010をそのまま返して再起動スケジュールをOSに任せる
exit 3010
}
default {
Write-Error "インストールに失敗しました。終了コード: $ExitCode"
exit $ExitCode
}
}
現場で役立つ「未知のEXEインストーラー」解析テクニック
開発元がサイレントスイッチを公開していない特殊な社内アプリや海外製ツールの場合は、以下の手順で正体を暴くことができます。
1. 7-ZipでEXEを右クリック解凍してみる
インストーラーEXEを「7-Zip」などの解凍ソフトで強制解凍します。
- 内部に .msi ファイルが出てきた場合 → MSIラッパーであるため、解凍したMSIを直接 /qn で実行可能。
- $PLUGINSDIR フォルダや [NSIS] というファイルが出てきた場合 → NSIS 形式。
- Embedded MSIs や ISSetup.dll が出てきた場合 → InstallShield 形式。
2. レスポンスファイル(issファイル)の生成(InstallShieldの場合)
InstallShieldのEXEで /s だけでは設定項目が不足して止まる場合は、以下の手順で応答ファイル(setup.iss)を作成します。
:: 記録モードで起動し、手動で一度インストールして回答を記録
setup.exe /r /f1"C:\Temp\setup.iss"
:: 記録した回答ファイルを使って完全無人インストールを実行
setup.exe /s /f1"C:\Temp\setup.iss"
よくある質問(FAQ)
Q: Microsoft IntuneでWin32アプリ(.intunewin)を配布する際、3010はどう設定すべきですか?
A: Intuneのアプリ設定画面「戻りコード(Return codes)」の項目に、デフォルトで「3010: ソフト リブート(Soft reboot)」が登録されています。この設定のままであれば、Intune側も「インストール成功(保留中の再起動)」として正常判定されます。独自スクリプトで0に書き換える必要はありません。
Q: MSIインストール時に /qn を指定しても再起動されてしまうことがあります。なぜですか?
A: /qn は「画面表示を消す」オプションであり、「再起動を禁止する」オプションではないからです。インストーラー内部で再起動が必須と定義されている場合、画面なしのまま即座にOS再起動が始まります。必ず REBOOT=ReallySuppress プロパティを末尾に付与してください。
まとめ
Windowsアプリのサイレントインストールと終了コード3010の設計ポイントは以下の通りです。
- インストーラーのエンジンを特定し、正しい引数(大文字・小文字含む) を適用する
- 意図せぬ業務中断を防ぐため、必ず再起動抑制オプション(
/norestart、REBOOT=ReallySuppress)をセットで渡す - 終了コード 3010は正常完了(要再起動) であり、スクリプト側でエラー判定せず正しくハンドリングする
- 正体不明のEXEは 7-Zipでの解凍や応答ファイル(iss)の記録 を活用して解析する
これらをテンプレート化しておくことで、新しいソフトウェアの社内展開やPCキッティング作業を圧倒的にスムーズかつ安全に進めることができます。
関連記事
この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。
OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。
また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。
この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。
すべての操作は自己責任で行ってください。
またお会いしましょう!
著者のおすすめ教材 & note実践記事
PowerShell実務スクリプト50選
AD・Windows運用・障害対応をコマンド一発で自動化する現役SEの実務スクリプト集。
ググっても出ない実務テク20選
社内SE現場の地味で細かすぎる面倒作業を一撃で解消する実践テクニック集。