ハクソク

世界を動かす技術を、日本語で。

Zigプロジェクトの堅固な反AI貢献ポリシーの理由

7時間前原文(simonwillison.net)

概要

  • Zigプロジェクトは、主要なオープンソースの中でも特に厳格なLLM（大規模言語モデル）禁止ポリシーを採用
  • イシューやプルリクエスト、コメントにおけるLLM利用を全面禁止
  • Bun JavaScriptランタイムはZigベースだが、独自フォークとAI活用を進行
  • Zigのポリシー背景には貢献者重視の文化が存在
  • LLM利用がコミュニティ成長の阻害要因となると明言

Zigの厳格なLLM禁止ポリシー

  • Zigプロジェクトは、イシュー、プルリクエスト、バグトラッカーのコメントを含め、LLMによる生成物の利用を一切禁止
  • 英語推奨だが必須ではなく、母国語での投稿も歓迎
    • 各自で翻訳ツールを利用して内容を解釈する運用
  • Bun JavaScriptランタイムが代表的なZig製プロジェクト
    • BunはAnthropicに2025年12月に買収
    • AI支援を積極活用し、Zigのフォークで4倍のビルド高速化を達成
    • しかし、Zig本家にはアップストリームしない方針を表明
      • 理由：ZigのLLM禁止方針に抵触

ZigコミュニティがLLMを禁止する理由

  • **Loris Cro（Zig Software Foundation VP of Community）**がポリシーの理由を解説
  • 成功したオープンソースプロジェクトでは、処理可能数を超えるPRが集まる状況が発生
  • Zigでは、完璧なPRのみ受け入れる方針は採用せず、新規貢献者の成長を重視
    • コアチームが貢献者自身に投資し、将来的な信頼・実力のあるメンバー育成を目指す
    • PRレビューの主目的はコードの品質向上ではなく、貢献者の成長支援
  • LLM支援によるPRは、プロジェクト成長のこの仕組みを根本から損なう
    • LLMが作成したPRをレビューしても、新たな信頼できる貢献者は増えない
  • 「contributor poker（貢献者ポーカー）」という考え方
    • カードゲーム同様、「人を見て賭ける」という発想
    • 最初のPR内容よりも、貢献者本人の将来性を重視

LLM禁止の合理性と他プロジェクトとの違い

  • LLM主導のPRが増えると、プロジェクトメンテナーの負担増大
    • LLMで作成できるなら、メンテナー自身もLLMを使えばよいという状況に
  • Zigでは、人間の貢献者こそが最大の資産という価値観
  • 他プロジェクトでは効率や品質重視が主流だが、Zigはコミュニティ育成重視で独自路線
  • この方針が、長期的なオープンソースプロジェクトの持続的発展につながる可能性

Hackerたちの意見

