「AI が書いてくれたコードに、ライセンスってあるのですか？」――この問いに即答できない中堅企業は少なくありません。 しかし、答えは「ある場合がある」です。GitHub Copilot や Cursor といった AI コーディング支援ツールは、世界中の公開ソースコードを学習しています。そのため、生成されたコードが既存のオープンソース・ソフトウェア（OSS）に酷似することがあり、その場合、元コードのライセンス条件が自社のプロダクトに波及する可能性があります。

OSS ライセンスには、利用条件がほとんどない「寛容（permissive）」なものから、派生物のソースコード公開を義務づける「コピーレフト」な強いものまであります。後者に該当するコードを、ライセンスを意識せず自社製品に取り込むと、最悪の場合、自社で開発したソースコードまで公開を求められる事態になりかねません。これは、AI を使うほど見えにくくなるリスクです。

本記事は連載「バイブコーディング危機」第16回（防衛策の実装編）として、主要 OSS ライセンスの違い、AI コーディングが踏みやすいライセンスの地雷、GitHub Copilot をめぐる訴訟（Doe v. GitHub）の到達点、SBOM（ソフトウェア部品表）・SCA（依存関係解析）による防衛策、中堅企業の実務を、OSI（Open Source Initiative）・GitHub 公式・公開報道を一次ソースに整理します。「OSS を使うな」ではなく、OSS を安全に使うためのライセンス管理を持ちましょう、という趣旨です。

目次

  1. なぜAI生成コードにライセンスリスクがあるのか
  2. 主要OSSライセンスの違い：寛容型とコピーレフト型
  3. 中堅企業が踏みやすい5つのライセンス地雷
  4. GitHub Copilot訴訟（Doe v. GitHub）の到達点
  5. 防衛策その1：AIツールの設定と運用ルール
  6. 防衛策その2：SBOMとSCAでライセンスを可視化する
  7. 中堅企業の現実的な導入ステップ（30〜90日）
  8. 中堅企業が陥りやすい5つの失敗
  9. よくある質問（FAQ 10問）
  10. 参考一次ソース
  11. まとめ
  12. 関連記事

なぜAI生成コードにライセンスリスクがあるのか

AI コーディング支援ツールが便利なのは、過去の膨大なコードを学習しているからです。ところが、その学習元こそが、ライセンスリスクの源になります。

AIは公開コードを学習している

GitHub Copilot や Cursor などのツールは、公開されている大量のソースコードを学習しています。そのため、特定の処理を書かせると、学習元に存在したコードと似た出力を返すことがあります。出力されたコードが、たまたま厳しいライセンスの OSS に酷似していた場合、そのライセンス条件が問題になる余地が生まれます。

「動くコード」にライセンスの注記は付いてこない

AI が生成するのは「動くコード」であって、「このコードは○○ライセンスのプロジェクトに由来します」といった注記は基本的に付いてきません。利用者は、出てきたコードの由来を知らないまま、自社の製品に貼り付けてしまいます。本連載が繰り返し指摘してきた「動けばいい」の発想が、ここでもリスクを生みます。

GitHub Copilot自身が重複検知の仕組みを用意している

この問題は、ツール提供側も認識しています。GitHub Copilot には、生成しようとするコードが GitHub 上の公開コードに一致・近似していないかを検知するフィルターが用意されています。GitHub の公式ドキュメントによると、このフィルターは、周辺コードを含めて約 65 レクシーム（lexeme、平均でおよそ 150 文字）以上の一致・近似を検査し、設定によって一致するコードの提案をブロック（block）するか、許可（allow）して一致情報を確認できるようにするかを選べます（GitHub Docs: Finding public code that matches GitHub Copilot suggestions）。この設定が存在すること自体が、「AI生成コードが既存コードに一致しうる」という前提を示しています。

要点：AI 生成コードのライセンスリスクは、「AI が悪い」のではなく、OSS という巨大な資産の上に AI が成り立っていることの裏返しです。だからこそ、出力の由来とライセンスを管理する仕組みが必要になります。

主要OSSライセンスの違い：寛容型とコピーレフト型

ライセンスリスクを理解するには、OSS ライセンスを大きく 2 つのタイプに分けて捉えるのが近道です。OSI（Open Source Initiative）は、各ライセンスの一覧と全文を公開しています（OSI: Licenses）。

寛容型（permissive）：MIT・Apache 2.0

