Zig開発者、AIコードを全面禁止しGitHubからCodebergへ移行！53万行のBun書き換えが炙り出す開発現場の『価値観の断層』

• 事実と背景：Zig開発者Andrew Kelley氏がAIコードの貢献を正式に禁止し、GitHubからCodebergへプロジェクトを移行した。
• 技術的変革：AI生成コードは「例外なくゴミ」と断じ、限られたレビュー時間の浪費とコミュニティの健全性低下を指摘。
• 現場への影響：AI活用による開発効率化の裏で、コード品質、メンターシップ、オープンソースコミュニティのあり方について再考を迫られる。

我々エンジニアが日々直面する課題の一つに、コードの品質維持と、それを支えるコミュニティの健全性がある。特に、AIが生成するコードが開発プロセスに深く浸透し始めた今、その問題はより複雑かつ根源的なものへと変貌している。Zig言語の生みの親であるAndrew Kelley氏が、自身のプロジェクトにおいてAIによるコード貢献を正式に禁止したというニュースは、まさにこの現代的な課題に対する痛烈なアンチテーゼだと私は受け止めている。

Kelley氏がAI生成コードを「invariably garbage（例外なくゴミ）」と断じた背景には、極めて具体的な経験と哲学がある。彼は、AIによる貢献が「negative value（負の価値）」を持つとまで言い切る。なぜか。それは、限られた人間のリソース、特にコードレビューの時間が、質の低いAI生成コードによって無駄に消費されるからだ。まるでデッドロックに陥ったかのように、レビュー担当者はAIが生成した、あるいはAIを使って「体裁を整えられた」コードと格闘し、結局は「彼らが何をしているのか全く理解していない」という現実に直面する。これは、深夜の障害対応でスパゲッティコードと格闘する我々の日常と何ら変わらない、生々しい現実だ。

さらにKelley氏は、オープンソースプロジェクトにおける「contributor poker」という概念を持ち出す。これは、限られたレビュー時間を、将来的にプロジェクトのコアメンバーに成長し得る「本物の」エンジニアに投資すべきだという考え方だ。AIを利用するコントリビューターは、残念ながらこの「投資に値する」カテゴリーには入らない。彼らは学習せず、プロジェクトへの深いコミットメントも期待できない「ドライブバイコントリビューター」に過ぎない。AIが生成したコードは、その背後に人間の学習や成長のプロセスを伴わないため、コミュニティ全体の技術力向上には寄与しないどころか、むしろ阻害要因となり得るのだ。これは、単にコードが動けば良いという表層的な議論ではなく、オープンソースが持つ「知識の共有」と「人材育成」という本質的な価値への問いかけである。

このKelley氏の principled approach（原則に基づいたアプローチ）は、最近話題になったBunプロジェクトの事例と鮮やかなコントラストをなす。Bunは、AIエージェント（具体的にはClaude）の支援を受け、なんと53万行ものZigコードをRustに書き換えたという。この大規模な書き換えは、わずか11日間で完了したと報じられ、一部では「widespread public outrage（広範な公衆の怒り）」を招いたとも言われている。Kelley氏は自身のブログ記事「My Thoughts on the Bun Rust Rewrite」で、この件について「言語機能の優劣ではなく、二つのプロジェクトの『価値観の相違』に尽きる」と述べている。AIによるコード生成が、いかに効率的であろうとも、その背後にある品質保証、倫理、そしてコミュニティへの影響という側面を無視することはできない。我々エンジニアは、AIがもたらす生産性向上という甘い誘惑の裏側で、何を守り、何を犠牲にするのか、真剣に自問自答する時期に来ているのだと私は強く感じる。

Andrew Kelley氏の決断は、AIコードの禁止だけに留まらない。彼はZigプロジェクトのコードベースを、長年利用してきたGitHubからドイツの非営利団体Codebergへと移行させた。この「亡命」とも言える動きの背景には、単なる技術的な問題を超えた、プラットフォーム提供者の「インセンティブ」に対する深い不信感と、オープンソースプロジェクトの持続可能性への懸念が横たわっている。

Kelley氏がGitHubからの移行を決断した直接的な引き金は、GitHub ActionsにおけるCI（継続的インテグレーション）の「persistent failures（永続的な失敗）」だったという。「GitHub simply stopped working for us.（GitHubは我々にとって機能しなくなった）」という彼の言葉は、多くの開発者が共感するであろう、プラットフォームの信頼性に対する切実な不満を物語っている。CIが機能しないということは、開発サイクルが滞り、品質保証のプロセスが麻痺することを意味する。これは、開発現場において致命的な問題であり、まるで無限ループに陥ったかのように、開発者の生産性を著しく低下させる。

