「AIは、ある気まずい疑問を投げかける。『この部屋はどれくらいきれいなのか？』」
AIツールは、開発者が既存のソフトウェアの機能を再現するのに役立ちます。しかし、代替手段を構築することと、他人の作品をコピーすることの間には、重要な違いがあります。
ある開発者が最近、Photoshopの代替となる「雰囲気重視」のソフトに2万人のユーザーを集めたと主張したことが、興味深い疑問を投げかけている。もしAIが誰かが競合製品を開発するのを支援できるとしたら、元のソフトウェアの所有者は不満を述べる正当な理由があるのだろうか？
直感的には、既存の製品を再現することは、その著作権を侵害することになるだろうと思われるかもしれません。何しろ、元の開発者はその開発に何年も費やしてきたかもしれませんから。しかし、著作権は、ソフトウェア企業に対して、その製品の機能に対する独占権を与えるものではありません。機能の複製と、その機能の表現の複製との区別については、AIコーディングツールが登場するはるか以前から、裁判所で争われてきました。
結果は同じでも、ソフトウェアは異なる
写真編集ソフトを例に考えてみましょう。開発者は、ユーザーに画像のトリミングや色の調整、レイヤーの操作を行ってもらいたいと考えるかもしれません。こうした要件は「機能」を表しています。それを実現するために書かれるコードは、また別のものです。
この区別は、ソフトウェアの著作権において極めて重要なものです。ソースコードやオブジェクトコードは保護の対象となりますが、プログラムの根底にあるアイデアや原理そのものは保護されません。したがって、競合するプログラムが、単に同じ入力を受け入れたり、同じ結果を出力したりするからといって、必ずしも著作権侵害となるわけではありません。
英国の裁判所は、Navitaire v easyJet [2004] EWHC 1725 (Ch) 事件においてこの問題を取り上げた。この事件では、既存のシステムのソースコードにアクセスすることなく、その動作とほぼ同様の機能を果たすよう意図的に開発された代替の航空券予約システムが問題となった。裁判所は、その機能的挙動を再現したことが著作権を侵害するという主たる主張を退けた。しかし重要なことに、グラフィカルな画面やアイコンに関する一部の主張については認められた。機能性とアートワークについては、それぞれ異なる判断が必要であったのである。
代替ソフトウェアを開発する者にとって、これは有用な出発点となる。つまり、製品の機能を再現することと、ユーザーに表示されるすべてのものを複製する許可を得ることとは、同じではないのだ。
クリーンルームの導入には、どのような特徴があるのでしょうか？
クリーンルーム方式は、こうした区別を明確にするように設計されています。通常、あるチームが既存のソフトウェアを調査し、その機能的な挙動を記述した仕様書を作成します。そして、元のコードを見たことのない別のチームが、その仕様書に基づいて新しい実装を記述します。このプロセスの記録は、独立した開発が行われたことを示す証拠となります。
これは、元の著作権を消滅させる手段ではありません。また、「クリーンルーム」という用語は、有利な結果を保証する法的概念でもありません。その価値は、新製品が保護対象となる表現ではなく、保護対象外の機能を再現していることを示す点にあります。
AIは、ある気まずい疑問を投げかけます。「この部屋はどれくらいきれいなのか？」
空のリポジトリから始めることが、必ずしもこの疑問に答えるとは限りません。コーディングツールに提供された資料も、ツールが取得したソース資料と同様に重要です。また、トレーニング中にモデルが関連するコードに遭遇したかどうかという疑問も生じ得ます。これらの疑問は侵害を立証するものではありませんが、「AIが一から書いた」という単純な主張を、一見したほどには安心できるものではないことを示唆しています。
したがって、開発者は、AIに機能仕様の実装を依頼することと、既存のコードベースの書き換えを依頼することとを区別すべきである。この2つの作業は、互いに置き換え可能であるかのように扱うべきではない。
欧州法
最も関連性の高い判決の一つは、SAS Institute 対 World Programming 事件（C‑406/10）である。競合ソフトウェアは、元のシステムと同じ言語で記述されたプログラムを実行し、同じ出力を生成することを目的としていた。その開発者は元の製品を調査したが、元のソースコードにアクセスしたり、それを複製したりしたことを示唆する証拠はなかった。
C-406/10事件において、欧州連合司法裁判所は、プログラムの機能、プログラミング言語、および関連するデータファイル形式は、ソフトウェア指令に基づくコンピュータプログラムの著作権によって保護される表現形態には該当しないと判示した。この区別により、最初の開発者が基礎となるアイデアを独占的に支配することなく、互換性のあるソフトウェアを開発する能力が維持された。
その後の英国での上訴事件である「SAS Institute 対 World Programming」[2013] EWCA Civ 1482 において、機能的な再実装を認めるという判決が支持された。しかし、マニュアル間の複製に関する限定的な侵害認定は残された。ドキュメントから製品を理解することと、そのドキュメントから保護された表現を複製することは別問題である。
写真編集ソフトを例に挙げると、これは有用な例えとなります。既存のファイル形式に対応するための独立したコードを書くことは、必ずしも元のプログラムをコピーすることと同じではありません。しかし、だからといって、その形式に関連するコード、ドキュメント、その他の保護対象となる資料を、単に流用してよいということにはなりません。
APIをめぐる議論では、Googleが勝ったんじゃないの？
米国裁判所におけるグーグルとオラクルとの長年にわたる係争は、アプリケーション・プログラミング・インターフェース（API）が著作権によって保護されないことを確立した事例としてしばしば挙げられる。しかし、米国最高裁が最終的に下した判断は、そのようなものではなかった。
API を利用することで、プログラマーは、基盤となる実装を自ら記述することなく、関数を呼び出すことができます。Android の開発において、Google は独自の実装コードを記述しましたが、Java プラットフォームから約 11,500 行の宣言コードとそれに関連する構成構造を流用したため、プログラマーは慣れ親しんだコマンドを使用できるようになりました。
下級審で相反する判決が出た後、最高裁は2021年4月、「Google対Oracle」事件において、当該の複製行為はフェアユースに該当すると判断した（概要はこちら）。重要な点として、同裁判所は、当該素材が著作権の対象となるかどうかを判断するのではなく、本件を裁決する目的において、著作権保護が存在すると仮定した。
したがって、この判決は、APIの複製が普遍的に自由であることを定めたものではない。また、この判決における米国のフェアユースに関する論拠を、ソフトウェアの著作権の範囲を争点とし、プログラムの研究を認めた欧州の「SAS Institute 対 World Programming」事件におけるアプローチと混同してはならない。これらの判例は、互換性や再実装を支持するものであるが、その法的根拠は異なる。
新しい規定では、この問題は解決されない
開発者は、元のコードをコピーせずに、そのインターフェースを非常に忠実に再現することもあるだろう。それによって、別の問題が生じる。
「Bezpečnostní softwarová asociace」事件（C‑393/09）において、欧州司法裁判所は、グラフィカル・ユーザー・インターフェースは、ソフトウェア指令の下ではコンピュータプログラムの表現として保護されないとの判断を示した。とはいえ、インターフェースが著作者自身の知的創作物である場合には、それ自体が著作権保護の対象となり得る。技術的な機能のみによって決定される構成要素は、その独創性の要件を満たさない。
AIによるコード生成型写真編集ツールに当てはめると、その区別は、使い慣れた編集機能を提供することと、オリジナルのグラフィックやその他の保護されたインターフェース表現を再現することとの間にある。画像から画面を再現するようコーディングツールに指示する場合、生成されたコードが新規であるという理由だけで、それが安全であると安易に想定すべきではない。これが、インターフェースを、それを実装するプログラムとは別個に扱うことによる実務上の意味合いである。
開発者やソフトウェア企業は、どうすべきでしょうか？
開発者の皆様には、実装を生成する前に必要な機能を明確に定義することをお勧めします。仕様書、プロンプト、および使用した参考資料を記録に残し、生成されたコードとビジュアルアセットを別々に検証してください。「AI生成」や「一から作成」といった説明に頼るよりも、文書化された開発プロセスの方が有用です。
確立されたソフトウェア企業にとって、これらの事例は、著作権のみに依存することの限界も浮き彫りにしている。著作権は、価値のあるコード、グラフィック、ドキュメントを保護することはできるが、競合他社が独自に同じ機能を実装することを必ずしも阻止できるわけではない。特許、営業秘密、契約上の制限など、その他の権利や義務については、別途検討する必要がある。
バイブコーディングにおける最近の進展は、その議論のきっかけとなるはずだ。
核心となる疑問は、依然としておなじみのものです。すなわち、開発者は同じことを行うための別の方法を考案したのか、それとも他者の保護された著作物を複製したのか、ということです。AIによってソフトウェアの構築方法は変わるかもしれませんが、「AIが書いた」というだけでは、この疑問に対する答えの代わりにはなりません。
競合する、あるいは互換性のあるソフトウェア製品を開発している場合、あるいは他社の製品が自社の製品を模倣しているのではないかと懸念がある場合は、普段お取引のあるバーカー・ブレテル法律事務所の弁護士にご連絡の上、知的財産権に関する問題についてご相談ください。
