はじめに：その「動くコード」、"使っていいか"は誰か確認しましたか

AIにコードを書いてもらう。もう、当たり前になりましたよね。

正直に言いましょう。僕らはAIが出したコードに対して、だいたい2つのことを確認しています。ひとつは 「ちゃんと動くか」 。もうひとつは、意識が高い現場なら 「安全か（脆弱性はないか）」 。ここまでは、テストを書いたりレビューしたりで、だんだん文化になってきました。

でも、3つ目の問いが、すっぽり抜け落ちてる気がするんです。

それが 「このコード、"ライセンス的に"会社で使っていいの？」 という問いです。

考えてみてください。AIが提案してくれたその20行、実は世界のどこかのGPLライセンスのリポジトリにある実装、ほぼそのままだったら？そのコードをあなたのプロダクトに入れて、お客さんに納品したり、有償SaaSとして売ったりした瞬間、「このプロダクト全体のソースコードを公開してください」という義務が、あとから降ってくるかもしれない。しかも、元のライセンス表示（誰が書いた、どのライセンスか）は、AIの出力からはきれいに剥がれていて、誰も気づかない。

こわいのは、「動く」し「安全」でも、この問題は起きるということなんです。テストは全部グリーン。脆弱性スキャンもクリーン。それでも、由来（来歴）がアウトなら、使っちゃいけない。検証している"軸"が、そもそも違うんですよね。

この記事は、その第3の軸 ―― 「使っていいか（ライセンス）」を、気合いや目視じゃなくて"仕組み"で検証する ための実践ガイドです。無料のツールから始められる4段のパイプラインを、CIに組み込むところまで持っていきます。

この記事の守備範囲（先に線引きしておきます）

これは 「動くが危険なコード（SQLインジェクションやXSSなどの脆弱性）」の話ではありません 。それは別軸の検証で、以前に書きました。

これは 「AIが存在しないパッケージ名をでっち上げる（パッケージ幻覚・slopsquatting）」の話でもありません 。それも別問題です。

この記事が扱うのは、「実在するOSSのコードが、ライセンス表示なしにあなたのコードへ静かに混ざり込む」 という、来歴とライセンスの問題です。

なぜAIの書いたコードに、ライセンスの地雷が埋まるのか

まず「なんでそんなことが起きるの？」を、構造として理解しておきましょう。ここが腑に落ちないと、対策が"お守り"になってしまうので。

理由はシンプルです。大規模言語モデル（LLM）は、大量の公開ソースコードを学習して作られている から。GitHubをはじめとする世界中のOSSが、学習データに含まれています。その中には、自由に使える寛容なライセンスのコードもあれば、GPLやAGPLのような「コピーレフト」 ―― つまり「これを使うなら、あなたのコードも同じ条件で公開してね」という強い条件つきのコードも、当然たくさんある。

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

しかもタチが悪いのは、AIの出力からは、元コードの「ライセンス表示」や「著作者名」が消えている こと。この著作権表示・著者名・ライセンス条項といった情報を、専門用語で CMI（Copyright Management Information／著作権管理情報） と呼びます。人が普通にコピペするなら、まだヘッダーコメントに // Copyright ... が残っていて気づけるんですが、AIは中身のロジックだけを再構成するので、CMIがきれいに落ちる。この現象は 「license laundering（ライセンス・ロンダリング）」 ―― ライセンスの洗浄、と呼ばれたりします。地味だけど、けっこう本質を突いた表現だなと思います。

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

「そんなの、めったに起きないでしょ」と思うかもしれません。ここは煽らず、正確に見ておきましょう。

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が消してしまう来歴を、自分たちの仕組みで取り戻す」姿勢が要る、というわけです。

用語を、ぜんぶ"借り物"のたとえで整理する

ここで一回、専門用語をやさしく揃えておきましょう。AIコードのライセンス問題は、要は 「借り物かもしれないコードを、黙って自分のものとして使っていないか」 の話です。この比喩で全部つながります。

