QGISプロジェクトは2026年10月7日、QGIS Enhancement ProposalsのPR #387をマージし、AIツール利用方針を更新しました。現行のQEP408は、LLM・AI・エージェントに支援されたコード貢献を、qgis/qgisリポジトリで認めないと定めています。
これまでのQEP408は、人間が生成物を読み、理解し、レビューしたうえで、ツール利用を開示する「human in the loop」方式でした。AIを使ったことを申告すれば投稿できるという運用から、少なくとも対象リポジトリへのAI支援コード貢献を受け付けない運用へ軸足が移っています。
ただし、現行文言が直接対象にするのはqgis/qgisへのコード貢献です。社内でのAI利用や、文書・議論・検索などすべての行為を一律禁止するとまでは書かれていません。QGISを使う企業が上流へパッチを返すときに、どのルールを確認すべきかを整理します。
※本記事は2026年10月14日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
QGISは何を決めたか｜PR #387でQEP408を更新
今回の変更は、PR番号とQEP番号を分けて読む必要があります。PR #387のタイトルは「Add QEP428: No ai contributions permitted」です。マージ後に公開されているポリシーファイルは新規のQEP428ではなく、既存のqep-408-ai-tool-policy.mdでした。QEP428は提案名、QEP408は更新されたファイル名として扱うと混乱しません。
現行ファイルの方針は、qgis/qgisリポジトリで「LLM、AI、エージェントに支援されたコード貢献」を認めないというものです。AIを使ったワークフローが後から判明した場合は、コードの差し戻しと貢献者権限に関する制裁の対象になると記載されています。
PRの提案者は2026年9月24日のコメントで、方針を strict な「NOT ALLOWED」へ変更すると説明しました。企業が見るべきなのは刺激的な見出しではなく、どのリポジトリの、どの種類の貢献を対象にした文言なのかです。AI支援コード貢献のレビュー体制を考える際は、AI生成コード時代のコードレビューで扱われるレビュー負荷とも接続します。
ポイント
PR #387はQEP428という提案名を掲げていますが、更新対象は既存のQEP408です。現行ルールの直接の対象は、qgis/qgisへのAI支援コード貢献です。
旧QEP408の開示制から何が変わったか｜人間の確認だけでは足りない
2026年1月31日版のQEP408は、使うツールを限定していませんでした。貢献者がLLMの生成物を読み、レビューし、自分の著作物として責任を持てることを前提に、プルリクエストやコミットメッセージでツール利用を開示する考え方です。実質的なツール生成内容には、Assisted-by:のような記載を使う例も示されていました。
自律エージェントが人間の承認なしにGitHub上で動くことや、人間の確認なしにレビューコメントを公開することは、旧方針でも認められていませんでした。一方で、人間が正しさを確認して編集した文書生成や、opt-inで人間が確認するレビューは許容例です。現行方針は、この開示と人間の確認を満たせばコードを出せるという前提を取り下げています。
| 項目 | 旧QEP408（2026年1月） | 現行ポリシー（2026年10月） |
|---|---|---|
| 基本姿勢 | 人間が理解・レビューする限りツール利用を許容 | qgis/qgisへのLLM・AI・エージェント支援コード貢献を不可 |
| 開示 | ツール生成内容を説明し、Assisted-by:などを例示 | 開示すればコード貢献できる例外は書かれていない |
| 自律エージェント | 人間の承認なしの行動は不可 | コード貢献へのAI・エージェント支援自体を不可とする文言 |
| 違反時対応 | 修正要求、クローズ、繰り返し時の権限制裁 | コード差し戻しと貢献者権限に関する制裁 |
比較の要点は、レビューの質を上げる条件が変わったことです。旧方針では人間の理解と開示が入口でしたが、現行ポリシーでは対象コード貢献そのものを認めない文言になりました。「人間が最終確認したから投稿できる」と自社のルールだけで判断するのは危険です。
ポイント
旧QEP408の「開示して人間がレビューする」は、現行ポリシーでコード貢献を許可する条件としては扱えません。過去の社内運用をそのまま上流PRへ持ち込まず、最新版の対象範囲を確認します。
なぜ開示制が機能しなかったのか｜レビュー負荷と抽出型貢献
方針変更の背景には、AIの良し悪しを一括りにするより、メンテナーの作業量をどう守るかという問題があります。PRの議論では、旧方針にあったextractiveラベルが作られず、約50件のPRがAI Assistedとタグ付けされ、そのうち約40件がマージされずに閉じられたという指摘がありました。いずれも議論で示された概数で、QGIS全体の公式統計として読む数字ではありません。
開示は「AIを使ったPRだ」と知らせる役割を持ちます。しかし、それだけでレビューに必要な設計理解や検証作業が減るわけではありません。投稿量が人間のレビュー能力を上回れば、未レビューのPRが滞留するか、十分に読まれないまま品質問題を抱えます。
QGISの議論では、貢献者とメンテナーが同じ設計意図を共有し、質問に答えながらコードを育てる関係が重視されています。AIが作った成果物を人間が後から説明するだけでは、実装者側からレビュー側へ負荷が移る構造です。企業は生成速度ではなく、レビュー可能な粒度と保守担当者の余力を先に見積もる必要があります。
この見方は、AIコードの検出方法を増やす対策とは別の論点です。提出前に人間が仕様、変更理由、テスト結果を説明できるかを確かめ、説明できない成果物を上流へ流さない仕組みを作ることが、メンテナー負荷を抑える直接的な対策になります。
禁止の範囲と未確定部分｜コード・レビュー・検索を分けて確認
現行ファイルが明記する禁止対象は、qgis/qgisリポジトリへのLLM・AI・エージェント支援コード貢献です。文書、議論、検索、IDE補完、翻訳、レビュー、監査、セキュリティ用途について、現行ポリシーに具体的な例外条項はありません。だからといって、禁止されないと断定することもできません。
その後の動きは、現行ルールと分けて読みます。QEP429のPR #388は、実績のある貢献者にAI支援コードの例外を認める提案ですが、2026年10月14日時点で未マージです。QEP430のPR #389は、QGIS組織内の全リポジトリの文章へAI生成物の禁止を広げる提案として公開されていますが、こちらも未マージです。
つまり、提案が並んでいることは、現行ルールがすでに広がったことを意味しません。上流PRの準備では、現行ファイルの文言と、議論中の提案を別の情報として記録してください。「人間が最後にレビューした」「翻訳だけに使った」といった社内判断だけで投稿可否を決めず、対象リポジトリの窓口へ確認するのが安全です。
設計意図を誰が説明できるかという観点は、AI時代の技術的負債と設計意図を考えるときにも共通します。ここで大切なのは、QGISの現行ポリシーに書かれていない行為を「許可」と読み替えないことです。
ポイント
現行QEP408、未マージのQEP429、未マージのQEP430は別々に扱います。現行ルールの対象外に見える行為ほど、プロジェクト側の最新版ポリシーと確認窓口を先に確認します。
OSSを使う・貢献する企業が確認すること｜上流ルールと社内統制を分離
QGISを利用する企業は、社内でAIを使うかどうかと、QGISへ何を返すかを同じ判断表に置かないことが重要です。利用だけなら社内のセキュリティ・知財ルールが中心ですが、上流リポジトリへのコード貢献にはプロジェクトの参加条件が加わります。
上流PRを出す前に、次の順番で確認すると担当者の判断がぶれにくくなります。
- 貢献先：利用、社内フォーク、プラグイン、
qgis/qgisへの上流PRを分ける。 - AIの関与工程：生成、補完、レビュー、翻訳、検索など、何に使ったかを記録する。
- 最新版の規約：対象リポジトリのポリシーファイル、PRテンプレート、確認窓口を調べる。
- 説明可能性：変更理由、設計、テスト、保守方法を担当者が自分の言葉で説明できるか確認する。
- 権利と記録：ライセンス、著作権、レビュー記録、承認者を社内に残す。
QGISの貢献者要件でも、開発プロセスとコーディング文書を理解し、コードがライセンスと両立し、権利上の問題を生じないことが求められます。社内のAI利用ルールを整えるときは、生成AIの回答を丸写ししない組織運用の考え方を、OSSの提出前確認へつなげるのが実務的です。
自律エージェントを開発フローへ組み込む企業は、権限や監査ログの境界も分けて設計します。シャドーAIエージェントの統制で扱うような検出・承認の仕組みは、QGISのポリシーを自動的に満たすものではありませんが、誰が何を実行したかを残す社内基盤になります。
ポイント
社内のAI利用許可と、OSSプロジェクトが受け入れる貢献は別のゲートです。貢献先、AIの関与工程、最新版ポリシー、説明可能性、権利確認を記録してから上流PRの可否を判断します。
よくある質問
Q. QEP428とPR #387、QEP408はどう違いますか？
PR #387のタイトルが「Add QEP428」で、マージ時に既存のQEP408ファイルを更新しました。PR番号とQEP番号、更新されたファイル名は別のものです。
Q. QGISはAIの利用をすべて禁止したのですか？
現行文言が明記するのは、qgis/qgisリポジトリへのLLM・AI・エージェント支援コード貢献です。全ツール利用や全文章の禁止と断定せず、明記されない行為はプロジェクトへ確認します。
Q. 人間がコードをレビューして開示すれば投稿できますか？
旧QEP408では人間による理解・レビューと開示が許容条件でしたが、現行ポリシーは対象コード貢献を認めない文言に変わりました。開示だけで許可されるとは扱いません。
Q. QGISを使う企業は何を確認すべきですか？
利用だけか上流貢献か、対象リポジトリ、AIが関与した工程、最新版ポリシーと確認窓口、ライセンス・権利・レビュー記録を分けて確認します。現行ルールが社内フォークやすべてのプラグインへ自動適用されるとは扱いません。
まとめ
QGISはPR #387のマージ後、QEP408でqgis/qgisへのAI・LLM・エージェント支援コード貢献を認めない方針を示しました。旧方針のように、利用を開示して人間がレビューすればよいという整理ではありません。
一方、未マージのQEP429とQEP430では、信頼できる貢献者への例外や、文章への適用範囲が議論されています。企業は現行ポリシーと提案段階の内容を分け、上流へ返す前に対象リポジトリの最新版ルール、AIの関与工程、権利と説明可能性を確認してください。
ポイント
QGISの事例が示すのは、AI利用の可否をツール名だけで決めず、貢献先・関与工程・レビュー負荷・権利確認をプロジェクトごとに分けて管理する必要性です。
関連記事
- AI生成コード時代のコードレビューを解説｜開発現場のボトルネックと対策
- 生成AI活用の質を解説｜回答の丸写しを防ぐ組織運用のポイント
- 「問題はAIのコードではなく設計意図を誰も知らないこと」を解説｜AI時代の技術的負債
- 生成AIの使いこなし格差を解説｜組織で整える運用ルールと研修のポイント
- シャドーAIエージェント対策を解説｜検出・統制の進め方
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。