AIが書いたコードで確かめるライセンス5項目｜納品する前の点検手順

ギットハブの公式の説明によると、Copilot の提案が公開されているコードと一致するのは、提案全体の1パーセント未満です。照合は周囲のおよそ150文字を使って行われ、一致すると元のファイルの場所とライセンスの名前が表示されます。さらにマイクロソフトは、2026年4月3日以降、ギットハブの製品については一致を遮断する機能を使うことを補償の条件から外しました。数字だけを見ると、混ざる心配はほとんど無いように思えます。しかし、ライセンスの点検はAIの出力の一致率の話ではありません。本当は、自社が何を使い、何を社外に出すのかを、誰が記録して説明できるかの話です。この記事では、AIが書いたコードとAIが勧めた部品について、納品する前に確かめる5項目と、それを社内で続けるための運用を整理します。

一致は1パーセント未満。それでも納品前の点検が要る理由

1パーセント未満という数字は、提案1件あたりで見れば小さく見えます。ところが開発の現場では、AIの提案を1日に何十回、何百回と受け入れます。1本の納品物に含まれる提案の数が増えれば、そのうちいくつかが公開コードと一致している可能性は無視できなくなります。確率が低いことと、点検が要らないことは別の話です。

しかも、この数字はコードの断片が一致した割合であって、ライセンスの問題が起きる経路の全部ではありません。AIに「この処理をする部品はあるか」と聞けば、公開されている部品の名前と導入の手順が返ってきます。そのまま入れれば、部品のライセンスの条件ごと自社のコードに入ります。断片の一致よりも、部品を丸ごと入れる経路のほうが、影響は大きくなりがちです。

もう一つの理由は、納品先に説明を求められる場面が増えていることです。取引先から「オープンソースの利用状況を示してほしい」と求められたとき、AIで作ったので分からない、とは答えられません。点検は、問題を見つけるためだけでなく、何を確かめたかを後から示せるようにするための作業でもあります。

ライセンスの型を3つに分けて覚える

オープンソースのライセンスは種類が多く、全部を覚える必要はありません。点検の実務では、大きく3つの型に分けて考えると判断が速くなります。1つ目は、著作権の表示を残せば改変も配布も販売も認められる寛容型です。エムアイティーやアパッチと呼ばれるものがここに入ります。ソースコードを公開する義務はありません。

2つ目は、改変したものや組み込んだものを配布するときに、ソースコードの公開を求めるコピーレフト型です。代表的なジーピーエルでは、公開義務が及ぶきっかけは配布です。3つ目は、配布しなくても、ネットワーク越しにサービスとして提供するだけで公開義務が及ぶ型で、エージーピーエルがこれにあたります。社外に配っていないから大丈夫、という感覚のまま3つ目の型を使うのが、いちばん危ないと、解説記事でも繰り返し指摘されています。

型	代表的な呼び名	主な条件	点検での扱いの目安
寛容型	エムアイティー、アパッチなど	著作権表示とライセンス文を残す。公開義務はない	表示義務を満たしていれば受け入れやすい
コピーレフト型	ジーピーエル、エルジーピーエルなど	組み込んだものを配布するとき、ソースの公開を求められる	配布するかどうかで判断が分かれる。相談に回す
ネットワーク提供でも及ぶ型	エージーピーエルなど	サービスとして提供するだけで公開義務が及ぶ	社外向けのサービスでは原則として止める
ライセンス不明	記載が無い・読み取れない	使ってよい根拠が無い	使わない。出どころを確かめる

表の右端は、あくまで点検の入口の目安です。同じ型でも条項の細部で扱いが変わることがあり、個別の結論は法務や専門家の確認を経ます。点検をする人の役割は、結論を出すことではなく、どの型が混ざっているかを見つけて、判断する人の机に載せることです。

混ざる経路は2つ：AIが書いた断片と、AIが勧めた部品

ライセンスの条件が自社のコードに入り込む経路は、大きく2つあります。1つは、AIが書いたコードの断片が、学習に使われた公開コードとほぼ同じ形で出てくる経路です。コード生成AIは公開されているソースコードを学習しており、出力がもとのひな型とよく似た形になることがあると、ライセンス管理の道具を扱う会社の解説でも指摘されています。

