AIがオープンソースを変える方法

人工知能は2025年にソフトウェア開発に本格的に浸透し、オープンソースプロジェクトにも大きな影響を与えている。本記事では、筆者が最近オープンソースで観察したいくつかのトレンドと、それらがオープンソースソフトウェアの世界をどのように変えているかについて論じる。

プロジェクトのインフレ

AIがもたらすトレンドの一つは、コンテンツの爆発的増加である。検索結果は生成されたウェブサイトで埋め尽くされ、ソーシャルネットワークは生成画像や動画で溢れている。ソースコードも例外ではない。今日、GitHubは増え続けるリポジトリで溢れかえっている。

しかし、高品質なプロジェクトが増えているわけではない。むしろ、信頼できるかどうか判断できないプロジェクトが増えている。過去には、数千行のコードからなる大規模なプロジェクトに出くわした場合、作成者が問題をよく理解し、個人としての愛着を持ち、将来にわたってメンテナンスする意思があると想定できた。

しかし、今はそのような想定は全く通用しない。今日では、数千行のコードを瞬時に生成できる。まったくのナンセンスや危険なコードである可能性もあるし、機能するコードであっても、作成者が自分の一時的なニーズのために生成してGitHubに投稿しただけで、オープンソースプロジェクトにする気がない場合もある。コードのリポジトリがあっても、それはオープンソースプロジェクトではない。GitHub上のコードとオープンソースプロジェクトの違いは、後者がユーザーの問題やユースケースを解決することにある。そして、そのような使い捨てコードの作成者のほとんどは、それを行うことに興味がない。

これはMeshCoreのようなプロジェクトで明確に見られる。あらゆるもののフォークが何十も存在する。公式のMeshCoreファームウェアに機能がない？フォークして、不足している部分をAIで生成し、MeshCore-UltimateEditionとしてGitHubに投げる。問題は、最小限の労力で作成され、作成者は通常それに愛着がなく、1ヶ月も経てば飽きてしまい、成熟する前に放棄されることだ。

約10年前、人々はLinuxリポジトリの概念はもはや時代遅れだと言い始めた。2000年代には、それらは事実上Linuxソフトウェアの唯一のソースだった。しかし、オープンソースプロジェクトの数が急増し、ディストリビューションは追いつけなくなった。ユーザーは他の場所からソフトウェアを入手せざるを得なくなり、ソフトウェア作成者はディストリビューションなしでやることを学んだ。ほんの数年前までは、「必要なものはすべてDebianにある」というアプローチは決定的に死んだように思えた。

しかし、厳選されたソフトウェアソース——例えばLinuxディストリビューションのリポジトリ——が復活する可能性がある。オープンソースソフトウェアの世界は混沌としてきており、ユーザーは再び、誰かが精査し、6ヶ月後も信頼できるソースを評価するようになるかもしれない。

レビュー過多

AIがオープンソースで引き起こしたもう一つのトレンドは「レビュー過多」である。以前は、コードを書くことは、かなりの努力と時間投資を必要とするため、自然なフィルターとして機能していた。それがなくなったことで、コード作成は迅速かつ簡単になった。しかし、誰かがこのコードを本番環境に投入する前にレビューしなければならない。長年にわたってオープンソースプロジェクトで機能してきたレビュープロセスは、現在その容量の限界に達している。

GNOME 50では、Google Driveのサポートが削除された。長期間メンテナンスされていなかったからだ。ユーザーは当然不満を持ち、最終的に一人のユーザーが立ち上がり、サポートを再追加してgvfsプロジェクトに提出した。

そのプロジェクトのメンテナーである同僚は、4000行のコード変更であると嘆いた。基本的なレベルでは動作するように見えるが、明らかにAIを使って生成されていた。彼は依然として、コードが意図したとおりに動作し、長期的にメンテナンスするためのコード品質基準を満たしていることを確認するために、一行ごとに確認しなければならない。

したがって、ほとんどの労力はコード作成からコードレビューに移っており、これはAIに典型的なことである。しかし、オープンソースの問題は、コードをレビューしてマージできる経験豊富な開発者が、AI以前から既にボトルネックだったことだ。今や問題は大幅に深刻化している。そして上記の例では、同僚はコントリビューターが応答性があり、長期的な関心を示していることを幸運に思える。

今日では、それはむしろ稀な例外である。一般的なコントリビューションは、誰かが深い関心や理解もなく無分別にAIでコードを生成し、メンテナーに投げつけるというものだ。

筆者はMeshyでこれに近い経験をした。誰かが9000行のコード変更を含むプルリクエストを提出し、macOSサポートを追加すると主張した。筆者は一晩中、非常に迅速なレビューに1時間を費やしたが、短時間でも多くの問題に遭遇した：コードは明らかにAI生成であり、数千行は単にシングルクォートをダブルクォートに置き換えただけで、問題とは無関係のコード部分が変更され、メインブランチでここ数週間に行ったすべての変更が上書きされていた。

作成者はコメントに返信せず、その後連絡はなかった。筆者の結論は、そのようなコントリビューションには1時間でも投資が大きすぎるので、次回はもっと早く拒否するということだ。

一部のプロジェクトは、基本的なコントリビューション要件を厳しくすることでこの状況に対応している。例えば、FlathubがAI生成アプリを拒否する決定は、かなりの波紋を呼んだ。多くの人が自らの足を撃つものだと批判したが、彼らの現実を見る必要がある。

