「お金を払って作ってもらったシステムなのに、ほかの会社に改修を頼もうとしたら断られた」
「開発会社を変えたいが、ソースコードを渡してもらえない」
システムの外注では、こうした相談が少なくありません。
原因の多くは、プログラムの著作権を契約でどう扱ったかにあります。
代金を払ったからといって、ソースコードの著作権が自動的に発注者のものになるわけではありません。
本記事では、「ソースコードは誰のものか」という疑問に対して、著作権法の基本ルール、契約書で必ず確認すべき条文、発注者が取れる3つの選択肢を、開発会社の立場から解説します。
ベンダーロックインやデータが取り出せない問題の背景を知りたい方にも役立つ内容です。
プログラムの著作権とは
プログラムの著作権とは、ソースコードという「表現」を、作った人に無断でコピー・改変・配布させない権利です。
著作権法では、プログラムは小説や絵と同じ「著作物」の一つとして明記されています（著作権法10条1項9号）。
特許と違い、登録などの手続きをしなくても、書いた時点で自動的に発生します。
守られるもの・守られないもの
著作権で守られるのは、あくまで書かれたコードそのものです。
「どんな機能があるか」「どういう考え方で処理するか」といったアイデアは対象外です。
| 著作権で守られるもの | 著作権で守られないもの |
|---|---|
| ソースコード（書かれた命令の並び） | プログラム言語そのもの（PHP、Javaなど） |
| コードを変換したプログラム（実行ファイル） | 規約（通信の取り決めなど） |
| 設計書・マニュアルなどの文書（別の著作物として） | 解法（アルゴリズム・処理の考え方） |
| 画面デザインの一部（創作性がある場合） | 業務の流れ・機能のアイデア |
言語・規約・解法が保護されないことは、著作権法10条3項に定められています。
つまり、同じ機能のシステムを別の会社がゼロから作り直すこと自体は、著作権の問題になりません。
問題になるのは、既存のソースコードをコピーしたり、手を加えて使ったりする場面です。
「著作権」と「所有権」は別物
よく混同されるのが、著作権と所有権です。
納品されたDVDやサーバー、プログラムの複製物を「持っている」ことと、そのプログラムを「改変・複製してよい」ことは別の話です。
本を買っても、その本を勝手に印刷して売れないのと同じ構造です。
ソースコードは誰のもの？著作権法の基本ルール
著作権は、原則として実際にコードを書いた人（著作者）に発生します。
発注者がアイデアを出し、仕様を決め、代金を払っても、それだけでは著作者になりません。
| 作られ方 | 契約で何も決めていない場合の著作権者 |
|---|---|
| 自社の社員が業務で書いた | 会社（職務著作） |
| 開発会社に外注した | 開発会社 |
| 開発会社がさらに下請けに出した | 実際に書いた下請け会社 |
| フリーランス個人に依頼した | そのフリーランス本人 |
社員が書いたコードは会社のもの（職務著作）
会社の指示で、社員が業務として作ったプログラムは、契約や就業規則に別の定めがなければ会社が著作者になります（著作権法15条2項）。
文章やイラストと違い、プログラムは「会社名義で公表すること」が条件になっていない点が特徴です。
そのため、社内で内製したシステムの著作権は、通常は会社に残ります。
外注したコードは、契約がなければ開発会社のもの
一方、外部の開発会社に作ってもらった場合、職務著作は当てはまりません。
著作権は開発会社に生まれ、発注者に移すには「著作権を譲渡する」という契約上の約束が必要です。
請負契約で代金を払っただけでは、発注者が手にするのは「納品物を使う権利」にとどまるのが基本です。請負と準委任の違いは準委任契約と請負契約の違いで解説しています。
著作権がなくても、発注者が自由にできること
著作権が開発会社に残っていても、正規に受け取ったプログラムを自社のコンピュータで使うために必要な範囲なら、複製や改変は認められています（著作権法47条の3）。
たとえばバックアップを取る、自社の環境で動くよう調整する、といった範囲です。
ただし認められる範囲は限られており、機能追加や他社への改修依頼、別システムへの流用までこの規定で自由にできると考えるのは危険です。
著作権が開発会社に残ると起きやすい5つの問題
著作権が開発会社にあること自体は、珍しいことでも違法なことでもありません。
問題は、発注者がそれを知らないまま運用を続け、困ったときに初めて気づくことです。
1. ほかの開発会社に改修を頼めない
改修は、既存のコードに手を加える行為です。
改変する権利（翻案権）が開発会社にあれば、別の会社に改修を頼むには元の開発会社の許諾が要ります。
結果として、改修や保守を元の会社に頼み続けるしかなくなります。
2. 保守費用の交渉力がなくなる
乗り換え先がない状態では、保守費用や改修見積もりが妥当かどうかを比べられません。
これがいわゆるベンダーロックインの典型的な形です。
公共分野でも、システムの著作権が開発会社にあることを理由に、その会社と随意契約で改修を進める例が公開資料に見られます。
3. 開発会社の廃業・撤退で改修が止まる
開発会社が廃業したり、その分野から撤退したりすると、改修の許諾を得る相手がいなくなります。
ソースコード自体を受け取っていなければ、手を入れることすらできません。
小規模な開発会社やフリーランスに依頼する場合ほど、事前に決めておく価値があります。
4. 自社サービスとして外販・展開できない
社内用に作ったシステムを、グループ会社や取引先に提供したくなることがあります。
著作権が開発会社にあると、複製して配る行為に許諾が必要です。
逆に、開発会社が同じコードを同業他社に売ることも、契約で制限していなければ止められません。
5. ソースコードそのものが手元にない
著作権の問題とは別に、そもそもソースコードが納品物に含まれていないケースもあります。
動くシステムは受け取っていても、コード一式や設計書、サーバーの管理権限が開発会社側にしかない状態です。
権利があっても現物がなければ、乗り換えは実質的にできません。開発会社を替えるときの手順はシステム開発の引き継ぎの進め方で解説しています。
特定の開発会社から抜け出せなくなる仕組みと対策については、ベンダーロックインの罠から抜け出す方法で解説しています。
契約書で必ず確認したい「27条・28条」と著作者人格権
「著作権は発注者に帰属する」と書いてあれば安心、とは言い切れません。
著作権の譲渡には、法律上のつまずきやすい点が2つあります。
「すべての著作権」だけでは改変する権利が移らない可能性
著作権法61条2項では、譲渡の契約で27条と28条の権利をはっきり書いていないと、それらは譲渡した側（開発会社）に残ったものと推定されます。
27条は改変・翻案する権利、28条は改変してできたものを使うときの原作者の権利です。
プログラムでいえば、改修・機能追加・移植に関わる、発注者にとって最も大事な部分です。
そのため、契約書には次のように条文番号まで書くのが実務の定番です。
（記載例）本件成果物に関する著作権（著作権法第27条及び第28条に定める権利を含む。）は、検収完了をもって甲に移転する。
契約書の著作権条項に「第27条及び第28条」の文字があるかどうかを、まず確認してください。
著作者人格権は譲渡できない
著作権とは別に、作った人には「著作者人格権」があります。
勝手に内容を変えられない権利（同一性保持権）などが含まれ、これは他人に譲渡できません（著作権法59条）。
そこで契約では「著作者人格権を行使しない」という不行使特約を入れるのが一般的です。
確認すべき条項チェックリスト
| 確認項目 | 具体的に見るポイント |
|---|---|
| ① 著作権の帰属先 | 発注者・開発会社・共有のどれか |
| ② 27条・28条の特掲 | 譲渡する場合、条文番号が明記されているか |
| ③ 移転のタイミング | 検収時か、代金支払い時か |
| ④ 除外される部分 | 開発会社の既存部品・汎用部品の扱い |
| ⑤ 利用許諾の範囲 | 除外部分を、発注者が改修・継続利用できるか |
| ⑥ 著作者人格権 | 不行使特約があるか |
| ⑦ ソースコードの納品 | 納品物にコード一式・設計書が含まれるか |
| ⑧ 第三者の権利 | オープンソースや外部サービスの利用条件 |
著作権の帰属パターン3つと選び方
経済産業省が公表し、情報処理推進機構（IPA）が改訂を続けている「情報システム・モデル取引・契約書」でも、著作権の帰属は1つに決めつけず、複数の案が用意されています。
大きく分けると、次の3つです。
| パターン | 中身 | 発注者のメリット | 注意点 |
|---|---|---|---|
| 開発会社に帰属 | 著作権は開発会社に残し、発注者には利用を許諾 | 既存部品の流用で費用・期間を抑えやすい | 他社への改修依頼・外販に許諾が必要 |
| 発注者に帰属 | 汎用部品などを除き、検収時に発注者へ移転 | 改修先を自由に選べ、乗り換えやすい | 費用が上がる場合がある。除外部分の範囲を要確認 |
| 共有 | 発注者と開発会社が共同で持つ | 双方が一定の権利を持てる | 行使に相手の同意が要り、かえって動きにくい |
「発注者に全部」がいつも正解とは限らない
開発会社は、ログイン機能や帳票出力などの汎用的な部品を、複数の案件で使い回して開発費を下げています。
これらまで発注者に譲渡すると、開発会社は以後その部品を使えなくなるため、同じものを作り直すか、価格を上げるしかありません。
そのため実務では、「その案件のために新しく書いた部分は発注者へ」「汎用部品は開発会社に残して利用を許諾」という分け方が多く見られます。
選び方の目安
- 長く使い、改修を続ける基幹的なシステム
発注者帰属（汎用部品は除外＋利用許諾）が向いています。 - 自社サービスとして外販・横展開したい
発注者帰属に加え、除外部分の再配布まで許諾範囲に入れます。 - 費用を抑えたい小規模なツール
開発会社帰属でもよいですが、ソースコードの開示と改修の許諾は確保します。 - 共有
特別な理由がなければ避けるのが無難です。
大事なのは帰属先そのものより、「将来、自社が困らない範囲の権利が確保されているか」です。
発注前に決めておきたい6項目
著作権の条項は、見積もりや仕様が固まった最後に、ひな形のまま流されがちです。
次の6項目は、見積もり依頼の段階で開発会社に伝えておくと、後からの揉めごとを防げます。
| 決めること | 具体的に確認する内容 |
|---|---|
| ① 著作権の帰属 | 発注者帰属か開発会社帰属か。譲渡なら27条・28条の明記 |
| ② 除外部分の範囲 | どの部品が開発会社に残るか、一覧で示してもらえるか |
| ③ 許諾の範囲 | 除外部分を他社に改修させてよいか、期間の制限はないか |
| ④ 納品物の中身 | ソースコード一式、設計書、構築手順書、データベースの定義 |
| ⑤ 管理権限 | サーバー・ドメイン・コード置き場のアカウントの名義 |
| ⑥ 契約終了時の扱い | 保守契約を終えるときの引き継ぎ資料とデータの受け渡し方法 |
著作権の帰属と納品物の範囲は、見積もり金額にも影響します。
条件によって、流用できる部品や必要な工数が変わるためです。
見積もりを比べるときは、これらの条件がそろっているかも確認してください。複数社への頼み方と比べ方はシステム開発の相見積もりの取り方で解説しています。
すでに契約済みの場合の対処法
契約書を見直したら、著作権が開発会社に残っていた、ということもあると思います。
その場合でも、打てる手はあります。
- 契約書と納品物を確認する
著作権条項、利用許諾の範囲、ソースコードを受け取っているかを洗い出します。 - 開発会社に許諾や譲渡を相談する
有償での著作権譲渡や、他社による改修の許諾に応じてもらえるケースもあります。 - データだけを取り出して作り直す
機能やアイデアは著作権の対象外なので、既存コードを使わずに新しく作り直す道があります。 - 次のリプレイスで条件を変える
今すぐ動けなくても、次回の契約で帰属と納品物を見直します。
作り直す場合は、既存のソースコードを見ながら書き写すと、著作権侵害を疑われるおそれがあります。
画面や業務の流れを参考にしつつ、コードは新しく書くのが安全です。
発注で失敗しやすい3つのパターン
開発会社のひな形をそのまま使う
開発会社が用意する契約書は、開発会社に著作権を残す内容になっていることがあります。
悪意があるとは限りませんが、発注者が読まずに押印すると、後から変えるのは困難です。
著作権と納品物の条項だけは、必ず自分の目で確認してください。
再委託先・フリーランスの権利処理を確認しない
開発会社がさらに外部へ作業を出している場合、実際の著作権は再委託先に生まれます。
開発会社と再委託先の間で権利がまとまっていないと、発注者への譲渡も成り立ちません。
契約書に「再委託先の権利も開発会社が責任をもって処理する」旨があるか確認します。
オープンソースやAI生成コードの扱いを決めない
今のシステムは、オープンソースのライブラリを組み合わせて作るのが一般的です。
これらは開発会社のものでも発注者のものでもなく、それぞれの利用条件（ライセンス）に従います。
AIで生成したコードを含め、どの部品がどの条件で使われているかを、一覧で受け取れるようにしておくと安心です。
よくある質問
Q. 代金を全額払えば、著作権は発注者のものになりますか？
A. 代金の支払いだけでは移りません。
著作権の移転には、譲渡の合意が必要です。
契約書に定めがなければ、著作権は実際に作った開発会社に残るのが原則です。
Q. 著作権を発注者に移すと、費用は高くなりますか？
A. 案件によります。
新規に書いた部分だけを譲渡し、汎用部品は開発会社に残して利用許諾する形なら、大きく変わらないことも多いです。
汎用部品まで含めた全面的な譲渡を求めると、作り直しが必要になり、費用が上がる傾向があります。
Q. 著作権がなくても、ソースコードを受け取ることはできますか？
A. できます。
著作権の帰属と、ソースコードを納品物に含めるかどうかは別の取り決めです。
「著作権は開発会社、ソースコードは納品し、発注者側での改修も許諾」という契約も可能です。
Q. 画面のデザインや仕様書にも著作権はありますか？
A. 創作性があれば、設計書やマニュアル、画面デザインも著作物になり得ます。
ソースコードだけでなく、「成果物全体」の著作権をどうするかを契約で決めておくと確実です。
Q. 開発会社を変えて、同じ機能のシステムを作り直すのは違法ですか？
A. 機能や業務の流れといったアイデアは著作権の対象外なので、新しくコードを書いて作り直すこと自体は、著作権の問題になりません。
既存のソースコードを流用・書き写す場合は、元の著作権者の許諾が必要です。
なお、元の契約に競業や秘密保持の取り決めがある場合は、その内容も確認しておきましょう。
まとめ
- プログラムの著作権は、原則としてコードを書いた人（外注なら開発会社）に生まれる
- 代金を払っても、譲渡の契約がなければ著作権は発注者に移らない
- 譲渡するなら「著作権法第27条及び第28条の権利を含む」と明記し、著作者人格権の不行使特約を入れる
- 帰属先は「開発会社」「発注者」「共有」から選ぶ。新規部分は発注者、汎用部品は利用許諾が現実的
- 著作権とは別に、ソースコード・設計書・管理権限を納品物に含める
- これらを決めておくことが、ベンダーロックインを防ぐ一番の近道
ソースコードは誰のものかという問題は、トラブルになってから考えると選択肢がほとんど残っていません。
見積もりを依頼する段階で、著作権の帰属と納品物の範囲を開発会社と話し合っておくことが、長く安心してシステムを使うための出発点です。
なお、本記事は一般的な考え方をまとめたものです。個別の契約内容については、必要に応じて弁護士などの専門家にご相談ください。
株式会社みんなシステムズでは、業務システムの受託開発を手がけています。
システムの発注や開発会社の乗り換えをご検討の際は、現在の契約と運用の状況をお聞かせいただければ、権利関係の整理も含めて進め方と概算費用をご提示します。お気軽にご相談ください。
