AIがオープンソースに偏った圧力をもたらす

オープンソースコミュニティが、メンテナーを圧倒することなくAI生成の貢献に適応する方法

Drupal CMS ラボ編集部

2026-01-29

2026-03-06

この記事は Dries Buytaert の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

AIはオープンソースへの貢献コストを下げましたが、メンテナーの生活を楽にしているわけではありません。より多くの貢献が流入していますが、それらを評価する負担は依然として同じ小さなグループに集中しています。この非対称的な圧力は、メンテナーを疲弊させる危険性があります。

curlの事例

curlをメンテナンスしているDaniel Stenberg氏は、curlプロジェクトのバグ報奨金プログラムを終了したばかりです。このプログラムは長年うまく機能していました。しかし2025年には、提出された報告のうち本物のバグと判明したのは20件に1件未満でした。

「千の粗悪品による死」と題した投稿で、Stenberg氏はcurlの7人編成のセキュリティチームへの負担を説明しました。各報告に3〜4人が関わり、時には何時間もかけても、結局何も見つからないことが多かったのです。彼は「精神を麻痺させる愚かさ」による「精神的負担」について書きました。

Stenberg氏の対応は現実的でした。彼はAIを禁止しませんでした。バグ報奨金を終了させたのです。それだけで、低品質な報告でプロジェクトを溢れさせる動機のほとんどが消えました。

Drupalにはバグ報奨金制度はありませんが、それでもインセンティブは存在します。貢献クレジット、評判、可視性、これらすべてが重要です。これらのインセンティブも低品質な貢献を引き寄せる可能性があり、それらを選別するコストは多くの場合メンテナーにかかります。

2つの真実の狭間で

Drupalでもいくつかの粗悪なAI生成物を見てきましたが、curlが経験したような規模ではありません。しかし、私たちのメンテナーは手一杯で、他のプロジェクトで何が起こっているかを見ています。

その緊張は、Drupal CoreにおけるAIに関する会話に現れ、決断の遅れにつながることがあります。例えば、AGENTS.mdファイルや適応可能なモジュールに関して人々が躊躇するのは、それらを評価する能力を増やすことなく、より多くの貢献を招くことを心配しているからです。

これが、私たちのコミュニティにおけるAI駆動の非対称的な圧力です。私はその躊躇を理解しています。私たちがこれを間違えると、メンテナーが代償を払うことになります。彼らは懐疑的になる権利を得ているのです。

多くの人はAI自体についても懸念を抱いています。環境への負荷、技術への影響、そしてAIがどのように訓練されたかに関する未解決の法的・倫理的問題です。セキュリティ脆弱性がすり抜けることを心配する人もいます。そして、丹精込めて構築したものが大量の低品質な貢献の標的になるのを見ることが、単純にやる気を削ぐという人もいます。これらの懸念は正当であり、耳を傾けるに値します。

その結果、私は2つの真実の狭間に挟まれていると感じています。

一方では、メンテナーがすべてを支えています。彼らが燃え尽きたり去ったりすれば、Drupalは深刻な問題に陥ります。まず負担を軽減する方法を作らずに、彼らにもっと多くの仕事を吸収するよう求めることはできません。

他方では、Drupalに依存している人々は、他のプラットフォームが加速するのを見ています。私たちの動きが遅すぎれば、彼らは他を探すでしょう。

どちらも真実です。メンテナーを保護することとイノベーションを加速させることは、対立するものであってはならないはずですが、今はそう感じられます。Drupalのプロジェクトリーダーとして、私の仕事は両方を尊重する道を見つける手助けをすることです。

私がどこに立っているかについて正直であるべきでしょう。私は1年以上AIツールを使ってソフトウェアを書いてきました。本当の成功を収めています。また、最も経験豊富な貢献者の一部が劇的に生産性を高め、以前には単純にできなかったことを行うのも見てきました。その見解は経験から来ており、誇大宣伝からではありません。

しかし、視点を持つことと、すべての答えを持つことは同じではありません。そしてリーダーシップは、人々が行きたくない場所へ引きずっていくことを意味しません。それは慎重に方向を示し、異なる視点に対して開かれたままでいて、プロジェクトを支える人々を見捨てないことを意味します。

私たちは以前にもこのような状況にいたことがある

新しい技術は障壁を下げる傾向があり、障壁が低くなることには常にトレードオフがあります。私はキャリアの初期にこれを目の当たりにしました。日中は組み込みシステム用の低レベルCを書いていて、仕事の後に家に帰ってDrupalとPHPでウェブサイトに取り組んでいました。それはスリリングで、日中の仕事とは対照的でした。Cで何日もかかることを、一晩で構築できたのです。

その興奮を覚えています。初期のウェブが生き生きとしてきたとき。AIに出会うまで、25年間同じような興奮を感じたことはありませんでした。

PHPは趣味プログラマーや独学の開発者、進みながら学ぶ人々を引き寄せました。彼らの多くはここでキャリアを築きました。しかし、それは初期のPHPコードの多くが深刻なセキュリティ問題を抱えていたことも意味しました。言語が非難され、多くの専門家がそれを完全に否定しました。今でもそうする人もいます。

答えは、低品質なコードを可能にするからといってPHPを拒絶することではありませんでした。答えはフレームワーク、より良いセキュリティ慣行、そして共有された標準でした。

