まず認めておくべきなのは、Minisforumが自社製品のBIOSアップデートを公開しているという点です。ミニPC分野のハードウェアメーカーの多くは、開発完了時点で固定されたBIOSのまま製品を出荷し、その後一度も改訂しません。ファームウェアレベルの問題は、顧客の手元にずっと残ることになります。Minisforumはそうではありません。BIOSの改訂版は存在し、公開され、実際のバグに対処しています。同社のファームウェア対応について公平に論じるなら、ここが出発点です。

一方で、同じく認めなければならないのが配布方法です。話が一変するのはここからです。

Windows版フラッシュツールでの手順

Minisforumが最近の製品ラインのほとんどで案内しているBIOS更新手順は、Windows上で動くフラッシュツールです。顧客は実行ファイルをダウンロードし、Windows上で実行し、ツールがマザーボードのSPIフラッシュチップに新しいBIOSイメージを書き込むのを待ちます。一部の一般向けマザーボードメーカーでもおなじみの手順で（MSIのLive Updateが思い浮かびます）、それ自体が本質的に危険なわけではありません。

Minisforumの場合に問題となるのは、記録されている失敗率です。

UM780 XTXのBIOSに関するBadcapsフォーラムのスレッドには、詳しく説明する価値のある具体的な故障パターンが記録されています。Windows版フラッシュツールが新しいBIOSイメージの書き込みを始め、処理の約31%まで進んだところで、ブルースクリーンを出して停止します。システムは再起動します。この時点でBIOSは中途半端に書き込まれた状態です。古いイメージは消え、新しいイメージは不完全で、マザーボードのフラッシュチップには起動できないファームウェアが入っています。

失敗後のUM780 XTXは、電源ボタンにまったく反応しません。POSTビープ音もありません。画面出力もありません。システム内部からの復旧につながるような、認識できる挙動は何もありません。Badcapsはハードウェア修理のフォーラムで、この症状を抱えてたどり着いたユーザーは、フラッシュチップを取り外し、プログラマーで外部から書き込み直し、再び取り付けるかどうかを検討するトリアージの段階にいます。これは基板レベルの修理作業です。一般的な消費者にできることではなく、まともな製品のBIOS更新手順が故障パターンとして生み出してよい結果でもありません。関連記事：UM773 Liteのユーザーが壊れたマザーボードの復活をiFixitに求めている件。

BD770iがBIOS更新後にPOSTしなくなった状態を記録したLevel1Techsのスレッドは、別の製品で同じパターンを捉えています。流れはこうです。Windowsをインストールし、MinisforumのBIOS更新ツールを実行し、更新完了後に電源を入れ直すと、画面が映らず、ボードが文鎮化したと判断することになります。スレッドの後続ページは、コミュニティによる復旧方法の議論で占められています。

コミュニティの回避策

「Windowsを使わないMinisforumのファームウェア更新」と題したQuindorianのブログ記事が存在するのには、明確な理由があります。筆者がこの故障パターンに何度も遭遇したり、その報告を読んだりした末に、別の手順を文書化することにしたからです。Minisforumの配布パッケージから生のBIOSイメージを取り出し、FAT32のUSBドライブに置き、システムをUEFIシェルで起動して、ファームウェア内からBIOSを書き込みます。Windowsは完全に迂回します。

UEFIシェルでのBIOS書き込みは、この種の作業における業界標準の安全な推奨手順です。その理由は構造的なものです。Windows版フラッシュツールはOSの上で動き、OSはカーネルの上で動き、カーネルはドライバーの上で動き、ドライバーはまさに書き換えられている最中のBIOSの上で動いています。このスタックのどこかで中断が起きると（ドライバーのクラッシュ、一瞬の電源トラブル、バックグラウンド処理を予約するWindows Updateなど）、任意の時点で書き込みが中断される可能性があります。UEFIシェルでの書き込みはファームウェア環境上で直接実行され、OSへの依存も、処理を妨げうるバックグラウンドサービスもありません。始めるまでの手間は多いものの、最後まで完了させるうえではずっと安全です。

MS-01のBIOS更新に関するVirtualizationHowtoのガイドは、別のMinisforum製品で同じ手順をたどっています。このガイドが存在するのも、Minisforum自身のドキュメントがUEFIシェルでの方法を目立つ形で推奨していないからです。コミュニティは、メーカーが推す方法は別の手順書が必要なほど危険だと判断し、その手順書を自分たちで書きました。関連記事：Raptor LakeのバグとMS-01のBIOSリリースノート。

構造的な問題

メーカー製品のファームウェアを更新する最も安全な方法を、メーカーではなく独立したブロガーが文書化しているとすれば、そのメーカーの顧客の安全に対する考え方はどこかで間違っています。ファームウェア更新は、失敗すれば取り返しのつかない作業です。文鎮化したマザーボードは、カードを抜いて挿し直せば顧客が解決できるような保証案件ではありません。メーカーに求められるのは、顧客の手元に壊れたボードが残る確率が最も低い手順を推奨し、代替手順があれば明確に文書化することです。

記録を見る限り、Minisforumの対応はその逆です。Windows版フラッシュツールが標準で、推奨されている方法です。UEFIシェルという代替手段はメーカー自身の資料には記載されておらず、コミュニティのブログ記事で紹介されているだけです。2つの方法の違いを判断する技術的な知識を持たない顧客は、メーカー自身のダウンロードページの情報設計によって、より安全でない方法へと誘導されています。関連記事：Minisforumのサポートポータルと対応しない傾向。

今後のためのアドバイス

2026年にMinisforum製品のBIOSを更新する際、ドキュメントがWindows版フラッシュツールを推奨手順として示している場合は、進める前に次のどちらかを行ってください。お使いのモデル向けにコミュニティが書いたUEFIシェルでの手順を探して、そちらを使うか、新しいBIOSによる改善がWindows版の方法の文鎮化リスクに見合うかどうかを判断するかです。コミュニティの回避策が存在するのは、標準の方法が回避策を必要とするほど危険だからです。$500〜$1,500のミニPCを買う顧客が、Substackの記事でこれを学ばなければならないのはおかしな話です。しかし、Minisforumがドキュメントを変えるまでは、これが現状です。そして、それを知らない人こそが、危険な標準手順の代償をまるごと支払うことになります。