システム開発のソースコード｜納品後の所有権を明確にする方法 2026

システム開発を外注する際、意外と見落とされがちなのが「ソースコードは誰のものになるのか」という論点です。結論から言うと、開発費用を全額支払っていても、契約で著作権譲渡を明記していなければ、ソースコードの権利は発注者ではなく開発会社側に残ります。この誤解が原因で、後々のシステム改修やベンダー変更時に深刻なトラブルへ発展するケースは少なくありません。

システム開発の著作権と所有権をめぐる現状

システム開発の発注でトラブルが発生する背景には、「お金を払ったのだから、成果物は全部自分のものになる」という素朴な感覚と、法律上の実態とのズレがあります。

まず整理しておきたいのは、著作権と所有権はまったく別の概念だという点です。所有権はサーバーやハードディスクといった有体物（物理的なモノ）に対して発生する権利で、これは開発費用を支払った時点で発注者に移転するのが一般的です。一方、著作権はソースコードという「著作物」そのものに対する権利であり、有体物の所有権とは切り離して考える必要があります。

原則として、ソースコードを実際に作成した技術者やシステム開発会社に帰属します。発注者が開発費用を全額支払っている場合でも、法律上の「著作者」は作成した側にあります。別途譲渡の合意がない限り、発注者側は著作権を持つことはできず、システムを利用するための「著作利用権」のみを保有することになります。 出典: hnavi.co.jp

つまり、契約書に何も書かれていない状態でシステム開発を発注すると、発注者はそのシステムを「使う権利」は持っていても、ソースコードを自由に改変したり、別の開発会社に渡して保守を依頼したりする権利までは持っていない可能性があるということです。

正直なところ、これは発注者にとってかなり不利な話です。中小企業庁や公正取引委員会が下請取引の適正化に関するガイドラインを整備しているのも、こうした情報の非対称性が中小事業者の不利益につながりやすいという問題意識があるためです。システム開発の委託契約においても、発注者側が契約書の重要性を正しく理解しておくことが、将来のリスクを回避する第一歩になります。

近年はクラウドサービスやSaaS型の業務システムが普及したことで、「自社専用にゼロから開発するシステム」の位置づけも変わってきています。それでも、業務の根幹を担う基幹システムや、競合他社との差別化要因となる独自機能を持つシステムについては、今なお受託開発でオーダーメイドされるケースが多く、その分だけ著作権・所有権をめぐる契約整理の重要性は増しています。

著作権と所有権の違いを正しく理解する

「著作権」とは何を指すのか

著作権は、ソースコードというプログラムの著作物に対して、作成者（原則として実際にコードを書いたエンジニアが所属する会社）に自動的に発生する権利です。著作権法では、プログラムの著作物も「著作物」として保護対象に含まれており、複製権・翻案権・譲渡権など複数の権利の束（バンドル）として構成されています。

重要なのは、著作権は「創作した瞬間に自動的に発生する」という点です。特許のように出願・登録の手続きを踏む必要はありません。したがって、システム開発会社がコードを書き終えた時点で、その会社（あるいは実際にコーディングを担当した個人）に著作権が発生します。発注者に著作権を移転させるには、契約書で明確に「著作権を譲渡する」という条項を入れる必要があります。

「所有権」とは何を指すのか

所有権は、サーバー機器・外付けハードディスク・納品されたUSBメモリといった有体物に対する権利です。民法上の所有権は、対価を支払って物を購入すれば、特段の合意がなくても買主に移転するのが原則です。

ここで注意したいのは、「ソースコードが記録されたUSBメモリの所有権」と「ソースコードそのものの著作権」は別物だという点です。USBメモリという物体は発注者のものになっても、その中身であるプログラムの著作権までは自動的には移転しません。

システム開発に伴い所有権の対象となるものとしては、サーバ・ハードディスク等の電磁的記録媒体物、設計書・マニュアル等の書類といった有体物が想定されます。 出典: ys-law.jp

