オープンソース貢献、AIでポチッとやってもいいですか？

AI 時代にオープンソースへ貢献するということ

はじめに

こんにちは、オープンソースが好きな開発者のイ・スンジェです。自分の書いたコードや作ったものが誰かに影響を与えるのが好きで、正直その楽しさのために開発していると言っても過言ではありません。

今日は、その楽しさを初めて知った話と最近もらったフィードバック、そしてそのフィードバックが残した考えを書いてみようと思います。

オープンソースを愛する理由

初めてのオープンソース貢献は exercism でした。開発の勉強を始めたばかりの頃に見て学んだサイトなので、いつか受け取った分を返したいと思っていて、2024年11月に Java トラックの Parallel Letter Frequency 問題の解法アプローチをまとめた PR #2863 を出しました。拙い英語に初めて見る貢献ルールまで重なり、何度もフィードバックを受けてようやくマージされました。

その後サイトを開いてみると、書いたコードと説明がそのまま載っていて、コントリビューターの欄には自分の名前が刻まれていました。学生だった当時はそれがあまりに嬉しく胸がいっぱいで、しばらく何度も見に行ったのを覚えています。

この経験を活かして、サークル goorm-thon UNIV の世宗大学×建国大学合同テックトークでオープンソースを読む力を鍛えるというテーマで発表したこともあり、exercism の記憶が今も残っていて、いまもオープンソースに貢献し続けています。

LLM による貢献に意味はあるのか？

オープンソースにもっと頻繁に貢献したくて、一時期は使っているライブラリやフレームワークごとにエージェントとスキルを置き、定期的にチェックして欠陥を見つけては PR を出していました。そのおかげで実際に多くの貢献ができ、電子政府標準フレームワークだけで 22 件がマージされ、Spring Data JPA や jjwt、LangChain4j にも PR を出しました。ところが PR が積み重なるにつれ、いつからか、なんとなくモヤモヤするようになりました。

そんな中、Spring Boot に出した PR #51468 でこんなフィードバックをもらいました。

Did you use AI to produce the description? Regardless, it's unnecessarily verbose for a one-line change to main code and includes lots of details that are already available elsewhere.wilkinsona · Spring Boot メンテナー

PR の説明を AI で書いたのかと尋ねたうえで、どちらにせよコード一行の変更にしては無駄に長く、ほかの場所にすでにある内容まで含んでいるという指摘でした。

I use an LLM to look for bugs in projects I use, then check the bug is real and run the tests myself. … I still think it is good for open source, but I would like to know if you agree. Are LLM pull requests more tiring than helpful now? Or is it still worth it if it brings in more contributors?masiljangajji · 私

私は普段使っているプロジェクトで LLM を使ってバグを見つけて直していると答え、こうした貢献がオープンソースをより良くすると期待していると付け加えました。そして、LLM で作った PR が実際に役立っているのか、貢献のハードルが下がってコントリビューターが増えた今をメンテナーとしてどう見ているのかを尋ねました。

返ってきた答えはこうでした。

As we have limited resources, we much prefer dealing with bugs that are causing real-world problems. The value of fixing these is much higher than fixing something that may technically be a bug but isn't have a negative impact on anyone.wilkinsona · Spring Boot メンテナー

リソースが限られているので、現実に問題を起こしているバグのほうをはるかに好み、技術的にはバグかもしれなくても誰にも害を与えないものを直すことにはあまり意味がない、ということです。

LLM そのものを責めることはなく、現実の問題を直したのなら何を使っても歓迎で、うまく仕上げれば LLM が関わったかどうかもわからないと言いました。ただ、大事なのはコントリビューターの数ではなく貢献の質だとして、こう付け加えました。

The best way to contribute to an open source project is to use it in your day-to-day work in real-world situations. You can then propose bug fixes and enhancements that make your day-to-day work easier, benefiting both you and the rest of the community.wilkinsona · Spring Boot メンテナー

最良の貢献方法はそのプロジェクトを実際の業務で毎日使うことで、そのうえで自分の仕事を楽にしてくれる修正や改善を提案すれば、みんなの得になるという話でした。

私も LLM で問題を見つけてコードを改善することが悪いとは思いません。LLM が見つけたバグであっても、それを判断して解決策を取り入れるには、やはりエンジニアリング上の判断が必要ですから。それでも、すっきりしない気持ちは消えませんでした。

履歴書のためのオープンソース

