AI でコードを書ける時代になっても、オープンソースのコア開発者たちは思ったほど AI を歓迎していない。Godot は 2026 年 6 月、長年メンテナを務めてきた Rémi Verschelde が「Godot は vibe-coded ではない」と表明し、ガイドラインで AI 使用の許容範囲をかなり狭く線引きしていることを再確認した。自分は副業で AI を運用していて、コードを AI に書かせて納品物に混ぜたいエンジニアと、それを受け取る OSS メンテナの温度差を何度も見てきた。今回の Godot の表明は、その温度差を一番はっきり言語化した事例だと思っている。
結論から書く。Godot が線を引いたのは「AI を使ったかどうか」ではなく、「人間が責任と著作権を担保できる粒度で使ったか」だ。翻訳・単行のコード補完・デバッグ補助・既存コードへの外科的な修正は通すが、丸ごと生成された PR (Pull Request、変更の取り込み依頼) は弾く。3700 件のうち AI 開示付きで通ったのは 47 件、約 1.27% にとどまる。受託や個人開発で AI を稼ぎに変えたい人ほど、この境界線は読み取っておく価値がある。
オープンソースゲームエンジンが「AI支援は一部容認」と明言した意味
Godot は MIT ライセンスで公開されている無料のゲームエンジンで、Unity の代替先として個人開発者やインディースタジオに広く使われている。バックには W4 Games という商用支援会社もあり、Verschelde はその共同創業者でもある。つまり今回の声明は、ホビーコミュニティの愚痴ではなく、商用導線まで含めた基幹 OSS の運営判断として出ている。
2026 年 2 月の時点で、Verschelde は「AI slop な PR がメンテナを圧迫している」と発信していた。slop は「中身の薄い、雑な生成物」を指すスラングで、英語圏の OSS 界隈ではこの 1 年ほどで一気に一般化した言葉だ。今回 Verschelde が出したコメントは、その状況を踏まえて「Godot 全体が vibe-coded (= 雰囲気で AI に書かせたコードの寄せ集め) になっているわけではない」と否定する文脈だった。
注目すべきは、Verschelde が AI を全否定していない点だ。「AI が役に立つことは認める」「ただし人間の労力の方が良い貢献に繋がると確信している」「もし AI を使うなら、生成物を必ず校正・改善した上で、何に AI を使ったかを開示してほしい」と書いている。AI 禁止ではなく、AI 込みの責任設計だ。これは個人開発者が普段の作業で AI を使う時にも、そのまま当てはまる規律だと思っている。
Godotが線引きした「許容するAI使用」と「拒否するslop PR」の境界
ガイドラインの読み解きでよく誤解されるのが、「OSS は AI 禁止」という雑な要約だ。Godot のガイドラインを丁寧に読むと、許容と拒否の境界はかなり具体的に書かれている。
翻訳と単行コード補完は通す、丸ごと生成は弾く
Verschelde 自身が Bluesky のスレッドで挙げた許容範囲は次の 4 つだ。
・翻訳作業
・単行のコード補完 (1 行レベルの autocomplete)
・デバッグ補助 (エラーを AI に投げて原因を探る)
・既存コードへの外科的な修正 (surgical changes)
逆に拒否されるのは、ChatGPT・Claude・Grok などで「丸ごと生成された」コントリビューションだ。これは PR 単位で禁止と明言されている。「some AI assistance」の「some」が「重要な負荷を担う語」だと Verschelde はわざわざ書いている。曖昧に「AI 使ってもいいよ」と言っているのではなく、「ここまでなら通すが、これを超えると弾く」という閾値が設定されている。
この線引きは、AI を実装現場で使う側にとってかなり重要だ。「コードを書く」工程の中で、AI が出してきた成果物を人間がどこまで読み、検証し、テストし、責任を引き受けられるかが境界になっている。1 行補完なら人間が読んで判断できる。バグ調査で AI にエラーログを投げて当たりを付けるのも、最終的に直すのは人間だ。一方、関数まるごと、ファイルまるごと、機能まるごとを AI に生成させて投げ込まれると、レビューする側が中身を理解しないまま責任を負わされる。境界はそこにある。
3700件中47件がAI開示付き、その実態
Verschelde が出した数字も面白い。直近 2 リリースサイクルで Godot にマージされた PR のうち、AI 開示付きで通ったのは 47 件。全体 3700 件のうち約 1.27% だ。さらにそのうちのいくつかは、Verschelde 自身が技術の影響を理解するために試した PR だという。
この数字をどう読むか。AI を毛嫌いしているわけではない (現に 1% 強は通している) し、AI 開示付きの PR は「機械的に信用度を一段下げて」より厳しくレビューされる、と明言されている。新規コントリビュータからの AI 開示付き PR は特に注意深く見られるという。
つまり Godot のスタンスは「使ってもいいが、使ったと正直に書け。書いたら厳しくレビューする」というものだ。AI を隠して PR を投げる行為が一番ペナルティが大きい。これは受託・副業で AI 活用を売り物にしている人にとっても、クライアントとの信頼設計のテンプレートになる態度だと思う。
「責任を取れるか」と「著作権を主張できるか」がコントリビュータ選別の基準になった
Verschelde の発言で一番強い言葉は、PR を通す条件として並べられた次の 5 項目だ。
・自分が submit したコードを理解している
・テスト済みで動作することを確認している
・実装に確信がある
・マージ後も自分でメンテナンスを手伝う意思がある
・そのコードに対して著作権を主張できる
最後の「著作権を主張できる」が、AI 生成物を弾く法的な根拠になっている。AI が大半を書いたコードについて、コントリビュータ本人が著作権を持っていると主張できるか、という問いに正直に答えると、grossly な vibe-coding (雰囲気生成) は通せない。Verschelde は「That precludes any substantial vibe-coding」と明言した。
ここで効いているのは、責任と権利のセットだ。OSS の世界では、PR を投げるという行為が「自分はこのコードに責任を持ち、ライセンス下で自由に再配布される権利を譲渡できる」という宣言とセットになっている。AI 生成物はその宣言と相性が悪い。コードの出自が不透明で、メンテナンスを引き継ぐ覚悟もない PR は、見た目が動いていても受け取れない。
副業で AI を使ったコード納品をしている人なら、この観点はクライアント側の不安と完全に重なる。「AI に書かせたものを納品して、後から不具合が出たら誰が直すのか」「ライセンス的に問題ないと言い切れるのか」という問いに、Godot の 5 項目はそのまま答えになっている。納品物に AI 寄与を明示し、自分が読み切ってテストし、保守を引き受ける範囲だけを請ければ、信頼は崩れない。
AI支援開発を仕事にする側が読み取るべき3つの実務シグナル
Godot の声明から、AI でものを作って稼ごうとしている側が拾うべきシグナルは 3 つあると思っている。
1 つ目は、「AI 開示は減点ではなく加点に変わる」というシグナル。Godot は AI 使用を隠す行為を最も嫌っている。逆に開示すれば、厳しいレビュー前提だが通る道はある。これは受託案件でも同じ流れがすぐ来る。「この機能はここまで AI 補助で、ここからは自分の判断で書いた」という粒度で開示できる人は、ブラックボックスで納品する人より信頼を積みやすい。
2 つ目は、「surgical changes (外科的な修正) 」という言葉が境界線になるというシグナル。既存コードを 1 箇所だけ AI で直す、関数 1 つだけ補完させる、エラーログから当たりを付ける、こういう粒度の使い方は OSS でも商用でも今後広く許容される。一方、ゼロから機能を AI に生成させる依頼を受けてそのまま納品する仕事は、レビューハードルが急上昇する。受託で AI を使う場合、「どこを surgical に使うか」の設計力が単価を決めるようになる。
3 つ目は、「OSS が立てた基準が商用の SLA に降りてくる」というシグナル。Godot のような基幹 OSS が AI ポリシーを明文化すると、その下流で動く商用案件のレビュー基準にも波及する。すでに大手 SaaS 各社は AI 生成コードの開示と監査を契約に組み込み始めている。Godot の 5 項目 (理解・テスト・確信・保守・著作権) は、汎用的な納品物チェックリストとして使える形になっている。AI で速く作る側は、この 5 項目に対して自分の作業フローが答えを返せるかどうかを自己点検しておくと、後から揉めにくい。
この整理から、AI コントリビュータの責任設計を理解できるエンジニアへの受託案件、たとえばゲームエンジン拡張・ツール内製・OSS への代理コントリビュートなどは、今後人手不足になりやすい領域だ。AI を使えるだけでなく、「AI 使用を明示しながら品質を担保する」運用を回せる人は、フリーランスでも社内でも武器になる。
まとめ
要点を 3 行で整理する。
・Godot は AI 全面禁止ではなく「翻訳・単行補完・デバッグ・外科的修正」までを許容し、丸ごと生成 PR は拒否する境界を引いた
・コントリビュータに求める 5 条件 (理解・テスト・確信・保守・著作権) は、受託や副業の納品物にもそのまま転用できるチェックリストになる
・AI 使用の開示は減点ではなく信頼設計の入口になる。隠す側がペナルティを受ける流れは商用にも降りてくる
AI に任せられる範囲を広げるより、AI を使ったと正直に書ける範囲を整える方が、これからの稼ぎ方には効く。地味だけど効くんですよ。こういう線引きを先に決めておく作業が。
参考
【PR】関連ツール・サービス
個人開発の作業環境を整える時にレンタルサーバーが欲しくなったら、XServerショップ は手堅い選択肢です。
プロジェクトや作品の発信用にドメインを取るなら、.com/.net ０円〜 を覗いてみるとコスト感がつかめます。
ゲーム開発・AI 系の技術書や資料を電子書籍で揃えたい人には、DMMブックス が幅広くてセールも回ってきます。
発信は セレネのX (@selene_nyx_ai) でも流しています。AI × ものづくりの実装事例を追いたい人はぜひ。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
Computer Useやアーティファクト自作からMCPサーバー構築まで Claude AIエージェント開発入門
Claude を軸に AI エージェント開発を学べる入門書です。Computer Use やアーティファクト自作、MCP サーバー構築まで扱い、AI をコード生成に取り入れたい開発者の足場づくりに役立ちます。
Unity 6 に対応したゲーム開発の教科書です。エンジン操作からスクリプティングまで段階的に解説されており、AI 任せにせず自分の手で実装を理解したい人に向いた一冊です。
コメント