Windows 11 に Microsoft 365 Apps を入れようとすると、OfficeSetup.exe が「We’re getting things ready（準備しています）」のまま止まり、完了しない／無言で終了することがあります。原因の多くは「中途半端に残ったOffice残骸」やダウンロード周りの詰まりです。ログの取り方と、現場で成功率が高い手順を順番にまとめます。
「We’re getting things ready」で止まるときに起きていること
管理センターやポータルから入手する OfficeSetup.exe は“本体”ではなく、インストールの準備とダウンロードを行う小さなブートストラップです。ここで止まる場合、次のどれかが絡むケースが多いです。
- 過去に入っていたOffice（試用版・プリインストール・別エディション）の残骸が残っていて、Click-to-Run の整合性チェックで詰まる
- Click-to-Run のサービスやタスクが壊れている／止まっている
- ネットワーク（プロキシ、SSLインスペクション、DNS、証明書、時刻ずれ）で必要ファイルを取得できない
- ディスク不足、ユーザープロファイル破損、セキュリティ製品の監視で処理が途中で落ちる
- ポリシー（WDAC/AppLocker、企業ポリシー、端末保護）で実行や書き込みがブロックされる
「SaRAを回しても直らない」「公式削除ツールでも取り切れない」場合は、残骸除去とログ採取のやり方を切り替えるのが近道です。
最初にやるべきチェック（5分で終わる範囲）
インストールの“前提条件”を潰す
- 空き容量：OSドライブに余裕がないと、準備中に止まったり無言終了しやすいです（更新ファイルや展開領域が確保できない）。目安として数GBではなく、余裕を持って10GB以上確保してから試します。
- 実行場所：OfficeSetup.exe はデスクトップやダウンロードフォルダでも動きますが、ネットワークドライブや同期フォルダ配下は避け、C:\Temp などローカルの短いパスに置いて実行します。
- 管理者権限：右クリック→管理者として実行。
- 時刻のズレ：PCの時刻がズレているとTLS通信や証明書検証で詰まります。まずは時刻を自動設定して同期。
- 再起動：Office関連プロセスやサービスが中途半端な状態のまま残ると再試行が失敗します。作業前に一度再起動。
「残っているOffice」を見つける
設定 → アプリ → インストールされているアプリ（または「アプリと機能」）で、次のような項目がないか確認します。少しでもOfficeっぽいものが残っているなら、それが今回の原因になっている可能性が高いです。
- Microsoft 365 / Office / Microsoft Office
- Office（言語パック、Access、Visio、Project など単体製品含む）
- Microsoft Office Click-to-Run / Click-to-Run（表示名は環境で揺れます）
- 会社支給PCで、古い「Office 2016/2019/2021」などが混在
原因を追えるログの集め方（ここが分岐点）
「準備しています」で固まる系は、画面上は何も起きていないように見えても、内部ではサービス起動、残骸チェック、ダウンロード開始、展開、登録など複数の工程が進んでいます。まずはログの場所を押さえます。
まず見るべきログ／痕跡の場所
| 種類 | 主な場所（例） | 何が分かるか | 見るポイント |
|---|---|---|---|
| テンポラリ（ユーザー） | %TEMP%（例：C:\Users\ユーザー名\AppData\Local\Temp） | OfficeSetup.exe 実行時のログや断片 | 実行時刻に近い .log / .txt を探す（更新日時順） |
| テンポラリ（システム） | C:\Windows\Temp | サービス側が吐くログが残ることがある | Office/ClickToRun っぽい名前を探す |
| Click-to-Run のログ | C:\ProgramData\Microsoft\ClickToRun\（配下に Log がある構成が多い） | Click-to-Run サービスの動き、ダウンロード・展開・登録の詳細 | エラーコード、ダウンロード失敗、整合性チェック失敗の記録 |
| イベントビューア | イベントビューア → Windowsログ → アプリケーション（＋アプリとサービスログ） | アプリのクラッシュ、ブロック、サービスの異常 | Office/ClickToRun/アプリ制御（WDAC/AppLocker）関連のイベント |
注意点として、ログ名は環境や世代で揺れます。重要なのは「実行した時刻」と「更新日時が新しいログ」を追うことです。見つからない場合は、次のODT（Office Deployment Tool）に切り替えると、ログを指定フォルダに確実に出せます。
イベントビューアで“無言終了”の痕跡を見る
無言で終わる場合、インストーラー自体が落ちているか、起動がブロックされていることがあります。
- イベントビューア → Windowsログ → アプリケーション：エラー（赤）や警告（黄）を確認
- 「アプリケーションエラー」「.NET Runtime」「Windows Error Reporting」などが出ていないか
- 企業端末なら「アプリとサービスログ」側に AppLocker / WDAC のブロック記録が出ることがあります
最優先：Officeの“残骸”を確実に消す（公式ツールでダメなら手動）
今回の症状で一番多いのは、過去のOfficeが中途半端に残っていてClick-to-Runの準備段階で止まるパターンです。SaRAや公式削除ツールを使っても改善しないなら、手動アンインストールに切り替えるのが効果的です。
手動アンインストールの前に（安全策）
- 復元ポイントを作成（万一のロールバック用）
- 作業中はOffice関連アプリをすべて終了（Outlook/Teams/OneNote など含む）
- OneDrive同期フォルダ直下で作業しない（削除・ロックの原因）
手動アンインストール手順（現場で効く“順番”）
以下は「残骸を残しにくい順序」です。すべてを必ず実施する必要はありませんが、途中で改善しない場合は次へ進む運用が確実です。
手順A：設定からアンインストール（見える範囲を先に消す）
- 設定 → アプリ → インストールされているアプリ で、Office/365/Visio/Project/言語パックなどをすべてアンインストール
- アンインストール後、必ず再起動
手順B：Office関連プロセス／サービスを止める（削除を通す）
タスクマネージャーで Officeっぽいプロセスが残っていれば終了します。加えて、サービスの状態を確認します。
| 項目 | 確認場所 | 正常の目安 | 異常時の対処 |
|---|---|---|---|
| OfficeClickToRun（関連プロセス） | タスクマネージャー | インストールしていないなら基本いない | 残っていれば終了→再起動 |
| Microsoft Office Click-to-Run Service | services.msc | 残骸があると動き続ける場合あり | 停止できるなら停止（停止できないなら再起動後に削除） |
| BITS（バックグラウンド転送） | services.msc | 手動/自動で起動可能 | 停止していたら開始（ダウンロードが詰まる原因） |
| Windows Update | services.msc | 更新が詰まっていない | 更新が壊れている場合は修復（後述） |
手順C：残フォルダを削除（“取り切れない残骸”の核心）
以下は代表例です。環境によって存在しない場合もあるので、見つかったものだけを対象にします。削除中に「使用中」で弾かれる場合は、再起動後やクリーンブート後に再挑戦します。
- Program Files：
- C:\Program Files\Microsoft Office
- C:\Program Files (x86)\Microsoft Office
- C:\Program Files\Common Files\Microsoft Shared\ClickToRun
- ProgramData（隠しフォルダ）：
- C:\ProgramData\Microsoft\Office
- C:\ProgramData\Microsoft\ClickToRun
- ユーザー配下（影響が出やすい残骸）：
- %LOCALAPPDATA%\Microsoft\Office
- %APPDATA%\Microsoft\Office
ポイントは、ClickToRun と Office の ProgramData 配下です。ここに古い構成・ダウンロード断片・登録情報が残っていると、再インストールで「準備中」のまま止まりやすくなります。
手順D：タスクスケジューラのOfficeタスクを確認
「タスク スケジューラ ライブラリ → Microsoft → Office」配下にタスクが残ることがあります。残骸削除の妨げになるほどではない場合もありますが、Officeを完全に入れ直す局面では整理対象です。
手順E：最後の一手（レジストリ整理は“必要な場合だけ”）
レジストリ編集はリスクがあります。ここまで実施しても改善しない場合の手段として、次の方針で行います。
- 削除前に該当キーをエクスポートしてバックアップ
- 「Office」「ClickToRun」関連のキーでも、企業端末のポリシーが入っている場合があるため、むやみに全消しはしない
一般に参照される場所の例：
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun
- HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office
ここまで終えたら再起動し、次の「再インストール」へ進みます。
再インストールでつまずかないための“定番の手当て”
残骸を消したあと、次の順序で再インストールを試すと、成功率が上がります。
まずはシンプルにOfficeSetup.exeを再実行
- OfficeSetup.exe をローカル（例：C:\Temp）に置く
- 右クリック → 管理者として実行
- 実行中は、Office/Teams/OneDrive など関連アプリは閉じる
ダウンロード系が怪しいときの切り分け
| 状況 | 疑うポイント | 確認のしかた | 現実的な回避策 |
|---|---|---|---|
| 「準備中」で長時間変化なし | プロキシ/SSLインスペクション/DNS | 別ネットワーク（テザリング等）で再試行 | ODTで事前ダウンロード→オフライン構成 |
| 無言で終了する | アプリ制御（WDAC/AppLocker）やセキュリティ製品 | イベントビューアのブロック記録、セキュリティログ | クリーンブート、例外設定、ODTでログ確保 |
| 毎回同じところで止まる | 残骸/壊れたClick-to-Run構成 | ProgramData配下の残り、C2Rログ | 手動アンインストール徹底→ODTで再構築 |
クリーンブートで“邪魔者”を排除
セキュリティ製品や常駐ツールが絡む場合、Windowsをクリーンブートしてからインストールすると通ることがあります。ポイントは「Microsoftのサービスは残し、サードパーティを止める」ことです。インストールが終わったら元に戻します。
実務的な回避策：Office Deployment Tool（ODT）で入れると安定する
企業向けの配布や、今回のようにGUIインストーラーが不安定な場合は、Office Deployment Tool（ODT）で構成XMLから導入する方法が強力です。
- インストール工程が明確（ダウンロードと構成を分離できる）
- ログの出力先を指定できるため、原因追跡がしやすい
- オフライン配布（社内共有）にも向く
ODT導入の全体像
- ODTを展開するフォルダを用意（例：C:\ODT）
- 構成XMLを作成（後述のサンプルを流用）
- （オンライン端末で）必要ファイルを事前ダウンロード
- ダウンロード済みソースからインストール（ログを見ながら）
構成XML（Microsoft 365 Apps for business の例）
Business Standard は一般に「Microsoft 365 Apps for business」を含むため、製品IDは O365BusinessRetail を使う構成が多いです（組織の契約や配布方針により変わることがあります）。
例（64bit／日本語／ログ出力あり／サイレント寄り）：
<Configuration>
<Add OfficeClientEdition="64" Channel="Current">
<Product ID="O365BusinessRetail">
<Language ID="ja-jp" />
</Product>
</Add>
補足：
- Channel は「Current」が一般的ですが、企業で更新管理をしているなら方針に合わせます。
- RemoveMSI はMSI版Officeが残っているときの衝突回避に有効です。
- 共有端末（RDS/VDI等）で使うなら SharedComputerLicensing の指定が必要なことがあります。
ODTの実行コマンド例
（ODTの setup.exe と config.xml が同じフォルダにある前提）
setup.exe /download config.xml
setup.exe /configure config.xmlこの方式にすると、C:\ODT\Logs にログが残るため、「準備しています」で止まる原因がダウンロードなのか、展開なのか、登録なのかを追いやすくなります。
ODTログで見るべきポイント
- ダウンロード失敗：ネットワーク・プロキシ・証明書・DNSの線が濃い
- 展開/書き込み失敗：ディスク不足、アクセス権、セキュリティ製品の監視、Controlled folder access など
- 既存構成の検出/削除で失敗：残骸がまだ残っている（ProgramData配下やClickToRun周りを再確認）
それでも止まる場合の“深掘り”チェック
残骸除去＋ODTでも通らない場合、OfficeそのものよりWindows側の状態が原因になっていることがあります。以下は「効く頻度が高い順」です。
Windowsのシステム修復（SFC/DISM）
システムファイルやコンポーネントストアの破損は、インストーラーが準備段階で落ちる原因になります。管理者のターミナル（PowerShell/コマンドプロンプト）で実行します。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth新しいローカル管理者ユーザーで試す
ユーザープロファイル配下（%TEMP%やAppData）の破損や権限のねじれで詰まることがあります。一時的なローカル管理者を作成し、そのユーザーでインストールを試すと原因が切り分けられます。
プロキシ/WinHTTP設定の確認
企業ネットワークでは、ブラウザのプロキシとは別に WinHTTP の設定が影響することがあります。次のコマンドで確認できます。
netsh winhttp show proxy意図しないプロキシが入っている場合は、ネットワーク管理方針に従って調整します（自己判断での無効化がNGな環境もあるため注意）。
端末保護（WDAC/AppLocker/EDR）のブロック確認
「無言終了」「起動してすぐ消える」場合、アプリ制御やEDRがブロックしているケースがあります。
- イベントビューアでブロックイベントが出ていないか
- セキュリティ製品の管理画面で、OfficeSetup.exe / setup.exe / OfficeClickToRun 系の検知がないか
- 管理者・情シスがいる環境では、例外（許可）設定やポリシー確認を依頼
現場でのおすすめ解決フロー（迷ったらこの順番）
最後に、手戻りが少ない“成功率重視”の流れをまとめます。
- 空き容量・再起動・管理者実行などの基本を実施
- 設定からOffice関連をアンインストール
- 改善しなければ手動アンインストール（ProgramData配下まで意識して残骸除去）
- 再起動後にOfficeSetup.exeで再試行
- まだダメならODTへ切り替え（ログ指定・事前ダウンロードで安定化）
- それでもダメなら、SFC/DISM、別ユーザー、ネットワーク/プロキシ、アプリ制御の順に切り分け
よくある質問
公式削除ツールを使ったのに残骸が残るのはなぜ？
Officeは Click-to-Run の構成情報や更新キャッシュが複数箇所に分散し、さらにユーザーごとの設定も絡みます。削除ツールは多くのケースで有効ですが、環境差（過去の混在、途中失敗、権限、セキュリティ監視）で取り切れないことがあります。手動アンインストールで“残りやすい場所”まで確実に掃除すると改善しやすいです。
ODTで入れるとライセンスはどうなる？
ODTはあくまで「導入方法」を変えるだけで、利用権は契約（Business Standard 等）とユーザーへのライセンス割り当てで決まります。インストール後は通常どおりサインインして有効化されます。
32bit/64bitはどちらがいい？
特別な理由（古いアドインや32bit限定の連携ソフト）がなければ、Windows 11 では64bitが基本です。混在（過去に32bitが入っていた等）があると詰まりやすいので、残骸除去後にどちらかへ統一するのが重要です。
コメント