「動かないハード」をClaude Codeで修復　Windowsの通信解析からLinuxドライバーを開発する手法が公開

Linuxの開発者Christian Fredrik Kalager Schaller氏は2026年10月15日、AnthropicのAIコーディングツール「Claude Code」を活用してLinux向けスキャナードライバーを開発し、ノートPC内蔵カメラの画質も大幅に改善したと報告した。数か月間行き詰まっていたスキャナーの解析は、Windowsのメーカー製ドライバーによる正常動作を記録し、Linux側の動作と比較できる環境を整えたことで、一気に進展したという。わずか数時間で最初の画像の読み取りに成功し、数日後には赤外線スキャンにも対応した。同氏は、この開発手法を他の機器にも応用できるよう汎用化し、「hw-harness」としてGitHubで公開している。今回の成果は、AIのコーディング能力だけでなく、実機の動作を観測して仮説を検証できる環境が、ドライバー開発の効率を大きく左右することを示している。

Windowsの正常動作を記録し、AIによるドライバー開発の行き詰まりを解消

開発のきっかけは、Schaller氏が亡くなった母親の遺品から大量の写真のネガフィルムを見つけたことだった。思い出の写真をデジタル化しようと、Linuxで利用できると考えてPlustek製フィルムスキャナー「OpticFilm 8200i」を購入したものの、実際には内部の制御チップが変更されており、手元の個体はLinuxに対応していなかった。同氏はClaude Codeを使ってLinuxのスキャナー共通インターフェース「SANE」に対応するドライバーの開発を試みたが、思うように進まず、数か月間作業を中断していたという。

転機となったのは、AIを利用してマウスドライバーを修正した開発者Tom Crider氏の投稿だった。Crider氏がAIにWindows環境を操作させ、機器の動作を記録する方法を紹介していたことから、Schaller氏も同様の環境を構築することにした。KVM上にWindowsの仮想マシンを用意し、実物のスキャナーを接続してメーカー製ソフトウェアでスキャンを実行する。その際、Linuxホスト側のUSB監視機能「usbmon」を使って通信内容を記録し、続いて同じ機器をLinuxへ戻して、開発中のドライバーで同じ操作を行った際の通信も記録した。

この方法の利点は、正常に動作するWindowsドライバーと開発中のLinuxドライバーの挙動を、同じ仕組みで比較できることだ。10月15日のブログ記事でSchaller氏は、この環境とClaude Codeの能力向上が組み合わさったことで開発が大きく進んだと説明している。数時間後にはLinux上で最初のスキャンに成功し、当初は画質に問題が残っていたものの、ネガフィルムの画像を判別できる状態になった。さらに数日間の作業で、赤外線スキャンにも対応するドライバーを完成させたという。

解析の対象となるのは、スキャンした画像だけではない。USB通信には機器の初期化手順、レジスターへの書き込み、動作準備が整ったかを確認する処理、データ転送量やタイミングなど、ドライバーの動作を理解するための情報が含まれている。例えば、スキャン解像度だけを変えて通信を比較すれば、それに応じて変化する制御値から、解像度を設定するレジスターを特定できる可能性がある。Claude Codeは大量の通信記録から差分や繰り返しパターンを探し、その意味について仮説を立て、確認用のプログラムを作成する。開発者はそのプログラムを実機で動かして結果を確認し、得られた情報を次の解析に利用する。

Schaller氏が公開したhw-harnessの手法文書では、一度に大量の通信を記録するよりも、一つの記録で一つの疑問を検証することを推奨している。例えば、120秒間のスキャン全体を記録するより、ランプの点灯、読み取りヘッドの初期位置への移動、300dpiでの1ラインの読み取りなど、操作を細かく分けた方が原因を絞り込みやすい。同じ条件でWindowsとLinuxの通信を記録し、最初に現れる重要な違いを調べることで、ドライバーのどこに問題があるかを特定していく。

