Rufus

Rufus 4.14、要件回避設定が毎回戻るバグ

情報の灯台

2026年5月3日 20:3500

USBブートメディア作成の定番ツール「Rufus」の最新版4.14で、Windows 11のハードウェア要件をバイパスする設定が次回起動時にリセットされる不具合が報告されている。開発者本人が原因を特定し、修正に動いている。

設定が「毎回オンに戻る」というやっかいなバグ

不具合の内容はシンプルで、ある意味たちが悪い。

ポータブル版のRufus 4.14でUSBメディアを作る際、ユーザーが「Windows User Experience」（WUE）ダイアログのチェックボックスを全部外しても、次にRufusを起動したときに「4GB以上のRAM、Secure Boot、TPM 2.0の要件を削除」のチェックだけが勝手に復活してしまう。前バージョンの4.13までは、ユーザーが選んだ状態をきちんと記憶していた。

最初に問題を報告したのはGitHubユーザーのzoomwaffleで、issue #2965として登録されたのが日本時間の5月2日。報告にはこう書かれている。

4.13ではうまく動いていて、次回USBスティックを作るときも自分の設定が記憶されていた。4.14ではチェックボックスを外しても「remove requirement for 4GB+ RAM, Secure Boot and TPM 2.0」が常にチェックされた状態に戻ってしまう。Rufus.iniファイルを見るとWindowsUserExperienceOptionsが385810448にセットされている。このファイルを削除して再生成させても同じことが起きる。

Rufus.iniの値が記憶されているのに、UI上では別の値が表示される。ファイルを消してもまた同じ値が書き込まれる。バグの構造としては、ユーザーの選択が保存系統には届いているのに、UI側のロジックがそれを上書きしているように見える。

開発者が一度クローズ、しかし別ユーザーが食い下がる

ここからの展開がこのissueの面白いところだ。

Rufusの開発者であるピート・バタール（Pete Batard）は当初、報告を読んで「これは意図された挙動だ」と判断した。WUEダイアログの設定は「OKを押した後」に保存されるのであって、ユーザーがダイアログ上でチェックボックスを操作している最中に動的に保存されるわけではない、という理屈だ。バタールはzoomwaffleがログを添付していなかったことも指摘し、「あなたが実際に作成プロセスを完走していないからログがないのでしょう」と推測してissueをクローズした。

Rufusのチェックリストには「ログを添付しない場合はissueを即座にクローズする」というルールがあり、これは開発者一人で運営しているプロジェクトを守るための線引きだ。理屈の上ではバタールの判断は筋が通っていた。

ところが、ここで別のユーザーpineapple63が割って入る。pineapple63は実際にログを添付した上で、こう書いた。

WUEオプションでシステム要件をバイパスする設定が記憶されない問題は確かに存在するようだ。ただし、WUEオプションを何も選択しなかった場合にのみ発生するように見える。すべてのWUEオプションを外してOKを押し、その後ドライブが消去される警告でキャンセルを押し、もう一度スタートを押すと、外したはずのチェックが記憶されていない。警告ダイアログでそのままOKを押してUSBを作成させた場合も同じだ。

pineapple63のレポートはバタールの仮説を直接反証する形になっていた。OKを押した後の保存ロジックそのものに問題がある、ということだ。

「読み違えた」と認めた開発者

バタールはこのレポートを受けて、自分の最初の判断を撤回した。

ああ、なるほど。最初の報告を急いで読んでしまって、保存済みオプションが保持される話だと勘違いしていた。調べてみる。

バタールはissueを再オープンして自分にアサインし直し、20時間ほど後に原因の特定結果を投稿した。問題はコミット92a8926で導入されたUIロジックの変更にあった。

技術的にはこういう話だ。Rufusはダイアログ内のラジオボタンとチェックボックスの選択を内部的に「selection_options」という構造体で管理している。今回のリファクタリングで、ラジオボタン用の処理（必ずどれか一つが選ばれる必要がある）とチェックボックス用の処理（何も選ばれていない状態が許される）を共通化しようとした際、チェックボックス側で「全て未選択」のケースを正しく扱えなくなっていた。具体的には、ダイアログのスタイル属性がBS_AUTORADIOBUTTONでない場合に空のマスクをそのまま受け入れる検証ロジックが抜け落ちていたという。

