ソースコードの著作権は誰のものか：納品物と権利帰属の決め方

外注して作ったシステムのソースコードは、お金を払った発注側のものになる、と考えている方は少なくありません。しかし、日本の著作権法の考え方では、プログラムの著作権は原則として、実際にそれを作った側（開発会社）に生じます。発注側が権利を得るには、契約で著作権の譲渡や利用許諾を定めておく必要があります。契約書に何も書かれていなければ、発注側は「使うことはできても、自由に改変したり他社に保守を任せたりすることに制約がある」状態になりかねません。

結論から言うと、発注側が確認すべきポイントは三つです。著作権を譲り受けるのか、利用の許諾を受けるのかを明確にすること。開発会社が以前から持っている汎用的な部品やライブラリの扱いを分けて定めること。そして、将来ほかの会社に保守を移したり、自社で改修したりできる条件を、契約と納品物の両面でそろえておくことです。

この記事は、システム開発を外注しようとしている事業責任者や、契約書の確認を任された担当者に向けて書いています。著作権の基本的な考え方、譲渡と利用許諾の違い、汎用部品やオープンソースの扱い、納品物として受け取るべきもの、保守の移管で困らないための条件を、チェックリストとともに整理します。なお、権利関係の法的な解釈は個別の契約や事情によって変わるため、実際の契約書は弁護士などの専門家に確認してください。

ソースコードの著作権は原則として誰に帰属するか

プログラムは、著作権法で保護される「著作物」に含まれます。著作権は、著作物を創作した人に、登録などの手続きなしに発生するのが原則です。社内の従業員が業務として作ったプログラムであれば、一定の条件のもとで会社が著作者となる「職務著作」の考え方が適用されます。しかし、外部の開発会社に作ってもらった場合、作ったのは開発会社の従業員であり、職務著作として権利を持つのは開発会社になるのが一般的です。

つまり、発注側が代金を払ったという事実だけでは、著作権は移りません。著作権を発注側に移すには、契約書で「著作権を譲渡する」と定める必要があります。

ここで注意したいのは、「著作権」と「ソースコードを受け取ること」は別の問題だということです。ソースコードのファイルを受け取っていても、著作権が開発会社にあれば、無断で改変や複製をすることには法的な制約が生じうるのです。反対に、著作権を譲り受けていても、ソースコードや設計書を受け取っていなければ、実務上は改修できません。権利と現物の両方をそろえることが大切です。

著作権の譲渡と利用許諾の違い

ソースコードの権利の定め方は、大きく「譲渡」と「利用許諾」の二つに分かれます。

譲渡は、著作権そのものを開発会社から発注側に移すことです。譲渡を受ければ、発注側は自分の判断でソースコードを改変したり、別の会社に改修を依頼したりできます。一方、開発会社は同じコードを他の案件で使うことに制約を受けるため、譲渡を前提とすると見積もりに影響することもあります。

利用許諾は、著作権は開発会社に残したまま、発注側に一定の範囲で使う権利を認めることです。開発会社は同じ部品を他の案件でも使えるため、開発費を抑えやすい面があります。ただし、許諾の範囲が狭いと、将来の改修や保守の移管で制約を受けます。

譲渡を定めるときに注意すべき条項

著作権の譲渡を契約で定める場合、法律上の注意点がいくつかあります。代表的なのが、著作権のうち「翻案権」（改変して新しいものを作る権利）と「二次的著作物の利用に関する権利」です。著作権法では、これらを譲渡の対象として特に明記しないと、譲渡した側に残ると推定される扱いになっています。そのため、契約書では「著作権法第27条および第28条の権利を含む」といった書き方をするのが一般的です。

もう一つが「著作者人格権」です。著作者人格権は、作品の公表や氏名の表示、改変に関する権利で、譲渡ができないとされています。そのため、発注側が自由に改変できるように、開発会社が著作者人格権を行使しない旨を約束する条項（不行使特約）を入れることが多くなっています。

これらの条項の書き方や効力は、専門的な判断を伴います。契約書の確認は、弁護士など専門家の助言を受けて行いましょう。

権利が移るタイミングを決める

譲渡を定める場合は、権利がいつ移るかも明確にしておきます。よく使われるのは、納品時、検収完了時、代金の支払い完了時のいずれかです。開発会社の立場からは、代金の支払いと引き換えに権利を移したいと考えるのが自然です。発注側としては、開発の途中で契約が終了した場合に、それまでに作られた部分の権利と現物がどう扱われるかもあわせて確認しておくと安心です。分割で支払う契約であれば、支払いの区切りごとに対応する部分の権利が移る、という定め方もあります。

汎用部品とオープンソースの扱い

ソースコードの権利を考えるうえで避けて通れないのが、開発会社が以前から持っている汎用的な部品と、オープンソースソフトウェア（OSS）の扱いです。

開発会社の汎用部品

開発会社の多くは、ログイン機能や管理画面の土台など、複数の案件で使い回す汎用的な部品やひな形を持っています。これらを使うことで、開発期間と費用を抑えられます。しかし、契約で「納品物の著作権はすべて発注側に譲渡する」と定めると、開発会社は自社の汎用部品の権利まで手放すことになり、受け入れられない場合があります。