なお、usbmonが記録するのはLinuxカーネルとUSBホストコントローラーの間の要求や応答であり、物理的なUSBバス上の信号を直接測定しているわけではない。Linuxカーネルの公式文書も、ホストコントローラー側に不具合がある場合などには、実際のバス上の通信と記録内容が完全には一致しない可能性があると説明している。それでも、WindowsとLinuxの動作を同じ層で記録すれば、両者の違いを追跡しやすくなる。

今回公開されたhw-harnessのGitHubリポジトリには、Windows仮想マシンの操作、USB通信の記録、機器の接続先の切り替え、Linux側のデバッグなどを支援するツールがまとめられている。Fedoraで開発・検証されており、公開時点の手順ではlibvirt/KVMとWindows 11 Proを利用する構成が前提となる。ただし、Schaller氏が実際にスキャナーやカメラを修正した際には個別に作成したスクリプトを使用しており、公開版のhw-harnessは後から汎用化したものだ。多数の異なる機器で同じ効果が得られるかについては、まだ十分な検証が行われていない。

スキャナードライバーの開発に成功、SANE本体にも対応コードが追加されていた

今回の対象となったPlustek OpticFilm 8200iには、同じ製品名でも異なる制御チップを搭載したモデルが存在する。従来のモデルはGenesys GL845を採用しており、LinuxのSANEですでに対応していた。一方、Schaller氏が購入した個体はGenesys GL128を搭載し、USB IDは「07b3:1825」で、当初はLinuxから利用できなかった。同じ製品名であっても、内部のハードウェア構成が異なれば既存のドライバーをそのまま使用できない場合がある。

Schaller氏は独自のSANEバックエンドを開発し、カラー、グレースケール、赤外線、およびカラーと赤外線を組み合わせたスキャンに対応させた。解像度は300〜7200dpi、各チャンネルのビット深度は8ビットと16ビットをサポートし、赤外線データを利用したほこりや傷の除去機能も備えている。濃度の高いネガフィルムに対応するため、露出倍率を調整する機能も追加した。ドライバーはFedora向けRPMパッケージとして公開されており、GitHubへの更新時に自動ビルドされる仕組みとなっている。

ただし、Schaller氏が開発を再開するまでの間に、SANE本体にも同じスキャナーへの対応コードが追加されていた。同氏によると、対応が加わったのは2026年9月で、SANEの開発版対応表でもGL128搭載モデルは「Basic」として掲載されている。16ビットのカラーおよびグレースケールによる透過原稿のスキャンには対応しているものの、赤外線スキャンは未対応となっている。なお、開発版で対応していても、各Linuxディストリビューションの安定版パッケージにその変更が反映されているとは限らない。

Schaller氏は10月9日、独自ドライバーとSANE本体の開発版を比較した検証結果を公開した。同じスキャナーとネガフィルムを使って測定したスキャン時間は、次のとおりだ。

スキャン解像度	Schaller氏の独自ドライバー	SANE本体の開発版
600dpi	16.7秒	16.4秒
3600dpi	34.6秒	54.4秒

600dpiではSANE本体の開発版が0.3秒速かった一方、3600dpiではSchaller氏の独自ドライバーが19.8秒速かった。ただし、独自ドライバーがすべての条件で高速というわけではない。また、この比較では3600dpiでの出力画像のサイズが異なり、独自ドライバーは5184×3877ピクセル、SANE本体は5184×3519ピクセルとなっていた。走査範囲が完全には一致していないため、同じ処理量を比較した厳密な性能試験とはいえない。

検証には1台のスキャナーと1コマのネガフィルムが使用され、比較対象のSANEにはmasterブランチのコミット「415217c5」が使われた。フィルムホルダーの位置を揃え、両ドライバーから得た16ビットの生データを同じネガ変換処理に通している。フィルムのベース色はそれぞれの出力から推定し、ほこり除去機能は使用していない。ただし、繰り返し測定による誤差は示されておらず、今回の結果は限定された条件での比較となる。Schaller氏自身は、3600dpiで得られる細部の解像度は両ドライバーで同程度と評価している。

