Zig プロジェクトが AI 貢献を厳しく制限する方針の理由
Zig プロジェクトが LLM による貢献を全面禁止する方針の背景にある、開発者育成とプロジェクトの健全性を優先する戦略的意図が明確に説明された。
キーポイント
Zig の厳格な LLM 禁止ポリシー
Zig は Issue、Pull Request、バグトラッカーのコメント（翻訳含む）において、LLM による生成物の提出を完全に禁止する方針を定めている。
Bun の事例と upstreaming の断念
Anthropic に買収された Bun は Zig のフォークで高性能化を実現したが、Zig の LLM 禁止規定により本家への統合（upstreaming）を見送った。
貢献者育成を最優先する哲学
Zig ソフトウェア財団は、コードの完成度よりも新規貢献者の獲得と信頼構築を重視しており、LLM による完璧な PR はそのプロセスを阻害すると判断している。
ROI とプロジェクト健全性のバランス
レビューコストを削減してコード量を増やすのではなく、開発チームが貢献者を指導し育成する時間的投資こそが長期的なプロジェクトの成功に寄与すると考えている。
影響分析・編集コメントを表示
影響分析
この方針は、生成 AI が急速に進化する中で、オープンソースコミュニティが「効率性」よりも「人的資本の育成」という本質的な価値を守るための重要な指針を示しています。特に大企業が関与するプロジェクトにおいても、AI の濫用を防ぎ、開発者エコシステムの健全性を維持するための強力な先例となります。
編集コメント
AI ツールの活用が当たり前になる中で、あえて「人の手による指導」の価値を再定義した事例として注目すべき記事です。開発効率化とコミュニティ健全性のトレードオフについて、実務家にとって重要な示唆を与えています。
Zig は、主要なオープンソースプロジェクトの中で最も厳格な LLM 利用禁止ポリシー の一つを持っています：
**
イシューには LLM を使用しないこと。
プルリクエストには LLM を使用しないこと。
バグトラッカーへのコメント、翻訳を含むすべてのコメントに LLM を使用しないこと。英語の使用が推奨されますが必須ではありません。母国語で投稿し、他の人々に各自の好みの翻訳ツールを使って内容を解釈してもらうことを歓迎します。
Zig で書かれた最も有名なプロジェクトは、Bun JavaScript ランタイムかもしれません。これは 2025 年 12 月に Anthropic に買収されました が、当然のことながら AI の支援を積極的に活用しています。
Bun は独自の Zig フォークを運用しており、最近「LLVM バックエンドに並列セマンティック解析と複数のコード生成ユニットを追加した」ことで、Bun コンパイルにおいて 4 倍の性能向上 を達成しました。こちらがそのコードです。しかし、@bunjavascript は述べています：
現在、Zig が LLM 作成による貢献を厳しく禁止しているため、これをメインプロジェクトに統合する計画はありません。
Zig Software Foundation のコミュニティ担当副社長であるロリス・クロは、Contributor Poker and Zig's AI Ban（via Lobste.rs）において、この厳格な禁止措置の根拠を説明しています。これは、LLM 支援によるコントリビューションに対する包括的な禁止に関するものとして、私がこれまで見た中で最も適切な説明です。
成功しているオープンソースプロジェクトでは、最終的に処理可能なプルリクエスト（PR: Pull Request）の数よりも多くの PR が寄せられる段階に達します。これまでに述べたことを踏まえると、作業からの投資対効果（ROI: Return on Investment）を最大化するために不完全な PR の受け取りを停止するのが理にかなっているように思えますが、Zig プロジェクトではそうはしていません。むしろ、新しいコントリビューターがその成果物を受け入れられるよう、必要な支援を行いながら最善を尽くしています。これは単に「正しい」ことをしているからではなく、 賢明な選択だからです。
Zig は貢献者自身を、彼らの貢献内容よりも重視します。各コントリビューターは、Zig コアチームによる投資と見なされます。PR のレビューや受け入れの主な目的は新しいコードを導入することではなく、時間とともに信頼性が高く生産的なコントリビューターへと成長できる新たな人材を育成することです。
LLM（大規模言語モデル）の支援はこの考え方を完全に壊してしまいます。たとえ LLM が Zig に対して完璧な PR を提出するのを助けたとしても、Zig チームがその作業をレビューするために費やす時間は、プロジェクト全体に新しい、自信があり、信頼できるコントリビューターを追加することに何ら寄与しません。
ロリスはここで名称の由来について説明しています：
これを「コントリビューター・ポーカー」と呼ぶ理由は、実際のカードゲームについて言われるように、「カードそのものではなく、プレイヤーを相手にする」からです。コントリビューター・ポーカーでは、最初の PR（Pull Request）の内容ではなく、そのコントリビューター自身に賭けます。
これは私にとって非常に理にかなっています。これは私が他の場所でも見かけた考えに関連しています：もし PR の大部分が LLM（大規模言語モデル）によって書かれたものであれば、なぜプロジェクトのメンテナーは、同じ問題を解決するために自分自身の LLM を起動する代わりに、その PR のレビューや議論に時間を割く必要があるのでしょうか？
Tags: anthropic, zig, ai, llms, ai-ethics, open-source, javascript, ai-assisted-programming, generative-ai, bun
原文を表示
Zig has one of the most stringent anti-LLM policies of any major open source project:
No LLMs for issues.
No LLMs for pull requests.
No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.
The most prominent project written in Zig may be the Bun JavaScript runtime, which was acquired by Anthropic in December 2025 and, unsurprisingly, makes heavy use of AI assistance.
Bun operates its own fork of Zig, and recently achieved a 4x performance improvement on Bun compile after adding "parallel semantic analysis and multiple codegen units to the llvm backend". Here's that code. But @bunjavascript says:
We do not currently plan to upstream this, as Zig has a strict ban on LLM-authored contributions.
In Contributor Poker and Zig's AI Ban (via Lobste.rs) Zig Software Foundation VP of Community Loris Cro explains the rationale for this strict ban. It's the best articulation I've seen yet for a blanket ban on LLM-assisted contributions:
In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.
Zig values contributors over their contributions. Each contributor represents an investment by the Zig core team - the primary goal of reviewing and accepting PRs isn't to land new code, it's to help grow new contributors who can become trusted and prolific over time.
LLM assistance breaks that completely. It doesn't matter if the LLM helps you submit a *perfect* PR to Zig - the time the Zig team spends reviewing your work does nothing to help them add new, confident, trustworthy contributors to their overall project.
Loris explains the name here:
The reason I call it “contributor poker” is because, just like people say about the actual card game, “you play the person, not the cards”. In contributor poker, you bet on the contributor, not on the contents of their first PR.
This makes a lot of sense to me. It relates to an idea I've seen circulating elsewhere: if a PR was mostly written by an LLM, why should a project maintainer spend time reviewing and discussing that PR as opposed to firing up their own LLM to solve the same problem?
Tags: anthropic, zig, ai, llms, ai-ethics, open-source, javascript, ai-assisted-programming, generative-ai, bun
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み