ライセンス … コードという貸し出し品についてくる「借用のルール」。返さなくていいけど、使い方に条件がつく。
permissive（寛容）ライセンス（MIT / Apache-2.0 / BSD など） … 「著作権表示さえ残してくれれば、あとは自由。商用もOK、改変もOK」という、ゆるい貸出条件。基本、味方。
copyleft（コピーレフト）ライセンス（GPL / AGPL / LGPL など） … 「使ってもいいけど、これを含む"あなたの成果物"も同じ条件で公開してね」という、強い条件つきの貸出。これが混ざると、プロダクト全体に条件が"伝染"しうる のが怖いポイント。「感染」とよく比喩されます。
CMI（著作権管理情報） … 貸出品に貼られた「持ち主の名札」。著作者名・著作権表示・ライセンス条項など。AIはこれを剥がしがち。
SPDX … ライセンスに世界共通の"型番"をつけた識別子。MIT、GPL-3.0-only、Apache-2.0 みたいに機械が読める形で書ける。
SCA（Software Composition Analysis） … 「あなたのプロダクトに、どこの誰の借り物が、いくつ入っているか」を棚卸しする作業・ツール。
スニペット照合（snippet scanning） … 借り物リスト（依存パッケージ）だけでなく、"ソースコードの断片そのもの"が既知のOSSと一致していないか を照合する、もう一段深い検査。AIコード対策ではここが効く。
SBOM（Software Bill of Materials） … 「ソフトウェアの部品表（成分表）」。何が・どのバージョンで・どのライセンスで入っているかの一覧。食品の原材料表示みたいなものです。標準フォーマットに CycloneDX（OWASP由来）や SPDX があります。

この地図さえ頭にあれば、これから出てくるコマンドが「あ、名札を確認してるのね」「成分表を作ってるのね」と読めるようになります。

大前提：どこを人間が決めて、どこをAI・ツールに任せるか

手を動かす前に、役割分担を固定します。ここを最初に決めておかないと、「ツールが緑だから出荷OK」みたいな、判断の丸投げ が起きます。ライセンスは最終的に"事業の判断"なので、機械に決めさせてはいけない領域があるんです。

工程	誰がやる	中身
どのライセンスを許可/禁止するか（ポリシー策定）	人間	MIT/Apacheは許可、GPL/AGPLは要審査、など会社の方針として決める
コードの由来・ライセンスの調査（スキャン）	AI・ツール	ScanCodeやSCAで機械的に検出
依存やスニペットの一致検出	ツール	決定的に照合できる部分
コピーレフト混入時に「使う/避ける/書き直す」の判断	人間	事業リスクとして受容するか決める
部品表（SBOM）の生成	ツール	CIで自動生成
最終的な「出荷してよい」の承認	人間	不可逆な行為の最終ゲート

覚え方はいつもの通りです。「What（何を許すか）とWhy（なぜ）は人間、How（どう検出するか）はAI・ツール」 。検出は機械が速くて正確。でも「このリスクを背負って出荷するか」は、人間にしか決められません。

4段の検証パイプラインを組む

ここから本題。AIコードのライセンスを"仕組み"で守る、4段のパイプラインを作ります。いきなり全部やろうとすると重いので、上から順に、できるところから で大丈夫です。まず1段目だけでも、今日入ります。

段① 依存パッケージのライセンスを allowlist で縛る（いちばん軽い最初の一歩）

まずは足元から。AIが pip install や npm install を提案してくるたびに、その依存パッケージのライセンスが「うちで許可してるやつか」を機械的にチェックします。これは既存の無料ツールで一発です。

Node.js（license-checker）の例：

# 依存のライセンス一覧を出す
npx license-checker --summary

# 許可リスト以外が混ざっていたら失敗させる（CIで使える）
npx license-checker \
  --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC" \
  --excludePrivatePackages \
  || { echo "許可外ライセンスの依存が見つかりました"; exit 1; }

Python（pip-licenses）の例：

pip install pip-licenses

# ライセンス別に一覧化
pip-licenses --format=markdown --order=license

