2026年、OpenJDKは生成AIが作ったコードをContributionへ含めることを禁止した。

現在公開されている「Interim Policy on Generative AI」では、LLMや拡散モデルなどによって全部または一部が生成されたコンテンツをOpenJDK Communityへ提出してはならないとしている。

対象はソースコードに限らない。Gitリポジトリ内の文章や画像、GitHubのPull Request、メール、Wiki、JBS（Java Bug System）のIssueまで含まれる。

https://openjdk.org/legal/ai

openjdk.org

AI Codingが急速に広がっている時期だけに、かなり強い方針だ。

似た判断をしているOSSはほかにもある。ClojureはLLM生成コードを受け付けず、NetBSDはLLM生成コードを原則として「tainted code」と扱う。GentooもAI支援で作られたContributionを禁止している。

さらにtldrawは2026年1月、AIによって完全生成されたContributionの増加を理由の一つとして、外部Contributorから届くPull Requestを原則自動Closeする暫定方針を始めた。

一見すると、OSSがAIを拒み始めているようにも見える。ただ、各プロジェクトが警戒しているものは少しずつ違う。

コードの権利を保証できるのか。安全性を確認できるのか。Contributor本人が変更を理解しているのか。そして、増え続ける変更を誰がレビューするのか。

最後の問題は、OSSに限った話ではない。企業でもAI Codingによって実装量やPull Requestが増えた一方、Code ReviewやQA、Security Reviewの処理能力が同じ割合では増えなければ、その後ろに仕事が溜まっていく。開発部門の数字は良くなったのに、QA部門では確認対象だけが増えている、ということも十分あり得る。

OpenJDKの新しい方針を起点に、コードを書くコストが下がったあと、その負荷がどこへ移るのかを考えてみたい。

OpenJDKが止めているのはAIの利用そのものではない

OpenJDKの暫定ポリシーは厳しいが、開発中に生成AIを使うことまで全面的に禁じているわけではない。

既存コードを理解する、デバッグする、レビューする、OpenJDKについて調査するといった私的な利用は認められている。禁止されるのは、そこで生成された内容をContributionへ含める場合だ。

FAQでは、生成AIに100行のコードを書かせて10行を自分で修正した場合でも、残りにAI生成部分が含まれていれば提出できないと説明されている。

使い方OpenJDKの暫定ポリシー
既存コードの説明をAIに聞く可能
デバッグやレビューの補助に使う可能
AI生成コードをPRへ含める不可
AI生成文章をIssueやメールへ使う不可
AI生成コードを一部だけ手直しして提出する不可

OpenJDKが挙げているリスクは、Reviewer burden、Safety and Security、Intellectual Propertyの3つだ。

生成AIを使えば、もっともらしいコードやテストを短時間で大量に作れる。しかし、生成速度が10倍になったとしても、安全性や設計を確認するReviewerまで10倍速くなるわけではない。

JDKは多くのJavaアプリケーションやフレームワークの土台でもある。小さな不具合や互換性問題でも影響が広がる可能性があり、「動いた」という確認だけでは足りない。

さらにOpenJDKへのContributionではOracle Contributor Agreement（OCA）が関係する。AI生成物の出所や権利をContributorがどこまで保証できるかという問題も残る。

こうした確認をContributionごとに行うより、暫定的に生成AI由来の内容を受け付けない。OpenJDKは現在、その運用を選んでいる。

AIを禁止・制限する理由はプロジェクトごとに違う

ほかのOSSも並べると、「AI禁止」という言葉だけでは中身を説明しきれないことが分かる。

プロジェクト主に問題としているもの現在の対応
OpenJDKレビュー負荷、安全性・セキュリティ、知的財産AI生成ContentをContributionへ含めない
ClojureContributor Agreementと権利関係LLMなどが生成したコードを受け付けない
NetBSDコードの出所とライセンスLLM生成コードを原則tainted codeとして扱う
Gentoo著作権、倫理、品質NLP系AIの支援で作られたContributionを禁止
tldrawMaintainerのレビュー負荷、文脈不足、Contributorの継続的な関与外部PRを原則自動Closeする暫定運用
GraalVM人間の説明責任と権利確認AI支援を許可し、Contributorが全責任を持つ

ClojureはContributor Agreementとの整合性を重視する

ClojureのContributor Agreementページには「No Generated Code」という項目がある。

Clojureのコードは人間が書き、人間がレビューするものとし、LLMなどによって生成されたコードはContributor Agreementの表明・保証と整合しないため受け付けないとしている。

https://clojure.org/dev/contributor_agreement

clojure.org

ここで重いのは、AIコードそのものの品質よりも、そのコードをContributionとして提出する権利をContributorが保証できるかどうかだ。

NetBSDはLLM生成コードを原則「tainted code」とみなす

NetBSDのCommit Guidelinesには、LLMや同様の技術で生成されたコードは原則としてtainted codeとみなし、Core Teamの事前の書面承認なしにはCommitしてはならないと明記されている。

