GCCのAI方針とオープンソースの選択 — 15行という境界線は何を守ろうとしているのか

はじめに — 7月29日、15行という線
方針が実際に要求すること — そして禁止しないこと
なぜよりによって15行なのか — 著作権譲渡、DCO、そして二方向のリスク
他のプロジェクトはどこに線を引いたか
貢献者にとって実際に変わること
この論争の両側
おわりに — この方針はコード品質ではなく出所の履歴に関するものです
参考資料

はじめに — 7月29日、15行という線

2026年7月29日、David EdelsohnがGCCメーリングリストにAI方針の発表を投稿しました。運営委員会がJonathan Wakelyが率いたAI方針作業部会の勧告をそのまま受け入れたという内容です。作業部会にはCarlos O'Donell、Sudakshina Das、Jason Merrill、Joel Sherrill、Sam James、Robin Dapp、Arthur Cohenが参加しました。

方針本文はgcc.gnu.org/ai-policy.htmlにあり、一文に縮めるとこうです — 法的に重要な貢献にLLM生成コンテンツが含まれる、またはそれに由来する場合は受け付けません。 そして「法的に重要」の基準はGNUメンテナーガイドラインに従いおよそ15行です。

見出しは大抵「GCCがAIコードを禁止した」となりましたが、方針本文を読むと図はずっと細かいです。禁止されていないものがかなりあり、新たに要求されるものもあり、例外が一つあって、その例外がよりによってテストケースです。この記事は方針が実際に何を要求しているのか、その背景にある法的構造は何か、他の主要プロジェクトはどこに線を引いたか、そして貢献者の立場から実際に何が変わるのかを見ます。どちらが正しいかは判定しません。両方の論拠に実体があり、実際に分かれる地点がどこかを知るほうが役に立つからです。

方針が実際に要求すること — そして禁止しないこと

方針を項目として展開すると四つです。

禁止されること。 法的に重要な貢献のうち、LLMが作った内容を含む、またはそれに由来するもの。ここで「由来」という言葉が広く使われている点が重要です。モデルが書いたコードを人間が手直しした結果も「由来」に当たります。

許可されること。 法的に重要でない貢献、つまりおよそ15行未満はLLMが生成したものであっても、明確に表示し他の通常の要件を満たせば受け付けられます。

例外。 メンテナーは法的に重要なテストケースについては、LLMが全部または一部を生成したものでも受け付けられます。この例外の設計意図は明確です — テストケースはコンパイラが判定してくれる成果物なので人間のレビュー負担が低く、著作権の観点からも大抵表現の幅が狭いです。先に見た大規模マイグレーションの事例がテストスイートを機械の審判として使ったのと同じ論理がここにも当てはまります。

新たに生じる義務。 AIの助けを受けた作業にはコミットメッセージにAssisted-by:トレーラーを付けなければなりません。そして人間が変更内容を理解し、質問に答えられ、含めることを承認しなければなりません。DCOへの署名は人間だけができます。

ここでよく誤解される点を明確にしておく必要があります。方針は個人がLLMを使うこと自体を禁じてはいません。 アクセシビリティツール、研究、分析、バグの発見と報告、パッチレビューに使うことは明示的に許可されています。条件は一つ — その出力がプロジェクトにそのまま提出されなければよいのです。つまりこの方針が統制しようとしているのは開発者の作業方法ではなく、リポジトリに入るバイトの出所です。

最後に方針自体が暫定的です。本文はこの方針がコミュニティやGNUプロジェクト全体の立場によって変わることを見込んでおり、遅くとも2027年初頭に再検討すると書いています。そして態度に関する一文が付いていて、LLMに対する立場に関わらず貢献者を尊重して扱い、拒絶より遵守へ導くようにというものです。方針文書にこうした一文が入ったこと自体が、この論争がコミュニティ内部でどれほど鋭かったかを示しています。

なぜよりによって15行なのか — 著作権譲渡、DCO、そして二方向のリスク

15行という数字は新しく作られたものではなく、GNUプロジェクトが長く使ってきた著作権帰属の基準線です。それ未満は著作権で保護されるだけの創作的表現とは見なしがたいという実務的な慣行です。AI方針がこの線をそのまま再利用したという事実自体が、この方針の性格を物語っています — これは品質方針ではなく著作権方針です。

背景を知ればなぜGCCが特に保守的なのか理解できます。GCC貢献ガイドによれば、FSFは大きな貢献について依然として著作権譲渡を好み、その代替としてコミットにSigned-off-by:タグを付けるDCO方式を受け入れます。著作権譲渡が存在する理由は一つです — GPL違反訴訟で原告資格を一箇所に集め、ライセンスを実際に執行できるようにすることです。コピーレフトは著作権の上に載った契約なので、著作権が揺らげばGPLも一緒に揺らぎます。