# 禁止ライセンスが含まれていたら落とす
pip-licenses --allow-only="MIT License;Apache Software License;BSD License;ISC License (ISCL)" \
  || { echo "許可外ライセンスの依存が見つかりました"; exit 1; }

ポイントは、「許可リスト（allowlist）方式」にすること 。「これはダメ」を列挙する禁止リストだと、知らないライセンスがすり抜けます。「これだけOK、それ以外は全部止めて人間が見る」のほうが、圧倒的に安全なんです。ここは、以前セキュリティの記事で書いた「default deny（迷ったら止める）」と同じ発想ですね。

段② ソースコードの断片そのものをスキャンする（AIコード対策の本丸）

段①は「宣言された依存」しか見られません。でも、AIが埋め込むコードは 依存パッケージじゃなくて、あなたのソースに直接コピーされた断片 です。ここを捕まえるには、ソースレベルのスキャン が要る。無料で定番なのが ScanCode Toolkit（AboutCodeプロジェクト）です。ライセンス・著作権・コードの由来を、ソースから直接検出してくれます。

# インストール（pipで入ります）
pip install scancode-toolkit

# src/ 配下をスキャンして、ライセンス・著作権・URLを検出し、JSONで出力
scancode \
  --license \
  --copyright \
  --url \
  --json-pp scancode-report.json \
  src/

# 出力の中身を軽く確認（検出されたライセンス識別子を拾う）
cat scancode-report.json | python -c "
import json, sys
data = json.load(sys.stdin)
found = set()
for f in data.get('files', []):
    for d in f.get('license_detections', []):
        found.add(d.get('license_expression'))
print('検出ライセンス:', sorted(x for x in found if x))
"

ScanCodeはSPDX形式の識別子で結果を返してくれるので、gpl-3.0 や agpl-3.0 みたいなコピーレフトが検出されたら、そこを人間が精査する、という運用に落とせます。「AIが書いたはずのファイルから、なぜかGPLの痕跡が出た」―― これが見えるだけで、事故率がぐっと下がります。

補足：ScanCodeのようなOSSツールは「ライセンステキストや既知パターンの照合」が主戦場です。もっと踏み込んで "世界中のOSSスニペットのデータベースと断片単位で突き合わせる" ところまでやりたい場合は、Black Duck・FOSSA・FossID といった商用のスニペット照合が強い領域です。まずは無料のScanCodeで土台を作り、規模が大きくなったら商用の段を足す、という順番がいいと思います。

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

検出できたら、次は 「うちのプロダクトには、こういう成分が入っています」を一覧化した部品表（SBOM）を残す 。これは監査・納品・脆弱性対応でも効いてくる、いわば"成分表示ラベル"です。OWASPの CycloneDX が軽量で、ライセンス情報もSPDXで持てます。

# 例: Node.js プロジェクトの SBOM を CycloneDX 形式で生成
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# 例: Python プロジェクトの SBOM を生成
pip install cyclonedx-bom
cyclonedx-py environment --output-format json --outfile sbom.cdx.json

生成したSBOMには各コンポーネントの licenses フィールドが入るので、ここを機械的に走査すれば「禁止ライセンスが成分に含まれていないか」を後段のゲートで判定できます。部品表は、未来の自分（や監査担当）への申し送り なんですよね。「このリリース時点で、何が入っていたか」を後から証明できる。これがあると、いざ問い合わせが来たときに、青ざめずに済みます。

段④ CIで「ライセンスゲート」を作り、コピーレフト混入を止める

最後に、①〜③を 人の善意に頼らず、パイプラインで強制 します。GitHub Actions で、プルリクのたびに走らせる例です。ここでの設計思想は、「決定的に真っ黒なもの（既知の禁止ライセンス）はblockで止める。グレー（未知・判定不能）はwarningにして人間に回す」 。全部blockにすると現場が回らなくなるので、濃淡をつけます。

# .github/workflows/license-gate.yml
name: license-gate

on:
  pull_request:

