140行のガイドラインを7行へ削ぎ落とす:老舗オープンソース「QGIS」が選んだAIコード全面禁止の決断

140行のガイドラインを7行へ削ぎ落とす:老舗オープンソース「QGIS」が選んだAIコード全面禁止の決断

オープンソース人工知能コードレビューQGIS

データソース:GitHub / Hacker News

140行の細則を7行へ圧縮、老舗プロジェクトが閉ざした門戸

2026年9月24日、20年以上にわたって開発が続けられてきたオープンソース地理情報ソフトウェア「QGIS」のリポジトリに、PR #387という1つの提案が提出された。その内容は極めて異例だった。ポリシー文書から140行ものテキストを削除し、追加されたのはわずか7行。文書全体は148行から15行へと一気に凝縮された。

削ぎ落とされたのは、かつての穏やかな推奨や配慮の言葉すべてだ。新たに追加された条文は極めて明快だった。QGISリポジトリは今後、LLM、AI、またはエージェントの支援を受けたコードコントリビューションを一切受け入れない。もし事後的にそうしたワークフローの使用が判明した場合、提出されたコードはリバート(差し戻し)され、貢献者権限に対する制裁措置が取られる。この提案はコミュニティの強い支持を受け、迅速にマージされた。

No LLM, AI or agent assisted code contributions are allowed in the qgis repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.

ポリシー文書はバージョン1.0から2.0へと更新され、署名も単独のメンテナーから「QGISプロジェクトの全貢献者」へと改められた。ガバナンス文書の9割以上を削ぎ落としたにもかかわらず、その執行力はかつてないほど強固なものとなった。 自主的な善意に委ねられていた紳士協定は、後退の余地を残さない明確なレッドラインへと置き換わったのである。