もう1つは、AIが勧めた部品を取り込む経路です。こちらは断片の一致とは違い、導入した時点で部品全体の条件が自社に入ります。さらに、その部品が内部で別の部品を使っていれば、その条件もついてきます。自分で選んだ覚えのない部品の条件まで背負うことになるのが、この経路の厄介なところです。

2つの経路は、確かめ方が違います。断片は、AIの道具が持つ一致の検出や、断片を照合する道具で探します。部品は、取り込んだ部品の一覧を作って、それぞれのライセンスを調べます。どちらか一方だけを見ていると、もう一方の経路から入ったものを見落とします。5項目は、この2つの経路を両方ふさぐように並べています。

確かめる5項目の全体像

納品する前、あるいは社内のツールとして使い始める前に確かめるのは、次の5項目です。順番にも意味があり、前の項目の答えで次の項目の重さが変わります。とくに3つ目の「社内利用か配布か」は、1つ目と2つ目で見つけたものをどう扱うかを決める分かれ目になります。

• 項目1：AIの提案に、公開されているコードとの一致が出ていないか
• 項目2：取り込んだ部品と、その部品が使う部品のライセンスは何か
• 項目3：社内で使うだけか、社外に配布・提供するのか
• 項目4：著作権表示とライセンス文を残す義務を満たしているか
• 項目5：使っているAIの提供元の補償が効く条件を満たしているか

5項目のうち、項目1と項目2は道具で洗い出せる部分が大きく、項目3と項目5は契約と事業の形を知っている人でないと答えられません。項目4はその中間で、洗い出しは道具、添え方の判断は人です。誰がどの項目を見るのかを先に決めておくと、点検が1人の担当者に積み上がることを防げます。

項目1：AIの提案に、公開コードとの一致が出ていないか

主要なコード生成AIには、提案が公開コードと一致したときに知らせる機能があります。ギットハブの Copilot では、提案と周囲のおよそ150文字を、公開リポジトリ全体の索引と照合します。一致すると、元のコードがあるファイルの場所と、そのライセンスの名前が表示されます。2026年2月には、指示を受けて作業を進めるエージェントの機能でも、一致したコードが作業記録に元のコードへの案内付きで表示されるようになりました。

アマゾンの開発者向けAIにも、同じ役割の機能があります。多くの開発環境で既定でオンになっており、受け入れた提案に参照がある場合は、参照の記録に、受け入れた位置、ライセンス、参照元、該当する断片が残ります。管理者は組織全体で、参照付きの提案そのものを出さない設定にでき、その場合は個人の設定では戻せません。一致を知らせる設定にするか、一致する提案を出さない設定にするかは、会社として先に決める項目です。

知らせる設定を選んだ場合、点検では、その記録を見ればよいことになります。納品物ごとに、一致の表示が出たかどうか、出たならどのライセンスで、そのコードを残したのか書き直したのかを記録します。記録の仕組みが道具の中にあるなら、その記録を納品物の点検記録に写すところまでを手順に入れておきます。道具の画面に残っているだけでは、担当者が替わったときに追えません。

一致の検出には、見えないところがある

一致の検出は便利ですが、万能ではありません。ギットハブの説明にも限界が書かれています。短い断片は一致として検出されないことがあり、ライセンスの情報が得られない場合もあります。索引の更新は数か月おきなので、最近公開されたコードや削除されたコードは正しく反映されないことがあります。そして、非公開のリポジトリにあるコードは照合の対象外です。

つまり、一致の表示が出なかったことは、混ざっていないことの証明にはなりません。重要な納品物では、AIの道具とは別に、コードの断片を公開ソースと照合する道具や、取り込んだ部品の構成とライセンスを調べる道具を使う会社もあります。こうした道具は、開発の流れの中に組み込み、変更のたびに自動で走らせる使い方が勧められています。

どこまでの道具を入れるかは、納品物の性格で決めます。社内で数人が使う小さな道具と、取引先の製品に組み込まれるコードでは、求められる確かさが違います。どの種類の納品物に、どの点検をかけるかを表にしておくと、毎回その場で判断する必要がなくなります。

• 一致の表示は「このコードに似たものが公開されている」という知らせで、「このコードは問題がある」という判定ではない
• 一致したコードを残すか書き直すかは、表示されたライセンスの型を見てから人が決める

項目2：取り込んだ部品と、その先の部品のライセンス

