GitHub Copilotが登場した頃、多くの開発者はコーディングの補助ツールと捉えていた。「役に立つのは分かるが、コーディングの全てを任せるようなツールではない」というのが多くの開発者の素直な感想だっただろう。しかし、この2025年においては、「バイブコーディング」という用語が急激に一般化し、多くの開発者が様々なAIコーディングツールを併用して、より多くの作業をAIツールに頼るようになっている。コーディングのみならず、開発プロセスにおけるほとんどの工程をAIを頼る傾向は今後さらに高まることは間違いないだろう。 ここで多くの開発者が気にするのは開発(生成)されたコードの著作権であろう。ソースコードの権利を制御するのは基本的に著作権だと考えられているが、「AI生成によるコードには著作権が発生しない」という話を耳にした開発者も多いと思う。そうであれば、「自分がAIツールに作成を指示したコードには著作権が全く発生しないのではないか？」と疑問を持つのが一般的な感覚であろう。一方で「AI生成物の権利は全て指示者にある」という感覚を持つ者もおり、この両極端な捉え方が特にネット上において諍いの種の一つにもなっているようにも見える。 そこで本稿では、プログラム著作物に特化して、AIツールを利用して開発を行ったソースコードがどのような場合に著作物性(著作権保護に値する創作性)が発生するのかという疑問に対して、日本法ならびに米国法の両面から詳細に解説する。さらに、実際のソフトウェア開発の現場(クローズドな商用開発)やオープンソース開発の実務において、開発者がどのように対処すべきかについても簡単に触れることにする。 1. 日本法におけるAI生成コードの著作物性 1. AI生成物の著作物性 2. プログラム著作物特有の事情 3. ケース別の著作物性有無の境界線 1. 明らかに著作物性が認められないと考えられるケース 2. 著作物性が認められる可能性がある境界的なケース 2. 米国法におけるAI生成コードの著作物性 1. AI生成物の著作物性 2. プログラム著作物特有の事情 3. ケース別の著作物性の有無の境界線 3. クローズドな商業的ソフトウェア開発における実務 4. オープンソース開発における注意点 5. 余談 6. 参考 * * * ## 日本法におけるAI生成コードの著作物性 まず、日本法においてAIツールを利用してコードを生成した場合、そのコードに著作物性が認められるのはどのような場合であるか、基本的な考え方を整理する。 ### AI生成物の著作物性 日本の著作権法上、著作物とは**「思想又は感情を創作的に表現したもの」**(著作権法2条1項1号)をいう。この定義に照らせば、AIが生成したコードであっても人間による創作的表現が認められる場合には著作物となり得る。しかし反対に、人間の関与なしに自律的に生成されたコードには著作物性が認められない可能性が高い。文化庁のガイドラインとなる「AIと著作権に関する考え方」(令和6年3月公表)でも、生成AIに対する**人間の指示が表現に至らないアイデア止まりであるような場合には、当該AI生成物に著作物性は認められない** と整理されている。例えば、「◯◯な機能を実装せよ」といった抽象的な指示だけでは、生成されたコードに著作権は発生しないと考えられる。 もっとも、日本においてはAIを創作のための道具として用い、人間が創作へ関与した部分については著作物性を個々のケースにおいて判断することになるというのが文化庁の「考え方」による立場であろう。AI生成物の著作物性は個別かつ具体的に判断することになり、単なる作業量のようなものではなく、生成指示者に「何かを表現しよう」という主体的な創作意図が存在するかという点を前提として、**人間がAIに対して単なるアイデアの提示に留まらない具体的な表現に至るまでの工夫としての創作的寄与が積み重ねられているか** で総合的に判断されると考えられる。 ここで重要なのは特にネット上で流布される「道具として用いる」をクリアすればAI出力に著作物性が認められるという単純な話ではなく、最終的な結果物に対して人間の創作的寄与が含まれているのであればAIを道具として用いているとみなせるということである。繰り返すが、肝心なのは結果物に対して人間による創作性が生じているかどうかである。 AIを利用して作成された作品が著作物と言えるかどうかは、文化庁の「考え方」で示されている内容に若干の私見を加えていくと、以下のように人間による「創作的寄与」の有無を総合的に考慮して判断することになると考えられる。 * **A. 指示(プロンプト等)の具体性：** * ユーザーがAIに対して出す指示内容が、作品の表現内容に踏み込んで具体的であればあるほど人間の創作的寄与があったと評価されやすくなるが、その反対に、どれだけ長い指示を書いても表現に至らない抽象的アイデアの提示に留まるような内容では、創作的寄与とは認められない。例えば「面白いものを作って」といった漠然とした依頼や、機能的な要件を箇条書きしただけのプロンプトでは人間の具体的な表現による寄与があったとは言えないと考えられる。 * **B. 生成過程での試行錯誤(フィードバックと修正)：** * AIに何度も生成を繰り返させた回数そのものは、創作的寄与の有無に直接影響しない。しかしながら、出力結果を都度確認し、それに応じて指示内容を修正しつつ再生成を繰り返すといったプロセスを経ている場合には注意が必要となる。このような試行錯誤のプロセスにおいて、ユーザーの創作上の判断や工夫が反映されている可能性が考えられ、結果として得られたAI生成物に対して人間の著作物性が認められる可能性がある。 * **C. 複数生成結果からの選択：** * AIが一度に多数のバリエーションを出力し、その中から指示者が単に選択していくだけでは、その選択結果には創作的寄与とは言えない。これは、選択行為そのものは機械的な判断に留まりがちであり、創作的表現の産物とはみなされにくいからである。しかし、選択が関わる場面で編集・構成など他の創作行為と結び付いている場合には考慮の余地が生じると考えられる。指示者が何らかの意図をもって選択し、それらの組み合わせによって一つの作品となるような場合に人間の創作的寄与の要素の一つになり得ると考えられる。 * **D. 人間による加筆・修正：** * AIの出力に対して人間が創作的表現と言える修正や加筆を行った部分については、通常その部分に対しては人間の著作物性が認められる。AI出力そのものが人間の創作性を欠くとしても、人間による修正部分の著作物性が失われるわけではなく、修正後の結果物には総体として人間の著作権が含まれる。ただし、この場合は保護され得るのは人間が創作した部分に限られる。 以上の文化庁の「考え方」から援用したポイントを踏まえると、著作物と認められるか否かの事実上の条件は「人間の創作的寄与」があったかどうかに尽きる。人の関与がない純粋な自律生成部分については現時点の議論において著作物性が否定される可能性が高く、やはり人間による独自の創作的な表現がAI生成物へ反映された場合に著作物性が生じることになる。総じて、日本法におけるAI生成コードの著作物性は一律に判断されるものではなく、ケースバイケースで上記のような要素の積み重ねを精査した上で、人間による創作性が発揮されているかどうかで判断されるのが基本的な考え方と言えるだろう。 ### プログラム著作物特有の事情 次に、ソースコード(プログラム)特有の著作物性判断の事情を確認する。日本の著作権法では、著作物を「思想又は感情を創作的に表現したもの」と定義しているが、プログラム著作物においてもこの要件を満たす場合に著作物として保護対象となるのは同一である。他方で、プログラムのアイデアと表現の区別が条文上で明確に規定されており、著作権法10条3項では**プログラム言語(プログラムを記述する記号や体系)、規約(記法上の取り決め)及び解法(アルゴリズム)については「その著作物を作成するために用いるもの」に過ぎず、著作権保護の対象には及ばない** と規定されている。つまり、プログラムにおいて創作的な「表現」と認められる部分のみが著作権で保護され、処理手順、アルゴリズム、入出力仕様、フレームワークの設計思想などは、たとえ創意工夫があったとしてもアイデア・表現二分論によりそのままでは著作権保護の対象にはならない。 この点に関し、ソフトウェアの創作性が争点となった**システムサイエンス事件**(東京高裁平成元年6月20日決定)は重要なリーディングケースとなっている。同事件で東京高裁は、プログラムはそれを表現する記号が極めて限定され文法も厳格であるため、コンピュータをより効率的に機能させようとすれば指令の組合せが必然的に類似してしまう部分が少なくない、と指摘した。従って、プログラム著作物における著作権侵害の判断は慎重になされるべきであるとも判示されている。この趣旨は、プログラムの表現は本質的に制約が多く、**「効率性・互換性の要請など外部要因によりほぼ一通りに定まる」ありふれた表現や「必要不可欠な表現」の類似は直ちに著作権侵害につながるものではない** ことを示したものといえる。 その後の裁判例では、プログラムの創作性についてさらに踏み込んだ基準が示されている。とりわけ**電車線設計用プログラム事件**(東京地裁平成15年1月31日判決)は、プログラムの具体的記述が創作的表現といえるかどうかを判断するにあたり、次のようなコードは作成者の個性が発揮されておらず創作性が認められないと判断した： * **誰が作成してもほぼ同一** になるようなプログラムの記述 * **簡単な内容を極めて短い表記法** で記述したプログラムの記述 * **極めてありふれた定型的なプログラム** の記述 本事件では、定型的若しくは平凡なコードまで著作物として保護してしまうと、電子計算機の広範な利用や技術の発展を不当に妨げ、結果的にプログラムの機能やアイデアそのものを独占的に保護することになりかねないとも指摘している。要するに、プログラムのソースコードであっても、ありふれた手法の寄せ集めに過ぎない部分には独自性がなく、著作物たりえないという整理である。 さらに、**宇宙開発事業団プログラム事件**(知財高裁平成18年12月26日判決)もこの考え方を明確にしている。本件判決は、法が保護するのはあくまで「表現したもの」であり、思想およびアイデア自体や表現に至る手法は保護されないとの原則を確認した上で、プログラムについて表現上の選択肢が十分にあり、それが凡庸でなく作成者の個性が表れていることが著作物性の要件であると判示している。そして、表現に選択の余地がないか著しく限られる場合には作者の個性が表れる余地もなくなり著作物性が否定されるとも述べている。また、プログラムの指令手順自体も単なるアイデアに過ぎず、それを実現するアルゴリズムも「解法」として著作権の保護対象外であることを改めて明言している。これらの裁判例の積み重ねにより、**プログラムにおける表現の保護範囲は絵画、音楽、映像といった他の伝統的著作物に比べて相当に限定的** であることが司法上も確認されてきていると言えるだろう。 実務的に見ても、プログラム開発の現場では創作性が発揮される余地が限られる場合が多い。効率や機能実現のためにコードの書き方が定型化しやすく、結果として同種のプログラムでは似たような記述が生じるのは避け難い。実際、著作権法が保護し得るプログラム上の表現の範囲は一般に考えられている以上に狭いものとなっているのが実情だろう。 以上のようなプログラム著作物特有の事情を踏まえると、生成AIツールを利用して開発されたソースコードにおいてどのようにすれば著作権が発生し得るのかという観点においては、創作性の判断基準を慎重に適用する必要があるだろう。 なお、生成AI以降における自動的なツールに出力コードの著作物性の問題に注目が集まってきたのは、そもそも生成AI以前のコード補完やコード自動生成ツールは創作性が非常に薄く著作物性がないと考えられるコードを出力し、人間が残りの創作性を発揮しやすい領域を担当していたからである。生成AIツールはコーディングにおいて人間が創作性を発揮してきた領域を自動化してきており、著作権を意識する場合には人間の創作性がどこにあるのかを認識せざるを得なくなっていると言える。 ### ケース別の著作物性有無の境界線 これまでに述べた制約を前提として、どういった場合にAI生成コードに著作物性が認められ、どういった場合に認められないかを具体的なケースに即して考えていく。 #### 明らかに著作物性が認められないと考えられるケース 既にデフォルトの状態でAI出力には著作物性は生じないと書いているが、中でもほぼ著作物性がないと判断できるようなケースは下記のプログラム著作物特有のケースとAI生成出力に特有のケースの二つになるだろう。 * **ごく短い定型コードの自動生成：** 例えば「Hello Worldを表示するコードを書いて」とプロンプトを入れてAIが出力した数行のコードなど、誰が書いても同じになるようなごく短いコード断片は創作性がなく、著作物ではないと判断されるだろう。これは人間の創作的寄与への関与云々以前に表現上の独自性がない典型例となる。 * **抽象的な指示による標準的実装の生成：** 「ソート関数を書いて」「ボタン押下時に現在時刻を表示して」等のアイデアレベルの指示だけをAIに与え、AIが一般的な実装コードを出力した場合、人間が出力の内容の具体的表現には寄与しておらず、また出力されたコードもありふれた標準実装に過ぎないため、著作物性は生じない。 #### 著作物性が認められる可能性がある境界的なケース 前述の状態を踏まえて、文化庁の「考え方」に合わせ、具体的にどのような人間による行為が行われているのであれば著作物性が生じるかという境界線を探ると以下のようになると考えられる。 ##### A. 指示・設計が具体的な「表現」に踏み込む場合： 人間によるAIへのプロンプトや指示の段階で、単なる機能要求に留まらず具体的なコード上の表現まで踏み込んだ指示を行った場合である。 例えば「○○アルゴリズムのこの部分をこういう手法で実装せよ」と細部にわたり指定したり、関数名や変数名、あるいはコメント文に至るまでクリエイティブなアイデアを盛り込んだプロンプトを作成した場合が該当する。文化庁の「考え方」においても、創作的表現と言えるものを具体的に示す詳細な指示は創作的寄与があると評価される可能性を高めるとされている。このような場合、出力されたコードの中にプロンプト作成者である人間の創作的な表現である指示内容が反映されている部分があれば、その部分について著作物性が認められると考えられる。判断にあたっては、平易ではない独自の実装やユニークなコメント表現などの指示者の個性が完成したコード中に表れている箇所があるかを着目することになる。 プロンプトによる指示が「表現」としてソースコード中に痕跡として残ることがポイントと言えるが、著作物性が認められる安全度は概ね次のような順になるのではないかと考える。 * **指示テキストが出力と同一 (高)：** * 関数名や識別子の体系、コメント文、メッセージ文言、ヘッダ書式等を具体的な文言で指示し、そのままAI出力に反映された場合、人の記述が可視化され、著作物性が肯定されやすい。 * **構造や配列を具体的に指定 (中)：** * モジュール分割、クラス/関数の順序、例外の配置、処理の組み合わせ、設定ファイル/ディレクトリの構成等の指定が出力へほぼ追随される場合、構成として表現が定着したとみなしやすい。この場合、典型的な解から外れるほど可能性が高まる。 * **設計意図のみの指定 (低)：** * 「高速」「RESTらしく」等の抽象的要件に指示が留まる場合、実装が定石に収斂しやすく、典型的な解に近い出力となると考えられる。出力がありふれたコードに落ち着けば、アイデアに近いものとして著作物性は弱まる。 要するに、指示において具体的な文言や配置を指定し、AIの出力にそれらが人間の目で分かるような状況であれば著作物性が生じるわけである。 ##### B. 試行錯誤とリファクタリングが「構成上の選択」に結実した場合： AIによるコード生成を一度で終わらせず、何度もプロンプトを試行錯誤し出力を取捨選択あるいは修正しながら最適なコードに仕上げていった場合である。 一度目の出力を見てプロンプトを変え、二度目を出力させ、それらを部分的に組み合わせたり不要な箇所を削除したりする反復作業の過程が、人間の開発者による構成上の創意工夫が最終コードに反映されたと評価できる場合には、そのコード全体もしくは特定の組み合わせ方に著作物性が認められる可能性が生じる。また、最終的なコードだけを見ると凡庸に見えても、実は人間が複数の候補から取捨選択し構成したものであればそこには編集著作物的な創作性が生じ得る。ただしこの場合、自身の創作的関与を後から説明もしくは立証できるように、プロンプトの履歴や出力結果の差分などを記録しておくことが実務上望ましいと考えられる。そうしたログがない場合、第三者から「人間が何も創作していないのではないか？」と疑われたときに反証が難しくなるためである。 ただし、結局のところ試行回数の多寡はノイズに過ぎず、構造的な変化と人の判断の関係性をログやコメント等で可視化できないと、著作物性が否定寄りに評価されがちになるのではないかと考える。 ##### C. 選択・配列・体系化が「通常解」を超えるとき： 生成AIが大量のコードを吐き出し、それらの中から人間が取捨選択して組み合わせた結果、一般的に想定される実装を超える独創的な構成になった場合である。 単に複数の生成結果から一つのコードを「選ぶ」だけでは創作的寄与とは言えないと考えられているが、例えば、各生成結果から一部ずつを取り出してモジュール化し、全体を独自の構成に再構築したような場合には完成したコード全体として編集著作物(素材の選択・配列に創作性がある著作物)たり得るかもしれない。この場合の判断のポイントは、そのコードの構成もしくは体系が他の開発者であれば一般にはしないような非自明的な組み合わせになっているかどうかであるだろう。オープンソースの既存コードを寄せ集めた場合に近いが、AI生成コードの場合も人間がどのように素材としてのコード断片を取捨選択・配置したかによって創作性の有無が決まると考えられる。フレームワークの既定テンプレに沿ってそのまま並べた、あるいはフレームワークによって事実上決定されてしまうような場合には、やはり著作物性は低いと考えられる。 また、このCの形式が開発現場で最も起こり得るパターンであると考えられるが、編集著作物で保護されるのは「選択・配列・体系化という構成の表現」だけであり、AI出力そのままの断片や一般的な処理ロジック自体には及ばないことに注意が必要となる。 ##### D. 既存コードへの加筆・修正で「創作的部分」が追加された場合： 既に自分または自社が権利を有する既存のコードやオープンソースなどの第三者権利のコードに対して、AIツールを利用しつつ新たなコードを付け加えたり書き直したりした場合である。 例えば、既存プロジェクトに新機能を実装する際においてAIツールに補助させてコードを書き足したようなケースでは、追加もしくは変更部分に人間の創作性が存在すればその部分について著作権が発生する。AIの提案をそのままコピペしただけでは創作的寄与はほぼないと考えられるが、AIに提案コードをベースに手作業でリファクタしたり自分のコードと統合したりすれば、人間の創作性が付加されると考えられる。このような場合、変更差分の中に人間の独自性のあるコードがあるかが判断のポイントとなる。著作物性が生じる改変の典型としては、処理の入替や再編、機能の追加、コメント／ログ／メッセージ等の文言の独自の創作的記述、識別子体系の再編等であると考えられるが、無改変のコード採用(コードを見ただけ)、変数やライブラリの改名といった軽微な改変には逆に著作物性が生じないと考えられる。 なお、元の既存コード部分は元から著作物であれば引き続き保護されるし、そうでなければ保護外である。AIの利用によって既存部分の法的性質が変わることはない。 以上のように、総じて日本法では人間が創作的関与をした部分に着目して著作物性の有無を判断することになる。「AIが書いたからすべて著作物性がない」あるいは「人間が指示したからすべて人間の権利」といった極端な判断ではなく、**最終的な結果物におけるどの部分が誰による創作によるものかを細かく見極めていくアプローチ** になる点に注意が必要である。 * * * ## 米国法におけるAI生成コードの著作物性 ここまでは日本法における考え方を整理してきたが、ここで米国法の下でAI生成コードの著作物性がどのように考えられているかを整理する。ソフトウェア分野においては特にオープンソース開発をはじめ米国法の影響が非常に大きいため、米国での著作物性の扱いを理解することは実務上も重要である。 ### AI生成物の著作物性 米国著作権法においては、基本的に人間が創作したもののみを保護するという立場を明確に打ち出している。AIが自律生成した画像の著作権登録を巡る訴訟として近年話題となった**Thaler v. Perlmutter** でも、D.C.巡回区控訴裁判所は一貫して**「人間の著作物性は著作権の根幹を成す要件である」** と判示し、純粋にAIだけで作られた作品には著作権を認めないとの結論を下している。この点は、日本法では明文化されていないものの実質的には同様に考えられている部分ではあるが、**米国では判例と条文解釈の運用上により明確に人間の著作者性が要求される** と言えるだろう。 また、米国著作権局は2023年3月にAI生成物を含む作品の著作権登録ガイダンスを公表し、AIツールを用いて作成された作品を著作権登録申請する際には人間が創作した部分とAIが生成した部分を明確に区別し申告するよう求めている。そのガイダンスでは、著作権は人間が創作したオリジナルな表現部分のみを保護し、純粋にAIが生成した部分には及ばないとはっきり示され、また、単にテキストの**プロンプトをAIに与えただけでは生成物に対する「十分な創作的制御」を人間が及ぼしたとは言えない** とも述べられている。つまり、プロンプトを入力しただけの出力コードには原則として著作権保護は及ばないと判断できる。なお、著作権局のガイダンスはあくまで「著作権登録実務における判断基準」であって、裁判所を形式的に拘束するものではないが、Thaler訴訟等に見られるように、現時点では裁判所もほぼ同じ方向を採用しているので、現在の実務上は「事実上の標準」として扱い得るだろう。 もっとも米国法においても、人間が創作に関与した部分については引き続き権利保護されることには変わりはない。米国著作権局のガイダンスによれば、人間が作成した文章やコード断片を組み込んだケースなど、AI生成物の中に人間の著作物が知覚できる形で表れている場合や人間が生成物を創造的に選択・配列・編集した場合、あるいは生成物を創作的に改変した場合には、その人間が行った創作部分について著作権を認めるとされている。実際、米国著作権局は、AI生成物を土台に人間が修正を加えた画像などの人間がAIを補助的なツールとして用いて作成した作品の著作権登録を個別に認め始めており、「人間が最終的な創作的判断を下した部分」が存在するかどうかが重要視されている。つまり、米国法下でも人間が創作的寄与をした範囲に限って保護する枠組みであることに違いはないが、その線引きをより明示的に「ケースバイケースで判断する」という立場であると言えるだろう。 ### プログラム著作物特有の事情 米国におけるソースコードに関しての著作権の考え方は、基本的に日本法と共通する部分が多い。すなわち、コード中のアイデアや処理手順、機能そのものは保護されず、具体的な表現のみが保護対象となる。米国連邦著作権法(17 U.S.C.)の§102(b)において、「著作物の保護はいかなる場合も、アイデア、手続、過程、システム、運用方法、概念、原理または発見そのものには及ばない」と明文的に規定しており、プログラム中の機能的要素は著作権で保護しないことが法律条文的に明らかにされている。 さらに、**Computer Associates v. Altai**(第2巡回区控訴裁判所)において有名な**抽象化・濾過・比較テスト**(AFCテスト)が示され、プログラムの非文字的要素(構造やUIなど)が著作権保護されるかを判断する枠組みが確立した。このテストは、まずプログラムを抽象度の高い構造まで分解し、次にその中から効率上の必要に迫られた要素、外部仕様から要求される要素、パブリックドメイン領域から取得された要素を順次取り除き、そうして最後に残った部分が創作的表現として保護され得る部分であり、その部分について他の作品との実質的類似性を比較検討するという手法である。要するに、機能的あるいは規範的な要素をフィルタリングして純粋な表現部分を抽出するという考え方であり、表現とアイデアの切り分けを厳密に行う点が特徴である。米国法はこの点について日本法よりも制度的および判例上明文化されている分、判断手法が洗練されているとも言える。 ### ケース別の著作物性の有無の境界線 前項までの米国法の考え方を踏まえ、日本法において整理したケースA、B、C、Dを米国法で考えるとどうなるか、相違点を中心に確認していく。 * **プロンプトのみで生成されたケース(日本のケースA該当)：** 人間が具体的表現に踏み込んだ指示を行ったかどうかが問題となる点は日米共通ではある。しかし、米国では例え詳細なプロンプトを作成したとしても「プロンプト自体は通常、生成物に対する十分な制御とはみなされない」との立場が明確であり、人間による創作的表現が実際の出力コード上に現れていない限り人間の著作物とは認められない可能性が高い。このため、単にAIツールにコードを書かせただけの場合、日本法以上に著作権保護が否定されやすい点に注意が必要であり、実際、著作権局はプロンプトによる出力物のみの登録申請を軒並み拒絶している。 他方で、人間が提示した具体的コード片や擬似コードがそのまま出力に組み込まれているような場合は、その部分は人間の著作物として保護され得る。 * **複数回の生成と取捨選択・編集を経たケース(日本のケースBおよびC該当)：** 人間がAI出力を選別・編集・構成した場合、それによって生じた創作性は米国法でも評価される。米国著作権法は、「編集著作物」として素材の選択や配列に創作性があれば著作物となることを認めているため、AIが生成した複数のコード断片を人間が創造的に取捨選択し配置したようなケースでは、その配置や組み合わせ自体に著作権が発生し得る。 日本法のケースBに相当する試行錯誤による改良も、最終的な結果として人間がコードの表現上の構成を決定したのであれば、著作者は人間だと言える。日米の違いとしては、米国ではその人間の寄与部分を明確に切り出して保護する意識が強い点であろう。つまり、完成したコード全体ではなく、並べ替えという行為や編集結果が創作性を持つと分析する形になる。総じて、主張立証のハードルは日本より高いと考えられるが、出力における人間の創作的工夫が具体的に何かを特定しやすい分、保護の結論自体は日本法と大きく変わらない。 * **既存コードへの加筆修正(日本のケースD該当)：** 人間の著作者が既存コードにAI支援を受けて新たな表現を付け加えた場合、その付加もしくは改変部分に人間の創作性があれば米国法でも保護される点は同じである。米国法では人間が他人の著作物を元に改変を加えたものは二次的著作物として保護されるが、AIが出力したコードも広義には「他者が作った素材」と言えなくもない。しかし、前述の通りAIの出力部分自体には保護が及ばないため、人間が実際に書いて創作性が生じた部分のみが新たな創作部分として扱われることになる。例えば、AIが生成したコードに開発者が肉付けしてユニークな挙動を実装したのであれば、そのユニークな部分が人間の著作物となる。つまり、これに関しては日本法とほぼ同様であり、人間による創作的改変を加えたか否かがカギとなる。 以上のように、米国法も「人間が創作したか否か」という軸でAI生成コードの著作物性を判断しており、大枠では日本法と共通すると考えられる。ただし、米国では著作権局のガイドラインや裁判の判例を通じてそのスタンスがより明確化されているため、プロンプトだけではダメだとか編集すればOKといった線引きを公式に確認できる点で実務上の予見性が高いと言える。一方、日本では文化庁のガイドラインはあるものの判例の蓄積がなく、グレーに感じる部分も残されている。いずれにせよ、日米ともケースバイケースの個別判断をせざるを得ない状況には変わりなく、今後の具体的な事例の集積が待たれるところである。 * * * ## クローズドな商業的ソフトウェア開発における実務 AIコーディングツールの活用が劇的な速度で進む中、企業内のクローズドなソフトウェア開発の実務では著作権管理をどう考えるべきだろうか？ まず、大前提として、企業内で大規模な体制でクローズドに開発されるようなソフトウェアにおいては、従来からプログラム著作物の権利の保護範囲は限定的であったということである。前述の通り、コードの中にはアイデアや機能に過ぎない部分、あるいは誰が書いても同じような表現部分といった権利保護されない部分が多分に含まれる。したがって、AIの有無に関わらずソフトウェア全体の中で著作権侵害を主張できるような**「創作的表現と呼べる島」** は部分的であるケースが多い。大海に浮かぶ島々の部分だけが著作権が認められるということであるわけだが、AI生成ツールの現場への導入によって、この権利保護が生じる島が部分的になる傾向は更に強まる可能性が高いだろう。というのも、現状のAIは大量の既存コードを学習し、定型的若しくは汎用的なコードを出力することが多いと考えられるため、開発者が人力でイチから書いた場合に比べて独自性の低いコードが増えると考えられるからである。例えば、システムにおいて典型的なCRUD処理やAPI呼び出しコードなどは、AIに書かせれば大同小異なコードが生成されるだろう。このような部分はそもそも創作性が乏しく著作権で保護されにくいため、AI利用によって著作権で保護される範囲が相対的に減少することにもなる。 もっとも、商業ソフトウェア開発におけるソースコードにおいて、全く創作的な表現がなくなるわけではない。要求仕様が複雑化すればコード全体の構造や特定のアルゴリズム部分で開発者の創意工夫が現れる場面は依然として存在するし、AIの定型的な提案を鵜呑みにせず人間が調整あるいは工夫を凝らした部分は創作性が認められるだろう。そうした大海の中に浮かぶ**著作権が発生する島々を繋なぎ合わせるアプローチ** が重要であり、そのため、著作権を意識したビジネスを行うのであれば、企業としてはプロジェクト内でどの部分が創作的表現かを意識しつつ管理する必要があるだろう。具体的には、AIツールによる生成箇所についてはその旨をコメント等で記録したり、生成時のプロンプト・出力ログを保存しておき、万が一、後に著作権紛争になった場合に備えて、「この部分は人間が創作した」「この部分は創作性がない(誰の著作物でもない)」と説明できるようにしておくのが望ましい。 加えて、このAIによる変革により、今後は著作権よりも契約および秘密管理の重要性が一層高まると考えられる。著作権だけでは保護が薄くなり、帰属が不明確なコード断片についても、契約上の取り決めによってその利用を制御したいのであれば、やはり**契約手法が最も重要になる** だろう。企業が自社内で開発したソースコードであれば、そのコードに実質的な独自性がなく著作物として認められにくい場合であっても、秘密保持契約(NDA)によって第三者への開示や利用を制限したり、自社サービスの利用規約でコードの転載や複製を禁止するといった対応が可能になる。また、開発委託契約や雇用契約の中で、成果物にAI生成部分が含まれる可能性を踏まえた著作権の帰属や利用許諾の範囲といった権利処理を明記する動きも出てくるだろう。ソフトウェア製品としてリリースする場合には、商標や不正競争観点による保護も相まって、仮にコード自体の著作権保護が弱くても模倣品の排除は一定程度可能である。総じて、**著作権単体では薄くなった権利の保護層を、契約+営業秘密保護+商標等といった他の法的枠組みを動員して補完する方向にシフトせざるを得ない** のが今後の実務と考えられる。 * * * ## オープンソース開発における注意点 最後に、オープンソース開発にAI生成のコードを取り入れる場合の注意点を述べる。基本的に、第三者の権利を侵害していない限りAIツールが出力したコードを自由に利用すること自体は法的に問題ない。何故なら、AI生成コードにはそもそも著作権が発生しない可能性が高く、言わば誰の権利にも属さないパブリックドメイン的なコードとして扱い得るからである。したがって、既存のオープンソースプロジェクトに対してAI生成コードをもって貢献したとしても、その貢献コード単体では誰かの権利を侵害することにもならない可能性が高い。 しかし、実務上はそれで済むほど単純ではない。第一に懸念されるのは貢献時の「著作者」表明との矛盾である。多くのオープンソースプロジェクトでは、開発者がコードを貢献する際に**DCO**(Developer Certificate of Origin:開発者証明)や**CLA**(Contributor License Agreement:貢献者ライセンス契約)への署名が求められ、自分自身が貢献コードを作成し、そのコードを適切に権利処理済みであることを証明する宣言を行う。しかし、仮にコードが純粋なAI生成物であり人間の創作性が皆無だとすると、「自分が作成した」と言えるのかという問題が生じる。法的に著作物でないものを「自分の作品だ」と主張するのは厳密には誤りであり、そこに法的な不確実性が生じることになるのである。まさにこの点について、QEMUプロジェクトではAI生成コードによる貢献を一律に拒否する方針を打ち出している。QEMUプロジェクトの見解では、AI生成コードは各国法で著作物と認められない可能性が高く、自分が著作者であることを求めるDCOの要件を満たせないため受け入れないということである。Linuxカーネルのように割と多くのプロジェクトはAI生成コードとの共存を目指しているものの、QEMU以外のプロジェクトでも同様の方針を採る例が増えるとも予想され、しばらくはオープンソースプロジェクトにおけるAI利用のポリシーに混乱が続くと思われる。 このような法的な矛盾以前の問題として、多くの貢献者によるコードの集合体であるオープンソースのプロジェクトにおいては、貢献コードの一つ一つに著作権が生じているかどうかという観点は些細な問題であり、**個々の貢献コードの責任が誰にあるのか？という観点の方が問題** となり得る。AI生成コードに誰の著作権も生じないのであれば、最終的な責任者が誰であるか分からないコードが増えることにつながり、その観点での影響はまだ未知の領域であると言えるだろう。 また、第二に注意すべき点としてライセンス適合性の問題もあるだろう。AIが学習に使ったオープンソースのコードの一部をそのまま出力してしまうケースは完全に否定できるものでもなく、万が一、GNU GPL等の強いコピーレフト性のあるライセンスのコード断片がAI出力に含まれていた場合、それを知らずに他のライセンスのプロジェクトに混入させてしまうことでライセンスの矛盾を引き起こす可能性があるだろう。もっとも近年はGitHub Copilotに代表されるように、出力コードを既存コードと照合して酷似箇所を検出する仕組みがAIツール側に導入されつつあり、このリスクは低減しつつある。しかし、それでも「このコードは他人の著作物に由来しないコードである」と人間が保証することは非常に困難であるのが現状であり、であればオープンソースプロジェクト側としてはAIによる貢献には慎重にならざるを得ないだろう。 では、オープンソースコミュニティとしてAI生成コードを活用していくにはどうすれば良いのだろうか？ 現実的なアプローチとしては、人間が一定の創意工夫を施してから貢献することが挙げられる。すなわち、AIが提案したコードをそのままコピペするのではなく、きちんと自分自身で内容を理解および検証を行い、必要に応じてリファクタリングやコメント追加を行った上で自分の責任によるコードとして投稿するということである。こうすれば、法律上も実態上も「自分が作成したコードだ」と胸を張って言えるし、DCOとの矛盾も生じにくいだろう。 また、プロジェクトによっては貢献時に「AIツールを使用したかどうか」を申告させるところも出てきているが、そのようなプロジェクトのポリシーに沿った透明性の確保も重要である。例えばLinuxカーネルのコミュニティはAI利用に関する行動規範を示しつつあるが、基本的にはAIツールの使用を詳細に明示していく流れが強まるのだろう。オープンソースプロジェクトのメンテナーは、自分たちのプロジェクトにおいて**AI生成コードを受け入れるか否か、あるいは「AI起源のコードであることをコメントで明示する」「生成物の出所証明を添付する」等の利用条件を早めに議論し、プロジェクトの方針を定めておく必要がある** だろう。 以上、オープンソース分野での注意点を述べたが、ここには本稿では書ききれていない実務上の課題も数多く存在するため、オープンソースの開発コミュニティにおけるAIツール利用の是非やプラクティスについては、近いうちにより踏み込んだ解説記事を書くことにしたい。 * * * ## 余談 本稿では、プログラム著作物に特化して、どのような場合にAIツールの出力に著作物性が発生し得るかを日本法と米国法に基づいて検討したが、結局のところ、双方共に人間の創作性がコードに表れているか否かという軸でAI生成コードの著作物性を判断するという方向性で共通していると考えられる。また、日米ともケースバイケースの個別判断をせざるを得ない状況であることも変わりはなく、まだまだ不明瞭な点が多いことは間違いない。また、日米以外の法域に注目すれば、コンピュータ生成作品について50年の保護期間を設けている英国のCDPA第9条といった単純なAI出力にも著作物性を認め得る考え方も存在するわけであり、日米のスタイルが主流になるかは定かではない。AIを巡る情勢は日進月歩であり、本稿での記述が数年先に全く異なるものとなる可能性すらあるだろう。 * * * ## 参考 * AIと著作権に関する考え方について、文化庁(令和6年3月15日)：https://www.bunka.go.jp/seisaku/bunkashingikai/chosakuken/pdf/94037901_01.pdf * プログラムは著作権法でどこまで保護されるのか。注意点とポイントを解説：https://www.ys-law.jp/IT/column/column-10994/ * システムサイエンス事件(東京高裁平成元年6月20日決定)：https://www.isc.meiji.ac.jp/~sumwel_h/doc/juris/tacd-h1-6-20.htm * 電車線設計用プログラム事件(東京地裁平成15年1月31日判決)：https://www.courts.go.jp/assets/hanrei/hanrei-pdf-11333.pdf * 宇宙開発事業団プログラム事件(知財高裁平成18年12月26日判決)：https://www.courts.go.jp/assets/hanrei/hanrei-pdf-33985.pdf * Thaler v. Perlmutter：https://media.cadc.uscourts.gov/opinions/docs/2025/03/23-5233.pdf * Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence (U.S. Copyright Office, 2023年3月16日)：https://www.federalregister.gov/documents/2023/03/16/2023-05321/copyright-registration-guidance-works-containing-material-generated-by-artificial-intelligence * Copyright and Artificial Intelligence, Part 2: Copyrightability (U.S. Copyright Office, 2025年1月29日)：https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf * Computer Associates International, Inc. v. Altai, Inc.：https://en.wikipedia.org/wiki/Computer_Associates_International,_Inc._v._Altai,_Inc. * How Can Open Source Projects Accept AI-Generated Code? — Lessons from QEMU’s Ban Policy：https://shujisado.org/2025/07/02/how-can-open-source-projects-accept-ai-generated-code-lessons-from-qemus-ban-policy/ ### 共有: * クリックして X で共有 (新しいウィンドウで開きます) X * Facebook で共有するにはクリックしてください (新しいウィンドウで開きます) Facebook * いいね 読み込み中… ### _関連_

