「AIに書かせたコードは、誰のものか」という質問は、業務でClaude Codeを使い始めた企業から必ず出る。だが、この質問の立て方自体が少しずれている。実務で先に効いてくるのは所有権の話ではなく、「レビューせずに出荷していいか」という話だ。
著作権は基本的に発生しない、が出発点
日本の文化庁が著作権分科会法制度小委員会で示した整理では、AIが自律的に生成しただけのものは「人の思想又は感情を創作的に表現したもの」という著作物の要件を満たさず、原則として著作物に該当しないとされている。プロンプトを打ち込んでコードを出力させただけの状態は、これに当たる。
一方で、人間が生成物に対して構成の選択・修正・組み合わせといった創作的寄与を加えた場合は、その寄与の程度に応じて著作物性が認められる余地があるという整理もされている。単なる労力の投入ではなく、創作的な工夫がどれだけ積み重なっているかで個別に判断される、という考え方だ。
つまり「AIに書かせたコードそのもの」に自社の著作権を主張するのは難しく、逆に言えば競合が似たコードを書いても著作権侵害には問いにくい。ここまでは複数の法律専門家の解説記事でも一致した見解として繰り返し説明されている。
ただし、業務で本当に注意すべきはこの先にある。文化庁の整理は同時に、生成物が既存の著作物と類似しており、かつ利用者がその著作物を認識した上で似せて生成させたと言える場合（依拠性が認められる場合）は、著作権侵害が成立し得るとも述べている。「AIが書いたから自分は関係ない」という言い訳は通らない。侵害の主体は生成AIではなく、それを業務で使った利用者側になる。
適用条件と例外——所有権より先に見るべき2つのリスク
ライセンス混入のリスク
生成AIは大量のオープンソースコードを学習している。学習元のコードの断片が、そのままか、わずかに変形されただけの形で出力に混じることがある——これは複数の技術系メディア・法律系メディアの解説で共通して指摘されている点だ。
これに気づかず自社の製品コードへ組み込むと、GPL・AGPLのような強いコピーレフト性を持つライセンスの義務(ソースコード開示義務など)を、意図せず自社のプロダクトが負ってしまう可能性がある。納品物や自社プロダクトに、想定していないライセンス条件が混入する形だ。
「AIが書いたコードだから自由に使える」という発想は、この意味でも危うい。出力の由来を追跡できない以上、少なくとも重要な機能や外部提供物に組み込む前には、ライセンス上不自然な既視感のあるコード(見慣れたライブラリのコピーに近い塊など)がないかを見る工程が要る。
依拠性・類似性のリスク
前段で触れた著作権侵害の話は、抽象論ではなく実務的な判断基準として使える。文化庁の整理をなぞると、判断軸は次の2つに集約される。
| 軸 | 意味 | 実務での現れ方 |
|---|---|---|
| 類似性 | 生成物が既存の著作物の表現上の本質的特徴に近接しているか | 特定のOSSプロジェクトやコードサンプルと構造・変数名・コメントまで酷似している |
| 依拠性 | 利用者が既存の著作物を認識した上で、それに似せて生成させたと言えるか | 「〇〇というライブラリの実装と同じように書いて」のような指示を出している |
両方が揃うと侵害が成立し得る、というのが文化庁の整理の骨子だ。逆に言えば、既存の特定コードを意識せず一般的な指示で書かせた場合は、依拠性の要件を満たしにくく、リスクは相対的に低い。「何を参照させて書かせたか」という指示の作り方自体が、リスクの大きさを左右する。
⚠️ 上記の著作権に関する記述は、文化庁の一次資料(bunka.go.jp)に本セッションのネットワーク境界からWebFetchで直接アクセスできなかったため、複数の独立した法律・ビジネス系メディアの解説記事が一致して説明している範囲の一般的な考え方としてまとめたものであり、個別の条文番号や係争事例の断定はしていない。自社の契約・案件に当てはめる際は、顧問弁護士・弁理士など専門家の確認を経ること。
自社で判断する基準——「人間のレビューを必須にする」に尽きる
ここまでの2つのリスクへの対処は、結局同じ一点に集約される。生成されたコードを、レビューせずにそのまま出荷しない。
Anthropic自身、Claude CodeのCode Review機能(PRに対して複数のエージェントが並行して差分をレビューし、バグ・セキュリティ上の懸念・リグレッションを指摘する機能)について、公式ドキュメントで明確に書いている。
Findings are tagged by severity and don’t approve or block your PR, so existing review workflows stay intact.
Code ReviewはPRを承認も拒否もしない。見つけた問題に重要度のタグを付けて提示するだけで、マージするかどうかは既存のレビューフローに委ねられる。AIが自分の書いたコードを自分でレビューして通す、という構造にはなっていない。ツールを作っている側が、「最終判断は人間が行う」という前提を製品仕様として維持している点は、業務利用のルールを作る側にとって参考になる。
これを踏まえると、社内で決めるべきルールは次の形に落ち着く。
- 人間のレビューを経ないコードはマージしないという原則を、AI生成かどうかに関わらず既存のレビュープロセスの中に維持する(新しい承認フローを別途作る必要はない)
- レビュー時に、通常のロジック確認に加えて「見慣れたライブラリの実装そのままに見える塊がないか」「参照元を明示的に指示した生成でないか」を確認項目に加える
- 依存関係・ライセンススキャンのツールを使っている場合は、AI生成コードもスキャン対象から外さない
- 受託開発で顧客に納品するコードについては、著作権の帰属や生成AI利用の有無を契約・仕様書のどこでどう扱うかを、技術的なレビュー体制とは別に整理しておく(顧客のコードをどう扱うかという設定面の整理は別記事で扱った内容と対になる論点)
社内ルールとして文書化する場合の書き方は、生成AIの利用規程に何を書くかで整理した「技術で縛れる部分」と「人に約束させるしかない部分」の分け方がそのまま使える。ライセンス混入・依拠性のチェックは後者、つまり人がレビューという行為で担保するしかない部分に当たる。
このプロジェクト自身も、同じ発想でルールを敷いている
このブログの記事は、Claude Codeによる自動リサーチ・執筆・事実確認・マージという一連の運用で作られている。「AIが生成したコンテンツを、人間のレビューなしにそのまま公開しない」という発想は、コードに限った話ではなく、この記事自体の運用ルールにもそのまま適用されている。
具体的には、一次ソースへのアクセスに失敗した場合は独自の数値・日付を作らない、助成金・補助金のように誤りの影響が大きいテーマは自動マージの対象から外して必ず人の確認を通す、という2段構えのゲートを敷いている(このプロジェクトの運用ルールとしてCLAUDE.mdに明記済み)。コードのレビューゲートと、コンテンツのレビューゲートは、同じ理由で存在している——生成物の由来をAI自身は保証できないので、出す前に人が見る工程を削らない、という一点だ。
「AIに書かせたから確認しない」のではなく、「AIに書かせたからこそ、どこを確認するかを事前に決めておく」。業務利用のルール作りは、この順番で考えると設計しやすい。
Claude Codeの導入支援では、こうしたレビューゲートの設計を含めた運用ルール全体の整理もサービス内容に含めている。