Copilotで書いた10行も駄目——OpenJDKがAIコードを閉め出した

要点（30秒で）: OpenJDKへの貢献物は、LLMが生成した内容をわずかでも含んではいけなくなった。JavaのOSSに手を出すなら、自分のPRが「AI由来ゼロ」だと言い切れるかを先に確認する必要がある。まずは自分のリポジトリのCONTRIBUTING.mdに、AI利用の申告ルールを一行だけでも書いておくといい。

この記事の内容（約12分で読めます）

何が禁じられたのか

「100行のうち10行だけ直した」も通らない

三つの理由と、その重さの違い

同じOracleの中で、線が二本引かれている

Linuxは、逆の道を選んだ

禁止側にも、それなりの先例がある

「Oracleのコードは、Oracleが書いていない」

日本・個人開発の視点

要点まとめ

出典・リンク

Javaの標準実装を作っているOpenJDKコミュニティが、生成AIの出力を貢献物から締め出した。ポリシーの名は「OpenJDK Interim Policy on Generative AI」。2026年4月9日にGoverning Boardの承認を経て公開され、8月に入って英米メディアが相次いで取り上げたことで、ようやく広く知られるところとなった。

騒ぎが大きくなったのは、禁止そのものよりも、それを出した会社の顔ぶれのせいだ。OracleはいまAIデータセンターに年間700億ドル規模を注ぎ込み、創業者ラリー・エリソンは「Oracleのコードは、Oracleが書いていない」と壇上で語っている。書かせている当人が、書かせるなと言った——構図としては、これ以上ないほど分かりやすい。

何が禁じられたのか

ポリシーの中核は一文で終わる。「OpenJDKコミュニティにおける貢献は、大規模言語モデル、拡散モデル、またはそれに類する深層学習システムによって、部分的にせよ全体にせよ生成されたコンテンツを含んではならない」。

対象はソースコードだけではない。Gitリポジトリ、GitHubのプルリクエスト、メーリングリストの投稿、Wikiのページ、そしてバグ追跡システムJBSのチケット——そこに置かれる文章や画像まで、まとめて射程に入っている。つまりコードは手書きでもPRの説明文をAIに書かせたら、それは違反ということになる。

一方で、使うこと自体は禁じられていない。既存コードを読み解く、デバッグする、レビューの下読みをさせる、調べ物をする。そうした私的な用途はむしろ推奨に近い書き方をされていて、同僚に見せる場合もAI生成物だと明示すれば構わないとされる。線が引かれているのは「持ち込むかどうか」の一点だ。

禁止・容認・申告——同じ問いに、OSSが出した三つの答え

「100行のうち10行だけ直した」も通らない

ポリシーに付随するFAQには、実務者が一番知りたい境界が書いてある。AIに100行書かせて、そのうち10行を自分の手で修正した場合はどうか。答えは、それでも駄目。一部でも生成物を含む以上、その貢献はAI生成物を含んだままだからだ。

この判定は厳しいが、論理としては一貫している。「どこまで人が触れば人のものになるか」という問いに、パーセンテージで線を引き始めた瞬間、その線はいくらでも動く。OpenJDKはその議論に踏み込まず、ゼロか否かで切った。

運用面では、PR管理ツールSkaraにポリシー遵守を宣言するチェックボックスが追加される。技術的にAIを検出するのではなく、貢献者の申告に委ねる仕組みだ。もっとも、解説メディアJVM Weeklyによれば、ポリシー本文には見分けの手がかりも列挙されている。不自然なほど陽気で几帳面な書きぶり、やたらとお喋りなコメント、必要のない防御的プログラミング、絵文字、過剰に構造化されたドキュメント——レビュアーが現場で「あ、これは」と感じるあの匂いが、そのまま文書化された格好である。

その貢献物は出せるか——OpenJDKが引いた「ゼロか否か」の線

三つの理由と、その重さの違い

Oracleが挙げた根拠は三つある。一つ目はレビュアーの疲弊。生成AIは、もっともらしいが誤っていたり、保守しづらかったりするコードを大量に投げ込むことを可能にしてしまった。JDKの中核をレビューできる人間の数は限られていて、明らかな粗悪品を弾く作業ですら消耗になる。

二つ目は安全性だ。JDKは世界中のミッションクリティカルなシステムの土台に敷かれている。「もっともらしいが間違っているコード」がそこに入り込む危険は、他のプロジェクトとは桁が違う、という主張である。

