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

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

概要

  • 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言語自体にも影響がある!だから、バグや不整合の山を避けるためには、言語の変更が必要なんだ。

Hacker Newsで議論の続きを見る