jobs:
  license-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install scanners
        run: pip install scancode-toolkit

      - name: Scan source for licenses
        run: |
          scancode --license --copyright \
            --json-pp scancode-report.json src/

      - name: Enforce license policy
        run: python scripts/check_license_policy.py scancode-report.json

判定スクリプトはこんな感じ。禁止（コピーレフト）は即失敗、未知ライセンスは警告して人間の目に載せる ようにしています。

# scripts/check_license_policy.py
import json
import sys

# 会社ポリシーとして人間が決める（What/Why は人間の仕事）
ALLOWED = {"mit", "apache-2.0", "bsd-2-clause", "bsd-3-clause", "isc"}
FORBIDDEN = {"gpl-2.0", "gpl-3.0", "agpl-3.0", "lgpl-3.0"}  # コピーレフト = 要注意

def main(report_path: str) -> int:
    with open(report_path, encoding="utf-8") as f:
        report = json.load(f)

    forbidden_hits = []
    unknown_hits = []

    for file in report.get("files", []):
        path = file.get("path", "")
        for det in file.get("license_detections", []):
            expr = (det.get("license_expression") or "").lower()
            if not expr:
                continue
            # 禁止ライセンスの痕跡 = 決定的にブロック
            if any(bad in expr for bad in FORBIDDEN):
                forbidden_hits.append((path, expr))
            # 許可リストにも禁止にも無い = 未知。人間が見る
            elif not any(ok in expr for ok in ALLOWED):
                unknown_hits.append((path, expr))

    for path, expr in unknown_hits:
        print(f"::warning file={path}::未知のライセンス '{expr}' を検出。人間の確認が必要です")

    if forbidden_hits:
        for path, expr in forbidden_hits:
            print(f"::error file={path}::禁止ライセンス '{expr}' を検出。出荷前に必ず対処してください")
        return 1  # CI を失敗させる = マージをブロック

    print("ライセンスチェック: 禁止ライセンスの混入なし")
    return 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

これで、「AIが書いたコードにGPLの痕跡が混ざったまま、こっそりマージされる」という事故を、仕組みとして 止められます。人間がうっかりしても、パイプラインは寝てても働いてくれる。ここが"気合い"と"仕組み"の決定的な差なんですよね。

そもそも、入口を絞る（生成の段階でやれること）

出てきたものを検査するだけじゃなく、「そもそも似すぎたコードを出させない／出たら気づける」 入口の工夫もあります。両論、正直に紹介します。

たとえば GitHub Copilotには「Suggestions matching public code（複製検出フィルタ）」 という設定があります。これは、AIの提案コードと周辺の 約150文字（おおよそ65レキシム以上） を、GitHub上の公開コードのインデックスと照合して、一致・近似が見つかったら ブロックする（Blockモード） か、一致した公開リポジトリとそのライセンスを表示する（Allowモード＋code referencing） 機能です。組織単位でBlockに倒しておけば、"あからさまなコピー"はかなり減らせます。

ただし、正直に言っておくべき限界もあります。この手のフィルタは 「ほぼ完全一致」に近いものを捕まえるのが得意 で、少し変形されたコードや、ロジックだけ同じで書き方が違うケースまでは拾いきれません。だから、入口のフィルタ（ベンダー側の緩和策）と、出口のスキャン（自分たちの検査）は、両方あって初めて意味がある 。どちらか一方に寄りかからないのがコツです。

プロンプト例：AIを「来歴の調査係」として働かせる

ライセンスの最終判断は人間の仕事ですが、調査と整理はAIがめちゃくちゃ得意 です。ここでAIに任せるのは"判断"じゃなくて"下ごしらえ"。3本、そのまま使えるプロンプトを置いておきます。

プロンプト1：生成時に「来歴の自己申告」を義務づける

あなたはコードを生成するアシスタントです。以下のタスクのコードを書いてください。
ただし出力の最後に必ず「来歴セルフチェック」を付けてください:

