GHCがLLM支援コントリビューションポリシーを採択――人間の作者にコード全行の説明を義務付け

2026年10月、GHCプロジェクトは具体的なポリシー文書を採択し、LLM支援によるコード貢献を明示的に認める一方、人間の作者がコードおよびドキュメントの全行を説明できることを義務付けた。同文書はSimon Peyton Jonesが起草し、ghc-devsメーリングリストでの議論を経て確定した。優先事項の第一条は「人とコミュニティを最優先に考える」とされている。

ポリシーの4つのコア要件

第1点は、コントリビューターとレビュアーの直接的なやり取りを人間主導で行うことを求め、LLMが生成したテキストで個人の判断を代替してはならないとする。第2点は、プルリクエストをレビューしやすい状態に保つことを求め、コントリビューターはレビュアーが内容を理解するために必要な労力をはるかに超える作業——明確な目標、設計説明、例示、テストを含む——を投入しなければならないとする。第3点は人間の作者としての立場と全責任を明確化し、識別可能な人間がコードの全行を説明できなければならないとする。第4点は、LLMが直接生成したコンテンツを使用した場合の開示を義務付ける。第5点は強い推奨事項として、コントリビューターが最終版を自ら執筆することが望ましいとしつつ、強制要件ではないとしている。

ポリシー文書は、プロジェクトとしてLLMの利害得失についていまだ合意に達していないことを明記しており、そのためコントリビューションとレビューに関する期待事項のみを定義するにとどめていると説明している。

レビューコストが実質的な制約に

GHCは現在6,500件を超えるオープンなチケットを抱えており、複雑なコンパイラの問題もあれば、日常的ではあるが有用なタスクも含まれる。ポリシー策定者は、低コストで生成されたパッチがレビュー負担を増大させるだけでは意味がないと指摘している。20分で生成されたパッチであっても、メンテナーが推論プロセスを再構築するために数時間を費やす可能性がある。Well-Typed.comが2025年4月に公開した記事では、開発者がGHCおよびCabalのタスクにCursorやClaude-3.7-sonnetといったツールを使用する際、有効なフィードバックを得るためにHaskell Language Serverをコンテキスト提供に組み合わせる必要があったことが記録されている。

他プロジェクトとの違い

Explainx.aiの概況整理によると、OpenJDK、Zig、ClojureおよびQEMUはAI生成コードに対して制限または禁止の姿勢をとっているのに対し、GHCは開示と責任の要件を付したうえでこれを認める選択をした。なお、同ポリシーはチケット報告には適用されず、初期のプルリクエストは未完成または生成されたコンテンツを含んでいても、明確に明示されていれば許容される。

背景にあるメカニズムの分析

今回のポリシー改定は、2026年夏のコミュニティ議論を契機としている。初期草案は3点のポリシーと1項目の推奨事項としてまとめられていたが、その後4点のポリシーと1項目の強い推奨事項へと発展した。元の「共有声明」の著者はそれがコントリビューションポリシーではないと明確に述べたため、採用されなかった。実際の推進要因はメンテナーの時間不足であり、ポリシーはLLM技術そのものへの価値判断ではなく、コントリビューターの事前投入を高めることで後続のレビューコストを削減することを目的としている。

産業への影響についての見解

このポリシーは、他のHaskell関連オープンソースプロジェクトが応用可能なテンプレートを提供している。すなわち、ツールの使用を認めつつ、人間の責任範囲を明確に規定するという枠組みである。実施面では、コントリビューターが変更の論理を人間の言葉でレビュアーに説明できるかどうかが、実質的な執行力を左右する。コスト対効果の観点では、同等のレビュー品質を維持しつつコントリビューターの事前投入を増やすことで、メンテナーの総所要時間を削減できる。ポリシーはLLMが必ずしも生産性を向上させると約束するものではなく、開示と責任のメカニズムを通じて低品質な生成コンテンツを選別することを目指している。

独自評価：GHCのポリシーは現段階においてツールの利用可能性とコミュニティの持続可能性のバランスをとるものであり、その効果は今後の運用においてレビュアーの実際の時間投入が減少するかどうかにかかっている。