AIが書いたコードの著作権は誰のものか｜Copilot利用と納品時の注意点

2026年2月23日

丸山桃子

この記事のポイント

✓GitHub Copilotなど AIコード生成ツールで書いたコードの著作権は誰に帰属するのか
✓訓練データ由来の侵害リスク
✓無償版と有償版の補償範囲の違い

「AI コード著作権 Copilot」で検索してこのページを開いた人は、おそらく二つのどちらかの立場にいる。GitHub Copilotなどの生成AIを使ってコードを書いていて、そのコードの著作権が自分にあるのか会社にあるのか分からなくなった人。あるいは、クライアントに納品するコードにAIの提案をそのまま使ってよいのか、契約上どう扱えばいいのか不安になった人だ。結論を先に書くと、AIが提案したコード自体には原則として著作権は発生しない。ただし、あなたがそれを選び、並べ、書き換えて完成させた成果物には著作権が発生し、その帰属は契約次第で変わる。この記事では、コーディングに詳しくない発注者でも理解できるよう、著作権の考え方、訓練データ由来の侵害リスク、無償版と有償版の違い、納品時の実務対応まで順番に整理する。

AIコード生成が当たり前になった今の現状

数年前まで「AIに書かせたコードを納品に使っていいのか」という質問自体が珍しかった。今は状況がまったく違う。GitHub Copilotは2,000万人以上の開発者に利用されており、書かれるコードのうち46%がAIによる生成だという調査もある。つまり今、業務委託でシステム開発やちょっとした自動化スクリプトを請け負っているフリーランスの多くが、意識するとしないとにかかわらずAIの提案を使ってコードを書いている。

私自身、アパレルECの運営代行をする中で、在庫の突合スクリプトやInstagram投稿の自動化ツールを何度か自作してきた。本業はデザインやEC運営で、エンジニアではない。それでもCopilotのようなツールがあれば、Pythonの基礎さえ分かっていれば動くコードにたどり着ける。最初にこの便利さに触れたとき、正直「これって誰が書いたことになるんだろう」とは全く考えなかった。考えるきっかけになったのは、あるクライアントから「納品物にAIが関わっている部分の権利関係を書面で示してほしい」と言われたときだった。契約書のひな形をそのまま流用していた私は、そこで初めて自分がグレーな状態でコードを納品していたことに気づいた。

この背景には、AIコーディングツールの普及スピードに、著作権法や契約実務の整備が追いついていないという構造的なズレがある。次のセクションから、まず法律上の考え方を整理していく。

Copilotが生成したコードに著作権は発生するのか

著作物性の基本的な考え方

日本の著作権法では、著作物は「思想または感情を創作的に表現したもの」と定義されている。ここでの重要なポイントは「人間の創作的関与」が前提になっているということだ。AIが単独で、人間の指示や修正なしに自動生成しただけのコード片には、現状の法解釈では著作権が発生しないとする見方が主流になっている。

一方で、AIの提案をベースに開発者が構造を組み替えたり、変数名や処理の流れを工夫したり、複数の提案を取捨選択して組み合わせたりした場合は話が変わる。そこに人間の創作的な工夫が加わっていれば、その部分については著作物として保護され得る。つまり「AIが書いたから著作権なし」と単純に割り切れるものではなく、どれだけ人間が手を入れたかというグラデーションの中で判断される。

実務での判断はどうなるか

現場でよく起きるのは、Copilotの提案をほぼそのままコピーして使うケースだ。特に定型的な処理(ファイルの読み込み、簡単なバリデーション、よくあるAPI呼び出しの雛形など)は、AIの提案通りに使っても違和感がない。こうした「誰が書いてもほぼ同じ形になる」コードは、そもそも創作性が低いと判断されやすく、著作権の議論自体があまり実益を持たない。

問題になりやすいのは、独自性の高いアルゴリズムやビジネスロジックの中核部分をAIにほぼそのまま書かせて納品するケースだ。この場合、後から「このコードは誰のものか」で揉める余地が生まれる。フリーランスとして案件を受けるなら、契約書の中で「成果物の著作権は納品と同時に発注者に譲渡する」という条項が入っているかを必ず確認しておきたい。この帰属の考え方は、著作権譲渡契約全般に共通する論点でもある。実際、著作権譲渡契約の注意点｜デザイン・ライティング案件でトラブルを避ける「帰属」と「譲渡」の境界線では、デザインやライティングの成果物における「帰属」と「譲渡」の違いを詳しく解説しており、コード納品でも同じ枠組みで考えることができる。

