はじめに
今回は、ChromeOS Flexを導入する際に拡張機能による標準のインストールでリカバリユーティリティが進行しない問題について書いていきます。
管理者権限でのGoogle Chrome実行でもできない場合、以下の可能性があります。
- 自動ダウンロード時のインターネットトラブル
- 解凍処理のセキュリティとの競合
- 省電力モードや最適化によるもの
結論から言うと、解決策は、あらかじめZIPをダウンロードしておき、右上の歯車メニューから「ローカルイメージ」を手動指定するという方法です。
1.環境セクション
- OS:Windows11
- CPU:Intel(R) Core(TM) Ultra 7 155U (2.10 GHz)
- メディア:KIOXIA USBメモリ
- ツール:Chromebook リカバリユーティリティ
3. 異常挙動の観察と切り分け
解決に至るまでに観察した、一般的なソフトウェアトラブルとは異なる「特異な挙動」を記録します。
3.1 物理的な挙動:CPUファンの停止
PCの電源プランを「最大パフォーマンス」に設定し、通常であれば高負荷がかかるはずの書き込みプロセスにおいて、以下の現象が発生しました。
現象: 「作成開始」をクリックした直後、それまで回転していたCPUファンが完全に停止した。
推察: CPU使用率が極端に低下しているか、ツール自体がOSのスケジューリングから外れ、デッドロック(処理の停滞)に陥っている可能性が高い。
3.2 システム的な挙動:UAC(ユーザーアカウント制御)の矛盾
Windowsの権限昇格プロセスの反応を比較した結果、ツールの特定のフローに問題があることが判明しました。
メディアの消去時: 正常にUACのポップアップが出現し、管理者認証後に処理が進行する。
リカバリメディア作成時: 認証を求めるダイアログが出現せず、進捗バーが0%のまま完全にスタックする。
切り分け結果: 「USBデバイスへのアクセス権限」そのものではなく、「ダウンロードデータの解凍・展開プロセス」とWindows 11(特に最新の2025年モデルにおける省電力/セキュリティ制御)の相性に起因すると推測。
3.3 待機時間の検証
試行: 無反応の状態で15分間の放置を行ったが、進捗バーおよびリソースモニター上のディスク書き込み量に変化は見られなかった。
結論: 単なる「処理の遅延」ではなく、内部プロセスがハングアップしていると断定。
4. 解決策:ローカルイメージの直接指定
標準の自動ダウンロード機能を使用せず、イメージファイルを事前に用意してツールに読み込ませることで、スタック問題を回避しました。
STEP 1:公式イメージのダウンロード
Googleの公式サーバーから最新のChromeOS Flexイメージを取得します。
ダウンロード: ChromeOS Flex イメージ (最新版)
※約1.3GBのzipファイルがダウンロードされます。解凍せずそのままで構いません。
STEP 2:リカバリ ユーティリティの設定変更
「Chromebook リカバリ ユーティリティ」を起動します。
画面右上の [歯車アイコン] をクリックします。
メニューから [ローカルイメージを使用] を選択します。
先ほどダウンロードしたzipファイルを選択します。
STEP 3:書き込みの実行
使用するUSBメモリ(今回はKIOXIA製)を選択します。
「今すぐ作成」をクリックします。
結果: 0%で止まっていたのが嘘のように進捗バーが動き出し、CPUファンも回転。正常に書き込みが完了しました。
5. 考察と代替案
5.1 原因の推察
今回のトラブル(0%停止およびファン停止)は、以下の要因が複合的に絡み合った結果だと推測されます。
リソース競合: 最新PC(2025年モデル)の省電力制御が、ツールの「ダウンロード完了待ち」を「アイドル状態」と誤認した可能性。
プロセスのハング: ツール内部での「zip解凍」と「管理者権限での書き込み開始」の受け渡しが、最新のWindows 11セキュリティ設定によりブロックされた。
「ローカルイメージ」を使用することで、不安定なネットワーク/解凍プロセスをスキップし、直接「書き込み」プロセスへ移行できたことが成功の鍵でした。
5.2 代替案:これでも解決しない場合
もし上記手順でも停止する場合は、サードパーティ製のライティングソフトである Rufus の使用を推奨します。Google公式ではありませんが、ISO/BINイメージをUSBに展開する能力が非常に高く、今回ダウンロードしたイメージファイルを使って同様にインストーラーを作成可能です。