この区別を理解していないと、「納品書類一式を受け取ったから権利関係も全部クリアになっている」と思い込んでしまい、後になって「実はソースコードの改変や再利用の権利は開発会社側にあった」と気づくパターンに陥ります。

著作者人格権という第三の論点

著作権の話でもう一つ見落とされがちなのが、著作者人格権です。これは著作権（財産権）とは別に、著作者本人に一身専属で認められる権利で、譲渡することができません。具体的には、同一性保持権（無断で改変されない権利）や氏名表示権などが含まれます。

システム開発の契約実務では、たとえ著作権（財産権）を発注者に譲渡する条項を入れても、著作者人格権は自動的には移転しないため、「著作者人格権を行使しない」という不行使特約を契約書に併記するのが一般的です。この特約がないと、開発会社側の同意なしにシステムを改修した場合に、理論上は著作者人格権侵害を主張されるリスクが残ります。契約書のひな型を使う際は、この不行使特約が含まれているかを必ず確認してください。

システム開発取引で権利が誰に帰属するのか

原則は「作成者」に権利が帰属する

日本の著作権法の原則に照らせば、システム開発の受託契約において、特段の定めがない限り、著作権はソースコードを実際に作成した開発会社（または個人事業主のエンジニア）に帰属します。これは請負契約・準委任契約のどちらであっても基本的には変わりません。

発注者側からすると「委託して、対価を支払って作らせたのだから当然自分のものになる」と考えがちですが、法律上の建付けはそうなっていません。この認識のズレこそが、システム開発の権利トラブルの根本原因です。

契約書における著作権譲渡条項の重要性

このズレを解消する唯一の方法が、契約書に著作権譲渡条項を明記することです。多くの受託開発契約書には、以下のような内容が盛り込まれます。

・成果物（プログラム、設計書、仕様書等）の著作権は、検収完了かつ委託料金の支払い完了をもって、開発会社から発注者へ移転する ・著作者人格権について、開発会社は発注者に対してこれを行使しない ・開発に用いた汎用的なフレームワークやライブラリ、独自の技術ノウハウについては、開発会社に権利を留保する

最後の項目は特に注意が必要です。開発会社側は、複数の案件で使い回せる共通モジュールや独自のフレームワークについては、著作権を発注者に渡さず自社に留保したいと考えるのが通常です。発注者としては、「自社の業務に固有な部分（画面デザイン、業務ロジック）」と「汎用的な技術基盤の部分」を切り分けて交渉することが現実的な落としどころになります。

経済産業省のモデル契約書が示す考え方

経済産業省は情報システム・モデル取引・契約書という指針を公表しており、システム開発委託契約の標準的な条項例を示しています。このモデル契約書では、著作権の帰属について「原則として発注者に譲渡する」パターンと「開発会社に留保する」パターンの両方が併記されており、案件の性質に応じて選択できる構成になっています。

契約交渉の場で、どちらのパターンを採用するかを曖昧にしたまま進めてしまうと、後になって「言った言わない」の水掛け論に発展しやすくなります。契約書のドラフト段階で、著作権の帰属について発注者側の希望を明確に伝え、条文として残しておくことが重要です。

ソースコード提供義務を契約書に明記する方法

「著作権を持つ」ことと「ソースコードを受け取る」ことは別問題

ここで発注者が誤解しやすいポイントがもう一つあります。それは、契約書で著作権を発注者に譲渡する条項を入れたとしても、開発会社が実際にソースコード一式を納品してくれるとは限らないという点です。

著作権の帰属と、ソースコードという成果物の実際の引き渡しは、契約上は別の条項として扱われます。極端な話、著作権譲渡条項があっても、開発会社が「納品物は実行ファイルのみ」という契約になっていれば、発注者はソースコードそのものを受け取れないままシステムを運用することになりかねません。

ソースコード納品義務を明記すべき理由

システムの保守・改修を将来的に別の会社へ依頼する可能性がある場合、あるいは開発会社が廃業・倒産するリスクを考慮する場合、契約書には「ソースコード一式を成果物として納品すること」を明記しておくべきです。

