AI生成コードのオープンソースライセンス確認──「AIが書いたから自社のもの」と納品しない。依存パッケージと断片の混入を点検する5つの手順と、納品時のライセンス一覧

この記事は、AI生成コードに含まれうるオープンソースのライセンスを、納品前に確認する手順を扱います。

「このコード、どこかで見たことがあるのですが」

納品から半年後、お客様の社内のエンジニアから質問が届きました。
「管理画面のこの処理、公開されているライブラリとほぼ同じに見えます。ライセンスの表記はどこにありますか」

担当者は、AIが出したコードをそのまま使っていました。元のコードがあることも、そのライセンスも、確かめていませんでした。
契約書には「成果物の著作権は、すべて甲に移転する」と書いてありました。

AI生成コードのライセンス確認とは、納品物に含まれる他人のコードを洗い出し、それぞれの条件を守った形で渡すための点検である

黒字化の外科医です。AI生成コードとオープンソースのライセンスの点検を、納品前の手順として解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

点検を手順にすべき理由は、三つあります。

第一に、オープンソースは「無料で自由」ではなく「条件つきで利用できる」ものだから。
多くのライセンスは、著作権の表示やライセンスの文を残すことを、利用の条件にしています。

第二に、ライセンスによって、条件の重さが大きく違うから。
MITやBSD、Apache License 2.0のような、比較的条件の軽いライセンスがある一方で、GPLのように、配布するときにソースコードを同じライセンスで提供することを求めるもの（コピーレフト）があります。

第三に、AIの出力は、元のコードの出どころを示さないことがあるから。
依存パッケージはファイルから一覧にできますが、AIが書いた「断片」は、どこかの公開コードと一致していても、出力だけでは分かりません。

AIの出力と公開コードの一致：確認できる仕組みの例

一致を確かめる機能を持つツールもあります。GitHubの公式ドキュメント（2026年10月25日に確認）では、GitHub Copilotの「コード参照」について、次のように説明されています。

・Copilotの提案を、GitHub.com上の公開リポジトリのコードと照合する
・非公開のリポジトリや、GitHub以外で公開されているコードは照合の対象外
・一致したコードの出どころとライセンスの情報を確認できる
・アカウントや組織の設定によって、一致する提案を表示しないこともできる
・公開コードとの一致は、通常、提案の1パーセント未満

ほかのツールで同じ機能があるかは、公式の資料で確認してください。
この機能があっても、照合の対象は限られます。「機能があるから点検は不要」にはなりません。

今すぐ試せる：依存パッケージのライセンスを仕分けるプロンプト

私はWeb制作会社の経営者です。納品前に、成果物に含まれるオープンソースの
ライセンスを仕分けてください。

【前提】
・依存パッケージの一覧（package.json、composer.json などの内容）：〔貼り付け〕
・成果物の提供のしかた：〔お客様のサーバーに設置／アプリとして配布／SaaSとして提供〕

1. 各パッケージのライセンスを、ライセンスの名前が分かる範囲で一覧にする。
2. 「条件の軽いもの」「コピーレフト」「ライセンス不明」に分ける。
3. 「コピーレフト」「ライセンス不明」について、人が公式の情報で確かめるべき点を挙げる。
4. 納品物に残すべき表記（著作権の表示、ライセンスの文）を整理する。
推測で書いたライセンスには「要確認」と付けること。最終的な判断はしないこと。

AIの答えは推測を含みます。ライセンスの名前は、必ず各パッケージの公式のリポジトリやライセンスのファイルで確かめてください。

ライセンス点検工場：納品前の5つの手順

手順1：依存パッケージを一覧にする

□ パッケージの管理ファイルと、ロックファイルから一覧を出す
□ 名前、バージョン、ライセンスの3列にする
□ ライセンスを一覧にするツールを使う場合も、結果を人が見る

手順2：条件の重いもの・不明なものを仕分ける

□ GPL・AGPLなどのコピーレフトのライセンスがないか
□ ライセンスが書かれていない（不明の）パッケージがないか
□ 「商用不可」など、独自の条件のものがないか
→ 1つでもあれば、使うかどうかを社内で判断し、必要ならお客様に相談する

