25年前のカーネルドライバをClaude Codeでモダナイズする
(dmitrybrant.com)- ftapeドライバは、1990年代のバックアップテープ（QIC-80）からデータを復旧できる唯一のLinuxオープンソースカーネルドライバである
- しかしこのドライバは2000年以降保守されておらず、古いLinux環境でしか利用できなかった
- Claude Codeを活用して古いソースコードを最新のLinuxカーネルに合わせてリファクタリングし、スタンドアロンのカーネルモジュールへの変換に成功した
- その過程でClaudeは自動的に旧式の関数や構造体を最新APIへ置き換え、ユーザーは出力結果を手動で分析して一部の設定ミスを修正した
- AIコーディングエージェントの活用経験を通じて、プログラマの能力増幅や新技術・フレームワークへの迅速なオンボーディングについての洞察を得た
背景: 古いバックアップテープの復旧とftapeドライバ
- QIC-80などのテープカートリッジからデータを復旧することが著者の趣味の一つである
- これらのテープの大半では、フロッピーコントローラに接続された特殊なテープドライブが必要になる
- こうしたドライブは主に1990年代に小規模事業者や個人がバックアップ用途で使用していた
- フロッピーコントローラを使う方式は、別途SCSIアダプタなしで安価に実現できた一方、**速度制限（500Kbps）**や非標準プロトコルなど複数の欠点があった
- このテープ装置と通信するには、Linuxではftapeカーネルドライバが必須である
- 純粋な生バイナリデータを読み取れるのがftapeだけであるため、復旧には欠かせない
- しかしftapeドライバは2000年ごろ以降保守されておらず、最新のLinuxカーネルでは利用できなかった
- そのためデータを復旧するたびに、古いLinux（CentOS 3.5など）を直接起動しなければならなかった
Claude Codeでカーネルドライバのモダナイズを開始
- Claude Codeにリポジトリの説明とともに「最新カーネルでビルドできるようドライバをモダナイズしてほしい」と依頼した
- Claudeは現在のカーネルAPIと構造に合わせて、旧式の関数や構造体を見つけて置き換えた
- 複数回のフィードバックと手動補正を経て、エラーなしでコンパイルできるドライバコードが完成した
- 初期コードはカーネル全体のソースツリー内でしかビルドできなかったが、追加の依頼によりスタンドアロンの外部モジュール用ビルドシステムも自動生成した
- これにより
.koファイルとしてカーネルモジュールを個別に作成できるようになり、実機接続テストに進めた
- これにより
問題解決の過程
- カーネルモジュール自体は正常にロードされたが、ドライブ認識・通信の問題が発生した
sudo権限が必要な作業のためClaudeが直接繰り返し実行することはできず、dmesgログを手動で渡しながら問題を追跡した
- Claudeはログと過去の成功事例の比較から、デフォルトI/Oポートアドレスの未設定とパラメータ初期化に関するバグを発見した
- デフォルト値が-1から0xffffへ変換されて検出に失敗していたため、正しいアドレスに再設定して解決した
- 最終的にモジュールは正常にロードされ、テスト用テープのデータダンプに成功した
AIコーディングエージェントとの協業経験が示すこと
- Claude Codeとのやり取りは、**「ジュニア開発者との協業」**のように実際のエンジニアと働いている感覚に近かった
- ユーザー自身がアーキテクチャの決定、問題発見、方向性の提示を主体的に担う必要があった
- ドメインに特化したキーワードと具体的な依頼をするほど効果的である
- AIエージェントは適した種類の作業が与えられると生産性が急激に高まるため、限界と強みを理解する感覚が必要だ
- 自分の能力をAIが何倍にも増幅してくれた。手作業なら数週間かかったはずの作業を、日常的な対話とフィードバックだけで数日で完了できた
- この過程で現代のカーネル開発プラクティス、x86アーキテクチャ、新しいコマンドラインツールなど実用的なスキルも学べた
- 新しいフレームワーク（Rust、Flutterなど）の初期オンボーディング・適応プロセスを大幅に速めてくれる点も強調している
結論: ftape、再び蘇る
- 25年ぶりにftapeが再び最新のLinuxでビルド・利用可能になった
- 著者は追加の機能改善とテストを進めており、フロッピーベースのドライブに加えてパラレルポートベースの装置も対応を確認している
- 物理デバイスは昔とほとんど変わらないが、OSはCentOS 3.5ではなくXubuntu 24.04へと変化した
参考
- ftapeプロジェクトのソースコードはGitHubで公開されている
- 著者の収集機材一覧などは個人ブログで確認できる
1件のコメント
Hacker Newsのコメント
私は自分でモジュールをロードし、
dmesgの出力を繰り返し Claude に手動で貼り付けていたClaude を主に使う理由の一つは、長時間実行されるプロセスを開始し、その出力を読んでデバッグできるからだ
ここでは手動の手順を飛ばすためのさまざまなハックもあり得た。たとえば、
dmesgをローカルの UDP ポートにパイプし、Claude にリスナーを起動させる方法などだ良い事例だと思う
こうしたツールを使うとき、2つの主要な効果が得られると考えている
第一に、私がすでに慣れているフレームワークでは、Claude が反復的な部分を素早くパターンマッチしてくれるので、生産性が大きく上がる
第二に、新しいフレームワークを学ぶときも、はるかに速くオンボーディングできる。この点は、さまざまなスタックを使う大企業で特に役立つ
AI の能力を正しく把握するには、急速に変化する技術やフレームワークにかなりの時間を投資する必要がある
Claude Code や Claude 4.0 を 100 時間以上使っていなければ、その可能性を十分に理解できていないかもしれない
「コーダーではない人が雰囲気でコーディングして問題にはまる」というシナリオは X（旧 Twitter）ではよく見かけるが、熟練した開発者が継続的に時間をかければ、まったく違う体験になる
そこが核心だ
私は Claude Code を一日も欠かさず、既存コードベースの変更におけるメインツールとして使っている
試行錯誤の末に自分なりのプロセスを作り上げ、そのおかげで生産性と大規模な実験に挑む意欲が大きく高まった
特に、自分で先にデータ構造、スキーマ、内部 API を設計しておくと、Claude Code が内部ツールの UI をほぼ一発でうまく作ってくれるのが本当に気に入っている
単純な反復作業やフレームワークの複雑さから離れて抽象的な思考ができるようになり、16 年のキャリアの大きな転機になった
その通り
筆者は Claude に Linux 2.4 ドライバを 6.8 に移植してくれと頼んだようなものだ
オンラインに十分な関連資料があるため、作業の大半は Claude がこなし、本当に複雑な核心部分でだけ筆者の専門性が必要だった
「自分のスキルを爆発的に増幅する道具として AI を使う」という表現が本当にしっくりくる
ここで自分の能力が 0 なら、AI を掛けても 0 に近いか、むしろマイナスの生産性になることすらある
私たちのチームにも、LLM を通じて新しい領域に大胆に挑む人はいるが、Claude 4 thinking agent を全員に使わせても、とんでもないコードが大量に出てくることがある
コーディングキャリアの大半でパターンマッチに慣れてきた人なら、LLM エージェントがその上でもう一段パターンマッチをする形になるが、そうした経験のないチームメンバーにとっては、むしろ頭痛の種だ
LLM エージェントは、人間にできるパターンマッチをはるかに速くこなすが、汎用的には人間より特別優れているようには思えない
新しいフレームワークの探索だけでなく、新しい言語にも有用だ
私たちのチームは Ruby を使っているが、Ruby は読みやすいので、構文をわざわざ学ばなくても LLM にコードを書かせ、自分は意思決定だけを行えばよい
Ruby を知らなくても、チームが許容する水準のコードをすぐに書けるようになり、不慣れな環境でもすぐ生産的に働ける
（参考: チームメンバーが Pull Request をレビューする）
「自分のスキルを爆発的に増幅する道具」という言葉は、今週小さなプロジェクトを 10 回繰り返して作る中で本当に実感した
AI が雑然と作ったものに対して、私がガイドを与え、マークアップやスタイル、JS などをきれいに統合（consolidation）していく作業で真価を発揮する
スタートアップのようにコーディング規約が弱い環境では、パターンマッチの要求を適用しにくいが、強力で成熟したコードベースではまったく違う効果が出るだろうと想像している
できるだけ具体的に、ドメイン特化のキーワードを使ってプロンプトを書くべきだと思う
特定の言語やフレームワークに対する技術的理解が不足していると、プロンプトに曖昧さが入り込み、その部分を LLM が勝手に補ってしまうため、意図と違う結果になりやすい
こうした曖昧さこそがバグの原因になる
これが「爆発的増幅」の裏側だ
こういう記事を読むと、LLM 導入前は需要に対して実際に処理される仕事量があまりにも少なかったのだと考えさせられる
私はいまだに、ボトルネックは「実行」ではなく「市場性のあるアイデア」だと思っている
人々が実際にお金を払いたいと思う仕事の数は多くない
問題は常に仕事が足りないことではなく、その仕事をこなす前提技術や経験を持つ人が足りないことだ
カーネル開発の経験がなければ、どれほど上手にプロンプトを書いても、筆者のような成果を出すのは難しい
理論上は、すべての古いドライバを最新カーネル向けに「モダナイズ」することも LLM の力で可能に思えるが、現実には必ず人間の監督、しかも熟練者が必要であり、実際にはこうした専門家の数は維持すべきドライバの数に比べてあまりにも少ない
Alan Kay と Joe Armstrong の 良い議論とインタビュー があり、そこではコードの大半が仕様なしにターゲットを変えてコンパイルするような形で開発されていないことから生じる問題に触れている
もし正式な仕様（spec）がコード以外に存在するなら、新しいカーネルターゲットへドライバを移す作業は「仕様を新しくコンパイルする」形で容易になるだろう
しかし今は仕様ではなく古いコードをベースにしているため、旧コードを現代的なコードへ移す過程で、LLM は似たコードをパターンマッチしているだけで、本当の意味を理解して保証しているわけではない。だからこそ、人間のスキルが不可欠なのだ
AI によってカーネルハックへの参入障壁が下がるだろうという予感は以前からあった
その実感を毎回強めている
近いうちに embedded/ARM ハードウェア対応が広がり、新しい軽量スマートデバイス向け OS も登場するかもしれない
ただし大半の人は AI に「家を丸ごと建ててくれ」と求めるが、実際には「金づちを振るうのを手伝ってくれる役割」として使うほうが効果的だ
AI の役割と限界をきちんと理解し、適切に使っている開発者の良い例だと思う
特に、懐疑的な視点のおかげでドライバを別モジュールにした点が印象的だった
ほかの人が触れていない「重大な手がかり」を指摘したい
筆者は「自分にはカーネルモジュールの経験が少しあり、C 言語にも習熟しているので、Claude の成果を過大評価すべきではない」と明言している
つまり、本当に 3 回質問しただけでカーネルモジュールが完成したわけではなく、何度も対話を重ね、コードも何度も手で修正している
基本的なカーネルモジュールの内部構造を理解していなければ、モダナイズは決して不可能だったと述べている。この点は、どんなコード生成ツールを使う場合でも必ず念頭に置くべき文脈だ
また、Claude Code と協業する感覚が「ジュニアエンジニアと一緒に働く経験」に似ているとも書かれているが、言われたことは何でもやり、ミスを指摘するとすぐ謝ったり褒めたりする様子は、本物のエンジニアというよりおべっかを使うスタイルに近いとも評価している
最後に、筆者が「本気なら一人でもこの作業はできたが、25 年前のカーネル開発のやり方をもう一度学び直す必要があっただろう」と述べている点から、
結局のところ「レガシーなソリューションを正確に理解し、何が必要かを把握すること」こそがモダナイズ作業の本質だと改めて示している
決定的には、学ばずに先へ進めることが利点として挙げられている点も興味深い
agent が自分の知らないプロジェクトを説明してくれるのはとても良いと感じる
最近 Firefox のソースをクローンして qwen-code を使い、Firefox の AI 機能やその実装方法について質問したが、本当に素晴らしく学べた
学び方がずっと面白くなった
これは人々により大きな力を与える変化だと思う
筆者は長年情熱を持ってサイドプロジェクトに取り組んできたし、道具のアップグレードは本当に良いことだ
ただ、分野がニッチすぎるとコミュニティからの支援が不足しがちだが、そこを LLM が助けてくれれば、カスタムな問題を解決できる
参入障壁はますます下がっており、技術的背景知識が少ない人でも、より単純な特殊状況の問題なら自力で解決できる時代が来るだろう
より多くの人が挑戦できるようにする前向きな変化だ
アップグレード後に速度がどう変わったのか気になる