AI生成コードの著作権｜事業で使う前の確認点

AIが書いたコードを事業で使うとき、著作権やライセンスはどう考えればよいのでしょうか。この記事では、AI生成コードに著作権が発生するのか、他人の権利を侵害するおそれはないか、OSS（オープンソースソフトウェア）のライセンスはどう関わるかを順に整理します。そのうえで、新規事業でAIを使った開発を進める前に確認したい点をまとめます。

なお、この記事は一般的な情報の整理であり、法的な助言ではありません。個別の案件で判断が分かれる場面は、知的財産に詳しい弁護士などの専門家に確認することをおすすめします。

論点は3つに分けると整理しやすい

「AI 生成 コード 著作権」という疑問は、実は性質の違う3つの問いが混ざっています。

1. 守れるか：AIが書いたコードに、自社の著作権は発生するのか
2. 侵害しないか：AIが出したコードが、他人の著作物と似てしまうおそれはないか
3. ルールを守れるか：OSSのライセンスや、AIツールの利用規約に反しないか

この3つは別々の問題です。たとえば「自社の著作権が弱い」ことと「他人の権利を侵害する」ことは、同時に起こることもあれば、片方だけのこともあります。まとめて「AIのコードは危ないのか」と考えると判断を誤りやすいため、分けて確認するのが近道です。

AI生成コードに著作権は発生するのか

日本での考え方

日本の著作権法では、著作物は「思想又は感情を創作的に表現したもの」と定義されています（著作権法2条1項1号）。プログラムも著作物の例に挙げられています（同法10条1項9号）。ここで大切なのは、保護の対象が「人の創作的な表現」である点です。

AIが自動的に出力した結果に著作権があるかどうかは、人がどれだけ創作的に関わったかで決まる、というのが現在の整理です。文化庁の文化審議会著作権分科会法制度小委員会が2024年3月に取りまとめた「AIと著作権に関する考え方について」では、AI生成物が著作物にあたるかは、利用者に「創作的寄与」があったかで判断するとされています。創作的寄与の有無を見る際の要素として、次のようなものが挙げられています。

• 指示（プロンプト）の分量や具体性
• 生成を試した回数
• 複数の生成物から選んだこと
• 生成後に人が加筆・修正したこと

つまり、「こういうコードを書いて」と短く頼んで出てきたものをそのまま使った場合と、設計を人が決め、AIの出力を選び、手を入れて仕上げた場合とでは、著作物性の見方が変わり得ます。どこから創作的寄与が認められるかは、個別の事情によって判断が分かれます。

海外の動き

米国では、著作権局が2025年1月に公表したAIと著作権に関する報告書（著作物性を扱う部分）で、プロンプトだけでは利用者が出力を十分に制御しているとはいえず、著作者性は認められないという考え方が示されています。一方で、人が加えた表現や、AIの出力を人が選び、並べ、改変した部分については、保護され得るとされています。

日本と米国で細かな枠組みは異なりますが、「AIの出力そのものよりも、人が判断し、表現を加えた部分に権利が生じやすい」という方向は共通して読み取れます。海外のユーザーや拠点を想定する事業では、国ごとに扱いが違い得る点も念頭に置いておくと安心です。

コードならではの事情

プログラムには、AI以前から保護されにくい部分があります。著作権法10条3項は、プログラム言語、規約（インターフェースやプロトコルなどの約束事）、解法（アルゴリズム）には著作権の保護が及ばないと定めています。

このため、AI生成かどうかに関係なく、次のような点は押さえておく必要があります。

• 「どういう仕組みで動くか」というアイデアや処理手順は、著作権では守られない
• 機能上、誰が書いても似た形になるコードは、創作性が認められにくい
• 守られやすいのは、具体的なコードの書き方や構成といった「表現」の部分

AIが生成したコードに著作権が発生するかどうかが不明確でも、それだけで事業が成り立たなくなるわけではありません。ただし、「このコードを他社が丸ごとコピーしても止められない可能性がある」という前提は、事業の守り方を考えるうえで持っておきたい視点です。

他人の権利を侵害するおそれはあるのか

依拠性と類似性

AIが出したコードが他人の著作権を侵害するかどうかは、一般に「依拠性」と「類似性」の2つで見ます。

• 依拠性：既存の著作物をもとにしたといえるか
• 類似性：表現として、既存の著作物と似ているか

前述の文化庁の資料では、AIを使った場合でも、この2つが満たされれば著作権侵害になり得るとされています。また、利用者が既存の著作物を知っていて、それに似せるような指示をした場合などは、依拠性が認められやすくなると整理されています。