MIT ライセンスは、最も寛容で広く使われているライセンスの一つです。著作権表示とライセンス文を残せば、利用・改変・配布・販売まで幅広く認められ、派生物を公開する義務はありません。Apache License 2.0 も寛容型で、MIT に近い自由度を持ちつつ、特許に関する明示的な許諾条項（特許グラント）と特許報復条項が含まれる点が特徴です（MIT にはこの特許条項がありません）。商用利用が中心の中堅企業にとっては、扱いやすいライセンスです。

コピーレフト型（copyleft）：GPL・AGPL・LGPL

GPL（GNU General Public License）は、コピーレフトの代表格です。GPL のコードを取り込んだプログラムを他者に配布する場合、その派生物も同じ GPL で公開しなければなりません。つまり、GPL コードを自社製品に組み込んで配布すると、自社のソースコードも公開を求められる可能性があります。これがいわゆる「GPL 汚染」と呼ばれる現象です。

LGPL（GNU Lesser General Public License）は、GPL を緩めたもので、主にライブラリ向けです。動的リンクなど一定の条件下では、利用側のソース公開義務が緩和されますが、条件を満たさない使い方をすれば義務が生じます。

AGPL（GNU Affero General Public License）は、GPL をさらに強めたものです。GPL では「ネットワーク越しに利用させるだけ（配布していない）」場合に公開義務が及ばないとされ、これが「SaaS の抜け穴（ASP ループホール）」と呼ばれてきました。AGPL は、改変したソフトウェアをネットワーク越しにユーザーへ提供する場合（SaaS を含む）も、そのソースコードを提供するよう義務づけることで、この抜け穴を塞いでいます（FOSSA: AGPL License 解説）。クラウドサービスを運営する中堅企業にとって、AGPL は特に注意が必要なライセンスです。

4タイプの比較

ライセンスタイプ配布時の義務ネットワーク提供（SaaS）時
MIT寛容著作権・ライセンス表示のみ公開義務なし
Apache 2.0寛容表示 + 変更点の告知（特許条項あり）公開義務なし
LGPL弱いコピーレフト条件次第で利用側ソースは免除条件次第
GPLコピーレフト派生物を同ライセンスで公開配布でなければ及ばないとされる
AGPL強いコピーレフト派生物を同ライセンスで公開公開義務が及ぶ

※ ライセンスの解釈は事案により異なり、最終的な法的判断は専門家・弁護士に委ねるべき領域です。表は概念整理の目安としてご覧ください。

中堅企業が踏みやすい5つのライセンス地雷

1. GPL汚染：自社製品のソース公開を求められる

GPL の OSS コード（AI が生成した類似コードを含む）を自社製品に組み込み、その製品を配布した結果、自社のソースコードまで公開義務が生じるケースです。販売しているソフトウェアの競争力の源泉が、公開を迫られるリスクになります。

2. AGPLの罠：クラウドサービスでソース公開を求められる

「配布していないから大丈夫」と GPL の感覚でいると、AGPL では足をすくわれます。AGPL のコードを使った機能を SaaS として提供すると、ネットワーク越しの利用者に対してソース公開義務が及びます。自社開発のクラウドサービスで、これは重大なリスクです。

3. ライセンス表示漏れ：寛容型でも違反になる

MIT や Apache のような寛容なライセンスでも、著作権表示・ライセンス文の保持が条件です。AI が生成したコードを貼り付けただけでは、この表示が抜け落ちます。「自由に使える」と誤解して表示義務を怠ると、寛容型であってもライセンス違反になります。

4. ライセンスの組み合わせ（非互換）問題

複数の OSS を組み合わせるとき、ライセンス同士が両立しない（非互換な）ことがあります。AI が様々な由来のコードを混ぜて出力すると、知らないうちにライセンス非互換を抱え込む可能性があります。

5. 依存ライブラリの孫・ひ孫まで見ていない

自社が直接使うライブラリだけでなく、そのライブラリが依存するライブラリ（推移的依存）にも、それぞれライセンスがあります。表層だけ見て「MIT だから安心」と判断すると、依存の奥に GPL や AGPL が潜んでいることがあります。これは、本連載第11回で触れた SCA（依存関係解析）の対象とも重なります。

GitHub Copilot訴訟（Doe v. GitHub）の到達点

AI 生成コードのライセンス・著作権をめぐる代表的な訴訟が、Doe v. GitHub です。事実関係を、公開報道にもとづいて整理します。

訴訟の概要

