生成AIニュース 2026年7月17日

AIが書いたコード、ライセンス的に会社で使っていいですか？ — 「動く・安全」だけでは足りない第3の検証軸

AIが書いたコード、ライセンス的に会社で使っていいですか？——「動く・安全」だけでは足りない第3の検証軸

AIにコードを書いてもらうのは、もう珍しいことじゃない。ほとんどの開発現場で当たり前になってきた。

そして多くの現場では、AIが出したコードに対して2つのことを確認している。「ちゃんと動くか」と「安全か（脆弱性はないか）」。テストを書き、セキュリティスキャンをかける。これは文化として根付いてきた。

でも、3つ目の問いが抜け落ちている。

「このコード、ライセンス的に会社で使っていいの？」

これが本稿のテーマだ。「動く」「安全」を確認する軸は整ってきたが、「使っていいか（来歴・ライセンス）」を検証する仕組みを持っている現場はまだ少ない。qiita.com の @akira_papa_AI（あきらパパ）氏が書いた実践ガイドを起点に、この問題の構造と対処を整理する。

なぜAI生成コードにライセンスの地雷が埋まるのか

理由は構造的にシンプルだ。

大規模言語モデル（LLM）は、GitHubをはじめとする大量の公開ソースコードを学習して作られている。その中には MIT や Apache-2.0 のような「著作権表示だけ残せばあとは自由」という寛容なライセンスのコードもあれば、GPL や AGPL のような「これを使うなら、あなたの成果物も同じ条件で公開してね」というコピーレフトのコードも当然含まれている。

AIは学習したパターンを再構成して出力する。多くの場合はオリジナルに近い「新しい」コードだが、ときどき学習元のコードと striking similarity（際立った類似性） を持つ断片を吐き出すことがある。法律の世界でこの言葉が使われるとき、意味するのは「偶然ここまで似ることはあり得ない＝実質コピーとみなせる」レベルの類似だ。

さらに問題なのは、AIの出力からは元コードの「著作者名」「著作権表示」「ライセンス条項」――これらを総称して CMI（Copyright Management Information／著作権管理情報） と呼ぶ――が消えていること。人間が普通にコピペするなら、ヘッダーコメントに // Copyright ... が残って気づけるが、AIはロジックだけを再構成するのでCMIがきれいに落ちる。

これが 「ライセンス・ロンダリング」 と呼ばれる現象の正体だ。借り物のコードから、持ち主の名札だけが消える。

数字で見ると、どのくらいの頻度か

「そんなの、めったに起きないでしょ」という感覚は理解できる。だから煽らずに数字で見ておく。

LiCoEval（arXiv:2408.02487）という研究は、14種類のLLMを評価している。その報告によれば、最も優秀なモデルでも、生成コードの 0.88〜2.01% が既存のOSS実装と「striking similarity」を持っていた。そしてほとんどのLLMは、その類似コードについて正しいライセンス情報を申告できなかった。特にコピーレフトなライセンスで顕著だったという。

「たった1〜2%か」と読むか、「50〜100回に1回は地雷を踏みうる」と読むか。

ここからは見方だが、後者で捉えるべきだと思う。これは典型的な 低確率×高影響の非対称リスク だ。ほとんどは無害。でも、1回でもコピーレフトのコードを製品に取り込んで、それが表沙汰になれば、「プロダクト全体のソース公開義務」や「取引先との契約トラブル」まで影響が跳ねる。期待値として無視できない。

法的な状況についても触れておく。GitHub Copilot をめぐって OSS 開発者らが起こした訴訟（Doe v. GitHub、2022年11月提訴）は続いており、多くの請求は2024年までに退けられたが、「AIの出力からCMIを剥がすことが DMCA（デジタルミレニアム著作権法）§1202(b) 違反にあたるか」という論点が残り、2026年2月に米連邦第9巡回控訴裁判所で口頭弁論が行われた。この記事執筆時点では判決は出ていない。

判決の予測はしない。ただ「ライセンス表示や来歴（provenance）を保つことは、それだけ重く見られている論点なんだ」という感覚は持っておいてほしい。

「検証の軸が違う」という問題——構造として理解する

ここが本質だと思う。

テストが全部グリーン。脆弱性スキャンもクリーン。それでも、コードの由来（来歴）がアウトなら、使っちゃいけない。「動く」「安全」を確認するツールは、来歴は見ていない。検証している軸が、そもそも違うのだ。

