필사 모드: 同じ会社の二つのプロジェクトがAI寄与に正反対の結論を出した理由

• 同じ会社、同じ寄与者協定、正反対の方針
• OpenJDKが禁止したものと許可したもの
• 10行だけ直してもだめな理由は知的財産条項にあります
• 検知が不可能だと方針が自ら認めています
• GraalVMは同じ危険を責任へ移します
• Linuxカーネルは三つ目の答えを出します
• 三つの方針を分ける本当の軸
• 自分たちのリポジトリの方針を書くときに決めるべき四つ
• 参考資料

同じ会社、同じ寄与者協定、正反対の方針

オープンソースのプロジェクトへパッチをひとつ送ろうとしています。作業中にコーディングアシスタントを点けていました。このパッチを送ってよいのか確かめようとプロジェクトの文書を開いたら、プロジェクトごとに答えが違います。しかも同じ会社が後援する二つのプロジェクトのあいだで正反対です。

OpenJDKの暫定方針は2026年4月9日付で、生成AIが作った内容が寄与に含まれてはならないと釘を刺します。GraalVMの方針ファイルは、寄与者がAIコーディングアシスタントを使用できると明記します。どちらもオラクルの寄与者協定を使っています。

この違いを「一方は保守的で一方は前向き」とまとめても、何も得られません。三つの文書を実際に読むと別の絵が出てきます。

OpenJDKが禁止したものと許可したもの

原文は範囲をとても広く取ります。禁止の対象はソースコードに限られず、リポジトリのテキストと画像、GitHubのプルリクエスト、メール、ウィキの文書、課題管理システムまで含みます。コミットメッセージも、PRの説明も、メーリングリストの返信も該当します。

同時に許可の範囲も明確です。寄与者は生成AIの道具を私的に使ってコードを理解し、デバッグし、レビューし、プロジェクト関連の調査をすることができます。そうして作られた内容を寄与しさえしなければよいのです。

FAQはこの区別をさらに押し進めます。草案のJEPや文書をAIにレビューしてもらうのは問題ありません。テキストを本人がすべて書いたのなら、レビューは明らかに許可の領域だからです。エディタのスペルチェックと自動補完も、大規模言語モデルに基づくものでなければ使い続けてよいとされています。

10行だけ直してもだめな理由は知的財産条項にあります

もっとも頻繁に引用されるFAQの項目はこれです。AIで100行を作り、そのうち10行を自分で直したなら寄与できるのかという問いへの答えは、だめだ、というものです。依然として部分的にAIが生成したコードを含むからです。

この答えが過度に厳格に見えるなら、その理由がコードの品質ではなく契約にあるという点を見れば理解しやすくなります。オラクルの寄与者協定は、寄与者が各寄与の知的財産権を保有し、その権利を制限なくオラクルへ移転できることを要求します。そして原文は、生成AIの道具の利用者がその産出物について知的財産権を持つかどうかが現在訴訟の進行中の事案であると書いています。

権利が不確実な部分が1パーセントでも混ざれば、「制限なく移転する」という確認は成り立ちません。だから比率の基準は出てきようがなく、二分法になります。

この点を理解すると、よくある反論のひとつが力を失います。「ではIDEの自動補完はどうするのか」という問いですが、原文はその境界を道具の種類ではなく技術で引きます。大規模言語モデルや類似の深層学習システムに基づかないスペルチェックと自動補完は使い続けてよいと書かれています。基準は利便性ではなく、権利の帰属が争われている学習方式かどうかです。

検知が不可能だと方針が自ら認めています

方針のなかでもっとも率直な箇所は、レビュー担当者の責任に関する部分です。原文は、人が作った内容とAIが作った内容を信頼できる形で区別することは一般に不可能だと明記します。

それでも兆候が見えたら寄与者に知らせる責任がレビュー担当者にあるとし、その兆候の例まで列挙します。コミットのトレーラーに特定の道具が共著者として残っている場合、普段の文体と違っておしゃべりで冗長な場合、見出しがいくつも付いた過度に構造化されたコメント、不要な注釈、必要以上に防御的なコード、絵文字の使用といったものです。原文は、これらの手がかりが今日有効でも明日はそうでないかもしれないと自ら付け加えます。

そのため執行は検知ではなく申告に掛かります。Skaraがプルリクエストの本文にチェックボックスを追加し、寄与者がこの方針を遵守したことを自ら確認する方式です。実質的には正直さの宣言体系です。

GraalVMは同じ危険を責任へ移します

