Debianが生成AIの「責任ある利用」を可決 — 8択Condorcet投票の結果と、OSSのAI寄稿ポリシーが割れる理由

はじめに

2026年8月28日に締め切られた Debian の General Resolution（一般決議、vote_002「LLM usage in Debian」）の結果が公開された。8つの提案が並んだ投票を制したのは、Marc Haber 提案の 「Responsible Use of Generative AI（生成AIの責任ある利用）」 だった。Hacker News で434ポイントを集め、本日のIT系トピックで最も注目を浴びている。

この件が単なる「Debianもついに AI OK になった」というニュースで終わらないのは、同じ問いに対して OSS プロジェクトが正反対の答えを出しているからだ。Gentoo と NetBSD は2024年に生成AI由来のコードを実質禁止しており、QEMU も AI コードジェネレータの使用を禁じるポリシーを持つ。Debian はそこから逆方向に舵を切った。

この記事では、8つの選択肢が何を争点にしていたのか、可決された条文が寄稿者に何を課しているのか、そして「禁止」と「容認」を分けている本当の分岐点はどこなのかを整理する。

8つの提案は何を争っていたのか

Debian は Condorcet 方式（全選択肢に順位をつける）で投票する。今回のバロットには8案＋「None of the Above（いずれでもない）」が並んだ。提案者と骨子は以下の通り。

案	提案者	内容
A	Matthias Geiger	社会契約を改定して LLM 寄稿を禁止（3:1 の特別多数が必要）
B	Lucas Nussbaum	条件付きで容認。大部分がAI生成なら開示を「要請」
C	Ian Jackson	実務的に可能な範囲で拒否。行動規範を改定し「人間宛のメッセージ」のLLM生成を禁止
D	Pierre-Elliott Bécue	Debian 固有の作業に限ってAI寄稿を容認
E	Marc Haber	責任ある利用（可決）。既存基準以上の特別ルールを設けない
F	Tobias Frost	可能な限り回避を推奨。禁止はしない
G	Gard Spreemann	GCC / Rust に倣い、直接の寄稿としては不可。調査・批評の補助としては可
H	Holger Levsen	気候破壊を理由に回避を表明（表明のみで禁止ではない）

争点は大きく3つに割れていた。ひとつは プロヴェナンス（出自）と著作権。A案の Geiger は、LLM 出力の著作権状態が不透明であり、学習データ由来のライセンス義務を果たせない以上 DFSG（Debian フリーソフトウェアガイドライン）適合性が疑わしいと主張した。これに対し Russ Allbery や Ted Ts’o といった古参は、多くの上流プロジェクトが既にその懸念を退けていること、そして「人間が Stack Overflow の例を読んで書く」のと本質的にどう違うのかを問い返している。

ふたつめは コミュニケーションの領域。C案が独特なのは、規制対象をコードではなく「人間宛のメッセージ」——バグ報告、メール、議論、Planet Debian のブログ投稿——に置いた点だ。生成された文章を人に読ませる行為そのものを行動規範違反と定義する設計である。

みっつめは 環境負荷。H案は LLM の消費電力を持ち出した。これには Nussbaum が「LLM だけを名指しするのは AI バッシングに見える。パッケージビルド回数を減らすとか DebConf の渡航を減らすとか、他にも手段はある」と反論している。

可決された「責任ある利用」が実際に課すもの

投票は2026年8月15日から28日まで行われ、有権者は約1,000名超の Debian Developer。結果、E案は主要な対立案をいずれも上回った。

E案 vs B案（条件付き容認）: 203 対 148
E案 vs F案（慎重路線）: 210 対 130
E案 vs D案（Debian固有作業のみ）: 232 対 115
E案 vs G案（Debianは人間が作る）: 251 対 139

LWN の報告によれば、強硬な禁止案である A案と C案は「None of the Above」を上回れなかった。つまり Debian の有権者にとって、禁止案は「いずれでもない」より下位だったことになる。禁止寄りを選好した層は約3割にとどまった。

可決された条文の中核はこうだ。

Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance, or documentation of software, packaging, documentation, and other media published within the Debian Project. （Debian は、Debian プロジェクト内で公開されるソフトウェア・パッケージング・ドキュメント等の開発、保守、文書化における生成AIツールの利用を、推奨もしなければ禁止もしない）

そのうえで寄稿者に課されるのは、次の4点である。

同一基準：AI を使ったかどうかに関係なく、品質・正確性・保守性・法令遵守について同じ基準を満たすこと
完全な責任：提出した人間が成果物に対して全責任を負う。生成物を理解し、レビューし、テストし、必要なら修正してから取り込むこと（鵜呑み禁止）
機密の保護：非公開の Debian データ——private なやり取り、未公開の脆弱性情報、暗号鍵、認証情報——を第三者の AI サービスに渡さないこと
開示は推奨、義務ではない：AI 利用の申告は encouraged だが必須ではない

