Windows 11でMicrosoft 365が「We’re getting things ready」で止まる時の対処法

Windows 11でOfficeSetup.exeが「We’re getting things ready(準備しています)」から進まない場合は、インストール済みOffice・通信・実行時刻を確認し、再起動後の再試行、公式のアンインストール、オフライン導入を順に検討します。この表示だけで、古いOfficeの残骸が原因だとは判断できません。手動削除やレジストリ整理は、通常の削除が失敗した場合に対象製品を確認して行う最後の段階です。

目次

まず、Officeのインストール画面かを確認する

表示される場所・症状確認すること
OfficeSetup.exeの「We’re getting things ready」Microsoft 365 Apps/Officeの導入を開始した場面か、停止か無言終了か
準備画面が消えたインストール済みアプリとWord等の起動を確認。消えただけでは成功/失敗を確定しない
Officeがすでに起動するが、サインイン・有効化が進まないインストール完了後のアカウント/ライセンス問題を分ける
Microsoft To DoやMicrosoft Storeの「更新の準備中」対象アプリ/Storeの更新問題。Officeの手動削除は使わない

同じ英語表示でも、Microsoft 365のWeb画面、Windowsの初期設定、別アプリでは確認先が異なります。本記事はWindows 11のOffice導入を対象にしています。Microsoft To Doの更新なら、未同期タスクがないか確認し、アプリ/Storeの更新や再起動、表示される場合の対象アプリの修復へ進みます。リセットは画面に表示されるデータ消去の内容を確認してから判断します。

対処1.再試行の前に、進行中の処理と導入条件を確認する

MicrosoftのOfficeインストールのトラブルシューティングで、対象の製品・症状に合う案内も確認します。まず次の情報をそろえます。

  1. 表示文、開始時刻、エラー番号、OfficeSetup.exeの入手元、対象プランを記録します。
  2. タスクマネージャーでインストーラーやOffice Click-to-Runの動きとネットワーク/ディスク使用を確認します。値が低い瞬間だけで停止と判断しません。
  3. Windows Update等が処理中なら完了・再起動の要求を確認し、未保存の作業を保存して再起動します。
  4. OSドライブの空き容量、PCの日時、インターネット接続、インストール権限を確認します。
  5. 契約に対応したMicrosoftアカウントまたは職場・学校アカウントから、公式の導入ファイルを取得し直して一度再試行します。

Microsoftのインストールに時間がかかる場合の案内では、通信やオフラインインストーラー、再試行等を確認します。「何分で必ず止まったと判断する」「10GB空ければ必ず直る」という共通の基準にはしません。ダウンロードや展開に必要な余裕は環境で変わります。インストーラーを繰り返し多重起動しないでください。

会社の管理PCは、Intune等による配布・既定の更新チャネル・アプリ制御に従います。ユーザー側で別製品を追加したり、管理されたプロキシや保護を解除したりする前に、配布状態を管理者へ確認します。

対処2.既存のOfficeを調べ、必要な場合だけ公式に削除する

設定→アプリ→インストールされているアプリ、またはコントロールパネル→プログラムと機能で、Microsoft 365/Office・Visio・Project等の名前を確認します。Word等が起動できるなら、ファイル→アカウント→製品情報で版・ビルド・32/64bit・Click-to-Run等の種類も記録します。Officeらしい名前があるだけで、競合や破損が証明されたことにはなりません。

  1. 既存製品を置き換えるのか、必要なVisio/Project等を併用するのかを決めます。再インストール用のアカウント/利用権とアドイン等の互換性を確認します。
  2. 対象Officeの通常アンインストールを実施し、案内に沿って再起動します。関係のないOffice単体製品まで一括削除しません。
  3. 通常の削除ができない場合は、Microsoft公式のアンインストールトラブルシューティングを検討します。
  4. 削除後に対象の公式インストーラーで再試行し、表示・エラー・実行時刻を記録します。

Microsoftのアンインストール案内では、現在の削除トラブルシューティングをGet Helpで開き、対象PC上で実行します。2026年10月4日に確認した同ページでは、Office 2024はこのトラブルシューティングの対象外です。古いSaRAの手順だけを頼りにせず、対象製品・インストール方式に合う現行案内を選びます。