この訴訟は、匿名のプログラマーたちが、GitHub・Microsoft・OpenAI を相手取り、2022 年 11 月に米国で提起したものです。GitHub Copilot が公開ソースコードを学習し、ライセンス条件（著作権表示など）を尊重しないコードを生成しているとして、当初は多数の請求を含んでいたと報じられています（The Register: GitHub Copilot copyright case narrowed）。

DMCA請求は棄却された

公開報道によると、裁判所（米カリフォルニア州北部地区連邦地裁、Jon S. Tigar 判事）は、原告が主張したデジタルミレニアム著作権法（DMCA）に関する請求を退けました。報道では、Copilot の出力が元のコードに似ていても、完全に同一でなければ DMCA 違反には当たらないという趣旨の判断が示された、と伝えられています（The Register: Judge dismisses DMCA copyright claim in GitHub Copilot suit（2024年7月））。当初多数あった請求の大部分は、被告側の申し立てにより退けられたと報じられています。

契約・ライセンス違反の論点は残った

一方で、報道によると、契約違反やオープンソースライセンス違反に関する論点は、一部残ったとされ、その後、上訴審（第9巡回区連邦控訴裁判所）への手続きに移ったと伝えられています。

この訴訟から中堅企業が学ぶべきこと

重要なのは、「裁判の最終的な決着」ではなく、「この問題が現実に争われている」という事実です。AI 生成コードと OSS ライセンス・著作権の関係は、まだ法的に固まりきっていない領域です。だからこそ、企業としては「白黒がつくまで待つ」のではなく、リスクを下げる運用を先回りで整えることが現実的です。本記事の防衛策は、その先回りにあたります。

注記：訴訟の論点や状況は時間とともに変化します。本記事の記述は公開報道にもとづく整理であり、最新の状況や正確な法的評価は、一次資料・専門家にご確認ください。

防衛策その1：AIツールの設定と運用ルール

ライセンスリスクは、まず「入口」で減らせます。

公開コード一致のブロック設定を有効にする

前述のとおり、GitHub Copilot には公開コードと一致する提案をブロックする設定があります。この設定を「ブロック（block）」にしておくことで、既存の公開コードに酷似した出力が表示されにくくなります。組織で利用している場合は、組織レベルでこの設定を統一しておくと安心です。

AI生成コードのレビュー方針を決める

AI が生成したコードを、人がどこまで確認してからマージするかのルールを持ちます。とくに、ライブラリの追加・大きなコードブロックの貼り付けについては、由来とライセンスを確認するプロセスを入れます。これは本連載第12回（CI/CD ガバナンス）のレビュー文化と直結します。

利用ガイドラインに「ライセンス確認」を明記する

社内の AI 利用ガイドラインに、「外部 OSS を取り込む際はライセンスを確認する」「不明な場合は判断を仰ぐ」といった項目を明記します。ルールが無いと、現場は「動けば OK」で進んでしまいます。

自社事業に合わないライセンスを「使わないリスト」にする

たとえば SaaS を運営する企業なら、AGPL のライブラリは原則使わない、というように、自社の事業形態と相性の悪いライセンスをあらかじめ避ける方針を決めておくと、判断が速くなります。

防衛策その2：SBOMとSCAでライセンスを可視化する

入口の対策に加えて、「いま自社が何を使っているか」を可視化する仕組みが必要です。

SBOM（ソフトウェア部品表）とは

SBOM（Software Bill of Materials）は、ソフトウェアを構成する部品（ライブラリ・依存関係）の一覧表です。どの部品を、どのバージョンで、どのライセンスで使っているかを把握できます。これは本連載第8回（ブラックボックス化）でも触れた考え方で、ライセンス管理だけでなく、脆弱性管理（第11回の SCA）の基盤にもなります。

SCAツールでライセンスを検査する

第11回で紹介した SCA（ソフトウェアコンポジション解析）ツールの多くは、脆弱性だけでなくライセンスも検査できます。たとえば、無料・オープンソースの Trivy は依存関係のライセンス情報を出力でき、商用では FOSSA や Black Duck といったライセンス管理に強いツールがあります。これらを使えば、推移的依存の奥に潜む GPL・AGPL を機械的に発見できます。

目的ツール例補足
まず無料で可視化Trivy依存関係の脆弱性 + ライセンス情報
ライセンス管理を本格化FOSSA / Black Duckポリシー設定・違反検知が充実
CI に組み込むSCA を CI に追加変更のたびにライセンスを再検査

CIに組み込んで継続的に検査する

ライセンス検査も、一度きりでは意味が薄れます。CI（継続的インテグレーション）に組み込み、依存関係が追加・更新されるたびにライセンスを再検査し、自社のポリシーに反するライセンスが入ったら警告・ブロックする、という運用が理想です。これは第11回・第12回の「CI ゲート」の考え方を、ライセンスにも広げたものです。