大規模な自動変更（mass change）に関する既存の慣行はそのまま維持される。

「開示義務なし」という判断をどう読むか

実務的に一番効いてくるのは4番目だ。B案は「大部分がAI生成なら開示を要請する」としていたが、それを含む案が退けられ、開示を義務化しない E案が通った。

この選択には筋が通っている。開示義務は検証できないからだ。 AI 生成物を検出する信頼できる手段がない以上、開示義務は「正直に申告した人だけが不利を被る」制度になりやすい。実際 Nussbaum は、AI 利用を認めた寄稿者が AI 忌避派から攻撃される事態が起きていたと述べている。申告が制裁のトリガーとして機能するなら、合理的な寄稿者は黙る。ルールとして残るのは、守る人を罰し、守らない人を素通りさせる仕組みだけになる。

代わりに Debian が置いたのは「誰が責任を負うか」という一点だ。パッチが壊れていれば、それを送った人間の問題である。生成したのがモデルであろうと、Stack Overflow からのコピペであろうと、扱いは変わらない。ツールの種類ではなく、成果物とアカウンタビリティで線を引いたということになる。

一方、Gentoo・NetBSD・QEMU が引いた線はここではない。NetBSD は LLM 由来のコードを「tainted（汚染された）コードと推定し、事前の書面承認なしにコミットしてはならない」と定めている。Gentoo は「これらのツールの支援を受けて」作られたコンテンツ全般を対象にしており、文面通りに読めばコミットメッセージを整えてもらうことすら含まれうる。これらは品質ではなくプロヴェナンスの問題として扱っている。学習データのライセンス義務を追跡できない成果物は、そもそもリポジトリに入れられない、という立場だ。

Debian は同じ不確実性を認識したうえで、それを寄稿者個人の判断責任として分散させた。条文にも「寄稿する素材の出自とライセンス上の含意を考慮し、法的地位を合理的に説明できない内容を持ち込まないこと」という趣旨の記述が入っている。禁止でも放任でもなく、判断を個人に委ねる設計である。

エンジニアへの影響 — 自社のAI寄稿ポリシーをどう書くか

この投票結果は、OSS への寄稿者だけでなく、社内のコントリビューションガイドラインを書く立場にも直接効いてくる。

まず、上流のポリシーを確認する習慣が必要になった。 同じ「AIを使ったパッチ」でも、Debian なら通り、NetBSD なら事前承認が要り、Gentoo なら差し戻される。プロジェクトごとに線の位置が違う以上、寄稿前に CONTRIBUTING を読むコストは以前より上がった。特に「支援を受けて」という広い書き方をしているプロジェクトでは、コード本体だけでなくコミットメッセージや issue の文面まで対象になりうる。

次に、社内規程を書くなら「開示義務」より「責任の所在」を先に決めるべきだ。 Debian の判断が示しているのは、検証不能なルールは運用に耐えないという実務的な結論である。「AI 利用時は申告すること」と書くのは簡単だが、申告しなかった場合に何が起きるかを定義できないなら、その条項は機能しない。それよりも「提出者がレビュー・テストの責任を負う」「レビューなしの生成物をそのまま出さない」を明記するほうが、実際のレビューフローに接続できる。

そして機密の扱いは、AI に限らず切り出して書いておく価値がある。 Debian が明示的に挙げた「未公開の脆弱性・暗号鍵・認証情報を第三者サービスに渡さない」は、AI ポリシーというより情報管理ポリシーだ。ここだけは曖昧にしておく理由がない。コーディングエージェントがリポジトリ全体を読める前提の今、.env や秘密鍵をコンテキストに入れない仕組み——ignore 設定や権限分離——を、規程ではなくツール側で担保しておきたい。

まとめ

Debian は2026年8月の General Resolution で、8案＋NOTA の Condorcet 投票の結果、「生成AIの責任ある利用」（Marc Haber 案）を可決した
社会契約や行動規範を改定する強硬な禁止案（A案・C案）は「None of the Above」を下回った。禁止寄りの選好は約3割
可決された条文は、同一の品質基準・提出者の完全な責任・機密の非提供を課す一方、AI 利用の開示は推奨にとどめ義務化しなかった
Gentoo・NetBSD・QEMU が引いた「プロヴェナンスによる禁止」の線とは明確に異なる。Debian はツールの種類ではなく成果物とアカウンタビリティで線を引いた
社内のAI寄稿ポリシーを書くなら、検証できない開示義務より、責任の所在とレビュー要件、そして機密をツール側で遮断する仕組みを先に固めるのが実務的

ひとつのプロジェクトが結論を出しても、OSS 全体の合意にはならない。Gentoo や NetBSD がこの結果を受けて方針を緩める気配は今のところなく、むしろ「どこに線を引くか」の分岐は当面固定されたまま残る。寄稿する側にとっては、上流ごとの線の位置を確認する作業がしばらく続くことになる。