世界を動かす技術を、日本語で。

25年前のカーネルドライバを近代化するためのClaude Codeの活用

概要

  • QIC-80テープ などの古いテープ媒体からデータ復旧を趣味とする体験談
  • ftapeドライバ を最新Linuxカーネル向けに移植した過程の詳細
  • Claude Code のAI支援によるカーネルモジュール移植の実例
  • AIエージェント との効果的なコラボレーション方法の考察
  • 現代的なツール活用 による学習・開発効率化の提案

QIC-80テープと復旧作業の魅力

  • QIC-80テープ :1990年代に個人や小規模ビジネス、BBS運営者に広く使われたバックアップ媒体
  • テープメディアの魅力 :物理的な手触りや扱う楽しさ、設計上の欠点も含めた愛着
  • データ復旧 :慎重な検査と再調整で、長年経過したテープからもデータ復旧が可能

古い環境でのftapeドライバ利用

  • ftapeドライバ :Linuxカーネルのレガシーテープドライブ用ドライバ
  • CentOS 3.5 など、古いLinux環境でのみ利用可能
  • テープドライブ接続 :マザーボードのフロッピーコントローラ(FDC)経由で接続
  • SCSIアダプタ不要 :コスト削減のためFDCを活用、フロッピードライブと同一ケーブル利用可能
  • 制約 :データレートはFDCの速度(約500kbps)に依存、通信プロトコルも非標準・サポート困難

ftapeドライバの現代化プロジェクト

  • 課題 :ftapeはカーネル2.4までしかサポートされず、最新カーネルではビルド不可
  • 目標 :最新カーネルでビルド・利用可能な スタンドアロン・カーネルモジュール

Claude Codeとのコラボレーション

  • AIへの依頼 :古いドライバを最新カーネル向けにモダナイズ
  • AIの役割 :非推奨APIの置換、構造体や関数の最新仕様対応
  • 人間の役割 :ビルド結果やdmesgログの確認、ハードウェア実機テスト、最終的な微調整
  • ビルド方法 :カーネルツリー外でのモジュール単体ビルド用システムをAIが自動生成

トラブルシュートと最終動作

  • 初期問題 :モジュールはロードできるがテープドライブと通信不能
  • 原因特定 :I/Oポートベースアドレス未設定により、デバイス検出失敗
  • 修正後 :モジュールが正常にロード・デバイス検出・テープ内容のダンプが可能に

AIエージェント時代の開発スタイル

  • AIとの協働 :AIは「熱心なジュニアエンジニア」のような存在
  • 人間の責任 :ガードレールの設置、設計判断、アーキテクチャ監督、問題の早期発見
  • 効果的なプロンプト :タスクの専門用語・詳細要件を明確に伝えることが重要
  • タスク適性の見極め :AIが得意な領域を見極め、適切な依頼で最大限活用
  • スキル増幅 :AIを「自分のスキルの力増幅装置」として活用
    • 旧技術の学習コストを大幅削減
    • 新しいフレームワークや開発環境への迅速なオンボーディング

現代Linuxでのftape復活と今後

  • ftapeドライバ :25年ぶりに最新Linuxカーネルで動作可能に
  • 新環境 :CentOS 3.5からXubuntu 24.04への移行
  • 今後の展望 :機能追加や微調整を継続中
  • AI活用の実感 :学習・開発ペースの劇的加速、新たな分野への挑戦意欲向上

AIエージェントとの開発で得た教訓

  • AIは魔法ではない :人間の知識と判断力が不可欠
  • 協働による学び :AIの説明で現代的なカーネル開発やx86アーキテクチャの新知識を獲得
  • 実践的学習 :Flutterアプリ開発など、未経験分野への挑戦も加速
  • 高次思考へのシフト :低レイヤの苦労をAIに任せ、よりアーキテクチャ的な思考に集中可能

ftapeは今も生きている!

  • 25年ぶりに蘇った ftapeドライバ
  • 物理的セットアップは昔のまま、OSは現代的に進化
  • 今後もさらなる改良とテープメディアの保存・活用を目指す

Hackerたちの意見

いいケーススタディだね。この2つは勝ちパターンとして良いカテゴリだと思う。

「これらのツールを自分のスキルの大きな力の倍増器として使う。」 クロードのおかげで、よく知っているフレームワークでの生産性が上がったよ。ボイラープレート部分をすぐにスキャンしてパターンマッチできるからね。 「これらのツールを新しいフレームワークへの迅速なオンボーディングに使う。」 ここでも生産性が上がって、新しい分野を探るための助けになってる。大手テック企業では、たくさんの技術スタックやフレームワークが使われているから、特にありがたい。AIの能力を測るのが面白い分岐点になってる気がする。急速に変化する技術やフレームワークの洪水に常に目を光らせておく必要があるんだよね。クロードコードやクロード4.0に100時間も費やしてないなら、その能力を正確に把握できてないと思う。「ノンコーダーがコードに振り回されてトラブルに巻き込まれる」ってのがXでの中央値のシナリオかもしれないけど、時間をかけた専門的なコーダーにはあまり関係ないと思う。

これはいいポイントだね。僕はコードベースに変更を加えるためにクロードコードをメインで使ってるし、何ヶ月も毎日使ってる。試行錯誤を通じて確立したしっかりしたシステムがあって、全体的に生産性が大幅に向上したし、大きな実験にも挑戦する意欲が湧いてきた。特に好きなのは、強固なデータ構造やスキーマ、内部APIを開発して、その後CCに内部ツールの素晴らしいUIを一発で作らせること。地味な作業やフレームワークの細かい部分を超えて高いレベルで考えられるのは、16年のキャリアにとってゲームチェンジャーだよ。

