何が決まったのか
GCCは、C/C++などで書かれたソースコードを実行できる形へ変換するコンパイラ群です。そのプロジェクトが、AI生成コードについて公式に線を引きました。
作業部会の案を運営委員会が承認した
2026年7月29日、GCCの運営委員会（Steering Committee）が、GCC AIポリシー作業部会の提案した方針を受け入れたことがメーリングリストで告知されました。告知したのはDavid Edelsohn（デビッド・エデルソン）氏です。
作業部会を率いたのはJonathan Wakely（ジョナサン・ウェイクリー）氏で、メンバーとしてCarlos O'Donell、Sudakshina Das、Jason Merrill、Joel Sherrill、Sam James、Robin Dapp、Arthur Cohenの各氏の名前が挙げられています。方針は今後も進化し続けることが見込まれ、定期的に見直すとされています。
The GCC Steering Committee has accepted the recommended policy of the GCC AI Policy Working Group. The policy is described in the following document preview / pull request in Forge, which will be committed to the GCC website: ／ We expect the policy to continue to evolve and will revisit it periodically. We wish to thank Jonathan Wakely for his leadership of the working group and the members of the working group: Carlos O'Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp, and Arthur Cohen. — 運営委員会による承認と、作業部会の構成に関する告知より
受け入れの線引きは「法的に重要かどうか」
ポリシーの中心は1文です。当面のあいだGCCは、LLM生成物を含むか、それに由来する「法的に重要な」貢献を、すべて拒否する。
逆に、法的に重要でない範囲であれば、LLMが生成した貢献をメンテナが受け入れても構わないとされています。ただし条件が2つあります。通常どおりの貢献に求められる前提条件を満たしていることと、その貢献がAI生成であると明確に示されていることです。
つまり構造としては「AI生成コードの全面禁止」ではありません。著作権上の重みが出る大きさになった時点で受け付けなくなる、という設計です。
For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content. The GCC maintainers are free to accept legally insignificant contributions generated by an LLM as long as they meet the usual prerequisites for any contribution and the contribution is clearly marked. — 拒否の対象となる貢献と、受け入れが認められる条件に関する記述より
テストケースだけは例外になっている
ひとつ例外が置かれています。テストケースへの貢献については、全体または一部がLLMによって生成されていても、法的に重要な規模であってもメンテナが受け入れて構わないとされています。
もうひとつ、このポリシーが適用されない範囲も明記されています。GCCプロジェクトに本来属さないコード、つまり利便性のためや前提条件を満たすために他のプロジェクトから取り込んだコード（例として libsanitizer が挙げられています）は対象外です。
As an exception, the GCC maintainers are free to accept legally significant contributions to test cases, generated in whole or in part by an LLM. ／ This policy does not apply to code which does not primarily belong to the GCC project, but is imported from other projects for convenience or to satisfy prerequisites (e.g. libsanitizer). — テストケースの例外と、適用外となるコードに関する記述より
「15行」はどこから来たのか
「15行以上のAI生成コードを拒否」という要約がよく使われます。方向としては合っていますが、その数字の出どころは別の文書です。
ポリシー本文に「15行」は一度も出てこない
GCCのAIポリシーの全文を通して、行数への言及はありません。受け入れの可否を分ける基準として書かれているのは「legally significant（法的に重要）」という語だけです。
つまり、行数はGCCが新しく決めた基準ではありません。GCCは既存のGNUの著作権基準をそのまま持ち込んで、その上に「LLM生成物なら受け付けない」という条件を重ねた形になります。ここを取り違えると、「GCCが15行という独自ルールを作った」という誤解が生まれます。
For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content. — 可否の基準が行数ではなく「legally significant」という語で書かれていることを示す記述より
GNUが定める著作権の敷居がその数字だった
出どころはGNUソフトウェアのメンテナ向け規定です。そこにはこう書かれています。著作権上、法的に重要なコードや文章をおよそ15行を超えて提供する場合、その貢献について著作権の書類が必要になる。そして、数行程度（15行未満くらい）の変更は著作権上は法的に重要ではない、と続きます。
さらに具体例も添えられています。シンボル名の変更のように、同じ変更を規則的に繰り返す種類のものは、多くの箇所で置き換える必要があったとしても法的に重要ではない、という判断です。
If a person contributes more than around 15 lines of code and/or text that is legally significant for copyright purposes, we need copyright papers for that contribution, as described above. A change of just a few lines (less than 15 or so) is not legally significant for copyright. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places. — 15行という敷居の定義と、規則的な繰り返し変更の扱いに関する記述より
小さな変更でも積み上がれば重要になる
ただし、この規定には見落としやすい但し書きがあります。同一人物による小さな変更の連なりは、合計すると重要な貢献になりうるというものです。
数えるのはその人の総貢献量であって、どの部分がいつ提供されたかは関係ないとされています。実際、小さなパッチを記録する際にはまず同じ人物の過去の変更を検索し、過去分と新しい分を足して法的に重要な量になっていないかを確認せよ、と手順まで書かれています。
この点をGCCのポリシーに当てはめると、「毎回15行未満に収めればAI生成コードを入れ続けられる」とは読めないことになります。同じ人が小さなLLM生成パッチを積み重ねれば、いずれ法的に重要な量へ達するからです。
自分の変更が累計でどれくらいの量になっているかは、差分を並べれば見当がつきます。手元のパッチが何行動いているかを確かめたいときは、差分表示のツールが早いです。
無料ツールテキスト差分比較2つのテキストの差分をハイライト表示。変更点を素早く発見できます。今すぐ使ってみる →
…Keep in mind, however, that a series of minor changes by the same person can add up to a significant contribution. What counts is the total contribution of the person; it is irrelevant which parts of it were contributed when. — 同一人物による小さな変更が合計で重要な貢献になりうるという記述より
手続きと、適用されない範囲
ポリシーには行数以外の要件も並んでいます。むしろ実務で毎回効いてくるのはこちらです。
Assisted-by は機械、Signed-off-by は人間
透明性と説明責任の項では、LLM生成物を含む貢献のコミットメッセージには Assisted-by: タグを入れなければならないと定められています。
そのうえで、責任の所在が明確に人間側へ置かれています。すべての貢献は、その変更を理解し、質問に答える用意のある人間によって提出されなければなりません。プロジェクトに取り込む判断も人間が行う必要があります。
開発者原本証明（DCO）を証明する Signed-off-by: タグを付けられるのは人間だけです。そして最後に一文、LLMがプロジェクトのリポジトリへコードをコミットしてはならないと明記されています。
The commit message for any contribution of LLM-generated content must include an “Assisted-by:” tag. ／ All contributions must be submitted by a human who understands the changes and is prepared to answer questions about them. The decision to include the contribution in the project must also be made by a human. Only a human may provide the “Signed-off-by:” tag certifying the Developer Certificate of Origin (DCO). An LLM may not commit code to the project repository. — コミットタグの要件と、人間が担う責任範囲に関する記述より
調査・レビュー支援・デバッグは対象外
適用されない範囲も広く取られています。まず個人的な利用です。画面読み上げ、音声合成、翻訳、綴りや文法の支援といった、自分のパソコンなどで作業するための利用は対象外とされています。ただし利用者が出力を検証することが前提です。
もうひとつが開発作業そのものへの利用です。調査・分析・バグの発見と報告・パッチのレビュー・デバッグへの利用は、その出力が貢献物に含まれない限り適用されません。
ここに2つの但し書きが添えられています。バグ報告については「出力を十分な検討なしにそのまま送るべきではない」、パッチレビューについては「人のレビューを支援するものであって置き換えるものではない」。そして、出力が貢献物に含まれるならこのポリシーが適用される、と締められています。
This policy does not apply to a contributor's other uses of AI including the use of these tools to enable them to work with their own computing devices e.g. screen readers, text-to-speech, direct translations, spelling or grammar assistance, where the contributor verifies the output of the tool. ／ This policy does not apply to a contributor's use of AI for the purposes of research, analysis, bug discovery and reporting (output should not be sent verbatim without due consideration), patch review (supporting human review, not replacing it) and debugging, so long as the output is not included in the contributions to the project. If the output is included in the contributions to the project then this policy would apply. — 個人的な利用と、調査・レビュー支援・デバッグが適用外となる範囲に関する記述より
2027年初頭までに見直す
方針は固定ではありません。コミュニティの状況やGNUプロジェクト全体の立場の更新に応じて進化することが見込まれ、遅くとも2027年の初めには見直されるとされています。文書自体は CC0 1.0 Universal（著作権上の権利を放棄し、誰でも自由に使える形）で公開されており、他プロジェクトが下敷きにしやすい形になっています。
冒頭に置かれた「コミュニティ第一」の項も特徴的です。LLMについては強く保持され大きく異なる意見があるとしたうえで、全員が誠実に貢献していると推定すべきと書かれています。方針にまだ従えていない貢献者も歓迎し、従い方を案内すべきだ、という姿勢です。
This policy is expected to evolve with the community or as the overall GNU Project position is updated. At the latest the policy will be reviewed at the start of 2027. ／ …There are strongly held and widely varying opinions regarding large language models (LLMs) and everyone should be presumed to be contributing in good faith. We welcome all contributors to the community even if they have not yet followed our policies; we should guide such contributors on how to do so. — 見直しの時期と、コミュニティへの姿勢に関する記述より
まとめ：行数ではなく著作権が線を引いた
このポリシーを「AI生成コードは15行まで」と覚えると、要点を外します。GCCが持ち込んだのは著作権の判断基準であって、コード品質の基準ではありません。LLMの出力が良いか悪いかについて、ポリシーは一言も評価していないからです。
ポリシー本文は拒否の理由を説明していませんが、2つの文書を並べると輪郭は見えてきます。GNUは法的に重要な貢献に対して著作権の書類を求めてきました。LLMが生成したコードについて、その書類を出せる人間がいるのか——問われているのは、そのコードの権利関係を誰が保証できるのかという一点だと読めます。テストケースが例外になっているのも、そこに著作権上の重みが乗りにくいためだと理解できます。
同じ時期に、GoogleがChromeの脆弱性修正にAIを組み込んだ実例を公開しています。そちらでは最終的な採否をすべて人間が判断する形にしていました。DeepSeekのコーディング特化モデルや手元で動かすローカルLLMでの開発が現実味を帯びるほど、「誰が権利と責任を負うのか」を先に決めておく必要が出てきます。GCCが出したのは、その問いに対するひとつの答えです。