独自ドライバーのもう一つの利点は、赤外線スキャンに対応していることだ。フィルムスキャナーでは赤外線を利用することで、画像に付着したほこりや傷の位置を検出し、画像処理によって補正できる。Schaller氏は、この機能を活用するためのGNOMEアプリ「Negative Vibes」もRustで開発した。スキャナーから取得した16ビットの線形画像データと、利用可能な場合には赤外線データも保持し、色調整やネガポジ変換などを非破壊で行える設計となっている。

Negative VibesのGitHubリポジトリによると、アプリはカラー・白黒ネガやスライドフィルムに対応し、TIFF、JPEG、PNG、DNGなどへの書き出しが可能だ。ただし、実機で検証済みなのはOpticFilm 8200iであり、他のフィルムスキャナーで同じ機能が使えるとは限らない。特に赤外線データの扱いはSANEのバックエンドごとに異なるため、現状ではアプリ側に機種固有の情報を持たせる必要がある。幅広いスキャナーで赤外線によるほこり除去を利用できるようにするには、SANE側で共通のインターフェースを整備することが課題となる。

ノートPCの内蔵カメラも改善、カーネルとlibcameraに計5件の問題を発見

スキャナードライバーの開発で成果を得たSchaller氏は、同じ手法をノートPC内蔵カメラの改善にも応用した。対象となったのは、Lenovoの「ThinkPad X1 Carbon Gen 14 Aura Edition」に搭載されたカメラだ。この機種はSony製IMX471イメージセンサーとIntel IPU7を組み合わせているが、Linuxでは撮影画像が暗く、画面の四隅が大きく暗くなる周辺減光や、黄色と緑が強く出る色かぶりが発生していたという。

ただし、内蔵MIPIカメラではUSBスキャナーと同じ方法で通信を記録できない。そこでSchaller氏は、Windowsのドライバー設定ファイルであるINF、レジストリー、ハードウェア構成を記述するACPIテーブルなどを調査し、Linux側の動作と比較する方法に切り替えた。さらに、IntelのWindows向けカメラドライバーパッケージに含まれる機種固有の調整データから、周辺減光の補正値や色変換行列を抽出した。メーカー製ドライバーの実行コードを解析・移植するのではなく、設定情報と実機の観測結果を手掛かりに修正を進める方法だ。

公開された調査結果によると、発見された問題はLinuxカーネルのセンサードライバーに3件、画像処理ライブラリ「libcamera」に2件の計5件だった。カーネル側では、撮像範囲を返す処理に不具合があり、libcameraが実際の読み出し範囲を正しく認識できていなかった。また、テストパターンを制御するレジスターを、本来の16ビットではなく8ビットとして定義していたため、テストパターンの切り替えも正常に機能していなかった。

さらに、アナログゲインの上限が低く設定されている問題も見つかった。IMX471センサーは最大16倍のアナログゲインに対応するが、Linuxドライバーでは約4.57倍までしか設定できない状態だった。アナログゲインはセンサーが受け取った信号を増幅する機能であり、上限が低すぎると暗い環境で十分な明るさを確保できない。今回の修正によって、本来センサーが備えている増幅能力を利用できるようになった。

一方、libcamera側には周辺減光の補正機能が存在せず、画像の四隅が中央よりも大幅に暗くなっていた。今回のカメラでは、周辺部の明るさが中央と比べて約2.7段分低下していたという。Schaller氏はWindows向けドライバーパッケージから取得した調整データを基に、ソフトウェアによる周辺減光補正を追加した。

もう一つの問題は、ホワイトバランスの計算方法にあった。この機種のLinux環境では、IPU7によるハードウェア画像処理を使用せず、センサーが出力した生の撮像データをlibcameraのソフトウェアISP（画像信号処理）で処理している。ところが、ホワイトバランスの統計値はセンサー本来のビット深度で計算している一方、黒レベルとして差し引く値は8ビット基準のままだった。

