AI生成コードを含むプルリクエストを一律禁止にするべき理由がよくわかる「貢献者ポーカー」とは？

汎用プログラミング言語の「Zig」は、主要なオープンソースプロジェクトの中でも特に厳しいAIポリシーを敷いており、運営元のZig Software Foundationは明確にAI生成のコードが含まれるプルリクエストを禁止しています。なぜZigコミュニティがAIによるプルリクエストを禁止するのかについて、Zig Software Foundationのコミュニティ担当副社長であるロリス・クロ氏が「貢献者ポーカー」という考えを基に説明しました。

Contributor Poker and Zig's AI Ban | Loris Cro's Blog
https://kristoff.it/blog/contributor-poker-and-ai/

The Zig project's rationale for their firm anti-AI contribution policy
https://simonwillison.net/2026/Apr/30/zig-anti-ai/

オープンソース開発にはさまざまなメリットとデメリットが伴い、問題に対処する際にはそこから得られるメリットについて考える必要があります。つまり、デメリットが大きすぎるのにほとんどメリットがない場合、その問題に対処する価値が下がるというわけです。

オープンソースはそもそも「価値のあるソフトウェアを無償で提供する」というモデルであり、これに対する見返りとして一部のユーザーは「貢献者(コントリビューター)」としてプルリクエストを行います。プルリクエストとは、貢献者が開発したコードをプロジェクトチームと共有し、メインのコードベースへの統合(マージ)を提案する仕組みのことです。多くの貢献者から有用なコードがプルリクエストで提出されることで、オープンソースソフトウェアはより良いものになっていきます。

しかし、残念ながらプルリクエストの多くはプロジェクトにメリットをもたらすどころか、余計な労力や摩擦の原因になることが少なくないとのこと。実際のところ、プルリクエストの貢献者と協力してコードをマージ可能な状態にするよりも、メンテナが直接変更を実装した方が手間がかからないことの方が多いそうです。

また、Zigのように成功したオープンソースプロジェクトになると、いずれ処理能力を超えるプルリクエストが届くようになります。これまで説明してきた内容を踏まえると、不完全なプルリクエストを停止するのが理にかなっているように思われますが、Zigは新規の貢献者が提出したコードを可能な限り取り込めるよう支援しています。

新規の貢献者をサポートする理由について、クロ氏はそれがオープンソースプロジェクトの姿勢として正しいだけでなく、賢明な選択でもあるからだと主張。その理由を説明するために、「貢献者ポーカー」という考え方を用いています。

そもそもオープンソースプロジェクトへの貢献は1回限りのものではなく、何度も繰り返される反復的なプロセスです。貢献者がプロジェクトにもたらす価値の大部分は初回のプルリクエストではなく、その後の反復プロセスの中にあるとのこと。

最初にプルリクエストを受けた際はたとえデメリットの方が大きくても、新しい貢献者を迎え入れるために一定の労力を費やし、後のプロセスで多くのメリットがもたらされればプロジェクト全体にはプラスとなります。つまり、最初はプロジェクト側が貢献者に対してコスト(賭け金)を支払い、最後に投じた分を上回る賭け金を回収できればOKというわけです。

クロ氏がこのやり取りを「ポーカー」にたとえる理由は、実際のポーカーでは作られた「役」ではなく「プレイヤー」との駆け引きが大事なのと同じで、オープンソースプロジェクトの場合も「プルリクエスト」そのものではなく「貢献者」との関係が大事なためです。

クロ氏は、「このダイナミクスを明確に理解できたことが、Zigプロジェクトに長年にわたり多大な価値をもたらしました。コンパイラツールチェーンをゼロから構築することは非常に大規模な作業であり、貢献者からの多大な支援なしには到底実現不可能でした」と述べています。

こうした「貢献者ポーカー」の考え方に基づくと、AIによるプルリクエストを一律禁止にするべき理由がよくわかります。Zigのように大規模なオープンソースプロジェクトは、すでにプルリクエストの数が多すぎて対処しきれないという問題を抱えていますが、AIによるプルリクエストはこれを悪化させます。

プロジェクトに対して十分有益なプルリクエストを行うには、貢献者がコードベースと問題領域に精通し、プルリクエストによるすべての変更点を十分に検討することで、最適なアプローチを追求する姿勢をコアチームから信頼される必要があります。さらに信頼性を高めるプロセスの一環として、貢献者はコードがマージされた後もしばらくの間はコードに責任を負い、問題が起きた時の対処をしなくてはなりません。こうしたフォローアップの議論も、オープンソースプロジェクトに長らく携わってきたコアチームのエンジニアと継続的な関係を築く上で重要です。

残念ながらクロ氏らがこれまでに見てきたAIベースのプルリクエストは、ほとんどがマイナスなものだったとのこと。幻覚(ハルシネーション)だらけで役に立たないプルリクエストや、初回でいきなり1万行ものコードを送ってくるプルリクエスト、「AIを使っていない」と言いながらも間違いだらけのAI生成の回答を送ってくる貢献者などが存在したそうです。

もちろんすべてのAIが悪だというわけではなく、これらの貢献者はAIを誤用しているに過ぎませんが、Zigプロジェクトに寄せられるAIによるプルリクエストの圧倒的多数が無駄なものでした。クロ氏は、「理論的には大規模言語モデルを利用する正当な貢献者もいるかもしれませんが、貢献者ポーカーの観点からすると、このリスク要因をもたらさない他の貢献者が多数存在する中で、大規模言語モデルユーザーに賭けるのは単純に非合理的です」と説明しています。

なお、中には「貢献者がAIを使っているかどうか見抜くのは不可能」と文句を言う人々もいますが、これらの人々はAIによるプルリクエストを禁止するという方針の要点を理解しておらず、貢献者ポーカーの存在も知らないのだろうとクロ氏は指摘。「貢献者ポーカーは私たちの戦略の重要な要素であり、この戦略を効果的に実行する妨げとなるものには断固として立ち向かうことがプロジェクトにとって最善です」と述べました。

オープンソース開発者のサイモン・ウィリソン氏は、貢献者ポーカーの考え方は理にかなっていると主張。「プルリクエストの大部分が大規模言語モデルによって書かれているなら、なぜプロジェクトのメンテナは同じ問題を解決するために自分の大規模言語モデルを起動せず、プルリクエストのレビューや議論に時間を費やす必要があるのでしょう？」と指摘しました。