- この実装は、特定の有名OSS実装と際立って似ている可能性があるか（Yes/No/わからない）
- 似ている可能性がある場合、想定される元プロジェクトとライセンス（推測でよいが「推測」と明記）
- コピーレフト（GPL/AGPL系）に由来する可能性の有無

注意: あなたの申告は「主張」であって「保証」ではありません。
最終判断のため、私が別途スキャン（ScanCode等）で必ず裏取りします。

これは魔法ではありません。研究（LiCoEval）でも、多くのモデルは正しいライセンスを申告できない と分かっています。だからこの申告を 信じてはいけない 。あくまで「怪しい所に人間の目線を寄せる、注意喚起の付箋」として使うのが正解です。

プロンプト2：ライセンス互換性のトリアージ

以下は、あるプロジェクトで検出されたライセンスの一覧です:
（scancode-report.json / SBOM から抽出したライセンス識別子を貼る）

このプロジェクトを「商用の閉じたソース（proprietary）」として配布する前提で、
各ライセンスを次の3段階に仕分けし、根拠を1行ずつ添えてください:
1. そのまま配布可（permissive: MIT/Apache 等、表示義務は残る）
2. 要注意・条件つき（copyleft や特殊条項。何が求められるかを明記）
3. 判定不能（情報不足。何が分かれば判定できるかを明記）

最終判断は人間（法務・責任者）が行います。あなたは分類の下書きに徹してください。
不確実なものを「たぶん大丈夫」と丸めないでください。

プロンプト3：コンプライアンス・レポートの初稿づくり

以下のスキャン結果とSBOMをもとに、経営・法務にも読める
「OSSライセンス・コンプライアンス報告」の初稿を作ってください。
- 検出されたライセンスの内訳（permissive / copyleft / 未知の件数）
- 特に注意すべきファイルとその理由（file:line で示す）
- 推奨アクション（書き直し / 代替ライブラリ / 表示追加 / 人間の審査）
- 未確認・情報不足の項目を「未検証」として明示

事実は貼った資料の範囲だけで書き、資料にない断定はしないでください。

3本に共通するのは、AIに「調べさせて・並べさせて・草案を書かせる」けれど、「決めさせない」 という姿勢です。判断の主語は、最後まで人間に置いておく。

安全に運用するための、外してはいけない4つ

仕組みを入れても、運用を間違えると意味がなくなります。ここは独立して回収しておきます。

コピーレフト混入は「低確率×高影響」。頻度で油断しない。 GPL/AGPLの断片が1つ入るだけで、最悪はプロダクト全体のソース公開義務に波及しうる。「1〜2%だから」ではなく「当たると重い」で身構える。逆に、permissive（MIT/Apache）は表示義務さえ守れば怖くないので、過剰に恐れて開発が止まるのも避けたい。濃淡をつけて怖がる のが正解です。
AIのライセンス申告を、最終判定に使わない。 前述の通り、研究上も多くのモデルは正しいライセンスを申告できません。AIの「これはMITだと思います」は、便利な付箋であって、証拠ではない。必ずScanCode等の決定的なスキャンで裏取り してください。
社内コードや秘密を、外部のスキャンSaaSに無断でアップロードしない。 ライセンススキャンをクラウドサービスに投げるとき、それは「自社の非公開ソースを外に出す」行為でもあります。AIやSaaSに渡す＝外に出る 。契約・データ取り扱いを確認し、機密性の高いコードはローカルで完結するツール（ScanCodeはローカル実行できます）を選ぶ。ここは以前から何度も書いている鉄則ですね。
不可逆な行為（出荷・納品・OSS公開）は、人間の承認ゲートを必ず通す。 CIのライセンスゲートは"門番"であって"最終決裁者"ではありません。グレーが残ったまま、機械の緑だけで世に出さない。世に出したコードは、取り消せない 。取り消せないことは、人間が最後にうなずいてから。

つまずきポイント early warning