Flathubは現在数千のアプリをホストしており、毎日追加されている。レビューを担当するのはたった3人である。レビュープロセスは高度に自動化されているが、非常に徹底しており、多くの手作業が依然として必要である。彼らの目標は最悪の粗悪品を見つけることだけでなく、コードの衛生状態の比較的高い基準を維持することであることは明らかだ。過去6ヶ月間に筆者は2つのアプリをFlathubに提出したが、レビュープロセスは最終的にアプリ自体の品質向上に貢献した。

しかし、これは今や、まったくAIで生成されたアプリを個人の努力なしに提出する人々の現実と衝突している。リクエストのテンプレートにはいくつかの質問があり、アプリの動作を示す短いビデオをアップロードする要件が含まれている。それは本当に要求が厳しいものではなく、誰でも15分でまとめられる。しかし、それさえもAIで生成された粗悪品の作成者にとっては過大な努力である。

これらの最小限の要件を満たす代わりに、一部はそれをLinuxの自由への攻撃とレッテルを貼り、すぐに誰にでも開かれたFlathubの代替をAIで生成した。驚くことではないが、それは1ヶ月も持たなかった。

オープンソースメンテナーは、このコードレビューの需要を満たす能力を欠いているだけでなく、それを行うモチベーションも失っている。多くの場合、彼ら自身で機能を書く方が速いが、レビュープロセスは歴史的に、新しい長期的な貢献者と後継者を育成する方法だった。誰かが一切の努力をせずに生成したAIコントリビューションを送ってきて、おそらく理解もしていない場合、どうやって彼らをプロジェクトを長期的に支援するコントリビューターに育て上げることを期待できるだろうか？

オープンソースソフトウェアは最終結果だけでなく、プロセスも重要だった。貢献者がプロジェクトとの関係を築き、最終的にそれを他の人に引き継ぐ人に成長するプロセスだ。これは、すべてが結果重視で、可能な限り迅速かつ最小限の努力を重視するAIの世界とは対照的である。

コード公開意欲の低下

1990年代、フランシス・フクヤマは民主主義と自由経済が世界秩序の最終的な勝者であると宣言した。今日、民主主義が世界的に侵食され、既存の経済秩序が崩壊する中で、それは控えめに言っても時期尚早な主張に見える。同様に、ほんの数年前、過去数十年の発展に感銘を受けた一部の人々は、オープンソースをソフトウェア開発モデルの究極の勝者と称賛した。我々はフクヤマのテーゼと同様の現実認識に直面しようとしているのだろうか？

最近、筆者はオープンソース開発からの撤退という微妙でありながら存在するトレンドを観察している。オープン開発に対する一つの議論として、前述のレビュー過多がある。一部のプロジェクトでは、AI生成の粗悪品に圧倒されるコストが、有用なコミュニティからの貢献の利益を上回る可能性がある。彼らは透明性のためにソースコードを公開するかもしれないが、オープン開発プロジェクトからオープンソース・クローズド開発プロジェクトへと変貌する。そして透明性をそれほど気にしない人々は、ソースコードを完全に閉鎖するかもしれない。

ソースコードを公開しないもう一つの議論は、ライセンス回避への恐れである。今日のLLMはライセンスに関係なくソースコードで学習し、その後、選択したライセンスで公開できる類似のソリューションを簡単に生成できる。

これは寛容なライセンスにとっては問題ではない。作者は誰でもコードで実質的に何でもできることを既に受け入れているからだ。しかし、AIはGNU GPLのようなコピーレフトライセンスに直接的な脅威をもたらす。作者は通常、自分の作品が永遠にオープンであり、それを使用する誰もが改良をコミュニティに還元することを確実にするためにこれらを選択する。もしLLMがあなたが何年も取り組んできたプロジェクトで学習し、非常に類似したソリューションを生成し、それをプロプライエタリライセンスで公開すれば、この原則を効果的に回避することになる。

再びMeshCoreを例に挙げる：プロトコル自体とファームウェアはオープンソースだが、クライアントはクローズドである。最近、コミュニティで、コアチームメンバーが密かにMeshCoreの商標を申請し、利用可能なコードに基づいて自身のクローズドソースソリューションをAI生成し始めたことが明らかになった。MeshCoreの創設者Scott Powellは、これをクライアントのソースコードを非公開にしておく決定を再確認させたものとして挙げている。具体的には、彼は次のように書いている：

「だから、AIの時代において、オープンソースはあなたの血、汗、涙を他人が無数の方法で盗むために提供することだと見ている。」

我々はPowellの見解に同意しないかもしれないが、それは筆者の周りでますます見られる正当な立場である。筆者は、かつてはあらゆる小さなヘルパースクリプトを共有したいために公開していた生涯のオープンソース支持者たちが、今ではそれらを自分自身に留め、要求があった場合のみ他人に提供しているのを目にする。彼らはPowellと同様の理由を持っている。

オープンソースはまた、共有の必要性から生まれた。コードを書くことは困難であり、メンテナンスはさらに困難だった。なぜ誰もが同じことを独立して実装しなければならないのか？オープンソースプロジェクトで力を合わせ、共有ライブラリを作成し、誰もが結果を活用できるようにしよう。今日のインターネットを支えるインフラは、この基盤の上に構築された。しかし、AIはこの必要性を抑制している。

例えば、筆者は「簡単に自分のCMSを生成できる」という理由でWordPressは死んだという意見に遭遇する。筆者の見解では、これはオープンソースプロジェクトが実際に提供するものを著しく過小評価している。それはコードを書くこと以上のものであり、オープンソースプロジェクトへの依存をLLMへの依存に置き換えるこの戦略は、長期的には報われないかもしれない。

それでも、共有オープンソースコンポーネントへの依存は確かにある程度減少している。