AI生成コードのOSSライセンス｜自動スキャンが必要な理由

サイオステクノロジーは、OSS管理ツール「SCANOSS」の日本国内初の代理店です。

生成AIでコードを書く比重が上がるにつれ、「動くコードは手に入ったが、それを使っていいか」を確かめる工程が抜け落ちるようになりました。テストは通る。脆弱性スキャンを回していれば、それも通る。しかし、そのコードがどこ由来なのかを見る工程は、どちらにも入っていません。

AIが生成したコードに含まれるOSSは、読んで見分けることができません。機械的な照合で見える範囲と、機械にも見えない範囲が残ります。

この記事でわかること:

• 生成されたコードの出所を、読んで見分けられない理由
• OSSが混ざっていた場合に、ライセンス種別ごとに何が求められるか
• 何を見るツールがあり、そのうちコードを見るものはどれか
• 機械的な照合でも判定できない範囲

このコードにOSSは入っているか

次のコードを読んでください。JavaScriptで、文字列をUTF-8のバイト列に変換する処理です。

// convert string to array (typed, when possible)
exports.string2buf = function (str) {
  var buf, c, c2, m_pos, i, str_len = str.length, buf_len = 0;

  // count binary size
  for (m_pos = 0; m_pos < str_len; m_pos++) {
    c = str.charCodeAt(m_pos);
    if ((c & 0xfc00) === 0xd800 && (m_pos + 1 < str_len)) {
      c2 = str.charCodeAt(m_pos + 1);
      if ((c2 & 0xfc00) === 0xdc00) {
        c = 0x10000 + ((c - 0xd800) << 10) + (c2 - 0xdc00);
        m_pos++;
      }
    }
    buf_len += c < 0x80 ? 1 : c < 0x800 ? 2 : c < 0x10000 ? 3 : 4;
  }
  // …（UTF-8バイト列への書き込みは中略）…
  return buf;
};

このコードにOSS由来のものが混ざっているか、読んで判定できたでしょうか。

答えは、このコード自体がOSSです。圧縮ライブラリ pako v1.0.11 の lib/utils/strings.js からの抜粋（MIT）で、後半のバイト列への書き込みは省略してあります。

pako — Copyright (C) 2014-2017 by Vitaly Puzrin and Andrei Tuputcyn / MIT License

見分けられなかったとしても、注意力の問題ではありません。理由は2つあります。

照合すべきOSSが多すぎる

1つ目は単純な話です。世に公開されているOSSのコードすべてと、目の前のコードを突き合わせる作業になります。人間の記憶で照合できる規模ではありません。

そして、これは「珍しく起きること」でもありません。ICSE 2025で発表された LiCoEval は、14のLLMに4,187件のコードを生成させ、既存のOSS実装と強く似ているものがどれだけ含まれるかを測っています。コード生成の性能が高い3モデル（GPT-4o / Claude 3.5 Sonnet / DeepSeek-Coder-V2）では、生成したコードのうち 0.88%〜2.01% が該当しました。14モデル全体で見ると 0.0%〜2.17% まで幅があり、最多はコード生成の性能で下位のCodestral（2.17%）、0件だったのは性能が中位のGLM-4-9B-Chatでした。なお、この測定の対象は2024年時点のモデル群です。モデルは入れ替わるので、この数値がそのまま今のモデルに当てはまるわけではありません。

数字だけ見ると小さく感じますが、この値は下限です。論文自身が測定の限界としてこう書いています。

Our striking similarity standard focuses on precision, potentially overlooking cases where LLMs generate code derived from open-source code but fall below our threshold

（この判定基準は精度を重視しているため、OSS由来のコードを生成していても閾値を下回るケースは見落とす可能性がある）

つまり、実際にはこれより多く起きている可能性があります。

出力に出所の情報が付かない

2つ目のほうが厄介です。人がOSSを持ってくるときは、由来を知っていて、多くの場合ライセンスファイルも一緒に付いてきます。生成された場合は、何も付いてきません。

同じLiCoEvalは、モデルが生成したコードについて、ライセンス情報を正しく示せたかも測っています。コピーレフトライセンス（次章で見るとおり、義務がもっとも重い種別）のコードで出所を正しく示せた割合は、GPT-4o・GPT-3.5 Turbo・GPT-4 Turbo・Gemini 1.5 Pro・DeepSeek-Coder-V2・Codestral のいずれも 0.0。Claude 3.5 Sonnet の 0.4 が唯一の例外でした。

「性能の高いモデルを使えば避けられる」という話でもありません。0.0 が並んでいるモデルには、コード生成の性能で上位3モデルに入る GPT-4o と DeepSeek-Coder-V2 が含まれています。論文自身も、この種のスコアと生成性能が対応しないことに注意を促しています。

a high LICO score, particularly a score of 1 in the absence of any strikingly similar cases, is not meaningful if the model’s code generation performance is poor. Models producing erroneous or chaotic code may naturally avoid striking similarities

（コード生成の性能が低いモデルでは、高いスコア（とくに似た事例が0件で満点になる場合）は意味を持たない。誤ったコードや混乱したコードを出すモデルは、そもそも強い類似を避けてしまう）

つまりこの手のスコアは、性能が低いモデルほど良く見える向きに歪みます。モデルを選び直して解決する問題ではありません。

OSSが混ざっていたら、何をしないといけないのか

「AIが出力したコードの著作権をめぐる争いはまだ決着していないのだから、様子を見ればいい」と考えることもできます。実際、その論点に外から答えは出ていません。

