Debian では、生成 AI や大規模言語モデル（LLM）を利用した貢献を、どの条件で受け入れるかについて、開発者全体による正式な意思決定手続きである General Resolution の議論が続いている。調査日時点では、禁止、条件付き許可、利用回避、既存規則の継続適用など、前提の異なる提案が並び、公式一覧でも審議中とされている[1][2]。Debian が直面しているのは、特定の生成 AI サービスを許可するかという製品選定ではない。コード、文書、翻訳、バグ報告、レビューコメントに生成 AI が介在したとき、誰の判断をもって Debian の成果物として受け入れるのかという統治上の問題である。
同じ問いは、Debian に限られていない。Linux カーネル、NetBSD、QEMU、LLVM、Python、Fedora などは、AI 支援による貢献について、それぞれ異なる受入条件を公表している。後続の章では、これらの方針を、禁止か許可かではなく、人間による確認をどこまで信頼し、確認不能な部分を誰が引き受けるかという観点から比較する。
生成 AI の導入によって変わったのは、コードを作る速度だけではない。従来は一人のコントリビューターを中心に結び付いていた、実装、理解、出自確認、権利表明、提出、レビュー対応、修正という役割を、別々の主体が担えるようになった。AI が差分を生成し、人間が内容を十分に追わないまま提出し、メンテナーが正しさを検証する構図になれば、作成コストの削減はレビュー負担の外部化として現れる。さらに、後からライセンス上の疑義や脆弱性が見つかったとき、生成した AI は調査にも修正にも応答できず、提出者が実装を説明できなければ、対応責任はプロジェクト側へ移る。
AI 生成コードのライセンス問題は、AI にどのライセンス名を付けるかという問題ではない。ライセンスは、著作物をどの条件で使用、改変、再配布できるかを示すが、その表示を付けた人が第三者へ許可を与える権限を持つことまでは証明しない。問われるのは、人間が何を根拠として、そのコードをオープンソースプロジェクトへ提出・配布できると表明するのか、その表明が誤っていた場合に誰が調査、撤回、修正、通知を担うのかである。人間が責任を引き受けるという宣言は必要だが、それによって存在しない著作権や再許諾権限が新たに生じるわけではない。
1. AI 生成コードは責任のまとまりを分解した
1.1 コードを書くことと、コードを提出することは同じではない
オープンソース開発では、コードを作成する能力だけで貢献が成立するわけではない。提出者には、変更が必要な理由を説明し、既存設計との関係を示し、テスト結果を提示し、レビューで指摘された問題を修正することが求められる。外部からコードを取り込む場合には、作者、ライセンス、取得経路を確認し、対象プロジェクトへ持ち込める根拠も説明しなければならない。作者、提出者、レビュアー、保守担当者が同一人物である必要はないが、少なくとも各役割を接続し、質問に応答できる人間と履歴が必要になる。
生成 AI は、実装工程だけをこの関係から切り離す。対話型の支援ツールは関数やテストの候補を生成し、コーディングエージェントは複数ファイルの調査、編集、テスト実行、エラー修正、変更説明の作成まで進める。ここで生成されるのはコードだけではない。設計理由や変更説明まで生成できるため、提出文が整っていることと、提出者が実装上の判断を理解していることも一致しなくなる。差分がテストを通過していても、未試験の境界条件、既存の暗黙仕様、将来の変更に弱い依存関係を説明できるとは限らない。
| 工程 | 従来の中心主体 | AI 支援で生じる分離 | 受入時に確認すべきこと |
|---|---|---|---|
| 実装 | コントリビューターが変更内容を作成する。 | AI が関数、テスト、複数ファイルの差分を生成できる。 | 提出者が生成された各変更の目的と動作を説明できるかを確認する。 |
| 設計判断 | 実装者が採用した方式と代替案を説明する。 | AI が提示した最初の案が、比較されないまま採用される場合がある。 | 既存設計との整合、代替案を退けた理由、境界条件が検討されているかを確認する。 |
| 権利確認 | 提出者が自己作成または適法に取得したコードであることを表明する。 | 利用者がモデルの学習データや出力の由来を完全には確認できない。 | 提出権限を合理的に認証できる根拠があり、確認不能な出力を除外しているかを確認する。 |
| レビュー対応 | 提出者が質問に答え、指摘に応じて変更する。 | 提出者が実装を理解していなければ、説明と修正がメンテナー側へ移る。 | 提出者自身が指摘を理解し、差分を縮小、修正、撤回できるかを確認する。 |
| 事後保守 | 提出者またはプロジェクトが回帰や脆弱性へ対応する。 | 生成時の判断過程が残らず、障害原因の追跡に追加調査が必要になる。 | 生成経路、レビュー記録、テスト範囲、責任主体を後から追跡できるかを確認する。 |
この分離が直ちに不適切な貢献を意味するわけではない。人間が AI の候補を比較し、不要な部分を捨て、設計に合わせて修正し、テストとレビューを経て提出するなら、生成 AI はコンパイラ、静的解析、コード生成器と同様に開発を補助する道具になる。反対に、出力を理解しないまま提出するなら、人間は責任主体ではなく、AI の出力をプロジェクトへ通過させる名義人にとどまる。両者を分ける基準は AI の利用有無ではなく、採用判断が実質的に人間によって行われたかどうかにある。
AI の出力は、生成された時点では採否の決まっていない候補である。利用者が差分を選択し、プロジェクトの規則に従って提出し、メンテナーが受け入れたとき、その内容は人間とプロジェクトの判断へ変わる。既稿「AI の答えは、採用されたときに責任になる」で扱ったのも、この生成と採用の境界である[3]。AI が候補を作ったという履歴は残せるが、採用理由の説明と採用後の対応は、判断権を行使した人間から切り離せない。
1.2 オープンソースでは継続的な応答が求められる
組織内部の試作であれば、生成物に問題が見つかった時点で利用を中止し、別の実装へ置き換えることもできる。公開されたオープンソースの変更は、同じ範囲にとどまらない。リリースへ収録されたコードは、下流ディストリビューション、組み込み製品、クラウドサービス、長期保守版へ複製される。最初のプロジェクトで小さな変更として受け入れられても、配布範囲が広がるほど、回帰、互換性低下、性能劣化、脆弱性、ライセンス違反が及ぼす影響も増える。
影響が判明した後には、どの変更で問題が入ったかを特定し、設計上の意図を確認し、安全な修正を作り、必要な利用者へ通知しなければならない。提出者がコードを説明できず、生成時の入力や採用理由も残っていなければ、原因調査はコミットされた差分から逆算する作業になる。その結果、生成時に節約された時間が、メンテナーによる調査、再設計、置換、下流調整として後から発生する。AI による作成コストの低下が、プロジェクト全体の保守コストの低下を意味しない理由はここにある。
レビュー能力にも同じ制約がある。生成 AI は短時間で多数の修正案を作れるが、メンテナーの時間とプロジェクト固有の知識は同じ速度では増えない。提出者が十分に絞り込んでいない差分を大量に送れば、誤りの有無にかかわらず、確認作業が共有資源を消費する。提出側が数分で作った変更を、受入側が数時間かけて検証する状態が続けば、AI の便益はプロジェクトへ提供されず、レビュー負担だけが移転される。
この制約から、オープンソースにおける人間の責任は、署名欄に名前を残すことより広い意味を持つ。提出者には、コードを理解し、変更範囲をレビュー可能な大きさへ抑え、質問へ応答し、不適切な部分を撤回し、問題が判明した後も修正へ関与できることが求められる。プロジェクト側には、どの程度の AI 関与を開示させるか、自律エージェントによる直接投稿を認めるか、高リスク領域へ追加審査を課すかを定める責任がある。
オープンソース AI ガバナンスは、生成を許可するか禁止するかだけを決める規則ではない。生成経路を記録し、提出権限を人間が認証し、技術的な正しさをレビューし、受入れ後の修正主体を確保するための制度である。生成、認証、審査、採用、保守を別々の工程として扱い、それぞれの責任主体を結び直さなければ、AI によって分解された役割の隙間へ、権利上の不確実性と保守負担が残る。
2. ライセンスは利用条件を示すが、提出権限を証明しない
2.1 オープンソースライセンスが定めるもの
オープンソースライセンスは、ソフトウェアを使用、改変、再配布できる条件を定める。Open Source Definition は、自由な再配布、ソースコードの提供、派生物の作成、個人・団体・利用分野への差別禁止、技術中立性などを要件としている[4]。Debian Free Software Guidelines も同じ系譜にあり、Debian Social Contract の一部として、Debian が自由なソフトウェアと判断する基準を示している[5]。
これらの基準が直接規定するのは、権利者から有効な許諾を受けた利用者が、何をしてよいかである。GPL、BSD、MIT、Apache などのライセンス表示があれば、複製、改変、再配布に必要な条件を確認できる。しかし、その表示だけでは、表示を付けた人が著作権者であること、著作権者から許諾を受けていること、第三者のコードを無断で含めていないことまでは確認できない。
たとえば、第三者のコードを無断で複製したファイルへ MIT License の表示を追加しても、複製した人に再許諾権限は生じない。元のコードを GPL の条件で受領した利用者が、権利者の追加許諾なく BSD License へ書き換えて配布することもできない。ライセンス表示は、権限を持つ者が許諾条件を伝えるための記録であり、権限を持たない者へ許諾能力を与える仕組みではない。
この区別は、生成 AI の出力を扱うときに表面化する。AI が生成したファイルへ対象プロジェクトの標準ライセンスを記載することは容易である。一方、その出力が完全な新規表現なのか、既存コードの一部を再現しているのか、特定のライセンス条件を引き継ぐ必要があるのかを、表示から判断することはできない。生成物へ適切なライセンス名を記載する作業と、そのライセンスで提供する権限を確認する作業は、別の工程として実施しなければならない。
Debian Policy Manual も、パッケージへ配布ライセンスと必要な著作権情報を収録することを求めている。また、法令、倫理上の要件、Debian の方針と衝突するファイルをアーカイブから除外できるとしている[6]。Debian は上流から受け取ったコードを保存するだけではなく、世界各地の利用者へ再配布する。再配布者として判断するには、ライセンス名に加えて、誰がどの権限で提供したのか、必要な表示が維持されているか、Debian が同じ条件で下流へ渡せるかという記録が必要になる。
| 情報 | 示す内容 | 単独では示せない内容 |
|---|---|---|
| ライセンス表示 | 利用、改変、再配布に適用される条件を示す。 | 表示を付けた者が有効な許諾権限を持つことまでは証明しない。 |
| 著作権表示 | 著作権者として主張されている個人・組織と対象年を示す。 | 表示内容が正確であり、他の権利者が存在しないことまでは証明しない。 |
| 生成経路 | 人間、生成 AI、コード生成器など、作成に関与した手段を示す。 | 生成された内容の権利状態や技術的な正しさまでは保証しない。 |
| 提出者の認証 | 提出者がどの根拠でプロジェクトへ持ち込めると判断したかを示す。 | 認証内容が客観的に正しいことや、コードに欠陥がないことまでは保証しない。 |
2.2 AI 出力に新しい著作権があるかと、既存の権利を侵害するかは別である
生成 AI の出力に著作権が成立する条件については、法域ごとに検討が続いている。米国著作権局は 2025 年 1 月、人間が作品の表現要素を十分に決定した場合には、生成 AI を利用した作品にも著作権保護が成立し得る一方、単にプロンプトを入力して生成結果を得ただけでは、人間による著作者性として不足する場合があると整理した[7]。
この整理が扱うのは、生成された表現について、新しい著作権を誰が取得できるかという問いである。新しい著作権が成立しない生成物は、少なくとも生成した利用者の独占的な著作物として保護されない可能性がある。しかし、この結論から、生成物に第三者の権利が及ばないことや、誰でも自由に再配布できることまでは導けない。
生成結果が既存コードの創作的な表現を相当程度再現していれば、元のコードに成立している著作権が問題になる。元のコードが GPL で提供されていれば、必要なソースコード提供、著作権表示、ライセンス条件の継承が求められる可能性がある。プロプライエタリなコードを再現していれば、そもそも再配布の許可を得られない場合もある。生成結果に新しい権利が成立するかという判断は、既存作品との関係を検査する代わりにはならない。
さらに、既存コードと一致していなくても、提出者が対象プロジェクトへ提供できる根拠を説明できるとは限らない。利用した AI サービスの規約が出力の商用利用や再配布を認めているか、入力したコードに秘密保持義務や再利用制限がなかったか、生成結果に付随する条件が対象プロジェクトのライセンスと両立するかという確認も必要になる。著作者性、第三者権利、サービス利用条件、提出権限は、一つの判断へまとめられない。
| 確認対象 | 確認する内容 | 混同した場合の帰結 |
|---|---|---|
| 著作者性 | 人間による創作的な選択や修正があり、生成物に新しい著作権が成立し得るかを確認する。 | 新しい著作権が成立しない可能性を、第三者の権利も存在しないという意味に取り違える。 |
| 第三者権利 | 既存コードの複製または翻案が含まれ、元の著作権やライセンス条件が及ばないかを確認する。 | 生成物側の著作者性だけを調べ、既存権利の侵害や表示義務を見落とす。 |
| サービス利用条件 | 生成に用いたサービスの規約が、出力の利用、改変、公開、再配布をどの範囲で認めているかを確認する。 | 出力を取得できることを、任意の条件で第三者へ提供できることと同一視する。 |
| 提出権限 | 提出者が、対象プロジェクトのライセンスでコードを提供できる合理的な根拠を持つかを確認する。 | 責任を負う意思や署名の存在を、必要な権利を持つことと同一視する。 |
| 技術的責任 | 仕様、品質、安全性、保守性について誰が説明し、必要な修正を行うかを確認する。 | ライセンス上受け入れられることを、技術的な受入条件も満たすことと取り違える。 |
これらの確認対象は独立しているが、実務上は連鎖している。第三者権利を確認できなければ、提出者は再配布権限を根拠付きで表明できない。提出権限を説明できなければ、プロジェクトは採用したコードを下流へ安全に配布できない。下流配布後に権利上の疑義が判明すれば、対象箇所の特定、削除、再実装、リリース差し替え、利用者への通知が必要になる。最初の確認不足は、単一のコミットにとどまらず、配布経路全体の修正費用へ拡大する。
2.3 DCO は提出権限に関する人間の認証である
Developer Certificate of Origin、略して DCO は、提出者がコードの由来と提出権限について行う認証である。DCO 1.1 は、提出物について、提出者自身が作成したこと、適切なオープンソースライセンスで提供された既存作品を基礎としていること、または同様の認証を伴って他者から受領したことのいずれかを表明させる[8]。コミットへ付ける Signed-off-by は、単なる作者名の表示ではなく、この認証に同意した人間を記録する。
DCO が確認するのは、コードが正しく動作することや、脆弱性を含まないことではない。提出者が、どの経路で対象コードを得て、どの根拠でプロジェクトへ提出できると判断したかを明示する。技術的な品質はテストとレビューが確認し、ライセンス条件はファイルやパッケージの表示が示し、DCO は提出経路に関する人間の認証を担う。これらの役割を分けることで、一つの署名に過剰な意味を持たせずに済む。
DCO は、一般的な「問題が起きれば責任を取る」という宣言より具体的である。責任を負う意思だけでなく、自分が作成したのか、適法な既存作品を基礎にしたのか、認証済みの経路から受け取ったのかを問うからである。第三者のコードを提出する権限がない人が、将来の損害に対応すると約束しても、権利者の許諾に代えることはできない。DCO が求めるのは、事後対応への覚悟だけでなく、提出時点の権利表明である。
AI 生成コードでは、この表明を支える情報が提出者の手元にあるかが争点になる。モデルの学習データを閲覧できず、出力がどの既存コードに影響されたかも確認できない場合、提出者は自己作成物として認証できるのか、適法な既存作品を基礎としたと判断できるのかを検討しなければならない。AI が関与したという理由だけで直ちに DCO を満たせないとは限らないが、生成結果を取得したという事実だけでも認証の根拠にはならない。
この評価の違いが、オープンソースプロジェクトの方針を分ける。Linux カーネルは、人間が生成物をレビューし、ライセンス適合性を確認し、自ら DCO を認証するなら受け入れられると考える。NetBSD や QEMU は、現在の生成 AI では出力の由来を十分に確認できず、責任ある認証が成立しにくいと判断する。両者は人間の責任を重視する点では一致しており、人間の認証を支える証拠がどこまで必要かという評価で分かれている。
人間責任をガバナンスの中心に置くなら、署名を形式的な通過条件にしてはならない。提出者が変更内容を理解し、第三者コードとの関係を合理的に確認し、対象ライセンスで提供できる理由を説明し、疑義が生じた場合に調査と修正へ応答できることが必要になる。確認できない生成物を署名によって受け入れる運用は、人間へ責任を戻すのではなく、確認不能な権利状態へ人間の名前を付けるだけになる。
3. Linux カーネルは生成経路と人間の責任を分ける
3.1 AI は利用できるが Signed-off-by は付けられない
Linux カーネルは、AI を開発道具として利用すること自体を禁止していない。一方、AI が生成したコードをカーネルへ提出する場合でも、提出権限の認証、ライセンス適合性の確認、レビューへの応答、受入れ後の修正は人間が担う。公式文書は、AI エージェントが Signed-off-by を付けることを認めず、人間の提出者が生成されたコードをすべてレビューし、適用されるライセンス要件を確認し、自分の Signed-off-by によって DCO を認証し、コントリビューション全体へ責任を負うよう求めている[9]。
Signed-off-by を人間に限定する理由は、署名欄へ人名を残すためだけではない。DCO に基づく署名は、提出者がコードを自ら作成したか、適切なライセンスで提供された既存作品を基礎にしたか、認証された経路で受領したことを表明する行為である。AI はコード候補を生成できても、その出力をどの根拠で提出できるかを法的・制度的に表明し、後日その表明について説明する主体にはなれない。生成工程を AI に任せても、プロジェクトへ投入する判断までは委任できないという境界が、Signed-off-by によって明示される。
AI の関与そのものは Assisted-by などの記録へ残せる。Assisted-by が示すのは、実装、分析、文書作成などに外部の道具が関与した生成経路であり、法的責任や保守責任の移転ではない。AI の関与を記録したうえで、人間が提出を認証するため、誰が作業を補助したかという来歴と、誰が成果物を引き受けたかという責任を混同せずに済む。
Linux カーネルは、各ソースファイルへ正確な SPDX ライセンス識別子を付けることも求めている[10]。SPDX ライセンス識別子、Assisted-by、Signed-off-by、レビュー記録は、同じコミットの周辺に置かれることがあっても、担う機能は異なる。ライセンス表示は利用条件を伝え、生成経路の表示は作成過程を記録し、人間の署名は提出権限に関する認証を残し、レビューとテストは技術的な受入可否を判断する。
| 記録 | 担う役割 | 単独では確認できないこと |
|---|---|---|
| SPDX ライセンス識別子 | ファイルへ適用されるライセンス条件を機械可読な形で示す。 | 表示を付けた者が、そのライセンスで提供する権限を持つことまでは証明しない。 |
| Assisted-by | AI やその他の道具が生成、分析、修正へ関与した経路を示す。 | 提出権限、技術的品質、保守責任を道具へ移転しない。 |
| Signed-off-by | 人間が DCO に基づいて提出経路と提出権限を認証した記録を残す。 | 認証内容の正しさや、第三者権利が存在しないことを自動的には証明しない。 |
| レビューとテスト | 変更の必要性、正しさ、影響範囲、回帰、保守可能性を技術的に評価する。 | 著作権者、取得経路、再許諾権限を単独では確定しない。 |
この分業によって、一つの署名やタグに過剰な意味を持たせずに済む。AI が関与したことを開示しても、提出者の責任は減らない。反対に、人間が Signed-off-by を付けても、ライセンス確認や技術的レビューが不要になるわけではない。それぞれの記録を独立させることで、後から疑義が生じたときに、生成経路、権利表明、技術判断を別々に追跡できる。
3.2 AI だけでなくツール生成物一般を扱う
Linux カーネルには、生成 AI に関する文書に加えて、ツールが生成した内容全般を対象とする指針が置かれている。Kernel Guidelines for Tool-Generated Content は、意味のある量の内容が、Signed-off-by の連鎖に含まれる人間以外によって作られた場合を対象とする。チャットボットが生成した関数だけでなく、Coccinelle による変換、専用修正ツールによる差分、生成された変更説明、翻訳なども対象例に含まれる[11]。
この対象設定により、特定の製品名やモデル名が規則の基準にならない。生成技術が大規模言語モデルから別の方式へ変わっても、人間以外の仕組みが意味のある内容を作り、その内容がレビュー対象へ入るなら同じ原則を適用できる。技術ごとに新しい禁止規則を追加する方式より、生成量、変更の性質、説明可能性を基準にする方が、開発道具の変化に耐えやすい。
ただし、すべての機械的処理が同じ負担を生むわけではない。識別子の補完、定型的な構文、変数名の一括変更、整形といった操作では、変更内容と変換規則を人間が容易に確認できる。これに対し、設計判断を含む関数、複数ファイルに及ぶ修正、変更理由の文章まで生成された場合には、生成物だけを見ても、どこまで人間が判断したのか分かりにくい。現行方針が「AI を使ったか」ではなく「意味のある内容をどの程度生成したか」を見るのは、両者のレビュー負担が異なるためである。
生成量が増えると、提出前の作業時間は短くなる一方、受入側が確認すべき範囲は広がる。差分の各行が既存仕様に適合するか、暗黙の前提を壊していないか、テストが実装を追認するだけになっていないかを調べるには、カーネル固有の知識が必要になる。提出者がこの確認を行わなければ、生成側で削減された時間が、メンテナーによる再調査として発生する。作成コストの低下が、そのままプロジェクト全体の開発コスト低下にならない理由である。
この負担差を踏まえ、同文書は、生成された割合や内容に応じてメンテナーが追加審査を行うことを認めている。通常の貢献と同じように扱うだけでなく、追加テストを求め、詳細な生成過程や検証内容を質問し、レビューの優先順位を下げ、受入れを拒否することもできる。ツールが短時間で差分を作成できることから、プロジェクトに同じ速度でレビューする義務が生じるわけではない。
この方針は、レビュー帯域を有限な共有資源として扱っている。大量生成が可能になると、提出数を抑える技術的制約は弱まるが、変更の必要性と正しさを判断できるメンテナーの人数は増えない。人間以外による生成を開示させる目的は、AI を識別して排除することだけではなく、どの程度の検証を追加し、限られたレビュー時間をどこへ配分するか判断できるようにすることにある。
3.3 パッチはレビュー可能な単位でなければならない
ツール生成物に対する考え方は、AI の普及以前から存在する Linux カーネルのパッチ文化と連続している。パッチ提出ガイドは、一つのパッチで一つの論理的変更を扱い、何を変更したかだけでなく、なぜ変更が必要なのか、利用者や既存動作へどのような影響があるのかを説明するよう求めている[12]。複数の目的を持つ大きな差分は分割し、レビュアーが変更ごとに妥当性を判断できる単位へ整えなければならない。
AI によって複数ファイルの変更を一度に生成できるようになっても、レビューの認知的な単位は拡大しない。むしろ、生成された変更が広範囲に及ぶほど、どの差分が必須で、どの差分が付随的で、どの判断が AI の推測によって追加されたのかを分離する作業が必要になる。生成結果をそのまま一つのパッチへまとめれば、ある変更への反対が無関係な修正まで巻き込み、回帰が発生した際にも原因を特定しにくくなる。
レビュー可能な単位へ分割する作業は、書式を整えるための形式要件ではない。提出者が変更の因果関係を理解しているかを確認する試験になる。一つの修正を独立したパッチとして説明できるためには、変更前の状態、直接の不具合、修正によって変わる動作、影響を受ける利用者、必要なテストを把握しなければならない。AI が作った差分を理解せず提出した場合、この分割と説明の段階で不足が表面化する。
Linux カーネルの方針に賛同する理由は、AI を特殊な作者として扱わず、既存の提出、認証、レビュー、保守の制度へ接続している点にある。AI が作った候補を利用することと、候補をプロジェクトの成果物として採用することを分け、後者を人間の判断として扱う。人間が生成物を理解し、提出権限を確認し、レビュー可能な単位へ整え、指摘に応答できるなら、AI は開発能力を補助する道具になる。
反対に、提出者が差分を説明できず、ライセンス上の根拠を示せず、レビュー指摘への修正を再び AI へ委ねるだけなら、Signed-off-by は責任認証として機能しない。人間の名前が記録されていても、実質的な判断と対応能力が存在しないからである。人間責任型の成否は、署名の有無ではなく、提出者が採用判断を再現し、必要に応じて変更を撤回・修正できるかにかかっている。
既稿「AI が脆弱性を見つけても、安全になるとは限らない」では、脆弱性候補を生成する工程と、真偽を確認し、修正を設計し、公開手続きを進める工程を分けた[13]。Linux カーネルの方針も同じ構造を持つ。コードを生成できることは、提出可能であることを意味しない。生成物が人間による権利確認と技術的検証を通過し、プロジェクトが受け入れた時点で、初めてそのコードはオープンソースの保守対象になる。
4. 人間責任モデルにも成立条件がある
4.1 NetBSD は確認できない来歴を受け入れない
Linux カーネルの人間責任モデルは、AI が生成したコードであっても、人間が内容と権利状態を確認し、自分の署名で提出を認証できるという前提に立つ。この前提が成立しないと判断すれば、同じく人間の責任を重視するプロジェクトでも、結論は許可ではなく拒絶になる。NetBSD は、大規模言語モデルが生成したコードを原則として汚染コードと推定し、NetBSD Core による事前の書面承認がなければコミットできないとしている[14]。
NetBSD の方針は、生成 AI だけを例外的に嫌悪する形では組み立てられていない。既存のコミット規則では、自分で作成していないコードを取り込む場合、誰が作成したのか、どのライセンスが適用されるのか、他のコードを複製したものではないかを確認する必要がある。大規模言語モデルの出力についても同じ基準を適用し、作者と取得経路を確定できない以上、通常の外部コードより緩い条件では受け入れない。
この判断では、提出者が生成結果を読んだか、テストを通したか、将来の修正に応じる意思があるかだけでは足りない。技術的な理解があっても、第三者のコードを複製していないことや、対象ライセンスで再配布できることまで確認できるとは限らない。出自を確認できなければ提出権限を根拠付きで表明できず、その状態でコミットを受け入れれば、ライセンス上の不確実性が NetBSD とその下流利用者へ移る。
NetBSD が要求しているのは、責任を負うという意思ではなく、その責任表明を支える来歴である。提出者が誠実であっても、確認に必要な情報へアクセスできなければ、認証の信頼性は高まらない。人間責任モデルは、人間が署名欄に名前を書けるだけでは成立せず、提出権限を合理的に判断できる情報が存在することを必要とする。
4.2 QEMU は DCO を満たせるかを問う
QEMU も、生成 AI の利用一般ではなく、生成物をコントリビューションへ含める行為を問題にしている。QEMU は、AI が生成した内容を含む貢献や、その内容を基礎として作成した貢献を原則として受け入れない。一般的な生成 AI の出力について著作権とライセンス状態が明確ではなく、提出者が DCO の条件をどの根拠で満たせるのか確認できないためである[15]。
一方、API の利用方法やアルゴリズムを調査すること、静的解析の結果を解釈すること、デバッグの補助に使うことなど、AI の出力そのものを提出物へ含めない利用は対象外とされる。AI が調査の入口を示しても、人間が一次資料とソースコードを確認し、自分で変更を作成するなら、提出物の来歴を人間の作業として説明できる。生成されたコードや文章を直接取り込む場合には、この説明が難しくなる。
QEMU が引いている境界は、AI を開いた時点ではなく、AI 出力がリポジトリへ入る時点にある。調査補助であれば、出力に誤りがあっても、人間が確認する過程で除外できる。生成物を差分へ含めれば、誤りだけでなく、確認できない権利状態も成果物へ取り込まれる。技術的な欠陥はレビューやテストで発見できる可能性があるが、非公開の学習データや生成経路に由来する権利上の疑義は、ソースコードを読むだけでは解消できない。
Linux カーネルと QEMU は、人間が最終責任を負うべきだという原則では大きく離れていない。Linux カーネルは、人間が生成物を全面的にレビューし、ライセンス適合性を確認して DCO を認証できるなら受け入れる。QEMU は、現在の一般的な生成 AI では、その認証に必要な情報を提出者が得られないため、適切な DCO 認証が成立しにくいと判断する。
| 観点 | Linux カーネル | NetBSD・QEMU |
|---|---|---|
| 人間の責任 | 生成物を理解し、ライセンスを確認し、署名する人間へ最終責任を置く。 | 人間が責任を負う原則自体は維持する。 |
| 認証可能性 | 人間による十分な確認を経れば、提出権限を認証できると判断する。 | 現在の生成 AI では、確認に必要な来歴が不足し、認証が成立しにくいと判断する。 |
| 受入方針 | 開示、レビュー、DCO 認証を条件として受け入れる。 | 事前承認などの例外を除き、生成物の提出を受け入れない。 |
| 主な失敗条件 | 提出者が内容を理解せず、署名だけを形式的に行うと人間責任モデルが形骸化する。 | 有用な生成補助まで一律に排除すると、調査や解析に利用できる道具の範囲を不必要に狭める。 |
許可型と禁止型の差は、人間へ責任を置くかどうかではなく、人間の表明を支える証拠が十分かという評価にある。責任の所在を明確にしても、提出者が確認できない事実まで保証させれば、制度は実質的な認証ではなく、未知の危険を個人名へ帰属させる手続きになる。反対に、来歴を完全に証明できなければ一切利用できないとすれば、通常の外部コードや既存のコード生成器にも同じ厳格さを適用できるのかという整合性が問われる。
4.3 FreeBSD は拙速に結論を固定していない
FreeBSD Core Team は、生成 AI の用途を一括して評価していない。翻訳、長い文書の説明、バグ探索、既存コードベースの理解には有用性がある一方、ライセンス上の懸念から、コード生成物を直接取り込む利用には慎重な姿勢を示している[16]。その後も、著作権、コードの来歴、コミッターと外部貢献者に適用する条件、他のオープンソースプロジェクトとの整合を検討しながら方針策定を続けている[17]。
この保留には実務上の理由がある。生成 AI の利用場面は、文章の要約から複数ファイルの自律的変更まで幅が広く、すべてを一つの許可または禁止で扱うと、規則と実際の危険が一致しなくなる。翻訳候補を人間が確認する作業と、生成されたドライバーをそのままコミットする作業では、権利、品質、影響範囲、レビュー負担が異なる。用途別の差を無視して制度を固定すれば、低リスクの利用を不必要に妨げるか、高リスクの利用へ不十分な条件しか課せない。
執行可能性も方針設計を左右する。AI 使用を全面禁止しても、識別子補完や文章校正まで外部から確実に検出することは難しい。開示を義務化しても、何文字以上、どの程度の変更、どの種類の支援を申告対象にするかが曖昧なら、利用者ごとに運用が分かれる。生成物の割合だけで判定すれば、少量でも設計上重要な変更を見落とし、大量でも機械的な整形へ過剰な手続きを要求する。
方針を確定しない期間は、規律が存在しない期間と同じではない。既存のライセンス規則、コミット権限、レビュー要件、メンテナーの裁量は引き続き適用できる。そのうえで、どの利用を追加開示の対象とし、誰にどの確認を求め、外部貢献者へどこまで同じ条件を課すかを整理する。法的な不確実性と実際の開発工程を対応させてから制度化する方が、抽象的な賛否を先に固定するより運用可能性は高い。
FreeBSD の検討過程から得られるのは、慎重さと禁止を同一視できないという点である。明確な方針を早く示すことには予測可能性を高める利点があるが、適用対象と確認方法が定まっていなければ、規則は形式だけが残る。AI ガバナンスでは、宣言の強さより、開発者が具体的な変更について受入可否を判断できることが必要になる。
人間責任モデルを採用する場合にも、同じ運用上の検査が要る。署名した人間が変更を読まず、設計理由を説明できず、レビュー指摘への回答を再び AI に生成させるだけなら、その人間は判断主体ではなく名義人にすぎない。責任主体として扱うには、出力を拒否できること、変更範囲を縮小できること、権利上の疑義があれば提出を中止できること、採用後に欠陥が判明すれば修正または撤回できることが必要になる。
この成立条件を欠いたまま「最終責任は人間にある」と定めても、確認不能な来歴とレビュー負担がプロジェクトへ残る。Linux カーネル型の方針が実用的なのは、人間の名前を記録するからではなく、提出前の全面的なレビュー、DCO に基づく認証、生成経路の開示、レビュー可能なパッチという具体的な手続きを組み合わせているからである。人間責任は原則だけでは完結せず、人間が実際に判断し、拒否し、説明し、修正できる工程によって初めて成立する。
5. レビュー帯域と共同体の維持もガバナンスの対象になる
5.1 AI は提出コストを下げてもレビューコストを消さない
オープンソースプロジェクトでは、コードを書ける人数と、コードを受け入れる判断ができる人数は一致しない。外部から Pull Request を送ることは多くの参加者に開かれていても、既存設計、過去の不具合、互換性要件、リリース方針まで理解してレビューできる人間は限られる。メンテナーの時間と注意は、追加の計算資源を購入するようには増やせない共有資源である。
生成 AI は、提出側に必要だった作業の一部を短縮する。コードだけでなく、テスト、Issue、変更説明、設計案、レビューへの回答まで短時間で生成できるため、一人の参加者が作成できる提案数は増える。しかし、提出数が増えても、各変更が本当に必要か、既存の抽象化を壊していないか、テストが仕様を検証しているか、それとも生成された実装を追認しているだけかを判断する作業は残る。
この非対称によって、生成側で減った費用が受入側へ移る。提出者が 10 分で作成した差分であっても、メンテナーは関連する設計、過去の議論、影響範囲、失敗時の挙動を確認しなければならない。生成された説明まで誤っていれば、差分だけでなく説明の前提から再検証する必要がある。提出コストの低下が提案数の増加を生み、その増加がレビュー待ちを長期化させると、適切に準備された人間の貢献まで埋もれる。
LLVM は、この負担転嫁を方針上の問題として明示している。提出者は、LLM が生成したコードや文章を自分で読み、内容を検証してから、他のメンバーへレビューを依頼しなければならない。さらに、レビューと統合に必要な限界費用が、プロジェクトにもたらす利益を上回る貢献を「抽出的な貢献」と位置付けている[18]。
抽出的という評価は、生成 AI を使用したという事実だけで決まらない。小さな修正であっても、必要性が説明されず、提出者が質問へ答えられず、メンテナーが設計から調べ直さなければならないなら、プロジェクトから作業時間を引き出す。一方、AI を使った広い変更でも、提出者が差分を分割し、各変更の理由を示し、テストと既存仕様との対応を説明できるなら、レビュー負担を制御できる。判断基準は生成手段ではなく、受入れに必要な追加作業と、変更によって得られる便益の関係にある。
| 提出状態 | 提出者が省略した作業 | メンテナー側に生じる作業 | プロジェクト上の帰結 |
|---|---|---|---|
| 目的が説明されていない大量差分 | 変更の選別、分割、必要性の検討が省略されている。 | 各変更が必要か、相互に独立しているかを受入側が調べる。 | 有用な部分が含まれていても、レビュー費用が便益を上回りやすい。 |
| 生成された説明を未確認で添付 | 説明と実装が一致するかの照合が省略されている。 | 差分だけでなく、説明に含まれる前提と主張も再検証する。 | 文章が整っているほど、誤った前提を見抜く費用が増える。 |
| テストを含むが仕様との対応が不明 | 何を保証するテストか、失敗条件は何かという検討が省略されている。 | テストが既存仕様を検証しているか、実装を固定しているだけかを確認する。 | テスト件数が増えても、回帰検出能力が高まらない場合がある。 |
| 理解、分割、検証を終えた差分 | 生成作業だけが道具へ委ねられ、採用判断は人間が行っている。 | 提示された理由、影響範囲、テスト結果を基に通常のレビューを進められる。 | AI の生成能力を利用しながら、レビュー負担の一方的な転嫁を避けられる。 |
5.2 初学者向け課題は未処理作業の在庫ではない
LLVM は、AI によって good first issue を解決することも禁止している[18]。この規則は、簡単な作業を人間だけに独占させるためのものではない。good first issue は、新しい参加者がコードベースを読み、ビルドとテストの手順を覚え、変更説明を書き、メンテナーとのレビュー対話を経験するために選ばれている。
AI が課題を短時間で処理すれば、未解決 Issue の件数は減る。しかし、新しい参加者が調査、失敗、修正、説明を経験しなければ、プロジェクト固有の知識は蓄積されない。入口となる課題が減ることで参加者の学習機会が減り、その結果として将来レビューや保守を担える人間も増えにくくなる。短期的な処理件数の改善が、長期的な保守能力の低下を招く可能性がある。
オープンソースの作業には、成果物を作る機能と、参加者を育てる機能が同時に含まれる。単純な修正、文書の更新、小規模なテスト追加は、経験豊富な開発者や AI に任せれば短時間で終えられる。それでも初学者へ残されるのは、作業そのものより、作業を通じてプロジェクトの規則と判断基準を学ぶ価値があるためである。
すべての初学者向け課題を教育目的で保存する必要はない。利用者へ影響する不具合を放置したり、セキュリティ修正を遅らせたりする理由にはならない。一方、課題管理を未処理件数の削減だけで評価すると、共同体が次のメンテナーを育てる経路が見えなくなる。AI ガバナンスには、現在の作業量だけでなく、知識が誰へ移り、将来の判断能力がどこに形成されるかという時間軸も必要になる。
5.3 Python と Fedora は成果物だけでなく提出者の行動を問う
Python の開発者ガイドは、AI の利用有無にかかわらず、Issue や Pull Request を提出した人が内容へ責任を持つと定めている。提出者には、AI が作成した内容を詳細に確認し、自分の言葉で変更を説明し、必要な範囲へ差分を絞り、既存のテストを迂回して失敗を隠さないことが求められる[19]。
これらは成果物の外見だけからは確認しにくい条件である。生成された説明が流暢で、テストがすべて成功していても、提出者が変更理由を理解しているとは限らない。そこで Python は、AI の使用を検出しようとする代わりに、レビューで観察できる提出者の行動を受入条件にしている。変更を自分の言葉で説明できるか、質問に応じて差分を変更できるか、テスト失敗の原因を追えるかという行動は、生成履歴が見えなくても確認できる。
Fedora の方針も、AI 支援を受けた貢献について、提出者が品質、ライセンス適合性、有用性を保証し、貢献全体へ責任を負うと定める。意味のある AI 利用については Assisted-by などによる開示を強く推奨し、AI を人間や貢献物の最終評価者として使用してはならないとしている[20]。この方針は 2025 年 10 月、Fedora Council によって全会一致で承認された[21]。
Fedora が AI を最終評価者にしない理由は、AI の評価精度が常に低いからではない。プロジェクトへの参加資格、貢献者の行動、コードの受入可否を決める判断には、説明、異議申立て、方針との整合、個別事情への配慮が必要になる。AI が候補や分析を示すことはできても、誰を受け入れ、誰の変更を拒否するかという制度上の決定まで委ねれば、判断主体が不明確になる。
| プロジェクト | 主な受入条件 | 保護しようとする資源 | 防ごうとする失敗 |
|---|---|---|---|
| LLVM | 生成内容を人間が事前に読み、レビュー費用が便益を超える貢献を送らない。 | メンテナーのレビュー時間と、新規参加者の学習機会を保護する。 | 生成側が省いた確認作業を、受入側と初学者へ転嫁することを防ぐ。 |
| Python | 提出者が内容を理解し、自分の言葉で説明し、必要な小規模変更へ絞る。 | レビュー可能性、変更履歴の説明可能性、テストの信頼性を保護する。 | 流暢な説明や表面的なテスト成功によって、理解不足が隠れることを防ぐ。 |
| Fedora | 提出者が品質、ライセンス、有用性へ責任を持ち、意味のある AI 支援を開示する。 | 成果物への信頼、貢献者間の透明性、人間による最終判断を保護する。 | AI を責任主体や人間の評価者として扱い、判断主体が消えることを防ぐ。 |
三つのプロジェクトに共通するのは、AI が使用されたかという一事実だけで受入可否を決めていない点である。AI 使用の完全な検出は難しく、少量の補完と大規模な自動生成を同列にも扱えない。そのため、提出者が内容を統制できるか、変更が必要か、レビュー可能な単位か、プロジェクトへ与える利益が受入費用を上回るかという、実際の開発行為を評価している。
この方式では、人間を処理の最後に配置するだけでは足りない。提出者が生成物を拒否できず、レビュー指摘への回答も AI の提案を転送するだけなら、変更の目的と結果を統制していない。人間責任モデルが求めるのは、成果物に名前を付けることではなく、生成、選別、説明、修正の各段階で判断権を行使することである。
5.4 人間による承認を儀式にしない
コーディングエージェントは、リポジトリを読み、複数ファイルを変更し、テストやビルドを実行し、外部サービスへ接続し、Pull Request の作成まで進められる。権限が広いほど作業を連続して処理できるが、誤った前提に基づく変更も同じ範囲へ拡大する。最初の設計判断が誤っていれば、後続の実装、テスト、説明が互いに整合しながら、全体として誤った変更になる場合もある。
この種の失敗は、最終差分だけを確認する運用では見つけにくい。数十ファイルの変更、生成されたテスト、整った説明を最後にまとめて提示されれば、承認者は各判断を再検証するより、全体が一貫して見えることを根拠に受け入れやすくなる。作業量が増えるほど確認が形式化し、承認回数が増えるほど一件ごとの注意が薄れる。人間を最後に置いても、判断に必要な時間と情報がなければ、承認は責任統制ではなく確認儀式になる。
既稿「Devin と Claude Code の違いは、作業の任せ方にある」では、自律的な作業環境への入口で承認する方式と、ファイル変更やコマンド実行など個々の行為に承認点を置く方式を整理した[22]。どちらが適切かは作業の危険度によって変わる。読み取り中心の調査であれば広い裁量を与えられるが、認証処理、暗号実装、依存関係更新、本番設定の変更では、途中の判断を確認できる承認点が必要になる。
有効な人間関与には、少なくとも四つの能力が要る。変更内容を理解できる知識、確認に使える時間、処理を停止または却下できる権限、採用後に修正または撤回できる継続性である。いずれかが欠ければ、人間が画面上で承認していても、実質的な統制は成立しない。
| 成立条件 | 人間に必要な能力 | 欠けた場合の状態 |
|---|---|---|
| 理解 | 変更理由、実装、影響範囲、テストの意味を説明できる。 | 出力の妥当性を判断できず、AI の提案を追認するだけになる。 |
| 時間 | 差分と根拠を確認し、必要なら追加調査を行える。 | 大量の変更を形式的に承認し、見落としが増える。 |
| 権限 | 処理を停止し、範囲を縮小し、生成結果を却下できる。 | 人間が確認しても、実際には進行を変えられない。 |
| 継続性 | 受入れ後の質問、回帰、脆弱性、ライセンス上の疑義へ対応できる。 | 提出時だけ人間が存在し、保守責任がプロジェクトへ残る。 |
human-in-the-loop という表現が意味を持つのは、人間が処理の途中で判断を変えられる場合である。最後に承認ボタンを押すだけでは、AI の自律性へ人間の名前を付けたにすぎない。変更を却下し、別の設計を選び、作業範囲を狭め、説明を作り直し、必要なら提出を中止できて初めて、人間が判断主体として機能する。
レビュー帯域、初学者の学習機会、判断権限は、ライセンス文からは見えない。しかし、これらが失われれば、コードの受入れと保守を続ける共同体そのものが弱くなる。オープンソース AI ガバナンスが守る対象は、個々の生成物の正しさだけではない。限られたレビュー能力を誰が使用し、知識を次の参加者へどう移し、最終判断をどの人間が引き受けるかという、開発共同体の継続条件も含まれる。
6. Debian の現在は下流プロジェクト固有の難しさを示す
6.1 制度選択の途中にある
調査日時点で、Debian は生成 AI を利用した貢献について最終方針を決定していない。審議中の General Resolution には、Debian への直接貢献を原則として禁止する立場、条件を満たせば認める立場、可能な限り利用を避ける立場、提出者へ責任を集中させる立場、既存の規則を技術中立的に適用する立場が並んでいる[1]。General Resolution は、個別パッケージの技術判断ではなく、Debian 開発者全体がプロジェクトの方針を決定する正式な手続きである[23]。
この議論が正式な意思決定手続きへ進んだ理由は、生成 AI の利用が特定の開発者だけで完結しないためである。AI が作成したコードや文書が Debian のリポジトリへ入れば、パッケージメンテナーだけでなく、レビュー担当者、リリースチーム、セキュリティチーム、ミラー運営者、下流利用者まで影響を受ける。利用者本人が出力を受け入れられると判断しても、その判断に伴う権利上の不確実性と保守負担は、Debian 全体の配布工程へ広がる。
General Resolution に並ぶ立場は、生成 AI に賛成か反対かという一つの軸では整理できない。各立場は、少なくとも三つの判断で異なる。第一は、提出者が AI 出力の来歴と提出権限をどこまで認証できるかである。第二は、生成量の増加によって生じるレビュー負担を、誰が提出前に引き受けるかである。第三は、Debian が直接管理できない上流由来のコードを、どの根拠で再配布するかである。
| 論点 | Debian が決める必要があること | 判断を誤った場合の帰結 |
|---|---|---|
| 提出権限 | AI 出力を Debian へ持ち込む人間に、どの範囲の来歴確認と権利表明を求めるかを決める。 | 確認できない権利状態が Debian の配布物へ入り、後から削除や再実装が必要になる。 |
| レビュー負担 | 提出者が生成物をどこまで理解、検証、整理してからレビューを依頼するかを決める。 | 生成側が省いた作業がメンテナーへ移り、通常の保守と他の貢献が停滞する。 |
| 上流との関係 | 上流の認証と公開記録へどこまで依存し、どの条件で取り込みを中止するかを決める。 | 確認不能な生成工程まで Debian が保証するか、逆に再配布実務が成立しないほどの確認を求めることになる。 |
投票によって一つの方針が採択されても、この三つの判断が消えるわけではない。決議が定められるのは、Debian がどの危険を許容し、どの作業を提出者へ要求し、どの不確実性をプロジェクトとして引き受けるかである。General Resolution は AI の性質を確定する手続きではなく、確定できない部分を含む成果物を、どの条件で Debian の配布工程へ入れるかを決める手続きである。
6.2 Debian は上流の生成工程を完全には統制できない
Debian は、プロジェクト内部だけで開発されたコードを配布しているわけではない。Linux カーネル、言語処理系、デスクトップ環境、サーバーソフトウェア、各種ライブラリなど、多数の上流プロジェクトが公開した成果物を選択し、パッケージ化し、Debian 固有の設定や修正を加えて利用者へ再配布している。この構造では、Debian が直接統制できる工程と、上流の判断へ依存する工程が分かれる。
Debian が統制できるのは、Debian 固有のパッケージングファイル、追加パッチ、バグ報告、翻訳、文書、レビュー、アップロード手続きである。これらについては、生成 AI の使用条件、開示方法、提出前の確認、署名者の責任を Debian 自身が定められる。一方、上流のソースコードがどの補完機能を使って書かれたか、開発者が非公開の AI 対話を利用したか、モデルがどの学習データから影響を受けたかまで、Debian のメンテナーが遡って確認することはできない。
上流プロジェクトの方針も統一されていない。Linux カーネル、LLVM、Python、Fedora のように、人間による確認と責任を条件として AI 支援を認めるプロジェクトがある。NetBSD や QEMU のように、出力の来歴と DCO 認証に疑義があることを理由として、生成物の提出を原則拒否するプロジェクトもある。同じ Debian アーカイブの中に、異なる受入基準を経た上流成果物が共存することになる。
| 情報 | Debian が通常確認できる範囲 | Debian が通常確認できない範囲 |
|---|---|---|
| ライセンス | 上流のライセンス文、著作権表示、ソースファイルの識別子、配布条件を確認できる。 | 表示されていない第三者コードの混入や、表示を付けた者の認証根拠までは完全に確認できない。 |
| 変更履歴 | 公開コミット、Pull Request、レビュー記録、リリース履歴を確認できる。 | 公開前に使用された非公開の生成履歴、破棄された出力、開示されなかった AI 利用は確認できない。 |
| 上流方針 | 上流プロジェクトが公表している貢献規則、DCO、CLA、AI 利用方針を確認できる。 | すべての貢献者が方針を遵守したことや、違反を上流が検出できたことまでは保証できない。 |
| 技術的品質 | Debian 上でのビルド、テスト、静的解析、既知の脆弱性、パッケージ間の整合を確認できる。 | 上流設計者が採用した判断の全過程や、未公開の入力に依存する失敗条件までは再現できない。 |
| Debian 固有変更 | パッケージング、追加パッチ、設定、文書について、提出者とレビュー履歴を直接管理できる。 | 固有変更が依存する上流部分の生成経路まで、Debian の規則で統一することはできない。 |
この情報差があるため、Debian メンテナーへ上流の全生成工程を保証させる制度は実行できない。すべての開発者が利用したエディター、補完機能、対話履歴、学習データまで確認しなければ取り込めないとすれば、通常のパッケージ更新も成立しなくなる。逆に、上流が公開したライセンス表示だけを無条件に信頼すれば、上流で見落とされた権利問題や生成物の欠陥が、そのまま Debian の配布物へ入る。
下流プロジェクトに可能なのは、保証範囲を無制限に広げることではなく、依存する認証経路を明確にすることである。上流の公開方針、ライセンス表示、コミット履歴、署名、レビュー記録を通常の信頼根拠とし、矛盾や疑義が見つかった場合には取り込みを停止する。Debian 固有の変更については、自らの規則によって提出者、生成経路、技術検証を管理する。確認可能な範囲と上流へ依存する範囲を分けることで、下流配布者として負える責任の境界が定まる。
この構造は、上流の説明を無条件に信じることを意味しない。信頼できる上流方針がなく、著作権表示が不整合で、生成物の由来について具体的な疑義があり、修正にも応答がない場合には、Debian は取り込みや再配布を止める必要がある。責任ある下流プロジェクトとは、上流のすべてを知るプロジェクトではなく、どの証拠を信頼し、どの異常を停止条件とするかを説明できるプロジェクトである。
6.3 投票結果が出ても残る運用上の判断
Debian が生成 AI に厳格な方針を採用した場合、Debian 固有の直接貢献については利用を抑制できる。しかし、AI 支援を認める上流からコードを取り込む限り、アーカイブ全体から AI の影響を排除することはできない。上流の全コードを Debian 内で人間だけによって再実装しない限り、規制対象は Debian が直接管理する工程に限定される。
条件付き許可を採用した場合には、開示、確認、署名、レビューという手続きを設けられる。一方、提出者がどこまで出力の来歴を調べれば十分か、識別子補完と実装生成をどう分けるか、大量変更へどの段階で事前承認を求めるかという運用基準が必要になる。方針文が人間の責任を定めても、確認の深さと拒否条件が曖昧なら、メンテナーごとに受入基準が分かれる。
既存規則を継続適用する場合にも、AI を従来のコード生成器と同じ道具として扱える範囲を決めなければならない。決定的な変換規則に従う生成器と、入力に対して確率的に内容を作る大規模言語モデルでは、出力の再現性と来歴確認の方法が異なる。さらに、自律エージェントが複数ファイルを変更し、テストを作成し、説明文まで生成する場合、単一の補助道具という整理では、判断を委任した範囲を捉えきれない。
| 方針の方向 | 直接得られる効果 | 決定後にも残る課題 |
|---|---|---|
| 原則禁止 | Debian 固有の貢献へ確認不能な生成物が入る機会を減らせる。 | 上流由来コード、利用検出、軽微な補完との境界を別途扱う必要がある。 |
| 条件付き許可 | 有用な支援を残しながら、開示、確認、責任を提出者へ要求できる。 | 十分な確認の水準、生成量の基準、違反時の処理を具体化する必要がある。 |
| 既存規則の適用 | 特定技術へ依存せず、品質、ライセンス、保守性の原則を維持できる。 | 確率的生成、自律実行、大量提出が既存制度の想定内かを個別に判断する必要がある。 |
どの方針でも、ライセンス、来歴、提出認証、技術検証、レビュー帯域、上流への依存を一つの規則だけで処理することはできない。投票で決まるのは、Debian がどの方向から制度を組み立てるかであり、個々のパッケージと貢献について必要になる判断まで自動化されるわけではない。決議後には、メンテナーが実際に適用できる指針、開示方法、例外手続き、停止条件へ落とし込む作業が残る。
Debian の事例から導かれる帰結は、AI を禁止するか許可するかという二択ではない。上流が行った認証をどこまで信頼し、Debian 固有の変更を誰が引き受け、疑義が生じたときにどこで配布を止めるかを制度として示す必要がある。下流の AI ガバナンスとは、見えない生成工程を完全に支配することではなく、確認できる証拠、依存する表明、受入れを拒否する条件を結び付けることである。
7. オープンソース AI ガバナンスは複数の統制を組み合わせる
7.1 一つの表示や規則では異なる危険を処理できない
AI 生成コードを受け入れる際には、ライセンス、生成経路、提出権限、技術的品質、自律的な操作範囲、問題発生後の対応を確認する必要がある。これらは相互に関係するが、同じ問いではない。適切なオープンソースライセンスが表示されていても、提出者にそのライセンスで提供する権限があるとは限らない。生成経路が開示されていても、コードが安全であるとは限らない。人間が署名していても、実装を理解せず、問題発生後に修正できなければ、責任認証は実質を失う。
一つの制度へ複数の役割を負わせると、記録が存在することと、必要な確認が終わっていることが混同される。たとえば、Assisted-by は生成 AI の関与を示せるが、第三者コードが含まれていないことを証明しない。Signed-off-by は人間による DCO 認証を記録するが、コードの正しさや安全性を保証しない。SPDX ライセンス識別子は利用条件を明確にするが、その表示を付けた人の権限を自動的には検証しない。
必要なのは、各制度が何を確認し、どの不確実性を残すのかを明示したうえで、同じコントリビューションへ複数の統制を重ねることである。本稿では、オープンソース AI ガバナンスを、利用許諾、来歴、提出認証、技術検証、自律性管理、事後対応の六つに分ける。
| 統制層 | 中心となる問い | 主な手段 | 単独では確認できないこと | 欠けた場合の帰結 |
|---|---|---|---|---|
| 利用許諾 | どの条件で使用、改変、再配布できるかを確認する。 | オープンソースライセンス、SPDX ライセンス識別子、著作権表示を用いる。 | 表示を付けた者の提出権限や、第三者コードが含まれていないことまでは確認できない。 | 下流利用者が守るべき条件と、再配布できる範囲が不明になる。 |
| 来歴 | 何が誰またはどの道具によって作られ、どの処理を経て現在の形になったかを確認する。 | Assisted-by、コミット履歴、生成条件、入力と処理内容の要約を記録する。 | 生成物の法的適合性や技術的品質までは保証できない。 | 問題が判明しても、影響を受ける変更と生成経路を追跡できない。 |
| 提出認証 | 誰が提出権限を表明し、どの根拠を自分の判断として引き受けるかを確認する。 | DCO、Signed-off-by、貢献者契約によって権利表明を記録し、必要に応じて GPG 署名で署名者と内容の同一性を確認する。 | 表明内容が客観的に正しいことや、コードに欠陥がないことまでは保証できない。 | 権利状態に疑義が生じても、表明主体と提出経路を確認できない。 |
| 技術検証 | 変更が必要であり、正しく、安全で、既存設計と両立し、保守可能かを確認する。 | 人間レビュー、テスト、静的解析、再現手順、論理単位へ分割した差分を用いる。 | 著作権者や再許諾権限などの法的来歴までは確定できない。 | もっともらしい出力が、仕様との対応を確認されないままコードベースへ入る。 |
| 自律性管理 | AI がどの範囲まで単独で読み、変更し、実行し、外部へ投稿できるかを確認する。 | 権限の最小化、途中承認、実行環境の分離、投稿前確認、大量変更の事前協議を用いる。 | 承認された変更の技術的正しさや提出権限までは保証できない。 | 一つの誤判断が複数ファイル、外部サービス、公開リポジトリへ連続して作用する。 |
| 事後対応 | 問題が判明した後に、誰が調査、修正、撤回、再配布、利用者への通知を行うかを確認する。 | 担当者、監査記録、修正手順、下流通知、セキュリティ対応経路を定める。 | 問題の発生自体を防ぐことや、提出時の認証を代替することはできない。 | 責任者の名前だけが残り、実際の回復作業を実行できない。 |
六つの統制は順番に一度ずつ通過すれば終わる工程ではない。提出時には、利用許諾、来歴、提出認証、技術検証を確認する。自律エージェントを利用する場合には、その前段階で権限と承認点を設計する。受入れ後に脆弱性や権利上の疑義が判明すれば、保存された来歴と認証記録を使って影響範囲を特定し、事後対応へつなげる。各層が独立して記録されていなければ、後の工程が前の工程を追跡できない。
たとえば、AI が生成した関数にライセンス上の疑義が生じた場合、ライセンス表示だけを確認しても生成経路は分からない。Assisted-by が残っていれば AI の関与は分かるが、どの人間が提出可能と判断したかは Signed-off-by などの認証記録を見なければならない。対象コミットを特定した後も、削除すればよいのか、同じ仕様を維持した再実装が必要なのか、下流リリースへ通知すべきかを判断するには、レビュー記録と配布履歴が必要になる。
7.2 機械可読な記録は責任を履行するための基盤になる
REUSE Specification は、各ファイルの著作権者と適用ライセンスを、人間と機械の双方が確認できる形で記録する方法を定めている[24]。ファイルごとのライセンス情報が明確であれば、パッケージ全体のライセンスを推測する必要が減り、ファイルの追加、移動、再利用が行われた後も条件を追跡しやすくなる。
SPDX 3.0.1 は、ソフトウェア構成、作成者、供給者、配布者、来歴、完全性、ライセンス、著作権、AI モデル、データセット、品質情報を別々の要素として表現できる[25]。さらに Annotation は、対象要素について誰がどの時点で何を表明したかを追加記録する枠組みを提供する[26]。
これらの仕様を導入しても、AI 生成コードの法的状態が自動的に確定するわけではない。誤ったライセンス情報を機械可読にしても、誤りが正しくなることはない。生成経路を詳細に記録しても、提出者が内容を理解していなければ技術的責任は成立しない。仕様が提供するのは判断そのものではなく、判断に使った情報と表明を、後から検査できる形で保存する能力である。
この違いは、透明性を責任の代替にしないために必要である。AI の利用を開示しただけで、ライセンス確認やレビューの責任が軽くなるわけではない。一方、何も記録されていなければ、問題が起きた後に、誰がどの情報を基に採用したのかを再構成できない。透明性は責任そのものではないが、責任者が調査、説明、修正を実行するための前提になる。
| 記録対象 | 保存する情報 | 事後対応での利用 |
|---|---|---|
| ライセンス情報 | ファイルまたは構成要素ごとのライセンスと著作権表示を保存する。 | 疑義のあるコードがどの配布条件へ影響するかを特定する。 |
| 生成経路 | 使用した道具、生成対象、入力の種類と制約、生成後の人間による修正を、機密情報を含めない範囲で保存する。 | 同じ条件で作られた変更や、同じ出力を基礎にした派生箇所を探索する。 |
| 提出認証 | 提出者、署名、適用された DCO または貢献者契約を保存する。 | 提出時に誰がどの権限を表明したかを確認し、追加説明を求める。 |
| レビュー記録 | 指摘事項、テスト結果、受入理由、残された制約を保存する。 | 受入時に確認済みだった範囲と、未確認だった範囲を区別する。 |
| 配布履歴 | 対象変更を含むリリース、パッケージ、下流配布先を保存する。 | 修正版の配布先と、通知が必要な利用者の範囲を確定する。 |
7.3 AI を使ったかではなく、行為と影響で要求を変える
すべての AI 利用へ同じ手続きを要求すると、危険と統制の強さが一致しなくなる。識別子の補完と、認証処理を含む複数ファイルの自律的変更を、同じ「AI を利用した変更」として扱えば、前者には過剰な申告を求め、後者には不十分な確認しか課さない制度になる。
規制の基準には、使用した製品名ではなく、生成された内容の意味、変更範囲、自律性、検証可能性、可逆性、失敗時の損害を用いる必要がある。製品名を基準にすれば、同じ道具でも利用方法が異なる場合を扱えず、別の技術へ置き換わるたびに方針を更新しなければならない。行為と影響を基準にすれば、将来の生成技術にも同じ判断軸を適用できる。
| 利用形態 | 判断を伴う範囲 | 主な失敗条件 | 必要な統制 |
|---|---|---|---|
| 識別子や定型句の補完 | 既存の文脈から短い表記を補い、変更範囲を差分から容易に確認できる。 | 誤った変数や API 名を選択するが、通常は局所的な差分として発見できる。 | 通常のレビューを基本とし、生成手段によって追加の不確実性が生じる場合だけ補足する。 |
| 関数やテストの生成 | アルゴリズム、例外処理、境界条件、既存仕様との対応を生成物が決定する。 | 実装とテストが同じ誤った前提から生成され、相互に正しいように見える。 | 提出者による設計説明、対象範囲の実行結果、独立したテスト観点、意味のある AI 関与の開示を求める。 |
| 複数ファイルの実装 | 複数の構成要素、依存関係、公開 API、設定、文書を同時に変更する。 | 一つの誤った設計判断が広い差分へ展開され、原因特定と切り戻しが難しくなる。 | 論理単位への分割、独立した人間レビュー、変更間の依存関係、来歴、テスト方針を記録する。 |
| 暗号、認証、権限制御、課金 | 秘密情報、アクセス権、金銭、利用者の安全へ直接影響する判断を含む。 | 通常テストでは見つからない設計欠陥が、権限昇格、情報漏えい、不正請求へつながる。 | 分野の専門家による独立レビュー、脅威分析、負の試験、既存標準との照合を要求する。 |
| 自律エージェントによる投稿 | リポジトリの変更だけでなく、Issue、Pull Request、レビューコメントを外部へ公開する。 | 人間が確認する前に誤情報、機密情報、大量の低品質な提出物が公開される。 | 投稿前承認、権限の最小化、監査ログ、即時停止手段、プロジェクト側の事前同意を求める。 |
| 大量または反復的な変更 | 同じ規則を多数のファイルやパッケージへ適用し、総変更量が大きくなる。 | 一件ごとの誤りが小さくても、全体では広範な回帰とレビュー負担を生む。 | 実行前の協議、限定範囲での試行、全体検証の方法、段階的投入、切り戻し手順を求める。 |
変更規模だけでも危険度は決まらない。一行の認証条件変更は、数百行の文書更新より影響が大きい場合がある。反対に、多数のファイルを対象とする機械的なライセンス識別子の修正は、変換規則と全件検査が明確であれば、大規模でも検証しやすい。生成量、自律性、影響範囲、検証可能性は、それぞれ独立した軸として評価しなければならない。
自律性が高い処理では、結果のレビューだけでなく、実行前の権限設計が必要になる。リポジトリの読み取りだけを許可する場合と、ファイル変更、任意コマンド実行、秘密情報へのアクセス、外部投稿まで許可する場合では、失敗時の作用範囲が異なる。最終差分を人間が確認するという条件だけでは、確認前に行われた外部通信や情報漏えいを取り消せない。
高リスク領域では、生成者と提出者が同一人物であっても、独立したレビューが必要になる。AI を利用した本人は、生成時に与えた前提や採用した設計に引きずられやすく、同じ観点から作成したテストも同じ誤りを共有する可能性がある。認証、暗号、権限制御では、別の人間が異なる脅威モデルと失敗条件から検査することで、生成者と提出者の確認だけでは残る偏りを減らせる。
7.4 受入条件は失敗時の作用範囲から逆算する
統制の強さは、AI の能力が高いか低いかではなく、誤った出力が採用されたときに何が起きるかから決める必要がある。誤った識別子補完であれば、コンパイル失敗や局所的なテストによって発見できる可能性が高い。認証処理の誤りは、テストを通過したまま権限昇格へつながる場合がある。自律エージェントによる誤投稿は、コードがマージされなくても、機密情報の公開やメンテナーへの大量通知を発生させる。
影響が限定的で、容易に検出でき、切り戻し可能な変更には、通常のレビューを適用できる。影響が広く、発見が遅れ、下流へ再配布され、修正費用が高くなる変更には、提出前の独立審査と詳細な来歴を求める。確認方法を強化しても許容できない危険が残る場合には、対象用途での生成物利用を認めないという判断も必要になる。
| 評価軸 | 低い場合 | 高い場合 | 統制への反映 |
|---|---|---|---|
| 影響範囲 | 単一の内部関数や局所的な文書へ影響する。 | 公開 API、複数パッケージ、利用者データ、下流製品へ影響する。 | 影響範囲が広いほど、変更分割、独立レビュー、下流通知計画を強化する。 |
| 検出可能性 | コンパイル、型検査、通常テストで誤りを発見しやすい。 | 特定条件でのみ発生し、通常テストでは見つからない。 | 検出しにくいほど、脅威分析、負の試験、長期検証を追加する。 |
| 可逆性 | コミットを戻せば影響を解消できる。 | 公開情報、データ破壊、互換性変更など、後から完全には戻せない。 | 戻せない処理ほど、実行前承認と権限制限を厳しくする。 |
| 下流拡散 | 開発ブランチ内にとどまり、外部配布されていない。 | リリース、ディストリビューション、製品へ複製される。 | 拡散範囲が広いほど、来歴保存、配布追跡、通知手順を整備する。 |
| 権利上の不確実性 | 自己作成の入力と決定的な変換規則から生成され、来歴を説明できる。 | 出力の由来と第三者コードとの関係を合理的に確認できない。 | 不確実性が許容水準を超える場合は、署名の有無にかかわらず受け入れない。 |
能力そのものを全面的に止めるのではなく、能力が現実へ作用する境界で確認し、記録し、必要なら停止するという考え方は、既稿「AI 時代の危険な能力は、どこで止めるべきか」で扱った境界管理と共通する[27]。オープンソースでは、その境界がファイル変更、コマンド実行、パッチ提出、レビュー依頼、マージ、リリース、下流配布に存在する。
各境界で必要な統制は異なる。ファイル変更前には権限と作業範囲を制限し、提出前には人間が内容と権利状態を確認し、マージ前には独立したレビューを行い、リリース前には影響範囲と切り戻し方法を確認する。下流配布後には、来歴と配布履歴を使って修正対象を追跡する。最後の一度だけ人間が承認する方式では、途中の不可逆な行為を管理できない。
オープンソース AI ガバナンスの目的は、AI を利用したという事実へ一律の罰則を結び付けることではない。AI によって分離した生成、認証、審査、採用、保守の各工程を再接続し、確認できない権利状態、未検証の変更、過剰なレビュー負担がプロジェクトへ流入する地点を制御することにある。六つの統制層は、その責任を一人の署名や一つのライセンス表示へ押し込めず、実際に判断と修正を行える主体へ割り当てるための設計である。
8. AI は使えるが、認証と責任は委任できない
生成 AI は、ソースコードの調査、既存実装の説明、修正案の作成、テスト観点の列挙、文書の下書きに利用できる。これらの用途まで一律に禁止すれば、開発者が候補を得る速度や、未知のコードベースを理解するための補助も失われる。一方、生成された内容をそのまま提出できるとすれば、AI が省略した調査、権利確認、設計判断、検証が、メンテナーへ移される。利用を認めるかという入口だけではなく、生成物がリポジトリへ入るまでに誰が何を確認するかを定めなければ、AI の便益と負担を分離できない。
Linux カーネルの方針は、この境界を生成、来歴、認証、レビューへ分けている。AI はコード作成を支援でき、その関与は Assisted-by などで記録できる。しかし、DCO に基づく Signed-off-by を付けられるのは人間だけである。提出者は生成された変更を読み、適用されるライセンスを確認し、パッチをレビュー可能な単位へ分割し、変更理由と影響を説明しなければならない。さらに、生成結果を却下し、不要な変更を除き、別の設計へ置き換え、レビュー指摘に自分で応答する能力が要る。採用後に回帰、脆弱性、ライセンス上の疑義が見つかれば、対象箇所の調査と修正または撤回へ関与しなければならない。生成量や変更範囲が大きければ、メンテナーは追加説明、追加試験、低いレビュー優先度、受入拒否を選べる。AI を利用する自由と、プロジェクトが未検証の出力を受け入れない自由が、同時に確保されている。
署名にはもう一つ限界がある。人間が責任を負うと宣言しても、その人間が持っていない著作権や再許諾権限は生まれない。DCO は、自己作成、適切なライセンスを持つ既存作品、認証された取得経路のいずれかを提出者に表明させる制度であり、確認不能な来歴を署名によって適法化する制度ではない。AI 出力が第三者コードを再現している可能性を合理的に排除できず、対象プロジェクトのライセンスで提供できる根拠も示せないなら、提出者に修正意思があっても受入条件は満たされない。
プロジェクト側の責任も、提出者へすべて転嫁するだけでは終わらない。メンテナーは、必要な開示、レビュー可能な変更量、高リスク領域の追加審査、自律エージェントの投稿権限、疑義が生じた場合の停止手順を定める必要がある。マージ後のコードは、提出者個人の成果物であるだけでなく、プロジェクトが受入基準を通過させ、利用者へ提供する成果物になる。提出者が認証を行い、プロジェクトがレビューと採用を行うことで、責任は両者の異なる判断へ配分される。
オープンソースにおける受入原則は、二つの文に集約できる。AI が生成したコードは、生成された時点では採否の決まっていない候補である。人間が内容を理解し、提出権限を根拠付きで認証し、プロジェクトがレビューして受け入れた時点で、そのコードは人間とプロジェクトの保守責任へ入る。同時に、責任を引き受けても、提出者が持っていない著作権や再許諾権限を補うことはできない。来歴と提出権限を合理的に認証できない出力は、動作し、便利であり、修正する意思があっても、オープンソースプロジェクトへ取り込む根拠を欠く。
調査日：2026 年 8 月 2 日
参考文献
- Debian Project, General Resolution: LLM usage in Debian（2026）. https://www.debian.org/vote/2026/vote_002
- Debian Project, Issues brought up in 2026（2026）. https://www.debian.org/vote/2026/
- id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
- Open Source Initiative, The Open Source Definition. https://opensource.org/osd
- Debian Project, Debian Social Contract, Version 1.2（2022）. https://www.debian.org/social_contract
- Debian Project, Debian Policy Manual 4.7.4.1, The Debian Archive（2026）. https://www.debian.org/doc/debian-policy/ch-archive
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability（2025）. https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
- The Linux Foundation and its contributors, Developer Certificate of Origin, Version 1.1. https://developercertificate.org/
- Linux Kernel Documentation, AI Coding Assistants. https://docs.kernel.org/process/coding-assistants.html
- Linux Kernel Documentation, Linux kernel licensing rules. https://docs.kernel.org/process/license-rules.html
- Linux Kernel Documentation, Kernel Guidelines for Tool-Generated Content. https://docs.kernel.org/process/generated-content.html
- Linux Kernel Documentation, Submitting patches: the essential guide to getting your code into the kernel. https://docs.kernel.org/process/submitting-patches.html
- id774, AI が脆弱性を見つけても、安全になるとは限らない（2026-07-14）. https://blog.id774.net/entry/2026/07/14/4959/
- The NetBSD Foundation, NetBSD Commit Guidelines. https://www.netbsd.org/developers/commit-guidelines.html
- QEMU Project, Code provenance. https://www.qemu.org/docs/master/devel/code-provenance.html/
- FreeBSD Core Team, Policy on generative AI created code and documentation, FreeBSD Status Report Second Quarter 2025（2025）. https://www.freebsd.org/status/report-2025-04-2025-06/core/
- FreeBSD Core Team, AI policy, FreeBSD Status Report Third Quarter 2025（2025）. https://www.freebsd.org/status/report-2025-07-2025-09/core/
- LLVM Project, LLVM AI Tool Use Policy. https://llvm.org/docs/AIToolPolicy.html
- Python Developer’s Guide, Guidelines for using AI tools（2026）. https://devguide.python.org/getting-started/generative-ai/
- Fedora Council, Fedora AI-Assisted Contributions Policy（2025）. https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/
- Fedora Council, Fedora Council Meeting: AI Policy Approved（2025-10-22）. https://discussion.fedoraproject.org/t/fedora-council-meeting-2025-10-22-ai-policy-approved-docs-initiative-proposed/169630
- id774, Devin と Claude Code の違いは、作業の任せ方にある（2026-07-09）. https://blog.id774.net/entry/2026/07/09/4967/
- Debian Project, Constitution for the Debian Project. https://www.debian.org/devel/constitution
- Free Software Foundation Europe, REUSE Specification, Version 3.3（2024）. https://reuse.software/spec-3.3/
- SPDX Project, SPDX Specification 3.0.1, Scope. https://spdx.github.io/spdx-spec/v3.0.1/scope/
- SPDX Project, SPDX Specification 3.0.1, Annotation. https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Annotation/
- id774, AI 時代の危険な能力は、どこで止めるべきか（2026-06-16）. https://blog.id774.net/entry/2026/06/16/4892/