中堅企業の現実的な導入ステップ（30〜90日）

専任の法務・知財担当がいない中堅企業でも、段階的にライセンス管理を始められます。

ステップ1（〜30日）：現状の可視化

  • AI コーディングツールの「公開コード一致ブロック」設定を有効化する
  • SCA ツール（まずは Trivy など無料のもの）で、依存関係とライセンスを棚卸しする
  • GPL・AGPL など、コピーレフトのライセンスが含まれていないかを確認する

ステップ2（〜60日）：ポリシーとルールの整備

  • 自社事業に合わない「使わないライセンスリスト」を決める
  • AI 生成コード・OSS 取り込みのレビュー方針を文書化する
  • 表示義務（著作権・ライセンス文）を満たす運用を整える

ステップ3（〜90日）：CIへの組み込みと体制化

  • ライセンス検査を CI に組み込み、ポリシー違反を自動で警告・ブロックする
  • 判断に迷う案件のエスカレーション先（社内の責任者・外部の専門家）を決める
  • 定期的に SBOM を更新し、棚卸しを継続する

導入の優先順位

優先度やること
最優先コピーレフト（GPL / AGPL）が製品・サービスに混入していないか確認
高AI ツールの一致ブロック設定 + 取り込みレビュー方針
中寛容型ライセンスの表示義務の順守
継続SCA を CI に組み込み、SBOM を更新し続ける

中堅企業が陥りやすい5つの失敗

1. 「OSSは自由に使える」と思い込む

OSS は「無料で使える」ことと「無条件で使える」ことが別物です。とくにコピーレフト型は、条件を守らないと自社ソースの公開義務が生じます。「自由」を「無条件」と誤解しない、が出発点です。

2. AI生成コードの由来を確認しない

AI の出力を、由来を確認せず製品に貼り付けるケースです。公開コード一致のブロック設定とレビューで、入口を絞ります。

3. 直接依存だけ見て推移的依存を見ない

表層のライブラリだけ確認し、その奥の依存を見ないケースです。SCA ツールで推移的依存まで検査します。

4. SaaSなのにAGPLを警戒していない

「配布していないから OSS ライセンスは関係ない」と考え、AGPL を見落とすケースです。SaaS 事業者は AGPL を特に警戒する必要があります。

5. 一度棚卸しして終わりにする

最初に SBOM を作って満足し、その後更新しないケースです。依存関係は日々変わるため、CI に組み込んで継続的に検査します。

よくある質問（FAQ 10問）

Q1. AIが書いたコードに、本当にライセンスの問題が起きうるのでしょうか？

A. はい、起きうると考えるのが安全です。AI コーディングツールは公開コードを学習しているため、出力が既存 OSS に酷似することがあります。GitHub Copilot 自身が「公開コードと一致する提案」を検知・ブロックする設定を用意していることが、その前提を示しています。

Q2. MITやApacheのライブラリなら、何もしなくてよいでしょうか？

A. いいえ。寛容型でも、著作権表示・ライセンス文の保持が条件です。これを怠ると、寛容型であってもライセンス違反になります。表示義務を満たす運用が必要です。

Q3. GPL汚染とは具体的に何が起きるのでしょうか？

A. GPL の OSS コードを取り込んだ製品を配布すると、その派生物も GPL で公開する義務が生じうる、という現象です。自社で開発したソースコードまで公開を求められる可能性があり、競争力の源泉が露出するリスクになります。

Q4. 自社はSaaSなので、ライセンスは関係ないのではないですか？

A. むしろ注意が必要です。AGPL は、SaaS のようにネットワーク越しに提供する場合もソース公開義務を及ぼすライセンスです（GPL の「SaaS の抜け穴」を塞いだもの）。SaaS 事業者こそ AGPL を警戒すべきです。

Q5. GitHub Copilotの訴訟は、結局どうなったのでしょうか？

A. 公開報道によると、DMCA に関する請求は棄却され（出力が同一でなければ違反に当たらないとの判断）、契約・ライセンス違反などの論点は一部残って上訴審の手続きに移ったと伝えられています。最終的な決着というより、「この問題が現実に争われている」段階と捉えるのが妥当です。最新状況は一次資料でご確認ください。

Q6. ライセンスを確認するツールは無料でありますか？

