Oracle、AI生成コードを受け入れる一方でOpenJDKは一線を引く
Oracleは事業全体でAI生成ソフトウェアを取り入れている。しかしGoogle Newsの見出しは、そうしたコードが歓迎されない領域、すなわちOpenJDKの存在を浮き彫りにした。同プロジェクトの暫定ポリシーは、大規模言語モデルや類似システムが一部または全部を生成したコンテンツの投稿を、コントリビューターに禁じている。
この制限は、Oracleの企業戦略と並べると際立つ。Oracleは、AIによるコード生成により小規模な開発チームでもより多くのソフトウェアを生み出せるとしており、同社のクラウド部門はAI顧客を支えるために多額の投資を行っている。つまり同社は、インフラを販売し、ツールを自ら採用しながら、最も重要なオープンソースプロジェクトの一つではその出力を制限している。
この一見した矛盾は実在する。ただし、Oracleが社内ではAIを信頼し、社外では拒絶しているというほど単純な話ではない。OpenJDKには、社内アプリケーションチームとは異なる知的財産、安全性、保守上の責務が伴う。そのポリシーは、生成コードが共有インフラに入る際に、誰が責任を引き受けるべきかという問題も反映している。
したがって中心にある対立は、Oracle対AIではない。自動化された生産と、説明責任を伴うコントリビューションの対立である。Oracleはコーディングエージェントによる生産性向上を望む一方、OpenJDKの保守担当者は、投稿者が十分に説明できないリスクをレビュアーに引き継がせたくないと考えている。
Google Newsの見出しが捉えた、限定的ながら重要な禁止措置
OpenJDKのポリシーが対象とするのは、AIアシスタントのあらゆる私的利用ではなく、コントリビューションとして提出されるコンテンツだ。
OpenJDKのGoverning Boardは2026年3月27日、暫定的な生成AIポリシーを全会一致で承認した。OracleのJava Platform Groupでチーフアーキテクトを務めるMark Reinholdは、4月9日にこの決定を公表した。
この区別は重要である。なぜなら、この規則はコントリビューションのプロセス内では広範に適用されるからだ。OpenJDKは、コントリビューションに大規模言語モデル、拡散モデル、またはこれに相当するディープラーニングシステムが一部または全部を生成したコンテンツを含めてはならないとしている。
この定義はソースコードにとどまらない。テキスト、画像、プルリクエスト、メール、wiki資料、JDK Bug Systemのエントリーも含まれる。したがって、人間が書いたパッチに添えられたAI作成の説明文も、この制限の対象になり得る。
コントリビューターは、OpenJDKのコードを理解、デバッグ、レビューする目的で、生成AIを私的に利用することはできる。プロジェクトに関連する調査にも利用可能だ。ただし、生成された素材をコントリビューションに組み込むことはできない。
この線引きは、開示要件よりもはるかに厳しい。生成コードをレビューし、利用ツールを文書化し、個人として責任を引き受ければ提出できる、という規則ではない。生成されたコンテンツ自体が、許可されたコントリビューション経路の外に置かれている。
暫定AIポリシーは、懸念事項を3つ挙げている。レビュアーの負担、安全性とセキュリティ、そして知的財産だ。OpenJDKの企業スポンサーであるOracleは、将来的にGoverning Boardが検討する完全版ポリシーを策定中だとしている。
暫定的な位置付けは強調に値する。OpenJDKは、統治機関が未解決の技術的・法的問題を検討する間の暫定的な立場を示した。AI支援開発がプロジェクトの基準を決して満たせない、と宣言したわけではない。
この時期は、8月初旬のGoogle News報道よりも前に当たる。報道によれば、ポリシーをめぐるBoardでの議論は2024年に始まり、2025年初頭まで続いた。公開記録は、直近の見出しの波が起きる数か月前に正式投票が行われたことを示している。
この時系列は、もっともらしく見える一つの解釈を弱める。このポリシーは、欠陥のある単一のプルリクエストや、突発的な企業方針の転換に対する即時の反応ではなかった。参加者が法的に慎重な扱いを要すると考えた、より長いガバナンスプロセスから生まれたものだ。
OpenJDKは単なるOracle製品のリポジトリでもない。正式な役割、複数の雇用主、公開レビュー、そして業界全体のJavaディストリビューションに流れ込むコードを持つコミュニティである。Oracleはコミュニティを後援し、そのリーダーを任命しているが、コントリビューターとレビュアーは文書化されたガバナンス機構を通じて活動している。
それでも、この制限にはOracleの組織としての重みがある。恒久的なポリシーを準備しているのは同社であり、Javaエコシステム全体でOracleの従業員が重要な地位を占めている。読者がプロジェクトの慎重さを、同社のより積極的な企業メッセージと比較するのは当然だ。
変わった点は、したがって具体的である。主要なオープンソースプロジェクトが、私的なAI支援を認めつつ、生成されたコントリビューションに明確な境界を設けた。この境界によって、Oracleの広範なコーディング戦略は、AIの生産性に関する主張が管理された企業ワークフローの外でも成り立つかを試す、目に見える試金石となった。
Oracleは、AIコーディングによって少人数でより多くのソフトウェアを作れると語る
Oracleの社内向けメッセージは、AIコード生成を実験的な利便性ではなく、事業運営上の優位性として位置付けている。
2026年度第3四半期の決算で、Oracleはコーディングモデルが十分に効率化され、製品開発チームを再編できるようになったと述べた。同社は、その結果として生まれたチームを、より小規模で、より機敏かつ生産性の高いものだと説明した。
Oracleはさらに踏み込んだ。同社は、この技術によって少ない人数で、より短い時間により多くのソフトウェアを構築できるようになっているとした。AIコード生成を、開発コストの削減、業界カバレッジの拡大、software-as-a-serviceアプリケーションの収益性向上に結び付けている。
これは重大な主張だ。AIコーディングをエディターの機能から、人員配置と製品戦略の問題へと変える。また、生成されたソフトウェアがOracleの信頼性、セキュリティ、保守性の要件を満たせることを示す圧力も生む。
Oracleは、こうした生産性の主張を独立して測定するのに十分な証拠を公表していない。AIコーディングに関する声明には、AI支援作業の欠陥率、レビュー時間、流出した脆弱性、長期的な保守コストは示されていない。
また、特定の開発グループにおいて「少ない人数」が何を意味するかも説明されていない。小規模チームは、自動化、組織再編、対象範囲の縮小、外注、あるいは通常のコスト管理によって生じ得る。OracleはAIが意味のある役割を果たしたとしているが、外部の人々はこの発表だけからその効果を切り分けることはできない。
同社の製品方針は、開発ワークフローにAIを組み込みたいという、より広範な主張を裏付けている。Oracleは、顧客やパートナーがコーディングアシスタント、コマンドラインインターフェース、Git、ローカル検証、デバッグ、継続的デリバリープロセスと連携できるツールを導入してきた。
Oracleの金融アナリスト向け資料でも、コード生成は新しいアプリケーション開発の中核として説明されている。同社によれば、開発者は意図を表現し、ソフトウェアが実装手順を生成するとともに、ワークフローを通じてアプリケーションコンポーネントを接続できる。
これは、レビューされていないモデル出力をそのまま本番環境に投入することと同義ではない。社内チームはツールを制約し、承認済みのモデルを選び、トレーニングコンテキストを管理し、独自のテストスイートを実行し、すべての変更を従業員にレビューさせることができる。また、欠陥を企業管理下のシステムを通じて追跡することも可能だ。
公開オープンソースへのコントリビューションでは、責任の連鎖が異なる。コントリビューターは、未知のサービスを介して未知のモデルを使用し、未知のプロンプトや非開示のソース素材を用いる可能性がある。レビュアーに見えるのは提案された変更であり、それを生んだプロセスまでは必ずしも見えない。
この非対称性は、Oracleの二つの立場を説明する助けになる。自社アプリケーションの内部では、Oracleは開発環境を定義し、組織としての責任を保持できる。OpenJDKの保守担当者は、外部コントリビューターのすべてが同等の管理を適用しているとは想定できない。
それでも、企業としてのレトリックは妥当な問いを投げかける。Oracleが現代のコードモデルによって少人数のチームとより良い経済性が実現できると考えるなら、その成果を許容可能にするガバナンス実務を説明できるはずだ。そうした実務が移転可能であれば、OpenJDKのコントリビューターも恩恵を受けるだろう。
現行の制限には、同等性を示すための道筋がない。コントリビューターは、モデルログ、テスト結果、来歴記録、詳細な人間によるレビューを提示して例外を求めることはできない。暫定ポリシーは、より高コストな証拠ベースのプロセスではなく、単純な禁止を選択している。
この選択は、短期的には保守担当者を守る。一方で、実際に機能する管理策を明らかにし得る実験を先送りにする。Oracle自身の開発運営は貴重な証拠源になり得るが、それは同社が生産性に関する主張を超えた測定値を公表する場合に限られる。
開発者にとって本当の問いは、Oracleの従業員が生成ボタンを押すかどうかではない。AI支援による変更が、最初のリリース後も理解可能で、帰属を明確にでき、安全で、保守可能であり続けることを、Oracleが示せるかどうかだ。
OpenJDKはレビュアーの負担を決定要因とする
生成コードはコントリビューターの生産コストを下げる一方、保守担当者の検証コストを上げる可能性がある。
この不均衡こそ、OpenJDKの制限を支持する最も強い実務上の根拠だ。コーディングエージェントは、パッチ、テスト、ドキュメント、説明文を高速に生成できる。だが、レビュー能力が同じ速度で自動的に増えるわけではない。
コンパイルできるパッチが、必ずしも安全とは限らない。レビュアーは、オペレーティングシステム、プロセッサ、ガベージコレクター、セキュリティ境界、互換性への期待をまたいで動作を検証しなければならない。また、コントリビューターがその変更を保守できるほど十分に理解しているかも判断する必要がある。
OpenJDKは、迅速な実験より予測可能な挙動を重視するエンタープライズシステムの基盤に位置する。小さな変更でも、ランタイム最適化、メモリ管理、暗号、ネットワーキング、クラスローディングと相互作用する可能性がある。表面的には妥当に見えるパッチが、編集したファイルから遠く離れた場所に影響を及ぼすこともある。
AIシステムは、誤ったコードに対しても自信に満ちた説明を生成し得る。同じモデルがパッチとその根拠の両方を生成すると、その文章は誤りを明らかにするのではなく、むしろ補強する場合がある。するとレビュアーは、一つの人間の主張ではなく、二つの生成物を検証することに時間を費やす。
投稿の作成コストが低いほど、負担はさらに深刻になる。コントリビューターはエージェントにもっともらしい修正案を多数作らせ、その中で最も見栄えのする結果をアップストリームへ送ることができる。それでも保守担当者は、受け入れる提案ごとにプロジェクトレベルの慎重さで調査しなければならない。
これは、すべての生成コードに欠陥があるという主張ではない。人間が書いたコードにも、ミス、コピーされたパターン、不十分な説明はある。違いは規模と、投稿者と成果物の関係が不確実であることにある。
従来のコントリビューションプロセスは、部分的には社会的な証拠に依存している。開発者は問題を議論し、設計を説明し、レビューに応答し、時間をかけて理解を示す。生成された投稿は、ツールを指示する人物が実装を理解していることを証明せずに、こうしたシグナルを模倣できる。
知的財産は、さらに別の問題を加える。コントリビューターは、モデルがトレーニングデータから識別可能なコードを再現したか、あるいは互換性のない素材の影響を受けた実装を生成したかを把握できない可能性がある。プロジェクト側も、ほとんどのプロプライエタリなトレーニングセットを検査できない。
Oracle Contributor Agreementは、コントリビューターとOracleの間で権利を確立する助けにはなるが、来歴に関するすべての問題を解消するわけではない。コントリビューターは、自ら保有していない権利を安全に付与することはできない。ユーザーもプロジェクトもその出所を再構築できない場合、モデル出力はその保証を複雑にする。
著作権法は、生成されたすべての成果物に対して一律の答えを示すものではない。結論は、法域、人間による創作性、入力の性質、出力が保護対象の素材に似ているかどうかに左右され得る。こうした問題が未解決のままである以上、オープンソース・プロジェクトが自らを試金石にしないよう努めるのは合理的だ。
セキュリティにも、同様の証拠上の問題がある。コーディングモデルは、古いパターンや脆弱なパターンも含め、一般的なコードパターンを学習する。存在しないAPIを捏造したり、境界チェックを省略したり、並行処理を誤ったり、より見えにくい不変条件を守らずに目に見えるテストだけを通過させたりする可能性がある。
OpenJDKの方針は、レビュー開始前に生成コンテンツを除外することで、こうしたコストをコントリビューター側に戻している。執行が完全でなくても、運用上は明確だ。
検出は依然として明白な弱点である。洗練されたコード変更がモデルによって生成されたことを証明する信頼性の高い手法はない。誠実なコントリビューターは制限を受ける一方、不誠実な者は開示を削除して提出できてしまう。
違反を確実に検出できない方針であっても、規範としての価値はある。コミュニティがコントリビューターに期待する証拠と行動を示すからだ。また、AI生成が明らかになった際に、メンテナーが提出物を拒否する根拠にもなる。
ただし、規範が最も有効に機能するのは、コントリビューターがそれを正当なものと受け止める場合だ。特にツールが補完、翻訳、リファクタリング、エラー修正を提供する場合、OpenJDKは境界事例を慎重に説明する必要がある。従来型の自動化と生成的な制作の境界は、引くのが難しいことがある。
自らのAI支援による変更を扱うチームにとって、検索可能な設計履歴はコードレビューと同じくらい重要だ。エンジニアリング・ナレッジベースは意思決定やソースの文脈を保存できるが、所有権の問題を解決したり、正確性を保証したりするものではない。
OpenJDKにとってより困難な課題は制度的なものだ。すべてのプルリクエストを誰かの開発環境に対する調査に変えることなく、コントリビューター、ダウンストリームのベンダー、企業の間で信頼を維持しなければならない。
LinuxとGraalVMは、禁止だけが唯一のモデルではないことを示している
他のプロジェクトでは、生成コンテンツを全面的に排除するのではなく、人間のコントリビューターに責任を負わせている。
Linuxカーネルのガイダンスは代替案を示している。同プロジェクトの文書は、コントリビューターによるコーディング支援ツールの使用を認めているが、提出パッチに付随するコンプライアンス、レビュー、認証については、コントリビューターが引き続き個人的に責任を負う。
Linuxのコントリビューターは、ツールからの実質的な支援を示すために「Assisted-by」タグを使用できる。このタグは既存の署名プロセスを置き換えるのではなく、補完するものだ。人間は依然として、その作業を提出する権利を証明する。
このアプローチは、創作手法ではなく説明責任に焦点を当てる。プロジェクトは、パッチがライセンス、開発プロセス、技術基準に準拠しているかを問う。モデルの関与を自動的な失格理由とは見なさない。
カーネルの支援ツール規則も、コントリビューターが出力を理解すべきだと認識している。法的人格、プロジェクト上の立場、継続的な保守責務を持たないモデルに、人が責任を委ねることはできない。
このモデルにはリスクがある。人間による認証では、プロプライエタリなモデル内部で何が起きたかは明らかにならず、個人がライセンスやセキュリティ上の問題を過小評価する可能性もある。メンテナーには、品質の低い生成パッチが大量に届く可能性が残る。
それでも、このモデルは責任ある実験への道を残す。経験豊富な開発者は、限定された作業で支援ツールを使い、すべての行を確認し、手書きのコードと同じ義務の下で作業を提出できる。
GraalVMはOracleも支援しているプロジェクトであるため、さらに鋭い比較対象となる。公開報道では、GraalVMは定められた条件の下でコーディング支援ツールの使用を認めている一方、OpenJDKの暫定方針はより厳しい立場を取っていると指摘されている。
Oracleの影響圏内に異なる方針が存在しても、それだけで不整合が証明されるわけではない。GraalVMとOpenJDKでは、ガバナンス構造、コントリビューター層、コンポーネント、リスク判断が異なる。あるプロジェクトに適した方針が、別のプロジェクトには受け入れがたいコストを課すこともある。
それでもこの対比は、OpenJDKが示す論拠を検証するものだ。知的財産を巡る不確実性が生成されたコントリビューションを根本的に不適格にするなら、観察者は、なぜ別の場所ではガバナンス上の統制でその不確実性を管理できるのかと問うだろう。レビュー負担が決定的な要因であるなら、プロジェクト固有の能力のほうが、より説得力のある説明になる。
開示に基づく方針は、禁止よりも実務上の利点も持つ。記録を生み出すからだ。メンテナーはAI支援パッチと従来のパッチを比較し、レビュー工数を追跡し、欠陥パターンを研究し、実際のプロジェクトデータに基づいて統制を見直せる。
禁止は、遵守するコントリビューターが生成物をプロセスから排除するため、得られる証拠が少ない。短期的なリスクを減らす可能性はあるが、検証済みのAI支援コントリビューションがいずれ機能し得るかについて得られる情報は限られる。
OpenJDKは意図的に時間を買っているのかもしれない。Oracleがより精緻な枠組みを策定する間、暫定ルールはコントリビューション経路が無統制な実験になるのを防げる。恒久方針では、開示、承認済みの用途、証拠要件が導入される可能性がある。
この比較は、Google Newsの見出しの扱いに注意が必要な理由も示している。Oracleは、自社従業員、顧客、あるいは関連するすべてのプロジェクトに対し、AIによるコード作成を禁じたわけではない。OpenJDKの理事会が禁止したのは、あるコミュニティのコントリビューションにおける生成コンテンツだ。
このより限定的な説明は、派手さには欠けるが、より有用である。重要なオープンソース・プロジェクトは、コントリビューターの認証を信頼すべきなのか、それとも生成コードがレビューに入る前により強力な来歴証明を求めるべきなのか、という実際の政策課題を特定するからだ。
コストのかからない答えはない。禁止は潜在的に価値ある作業を排除し、執行も依然として難しい。開示システムはメンテナーを圧倒しかねず、不透明なツールを評価するコントリビューターの能力に過度に依存する可能性がある。
最も強固な長期的枠組みは、人間による認証、必須の開示、再現可能なテスト、受け入れる用途への制限を組み合わせるものかもしれない。OpenJDKはその結論にコミットしておらず、恒久方針はいまなお決定的に欠けている文書である。
OracleのAIインフラへの賭けが重要性を高める
Oracleの財務的な将来がAI需要とますます結び付いているため、この方針論争の重要性は増している。
Oracleは、2026年度のクラウドインフラ収益が181億ドルに達し、前年度比77％増となったと報告した。第4四半期のインフラ収益は58億ドルで、93％増だった。
未認識の契約収益を示す残存履行義務は、年度末時点で6,380億ドルに達した。Oracleは、この増加の大部分を大規模AI契約が牽引したと述べている。
同社は、この受注残を稼働能力に転換するため多額の投資を行っている。Oracleがクラウドインフラを拡大する中、2026年度のフリーキャッシュフローは237億ドルの赤字となった。同社は年度中に、負債調達で430億ドル、株式調達でさらに50億ドルを調達した。
Oracleによると、大規模AI契約に関連する前払いまたは顧客提供のハードウェアは750億ドルに上った。同社によれば、この仕組みはAIデータセンター向けにOracleが調達する必要のある資本を減らす。
これらの数字は、Larry Ellisonをめぐる「社運を賭ける」という表現を説明する。Oracleは成熟したソフトウェアに単にチャット機能を追加しているのではない。異例の需要予測を前提に、データセンター、GPU、ネットワーク、エネルギー容量へ資金を投入している。
同社の2026年度業績は、この移行における緊張も示している。通年の総収益は674億ドルに達し、クラウド収益は340億ドルとなった。従来型ソフトウェアの収益は1％減少した。
Oracleは、AIのトレーニングと推論ワークロードが将来の成長を後押しすると見込む。顧客には、大規模なアクセラレータ・クラスターを必要とする主要なモデル開発企業やテクノロジー企業が含まれる。これによりOracleは、Amazon Web Services、Microsoft Azure、Google Cloud、専門のAIインフラ事業者とより直接的に競合することになる。
この投資は二つの異なる圧力を生む。Oracleは、契約収益を認識するために十分な速さで物理的な能力を提供しなければならない。同時に、資金調達と運営上のコミットメントを正当化できるほどAI需要が持続的であることも証明する必要がある。
AI支援開発は、その財務ストーリーに適合する。Oracleがより少人数のチームでより多くのアプリケーションを構築できれば、インフラに資本を投じながらソフトウェアの利益率を改善できる。社内自動化は、クラウド拡張を支える資金調達ロジックの一部となる。
OpenJDKの慎重姿勢は、この物語の単純な版に割り込む。より多くのコードを生み出すことは、独立したメンテナーが安全に受け入れられるコードを生み出すことと同じではない、と顧客や投資家に思い起こさせる。
この対比は、エンタープライズの購入者にとり特に重要である。こうした組織はJavaシステムを数か月ではなく数年にわたって運用することが多い。安定したインターフェース、セキュリティ対応、予測可能なアップグレード、そして元の開発者が去った後も障害を理解できる能力を重視する。
Forresterのアナリスト、Andrew Cornwallは、Java開発者がしばしば慎重な組織統制の下で働いていると指摘した。彼のJavaOne分析は、エージェントがより多くの開発作業を担うようになっても、出荷されるものについては人間が責任を負うというOracleのモデルを説明している。
この原則は、OracleとOpenJDKの隔たりを狭める。両者の立場は最終的に、説明責任を負う人間に依存している。意見の相違は、生成コンテンツが公開プロジェクトに入る前に、人間のレビューで十分に浄化できるかどうかにある。
Oracleの財務的なエクスポージャーは、曖昧な答えを維持しにくくする。同社は顧客にモデル訓練の能力を販売し、コーディングツールを提供し、自社開発チームを再編する一方で、生成されたコントリビューションを禁じるプロジェクトを支援している。
投資家はクラウド成長と資本要件に注目する。開発者は来歴、レビュー品質、保守性に注目する。OracleのAI戦略は現在、この二つを結び付けているため、同社には双方に対する信頼できる答えが必要だ。
OracleとOpenJDKが次に証明すべきこと
現在の矛盾が持続的なガバナンスモデルになるのか、一時的な保留状態にとどまるのかは、三つのシグナルによって示される。
第一のシグナルはOpenJDKの恒久方針である。Oracleは提案を策定中だとしているが、最終文書は暫定的な禁止が残した問題を解決しなければならない。
開発者は、この方針が生成コードと、AI支援によるレビュー、補完、翻訳、機械的リファクタリングを区別するかどうかに注目すべきだ。また、コントリビューターが偶発的な違反をどう是正できるか、メンテナーがどのような証拠を要求できるかも説明すべきである。
恒久的な一律禁止は、OpenJDKが現時点の来歴管理とレビュー統制を不十分と見なしているという判断を強めるだろう。一方、開示に基づくプロセスは、暫定ルールがより慎重な枠組みを整えるための時間を確保することに成功したことを示唆する。
第二のシグナルは、Oracle自身のAIコーディングに関する主張を裏付ける証拠である。生産性の数値だけでは、ソフトウェア品質を立証できない。有用な報告には、レビュー時間、変更失敗率、脆弱性の発見件数、ロールバック頻度、保守の結果が含まれる。
Oracleは意味のある集計測定値を公表するために、プロプライエタリなソースコードを公開する必要はない。コーディング・エージェントをどこで使用しているか、どのような統制がそれを取り巻いているか、どの種類の変更が引き続き人間主導なのかを説明できる。
安定した、あるいは改善する品質の証拠が得られれば、隠れた負担を下流へ転嫁せずに、AI主導の開発がコストを削減できるというOracleの主張は強まる。欠陥の増加や説明のつかない保守作業が見られれば、OpenJDKの慎重な姿勢を裏づけることになる。
3つ目のシグナルは、ほかの基盤的プロジェクトが1つのコントリビューションモデルへ収束するかどうかだ。Linuxは人間による認証と、支援ツール利用の任意開示を重視している。ほかのプロジェクトでは、禁止措置、ラベル表示の義務化、ライセンスや貢献者の理解度に結び付いたルールが検討されている。
収束すれば、複数のエコシステムに貢献する開発者にとってコンプライアンス対応は容易になる。分断が続けば、貢献者はプロジェクトごとの境界を追跡せざるを得ず、AIの来歴がオープンソース・ガバナンスの標準的な要素になる可能性がある。
Google Newsの報道では、この対比が分かりやすいため、表面的な矛盾が引き続き強調される可能性が高い。OracleはAI生成による開発を推進する一方、OpenJDKは生成されたコントリビューションを受け入れない。より深い問題は、自動化された出力が共有インフラに入る際、そのコストを誰が負担するのかという点にある。
エンタープライズの購入者にとって、この答えはベンダー評価に影響すべきだ。AI生成コードがどこで許可されているのか、どのように識別されるのか、誰が承認するのか、導入後にどの品質指標が変化したのかをサプライヤーに確認すべきである。
開発者にとって、この方針はツールの利用許可とコントリビューションの許可は別物だという注意喚起になる。アシスタントはバグの調査を支援できるが、それによって生成した説明やパッチがOpenJDKで受け入れられるわけではない。
メンテナーにとっての課題は、ルールを解釈・執行不可能なものにせず、限られたレビュー能力を守ることにある。誠実な貢献者が一貫して適用できない方針は、時間とともに権威を失うだろう。
Oracleはいま、この試験の両側に位置している。AIがより多くのコードを生み出すことで利益を得ると同時に、顧客がモデルを動かすためのインフラを購入することでも利益を得る。また、その価値が規律ある保守に依存するJavaエコシステムに対する責任も負っている。
次のGoogle Newsの見出しよりも、その背後にある証拠のほうが重要だ。OpenJDKの完全な方針、Oracleのソフトウェア品質指標、そしてほかの主要プロジェクトによる同様のルールに注目したい。
そして、実務的な問いを投げかけるべきだ。AIによってコードの生成コストがほぼゼロになった場合、そのコードが安全で、合法的で、保守可能だと確認するための費用を誰が支払うのか。