部品の点検は、まず一覧を作るところから始まります。どの部品を、どの版で取り込んだか。AIが勧めた部品は、開発者が自分で選んだという意識が薄く、一覧から漏れがちです。AIに勧められて入れた部品にも、自分で選んだ部品と同じ責任がある、と最初に共有しておくことが大切です。

次に、部品が内部で使っている部品までたどります。表に見えている部品が寛容型でも、その内側に別の型の部品が入っていることがあります。解説記事でも、表面の依存関係だけでなく奥の依存関係まで見ることが対策の1つに挙げられています。手作業でたどるのは現実的ではないので、部品の構成を読み取る道具か、開発言語の標準の仕組みで一覧を出します。

一覧ができたら、各部品のライセンスの型を3つの型に振り分けます。ここでつまずきやすいのが、ライセンスの記載が無い部品です。記載が無いことは自由に使ってよいという意味ではなく、使ってよい根拠が無いという意味です。記載が無い部品は、出どころを確かめるまで使わない扱いにします。

項目3：社内で使うだけか、社外に出すのか

同じ部品が混ざっていても、社内でだけ使うのか、社外に配るのかで、守るべき条件が変わります。コピーレフト型の多くは配布をきっかけに公開義務が及ぶので、社内のツールとして使っているだけなら義務が生じない場合があります。一方で、取引先に納品するコードは、相手に渡した時点で配布にあたる可能性が高くなります。納品は社内利用ではない、と考えておくのが安全です。

ネットワーク越しにサービスとして提供するだけで義務が及ぶ型は、この区別が効きません。社外の人が使えるサービスに組み込めば、コードを渡していなくても条件がかかります。社内向けに作ったツールを、あとから取引先にも使ってもらうことにした、という変化はよく起きます。使う範囲が広がったときに、項目3をやり直すことを手順に入れておきます。

どの場面が配布にあたるか、どの使い方なら義務が生じないかは、ライセンスの条文と事業の形によって判断が分かれることがあります。点検をする人は、社内利用か、納品か、サービスとして提供するかの3つのどれにあたるかを記録し、判断が分かれそうなものは法務や専門家に回します。この記事でも、個別の結論は断言しません。

項目4：表示の義務を満たしているか

寛容型のライセンスは使いやすい反面、表示の義務があります。多くの場合、著作権の表示とライセンスの本文を、配布するものに含めることが求められます。公開義務が無いからといって、何もしなくてよいわけではありません。寛容型で起きやすい違反は、使ったこと自体ではなく、表示を落としたことです。

AIが書いたコードの断片が寛容型のコードと一致した場合も、表示の扱いが問題になります。ギットハブの説明では、一致の情報は、帰属の表示をするか、そのコードを取り除くかを決めるための材料として示されています。残すなら表示を付ける、表示を付けないなら書き直す。どちらかに決めて、決めた内容を記録します。

納品物では、使った部品とライセンスの一覧を1つの文書にまとめて添える形がよく使われます。AIにこの一覧の下書きを作らせるのは効率的ですが、部品名や版、ライセンスの名前が実際の構成と合っているかは、構成を読み取った結果と人が突き合わせます。AIは存在しない版や、似た名前の別の部品を書くことがあるからです。

項目5：提供元の補償が効く条件を満たしているか

一部のAIの提供元は、生成物が第三者の知的財産を侵害したと訴えられた場合に、顧客を守る約束をしています。マイクロソフトの顧客著作権コミットメントは、生成物に関する第三者からの一定の知財請求について、マイクロソフトが顧客を防御する義務を定めた規定です。ただし、補償は無条件ではなく、条件を満たしていたことを請求のときに顧客が示す必要があるとされています。

条件は製品ごとに違います。ギットハブの製品については、2026年4月3日以降、追加で必要な対策は無いとされ、一致を遮断する機能の利用も補償の条件から外れて任意になりました。これとは別に、ギットハブは法人向けの契約で一致の表示を使う場合でも、示されたライセンスに従っていれば補償が及ぶと説明しています。一方、マイクロソフトのクラウドでオープンAIのモデルを使ってコードを生成する場合は、保護された素材を検出する機能を、注記するか遮断する設定で有効にしておく必要があり、注記を選んだなら示されたライセンスに従うことが求められます。