通常のOfficeアンインストールは作成した文書やブックを削除しません。ただし、手動でAppDataやフォルダーを削除する作業まで同じ保証ではありません。未同期のOneNote、Outlookのローカルデータ、テンプレート、アドイン・独自設定は、必要なものを先に確認・保全します。復元ポイントだけで全ての個人データが戻るとは想定しないでください。

手動アンインストールは、通常の削除が失敗した場合に限定する

Microsoftの手動削除手順は、Click-to-Run・MSI・Microsoft Storeのインストール方式を判定し、該当する手順を選ぶ構成です。誤操作でOSの再インストールが必要になる可能性も説明されています。通常の削除手段を先に試し、対象PCの構成が公式手順と合わない場合は管理者/サポートへ確認します。

「ProgramDataのOfficeとClickToRunをすべて削除」「AppDataのOfficeを丸ごと削除」「Officeと名の付くサービス・タスク・レジストリを整理」という一般化した操作にはしません。残存して見えるものを消すこと自体を目的にせず、導入方式・対象製品・公式に指定された項目を照合して進めます。

対処3.通信による導入停止は、オフライン方式を検討する

Officeのオフラインインストーラーは、必要な導入ファイルを先に取得してから使う方法です。個人用プランと職場・学校用プランで案内が分かれます。ダウンロード段階には通信が必要で、Officeのサインイン・有効化や更新に必要な通信まで不要になる方法ではありません。

比較結果次に調べる点
通常の導入だけ失敗し、必要ファイルを取得済みの導入は進むダウンロード経路・プロキシ・取得先の違い。特定の装置が原因とは未確定
ODTの/downloadも失敗する通信エラー、プロキシ、認証/証明書、保存先へのアクセス、空き容量
取得は完了するが/configureで失敗する構成XML、製品/bit数/言語、既存製品との条件、権限やブロック記録
導入は完了するが有効化できないサインイン先、ライセンス割り当て、認証/ライセンスサービスへの通信

別回線で比較する場合も、組織の許可された接続を使います。「Webページが開く」ことだけでは、Officeのファイル取得も正常とは限りません。必要ならWinHTTPの公式コマンドで現在の設定を確認します。次のコマンドは表示用です。

netsh winhttp show proxy

結果とWindowsの設定→ネットワークとインターネット→プロキシの内容を管理者へ共有します。この結果だけで全てのアプリが同じプロキシを使うとは判断せず、自己判断でreset proxyを実行しません。

ODTでダウンロードと構成を分ける手順

Office Deployment Tool(ODT)はMicrosoft 365 Appsを配布するためのコマンドラインツールです。通常のインストーラーを置き換えて条件を明示できる一方、破損・通信・権限の問題を必ず直す道具ではありません。公式ページから現行ODTを取得し、setup.exeと構成XMLを用意します。

構成XML:64bit・日本語のApps for businessの例

次は、対象契約でO365BusinessRetailを利用することが確認できたPC向けの例です。個人用Microsoft 365、Enterprise、Teamsなし等の別契約へそのまま流用せず、管理者の配布製品/チャネル・既存Officeのbit数に合わせます。C:\ODTフォルダーを用意し、config.xmlという名前で保存します。拡張子がconfig.xml.txtになっていないか確認してください。

<Configuration>
  <Add SourcePath="C:\ODT" OfficeClientEdition="64" Channel="Current">
    <Product ID="O365BusinessRetail">
      <Language ID="ja-jp" />
    </Product>
  </Add>
  <Display Level="Full" AcceptEULA="FALSE" />
</Configuration>

ODTの構成オプションに沿って、SourcePathは導入ファイルの保存元/保存先、OfficeClientEditionはbit数、Channelは更新チャネル、Languageは言語、Displayは画面表示を指定します。SourcePathはOfficeサブフォルダーの親を指定し、ここではC:\ODTです。確認中に進捗/エラーを隠すLevel=”None”は使わず、Fullにしています。

この例には既存製品を削除するRemove/RemoveMSIは含めていません。RemoveMSIは対象となる旧MSI版のOffice/Visio/Project向けで、Click-to-Runの万能な残骸掃除ではありません。追加する場合は削除対象と保持したい製品を別途確認します。

先に/downloadだけ実行する