三つ目が知的財産。OpenJDKに貢献するにはOracle Contributor Agreement（OCA）への署名が要り、貢献者は自分が必要な権利を持っていると保証しなければならない。ところがAI出力の権利が誰に帰属するのかは、いまも係争中の論点だ。米国著作権局の見解では、プロンプトだけでは著作物性を認めるに足る「支配」があるとは言えない——つまり、署名しようにも保証できる根拠がない。

Hacker Newsで最も支持を集めた読み筋は、この三つ目こそが本丸だというものだった。AI生成物を受け入れてしまえば、Oracleは将来「AIで洗浄されたコード」をめぐって他社を訴える選択肢を、自分の手で狭めることになる。原則の問題ではなく訴訟オプションの温存だ、と。真偽は分からないが、Oracleという会社を知る人ほど、この説明を自然だと感じたらしい。

OSSがAIに線を引くまで——2024年の先例から2026年の分岐まで

同じOracleの中で、線が二本引かれている

面白いのは、この禁止がOracle全体の方針ではないことだ。同じOracle傘下でも、Oracle LabsのGraalVMは真逆の方針を採っている。「GraalVMの貢献者は、貢献物を準備する際にAIコーディングアシスタントや類似のツールを使用してよい」。

GraalVMが求めるのは禁止ではなく説明責任だ。提出した人間が、正しさを検証し、変更内容を理解し、その判断を説明できること。AIを使ったことの開示は「レビュアーが実装上の選択を理解する助けになる場合には推奨される」という、義務ではなく礼儀に近い書き方になっている。OCAへの署名はどちらも必要で、違いはガバナンスの主体——GraalVMはOpenJDKの統治機構の外にある。

つまり同じ会社の中に、同じ法務リスクを抱えたまま、正反対の結論が並存している。The Registerはこの点を突いて、なぜAI生成コードがOpenJDKには不適切で商用製品には適切なのか、その基準を社内コードがどう満たしているのか、Oracleはまだ説明していないと書いた。

Linuxは、逆の道を選んだ

比較対象としてLinuxカーネルを置くと、分岐がよく見える。カーネルは2026年7月15日、リーナス・トーバルズがLKMLで長文を投じ、AIコーディングツールを歓迎する立場を明確にした。異論があるならフォークすればいい、という例の調子で。

成果物はDocumentation/process/coding-assistants.rstという59行の文書で、Linux 7.0向けにマージされた。要点は三つ。AIエージェントは法的拘束力を持つSigned-offAND-byを名乗れないこと、代わりにAssisted-byタグで来歴を残すこと、受け入れるかどうかはメンテナの裁量であること。責任は必ず人間側に残る設計だ。

実際、2026年5月以降はGitHub CopilotやClaude Codeによる修正が、Intel Xeドライバ、Raspberry Piの映像出力、AMDのディスプレイコード、Bluetoothスタック、io_uringといった領域に入り始めている。禁止して匂いで弾くか、通してタグで追跡するか——OpenJDKとLinuxは、同じ問題に正反対の答えを出した。

禁止側にも、それなりの先例がある

とはいえOpenJDKは孤立しているわけではない。QEMUはAI生成物を含むと判断した貢献を受け付けない方針を採っており、理由はDCO（開発者出自証明）を満たせないという一点に絞られている。Gentooの評議会は2024年に全会一致で自然言語AIによる支援を禁じ、NetBSDは同年5月、LLM由来のコードを「汚染された（tainted）」ものとみなし、コアの明示的な許可なしにはコミットできないと定めた。

そして最も生々しいのがcurlだ。作者のダニエル・ステンベルグは、AI生成のバグ報告が流入して全体の2割に達したところでバグバウンティを閉じている。報奨金という動機づけが噛み合っていてすら、人間のレビュー能力が先に尽きた。この事実は、OpenJDKが一つ目の理由に掲げた「レビュアーの負担」が、単なる建前ではないことを裏づけている。

裏を返せば、「93行だけ信じろ」——AIが書いた1000行を読まずに正しさを証明するで扱ったような、生成物の正しさを人間が全部読まずに担保する仕組みが実用に乗れば、この禁止の前提はかなり揺らぐ。禁止は技術的な結論ではなく、現時点の検証コストに対する暫定解なのだ。ポリシーの名前に「Interim（暫定）」と入っているのは、そういうことだろう。

「Oracleのコードは、Oracleが書いていない」

ここで冒頭の矛盾に戻る。エリソンはOracle AI World 2025の壇上で、こう言った。「Oracleが書いているコードを、Oracleは書いていない。我々のAIモデルが書いている」。続けて、プログラムに何をさせたいかをモデルに伝えれば、モデルが手順を組み立てる、我々は意図を宣言するだけで手順は書かない、と。