訓練データ由来の著作権侵害リスク

なぜ「似たコードが出てくる」ことが問題になるのか

Copilotのようなツールは、公開されているソースコードを大量に学習して提案を生成している。この学習データの中には、オープンソースライセンスの条件を守らなければならないコードや、著作権が明確に主張されているコードも含まれている。まれに、学習データに含まれていた特徴的なコード片がほぼそのままの形で出力されることがあり、これが著作権侵害の火種になる。

実際、この論点は米国で訴訟にまで発展している。

GitHub Copilotは、OpenAIのAIモデルを活用したコーディング支援ツールとして2,000万人以上の開発者に利用されていますが、訓練データに使用された公開ソースコードとの関係から著作権上の問題が指摘されています。本記事では、2026年2月に第9巡回控訴審で口頭弁論が行われたDoe v. GitHub訴訟の最新動向、Microsoft著作権コミットメントの適用範囲、米国・EU・日本の規制比較、そして主要AIコーディングツール5社のIP補償体制を徹底解説します。出典: ai-souken.com

この訴訟は2022年に提起され、2026年時点でも控訴審が続いている長期案件だ。争点は、AIの学習に他人のコードを無断で使うことがフェアユースの範囲に収まるか、そして出力されたコードが元のコードの著作権を侵害しているかという二点に集約される。判決が確定するまでは「グレーゾーンが続く」というのが実情であり、フリーランスとして案件を受ける側は、この不確実性を前提に自衛策を取る必要がある。

OSSライセンスとの衝突という別の論点

著作権侵害とは少し性質が異なるが、実務でより頻繁に起きるのがオープンソースライセンス(OSS)との衝突だ。GPLのようなコピーレフト型のライセンスが適用されたコードの一部がAIの提案に紛れ込むと、そのコードを組み込んだ成果物全体にライセンス条件が波及するリスクがある。業務委託先に納品するコードにOSSライセンスの制約が意図せず混入していた場合、後から大きなトラブルになりかねない。

対策としては、AIが提案したコードのうち少しでも「これはどこかで見たことがある定型パターンではなく、独自性の高い処理だ」と感じた部分については、出典の確認や書き換えを行う運用を徹底することが現実的だ。すべての提案を逐一検証するのは現実的ではないが、納品前のセルフレビューの中に「AI提案部分の由来チェック」という項目を一つ加えるだけでも、リスクはかなり下げられる。

無償版と有償版で補償範囲は大きく違う

Microsoftの著作権コミットメントとは

Copilotの著作権リスクを考えるうえで欠かせないのが、Microsoftが提供する「Copilot Copyright Commitment(顧客著作権コミットメント)」という補償制度だ。これは、Copilotの出力によって第三者から著作権侵害を主張された場合に、Microsoftが法的な防御費用や和解金を一定の条件下で負担するという仕組みだ。

ただし、この補償が適用されるのは主に有償版(Copilot Business、Copilot Enterprise等の商用プラン)であり、なおかつMicrosoftが定めるガードレール機能(重複コード検出のフィルタリング等)を有効にしていることが条件になっているケースが多い。無償版や個人利用のプランでは、この補償の対象外になることが一般的だ。

Copilotの生成物は著作権侵害になる? 商用利用の注意点として、結論はリスクが「無償版か有償版か」と「規約を守っているか」で決まるという整理がされている。Microsoftの著作権コミットメントは、有償プランでガードレール機能を有効にしていることなど、一定の条件を満たした場合にのみ適用される。出典: ai-souken.com

フリーランスが確認すべきプラン選び

業務委託で継続的にコードを納品する立場であれば、無償版のCopilotを使い続けることのリスクは意外と大きい。クライアントによっては契約書に「AIツールを使用する場合は補償制度のある有償プランを利用すること」という条項を入れてくるケースも増えている。月額の利用料は数千円程度で、案件の規模を考えれば十分に経費として回収できる水準だ。むしろ「無償版で節約して、後から著作権トラブルに巻き込まれるリスク」の方が、フリーランスにとってはるかに高くつく。

