黒い基板上の抵抗器とコンデンサの接写
技術解説

AIコーディングツールが生むOSSライセンス違反、AGPLの落とし穴

目次を見る

AIコーディングツールにコード生成を任せているエンジニアや、社内でCopilot・Claude Codeなどの導入を進めているテックリードに向けた内容です。生成されたコードのライセンス起源を確認しないまま本番に組み込むと、思わぬ法的リスクを抱え込む可能性があります。

普段何気なく使っているBash、Git、Docker、PostgreSQL、Reactは、いずれも無償で公開されたオープンソースソフトウェア(ソースコードが公開され、誰でも利用・改変・再配布できるライセンスの下で提供されるソフトウェア)です。AIコーディングツールは、こうしたOSSのコードを大量に学習データとして取り込んでいます。つまり生成される補完コードやスニペットには、特定のライセンス条件を引き継ぐ断片が紛れ込んでいる可能性があります。

何が起きるか

AIコーディングツールに「認証処理を実装して」「画像処理のユーティリティを書いて」と指示すると、学習元のOSSコードに酷似した、あるいは一部そのままのコードが出力されることがあります。

出力されたコード自体には、どのライセンスに由来するかという情報は付与されません。開発者はそれをコピーレフトライセンス(改変後のコードも同じ条件で公開する義務を課すライセンス)のコードだと気づかずに、自社の商用プロダクトに組み込んでしまいます。

特に注意が必要なのがAGPL(Affero General Public License)です。GPLと似た性質を持ちますが、ネットワーク経由でサービスとして提供する場合にも改変部分の公開義務が及びます。社内SaaSやAPIサーバーに紛れ込んだ場合、配布していないつもりでも義務が発生する可能性があります。

なぜ起きるか

原因は段階的に分解すると見えてきます。

第一に、AIモデルの学習データにはMITやApache 2.0のような許諾範囲の広いパーミッシブライセンスのコードだけでなく、GPLやAGPLのコピーレフト系コードも大量に含まれています。モデルは「このコードがどのライセンスか」を意識せず、パターンとして学習しています。

第二に、生成結果の提示画面には基本的にライセンス出典が表示されません。Copilotの一部機能には既存コードとの一致を検知する仕組みがありますが、すべてのツール・すべての言語でカバーされているわけではありません。

第三に、開発者側にも「AIが書いたコードは自分のオリジナルだ」という思い込みがあります。手書きのコードなら参照元を覚えていますが、生成コードは出所の記憶が残らないため、レビュー段階でライセンスチェックの発想自体が抜け落ちがちです。

自分のプロジェクトが該当するか確認する方法

まず、リポジトリの依存関係とAI生成コードの範囲を切り分けて確認します。

依存パッケージのライセンスは、Node.jsプロジェクトならpackage.jsonのlicenseフィールドとnode_modules内の各パッケージのLICENSEファイルで確認できます。まとめて洗い出すには次のようなコマンドが使えます。

npx license-checker --summary

これで依存パッケージごとのライセンス一覧が表示されます。MIT・Apache-2.0・ISCが大半で、GPL・AGPLが含まれていないかをまず確認します。

次に、AIツールが直接生成したコード片について、既存OSSとの一致がないかを確認します。GitHub Copilotには「コード参照フィルター(Code Referencing)」という機能があり、公開リポジトリと一致する提案をブロックまたは表示する設定があります。組織のCopilot管理画面(GitHub Organization Settings > Copilot > Policies)で有効になっているかを確認してください。

該当する疑いがあるコードについては、生成された関数名・変数名・コメント文をそのままGitHub検索やGoogle検索にかけると、由来のOSSプロジェクトが見つかることがあります。特にコメントの文体や変数名の癖がそのまま残っているケースは要注意です。

対策の手順

実務でできる対策は次の4点です。

  • 社内ポリシーの明文化: AI生成コードを本番マージする前にライセンス確認を必須とする社内ルールを作り、レビューチェックリストに項目として追加する
  • ライセンススキャンのCI組み込み: license-checkerやFOSSA、SnykなどのライセンススキャンツールをCIパイプラインに組み込み、GPL・AGPL系のライブラリが混入した時点でビルドを失敗させる
  • AIツールの出典表示機能を有効化: Copilotのコード参照フィルターのような、既存コードとの一致検知機能があるツールでは必ずオンにする
  • 重要モジュールは生成後に人力レビュー: 認証・決済・暗号処理など、コピーが疑われやすい定型処理はAI生成後に人間が改めて実装意図を説明できるかを確認する

ライセンススキャンツールを導入する場合、GitHub Actionsなら以下のようなステップを追加するだけで最低限のチェックが回ります。

- name: Check licenses
  run: npx license-checker --failOn 'GPL;AGPL-3.0'

この設定により、GPLやAGPL-3.0のライブラリが依存関係に混入した時点でCIが失敗し、マージ前に気づける状態になります。

まとめ

AIコーディングツールが便利な分、生成コードの由来を意識する機会は減っています。

確認すべきことは大きく3つです。まず依存パッケージのライセンスをlicense-checkerなどで棚卸しすること。次にCopilotなどのコード参照フィルターが有効になっているかを組織設定で確認すること。最後にライセンスチェックをCIに組み込み、人力レビューに頼らない仕組みを作ることです。

OSSは無償で使える代わりに、ライセンスという契約条件が必ず付いています。AIが間に入っても、その条件が消えるわけではありません。

参考

How the Open Source Economy Works — and Why It Powers Almost Everything You Build

この記事について: 本記事は AI を活用して作成し、forva AI 編集部が内容を確認・監修しています。

AI 駆動開発のご相談は forva AI へ。まずはお気軽にどうぞ。