共同CEOのマイク・シシリアも2026年3月の決算説明で、社内でのAIコーディングツールの活用が、より少人数のエンジニアチームでより完成度の高いソリューションを速く届けることを可能にしている、と述べている。The Registerによれば、Oracleは同年6月に2万1000人規模の人員削減を行い、その理由の一部に「事業全体へのAI技術の展開」を挙げた。

年700億ドルのデータセンター投資、マイナスのキャッシュフロー、AIを理由にした大量解雇。その会社が、自社が管理するOSSプロジェクトでだけ「AIが書いたものは要らない」と言う。矛盾を指摘されるのは当然だが、実のところ両立はしている——リスクを取れる場所と取れない場所を、Oracleは冷徹に切り分けただけだ。商用製品の瑕疵は自社で被れるが、OCA経由で外部から流れ込む来歴不明のコードは、被れない。

日本・個人開発の視点

日本の基幹系は、いまだにJavaの上に厚く積み上がっている。社内でCopilotやClaude Codeの導入が進む企業ほど、OSSに何かを還元しようとした瞬間にこのポリシーとぶつかる。「業務で書いたコードは全部AI補完が入っている」という状態は、もはや珍しくないからだ。

現実的な備えは二つある。一つは、OSSに出す予定のあるコードだけ補完を切った環境で書くという、面倒だが確実な運用の分離。もう一つは、自分が管理する側に回ったときの準備で、CONTRIBUTING.mdに「AI利用を認めるか、認めるなら申告を求めるか」を一行書いておくこと。判断を先送りにしたリポジトリに大量のPRが降ってきてから考えるのは、curlの顛末が示すとおり遅い。

個人開発者にとっては、「書かないのが最高のコード」——44000スターponytailの正体で触れたような「量を出さない」姿勢のほうが、結果的にこの時代のOSSでは通りやすくなるかもしれない。レビュー枠が希少資源になった以上、小さくて説明できる差分の価値は上がる。

要点まとめ

OpenJDKは2026年4月9日、LLM等の生成物を一部でも含む貢献を禁じる暫定ポリシーを公開した。対象はコードだけでなくPR説明・メール・Wiki・課題チケットにも及ぶ。
AIを読解やデバッグに私的利用するのは可。100行のうち10行を手直しした程度では例外にならず、Skaraのチェックボックスで自己申告する運用になる。
理由はレビュアーの負担、JDKの安全性、そしてOCAが求める権利保証をAI出力では満たせないというIPの不確実性の三つ。
同じOracle傘下のGraalVMはAI利用を容認し、説明責任で担保する。LinuxカーネルはAssisted-byタグによる申告制を選んだ。禁止・容認・申告の三つの型が出そろった。
エリソンは「Oracleのコードは、Oracleが書いていない」と語り、同社は年700億ドルのAI投資と2万1000人規模の削減を進めている。この落差はまだ説明されていない。

🐦‍⬛ 編集部の視点

このニュースが刺さるのは、Oracleの矛盾が面白いからではない。「AIが書いたコードの責任は誰が取るのか」という問いに対して、業界が初めて三つの異なる答えを同時に机の上に並べた瞬間だからだ。禁止（OpenJDK・QEMU・Gentoo）、容認（GraalVM）、申告（Linux）。しかもその三つが、Oracleという一社の内側にすら二つ同居している。

そして本当の分岐点は、たぶん検証コストにある。いま禁止が合理的に見えるのは、人間のレビュー能力が希少資源だからで、生成物の正しさを安く証明できる道具が育てば、「Interim」の二文字は静かに外れるだろう。逆に育たなければ、OSSは「信頼できる少数の人間だけが触れる場所」へ縮んでいく。curlのバグバウンティが閉じたのは、その縮小の最初の一歩だったと後から言われるかもしれない。

あなたが今日書いたコードは、どちらの世界に出せるものだろうか。補完を全部切って書き直せと言われて、素直に「はい」と言えるコードが、手元にどれだけ残っているか——このポリシーは、その質問を全員に配って回っているようなものだ。

コメントを残すコメントをキャンセル

2026年、AIは「使うもの」から「任せるもの」へ。海外最新動向で読むAIエージェント時代の本番化

MLPを捨てた14MBのAI——指輪の中で動く45Mモデル

70,900回クロールして1回返す——消えるウェブの記憶

デンマーク、書いた文章を口で守れ——AI不正への即時三点セット

Trending

MLPを捨てた14MBのAI——指輪の中で動く45Mモデル

70,900回クロールして1回返す——消えるウェブの記憶

デンマーク、書いた文章を口で守れ——AI不正への即時三点セット