そこで実務では、「今回の案件のために新たに作った部分」と「開発会社が以前から持っていた部分や、汎用的に使える部分」を分け、前者は発注側に譲渡し、後者は開発会社に権利を残したうえで、発注側に利用を許諾する、という定め方がよく使われます。この場合、発注側が確認すべきなのは、許諾の範囲が十分かどうかです。特に、次の点を確認しましょう。

• 許諾の期間に期限がないか、あるいは十分な長さがあるか
• 発注側が改変して使えるか
• 他の開発会社に保守や改修を依頼する場合にも使えるか
• 事業の譲渡や会社の合併があった場合にも使い続けられるか
• 許諾の対価が開発費に含まれているか、別途必要か

オープンソースソフトウェア

現代のシステム開発では、多くのOSSが使われています。OSSの著作権はそれぞれの作者にあり、ライセンスと呼ばれる条件のもとで誰でも使えるようになっています。発注側がOSSの著作権を譲り受けることはできませんが、ライセンスの条件を守れば利用できます。

注意すべきなのは、ライセンスの種類によって、使う側に求められる義務が異なる点です。著作権表示を残せばよいものもあれば、改変した部分のソースコードの公開を求めるものもあります。自社のサービスの中核にそうしたライセンスのOSSが組み込まれていると、事業上の制約になる可能性があります。開発会社に、使用しているOSSとライセンスの一覧を納品物として提出してもらうと安心です。

納品物として受け取るべきもの

権利の定めとあわせて、実際に受け取るべき納品物を契約で決めておきます。ソースコードだけを受け取っても、それを動かす方法や設計の意図が分からなければ、他の会社や自社で保守することは困難です。

特に重要なのが、変更履歴を含めたソースコードの受け取り方です。Gitなどのバージョン管理の仕組みを使っている場合、管理場所（リポジトリ）を発注側の名義で作り、開発会社をそこに招待する形にしておくと、納品の手続きをしなくても常に最新のコードが発注側の手元にある状態になります。用語の意味はソースコードの用語解説でも説明しています。

将来の保守移管で困らないための条件

システムは作って終わりではなく、何年にもわたって改修と保守が続きます。その間に、開発会社との関係が変わることも珍しくありません。担当者が退職する、開発会社の方針が変わる、費用や対応の質に不満が出る、といった理由で、保守の担い手を変えたくなる場面は十分に考えられます。

保守の移管で困らないためには、次の条件を開発契約の段階でそろえておくことが大切です。

1. 権利の条件：発注側が改変でき、他の会社に保守を依頼できる権利（譲渡、または十分な範囲の利用許諾）を確保する。
2. 現物の条件：ソースコード、設計書、環境構築手順、運用手順書を、最新の状態で受け取れるようにする。
3. アカウントの条件：クラウドや外部サービス、ドメインの契約者と管理者権限を、発注側の名義にしておく。
4. 引き継ぎ協力の条件：契約終了時に、一定期間の引き継ぎ協力を行う旨を定めておく。
5. 継続性の条件：開発会社の汎用部品を使っている場合、その利用許諾が契約終了後も続くことを確認する。

開発会社を途中で変える場合の具体的な手順は、開発会社を途中で変更するにはで詳しく説明しています。また、外注から自社開発に切り替える場合の引き継ぎ方は、MVPを外注から内製へ引き継ぐで扱っています。

架空の例：新規事業のサービスで権利を整理する

ここでは架空の例で、権利の整理のしかたを見てみます。

ある会社が新規事業として、法人向けの業務管理サービスを開発会社に依頼することになりました。将来は自社にエンジニアを採用して内製化することも視野に入れています。担当者は、開発会社から提示された契約書のひな形を確認し、納品物の著作権が開発会社に残る内容になっていることに気づきました。

担当者は開発会社と相談し、今回の案件のために新たに作る部分の著作権は検収時に発注側へ譲渡し、翻案権などを含めること、著作者人格権は行使しないこと、開発会社が以前から持つ認証まわりの部品は開発会社に権利を残したうえで、期間の制限なく、改変と第三者への保守委託を含めて利用を許諾することで合意しました。あわせて、ソースコードの管理場所とクラウドのアカウントを最初から自社名義で作り、開発会社を招待する形にしました。

この結果、開発会社は既存部品を活用して開発費を抑えられ、発注側は将来の内製化に必要な権利と現物を確保できました。お互いの事情を踏まえて範囲を分けたことが、合意を早めたポイントです。

契約書の確認チェックリスト

ソースコードの権利に関して、契約書で確認すべき項目をまとめます。

