まず前提を押さえておく必要があります。それが話の土台になるからです。Intel Raptor Lakeの不安定問題（第13世代と第14世代のIntel Coreのデスクトップ向けとモバイル向けシリコンの広い範囲に影響する、クラッシュ、ハング、長期的なチップ劣化の一群）は、Minisforumが生み出した問題ではありません。原因を作ったのはIntelであり、それを認めたのもIntelです。そしてIntelは、根本原因がeTVB（enhanced Thermal Velocity Boost）アルゴリズムと、影響を受けるコアでのVMin Shiftによる劣化メカニズムの組み合わせだと特定したあと、影響を受けるSKUの保証期間を延長しました。この2年間にRaptor Lakeのチップが不安定な挙動を示した購入者が正当な不満を向けるべき相手は、何よりもまずシリコンのベンダーです。それが公平な見方です。

それでもMinisforumについて書く価値があるのは、自社が販売するシリコンに上流の既知の不具合があるとき、ハードウェアベンダーが取りうる対応のなかで、Minisforumがかなり静かなものを選んだからです。そして顧客は、その選択がもたらした影響を今も抱えています。

Minisforum MS-01はどう影響を受けたか

MS-01は、IntelのCore i9-13900HとCore i5-13500Hを上位2つのCPU構成として発売されました。どちらも第13世代Raptor Lakeのチップです。どちらも、Intel Communityフォーラムでユーザーから報告された不安定性のパターンが記録されているIntel SKUの範囲に含まれます。それらのパターンは、最終的に同社が認めたeTVB / VMin Shiftの問題と一致しており、VideoCardzの2024年の記事はこれを業界全体に及ぶ調査として報じました。

MS-01に固有の文脈では、このパターンは2つの形で現れます。i9-13900H搭載MS-01に対するNotebookCheckのワークステーション級レビューは、Cinebenchを複数ループ実行している最中に予測できないクラッシュが起きたことを記録しています。これはまさに、Raptor Lakeの電圧とブーストの異常な挙動を表面化させる、持続負荷のテストです。ハイパーバイザー負荷でのMS-01の不安定性を扱ったXCP-ngフォーラムのスレッドは、もう1つの形を捉えています。デスクトップ用途では問題がなさそうなマシンが、多数のコアを長時間使い続ける仮想化クラスの負荷をかけると、ハングや再起動を起こすというものです。

いずれも、MS-01固有のハードウェア欠陥を示す証拠ではありません。Raptor Lakeが、Raptor Lakeのシリコンとしての限界に達したことを示す証拠です。しかもMS-01の筐体には、ほかの環境と違う挙動をシリコンにさせるような、熱や電力の面での特殊な特性はありません。関連記事：MS-01とMS-A2でのIntel i226-V 2.5GbEの不安定性、MS-01の工場出荷時の熱伝導グリス。

Minisforumがしたこと、そして書かなかったこと

Minisforumは、問題の期間中にMS-01向けのBIOSアップデートを出荷しています。そのうちいくつかのアップデートには、後から振り返ると、IntelがRaptor Lakeの挙動に対処するために提供したマイクロコードに相当するリビジョンが含まれています。これが話の良いほうの半分です。BIOSを最新に保ってきたMS-01のオーナーは、最終的に上流から出荷された対策の恩恵を、おおむね受けています。

あまり良くないほうの半分は、こうした対策の大半が展開されていた時点で、MinisforumのBIOSリリースノートがそのことを何も書いていなかったという点です。リリースノートを読んだ顧客が目にしたのは、バージョン番号と、一般的な表現（「improved stability（安定性の向上）」「updated microcode（マイクロコードの更新）」）で書かれた変更点の一覧だけで、アップデートがIntelの認めたCPUの不具合に対処するものだという明確な記述はありませんでした。業界全体のRaptor Lake問題を追っていなかった顧客には、目の前のアップデートで自分の個体の不安定性が直るのかどうかを判断する手段がありませんでした。BIOSを書き換えるかどうか（失敗すると文鎮化しうる1.9リットルのミニPCでは軽い作業ではありません）という判断が、そのトレードオフを比較するのに必要な情報がないまま下されていたのです。

顧客に必要だった情報

この状況での良いBIOSリリースノートなら、わかりやすい言葉で次の3点を伝えていたはずです。

  1. 対処する不具合。 「このアップデートにはIntelのマイクロコードリビジョンXXXが含まれており、IntelがアドバイザリーYYYで説明したRaptor LakeのeTVB / VMin Shiftによる不安定性に対処します。」
  2. 影響を受ける個体。 「i9-13900Hとi5-13500Hを搭載したMS-01の構成が対象です。i9-12900Hを搭載した構成は影響を受けません。」
  3. ユーザーが想定すべきこと。 「アップデート前：持続負荷の最中に予期しないハングを経験している場合は、このアップデートを推奨します。アップデート後：ブーストの挙動が見直されたため、持続負荷での性能が以前のBIOSバージョンと最大N%異なる場合があります。」

そのどれも記載されませんでした。どの場合も、Tom’s Hardware、Ars Technica、Intel Communityのスレッドを読み、読んだ内容を自分のBIOSアップデートの判断に置き換え、その置き換えが正しいことを祈るのは顧客の仕事でした。正しく置き換えられた購入者もいました。一方で、ファームウェアの更新をすっかりやめてしまった購入者もいました。明確なリリースノートなしにBIOSを書き換えるのに必要な信頼が、彼らに残っていた信頼を上回っていたからです。

構造的な問題点

Intelのシリコンの不具合をミニPCベンダーのせいにするのは、まったく公平ではありません。ベンダーの責任として問うのが公平なのは、そのベンダーを通じてシリコンに代金を払った顧客とのコミュニケーションの頻度と率直さです。MS-01のRaptor Lake問題でのMinisforumのやり方は、問題の名前を出さずに修正だけを出荷するというものでした。このコミュニケーションのスタイルは、愛好家向けフォーラムを毎日読んでいる顧客層には通用しますが、それ以外の顧客すべてには通用しません。これらのチップのライフサイクルが始まって2年が経った今も、自分のBIOSにRaptor Lakeの対策が含まれているかどうかを知らないMS-01のオーナーがいます。それを確かめるのに必要なドキュメントが、一度も書かれなかったからです。その沈黙はシリコンの不具合ではありません。シリコンを彼らに販売したベンダーによる選択でした。