GodotのAIコントリビューション方針は何を求めるか。PR提出と社内レビューの判断表
2026年6月30日のGodot Foundation発表と現行の貢献ガイドを分けて確認し、AI支援コードをOSSへ出す前の受け入れ判断と、社内で誰が説明・修正・保守を担うかを整理する。
GodotへAI支援コードを提出するとき、見るべきなのは「AIを何％使ったか」だけではない。2026年7月18日時点の現行ガイドは、AI利用を推奨せず、全面的にAIが作った貢献を禁じたうえで、提出者がコードを理解し、説明し、テストし、AIを使った範囲を開示するよう求めている。一方、Godot Foundationが6月30日に示した、より厳しい制限の一部は改定予定として書かれている。
方針の中心はAIコードの品質一般論ではなく、負担の非対称性にある。AIでPRを作る費用が下がっても、受け取る側のレビュー、投稿者を育てる教育、マージ後の保守は自動的には安くならない。OSSへ出す開発者は「生成できたか」ではなく「人が責任を引き受けられるか」を提出条件に置く必要がある。社内チームにも同じ判断軸を応用できる。
作成コストだけが下がると、誰の待ち行列が伸びるのか
Godot Foundationの2026年6月30日発表は、未処理PRの背景として、適格なレビュー担当者が少なく、レビュー作業が重く、流入に追いつけないことを挙げた。さらに、AIでPRを作る労力は下がり件数が増えた一方、レビュー作業量とレビューできる人数は変わっていない、と説明している。
もう一つの論点が教育である。人へのレビューは、新しい貢献者が学び、将来のメンテナーやレビュー担当者になる可能性へ時間を投じる行為でもある。フィードバックを機械だけが吸収し、責任を持つ人の理解が深まらなければ、その投資が次のレビュー能力につながりにくいというのがFoundationの問題提起だ。
発表から切り分けられる4つの費用
- PR作成：AIを使う提出者側で下がりやすい。
- レビュー：差分の正しさ、互換性、テストを確かめる受け手側に残る。
- 教育：説明を受けた人が理解を深め、次の担い手になるときに回収できる。
- 保守：マージ後の不具合修正、設計変更、後方互換への対応として将来へ移る。
最後の保守費用はAI特有ではない。Godotのエンジン貢献のベストプラクティスも、追加コードは場所を取り、維持が必要になるため、現実に存在する問題から始め、実装前に他の開発者と議論する考え方を示している。AIが差分を速く作れることは、変更を上流へ入れる理由そのものにはならない。
現行の公開規則と、6月30日に示された改定予定
現在公開されているPR規則には、理解して説明できるコードだけを出すこと、十分に理解していない部分は厳格にテストして説明へ記すこと、AI支援を含め自分が完全に書いていない部分を開示することがある。AI利用は非推奨で、全面的にAIが作った貢献は禁止されている。生成物の校正・改善と、動作する状態までのテストも提出者へ求めている。機械翻訳は利用でき、1行のコード補完は開示不要と明記されている。
これに対し6月30日の発表は、追加・明確化する方針として、実質的な量のAI生成コードを認めず、人がコードを書くこと、AI支援を補完・正規表現・検索置換などの単純作業へ限ること、AIを使った場合はPRの議論で開示することを挙げた。また、人同士の課題・PR・提案でAI生成文を使わないこと、新規貢献者が許可なく新機能や大規模リファクタリングを始めないことも改定予定である。ここでいう新規貢献者は、マージ済みPRが3件以下の人と定義されている。
同じ発表によれば、自律AIエージェントやvibe codingはすでにGitHubリポジトリからの自動BAN対象で、この運用は継続予定である。全PRを人がレビューして承認してからマージする運用もすでに行われており、文書上さらに明確にする予定とされる。将来項目を現在の公開ガイドに書かれた規則として混同しない一方、提出直前には両方を読み直したい。
OSS提出の受け入れ判断表
| 提出ケース | 2026年7月18日時点で確認できる状態 | 提出側の判断 |
|---|---|---|
| 1行のコード補完 | 現行ガイドでは開示不要。改定予定でも単純作業の例に補完がある。 | 人が意味を説明し、周辺を含めてテストできるなら受け入れ候補。 |
| 限定的なAI支援を人が修正・検証 | 現行ガイドは非推奨だが、開示、校正、改善、テストを求める。改定予定は許容範囲をさらに狭める。 | 使ったファイルと作業を開示し、実質的なコード生成に当たるかをメンテナーへ事前確認。 |
| 関数群や機能の大半をAIが生成 | 全面AIの貢献は現行でも禁止。実質的な量のAI生成コードも禁じる方針が発表済み。 | そのまま提出しない。人が問題と設計から実装し直せないなら上流化を止める。 |
| 自律エージェントやvibe codingによる提出 | Foundationは、すでに自動BAN対象で今後も継続すると説明。 | 提出しない。 |
| AIが書いたPR説明・レビュー返信 | 人同士の通信でAI生成文を禁じるのは改定予定。機械翻訳は現行でも利用でき、改定後も人が原文を書いた場合は許容予定。 | 説明と返信は本人が書き、理解を示す場として扱う。 |
| マージ済みPRが3件以下で新機能・大規模改修 | 明示的許可を求める制限は改定予定。現行資料でも、まず問題を議論し単純な修正から始める導線がある。 | 実装前に課題・提案で相談し、メンテナーの許可を得る。 |
社内レビュー制度では「生成率」より責任の流れを設計する
Godotの規則を各社へそのまま移す必要はない。ただし、レビュー費用が別の人へ移るという構造は社内でも同じである。Desync編集部の提案は、AI利用の有無を一つのラベルにせず、提出者、レビュー担当者、教育担当、保守担当の責任を分けて記録することだ。
- 提出者：変更の目的、AIを使った範囲、テスト結果、既知の限界を説明し、差分の各部分へ答えられる。
- レビュー担当者：互換性、失敗条件、セキュリティ、設計整合を確認する。提出者が説明できないコードの再構築役にはしない。
- 教育担当：指摘を人が理解して修正し、次回は同じ判断を自力で行えるかを見る。
- 保守担当：不具合発生時に直す人、監視期間、差し戻し条件をマージ前に決める。
この分け方なら、AI支援の速度を活かしつつ、レビュー時間を無制限に外部化しにくい。受け入れ基準も「AIを使ったら拒否」ではなく、「責任者が説明できない」「テスト証拠がない」「将来の所有者がいない」といった観測可能な条件へ落とせる。
提出前チェックリスト
- 解こうとしている問題と、関連するissue・提案・利用例を示したか。
- PRを一つの自己完結した変更へ絞ったか。
- AIを使ったファイル、工程、生成・補完・翻訳の別を具体的に書けるか。
- 提出者が差分を行単位で説明し、別の実装案を比較できるか。
- 正常系、失敗系、互換性、回帰を人が実行して結果を残したか。
- 生成コードを含む外部素材の著作権・特許・ライセンスを確認したか。
- レビュー指摘へ本人が答え、修正理由を説明する体制か。
- マージ後の修正担当と、必要なら差し戻す条件が決まっているか。
提出直前に行うこと
Godotへ出す人は、まず現行のPR規則を読み、6月30日の発表で改定予定とされた範囲も確認する。1行補完を超えるAI支援があるなら、使用箇所と本人が行った修正・テストを説明できる形にする。新規貢献者が新機能や大規模改修を考えている場合は、コードを書く前にメンテナーへ相談する方が、作成側とレビュー側の両方の時間を守りやすい。
適用範囲と再確認点
この記事はGodot FoundationとGodotの公開資料を、2026年7月18日に確認した整理である。6月30日の発表には改定予定の項目が含まれ、公開ガイドは今後更新され得る。Godotの運用を他のOSSや社内規則へ自動的に当てはめるものでもない。実際のPRでは、対象リポジトリの最新ガイドとメンテナーの指示を正本にする。
参照した情報源
一次情報、補助報道、コミュニティ観測を役割別に表示しています。
2026年6月30日の公式発表。PR作成費用だけが下がりレビュー作業量とレビュー人数は変わらないという非対称性、レビューを通じた新規貢献者の教育と将来のメンテナー育成、現在運用中と説明された自律AI・vibe codingの自動BANと人によるマージ承認、今後のAIコード・人同士の通信・新規貢献者に関する改定予定を確認。
2026年7月18日時点の現行公開ガイドを確認。理解・説明できるコードだけを提出すること、AI支援箇所の開示、全面的にAIが作った貢献の禁止、生成物の校正・改善・テスト、機械翻訳の許容、1行コード補完の開示除外、著作権・特許・ライセンス確認の記述に対応。ページ上では今回の強化策すべての発効日を確認できないため、6月30日の改定予定と分けて扱った。
追加コードには将来の保守が伴うこと、実在する問題を先に確認すること、実装前に他の開発者と議論すること、保守しやすさを重視する設計方針を確認。AI固有の規則ではなく、受け入れ・保守判断の背景資料として使用。