AIに書かせたコードは、誰のものでもない。正確に言えば、著作権という名の「守り」が存在しない。それだけでも困るのに、問題はもう一重ある。そのコードが他人の著作権を侵害しているかもしれない。守れない剣だ。自分は攻撃されるリスクがあるのに、相手を攻撃することもできない。
バイブコーディングで社内ツールを作った人、AIでプロダクトを作った人——法的な地雷を踏んでいる可能性がある。この記事では、日本法・米国法・EU法の3つの視点から、AI生成コードの著作権リスクを整理する。法律の解釈は未確立の部分が多く、「こういう判断になりうる」という整理であり、個別のケースには専門家への相談を勧める。
著作権は「人間が作ったもの」しか守らない
著作権とは何か。日本の著作権法では「人間の思想または感情を創作的に表現した著作物」にのみ著作権が発生する。ここで重要な言葉は「人間の」だ。
AIが自律的に生成したコードには、この「人間の創作的表現」がない。だから著作権が発生しない。これは解釈論ではなく、著作権法の大前提だ。
文化庁が2024年3月に公開した「AIと著作権に関する考え方について」では、この考え方を明確にしている。AI生成の出力物の著作物性については、人間の「創作的寄与」があるかどうかが判断基準になるとしている。
「創作的寄与」とは何か。AIを単なる道具として使い、人間が創作意図を持ち、具体的な指示を出し、選択・編集を重ねること——そういった行為があれば、著作者になれる可能性がある。ただし、どこからが「創作的寄与」として認められるかは、現時点では判例が積み上がっておらず未確立だ。
米国著作権局（USCO）も同様の立場を取っている。2025年1月29日公開の第2部レポートでは、「完全にAIが生成した素材は著作権保護の対象外」と結論づけた。そして「プロンプトの提供だけでは著作者とは認められない」とも明記している。
コンビニの店員に「おにぎりを作って」と言ったからといって、そのおにぎりのレシピの著作権はあなたのものにならない。プロンプトは指示であり、創作ではない。長島・大野・常松法律事務所の解説によれば、USCOはこのレポートで「どれだけ詳細なプロンプトであっても、それだけでは著作権保護の根拠にならない」と明示している。
リスク1：作ったものを守れない
バイブコーディングで何十万円もかけてプロダクトを作ったとする。競合他社が同じ機能を持つものを作った。「それは私のコードを真似した」と言いたい。でも著作権がなければ、法的手段を取れない。
エンジニアがゼロから書いたコードであれば、独創性のある表現として著作権保護の対象になりうる。しかし「AIに書かせてコピペしただけ」なら、それは守れない。コストをかけて工場で大量生産した製品に特許がないようなものだ。誰でも同じものを作れる。競合に真似されても「これは私のオリジナル」と言えない。
リスク2：知らずに侵害する
もう一つのリスクは、自分が加害者になる可能性だ。AIは大量の既存コードを学習している。GitHubにあるオープンソースコード、技術書のサンプルコード、ブログに載っているスニペット。それらを学習して、新しいコードを生成する。
著作権侵害の成立には2つの要件がある。
- 類似性：既存の著作物と出力が似ているか
- 依拠性：その著作物に依拠して（元にして）作ったか
通常の「真似した」かどうかの争いでは、「そのコードを見たことすら知らなかった」と言い訳ができる場合もある。しかしAIの場合は違う。AIが学習データとしてそのコードを取り込んでいた事実があれば、「依拠性あり」と判断される可能性がある。
AIは何億行ものコードを読んで育った子供のようなものだ。その子が書いたレポートが既存の本のフレーズと似ていたとき、「本を読んだことがある」という事実が「元ネタを知っていた」という証拠になりうる。
車が事故を起こしたとき、製造会社ではなくドライバーが責任を負う。AIを作ったOpenAIやAnthropicではなく、そのAIを使って成果物を作った人、つまりあなたが責任を負う可能性が高い。
GitHub Copilot訴訟から学ぶ
2022年、GitHub・Microsoft・OpenAIに対して著作権侵害を主張する集団訴訟が起こされた。損害額として90億ドル超が主張された。訴訟の主な論点は、CopilotがOSSのライセンス表記（著作権管理情報）を削除して出力していたというものだ。
2024年7月に裁判所はDMCA第1202条違反の請求を棄却した。理由は「Copilotが生成したコードが元のコードと十分に同一ではない」というものだ。ただし訴訟の一部は継続中で、最終決着はついていない。
この訴訟を受けてMicrosoftは2023年9月に「Copilot Copyright Commitment」を発表した。Copilotで生成した出力に著作権侵害の申し立てがあった場合、Microsoftが法的責任を負うという仕組みだ。AIツール会社が著作権リスクを認識して対策を取り始めている。逆に言えば、それだけリスクが現実的に存在するということでもある。
著作権侵害を判断する2つの要件
著作権侵害が成立するには「類似性」と「依拠性」の両方が必要だ。2つの要件の関係を整理する。
AIで問題になりやすいのは依拠性だ。人間が書くコードであれば「そのコードを見たことがない」という主張が通りやすい。しかしAIが学習データとして特定のコードを取り込んでいれば、「AIはそれを知っていた」という事実が残る。
ただし、問題が起きやすいコードと起きにくいコードがある。教科書的なアルゴリズム（ソートや検索など）は著作権ではなくアイデアの領域であり保護対象外だ。また、コードが短いほど独創性が認められにくい。問題になりやすいのは、特定のライブラリや独自実装と類似した長いコード片だ。
AIが「よく見るパターン」を出力することは多い。それがどのコードを参考にしたかは、AIも、あなたも、知る術がない。
世界の法的動向（2026年2月時点）
日本：AI学習は原則OK、でも出力は別の話
著作権法第30条の4により、情報解析（AI学習）目的での著作物利用は原則として著作権者の許諾なしに可能だ。日本はAI学習について比較的許容的な制度設計になっている。
ただし「著作権者の利益を不当に害する場合」は例外とされている。特定クリエイターの作品だけを集中的に学習させて創作的表現を出力させる追加学習（LoRAやRAGなど）は、「享受目的あり」とみなされる可能性があり、この例外に該当しうる。
文化庁は2024年7月にチェックリスト＆ガイダンスを追加公開し、企業向けの判断軸を提供している。
米国：完全AI生成物は著作権対象外と明確化
USCOの2025年1月レポートは明快だ。完全にAIが生成した成果物は著作権保護の対象にならない。一方、人間が入力した創造的表現が「認識可能な形で」出力に反映されている部分は保護対象になりうる——人間が書いて、AIに渡した部分が出力に残っている場合は保護の余地があるということだ。
USCOは新しい法律が不要という立場も示している。既存の著作権法で対応できるという見解だ。
EU：AI事業者に透明性義務
EU AI Actは2024年8月1日に発効した世界初の包括的AI規制法だ。汎用AI（GPAIモデル）に対する透明性義務（第53条）は2025年8月2日から適用されている。
この義務の核心は、学習に使ったコンテンツがEU著作権法を遵守していることを確認する方針の策定・公開だ。AIを使うエンドユーザーへの直接の義務ではないが、AIを提供する事業者が学習データの適法性を担保することを要求している。違反時の制裁金は最大3,500万ユーロまたは全世界年間売上高の一定割合だ。
学習データの適法性については、AIツール会社が対応する義務を負っている。エンドユーザーへの直接の義務ではないが、ツール選択時の参考にはなる。
コードと著作権：具体的なパターン
コード例で整理する。
// ❌ 著作権保護の対象になりにくいパターン
// プロンプト: "Eコマースのカート機能を実装して"
// → AIが生成、そのままコピペ、人間は出力を確認しただけ
// → 創作的寄与なし → 著作権保護の根拠なし
// → 競合に真似されても法的手段を取れない
const addToCart = (productId: string, quantity: number) => {
// AIがそのまま生成。人間の創作的判断が入っていない
cart.push({ productId, quantity });
};
// ✅ 著作権保護の余地が生まれるパターン
// 1. 独自のアーキテクチャ設計・ビジネスルールをプロンプトに詳細仕様として記述する
// 2. AIの出力を人間が選択・編集・組み合わせる
// 3. 生成プロセスと変更履歴を記録しておく
// → 人間の創作的寄与が認められる可能性
// 人間が設計した在庫チェックとロールバックのロジック（人間による変更コメント付き）
const addToCart = async (productId: string, quantity: number): Promise<void> => {
// 人間が独自に設計したトランザクション管理ロジック
const stock = await checkStock(productId);
if (stock < quantity) throw new InsufficientStockError(productId, stock);
await cart.add({ productId, quantity, addedAt: new Date() });
};
著作権侵害リスクの高低も整理する。
// ⚠️ 侵害リスクが上がるパターン
// 有名OSSのコアロジックと酷似した関数が出力された場合
// → AIがそのコードを学習済みの可能性
// → 類似性・依拠性の両方が問題になりうる
// → 商用利用している場合、ライセンス違反・著作権侵害の可能性
function debounce(fn: (...args: unknown[]) => void, delay: number) {
// Lodashのdebounceと酷似した実装が出力されるケース
let timeoutId: ReturnType<typeof setTimeout>;
return (...args: unknown[]) => {
clearTimeout(timeoutId);
timeoutId = setTimeout(() => fn(...args), delay);
};
}
// ✅ 侵害リスクが低いパターン
// バブルソートなど、教科書的アルゴリズムの基本実装
// → アイデアの領域（著作権保護の対象外）
// → 独創性が認められにくい短いコードスニペット
function bubbleSort(arr: number[]): number[] {
const result = [...arr];
for (let i = 0; i < result.length - 1; i++) {
for (let j = 0; j < result.length - 1 - i; j++) {
if (result[j] > result[j + 1]) [result[j], result[j + 1]] = [result[j + 1], result[j]];
}
}
return result;
}
今すぐ取れる3つの行動
法律が整理されるのを待つ必要はない。リスクを下げるための実務的な行動は今すぐ取れる。
1. 人間の創作的寄与を残して記録する
プロンプトに詳細な設計仕様を書く。AIの出力をそのままコピペするのではなく、選択・編集・組み合わせをする。その過程を記録する。
# AI生成コード使用記録
- 生成日: 2026-02-28
- ツール: Claude Code
- プロンプトの概要: [独自仕様・設計の詳細]
- 生成後の人間による変更: [主な変更内容と理由]
- 著作権の根拠となる創作的寄与: [どこに人間の判断があったか]
この記録は「創作的寄与があった」という証拠になりうる。万一、侵害を申し立てられた場合の対応材料にもなる。
2. AIツールのIPポリシーを確認する
MicrosoftのCopilot Copyright Commitmentのように、一部のAIツールは著作権侵害のリスクをツール側が補償する仕組みを持っている。業務利用するツールについては、こういったカバレッジが存在するかどうかを確認しておくとよい。
3. 長いコードのライセンス確認を習慣にする
既存ライブラリや独自実装と酷似した長いコードが出力された場合は、類似している可能性のあるOSSコードを検索してライセンスを確認する習慣をつけるとよい。特に商用プロダクトに組み込む前には確認を怠らないことだ。
まとめ
AI生成コードには二重のリスクがある。
- 自分のコードを著作権で守れない可能性がある
- 他人の著作権を知らずに侵害するリスクがある
どちらも「知らなかった」で済まない問題だ。特に事業に使う場合、法的リスクとして認識しておく必要がある。
完全に避けることは難しいが、リスクを下げることはできる。人間の創作的寄与を残して記録し、ツールの補償ポリシーを確認し、類似コードのライセンスを確認する——それが今できることだ。