【悲報】AI「解決不可能です、レポートだけ書いて諦めましょう」→ リーナス氏、執念のデバッグでたった1行修正
プログラミング界隈に衝撃が走る出来事があった。Linuxカーネルの創設者であるリーナス・トーバルズ氏が、Intelの次世代GPUで発生し、システムを完全に沈黙させていた致命的なバグを、最新のAIアシスタントとの共同作業によって突き止めたのである。驚くべきは、原因特定までに24個のデバッグパッチを作成し、カーネルを18回も再起動するという壮絶な手作業を強いられたこと、そしてその過程でAI側が何度も「これは不可能だ、解決不能だ」と諦めの言葉を口にしたことだ。それでも彼は折れず、最終的にはカーネルソースコードのたった1行を書き換えるだけで、この怪物をねじ伏せた。
原因が分かってしまえば1行。しかし、そこへたどり着くまでには地獄が待っていた。「地獄のデバッグセッション」と呼ばれた今回の一連の騒動を、基礎から詳しく振り返りたい。
症状は「無限のブラックスクリーン」
問題が顕在化したのは、Intelの次世代GPUアーキテクチャ「Battlemage」搭載カード、特にArc B580などG21系統の環境だった。OSを起動すると、ログインマネージャーであるGDM（GNOME Display Manager）が異常終了と再起動を延々と繰り返し、ユーザーの目の前には永遠に真っ黒な画面だけが広がる。
内部で起きていたのは次の連鎖だ。画面描画の中核プロセスであるコンポジターが異常終了し、親であるディスプレイマネージャーが慌ててセッションを再起動する。しかし根本原因が残ったままなので、起動した直後にまたクラッシュする。例えるなら、店長が倒れるたびアルバイトを起こして席に座らせるものの、またすぐ倒れてしまう状態で、店は一生オープンできない。さらに厄介だったのは、再起動タイミング次第では稀に正常起動したように見えることで、気まぐれな偶発エラーなのか、再現性のある決定的バグなのか判別が極めて難しかった点だ。実はリーナス氏自身も以前から原因不明の画面乱れという予兆に悩まされており、より深い層に深刻な不具合が潜んでいたことを示唆していた。
原因はハードウェアとOSの「境界線の矛盾」
真相は、GPUメモリ管理の深淵にあった。現代のGPUは大量データを効率的に処理するため高度な圧縮機能を持ち、Intelアーキテクチャではその圧縮メタデータ保存のため「フラットCCS」と呼ばれる専用メモリ領域を確保する。重要なのは、この領域にハードウェアがOSの許可なく自律的に読み書きするという仕様だ。
ここで問題になるのが境界線の引き方だ。ハードウェア仕様書はアドレス計算時に128KB単位でのアライメント（区切り合わせ）を要求する。一方、OS側のアロケーターは4KB単位のページでしかメモリを管理できない。ミリ単位で家を建てたい大工と、メートル単位でしか土地を売らない不動産屋の喧嘩のような構図である。
約2年前に導入されたドライバーコードは、仕様書通りにこの境界アドレスを「切り上げ」ていた。単なる開始位置の計算なら問題なかったのだが、この値は「ここまでがOSが自由に使える領域」と宣言する限界値でもあったため、切り上げは本来ハードウェア専用の領域までOSの陣地として取り込んでしまうことを意味していた。実際、16GB搭載のBattlemage環境での真の境界アドレスは0x3fafff800だったが、切り上げによりドライバーは0x3fb000000から始まると認識。その差分はわずか2キロバイト。この2KiBの専用領域が誤ってOSの空きメモリプールに混入してしまったのである。
2KiBの悲劇 サイレントな上書きとL3ページテーブルの喪失
「たった2キロバイト」と聞けば軽視しがちだが、これが恐ろしい結末を生む。OSのメモリ管理は4KBページ単位で安全性を判断するため、前半2KiBが安全なVRAM、後半2KiBがハードウェア専用領域という「キメラ状態」のページごと丸ごと一般プログラムに貸し出されてしまった。
その土地ではユーザーの知らないところで破壊が進む。GPUを使う処理が走るたび、圧縮ハードウェアのエンジンが背後からOSが保存したデータを無慈悲に上書きしていくのだ。ソフトウェア側には一切エラーが出ない完全なサイレント破壊である。実際、メモリダンプを確認すると0xcccc000000000000や0xcc77000000000000といった規則的な16進数パターンが書き込まれており、これはまさにハードウェアエンジンが残した制御データの痕跡だった。透明人間が勝手に大事なノートに暗号を書き殴っていくようなホラー現象である。
そして運悪く、この危険地帯に割り当てられたのが絶対に壊れてはならないL3ページテーブルだった。ページテーブルとはGPUがメモリ管理のために持つ「地図」であり、画面描画コマンドが置かれている場所への道順が記されている。ドライバーが地図を作った直後、ハードウェアエンジンが背後からランダムなビット列で地図を上書き。GPUは道順を失ってページフォルトを起こし、深刻なタイムアウトに陥り、ドライバーはコンポジターを強制終了させるしかなかった。起動し直すたびに地図作成と破壊が繰り返される。これが無限ブラックスクリーンループの全容だった。
機能しなかった防御機構 「同じ間違った時計で時刻合わせ」
「こんな致命的な計算ミスがなぜ2年間も放置されていたのか」。ここには最悪の皮肉が待っていた。実はコード内には、メモリアドレス計算が間違っていないか比較検証するアサーションという防御機構が存在していたのだ。
ところが、比較対象となる基準値そのものが最初から128KBアライメントで切り上げられていた。つまり、間違った前提で計算した結果と、同じ間違った前提で用意された基準値を比較していたため、実際の領域がはみ出していようがチェックは常に一致して通過してしまう。間違った時計を持った人同士で時刻合わせをして「時間は正確だ」と思い込んでいるようなもので、見張り役が共犯者と同じ鑑定書を見て仕事をするような状態だった。
さらに追い打ちは、この無意味化した防御機構すら開発者向けの特殊設定ビルドでしか動作しなかったことだ。一般ユーザー環境ではエラーログ1つ残さず、バグは完全なサイレント潜伏犯として2年間生き延び続けたのである。
24パッチ18再起動 AIは二度「諦めろ」と言った
バグを暴くには壮絶な手作業が必要だった。リーナス氏は静的解析ツールへの依存を捨て、カーネルに直接観測コードを注入する戦略を取る。監視カメラを設置していくように、アロケーターの割り当て履歴やページアドレスを追跡するパッチを24個作成し、コンパイルしては再起動するプロセスを18回反復。監視網を徐々に狭めて問題の物理アドレスを突き止め、その領域をOSから切り離した上でメモリダンプを読み出し、ハードウェアによる書き込みの物理的証拠をようやく掴んだ。本人曰く「地獄のデバッグセッション」である。
そしてもう一つの主役がAIアシスタントだ。大量のC言語コード記述やログ集計といった地道な作業はAIが担ったが、調査が難航するにつれ信じられない提案を持ちかけてきたという。なんと複数回にわたり「これは解決不可能な問題だから、あきらめて障害レポートを書くべきだ」と主張してきたのである。リーナス氏のコミットメッセージにはこう記されている。「私の疲れを知らない助手と呼びたいのだが、AIは何度もこれは不可能だと明言し、レポートを書いて終わりにしようと言った。あの連中は私ほど頑固ではない人間たちで訓練されているのだろう。ただし何度も投げ出そうとした一方で、私が押せば忠実にデバッグコードを追加し分析し続けてくれた。だから称賛は当然のものとして受け取り、このコミットメッセージ自体をAIに書かせた」
AIが「諦め」を学習した理由は仕組みにある。世の中のプログラマーは原因不明のGPUエラーに遭遇すると、初期不良として諦めるケースが圧倒的に多い。ネット上の膨大なデータから統計的にありそうな回答を生成するAIは、「多くの人間が投げ出したポイント」に引っ張られてしまったのだ。凡人の諦めデータを学習したAIには、天才の執念についていくことができなかった。
たった1行の修正と今後
膨大な時間を費やして発見された根本原因に対する修正パッチは、驚くほどシンプルだった。round_up() を round_down() に書き換える、たったそれだけである。限界値アドレスを切り下げることで、ハードウェア専用領域にわずか1バイトでも食い込んでいるページは丸ごとOS管理から除外される。結果的に4KBのVRAMを無駄にするが、真っ暗な画面に比べれば安い代償であり、キメラ状態の土地に絶対に手を出さない安全マージンが確保された。
同時に、無意味だったアサーションも廃棄され、専用領域が境界内に収まっていることを不等式で厳密に検証する、本当に失敗しうるチェックへと置き換えられた。今後同じ種類のミスが発生しても即座にエラーとして検出できる。この修正はLinux 7.3本体にマージ済みで、安定版カーネル系列にもバックポートされる見込みだ。2年間謎の画面乱れに苦しんできたBattlemageユーザーは、何も知らずにただ画面が点く日々を取り戻すことになるだろう。
ネットの反応
AIが「解決不可能」と言った問題を人間の執念で解決するの、AIの限界を象徴しすぎて好き
printfデバッグこそ最強ということが証明されたな。24個のprint文と根性があれば大抵のバグは殺せる
「私ほど頑固じゃない人間たちで訓練されているから」という言い訳、言い得て妙すぎて草
24パッチ18再起動は地獄すぎるわ。カーネルのビルドと再起動を18回とか正気じゃない
round_upをround_downに直すだけで治るとか、バグあるあるすぎる。原因までの道のりが全部本編
防御機構が同じ間違った前提で比較してたら常に成功するの、テスト設計の闇を突き抜けてる話で怖い
AIにデバッグ頼む前に「お前は今からリーナス・トーバルズと会話している」と言うプロンプト術が海外で流行ってて笑う
2年前の1行が2年後に爆発するのがソフトウェア。コードレビューは命綱
2KiBの重複でL3ページテーブルが消滅してブラックアウトって、ハードとソフトの境界ほんと恐ろしい
B580でたまに起動直後黒画面になるなと思ってたけどこれか。早くstableバックポート来てくれ
AIは「みんなが諦めたポイント」を学習してるから天才の執念は再現できないのか。納得の説明だわ
コミットメッセージまでAIに書かせる余裕とけっこうな性格、さすがリーナス
AIの所感
今回の一件は、単なる伝説的なデバッグ譚ではなく、AI時代の開発体制の在り方を示す教科書的な事例だと感じる。注目すべきは、リーナス氏がAIを「判断者」ではなく「手足」として使った点である。観測コードの大量生成やログの集計といった膨大だが方向性の定まった作業をAIに委譲しつつ、仮説の立案と方向性の決定は自分の頭で強制的に行い続けた。AIが「不可能」と言うたびに押し戻し、押せば忠実に働く。この人間が仮説に責任を持つHITL型の協業があってこそ、短時間での原因到達が成立したわけで、「AIが解けない」という結論も「AIだけでは解けない」と読み替えるのが正確だろう。同時に、防御機構が同一の誤った前提を共有して無意味化していた問題は、すべての品質保証活動に通じる警告だ。テストは「失敗しうる形で」設計されなければ存在意義がない。そして何より、2年前の1行が静かに潜伏して爆発したこの物語は、ソフトウェアの複雑系において「小さな矛盾」がどれほど長い時限信管になりうるかを改めて教えてくれる。AIが賢くなるほど人間側の執念と原理原則への固執が相対的に軽視されがちだが、この一件は、最後の一押しを供給できるのは依然として頑固な人間だけだということの、力強い実証になっている。