https://www.netbsd.org/developers/commit-guidelines.html

www.netbsd.org

NetBSDには、もともと自分以外が書いたコードを取り込む際にライセンスや出所を確認するルールがある。AI生成コードも、その延長線上で扱われている。

Gentooは著作権だけでなく倫理と品質も挙げる

Gentooは2024年に、Natural Language Processing系のAIを使って作成されたContributionを禁止する方針を採択した。

挙げられている懸念はcopyrightだけではなく、ethicalとquality concernsまで含む。Gentoo Wikiにも、AI支援で作られたContentを投稿してはならないことが明記されている。

https://wiki.gentoo.org/wiki/Gentoo_Wiki:Contribution_requirements

wiki.gentoo.org

ClojureやNetBSDが権利や出所を強く意識しているのに対し、Gentooは品質や倫理まで含めて広く問題を捉えている。

tldrawはAIだけでなく外部PRの入口まで絞った

レビュー負荷の問題が分かりやすく表れたのがtldrawだ。

2026年1月、tldrawは外部Contributorから届くPull Requestを自動的にCloseする方針を発表した。Issue、バグ報告、Discussionは引き続き歓迎するが、PRはいったん閉じ、実際に検討するものを選んでReopenする。

Contributions policy · Issue #7695 · tldraw/tldraw

Hey all, update on the tldraw policy with regard to contributions. For the good of the project, we're going to begin automatically closing pull requests from external contributors. We will of cours...

https://github.com/tldraw/tldraw/issues/7695

GitHub · github.com

背景には、AIツールによって完全生成されたContributionの大幅な増加がある。

形式上は正しいPRであっても、コードベースへの理解が浅い、不完全または誤解を招く文脈が付いている、提出後にContributorがほとんどフォローしない、といったケースが多かったという。

tldrawは、OpenされたPull RequestそのものをMaintainer側のコミットメントとして捉えている。PRがOpenなら、Maintainerは内容を読み、設計を考え、取り込めるか検討し、必要ならContributorとやり取りする。

PRを作る側がAIによって数分で作業を終えられても、受け取る側の作業はほとんど消えない。

Contributor
AIで変更を生成
PRを作るコスト ↓↓↓

        ↓

Maintainer
背景を読む
コードを読む
設計を確認する
テストする
やり取りする
レビューコスト → 大きくは下がらない

生成する側と確認する側では、AIによるコスト低下の幅が違う。OpenJDKが「reviewer burden」を明記しているのも、この問題と無関係ではない。

GraalVMは人間が責任を持つ前提でAI支援を認める

同じOracleが関わるGraalVMは、AI Coding Assistantを使ったContributionを認めている。

graal/CODING_ASSISTANTS.md at master · oracle/graal

GraalVM compiles applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀 - oracle/graal

https://github.com/oracle/graal/blob/master/CODING_ASSISTANTS.md

GitHub · github.com

GraalVMでは、提出した人間がAI支援部分を含むContribution全体に責任を持つ。コード、テスト、ドキュメント、Commitメッセージを自分で確認して理解し、Reviewerから質問されたときに説明し、その後も保守できることが求められる。

説明、擁護、保守ができないAI支援の変更は拒否される可能性がある。

OCAや通常のライセンス要件もそのまま適用される。Contributorは提出する権利があることを確認し、利用したCoding Assistantの規約がプロジェクト側の義務と衝突しないことまで確認しなければならない。

OpenJDKとGraalVMは、同じ問題に対して運用の仕方が違う。OpenJDKは生成物を受け付けないことで不確実性を減らし、GraalVMはAI支援を認めたうえで、その責任を人間のContributorに持たせている。

企業でも実装だけ速くなれば、その後ろが詰まる

OSSで表面化しているレビュー負荷は、企業の開発組織でも起こり得る。

AI Coding導入前の流れを単純化すると、次のようになる。

企画
 ↓
実装
 ↓
Code Review
 ↓
QA
 ↓
Release

このうち実装チームだけがAIによって大幅に速くなったとする。

企画
 ↓
実装 × 2
 ↓
Code Review × 1
 ↓
QA × 1
 ↓
Release × 1

実装量が2倍になっても、会社全体の開発速度がそのまま2倍になるとは限らない。Code ReviewかQA、あるいはその後のSecurity ReviewやRelease判定の前に待ち行列ができるからだ。

開発部門から見れば、以前より多くのIssueを実装でき、Pull Requestも増えている。AI導入の成果は数字にも出やすい。一方で、QA部門の人数や予算が変わらなければ、確認対象だけが増える。

AI生成コードによってQAからの戻しまで増えれば、部署ごとの見え方はさらに離れる。

開発部門
「AI導入で実装量が増えた」

          ↓ PR増加

QA部門
「確認対象が増えた」
「仕様確認も減っていない」
「修正依頼のやり取りも残っている」

部署ごとにKPIや予算が分かれている会社では、この差が不満につながりやすい。実装部門で短縮できた時間の一部をQAやReviewerが追加の確認作業として引き受けていても、「AIで開発が速くなった」という数字だけでは見えにくい。