• 納品物の著作権が、譲渡なのか利用許諾なのか明記されているか
• 譲渡の場合、翻案権と二次的著作物の利用に関する権利が含まれているか
• 著作者人格権を行使しない旨の条項があるか
• 開発会社の既存部品・汎用部品の範囲と、その扱いが定められているか
• 既存部品の利用許諾が、期間・改変・第三者への保守委託の点で十分か
• 著作権が移るタイミング（納品時、検収時、代金支払い時など）が明記されているか
• 納品物の一覧に、ソースコード以外の設計書や手順書が含まれているか
• 使用しているOSSとライセンスの一覧の提出が求められているか
• クラウドや外部サービスのアカウントの名義と管理者権限の扱いが決まっているか
• 契約終了時の引き継ぎ協力が定められているか
• 第三者の権利を侵害していないことの保証と、侵害があった場合の対応が定められているか
• 再委託先が作った部分の権利も、同じ条件で発注側に移るようになっているか

最後の項目は見落とされがちです。開発会社が作業の一部を別の会社やフリーランスに再委託している場合、再委託先との間で権利が整理されていないと、その部分の権利が宙に浮く可能性があります。契約形態全般の確認点は、請負契約と準委任契約の選び方もあわせてご覧ください。

よくある失敗と避け方

契約書の権利条項を確認せずに署名する

開発会社のひな形の契約書をそのまま使い、権利の条項を読まずに署名するケースです。ひな形によっては、著作権が開発会社に残る、利用許諾の範囲が狭い、といった内容になっています。後から気づいても、契約の変更には相手の合意が必要です。署名前に必ず権利の条項を確認しましょう。

ソースコードの受け取りを後回しにする

権利は譲渡を受けていても、ソースコードを受け取らないまま長く運用するケースです。開発会社が保守を続けている間は問題が表面化しませんが、関係が変わったときに、最新のコードが手元にないことに気づきます。バージョン管理の場所を発注側の名義にしておくか、定期的に最新のソースコードを受け取る運用にします。

クラウドのアカウントが開発会社の名義になっている

サーバーやクラウド、ドメインの契約を開発会社に任せた結果、アカウントの名義が開発会社になっているケースです。保守の移管の際に、アカウントの移転手続きが複雑になったり、データの取り出しに協力が必要になったりします。本番環境のアカウントは、最初から発注側の名義で作るのが基本です。

権利をすべて譲渡するよう一方的に求める

発注側が、汎用部品を含めたすべての権利の譲渡を一方的に求めるケースです。開発会社は汎用部品を使えなくなるため、一から作り直す前提で見積もりが高くなる、あるいは受注を断られることがあります。何を自社で持つべきかを考え、汎用部品は利用許諾で十分かを検討しましょう。

よくある質問

Q. 著作権を譲り受けると、開発費は高くなりますか？

開発会社が同じコードを他の案件で使えなくなるため、見積もりに影響する場合があります。ただし、汎用部品を利用許諾に分ければ、影響を抑えられることもあります。何を譲渡の対象にするかを開発会社と話し合ってください。

Q. すでに契約が終わっていて、権利の定めがなかった場合はどうすればよいですか？

まずは契約書や発注書、見積書などの書類を確認し、権利に関する記載がないかを探します。定めがない場合は、開発会社と改めて権利の譲渡や利用許諾の契約を結ぶ交渉を検討します。具体的な対応は、弁護士に相談することをおすすめします。

Q. ノーコードツールやSaaSで作ったシステムの場合はどうなりますか？

ツールやサービスそのものの権利は提供事業者にあり、発注側は利用規約の範囲で使うことになります。作り込んだ設定やデータを他に移せるかは、サービスによって異なります。将来の移行を見込む場合は、データの出力方法や移行の手段を事前に確認しておきましょう。

Q. 生成AIで書いたコードの権利はどう考えればよいですか？

AIコーディングアシスタントなどを使って書かれたコードの権利の扱いは、法的な議論が続いている分野です。発注側としては、開発会社がどのようなツールを使っているか、生成されたコードが第三者の権利を侵害していないかをどう確認しているかを聞いておくとよいでしょう。契約では、第三者の権利を侵害していないことの保証の条項を確認します。最新の考え方は、専門家に確認してください。

Otsumuに相談できること

契約書のひな形に権利の条項がきちんと書かれていて、本記事のチェックリストで確認できるなら、ソースコードの権利の整理は自社と開発会社の話し合いで十分に進められます。最終的な契約書の文言は、弁護士に確認してもらうと安心です。

一方で、将来の内製化や保守の移管を見込んで、どこまでの権利と納品物を確保すべきか判断に迷う場合や、すでに権利や納品物が十分でないシステムを引き継ぐ必要がある場合は、技術と事業の両面から整理できる外部の力を借りると、判断が早くなります。

Otsumuは、構想から開発・運用・改善まで一気通貫で支援する中で、将来の保守や内製化を見据えたソースコードの管理、納品物の整備についても一緒に設計します。開発全般はシステム開発、既存システムの保守や引き継ぎは保守・運用、作り直しを含む検討はシステムリプレイスのページをご覧ください。法的な判断が必要な点は、専門家への確認をおすすめしています。

まずは30分の無料相談で、現在の契約や納品物の状況をお聞かせください。秘密保持や契約条件は、相談時に確認のうえ合意して進めます。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01