僕がGodotのコントリビューターになれた話

結論から、画像で示していくスタイル

たった6行に、全世界への愛を詰めた

2026年7月、僕の書いたコードがGodot Engineにmergeされた。
正確には、2本のPull Requestがmergeされた。
ひとつは、AndroidでSoC名を取得できるようにする変更。
もうひとつは、iPhone 17eのSoC名と画面密度をGodotの対応表へ追加する変更だった。
Android対応は6行追加、1行削除。
iPhone 17e対応は2行追加、1行削除。
世界的なゲームエンジンへの貢献としては、拍子抜けするほど小さい。
でも、その数行に、僕は全力だった。

なぜなら、僕はGodotを愛していたからだ。

UnityもCocos2d-xも触ってきた

これまで、UnityやCocos2d-xを触ってきた。
どちらも強力なゲーム開発環境だし、それぞれから多くのことを学んだ。

ただ、僕が本当に愛したゲームエンジンはGodotだった。

機能が多いから。
無料だから。
軽いから。

そういう比較表に載る理由だけではない。

Godotには思想がある。
誰かの商売道具を借りているのではなく、世界中の人が同じエンジンを持ち寄り、少しずつ良くしていく。
ソースコードを読める。
内部の仕組みを調べられる。
気に入らないところがあれば、自分で直せる。

そして、その修正を世界へ返せる。

僕は哲学が好きだ。

だから、思想を持ったソフトウェアを愛せる。
そして、愛せるものだからこそ、たった6行のために、全力になれる。

自分が困ったので、Godotの中を掘った

きっかけは、Android端末のSoCをGodotから取得したかったことだった。
端末に搭載されたSoCやNPUによって、実行する処理を切り替えたかった。
Godotには、CPU名を取得するためのAPIがある。

var processor_name = OS.get_processor_name()
print(processor_name)

ところが、Androidで実行すると空文字列が返ってきた。

""

Pixelでも、REDMAGICでも、POCOでも空文字列だった。
自分の使い方が間違っているのかと思い、Godot本体のコードを調べ始めた。
すると、Windows、Linux、macOSなどにはプラットフォーム固有の実装がある一方、Androidには実装がなかった。

Android 12以降なら、システムプロパティのro.soc.modelからSoC名を取得できる。
実機で確認すると、きちんと値が返ってきた。

Pixel 10a    -> Tensor G4
REDMAGIC 9   -> SM8650
POCO         -> MT6899

そこで、Issue #120816を作った。

再現方法、調査したコード、実機の結果、考えられる修正方法を書いた。
ここまでは、普通のバグ報告だった。
でも、僕にとってはIssueを立てて終わりにはできなかった。

もちろん、再現可能なIssueを書くこと自体も立派なOSS貢献だ。
ただ、僕自身が「愛している」と言うなら、問題を見つけて誰かに渡すだけでは足りなかった。
直せそうなら、自分で直したかった。

最初のPRは閉じられた

最初に出したPR #120850では、Android向けの実装を追加した。

ro.soc.modelを取得し、古いAndroidでは/proc/cpuinfoへフォールバックする、少し大きめの実装だった。

このコードとPRの文章を作るために、Claude Codeを使っていた。
AIを使ったことはPRにも開示していた。
自分では、実装内容を確認し、3台の実機でもテストしていた。

だから、問題ないと思っていた。

しかし、Godotのルールでは、AIによるコントリビューションは非推奨であり、AIが全面的に生成した貢献は禁止されていた。

さらに、PRを出すわずか2日前の2026年6月30日、Godot Foundationはコントリビューション方針の変更を発表していた。

Godotには大量のPRが集まり、少数のメンテナーではレビューしきれない状態になっていた。

AIエージェントやAI生成コードによってPRを作るコストだけが下がり、レビューする人間の負担は増えていた。

そのため、

• 自律型AIエージェントによる貢献
• AIが生成した大部分のコード
• 人間同士の会話に使われるAI生成文

を認めない方針が、明確に打ち出された直後だった。

僕は、その記事を知らなかった。

そして、最悪に近いタイミングで飛び込んだ。

さらに、自動化が事故を起こした

その後、PR #120854が作られた。

閉じられたPRとほぼ同じコードで、PRテンプレートも正しく使われておらず、AI利用の開示も欠けていた。

外から見れば、

AI生成だと指摘されて閉じられたコードを、AI利用の説明だけ消して出し直した

ようにしか見えない。

当然、厳しく指摘された。

実際には、僕の環境でClaude CodeがPR作成まで自動化された状態になっており、意図しないPRを作ってしまった。

僕は動作していたClaude Codeのセッションをすべて停止した。

ただし、これはAIのせいではない。

僕のGitHubアカウントから行われた操作は、僕の責任だ。

便利な道具が勝手に走ったからといって、他人の庭へ突っ込んでよい理由にはならない。

メンテナーからは、次に同じことをすれば、今後コントリビューションできなくなる可能性があるとはっきり警告された。

それでも、対話を打ち切らず、僕が責任を持ってやり直すことを信じてくれた。

僕は最初からやり直した。

自分の手で書いたら、6行になった

新しく作ったPR #120896では、コードもPRの説明も、自分で書いた。

最初のPRにあった、古いAndroid向けのフォールバックや複雑なエラー処理をいったん捨てた。

本当に必要な変更だけに絞った。

String OS_Android::get_processor_name() const {
    return get_system_property("ro.soc.model");
}