厳密には、ソースコードを読まない限りユーザーが知る由もない話だが、これはWUEオプションを「忘れている」のではなく、表示可能なWUEオプションが空の場合にUIがリストの最初の要素を強制的にチェックしている、という挙動だ。

バタールはあわせて、ユーザーが懸念しそうな点にも踏み込んでいる。「バイパスオプションを有効のままにしておいても、TPMを搭載したシステムでの最終的なWindowsインストールには絶対に何の悪影響もない」。RAMバイパスが4GB以上のRAMを搭載したPCでRAM容量を制限することがないのと同じ理屈で、TPMバイパスもTPMを持つシステムで何かを無効化することはない、ということだ。

開発者一人プロジェクトの「ログを送れ」原則

この一連のやり取りには、Rufusというプロジェクトの運営スタイルが透けて見える。

いずれにせよ、これは簡単に修正できるはずだ。報告ありがとう。ただし、私にissueをきちんと調査してほしいなら、要求された通りに必ずログを提供してほしい。チェックリストの要件を無視したレポートは、私は速読でしか処理しないので。

Rufusは2011年から続くオープンソースプロジェクトで、累計ダウンロード数は数千万本規模、GitHubのスター数は3万5,900を超える。それでも開発体制はピート・バタール一人だ。日々飛んでくるissueをすべて精読していたら開発時間がなくなる。だからこそチェックリストとログ提出がプロジェクト運営の生命線になっている。

zoomwaffleの最初の報告は、バグそのものは実在していたものの、ログを添付しなかったために速読モードで処理され、誤った判断を引き出した。pineapple63が丁寧にログ付きで再現手順を示したことで、ようやく開発者の手が動いた。

オープンソースプロジェクトに不具合報告を出すユーザーにとっては、教科書的なやり取りでもある。

Rufus 4.14は何を狙ったバージョンだったのか

このバグが現れた4.14は、もともとRufusとしてはかなり野心的なアップデートだった。日本時間の4月21日にベータ版がリリースされ、その後4月30日に正式版が配信された。

主な追加機能は3つ。1つ目は「Quality of Life」オプションで、Windows 11のインストール時にCopilot、Microsoft Teams、Outlook、OneDriveの強制起動などをまとめて無効化する仕組みだ。2つ目は完全サイレント・無人インストールモードで、ターゲットディスクを自動で選んで全消去するという尖った機能だが、現時点では75%付近で進行が止まる別の不具合がすでに報告されている。3つ目はSkuSiPolicy.p7bという署名ポリシーファイルをESP（EFIシステムパーティション）に配置するオプションで、Microsoft KB5042562に関連するVBS（仮想化ベースのセキュリティ）保護をインストール直後から有効にする。

Windowsの強制パッケージ群を「インストール時点で剥がす」方向にRufusが踏み込んだバージョン、と整理してもよい。

その意欲的なリファクタリングの過程で、長年安定して動いていたWUEオプションの記憶機能を巻き込んでしまった、という構図になる。

修正は時間の問題、ただし

バタール本人が「簡単な修正だ」と書いている通り、この不具合は近日中の4.14系のパッチでつぶされる見込みだ。原因コミットも特定済み、再現手順もログ付きで揃っている。

ただ、Rufusを使ってWindows 11を非対応ハードウェアにインストールしているユーザーにとって、この一件はちょっとした注意喚起ではある。4.13までのバージョンと4.14では、UIに対するこちらの操作が同じ意味を持っていない可能性がある、ということだ。バイパスオプションが意図せず有効になっていても実害はない、というのがバタールの説明だが、同じバージョンで他にも回帰バグが潜んでいる可能性は否定できない。

しばらくは4.13に留まる選択肢もあるし、4.14のメリット（Copilot等の除去、サイレントインストール）が魅力なら次回リリースを待つ手もある。

オープンソースの強みは、こうしたやり取りがすべて公開されていることだ。バグの存在も、開発者の最初の判断ミスも、原因を突き止めた瞬間の説明も、すべてGitHubに残っている。商用ソフトには滅多に望めない透明性だ。

参照元