システム開発の著作権帰属は誰のもの？契約前の確認点
システム開発を外注するとき、「お金を払って作ってもらうのだから、ソースコードも自社のものになる」と考えてしまいがちです。しかし著作権法の原則では、そうとは限りません。この記事では、システム開発の著作権の帰属がどう決まるのか、契約書のどこを見ればよいのか、AI生成コードが含まれる場合に何が変わるのかを整理します。なお、ここで書くのは一般的な考え方です。個別の契約については、弁護士などの専門家にも確認してください。
著作権は、発注しても自動では移らない
原則は「作った側」が著作者になる
ソースコードのようなプログラムは、著作権法で「プログラムの著作物」として保護の対象になります。著作権は、著作物を創作した人（著作者）に、創作と同時に発生します。登録や届出は必要ありません。
発注側が費用を負担したかどうかは、著作者を決める条件ではありません。外注でシステムを作った場合、原則として著作権は実際に作った側に生まれます。
開発会社の社員が仕事として作った場合は、著作権法第15条の「職務著作」の規定により、会社が著作者になるのが一般的です。つまり、外注した成果物の著作権は、最初は開発会社の側にあります。個人のフリーランスが作った場合は、その個人が著作者です。開発会社がフリーランスに再委託している場合は、開発会社が権利を取得できているかどうかも関わってきます。
契約書に書かなければ、移転は起きない
著作権は、契約によって他者に譲渡できます。逆に言えば、譲渡の定めがなければ、納品後も著作権は開発会社に残ったままです。契約書に権利の条項がない、または曖昧なまま進めてしまうと、次のような場面で食い違いが起きやすくなります。
- 別の会社に保守や機能追加を頼もうとしたところ、改変してよいか判断できない
- 事業を他社に譲渡する、または出資を受けるときに、権利関係の説明を求められる
- 開発会社が、似た仕組みを別の顧客向けに再利用してよいかで意見が分かれる
契約書に何も書いていない場合でも、発注側がシステムを使う権利が全くないわけではなく、状況に応じて利用が認められると解釈される余地はあります。ただし、その範囲は個別の事情で判断されるため、後から争いになりやすい部分です。「書いていないから大丈夫」ではなく、「書いていないから不安定」と考えておくのが安全です。
著作権で守られるもの、守られないもの
もう一点、押さえておきたいのが保護の範囲です。著作権が守るのは、プログラムの具体的な表現（書かれたコードそのもの）です。著作権法第10条第3項は、プログラム言語、規約（通信規約など）、解法（アルゴリズム）には保護が及ばないと定めています。
新規事業では、ここが大切な論点になります。サービスのアイデア、機能の組み合わせ、ビジネスモデルは、著作権では守られません。事業の独自性を守りたい場合は、秘密保持契約（NDA）、競業の制限、場合によっては特許など、著作権とは別の手段も合わせて考える必要があります。著作権の帰属を決めることは重要ですが、それだけで事業の独自性が守れるわけではありません。
契約でよくある帰属の3つの形
システム開発の契約では、成果物の著作権の扱いは大きく3つに分かれます。経済産業省が公表している「情報システム・モデル取引・契約書」でも、著作権の扱いは契約で整理しておくべき論点として取り上げられています。確認する場合は、同資料の最新版を参照してください。
| 形 | 内容 | 向いている場面 | 注意点 |
|---|---|---|---|
| 発注側に譲渡 | 成果物の著作権を発注側に移す | 事業の中核となる独自システム | 開発会社が持つ既存資産の扱いを別途決める必要がある |
| 開発会社に留保し、利用を許諾 | 著作権は開発会社に残し、発注側は使用・改変の許諾を得る | 開発会社の共通基盤を土台にするとき | 許諾の範囲、期間、第三者への委託の可否を確認する |
| 共有 | 双方が著作権を持つ | 共同で開発した場合 | 共有著作権は、原則として全員の合意がなければ行使できない（著作権法第65条） |
どの形が正しい、ということはありません。システムの位置づけによって選ぶべき形が変わります。
注意したいのは共有です。「どちらも持てば公平」に見えますが、権利の行使や譲渡に相手の合意が必要になるため、将来の事業展開で身動きが取りにくくなることがあります。共有にする場合は、どちらが何をできるのかを、契約で具体的に書いておく必要があります。
新規事業のように、システムそのものが事業の価値になる場合は、中核部分の権利を発注側が持てるかどうかが重要になります。一方で、開発会社が長年使っている共通部品まで譲渡の対象にするのは現実的でないことが多く、「どこまでを自社の資産にするか」を切り分けることが現実的な落としどころになります。
譲渡契約で見落としやすい条項
「著作権は発注者に帰属する」と一文あれば十分、というわけではありません。次の点は、契約書の文面を読み込んで確認したい部分です。
翻案権・二次的著作物の利用権が含まれているか
著作権法第61条第2項は、著作権を譲渡する契約で、翻案権（改変・作り替える権利、第27条）と二次的著作物の利用権（第28条）が譲渡の対象として明記されていないときは、譲渡した側に残っていると推定する、と定めています。
システムは納品後に、機能追加や改修をして育てていくものです。改変にあたる権利が譲渡に含まれていないと、思い通りに改修できない恐れがあります。譲渡条項には「第27条及び第28条の権利を含む」といった特掲があるかを見ておきたい点です。
著作者人格権の扱い
著作権とは別に、著作者人格権（公表権・氏名表示権・同一性保持権）という権利があります。これは著作者本人に専属し、譲渡できません（著作権法第59条）。そのため実務では、「著作者人格権を行使しない」という特約を結ぶ形がよく使われます。
この特約がないと、改変に対して著作者が同一性保持権を主張できる余地が残ります。譲渡と合わせて、不行使の定めがあるかを確認しておくと安心です。
開発会社の既存資産と、オープンソースの扱い
開発会社が以前から持つ共通ライブラリやテンプレートが成果物に含まれる場合、これらは譲渡の対象外とし、利用の許諾を受ける形にするのが一般的です。このとき、許諾の範囲が「納品したシステムを使い続けるのに十分か」を確認します。許諾が限定的だと、システムは動くのに、別の会社に引き継げないといったことが起こりえます。
また、多くのシステムにはオープンソースソフトウェア（OSS）が使われています。OSSは、それぞれのライセンスの条件に従って使うものであり、発注側に「譲渡」できるものではありません。どのOSSを使っているか、そのライセンス上の義務は何か、一覧を提出してもらえるかを確認しておくと、後の事業展開で役立ちます。
権利が移るタイミング
著作権がいつ移転するのかも、契約で決めておく点です。検収が完了した時点なのか、対価の支払いが完了した時点なのかで、途中で契約が終了したときの扱いが変わります。開発が途中で止まった場合の成果物の扱いまで書いてあるかも、見ておきたいところです。
権利があっても、コードがなければ使えない
著作権の帰属を決めても、それだけで安心はできません。ソースコードそのものや、設計書などの資料が手元に渡されなければ、権利を実際に生かせないからです。
確認したいのは、納品物の範囲です。
- ソースコード一式（ビルド・実行に必要な設定ファイルを含む）
- 設計書、データベース定義書、API仕様書などのドキュメント
- 環境構築の手順書
- 利用しているライブラリやOSSの一覧
- 管理者アカウントやサーバー、ドメインなどの管理権限
なお、著作権法第47条の3には、プログラムの複製物の所有者が、自分で使うために必要な範囲で複製や改変をできる、という規定があります。ただし、あくまで必要な限度に限られ、契約で別の定めをすることも考えられます。この規定を前提に「何もしなくても自由に改修できる」と考えるのは避けたほうがよいでしょう。
引き継ぎや改修のしやすさは、コードの読みやすさや資料の整い方にも左右されます。この点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点でも整理しています。
AI生成コードが含まれる場合の注意
近年は、開発会社がAIを使ってコードを書くことも増えています。AIの活用自体は珍しいことではなくなりましたが、権利の面では新しい確認点が加わります。
生成された部分に著作権が成立するとは限らない
文化庁は2024年3月に「AIと著作権に関する考え方について」を公表しています。この中では、AIが生成したものが著作物にあたるかどうかは、人が創作的に寄与したかどうかで個別に判断される、という考え方が示されています。
つまり、AIが生成したコードのうち、人の創作的な関与が乏しい部分は、そもそも著作物と認められない可能性があります。その場合、契約で「著作権を譲渡する」と書いても、譲渡する対象の権利が存在しないことになります。
ここから、契約書で押さえたい点が見えてきます。著作権の譲渡だけに頼らず、成果物の利用・複製・改変を発注側が自由にできること、第三者への開示や委託ができることを、契約上の取り決めとして明記しておく考え方です。
確認しておきたい4つのこと
AIを使う開発会社に対しては、次の点を確認しておくと安心です。
- AIの利用範囲：どの工程で、どの程度AIを使うのか
- ツールの利用規約：使うAIサービスの規約上、生成物を商用利用できるか。入力した内容がAIの学習に使われないか
- 発注側の情報の扱い：発注側の業務情報や個人情報を、AIに入力するのか、しないのか
- 人による確認：生成されたコードを、人がレビューして品質の最終判断をしているか
特に3は、権利というより情報管理の問題ですが、契約前に確認しておくべき項目です。セキュリティ面の確認点はAI生成コードのセキュリティ｜確認点と人の役割に、人の確認が必要な理由はAI開発でも品質には人の確認が必要な理由にまとめています。
契約前に確認したいチェックリスト
ここまでの内容を、契約前の確認用に整理します。契約書のひな形を受け取った段階で、次の点に答えが書かれているかを見てください。
帰属と利用の範囲
- 成果物の著作権は、どちらに帰属するのか（譲渡・留保・共有のどれか）
- 譲渡の場合、第27条・第28条の権利が含まれると明記されているか
- 著作者人格権の不行使について定めがあるか
- 権利が移転する時期はいつか
既存資産と第三者のもの
- 開発会社の既存資産は何か、その利用許諾の範囲は十分か
- 使用するOSSの一覧と、ライセンスの条件が示されるか
- 再委託先（フリーランスなど）の権利処理は済んでいるか
納品と引き継ぎ
- ソースコード、設計書、手順書など、納品物の範囲が決まっているか
- 他の会社に保守や改修を頼むことが制限されていないか
- 契約終了後や、開発途中で終了した場合の成果物の扱いはどうなるか
AIを使う場合
- AIの利用範囲と、使用するツールの規約上の扱いが説明されているか
- 発注側の情報をAIに入力する場合のルールがあるか
- 生成物の利用・改変・開示について、契約上の取り決めがあるか
秘密保持と事業の独自性
- 発注側のアイデアや業務情報の秘密保持が定められているか
- 同種のシステムを他社向けに開発する場合の取り扱いはどうなるか
どの項目も、開発会社に「聞いてはいけないこと」ではありません。むしろ、これらに具体的に答えられるかどうかは、会社を選ぶ際の一つの目安になります。会社選びの視点全体はシステム開発会社の選び方｜新規事業で失敗しない7つの視点も参考になります。依頼から納品までの流れはシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方で、契約形態の種類は受託開発とは？依頼の流れ・契約形態・新規事業の選び方で確認できます。
仕様が固まる前に、権利の話をしておく
権利の話は、仕様が固まってから、あるいは開発が終わってからにしたくなるものです。しかし、帰属は「何を作るのか」と切り離せません。どの部分が事業の核で、どの部分が汎用的な部品なのかが見えて初めて、「ここは自社の資産に、ここは許諾で十分」という切り分けができます。
仕様の決め方に不安がある場合は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方や、仕様が決まってないシステム開発の相談は可能かも参考になります。
まとめ
システム開発の著作権帰属について、要点を整理します。
- 外注しても、著作権は自動では発注側に移らない。原則として作った側（開発会社など）が著作者になり、移転には契約での譲渡が必要
- 著作権で守られるのは具体的な表現であり、アイデアやアルゴリズムは対象外。事業の独自性は、秘密保持など別の手段も合わせて考える
- 帰属は「譲渡」「留保して利用許諾」「共有」に分かれる。システムの位置づけに合わせて選び、既存資産とは切り分ける
- 譲渡契約では、翻案権等の特掲（著作権法第61条第2項）、著作者人格権の不行使、権利移転の時期を確認する
- 権利があっても、ソースコードやドキュメントが渡されなければ使えない。納品物の範囲まで契約で決める
- AI生成コードには著作権が成立しない部分がありうるため、譲渡だけに頼らず、利用・改変・開示の取り決めも明記する
権利の問題は、トラブルが起きてから初めて気づかれることが多い分野です。契約前に一度、上のチェックリストで確認しておくと、後の選択肢が狭まるのを防げます。
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約するかを判断できる進め方をとっています。何を作るのかが見えた状態で契約に進めるため、納品物や権利について検討する際にも、具体的なイメージを持ちやすくなります。進め方の全体はJustFitのサービス紹介でご覧いただけます。