GraalVMの文書は、同じ危険の一覧を違うやり方で処理します。使用を許可しつつ、提出した人がAIが作った部分を含めて寄与の全体について責任を負うと規定します。

期待される振る舞いも具体的です。提出したコードとテストと文書とコミットメッセージを読んで理解すること、変更が正確で必要でプロジェクトの基準に合っているかを検証すること、レビュー担当者の質問に道具を言い訳にせず答えること、そしてレビューと保守の期間を通じてその寄与に責任を持つことです。文書は、寄与者がAI補助の変更を説明できず、擁護できず、保守できないなら、その寄与は拒否されうると書きます。

出所の表記は推奨ですが必須ではなく、特定のモデル名を明かす必要もありません。保守担当者に対しては、AI補助かどうかが正確性の推定の根拠にはならない点を明記します。

Linuxカーネルは三つ目の答えを出します

GraalVMの文書が参照したと明かしているLinuxカーネルのAIコーディングアシスタント文書は、また別の軸を使います。許可しつつ痕跡を残させる方式です。

核心となる規則がひとつ印象的です。AIエージェントはSigned-off-byタグを付けてはいけません。開発者原本証明を法的に確認できるのは人だけだからです。代わりに別のタグを使います。

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

例: Assisted-by: Claude:claude-3-opus coccinelle sparse

バグを見つけて直す手続きも、文書に段階として釘を刺してあります。些細でないバグは再現コードを作って実在を確認すること、直すところまでやること、ビルドの警告を追加せずcheckpatchの検査を通すこと、そしてできなかったことを明示的に明かすことです。再現コードを作れなかったり試験できなかったりしたなら、そう書けという要求です。検証されていない報告を分析するのに保守担当者の時間があまりにも多く浪費されているという理由が、文書にそのまま書かれています。

三つの方針を分ける本当の軸

三つの文書を並べると軸が見えます。AIをどれだけ信頼するかではなく、レビューの負担を誰に請求するかです。

OpenJDKがもっとも厳格なのは、レビュー担当者の層が薄く代替が利かず、成果物がミッションクリティカルなシステムの土台に敷かれるからです。原文が安全とセキュリティを理由に挙げた場所がここです。逆にGraalVMは、同じ協定のもとでも個別の責任で担えると判断しました。同じ会社が違う答えを出したのは矛盾ではなく、プロジェクトごとにボトルネックが違うからです。

自分たちのリポジトリの方針を書くときに決めるべき四つ

この軸を知れば、社内リポジトリの方針も短く書けます。他人の方針を複写する代わりに、四つだけ決めればよいのです。

AI補助の寄与に関する方針 — 例としての骨格

1. 範囲: コードだけか、PRの説明とイシューのコメントまでか
2. 責任: 提出者が説明できない変更は拒否されるか
3. 記録: 表記を義務にするか推奨にするか、どのタグで残すか
4. 執行: 検知に頼るか、宣言とレビューに頼るか

既定の推奨: 範囲はコードとPRの説明、責任は提出者が全面的に負う、
記録はコミットのトレーラーで推奨、執行は宣言と通常のレビュー。

三つ目の項目だけ補足すると、表記を義務化して得られるのは監視ではなくデータです。半年後にAI補助の変更の事後欠陥率を別に見られるようになり、そうすれば方針を勘ではなく数字で調整できます。いまこの論争がおおむね勘で進んでいる理由は、その数字を持っている組織がほとんどないからです。

最後にひとつ。OpenJDKの文書は題名からして暫定と付いており、オラクルが正式な方針を統治委員会に提案する予定だと本文に書かれています。いまの禁止は最終結論ではなく時間を稼ぐ措置です。この点を抜いて引用すると、原文が言っていないことを言わせることになります。

参考資料

• OpenJDK Interim Policy on Generative AI — openjdk.org, 2026-04-09 — 禁止の範囲、私的使用の許可、三つの危険、100行のうち10行のFAQ、Skaraのチェックボックス、レビュー担当者の責任と手がかりの一覧が、すべてこの文書にあります。
• GraalVM Coding Assistants — oracle/graalリポジトリ — 許可の範囲、寄与者の責任、任意の表記、保守担当者のレビュー原則。
• AI Coding Assistants — Linuxカーネル文書 — 署名の禁止、Assisted-byタグの形式、バグ修正の手続き。
• 上の比較表と方針の骨格は三つの原文を読んで私が整理したものであり、どの文書にもそのままの形では出てきません。