配布に当たるかどうか、どこまでが同じライセンスの対象になるかは、提供のしかたで変わります。判断がつかないものは、専門家に確認してください。WordPressのプラグイン・テーマとGPLの関係は、こちらで扱っています。

▶ WordPressプラグイン開発の受託、納品した後の「動かなくなった」は誰の責任か──本体・PHPの更新への追従、保証の範囲、権利とライセンス、保守料の計算例

手順3：AIが書いた「断片」を点検する

□ AIがまとめて出力した長い処理（目安：数十行以上）を一覧にする
□ 特徴的なコメント、他社名、作者名、URLが残っていないか見る
□ 一致を確かめる機能があるツールでは、その結果を記録する
□ 気になる断片は、特徴的な行で検索し、元のコードがないか確かめる
□ 元のコードが見つかったら、そのライセンスに従うか、書き直す

手順4：表記を残す

□ 依存パッケージのライセンスのファイル・著作権の表示を消していない
□ 元のコードを使った断片には、元の表示を残した
□ ビルドの過程で、表記が削られていないか確かめた

手順5：納品物にライセンスの一覧を添える

【オープンソース・ライセンス一覧】案件名：〇〇　確認日：〇年〇月〇日
名前｜バージョン｜ライセンス｜確認した情報の場所
〔　〕｜〔　〕｜MIT｜公式リポジトリのLICENSE
〔　〕｜〔　〕｜Apache-2.0｜公式リポジトリのLICENSE
AIの出力で、公開コードとの一致を確認した方法：〔　〕
確認者：〇〇

点検の時間を見積書に載せる（例）

例：時間単価8,000円、依存パッケージ80件、AIの長い出力15か所の案件

一覧の作成と仕分け：1.5時間
コピーレフト・不明の確認：1時間
AIの断片の点検：15か所 × 6分 ＝ 90分（1.5時間）
一覧表の作成：0.5時間
合計：1.5 ＋ 1 ＋ 1.5 ＋ 0.5 ＝ 4.5時間
見積書の計上：4.5時間 × 8,000円 ＝ 36,000円

（例の数字です。時間は自社の実績で置き換えてください）

構造的なリスク

逆説を指摘しておきます。

点検の手順を作ると、「一覧を出したから大丈夫」と、AIの断片の点検が形だけになりがちです。
けれど、依存パッケージの一覧は、ファイルから機械的に出せます。見落としが起きるのは、出どころが分からない断片のほうです。

断片の点検を毎回すべてやるのが重いなら、「AIに長い処理を丸ごと書かせない」「既存のライブラリを使うなら、AIに書き写させず、パッケージとして入れる」という書き方のルールのほうが、効きます。

よくあるQ&A

Q. AIが書いたコードは、すべて自社の著作物として渡せるのか？

すべてとは言えません。他人のコードと一致する部分は、そのライセンスに従います。渡し方は、納品物の権利の条項で「オープンソースの部分は移転の対象外」と分けて書くのが安全です。

Q. GPLのパッケージは、受託の案件で使ってはいけないのか？

一律に禁止されているわけではありません。条件を守れるか、お客様がその条件を受け入れられるかの問題です。事前にお客様に説明し、判断がつかなければ専門家に確認してください。

Q. 実在しないパッケージをAIが提案する問題とは、別の話か？

別の点検です。ライセンスの前に、パッケージが本物かを確かめる必要があります。その点検は、こちらで扱っています。

▶ AI生成コードのセキュリティ、「動いたから納品」をやめる社内ルール──人が確かめる5つの観点、実在しないパッケージの確認、記録の型

最後に

AI生成コードのライセンス確認は、「AIが書いたから自社のもの」という思い込みを、納品の前に点検で外す作業です。

依存パッケージを一覧にし、AIの断片の出どころを確かめ、ライセンスの一覧を納品物に添えた会社だけが、半年後の「どこかで見たコード」を、慌てずに説明できるのです。

オープンソースの扱いを、契約の条項に入れる文例は、キットにまとめました。

▶ AI駆動開発の契約条項キット──AI利用の告知、レビューとテストの責任分担、ライセンス、機密情報、検収と不適合の期間の文例と、そのまま添える別紙3種

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #オープンソース #ライセンス #AI生成コード #GPL #納品 #制作会社経営 #中小企業 #リスク管理 #AI駆動開発