生成 AI や AI コーディングエージェントを使って自由ソフトウェアを作る場面が増えている。そこで最初に浮かぶ問いは単純である。非自由な AI サービスを使ってコードを書き、その成果物を GPL などの自由なライセンスで公開したとき、そのソフトウェアは自由ソフトウェアと呼べるのか。
この問いには、最初から二つの異なる対象が含まれている。一つは、完成したプログラムを受け取った利用者が、そのプログラムを実行し、動作を調べ、変更し、変更版を他者へ渡せるかという成果物側の自由である。もう一つは、そのプログラムを作るために使った AI、開発環境、仕様書、プロンプト、テスト、生成手順を、別の開発者も利用し、調べ、変更できるかという開発工程側の自由である。前者が満たされているから後者まで自由だとは限らず、後者に非自由なものが含まれているから前者まで直ちに非自由になるとも限らない。
既稿「『AI を使ったから駄目』を分解する」では、「AI を使った」という一つの事実から、成果物の品質、制作工程、透明性、著者性などを一括して判断しないために、問題を評価対象ごとに分けた[1]。自由ソフトウェアでも同じ分解が必要になる。AI を使ったという制作履歴と、完成したコードを利用者が実行、研究、変更、再配布できるかは同じ問いではない。また、コードが自由なライセンスで公開されていることと、そのコードを実際に作り変えるための知識や道具まで利用者の側へ渡っていることも同じではない。
たとえば、AI に数十行の Python 関数を生成させた後、人間がそのコードを読み、修正し、テストし、通常のソースコードとして保守している場合を考える。この場合、AI はコードの初期案を作ったが、その後の変更には必須ではない。AI サービスが翌日停止しても、公開されたソースを別の人間が読み、エディタで変更し、テストを実行できる。AI の非自由性は制作履歴には残るが、利用者が成果物へ行使できる変更能力まで直ちに奪うわけではない。
状況は、AI が数行の補完ではなく、設計、実装、変更、保守まで担うようになると変わる。人間がソースコードそのものをほとんど編集せず、要求仕様、テスト、プロンプト、エージェント指示を変更し、それらを非公開の AI サービスへ渡してコードを作り直しているなら、開発者が実際に操作している「変更の原本」はソースコードより上流へ移っている。公開されたコードだけを受け取った利用者は、結果を読むことはできても、元の開発者が行っていた変更工程をそのまま再現できない可能性がある。
さらに、その AI が設計上の選択まで担っている場合、失われるものは生成手順だけではない。なぜこのデータ構造を選んだのか、どの代替案を退けたのか、どの制約を優先したのかという判断が、ソースコードではなく対話履歴や非公開の文脈に残ることがある。AI サービスが利用できなくなり、人間側にもその判断が記録されていなければ、ソースコードは残っているのに、変更のために必要な知識だけが失われる。
| 最初に見える問い | 実際に分けて確認する対象 | 混同すると起きること |
|---|---|---|
| AI で作ったコードは自由か | 完成したプログラムに、利用、研究、変更、再配布の自由が与えられているかを確認する。 | 非自由な AI を使ったという制作履歴だけから、成果物まで非自由だと判定してしまう。 |
| ソースを公開すれば十分か | 元の開発者が実際の変更に使っている仕様、テスト、プロンプト、エージェント指示、生成手順がどこにあるかを確認する。 | 結果として生成されたコードを公開しただけで、変更に必要な情報もすべて渡したと考えてしまう。 |
| AI 自体は自由である必要があるか | AI が交換可能な補助なのか、設計、実装、保守に不可欠な開発系の一部なのかを確認する。 | 一度使っただけの AI と、なくなれば開発できない AI を同じ依存として扱ってしまう。 |
| 同じものを再生成できる必要があるか | ソフトウェアの自由、開発工程の再現可能性、モデルの透明性、必要な計算資源を別々に確認する。 | 同じ出力を再現できないことを、そのまま変更や再配布の自由がないことと取り違える。 |
| AI 生成コードを受け入れてよいか | 人間による確認、コードの由来、配布権限、変更理由の記録、将来の保守主体を確認する。 | 生成できたことを、共同体が安全に引き継げる状態まで整ったことと同一視してしまう。 |
この分解を置くと、AI の自由とソフトウェアの自由が接続する場所も見えやすくなる。AI が交換可能な補助であり、生成後のコードを人間が普通のソースとして理解、変更、保守できるなら、AI 自体の非自由性と成果物の自由はかなり切り離せる。反対に、仕様変更のたびに同じ AI が必要で、設計判断も生成手順もそのサービスに依存し、人間が結果のコードを直接保守できないなら、AI の非自由性は制作工程の外側にとどまらない。利用者が将来そのソフトウェアを変更する能力まで左右する。
自由ソフトウェアが守ろうとしてきたのは、ソースコードという形式そのものではなく、利用者がプログラムを自分の目的に合わせて支配できる状態である。AI が開発工程へ入るほど、その状態を支える要素がソースコードの外側へ広がる。完成したコードのライセンス、変更に使う形式、開発道具への依存、モデルの自由、学習データ、再現可能性、由来、保守能力を分けて追わなければ、「コードは自由だが、そのコードを作り変える能力は特定企業の AI に依存している」という状態を捉えられない。
本稿では、この分離を起点に、自由ソフトウェアの「自由」が AI 時代に何を対象として考える必要があるのかをたどる。焦点になるのは AI の利用を禁止するか許可するかではなく、AI が開発のどの工程を担い、その結果として利用者が何を自分で支配でき、何を外部のモデルやサービスへ依存することになるのかである。
1. 非自由な AI を使っただけでは、成果物まで非自由になるわけではない
1.1 自由ソフトウェアが最初に見るのは利用者の自由である
GNU の自由ソフトウェア定義は、プログラムの利用者に四つの自由があるかを基準にする。任意の目的でプログラムを実行できること、プログラムがどのように動くかを研究して自分の目的に合わせて変更できること、コピーを他者へ再配布できること、変更した版を配布できることである。研究と変更の自由を現実に行使するにはソースコードへのアクセスが前提になる。GNU は、これらの自由によって、プログラムの開発者ではなく利用者自身が、そのプログラムと自分の計算を支配できることを中心に置いている[2]。
この定義で直接評価されるのは、プログラムを受け取った利用者が何を許されているかである。開発者がコードを書くときにどのエディタを使ったか、どのコンパイラを使ったか、AI に補完させたかという制作履歴は、それだけでは四つの自由を増減させない。反対に、人間が一文字ずつ書いたコードでも、変更や再配布を禁止する条件で公開すれば自由ソフトウェアにはならない。制作主体と利用者の自由は別の軸にある。
たとえば、非自由な AI サービスへ「CSV を読み込んで重複行を除去する関数を書いてほしい」と依頼し、その出力を人間が確認して GPL のプロジェクトへ組み込んだとする。完成した Python コードがソースとして公開され、利用者がそれを読み、処理方法を変更し、別の用途へ転用し、変更版を GPL の条件に従って配布できるなら、AI を利用したという事実だけを理由に、その利用者の四つの自由が失われるわけではない。
ここで別に残るのが、生成コードをその条件で配布する権限を本当に持っているかという問題である。AI の出力が第三者のコードを再現していた場合や、元のコードに別のライセンス条件が適用される場合には、配布者が新しいライセンス表示を付けただけで元の権利関係を消すことはできない。これは「成果物を自由な条件で利用させたい」という意思の問題ではなく、その条件を第三者へ許諾できる法的根拠があるかという問題になる。
| 状態 | 自由ソフトウェアとして直接問われること | 制作方法とは別に確認すること |
|---|---|---|
| 人間がすべて手書きした | 利用者へ実行、研究、変更、再配布の自由が与えられているかを確認する。 | 人間が書いたという事実だけでは、変更や再配布の自由を保証しない。 |
| AI が一部を生成した | 完成したプログラムを利用者が研究、変更、再配布できるかを確認する。 | 生成部分の由来と、その条件で配布できる権限を確認する。 |
| AI が大半を生成した | AI が書いた割合ではなく、利用者へ与えられた権利と変更に必要なソースの状態を確認する。 | 人間がコードを理解しているか、AI が将来の保守にも不可欠かを別の軸で確認する。 |
| ソースを公開したが改変を禁止した | 変更の自由がないため、閲覧可能なソースが存在しても自由ソフトウェアにはならない。 | ソースが見えるという透明性と、実際に変更できる自由を区別する。 |
この整理から、AI 生成コードについて最初に確認すべき順序が決まる。第一に、完成したプログラムへ四つの自由が与えられているかを見る。第二に、その自由な条件を有効に付与できる権利があるかを確認する。第三に、AI が将来の変更にも不可欠なら、成果物のライセンスとは別に開発系への依存を調べる。「AI を使った」という一つの情報だけで三つの判定を代用すると、成果物の自由、権利の由来、開発能力への依存が同じ問題として処理されてしまう。
1.2 自由ソフトウェアを作る人が非自由な道具を使った歴史もある
制作手段と成果物の自由を分ける考え方は、生成 AI の登場に合わせて新しく作る必要はない。Software Freedom Conservancy の Bradley M. Kühn は 2026 年、初期の GNU 開発では既存の非自由な Unix や C コンパイラを利用しながら GNU Emacs や GCC を作った歴史を挙げ、非自由なソフトウェアを自分が利用することと、非自由なソフトウェアを他者へ提供することの倫理的な重さを分けて論じている[3]。
初期段階で利用可能な開発環境が非自由であっても、その環境を使って自由な代替物を作り、最終的に利用者が非自由な環境から離れられるなら、非自由な道具の利用は自由を増やす移行過程として説明できる。反対に、自由な成果物を作るたびに同じ非自由な道具が不可欠で、その依存が永久に解消されないなら、成果物の自由は増えても開発工程の支配は外部に残る。この二つは、同じ「非自由な道具を使った」という記述では区別できない。
Kühn の議論は FSF の公式な自由ソフトウェア定義そのものではなく、SFC 側から示された倫理的評価である。そのため、この歴史から「非自由な AI は自由ソフトウェア開発で常に許容される」という規則を導くことはできない。比較に使えるのは、非自由な道具の利用を、それが最終的に誰の自由を増減させるかという時間軸まで含めて評価する点である。
自由なシステム全体を目指す基準では、要求はさらに厳しくなる。GNU Free System Distribution Guidelines は、自由なディストリビューションを、そのシステム自身が提供する自由な道具を使って開発・ビルドできる自己完結したものにすることを求めている。非自由なソフトウェアでしかビルドできない自由ソフトウェアを含めないという条件も置き、実用的な情報については変更に適した形式で提供されるべきだとしている[4]。
| 評価する範囲 | 中心となる問い | 非自由な AI が関与した場合 |
|---|---|---|
| 個々の成果物 | 利用者がそのプログラムを実行、研究、変更、再配布できるかを確認する。 | AI を使ったという履歴だけでは判定せず、完成したソフトウェアへ与えられた自由を見る。 |
| 開発環境 | そのソフトウェアを変更、ビルド、保守するために何が必要かを確認する。 | 特定の非自由な AI が不可欠なら、成果物とは別に開発系の依存が残る。 |
| 自由なシステム全体 | システム自身の自由な道具だけで開発と再構築を継続できるかを確認する。 | 非自由な AI なしでは主要な構成要素を保守できない場合、自己完結性との緊張が大きくなる。 |
ここから、AI と自由ソフトウェアを接続する位置が具体化する。非自由な AI を一度使って自由なコードを作ったというだけなら、成果コードの自由と制作手段の自由を分ければよい。AI が設計、変更、保守を継続的に担い、その AI がなくなると同じプロジェクトを実質的に発展させられないなら、非自由な道具は制作履歴の外側から、利用者が将来変更できる能力の内側へ入ってくる。
その境界を決めるのは、AI の利用回数や生成したコードの割合ではない。別の人間、別のモデル、通常の開発ツールへ置き換えられるか、設計判断が公開された文書やテストに残っているか、生成コードを人間が直接理解して修正できるか、サービス終了後も保守を続けられるかという条件である。AI が交換可能な道具である間は成果物の自由と切り離しやすいが、AI が変更能力そのものを保持するほど、自由ソフトウェアの評価対象はコードから開発系へ広がっていく。
2. AI が補助から開発系へ移ると、依存関係が変わる
2.1 数行の補完と、設計から保守まで任せることは同じではない
AI の利用を「使った」「使っていない」の二値で扱うと、自由ソフトウェアにとって重要な差が消える。変数名の候補を出させる場合、AI は入力作業の一部を短縮しているにすぎず、どの機能を実装するか、どの構造を採用するか、どの変更を受け入れるかという判断は人間側に残る。一方、AI エージェントがリポジトリ全体を読み、依存関係を調べ、複数ファイルを変更し、テストまで追加する場合には、AI が担っているのは文字入力ではなく、変更箇所の特定と実装方法の選択である。
この違いは、生成されたコードの行数だけでは測れない。AI が 500 行を書いても、人間が仕様、設計、変更箇所、受け入れ条件を先に決め、生成結果を一行ずつ確認しているなら、開発上の主要な判断は人間側に残り得る。反対に、AI が 30 行しか変更していなくても、「この障害を直して」とだけ指示され、原因調査、変更対象の選択、修正方法、テスト方法まで AI が決めたなら、その 30 行には開発判断の大きな部分が含まれている。
| AI の役割 | AI が担う判断 | 人間側に残る主な仕事 | AI が使えなくなった場合 |
|---|---|---|---|
| 補完 | 局所的な記述候補を提示する。 | 設計、実装方針、検証、保守を人間が担う。 | 入力速度は落ちても、通常は同じソースを直接編集して開発を続けられる。 |
| レビュー補助 | 疑わしい箇所や修正候補を提示する。 | 指摘の妥当性を判断し、採用する変更を決める。 | 確認効率は落ちるが、ソースとレビュー能力が残っていれば別の手段へ置き換えられる。 |
| 実装 | 仕様をコードへ変換し、複数の実装候補から具体的な形を選ぶ。 | 仕様、受け入れ条件、生成結果の検証を人間が担う。 | 実装速度は落ちるが、人間が生成コードを理解し保守できれば継続可能である。 |
| 設計・変更 | 変更箇所、構造、依存関係、実装方法を選択する。 | 人間は目的、制約、評価条件を主に与える。 | 設計判断が文書化されず AI との対話にしか残っていなければ、同等の変更を続けにくくなる。 |
| 継続的な保守 | 障害解析、修正、移行、追従変更を継続的に行う。 | 人間は優先順位、承認、最終責任を主に担う。 | 特定の AI が使えなくなると、速度ではなく開発能力そのものを失う可能性がある。 |
依存が深くなる最初の段階は、AI がコードを書く量が増えたときではなく、変更のために必要な判断が人間側から AI 側へ移ったときである。原因調査、影響範囲の特定、変更箇所の選択、代替案の比較まで AI が担えば、人間が受け取るのは「なぜこの変更になったのか」という判断過程ではなく、その結果としてのパッチになりやすい。結果だけを保存して判断過程を残さなければ、次の変更では同じ分析能力をもう一度 AI へ依存することになる。
さらに、その判断を特定のモデル固有の能力へ依存させると、依存はプロジェクトの外部へ固定される。たとえば巨大なコードベース全体を一度に読める文脈長、独自の検索機能、リポジトリ操作機能を前提に保守手順を組み立てた場合、別のモデルへ切り替えても同じ作業ができるとは限らない。ソースコードは手元に残っていても、「どのファイルを読めばよいか」「どの変更が安全か」を判断する能力は、特定サービスが提供する機能へ移っている。
この差を見るには、「利用している AI サービスが明日なくなったら何が失われるか」を分解するとよい。失われるのが補完速度だけなら、AI は交換可能な開発補助に近い。失われるのが特定の分析手順だけなら、その手順を文書化したり別の道具へ移したりできる。設計意図、変更方法、コード全体を理解する能力まで失われるなら、AI はすでに開発系の一部になっている。
| AI 停止時に失われるもの | 依存の意味 | 自由ソフトウェア側で確認すべきこと |
|---|---|---|
| 入力速度 | 作業効率への依存にとどまる。 | 通常の開発ツールや人間による直接編集へ戻れるかを確認する。 |
| 局所的な提案能力 | レビューや実装補助への依存である。 | 別の人間や別のツールで同じ判断を代替できるかを確認する。 |
| 設計判断 | ソフトウェアの構造を変更する知識が外部へ移っている。 | 設計理由、制約、代替案が文書やテストに残っているかを確認する。 |
| 変更方法 | コードは公開されていても、実質的な保守手段が外部へ依存している。 | 別の開発者が公開情報だけから変更作業を再開できるかを確認する。 |
| コードベースを理解する能力 | 開発能力そのものが特定 AI の機能へ移っている。 | ソース公開だけでなく、人間側に理解と引き継ぎ可能な知識が残っているかを確認する。 |
この段階まで進むと、「AI を使っている」という事実より、「AI を外しても同じ自由を行使できるか」の方が意味を持つ。自由なライセンスによって変更を許されていても、実際の変更方法を特定 AI しか担えないなら、法的な変更自由と開発能力の間に距離が生じる。AI が補助から開発系へ移るとは、単に利用頻度が増えることではなく、この距離を生み出す位置まで AI が入り込むことである。
2.2 外部 AI サービスでは、ソフトウェアのライセンスとは別に計算の支配が生じる
AI がローカルで動く交換可能なツールではなく、他者が運用する外部サービスとして提供される場合には、さらに別の支配関係が加わる。GNU は、利用者自身が行いたい計算を他者のサーバー上のプログラムへ任せ、そのプログラムを利用者が取得も変更もできない状態を Service as a Software Substitute、SaaSS と呼んでいる[5]。
GNU がここで区別しているのは、Web サービス一般と SaaSS である。たとえば第三者が保有する情報を検索するサービスと、自分が本来ローカルなプログラムで行える計算を外部サーバーへ委ねることは同じではない。また GNU は、サービスそのものを free software や proprietary software と呼ばない。サービスはプログラムのコピーではないためである。問われているのは、そのサービスを通じて行われる計算を利用者がどこまで支配できるかである[5]。
AI コーディングサービスを使うすべての場面を、そのまま SaaSS と断定することはできない。コード補完を受け取るだけなら、外部サービスが行った計算の結果を一つの候補として利用し、その後の開発は手元のソースで続けられる場合がある。設計変更、依存関係の解析、移行、障害修正まで外部 AI に継続的に任せる場合には、自分たちのソフトウェアを変更するための計算そのものを外部サービスへ預ける割合が増える。
この違いには二段階ある。第一に、計算処理が手元から外部サービスへ移る。第二に、その処理を行うモデル、検索機能、システム指示、実行環境を利用者自身が変更できないため、開発方法の変更可能性までサービス提供者へ移る。単に CPU を借りているだけなら、同じプログラムを別の計算機で実行できる可能性がある。非公開モデルの能力そのものへ依存している場合には、計算場所を変更するだけでは代替できない。
| 依存の確認 | 低依存の状態 | 高依存の状態 | 依存が深くなる理由 |
|---|---|---|---|
| 代替可能性 | 別の AI、人間、通常の開発ツールへ切り替えられる。 | 特定モデルや特定サービスでなければ実質的に変更できない。 | 開発手順が一般的な知識ではなく、サービス固有の能力を前提にする。 |
| 知識の所在 | 設計文書、テスト、ソース、レビュー記録に判断が残っている。 | 重要な判断が対話履歴やサービス内部の文脈に閉じている。 | 次の開発者が公開資料から判断過程を復元できなくなる。 |
| サービス終了 | 速度は落ちても通常の手段で保守を続けられる。 | 変更手順や設計解析そのものを実行できなくなる。 | ソースではなくサービスが実質的な開発能力を保持している。 |
| モデル更新 | 出力差を通常のツール差として吸収できる。 | 同じ指示でも変更方針や品質が変わり、過去の手順を再利用できない。 | モデルの挙動が開発工程の一部でありながら、利用者がその版を固定・変更できない。 |
| 利用条件 | サービス変更後も別の手段へ移行できる。 | 価格、利用規約、API 制限の変更が保守可能性を直接左右する。 | 技術的依存が事業者との契約上の依存にも変わる。 |
たとえば、ある自由ソフトウェアの大規模な移行作業を、特定の AI エージェントへ毎回「新しい API へ追従して」と依頼する運用にしたとする。AI が変更対象を自動で探し、互換性を判断し、テストを直すため、人間側には完成したパッチしか残らない。数年後にそのサービスが終了すると、ソースコードは GPL のまま残っていても、従来と同じ移行作業を行うには、まず人間が失われた解析方法を再構築しなければならない。
この状態で失われているのは変更する権利ではない。GPL が認めた変更の自由は残っている。失われているのは、その自由を以前と同じ開発工程で行使するための手段である。だから外部 AI サービスへの依存は、「このソフトウェアは自由ソフトウェアか」というライセンス判定と、「この共同体は自分たちのソフトウェアを自分たちで変更し続けられるか」という開発能力の判定に分ける必要がある。
依存の強さは利用回数ではなく、代替不能になった仕事の種類で測る方がよい。毎日 AI を使っていても、補完やレビューを別の道具へ容易に置き換えられるなら依存は限定される。反対に、一度だけ AI に生成させた巨大なサブシステムを誰も理解せず、以後の修正にも同じサービスが必要なら、その一回の利用は長期間の依存を残す。
ここまで進むと、外部 AI サービスの問題は「クラウドを使ったか」というインフラの話だけではなくなる。開発者が保持していた分析、設計、変更の能力がどこへ置かれているかという問題になる。AI が交換可能な計算手段であるうちは依存を切り離しやすい。AI がソフトウェアを理解し変更するための不可欠な能力になるほど、自由ソフトウェアの利用者が支配すべき対象は、完成したプログラムから開発に必要な計算能力へ広がっていく。
3. 「ソースコードを公開した」で終わらない場合が出てくる
3.1 ソースは、単なる読みやすいテキストではなく変更に使う形式である
自由ソフトウェアでソースコードが重要なのは、人間が読めるテキストだからではない。GNU の自由ソフトウェア定義は、ソースコードを「プログラムを変更するために好ましい形式」と説明している[2]。GPLv3 も同じ考え方を採用し、オブジェクトコードに対応する Corresponding Source には、その成果物を生成、インストール、実行、変更するために必要なソースと、それらの作業を制御するスクリプトを含めるとしている[6]。ソースという概念は、ファイルの見た目ではなく、実際の変更工程との関係で定義されている。
従来のソフトウェア開発では、この定義と実態がかなり一致していた。C のプログラムを変更するときには C のソースを編集し、Ruby のプログラムなら Ruby のソースを編集する。コンパイラやインタプリタは、その変更結果を実行可能な形へ変換する。人間が変更する対象と、配布時にソースとして渡す対象がほぼ同じだったため、「ソースコードを公開する」という行為によって、別の開発者にも元の開発者と同じ変更対象を渡すことができた。
AI エージェントを中心に開発すると、この対応が弱くなる場合がある。たとえば人間が、アーキテクチャ文書の「認証方式をセッション方式からトークン方式へ変更する」という記述を書き換え、テストの期待値を修正し、AI エージェントへ実装を任せる運用を考える。AI はその指示から関連ファイルを探し、データ構造を変更し、API を修正し、テストを通す。人間が日常的に変更しているのは複数のソースファイルではなく、その上流にある仕様と制約である。
この開発方法では、生成されたソースコードが不要になるわけではない。コードは実際に実行されるプログラムを理解し、局所的に修正し、監査するために依然として必要である。ただし、元の開発者自身が大規模な変更を行うときにコードを直接編集せず、仕様、テスト、エージェント指示を変更して AI に反映させているなら、「変更するために好ましい形式」がソースコードだけで完結しているとは言いにくくなる。
| 開発形態 | 人間が主に変更するもの | ソースコード公開で引き継げるもの | ソースコードだけでは失われ得るもの |
|---|---|---|---|
| 人間が直接実装 | ソースコード、設定、テストを直接編集する。 | 元の開発者が実際に変更していた主要な対象をそのまま引き継げる。 | 口頭の設計判断、却下した案、作業履歴などは別途記録しなければ失われる。 |
| AI が整形・補完 | 人間がソースコードを中心に変更し、AI は局所的な候補を補う。 | ソースコードが引き続き主要な変更形式として機能する。 | 個々の補完指示は失われても、その後の変更能力には通常大きく影響しない。 |
| AI が仕様から実装 | 要求仕様、テスト、恒久的な指示を変更し、AI がコードへ反映する。 | 現在の実装内容と実行される処理は確認できる。 | 仕様と生成規則がなければ、元の開発者が行っていた変更工程を再現しにくくなる。 |
| AI が設計変更まで担う | 人間は目的、制約、受け入れ条件を与え、AI が変更箇所と構造を選ぶ。 | 選択された結果としてのコードとテストは保存できる。 | なぜその構造を選んだのか、どの代替案を退けたのかが対話履歴にしか残らない場合がある。 |
| AI を前提に再生成 | 人間は仕様や生成条件を編集し、AI が広範囲の実装を繰り返し作り直す。 | 各時点の成果コードを保存し、個別の差分を調査できる。 | AI、入力文脈、生成手順がなければ、開発者が通常行っていた変更方法そのものを失う。 |
ここで生じる差は、コンパイラがあることとは性質が違う。通常のコンパイラは、開発者が書いたソースコードを別形式へ変換するが、どの機能を実装するか、どの構造を採用するかという設計判断まで自律的に補うわけではない。AI エージェントは、仕様から変更対象を推定し、複数の実装方法から一つを選び、必要なら周辺コードまで書き換える。そのため、AI の入力側に置かれた文書や指示が、単なるビルド設定ではなく、実装内容を決める情報として働く。
結果として、AI 時代には二つの「ソース」がずれる可能性がある。一つは、実行されるプログラムを構成するソースコードである。もう一つは、開発者が次の版を作るときに実際に変更する情報である。後者が仕様、テスト、エージェント指示へ移っているのに、前者だけを公開すると、利用者は現在のコードを変更する権利を持っていても、元の開発者が利用していた変更方法までは受け取れない。
この状態を直ちに GPL 違反や非自由ソフトウェアと断定することはできない。GPL の Corresponding Source は法的な定義であり、AI を前提とした個々の開発工程へどこまで適用されるかは別途判断が必要である。それでも、「変更するために好ましい形式」という自由ソフトウェア側の基準から見ると、AI によって実際の変更対象がソースコードの上流へ移動している事実は無視できない。ソース公開の目的が他者による変更を可能にすることなら、何を公開すれば元の開発者と同程度に変更できるのかを改めて確認する必要がある。
3.2 プロンプトだからソースなのではなく、実際に何を変更しているかを見る
この議論を「AI を使ったならプロンプトを全部公開すべきだ」と置き換えると、再び分類が粗くなる。プロンプトという同じ名前で呼ばれていても、開発工程における役割は大きく異なる。一度だけ「この条件式を読みやすくして」と依頼した文章と、プロジェクト全体の設計原則、互換性条件、禁止事項を定義し、すべての変更時に読み込ませるエージェント指示では、失われたときの影響が違う。
前者が残っていなくても、完成したコードを読めば次の開発者は通常の方法で修正を続けられる。後者が失われると、同じエージェントへ同じリポジトリを渡しても、元のプロジェクトが守っていた設計条件を再現できない場合がある。さらに、仕様書やテストが AI への主要な入力であり、人間がそれらを書き換えることで実装を変更しているなら、それらは単なる説明資料ではなく開発工程を制御する入力として働いている。
| AI へ与える情報 | 実装への作用 | 失われた場合の影響 | 保存する意味 |
|---|---|---|---|
| 一時的な質問 | 局所的なコード候補や説明を一度だけ得る。 | 完成コードを通常の方法で保守できるなら影響は小さい。 | 不具合調査や生成経路の確認が必要な場合に記録価値が生じる。 |
| 恒久的なエージェント指示 | 毎回の設計方針、実装規則、禁止事項、作業手順を制御する。 | 同じコードベースでも別の設計判断や変更方法が選ばれる可能性がある。 | 別の開発者が同じ制約下で AI を使い、変更を続けるための情報になる。 |
| 要求仕様 | 何を実装すべきかという生成の上流条件を与える。 | コードから現在の処理は読めても、どの要求を満たすための実装か分からなくなる場合がある。 | 生成結果の目的と、次の変更で維持すべき条件を引き継げる。 |
| テスト | AI が満たすべき観察可能な動作を機械的に固定する。 | 変更可能な範囲と、変更後も維持すべき挙動が不明確になる。 | 人間と AI の双方に対して受け入れ条件を継続的に与えられる。 |
| 対話履歴 | 設計判断、調査結果、代替案の比較を蓄積する。 | 完成コードだけからは、なぜその変更を選んだのかを復元できない場合がある。 | 後から判断経路を確認し、同じ前提で次の変更を行いやすくする。 |
| 検索・参照文脈 | AI がどの仕様、API 文書、既存コードを根拠に判断するかを決める。 | 同じ指示でも別の資料を参照すれば異なる実装になる可能性がある。 | 変更がどの情報源に基づいて行われたかを追跡できる。 |
| 生成・実行手順 | どの情報をどの順序で AI へ与え、どの検証を通して成果物を確定するかを決める。 | 個々の入力が残っていても、元の変更工程を組み立て直せなくなる。 | 別の開発者が一連の変更工程を再構成するための手掛かりになる。 |
Software Freedom Conservancy は 2026 年の FOSS 貢献向け勧告で、LLM とのやり取りによって生じたプロンプト、メモなどの詳細な記録を保存し、それらをライセンス上の厳密な結論とは切り離したうえで、Corresponding Source の一部であるかのようにアーカイブすることを推奨している[7]。この勧告が求めているのは、「プロンプト」という名称の文書を機械的に全部ソースと認定することではない。後からコードだけを見ても失われる開発情報を、将来の理解、検証、保守のために残しておくことである。
この勧告には、AI を使った開発特有の事情がある。人間が直接コードを書いた場合、少なくとも実装時に考えた内容の一部はソースの構造やコメント、コミット差分として残りやすい。AI へ大きな判断を委ねた場合には、判断に与えた入力や、外部に現れた対話・作業履歴がコードの外側へ分離する。完成したパッチだけをコミットすると、AI へ与えた制約、参照した資料、却下した案、人間がどこを確認したかが失われ、次の保守者は結果だけから判断過程を逆算しなければならない。
たとえば、ある AI エージェントへ「既存 API との後方互換性を維持し、公開関数を増やさず、データベースのスキーマ変更を避ける」という恒久的な指示を与えているとする。AI はその条件を前提に毎回の実装を選ぶ。生成されたコードだけを公開して指示を残さなければ、別の保守者は各実装を個別に読むことはできても、複数の変更に共通する制約がどこから来たのかを知ることができない。次の変更でその制約を破っても、コード単体からは違反だと判定できない場合がある。
逆に、「この関数名の候補を三つ出して」という一時的な質問まで保存しなければ将来の変更が困難になるとは考えにくい。両者の差は AI を使った回数ではなく、失われた情報が次の変更能力へどの程度影響するかにある。AI への入力をソースに近いものとして扱う必要性は、その入力が実際の変更をどれだけ制御しているかに比例する。
| 判断基準 | ソースに近づく条件 | 単なる作業記録に近い条件 |
|---|---|---|
| 継続利用 | 同じ情報を毎回の変更で読み込み、実装方針を継続的に制御する。 | 一度限りの質問で、その後の開発には使わない。 |
| 変更対象 | 人間がその情報を書き換えることによってソフトウェアの機能や構造を変更する。 | 結果の説明や候補取得に使うだけで、実装条件を決めない。 |
| 不可欠性 | 失うと元の開発工程や設計制約を復元できない。 | 失っても公開されたコードから通常の方法で保守を続けられる。 |
| 意味の保持 | コードだけには表れない要求、設計理由、禁止条件を保持している。 | コードや既存文書に同じ情報が十分残っている。 |
| 再利用性 | 別の開発者が同じ情報を使って次の変更を行える。 | 特定の一回の対話を説明する履歴にとどまる。 |
この基準を使うと、「プロンプトを公開するべきか」という問いを、より具体的な「何を渡せば別の開発者が変更を続けられるか」へ置き換えられる。プロンプトという形式そのものには特別な地位はない。仕様書でも、テストでも、エージェント指示でも、生成スクリプトでも、それが元の開発者にとって実際の変更手段になっているなら、自由ソフトウェアが従来ソースコードに求めてきた役割の一部を担い始めている。
AI エージェントが開発の中心へ入るほど、「公開されているソースファイルの集合」と「そのソフトウェアを作り変えるために必要な情報の集合」は一致しにくくなる。ここで自由ソフトウェア側から問うべきなのは、新しい種類のファイルを機械的に Corresponding Source へ追加することではない。元の開発者が変更のために実際に操作しているものを特定し、それを失った利用者がどの変更能力を失うのかを確認することである。
ソースコードの公開だけでは終わらないという主張は、ソースコードの価値が下がったという意味でもない。むしろ GNU と GPL がソースを「変更に使う形式」として重視してきた原則をそのまま追うと、AI 時代にはその原則をコードの上流まで適用して考える必要が出てくる。AI が結果を生成するほど、自由を判断する対象は生成結果だけでなく、その結果を再び作り変えるために人間が操作している情報へ広がる。
4. コードが自由でも、開発能力は外部へ移り得る
4.1 法的に変更できることと、現実に変更を続けられることは別である
自由なライセンスは、利用者がソフトウェアを変更することを法的に妨げられないための基盤になる。しかし、変更を許されていることと、実際に変更できることは同じではない。ソースコードが公開されていても、元の開発者だけが持つ設計情報、特殊な開発環境、非公開の生成手順がなければ保守を続けられないことはある。AI エージェントは、この差をさらに大きくし得る。コードを書く作業だけでなく、どのファイルを読み、どこを変更し、どの影響を確認するかという開発判断まで外部サービスへ移せるからである。
たとえば GPL で公開されたソフトウェアがあり、ソースコードもテストもすべて取得できるとする。ライセンス上は、誰でもそのコードを変更し、変更版を配布できる。ところが元の開発チームが、大規模な変更では常に特定の AI エージェントへリポジトリ全体を読ませ、非公開の指示と長大な対話履歴を使って設計変更を行っていた場合、第三者が受け取るものは完成したコードとテストだけになる。変更する権利は同じでも、元の開発者が利用していた変更方法までは引き継げない。
ここでは最初に、変更に必要な情報がソースコードの外へ移る。設計上の前提、互換性条件、過去に却下した案、特定の変更時に参照すべき資料が AI との対話や外部サービスの文脈にだけ残れば、公開されたコードからそれらを復元する必要が生じる。次に、その復元自体を同じ AI へ依存するようになると、開発者はコードだけでなく、コードを理解するための能力まで外部サービスへ預けることになる。
| 自由・能力 | 満たされている状態 | AI 導入後に起き得る不足 | 不足が生じる理由 |
|---|---|---|---|
| 法的な変更自由 | ライセンスが変更と変更版の配布を認める。 | AI を使ってもライセンス条件自体は自動的には変わらない。 | 制作方法と、利用者へ与えられた法的権利は別の属性だからである。 |
| ソースへのアクセス | 元の開発者が変更に使う主要な形式を取得できる。 | 仕様、指示、対話履歴など実際の上流入力が非公開になる。 | 人間がコードそのものではなく、AI への入力を変更して実装を動かすようになるためである。 |
| 理解可能性 | 開発者が構造、依存関係、変更の影響を追える。 | 大量生成されたコードを人間が十分に把握しないまま採用する。 | 生成速度が人間の読解、レビュー、設計理解の速度を上回るためである。 |
| 保守可能性 | 元の開発者や特定サービスが消えても修正を続けられる。 | モデル固有の解析能力や外部サービスへ変更方法が依存する。 | 保守作業そのものが AI によるコード理解と修正提案を前提に組み立てられるためである。 |
| 代替可能性 | 別の人間、別のモデル、通常の開発ツールへ切り替えられる。 | 特定ベンダーの文脈長、検索、エージェント機能、非公開モデルを前提にする。 | 一般的な開発手順ではなく、サービス固有の能力が工程の一部になるためである。 |
この差を「ソースコードは公開されているのだから自由である」で終わらせると、自由ソフトウェアの制度上の自由と、共同体が現実に行使できる能力が混ざる。法的な変更自由は、その権利を行使するための技能、知識、計算環境まで同時に保証するものではない。一方で、技能や知識が不足しているからといって、そのソフトウェアが直ちに非自由になるわけでもない。両者を分けたうえで、AI がどちらへ影響しているのかを見る必要がある。
GNU Free System Distribution Guidelines の self-hosting は、この差を考える比較材料になる。FSDG は、自由なシステムを、そのシステム自身が提供する自由な道具で開発・ビルドできる自己完結したものにすることを求め、非自由なソフトウェアでしかビルドできない自由ソフトウェアを含めないとしている[4]。ここで守ろうとしているのは、完成したプログラムのライセンスだけではなく、そのプログラムを維持する工程まで非自由な道具へ固定されない状態である。
AI エージェントをコンパイラと同一視することはできない。コンパイラは通常、開発者が用意したソースを別形式へ変換する。一方、AI エージェントは変更箇所の探索、設計の選択、コード生成、テスト修正まで行い得る。それでも FSDG との比較が有効なのは、「自由な成果物を維持するために非自由な開発手段が不可欠になったとき、その自由をどこまで自律的に行使できるのか」という構造が共通しているためである。
たとえば、自由なコンパイラへ置き換えれば同じソースからビルドできる状態と、特定 AI がなければ「どこをどう直せばよいか」から分からない状態では依存の深さが違う。後者では、ビルドの手段だけでなく、変更すべき内容を決める認知作業まで外部化されている。AI が開発系へ入るほど、自己完結性の確認対象はコンパイラやビルドツールから、設計理解、変更判断、保守手順へ広がる。
| 状態 | 残っている自由 | 外部へ移っている能力 | AI がなくなった後 |
|---|---|---|---|
| 自由なコードを人間が直接保守 | 法的な変更自由と実際の変更能力の双方が共同体側に残る。 | 特定の外部能力へ大きく依存しない。 | 通常の開発環境があれば保守を継続できる。 |
| AI を補完に利用 | コードと主要な設計判断は共同体側に残る。 | 入力効率や局所的な提案能力が外部化される。 | 速度は落ちても人間が直接変更できる。 |
| AI に実装を依存 | コードを変更する権利は残る。 | 大量実装の生産能力が外部へ移る。 | 人間がコードを理解していれば、速度を落として保守できる。 |
| AI に設計理解まで依存 | ライセンス上の変更自由とソースへのアクセスは残り得る。 | 変更箇所の特定、設計判断、影響分析が外部へ移る。 | ソースは残っても、保守方法を再構築する必要が生じる。 |
| 特定 AI なしでは保守不能 | 形式上の変更自由は残り得る。 | 開発能力の中核がサービス提供者へ固定される。 | ライセンスは自由なままでも、共同体の実質的な変更能力は大きく失われる。 |
この整理から、コードの自由と開発能力の自由は同じ速度では失われないことが分かる。AI への依存が増えても、GPL の許諾はそのまま残り得る。一方、設計判断と保守能力が外部へ移れば、共同体がその許諾を実際に使うための条件は弱くなる。AI 時代に新しく見えるのは、自由ソフトウェアが法的にはそのまま自由でありながら、元の開発者と同じ方法で発展させる能力だけが非自由な開発系へ移っていく状態である。
4.2 人間が理解していないコードを公開しても、変更自由は弱くなる
AI が大量のコードを短時間で生成できるようになると、もう一つの差が大きくなる。生成量と人間が確認できる量の差である。AI が 1 時間で数千行を変更しても、保守者が同じ 1 時間で、その変更の前提、依存関係、副作用、例外条件まで理解できるとは限らない。生成速度がレビュー速度を上回れば、ソースコードは増える一方で、そのコードを説明できる人間の理解は追いつかなくなる。
この状態では、最初の生成時点で確認不足が生じる。変更されたコードがテストを通ったという理由だけで取り込まれ、なぜその構造なのか、どの入力で失敗するのか、どの依存関係に影響するのかを人間が十分に確認しないまま残る。次に、そのコードへ追加変更が必要になると、人間は理解していない既存実装をもう一度 AI に解析させる。最初の理解不足が、次の AI 依存を生む。
たとえば AI エージェントが、認証処理を 20 ファイルにまたがって書き換え、既存テストをすべて通したとする。保守者が diff を眺めて成功と判断し、セッション管理、例外処理、権限境界まで説明できないままマージした場合、その時点ではコードもテストも公開されている。しかし半年後に権限昇格の不具合が見つかったとき、どの層で認可判断を行う設計なのかを説明できる人がいなければ、修正の第一歩から AI に再解析を依頼することになる。
| 段階 | AI によって起きること | 人間側で不足し得るもの | 次の保守へ与える影響 |
|---|---|---|---|
| 生成 | 広範囲の変更を短時間で作れる。 | 変更理由や影響範囲を読む時間が不足する。 | 理解されていないコードがリポジトリへ蓄積する。 |
| レビュー | AI 自身が要約や説明も生成できる。 | 説明が正しいかを独立に確認する作業が省略されやすい。 | 生成物と説明の双方を同じ AI に依存する状態になる。 |
| マージ | テスト通過を根拠に大きな変更を受け入れやすくなる。 | 設計意図、失敗条件、例外処理の理解が残らない。 | 後からコードだけを読んで意図を復元する必要が生じる。 |
| 障害対応 | 大量の既存コードを AI に再解析させられる。 | 人間が自力で原因箇所を絞る能力が育ちにくい。 | 過去の AI 依存が次の AI 依存を強める。 |
| 引き継ぎ | AI にリポジトリを説明させれば短時間で概要を得られる。 | 共同体に蓄積された設計知識と AI が生成した説明の境界が曖昧になる。 | 特定 AI が使えなくなると、引き継ぎ能力まで失う可能性がある。 |
Software Freedom Conservancy の 2026 年勧告は、AI 支援・生成による FOSS 貢献について、提出前に人間が相当の時間をかけて確認し、貢献内容を深く理解することを求めている。また、AI 利用によって自身の技能を衰えさせないようにし、既に持っている能力を補完する形で使うよう勧めている[7]。この条件は、AI が書いたコードを形式的に排除するためのものではない。提出者が変更内容を理解し、その説明と保守責任を人間側へ残すための条件になっている。
人間による理解を要求する理由は、コード品質の判定だけではない。FOSS の変更は、提出した瞬間に完結しない。将来、別の保守者がそのコードを読み、別の機能と組み合わせ、不具合を修正し、異なる環境へ移植する。提出者が「AI がそう書いたので分からない」としか説明できない場合、生成時に節約された理解のコストは消えたのではなく、後の保守者へ移されている。
この移転が繰り返されると、共同体の構造も変わる。従来は、コードを書いた人、レビューした人、保守した人の間に設計知識が蓄積していた。AI が実装と説明を一括して担い、人間が結果の承認だけを行うようになると、知識は共同体のメンバーではなく、毎回リポジトリを解析する AI の能力へ依存する。コードは公開され続けても、そのコードを扱うための知識が共同体へ蓄積しにくくなる。
ただし、「人間がすべて理解していなければ自由ソフトウェアではない」という定義に変えることはできない。大規模なカーネル、コンパイラ、ブラウザでは、単一の人間が全体を理解しているわけではない。それでも複数の保守者が領域ごとの知識を持ち、文書、テスト、レビュー履歴、公開された開発手順を通じて変更能力を分散している。自由を支えているのは、一人の完全な理解ではなく、共同体の内部に変更可能な知識が残っていることである。
| 状態 | ソースの公開 | 人間側の理解 | 保守能力の所在 |
|---|---|---|---|
| 大規模だが人間が分担して保守 | 公開されている。 | 一人ではなく複数の保守者へ分散している。 | 共同体の文書、レビュー、技能、履歴に残る。 |
| AI が生成し人間が十分にレビュー | 公開されている。 | 生成結果の設計と影響を説明できる程度に残る。 | AI を外しても共同体が変更を続けられる可能性が高い。 |
| AI が生成し人間は動作だけ確認 | 公開されている。 | 実装理由や失敗条件の理解が弱い。 | 次の解析で再び AI に依存しやすい。 |
| AI が生成・説明・保守を一貫して担当 | 公開されていてもよい。 | 共同体側に設計知識がほとんど蓄積しない。 | 変更能力が AI サービスの継続利用へ集中する。 |
ここで自由ソフトウェアにとって問われるのは、難しいコードを禁止することでも、AI が書いたコードを人間が一字一句暗記することでもない。次の変更を行うための知識が、ソース、テスト、文書、レビュー、人間の技能として共同体の側に残っているかである。AI がなくなったときに速度だけが低下するなら、AI は補助に近い。AI がなくなるとコードを説明できる主体まで消えるなら、開発能力はすでに外部へ移っている。
自由なライセンスは、利用者へ変更の権利を渡す。ソース公開は、その権利を行使する材料を渡す。AI エージェントが開発の中心へ入ると、その二つだけでは元の開発方法を十分に引き継げない場合が生まれる。設計判断、変更手順、理解能力まで外部 AI に集中させないことは、新しい法的な自由を追加する話ではない。既に与えられている変更自由を、将来の利用者と共同体が現実に行使し続けられる状態として維持するための条件である。
5. AI モデル自身の自由を考えると、ソフトウェアより構成要素が増える
5.1 FSF はソフトウェアだけでは機械学習アプリケーションの自由を説明できないと考えている
AI が単なる補完ツールではなく、設計、実装、保守に不可欠な開発系の一部になると、前章までの「その AI がなくても開発を続けられるか」という問いは、さらに一段上流へ進む。その AI 自体を利用者がどこまで研究し、変更し、置き換えられるのかを確認しなければ、開発能力を誰が支配しているかを評価できないからである。
通常のソフトウェアであれば、実行プログラムと、その変更に使うソースコードという対応を比較的はっきり置ける。機械学習では、この対応だけでは構造を説明できない。推論を行うプログラムが自由であっても、その動作を大きく決めるモデルパラメータが入手できなければ、利用者は同じ AI を実行できない。モデルパラメータを取得できても、学習コードや学習条件が分からなければ、そのモデルがどのように作られたかを調べたり、同じ方法で変更したりする能力は限定される。
FSF は 2024 年、自由な機械学習アプリケーションについて新しい基準を策定中であることを公表した。その説明では、機械学習アプリケーションをソフトウェア部分だけで捉えず、学習によって得られたモデルパラメータまで含めて考える必要があるとしている[8]。推論コードが自由なライセンスで公開されていても、実際の出力を決めるモデルが利用者の支配下になければ、通常のソフトウェアと同じ意味で四つの自由を行使できるとは限らないという問題設定である。
ただし、ここでモデルパラメータを通常の実行ファイル、学習データを通常のソースコードと機械的に対応させると、機械学習の実態から外れる。FSF 自身、学習データは通常の意味でモデルパラメータの「ソースコード」ではないと整理している[8]。通常のソフトウェアでは、人間がソースコードを直接編集し、コンパイラなどの比較的明示的な変換によって実行形式を作る。機械学習では、データ、学習アルゴリズム、初期値、ハイパーパラメータなどを使った学習過程から、大量の数値パラメータが得られる。学習データの一行を書き換えれば、重みの特定箇所が対応して変わるという関係ではない。
モデルパラメータそのものも、人間が通常のソースコードと同じ方法で読んで変更する対象ではない。数十億、数百億という数値を直接編集して望む機能を実装するのではなく、追加データによる学習、微調整、別の学習条件による再学習などを通じて挙動を変える。そのため、利用者が AI を研究し変更する能力を考えると、重みを取得できることだけでなく、どのデータとどの学習処理を使って変更できるかが関係してくる。
| 構成要素 | 利用者が取得できると可能になること | 欠けた場合に制限されること | 通常のソースコードと異なる点 |
|---|---|---|---|
| 推論・学習コード | 処理手順を研究し、実装を変更し、別環境へ移植できる。 | モデルを動かす処理や学習アルゴリズムを利用者自身で変更できなくなる。 | 通常のソフトウェアと最も近い形で四つの自由を適用できる。 |
| モデル構造 | 層構成、入出力、内部表現の設計を理解し、別構造へ変更できる。 | 重みがあっても、どのような構造で利用すべきか分からなくなる場合がある。 | プログラム構造に似るが、実際の挙動は学習後のパラメータにも大きく依存する。 |
| モデルパラメータ・重み | 学習済みモデルを実行し、条件が許せば追加学習や変換を行える。 | 学習済みの能力そのものを利用したり検証したりできない。 | 人間が直接編集する「変更に適した形式」とは限らない。 |
| 学習データ | データ構成を調べ、偏りを分析し、追加学習や再学習へ利用できる。 | どの情報からモデルの性質が形成されたかを調べる能力が弱くなる。 | データと特定の重みの間に、通常のソースと実行形式のような直接対応はない。 |
| 学習設定 | ハイパーパラメータ、前処理、学習手順を変更して別のモデルを作れる。 | 同じコードとデータがあっても、どの条件で学習したかを再構成しにくくなる。 | ビルド設定に似た面があるが、最終的なモデル挙動へ直接影響する。 |
FSF が学習データへ注目する理由も、この変更方法の違いから説明できる。重みを入手して推論できるだけなら、完成したモデルを利用する自由は広がる。しかし、そのモデルが特定の入力をなぜ誤るのかを調べたり、別のデータを加えて挙動を変えたり、異なる目的へ適応させたりするには、学習過程へ近い情報が必要になる。利用者の自由を「既存モデルを動かせること」から「モデルを研究し作り変えられること」まで広げるほど、学習データと関連スクリプトの重要性が増す。
この考え方から FSF は、学習データと関連スクリプトにも四つの自由を要求する方向を示した[8]。2025 年の FOSDEM 後の報告でも、FSF は基準をまだ策定中としながら、自由な機械学習アプリケーションには学習データを含めるべきだという立場を明示している[9]。2025 年時点で完成済みの一般定義として確定しているわけではないが、FSF が自由の対象を推論コードと重みだけに限定していないことは確認できる。
この違いは、本稿の自由ソフトウェア開発の議論へ直接戻ってくる。AI エージェントが交換可能な補助なら、その AI の内部を利用者がすべて変更できなくても、成果コードの変更能力を共同体側へ残せる場合がある。AI 自体がソフトウェアを理解し変更するための不可欠な開発系になるほど、その AI を研究し、修正し、置き換える能力まで失うことが、自由ソフトウェア側の開発能力へ影響する。AI モデルの自由は、AI という別分野の問題として独立しているだけでなく、自由なソフトウェアを将来誰が保守できるかという問題と接続する。
5.2 OSI は「変更に適した形式」を AI システム全体へ拡張した
Open Source Initiative は、この問題へ FSF とは別の形で具体的な定義を与えた。OSI は 2024 年 10 月、Open Source AI Definition 1.0 を公開し、AI システムについて、利用、研究、変更、共有の自由を置いた[10]。通常の Open Source Definition を単純にモデルファイルへ適用するのではなく、AI システムを変更するために必要な情報を複数の構成要素へ分けている。
OSI がこの定義で中心に置くのも、「変更に適した形式」である。AI システムを単に実行できるだけではなく、第三者がその仕組みを研究し、実質的な変更を加え、変更版を共有できるために必要な情報へアクセスできることを要求する[10]。この点では、前章で扱った GNU や GPL のソースに関する考え方と連続している。ただし AI では、変更に必要な情報を一つのソースコードへ集約できないため、要求対象が学習コード、モデルパラメータ、データに関する情報などへ分かれる。
その中でも特徴的なのが Data Information である。OSI は、学習データについて、来歴、範囲、特性、取得・選択方法、ラベル付け、処理、フィルタリングなどを詳細に説明する情報を要求する[10]。公開されているデータや第三者から取得可能なデータについては、利用者が入手できる場所も示す。これによって、利用者は「どのようなデータ集合をどのように作ったモデルなのか」を調べ、別のデータを選んで変更版を作るための材料を得られる。
一方、OSI は学習に使われたすべての生データそのものを常に再配布することまでは要求していない。契約、個人情報、第三者の権利などによって共有できないデータがあり得るためである。共有できない部分については、詳細な Data Information を提供することで、利用者がデータの性質と処理方法を理解できるようにする設計を採っている[10]。
| OSI が求める情報 | 利用者が確認できること | 変更へどうつながるか | 残る制約 |
|---|---|---|---|
| 学習コード | どの処理によってモデルを学習したかを確認できる。 | 学習方法を変更し、別のモデルを作れる。 | 元のデータや計算資源まで自動的に得られるわけではない。 |
| モデルパラメータ | 完成したモデルを実行し、内部評価や追加学習を行える。 | 元のモデルを基点に変更版を作れる。 | 学習履歴そのものを重みだけから完全には復元できない。 |
| 共有可能な学習データ | 実際に使われたデータを調査できる。 | 同じデータや変更したデータを使った学習を試せる。 | 第三者の権利などにより全データが共有可能とは限らない。 |
| Data Information | データの由来、範囲、選択、処理、フィルタリング方法を確認できる。 | 同じ目的の別データセットを構築し、意味のある変更を試しやすくなる。 | 元の非公開データを完全に再現できるとは限らない。 |
OSI の FAQ は、この区別を明示的に説明している。学習データを通常のソフトウェアにおけるソースコードと同一視するのではなく、第三者が意味のある fork を作るために必要な情報を、学習コード、モデルパラメータ、共有可能なデータ、Data Information の組み合わせとして考えている[11]。
この設計は、「完全に同じモデルをもう一度作れること」と「利用者が意味のある変更版を作れること」を分けている。元の非公開データをすべて取得できなければ、元モデルを完全に再学習することはできない場合がある。それでも、データの構成と処理方法が十分に分かり、学習コードと重みを取得できれば、別データで挙動を変えたり、特定用途へ適応したりすることはできる。OSI は後者を Open Source AI の自由を成立させる実用的な基準として採用している。
自由ソフトウェア開発へ戻せば、この差は AI エージェントの交換可能性に関係する。利用しているモデルの重み、コード、学習に関する情報へアクセスできるほど、特定サービスが終了したときに自分たちで運用したり、別用途へ変更したりする余地が増える。反対に、API から完成した出力だけを受け取り、モデルの構造も重みも変更できない場合には、AI が開発系の中心になるほど、開発能力をサービス提供者から切り離しにくくなる。
5.3 学習データをどこまで要求するかについて、FOSS 側でも結論は一つではない
FSF と OSI はどちらも、機械学習ではコードだけを公開して自由を説明するのは不十分だと考えている。しかし、学習データそのものをどこまで利用者へ渡す必要があるかでは立場が一致していない。この差は細かな定義上の争いではなく、「自由な AI の利用者に、どこまで同じ生産過程を取り戻せる能力を保証するか」という基準の違いから生じている。
Software Freedom Conservancy は 2024 年の「Machine-Learning-Assisted Programming that Respects User Freedom」で、AI 支援プログラミングについてさらに高い理想を掲げた。ソフトウェア、データ処理コード、モデル構造、ハイパーパラメータ、重みなどを FOSS とし、学習データについても完全に特定され、自由に利用できる状態を目標としている[12]。同文書は最低要件を定義したものではなく、明示的に aspirational、すなわち目指すべき理想として提示されたものである。
SFC が学習データを重視する理由は、モデルを使えることと、モデルを作り直せることを分けて考えているからである。重みだけを取得できれば既存モデルを動かせる場合がある。しかし、同じ学習過程を調査し、別条件で再学習し、特定のデータを除外したモデルを作りたい場合には、元の学習データへアクセスできることが大きな意味を持つ。データが非公開なら、利用者は完成したモデルの改変はできても、モデルが作られた過程の一部を自分で再構成できない。
この観点から SFC の Bradley M. Kühn は、OSI の OSAID 1.0 公開後、学習データのライセンスと公開について十分な要求を置いておらず、公衆によるモデルの再現可能性を保証しないとして強く批判した[13]。これは OSI の定義についての外部批判であり、OSI 自身の説明ではない。両者の差は、共有できないデータについて詳細な説明で代替することを認めるか、それとも自由な AI の理想として学習データ自体へのアクセスまで要求するかにある。
| 立場 | 学習データへの要求 | 利用者へ確保しようとする能力 | 基準上の特徴 |
|---|---|---|---|
| FSF の検討中基準 | 学習データと関連スクリプトにも四つの自由を要求する方向を示している。 | モデルを利用するだけでなく、学習データを研究し、変更し、再学習へ利用できる能力を重視する。 | 2025 年時点では完成した正式基準ではなく、策定中の方向性として示されている。 |
| OSI OSAID 1.0 | 共有可能なデータと詳細な Data Information を要求し、共有不能データは説明によって扱う。 | 第三者が AI システムを研究し、意味のある変更や fork を作れる能力を重視する。 | 元の学習データを完全に複製できることを必須条件とはしていない。 |
| SFC の理想目標 | 学習データを完全に特定し、自由に利用可能にする状態を目標とする。 | モデルの利用、変更だけでなく、学習工程そのものを公衆が再構成できる能力を重視する。 | 定義上の最低ラインではなく、FOSS in、FOSS out、FOSS throughout という理想として提示されている。 |
三者の差を、「どこが最もオープンか」という一つの尺度に押し込めると、それぞれが何を守ろうとしているのかが見えにくくなる。OSI は、共有不能なデータが存在しても、第三者が意味のある変更を行える条件を具体化している。FSF は、利用者がモデルを研究し作り変える自由をより上流の学習データまで広げようとしている。SFC はさらに、AI 支援プログラミングの生産過程全体を FOSS で構成できる状態を理想としている。
ここでは「再現」という言葉にも二種類ある。第一は、同じ学習データ、コード、設定から、元と同等のモデルをもう一度構築できるという再現である。第二は、元の AI を十分に研究し、自分の目的に合わせた変更版を作れるという変更能力である。学習データを完全に共有しない OSI の基準に対する SFC の批判は、第一の能力をより強く要求する立場から出ている。一方、OSI は第二の能力を成立させるために必要な情報を現実的に定義しようとしている。
FSF は 2026 年 3 月の Anthropic 訴訟和解に関する記事でも、LLM 開発者に対して、完全な学習入力、モデル、学習設定、関連ソフトウェアのソースを利用者へ共有するよう求めた[14]。これは裁判所が示した一般的な法的要件ではなく、FSF がソフトウェア自由の観点から示した政策的要求である。FSF がモデルの重みを利用できる状態だけでは、利用者が AI を十分に研究し変更できるとは考えていないことが表れている。
| 利用者が持つもの | 可能になること | 依然として難しいこと |
|---|---|---|
| API アクセスだけ | 事業者が許可した範囲でモデルを利用できる。 | モデルの内部を研究し、重みを変更し、自分で運用することはできない。 |
| 重みと推論コード | 自分の環境でモデルを実行し、許諾範囲で変換や追加学習を行える。 | 元の学習過程やデータ構成を完全には調査できない場合がある。 |
| 重み・コード・Data Information | モデルの由来を調べ、別データを構築して意味のある変更を試しやすくなる。 | 非公開だった元データと同じ学習過程を完全には再現できない場合がある。 |
| 重み・コード・完全な学習データ・学習設定 | 元の学習過程を詳細に調査し、データを変更した再学習を試せる。 | 同じ計算資源や実行条件まで用意できるとは限らない。 |
この段階まで来ると、「AI モデルが自由か」という問いも一枚岩ではない。既存モデルを自分の環境で実行できること、重みを変更できること、学習過程を調査できること、別データで再学習できること、元モデルと同じ生産過程を再構築できることは、それぞれ必要な情報が違う。これらの公開基準・提案を見る限り、どこまでを自由の必須条件にするかについて FOSS 関係組織の基準は一致していない。
自由ソフトウェア開発との接続では、この不一致そのものより、AI への依存度に応じて必要な自由が変わる点が重要になる。AI を一度だけコード補完に使うなら、モデルの学習データを取得できないことが、その後のソフトウェア保守を直ちに妨げるわけではない。AI が設計、実装、保守を継続的に担い、同じ能力を自分たちで運用・変更できなければ開発を続けられないなら、モデルの重み、コード、学習情報へアクセスできないことは、自由ソフトウェア側の開発能力へ直接影響する。
つまり、AI モデル自身の自由を考える理由は、「自由ソフトウェアを作るなら自由な AI だけを使わなければならない」という形式的な純化にあるのではない。ソフトウェアを作り変える能力を AI へ移すほど、その AI を誰が実行し、研究し、変更し、置き換えられるかが、完成したソフトウェアを将来誰が支配できるかへつながる。モデル、重み、学習コード、学習データを分けて考える必要があるのは、AI の構成要素が多いからだけではなく、それぞれが利用者の異なる変更能力を支えているからである。
6. 学習データ、重み、計算資源を一つの「ソース」に押し込めると混乱する
6.1 学習データは重要だが、通常のソースコードと同じものではない
機械学習モデルを自由ソフトウェアの語彙で説明しようとすると、学習コード、モデルパラメータ、学習データ、学習設定、計算資源をすべて「ソース」に対応づけたくなる。しかし、この整理は便利な一方で、それぞれが利用者へ与える能力の違いを隠してしまう。通常のソフトウェアでは、ソースコードを変更すれば、どの処理を変えたのかを人間が比較的直接追える。機械学習では、学習データの一部を書き換えても、モデル内部のどの重みがどう変わり、最終的な出力がどう変化するかを同じ粒度では対応づけられない。
FSF と OSI は学習データへの要求水準では異なるが、「学習データは通常のソフトウェアのソースコードそのものではない」という点では近い整理をしている。FSF は、モデルパラメータが人間の著作したソースを単純な変換によって得たものではなく、学習データを通常のソースコードと同じ意味で扱えないと説明している[8]。OSI も、学習データをソースコードとそのまま同一視する理解を退けている[11]。
違いは変換関係にある。通常のコンパイルでは、ソースコードと生成された機械語の間に、コンパイラという明示的な変換処理がある。元のソースコードを保持していれば、人間はその内容を編集し、同じ処理系を通して変更された実行形式を作れる。機械学習では、学習コード、学習データ、初期値、ハイパーパラメータ、最適化手法、乱数などが相互に作用し、その結果としてモデルパラメータが得られる。一つの入力ファイルを「これがモデルのソースである」と切り出しても、変更能力の全体を説明できない。
そのため、学習データが重要であることと、学習データをソースコードと呼ぶことは分けた方がよい。学習データがなければ、どの言語、地域、文体、カテゴリの情報が多く含まれていたのかを詳細に調べにくくなる。特定のデータを除外して再学習したり、別のデータを加えて挙動を変えたりする能力も制限される。これはモデルを研究し変更する自由に直接関係するが、その役割は通常のプログラムにおけるソースコードと同一ではない。
| 対象 | 主に決めているもの | 公開・自由化によって得られる能力 | それだけでは得られない能力 |
|---|---|---|---|
| 学習コード | どの手順でデータを処理し、どの方法でモデルを更新するかを決める。 | 学習処理を研究し、アルゴリズムや実装を変更できる。 | 同じデータ、初期条件、計算資源がなければ元モデルと同じ学習過程を再現できるとは限らない。 |
| モデルパラメータ・重み | 学習後のモデルが実際にどのような出力を生成するかを大きく決める。 | モデルを実行し、評価し、条件が許せば追加学習や変換を行える。 | 重みだけから、元の学習データや学習途中の判断を完全に復元することはできない。 |
| 学習データ | モデルが学習する事例の分布、範囲、偏りを形成する。 | データ構成を調べ、偏りを分析し、別条件での再学習を試せる。 | 同じコードとデータがあっても、乱数や計算環境まで含めて同一モデルを再構築できるとは限らない。 |
| Data Information | どの種類のデータを、どの基準で収集、選択、処理したかを説明する。 | 共有できない元データを含め、学習集合の性質や作り方を理解しやすくなる。 | 元データそのものを使った再学習や、個々のデータ点の検証までは保証しない。 |
| 学習設定 | 学習率、バッチサイズ、エポック数、前処理など学習過程の条件を決める。 | 同じコードとデータを異なる条件で学習させ、挙動を比較できる。 | 必要な計算資源や実行時の非決定性まで解消するわけではない。 |
| 計算資源 | どの規模のモデルを、どの時間と費用で学習・評価できるかを制約する。 | 十分な資源があれば公開された学習工程を実際に実行できる。 | 計算資源そのものがあっても、コード、データ、権利がなければ自由は成立しない。 |
この表から、AI の自由を一つの「ソース公開率」で測ることが難しい理由が分かる。学習コードは処理手順を、学習データは経験させる内容を、重みは学習結果を、学習設定は生成条件を、計算資源は実行可能性を支えている。どれか一つをソースと呼んで他を従属させると、利用者が実際に何を変更でき、何を変更できないのかが見えなくなる。
たとえば、学習コードと重みだけが公開されているモデルでは、利用者は既存モデルを動かし、追加学習できる場合がある。しかし、元の学習データが不明なら、特定の偏りがどのデータに由来するのかを調べたり、同じデータ集合から別のモデルを作ったりすることは難しい。反対に、学習データとコードが公開されていても、必要な計算資源が極端に大きければ、多くの利用者は理論上可能な再学習を現実には実行できない。
この違いを保ったまま考えると、「自由な AI に何を要求するか」という議論も整理しやすくなる。問いは「何が本当のソースか」ではなく、「モデルを利用、研究、変更、再学習、再構築するそれぞれの能力には、どの構成要素が必要か」である。通常のソースコードが複数の自由を一つの形式に集約できていたのに対し、機械学習ではその役割が複数の対象へ分散している。
6.2 「全部公開できない」ことと「自由の要件を弱める」ことも同じではない
学習データには、ソフトウェアのソースコードとは異なる公開上の制約がある。医療記録、個人を識別できる情報、契約によって取得したデータ、第三者が権利を持つ資料などは、モデルの自由を高めたいという理由だけで無条件に再配布できるものではない。AI の自由を議論するときには、「変更のために情報が必要である」という要求と、「その情報を公開する権利や正当性がある」という条件を同時に扱う必要がある。
OSI は、この現実的な制約を前提に Open Source AI Definition を設計している。共有可能な学習データは提供しつつ、個人情報など正当な理由で共有できないデータについては、データの由来、範囲、特性、選択方法、処理方法などを Data Information として詳しく示すことを求める[11]。ここでは、元データを完全に再配布できない場合でも、第三者が学習過程を理解し、類似したデータを構成して意味のある変更を行える余地を残そうとしている。
FSF は異なる線を引いている。2024 年の検討文書では、医療データのように公開できない道徳的理由がある場合、その機械学習アプリケーションを自由とは呼ばない一方、その用途自体が倫理的に許容され、有益である可能性は別に認めている[8]。つまり「自由な機械学習アプリケーションの定義」と「社会的に使うべきかという判断」を分離している。
| 状況 | 自由の観点 | 公開可否の観点 | 混同した場合の誤り |
|---|---|---|---|
| 学習データを自由に再配布できる | 利用者はデータを調査、変更し、再学習へ使える余地が大きい。 | 権利処理や個人情報上の制約が解決されている必要がある。 | 公開可能だからという理由だけで、モデル全体の自由まで自動的に保証したと考えてしまう。 |
| 個人情報のため共有できない | 利用者が元データを使って研究・再学習する自由は制限される。 | プライバシー保護のため非公開とする正当な理由がある。 | 社会的に正当な非公開だから、自由の制約も存在しないと扱ってしまう。 |
| 契約上共有できない | 第三者は同じ学習集合を取得して変更できない。 | 契約条件によって配布権限が制限されている。 | 事業上の都合と自由の定義を同一の基準で処理してしまう。 |
| Data Information のみ公開 | 学習データの構成や処理を理解し、代替データを設計できる余地が残る。 | 元データそのものを開示せずに説明責任の一部を果たせる。 | 説明情報があることを、元データへの完全なアクセスと同じだと考えてしまう。 |
この区別を置くと、「公開できないなら自由の定義を現実に合わせて弱めるべきだ」という結論も、「自由を守るためなら何でも公開すべきだ」という結論も避けられる。自由の基準は、利用者が何を研究し変更できるかを示す。一方、公開可否は、個人情報、第三者の権利、契約、社会的な危険など別の制度条件によって決まる。両者が衝突する場合には、「自由の条件を満たしていないが利用価値はある」という状態も成立する。
医療 AI を例にすると分かりやすい。患者の診療記録をそのまま世界中へ公開すれば、モデルを再学習する材料は増えるかもしれない。しかし、そのために患者のプライバシーを侵害すれば、別の権利を犠牲にしている。逆に、診療記録を非公開にすることが正当でも、そのモデルを誰でも自由に再学習できる状態になったとは言えない。ここでは、「倫理的に使える」「社会的に有用である」「自由な AI である」という三つの判定が別々に存在する。
この分離は、自由ソフトウェアの議論にも必要である。自由ソフトウェアという語は、すべての望ましい性質を一つにまとめた品質表示ではない。セキュリティが高いか、プライバシーを守るか、社会的に有益かとは別に、利用者がプログラムを実行、研究、変更、共有できるかを示す概念である。AI でも同じように、自由、合法性、倫理性、公開可能性を別の軸として記録しなければ、どの条件が満たされ、どこに制約が残っているかを説明できない。
6.3 計算資源へのアクセスは、法的自由とは別の実行可能性である
AI ではもう一つ、通常の自由ソフトウェアより極端に大きくなり得る制約がある。計算資源である。学習コード、モデル構造、学習データ、ハイパーパラメータがすべて公開され、ライセンス上も自由に再利用できるとしても、数千枚規模の GPU、大量のストレージ、高速なネットワーク、長期間の電力を必要とするなら、同じ学習を実行できる主体は限られる。
ここから「誰でも再学習できない以上、その AI は自由ではない」と結論すると、自由と資源へのアクセスを混同する。自由ソフトウェアでも、高価なスーパーコンピュータ向けプログラムや特殊な計測装置を必要とするプログラムは存在する。利用者全員が現実に実行できることは、自由ソフトウェアの四つの自由そのものの条件ではない。変更と再配布を法的に許されているかと、その権利を実際に行使する資金や設備があるかは別である。
ただし、計算資源を単なる外部事情として無視することもできない。モデルの挙動を根本から変える唯一の方法が大規模な再学習であり、その費用を負担できるのが数社だけなら、法的には全員に開かれた変更方法でも、実際には限られた主体しか行使できない。自由は残っていても、自由を行使する主体の分布は大きく偏る。
| 条件 | 利用者が持つもの | 実際に可能なこと | 制約の種類 |
|---|---|---|---|
| コードも権利もない | API や完成したサービスへのアクセスだけを持つ。 | 事業者が許した範囲で利用できる。 | 法的・技術的な自由そのものが制限されている。 |
| コードと重みは自由 | モデルを自分の環境で実行し、軽量な追加学習を試せる。 | 推論、評価、小規模な改変を行える。 | 元モデルを一から再学習する能力までは保証されない。 |
| コード、データ、学習設定も自由 | 学習工程を研究し、別条件で再実行する権利と情報を持つ。 | 十分な設備があればモデルを再学習できる。 | 必要な GPU、電力、時間、費用が実行上の制約になる。 |
| 計算資源まで利用可能 | 法的自由、技術情報、実行環境の三つを持つ。 | 元の学習過程を再試行し、大規模な変更を実際に検証できる。 | なお同じ乱数状態やハードウェア特性まで完全一致するとは限らない。 |
この違いを明示すると、「自由だが現実には難しい」という状態を正確に表現できる。たとえば重み、学習コード、データ、設定が自由な条件で公開されていても、再学習に巨額の費用が必要なら、法的な変更自由は存在する一方、実際にフルスクラッチでモデルを作り直せる主体は少ない。この制約を理由に自由の存在そのものを否定すると、権利と経済力の差を同じ概念へ押し込めることになる。
反対に、API の利用料が安いから誰でも使えるという理由だけで自由と呼ぶこともできない。安価なサービスでも、利用者がモデルのコピーを持たず、重みを取得できず、学習コードを変更できず、事業者がサービスを終了すれば利用できなくなるなら、アクセスしやすさは高くても支配可能性は低い。経済的アクセスの広さと、利用者が対象を研究・変更できる自由は別である。
AI では、この三つの軸を分ける必要がある。第一に、ライセンスや利用条件として何を許されているかという法的自由がある。第二に、コード、重み、データ情報、学習設定へアクセスできるかという技術的な変更可能性がある。第三に、それらを使って実際に学習や評価を行える資源があるかという実行可能性がある。
| 評価軸 | 問う内容 | 典型的な制約 |
|---|---|---|
| 法的自由 | 利用、研究、変更、再配布を許されているかを確認する。 | ライセンス、利用規約、再配布制限、用途制限が影響する。 |
| 技術情報へのアクセス | 変更に必要なコード、重み、学習情報を取得できるかを確認する。 | 非公開モデル、非公開データ、非公開学習設定が影響する。 |
| 実行可能性 | 取得した情報を使って実際に推論、追加学習、再学習できるかを確認する。 | GPU、ストレージ、電力、費用、時間、専門技能が影響する。 |
この分離は、前章で見た FSF、OSI、SFC の差も理解しやすくする。学習データをどこまで要求するかという議論は技術情報へのアクセスに関わる。モデルの再学習を公衆が行えるべきだという要求は、その情報を実際に使える実行可能性まで視野に入れる。両者は接続しているが、同じ条件ではない。
自由ソフトウェアと AI を接続するとき、学習データ、重み、計算資源を一つのソース概念へ押し込める必要はない。それぞれが利用者の異なる能力を支えていると考えた方が、制約の所在を正確に示せる。重みがあれば既存モデルを実行できる。学習コードがあれば処理を研究できる。学習データがあればモデル形成の材料を調べられる。学習設定があれば学習条件を変更できる。計算資源があれば、それらの自由を大規模な再学習として実際に行使できる。
通常の自由ソフトウェアではソースコードがこれらの能力の多くを比較的まとまった形で支えていた。機械学習では、その役割が複数の構成要素へ分散している。AI 時代の「ソース」を考えるときに必要なのは、すべてを一つの語へ統合することではなく、利用者が何をしたいときに、どの情報、権利、資源を必要とするのかを分けて示すことである。
7. 再現可能性、透明性、自由は互いに関係するが同じではない
7.1 再現可能なビルドは「同じ入力から同じ成果物を作れるか」を問う
自由ソフトウェアと AI を考えるとき、「再現できるか」という言葉は便利だが、その意味を分けないと議論が崩れる。ソースコードから同じバイナリを再構築できること、同じ AI へ同じ入力を与えて同じコードを得られること、別の利用者が同じモデルを再学習できることは、すべて別の再現性である。それらは自由と関係するが、どれか一つを満たせば他も満たすわけではない。
Reproducible Builds は、この中でも対象を明確に限定している。同じソースコード、同じビルド環境、同じビルド手順を与えたとき、任意の主体が指定された成果物をビット単位で同一に再作成できる状態を再現可能と定義する[15]。ここで確認しているのは、「公開されたソースから本当に配布物が作られたのか」を第三者が独立して検証できるかという関係である。
たとえば、あるプロジェクトがソースコードと署名済みバイナリを配布しているとする。利用者が公開されたソースを自分でビルドし、その結果が配布バイナリとビット単位で一致すれば、配布物に公開ソースからは説明できない変更が混入していないことを検証しやすくなる。これはサプライチェーンの検証や改ざん検出に強い意味を持つ。しかし、そこで確認できるのはソースとバイナリの対応であり、そのソースを変更して再配布する法的権利まで自動的に与えるものではない。
逆方向も同じである。GPL のソフトウェアが、ビルド日時、ファイル順序、乱数、外部サービスの応答などによって毎回異なるバイナリを生成する場合、そのソフトウェアは再現可能なビルドになっていない可能性がある。それでも、利用者がソースを研究、変更、再配布する四つの自由を失うわけではない。自由と再現可能性は、同じ成果物に関係していても別の失敗条件を持つ。
| 概念 | 中心となる問い | 満たされると得られるもの | 満たしても保証しないもの |
|---|---|---|---|
| 自由ソフトウェア | 利用者が実行、研究、変更、再配布できるかを問う。 | プログラムを自分の目的に合わせて変更し、変更版を共有できる。 | 同じバイナリをビット単位で再現できることまでは保証しない。 |
| 再現可能なビルド | 同じソース、環境、手順から同一成果物を再作成できるかを問う。 | 公開ソースと配布バイナリの対応を第三者が独立に検証しやすくなる。 | ソースを変更・再配布する法的自由までは保証しない。 |
| 透明性 | 構成、由来、手順、判断条件についてどこまで情報が見えるかを問う。 | 利用者が仕組みや生成経路を把握しやすくなる。 | 見えている情報を変更し、再配布する権利までは保証しない。 |
| 実行可能性 | 必要な計算資源、技能、設備を現実に用意できるかを問う。 | 与えられた自由や技術情報を実際の作業として行使できる。 | 利用、変更、再配布を法的に許されていることまでは保証しない。 |
| AI の再生成可能性 | 同じモデル、文脈、入力から同じ、または同等のコード変更を再度得られるかを問う。 | AI を使った開発手順を後から検証し、再試行しやすくなる。 | 元のコードや AI システムそのものが自由であることまでは保証しない。 |
この区別を置かないと、「同じ結果を再現できないから非自由である」という誤った接続が生まれる。自由ソフトウェアの変更自由は、元と同じ成果物を作り直す自由ではなく、自分の目的に合わせて異なる成果物を作る自由でもある。むしろ変更した結果が元と違うことを許すのが自由である。再現可能なビルドが求める「同じ入力なら同じ成果物」と、自由ソフトウェアが認める「入力やソースを変えて別の成果物を作る」は、別の方向を向いている。
一方で、両者は完全に無関係でもない。ソースを自由に取得・変更できても、配布バイナリがそのソースから作られたのか確認できなければ、利用者は公開された自由なソースと実際に実行するプログラムの間を検証しにくい。再現可能なビルドは、四つの自由へ新しい項目を加えるものではなく、公開されたソースと実行対象の対応を確認可能にすることで、既存の自由を信頼して行使するための検証基盤になる。
7.2 AI の確率的出力を、ビット単位の再現と同じ基準で測る必要はない
AI エージェントを使った開発では、「同じ入力から同じ成果物」という条件をそのまま持ち込めない場合が多い。同じ指示文を送っても、モデルの更新、乱数、会話履歴、検索結果、利用可能なツール、非公開のシステム指示などによって別のパッチが生成され得る。外から見えるプロンプトが同じでも、実際にモデルへ与えられた入力全体が同じとは限らない。
たとえば、ある日に AI エージェントへ「このテスト失敗を直して」と依頼し、3 ファイルを変更するパッチが生成されたとする。翌月に同じ指示を与えても、モデルが更新されていれば 5 ファイルを変更する別の実装が出るかもしれない。どちらもテストを通し、仕様を満たす可能性がある。この場合、同じパッチを再生成できないというだけで変更能力が失われたとは言えない。
自由ソフトウェアに必要なのは、過去と同一のパッチを再び得ることではなく、利用者がソースを理解し、自分の目的に合わせて別の変更を作れることである。AI が異なる実装を生成しても、そのコードを利用者が取得、研究、修正、再配布できるなら、出力の非決定性と自由の有無は分けて評価できる。
ただし、AI の非決定性が開発工程の追跡可能性を弱めることはある。昨日生成した修正を今日もう一度説明しようとしても、同じモデル、同じ版、同じ会話履歴、同じ検索結果を用意できなければ、同じ判断経路を再現できない。すると、なぜその変更になったのかを確認するために必要な情報が、完成したコードの外側に増える。
| 変動要因 | 同じ指示でも変わり得るもの | 記録しない場合の影響 | 記録する意味 |
|---|---|---|---|
| モデルの版 | コード生成能力、推論傾向、選択する実装方針が変わる。 | 同じ指示から別の変更が出た理由を追いにくくなる。 | どの能力と挙動を前提に生成したかを特定できる。 |
| システム指示 | 禁止事項、優先順位、回答形式、ツール利用方針が変わる。 | 利用者が見えているプロンプトだけでは生成条件を説明できない。 | 利用者側で管理可能な指示は、開発条件として残す価値がある。 |
| 会話履歴 | 以前の判断、修正方針、既知の制約が次の出力へ影響する。 | 単独の最終プロンプトから変更理由を再構成できない。 | どの前提が累積して最終変更へ至ったかを確認できる。 |
| 検索・取得結果 | 参照する API 文書、Issue、既存コード、外部資料が変わる。 | 後から同じ情報源を参照して検証できなくなる。 | 変更がどの資料に基づいていたかを追跡できる。 |
| 乱数・サンプリング | 候補となる実装、説明、変更順序が変わる。 | 同一条件でも完全に同じ結果を期待できない。 | 完全再現が可能な条件と、意味的な再現しかできない条件を区別できる。 |
| 利用可能なツール | 検索、テスト、シェル実行、ファイル編集の方法が変わる。 | モデル名が同じでも、エージェント全体として同じ能力にならない。 | モデルだけでなく開発環境全体を生成条件として把握できる。 |
ここでは「再現」の水準を分けると整理しやすい。最も厳しいのは、同じ入力からビット単位で同じ成果物を得る再現である。その次に、同じパッチや同じソース差分を得る再現がある。さらに緩い水準として、同じ仕様を満たす別実装を得る意味的な再現がある。AI エージェントの開発では、後ろ二つしか現実的でない場合が多い。
| 再現の水準 | 要求する一致 | AI 開発での意味 |
|---|---|---|
| ビット単位の再現 | 成果物の全ビットが一致する。 | 通常の再現可能 build では重要だが、確率的なコード生成そのものにはそのまま適用しにくい。 |
| 差分の再現 | 同じファイルへ同じ変更が入る。 | モデル、入力、環境を固定できれば目指せる場合があるが、必須とは限らない。 |
| 意味的な再現 | 同じ仕様、テスト、制約を満たす変更が得られる。 | AI エージェントでは、異なる実装でも同じ要求を満たせるため実務上重要になる。 |
| 工程の再現 | 同じ資料、制約、検証手順を使って変更作業をやり直せる。 | 同じパッチが出なくても、判断条件と検証方法を第三者が追える。 |
自由ソフトウェアとの接続で特に重要なのは、最後の工程の再現である。AI が異なるパッチを出しても、第三者が同じ仕様、同じテスト、同じ設計制約を読み、別のモデルや人間の手で同等の変更を作れるなら、開発能力は共同体に残っている。反対に、同じ AI サービスへ同じ依頼をしなければ変更できず、そのサービス内部の文脈も固定できないなら、過去の成果を複製できるか以前に、変更工程そのものが外部化されている。
このため、AI を使った開発では「同じ結果を再生成できるか」だけでなく、「変更条件を第三者が再構成できるか」を記録した方がよい。使用したモデルと版、主要なプロンプト、恒久的なエージェント指示、参照した仕様、テスト、ツール、採用したパッチ、人間による修正内容を残せば、完全に同じ出力を得られなくても、なぜその変更を受け入れたのかを後から検証できる。
7.3 透明性が高くても自由とは限らず、自由でもすべてが透明とは限らない
再現可能性と同様に、透明性も自由と混同しやすい。モデルの構造、学習データの概要、システム指示、生成ログが詳細に公開されていれば、その AI がどのように動くかを理解しやすくなる。しかし、公開された情報の利用や改変、再配布をライセンスで禁止していれば、透明性が高くても自由ではない。
反対に、自由なライセンスで公開されたソフトウェアでも、すべての設計理由、開発者の会話、過去の判断、ビルド環境まで完全に記録されているとは限らない。四つの自由は、あらゆる背景情報の公開を要求する概念ではない。そのため、「情報が足りないから非自由」と「情報が足りないため保守や検証が難しい」も分ける必要がある。
| 状態 | 透明性 | 自由 | 利用者ができること |
|---|---|---|---|
| 内部仕様を詳細公開するが改変禁止 | 高い。 | 変更自由がない。 | 仕組みを理解できても、自分の変更版を自由に作って共有できない。 |
| 自由なライセンスでソースを公開 | 主要な実装は見える。 | 高い。 | ソースを研究、変更、再配布できるが、すべての設計履歴が分かるとは限らない。 |
| AI の生成ログだけ公開 | 生成工程の一部は見える。 | モデルや成果物のライセンス次第で別に決まる。 | どの指示で生成したかは追えても、AI 自体を変更できるとは限らない。 |
| モデル、コード、変更情報を自由に公開 | 高くできる。 | 利用者が変更・共有できる条件を満たしやすい。 | 仕組みを調べ、自分の目的に合わせた変更版を作る余地が大きい。 |
透明性は、自由を行使するときの情報量を増やす。再現可能性は、公開された情報と成果物の対応を検証しやすくする。自由は、その情報や成果物を利用者自身が研究、変更、共有できる権利を与える。実行可能性は、それらの権利と情報を現実の計算として使えるかを左右する。それぞれが別の不足を埋めている。
AI 時代にこれらを分ける必要があるのは、どれか一つを「オープン」という語で代表させると、利用者が実際に失っている能力が見えなくなるためである。重みが公開されていても再配布できない場合がある。学習データの詳細が説明されていても元データへアクセスできない場合がある。コードが自由でも、特定 AI なしでは変更工程を再現できない場合がある。逆に、同じ生成結果を再現できなくても、第三者が別の手段で同じ仕様を満たす変更を作れるなら、変更能力は残っている。
自由ソフトウェアと AI を接続するときに必要なのは、すべてを「再現できるか」に還元することではない。何を再現したいのか、何を変更したいのか、そのためにどの情報と権利が必要なのかを分けることである。ビット単位の再現、AI 出力の再生成、開発工程の再構成、利用者の変更自由は別々の条件である。この区別を保つことで、AI の非決定性を理由に自由を否定することも、自由なライセンスだけを理由に検証可能性の不足を見落とすことも避けられる。
8. AI 生成コードでは、由来と著作権を自由の問題から切り分ける必要がある
8.1 自由なライセンスを付けるには、付ける側が権利を持つという前提がある
AI が生成したコードを GPL などの自由なライセンスで公開したとき、確認すべきことは一つではない。第一に、そのコードを受け取った利用者へ、実行、研究、変更、再配布の自由が与えられているかを確認する必要がある。第二に、そのライセンスを付けた側が、そもそも第三者へその権利を与えられる立場にあるかを確認する必要がある。前者は自由ソフトウェアとしての条件であり、後者は著作権や既存ライセンスとの整合に関する条件である。
この二つを分けないと、「GPL と書いて公開したのだから自由ソフトウェアである」という説明が途中で止まる。ライセンス表示は、配布者が持っていない権利まで新しく生み出すものではない。生成結果が第三者の著作物を再現していたり、既存のコピーレフト作品を変更したものだったりする場合には、その元作品に由来する条件が別に存在し得る。成果物を自由な条件で配布したいという意思と、その条件を有効に許諾できる権限は別である。
たとえば、AI が生成した関数へ GPLv3 の表示を付けて公開したとしても、その関数が既存の別プロジェクトのコードに含まれる著作権上保護される表現を複製・翻案していると評価されるなら、確認すべき対象は AI の利用有無ではなく、その既存コードとの関係になる。元コードが GPL なら GPL 上の義務との整合を確認する必要があり、別の条件ならその条件が影響する可能性がある。AI を経由したことで、元の権利関係が自動的に切断されるとは考えられない。
一方で、AI を使ったという理由だけから、生成コードについて第三者の権利侵害が存在すると推定することもできない。生成物がどの程度人間によって選択、修正、構成されているか、既存コードとどの程度対応しているか、どの法域で判断するかによって論点は変わる。AI 利用という一つの事実から、著作権の成立、侵害、ライセンス義務まで一括して結論することはできない。
米国著作権局は 2025 年の AI 報告 Part 2 で、生成 AI を利用したこと自体は著作権保護を妨げない一方、保護されるためには人間が十分な表現要素を決定している必要があり、単にプロンプトを与えただけでは足りないという立場を示した[16]。ここで扱われているのは、AI 利用者にどの範囲の著作権が成立し得るかという米国法上の著作者性の問題であり、「AI 生成コードを自由ソフトウェアとして配布できるか」という問いそのものではない。
この区別は実務上も必要になる。人間が AI 出力を大きく修正し、複数の生成候補を選択し、既存コードと統合した場合には、人間の寄与について別の評価が必要になる。反対に、AI の出力をほぼそのまま採用した場合には、誰がどの表現について権利を持つのかという問いが残る。どちらの場合も、最終的な FOSS ライセンスの表示だけを見て、権利関係まで解決したとは判断できない。
| 確認対象 | 自由ソフトウェアとして問うこと | 由来・著作権として問うこと | 混同した場合の誤り |
|---|---|---|---|
| AI が新たに生成したコード | 利用、研究、変更、再配布を認める条件で提供されているかを確認する。 | 配布者がその条件を付与できる権利をどこまで持つかを確認する。 | 自由なライセンス表示があれば権利関係も自動的に解決すると考えてしまう。 |
| 既存コードを入力にしたパッチ | 変更版をプロジェクトの自由な条件で利用・配布できるかを確認する。 | 元コードのライセンス義務が変更部分や配布物へどう及ぶかを確認する。 | AI を介したことで元コードとのライセンス関係が消えたと考えてしまう。 |
| 既存コードと似た生成結果 | 自由な条件で公開したいという配布方針を確認する。 | 類似が著作権上どのような意味を持つかを、具体的なコードと法域に応じて確認する。 | 類似しているだけで直ちに侵害、または AI 生成だから直ちに非侵害と断定してしまう。 |
| モデルの学習元 | AI システム自体の自由や変更可能性を考える材料になる。 | 学習利用、モデル生成、出力との権利関係を個別に検討する必要がある。 | 学習段階の問題と個々の生成コードの配布条件を一つの問題として扱ってしまう。 |
| 人間による選択・修正 | 人間が生成コードを理解し保守できるかという開発条件に関わる。 | 人間による表現上の寄与がどこまで著作者性を構成するかに関わり得る。 | 保守能力と著作権上の創作性を同じ基準で判定してしまう。 |
学習段階の著作権については、さらに別の不確定性がある。米国著作権局の AI Study は、生成 AI の学習を扱う Part 3 を 2025 年 5 月に pre-publication 版として公開し、現在の案内でも最終版は今後公開するとしている[17]。SFC も 2026 年の勧告で、AI 支援・生成による FOSS 貢献の法的意味には未解決の問題が多いとして、単純な一般則を置くことを避けている[7]。
この不確定性がある以上、「AI 学習はすべて合法だから出力も問題ない」「学習に著作物が含まれるからすべての出力が問題である」という両極の整理は採れない。学習時の利用、モデルそのもの、個々の出力、FOSS プロジェクトへの取り込みは、それぞれ異なる事実関係を持つ。生成コードの受け入れでは、現在確認できる出力と由来に基づいて判断し、確定していない法的論点を確定済みの前提として扱わない方がよい。
| 段階 | 主な対象 | 確認すべきこと | 次の段階へ自動的には引き継げないこと |
|---|---|---|---|
| 学習 | 学習データとモデル開発者の利用行為を扱う。 | どのデータをどの条件で学習に利用したかを確認する。 | 学習が適法かどうかだけで、個々の出力の権利関係まで決まるわけではない。 |
| 生成 | モデルが出した具体的なコードを扱う。 | 既存コードとの関係、人間の関与、生成条件を確認する。 | 生成されたという事実だけで配布ライセンスを自由に決められるとは限らない。 |
| 取り込み | FOSS プロジェクトへ採用する変更を扱う。 | ライセンス適合性、人間のレビュー、由来の記録を確認する。 | テストに通ったことだけで権利上の確認まで完了したとは言えない。 |
| 再配布 | 利用者へ提供する完成したソフトウェアを扱う。 | 自由なライセンス条件と、元作品に由来する義務が整合しているかを確認する。 | 配布者の希望だけで第三者の既存権利を上書きすることはできない。 |
著作権が成立する部分については、配布者がどの権利を持ち、どの条件で利用者へ許諾できるかを確認する必要がある。自由なライセンスは、著作権が成立する著作物について、権利者の許諾を通じて利用者の実行、研究、変更、再配布の自由を確保する仕組みである。一方、著作権が成立しない部分では、同じ許諾構造を前提にできない。AI 生成コードで権利主体や由来が不明確になると、どの部分について誰がどの権利を持つのかを分けて確認する必要が出てくる。
8.2 由来情報（provenance）は「誰が書いたか」だけでなく、後から追跡できる形で残す
AI 生成コードの由来を確認するとき、すべての生成物について「学習データのどのコード片が影響したか」を完全に逆算することは現実的ではない。モデル内部の学習過程と個々の出力の対応を、通常の version control のように一対一で追跡できないためである。そのため実務では、分からない由来を推測で埋めるより、開発時点で確認できる情報を失わないことの方が重要になる。
記録すべき対象は、単に「AI を使った」という一項目ではない。どのモデルと版を使ったか、どのリポジトリやファイルを入力として与えたか、どのプロンプトや恒久的な指示が使われたか、生成された変更を人間がどこまで修正したか、どのテストを通し、誰が最終的に採用したかを分けて残す必要がある。こうしておけば、後からライセンス上の疑義が生じたときにも、どの時点の何を調査すべきかを絞れる。
| 記録対象 | 後から確認できること | 記録がない場合に困ること |
|---|---|---|
| モデル名・版 | どの生成能力と利用条件を前提にコードが作られたかを特定できる。 | 同じサービス名でもモデル更新による差を追えなくなる。 |
| 入力したソース | どの既存コードを参照した変更かを確認できる。 | 第三者コードとの関係を調べる対象範囲が不明になる。 |
| プロンプト・指示 | どの要求と制約から変更が生成されたかを確認できる。 | AI が独自に生成した部分と、人間が具体的に指定した部分を区別しにくくなる。 |
| AI の生成結果 | 人間による修正前の出力を比較できる。 | どの部分が AI 由来で、どの部分が後から変更されたかを追えなくなる。 |
| 人間による修正 | 最終成果物へ人間がどの変更を加えたかを確認できる。 | 人間の著作者性やレビュー範囲を後から説明しにくくなる。 |
| テスト・レビュー結果 | どの条件を満たしたため採用したのかを確認できる。 | 生成物を受け入れた根拠と責任主体が不明になる。 |
| 最終コミット | 生成工程と実際に配布されたソースを結び付けられる。 | 記録した AI 利用と成果物のどの版が対応するか分からなくなる。 |
このような由来情報を残す意味は、「AI が書いたか、人間が書いたか」という作者ラベルを付けることだけではない。後から疑義が生じたときに、成果物から入力、生成、レビューまで遡れるようにすることである。ある関数について既存プロジェクトとの類似が指摘された場合、使用モデル、入力ソース、生成時点のコード、修正履歴が残っていれば、少なくとも調査の対象と順序を確定できる。
Software Heritage の SWHID は、この追跡の一部を支える。SWHID は Software Heritage に保存されたソース成果物を内容に基づく識別子で参照し、特定のソース内容を長期間安定して指し示す仕組みである。origin などの文脈情報も修飾子として扱える[18]。これによって、「ある URL にあったコード」ではなく、「この内容を持つ特定のソース成果物」を参照できる。
SWHID の役割は、著作権者を確定することではない。あるコードが誰の著作物であるか、AI がそこから何を学習したかを自動的に証明するものでもない。価値があるのは、調査対象となるソースを内容ベースで固定し、後から同じ対象を参照できることである。Web ページやリポジトリの内容が変更されても、当時参照していた成果物を特定しやすくなる。
SPDX 3.0.1 は、さらに広い範囲の関係を機械可読に記録するための構造を持つ。通常の Software や Licensing に加えて Dataset、AI、Build の profile があり、データセットの出所とライセンス、AI システムの構成要素や依存関係、ビルドの入力、出力、手順、環境などを表現できる[19]。AI Profile の AIPackage では、学習情報、ハイパーパラメータ、前処理、モデル種別なども記録対象になる[20]。
| 仕組み | 記録できる対象 | AI 生成コードでの使い道 | 証明できないこと |
|---|---|---|---|
| SWHID | 特定のソース成果物を内容由来の識別子で参照できる。 | AI に入力した、または調査対象となるコードの特定版を固定して示せる。 | 著作権者、AI の学習元、権利侵害の有無を自動的に証明するものではない。 |
| SPDX Software Profile | ソフトウェア構成要素、パッケージ、ファイル、関係を記録できる。 | 生成コードを含む成果物がどの構成要素から成るかを機械可読に整理できる。 | 記録されたライセンス情報が法的に正しいことを自動的に保証しない。 |
| SPDX Dataset Profile | データセットの構成、由来、ライセンスなどを記録できる。 | AI システムに関係するデータの出所と条件を成果物へ関連付けられる。 | 非公開データの内容や利用適法性を完全に証明するものではない。 |
| SPDX AI Profile | AI パッケージ、モデル情報、学習関連情報などを記録できる。 | どの AI システムが生成や開発工程に関係したかを構造化して残せる。 | AI の出力が第三者コードを再現していないことを保証しない。 |
| SPDX Build Profile | ビルド入力、出力、手順、環境を記録できる。 | AI 生成物を含むソフトウェアがどの工程から最終成果物になったかを追跡できる。 | 記録された工程の安全性やライセンス適合性そのものを判定しない。 |
ここで由来情報と権利判定を分けることも必要になる。記録が詳細だからといって、そのコードが法的に安全だと証明されたわけではない。反対に、記録が足りないから直ちに権利侵害があるとも言えない。由来情報の役割は、後から判断するための証拠と経路を失わないことにある。
この差は AI 生成コードで特に大きい。通常の人間による開発でも、どの資料を参考にしたかを完全には記録できない。しかし AI では、モデル、入力コード、プロンプト、検索結果、生成物、人間による修正という複数の段階を短時間で通過する。生成量が増えるほど、一つ一つの変更について記憶だけを頼りに由来を説明することは難しくなる。工程を機械可読に残す価値は、生成速度と変更量が増えるほど高くなる。
自由ソフトウェアとの接続では、由来情報は自由そのものではない。詳細な生成履歴が残っていても、成果コードの変更や再配布が禁止されていれば自由ソフトウェアではない。逆に、自由なコードでもすべての開発履歴が記録されているとは限らない。それでも、AI によって制作工程が複雑化し、著作権や既存ライセンスとの関係を後から調べる必要が増えるなら、由来情報は自由な成果物を安全に引き継ぐための実務基盤になる。
AI 生成コードについて求めるべきなのは、「AI が書いた」と一行表示して終わることではない。どの AI を使い、何を入力し、何が生成され、人間がどこを確認・修正し、どの成果物へ取り込んだのかを追跡可能にすることである。自由なライセンスは利用者へ権利を渡し、由来情報はその権利をどの成果物へ安心して適用できるかを後から調べるための経路を残す。AI 時代には、この二つを別の役割として設計する必要がある。
9. FOSS プロジェクトでは、AI の可否より受け入れ工程を設計する必要がある
9.1 2026 年の SFC 勧告は全面禁止でも全面容認でもない
FOSS プロジェクトが AI 生成コードを受け入れるかどうかを考えるとき、「AI を使った貢献は禁止する」「AI を使っていても通常の貢献と同じように扱う」という二択では運用条件を捉えきれない。AI を使った変更でも、人間が内容を理解し、由来を記録し、テストとレビューを通したものと、人間が内容を確認せず自動生成したものでは、保守者が引き受けるリスクと確認コストが違うからである。
Software Freedom Conservancy は 2022 年、GitHub Copilot を契機に、機械学習支援プログラミングがソフトウェア自由へ与える影響を論じた。そこでは、生成されたコードだけでなく、モデルや入力まで含めて利用者が fork できる状態を理想として示している[21]。この時点では、AI 支援開発を単なるコード生成機能として見るのではなく、開発系そのものを誰が支配できるかという問題として扱っていた。
その後の 2026 年の勧告では、より具体的な FOSS 貢献の受け入れ工程が示されている。SFC は、AI を使いたくない貢献者が参加できることを守る一方、AI を利用した貢献を一律に排除する方針も採っていない[7]。代わりに、人間による理解、利用方法の開示、対話記録の保存、人間未確認の自動貢献の制御など、生成後の扱いへ条件を置いている。
この方針では、「AI を使ったか」は受け入れ判定の終点ではなく入口になる。AI を使ったと分かった後に、誰が変更内容を理解しているのか、どのモデルをどの用途で使ったのか、どの入力から生成したのか、誰が最終的に責任を持って提出したのかを確認する。AI 利用の有無を一つの禁止条件にする代わりに、受け入れ可能な状態へ整える工程を設計している。
| 受け入れ条件 | 確認する対象 | 不足した場合の直接的な問題 | 共同体へ生じる帰結 |
|---|---|---|---|
| 人間によるレビュー | 提出者が変更内容、影響範囲、失敗条件を説明できるかを確認する。 | 生成された変更の妥当性を保守者が最初から検証し直す必要が生じる。 | 生成側が省いた理解と確認のコストがレビュー側へ移転する。 |
| AI 利用の開示 | どの貢献で、どの工程に AI が関与したかを確認する。 | 追加確認が必要な変更を後から特定しにくくなる。 | プロジェクトが AI 利用の実態を把握できず、受け入れ方針を調整できなくなる。 |
| モデル・版・用途の記録 | どの AI を、補完、実装、レビュー、設計のどこに使ったかを確認する。 | サービス更新後に出力差や不具合の原因を追跡しにくくなる。 | 同じ名前のサービスを使っていても、異なるモデル挙動を区別できなくなる。 |
| 対話・メタ成果物の保存 | どの指示、文脈、判断過程から変更が生じたかを確認する。 | 完成コードだけでは設計理由や却下した案を復元できない。 | 次の保守者が失われた判断過程を再構築する負担を負う。 |
| 人間未確認の自動貢献の制御 | 人間が確認していない生成物をどこまで自動提出できるかを制御する。 | 生成側の限界費用が低いため、大量の未検証変更を送信できる。 | 保守者の有限なレビュー能力が生成量によって圧迫される。 |
この受け入れ設計が必要になるのは、AI 生成コードに人間のコードとは別の性質があるからというより、生成と確認の費用構造が変わるためである。AI は候補となる変更を短時間で大量に作れる。しかし、依存関係、互換性、セキュリティ、ライセンス、テスト結果を確認する工程は、同じ割合では自動化できない。生成工程だけが安くなると、確認を省いた変更を共同体へ送る誘因が強くなる。
そのため、FOSS プロジェクトの実務上の境界は、「AI が生成したか」ではなく、「誰が確認して責任を引き受けたか」に置いた方が安定する。AI が生成した変更でも、提出者が内容を理解し、由来と利用方法を記録し、テストし、レビューに応答できるなら、共同体が受け取るのは人間の責任下に置かれた変更である。人間の確認を経ずに自動提出された場合には、共同体が受け取るのは未検証の候補であり、保守者が生成者の代わりに検証工程を引き受けることになる。
9.2 生成速度が上がるほど、自由を支える人間側の処理能力が制約になる
既稿「この物量の文章を、一体誰が検証できるのか」では、AI によって生成量が増えても、根拠を読み、事実を確認し、誤りを訂正する人間の処理能力は同じ速度では増えないと論じた[22]。FOSS のコード貢献でも同じ非対称が生じる。AI エージェントが数分で複数の pull request を作れても、保守者がそれぞれについて影響範囲、テスト、互換性、ライセンス、設計整合性を同じ速度で確認できるわけではない。
この非対称は、生成側と受け入れ側で必要な仕事が違うために生じる。生成側は「もっともらしい変更案」を作れば次へ進める。受け入れ側は、その変更を本番のコードベースへ入れてよいか判断しなければならない。見た目が正しいだけでは足りず、既存 API を壊さないか、想定外入力で失敗しないか、別のプラットフォームでも動くか、ライセンス上問題がないかまで確認する必要がある。
| 工程 | AI によって下がるコスト | 人間側に残るコスト | 生成量が増えたときの帰結 |
|---|---|---|---|
| 変更案の作成 | 複数の候補を短時間で生成できる。 | 各候補の必要性と妥当性を判断する必要がある。 | 不要な候補まで大量に生成されると、選別負荷が増える。 |
| 実装 | 複数ファイルにまたがる変更を自動生成できる。 | 変更された全箇所と依存関係を確認する必要がある。 | 変更量がレビュー可能量を超えると、理解不足のまま取り込む圧力が高まる。 |
| テスト生成 | 既存仕様に合わせたテスト候補を作れる。 | テストが正しい仕様を表しているかを確認する必要がある。 | 実装とテストを同じ AI が生成すると、同じ誤解を相互に補強する可能性がある。 |
| 説明 | 変更内容の要約や理由を自動生成できる。 | 説明が実際のコードと一致するかを確認する必要がある。 | 説明文を読んだだけでレビューしたつもりになる危険が増える。 |
| pull request 提出 | 変更、説明、テスト結果まで自動で整形できる。 | 保守者は提出された変更ごとに最終判断を行う。 | 提出件数が急増すると、共同体のレビュー待ちが新しいボトルネックになる。 |
人間が書いたコードにも誤りはあるため、「AI 生成だから特別に疑う」という基準だけではこの問題を説明できない。差が生じるのは、誤りを含み得る変更を作る限界費用が大きく下がることにある。人間が一日に一件しか作れなかった変更を AI が十件作れるようになれば、各変更の品質が同程度でも、保守者へ届く確認対象は十倍になる。
さらに、提出者自身が十分に確認せず「CI が通ったので送る」という運用を始めると、確認コストは生成側から共同体側へ移転する。提出者は数分で pull request を作れるが、保守者はコードを読み、失敗条件を考え、再現し、必要なら修正方針を説明する。その結果、AI によって開発が高速化したはずなのに、プロジェクト全体ではレビュー待ちや保守者の疲弊が増えることがある。
この構造では、pull request の生成数を増やすことが生産性とは限らない。FOSS プロジェクトが必要としているのは、候補の総量ではなく、理解され、検証され、将来も保守できる変更である。生成工程の速度だけを評価すると、最も希少な資源である保守者の注意を消費する方向へ最適化される。
| 提出状態 | 生成者が負担している確認 | 保守者へ移る確認 | 共同体全体の効率 |
|---|---|---|---|
| AI 生成後に人間が十分に確認 | 変更内容、テスト、影響範囲を提出前に確認する。 | 通常のコードレビューへ集中できる。 | 生成速度の向上を保守者の負荷増加へ直結させにくい。 |
| CI 通過だけ確認 | 機械的なテスト結果だけを確認する。 | 設計妥当性、例外条件、保守性を保守者が確認する。 | 生成側の時間短縮がレビュー側の追加作業になる。 |
| AI が自動提出 | 人間による事前理解がほとんどない。 | 必要性の判断から実装確認まで保守者が引き受ける。 | 生成量が増えるほど共同体の処理能力を消費する。 |
自由ソフトウェアの持続性は、変更できる法的権利だけでは成り立たない。誰かがコードを読み、レビューし、不具合を直し、次の人へ知識を渡す必要がある。AI が生成量を増やすほど、この人間側の処理能力が相対的に希少になる。SFC が人間による理解と人間未確認の自動貢献の制御を求める理由は、AI 生成物を道徳的に低く見るためではなく、共同体へ送る前に生成者側で確認コストを負担させる必要があるためと読める[7]。
9.3 非自由な AI の利用は、自由ソフトウェアの目的との距離で判断する
ここまでの議論から、非自由な AI を使ったという一事だけで貢献を判定するのが粗い理由も見える。非自由な AI を使っていても、その利用が一時的な補完にとどまり、成果コード、設計知識、変更能力が共同体の側へ残る場合がある。反対に、自由なライセンスのモデルを使っていても、人間が内容を確認せず大量の変更を自動投入すれば、保守者の処理能力を圧迫する問題は残る。
SFC の 2026 年勧告は非自由な LLM 系を避ける方向を示しながらも、それを FOSS の改善へ大きく寄与させられる場合には戦略的な妥協になり得るとしている[7]。Kühn も同年の論考で、初期 GNU が非自由な Unix やコンパイラを利用しながら自由な代替物を作った歴史を参照し、非自由な道具の利用と、利用者へ非自由な成果物を渡すことを同じ倫理的重さでは扱っていない[3]。
この比較で見るべきなのは、「非自由な道具を使った」という一点ではなく、その依存がどこへ向かっているかである。非自由な AI を使うことで自由なコードが増え、生成後のコードを人間が理解し、将来は別の道具へ置き換えられるなら、依存は過渡的な手段として説明できる。反対に、自由なコードを作るたびに特定 AI への依存が深まり、その AI がなければ設計も保守もできない状態になるなら、成果物の自由を増やす一方で開発能力の自由を減らしている。
| 利用形態 | 自由な成果物への寄与 | 新たに生じる依存 | 評価 |
|---|---|---|---|
| 一時的な補完に 非自由な AI を利用 | 自由なコードの作成速度を上げる。 | 補完機能への効率上の依存が生じる。 | AI がなくてもコードを保守できるなら依存は限定的である。 |
| 実装に継続利用するが人間が理解 | 実装量を増やし、FOSS の改善を加速できる。 | 実装速度が特定サービスへ依存する。 | 設計と保守能力が共同体側に残るかが分岐点になる。 |
| 設計・保守まで 非自由な AI に依存 | 短期的には大規模な変更を高速化できる。 | ソフトウェアを理解し変更する能力がサービス提供者へ移る。 | 自由な成果物を増やしながら、開発系の自己完結性を弱める。 |
| 自由な AI へ置換可能な運用 | 成果コードの自由に加え、開発手段の代替可能性も維持できる。 | 特定ベンダーへの固定を減らせる。 | 長期的な開発能力を共同体側へ残しやすい。 |
ここでは時間軸も必要になる。現在 非自由な AI を使っているという状態と、将来もその AI から離れられないという状態は同じではない。新しい FOSS ツールを作るために一時的に非自由なサービスを使い、その成果物と開発知識を共同体へ残し、後に自由な代替手段へ移行できるなら、依存は縮小する方向へ進む。逆に、AI を使うたびに非公開の文脈、モデル固有の手順、サービス独自機能へ開発工程を寄せていけば、依存は時間とともに強くなる。
そのため、非自由な AI の利用を評価するときには、現在の利便性だけでなく出口を確認する必要がある。AI が停止した場合に何が失われるか、別モデルへ切り替えられるか、重要な仕様と設計判断が公開リポジトリへ残っているか、人間が生成コードを直接保守できるかを見る。これらが満たされていれば、AI は交換可能な開発手段として扱いやすい。満たされていなければ、自由なソフトウェアの周囲に非自由な開発基盤が固定される。
| 判断軸 | 自由を増やす方向 | 依存を固定する方向 |
|---|---|---|
| 成果物 | 生成されたコード、テスト、文書を自由な条件で共同体へ渡す。 | 成果物自体を特定サービスでしか利用できない形にする。 |
| 知識 | 仕様、設計理由、変更手順を公開リポジトリへ残す。 | 重要な判断を非公開の AI 対話にだけ残す。 |
| 保守 | 人間や別の AI でも変更できる状態を維持する。 | 同一サービスでなければ実質的に変更できない運用にする。 |
| 移行 | モデルやサービスを交換できる入力形式と手順を保つ。 | 独自機能へ開発工程を深く結合する。 |
| 時間軸 | 非自由な依存を徐々に減らし、自由な代替へ移せる。 | 利用を重ねるほど過去の知識と変更能力が特定事業者へ集中する。 |
この見方なら、非自由な AI の利用を無条件に正当化する必要も、利用した時点で成果物を失格とする必要もない。評価対象は、AI を使ったという過去の事実ではなく、その利用によって利用者と共同体が何を新しく支配できるようになり、何を外部へ依存するようになったかである。
FOSS プロジェクトにとって、AI 利用の受け入れ工程はその差を管理する装置になる。人間による理解を要求し、利用方法を開示し、生成記録を残し、人間未確認の自動貢献を制御することで、AI の生成能力だけを共同体へ取り込み、検証責任と保守能力まで外部へ移さないようにする。非自由な AI を使うかどうかという一項目より、この工程が実際に機能しているかの方が、自由な成果物を長期に維持できるかを左右する。
10. 「AI を使ったか」ではなく、利用者へどの自由を渡せているかを見る
10.1 AI 時代の自由を一つの点数にしない
ここまで見てきた論点を一つの「自由度」にまとめると、性質の違う制約が見えなくなる。自由ソフトウェアとして最初に判定すべきなのは、利用者がプログラムを実行し、研究し、変更し、再配布できるかという四つの自由である。しかし AI が開発工程へ深く入ると、その自由を実際に行使し続けるための条件がソースコードの外側へ広がる。元の開発者が何を変更していたのか、設計知識がどこに残っているのか、特定 AI がなくても保守できるのか、モデルそのものを置き換えられるのかという問いが加わる。
このとき、「自由ソフトウェアかどうか」という定義上の判定と、「その自由を共同体が現実に維持できるか」という運用上の評価を分ける必要がある。GPL で公開され、Corresponding Source も提供されているプログラムは、AI を使って開発されたという理由だけで自由ソフトウェアではなくなるわけではない。一方、そのプロジェクトの設計、実装、保守が特定企業の AI サービスなしでは続けられないなら、法的な変更自由を保持したまま、実際の開発能力だけが外部へ移っている状態が成立する。
逆方向の例もある。自由に利用・変更できるモデルを使って開発していても、生成された大量のコードを誰も理解せず、テストも設計判断も十分に残していなければ、共同体の保守能力は弱くなる。ここではモデルの自由度は高くても、成果コードを将来変更するための知識が不足している。どれか一つの属性を高くすれば全体の自由が自動的に高くなるわけではない。
| 評価軸 | 中心となる確認 | 満たされている状態 | AI 利用時の典型的な失敗 |
|---|---|---|---|
| 法的自由 | 実行、研究、変更、再配布の権利が利用者へ与えられているかを確認する。 | 自由なライセンスによって、利用者自身が変更版を作り共有できる。 | コードが閲覧可能でも、ライセンスが改変や再配布を制限する。 |
| 変更形式へのアクセス | 元の開発者が変更に使うソース、仕様、テスト、指示を取得できるかを確認する。 | 別の開発者が、元の開発工程で使われた主要な入力を引き継げる。 | 完成コードだけ公開され、仕様や恒久的なエージェント指示が非公開になる。 |
| 開発手段の支配 | 特定の外部サービスなしでも変更を継続できるかを確認する。 | 人間、別モデル、別ツールへ切り替えても保守を続けられる。 | 設計と保守が一社の AI サービスへ固定される。 |
| 理解・保守能力 | 保守者が変更内容、設計理由、影響範囲を説明できるかを確認する。 | 知識が人間、文書、テスト、レビュー履歴として共同体へ残る。 | AI が生成した大規模変更を誰も十分に理解せず、次の解析も AI に依存する。 |
| モデルの自由 | AI が不可欠なら、コード、重み、学習情報をどこまで利用・変更できるかを確認する。 | AI 自体を研究、変更、自己運用し、別用途へ適応できる余地がある。 | 自由な成果物の開発能力が、利用者の支配できないモデルへ依存する。 |
| データへのアクセス | モデルを研究・変更するために必要な学習データまたは Data Information が得られるかを確認する。 | データ構成を調べ、別データによる変更や再学習を検討できる。 | モデルの挙動を形成したデータの範囲や処理方法が分からない。 |
| 再現可能性 | 同じ入力、環境、手順から成果や変更工程を検証できるかを確認する。 | 第三者が公開情報から開発経路を再構成しやすい。 | モデル更新や非公開文脈によって、過去の変更経路を追えなくなる。 |
| 由来情報 | 入力、モデル、生成物、人間の修正、ライセンスを追跡できるかを確認する。 | 後からライセンスや不具合の疑義が生じても調査対象を特定できる。 | 第三者コードとの関係や生成条件を後から確認できない。 |
| 持続可能性 | モデルや事業者が消えてもプロジェクトを引き継げるかを確認する。 | ソース、知識、手順が共同体側へ残り、別の手段で開発できる。 | ソースは残るが、実質的な変更能力だけが失われる。 |
| 現実的アクセス | 計算資源、費用、技能の制約がどこにあるかを確認する。 | 与えられた権利と技術情報を実際の変更作業として行使できる。 | 法的には自由でも、大規模な再学習や運用を一部組織しか実行できない。 |
この表は、十項目をすべて自由ソフトウェアの定義へ追加するためのものではない。四つの自由という定義上の条件と、その自由を実際に行使するための周辺条件を切り分けるためのものである。法的自由が失われているなら、そもそも自由ソフトウェアとしての条件を満たさない。一方、法的自由を満たしていても、開発知識、代替手段、由来情報が不足していれば、その自由を共同体が長期に行使する能力は弱くなる。
AI によって新しく生じる特徴は、この二つの層を分離しやすくすることである。ソースコードは完全に自由な条件で公開できる一方、そのコードを効率よく理解し変更するための能力を 非自由な AI へ依存させることができる。従来ならソースコードの公開によって利用者へ渡せていたものの一部が、AI のモデル、入力文脈、対話履歴、サービス固有機能へ分散するためである。
| 状態 | 法的な変更自由 | 実際の開発能力 | 意味 |
|---|---|---|---|
| コードも開発系も自由 | 利用者が変更版を作り共有できる。 | 共同体自身が開発手段も支配できる。 | 法的自由と実際の変更能力が同じ側に残っている。 |
| コードは自由、AI は交換可能 | 利用者が変更版を作り共有できる。 | AI を失っても速度を落として開発を継続できる。 | AI は効率を高める補助手段に近い。 |
| コードは自由、特定 AI が不可欠 | 利用者が変更する権利は残る。 | 元の開発能力を再現するには外部サービスが必要になる。 | 法的自由と開発能力が分離している。 |
| コードも AI も非自由 | 変更や再配布自体が制限され得る。 | 開発手段もサービス提供者へ依存する。 | 成果物と開発系の双方で利用者の支配が制限される。 |
AI 時代の自由を一つの点数にしない理由は、この組み合わせを区別するためである。「AI を使ったので自由度が低い」「重みが公開されているので自由度が高い」という一行の評価では、成果物、開発系、モデル、データのどこに制約があるのかを説明できない。利用者へ何が渡され、何が外部に残っているのかを軸ごとに見る方が、自由の不足箇所を具体的に示せる。
10.2 AI モデルの自由については、まだ定義競争の途中にある
AI モデル自身をどこまで自由にする必要があるかについて、FOSS 関係組織の答えは一つに定まっていない。FSF は 2025 年 2 月時点で自由な機械学習アプリケーションの基準を策定中であり、学習データまで自由の対象へ含める方向を示している。OSI は Open Source AI Definition 1.0 を正式に公開し、学習コード、モデルパラメータ、共有可能なデータ、Data Information を組み合わせて、第三者が意味のある変更を行える条件を定義している。SFC は、OSI の学習データ要件では公衆による再現可能性が不足すると批判し、より広い学習工程の自由を理想として掲げている。
この違いは、「AI を open ソースと呼べる最低条件」をめぐる名称争いだけではない。各組織が、利用者にどの能力まで保証しようとしているかが違う。既存のモデルを自分の環境で実行できればよいのか、重みを変更できる必要があるのか、別データで追加学習できる必要があるのか、元の学習過程そのものを再構築できる必要があるのかによって、必要な構成要素が変わる。
| 利用者に求める能力 | 主に必要となるもの | 不足した場合 |
|---|---|---|
| 既存モデルを利用する | モデルへのアクセスと実行環境が必要になる。 | API など事業者が提供する範囲でしか利用できない。 |
| モデルを自分で運用する | 重み、推論コード、必要なモデル情報が必要になる。 | サービス終了や利用規約変更から独立できない。 |
| モデルを変更する | 重み、学習・追加学習コード、モデル構造などが必要になる。 | 既存モデルを使えても、自分の目的に合わせて十分に変更できない。 |
| データを変えて再学習する | 学習コード、学習設定、データまたは十分な Data Information が必要になる。 | 元モデルの形成過程を調べたり、別条件で作り直したりする能力が制限される。 |
| 元の生産過程を再構築する | 完全な学習入力、設定、コード、モデル構造、十分な計算資源が必要になる。 | 完成したモデルは変更できても、同じ開発過程を公衆が再現できない。 |
OSI が Data Information で一定の非公開データを扱える設計を採る一方、FSF や SFC が学習データそのものへより強い自由を要求するのは、どの能力を必須とみなすかが異なるためである。第三者が意味のある fork を作れることを重視するなら、元データを完全に複製できなくても変更可能性を認める余地がある。元の学習工程を公衆が調査し再構築できることまで重視するなら、Data Information だけでは不足する。
この不一致を「まだ定義が決まっていないから何も言えない」と処理する必要はない。むしろ、自由な AI という言葉を使うときに、どの能力まで意味しているのかを明示する必要があることを示している。重みが取得できること、自由に再配布できること、学習コードがあること、学習データがあること、元モデルを再現できることは別々の条件である。
自由ソフトウェア開発との関係では、すべてのプロジェクトが最も厳しい AI 自由の基準を満たさなければならないという結論にはならない。AI を局所的な補完に使い、成果コードを人間が通常の方法で保守できるプロジェクトと、モデルが設計、実装、保守を継続的に担い、その AI がなければ開発できないプロジェクトでは必要な代替可能性が違う。AI が開発能力の中心へ近づくほど、その AI 自体を利用者がどこまで支配できるかという問いの重みが増す。
| AI の位置 | AI 自体の自由が成果物へ与える影響 | 主な確認事項 |
|---|---|---|
| 一時的な補完 | 成果コードを人間が保守できれば直接的な影響は限定される。 | 生成物の由来、権利、人間による確認を中心に見る。 |
| 継続的な実装補助 | AI の利用不能によって開発速度へ大きな影響が出る。 | 別モデルや人間へ置き換えられるかを確認する。 |
| 設計・変更主体 | モデルの能力がソフトウェアの変更能力へ直接組み込まれる。 | モデル、指示、設計知識を共同体側へどこまで残せるかを確認する。 |
| 不可欠な保守基盤 | AI 自体の支配可能性が、自由な成果コードを将来変更できるかに直結する。 | 自己運用、変更、代替、サービス終了後の継続可能性まで確認する。 |
自由な AI の定義をめぐる論争が自由ソフトウェア開発に関係するのは、名称を統一するためではない。AI が変更能力を担うほど、その AI について利用者にどの能力を渡すべきかという論争が、そのまま自由なソフトウェアを誰が将来変更できるのかという問題になるためである。
10.3 自由ソフトウェアの中心は、コードという物体ではなく利用者による支配にある
ここまでの議論をたどると、AI が自由ソフトウェアへ持ち込んだのは、まったく新しい自由の原則ではない。GNU の自由ソフトウェア定義は、ソースコードを公開すること自体を最終目的としているのではなく、利用者がプログラムを実行し、研究し、変更し、共有することで、そのプログラムと自分の計算を支配できることを中心に置いている[2]。ソースコードへのアクセスが必要なのは、この支配を実際に行使するためである。
人間がソースコードを直接編集していた開発では、この目的を支える主要な情報がコードへ集まりやすかった。開発者が変更したものをそのまま公開すれば、第三者も同じ対象を編集できた。ビルドスクリプト、設定、テストなど周辺情報は必要だったが、「プログラムを変更するために好ましい形式」とソースコードの対応は比較的分かりやすかった。
AI エージェントが要求とコードの間へ入ると、この対応が崩れる。人間が要求仕様を変え、テストを変え、恒久的なエージェント指示を変え、AI が複数ファイルを更新する場合、実際の変更工程はソースコードだけでは表せない。さらに AI が設計理由や変更箇所まで決めれば、必要な知識が対話履歴へ移る。その AI が外部サービスであれば、変更を実行する計算能力まで事業者の側へ置かれる。
モデル自体を共同体へ取り戻そうとすると、さらに構成要素が増える。重みだけでは学習過程を完全には調べられず、学習コードだけでは元モデルを再構築できず、学習データがあっても十分な計算資源がなければ再学習できない。AI では、従来ソースコードが一つの形式としてまとめて支えていた変更能力が、モデル、データ、コード、設定、計算資源へ分散する。
| 開発段階 | 利用者が支配する必要がある主な対象 | 外部へ移ると失われる能力 |
|---|---|---|
| 通常のソフトウェア利用 | 実行プログラムと利用条件を確認する。 | 任意の目的で実行する自由が制限される。 |
| 通常のソフトウェア変更 | ソースコード、設定、ビルド手順を取得する。 | プログラムを自分で研究・変更する能力が失われる。 |
| AI 支援開発 | ソースに加えて仕様、テスト、エージェント指示、生成記録を確認する。 | 元の開発者が使っていた変更方法を引き継げなくなる。 |
| AI 主体の開発 | モデル、開発文脈、設計知識、代替手段まで確認する。 | コードは自由でも、設計・保守能力が特定サービスへ移る。 |
| AI 自体の変更 | 重み、学習コード、データ情報、学習設定、必要な資源を確認する。 | 開発能力を担う AI 自体を利用者が研究・変更できなくなる。 |
既稿「AI を一つの物語に閉じ込めない」では、AI を一つの属性として評価せず、どの判断へ入り、どの責任を変え、どこで人間の判断へ戻すのかを分けて考えた[23]。自由ソフトウェアについても同じ方法が必要になる。「AI を使った」という事実から自由が増えたとも減ったとも判断できない。AI がどの工程に入り、その結果として利用者が何を新たに支配できるようになり、何を外部へ依存するようになったのかを分けなければならない。
たとえば 非自由な AI を使って自由なソフトウェアを生成しても、人間がコードを理解し、仕様、テスト、設計知識を公開し、別の手段で保守できるなら、成果物の自由を共同体へ残すことはできる。逆に、自由なライセンスのコードを公開していても、設計判断と変更手順が特定 AI の内部へ集中し、その AI がなくなれば誰も保守できないなら、法的な変更自由と実際の変更能力の間には大きな距離が生じる。
この距離が、AI 時代に新しく可視化される自由ソフトウェアの弱点である。従来も、ソースを公開しただけで誰も保守できないプロジェクトや、特殊な環境へ依存する自由ソフトウェアは存在した。AI は、その依存を設計理解や変更判断という知的工程まで拡張できる。しかもコードそのものは完全に自由な条件で公開したまま、その状態を作ることができる。
| 問い | 表面的な判定 | AI 時代に追加して確認すること |
|---|---|---|
| 自由なライセンスか | 利用者に四つの自由を与えているかを見る。 | その自由を行使するための変更形式と知識が利用者側へ残っているかを確認する。 |
| ソースが公開されているか | ソースコードを取得できるかを見る。 | 元の開発者が実際に変更していた仕様、指示、テストも取得できるかを確認する。 |
| AI が使われたか | 制作工程の一事実を確認する。 | AI が補助なのか、設計・保守に不可欠な開発系なのかを確認する。 |
| モデルが公開されているか | 重みやコードを取得できるかを見る。 | 利用者がどこまで研究、変更、再学習、自己運用できるかを確認する。 |
| 同じ結果を再現できるか | 生成物やビルドを再現できるかを見る。 | 同じ結果でなくても、第三者が変更工程を再構成して別の変更版を作れるかを確認する。 |
この整理に立てば、「自由ソフトウェアを作るとき 非自由な AI を使ってよいのか」という最初の問いにも、一語で答える必要がなくなる。非自由な AI を使ったという制作履歴だけでは成果コードの自由は決まらない。しかし、その AI が将来の変更にも不可欠であり、開発知識も代替手段も共同体へ残っていないなら、成果コードが自由であっても、利用者がその自由を実際に行使し続ける条件は弱くなっている。
反対に、AI の利用を全面的に避ければ自由が自動的に高まるわけでもない。非 AI の 非自由な道具 へ依存することもできるし、人間だけで書いたコードを非自由な条件で配布することもできる。自由ソフトウェアが問うてきたのは制作方法の純粋さではなく、最終的に利用者が何を支配できるかである。
自由ソフトウェアの中心命題を AI 時代に置き直すなら、「AI を使ったか」ではなく、「利用者へ何を渡したか」となる。実行する権利だけなのか。ソースコードまで渡したのか。変更に使う仕様とテストも渡したのか。AI がなくても保守できる知識を残したのか。AI 自体が不可欠なら、それを研究し変更する能力まで利用者へ渡したのか。問いをこの順に進めれば、自由の不足している場所を具体的に特定できる。
AI がソフトウェア開発の中心へ近づくほど、自由を測る対象はコードという成果物から、そのコードを将来作り変える能力へ広がる。これは自由ソフトウェアの原則を別物へ変更することではない。利用者が自分の計算を支配するという既存の原則を、AI が入り込んだ開発工程の上流まで追いかけた結果である。
参考文献
- id774, 「AI を使ったから駄目」を分解する（2026-08-19）. https://blog.id774.net/entry/2026/08/19/5526/
- GNU Project, What is Free Software? https://www.gnu.org/philosophy/free-sw.en.html
- Bradley M. Kühn, Ethical and Moral Considerations in Proprietary Software Usage（2026-06-02）. https://sfconservancy.org/blog/2026/jun/02/ethical-use-proprietary-develop-free-software-foss/
- GNU Project, Free System Distribution Guidelines (GNU FSDG). https://www.gnu.org/distros/free-system-distribution-guidelines.en.html
- Richard Stallman, Who Does That Server Really Serve? https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
- GNU Project, The GNU General Public License v3.0（2007-06-29）. https://www.gnu.org/licenses/gpl.en.html
- Software Freedom Conservancy, Recommendations When Using LLM-backed Generative AI Systems for FOSS Contributions（2026-06-18）. https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
- Free Software Foundation, FSF is working on freedom in machine learning applications（2024-10-22）. https://www.fsf.org/news/fsf-is-working-on-freedom-in-machine-learning-applications
- Free Software Foundation, FSF talked about education, copyright management, and free machine learning at FOSDEM 2025（2025-02-11）. https://www.fsf.org/blogs/licensing/fsf-at-fosdem-2025
- Open Source Initiative, The Open Source AI Definition – 1.0（2024-10-28）. https://opensource.org/ai/open-ソース-ai-definition
- Open Source Initiative, OSAID FAQs. https://opensource.org/ai/faq
- Software Freedom Conservancy, SFC Announces Aspirational Statement on LLM-backed generative AI for Programming（2024-10-25）. https://sfconservancy.org/news/2024/oct/25/aspirational-on-llm-generative-ai-programming/
- Bradley M. Kühn, Open Source AI Definition Erodes the Meaning of “Open Source”（2024-10-31）. https://sfconservancy.org/blog/2024/oct/31/open-ソース-ai-definition-osaid-erodes-foss/
- Krzysztof Siewicz, The FSF doesn’t usually sue for copyright infringement, but when we do, we settle for freedom（2026-03-13）. https://www.fsf.org/blogs/licensing/2026-anthropic-settlement
- Reproducible Builds, Definitions. https://再現可能-builds.org/docs/definition/
- U.S. Copyright Office, Copyright Office Releases Part 2 of Artificial Intelligence Report（2025-01-29）. https://www.copyright.gov/newsnet/2025/1060.html
- U.S. Copyright Office, Artificial Intelligence Study. https://www.copyright.gov/policy/artificial-intelligence/
- Software Heritage, SoftWare Heritage persistent IDentifiers (SWHIDs). https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
- SPDX, SPDX Specification 3.0.1: Conformance. https://spdx.github.io/spdx-spec/v3.0.1/conformance/
- SPDX, AIPackage – SPDX Specification 3.0.1. https://spdx.github.io/spdx-spec/v3.0.1/model/AI/Classes/AIPackage/
- Bradley M. Kühn, If Software is My Copilot, Who Programmed My Software?（2022-02-03）. https://sfconservancy.org/blog/2022/feb/03/github-copilot-copyleft-gpl/
- id774, この物量の文章を、一体誰が検証できるのか（2026-07-30）. https://blog.id774.net/entry/2026/07/30/5160/
- id774, AI を一つの物語に閉じ込めない（2026-08-09）. https://blog.id774.net/entry/2026/08/09/4974/