実務上の難しさは、利用者が元になりそうなコードを知らないまま、AIが学習元のコードに近いものを出してしまう場合があることです。AIの出力が学習元のコードとほぼ同じになるケースは、研究や報告で指摘されています。出力のたびに「元のコードがあるか」を人が見抜くのは現実的ではないため、仕組みとして確認する手段を持つことが大切になります。

OSSライセンスとの関係

実務で見落とされやすいのが、OSSのライセンスです。OSSは、決められた条件を守れば自由に使えるソフトウェアですが、条件はライセンスごとに違います。代表的なものを、ごく簡単に整理します。

ライセンス	主な条件の例
MIT	著作権表示とライセンス文を残す
Apache License 2.0	著作権表示などを残し、変更箇所を明示する。特許の利用許諾に関する条項もある
GPL	配布する場合、同じ条件でソースコードを提供する必要がある（コピーレフト）
AGPL	GPLの条件に加え、ネットワーク経由でサービスとして提供する場合にもソースコードの提供義務が生じ得る

特に新規事業でWebサービスやSaaSを作る場合は、AGPLのような条件が事業の形と衝突しないかが問題になります。AIが提案したコードやライブラリにこうしたライセンスのものが混じると、あとから「自社のコードを公開する必要が出る」という事態も理屈の上ではあり得ます。

ここで注意したいのは、AIが書いたコードの中身だけでなく、AIが提案して追加された**外部ライブラリ（依存パッケージ）**のライセンスも対象になることです。AIは便利なライブラリを次々と提案しますが、そのライセンスまで説明してくれるとは限りません。

OSSライセンスの確認は、AIを使わない開発でも本来必要でした。AIによって開発のスピードが上がるぶん、確認の頻度と仕組みが追いつかなくなりやすい、というのが論点です。

なお、AIモデルそのものの公開にも、同じようにライセンスや利用条件があります。たとえばMuse Spark Openの重み公開、商用は条件つきやBeam公開、Apache 2.0の重みと40超の連携先が同時にのように、公開形態や商用利用の条件はモデルごとに異なります。自社のサービスにモデルを組み込む場合は、コードだけでなくモデル側の条件も確認の対象です。

AIツールの規約と外注先との契約を確認する

AIツール側の規約

AIコーディングツールは、提供事業者ごとに利用規約が異なります。確認したい主な点は次のとおりです。

• 生成物に関する権利を、利用者のものとして扱う規定になっているか
• 入力したコードや指示が、モデルの学習に使われるかどうか（法人向けと個人向けで扱いが違う場合がある）
• 公開コードと一致するコードを検知・抑制する機能があるか
• 知的財産権の侵害を指摘された場合の補償制度があるか、あるなら適用の条件は何か

補償制度や一致コードの検知機能は、提供しているツールとそうでないツールがあります。また、あっても適用に条件がつくのが通常です。「このツールだから安全」と考えるのではなく、規約と提供条件を読んだうえで、自社の使い方が条件に合っているかを見るのが確実です。各ツールの特徴の違いは、AIコーディングツール比較｜特徴と向く使い方｜2026年10月でも整理しています。

入力する情報の扱いも、権利の問題と隣り合っています。事業アイデアや顧客データをAIに入力してよいかは、生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで詳しく扱っています。

外注先との契約

システム開発を外部に依頼する場合、著作権の帰属は契約で決まります。著作権法61条2項により、著作権を譲渡する契約で翻案権など（27条・28条の権利）が明記されていないと、譲渡する側に残っていると推定されます。契約書の書き方ひとつで結果が変わるため、AIを使わない開発でも要注意の部分です。基本はシステム開発の著作権帰属は誰のもの？契約前の確認点にまとめています。

AIを使った開発では、これに加えて次の点も確認しておくと安心です。

• 納品物にAI生成部分が含まれるか、どのAIツールを使うか
• AI生成部分について、権利が及ばない可能性があることを双方が理解しているか
• 第三者の権利を侵害した場合の責任の分担
• 納品物に含まれるOSSの一覧と、そのライセンスを開示してもらえるか

「権利を譲渡する」と契約に書いてあっても、そもそも著作権が発生していない部分は譲渡できません。そのため、権利の譲渡だけに頼らず、利用できる状態と責任の範囲を契約で明確にしておくことが現実的です。秘密保持の取り決めはシステム開発のNDA｜秘密保持で決める8つの項目も参考になります。

事業で使う前の確認チェックリスト

