- 2016年モデルのMacBook Proの Broadcom BCM4350チップ はFreeBSDで標準サポートされておらず、従来はLinux VMを使う wifiboxによる回避策 が一般的だった
- 筆者は Claude Code を使ってLinuxのbrcmfmacドライバをFreeBSDへ移植しようとしたが、カーネルパニックと LinuxKPI互換性の問題 により失敗した
- その後 Pi coding agent を使ってbrcmfmacの動作原理を分析し、BCM4350専用の 11章構成の技術仕様書(specification) をAIが作成した
- 複数のAIモデル(Opus、Codex、Geminiなど)で相互検証して仕様を補強した後、それを基に FreeBSD向けの新規ドライバを完全自動生成 した
- 結果として Wi‑Fiスキャン、2.4/5GHz接続、WPA/WPA2認証 をサポートするカーネルモジュールが完成し、コードはGitHubで公開された
背景
- 2016年モデルのMacBook Proは Broadcom BCM4350 Wi‑Fiチップ を使用しているが、FreeBSDにはこのチップ向けのネイティブドライバがない
- FreeBSDフォーラムでは、一般的に wifibox というLinux VM経由でbrcmfmacドライバを使う方法が案内されている
- brcmfmac はBroadcomのFullMACチップ向けLinuxドライバで、802.11フレーム処理やWPA暗号化のような処理をチップ内部のファームウェアに委譲する
- FreeBSD向けのネイティブモジュールを作るには、Linuxコードの一部をFreeBSD向けに移植する 「glue code」変換 が必要になる
Act 1 — Claude Codeによる最初の試み
- 筆者は Claude Code を使ってbrcmfmacコードのFreeBSD向け変換を試みた
- FreeBSDの LinuxKPI 互換レイヤを参考に、Intel向けiwlwifiドライバの方式に従うよう依頼した
- モジュールはコンパイルできたが実機では動作せず、カーネルパニック が発生した
- Claudeは
#ifdef __FreeBSD__ 構文を追加して修正したが、LinuxKPIの不備 により依然として不安定だった
- AIはプロジェクトが「複雑で厄介なものになる」と警告し、結果的に 動かないコード だけが残った
Act 2 — 仕様書ベースのアプローチ
- その後 Pi coding agent を使ってbrcmfmacドライバの構造をBCM4350中心に分析し、クリーンルーム実装用の詳細仕様書 を作成させた
- AIは11章構成の文書を生成した
- 例:
00-overview.md, 04-firmware-interface.md, 08-data-path.md など
- 筆者は Codexモデル を使って仕様書と実コードの不一致を検証し、修正した
- 続いて Opusモデル で再検証し、修正内容がコードと一致しているか確認した
- 複数モデルを比較した結果、Gemini 3 Pro preview が最も多くの誤り(「hallucination」)を示したと述べている
Act 3 — 新しいFreeBSDドライバの構築
- 仕様書を基に BCM4350向けFreeBSDドライバを新規作成 するプロジェクトを開始した
- AIはプロジェクト構成、言語(Cを使うかどうか)、LinuxKPI依存性、マイルストーンなど 設計上の判断 を文書化した
- 当初はLinuxKPIを使用していたが、複雑さが増したため ネイティブFreeBSDコードへ移行 した
- AIはSSH経由でビルドホストとテストVMにアクセスし、自動ビルド・テストループ を実行した
- VMがクラッシュするたびに原因を要約・記録するよう設定した
- 反復セッションの末に、Wi‑Fiスキャン、2.4GHz/5GHz接続、WPA/WPA2認証 が可能なカーネルモジュールが完成した
結果と公開
- 完成したドライバはGitHubリポジトリ github.com/narqo/freebsd-brcmfmac で公開されている
- 筆者は「自分では直接コードを書いていない」と明言している
- いくつか既知の問題が残っており、現時点では 学習用の参考程度 にとどめて使うことを勧めている
3件のコメント
セキュリティに穴だらけ〜
ああいうふうに作って、セキュリティを強化して、レビューして、せめてアップストリームにPRでも残すとか、自分のGitHubでさらに強化してBSDコミュニティによく知らせるべきなのに、あそこで終わらせたのだとしたら、本気度はよく分からないですね。本当のユーザーなら手動でセキュリティの穴を埋めるだろうし、普段はWindowsを快適に使いながら趣味で別のOSをいじっている人なら放置するでしょう。2016年モデルであることを見ると、後者っぽいですね。
Hacker Newsのコメント
私が見るに、spec-firstアプローチが核心的な洞察だと思う
AIコード生成では、モデルに実装前に詳細な仕様書を先に書かせると反復サイクルが大幅に減る
仕様なしで始めると、モデルはもっともらしいアプローチの間で迷走するが、良い仕様があれば数千行のコードでも一貫性を保てる
2か月という開発期間も興味深い。カーネルドライバが新たに生まれたようなものなので、API利用料が500ドル程度なら十分に価値のある実験だ
コードの代わりにPiセッションを新しく開き、エージェントにbrcmfmacドライバの詳細な仕様を書かせたという部分が印象的だった
こうした**計画文書（markdown）**の作成は、大規模なLLM作業では本当に重要だ
記事で説明された事例は、その境界を越えたように見える。従来のクリーンルーム設計では、一方のチームがコードではなくインターフェースだけを文書化する
私にも似た経験がある。QEMUが旧版のMacOS（M1アーキテクチャ）でコンパイルできなくなっていたが、Sonnet 4.6に任せたら数分でパッチを書いてインストールまで完了した
エラーを見て修正しろと指示しただけなのに、完璧に解決した。正直、AIがなければそのまま諦めていたと思う
これからは、人々がソフトウェアを買うのではなく自分で作る時代が来る気がする
Thunderbirdのスパムフィルタが壊れたので自分で作り直したら、はるかによく動いた
CRMに欲しい機能がないなら自分で作ればいい。今では、自分固有の問題を解決するカスタムソリューションを簡単に作って配布できるようになっていくだろう
私の家族のような非技術職の人たちは、今後もアプリストアやWebサイトを使い続けるだろう
標準化されたソフトウェアの利点も大きい。企業はPhotoshopやXeroのような既に馴染みのあるツールを知っている人を雇える
近いうちに、すべてのOSでハードウェアサポートが完全に解決される気がする
AIコーディングエージェントは、どんなデバイスでもドライバを作れるほど進化しつつある
ハードウェアメーカーが意図的にインターフェースを隠さない限り、BSDやLinuxのサポートは自然についてくるだろう
むしろ人間の管理・検証役がより重要になった
ソフトウェアが世界を食う速度がさらに速くなっている
今やvibe-codedなソフトウェアがあらゆる場所に現れ、人々はそれを何の疑いもなく使うようになる気がする
問題は、マルウェアが混ざったコードが出てくる可能性があることだ。誰がそれを全部検証するのだろうか？
たとえばコンサートのチケットを買いたければ、AIエージェントがその場でコードを生成して実行する
翌年また買うときは、APIのバージョンに合わせて新しいコードを再生成する
無駄に見えても、はるかに動的で柔軟な構造だ
結局、ベンダーはAPIだけ提供すればよく、ユーザーは自分専用のUIを持てるようになる
たとえば私のボードゲームコレクション管理アプリはAIに任せられるが、金融やセキュリティ関連のアプリは専門家が作ったものを使う
AIが作ったカーネルモジュールがring 0でロードされ、作者自身も「問題が多いので実用は禁物」と明言している
まるで「本質的に安全でない時代」を速度で突き抜けようとしている感じだ
それでも何もしないよりはましで、コードが公開されている以上、改善も可能だ
すべてのGitHubプロジェクトが商用製品である必要はない
今回の作業は、既存実装を活用したポーティング作業に近い
GPLの観点から「着想」レベルなのか「ベース」レベルなのか比べてみると面白そうだ
会社でも既存実装があれば自信を持って進められるが、最初に道を切り開く人たちは評価されにくい
筆者は「自分ではコードを書いておらず、バグも多く、学習用として見てほしい」と言っていた
数か月で3回の試行を経て、ようやく動くところまで持っていった程度なのに、一部では「AIがプログラミングを征服した」と誇張している
実際には良い記事だが、タイトルだけ見て誤解したコメントが多い
ハードウェアやドライバの知識がなくても動くドライバを作れたのは、新しいマイルストーンだ
こうした成果物は出発点として大きな意味がある
高解像度で直接レンダリングする代わりに、GPUが差分を「それらしく」埋めるやり方に近い
Asahi Linux向けに最新Macのドライバが出てくるといいと思う。AIをうまく活用した事例だと思う
AIがAppleの文書やバイナリを学習していた可能性を排除できず、生成コードのライセンス互換性も保証できない