このフィードバックを受けて、じっくり考えました。コードを改善したりオープンソースを理解したりするのは今でも楽しいし、PR がマージされれば嬉しくもあります。なのに、どうしてこんなにモヤモヤして息苦しかったのでしょうか？

悩んだ末にたどり着いた結論は、履歴書を埋めるための貢献をしていたということです。自分が直面した問題を解決するのではなく、名前を載せたくてわざわざ欠陥を探して直していたのですから。いつからか、オープンソース貢献をやらなければならないことのように感じていたのだと思います。

貢献するオープンソースも Java·Spring エコシステムの中からだけ選んでいました。そもそも Java·Spring の開発者なのでこちらのエコシステムのほうがずっと馴染みがあり、たくさん使ってきたのも確かですが、履歴書でインパクトがあるという点を考えなかったとは言えません。

結局モヤモヤしていたのは LLM のせいではなく、目的のせいでした。どこに貢献するかより、なぜ貢献するかのほうがずっと大事だと感じ、本当の問題を解決しようと思いました。

自分のためのオープンソース

実際に遭遇した問題を直した PR を二つ紹介します。一つ目は sqlglot です。業務で Athena ベースの text-to-SQL 機能を作っていて、LLM が生成したクエリを実行前に sqlglot で検証していたのですが、Athena では問題なく動く LIKE 'QA3\_%' ESCAPE '\' のようなクエリが TokenError で拒否されました。調べてみると、Athena dialect は Hive と Trino のルールを合わせてトークン化してからどのエンジンに送るかを決めるのですが、Hive では \ がエスケープ文字なので '\' が閉じていない文字列になり、Trino に渡る前に失敗していました。合わせたルールでのトークン化に失敗したらエンジンごとのルールで再試行するように直した PR #8629 を出し、その日のうちにマージされました。

二つ目は Strands Agents SDK です。Bedrock 上の Claude で LLM サービスを運用していて、エラーログに ValidationException を見つけたのですが、モデルが stopReason を tool_use で返しながら、肝心のツール呼び出し情報を空のまま送ってきたケースでした。SDK は tool_use を見てツールを実行し結果を返そうとしましたが、実行するツールがないため結果の代わりに空の user メッセージを付け、次のリクエストでエラーになりました。ツール呼び出し情報がなければターンを終えるように直した PR #5145 を出し、まだレビューを待っています。

二つの PR は、Java·Spring エコシステムを出た初めての Python ベースのオープンソース貢献でした。LLM の使い方は以前と同じでしたが、自分が実際に遭遇した問題を解決していると思うと、モヤモヤがずいぶん和らぎました。

これからどうすればもっと意味のある貢献ができるのかも考えてみました。一つ目は今のように自分が直面した問題を直すこと、二つ目は feature 単位で分析して貢献するだけにとどまらず、モジュールや全体のアーキテクチャを把握したうえで貢献することです。一つのモジュールに貢献し続ければ、そのモジュールについては専門性が身につくのではないかと思うんです。Spring Data はモジュール化がよくできているようなので、それを分析した記事も書いてみたいです。

意味のない貢献はない

私は、どんな形の貢献にも意味があると考えています。意図がどうであれ、LLM を使ったとしても、結局コードは良くなるのですから。先ほど述べたように、問題を見つけるのはAIで「ポチッ」とできても、既存コードとの互換性を守りながらメンテナーを説得してレビューを通すのは、やはりエンジニアの役目です。ただ、メンテナーの言うとおり、実際に使っていて出会った問題を直すときのほうがその価値ははるかに大きく、意味もより実感できる気がします。

最近はオープンソース貢献のほかにも、履歴書にはまったく役に立たないものを作っています。代表的なのがデスクトップで一緒に動くちいかわのペットで、もうとにかく可愛くて、作るのが本当に楽しいです。

「ポチッ」とやれば終わる時代が来て、多くの開発者がキャリアに悩んでいます。開発の定義が急激に変わるぶん、方向を見失ったり興味を失ったりもしますし、市場は冷え込むどころか凍りついていて、なんとか自分をアピールすることが切実な時期です。私も同じで、学び始めた頃より楽しさが減ったのは事実です。それでも、役に立たないものを開発してみてほしいです。みんな、あまりに余裕なく、せかせかと生きているように思うんです。めちゃくちゃ可愛いちいかわを作って、ひと息ついてみてはどうでしょうか？AI 開拓時代のすべての開発者を応援しています。

読んでいただきありがとうございました。