4月30日、Simon Willisonが「The Zig project's rationale for their firm anti-AI contribution policy」と題した記事を公開した。

「コード」ではなく「人」に投資するZigの哲学

AI活用が当たり前となった現在、プログラミング言語Zigは主要なオープンソースプロジェクトの中でも最も厳しいLLM禁止方針を貫いている。その理由は技術的な懸念ではなく、コントリビューター自体への投資を重視する独自の開発哲学にある。

Zig Software FoundationのコミュニティVPであるLoris Croが提唱する「コントリビューターポーカー」理論によると、成功するオープンソースプロジェクトの本質は新しいコントリビューターを時間をかけて育成することにある。PRレビューの主目的は新しいコードを取り込むことではなく、信頼できる生産的なコントリビューターを育てることだという。

Zigとは何か

Zigは2016年にAndrew Kelleyによって開発が始まったシステムプログラミング言語で、C言語の現代的な代替として注目されている。メモリ安全性を重視しながらも、CやC++との相互運用性を保ち、コンパイル時の計算能力に優れることが特徴だ。近年、JavaScriptランタイムBunがZigで実装されるなど、パフォーマンス重視のプロジェクトでの採用が増えている。

最も厳格なAI禁止方針

Zigの行動規範には以下のように明記されている：

イシューでのLLM使用禁止。

プルリクエストでのLLM使用禁止。

バグトラッカーでのコメント（翻訳を含む）でのLLM使用禁止。

この方針により、たとえ技術的に優秀なコードであってもAI支援で書かれたものは受け入れられない。実際、BunチームはZigの独自フォークで「並列セマンティック解析」の改善によりコンパイル性能を大幅に向上させたが、AI支援により開発されたため本家Zigには提供できないという事例も生まれている。

「コントリビューターポーカー」理論の詳細

Loris Croはブログ記事で、この方針の合理性を「コントリビューターポーカー」として説明している：

実際のカードゲームで「カードではなく人を見てプレイする」のと同じだ。コントリビューターポーカーでは、最初のPRの内容ではなく、コントリビューターに賭けるのだ。

成功するオープンソースプロジェクトでは、処理能力を超えるPRを受け取るようになる。その際、不完全なPRを拒否するのではなく、新しいコントリビューターが目標を達成できるよう最大限支援する。これは「正しい」ことだからではなく「賢い」ことだからである。

AI支援がもたらす根本的な問題

LLM支援はこのモデルを完全に破綻させる。たとえLLMがZigへの完璧なPRの作成を手助けしたとしても、Zigチームがそのレビューに費やす時間は新しい信頼できるコントリビューターの育成には何も貢献しない。

Simon Willisonも重要な指摘をしている：PRが主にLLMによって書かれたものなら、プロジェクトメンテナーがレビューに時間を費やすよりも、自分でLLMを使って同じ問題を解決した方が良いのではないか。

オープンソース開発の未来への示唆

Zigの方針は、AI時代のオープンソース開発において重要な問いを投げかけている。技術的な品質向上と引き換えに、コミュニティの持続可能性やコントリビューターの成長機会を犠牲にすべきなのか。

他の主要プロジェクトがAI支援開発を積極的に受け入れる中、Zigの逆張りとも言える姿勢は、オープンソースの本質的価値について改めて考える機会を提供している。

詳細はThe Zig project's rationale for their firm anti-AI contribution policyを参照していただきたい。