Claude Codeが書いたコードの所有者は誰か？
(legallayer.substack.com)- AI支援コードの著作権は、人間による意味のある創作的寄与があるかどうかに左右され、AIが主に作成し人間がほとんど手を加えていない成果物は保護されない可能性がある
- 中核となる判断基準は meaningful human authorship であり、目標だけを指示するレベルよりも、アーキテクチャを定め、結果を取捨選択し、コードを再構成する創作上の判断のほうがより重要に作用する
- コードの著作権成立の有無とは別に、work-for-hire doctrine や広範なIP譲渡条項があれば、会社の時間・機材・プロジェクト・会社がライセンスしたツールで作られたAI支援コードも会社所有に帰する可能性が高い
- 所有権があっても、オープンソースライセンス汚染は別問題であり、とくにGPL系コードを実質的にそのまま複製した出力物はライセンス違反につながりうる
- 現時点で比較的明確な軸は、人間の著作性がない場合は保護されないこと、雇用契約による権利帰属、GPLの逐語的複製の危険であり、実務では裁判所の判断よりも先に記録保存とライセンススキャンの重要性が高まる
著作権の基準と未解決領域
- 著作権保護は人間が作った著作物にのみ適用され、AIが主として生成し、人間による意味のある創作的寄与がない成果物は、現行基準では保護対象にならない可能性がある
- Thaler事件 の後も連邦最高裁が本案を判断したわけではなく、DC Circuit の判決は維持されたものの、AI支援コーディングの成果物にそのまま適用された直接の判例はまだない
- 裁判所が直接扱っていない中核的な論点は、AI支援成果物 において人間の関与がどの程度あれば足りるのかという点である
- 純粋なAI生成画像のような 人間の関与がゼロの場合 とは異なり、コードは人間が一部の方向性を決めて承認することが多く、境界がより曖昧になる
- コード分野では、まだ 人間の著作性原則 をAIコーディング出力に直接適用した判決がない
- AIが作ったコードをほとんど修正せず受け入れた場合、誰も著作権を主張できない可能性 があり、競合他社がそのまま複製しても対抗手段が弱くなりうる
- 判断基準の中核は meaningful human authorship であり、目標だけを書くことよりも、構造を定め、結果を取捨選択し、設計を組み直す創作上の判断が重視される
人間の著作性を立証する方法
- 意味のある人間の寄与 は、割合や修正回数で機械的に計算されるものではなく、人間が実際に創作上の判断を下したかどうかが重要である
-
アーキテクチャの選択
- 複数の草案のうち何を 却下するかを決める 必要がある
- 特定の設計に合わせて結果を 再構成 する必要がある
- 「API用のrate limitingモジュールを作れ」のような短い指示の後に、ツールが複数ファイルを作成し反復修正した場合、人間の寄与が法廷で十分とされるかについては まだ明確な結論がない
- 大きく方向を変えながら手直ししたモジュールは人間の著作性が認められる可能性が高い一方、そのまま受け入れたコード は逆方向に解釈されうる
- Allen v. Perlmutter は、600件を超えるプロンプトとPhotoshop編集があっても、AIが作成した基本要素の登録が拒絶された事件であり、人間の関与の十分性を分ける重要な分岐点として残っている
- Zarya of the Dawn では、人間が書いたテキストだけが登録され、Midjourneyが作成した画像は除外された。この原則は、AI支援コードベースでも 人間が直接作った要素を分離して保護する 方向性とつながっている
- 設計文書は根拠になる
- コミットメッセージに残した設計判断も根拠になる
- ADRも根拠になる
- 意図的に方向を変えた痕跡が残るプロンプトログも役立つ
- 保護可能な部分を広げるには、何を自分で決定し、どう変えたのかを記録 しておくほうが有利である
-
雇用契約が先に分ける所有権
- コードが著作権保護の対象かを論じる前に、その権利が そもそも誰に帰属するのか を確認する必要がある
- 一般的な雇用契約は、職務範囲内で作られた成果物を会社所有とし、これは work-for-hire doctrine で説明される
- 会社の業務時間、会社プロジェクト、会社機材、会社が提供したAIコーディングツールを使って作られた成果物は、手書きコードでもAI支援コードでも 会社所有として扱われる可能性が高い
- 実際の契約書は通常、基本法理よりも広く書かれており、次の文言があれば AI支援コード まで包含する可能性が高い
- 会社の機材や資源を使って作られた成果物も含まれうる
- 雇用期間中に作られた発明や開発物も含まれうる
- 会社がライセンスしたツールの助けを借りて作られたソフトウェアも含まれうる
- とくに company-licensed tools という文言は個人プロジェクトにまで及ぶ可能性がある
- 会社が Claude Code、Cursor、Copilot をチーム向けに導入していて
- 同じツールを個人時間のサイドプロジェクトでも使っていた場合
- 広範なIP譲渡条項の下で会社が権利を主張する余地が生じる
- 会社コードがIDE内で開かれていてAIがそれを見られたという理由だけで、出力物が会社IPの 派生著作物 になるという主張は、法的にそのまま成立するとまでは言いにくいとされる
- ただし契約文言が広ければ、AIが実際に何をしたかとは別に、外形上の主張可能性 は生まれうる
- サイドプロジェクトを切り分けるには、個人アカウント、個人機材、自費のツール でワークフローを完全に分離するほうが安全である
オープンソースライセンス汚染のリスク
- AIが作ったコードを所有していても、そのコードが 見えないオープンソースライセンス義務 を持ち込んでいる可能性は別問題である
- AIコーディングツールは公開コード、とりわけ GPL、LGPLのような copyleft ライセンスのコード を含む大規模データで学習されている
- copyleft ライセンスは、そのコードの 派生著作物を配布する際に同一ライセンスで公開する義務 を伴わせる
- GPLコードの派生物であれば、自分のソースも同じライセンスで公開しなければならない
- ライセンスを知らなかったという事情は抗弁にならない
- 法的リスクの基準は機能的類似性ではなく、実質的かつ相当程度の逐語的複製 にある
- GPLコードのように動作する成果物と
- GPLコードを ほぼそのまま再現した成果物 は別問題である
- リスクは逐語的複製の側に集中しているが、現在のコードベースがどちらに当たるかは スキャンなしでは判断しにくい
- 2026年初頭の chardet community dispute では、Claudeでchardetを書き直してMITライセンスで再配布した事例があり、それをclean room実装とみなせるかをめぐって対立があった
- この件は 裁判ではなくコミュニティ内の紛争 であり、法的に結論が出たわけではない
- ただしGPL系コードを そのまま複製 すればライセンス違反になるという点自体はすでに確立している
- まだ確定していない点は、AI出力が学習データのパターンを再現した場合に、それを 逐語的複製 とみなすかどうかである
- 企業のM&Aアドバイザリーの現場ではこのリスクは現実の論点として扱われており、AIコードベースのライセンススキャン がデューデリジェンス項目に入っている
- Doe v GitHub は、Copilotがライセンス付きコードを出典表示なしに再現するかを争っており、2026年4月時点で Ninth Circuit で継続中である
- 一審は大半の請求を棄却したが、控訴は維持されている
- 訴訟結果とは無関係に、GitHub は duplicate detection filters を追加しており、業界実務も変わってきている
実務ですぐにやるべきこと
-
ライセンススキャンの実行
- AI支援コードベースでは、まず オープンソースライセンススキャン を実行することが重要である
- FOSSA — エンタープライズで広く使われる総合ツール
- Snyk Open Source — GitHub連携が優れており、開発チームのワークフローに合わせやすい
- Black Duck — M&Aデューデリジェンスで標準的に使われることが多い
- これらのツールはコードベースをスキャンして、既知のオープンソースライブラリとの一致 と関連ライセンスを見つけてくれる
-
人間の創作的寄与の記録
- 意味のある人間の著作性 を立証する資料は、日常のエンジニアリング過程でもすでに作られているが、意図的に保存しておくことで効果が大きくなる
- コミットメッセージには、AIが生成した結果そのものよりも 何を、なぜ変えたのか を残すべきである
Restructured Claude’s module architecture, rejected initial state management approach, rewrote error handling from scratchのような記録は根拠になるAdd rate limiting moduleのような記録だけでは人間の寄与を示しにくい
- Claude Code や Cursor の やり取りの記録 も、エクスポートやスクリーンショットで保管しておくほうがよい
- 生成コードより先に書かれた 設計文書、ADR、メモ は、人間が先に構造を決めた痕跡として使える
-
雇用契約のIP条項の確認
- 契約書では intellectual property、IP assignment、work product の項目を直接確認すべきである
- 「勤務時間中に作った成果物」は「会社資源を使って作った成果物」より狭い
- 「会社事業に関連するもの」は「すべてのソフトウェア開発」より狭い
- company-licensed tools という文言は、個人プロジェクトにもAIツール使用の痕跡を結び付けうる
- 独立プロジェクトを行うなら
- 開始前に 書面による carveout を協議すべきである
- 完全に個人機材、個人時間、個人ツールで分離すべきである
- 会社による主張可能性を受け入れて進める必要があるかもしれない
-
Anthropicの利用規約タイプの確認
- 商用リリース前に anthropic.com/legal を確認し、consumer terms と commercial terms の違いを見る必要がある
- free / Pro は出力物の権利をユーザーに渡すが、IP indemnification の範囲はより狭い
- API / enterprise は出力物の権利譲渡に加え、承認された利用や出力物による著作権侵害主張に対する防御範囲をより広くしている
- ただし、このような免責もコードベース内部の GPL汚染問題 まで代わりに解決してくれるわけではない
- その部分はライセンススキャンと内部ガバナンスで自ら管理しなければならない
今確定していることと、まだ開かれていること
- すでに比較的明確な軸は3つある
- 人間の著作性がない著作物 は著作権保護を受けられない
- work-for-hire doctrine は、コードがどのように生成されたかに関係なく適用されうる
- GPLコードの逐語的複製 はライセンス違反になる
- まだ裁判所が明確に線引きしていない軸は2つある
- agentic ワークフローにおいて、どれだけの人間の指示と修正 があれば十分な著作性になるのか
- AI出力が学習データのパターンを再現した場合、それが 逐語的複製 と評価されるのか
- 近い将来こうした争点が大規模訴訟に発展するかどうかは、純粋に推測の領域 にとどまっている
- 実際にこの不確実性が最も早く現実問題になる場所は、法廷よりも M&Aデューデリジェンス と 機関投資家の審査 である
- 買収者や投資家はすでに取引完了条件としてこうした質問を投げかけており、今すぐその状況でなくても 記録とスキャンを先回りして整えておくほうが有利 である
3件のコメント
コードは保護の対象になり得るのか？
含まれます
Hacker Newsの意見
これは 画像生成の判例 と同じ類型として見るべきだと思う
Zarya of the Dawn ですでに整理されたように、人が書いた要素は保護されるが、AIが生成した画像は保護されず、人が選択・プロンプト・キュレーションしたキャラクターデザインも著作権は認められなかった
コードも変わらないと思う。Claudeに関数を作れと指示するのは、自分で関数を書くことよりも、Midjourneyにフレームを出させることに近い
エンジニアが違って感じる理由は、たいてい コンパイラの比喩 を思い浮かべるからだが、コンパイラは同じ入力なら同じ出力が出る決定論的なツールであり、LLMはそうではない。Copyright Officeが線を引いているのもまさにここで、画像の分野が先にその結論に達した
誰かが同じプロンプトをもう一度使って似たように再現できるという事実が、その人の権利主張自体を無効にするのかも曖昧だ
cert denial は法を確定するものではない
最高裁が上告受理を拒否する理由は本案と無関係なことも多く、それ自体で争点を全国的に settled させるわけではない
最高裁が Thaler appeal を審理しなかったからといって下級審の論理を承認したり全国的な結論を出したわけではなく、ただDC Circuitの判決は生き残り、Copyright Officeの立場も維持され、まだ反対判断を出した裁判所はない、という趣旨だった
しかし、いま引用されている文言はもうTFAにはない
列挙された要素のうち、どれが著作者性を認めるのに十分かを確認した判例が思い浮かばない
特に、結果を何度も拒否して別の方向へ誘導した行為が人間の著作として認められた例があるのか知りたい
現時点ではっきりしているのは、人が書いていないコード部分は disclaim でき、実際にCopyright Officeも開示と disclaimer を求めているということだ。もっと引用できる資料があれば見たい
その判決を覆したときの核心的な法的効果こそ、その先例効の喪失ではないか
最高裁の審理を経ていない判例は理論上いつでも争えるが、実際にはたいていそのまま法律のように機能し、覆されるまで維持される。この件も大きくは違わないように見える
自分がコードレビューしたことは meaningful なのか
生成されたコードを自分が修正・編集したら人間の著作として扱われるのか
cert denial は最高裁が事件を取り上げなかったというだけで、下級審の論理を承認したり全国的に結論を出したわけではない
DC Circuitの判決は生きており、Copyright Officeの立場も一貫しているが、これは最高裁が確定させた法というより 安定した doctrine に近い
エージェントに指示した人が成果物の著作権を持つべきだとは思うが、そもそもそのエージェントが作れるようになった土台自体が 盗用されたIP に依拠していると思う
特にOSSでは、こうしたやり方が copyright washing を可能にするのが心配で、だからOSS開発者なら、自分が耐えられる範囲で最も強い copyleft ライセンスで公開するのがよいと思う
https://jackson.dev/post/moral-ai-licensing/
原本をまだ持っているなら、いったい何が盗まれたというのか
Dowling v. United States, 473 U.S. 207 (1985) でも、無断販売は National Stolen Property Act 上の "stolen, converted or taken by fraud" な財産ではないとされた
LLMの出力が裁判所で十分に派生的だと判断されれば、とりわけそのLLMが侵害された原作で学習されていたならなおさら、その派生出力を再配布した人が著作権侵害の責任を負う
LLMを作る行為は変形的であり得ても、侵害する出力そのものはそうではない
だから著作権がかえって発展を妨げるなら、例外を設けるのは十分に妥当だと思う
Community for Creative Non Violence v. Reid(https://en.wikipedia.org/wiki/Community_for_Creative_Non-Violence_v._Reid) を見ると、仕事を発注して方向性を示したからといって発注者が著作者になるわけではなく、実際に作業した人が著作者になる
契約で権利譲渡は可能だが、サルの自撮りのような事件以降、著作権は人間にしか与えられないという点も固まっている
LLMは人間ではないので著作権を持てず、法的な著作権がないなら、その権利をあなたに譲渡する権限もない
自分がコードを書くときも、教育とキャリアを通じて見てきた膨大なソースコードの影響を受けているし、LLMも見たコードをもとにその後の出力を整えているという点では似ている
「そのコードは読む権利がなかった」という反論がすぐ出てくるが、その論理もあまり納得できない。自分が学んだコードの大半には著作権があり、自分個人のコードでない限り、権利はたいてい他人のものだった。NDAや国防関連の機密コードでさえ、その後の自分のコーディングの仕方に影響を与えた
芸術も同じだ。写真では Ansel Adams、絵では Bob Ross やさまざまな師匠たちの影響を受け、他人の作品で見た断片を自分の視点と混ぜて別の何かを作ってきた
だからといって、その影響関係だけで自分の成果物に誰かが権利を主張できるとは思わない
自分の後輩たちも自分のコードから学んできたし、自分が書いたソフトウェア開発の本もある。いつか自分の美術作品も、誰かが取り込む価値を持つようになればと思う
LLMが登場するずっと前から、自分の仕事が自分と一緒に封印され、アイデアが墓場まで持っていかれることを望んだことはない
結局、私たちは皆 巨人の肩の上 に立っており、先行する仕事を取り込まずして、今成し遂げたことのごく一部すらできなかったはずだ
数十年後には自分は死に、名前もすぐ忘れられるだろうが、自分が作ったソフトウェアや写真、絵が時の中にさざ波を残すなら、それは小さな不死のように感じられる
生成コメント をHNにもう投稿しないでほしい
ルール上許可されておらず、すでに30回以上そういうパターンが見られる
もちろん100%確信しているわけではないが、ソフトウェアの判定と全体パターンを見るとかなり説得力がある
https://news.ycombinator.com/newsguidelines.html#generated および https://news.ycombinator.com/item?id=47340079 を参照
返信にAI assistantを使いましたし、今後は使いません
この質問は知的遊戯としては面白いが、現実では結局 金を持っている側 が取る可能性が高いと思う
Claudeが書いたという理由だけでAnthropicがClaude Codeを持てないと期待するのは、希望的観測に見える
すべての国が金のある側を暗黙に支持するわけでもないので、結果を予断するのは難しい
Claudeが書いたかどうかより、それを指示したエンジニアたちの雇用契約ゆえに会社が権利を持つというほうがもっともらしい
一方でDMCA削除要請の問題はもっと面白い。DMCAは請求人が著作権所有を善意で主張しなければならない
後に裁判所が、そのコードベースは主としてAIが書いたもので著作権の対象ではないと見れば、その 8,000件の takedown は bad faith DMCA請求として争いうる
所有権よりも、こちらのほうがより切り分け可能で現実的な法的争点だ
米国の法体系では、モデルは人ではなく、したがって財産を所有することも、自分が持っていない知的財産を契約で再譲渡することもできない、という点は比較的明確に見える
それなのに捜査機関が grokがCSAMや revenge porn のような違法物を作る問題にはあまり関心がないように見えるので、結局よいものだけ所有して悪い責任は回避する形になるのではと奇妙に感じる
企業の立場では、かなり抜け目のないアプローチに見える
まず claude code を使って作り、そのあとでそのコードが誰のものか考える、という態度だ
今まわりで起きている gold rush は、経営陣の近視眼性を露呈していると思う。うちの会社のEMたちも、できるだけ早くClaudeを使えと強く推してくる
第一に、Claude Codeに依存しすぎるとコードベースへの理解を失う
第二に、XPやコードレビューのような良い開発習慣が壊れる。いまやClaudeがClaudeのコードをレビューしているようなものだ
第三に、チームワークを壊す。もともとFEチームとBEチームに分かれていた仕事を、一人の開発者がバックエンドからフロントエンドまで全部まとめて処理するほうが、より簡単で安くなってしまうからだ
第四に、以前はコードそのものが文書だとしてコメントを軽視していたのに、今では コンテキスト限界 のためにClaude向けに再び説明を書かなければならない。人が理解できなければその人の責任だったのに、Claudeの狭いコンテキストのために突然退化を受け入れなければならないのは不公平に感じる
まだ言えることはあるが、こうした文化変化の駆動力は結局のところ金だ。だからこの状況を gold rush と呼んで、ポップコーン片手に眺めている
Copilot が最初に出たときは、ライセンス帰属の問題のせいで会社のコードには使うなという警告がはっきりあった
今は何が変わったのか。Anthropicが法的防御と indemnify をしてくれると言ったことで空気が変わったのか
バックエンドとフロントエンドは互いに噛み合うよう設計すべきで、チームが分かれていると、むしろ調整コストのほうが大きくなる
人間の頭の中のモデルが飢えるように消えていけば、障害時にどう動くのか、今後どうするのかを責任を持って説明するのも難しくなる
誤った一般化が入り込んでも、AIたちがコードもレビューも承認もすべて通してしまえるのなら、実際に誰がハンドルを握っているのか分からない
たいていは要件や落とし穴をチームで一緒に議論しつつ、実装責任は一人が持つほうがよいと思う
EU AI Act がここにさらに一層加わる
Article 50は、AIが生成または操作したコンテンツを最終利用者に開示することを求めており、これはモデル提供者ではなく deployer に課される透明性義務だ
したがって、著作権の問題が人間のプロンプターに有利に整理されたとしても、AI補助の成果物を大規模に配布する企業は別個の開示義務を負う
ほとんどはまだこれをきちんとやっていない
所有権の問題と開示義務は互いに独立しているのに、組織はしばしば両者を混同する
この条項は、内部アプリケーションのコードよりも、AIが作ったものを本物のように見せる映像のようなものに、より適しているように見える
欲しいコードの仕様をツールに与えたなら、それはすでに 創作的入力 を与えたと見るほうが明らかだと思う
結局コンパイラも似たようなものではないか。LLM agent は従来のコンパイラよりはるかに高度で、ずっと詳細でない仕様だけでも結果を出せるツールに見える
そのコードを所有するには、請負人が権利を明示的に譲渡しなければならなかった
たとえば「Pythonで rate limiter を書いて」とだけプロンプトを入れたなら、APIもリクエストバケットアルゴリズムもカウンタの保存場所も自分では決めていない
事実を述べただけであり、事実それ自体は本質的に創作的ではない
コンパイラは、その結果のバイナリが別個の著作物として扱われない点も違う。画像フォーマットをPDFに変えても同じ著作物なのと似ている
一方でLLMはそうではない。入力は著作権の対象でないかもしれず、出力は機械的変換ではなく選択が介在する
実際の利用でも、同じプロンプトを10回回せば意味のある違いを持つ結果が10個出ることがある
だから どのレベルのプロンプティングでも十分な創作性 と認められるだろうという見方には疑問がある
核心は入力を与えたかどうかではなく、出力の創作的表現が人間の著作を反映しているかどうかだ
従来のコンパイラでは、プログラマがソースのすべての表現を著作するが、LLMではプログラマは意図だけを与え、構造・名前・パターン・実装のような表現上の決定はモデルが下す
この違いが法的に重要かどうかは Allen v. Perlmutter で現在争われており、2026年初頭の summary judgment ブリーフィングも終わっているので、次の節目となる判決になり得る
これらすべては理論としては興味深いが、実際にはたいてい重要ではないと思う
ほとんど誰も、自分のコードが強い moat になると本気で信じておらず、著作権の対象だという感覚も現場では弱い
自分も複数の雇用主のもとで似たようなコード片を繰り返し書いてきたし、たいていのエンジニアもそうだろう。Stack Overflowのような所から持ってきたコードも、帰属を厳密に問わず使うことがよくある
この問題はたいてい、遺恨を伴う争いの中で表面化する。たとえばOracleが、Androidで自社APIをあまりに似せて模倣したとしてGoogleを訴えたのがその典型で、最高裁は最終的に fair use と見た
高頻度ヘッジファンドが退職した従業員を相手に訴訟することもあったし、米国では誰でもどんな理由でも訴えることができる
だからEllisonがPageとBrinを相手に最高裁まで争うようなことはあり得るが、99.9%のケース では実務上ほとんど影響がないと感じる
https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
コードを非常に大きなIPであり営業秘密だと見る人がとても多い
CTOとして「一般的にコードはそこまで大した秘密ではない」と言うと、しばしばショックを受けたような顔をされる
ある会社は、NDA下でのソースコード開示を要求する大口契約を、ほとんど諦めかけていたが、なぜそれが過剰反応なのか説明すると理解はしてくれた
それでも、そのような古い考え方は今もなお強く残っている
今まさにその convergence を話しているわけだが、書くべきコードのすべての文字が必要なAPIによって事実上あらかじめ決まっているなら、そこに芸術的表現も著作権もない
しかし、まったく新しいAPIを設計するなら、その部分は保護されうる
あなたが挙げた短い断片はそうでないかもしれないが、より大きな単位では会社も個人も、コードが著作権法上の知的財産だと概ね信じている
コードが著作権の対象でないなら、GPLはどこから力を得るのか
たとえばMicrosoftのコードがReactOSに混入したかもしれないという疑いだけで、なぜプロジェクトが何か月も何年も locked-down review mode に入らなければならないのか
雇用契約でなぜ企業がコードの著作権所有を明記するのか
むしろAPIや相互運用性、あまりに些末な実装を除けば、ほとんど誰もがコードの著作権性を認めていると思う
エミュレータ開発者やReactOS開発者に聞けばよい
https://reactos.org/forum/viewtopic.php?t=21740
「Claude CodeやCursorが生成し、あなたが意味ある修正をしていないコードには、誰の著作権もないかもしれない」という話にも例外はある
そのコードが既存著作物の 実質的な抜粋 をそのまま繰り返していたなら、元の著作者は依然として自分の著作権を主張でき、すぐに 侵害 の問題につながる