システム開発の著作権は誰のもの？発注者が知っておきたい権利帰属と契約のポイント
外注でシステムを開発してもらったのに、いざベンダーを変えようとしたら「ソースコードは渡せません」と言われた——こうしたトラブルは、中小企業の経営者や担当者が知らないうちに陥ってしまうケースの一つです。
「お金を払ったのだから、完成したシステムは自社のものではないか」と思うのは自然なことです。しかし法律の観点から見ると、それは必ずしも正しくありません。システム開発には著作権という概念が深く関わっており、契約書に適切な条項がなければ、発注者は思いがけない制約を受ける可能性があります。
このトラブルを生む原因は、著作権法の原則にあります。日本の著作権法では、プログラムを書いた人（または企業）がその著作権を持つと定められており、発注者が開発費用を全額負担したとしても、自動的に権利が移転されるわけではないのです。
では、発注者として何を知り、何を交渉すれば良いのでしょうか。本記事では、システム開発における著作権の基本から、具体的な契約条項の確認ポイントまでを、受託開発会社の視点も交えながら実務的に解説します。なお、個別の法的判断については必ず専門家（弁護士）にご相談ください。
目次
「ベンダーを変えたらソースコードを渡してもらえなかった」は実際に起きうる
システム開発の著作権をめぐるトラブルは、決して珍しい話ではありません。契約書に著作権の扱いが明記されていなかった場合、発注者が想定外の制約に直面するケースが実際に報告されています。
こんなトラブルが起きる
代表的なトラブルを3つ挙げます。
1. ベンダー変更時のソースコード未開示 既存のベンダーとの関係が終わり、別の開発会社に保守・改修を依頼しようとした際、現行のソースコードを引き継げないという状況です。ソースコードがなければ、新しいベンダーはゼロから作り直すか、解析しながら作業するしかなく、コストが大幅に膨らみます。
2. 改修費の高騰と「同意なしに変更できない」制約 他社に改修を依頼しようとすると、元の開発会社から「著作権侵害になる」と警告されるケースがあります。開発会社の同意なしにプログラムを改変することは、著作権法上の翻案権の侵害にあたる可能性があるためです。
3. 稼働中システムへの差止請求リスク 極端なケースでは、著作権者（開発会社）が「著作権侵害」を理由にシステムの使用差止を請求できる法的根拠を持ちます。トラブルが訴訟に発展した場合、システムの使用継続が困難になる可能性もあります。
なぜこれが起きるのか？著作権法の仕組みが原因
これらのトラブルが起きる根本的な原因は、「著作権はお金を払った人ではなく、作った人に発生する」という著作権法の原則です。この原則を理解することが、トラブル回避の第一歩です。
ソフトウェアにも著作権がある：「プログラムの著作物」とは
著作権というと、小説や音楽、絵画などをイメージする方が多いかもしれません。しかし、コンピュータプログラムも著作権法の保護対象です。
プログラムは著作物として保護される
日本の著作権法第10条1項9号では、保護対象となる著作物の一つとして「プログラムの著作物」が明記されています。また、同法第2条1項10号の2では、プログラムを「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」と定義しています。
つまり、システム開発で作成されるソースコードは、法律上「著作物」であり、著作権法による保護を受けます。なお、プログラム言語そのもの（PythonやJavaなど）や、アルゴリズム・解法自体は著作権の保護対象外です（同法第10条3項）が、それらを使って書かれたコード（表現）は保護されます。
著作権は「制作した人」に自動的に発生する
著作権の大きな特徴は、特許権と異なり、登録や申請なしに、著作物が完成した時点で自動的に発生することです（無方式主義）。システム開発で言えば、コードが書かれた瞬間に、そのコードを書いた開発者（または開発会社）に著作権が生まれます。
外注開発では著作権は開発会社に帰属する：その理由と現実
この原則を踏まえると、外注開発のシステムの著作権は、原則として「コードを書いた開発会社」に帰属します。
著作権が開発会社に帰属する3つの理由
開発会社が著作権を保持したがる理由には、主に次の3つがあります。
1. ライブラリ・フレームワークの再利用 現代のシステム開発では、すべてのコードをゼロから書くのは非効率です。開発会社は過去に自社で開発した汎用的なコードやライブラリ（部品集）を再利用しながら開発を進めます。これらの部品の著作権が開発会社にある以上、完成したシステムにもその権利が及びます。
2. ノウハウと技術的蓄積の保護 開発会社が長年磨いてきた設計パターンや最適化手法は、いわばビジネスの根幹です。著作権を発注者に全部譲渡してしまうと、自社のノウハウが競合他社に流出するリスクが生じます。
3. 保守・改修の継続受注 著作権を保持したままにすることで、発注者が他社に乗り換えにくい状況を作り、継続的な保守・改修の仕事を確保しやすくなるという側面も否定できません。
受託開発会社の立場から正直に言えば、これら3つの理由が組み合わさって「著作権は開発会社が持つ」という慣行が生まれています。
「お金を払ったのに自分のものじゃないの？」という疑問への答え
「開発費用を全額負担したのだから、成果物の著作権も自分のものでは？」と感じるのは当然です。しかし日本の著作権法上、この考え方は通りません。著作権は誰が費用を出したかではなく、誰が創作行為をしたかによって決まります。
これは建物の建築に似ています。建設会社に家を建ててもらった場合、建物の所有権は依頼主に移りますが、設計図（著作物）の著作権は設計士が持ちます。システム開発も同様で、ソースコード（著作物）の著作権は、コードを書いた開発会社が持つのが原則です。
職務著作との違い（社内で内製した場合との比較）
なお、自社の従業員がシステムを開発した場合（内製）は、著作権法第15条の「職務著作」の規定により、原則として会社が著作権を持ちます。外注した場合とは異なる取り扱いになりますので、内製・外注の選択においても著作権の観点は重要です。
著作権「譲渡」と「利用許諾」は何が違う？実務上の影響
著作権を発注者が確保する方法には、大きく「譲渡」と「利用許諾」の2種類があります。この違いを理解することが、契約交渉の土台となります。
著作権譲渡とは何か（完全に権利が移る）
著作権譲渡は、著作権者（開発会社）から発注者へ著作権そのものが移転することです。著作権法第61条では「著作権は、その全部又は一部を譲渡することができる」と規定されています。
譲渡を受けた発注者は、そのシステムを自由に使用・改変・第三者への提供ができるようになります。ただし、翻案権（改変する権利）や二次的著作物に関する権利（第27条・第28条）は、契約書に「著作権法第27条及び第28条の権利を含む」と明記しないと譲渡されないことに注意が必要です。
利用許諾とは何か（使う権利だけをもらう）
利用許諾（ライセンス）は、著作権そのものは開発会社が保持しつつ、発注者がそのシステムを使う権利だけを得る方法です。
利用許諾の範囲は契約で決まります。「改修する権利（翻案権）はあるか」「第三者（他のベンダー）に改修を依頼できるか」「システムをコピーして別環境に展開できるか」——これらを契約書に明記しないと、後で争いの元になります。
「譲渡は難しい」と言われたときの現実的な代替策
著作権の完全譲渡を求めると、開発会社が難色を示すケースは多いです。前述の通り、汎用ライブラリが組み込まれている部分は技術的に切り離せないことも多く、「開発会社が作ったフレームワーク部分の著作権を譲渡するわけにはいかない」という主張は合理性があります。
交渉が難航したとき、発注者として最低限確保すべきは「著作権譲渡」ではなく、以下の3点です。
- ソースコードの開示・納品: ソースコードを納品物として受け取ること
- 改修権（翻案権の許諾）: 発注者自身または第三者が改修を行える権利
- 再許諾権: 他のベンダーに保守・改修を委託できる権利
著作権の完全譲渡が難しい場合でも、これら3点を利用許諾の範囲として契約に明記することで、実務上の大半のトラブルは防げます。
発注者が権利を確保するための契約条項
実際に契約書を確認・交渉する際に注意すべきポイントを解説します。
著作権譲渡条項：移転できる範囲と注意点
著作権を発注者に譲渡する場合、契約書には次の文言が必要です。
- 「本件成果物に関する著作権（著作権法第27条及び第28条の権利を含む）を発注者に譲渡する」
「第27条及び第28条の権利を含む」という記載がないと、改変する権利（翻案権）が譲渡されません。この記載がない契約書で著作権譲渡が約束されていても、実はシステムを自由に改修できない可能性があります。
また、開発会社が第三者のライブラリやオープンソースソフトウェアを利用している部分は、著作権の所在が別にあるため、「開発会社が権利を持つ部分のみ」が譲渡の対象になります。システムにどのようなライブラリが使われているかの開示を求めることも重要です。
ソースコード開示条項：ソースコードは必ず納品物に含めること
ソースコードが納品物に含まれていない場合、将来的にシステムのメンテナンスや改修が困難になります。契約書には「ソースコード（コンパイル前のソースファイル一式）を納品物として引き渡すこと」を明記してください。
また、ソースコードの提供と合わせて、以下の書類・情報も受け取れるようにしておくと安心です。
- 設計書・仕様書
- 使用しているライブラリ・フレームワークの一覧（バージョン含む）
- 開発環境・デプロイ手順の説明書
ソースコードの引き渡しに関しては、法律（契約書）上の義務として明記しなければ、開発会社がソースコードを引き渡す義務を負わないとする解釈もあります（IT法務.COM「ソフトウェア開発委託契約におけるベンダのソースコード提供義務」参照）。
改修権と再利用権：ベンダー変更時に最低限確保すべき条件
著作権の完全譲渡が難しい場合でも、最低限以下の権利を利用許諾の範囲として契約書に記載してください。
- 改修権（翻案権の許諾）: 発注者自身がシステムを改変できる権利
- 第三者への再許諾: 他のベンダーに改修・保守を依頼できる権利（再許諾権）
- 複製権: システムをバックアップ・別環境へコピーできる権利
これらが明記されていない場合、元の開発会社以外への保守委託が「著作権侵害」とみなされるリスクがあります。
特許・営業秘密についても一言確認しておく
著作権以外にも、システムに関わる知的財産権として特許権・営業秘密が問題になることがあります。
特許権: 特定のビジネスロジックやアルゴリズムが特許を受けている場合、開発会社が特許権を持つことがあります。特許権は著作権と異なり、使用・製造の独占権を付与するため、契約書に「本件成果物に関連して出願した特許権の取扱い」を明記しておくことが望ましいです。
営業秘密: 自社が開発を依頼したシステムに含まれるビジネスロジックや顧客データの扱いについても、秘密保持条項で保護しておきましょう。
これらの権利については、個別の状況によって判断が異なるため、契約前に弁護士へ相談することを強くお勧めします。
まとめ：契約前に確認すべき知的財産権チェックリスト
システム開発の著作権に関して、発注者が押さえておくべきポイントをまとめます。
契約前の確認チェックリスト
- ソースコード（コンパイル前のソースファイル一式）が納品物に含まれるか
- 著作権が発注者に譲渡される場合、「第27条・第28条の権利を含む」記載があるか
- 利用許諾の場合、改修権（翻案権の許諾）が明記されているか
- 第三者（他のベンダー）への再許諾権が認められているか
- 使用しているライブラリ・フレームワークの一覧開示を受けられるか
最低限確保すべき3点
著作権の完全譲渡が難しいと言われた場合でも、以下の3点は必ず確保してください。
- ソースコードの開示・納品
- 改修権（翻案権の許諾）
- 第三者への再許諾権（他社への保守委託を可能にする権利）
システム開発における著作権の問題は、契約時にしか手を打てないケースがほとんどです。開発が完了した後では、権利関係の変更交渉が困難になります。本記事の内容を参考に、契約書のチェックを弁護士や専門家に依頼することを検討してください。
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
秋霜堂株式会社について
秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。
システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
