システム開発の著作権・ソースコードは誰のもの？ — 権利帰属と契約の落とし穴
開発費を払っても、著作権とソースコードは自動的には自社のものになりません。日本の法律では原則として作った側（開発会社）に著作権が残ります。権利帰属の基本、契約書で確認すべき条項、ソースコードを受け取れないと何が起きるかを、非IT担当の経営者向けに解説します。
開発費を払っても、著作権とソースコードは自動的には自社のものになりません。 日本の著作権法では、原則として「実際にプログラムを書いた側」＝開発会社に著作権が残ります。発注者が権利を持つには、契約書で明確に「著作権を発注者に譲渡する」と定めておく必要があります。ここを曖昧にしたまま発注すると、後からシステムを改修したい・別の会社に引き継ぎたいというときに、思わぬ制約にぶつかります。
この記事では、非IT担当の経営者・発注担当者に向けて、①著作権とソースコードは別物であること、②契約書のどこを見ればよいか、③権利を確保できないと何が起きるか、④発注前のチェックリスト、を順に整理します。
「著作権」と「ソースコード」は別の話
混同されがちですが、この2つは切り分けて考える必要があります。
| 意味 | 確保できないと困ること | |
|---|---|---|
| ソースコード（現物） | プログラムの設計図にあたるテキストファイル一式。これがないと改修・移行がほぼ不可能 | 別会社に引き継げない・自社で直せない |
| 著作権（権利） | そのプログラムを複製・改変・再配布してよいという法的な権利 | 現物があっても、勝手に改変・流用すると権利侵害になり得る |
つまり、「ソースコードを納品してもらう」ことと「著作権を譲り受ける」ことは別々に約束しておく必要があります。 ソースコードのファイルを受け取っても、著作権が開発会社に残っていれば、それを改変して使うには許諾が必要になる、という状態があり得るのです。逆に、著作権を譲り受けても、ソースコードの現物を渡してもらえなければ実際には手を入れられません。両方をセットで確保して、はじめて「自社のシステムとして自由に育てていける」状態になります。
日本の法律では、原則「作った側」に権利が残る
感覚的には「お金を出した自分のもの」と思いがちですが、著作権法の原則は逆です。プログラムの著作権は、特約がなければ実際に制作した開発会社（またはその従業員が作った場合は開発会社）に帰属します。発注者は「お金を払った」だけでは著作権を取得しません。
そのため、契約書に権利の扱いを書かなかった場合、「ソースコードは開発会社の持ち物」「発注者は使用を許諾されているだけ」という関係になっているケースが実務では珍しくありません。トラブルになるのは、多くの場合この前提を発注者が知らないまま数年が経ち、いざ改修や乗り換えの段になって初めて発覚するパターンです。
権利を確保できないと、実際に何が起きるか
- 別の開発会社に乗り換えられない: ソースコードを渡してもらえず、新しい会社が中身を確認できないため、事実上その開発会社にしか直せない状態（ベンダーロックイン）になる
- 改修のたびに追加費用と交渉が発生する: 権利が相手にあると、小さな変更でも都度見積もり・許諾のやりとりが必要になり、スピードとコストで不利になる
- 開発会社が廃業・音信不通になると詰む: 権利もソースコードも相手側にあると、会社が無くなった瞬間にシステムを触れる人が誰もいなくなる
- 他事業への流用・転売ができない: 自社の業務を切り出して別サービス化したいときに、著作権がなければ自由に使えない
特に3つ目のリスクは軽視されがちです。関連する対処は『作った会社と連絡が取れない』時の対処法や開発会社の乗り換え・引き継ぎガイドでも扱っていますが、そもそも発注時に権利とソースコードを確保しておけば、こうした事態の多くは未然に防げます。
契約書で確認すべき条項
難しい法律用語が並んでいても、見るべきポイントは限られています。契約書（またはその案）を受け取ったら、次の3点が明記されているかを確認してください。
| 確認項目 | 望ましい記載の例 | 曖昧・要注意な記載 |
|---|---|---|
| 著作権の帰属 | 「本件成果物の著作権は、検収完了後に発注者へ譲渡する」 | 権利の記載自体がない／「開発会社に帰属する」とだけ書かれている |
| 著作者人格権の不行使 | 「開発会社は著作者人格権を行使しない」 | 記載なし（改変時にクレームが出る余地が残る） |
| ソースコードの引き渡し | 「納品物にソースコード一式・ビルド手順・設計書を含む」 | 「納品物は稼働するシステム」とだけあり、ソースコードの記載がない |
「著作者人格権」は聞き慣れないかもしれませんが、これは著作権を譲渡した後も作った側に残る権利で、勝手に改変されない・氏名表示を求める、といった性質のものです。将来自由に改修していくためには、この権利を「行使しない」と一文入れてもらうのが実務上の定番です。契約形態（請負か準委任か）による違いはシステム開発契約の基本で解説しています。
なお、権利を発注者にすべて譲渡すると、開発会社は同じ部品（汎用ライブラリ等）を他社案件で再利用できなくなるため、費用が上がることがあります。「業務ロジックの権利は発注者、汎用部品は開発会社が再利用可」といった線引きで折り合うのも現実的です。大切なのは、あとで揉めないよう、どこまでが自社の自由になるのかを発注前に文章で決めておくことです。
オープンソース・生成AIが絡むとどうなるか
最近の開発では、既存のオープンソースソフトウェア（OSS）やAIが生成したコードが混ざることが普通です。ここにも権利の注意点があります。
- OSSにはライセンス条件がある: 「著作権を発注者に譲渡」と契約しても、OSS部分の権利までは移りません。OSSはそのライセンス（MIT・GPL等）の条件に従って使う前提です。GPL系など、改変・配布時に一定の義務が生じるものもあるため、どのOSSを使ったかのリスト（部品表）をもらっておくと安心です
- 生成AIが書いたコードの扱い: AIが生成したコードの著作権の考え方はまだ発展途上です。開発会社がどこまで権利を保証できるかを確認し、少なくとも「第三者の権利を侵害していないことの保証」を契約に入れてもらうとよいでしょう
発注前チェックリスト
- [ ] 契約書に「著作権を発注者に譲渡する」旨が明記されているか
- [ ] 著作者人格権を「行使しない」旨があるか
- [ ] 納品物にソースコード一式・ビルド手順・設計書が含まれると書かれているか
- [ ] 使用しているOSSのリスト（部品表）とそのライセンスを確認したか
- [ ] 第三者の権利を侵害していないことの保証条項があるか
- [ ] 権利を全譲渡する場合と、汎用部品は開発会社が再利用する場合とで、費用差を確認したか
これらは発注前に決めておけば追加費用がほとんどかからない一方、稼働後に「やっぱり権利をください」と交渉すると、費用も手間も大きく膨らみます。検収時に何を受け取るべきかは『検収』とは？納品時に確認すべきことも参考にしてください。
よくある質問
開発費を全額払えば、著作権も自動的に自社のものになりますか？
なりません。日本の著作権法では、特約がなければ著作権は実際に制作した開発会社に帰属します。発注者が権利を持つには、契約書で『著作権を発注者に譲渡する』と明記しておく必要があります。支払いの有無とは別の話だと理解しておくことが重要です。
ソースコードを納品してもらえば、著作権のことは気にしなくてよいですか？
完全ではありません。ソースコードの現物を受け取っても、著作権が開発会社に残っていれば、それを改変して使うには許諾が必要になる場合があります。実務では『ソースコードの引き渡し』と『著作権の譲渡』の両方を契約に入れておくのが安全です。
すでに稼働中のシステムで、契約に権利のことが書かれていませんでした。今からできることは？
まずは現在の契約書と納品物を確認し、ソースコードが手元にあるかを把握してください。そのうえで、開発会社に著作権譲渡やソースコード引き渡しを追加で交渉することになります。稼働後の交渉は費用が発生しやすいため、次回の改修や保守契約の更新のタイミングで併せて取り決めるのが現実的です。
著作者人格権の『不行使』とは何ですか？必要ですか？
著作者人格権は、著作権を譲渡した後も作った側に残る権利で、勝手に改変されないことなどを求められる性質のものです。将来システムを自由に改修していくには、契約で『著作者人格権を行使しない』と一文入れてもらうのが実務上の定番で、入れておくことを推奨します。
オープンソースを使った部分の権利はどうなりますか？
『著作権を発注者に譲渡』と契約しても、オープンソース部分の権利までは移りません。オープンソースはそれぞれのライセンス（MITやGPL等）の条件に従って使う前提です。どのオープンソースを使ったかのリスト（部品表）をもらい、ライセンス条件を確認しておくと安心です。
この記事に関連する無料ツール（登録不要・その場で結果）
お気軽にご相談ください
お問い合わせ