つまずき	何が起きる	対策
禁止リスト方式にする	知らないライセンスがすり抜ける	許可リスト（default deny）に倒す
依存スキャンだけで満足	ソースに直接埋まった断片を見逃す	ScanCode等でソースレベルも見る
AIの申告を鵜呑み	誤ったライセンス判定で出荷	決定的スキャンで裏取り
全部をblockにする	現場が回らずゲートが形骸化	真っ黒はblock/グレーはwarningで人間へ
SBOMを作らない	後から成分を証明できない	CIで毎ビルド自動生成

撤退ライン（無理をしない線）

コピーレフトの断片が製品コアに深く食い込んでいる … その場で判断せず、書き直し・代替ライブラリ・法務相談へ切り替える。
ツールが「判定不能」を大量に返す … スキャン設定や対象範囲を見直す。緑にするために基準を甘くしない。
由来がまったく追えないコードが混ざっている … 出荷を止めて、その部分をクリーンルームで書き直す判断も含めて検討する。

おわりに：30秒のスキャンは、明日の自分への「あざっす」

ここまで、AIコードの「使っていいか（ライセンス）」を仕組みで守る話をしてきました。最後に、少しだけ肩の力を抜いて。

僕がこの話を大事だと思うのは、これが 「過去の自分を責めない技術」 だからなんです。

半年後、監査や取引先から「このコード、由来は大丈夫ですか？」と聞かれたとき。SBOMもスキャンログも何もなかったら、当時の自分を責めながら、真っ青な顔で調査に何日も溶かすことになる。でも、今日CIにライセンスゲートを1本入れておけば、そのとき未来の自分は、部品表を一枚出して「はい、確認済みです」と、涼しい顔で答えられる。

これって、「明日の自分が"あざっす"って言ってくれる仕込み」 なんですよね。誰かを責めるためのチェックじゃなくて、未来の自分と、一緒に働く仲間を守るための思いやり。30秒〜数分のスキャンが、そういう装置になってくれる。

そして、こうやって積み上げた「安全に、堂々と出荷できる状態」は、消えない資産になります。動くコードは一瞬で価値を失うこともあるけど、"由来がクリーンで、いつでも証明できる"という信頼 は、あなたのプロダクトの土台として、ずっと積み上がっていく。コードそのものだけじゃなく、それを安心して世に出せる仕組みも含めて、資産（Capital）なんだと思います。

今日の最初の一歩は、たった1つでいい。あなたのリポジトリで license-checker か pip-licenses を1回走らせて、許可リストを書いてみる。 それだけで、第3の軸の入口に立てます。

一緒に、AIと気持ちよく、そして胸を張って作っていきましょう。

生成AI活用エンジニア＆3児のパパ。AI×開発の実践知を毎日発信しています → X: @akira_papa_AI

参考リンク（一次情報・事実照合先）

LiCoEval: Evaluating LLMs on License Compliance in Code Generation（arXiv:2408.02487） https://arxiv.org/abs/2408.02487 ／ベンチマーク https://github.com/osslab-pku/LiCoEval
GitHub Copilot Litigation（Doe v. GitHub）ケース更新 https://githubcopilotlitigation.com/case-updates.html ／論点解説 https://www.bakerlaw.com/the-copilot-litigation/
GitHub Docs: Finding public code that matches GitHub Copilot suggestions（複製検出フィルタ） https://docs.github.com/copilot/using-github-copilot/finding-public-code-that-matches-github-copilot-suggestions
ScanCode Toolkit（AboutCode） https://github.com/aboutcode-org/scancode-toolkit
CycloneDX（OWASP SBOM標準／Tool Center） https://cyclonedx.org/
FOSSA: Snippet scanning explained https://fossa.com/blog/snippet-scanning-explained/

（注記: 本記事のコードは説明用の最小例です。license-checker / pip-licenses / scancode / GitHub Actions の各コマンド・オプションは公式ドキュメントに基づいて記載していますが、実行はお使いの環境・バージョンで確認してください。Pythonの判定スクリプトはロジックの雛形であり、実データでの動作は各自でご確認ください＝動作未確認の雛形として扱ってください。法的判断については、必ず自組織の法務・専門家にご相談ください。筆者は法律の専門家ではありません。）