Windowsイベントログに「Acrobat MSInstallerエラー1730／1603」が大量発生する原因と完全対処ガイド（新規PCでも起きる）

新規OSに新規インストールしたAdobe Acrobat（64-bit）なのに、Windowsイベントログへ「Error 1730（管理者でないと削除できない）」や「再構成 1603」が一日中出続ける。しかも台数が増えるほど同じ症状が横展開する——。
このパターンは、単なる“壊れたインストール”というより、Windows Installer（MSI）の自己修復（Self-Heal）や再構成が何かのきっかけで連鎖し、一般ユーザー権限のセッションで修復が走って失敗ログを吐き続けている状態で起こりがちです。この記事では、ログの意味、発生メカニズム、現場で止血して根治するまでの手順を、管理者向けにまとめます。

Windowsイベントログに「Acrobat MSInstallerエラー1730／1603」が大量発生する原因と完全対処ガイド（新規PCでも起きる）

1. 症状の読み解き：1730と1603は「削除」ではなく「再構成の失敗」になりやすい

イベントに出る代表例は次の2つです。

Error 1730
「管理者でないとこのアプリケーションを削除できない」
これは文面だけ見ると“アンインストール要求”に見えますが、実務ではMSIが修復／再構成の途中で、権限が必要な処理（実質的に変更・再登録・置換に近い操作）に触れて失敗したときにも出ます。結果として、一般ユーザーがログオンしている間に“勝手に”記録されます。
Reconfiguration status: 1603
1603はMSIで頻出の汎用エラーで、原因は権限・競合・前提条件不足など多岐。ここでは「Windows Installer reconfigured the product（製品を再構成した）」という文言が重要で、何らかのトリガーで再構成が起動し、最終的に失敗したことを示します。

つまり、今回の現象は
「Acrobatが何度も自己修復／再構成を試みる → 一般ユーザー権限では通らない処理に当たる → 1730/1603が繰り返し記録される」
という一本筋で説明できるケースが多いです。

2. なぜ新規PCでも起きるのか：よくあるトリガー5選

新規OS＋新規インストールでも発生し得る理由は、インストール直後の“健全性”とは別に、運用や構成が自己修復を誘発するからです。代表的な原因は次の通りです。

(1) MSIの「広告（Advertise）」機能や自己修復が有効な配布になっている

企業配布（SCCM/Intune/GPO/イメージ展開）で、MSIの“広告インストール”や修復が起動しやすい条件が残ると、特定の機能呼び出し・ショートカット実行・COM呼び出しで再構成が走ることがあります。

(2) 依存コンポーネントやプラグイン呼び出しで“欠け”が検出される

Acrobat連携（Officeアドイン、シェル拡張、PDFプリンタ、ブラウザ連携、DLP/AVプラグイン）などが絡むと、MSIが「必要なキー/ファイルが無い」と判断して修復に入ります。セキュリティ製品がファイルを隔離したり、ポリシーで書き込みが制限されている場合も同様です。

(3) 権限設計とUACのギャップ

「Program Files配下への書き込み」「HKLMの変更」「サービス/タスクの更新」など、修復が要求する操作は管理者が必要になりやすい一方、発火は一般ユーザーの操作で起きます。そのギャップが1730として表面化します。

(4) Acrobat/Adobe Update周りのタスクやサービスが再構成を刺激する

Adobeの更新モジュールや関連タスクが、インストール状態の検査を行い、条件によってMSI再構成を呼ぶことがあります。更新自体が無くても“検査”は走ります。

(5) インストール方法の混在（ユーザー単位／端末単位）や残存情報

「同じ端末に別方式のAcrobat/Readerが混在」「過去の残存プロダクトコードがレジストリに残る」「言語パックや旧版の痕跡」などがあると、自己修復が迷子になりやすいです。クリーナーで消しても“Windows Installerの登録情報”が完全に整合するとは限りません。

3. まず止血：ログ発生源を特定して“自己修復の発火点”を掴む

闇雲な再インストールは遠回りになりがちです。最短で進めるために、以下の3点で「何がトリガーか」を確かめます。

3-1. イベントの詳細から「Product Code」や「Feature」「Component」を拾う