「これらのツールを自分のスキルの大きな力の倍増器として使う。」 今週学んだことなんだけど、小さなプロジェクトを10回明確に繰り返す形で作るのにAIの入力を使ったら、すごく実感したよ。でも、その後の魔法は「統合」タスクを作ることで、マークアップやスタイル、JSなどを一つにまとめるのを導くことなんだ。日常の仕事では、スタートアップで強いコーディングの規約がないから、パターンマッチングのリクエストを適用するのが難しいこともあったけど、厳格で成熟したコードベースではもっと効果的だと思う。

そうだね。著者は基本的に、ClaudeにLinux 2.4からLinux 6.8にドライバーを移植するように頼んだんだ。こういう作業を説明するトレーニング資料やウェブ検索可能な資料は、十分にあるはずだよ。著者は、Claudeがトレーニングコーパスで良い類似物を見つけられなかった部分、つまり実際に移植するのが難しい部分で自分の専門知識を提供したんだ。「自分のスキルを大きく引き上げるためにこれらのツールを使おう」というのは、いい表現だね。もし自分のスキルがほぼゼロなら、大きなファクターで掛け算しても、結果はほぼゼロになるかもね。(そして、生産性がマイナスになることも。)

チームには新しい領域に踏み込むことに自信を持っているメンバーがいるけど、LLMを使っても方向性を間違えたコードをたくさん作っちゃうんだ。みんなにClaude 4の思考エージェントを使わせても、そうなっちゃう。コーディングキャリアの大半をパターンマッチングで過ごしてきた人が、さらにその上にLLMエージェントのパターンマッチを重ねると、チームでそういうことをやってない人には頭痛の種になると思う。LLMエージェントは、人間よりもパターンマッチングが圧倒的に早いけど、全体的にはあまり得意じゃないと思う。

仕事を通じてClaude Codeを使う機会があるの?それとも、自分の個人プロジェクトでやってるの?

新しいフレームワークへの迅速なオンボーディングにこれらのツールを使おう。また新しい言語にも - 私たちのチームはRubyを使っていて、Rubyは読みやすいから、構文を学ぶのを飛ばしてLLMにコードを書かせることができる。すべての決定を自分で下し、指導する必要があるけど、Rubyを学ばなくても許容レベルのコードが書けるんだ [0]。知らない環境で即座に生産的になれるのは素晴らしいよ。[0] 許容レベルはチームの他のメンバーによって定義されていて、彼らが私のPRをチェックしてる。

AIがカーネルハッキングの参入障壁を下げるだろうって思ってたけど、実際にそうなって嬉しい。近いうちに、組み込み/ARMハードウェアのサポートがもっと広がるかも。スマートデバイス用の全く新しいシンプルなOSも出てくるかもしれないね。

こういう記事を読むと、仕事の需要がLLM以前の状況では全然満たされてなかったことを考えさせられる。

仕事が足りないわけじゃなくて、それをやるための専門知識を持った人が足りないんだよね。カーネル開発の経験がないなら、どれだけ促しても著者が達成したような結果は出せないよ。理論的には、古いドライバーを全部「モダナイズ」して新しいカーネルのバージョンに持っていくことは可能なんだけど、問題は、どのLLMも人間の監視なしではその作業ができないこと。実際にLLMを監視できる人は、メンテナンスされていないドライバーの数に比べてすごく少ないんだ。アラン・ケイとジョー・アームストロングの間での良いディスカッション/インタビューがあって、ほとんどのコードは後ろ向きに開発されているって話をしてる。なぜなら、どのコードにも異なるターゲットに「コンパイル」できる正式な仕様がないから。もし古いドライバーコード以外に仕様があったら、ドライバーをポーティングするのは新しいカーネルターゲット用にその仕様を再コンパイルするだけの話になる。そんな仕様がないと、古いコードの不変条件を新しいコードに維持するために人間の専門知識を代わりに使わないといけない。LLMは、似たようなコードを持つ他のドライバーとのパターンマッチング以外は何も理解してないからね。

本当にワクワクする未来が待ってるね。深い知識を再学習するために専任の人間が必要ない失われた技術がたくさんある。ただ、これらのLLMの呼び出しにはエネルギーが必要で、次の技術サイクルを回すためには信頼できる電力生成が必要だってことを忘れないでね。無駄な暗号通貨のサイクル消費がLLMのサイクル消費に回ってくれればいいけど :)

本当にワクワクする未来が待ってるね。失われた技術がたくさんあって、それを再学習するのに人間が必要ないなんて。次に海外旅行する時、エアトラフィックコントロールのソフトウェアがちゃんと動いてるか、専門家に確認してもらわないとね。「絶対正しい!」って言われたからって、チャットボットに頼りきりの新世代は要らないよ。 > 役に立たないクリプトで無駄に消費したサイクルが、LLMのサイクルに転用されるといいな :) ストライプが自分たちのブロックチェーンを作るくらい役に立つんだから、他のものよりもエネルギー効率もいいしね。でも、LLMの詐欺(あるいはAGIの詐欺)は、クリプトよりもさらにコストがかかるし、その「役に立つ」目的は、現実的な経済的代替手段もなく、2030年までに10%以上の世界的失業を達成することなんだ。クリプトの百倍もひどい結果になるよ。

Hacker Newsで議論の続きを見る