ここから分かるのは、補償があるから点検が要らない、とはならないことです。示されたライセンスに従うことが条件に含まれている以上、補償を当てにするほど、ライセンスを守った記録が必要になる。使っている道具の契約の種類と、その時点の条件を確かめ、条件は改定されることがあるので、確かめた日付も残しておきます。

AIに任せる範囲と、人が決める範囲

この点検でAIに任せてよいのは、コードを書かせること、似たコードの照合、部品一覧の下書きまでです。一致の検出も部品の洗い出しも、量をこなす作業なので道具に向いています。一方で、どのライセンスを受け入れてよいか、社外に出してよいか、止めるかは人が決める。この線は、点検の手順書の最初に書いておきます。

AIに「このライセンスの部品は商用で使ってよいか」と聞けば、もっともらしい答えが返ってきます。しかしその答えには、自社の事業の形も、取引先との契約も入っていません。AIに尋ねるなら、結論ではなく、そのライセンスの条文のどこに何が書いてあるかを、条文の該当箇所を引いて示させます。根拠の箇所を書かせ、結論は書かせない。こうしておけば、人は条文を読んで判断できます。

人が確認する範囲も先に決めておきます。全部のコードを人が読むことはできないので、見るのは、一致の表示が出た箇所、コピーレフト型やネットワーク提供でも及ぶ型の部品、ライセンス不明の部品、そして社外に出すものです。範囲を決めずに「気をつけて使う」とだけ伝えると、点検は担当者の注意力に任されて、忙しい時期に抜けます。

運用1：受け入れてよいライセンスの一覧を作る

点検を毎回ゼロから判断していると、続きません。定着させるには、受け入れてよいライセンスの一覧を先に作っておきます。区分は3つで足ります。そのまま使ってよいもの、使う前に相談するもの、使わないもの。一覧があれば、現場の開発者は相談の要らない部品を自分で判断できるので、点検の窓口に仕事が集中しません。

区分は、自社の事業の形で変わります。取引先に納品するコードが多い会社と、自社のサービスとして提供する会社では、止めるべき型が違います。受託開発では配布を前提に考え、サービス提供ではネットワーク提供でも及ぶ型を強く警戒する、という具合です。他社の一覧を写すのではなく、自社がどの形でコードを外に出しているかを書き出してから区分を決めます。

一覧は、法務と開発の責任者が一緒に決め、改定の手順も決めておきます。現場から「この部品を使いたいが、一覧に無いライセンスだった」と相談が来たときに、誰がいつまでに判断するのか。判断が出たら一覧に足すのか。一覧が更新されない状態が続くと、現場は相談するより黙って使うほうを選ぶようになります。

運用2：止める権限を、名前で置く

点検で問題が見つかっても、止められなければ意味がありません。納品の期限が迫っている時期ほど、「とりあえず出して、後で直す」という判断に流れます。これを防ぐには、納品を止める権限を持つ人を、役職ではなく名前で決めておくことです。役職で書くと、その役職の人が不在のときに誰も止められません。

止める権限を持つ人は、開発の責任者と法務の担当から、少なくとも2人を置きます。1人だけだと、その人が休んでいる日に判断が止まるか、逆に誰にも相談せずに出てしまいます。止めたときに納期をどう調整するかも、権限と一緒に決めておきます。止めた人が納期遅れの責任を1人で負う形では、誰も止めなくなります。

止める基準は、一覧の「使わない」に入る型が見つかったとき、ライセンス不明の部品が社外に出るものに入っていたとき、一致の表示が出たコードを表示なしで残していたとき、の3つから始めると分かりやすくなります。基準に当たったら、止める人に連絡が行き、止めるか条件付きで出すかをその人が決めます。

運用3：納品前チェックの記録を残す

点検は、やったことを記録して初めて、後から説明できるものになります。取引先から利用状況を問われたとき、あるいは提供元の補償を求めるときに示せるのは、その時点で何を確かめたかの記録だけです。記録は納品物ごとに1枚にまとめ、納品物と同じ場所に保管します。

この記録の下書きは、AIに作らせることができます。道具の参照記録や部品一覧を渡して、決まった様式に並べさせるのです。ただし、止める権限を持つ人の確認欄だけは、人が読んでから埋めます。記録の最後の1行を人が書くことが、点検を形だけにしない仕掛けになります。