具体的には、以下のような条項を盛り込みます。

・納品物にソースコード一式（コメント付き）、データベース定義書、環境構築手順書を含める ・ソースコードは指定の形式（バージョン管理システムのリポジトリ、または圧縮ファイル）で引き渡す ・改修や機能追加を行った場合、その都度最新版のソースコードを提供する

これらを検収条件に含めておくことで、「検収完了＝ソースコードの提供完了」という状態を担保できます。

エスクロー（第三者預託）という選択肢

開発会社が独自ノウハウを理由にソースコードの直接提供を渋るケースもあります。その場合の折衷案として、ソースコードエスクローという仕組みが使われることがあります。これは、ソースコードを信頼できる第三者機関に預託しておき、開発会社が倒産・廃業した場合や、契約で定めた条件（サポート終了等）に該当した場合にのみ、発注者がソースコードを取得できるという制度です。

エスクローは開発会社にとっても「日常的にはノウハウを開示せずに済む」というメリットがあるため、双方が納得しやすい落としどころになりやすい方法です。特に、業務の根幹を担う基幹システムを外部委託する場合は、エスクロー契約の導入を検討する価値があります。

システム開発の著作権をめぐるトラブル事例

開発会社の廃業でソースコードが引き渡されなかった事例

実際に起きたトラブルとして、開発会社の廃業に伴いソースコードの引き渡しを拒否された事例が報告されています。

この裁判は発注企業Xが、開発業者Yを相手に起こした裁判です。企業XはＹにシステム開発を委託し、そのシステムは問題なく納品されました。Ｙはその後、そのシステムアップデートを担当しましたが、Ｙが廃業することになり企業Ｘに通知します。企業Ｘはソースコードの引き渡しを求めましたが、Ｙは応じず、企業Ｘが損害賠償請求をした、という事例になります。 出典: freshet.co.jp

この事例が示すのは、「システムが正常に稼働している間は問題が表面化しない」という点です。開発会社が事業を継続している限り、発注者はソースコードを直接持っていなくても、保守や改修を依頼し続けることができます。しかし、開発会社の廃業や倒産、あるいは担当エンジニアの退職といった事態が起きた瞬間に、ソースコードを持っていないことのリスクが一気に顕在化します。

別のベンダーに改修を依頼できず、システムを作り直すことになった事例

ソースコードの提供義務が契約書に明記されていなかったために、既存システムの改修を別のベンダーに依頼できず、結果的にシステムを一から作り直すことになったという相談も、システム開発の現場ではよく耳にする話です。ゼロから作り直す場合、当初の開発費用に加えて、要件定義からやり直すための追加コストが発生します。金額にして数百万円規模の損失につながることも珍しくありません。

契約書に譲渡条項がなく、改修のたびに元の開発会社へ依頼せざるを得なかった事例

著作権が開発会社側に残ったままだと、著作権法上、発注者が無断でソースコードを改変することは著作権侵害（翻案権侵害）に該当するリスクがあります。このため、著作権譲渡条項のない契約でシステムを開発した発注者は、たとえ元の開発会社との関係が悪化していても、法的には改修のたびにその会社へ依頼せざるを得ない状況に置かれることがあります。これは価格交渉力の低下にも直結し、保守費用が年々上昇していく要因にもなります。

著作権トラブルを防ぐために発注者ができること

契約締結前に権利関係を必ず確認する

最も効果的な対策は、契約締結前の段階で著作権の帰属とソースコードの提供義務を明確にすることです。見積もり比較の段階で「著作権はどちらに帰属するか」「ソースコード一式は納品物に含まれるか」を各社に確認し、回答内容を比較検討の材料に加えることをおすすめします。

見積もり金額だけを見て安さで選んでしまうと、後になって著作権やソースコード提供の条件が発注者に不利な内容だったと気づくことがあります。金額と権利関係は必ずセットで比較するべきポイントです。

