サイレントデータエラー、またはサイレントデータ破損（Silent Data Errors/Silent Data Corruption）は、チップが従来の製造テストに合格することと、稼働期間全体を通じて正しい結果を生成できることの間に広がる隔たりを明らかにしている。プロセッサは、ATPGテスト、遷移故障・縮退故障のテスト、速度重視の構造テストに合格しても、明確な故障を記録せずに計算を誤って実行し、その破損した結果がアプリケーションやAI学習タスクへ渡る可能性がある。
この見解は、Semiconductor Engineeringが2026年9月10日に掲載した分析に基づくもので、Advantest、Siemens EDA、NXP、Synopsys、Intel、Meta、Google、proteanTecsの見解と結果をまとめている。これは特定製品の発表に関するものではなく、プロセッサの品質、テストカバレッジ、データセンター到着後の管理を定義する方法の変化に関するものである。
チップレベルではまれでも、フリートレベルでは広範な問題
サイレントデータエラーは、単一のデバイスで測定するとまれに見えるが、数百万個のプロセッサが高い利用率で稼働すると、頻発し、コストのかかる問題になる。GoogleとMetaによる初期の分析では、これらのエラーは1,000台に1台のサーバーに影響する可能性があり、これは100～1,000ppmの不良率に相当する。1FIT、すなわち10億稼働時間あたり1件の故障という割合であっても、1,000万台を導入した場合、約4日ごとに1件のエラーが発生する計算になる。
危険性は、エラーが不正な数値結果や未定義値として現れ、その後データベースの破損、AIモデルの予期しない動作、または矛盾した分析結果を引き起こす可能性にある。プロセッサ自体がエラー信号を送らない場合があるため、長時間のタスクの最後に不合理な結果が現れるまで、問題が発見されないこともある。
なぜ従来のテストは失敗するのか
サイレントエラーは、高抵抗の金属接続、弱いブリッジ欠陥、タイミングや電圧の変動に加え、経年劣化、放射線、温度、負荷の影響など、限界的な欠陥と関連している。先端製造ノードではマージンが狭くなり、接続が小型化して抵抗が増大するため、その可能性が高まる。また、チップレットに依存するパッケージによって、検証経路の複雑さも増している。
業界では、破損した実行結果のエラーのおよそ80%が、ゼロ時点のテストをすり抜ける欠陥に関連し、残りの20%は断続的に発生するか、経年劣化の結果として現れると見積もっている。しかし、電圧、周波数、温度、経過時間、負荷の種類について、考えられるすべての組み合わせをテストするのは現実的ではない。また、システムレベルで発生した故障を、チップテストにおける特定の欠陥パターンと結び付けるには、数週間かかることがあり、設計、テスト、故障解析、システム統合の各チームの協力が必要になる。
Siemens EDAは、遅延故障をテストする際に単一の入力切り替えに依存すると、実際の機能動作を十分に再現できない可能性があると指摘している。複数の入力を切り替えることで、より大きな遅延が発生する可能性があるためだ。そのためテストでは、構造的な故障モデルだけに頼るのではなく、電圧、温度、周波数の複数の条件を対象にする必要がある。
工場からデータセンターまで、より深いテストへ
この問題は、テストカバレッジの概念を再定義している。既知の製造欠陥のうちテストで検出できる割合を数えるだけでなく、実際の稼働環境と実負荷の下で誤った計算結果を検出できる可能性も、カバレッジに関連付けられるようになる。そのため企業は、システムレベルの機能テスト、負荷を考慮したテスト、タスクモードのテストに加え、組み込みテストの設計改善やチップ内部のマージン監視にも取り組んでいる。
Intelの経験は、課題の規模を示している。Intel Xeonプロセッサの5世代にわたり120万個のプロセッサをテストした後、同社はDCDiagスイートで1,000を超える機能テストを、またサイレントエラーの欠陥を検出するために5,000件の合成ストレステストを必要とした。テストは欠陥に均等に効果を発揮したわけではない。5%のテストだけで不良部品のおよそ50%を検出できた一方、エラーの90%を検出するには1,000件を超えるテストの半数以上が必要だった。また、欠陥の70%以上は1つのテストでしか検出されず、ある製品世代で有効だったテストレシピを、次世代へそのまま移行することはできなかった。
フリートでは実際に何が変わるのか
対応は工場の出荷ゲートで終わらない。データセンター運用企業は、異常な挙動を示すサーバーやコアを切り分けるため、ソフトウェアによる検査とフィールドテストを複数層で利用している。Metaでは、Fleetscannerプログラムがサーバーをサービスから外し、既知の結果が得られる計算テストを実行する。一方、Rippleプログラムは通常運用中に短いパターンを実行する。Hardware Sentinelはテスト負荷を割り当てずにアプリケーションの例外とシステムの挙動を分析し、Metaによれば、異なるアーキテクチャ、アプリケーション、データセンターにまたがるテストによって、従来のテストベースの手法と比較して検出率を40%向上させた。
Googleは、エンドツーエンドのテストセット検証、計算の重複と比較、不変条件のチェックとアサーション、転送中のデータ検証、保存データの定期検証など、複数の保護手段を利用している。Spanner方式のアプリケーション測定によって破損を検出し、疑わしいデバイスをフリートから除外することもできる。また、デバイスが戻ってきた際の検査方法を調整し、問題が悪化する前に問題の影響を受けやすいコアを特定する。
出荷時テストからシリコンのライフサイクル管理へ
こうした動向は、タイミング、電圧、温度、劣化のマージンを継続的に監視し、時系列分析と機械学習を利用してサイレントエラーへ変わる前の逸脱を検出する方向へと業界を動かしている。パラメトリック測定と機械学習モデルは、予測されるプロファイルから逸脱するデバイスの切り分けに役立つ可能性がある。また、命令の種類を変えたテスト、実行の複製、コア間の比較によって、検出の可能性を高められる。
ただし、このアプローチにも限界がある。すべてのエラー機構を捉えられる単一の方法は存在せず、テスト結果が設計から別の設計へ自動的に移行するわけでもない。また、物理的な欠陥から離れたアプリケーションに影響が現れる場合、根本原因の診断は依然として難しい。分析ではさらに、メーカー、テストツールのベンダー、データセンター運用者、大学の間での故障データの共有が、商業上および法的な考慮によって依然として限定的であることも指摘している。したがって実際の変化は、単一のテストを追加することではなく、製造から運用まで広がる可視性の連鎖を構築することである。その際、プロセッサの品質は出荷時点だけで完全に決まるものではないと認識する必要がある。