契約書の段階でAIツールの利用可否や、利用する場合のプラン要件について明記しておくことは、下請法(取適法)が求める発注条件の明確化とも関係が深い。フリーランスを守る「下請法(取適法)」の知識｜発注書・契約書の必須項目チェックリストでは、発注書・契約書に盛り込むべき必須項目を解説しており、AIツールの利用条件もこうしたチェックリストに含めておくと後々のトラブルを防ぎやすい。

各国の規制動向と日本での位置づけ

米国・EUの規制の流れ

米国では前述のDoe v. GitHub訴訟が象徴的だが、それ以外にもAI生成物の著作権登録を巡る米国著作権局のガイドラインが段階的に整備されつつある。基本的な立場は「人間の創作的関与がない部分は著作権登録の対象にならない」というもので、日本の解釈と大きな方向性は一致している。

EUでは、AI規則(AI Act)の枠組みの中で、生成AIの学習データの透明性確保を求める動きが強まっている。学習に使ったデータセットの概要を開示する義務などが段階的に導入されており、これは直接的な著作権規制ではないものの、間接的にコード生成AIの訓練データ由来リスクを可視化する方向に働いている。

日本の著作権法での扱い

日本では、著作権法第30条の4によって、AIの学習(情報解析)のための著作物利用は原則として著作権者の許諾なく行えるとされている。これは世界的に見てもAI開発に寛容な規定として知られている。ただし、この規定はあくまで「学習段階」の話であり、AIが出力した結果が既存の著作物と類似・依拠している場合には、通常の著作権侵害の判断枠組み(類似性と依拠性)が適用される。

つまり日本国内での業務においても、「学習に使われたこと自体は合法だが、出力されたコードが既存の著作物に酷似していれば侵害になり得る」という二段構えの理解が必要になる。この整理は、Copilotに限らずChatGPTやClaudeなどのコード生成AI全般に共通する考え方だ。

納品時に確認すべき実務上のチェックポイント

契約書に盛り込むべき項目

AIコード生成ツールを使って納品する場合、契約書やSOW(作業範囲記述書)に以下のような項目を入れておくと、後々のトラブルを大きく減らせる。

まず、AIツールを利用する旨の開示だ。多くのクライアントは「AIを使うこと自体」を問題視しているわけではなく、「使っていることを隠されること」を問題視する。事前に開示し、必要であれば使用範囲について合意しておくことが信頼関係の土台になる。次に、著作権の帰属条項だ。納品と同時にAI利用部分も含めて成果物全体の著作権が発注者に譲渡される旨を明記する。そして、補償や免責の範囲についても触れておくとよい。万が一、第三者から著作権侵害を指摘された場合、受注者側の責任範囲がどこまでかを事前に取り決めておくことで、感情的な対立を避けられる。

コードレビューと出典確認の運用

実務レベルでは、納品前のレビュー工程に「AI提案由来の疑いがあるコードの確認」という一手間を加えることをおすすめする。具体的には、独自性の高いロジックや、他では見ないような特徴的な実装については、AIの提案をそのまま採用せず、自分の言葉(コード)で書き直す。定型的な処理はAIの提案通りで問題ないが、ビジネスロジックの核心部分は人間の手による調整を必ず挟むというルールを、自分の中で明確にしておくことが重要だ。

主要AIコーディングツールの補償体制を比較する視点

GitHub Copilot以外にも、コード生成AIは複数の選択肢がある。ツールを選ぶ際は、単純な生成精度だけでなく、著作権リスクへの備えという観点も加えて比較するとよい。

ソフトウェアテスト事業のバルテス株式会社は、Microsoft Copilotをホワイトリストで全社利用可能とする一方、他の生成AIツールは申請・承認の許可制とし、利用申請の前提として社内教育プログラムの受講・合格を必須化しています。ツールごとに使ってよい範囲を明確に線引きすることで、著作権や情報漏えいのリスクを抑えながら、業務での生成AI活用経験を87.1%(社内サーベイ)まで高めました。出典: ai-keiei.shift-ai.co.jp