RFP（提案依頼書）の段階で権利関係の要望を明記する

複数の開発会社に見積もりを依頼する際は、RFP（提案依頼書）の段階で「成果物の著作権は発注者に譲渡すること」「ソースコード一式を納品物に含めること」という要望を明記しておくと、後の交渉がスムーズになります。この段階で条件をすり合わせておけば、契約書のドラフトを作成する際に大きな認識の齟齬が生じにくくなります。

弁護士など専門家によるリーガルチェックを入れる

契約書のひな型をそのまま使うのではなく、実際の取引内容に即して条文を調整し、可能であればIT関連の契約実務に詳しい弁護士によるリーガルチェックを受けることが望ましいです。特に、著作権譲渡の範囲（汎用モジュールを含むか除くか）、著作者人格権の不行使特約、ソースコード提供義務、瑕疵担保責任（契約不適合責任）の期間といった項目は、専門家の視点でチェックしておくべき重要条件です。

検収条件にソースコード提供を含める

検収完了の条件として「ソースコード一式の提供」を明記しておけば、開発会社側もソースコードを提供しない限り検収が完了せず、支払いも発生しないという構造を作ることができます。これにより、ソースコード提供漏れのリスクを実務的に防ぐことができます。

システム開発を外注する際の費用相場と依頼の流れ

費用相場の目安

システム開発の費用は、開発規模や機能要件によって大きく変動します。小規模な業務システムであれば数十万円から、中〜大規模な基幹システムであれば数百万円から数千万円に及ぶこともあります。目安として、簡易な業務システムやWebアプリケーションであれば50万円から300万円程度、複数部門にまたがる基幹システムであれば500万円以上になるケースもあります。

見積もりを比較する際は、単純な総額だけでなく、著作権譲渡やソースコード提供が含まれているかどうかで、実質的なコストパフォーマンスが変わってくる点に注意してください。ソースコードが提供されない契約は、将来の保守を元のベンダーに固定されることになり、長期的にはトータルコストが割高になる可能性があります。

仲介会社経由と直接依頼のコスト差

システム開発を発注する際、仲介会社やエージェントを経由する方法と、フリーランスのエンジニアや小規模な開発会社に直接依頼する方法があります。仲介会社を通す場合、仲介手数料が上乗せされるため、同じ開発内容でも総額が高くなる傾向があります。

一方、フリーランスのエンジニアへ直接依頼すれば、中間マージンが発生しない分、同じ予算でより多くの開発工数を確保できる可能性があります。ただし、直接依頼の場合は、契約書の作成や著作権譲渡条項の整備を発注者側でしっかり主導する必要がある点には注意が必要です。仲介会社が提供する契約書のひな型やトラブル対応のサポートがない分、発注者自身が権利関係の知識を持っておくことが重要になります。

依頼の流れ

一般的なシステム開発の依頼の流れは、要件整理、見積もり比較、契約締結、要件定義、設計、開発、テスト、検収、納品という順序で進みます。著作権とソースコード提供の条件は、契約締結の段階で必ず確定させておくべき項目です。要件定義以降の工程が進んでから条件交渉をやり直すのは、双方にとって手戻りのコストが大きくなります。

私自身、発注者としてシステム開発を依頼した際に、複数社から見積もりを取った段階で著作権の扱いについて質問したところ、ある会社は「著作権は当社に残ります、実行ファイルのみの納品です」という回答で、別の会社は「著作権は納品完了後に全面譲渡します」という回答でした。金額だけを見れば前者の方が安かったのですが、将来の改修のことを考えて後者を選びました。この経験から、見積もり比較の際は金額と権利関係を必ずセットで確認する習慣がついています。

独自データから見るシステム開発発注の実態

システム開発を外注する際の職種選びについては、Web・業務システム開発のお仕事のページで、業務システム開発を専門とするフリーランスエンジニアの案件傾向を紹介しています。基幹システムや業務システムの受託開発を得意とする人材は、著作権や契約実務についても一定の理解を持っているケースが多く、契約交渉がスムーズに進みやすい傾向があります。