管理者権限のコマンドプロンプトで、setup.exeとconfig.xmlを置いたフォルダーへ移動します。次はcmd向けの例です。

cd /d C:\ODT
setup.exe /download config.xml

コマンドが終わり、SourcePath配下のOfficeフォルダーに必要なファイルが取得されているか確認します。失敗や未完了ならその時刻・ログを確認し、続けて/configureを実行しません。PowerShellで同じフォルダーの実行ファイルを起動する場合は、setup.exeの代わりに.\setup.exeとします。ExecutionPolicyを変更する操作は必要ありません。

取得完了後に/configureを実行する

setup.exe /configure config.xml

ODTのダウンロードが終わったことと、Officeのインストールが完了したことは別なので、/downloadと/configureの結果を分けて確認します。

導入先へコピーする場合はOfficeフォルダーを含め必要な取得済みファイルを保持し、XMLのSourcePathを実際の配置先へ合わせます。製品・言語・bit数・チャネル・指定するバージョンが取得内容と合わないと、追加取得や失敗になる可能性があります。ファイルを一つ見つけただけで完全なオフライン導入が可能とは判断しません。

完了後はWord等を開き、製品情報・正しいサインイン先・ライセンス有効化を確認します。ODTで入れても利用権は増えません。RDS/VDI等で複数ユーザーが使う場合は共有コンピューターのライセンス認証の対象契約が別途必要です。Business Standardは対応せず、Business Premium等の対応プランとユーザー別ライセンスを確認します。

ログの取得:C:\ODT\Logsに必ず出るとは限らない

Microsoftの現行ODT概要は、ダウンロード・構成で問題がある時に%TEMP%のログを確認するよう案内しています。上のXMLやコマンドでC:\ODT\Logsへログが必ず作られるわけではありません。フォルダーがないだけで、ログ未取得やインストール失敗とは判断しません。

  1. 再現操作の開始/終了時刻を記録します。
  2. Windows+R→%TEMP%を開き、更新日時の近いログを確認します。削除や上書きはせず、必要なものを作業用フォルダーへコピーします。
  3. 再現操作、/downloadか/configureか、表示されたエラー番号をログと対応させます。
  4. 無言終了なら、同じ時刻のイベントビューア→Windowsログ→アプリケーションのエラー/Windows Error Reporting等も確認します。
  5. 管理PCではアプリ制御・端末保護の記録を管理者へ確認します。ブロック記録がある時に、その対象の許可を検討します。

通常ログが不足する場合は、管理者がMicrosoft 365 Apps for enterpriseの詳細ログの対象手順を検討します。導入/更新とサインインの有効化手順が分かれており、設定を変更して再現・収集した後は詳細ログを無効に戻します。ログ内のメールアドレス、端末名、内部パス等を確認し、サポートへ渡す範囲を絞ります。

対処4.常駐ソフトやWindows全体の問題を条件付きで確認する

ログや再現条件から他ソフトの干渉が疑われる場合は、Microsoftのクリーンブート手順を参照します。Microsoftサービスを隠してから対象を変更し、元の有効状態を記録して、比較後に通常起動へ戻します。管理された端末の保護を独断で停止せず、詳細ブートオプションも変更しません。比較で改善しただけでは、特定の製品名まで原因と確定できません。

Officeだけでなく複数のWindows機能・更新・アプリでも失敗する場合は、Microsoftのシステムファイル検査を検討します。管理者ターミナルでDISMを完了させてからSFCを実行し、結果に従います。Officeの準備表示一つだけを理由にOSを初期化しません。

DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow

サポートへ渡すと調査しやすい情報

  • Windowsの版・ビルド、Officeの製品/bit数/言語と導入アカウントの種類
  • OfficeSetup.exe/ODTのどちらかと入手元、既存Office/Visio/Projectの構成
  • 正確な表示文・エラー番号・開始/終了時刻
  • /downloadと/configureそれぞれの結果、構成XML、同時刻のログ
  • 通常の再試行・公式アンインストール・許可された接続比較で変わった点

準備表示が消えた後は、アプリ起動・製品情報・有効化・更新まで確認して復旧を判断します。変化がない場合は、削除範囲を広げ続けるのではなく、実行時刻と失敗した段階が分かる記録をサポートへ渡します。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次