LLM生成コードは時限爆弾か—フリーソフトウェアの著作権問題

LLM生成コードは「著作権の爆弾」—git-annex が全排除を宣言

2024年秋以降、多くのオープンソースプロジェクトが LLM 生成コードの採用に動いています。しかし git-annex（Haskell 製の分散ファイル管理システム）の開発チームは、あえて逆方向を選びました。

git-annex は LLM 生成コードを一切含まず、将来にわたってそうしないことを保証する—これが彼らの宣言です。（出典）

理由はシンプルですが、非常に深刻です。LLM が生成したコードの著作権は「開かれた問題」のまま。

その法的解釈が将来どう変わるか予測不可能な状況で、今からそのコードを組み込めば、後々トラブルに直面するリスクがあります。特に git-annex のような「長期間の保守・互換性維持」が重要なプロジェクトにとって、この不確実性は致命的です。

理想と現実のギャップ—依存関係に潜む LLM コード

git-annex 本体はクリーンでも、その問題は依存ライブラリに隠れています。開発チームが 100 時間をかけて依存関係をレビューした結果、複数の主要ライブラリが LLM 生成コードを取り込んでいることが判明しました。（出典）

検出された問題のある依存関係を整理すると、以下のような状況が浮かび上がります。

「不可解な変更が次のリリースで説明なく巻き戻される」という現象は、LLM 生成コードの品質問題を強く示唆しています。

特に tls（TLS/SSL 通信ライブラリ）や crypton（暗号関数）のような基盤的なコンポーネントに LLM コードが入り込むことは、セキュリティ上の懸念を高めます。コンピュータセキュリティの領域では、「生成 AI の精度に依存することはリスク」というのが業界の認識だからです。

ビルド時の選択肢—「NoLLMDependencies」フラグ

git-annex は、この問題に対して実用的な対抗手段を用意しました。

NoLLMDependencies ビルドフラグを使用することで、LLM コードを含まないバージョンの依存ライブラリを選択し、システム全体をビルドできます。（出典）

使い方は以下の通り：

• 通常のビルド：stack build
• LLM コード回避ビルド：stack build --flag git-annex:-NoLLMDependencies または stack --stack-yaml=stack-NoLLMDependencies.yaml build

注意点は、「セキュリティパッチが新版の依存ライブラリにしかない場合、NoLLMDependencies ビルドでは古い（脆弱な）版を使用する」という点です。つまり LLM コードを避けるか、セキュリティ更新を取るか、どちらかの引き換えになる可能性があります。これは非常にジレンマです。

この仕様の背景にあるのは、「理想と現実の妥協」です。開発チームは「LLM コード依存性がない状態を維持する」ことを目指していますが、HaskellのGHCコンパイラ本体が LLM コードを含むようになった 9.15 以降は、新しい言語機能に一切アクセスできなくなるという制約が生まれています。

実装側の視点では、自分たちのプロジェクトを LLM コード完全排除で貫くと、同時に技術進化の恩恵を受けられなくなるという難しい局面に直面しているわけです。100 時間の依存関係レビューという作業の重さが、この葛藤を象徴しています。

今後：「潮流に抗う」という選択の代償

開発者自身も「潮流に抗おうとしている」ことを認識しています。ソフトウェア・フリーダム・コンサーバンシー（Software Freedom Conservancy）が LLM コード問題での公式見解の表明を控えた理由も、おそらく同じ—解決困難な問題だからです。

この取り組みが示唆する最大の問題は、今後「プログラマーが常時、全依存ライブラリの LLM コード混入をモニタリングする」ことが新しい保守作業になる可能性です。これは仕様管理やテストと同じレベルで、継続的な作業負荷を生むことになります。

セキュリティとLLM品質のバランスをどう取るか、オープンソースコミュニティ全体が試行錯誤の段階にあるのが現状と言えるでしょう。