提案改動ビュー 図:提案の差分ビュー。長大なポリシー文書が削ぎ落とされ、わずか1段落の条文へと圧縮された。出典:GitHub(QGIS-Enhancement-Proposals PR #387)

以前の旧ポリシーは、実際には非常に寛容なものだった。貢献者はあらゆるツールを自由に使って構わないが、「人間がループ内に留まること(Human-in-the-loop)」を義務づけていた。すなわち、提出前に自分自身でLLM生成コードやテキストを完全に精読・レビューし、署名した本人が全責任を負うこと。そして、コミットメッセージにツール名を明記するなど、生成AIの関与を正直に開示すること。旧文書はさらに、この規約は協調のあり方を定めるものにすぎず、プロジェクトとして「LLM生成コードを受け入れるべきか否か」という理念的立場を表明するものではないとまで明言していた。

しかし数か月後、その長大な協定は厳しい現実に押し流された。メンテナーのtimlinuxは率直にこうコメントしている。「この7行の短い条文に変える最大の利点は、あらゆる曖昧さを完全に排除できることだ」と。

コード生成はわずか3秒、人間による検証は1行ずつの持久戦

老舗プロジェクトが直面している苦悩の本質は、「検証コスト」の非対称性にある。エンターキーを一度叩けば数百行のコードが一瞬で生み出されるが、それをレビューする作業速度は1ミリも上がっていない。

それはまるで、飲食店の厨房に細切りジャガイモが山積みでトラックから投げ込まれるようなものだ。機械は数秒で大量の具材を吐き出すが、検品係の人間はボウルの縁にかじりつき、中に傷んだものが混ざっていないか1本ずつ目で選別しなければならない。QGISが扱うのは地理空間データと複雑な幾何演算である。座標変換の投影パラメータが小数点1桁ずれていたり、多重ループの深層にメモリリークが潜んでいたりしても、コンパイラは何のエラーも吐かない。生成側のコストがほぼゼロにまで圧縮された一方で、検証側のコストは微塵も下がっておらず、その差分を埋めるのは人間の時間とエネルギーしかない。

メンテナーのhaubourgは、ディスカッションの中でその理由をもっとも明晰に説明した。外部の貢献者がAIを使うことは、ボランティアのメンテナーの肩に途方もなく重く、耐え難い負担を強いている。そしてこの仕事は、LLMが登場する以前からすでに過酷を極めていたのだ。ツールの普及は負担を軽減するどころか、上流のアウトプット量だけを爆発的に増やし、下流へとなだれ込ませたにすぎない。

彼は2つの結末を提示した。コードの流入速度が人間のレビュー能力の上限を超えたとき、プロジェクトに待ち受けるのは、放置されたプルリクエストが果てしなく積み上がるか、十分に検証されていないコードがリポジトリに紛れ込むかのどちらかだ。産業グレードの基盤ソフトウェアにとって、どちらの結末も受け入れられるものではない。

メンテナーによる発言 図:プルリクエストのディスカッションで門戸を閉ざす理由を語るメンテナー。出典:GitHub(QGIS-Enhancement-Proposals PR #387)

他人のアカウントを介してモデルと口論する:メンテナーはAIの宿題採点係ではない

haubourgが挙げたもうひとつの理由は、さらに本質を突いている。フリーソフトウェアコミュニティの礎は「人間のネットワーク」にあるという点だ。企業や公的機関がQGISを信頼して採用するのは、自分たちもプロジェクトに還元でき、サポートや研修、機能開発のために人材を雇用できることを知っているからだ。これらの前提はすべて、「画面の向こう側に、対話が可能で、自ら責任を引き受けられる生身の人間が存在する」という信頼の上に成り立っている。

しかし現在、現場のメンテナーたちはその前提の崩壊に対して過重な代償を払わされている。同じ時期、Hacker News上では「AIコーディングエージェントはコードの量を増やしたが、ソフトウェアの価値を増やしたわけではない」という議論が巻き起こり、コメント欄はメンテナーたちの悲痛な証言集と化した。Plotlyのメンテナーは、校正もされていない3ページに及ぶIssueと「一見動くが脆い」パッチにレビュー時間を奪われ、通りすがりの外部貢献の受け入れ停止を検討していると語った。Hatchetは、最近のPRレビューは「他人のアカウントを経由してClaudeと押し問答をしているようなものだ」と嘆いた。PgDogはコードの受付を完全に停止してIssueのみに絞り込み、Godotの開発者はAI生成PRに疲弊した末に弱々しい謝罪文を投稿せざるを得なくなった。

haubourgが危惧しているのは、単に目の前の業務量だけではない。外部からのコントリビューションに機械的なノイズが大量に混入すれば、真剣に技術を学びたい人間の初学者が埋もれてしまい、プロジェクトの次世代の育成ラインが断ち切られてしまう。彼が守ろうとしているのは、まさにそのための余力なのだ。小さなバグ修正から誠実に学び始めようとする生身の初心者を温かく迎え入れるためのリソースを残すことである。

門を閉ざすのは制度としての判断であり、技術の否定ではない

QGISの今回の決定において、誤解してはならない重要なポイントがある。それは、この禁止令が「外部から提出されるコード」を対象にしたものだという点だ。プロジェクト自体がAI技術そのものを全否定したわけではない。haubourg自身、コードレビューや監査、セキュリティ検証に大規模言語モデルを活用することについては別の文脈で議論すべきだと明確に述べており、まずはユーザーカンファレンスで意見を集めた上で正式な議題に上げる意向を示している。

この区別は極めて重要だ。同じ道具であっても、門番の手にあれば精密な探傷器となり、門の外から押し寄せる濁流に混ざれば泥砂となる。制度として防ぐべきなのは「責任の所在が曖昧なアウトプット」であり、ツールそのものではない。

140行の寛容な指針から7行の強硬な全面禁止への回帰は、この現実に対する必然的な防衛反応である。生成側のスピードが目覚ましく加速する一方で検証側の能力が変わらない以上、善意の自主基準に頼った防衛線はいずれ崩壊するほかない。ボトルネックはもはや「コードを書くこと」ではなく、「そのコードが何をしているかを検証すること」へと移った。 門を固く閉ざして守ろうとしたのは、人と人との間で誠実な対話が成り立つという、オープンソースの原点そのものなのだ。

参考リンク:

  • QGIS 提案 PR #387(QEP428)
  • QGIS 提案ディスカッションにおけるメンテナーの発言記録
  • Hacker News:AI coding agents produce more code, not more software
  • Plotly、Hatchet、PgDog、Godot メンテナーの公開フィードバック