ヘッダーファイルにoverrideを追加し、ドキュメントを更新した。

最終的な差分は、3ファイルで6行追加、1行削除だった。

3台のAndroid端末でテストした。

Pixel 10a       -> Tensor G4
Nubia NX769J    -> SM8650
Xiaomi端末      -> MT6899

レビューでは、ドキュメントの表現、不要なエラー処理、コミットのまとめ方などを教えてもらった。

指摘を受けて直す。

分からないところは分からないと言う。
自分が書いたコードを、自分の言葉で説明する。
今思えば、これがコントリビューションだった。

コードをGitHubへ置くことではない。
人間同士で、そのコードをGodotの一部にしていくことだった。

2026年7月5日未明、日本時間でPRはmergeされた。

メンテナーから、

Congratulations on your first merged contribution!

という言葉をもらった。

僕はコメントにこう書いた。

皆さんの親切と指導のおかげで、本当に愛しているGodot Engineへ貢献できたことを誇りに思います。

あれは社交辞令ではない。

本当に、そう思っていた。

もうひとつ、1行のバグを見つけた

Android版を検証している途中、iPhone 17eでもOS.get_processor_name()が空文字列になることに、気づいた。

今度はiOS全体の実装がないのではなかった。
Godotには、iPhoneのモデル識別子からSoC名を引く対応表がある。
しかし、iPhone 17eの識別子であるiPhone18,5が、まだ登録されていなかった。

必要だった修正は、SoC対応表への1項目追加だった。

{ { "iPhone18,3", "iPhone18,5" }, "Apple A19" },

レビューで、画面密度の対応表にも追加が必要だと教えてもらい、そちらも修正した。
このPR #120853もmergeされた。

差分は、2行追加、1行削除だった。

本気でOSSを使うと、こういうことが起きる。
巨大な設計を変えなくてもいい。
何千行ものアルゴリズムを書かなくてもいい。

新しい実機で試したら、対応表に1行足りなかった。
毎日使っていたら、ある関数だけ空文字列を返した。

そんな小さな穴が、世界中で使われているソフトウェアにも残っている。

メンテナーに感謝している

PR上では、厳しい言葉も受けた。
ただ、僕はメンテナーを恨んでいない。
むしろ、本当に感謝している。

彼らは僕を追い出すこともできた。
会話を打ち切ることもできた。

それでも、間違いを指摘し、ルールを説明し、僕が自分で書き直したPRをレビューしてくれた。

後日、厳しく指摘したメンテナーの方から、

振り返ると、自分は不公平で厳しすぎたと思う。謝りたい

というコメントをもらった。

僕は、

気にしないでください。
厳しくても、最後まで面倒を見てくれました。
チームがAIに疲れているという記事も読みました。
タイミングが悪かっただけです。

と返した。

僕が知らなかったルールを破ったことと、Godot側がAI生成コントリビューションに疲弊していたこと。
それらが、最悪の角度で衝突した。

でも、最後に残ったのは対立ではなかった。

コードと、対話と、感謝だった。

OSSを本気で使ってみてほしい

「OSSに貢献する」と聞くと、難しく感じるかもしれない。

• 英語が必要
• 巨大なコードベースを理解する必要がある
• 高度なアルゴリズムを書かなければならない

僕も、どこかでそう思っていた。
でも、違った。

OSSを本気で使ってみてほしい。
自分の仕事や作品で、限界まで使ってみてほしい。

すると、1行で直るバグが見つかる。

対応表に名前がひとつ足りない。
あるプラットフォームだけoverrideがない。
戻り値が空になる。

ドキュメントと実装が少しずれている。

コントリビューションは、「貢献できそうなIssue」を探すところから始まるとは限らない。

自分が愛して使い倒した結果、見つけてしまうものでもある。
愛しているから、違和感に気づく。
愛しているから、ソースコードまで掘る。

愛しているから、Issueを書いて終わりにせず、たった1行を直しに行く。

僕にとってOSSへの貢献は、技術力の証明ではなかった。

世界中から受け取ったものへ、少しだけ返す行為だった。

そして今日も、Issueを投げた

2026年8月1日。

僕は今度はHugging FaceのTransformers.jsへ、KV Cacheのメモリリークに関するIssueを投げた。

ChatterboxをWebGPUで繰り返し実行すると、生成のたびにGPUメモリが増え続ける。

調査したところ、呼び出しごとにKV Cacheが破棄されず、最大で約24GBまでGPUメモリが膨らんでいた。
max_new_tokens: 256では、生成1回につき約120MiBずつ増えていた。

Issue #1734として、再現コード、環境、計測結果、原因と思われるコードパスまで書いた。

ただ、僕は自分で書いた。

Issueを起こすだけなら、まだ愛ではない。

これは、愛の入口だ。

次にコードを読んで、直せるのか。
レビューする人の時間を尊重できるのか。
自分の変更を、自分の言葉で説明できるのか。

Godotで教えてもらったことを、次のOSSでも続けられるのか。

それは、これからの僕次第だ。
世界には、まだ誰も直していない1行がある。
そして僕は、多分また、それを見つけに行く。

閑話休題

ちょっと、僕は、メイドインアビスのボンドルドの気持ちがわかった、気がする。

「愛です 愛ですよナナチ」

OSSという、アビスに飛び込みましょう。
そして、君も黎明郷になろう！

参考文献:

• メイドインアビス: https://miabyss.com/

End of story.

If u want to knew my story, plz search the issues.
Every-body laughed at me.
But, It was my presure.