AI生成コードのライセンス確認｜依存関係・NOTICE・配布前チェック

「AI生成コードのライセンス」を一つの欄で管理すると、確認の漏れが起きます。AIが新しく書いたように見える行、既存コードへ似た行、AIが提案した依存パッケージ、画像やサンプル設定などの非コード資産は、同じ資料から生まれたとは限りません。最初に変更差分を分解し、どの対象について根拠を集めているかを決めます。

ここでいうライセンス確認は、法的な結論を自動で出す作業ではありません。利用許諾、表示、ソース開示、同一条件での配布など、候補となる義務を見つけて、契約や配布形態と照合する入口です。判断できない部分は、コードレビューの最後に隠すのではなく、公開前の法務確認へ切り出します。

社内で使うだけなのか、顧客へSaaSとして提供するのか、実行ファイルやライブラリを配布するのかでも、確認すべき事実は変わります。AIコーディングの社内ルールへ、ライセンス確認の担当者と記録場所を追加しておくと、ツールごとの運用に閉じません。

AIの回答欄を保存することだけが来歴管理ではありません。どのIssueや仕様から生成したか、どの提案を採用したか、既存コードをどこまで参照したか、誰が変更をレビューしたかを、コミットやPull Requestからたどれるようにします。生成物が新規実装なのか、既存の社内コードを変換したものなのかで、確認の質問は変わります。

既存コードと似ている行が見つかった場合、類似しているから直ちに問題だとも、AIが書いたから問題ないとも決めません。検索で見つかった公開コード、社内の過去実装、依頼したプロンプト、採用した提案を分けて記録します。取得元が確認できないスニペットや、ライセンス表記が切れたサンプルは、利用を止めて担当者へ戻します。

差分レビューでは、関数名やコメントだけでなく、エラー処理、テストデータ、設定例、READMEの文章にも同じ確認を行います。コードだけを調べて、同じPRに含まれるサンプル設定や画像を忘れると、配布時のNOTICEが不完全になります。

AIが提案した一行のimportでも、プロジェクトへ新しいパッケージを追加します。まずマニフェストとロックファイルの差分を見て、直接追加されたパッケージ、そこから解決された間接依存、更新された既存依存を分けます。パッケージ名が正しいか、配布元が意図したものか、利用する機能に対して依存が必要かも確認します。

GitHubの[Dependency graphに関する公式説明](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph)は、リポジトリの依存関係を把握するための仕組みを説明しています。Pull Requestでの[依存関係の変更レビュー](https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-dependency-changes-in-a-pull-request)も補助になります。ただし、ツールに表示されない依存や、リポジトリ外から持ち込んだコードまで自動で無罪にするものではありません。

確認結果が空でも、マニフェスト、ロックファイル、生成物のライセンス表記を人が読みます。依存を追加するPRには、追加理由、バージョン、ライセンス確認、脆弱性確認、削除条件を同じ本文へ置き、レビュアーがコード差分から行き来できるようにします。

SPDXは、ソフトウェアのライセンスや部品情報を交換するための標準仕様と識別子を提供しています。[SPDXの仕様一覧](https://spdx.dev/use/specifications/)と公式のライセンス情報を使うと、チーム内で「MITっぽい」「商用可のはず」といった曖昧なメモを減らせます。識別子を記録することは、個別契約や利用条件の確認を省略することではありません。

依存パッケージのライセンス欄からNOTICEを機械的に作る場合も、対象範囲と生成日時を残します。依存が要求する表示、著作権表示、ソース提供、同一条件の配布などが、どのファイルに置かれたかを確認します。ライセンスの文章を短く要約して、原文の条件を消す運用は避けます。

自社コードのライセンスと、組み込んだ第三者部品の条件は別の欄で管理します。プロダクトのLICENSE、第三者一覧、NOTICE、配布物のREADMEを突き合わせ、抜けた部品や古いバージョンの記載がないかを確認します。義務の解釈に争いがある、SaaSと再配布の境界が曖昧、契約で追加条件がある場合は、公開を止めて法務へ相談します。

ライセンス表を作ったら、次に何を誰へ渡すかを確認します。社内サーバーだけで動かす、顧客へSaaSとして提供する、実行ファイルを配布する、SDKやライブラリとして再利用される、といった形では、必要な通知や提供物の候補が変わります。ここを曖昧にして「商用利用可」とだけ書くと、後から配布物の不足が見つかります。

公開の判断表では、ライセンス名だけでなく、利用形態、第三者への渡し方、変更の有無、NOTICEの同梱場所、ソースを求められた場合の対応者を並べます。Webアプリだからすべて同じ、と決めず、外部へ配布する静的ファイル、CLI、コンテナ、学習データ、サンプルコードも対象に含めます。

法務確認が必要な条件は、失敗した後に発見しやすい条件から決めます。コピーの可能性が高い、ライセンス本文が見つからない、互換性の判断ができない、顧客契約と配布条件が衝突する場合は、公開日を優先せず、対象を隔離して確認します。

公開前の最終確認は、「ライセンスに問題がない」という一文では足りません。変更差分、依存差分、表記ファイル、配布物、未確認事項を同じPRからたどれることを受け入れ条件にします。Codexのコードレビューを追加レビュアーとして使う場合も、来歴、契約、配布形態の最終判断は人が行います。

レビュアーは、コードの生成元を推測して承認しません。確認できた根拠と、確認できなかった範囲を分け、未確認範囲を公開から外すか、法務・責任者へ返します。ライセンス確認を自動化するほど、ツールが扱わない入力をPRテンプレートで明示することが重要です。