また、AIを活用したシステム開発や、セキュリティ要件が厳しいシステムの開発を検討している場合は、AI・マーケティング・セキュリティのお仕事のページで、専門性の高いエンジニアの案件情報を確認できます。セキュリティ要件が絡む開発案件では、著作権に加えて秘密保持契約（NDA）の内容も併せて確認しておく必要があります。

発注先を選ぶ際、実際にどの程度の報酬水準で契約されているかを把握しておくことも交渉材料になります。ソフトウェア作成者の年収・単価相場のページでは、システム開発を担うエンジニアの単価相場データを公開しており、見積もり額が市場相場から大きく外れていないかを確認する目安として活用できます。

20年この市場を見てきた立場から言えば、システム開発の発注で長期的にうまくいっている企業ほど、契約書の細部（著作権、ソースコード提供義務、瑕疵担保責任の期間）を発注前にしっかり詰めています。逆に、価格交渉だけに時間をかけて契約条件の確認を後回しにした企業ほど、数年後に「保守を他社に頼めない」「システムを作り直すしかない」という壁にぶつかっている印象があります。

長く続く取引関係を築いている発注者ほど、単発の値切り交渉ではなく、契約段階での権利関係の整理に時間をかけている傾向が見られます。中間マージンの発生しない直接取引は、同じ予算でより多くの開発工数を確保できるだけでなく、発注者と開発者が直接コミュニケーションを取れる分、著作権やソースコード提供に関する条件のすり合わせもしやすくなります。手数料0%で直接契約できる環境は、金額面のメリットだけでなく、契約条件を発注者主導で決めやすいという質的なメリットも持っています。

システム開発の外注を検討している方は、システム開発を外注する方法｜失敗しない発注の進め方【2026年版】の記事で、発注先選びから契約締結までの具体的な進め方を詳しく解説しています。あわせて、開発規模が大きくなる場合は大規模システム開発で採用すべきマイクロサービスの利点と設計の難易度の記事も参考になります。システムの設計方針によって、将来の改修のしやすさや、契約すべき権利範囲も変わってくるためです。

案件獲得の視点からシステム開発の市場動向を知りたいエンジニア側の方には、Web・業務システム開発の案件獲得術｜単価を上げる3つのポイントの記事もあわせて参考にしてください。発注者・受注者双方が契約実務への理解を深めることが、システム開発業界全体のトラブル減少につながります。

よくある質問

Q. システム開発を発注した場合、ソースコードの著作権は自動的に発注者のものになりますか？

なりません。著作権は原則として実際にコードを作成した開発会社側に帰属します。発注者に著作権を移転させるには、契約書に著作権譲渡条項を明記する必要があります。

Q. 著作権を発注者に譲渡する契約にすれば、ソースコード自体も必ず受け取れますか？

必ずしも受け取れるとは限りません。著作権の帰属とソースコードの引き渡しは別の条項です。ソースコード一式を納品物に含める旨を契約書に明記しておく必要があります。

Q. 開発会社が倒産した場合、ソースコードを取得する方法はありますか？

契約書にソースコード提供義務を明記していない場合、取得が難しいケースがあります。あらかじめソースコードエスクロー（第三者預託）を契約に組み込んでおくと、倒産や廃業時にも取得できる可能性が高まります。

Q. 仲介会社を通さずフリーランスに直接依頼する場合、著作権の取り決めは自分で行う必要がありますか？

はい。仲介会社が提供する契約書のひな型やサポートがない分、著作権譲渡条項やソースコード提供義務を発注者側で契約書に盛り込む必要があります。不安な場合は専門家によるリーガルチェックの利用をおすすめします。

無料で案件を掲載する

入力は3分ほど。掲載料も取引手数料も0円です。@SOHOに登録しているフリーランス・副業ワーカーから、早ければ当日中に最初の応募が届きます。