9月20日、MakeUseOfが「The Linux kernel has 5 AI coding rules every vibe coder should use」と題した記事を公開した。Linuxカーネルのコントリビューションガイドラインから抽出した5つの原則を、AIコーディング（バイブコーディング）に応用する方法を実例とともに紹介している。
記事が最初に突きつける事実は鋭い。著者がAI（OpenAI Codex）で構築したモールス信号デコーダーアプリ「CW Inspector」は、一切クラッシュしなかった。しかし、自信満々に音声を誤デコードし続けていた。エラーがないことと、正しく動いていることは別物だ。この問題に気づけたのは、LinuxカーネルのAI生成コンテンツ向けガイドラインから借用した5つのルールを適用したからだった。
「バイブコーディング」とは、自然言語でAIに指示を出しながらアプリを作り上げる開発スタイルのことで、近年急速に広まっている。コードを書かずともアイデアが動くアプリになる手軽さが魅力だが、生成されたコードを誰が理解し、誰が責任を持つのかという問題は置き去りにされがちだ。バイブコーディングの光と影については、Andrej Karpathyが提唱した原概念や、GitHubが公開しているAIコーディングのベストプラクティスも参考になる。
以下に、カーネルガイドラインが示す5原則を紹介する。
最重要：ルール5「生成されたコードに自らを証明させる」
5つ目のルールを冒頭近くで取り上げるのには理由がある。これが最もクリティカルであり、他の4つのルールが機能する前提条件でもあるからだ。
CW Inspectorが誤デコードしていたのは、ダッシュの多い送信に対するパルス分離ロジックの問題だった。_estimate_dot関数のNumPy処理が、短いドットと長いダッシュのパルスを正しく分離できていなかった。通常の音声ではうまく動いていたため、テストを増やさなければ気づかないまま終わっていた。
カーネルのガイドラインは、生成コードに対して人間が検証可能なテストを要求する。著者は追加の音声録音を自分で作成し、独立した検証環境で実行した。生成されたテスト自体も検証の対象に含めた。「エラーが出ないから正しい」という思い込みが最大のリスクであることを、この実験は端的に示している。
ルール1：使用したAIツールを明記する
最初のルールは最もシンプルだ。プロジェクトの主要部分を生成したツールを記録しておく。カーネルのガイドラインは、スペルチェックや補完といった軽微な支援まで記録することは求めていない。対象は「関数・ソースファイル・バグ修正・翻訳・変更履歴」など、実質的な生成物に限られる。
著者はCW Inspectorの構築記録として以下を残した。
- OpenAI Codexが仕様書をもとに初期実装を生成
- テスト環境はLinux Mint 22.3 / Python 3.12.3
- FlaskでUI、NumPy・SciPyで音声処理、Plotlyでグラフ描画
- テストにPytest・Mypy・Banditを使用
「OpenAI Codexで作った」と明記することは成果を損なわない。自分で書いたコードと比べて、どこをより入念に検証すべきかが明確になるだけだ。
ルール2：AIへの入力（プロンプトの前提）を保存する
生成結果だけを残しても意味は薄い。AIが何を受け取って生成したかが残っていなければ、後から再現も検証もできない。
著者はCodexに何かを書かせる前に仕様ファイル（記事内ではPRODECT_SPEC.mdと表記されているが、PROJECT_SPEC.mdの誤記の可能性がある。本記事では元記事の表記をそのまま引用する）を作成・コミットした。そこには「ローカルFlaskインターフェースでモノラルPCM WAVを受け付ける」「クラウドサービスは使わない」「アップロードされたファイル名からシェルコマンドを組み立てない」といった制約が明記されていた。
参照用音声として用意したのは、22,050 Hz・16bit・モノラルのWAVファイルで、700 Hzのトーンで約15 WPMのモールス信号が収録されていた。ただし、このWAVファイル自体はCodexに渡していない。モデルが「後でデコードするサンプルに最適化する」ことを防ぐためだ。この独立した受け入れテストの設計が、後の誤デコード発見につながった。
ルール3：プロンプトの履歴を残す
生成されたソースファイルは、AIが「何を最適化するよう指示されたか」を語らない。著者はAI_ASSISTANCE.mdにセッションの要約を記録した。
- 仕様書を全部読んでからコードを書くこと
- ローカルのWAVアナライザーだけを作ること
- 信号処理とFlaskを分離すること
- 外部APIやファイル名ベースのシェル実行を避けること
後にアプリがダッシュの多い送信を誤読したとき、プロンプトの記録はバグを直接解決しなかった。しかし本来の意図を明確に示した。_estimate_dot関数のNumPy処理が「短いドットと長いダッシュのパルスを分離する」という目的のためのものだと、プロンプト記録があったから対応できた。
ルール4：AIが変更した箇所を具体的に記録する
「AIの助けを借りた」だけでは情報として不十分だ。数行の提案なのか、アプリ全体の生成なのかで、レビューに必要な労力は全く異なる。
著者の記録では、Codexが生成したファイルを列挙した（app.py、decoder.py、HTMLテンプレート、テストコード、ドキュメント等）。一方、仕様の記述と独立した音声ファイルの準備は自分が担当したと明記した。
最終的なGitコミットは著者自身が行い、Assisted-by: LLMという注記を付けた。カーネルの正式なSigned-off-by認証は個人プロジェクトには不要だが、「誰が生成し、何を自分で検証し、どこに責任があるか」がコミット履歴で追えるようになった。
カーネルのコーディングアシスタント向けガイドラインは、AIエージェントが他者に代わってコントリビューションに署名することを明確に禁じている。個人プロジェクトでの実務的な教訓は「コーディングエージェントを、保存・公開・共有の最終決定者にしない」ことだ。
まとめ
バイブコーディングを否定するのではなく、透明性と検証のプロセスを組み込むというのがこの記事の骨子だ。Linuxカーネルのガイドラインは巨大なOSSプロジェクトを対象に書かれたものだが、その原則は個人の小さなプロジェクトにも十分通用する。AIが生成したコードは動いているように見えても、誰かが理解し、検証しなければ信頼できないコードのままだ。
なお、Linuxカーネルにおけるこの種の議論は、LKML（Linux Kernel Mailing List）でも継続的に行われており、AIコード品質に懐疑的な開発者の声も多い。日本語での関連情報としては、kernel.orgの日本語ミラー情報や、Linuxカーネル開発プロセスの解説（The Linux Kernel documentation）も参照に値する。
詳細はThe Linux kernel has 5 AI coding rules every vibe coder should useを参照していただきたい。