DORAでも書く時間が検証へ移る問題が指摘されている

DORAが2026年3月に公開した分析では、2025年の調査を踏まえ、AIは初期のコード生成を速くする一方、作成で節約した時間が監査や検証へ再配分されることがあると説明している。

DORA | Balancing AI tensions: Moving from AI adoption to effective SDLC use

DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.

https://dora.dev/insights/balancing-ai-tensions/

dora.dev

DORAはこれを「verification tax」と表現している。

調査では、AI利用による個人の速度向上がReviewer側の認知負荷増加へ移る問題も挙げられている。AuthorはAIで大きな変更を短時間で作れるが、Reviewerは依然として各行の正しさや意図を確認しなければならない。

また、AI採用率の高さはSoftware Delivery Throughputの向上と関連する一方、Software Delivery Instabilityの増加とも関連しているという。

コード生成が速くなった効果は確かにある。ただ、その短縮分がReviewやTestingへ移れば、開発プロセス全体で得られる効果は小さくなる。

QAにもAIは使えるが、実装と同じ倍率では速くならない

QAやCode ReviewにもAIを使える。

テストケースの下書き、E2Eテスト作成、テストデータ生成、ログ解析、回帰テスト候補の抽出など、短縮できる仕事は多い。DORAの調査でもTestingやCode ReviewはAI活用が見られる領域として挙げられている。

それでも、実装とQAが同じ倍率で速くなる保証はない。最後まで残りやすいのは、「この挙動は仕様として正しいのか」という判断だ。

AI Coding
「仕様をこう解釈して実装した」

AI Test
「同じ解釈を前提にテストを作った」

人間
「そもそも仕様の解釈が違う」

AIが実装とテストの両方を作れるようになっても、同じ前提の誤りが両方へ入る可能性は残る。

QAへのAI導入は有効でも、「実装が2倍になったのでQAもAIで2倍にする」という計算だけでは足りない。自動化できる確認、人間の判断が必要な確認、AI導入後に待ち時間が増えた工程を分けて見る必要がある。

PR数やコード量だけではAI導入の成果を測れない

AI Codingの効果をPull Request数や生成コード量だけで測ると、下流の負荷を見落としやすい。

DORAも2026年の分析で、AIはコード量を簡単に増やせるため、狭いOutput指標だけを生産性として扱うべきではないとしている。

開発組織で見るなら、次のような数字も一緒に追いたい。

見る場所例
実装Issue着手からPR作成までの時間
ReviewPRがReview待ちになっている時間、差し戻し回数
QAQA待ち時間、QAからの戻し率
Delivery変更が本番へ届くまでのLead Time
Quality障害、Rollback、再修正、Productionで見つかった不具合

AI導入後にPR作成までの時間だけ短くなり、Review待ちやQA待ちが伸びているなら、開発全体が速くなったとは言いにくい。

ReviewやTesting、仕様参照、CIにもAIを組み込み、下流の待ち時間まで短くなっているなら、そこで初めて組織全体への効果が見えてくる。

OSSのAI制限は企業にとっても他人事ではない

OpenJDK、Clojure、NetBSD、Gentoo、tldrawは、それぞれ別の理由でAI生成物やContributionの入口を制限している。

OpenJDK
生成物を入口で止める

Clojure / NetBSD
権利や出所を保証できない生成コードを止める

Gentoo
著作権・倫理・品質上の懸念からAI支援Contentを止める

tldraw
レビュー能力を守るため、外部PRの入口そのものを絞る

GraalVM
AI支援を許可し、人間にContribution全体の責任を持たせる

どの方針にも、コードを作ることと、そのコードを受け入れて保守することの間にあるコストが表れている。

OSSでは、AIによって世界中からContributionを作れる速度が上がっても、Maintainerの人数やレビュー時間を同じ割合で増やすことは難しい。その結果、Contribution Policyで入口を制御する判断まで出てきた。

企業にはもう少し選択肢がある。ReviewerやQAの体制を変える、自動テストやCIへ投資する、仕様や社内ドキュメントをAIから参照しやすくして実装時点の誤りを減らす、といった手段を取れる。

OpenJDKの方針を、そのまま企業へ持ち込む必要はない。ただ、実装チームの生産性だけを上げた場合、その増加分を誰が受け取るのかは先に考えておいた方がいい。

AI CodingでPRが2倍になったなら、Review待ちはどうなったか、QAの負荷はどうなったか、差し戻しや障害は増えていないかまで見て、初めて導入後の変化が分かる。

コードを書くコストは急速に下がっている。一方、コードが正しいことを確認し、権利を確認し、仕様に合っていると判断し、長く保守する仕事まで同じ速度で安くなったわけではない。

OpenJDKのAI禁止は、その差がOSSのContribution Policyにまで表れ始めた一例だ。企業でAI Codingを導入するときも、実装部署の速度だけでなく、そのコードが本番へ届くまでの流れを一緒に見ておきたい。