ここでLLM出力が作る問題が二方向に分かれます。どちらへ行ってもコピーレフトプロジェクトには不利です。

第一の枝 — 著作権がなければ。 人間の著作者性のない純粋な機械生成物に著作権が認められないなら、そのコードにGPLが課す条件が付く根拠が弱まります。再配布者にソース公開を求める梃子が消えるということです。(米国著作権局が人間の著作者性を要求してきたことは広く知られた背景ですが、この記事で一次資料を直接確認してはいません。)

第二の枝 — 著作権があれば。 その著作権が誰のものかが問題になります。学習データにあったGPLコードや独占コードの派生物である可能性を排除する方法が現状ではなく、貢献者はDCOが求める「このコードを貢献する権利がある」という宣言を正直にはできなくなります。Gentooが方針本文で挙げる最初の理由が正確にこれです — そうした素材を使うと著作権を侵害する危険があるだけでなく、Gentoo自身のコピーレフト保護を弱める可能性があるというものです。

まとめるとGCCの線は「AIコードが悪い」という判断ではなく「出所の履歴が途切れたコードをGPLリポジトリに入れられない」という判断です。だから15行であり、だからテストケースは例外であり、だから個人使用は自由なのです。

他のプロジェクトはどこに線を引いたか

同じ問題を前に、主要プロジェクトが異なる答えを出しました。確認できたものだけ整理します。

プロジェクト	立場	時期・根拠
GCC	法的に重要な貢献は拒否。テストケース例外、Assisted-by必須、2027年初頭再検討	2026-07-29運営委員会承認
Linuxカーネル	許可するが公開義務あり。Assisted-byトレーラー形式指定、Signed-off-byは人間のみ	Documentation/process/coding-assistants.rst、2026年4月初旬マージ、59行
Debian	決定進行中。全面禁止から条件付き許可まで五つの案が総選挙にかけられている	議論期間2026-07-24開始、この記事時点で結果なし
Gentoo	自然言語AIツールで作ったコンテンツの貢献を全面禁止	2024-04-14評議会採決
NetBSD	LLM生成コードを「汚染された」ものと見なし、コアチームの事前書面承認なしのコミットを禁止	コミット指針
QEMU	AI生成コンテンツが含まれると判断された貢献を拒否	code-provenance文書
curl	公開を条件に許可。レビュー時間を正当化できない大量のAI PRは拒否	貢献ガイド

LinuxカーネルとGCCの対比がこの地形を最もよく示しています。カーネルは公式文書でAI補助の貢献を許可しつつAssisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]形式の公開を要求し、Signed-off-byは人間だけが付けられると明言しています。つまりカーネルは責任の所在を人間に固定する方法で問題を解き、GCCはそもそも入ってくるものを制限する方法で解きます。カーネル側の合意は2025年のメンテナーサミットでSasha Levinが押し進めた三原則の上に立っています — 人間の責任は交渉不可、人間のレビューのない純粋な機械提出物は歓迎しない、ツール使用は公開する。

Debianはまだ進行中です。2026年7月24日に議論期間が始まった総選挙に五つの案が上がっており、Matthias Geigerの全面禁止案からLucas Nussbaumの条件付き許可案、Ian Jacksonの自制勧告案、Pierre-Elliott Bécueの指針付き許可案、Marc Haberの中立案まで幅が広いです。興味深い設計の一つは、範囲がDebian自体の作業に限定されアップストリームは対象外である点です。Linuxカーネルをパッケージ化しなければならない配布版が、カーネルのAI方針まで規律することはできませんから。

Qtについては確認できませんでした。 Qtプロジェクトの貢献ガイドラインにAI生成コードに関する明示的な条項を、この記事を書いている時点で見つけられませんでした。他のプロジェクトと同じ表に入れる根拠がなく外しました。

全体の地形を数字で見るとGCC側は少数派です。Andre HoraとRomain Robbesが GitHubのスター数上位1,000リポジトリを調査した研究によれば、AI方針を持つ118リポジトリのうち78パーセントがAI補助の貢献を許可し(51パーセントは明示的に歓迎、27パーセントは推奨しないが許可)、22パーセントが明示的に自制を求めました。51パーセントが公開を求め、74パーセントが人間の介入を義務化しました。

貢献者にとって実際に変わること

方針文書を実務に翻訳するとこうなります。

