GCC

GCC、AIポリシー策定の作業部会を設置

LinuxカーネルとQEMUが正反対の答えを出した問いに、GNU Compiler Collectionがいま向き合い始めた。AI生成コードを受け入れるか、拒むか。最初の答案は3カ月以内に提出される。

情報の灯台

2026年4月25日

ついにGCCもこの議論に踏み込む

GCC(GNU Compiler Collection)の運営委員会(Steering Committee)が、コンパイラ開発におけるAIと大規模言語モデル(LLM)の扱いを検討する作業部会を設立した。

リードを務めるのは、Red Hatに所属するジョナサン・ウェイクリー(Jonathan Wakely)。libstdc++の主任メンテナを長年務めてきた人物で、ISO C++標準化委員会のライブラリ・ワーキンググループの議長も担っている。実装の現場と標準化の議論を行き来してきた経歴は、この種のポリシー議論の主導役として申し分ない。

ボランティアとしてカルロス・オドネル(Carlos O'Donell)、スダクシナ・ダス(Sudakshina Das)、ジェイソン・メリル(Jason Merrill)が参加する。オドネルは「GNUツールチェイン全体で整合の取れたAIポリシー」を志向していると、Wikiページ上の自己紹介に明記している。GCC単体ではなく、glibcやbinutilsを含むGNUツールチェイン全体を見据えた動きだ。

なぜいま、GCCで

きっかけは、AIやLLMがGCCの開発プロセス、つまりコンパイラ本体の実装やコードレビュー支援に「どこまで関与してよいのか」という問いに、開発者間で見解が割れてきたことにある。

GCC Wikiの作業部会ページには、検討の出発点がこう記されている。

貢献者は、自分が手がける作業の全部または一部にAIを使えるのかを知りたがっている。GCCはAI技術の利用について、貢献者に適切なガイダンスを与える方針を持つべきだ。

問いの立て方そのものは穏当に見える。だが、この穏当さの裏には、すでに同種の議論を経て正反対の結論にたどり着いた先行プロジェクトの存在がある。GCCが「いま」これを始めるのは、もはや沈黙が事実上の容認と受け取られる段階に入ったからだ。

LinuxカーネルとQEMU、二つの極

参考になるのは、隣接する2つのプロジェクトの選択だ。

Linuxカーネルの「使ってよい、ただし全責任は人間が負う」

Linux カーネルは長い議論の末、Linux 7.0のリリースに合わせてDocumentation/process/coding-assistants.rstという公式文書をマージした。AIアシスタントの利用そのものは禁止しない。ただし、出力されたコードの一行一行について、書いた本人と同等の責任を貢献者が負う、という立場をとる。

この合意に至る道のりは平坦ではなかった。NVIDIAのカーネル開発者サシャ・レビン(Sasha Levin)が2025年6月のOpen Source Summit North Americaで、Linux 6.15にマージされた自分の名義のパッチが実はLLMによる完全自動生成だったと自ら明かしたところからコミュニティの議論が一気に動いた。レビンは7月にAI支援パッチの開示ガイドラインを提案。最終的にLinux 7.0で採用されたのは、レビン当初案の「Co-developed-by」ではなく「Assisted-by」という新タグだった。

リーナス・トーバルズの姿勢も一筋縄ではいかない。AIに関するドキュメント整備の議論では「AIスロップ問題はドキュメントでは解決しない」と一蹴し、AI固有のルールを書き加えることに否定的な見解を示している。一方で、自身の趣味プロジェクトAudioNoiseでは、Google AntigravityというAIコーディングツールを使ったことを明示している。

QEMUの「拒否」

対照的なのがQEMUだ。Red Hatのダニエル・ベランジェ(Daniel P. Berrangé)が2023年に提案し、紆余曲折を経て2025年に合意に至ったポリシーは、より厳格な立場を取る。

AIコード生成器の出力に関するライセンスの法的位置付けは、現時点で広く受け入れられた見解が確立していない。AI生成コードを含むパッチについて、貢献者がDCOの条項(b)または(c)への準拠を主張することは現状信頼に足らない。

DCO(Developer Certificate of Origin)は、貢献者が「このコードを提出する権利を持っている」「これは自分の仕事である」ことを誓約する仕組みだ。AI生成コードの著作権ステータスが不透明な以上、その誓約自体が成り立たない、というのがQEMU側の判断である。法的リスクの不確実性を理由に、知り得る限りのAI生成コードを拒否する。

GitHub Copilot、ChatGPT、Claude、コーディングエージェントが具体例として挙げられている。ただし、APIや関数の調査、デバッグ、ブレインストーミング、静的解析といった「コードそのものを生成しない用途」は除外されている。

GCCが置かれた中間地点

LinuxカーネルとQEMU、この両極の間で、GCCはどこに着地するのか。Wikiページに書かれた現時点のゴールはこうだ。

作業部会の目的は、運営委員会が採用を検討するための初期的な暫定推奨AIポリシーを起草することにある。

加えて、より踏み込んだ詳細ポリシーが別の作業部会で起草される間、より単純な初期ポリシーを先行リリースすべきかどうか自体も検討対象に含まれる。Wikiでは、その単純な初期ポリシーの例として「LLMベースの支援技術の使用は許可される」といった整理を挙げている。

つまり、GCCはいきなり完成版のポリシーを目指すのではなく、まず暫定版で議論の足場を作る構えだ。Wikiにある「初期評価は3カ月以内」という記述が、その時間感覚を示している。

初期評価のタイムラインは3カ月以内とする。

Wikiページのステータス欄には「2026年4月16日:AIポリシー作業部会の草案を作成」とだけ記されている。最終更新者の欄に並ぶのは、リード役のジョナサン・ウェイクリー本人の名前だ。議論は始まったばかりである。

ツールチェインの「土台」が抱える固有の重み

GCCを含むGNUツールチェインは、ほぼあらゆるオープンソースソフトウェアのビルドに関わるという点で、エコシステム全体の地盤に近い位置にいる。

Wikiの「Background on the Problem」セクションでも、Linuxカーネル、QEMU、ディストリビューション全体がすでに暫定的なAIポリシーを公表していることが明記されている。GCCが沈黙を続けるほど、上に乗る無数のプロジェクトが「コンパイラ自体は何を許容しているのか」を判断材料にできない状態が続く。

そして、コンパイラのバグは静かに広がる。最適化パスに紛れ込んだ誤りは、ユーザー空間のプログラム全体に波及しうる。AIが書いた最適化コードを誰がどう検証するのか、検証コストは誰が負うのか。判断の重みが違う。