この記事は、Linuxカーネルへのパッチ投稿に興味がある方に向けて、私が経験したごく短いコードコントリビュートの記録を共有するものです。数字を並べたのは誇示するためではなく、開発プロセスの裏側にあるリアルを感じてほしいからです。この記事ではあえて技術的な詳細には触れません。細部自体はもはや最も議論すべき対象ではなく、AIという極めて優れた調査・学習ツールが存在するからです。私が語りたいのは、この短い投稿体験の背後にある「現実のフローと考察」です。
7月27日から現在までの約1か月間、私はAIを活用して18本のパッチを投稿しました。7月27日から8月15日にかけて投稿したThunderbolt関連の9本のパッチのうち、4本が stable に入り、残りの5本は next/dev ブランチにマージされました。その後、偶然にも resource: shared I/O の問題を発見し、そのバグは4時間以内にメンテナ側で確認されました。Thunderboltのバグ修正プロセスを振り返る中で、「古代のLinuxコードには、共通したバグのパターン（状態遷移の順序不整合）が存在するのではないか」という着想を得ました。そこでそのパターンをAIに入力したところ、大量の潜在的バグが浮き彫りになり、その中から4本を厳選して投稿しました。その過程でLinux界の重鎮であるGreg氏やArnd氏にもメールを送りましたが、驚くほど迅速な返信をいただきました。
もちろん、すべてが順風満帆だったわけではありません。
例えば、btrfs: zstd: fix lost wakeup when waiting for a workspace の件では手痛い挫折も味わいました。結論が出てからまとめた方が綺麗な記事になるかもしれませんが、私はもう待ちたくありませんでした。パッチがマージされるかどうかに執着して権威を気取るつもりはありません。ただ、この初期衝動が冷めないうちに、リアルな探索のプロセスを記録に残しておきたかったのです。
1. リアルな実機環境と、折れない集中力
私は天才ではありません。今年になって自作PCを組み、ようやく本格的かつ高頻度でLinuxを触り始めたばかりです。しかし使い始めてすぐにAIが私を追い越しました。AIの作業は私より遥かに速く、正確です。そんな私がこれらのパッチを見つけ出せた最大の理由は、「リアルな使用環境」にあったと考えています。LLaMAのために高速なネットワーク環境を構築する必要があり、Thunderboltを試したことで、初めてThunderboltのLinuxドライバに触れる機会を得ました。この泥臭いローカルの実機環境では、クラウド上よりも遥かに面倒な事態に直面します。電源コードを抜き差しし、再起動を繰り返す日々（笑）。不具合が起きるたびに、強烈なストレスと違和感を覚えました。
そして、「諦めないこと」も極めて重要です。情報が断片化し、娯楽が溢れかえる現代において、一つの物事に深く集中し続けることは非常に困難です。集中力は極めて貴重なリソースであり、挫折に直面すると簡単に途切れて摩耗してしまいます。とりわけソフトウェアとハードウェアの境界線では、0と1のデジタルな制御から外れ、世界はソフトウェアのように白黒はっきりしなくなります。それでも諦めず掘り下げていけば、必ず成果という果実が待っています。
2. AIの賢い活用と、責任ある使い方
私のパッチはすべてAIとともに作成したものです。問題を見つけたら、AIに「ここを掘れ」と指示を出します。出力結果を見て、納得がいけば次へ進む。納得がいかなければアプローチを変えて繰り返す。確信が持てなければ別のAIに聞いて教えを乞い、得られた知見をもとに元の作業AIを問い詰める。
ほら、何も難しくありません。私たちは単なる「情報の運び屋」です。気力とトークンを惜しまなければ、AIは指示通りにシラミ潰しの実験を繰り返してくれます。ノブのついたブラックボックスに無数のパラメータを注ぎ込むうちに、ブラックボックスの蓋は少しずつ開いていく。それだけのことです。
しかし同時に、「責任を持ってAIを使う」必要があります。現在LinuxコミュニティでAIに対する議論が起きているのは、単に保守的なメンテナがいるからではありません。「一見まともそうに見えるだけの未検証コード」が無数に投稿され、初心者がその妥当性を判断できていないことこそが根本原因です。
もちろん、誰も無責任になりたくてやっているわけではないでしょう。誰だって stable に入るような堅牢なパッチを作りたいはずです。
だからこそ、責任を持ってAIを使いこなす必要があります。AIに本物の検証環境やリアルなシナリオを構築させ、専門的なツールでコードを解析させるのです。QEMU/TCG、herd7、LKMM（Linux Kernel Memory Model）などを導入し、AIに精密な再現環境を組ませて仮説を検証し、何度も食らいついて結論を完全に裏付ける必要があります。
確信が持てないなら、別のAIに壁打ちして学習してください。自分自身の理解と結論を極限まで一致させておく。そうすれば、仮に間違っていたとしても問題ありません。あなたの時間もレビュアーと同じくらい貴重です。レビュアーの何倍もの時間をかけて徹底的に検証を重ねてパッチを投げたのなら、たとえ誤りがあっても恥じることは何もありません。
ただ、これは私が少し懸念している点でもあります。バグ探しが単なる「トークンを燃やす札束ゲーム」になりつつあるのではないか、世界の階層化と断絶がさらに広がっているのではないか、と薄々感じています。
3. サブシステムの「人」に恵まれるということ
ThunderboltサブシステムのMika氏は、私の最初のパッチのレビュアーでした。返信の速さは想像を絶するものでした。AIを使って出力した長文のメッセージを見た彼は、「なぜrevertを試さないのか？」と問いかけてきました。率直に言って、非常に嬉しかったです。Linuxはコンピュータ史における至宝であり、そこに名を連ねるマスターから返信とフィードバックをもらえたのですから、胸が熱くならないはずがありません。当然、厳しい指摘もありました。「AIが生成した長大なメッセージをそのまま横流しするのはダメだ。内容を完全に理解していることを示すために、要点を自分自身で要約しなさい」と。私はその日の夜にプロンプトを改良しました。返信は極めて簡潔にし、思考の過程ではなくアプローチとコアロジックのみを記述するように改めたのです。
Bradley氏の素早いレスポンスとユーモアにも救われました。「トップエンジニアも気取ったりしないんだな」と感じさせてくれました。彼が夜通し励ましてくれたおかげで頭の中に火花が散り、「状態遷移の順序に起因する共通のバグパターン」という着想にたどり着くことができました。
タイミング問題に関連して何年も前の古いドライバのバグを見つけた際、私は思い切ってトップメンテナに「これをどう処理すべきか」とメールを送ってみました。Greg氏はメールを確認したものの私が言及した関数を見つけられず、「その関数は見当たらないが、Arndに見てもらおう」とArnd氏を召喚してくれました。
Arnd氏はすぐに返信をくれ、まずは関数の件について解説し、その後の計画について丁寧に説明してくれました。
後から振り返ると、もし自分が逆の立場なら、見知らぬアカウントから「存在しない関数名が書かれたメール」が届いたら十中八九スルーしていたはずです。Greg氏とArnd氏の迅速で丁寧な対応には心から感謝しています。
btrfsサブシステムでは手痛い挫折を味わいましたが、その頃には他のメンテナたちのおかげで自分なりの方法論と自信が確立されていたため、大きく動揺することはありませんでした。むしろ「次はやってやるぞ」と闘志が湧いたくらいです。
なぜこの経緯を話すかというと、「最初に出会う人」が極めて重要だからです。多くのLinuxコントリビューターは、生涯で1本のパッチしか出さないかもしれません。もし私が初めてパッチを投稿し、不安と緊張の中で結果を待っていた時に、トップ層から高圧的なプレッシャーや全否定を受けていたら、二度と投稿しなかったはずです。コミュニティの新人オンボーディングにおいて重要なのは、ドキュメントやコーディング規約だけでなく、「レビュアーの振る舞い」そのものです。
ですから、パッチを投げる前にメーリングリストのログを検索し、そのサブシステムの空気感やメンテナの性格を調べておくことをお勧めします。例えば「新人を全く信用しないタイプ」なら、最初から避けた方が賢明です。「LLMの利用に対して強い忌避感を持っているタイプ」なら、最初のレビューを投げる前に、相手の厳しい追及に耐えうる知識・自尊心・自信が自分にあるかを確認してください。
最後に
ここ最近、ふと考えることがあります。AIの能力が指数関数的に向上した今日、Linuxのようなかつては敷居の極めて高かった世界でさえ、コードを書くハードルは劇的に下がりました。自分自身がまるで「工場のライン工」になったかのように思えることすらあります。私がやっていることといえば、方向性を定め、アプローチを指定し、メールを送信するだけ。それは書類にハンコを押す作業と大差ありません。ほんの少しの判断力と、ほんの少しの機械的なエネルギー。もちろん、ハンコを押した以上、その責任は自分が負わなければなりませんが。
もしAIがコードを飲み込み、テストを飲み込み、レビューを飲み込み、分析すらも貪り尽くすようになったら、ソフトウェアエンジニアには一体何が残るのでしょうか？
AIは、かつて決して手の届かなかった王座を、誰もが触れられる場所へと引きずり下ろしました。
皇帝（インペリウム）への信仰が潰えたとき、我々は虚無（ヴォイド）へと漂流するのでしょうか？ それとも Waaagh!（雄叫び）をあげて暴れ回るべきなのでしょうか？
おそらく私たち全員、いずれは巨大な生産ラインの歯車になっていくのでしょう。私のような初心者に限らず、btrfsのトップメンテナでさえも。
……では、そのサプライチェーンの「究極の最上流」に君臨しているのは誰なのでしょうか？
味の素（ABF）ですか？
そうそう、AIを使ったからといって、私がLinuxのエキスパートになれたわけではありません。
AIが変えたのは、私が「Linux開発に参加するためのコスト構造」そのものです。
コードはもはやボトルネックではありません。重要度を増しているのは「判断力」です。
さあ、手を動かして練習を始めましょう。