> これは私にとってすごく納得できる話だ。別のところで見かけたアイデアに関連してるんだけど、もしPRがほとんどLLMによって書かれていたら、プロジェクトのメンテナーがそのPRをレビューしたり議論したりする時間を使う理由は何だろう？自分のLLMを使って同じ問題を解決すればいいじゃん。オープンソース自体にも同じことが言えるよね。誰かのプロジェクトを使うより、自分のロボットに書かせた方がいいじゃん？特に、オープンソースプロジェクトが「バイブコード」されてたらそうだよね。AIやテクノロジーのおかげで、パーソナライズが安く手に入るようになった。昔はみんなに満足してもらうために大量生産されたものを使わなきゃいけなかったけど、今は自分だけの特別なものを手に入れる希望がある。これって労働経済にも刺激を与えるよね。みんなが自分のLLMでオープンソースプロジェクトを再発明してるから。
└
それはオープンソースプロジェクトの中でも一番小さいレベルにしか当てはまらないよ。ある程度の複雑さを超えると、ロボットがあなたの考えを理解して高品質で「あなたに特別なもの」を提供するのは難しいと思う。Zigプロジェクトはその能力をはるかに超えてるよ。
└
> 誰かのプロジェクトを使うより、自分のロボットに書かせた方がいいじゃん？最近これについてずっと考えてて、今私がソフトウェアで一番大事にしてるのは、堅牢なテストや徹底したドキュメントじゃないって気づいた。LLMはそれを数分で作れるからね。私が求めてるのは、他の人が使ったことのあるソフトウェアなんだ。彼らがバグや鋭い部分に遭遇して、それを磨き上げてくれたらいいなって思う。
└
ほとんどの人は、LLMの出力が良いかどうかを判断できるほどコードを読み解く能力がないんだ。そして、ほとんどの人は非トリビアルなプログラムを開発できるモデルのサブスクリプションを持っていない…でも、これが数年後には本当に問題になるかもしれないね。
└
LLMへのアクセスはまだ普遍的ではない。手が届かない人もいるし、アクセスできる人でも、Claudeのダウンタイムや時間の経過によるパフォーマンスの低下などの問題がある。例えば、数ヶ月前にClaudeを使い始めたときは、複数のプロジェクトで簡単に進展があったんだけど、今はほとんど何も進まなくて、ほとんどの時間Claudeはスピナーを表示してるだけ。コードの質も落ちてる気がする。
└
>> 以前は、みんなが満足するために大量生産されたものを使う必要があったけど、最近OpenSCADを使い始めた者としては、この考え方がすごくイライラする。人気のあるツールを「使わなきゃいけなかった」わけじゃないよ。OpenSCADの例は特にわかりやすい。使いにくくてイライラするし、特定のメンテナー向けに調整されてるのが明らかだから、変えてほしいことがたくさんある。でも、LLMにそれをやらせるのは絶対に無理だ！「ああ、出力は良さそうだね、いいね」なんてCADプログラムには全然足りない。「ああ、テストがたくさんある、いいね」って言われても、徹底的なCADテストスイートがどういうものか全くわからない。ClaudeにカスタムSCADプログラムを作らせるなんて、無謀なバカだよ…逆に無駄な労力をかけない限り。だから、OpenSCADで十分なんだ。あと、これが「労働経済」をどう刺激するのかも本当に謎。最も明らかな反論は、Anthropicだけがここで経済的利益を得ているように見えること。オープンソースのメンテナーは、品質を妥協しない限り完全に詰んでるし、LLMユーザーは問題を理解している人が作った高品質なツールを、ロボットが作ったクソみたいなツールと引き換えに、無報酬の労働で交換している。これは「労働経済」をバイザロ・ケインジアン的に刺激するだけで、誰かが入れ忘れたお金の入ったガラス瓶を掘り起こすようなものだ。この3ヶ月で、完全に壊れたバイブコーディングのRust SQLiteクローンを少なくとも4つ見たけど、データベース設計のような日常的な問題を心配しなくていいと思っている人たちに喜ばれている。これは解決済みの問題で、Claudeがやってくれる！実際、あの馬鹿な人間のSQLite開発者とは違って、Claudeはマルチスレッドにしてくれた！本当に憂鬱だよ。
└
2010年代初頭に「3Dプリント革命」がすぐそこまで来ていたとき、同じような議論を聞いたのを覚えてる。モデルをダウンロードして自宅で印刷できるなら、もう誰も何かを買う必要があるの？しかも無限にカスタマイズできるのに？文明を持つ意味は、ほとんどのことを他の誰かの問題にして、自分は一つのことをうまくやることに集中できることだよね。もし私が歯医者かマフラーショップを経営しているなら、1日に使える時間は限られてるから、変な高メンテナンスの部下を監督するよりは、SaaSベンダーにお金を払った方がいいと思う。例外もあるけど、それはあくまで例外。もしベンダーが合理的で、まともな製品を作ってくれるなら、喜んでお金を払うよ。オープンソースも同じで…たとえLLMが信頼性高く新しいオペレーティングシステムをゼロから作れるとしても、本当にそれを望むかな？OSを維持したくないし、OSを維持する人の責任を持ちたくもない。そもそも、OSに対する一貫したビジョンを持てる自信もないし！
└
自分のリポジトリに対するPRが減ってきてるのを感じてる。星が100個くらいのリポジトリがいくつかあるけど、特にすごいわけじゃないけど、去年までは時々PRが来てた。今年は今のところほとんどない。私の仮説は、LLMがメインストリームのプロジェクトにこだわる傾向があるってこと。今、多くの開発者がLLMに頼っているから、私が提供するものをほとんど無視しているんだ。LLMは今や安くできるから、無駄に同じものを作ることが多い。だから、私のようなマイナーなものをGitHubで使うより、必要なものを生成する方が簡単なんだ。依存関係の選択でも同じことに気づいた。特に良い理由がない限り、LLMが提案するものを選ぶことが多い。
└
LLMの貢献を高品質にするために必要な作業量を無視していると思う。純粋な人間の貢献よりはずっと少ないけど、ゼロではない。だから、オープンソースの共通作業を中央集権化することは、LLMにとっても以前と同じくらいの利点があるんだ。
└
> 「なぜ誰かのプロジェクトを使うの？ロボットに自分のを作らせればいいじゃん。」 それが可能なら、代替案として考える価値はあるね。 > 「それは労働経済を刺激するから、どこにでもたくさんの人が自分のLLMでオープンソースプロジェクトを再発明してる。」 それがどういう意味かはよくわからないな。
└
> 「なぜ誰かのプロジェクトを使うの？ロボットに自分のを作らせればいいじゃん。」 半分複雑なソフトウェアの代替を作るのはすごく高くつくからじゃない？フロンティアモデルにZigやDocker、VSCodeの代替を作らせるのは大変だよ。
どうやら、AIポリシーに関する騒ぎは、Bunの開発者たちがそのポリシーがパフォーマンスPRのアップストリームを妨げていると言っていたことから来ているみたい。でも、本当の理由はそのPRのコード自体があまり良くなくて、不健康な複雑さを引き起こしているからみたいだね。https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... > 並列セマンティック分析は、Zigコンパイラの長い間計画されていた機能で、自己ホスト型Zigコンパイラの設計にも大きな影響を与えている。ただし、この機能を正しく実装するには、コンパイラの実装だけでなく、Zig言語自体にも影響がある！だから、バグや不整合の山を避けるためには、言語の変更が必要なんだ。
└
3000行の追加のための単一のPRは、ほぼ確実に却下されるだろうね。
└
PRの質について議論する意味って何？ポリシーはすべてのLLMコードを明示的に禁止してるから、そのポリシーが「本当の理由」だよね。
└
うん、その返事はBunフォークをマージしない理由を納得させるものだね。Zigの自分たちのロードマップに干渉するから、より良い結果を出すための道を進むのが大事だし、言語全体を改善し続けることも重要だよ。
これとは逆に、AIツールを許可するオープンソースプロジェクトは、新しい貢献者に対してより制限的になるだろうね。これは、企業の支援を受けた大規模なソフトウェアプロジェクト（ウェブエンジンやコンパイラなど）で既にある程度起こっていて、独立した個人として貢献を始めるのは簡単じゃないことが多い。合理的な人々は、どちらのアプローチが本質的に優れているかについて意見が分かれるかもしれないけど、結局のところ、異なる目標を最適化しているように見えるんだよね。
└
そうだね、LLMにgit blameやgit grepを使わせることで、退屈な作業をかなり時間短縮できたよ。
└
誰かからの貢献があっても、その人がビルドシステムやテストにアクセスできなかったらどうなる？テストハーネスとLLMのワークフローがあれば、自分で新しいコードを書く方が楽なんだよね。「秘密のソース」を渡すわけにはいかないし。「この簡単な機能に1000個の新しいテストが必要な理由」を議論するつもりもないし、フルリリースビルドに2日もかけたくない。マージするためには、結局99%の作業を自分でやらなきゃいけない（分析、自動テスト、ビルド、スモーク、回帰テスト）。小さなコミットをマージするのは礼儀としてやってるけど（一人芝居に見えないようにね）、大規模なリファクタリングを受け入れるなんて無理だよ！
いい理由だと思う。でも、オープンソース開発の本当のボトルネックを指摘してるね。それは、貢献を手動でレビューする負担。AIを使ってそれを自動化する必要もある。AIが登場する前から、レビューは問題になってた。多くのプロジェクトが、世界中の未経験の開発者からの大量の貢献を受けて、GitHubの統計を増やすことで履歴書を良くしようとしている。これはStackoverflowを壊したのと同じダイナミクスだ。AIのおかげで、今はほとんど脇に追いやられてるし。AIがある今、同じ未経験の開発者たちがそれを使ってさらにゴミのような貢献を生み出してる。すべてを手動でレビューするのは非常に労力がかかるし、スケーラブルじゃない。でも、AIはコードレビューやガードレール、貢献者ガイドライン、その他のルールの遵守を確認するのが得意なんだ。完璧ではないけど、あまり使われていないツールだよ。レビューアーや貢献者の両方にとってね。もしあなたの貢献が明らかにガイドラインに従っていないなら、自動的に却下されるべきだ。「明らかに」という言葉は「AIシステムで簡単に検出できる」という意味だ。新しい貢献者からの貢献には、もっと厳しい目を向けるべきだし、そのほとんどは自動化されるべきだ。自動チェックを通過したものにだけ注意を向けるべきだよ。貢献の質、貢献者の信頼性、ルールへの遵守などにね。信頼性は、信頼できるソースからの貢献が優先されることを保証する良い方法だ。もしあなたの評判が良くないなら、もっと厳しい目を向けられることを覚悟すべきだし、優先順位も低くなるよ。
└
> [あなたは] ROIを最大化するために不完全なPRを受け入れるのをやめることができるけど、それがZigプロジェクトのやり方じゃない。成長したいなら、正しい人たちとつながることが本当のボトルネックだよ。コミュニティを築きたいなら、LLMはそれを助けてくれない。問題を理解する必要をスキップするためにLLMを使ったら、どうやって信頼できる評判を得るの？この投稿は評判についてではなく、コミュニティでの人々の反応や協力を見ることについてだよ。編集：あなたがそれを助けやツールとして捉えているのはわかるけど、私はそれがただの障害に過ぎない気がする。
└
Zigのことはよく知らないけど、ここでの問題はそれじゃないと思う。正確にはね。本当の疑問は、貢献が安くて正確なら、なぜそんなに多くの努力をして貢献者のプールを育てて調整するのかってこと。コードレビューは、単に「言っていることをやっているか」と「ガイドラインに従っているか」を確認するだけじゃないんだ。レビューは、プロジェクトの方向性やそこにどうやって到達するかを話し合うための接点なんだよ。それが長期的には最も重要な部分だと思う。集団的な人間の努力として、調整が必要なんだ。一部はレビューのプロセスを通じて行われる（特にロードマップを作成するコアチームに入っていない人たちにとってね）。その微細な決定を合理的に文書化することもできるけど、結局は「ワカモレゲーム」になっちゃうかも。個人的には、AIを使うプロジェクトは、もっと調整や品質保証に力を入れるべきだと思う。
└
結局、すべてを手動で再レビューしなきゃいけないんだよね。言語のコンパイラだから、バグや悪いアーキテクチャの決定は大きなコストがかかる。彼らはCodebergに移ったから、今はゴミのようなPRが少なくなったよ。良いコードをPRで出すことが期待される文化を育てようとしてるんだ。手動でゴミのPRを見つけるのに5分もかからないよ。LLMは意味のあるものが半分しかない壁のようなテキストで溢れさせることができるし、悪いアーキテクチャを見つけるのは本当に難しい。人気のない言語のコンパイラだってことを忘れないでね。
> 「なぜプロジェクトのメンテイナーは、そのPRをレビューして議論する時間を使うの？自分のLLMを立ち上げて同じ問題を解決すればいいじゃん。」 それは確かに聞く価値があるけど、みんなが全然違う結論に至るみたいだね。 でも、時間もトークンもかかるし、どちらも無料じゃないからね。個人的には、メンテイナーにはできるだけ多くのドキュメントや仕様を書く時間を使ってほしいな。そうすれば将来のLLMに強いガードレールができるから。Zigの方針は数年後には完全に時代遅れになるだろうね、良くも悪くも。誰かがbunのフォークを取って、ここにコード生成の改善を加えたり、あそこにリンカーの改善を加えたりして、突然Zigの外にもっと良くて速いZigができるかもしれない。
└
もし古くなったら、彼らは自分たちの方針を見直すことができるよ。今は理にかなってる。こういうAIの初期段階にいるから、最終的にどうなるかわからないしね。誰かがそれをフォークして、AIで改善する可能性もある。もしそうなったら、メンテイナーがコードをレビューする方がプロジェクトにとって良かったってわかるだろうね。そうなったら、彼らはフォークのメンテイナーになるかもしれないし、もしかしたらその仕事が嫌で他のことをやりたくなるかもしれないね。
> 「もしPRがほとんどLLMによって書かれていたら、なぜプロジェクトのメンテイナーはそのPRをレビューして議論する時間を使うの？自分のLLMを立ち上げて同じ問題を解決すればいいじゃん。」 それは確かに聞く価値があるけど、みんなが全然違う結論に至るみたいだね。
正直、そんなに悪くないと思うよ。LLMを使っちゃいけないってわけじゃなくて、コミットの著者にはなれないってことだね。つまり、開発者としてLLMが書いたことに責任を持つなら、全然問題ないよ。ただし、技術的な質問に答える準備をしておいてね。コードレビューで厳しくチェックされるかもしれないし、その部分でCVEが出たら呼ばれることもあるから。
https://kristoff.it/blog/contributor-poker-and-ai/ より: 「残念ながら、LLMを使った貢献は、私たちにとってほとんどネガティブな現実でした。無価値なドライブバイPRが増えて、ハルシネーションだらけで（コンパイルすら通らないし、CIも通らない）、初めてのPRが1万行もあるなんてこともありました。その間に、表面的には問題なさそうなPRもたくさん受け取りましたが、いくつかはLLMを使っていないと明言していたものの、フォローアップの議論で著者がこっそりLLMを参照して、間違いだらけの返答を私たちに吐き出していることがすぐに明らかになりました。」
└
LLMファン層をほぼ要約してるね。
最近の数ヶ月で、Zig/ZSFチームがLLMを使ってくれたらいいなと思うことが何度もあったよ。単純作業を良いLLMに任せていれば、存在しないはずのコピペミスをたくさん見つけたから。Zigコミュニティでも、興味のあるプロジェクトに対して「全部人間が作った」ってアピールするPRを見たけど、最悪のLLMでも見抜けるようなトリビアルな論理エラーが含まれてた。
└
それを見つけたなら、潰してあげればいいじゃん？
Zigの人たちはZeroMQの道を進んでいるみたいだね: 「プロジェクトの共同所有を強化することで、貢献者への経済的インセンティブを高め、敵対的な組織によるハイジャックのリスクを減らす。」健全な貢献者コミュニティは、単なるコードのパフォーマンスや機能の量、行数よりも重要だよ。 [1] https://zguide.zeromq.org/docs/chapter6