AIによるPull Requestでメンテナーの負担が増大、解決の道しるべとなる2大原則

AIによるコーディングが目の前で動作するコードを瞬時に構築していく。本人が目の前の作業を楽にするだけのコードを作るのであれば、動くだけのコードでいいかもしれないが、多くのユーザーに使ってもらうことを前提とするオープンソースプロジェクトのコード判断を行うメンテナーはそうは行かない。むしろAIの登場により負担が大きく増している。

生成AIで増加する粗製乱造のプルリクエスト

Linux Foundation Researchが10月に公開したレポート「Navigating Open Source Software Development in the Generative AI Era 」(生成型AI時代におけるオープンソースソフトウェア開発の進め方)によるとプルリクエスト(Pull Request/PR)の約25%が低品質なAI生成の提出物で大規模なプロジェクトではこの数値が31%に上がる。多くのメンテナーが長期化を経験し、燃え尽き症候群を懸念している。

一見、きれいに見えるがプロジェクト全体のアーキテクチャ文脈や一貫性に欠けるものなども増加するためメンテナーの時間や労力が増大することになる。参入障壁は減りプロジェクトへの参加者が増えるものの、管理権限を持つメンテナーの負担が急増する構造だ。

生成AI活用の場が広がる昨今においては組織管理においても似た構造を作り出す。これら事象はOSSコミュニティのなかでの調査の話だが、その生成物を組織の枠組みに入れても問題はないのか？それを公開しても問題はないのか？組織内プルリクエストが増加すれば、監査する側や管理権限者は、飽和という量による課題で破綻しかねない。

Linux FoundationのHilary Carter氏は、同レポートをまとめたブログを投稿しているが、"本報告書は、生成型AIが危機でも万能薬でもないことを明らかにしている。むしろ、それは方法論的な転換点として機能し、その成果はプロジェクトの規模やガバナンス、AIの効率化によって得られた時間をチームがどのように再投資するかによって大きく異なる"と使い方次第であることを述べる。

実際、監査を司るメンテナーは、58%が複雑なロジックの説明・要約にLLMを使い、48%がロジックバグやエッジケースの確認、39%が自動脆弱性スキャン（Snyk・CodeQLなど）、テストケース生成に38%と8割はなんらかの形でAIを使っている。AI活用を否定しているわけではない。

成功しているコミュニティの"2つの基本原則"

Hilary Carter氏は、AI支援についての「正式なガイドラインの欠如」にスポットを当てている。AI支援による貢献を許可する方針を定めているプロジェクトは全体の35%に過ぎない。そして、大事なのは成功しているコミュニティは、AI禁止措置を避ける代わりに、"2つの基本原則"に焦点を当てている。

・透明性のある帰属表示の標準化(Linuxカーネルの構造化されたgit commit trailerのような構造化されたメタ情報)
・検証責任を貢献者に戻す(貢献者がプルリクエストを開く前に機能テストと行ごとのレビューに個人的な責任を負うこと)

git commit trailerは、Reviewed-by: Yatarouのようにコミットメッセージの末尾にKey: Value 形式で記述するメタデータによる帰属表示で様々な項目で使われ、透明性を担保できる。プルリクエストを送る貢献者(コントリビューター)といえども、当然一定の本人の責任が必要であるということ。

レポートでは新規参入者への教育の重要性認識の増加にも触れているが、映画「スターウォーズ」におけるある構造と似た構造が見える。新規参入者は"パダワン"で熟練メンテナーは"ジェダイの騎士"。AIの使用は"フォース"の使い方だ。これを間違うとジェダイの騎士にはなれない。飽和に対しては、量ではなく質を追求することで、これもスターウォーズの世界のなかにある。