アカウント登録なし、インストール不要でありながら、編集・署名・別ファイル形式への変換・透かしの追加・光学文字認識(OCR)などのさまざまな編集機能を完全無料で使えるPDFエディターが「LocalPDF」です。既存のPDFエディターはオンライン上にファイルをアップロードする必要があるためプライバシーが完全に守られているとは言い難いものになっていますが、LocalPDFはローカルにあるファイルを読み込んでネット上にアップすることなく作業できるため、プライバシーが100％守られているという点でも特異です。 **続きを読む...**

Metaに買収された常時録音型のデバイスのプライバシーポリシーで、データ販売や広告への利用を禁止する条項を削除したことが判明し、批判が殺到している。

数々のWebサービスをヒットさせてきた個人開発者、catnoseさん。手がけたサービスの人気とは裏腹に、これまであまり明かされてこなかった、その素顔と半生についてじっくり聞いた。

市場価格下落と受注低迷により収益性が悪化し、回復が困難と判断した。

東京大学 大学院理学系研究科・理学部のプレスリリース情報です。

A WASM virtual machine written in Go with 0 dependencies - ziggy42/epsilon

【IIJ 2025 TECHアドベントカレンダー 12/9の記事です】 昨年は「SSHでも二要素認証を使いたい」のタイトルでご紹介したSSHで二要素認証を利用す...

博報堂テクノロジーズと会津大学が実施するサマーワークショップが、今年で3回目を迎えました。「生成AIによる動画制作」をテーマに開催された今回のワークショップでは、データサイエンティスト集団「AaaS Tech Lab」の […]

We’ve all seen them, on the boardwalks of Venice Beach or of the Jersey Shore: poop-joke t-shirts that state the gist of various world religions or philosophies by reference to the aforementioned bodily function.

Datacenters in space aren''t going to work (taranis.ie) 11-29  ↑ 104 HN Points