AIは異なる技術ですが、同じパターンが見えます。障壁を下げ、まだ専門家ではない新しい貢献者を呼び込むでしょう。そして、スクリプト言語と同様に、AIはここに留まります。問題は、AIがオープンソースに来るかどうかではありません。それをどう機能させるかです。

適切な手の中のAI

curlの話はそこで終わりません。2025年10月、Joshua Rogers氏という研究者がAI搭載のコード解析ツールを使って何百もの潜在的な問題を提出しました。Stenberg氏は「品質と洞察力に驚いた」と述べました。彼と仲間のメンテナーは、最初のバッチだけで約50の修正をマージしました。

今週初め、AISLEというセキュリティスタートアップが、最新のOpenSSLセキュリティリリースでAIを使って12のゼロデイ脆弱性を発見したと発表しました。OpenSSLは地球上で最も精査されているコードベースの1つです。インターネットの大部分を暗号化しています。AISLEが見つけたバグの一部は25年以上隠れていました。彼らはcurlにも30以上の有効なセキュリティ問題を報告しました。

これとStenberg氏の受信箱を溢れさせた粗悪品との違いは、AIの使用ではありませんでした。それは専門知識と意図でした。Rogers氏とAISLEはAIを深い知識を増幅するために使いました。低品質な報告は、存在しない専門知識を置き換えるためにAIを使い、洞察ではなく量を追い求めていました。

AIはメンテナーに新たな負担をもたらしました。しかし、うまく使えば、それは救済の一部にもなり得ます。

結果を通じて信頼を獲得する

今週、Daniel Stenberg氏に連絡を取って意見交換をしました。彼もcurlプロジェクト内で同じ緊張を乗り越えようとしており、メンテナーたちはAIに対して懐疑的、あるいは完全に否定的な態度を取っています。

彼のアプローチはシンプルです。チームにツールを押し付けるのではなく、自分自身でテストします。自分のプルリクエストにAIレビューツールを使って、その長所と限界を理解し、実際に役立つ場面を示します。目的は、他の人に採用を強制することなく、有用な応用例を見つけることです。

curlチームが今日AI搭載の解析ツールを使っているのは、Stenberg氏の言葉を借りれば「他の解析ツールでは見つけられないものを見つけることが実証されたから」です。ツールは自らの地位を獲得したのです。

これは、Drupalで試してみたいモデルです。実験は意欲的な貢献者に留め、立証責任は実験者に残すべきです。本当の、再現可能な価値が実証されるまで、メンテナーにとって新しい期待になるべきではありません。

それは待つべきだということを意味しません。意見ではなく証拠が欲しいなら、私たちはそれを作り出さなければなりません。貢献者はまず自分の仕事で実験すべきです。何かが役立つなら、それを示してください。何かが役立たないなら、それも共有してください。肯定的な結果だけでなく、正直な結果が必要です。メンテナーは何も採用する必要はありませんが、誰かが本当の結果を持って現れたら、一見の価値があります。

すべての低品質な貢献が悪意から来るわけではありません。多くの貢献者は学び、実験し、助けようとしています。彼らはDrupalにとって最善のものを望んでいます。歓迎的な環境とは、AIの有無にかかわらず、彼らが成功するのを助けるガイドラインと文化を構築することを意味し、挑戦することを恐れさせることではありません。

私はAIツールが救済を作り出す方法の一部だと信じています。また、それがすでに手一杯の人、AIの粗悪品に対処している人、またはAIが自分の技術にとって何を意味するかと格闘している人にとって、売り込むのが難しいことも知っています。私たちが最も助けたい人々は、しばしば最も懐疑的であり、彼らには十分な理由があります。

私は自分の役割を果たすつもりです。AIツールを実験している貢献者を探し出し、彼らが何を学んでいるか、何が機能しているか、何が機能していないか、何が驚きだったかを共有します。誰かに頼む前に、これらのツールのいくつかを自分で試してみます。そして、失敗も含めて、見つけたことについて書き続けます。

もしあなたがAIツールを実験しているなら、ぜひそれについて聞きたいです。貢献者からの実体験を集めるためにDrupal.orgにイシューを開設しました。そのイシューであなたが学んでいることを共有するか、自分のブログで書いてそこにリンクしてください。私のブログやDrupalConで学んだことを報告します。

メンテナーを守れ

これはDrupalだけの課題ではありません。すべての大規模なオープンソースプロジェクトが、AIへの熱意とその影響への実際の懸念との間で、同じ緊張を乗り越えようとしています。

しかし、これがどこへ向かおうとも、1つの原則が私たちを導くべきです。メンテナーを守ることです。彼らは希少な資産であり、代替が困難で、失いやすいのです。彼らを燃え尽きさせるような道は、前進への道では全くありません。

私はDrupalがAIツールによって弱体化するのではなく、より強くなると信じています。メンテナーの負担を増やすのではなく、減らすことができると信じています。しかし、そこに到達するには、実験、正直な結果、そして協力が必要です。それが私が指し示したい方向です。オープンマインドを保ち、証拠と採用が自ら語るようにしましょう。

草稿をレビューしてくれたphenaproxima、Tim Lehnen、Gábor Hojtsy、Scott Falconer、Théodore Biadala、Jürgen Haas、Alex Bronsteinに感謝します。