黒レベルとは、センサーに光が入っていない状態でも生じる出力の基準値であり、正しい色や明るさを計算する際には、この値を差し引く必要がある。例えば10ビットのデータに対して8ビット基準の値をそのまま使用すると、黒レベルの補正量が本来の4分の1になってしまう。その結果、各色の信号に余分な値が残り、ホワイトバランスの補正倍率が1に近づくことで、色かぶりを十分に補正できなくなる。

Schaller氏は、この不具合が今回のIMX471だけでなく、libcameraのソフトウェアISPを使用するRAW10やRAW12形式のセンサーにも影響すると説明している。そのため、修正が本体に取り込まれれば、他の機器でも同様の問題を改善できる可能性がある。ただし、現時点では他のカメラでも同じ効果が得られることを実機で確認したわけではない。

カメラの明るさは約2.9倍に改善、修正パッチの本体採用が次の課題

Schaller氏は修正の効果を確かめるため、同じ座席と照明条件でカメラの撮影結果を比較した。ノートPCの位置を動かさず、修正前の状態については標準のカーネルとlibcamera 0.7.1を再インストールして撮影し直している。また、どちらも400フレーム待機して自動露出とホワイトバランスが安定してから測定した。その結果、画像全体の明るさを示す測定値は修正前の31.1から90.9へ上昇し、約2.9倍の改善が確認された。

色の再現性も改善している。修正前は赤と緑の比率が0.890、青と緑の比率が0.672だったが、修正後はそれぞれ1.047、0.823となった。比較用のUSBカメラでは赤と緑の比率が1.052、青と緑の比率が0.989だったため、赤の再現性は基準に近づいた一方、青は依然として約17％不足していた。周辺減光も改善したものの、暗所での色再現には課題が残っている。

Schaller氏によると、今回の色変換行列は数学的な整合性と実際の撮影結果から検証されているが、カラーチャートを使った測色試験は行われていない。また、検証した照明条件は一つの部屋に限られ、さまざまな光源や明るさでの評価も今後の課題だ。画像処理についても、実際に検証されたのはGPUを使用する経路のみで、CPU側の処理経路は対象となっていない。

さらに、暗い環境でフレームレートを下げて露出時間を延ばす機能も未解決のままだ。現在のlibcameraの処理では、暗所でもフレームレートを維持しようとするため、露出時間が制限されてしまう。今回の修正によってアナログゲインの上限は改善したものの、それだけで暗所での撮影性能を最大限に引き出せるわけではない。Schaller氏も、画質は大幅に改善したが、完全な状態には達していないと説明している。

10月15日の報告時点では、カーネル向けの修正パッチはKate Hsuan氏へ提出済みで、libcamera向けの修正についてはWim Taymans氏が本体への提出に向けてレビューしている段階だった。いずれもLinuxの共通実装に正式採用されたと確認できる状況ではなく、今後のレビューや追加検証が必要となる。スキャナーについても、Schaller氏はSANE本体の機能が独自ドライバーに追いつけば、自身を含めて多くの利用者がSANE本体の実装を使うようになるだろうと述べている。

今回の取り組みが示しているのは、AIにドライバーのコードを書かせるだけではなく、正常に動く機器の挙動を観測し、開発中の実装と比較できる環境を用意することの重要性だ。Claude Codeは大量の通信記録の解析や仮説の立案、確認用プログラムの作成を効率化したが、最終的に動作を確かめたのは実機を持つ開発者だった。Schaller氏も、ハードウェアの動作を判断するには実機での確認が不可欠だと強調している。

公開されたhw-harnessが他の機器でも同様の効果を発揮し、得られた修正がLinuxカーネルやSANE、libcameraなどの共通実装に取り込まれれば、これまで対応が難しかったハードウェアのドライバー開発を進める手段になり得る。ただし、個人の開発環境で動作したことと、異なる個体や環境でも安定して利用できることは別だ。今後は再現性の検証と修正の本体採用が、今回の成果を広くLinuxユーザーの利益につなげられるかを左右する。