Copilotの出力をめぐる集団訴訟（Doe v. GitHub）は、22件の請求のうち20件が地裁で却下され、契約違反とOSSライセンス違反の2件が係属中です。却下された著作権管理情報に関する請求は控訴され、2026年2月11日に第9巡回区で口頭弁論が行われ、判断を待っている状態です（2026年9月3日時点）。

ただし、混ざっていた場合に何が求められるかは、AIとは関係なく、すでに明文で決まっています。

順に見ていきます。permissiveは「自由に使える」と理解されがちですが、表示の義務は残ります。表示を落とせば条件違反です。

弱コピーレフトは、そのOSS部分を改変したかどうかで変わります。改変して配布するなら、その部分のソースを開示することになります。

強コピーレフトは、影響範囲が自分のコード側に及びます。どこまでが「結合」なのかは配布形態や結合方法で変わるため、ここが最も判断の重い領域です。

ただし、同じ種別でも個別のライセンスごとに条件は違います。上の表は種別ごとに何が付いてくるかの傾向で、実際にどの義務が生じるかは、そのライセンスの条文と、結合の形や配布の方法で決まります。どのライセンスを通すかも、使う側が決めることです。どちらも、どんなライセンスのものが混ざっているかが分かってからの話です。

ツールは何をしてくれるのか

人間が読んで分からないのであれば、機械に照合させることになります。ただし「OSSライセンスを見るツール」とまとめられているものは、何を見ているかがそれぞれ違います。3つに分かれます。

以下は何を見ている道具なのかの分類で、製品どうしの比較ではありません。冒頭に書いた立場のとおり、この分類には当社が扱う製品も入ります。

上から順に、見ている対象がコードの内側へ入っていきます。いちばん下の指紋の照合だけが、宣言にもライセンス文にも現れないコードそのものを見ます。この層は製品が限られており、公式ドキュメントで機能を確認できたのは上の3つでした^{[^1]。}

表に載せていない道具にも触れておきます。依存しているパッケージの問題を知らせる仕組みとして広く入っているのが、GitHubのDependabotのアラートです。見ているのは、表のいちばん上の層です。公式ドキュメントを確認した限り、Dependabotのアラートは脆弱性の検出に限定されていて、ライセンスを見る機能への言及がありません。すでに何かを回しているから、ライセンスまで見えているとは限りません。

AI生成コードの混入が問題になるのは、表のいちばん下が扱う範囲です。宣言されていないコードは、依存の宣言を見るツールには映りません。

[^1]: 同じ層で公式ドキュメントに記述を確認できたものとして、他に FOSSA（ファイル単位の指紋照合・確率的なマッチと明記）と Revenera Code Insight（source-code fingerprints）があります。本記事は各製品の精度・速度・価格の比較は行いません。

機械に任せれば終わりなのか

ここまでで「機械に照合させればよい」という話になりますが、機械にも見えない範囲が残ります。

1つは、手が入るほど当たらなくなることです。指紋の照合が強いのは、そのままの形に近いコードです。書き直されたり、別の言語へ移されたりするほど、照合の手がかりは減っていきます。これは特定の製品の性能ではなく、指紋を照合するという方法そのものの性質です。どこまで手が入ると外れるのかは、道具によって違います。

もう1つは、似ていることが由来の証明にはならないことです。LiCoEvalはこう書いています。

Text similarity alone cannot determine non-independent creation in LLM-generated code. LLMs can produce highly similar code even for unseen samples

（テキストの類似度だけでは、LLMが生成したコードが独立創作でないとは判定できない。学習で見ていないサンプルに対しても、LLMは非常に似たコードを出せる）

似ているコードが出てきたとき、それが取り込みなのか、独立して書かれた結果なのかは、機械の出力だけでは決まりません。もちろん機械検出の製品が100%発見してくれるとも言えません。

ただし、限界があることは、機械に照合させない理由にはなりません。比べる相手は「完璧な検出」ではなく、何も見ていない状態のほうです。完璧に検出できる道具が無いのはこの領域に限りませんが、それでも入れるのは、入れない場合との差が大きいからです。

分担で言うと、機械が担うのは検出までです。出てきたものが本当に取り込みなのかを決めるのは人の側に残ります。この分担を先に持っておくと、ツールの出力を「答え」ではなく「候補」として受け取れます。

手元で動かしてみる場合は、SCANOSS の CLI でローカルスキャンを試す手順を別の記事にまとめています。インストールからスキャン結果の読み方、SBOM の生成までを扱っています。

なぜこの確認が要るのか

AIに書かせたコードは、スキャンにかけて判断するしかありません。 読んで見分けられない以上、出所を確かめる方法がほかに無いからです。

冒頭のコードに戻ります。あれがpako由来だと見分けられなかったのは、照合すべきOSSが多すぎるうえに、生成されたコードには出所が付いてこないからでした。人の目では、どちらも埋められません。書かれる量が増えても、埋まるようにはなりません。

そして、確かめていないことは、混ざっていないことではありません。混ざっていた場合に生じる義務は、すでに決まっています。スキャンしていないコードについて言えるのは「混ざっていない」ではなく、「混ざっているかどうかを言えない」だけです。生成の速度が上がるほど、その状態のコードが増えていきます。

機械が出せるのは候補までで、そこから先は人が判断します。それでも、候補が出てこなければ判断のしようがありません。自分のコードに何が入っているかは、外の答えを待たなくても、確かめれば分かります。