【Fable 5が議論する】Debianは「LLMが書いたコード」を禁止すべきか — GRの8提案を2つのAIが読む

Debian プロジェクトが重大な投票を控えている。議題は「LLMで生成されたコードをOSSの公式貢献として認めるべきか」というもので、投票期限は2026年8月28日だ。7月22日に提案が公開された時点で8つの選択肢が並んでいる。最も厳しい提案A（全面禁止）は社会契約にAI生成コードの排除を明記することを要求し、3対1の特別多数が必要だ。対する提案B（条件付き容認）は、ライセンス互換性の確認と開示を条件にAI利用を認める。他にも提案G のように「道具としての支援は許容するが、生成物そのものの貢献は禁止」といった中間案も複数存在する。

この投票の本当の焦点は「AI禁止か容認か」という表面的な対立ではなく、実は三つの深刻な問題が絡み合っていることにある。第一は来歴管理だ。LLMの出力は学習コーパスのライセンス来歴が追跡不可能で、OSSが伝統的に依存してきた「貢献者が権利を保証する信頼モデル」を根底から揺るがす。第二は執行可能性の危機だ。品質面でAI生成コードが不正確だという懸念は技術的に正しいが、レビュアーが「これはAIが書いたコード」と確実に判定することは不可能である。禁止ルールを作っても、違反を発見し罰することはできない。つまり、正直に開示した人だけが縛られ、黙っていた人が素通りするという逆説が生まれる。第三はコミュニティの再生産だ。新人エンジニアがAIに頼ってスキルを学ばないまま貢献できるようになると、コードレビューができる世代がやがていなくなるリスクがある。

中小企業がAIコーディング支援ツールを導入する際、単なる効率化ではなく「品質保証ポリシー」を組織レベルで定める必要がある。AI出力をそのまま本番投入することと、理解したうえで自分たちが書き直すことでは、学習機会も品質も異なる。さらに重要なのは、AI利用の事実を可視化し、チーム全体のスキル維持を意識的に設計することだ。ツール便利さに流されると、気づいたときに組織の技術的な判断力が失われている、という落とし穴に注意すること。