8月31日、Help Net Securityが「Debian developers rejected an LLM ban and left disclosure voluntary」と題した記事を公開した。DebianコミュニティがLLM(大規模言語モデル)の使用禁止を否決し、AI利用の開示を任意とするポリシーを採択したことを伝えている。
Debianが下した結論:禁止なし、強制なし、責任は人間に
8月28日をもって投票が締め切られ、プロジェクトセクレタリーのKurt Roeckxが結果をアナウンスした。採択されたのは「AI利用の開示を奨励するが、義務とはしない」という選択肢だ。
端的に言えば、マージリクエストのdiffを見ても、それが人間が書いたのかモデルが生成したのかは誰にもわからない。そして、誰もそれを明かす義務はない。
Debianは生成AIを推奨も禁止もしない立場を取った。ボランティアの時間を節約できるツールとして一定の有用性は認めつつ、コントリビューションの評価はこれまでと変わらず「diff そのもの」に基づく。提出者が品質・正確性・ライセンス適合性について引き続き責任を負う、という原則も不変だ。
実際に「噛んでくる」条項は3つ
採択テキストは既存の慣行をおおむね追認する内容だが、明示的に禁じた事項がいくつかある。
1. 機密情報の外部AIサービスへの送信禁止
CVEのエンバーゴ(公開前の脆弱性情報)、プライベートな通信、暗号鍵、クレデンシャルは、明示的な許可なく外部のAIサービスに送ってはならない。Debianのセキュリティチームはエンバーゴ状態のCVE詳細を日常的に扱うため、これは実務上の制約として機能する。
2. 大規模な自動化作業には事前議論が必要
大量のバグ報告や大規模なパッチ提出といったバルク作業は、事前にコミュニティで議論し、自動化の結果に責任を持つ人間を立てることが求められる。
3. AIレビューなし提出は「通常の慣行外」
「適切なレビューなしにAI生成物をそのまま受け入れたりアップロードしたりすること」はDebianの通常慣行の外にある、と採択テキストは明記している。読んでいないものをシップするな、ということだ。
「レビューが唯一の防衛線」という構造的な問題
このポリシーの最大の論点はここだ。
元記事によれば、機密情報の外部送信を禁じた条項の背景には、AI支援ワークフローの普及にともなう情報漏洩リスクへの業界全体の懸念がある。GitGuardianおよびOX Securityのデータは元記事が引用しているものだが、その内容は以下のとおりだ。
GitGuardianの調査では、2025年にGitHubの公開コミットで新たに発見されたハードコードされたシークレットは2865万件に上る。AIサービス自体のクレデンシャルの漏洩は前年比81%増だった。これらはDebianが禁じた行為(非公開のプロジェクト情報をモデルに送ること)を直接計測したものではないが、AI支援ワークフローの中でシークレットを無造作に扱う習慣が広まっていることを示している。
OX Securityが300以上のリポジトリ(うち50はCopilot、Cursor、Claudeなどを使用)を分析した結果によれば、モデルが書いたコードは行単位では人間が書いたものと比べて品質が劣らなかった。問題はボリュームだ。コードを読み、動かし、議論するというステップは、もともとチームの速度を落としていた工程であり、AI活用時に最初に省かれやすいものでもある。
Debianのポリシーは、AIリスクへの答えとして「人間によるレビュー」を据えた。しかし新たなゲートを追加したわけではなく、元々あった仕組みを再確認しただけだ。レビューという工程が現実に圧縮されやすい中で、それを唯一の防衛線とする構造は、実効性の面で問いを残す。
ライセンスの問題は「棚上げ」
もう一つ解決されていない問題がある。モデルの出力物に著作権が発生するかどうか、Debianはポリシーとして立場を示さなかった。
Debianアーカイブに収録するすべてのパッケージはDFSG(Debianフリーソフトウェアガイドライン)に準拠したライセンスが必要だ。モデルが制限的なライセンスのコードを学習データとして再現した場合、出力物にその痕跡は残らない。アップロードに署名する開発者が、ライセンス要件とライセンス不明なAI生成物という矛盾を自分の判断で処理しなければならない状況は続く。
OSSコミュニティでのAI利用ポリシーは各プロジェクトが手探りで整備している段階にあり、Debianの今回の決定はその一例として参照されることになるだろう。
詳細はDebian developers rejected an LLM ban and left disclosure voluntaryを参照していただきたい。