これはツールの問題ではなく、確認すべき問いを設定できていない問題だ。多くの開発現場では、AIコードを使い始めるとき「ライセンス的に大丈夫か」という問いを立てる文化がまだない。セキュリティが「脆弱性スキャンをCIに入れる」という文化になるのに数年かかったように、ライセンス確認もこれから文化にしていく段階にある。

もうひとつ強調したいのが、判断の丸投げリスクだ。ツールが緑だから出荷OK、という運用は危ない。ライセンスの「どれを許可し、どれを禁止するか」はポリシー、つまり事業の判断だ。機械に決めさせてはいけない領域がある。

役割分担はこう整理できる。「What（何を許すか）とWhy（なぜ）は人間、How（どう検出するか）はAI・ツール」。検出は機械が速くて正確。でも「このリスクを背負って出荷するか」は人間にしか決められない。

4段パイプラインの実際——何をどのツールでやるか

具体的な手を動かす話に入る。元記事が提案する4段構成を整理する。

段①：依存パッケージのライセンスを allowlist で縛る

まず足元から。AIが pip install や npm install を提案するたびに、その依存パッケージのライセンスが許可リストに入っているかを機械的にチェックする。

Node.js なら license-checker、Python なら pip-licenses で一発だ。ポイントは allowlist（許可リスト）方式にすること。「これはダメ」を列挙する禁止リストだと、知らないライセンスがすり抜ける。「これだけOK、それ以外は全部止めて人間が見る」ほうが圧倒的に安全――いわゆる「default deny」の発想だ。

段②：ソースコードの断片そのものをスキャンする

段①では「宣言された依存」しか見られない。AIが埋め込むコードは依存パッケージではなく、あなたのソースに直接コピーされた断片だ。ここを捕まえるにはソースレベルのスキャンが要る。

無料で定番なのが ScanCode Toolkit（AboutCodeプロジェクト）。ライセンス・著作権・コードの由来をソースから直接検出し、SPDX形式の識別子で返してくれる。gpl-3.0 や agpl-3.0 が検出されたら、そこを人間が精査する運用に落とせる。「AIが書いたはずのファイルから、なぜかGPLの痕跡が出た」――これが見えるだけで事故率はぐっと下がる。

もっと踏み込んで「世界中のOSSスニペットのデータベースと断片単位で突き合わせる」ところまでやりたい場合は、Black Duck・FOSSA・FossID といった商用ツールの領域になる。まず無料のScanCodeで土台を作り、規模が大きくなったら商用ツールを足す、という順番が現実的だ。

段③：SBOM（部品表）を自動生成して成分を可視化する

検出できたら次は記録だ。「うちのプロダクトには、こういう成分が入っています」を一覧化した SBOM（Software Bill of Materials） を残す。食品の原材料表示に近いもので、監査・納品・脆弱性対応でも効いてくる。OWASPの CycloneDX が軽量で、ライセンス情報もSPDX形式で持てる。CIで自動生成することで、成分表示が常に最新の状態になる。

段④：CIゲートで人間の承認を残す

どれだけツールを揃えても、最終的な「出荷してよい」の承認は人間が行う。不可逆な行為の最終ゲートは機械に渡さない。これが4段目だ。

実務的な示唆——何から、どの順番で始めるか

全部いきなりやろうとすると重い。上から順に、できるところから入ればいい。

まず今日できることは段①だ。license-checker か pip-licenses を既存のCIに1行追加するだけで始められる。許可リストを定義する作業も含めて、数時間以内に入る。これだけでも、依存パッケージのライセンス問題はかなり防げる。

次のステップとして段②のScanCodeを入れる。初回スキャンは時間がかかるが、検出結果を見ることで「自分たちのコードベースに今どんな来歴のものが混ざっているか」が初めて見える。これは認識を変えるきっかけになる。

段③のSBOM生成は、納品先や社内監査から求められるようになってからでも遅くない。ただ、作る習慣だけは早めに持っておくといい。法規制の方向性として、ソフトウェアの部品表を求める動きは米国・EUともに強まっている。

一点、先に決めておくべきことがある。どのライセンスを許可し、どれを要審査・禁止にするかというポリシーだ。MIT・Apache-2.0・BSD は許可、GPL・AGPL は要審査、というような方針を、法務や経営と一緒に言語化しておく。ここが曖昧なままツールを入れても、アラートが出たときに誰も判断できない。