システム開発を外部に発注していて、成果物の受け入れ時に「このコードにAIが生成した部分は含まれますか」と聞いたことはあるでしょうか。聞いていない会社が多数派です。そして聞いた会社の多くは、返ってきた答えを評価する基準を持っていなかったという同じ場所で止まります。
「使っています」と言われて、それが問題なのかどうかが分からない。かといって「一切禁止」と後出しで言えば、見積もりの前提が崩れます。結局その場では何も決まらず、次の案件でも同じ質問が繰り返されます。
この問いに、2026年の夏に相次いで答えを出したプロジェクトがあります。しかも三者三様に見えて、線の引き方は驚くほど揃っています。
3つのプロジェクトが出した方針
OpenJDK は2026年4月上旬に方針を広く公開し、大規模言語モデル・拡散モデル・類似の深層学習システムによって部分的または全面的に生成されたコンテンツを含む貢献を禁止しました。挙げられた理由は2つで、ひとつはレビュー負荷です。もっともらしく見えるが実際には誤っている、あるいは保守が困難なコードが、限られたレビュー時間を消費する。もうひとつは安全性と安定性で、JDKがミッションクリティカルなシステムを支えていることが根拠とされています。ただし、開発者が自分のデバッグやコードの読み解きにLLMを使うこと自体は禁じられていません。
Linuxカーネルでは、Greg Kroah-Hartmanが2026年8月3日、自身が管理する drivers/staging/ サブシステムにおいてAI/LLMで作成されたパッチを原則受け入れない方針を表明しました。例外は実在するセキュリティ問題の修正のみです。理由が独特で、staging は新規参加者が投稿プロセスを学ぶための場所——本人の言葉では「ジム」——であり、LLM生成パッチの殺到がその役割を壊すから、というものでした。品質そのものより、育成の場が埋まることを問題にしています。
Rust は2026年8月5日、コンパイラや標準ライブラリを管理する5チームが rust-lang/rust への貢献に関するLLM利用ポリシーを採用しました。こちらは全面禁止ではなく、分析や確認への利用は認め、生成については厳しく制限するという形です。
共通しているのは「工程で分けた」こと
3件を並べると、禁止か許可かの二択で線を引いたところはひとつもありません。
| プロジェクト | 制限しているもの | 認めているもの |
|---|---|---|
| OpenJDK | 生成物をリポジトリ・PRに投稿すること | 開発者個人のデバッグ・読解での利用 |
Linux drivers/staging/ | AI生成パッチの投稿（実セキュリティ修正は例外） | メンテナ自身の利用を含め、他領域での利用 |
| rust-lang/rust | LLMによる「作成」 | LLMによる「分析」「確認」 |
線は工程で引かれています。読む・調べる・検証する側での利用は認め、成果物を生み出して提出する側での利用を制限する。この構造が3件とも共通しています。
理由も揃っています。OpenJDKが挙げたレビュー負荷と、GKHが挙げた殺到は、同じ現象の別の言い方です。生成のコストが下がった結果、提出量が受け入れ側の処理能力を超えた。制限されているのは技術ではなく、検証されないまま流れ込む量のほうです。
この非対称は社内開発でも同じ形で現れます。生成が速くなっても、レビューと検証の速度は変わりません。AIが生成したPRの量にレビューが追いつかないで扱った詰まり方と、構造は同一です。
同じ会社の中でも方針は割れる
もうひとつ見ておくべき事実があります。OpenJDKがAI生成の貢献を禁じている一方で、同じOracle傘下のGraalVMはこれを許可しています。さらにOracleの共同創業者であるLarry Ellisonは、AIモデルが同社のコードを書いていると公言しています。
これを矛盾と読むこともできますが、実務的には別の読み方をしたほうが役に立ちます。同じ組織の中でも、プロジェクトの性質によって適切な方針が違うということです。ミッションクリティカルな基盤と、実験的な処理系では、許容できるリスクが違って当然です。
発注側にとっての示唆は明確です。「わが社はAI生成コードを許可する／禁止する」という全社一律の方針を作ろうとすると、必ずどこかで無理が出ます。決めるべき単位はシステムであり、判断材料はそのシステムが止まったときに何が起きるかです。
受け入れ基準に落とすなら
以上を踏まえて、発注側が現実的に決められることを整理します。
- システムごとに区分を決める。 基幹業務や決済のように停止が即座に事業損害になるものと、社内向けの補助ツールとでは、要求する検証の深さを変えます。全部を最も厳しい水準に合わせると、単価にそのまま跳ね返ります
- 禁止するのではなく「検証の責任」を書く。 実務で機能するのは、生成手段を問うことより、成果物の内容について受注側が責任を負うことを明確にしておくことです。人が書いてもAIが書いても、動かないものは同じように問題になります
- レビューの工数を見積もりから削らせない。 生成が速くなったことを理由に見積もりが圧縮されている場合、削られているのはたいてい検証工程です。ここが削られた成果物は、納品直後ではなく数か月後に問題として現れます
3つめは特に重要です。AI生成コードの問題は、納品時点では見えにくく、半年後に保守で顕在化するという形を取ります。検収を通ったことは、品質が確認されたことを意味しません。
「開示させる」だけでは機能しない
一方で、「AI生成部分を申告させる」という運用を単体で入れても、あまり機能しません。理由は3つあります。
申告の粒度が定義できないこと。補完機能で数行受け入れたコードと、指示から丸ごと生成させたコードを同じ「AI生成」と呼ぶのか。線引きを決めずに申告を求めても、返ってくる答えに情報量がありません。
検証手段がないこと。申告された内容が正しいかを発注側が確かめる方法は、実務上ほぼありません。性善説に依存した項目を契約に書いても、争いになったときに機能しません。
そして、開示されても判断基準がないこと。冒頭に戻りますが、これが最大の問題です。「使っています」と言われたときに何をどう見るかが決まっていないなら、聞くこと自体に意味がありません。
現実的に効くのは、生成手段の申告より検証の証跡を求めるほうです。静的解析やセキュリティレビューを通した記録が残っているか。テストがどの範囲を覆っているか。これらは人が書いたコードでも当然求めるべきもので、AI生成かどうかに関係なく評価できます。レビューを機械側で補強する手段についてはAI生成コードのセキュリティレビューを自動化するにまとめています。
次にやること
いま外部に発注しているシステムを、止まったときの影響で2つか3つに分けてみてください。分け終わると、どのシステムで検証の証跡を要求すべきかが自動的に決まります。全システムに同じ基準を敷こうとして止まっている会社は、ここを飛ばしています。
そのうえで、次の見積もりを受け取ったときにレビュー・テスト工程の内訳を確認する。これだけで、AI生成コードの扱いに関する実質的な議論はほぼ始められます。
開発体制の見直しや、既存システムの品質評価を含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。システムの構成や現在の体制によって取るべき手順は変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- Oracle’s OpenJDK Bans Generative AI Contributions While Oracle’s GraalVM Allows Them — InfoQ
- Oracle bans AI-generated contributions to OpenJDK — Techzine Global
- ステージングエリアは開発者を成長させるための”ジム”、AI成果提出の場にしないで！ — gihyo.jp
- Linux’s Staging Area To Now Reject LLM-Generated Patches, Except For Real Security Fixes — Phoronix
- Rustプロジェクトの5チーム、rust-lang/rustへの貢献ではLLMによる分析や確認を許可、作成は厳しく制限 — gihyo.jp
