7月2日、joey hessが「no LLM code in dependencies」と題した記事を公開した。分散ファイル管理ツールgit-annex（Gitリポジトリ外の大容量ファイルをバージョン管理するHaskell製ツール）の作者として知られるhessが、依存ライブラリからLLM生成コードを排除するために約100時間を費やした経緯と、その過程で露わになった品質問題を詳しく記録している。
「依存ツリー全体を継続的にレビューする必要がある——というのが今のプログラミングの現実らしい」。hessはそう皮肉を込めて書く。OSSのメンテナにとって、LLM生成コードの混入は単なる品質の問題にとどまらず、ライセンスリスクや信頼性の崩壊につながりうる新たな脅威だ。
実際に見つかった問題の深刻さ
hessが精査した記録はプロジェクトのWikiページにまとめられている。そこで見つかった具体的な問題は以下の通りだ。
- 大量のLLM生成変更が、次のリリースで何の説明もなくrevertされているケース
- 1489行のコミットメッセージが支離滅裂な内容で、26,000行規模のコードベースに対して10,000行の変更が一気に加えられたコミット
- 別プロジェクトからコードをコピーするようLLMに指示した結果、著作権侵害をかろうじて免れたとみられるケース
3点目は特に重大だ。LLMは学習データを再現することがあり、ライセンス条件の異なるコードがOSSプロジェクトに混入するリスクは以前から指摘されてきた。hessのケースでは「たまたま」免れただけという状況であり、次は免れない可能性もある。
さらにhessは、以下のようなコミットメッセージを例として挙げている。
Add fourmolu config and restyled
neat
format a module
このようなコミットを積み重ねて「10xエンジニア」（生産性が平均の10倍という評価を自称する開発者像）を名乗ることへの批判を述べ、「自分の行動が与える広範な影響を考えてほしい」と訴えている。このプロジェクトとは、以降の協力を打ち切ったという。
「潮流を押し返そうとしている」という自覚
hessは自身の取り組みについて率直だ。「おそらくすでに潮流を押し返そうとしているのだと思う」と認めている。
LLM生成コードのライセンス問題に関しては、Software Freedom Conservancyが「特定のケースを除いて判断が困難」とする見解を示しており、実質的に個別プロジェクトへの対応を委ねる形となっている。hessはこの状況を「お手上げ」と評し、FSF（Free Software Foundation）も大差ないだろうと見ている。
それでも、この100時間の作業から得られた唯一のポジティブな成果があるとhessは言う。「どの依存ライブラリの品質が信頼できるかという追加情報が得られたこと」だ。LLM混入の有無を精査することで、依存先の開発姿勢が透けて見えるという副産物——これは皮肉ではあるが、実用的な知見でもある。
「これらのドミノが倒れていく中で、こうしたコミュニティへの関与を再考しつつある」とも記しているが、それでも開発とユーザーサポートは続けると締めくくっている。
OSSエンジニア全体の問題として
従来、OSSの依存ライブラリを評価する基準はライセンス・パフォーマンス・メンテナンス状況が主だった。LLMコードの混入という新たな軸が加わることで、依存ツリーのレビューコストが構造的に増大する。
hessの取り組みは一個人の判断だが、問題の本質はパッケージエコシステム全体に波及しうる。Hacker Newsでもこの記事は活発に議論されており、「コードの出自そのものより、レビューしない文化が問題だ」という声と、「出自がわからないコードを依存に含めること自体がリスクだ」という声が交錯している。
hessが費やした100時間は、そのどちらの立場にとっても、問題の深刻さを示す具体的な証拠となっている。
詳細はno LLM code in dependenciesを参照していただきたい。
