Zigの「反LLM」ポリシーとは何か

Zigプロジェクトの行動規範には、次のような条項が明記されている。「イシューにLLMを使用しないこと。プルリクエストにLLMを使用しないこと。バグトラッカーへのコメント（翻訳を含む）にLLMを使用しないこと」。翻訳目的であっても例外は設けられておらず、英語が推奨されるものの母語での投稿は歓迎されるとしている。これは、LLM利用を「補助ツール」として黙認・推奨するプロジェクトが増える中で、正反対の方向性を示す注目すべき事例と言えるだろう。

このポリシーが改めて注目を集めたのは、Zigで書かれた代表的プロダクトである JavaScript ランタイム「Bun」を巡る動きがきっかけと思われる。Bunは2025年12月にAnthropicに買収されており、AI支援を積極的に活用していることは想像に難くない。Bunの開発チームは、独自のZigフォークにおいて「並列セマンティック解析とLLVMバックエンドへの複数コード生成ユニット追加」によりコンパイル速度を4倍改善したと報告している。しかし@bunjavascriptは「ZigにはLLM生成コントリビューションの厳格な禁止があるため、現時点でこの変更をアップストリームに送る計画はない」と述べており、ポリシーの実質的な影響が顕在化している形だ。Sourceが報じているように、この状況はOSSコミュニティにおけるLLM活用の是非を問う象徴的な事例となっている。

「コントリビューター・ポーカー」という概念

Zig Software Foundation VP of Community である Loris Cro 氏は、自身のブログ記事「Contributor Poker and Zig's AI Ban」において、この禁止方針の論拠を詳細に説明している。その中核にあるのが「コントリビューター・ポーカー（Contributor Poker）」という概念だ。

Cro 氏の説明によれば、成功したオープンソースプロジェクトはやがて、処理可能な量を超えるプルリクエストを受け取るようになる。この状況において、メンテナーは受け取ったPRを精査・レビューするコストを負担し続けなければならない。ここで問題となるのは、LLMを用いたコードや文章の生成が「送る側のコスト」を劇的に引き下げる一方で、「受け取る側（メンテナー）のレビューコスト」はほとんど変化しないという非対称性だ。

ポーカーの比喩を用いるならば、コントリビューターは「低コストで多数のハンドを張れる」状態になるが、メンテナーは「すべてのハンドに対してフルコストでコールし続けなければならない」状態に置かれる。LLMが生成するコンテンツは一見して整然としており、表面的な品質が高いように見えることが多い。しかし、プロジェクトの設計思想・コードスタイル・長期的アーキテクチャ整合性という観点での深い理解を伴わない投稿が大量に流入した場合、メンテナーの認知負荷は指数関数的に増大すると考えられる。Cro 氏の論考はこの点を、単なる感情論ではなくプロジェクト持続可能性の問題として位置づけている点で、これまでの反LLM論の中でも論理的な整合性が高いと評価できる。

禁止ポリシーの是非：両論を踏まえた検証

この方針に対しては、肯定的・否定的双方の見方が存在する。肯定的な立場からは、メンテナーの持続可能な労働環境を守るという観点が支持される。特にZigのような、言語設計の哲学的一貫性が重視されるプロジェクトにおいては、「量より質」を担保する仕組みとして機能し得ると思われる。また、母語での投稿を歓迎しつつLLM翻訳を禁じるという方針は、「人間の声」を担保するという価値観の表れとも読めるだろう。

一方、否定的・懐疑的な立場からは、いくつかの論点が提起され得る。第一に、LLM支援の有無を技術的に検証することは現時点では困難であり、ポリシーの実効性に疑問が残る。第二に、非英語話者にとってLLM翻訳の禁止は参加障壁を高める可能性があり、ダイバーシティの観点から逆効果になる可能性も否定できない。第三に、LLMをあくまで「補助ツール」として活用し、最終的な判断・検証を人間が行うというアプローチを一律に排除することが、実際のコード品質向上機会を失わせるという見方もある。

ただし、Cro 氏の論考が示す核心は「LLMが悪い」という技術的断定ではなく、「コントリビューションのコスト構造が変化したとき、メンテナー側がその変化に対して自衛する権利がある」という組織論的主張と解釈するのが適切と思われる。この視点に立てば、禁止ポリシーは技術的な優劣判断ではなく、プロジェクトガバナンスの選択として評価されるべきだろう。

Bunの事例が示すように、LLM支援によって実際に有意義な技術的成果が生まれている可能性は十分にある。並列セマンティック解析によるコンパイル4倍高速化は、もし検証可能であれば相当な工学的成果と言えるだろう。それがアップストリームに取り込まれないという状況は、ポリシーの一定のコストを示している。

結論：「持続可能なOSS」という問いへの一つの回答

筆者の見るところ、Zigの反LLMポリシーは、AI生成コンテンツの「品質」を問う議論とは異なる次元、すなわち「プロジェクトのエネルギー配分と持続可能性」という問いに対する一つの回答として位置づけられると考える。LLMツールの普及が進む中で、各OSSプロジェクトがどのようなコントリビューションポリシーを設計するかは、今後のオープンソースエコシステムの形を左右する重要な問いになると思われる。

Zigの選択が唯一の正解であるとは言えない。しかし、「送る側のコストと受け取る側のコストの非対称性」というCro 氏の指摘は、LLM活用を推進するプロジェクトにおいても真剣に検討されるべき論点と評価できる。今後、LLM生成コンテンツの検出技術が成熟するか、あるいは新たなレビュー支援ツールが登場するかによって、この議論の地形は変化する可能性がある。いずれにせよ、Zigの事例はOSSコミュニティにおけるAI倫理の実践的議論に重要な参照点を提供していると考える。