この事例が示唆しているのは、企業がAIツールを導入する際、「使う・使わない」の二択ではなく、「どのツールを、どんな条件で、誰が使うか」を線引きしているという点だ。フリーランス個人であっても、この考え方は参考になる。案件ごとに「このクライアントはAI利用に厳格か寛容か」「補償のある有償プランを使う必要があるか」を判断し、使い分ける姿勢が求められている。

ツール選定の比較軸としては、大きく以下の三つが挙げられる。一つ目は著作権補償の有無と適用条件、二つ目は学習データの透明性(どのようなコードで学習しているかの開示度合い)、三つ目は出力コードの重複検出フィルタの精度だ。これらはツールのアップデートによって頻繁に変わるため、契約前に最新の利用規約を確認する習慣をつけておくと安心だ。

このあたりの知識は、AIコンサルや業務活用支援を専門にする案件でも重宝される。AIコンサル・業務活用支援のお仕事では、企業が生成AIを安全に導入するための支援業務について紹介しており、著作権リスクの整理や社内ルール策定の知見が求められる分野として関連が深い。また、AIチャットボットやアプリ開発の受託でもコード生成AIの利用は避けて通れない。AIチャットボット・アプリ開発のお仕事では、開発案件の具体的な内容や必要スキルを解説している。画像生成AIを使った制作案件でも著作権の考え方は共通する部分が多く、画像生成AI(Stable Diffusion等)のお仕事も合わせて参考にできる。

開発以外の職種にも広がる著作権リスクの論点

コード生成AIの著作権論点は、エンジニア職に閉じた話ではない。ライターや編集者がAIを使って文章を生成する場合にも、構造的にはよく似た議論が起きている。AIが生成した文章そのものには創作性が乏しく著作権が発生しにくい一方、人間が編集・構成を加えた部分には著作権が生まれるという整理は、コードの場合とほぼ同じロジックだ。文章とコードで直面する著作権の考え方に大きな差はなく、副業やフリーランス案件を選ぶ際にはどちらの職種でもこの前提を理解しておく必要がある。単価相場を確認する際にも、ソフトウェア開発のソフトウェア作成者の年収・単価相場や、ライティング系の著述家、記者、編集者の年収・単価相場を比較しておくと、AI利用が前提になった今の市場感がつかみやすい。

スキルの証明という観点では、生成AIの利用ルールや基礎知識を体系的に学べる資格も整備されつつある。生成AIパスポートは、生成AIの基本的な仕組みやリスク、利用ルールを学べる資格として、著作権リスクの基礎理解を証明する材料になる。また、実際にPythonでコードを書く機会が多いなら、Python3エンジニア認定基礎試験のような基礎資格を持っておくと、AIの提案が正しいかどうかを自分で判断できる土台にもなる。AIに頼りきりで基礎を持たないまま納品を続けると、コードの由来チェックすら自分でできなくなってしまう。

著作権侵害を指摘されたときの対応フロー

万が一、納品したコードについてクライアントや第三者から「既存のコードに似ている」と指摘を受けた場合、慌てて謝罪や返金を申し出る前に確認すべき手順がある。

まず、該当箇所がAIツールのどの提案に由来するのかを特定する。Copilotなど一部のツールには、生成履歴や提案元の候補を遡って確認できる機能が用意されている場合があり、これを確認することで「意図的な模倣」なのか「AIの偶発的な出力」なのかを客観的に説明できる材料になる。次に、使用していたプランが有償版であれば、Microsoftの著作権コミットメントなど補償制度の対象条件を満たしているかを確認する。ガードレール機能を有効にしていたか、規約に沿った利用だったかによって、補償の可否が変わってくる。

そのうえで、契約書に定めた責任分担条項に基づき、発注者と受注者のどちらがどこまで対応するのかを整理する。ここで重要なのは、事前に契約書へ「AI利用に起因する著作権トラブルが発生した場合の対応」を明記していたかどうかだ。何も取り決めがない状態でトラブルが起きると、責任の押し付け合いになりやすく、フリーランス側が一方的に不利な立場に置かれるケースも少なくない。案件を受ける段階で、こうした万一の対応フローまで契約書に落とし込んでおくことが、結果的に自分の身を守ることにつながる。