イベントビューアーの詳細表示（XML含む）で、MSIが参照しているプロダクト識別子やコンポーネント情報が出ることがあります。特定の機能（例：Office連携、PDFMaker、シェル拡張）に偏りがあるなら、そこが発火点です。

3-2. 再現タイミングを観察する（ログオン直後／Office起動時／印刷時など）

「一日中」といっても、実は

ユーザーログオン直後
Outlook/Word起動時
エクスプローラーでPDFを選択した瞬間
既定プリンタ操作
のように偏ることが多いです。偏りがあれば対処が絞れます。

3-3. その端末だけ一時的に“修復トリガーになりやすい連携”を無効化して比較

Officeアドインやシェル拡張が疑わしい場合、テスト端末でそれらを切ってログが止まるか確認します。止まれば「Acrobat本体」ではなく「連携部品＋権限/構成」の問題です。

4. 根治策：現場で効きやすい対処を上から順に

ここからは、効果が出やすい順に並べます。複数台で同時発生している場合、配布方式・権限・ポリシーに共通原因がある可能性が高いので、1台で直した手順を横展開できる形に整えます。

対処A：端末単位（Per-machine）での正しい再導入に統一する

最重要です。企業環境では、ユーザー単位・混在導入・広告インストールが自己修復地獄の原因になります。

配布は端末単位のインストールに統一
旧版/Reader/言語パック等の混在を排除
同じメディア/同じ導入パラメータで揃える

「再インストールしたのに直らない」は、同じ地雷（配布の癖）で入れ直しているだけのケースが非常に多いです。

対処B：MSI自己修復の引き金になっている連携を潰す（Office/シェル/セキュリティ）

発火点が特定できたらそこを優先します。典型は次の2つです。

Officeアドイン（PDFMaker等）の登録が壊れる／ブロックされる
シェル拡張（プレビュー/サムネ等）が権限で更新できず修復が走る

加えて、セキュリティ製品がAcrobat配下や更新モジュールを監視・隔離していないかも確認します。隔離や書き込み制御があると、MSIは永遠に“欠け”を検出します。

対処C：ローカル管理者権限が必要な更新・修復処理を「ユーザー操作時に走らせない」

1730は「一般ユーザーセッションで管理者操作が必要な変更が走っている」状態のサインです。

更新検査や修復が、ユーザー利用時間帯に走らないようスケジューリングを見直す
端末管理側（管理者コンテキスト）で更新・修復を計画実行する
不要な自動修復を誘発するタスクや仕組みを整理する

“ユーザーが使うたび修復”を止め、“管理者が管理者として直す”構造に変えるのがコツです。

対処D：Windows Installerの整合性（キャッシュ/登録情報）を正す

クリーナーでアプリの痕跡を消しても、Windows Installerの登録情報が微妙にズレていると再構成が暴れます。環境により手段は変わりますが、狙いは以下です。

Acrobat関連のMSI登録が二重化・孤立していないか
必要なインストーラキャッシュ参照が壊れていないか
修復が参照するキー/コンポーネントが存在するか

ここは“個人の手作業”に寄せるほど事故りやすい領域なので、企業では可能な限り**標準手順（正規アンインストール→統一インストール）**で吸収するのが安全です。

対処E：ログを止めるだけの回避策（最終手段）

運用上どうしてもすぐ止めたい場合、自己修復の発火点（特定機能）を無効化してログだけ止める手もあります。ただし、機能が使えなくなる/別の不具合が潜む可能性があるため、恒久策にせず「暫定」と割り切るのが無難です。

5. まとめ：このエラーは“Acrobatの不良”より“MSI自己修復の設計不整合”を疑う

1730と1603が繰り返し出るのは、MSI再構成（自己修復）が発火し続け、一般ユーザー権限で失敗している構図が多い
新規PCでも、配布方式・連携・権限・セキュリティ制御で簡単に再発する
効く順番は「配布方式の統一（端末単位）→ 発火点の連携対処 → 管理者コンテキストでの更新/修復設計 → MSI整合性の回復」

一度このループを断ち切ると、イベントログは静かになり、体感の引っかかり（起動遅延、Office連携の不安定、プリンタ周りの不具合など）も同時に改善することが多いです。ログを“結果”として追うのではなく、自己修復を呼んでいる“原因の導線”を先に断つのが最短ルートです。