GCCにパッチを送るなら、15行以上のコードや文書についてはモデル出力を手直しする方法で書いてはいけません。これは「バレなければいい」という問題ではなく、DCO署名の正直さの問題です。逆にコードを理解するため、バグを見つけるため、他人のパッチをレビューするためにモデルを使うのは何の問題もありません。テストケースはメンテナーの裁量で受け付けてもらえるので、事前に聞いておくのがよいでしょう。

# GCC: 人間が書いたパッチがAIツールの補助を受けた場合
Signed-off-by: Your Name <your@email>
Assisted-by: <ツールとモデルの表記>

# Linuxカーネル: 形式が明示されている
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Signed-off-by: Your Name <your@email>

複数のプロジェクトに貢献するなら、トレーラーがプロジェクトごとに異なる点を考慮する必要があります。Assisted-by:が事実上の標準へ収束しつつありますが、形式と意味はまだ統一されていません。カーネルではこのトレーラーは規範的な承認ではなく、モデル別のバグ群を後で追跡するための鑑識的な装置に近いです。同じタグがプロジェクトによって異なる目的を持つということです。

グレーゾーンが一つ残ります。 IDEの自動補完はどこに属するのか。一行の補完は15行基準を超えませんが、一セッションの間に数十回の補完を受け入れた結果物はどう数えるのか。どのプロジェクトの方針もこの問題にきれいな答えを与えていません。実務的には「自分がこのコードを最初から説明できるか、レビュアーの質問に答えられるか」が唯一機能する自己検証基準です。奇しくもGCCの方針が明示的に求めているのも正確にそれです。

この論争の両側

一方に結論を出さず、実際に分かれる地点を整理します。

制限を支持する側の論拠。 コピーレフトは著作権の上に立っており、出所が不明確なコードはその土台を蝕みます。30年以上積み重ねてきたリポジトリに取り消せない汚染が入れば、後で濾過する方法がありません。しかもレビュー負担が実在します — もっともらしいが間違ったパッチを濾過するコストがメンテナーに転嫁され、curlが方針に「レビュー時間を正当化できない貢献」という表現を入れたのがこの負担の証拠です。Gentooが挙げる三つの理由(著作権、品質、倫理)のうち前の二つはプロジェクト運営の観点から反論しにくいです。

許可を支持する側の論拠。 第一に執行不可能性です。提出されたコードがAIで作られたかを判別する信頼できる方法がないため、禁止は正直な貢献者だけを濾過し不正直な貢献者はそのまま通過させます。第二に定義のあいまいさです。「由来」を広く読むと、検索で見つけたStack Overflowの回答とモデルが教えてくれたAPI使用法の境界があいまいになります。第三にアクセシビリティです — GCCの方針がアクセシビリティツールを明示的に許可したことは、この反論が実際に提起されたことを示しています。第四に、上流がすでに使っています。Debianが範囲を自身の作業に限定したのは、この現実を認めた設計です。

二つの陣営が実際に同意する点もあります。 人間が責任を負うこと、ツール使用を明かすこと、人間のレビューのない機械提出物は受け付けないこと。カーネルの三原則とGCCの要求事項はこの点で事実上同じです。違いは原則ではなくどこに敷居を置くかです。カーネルは人間の署名に置き、GCCはコードの出所に置きます。

私が見るに、この違いを生む本当の変数はプロジェクトの法的構造です。FSF著作権譲渡という執行装置を維持するプロジェクトと、DCOだけで回るプロジェクトは、同じリスクを異なる形で引き受けます。だから「誰が正しいか」よりも自分のプロジェクトがどちら側の構造かを先に見るほうがよいでしょう。

おわりに — この方針はコード品質ではなく出所の履歴に関するものです

三行に縮めるとこうなります。

GCCの線は15行で、その根拠はAIコードの品質ではなくGPLを執行するには出所の履歴が途切れてはならないということです。だからテストケースは例外であり、個人使用は自由であり、コミットトレーラーが新たに要求されます。
地形は分かれています。カーネル・curlは公開を条件に許可し、GCC・Gentoo・NetBSD・QEMUは制限し、Debianは五つの案を巡って投票中です。上位1,000リポジトリ基準では許可が多数派です。
二つの陣営が同意するのは人間の責任、ツールの公開、無検証提出物の拒否です。分かれるのは敷居の位置で、その位置はプロジェクトの法的構造が決めます。

貢献者として今できる最も実用的な備えは、方針文書を暗記することではありません。送るパッチについて最初から最後まで説明できる状態を維持することです。どのプロジェクトの方針も、結局はその一点を違う形で表現しているにすぎません。