Gemini 3.5 Flash、ASUSノートのLinux起動遅延を解明

GoogleのAIモデル「Gemini 3.5 Flash」が、高級ノートPCにおけるLinuxカーネルの異常な起動遅延の特定に貢献した。Phoronixの報道によれば、AMD Ryzen 9プロセッサと32GBのRAMを搭載するASUS ROG Strix G16 G614ラップトップで、カーネル起動に約36秒を要する問題が発生。Gemini 3.5 Flashが支援したカーネルメーリングリストへの投稿を通じて、原因がデバイスのファームウェアにあることが突き止められた。

問題の概要と発見

当該ラップトップは高性能な構成でありながら、カーネル起動に30秒以上かかるという異常な状態にあった。一般的な現代のIntel製またはAMD製ノートPCでは、カーネル起動にこれほどの時間を要することは稀であり、ユーザーのMarco Scardovi氏は問題の調査に着手した。調査の過程で利用されたのが、GoogleのGemini 3.5 Flashモデルの支援機能「Google Antigravity」である。

Phoronixの記事によると、投稿者はGeminiの支援を受けながらカーネルメーリングリストに問題を報告。その結果、起動遅延の原因はASUSのファームウェアがタッチパッドのGPIOラインを起動時にアサート（論理Low）したままにしていることに起因することが判明した。

技術的な原因と仕組み

Scardovi氏の説明によれば、これらのラップトップでは、ファームウェアがタッチパッドのActiveBoth GPIOラインを起動時にアサートしたままにする。カーネルの起動時初期状態ロジックでは、ActiveBoth割り込みがLow状態で検出されると、その割り込みを1回再生して初期状態を同期する。この処理がプローブパス内で同期的にハンドラを呼び出す仕組みになっており、問題のラップトップではその割り込みハンドラが遅延またはハングするため、同期的な呼び出しが約36秒間ブロックされ、起動全体が停滞する。

つまり、ハードウェアの初期化段階で、本来なら瞬時に完了すべき割り込み処理がファームウェアの不適切な状態設定によって長時間待機させられていたというのが実態である。

Gemini 3.5 Flashの役割

Gemini 3.5 Flashは問題の特定に貢献したものの、最終的な原因の正確な特定には至っていない。メーリングリストでのコードレビューにおいて、AIの指摘した原因はタッチパッド関連ではなく、ACPIダンプの分析からグラフィックス関連がGPIO問題を引き起こしている可能性が示唆されている。

この点は重要である。AIは問題の切り分けに一定の貢献をしたが、根本原因の特定には至らず、人間の開発者による追加調査が必要だった。Gemini 3.5 Flashが生成した初期分析は「部分的に正しい」という評価であり、完全な自動解決には至らなかった。

カーネルパッチの提案と今後の対応

現在、LinuxカーネルにはDMIクワークパッチが提案されている。このパッチは、ASUS ROG Strix G16 G614ラップトップにおいて、問題のあるファームウェアの動作を回避し、長大な起動時間を抑制するための暫定的な対策である。パッチ適用後のカーネル起動時間は、同スペックのノートPCに期待される水準にまで短縮される見込みだ。

ただし、根本的な解決にはASUS/AMD側による適切なファームウェア修正が不可欠である。パッチが提案されたメーリングリスト上では、ベンダーに対して適切なファームウェア修正を求める議論が継続中であり、本パッチはBIOSアップデートが提供されない環境でも動作するように、上流カーネルに取り込まれる可能性が高い。

過去の事例との共通性

今回の事例は、デバイスファームウェアがもたらすブート遅延問題として典型的なパターンの一つである。近年、高級ノートPCにおいても、ファームウェアの品質問題でLinux起動が遅延するケースが散見される。特に、省電力機能やタッチパッド、グラフィックス周りのGPIO制御は、メーカーごとに実装が異なるため、問題が発生しやすい領域である。

Linuxカーネル開発コミュニティでは、このようなベンダー依存のファームウェア問題に対し、DMIクワークなどの回避策を蓄積することで対応しているが、根本的にはベンダー側のファームウェア品質向上が求められる。この点については、本サイトで以前報じた「Microsoft Defenderの特権昇格脆弱性「RoguePlanet」公開(https://singulism.com/ja/microsoft-defender-rogueplanet-zero-day)」でも指摘したように、ファームウェアレベルの問題がOSやアプリケーションの動作に深刻な影響を与えるケースが増えている。

AI支援によるデバッグの現状

Gemini 3.5 Flashによる支援は、カーネル開発の現場におけるAI活用の一例として注目に値する。AIモデルは膨大なコードベースや過去の議論を学習しており、問題の切り分けや原因の仮説提示において人間の開発者を補助できる。本ケースでも、AIが問題の焦点をGPIO関連に絞り込んだことで、調査の方向性が明確になった可能性がある。

ただし、今回のようにAIの分析が完全には正確でなかったケースも存在する。AIによるデバッグ支援は、あくまで「強力な仮説生成ツール」として位置付けるべきで、最終的な検証と修正は人間の専門家が担う必要があるという現実を改めて示している。Google Researchが公開した「TimesFM 2.5(https://singulism.com/ja/google-timesfm-2-5-time-series-forecasting)」のような時系列予測モデルと異なり、デバッグ用途ではより高度な因果推論とコンテキスト理解が求められる。

編集部の見解

今回の事例は、AIによるカーネルデバッグ支援が実用的な段階に入ったことを示している。短期的には、Gemini 3.5 Flashのようなモデルが、開発者の問題切り分け時間を大幅に短縮する事例が増えるだろう。特に、カーネルメーリングリストのようなテキストベースの議論が中心の場では、AIによる初期分析の提示が効率を高める。ただし、AIの結論が必ずしも正確でない点は、依然として人間のレビューが不可欠であることを示唆する。3〜6ヶ月以内に、同様のAI支援事例が他のハードウェア問題でも報告される可能性が高い。 長期的視点では、AIがカーネル開発のワークフローに本格的に統合される未来が見える。1〜3年のスパンで、ベンダーが提供するファームウェアの品質検証にAIが活用されるようになるかもしれない。現状は事後的対応に留まるが、将来的にはAIがファームウェアの設計段階で潜在的な問題を予測し、起動時のような低レベル処理の不整合を事前に検出できるようになれば、ハードウェアとソフトウェアの協調はより円滑になる。今回のASUSケースは、その過渡期を象徴する出来事と言えそうだ。

参考

• Phoronix — 2026-06-21T10:43:53.000Z公開