しかし、Kelley氏の真の動機は、単なるCIの不具合に留まらない。彼は、非営利団体であるCodebergが提供する「安定性」と、営利企業であるGitHubの「不安定性」を対比させている。営利企業は常に「next thing（次の大きなもの）」を追い求め、四半期ごとの利益を最大化しようとする。この絶え間ない成長と収益化のプレッシャーが、プラットフォームの安定性や、オープンソースコミュニティとの長期的な関係性を損なう可能性があると彼は指摘する。一方で、非営利団体は「just trying to keep doing what they’re doing（ただ現状を維持しようとしている）」ため、より安定した基盤を提供できるというのだ。この視点は、我々エンジニアが日頃利用しているSaaSやクラウドサービスが、その裏でどのようなビジネスモデルとインセンティブによって動いているのかを再考させる。

興味深いことに、一部の開発者も、AIワークロードの指数関数的な増加とGitHubのパフォーマンス低下が同時期に発生していることに同意している。これは、AI関連の処理がプラットフォームのリソースを圧迫し、既存のユーザー体験に悪影響を与えている可能性を示唆している。もしこれが事実であれば、GitHubのような巨大プラットフォームが、AIという新たな波にどう対応し、既存のオープンソースコミュニティとのバランスをどう取るのかという、より大きな課題が浮上する。Kelley氏のCodebergへの移行は、単なる個人的な選択ではなく、オープンソースプロジェクトが、その理念と持続可能性を追求するために、どのプラットフォームを選択すべきかという、現代的な問いを投げかけているのだ。我々エンジニアは、単に便利なツールとしてプラットフォームを利用するだけでなく、その背後にある哲学やビジネスモデルにも目を向ける必要があると私は考える。

Andrew Kelley氏がZigを開発した背景には、既存言語への深い不満と、より「本質的」なプログラミングへの渇望があった。彼がネイティブのデジタルオーディオワークステーションを構築しようとした際、JavaScriptでは低レベルのハードウェア制御が不可能であり、Go言語の「stop-the-world」ガベージコレクションはリアルタイムオーディオ再生の要件を満たせなかった。当時のRust（1.0リリース前）は借用チェッカーの摩擦が大きく、UIのフォントレンダリングに数週間を要するほど開発を阻害した。そしてC++は、永続的なメモリ破損バグがデバッグ時間を大量に消費し、開発者を疲弊させたという。これらの経験から、Kelley氏は自動メモリ管理を拒否し、明示的なメモリ割り当てを推奨するZigを2018年に仕事を辞めてまで構築したのだ。Ghostty、低遅延金融データベースTigerBeetle、そしてUberのクロスコンパイルインフラストラクチャといった、パフォーマンスと信頼性が極めて重視される分野でZigが採用されている事実は、その設計思想の正しさを雄弁に物語っている。

AIがコード生成を加速し、開発の「効率」が至上命題とされる現代において、Kelley氏のAIコード禁止とGitHubからの移行という一連の決断は、我々エンジニアに何を問いかけているのだろうか。それは、単なる技術的な選択を超え、プログラミングという行為の「本質」と、開発者としての「覚悟」を問うものだと私は捉えている。AIは確かに、定型的なコードの生成やリファクタリングにおいて驚異的な能力を発揮する。しかし、その裏で失われつつあるのは、コードの背後にある深い思考、設計意図の理解、そして何よりも「人間による学習と成長」のプロセスではないだろうか。

我々エンジニアは、AIを単なる「便利な道具」として盲目的に受け入れるのではなく、その限界と影響を深く理解し、どこでAIの力を借り、どこで人間の手と頭脳を介在させるべきかを見極める必要がある。AIが生成したコードを鵜呑みにせず、その品質を厳しく評価し、必要であれば自らの手で修正・改善する能力は、AI時代においてますます重要になるだろう。また、オープンソースコミュニティにおいては、AIによる貢献がもたらす短期的なコード量の増加と、長期的なコミュニティの健全性や技術力向上とのバランスをどう取るかという、難しい舵取りが求められる。

このニュースは、単なる特定の言語やプラットフォームの動向に留まらない。AIが開発プロセスに深く浸透する中で、我々エンジニアは「何をもって高品質なコードとするのか？」「開発者の成長とは何か？」「オープンソースコミュニティの未来はどうあるべきか？」といった、根源的な問いに直面している。明日から我々が取るべき具体的な対策は、AIを批判的に活用し、その生成物を盲信せず、常に自身の技術的洞察力と倫理観を磨き続けることだ。そして、プロジェクトやキャリアにおいて、単なる効率性だけでなく、コードの「本質的な価値」と「コミュニティの持続可能性」を追求する覚悟を持つこと。このKelley氏の決断は、AI時代の開発者にとって、まさにその覚悟を問う痛烈な問いかけなのである。