ここまでの内容を、実務で使える形にまとめます。

開発を始める前

• AIツールの利用規約と、法人向けの条件（学習への利用、補償の有無）を確認した
• 入力してよい情報と、入力しない情報のルールを決めた
• 外注する場合、AI利用の可否と開示範囲を契約に盛り込んだ

開発の途中

• AIが追加したライブラリの名前とライセンスを記録している
• コピーレフト型のライセンス（GPL・AGPLなど）が混じっていないか確認する仕組みがある
• AIが出したコードを、人が読んでレビューしている

ライセンスの確認は、ソフトウェア構成解析（SCA）と呼ばれる種類のツールで、依存関係とライセンスを自動で洗い出す方法が一般的です。人の目だけに頼るより抜けが少なくなります。

納品・公開の前

• 使っているOSSの一覧を作り、必要な著作権表示やライセンス文を残している
• 自社の事業の形（SaaS、配布、組み込みなど）と、ライセンスの条件が衝突しない
• 重要なコードは、人の手で設計・修正した部分がどこかを説明できる

最後の項目は、創作的寄与を説明できるようにしておく、という意味です。誰が何を決め、どこに手を入れたかの記録は、権利の主張にも、後述する引き継ぎにも役立ちます。

公開後

• 依存ライブラリの更新に伴うライセンスの変更を追えている
• 保守や改修を担う人が、コードの由来を把握できる

保守まで見据えた観点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点でも扱っています。コード自体の安全性は、AI生成コードのセキュリティ｜確認点と人の役割で別に整理しています。

新規事業では「コードの権利」だけに頼らない

新規事業の場合、コードの著作権だけを競争力の源泉と考えるのは危うい面があります。前述のとおり、アイデアや処理手順は著作権で守られませんし、AI生成部分の権利は流動的です。

そう考えると、事業の強みは次のような部分に置くほうが現実的です。

• データ：運用を通じて蓄積される、自社だけが持つデータ
• 顧客との関係：使い続けてもらう仕組みや、業務への入り込み方
• 改善の速さ：使われ方を見ながら、機能を育て続ける体制
• 営業秘密としての管理：公開していない仕組みやノウハウを、アクセス制限などで守る（不正競争防止法の営業秘密は、秘密として管理されていることが要件の一つです）

こうした視点は、新規事業のシステム設計とビジネスモデルの作り方や、システムは納品後の改善で育てる｜新規事業の考え方にもつながります。

また、権利面の確認は「最初から完璧に」を目指すと動けなくなります。小さく作って確かめる進め方と、権利の確認を組み合わせるのが現実的です。まず動くものを作り、事業として続ける見通しが立った段階で、ライセンスの棚卸しや契約の整備を丁寧に行うという順序もあり得ます。ただし、外部に公開したり、顧客に提供したりする前には、終わらせておきたい確認があります。それがOSSライセンスの確認と、入力情報の扱いの整理です。

まとめ

AI生成コードの著作権とライセンスについて、要点は次のとおりです。

• 論点は「守れるか」「侵害しないか」「ルールを守れるか」の3つに分けて考える
• 日本では、AI生成物の著作物性は人の創作的寄与の有無で判断される。指示の具体性、試行、選択、加筆修正などが見られる（文化庁「AIと著作権に関する考え方について」）
• 米国著作権局も、プロンプトだけでは足りず、人が加えた部分が保護され得るという考え方を示している
• アイデアやアルゴリズムは、もともと著作権の保護対象ではない
• 他人の権利の侵害は、依拠性と類似性で見る。AIの出力が学習元に近くなるおそれは、仕組みで確認する
• OSSライセンスは、AIが追加したライブラリも含めて確認する。AGPLなど、サービス提供でも条件が及ぶものがある
• AIツールの規約、外注先との契約、納品物のOSS一覧を確認する
• 新規事業では、コードの権利だけでなく、データや改善の速さなどに強みを置く

AIを使った開発では、AIが書き、人が「何を作るか」を決めて品質の最終判断をする、という役割分担が基本です。権利の扱いも、人が判断する領域に含まれます。役割分担の全体像はAI駆動開発とは｜AIと人の役割分担と発注側の要点で、人の確認が必要な理由はAI開発でも品質には人の確認が必要な理由で詳しく扱っています。

私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく受託開発サービスです。AIを使った開発で権利面に不安がある、仕様がまだ固まっていない段階でも、確認したい点を整理するところから相談できます。サービスの詳細はJustFitのサービス紹介をご覧ください。