AI が Windows カーネルを書き上げる時代へ：Claude Fable 5 が示した可能性と課題

Claude Fable 5 Wrote Windows Kernel Code in Rust in 38 Minutes

2026/06/24 CyberSecurityNews — Anthropic Claude Fable 5 の実験的な運用において、Rust で記述された完全で起動が可能な NT 互換 Windows カーネルである “ntoskrnl-rs” モデルが、38分というアクティブな処理時間で生成された。この成果は、AI が生成したコードに対する信頼性や、重要インフラのセキュリティの将来へ向けた重大な懸念を提起している。このプロジェクトは、2026年6月22日にセキュリティ研究者 Matt Suiche と Tolmo の脅威調査チームにより文書化されたものであり、Windows NT カーネルである “ntoskrnl” を Rust で再実装することを目的としていた。

Fable 5 は、単一の連続したセッション内でカーネルの中核となる骨組みを構築し、スケジューラ／メモリ・マネージャ／トラップ／割り込み機構／オブジェクト・マネージャ／I/O マネージャにまたがる 27 のファイルと、約 5,100 行のコードを生成した。

また、このカーネルは QEMU エミュレータ上で正常に起動し、カーネル内部の 14件の全体的なテストをすべて通過した上で、プロジェクトで定められた成功条件である終了コード 33 を返して終了した。

Claude Fable 5 が Windows カーネル・コードを作成

セッション全体の経過時間は約 4時間半であったが、その大半はオペレータがキーボードから離れていた時間であり、モデルが実際に稼働していた時間はわずか 38分であった。Fable 5 は人間の介入なしにシステムの動作を推論する能力を示すとともに、生成の過程で 2 件の深刻な低レベル・バグを自律的に発見しており、その意味で、この成果は単純なコード生成とは異なるものとなる。

EOI オーダーのバグ：割り込み終了信号である End Of Interrupt (EOI) を潜在的なコンテキスト・スイッチよりも前に発行すべきことを特定した。現状では、ディスパッチ処理中にプリエンプションが発生した場合に、ローカル割り込みコントローラがデッドロックする。

IRQL エミュレーションのバグ：ホスト側のテスト結果が 11/12 であった際に、割り込み要求レベルである Interrupt Request Level (IRQL) のエミュレーションで、テスト・スレッド全体に単一の・アトミック (atomic) 変数が使用されていることを特定した。その後に、CPU ごとの実際の挙動を反映する thread_local を用いるかたちで、スレッド単位の実装へと修正した結果、最終的に 12/12 の IRQL テストを通過した。

さらに、Tolmo のレポートによると、このモデルは、コード内にアーキテクチャに関する説明コメントも残している。NT の GDT セレクタの順序が、IA32_STAR MSR のフォーマットと一致する理由を解説している。これは単なるパターン・マッチングではなく、将来の互換性を考慮した ABI 推論能力を示すものと評価されている。

Fable 5 は、プロジェクト全体でゼロから作成されたコードの約 40% を総ターン数のわずか 3% で生成している。その一方で、残された 97% のターンは Claude Opus 4.8 上で実施され、8日間にわたる反復的なデバッグを多用する立ち上げ作業が行われた。その結果、カーネルは修正されていない Windows カーネル・ドライバを読み込み、実際の Windows バイナリである sort.exe／choice.exe／cmd.exe などを実行できるまで拡張された。

このようなモデルごとの役割分担は、意図的なものである。Fable 5 には、隣接する防御的な作業にまで反応してしまうほどの、広範なサイバーセキュリティ安全性分類器が搭載されているからである。Anthropic の Mythos サイバーセキュリティ・モデルの一般公開版として、Fable は 2026年6月10日にリリースされた。しかし、その数日後の米国政府による輸出管理指令により、Anthropic はアクセスを完全に停止せざるを得なくなった。

このカーネルの起動は可能であるが、信頼性が十分に検証された状態には至っておらず、Fable 5 自身もその課題を認識している。Fable による指摘は、dispatcher lock の引き渡し処理／spin lock／DPC queue が、最もリスクの高い経路であるというものだ。さらに、コンカレント性の網羅的な探索には loom を、未定義動作の検出には Miri を利用するよう推奨している。

この成果における最大のセキュリティ上の意味は、生成能力が検証能力を上回り始めたことである。このモデルは、人間のチームが監査できる速度を大きく上回るペースで、x86_64 カーネルの Trusted Computing Base (TCB) を構築できる。

その一方で、形式検証／プロパティ・テスト／コンカレント性モデル・チェッカーといった検証技術により、監査におけるギャップを埋める必要がある。それまでは、AI が生成したカーネルは、正しさが保証されていない起動可能な成果物に過ぎず、TCB の一部を担うべきものではない。

また、現在のインターネットの重要インフラは、老朽化した C 言語のコードベース上で稼働しているが、歴史的にみて、TCB の書き換えが極めて高コストかつ高リスクであり続けたところに、その主な理由がある。

しかし、AI が生成した Rust カーネルにより、二重の効果がもたらされる可能性がある。Rust は、OS における CVE の多くの原因となる、メモリ安全性の脆弱性クラスを排除できる。その一方で AI モデルは、大規模な書き換えに必要とされる人的コストというボトルネックを解消できる。

さらに、検証ツールが成熟すれば、レガシー C コードを維持し続ける経済的根拠は失われる可能性が高い。その結果として、ソフトウェア・スタックの大部分が、AI 主導によるメモリ・セーフな再実装により置き換えられる可能性も生じる。

訳者後書：AI が生成したカーネルコードにおける問題は、人間の監査能力を大幅に上回る速度で TCB (Trusted Computing Base) が構築されてしまう点にあります。今回の、Rust による Windows カーネルの再実装では、従来の C 言語で発生しやすかったメモリ安全性の脆弱性 (CVE の主な原因) を排除できる可能性が示されました。しかし、形式検証などの検証技術が追いついていないため、起動はできても正しさが保証されていない成果物になってしまいます。開発現場では、AI の圧倒的な生成スピードに対して、その安全性を担保して検証していくための方式が、これからの技術者が向き合うべき重要なテーマとなるのでしょう。よろしければ、Claude での検索結果も、ご参照ください。