Linux

gkh_clanker_t1000の正体、Framework Desktopが浮上

Linuxカーネルのナンバー2、Greg Kroah-Hartmanがバグ発見に使う謎のAIツール「gkh_clanker_t1000」。その動作環境がFramework Desktop上のローカルLLMである可能性が浮上した。

情報の灯台

2026年4月26日

「gkh_clanker_t1000」の正体が一歩、明らかに

Linux カーネルの安定版（stable）メンテナでLinus Torvalds（リーナス・トーバルズ）に次ぐ実質的な「ナンバー2」と評されるGreg Kroah-Hartman（グレッグ・クロー＝ハートマン、以下GKH）が使う謎の補助ツール「gkh_clanker_t1000」について、その動作環境の手がかりが本人のMastodon投稿で示された。映っていたのは、AMDのRyzen AI Max+「Strix Halo」を搭載したFramework Desktopだ。

PhoronixのMichael Larabelは、この写真を踏まえて「ローカルの大規模言語モデル（LLM）を動かすための強力なマシン」だと指摘している。つまり、GKHはOpenAIやAnthropicのクラウドAIを叩いているのではなく、自宅の机の上で、自分の手元のハードウェアでバグ発見を回している、ということになる。

写真を見る限り、机の上はやや雑然としていて、Framework Desktopの隣にはペンギンの人形やモニター、小型のテストボードらしきものが並んでいる。世界中のLinuxサーバを支える人物の作業環境としては、拍子抜けするほど普通だ。

clankerブランチが出してきたバグの数々

「clanker」とは、もともとAIや人型ロボットを軽く揶揄するスラングだ。T1000は、映画「ターミネーター2」に登場する液体金属ロボットからの引用とみられる。GKHが自分の作業ブランチに「clanker」と名付け、各パッチに「Assisted-by: gregkh_clanker_t1000」というGitタグを入れ始めたのが今月初め。命名のセンスが、AIに対する彼の距離感をよく表している。

最初に槍玉に上がったのはksmbdとSMB関連のコードだった。「ローカルの仮想マシンでセットアップとテストがしやすかったから」というのが理由だ。そこから出てきたのは、smb2_get_ea()のEaNameLengthバリデーション漏れ、sub_auth[2]を読む前の境界チェック不足、SPNEGOデコード失敗時のmechTokenメモリリークといった、地味だが「信頼できないクライアント」を相手にすると刺さりかねないバグだった。

Assisted-by: gregkh_clanker_t1000

clankerブランチのパッチには、すべてこのGitタグが添えられている。AIが手を貸したことを記録に残す、Linuxカーネル開発における最初期の試みのひとつだ。

このパッチを一切信用しないでくれ。受け入れる前に、私がでっち上げてないか検証してほしい。

GKHはレビュー担当者にそう書き添えた。

その後、clankerブランチには48時間でUSB、HID、F2FS、LoongArch、WiFi、LEDなど、Linuxの幅広いサブシステムにまたがるパッチが流れ込んでいる。fuzzerが見つけ、人間が直す。AIに自動でコミットさせるのではなく、人間がレビューして責任を取るという線を、GKHははっきり引いている。

なぜFramework Desktopなのか

Framework Desktopは、修理や交換のしやすさを売りにしてきたFrameworkが2025年に発表した4.5リットルのMini-ITX筐体だ。最上位構成は16コアのZen 5 CPUと40基のRDNA 3.5 CUを統合した「Ryzen AI Max+ 395」を搭載し、最大128GBのLPDDR5xメモリをオンパッケージで持つ。価格は最上位構成で1,999ドル（約31万8,000円）から始まる。

メモリが基板にはんだ付けされている点はFrameworkの「修理する権利」哲学とは矛盾するが、これは256GB/sのメモリ帯域を稼ぐための妥協だ。CPUとiGPUが大容量の共有メモリを高速に叩けるからこそ、ローカルでLLMを動かす素地ができる。

ここがポイントだ。128GBの共有メモリは、量子化された大規模モデルをまるごと載せられる広さにあたる。クラウドAPIに毎回問い合わせなくても、手元で何度でも反復できる。カーネルの未公開パッチを外部のAIサービスに投げ込むことには、機密性とライセンス両面で慎重さが要る。ローカルLLMなら、その懸念がほぼ消える。

PhoronixのMichael Larabelは、GKHが最近GitHub上で各種AI/LLM関連プロジェクトを試している事実も合わせて指摘している。clanker_t1000の中身そのものは公開されていないが、ローカルLLMでfuzzing結果の解析やパッチ生成補助をしている、という推論には十分な状態証拠がそろってきた。

Linusも「コードを書かせるより、レビューに使いたい」

Linus Torvaldsは去年のOpen Source Summit Japanで、AIをカーネル開発にどう取り込むかについて踏み込んだ発言をしていた。彼は「AIにコードを書かせることにはあまり興味がない」とした上で、メンテナンスやパッチチェック、コードレビューの道具として使うことに関心がある、と述べている。実際、自分が拒否したマージを内部AI実験で再評価させたところ、AIは反対意見に同意した上で、追加で直すべき点まで指摘してきたという。

GKHのclanker_t1000は、その方向性をすでに走り始めた実装に見える。バグ候補を浮かび上がらせるのはAI、判断と責任は人間。LLVMが今年導入した「human in the loop」AIポリシーや、Gentooが2024年に出したAI生成コード全面禁止とは別の落とし所だ。

クラウドAIが当然視される時代の、もう一つの選択

カーネル開発者の手元のマシンが、クラウドの大手AIサービスではなくローカルLLMを回す方向に動いているのは、それだけで一つのメッセージだ。プライバシー、レイテンシ、コスト、外部依存。クラウドAIにはどれも付きまとう。AMDのStrix HaloとFramework Desktopの組み合わせは、それらをまとめて回避する具体的な選択肢として、すでに机の上の現実になっている。