点検が定着しない職場で起きること

点検の手順を作っても、続かない職場には共通の形があります。多いのは、点検がすべて1人の担当者に集まり、その人が忙しくなると止まる形です。次に多いのが、一致の表示が出なかったことを「問題が無かった」と読み替えて、部品の点検を省く形です。どちらも、手順の最初の設計で防げます。

• 一致の表示が出なかったので、部品の一覧を作らない：断片の一致と部品の取り込みは別の経路。部品から入った条件を見落とす
• 社内ツールとして作ったものを、点検をやり直さずに取引先へ渡す：使う範囲が変われば、守る条件も変わる
• AIに「商用で使ってよいか」を聞いて、その答えを記録に書く：自社の事業の形も契約も入っていない結論が、判断の根拠として残る
• 補償があるから点検は要らないと考える：補償の条件には、示されたライセンスに従うことが含まれる場合がある

もう一つ見落とされがちなのが、外注先が書いたコードです。外注先がAIを使って書いたコードを受け取り、そのまま自社の製品に組み込んで納品すれば、点検の責任は自社に戻ってきます。外注先に同じ5項目の記録を求めるか、受け入れのときに自社で点検するかを決めておきます。

外注先に求めるなら、受け取るときに聞く中身は5項目をそのまま使えます。使ったAIの道具と、一致を知らせる設定か出さない設定か。取り込んだ部品とその型の一覧。表示の義務をどう満たしたか。自社で点検するなら、外注先から受け取ったコードも自社の開発者が書いたコードと同じ手順に通します。どちらにしても、記録の最後の確認欄は自社の止める権限を持つ人が埋めます。

よくある質問

一致を出さない設定にしておけば、点検は要りませんか

一致する提案を出さない設定は、断片の経路を狭める効果があります。ただし、短い断片は検出されないことがあり、非公開のコードは照合の対象外なので、完全にふさげるわけではありません。また、AIが勧めた部品を取り込む経路には効きません。設定は点検を軽くするものとして使い、部品の一覧と表示の確認は続けます。

社内でしか使わないツールなら、確かめなくてよいですか

社内利用であれば公開義務が生じない型もありますが、ネットワーク越しに提供するだけで義務が及ぶ型は別です。また、社内ツールがあとから取引先にも使われるようになることは珍しくありません。社内利用のものも、部品とライセンスの一覧だけは作っておくと、範囲が広がったときにやり直しが短く済みます。

コピーレフト型の部品が見つかったら、必ず使えないのですか

必ずしもそうではありません。社内でだけ使う場合や、組み込み方によっては条件が変わることがあります。ただし、判断は条文と事業の形によって分かれるので、点検をする人が結論を出さず、止める権限を持つ人と法務に回します。代わりの部品で置き換えられるなら、置き換えを先に検討するほうが早いこともあります。

点検は誰がやるのがよいですか

洗い出しは開発の担当、判断は開発の責任者と法務、と分けるのが基本です。一致の検出と部品の一覧は開発の流れの中で自動化できる部分が大きいので、開発の担当が受け持ちます。社外に出すかどうか、止めるかどうかは、事業と契約を知っている人が決めます。1人に全部を任せないことが、続けるための前提です。

まとめ

AIの提案が公開コードと一致するのは1パーセント未満ですが、それだけでライセンスの点検が要らなくなるわけではありません。条件が入り込む経路は、AIが書いた断片と、AIが勧めた部品の2つがあり、とくに部品はその先の部品の条件まで連れてきます。納品する前に確かめるのは、一致の有無、部品のライセンスの型、社内利用か配布か、表示の義務、提供元の補償の条件の5項目です。一致の検出には、短い断片や非公開のコードが見えないという限界があり、表示が出なかったことは混ざっていない証明になりません。補償も、示されたライセンスに従うことが条件に含まれる場合があります。AIにはコードを書かせること、照合、部品一覧の下書きまでを任せ、根拠の箇所を示させたうえで、受け入れてよいライセンス、社外に出すか、止めるかは人が決めます。受け入れてよいライセンスの一覧、止める権限を持つ人の名前、納品ごとの記録の3つがそろえば、点検は担当者の注意力に頼らずに続きます。まずは直近の納品物1本について、使ったAIの道具の設定と、取り込んだ部品の一覧を書き出すところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。