QGISがAI支援コードの受け入れを停止。問われるのは「レビューする人」の時間
AIを使えば、複雑なソフトウェアにも短時間で修正案を出せる。では、その案を確かめる人の時間も同じように増えるだろうか。地理情報システムのオープンソースソフト「QGIS」が10月7日に採用した方針は、この非対称性に正面から向き合うものだ。
新しい規定は、QGIS本体のGitHubリポジトリに対し、LLM、AI、エージェントの支援を受けたコードの貢献を認めない。違反が後から分かった場合は、コードの差し戻しや貢献者権限への措置の対象になる。対象は明記されたリポジトリへのコード投稿であり、QGISの利用者がAIを使って地図を作ることを禁じる規定ではない。
なぜ「人が確認すればよい」では足りなかったのか
QGISは以前、AIを利用した貢献を人が確認する方向の方針を持っていた。しかし今回の提案をめぐる議論では、外部から届くAI支援の修正案が保守担当者のレビュー能力を超え、未確認の提案が積み上がるか、十分に読めないまま品質を損なう懸念が語られた。
コードを生成する時間と、そのコードが既存の設計に合うか、例外時にも動くか、将来も保守できるかを調べる時間は別物だ。投稿者にとっての作業短縮が、受け取る側の負担増になることがある。QGIS側の議論は、単に生成コードの正誤だけでなく、レビューする人を継続的に確保できるかを問題にしている。
提案のコメントには、AIを使って不具合修正を試みた参加者自身の振り返りもある。複雑なコードを十分に理解しないまま「直せた」と感じてしまい、投稿者とレビュー担当者の間にある信頼を損ね得る、というものだ。これはすべてのAI利用者に当てはまる結論ではないが、受け入れ側が背負う確認作業を具体的に表している。
一律の入口から、例外を議論する余地へ
方針の文面は短く、AI支援コードを許可しないと定める。一方、提案者らは議論の中で、これを永久に固定する規則ではなく、まず厳しく閉じ、補完や翻訳などの利用例を後から個別に検討する考えを示した。AIを使ったレビュー、調査、セキュリティ監査なども議論で論点となったが、今回の規定が具体的に対象とするのはコードの貢献だ。境界が曖昧な使い方を、記事の側で勝手に許可・禁止と断定すべきではない。
賛否が分かれるのも自然だ。AIの補助で新しい参加者が大きなプロジェクトに入れる利点がある。一方、レビュー能力には上限があり、長く関わる人が疲弊すれば、開かれた開発そのものが続きにくくなる。今回の決定は、その両方を見たうえでQGISが選んだ現時点の運用だ。
日本の開発チームにもある同じ問い
日本の企業や自治体が使うソフトウェアでも、AIエージェントによる修正案は増えていくだろう。社内のコードレビューでも外部のオープンソースへの投稿でも、「人が最終確認する」という一文だけでは運用は決まらない。誰が変更の意味を説明し、どのテスト結果を示し、レビュー担当者が理解できる量に投稿を絞るのか。受け入れる側の時間を設計に含めて初めて、AIによる開発速度は共同作業の速度になる。
QGISの判断がすべてのプロジェクトにとって正解とは限らない。それでも、コードを速く書ける時代に何が希少になるのかは明確だ。責任を持って読み、直し、維持できる人の時間である。
出典：QGISのAI利用方針、方針変更の議論と承認、Hacker Newsでの議論。内容は2026年10月13日時点の公開情報に基づく。