該当箇所を特定できたら、指摘されたコードを速やかに書き直す対応も必要になる。似ている処理であっても、変数名や処理順序、コメントの書き方などを自分の言葉で再構成すれば、創作的な関与を加えたことになり、リスクはかなり軽減される。指摘を受けてからでも遅くはないので、放置せず早めに手を動かすことが被害を最小限に抑える鍵になる。

AIコーディングツールを使う開発者に求められるリテラシー

著作権の議論はどうしても法律的で堅苦しく感じられがちだが、実務で求められているのは弁護士並みの専門知識ではない。必要なのは「どこまでがAIの提案そのままで、どこからが自分の創作か」を自分自身で説明できる状態を保っておくことだ。これは特別なスキルというより、日々のコーディング習慣の延長線上にある。

具体的には、AIの提案を採用するかどうかを判断する際に、一呼吸置いて「この処理は自分でも書けるものか、それとも完全にAI任せか」を意識するだけでも変わる。完全にAI任せの部分が多い案件ほど、納品前のレビューに時間をかける必要がある。逆に、自分で設計方針を固めたうえでAIに細部を補完させているような案件は、リスクが相対的に低い。この線引きを日常的に意識できるようになると、著作権トラブルへの耐性は自然と高まっていく。

また、AIツールの利用規約は頻繁に更新される。数か月前に確認した補償条件が今も有効とは限らない。継続的に案件を受けるなら、四半期に一度程度は利用しているツールの規約や補償範囲を見直す習慣を持っておくと安心だ。

独自データが示す実務上の傾向

長くフリーランス・在宅ワーク市場を見てきた運営者の立場から言えば、著作権トラブルが起きやすい案件には共通したパターンがある。それは、発注段階で「AIツールの利用可否」がまったく話題に上らず、納品直前になって初めて確認が入るケースだ。逆に、契約前の段階でAI利用について発注者と受注者がオープンに話し合っている案件ほど、後からのトラブルが少ない。これは著作権という法律論の話であると同時に、信頼関係の設計の話でもある。

運営者として見てきた限りでは、単発の作業を安く早くこなす受注者よりも、「このコードのどこにAIを使い、どこを自分で書いたか」を発注者に説明できる受注者の方が、継続的な依頼につながりやすい。AIの活用自体はもはや前提であり、隠すことよりも透明性を保つことの方が案件の継続性に直結している。

もう一つ、直接契約の構造が持つ意味も改めて触れておきたい。仲介業者を挟む契約では、著作権トラブルが起きたときに責任の所在があいまいになりやすく、発注者と受注者のあいだで直接すり合わせる機会が失われがちだ。一方、手数料0%の直接取引であれば、同じ予算の中でも受け手の手取りが厚くなるだけでなく、契約条件そのものを当事者同士で細かく詰められるという利点がある。AI利用の範囲や著作権の帰属といった、まさに今回のテーマのような繊細な条件ほど、間に人を挟まずに直接話し合える環境の価値は大きい。長く安定して案件を受け続けている人ほど、単発の作業をこなす以上に、こうした条件の擦り合わせに時間をかけている印象がある。

税務面でも、AIツールの利用料は経費として計上できる項目であり、確定申告の際に見落とされがちなポイントの一つだ。フリーランスとして継続的にAIツールへの支払いが発生するなら、経費管理や確定申告の実務についても早めに整理しておきたい。税理士資格でフリーランス副業｜確定申告代行で稼ぐ方法と注意点では、確定申告代行の副業について解説しており、自分自身の申告実務を見直すきっかけにもなる。

著作権リスクをゼロにすることは、現状の技術と法整備のスピードを考えると現実的ではない。それでも、無償版と有償版の違いを理解し、契約書に必要な条項を入れ、納品前のレビューで由来の怪しいコードを確認するという地道な積み重ねが、リスクを実務レベルで十分にコントロール可能な範囲まで下げてくれる。AIを使うこと自体を恐れるのではなく、使い方のルールを自分の中に持っておくことが、これからの開発案件を継続的に受注していくための最低条件になる。法整備が追いつくまでの間は、受注者側が先回りしてルールを整えておく姿勢そのものが、クライアントからの信頼につながっていく。