A. はい。SCA ツールの Trivy は無料・オープンソースで、依存関係の脆弱性に加えてライセンス情報も出力できます。より本格的なライセンス管理には FOSSA や Black Duck などの商用ツールがあります。

Q7. 推移的依存とは何でしょうか、なぜ重要ですか？

A. 自社が直接使うライブラリが、さらに別のライブラリに依存している関係です。表層が MIT でも、奥に GPL や AGPL が潜むことがあるため、奥まで検査する必要があります。SCA ツールで推移的依存まで確認できます。

Q8. ライセンス違反が見つかったら、どう対応すればよいでしょうか？

A. まず該当箇所を特定し、影響範囲を確認します。寛容型の表示漏れなら表示を補い、コピーレフトの混入なら、別ライブラリへの置き換え・自社実装への差し替えなどを検討します。事業への影響が大きい場合は、弁護士など専門家に相談してください。

Q9. AIツールの設定は、どこを変えればよいでしょうか？

A. GitHub Copilot の場合、設定画面の「公開コードに一致する提案（Suggestions matching public code）」を「ブロック（Block）」にします。組織で使う場合は、組織レベルで統一しておくと安心です。

Q10. まず何から始めればよいでしょうか？

A. AI ツールの一致ブロック設定を有効にし、SCA ツール（Trivy など）で依存関係とライセンスを棚卸しすることから始めてください。とくに GPL・AGPL などコピーレフトが製品・サービスに混入していないかを最優先で確認します。

参考一次ソース

  1. OSI（Open Source Initiative）「Licenses」公式一覧
  2. GitHub Docs「Finding public code that matches GitHub Copilot suggestions」（一致検知の設定）
  3. The Register「Judge dismisses DMCA copyright claim in GitHub Copilot suit」（2024年7月・DMCA請求棄却の報道）
  4. The Register「GitHub Copilot copyright case narrowed but not neutered」（請求縮小の報道）
  5. FOSSA「Open Source Software Licenses 101: The AGPL License」（AGPLのネットワーク条項解説）
  6. GNU Project「Licenses」（GPL / LGPL / AGPL 公式）

まとめ

  1. AI コーディングツールは公開コードを学習しており、生成コードが既存 OSS に酷似することがあります。GitHub Copilot 自身が一致検知・ブロック設定を用意していることが、その前提を示します
  2. OSS ライセンスは、寛容型（MIT / Apache）とコピーレフト型（GPL / AGPL / LGPL）に大別され、後者は派生物の公開義務を伴います
  3. GPL 汚染は自社製品のソース公開義務、AGPL は SaaS でのソース公開義務を生じさせうる、特に注意すべきライセンスです
  4. 寛容型でも著作権・ライセンス表示は必須で、AI 生成コードの貼り付けで抜けやすい点に注意します
  5. GitHub Copilot 訴訟（Doe v. GitHub）では DMCA 請求が棄却され、ライセンス・契約の論点が残るなど、法的にまだ固まっていない領域です（最新は一次資料で確認を）
  6. 防衛策は、入口（AI ツールの一致ブロック設定・取り込みレビュー）と、可視化（SBOM・SCA でのライセンス検査、CI 組み込み）の二段構えです
  7. 導入は 可視化（〜30日）→ ポリシー整備（〜60日）→ CI 組み込みと体制化（〜90日）の順が現実的です

「AI に書かせる」を続けるなら、「AI が書いたものの由来とライセンスを管理する」をセットにする。これが、知的財産という観点でバイブコーディングを安全に活用するための一歩です。

AI生成コードのライセンス監査を相談したい方へ

GXO の バイブコーディング監査 + OSSライセンス管理支援サービスでは、中堅企業向けに次のようなご相談を承っています。

  • OSSライセンス監査：既存システムの依存関係を棚卸しし、GPL / AGPL などコピーレフトの混入を可視化
  • SBOM の整備：ソフトウェア部品表の作成と、ライセンス・脆弱性情報の一元管理
  • AIツールの設定・運用ルール策定：公開コード一致ブロック設定、取り込みレビュー方針の整備
  • CI へのライセンス検査組み込み：依存追加のたびにライセンスを自動検査・ポリシー違反を警告
  • 事業形態に合わせたライセンス方針づくり：SaaS 事業での AGPL 回避など、自社に合う方針設計

→ 30 分無料相談を予約する

関連記事

著者: GXO株式会社 初回公開: 2026 年 6 月 5 日 最終更新: 2026 年 6 月 5 日 連載: バイブコーディング危機 第 16 回（全 30 回予定 / 第 4 週・AI 利用特有のリスク）