「現ベンダーから保守料金の値上げを打診された」「別の開発会社から、現行のソースコードがあれば改修見積を出せると言われた」——こうした場面で、自社にソースコードや改修権がそろっているのか、契約書を見ても判断できずに動けなくなる発注者は少なくありません。
ベンダー乗り換えや内製化を検討する瞬間にはじめて「成果物の権利が思ったほど自社にない」と気づき、現ベンダー以外の選択肢が取れない状態（ベンダーロックイン）に直面するケースは、中小企業のシステム発注で繰り返し起きています。
本記事では、納品時に確認すべき7項目と、別会社へ改修依頼するときの権利整理手順を実務フローとしてまとめました。著作権の概念や帰属原則は姉妹記事システム開発の著作権は誰のもの？で詳しく解説しています。本記事は「概念」ではなく「実務手続き」に焦点を当てます。なお、個別の法的判断は必ず弁護士にご相談ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ソースコードを渡してもらえない——ベンダー乗り換えで起きる3つの実害
発注後に直面する3つの実害シナリオ
- ソースコード未開示：保守値上げを断って契約終了を打診したところ、現ベンダーから「ソースコードは当社の著作物なので渡せません」と返答され、別会社での改修見積が取れなくなった。
- 改変不可（改修できない）：契約上、利用許諾はあるが「改変は不可」となっており、別会社が現行システムに手を入れるとライセンス違反になる。
- データ返還拒否：システム停止に伴って蓄積された業務データの返却・移行を依頼したが、ベンダー側から有償対応・短納期不可と回答され、移行スケジュールが大幅に遅れた。
いずれも「契約書をよく読めば書いてあった」ケースが多く、納品時のチェックの仕組みがなかったことが共通の原因です。
「成果物を受け取った＝自由に使える」ではない
日本の著作権法では、ソフトウェアの著作権は原則として制作した側（受託開発会社）に発生します。発注者が著作権または広範な利用権を取得するには、契約で明示的に取り決めることが必要です（詳しくはシステム開発の著作権は誰のもの？を参照）。このギャップを納品時のチェックで埋めておけるかどうかが、後の乗り換え自由度を左右します。
システム開発の成果物に含まれる「権利」の全体像
著作権と「ソースコードを渡してもらう権利」は別概念
著作権の帰属は「誰が独占的にコピー・改変・配布できるか」の問題で、ソースコードの引渡しは契約上の「納品物の範囲」として別途取り決めるべき事項です。著作権を譲り受けていても、契約書に納品物の明記がなければ引渡しを当然には請求できない可能性があります。逆に、譲渡を受けていなくても改変・再委託できる旨が契約に書かれていれば改修は現実に可能です。実務では「著作権の帰属」「ソースコードが納品物に含まれるか」「改変・再委託できるか」を別々に確認します。
著作権以外に確認すべき権利
成果物には、著作権以外にも次のような権利・義務が関係します。
- 特許権：業務プロセスの新規性が高い場合、ビジネスモデル特許等の論点が残る可能性
- 商標権：システム名・サービス名・ロゴが既存商標と衝突しないか
- OSSライセンス由来の義務：GPLなどコピーレフト型ライセンスの遵守義務が発注者にも及び得る
- データの権利：蓄積された業務データの所有・利用権、データベース著作権
- 仕様書・設計書などのドキュメントの権利：成果物の一部として明記されているか
納品時に必ず確認すべき7つのチェックリスト
発注者が確認すべき項目を7つに整理しました。各項目で「足りなかった場合に何を交渉すべきか」もあわせて示します。納品物の構成や注文書・契約書の基本は発注書・注文書とは？もご参照ください。
1. ソースコード一式（コンパイル前ファイル）が含まれるか
実行可能ファイル（コンパイル後のバイナリ）だけでは、別会社での改修・解析は事実上できません。
- コンパイル前の全ソースコード（フロントエンド・バックエンド・インフラ定義含む）
- バージョン管理リポジトリの完全なコピー（履歴・ブランチ含む）
足りない場合は、Gitリポジトリのクローンを含む完全な引渡しを契約・覚書で追記する交渉が必要です。バージョン管理の重要性についてはバージョン管理・Gitとは？が参考になります。
2. 著作権譲渡の場合、27条・28条の権利が含まれているか
契約で著作権譲渡を受ける場合、著作権法61条2項により、27条（翻案権等）・28条（二次的著作物の利用権）は特掲されていないときは譲渡人に留保されたものと「推定する」とされています。これらの権利は、システムの改修・派生システムの開発で重要な意味を持ちます。
契約書に「著作権（著作権法27条および28条に定める権利を含む）を譲渡する」と明記されているかを点検してください。「著作権を譲渡する」だけの記載では、27条・28条はベンダーに残ったままという解釈になり得ます。詳細はシステム開発の著作権は誰のもの？で解説しています。
3. 利用許諾の場合、改変権・第三者再委託権が認められているか
著作権がベンダーに残る利用許諾型の契約では、許諾範囲が後の改修自由度を決めます。
- 改変の可否：発注者または発注者が指定する第三者がソースコードを改変できる
- 第三者再委託の可否：別の開発会社に改修を委託する権利が含まれている
- 再委託先の制限：「事前承諾が必要」「同業他社不可」などの制約があるか
これらが明示されていない・禁止されている場合、別会社への改修依頼が契約違反となるリスクがあります。納品前は契約条項の修正交渉、納品後は覚書での追加合意を検討します。
4. 仕様書・設計書・運用ドキュメントが揃っているか
ソースコードだけでは別会社が短期間でシステムを理解することは難しく、解析工数が膨らんで乗り換えコストが跳ね上がります。
- 要件定義書・基本設計書・詳細設計書
- データベース定義書（ER図・テーブル定義）
- API仕様書・画面遷移図
- 運用手順書・障害対応マニュアル
古い・存在しない場合は、現ベンダーに「現状版の整備」を依頼します。プロジェクト終了直前ほど協力を得るのは難しくなります。
5. ビルド手順・実行環境情報が整理されているか
ソースコードと設計書がそろっていても、「動くシステムに組み立て直す」情報がなければ別会社は手をつけられません。
- ビルド手順（必要なツール・コマンド・順序）
- 実行環境（OS・ミドルウェア・バージョン）
- 依存ライブラリの一覧とバージョン
- 環境変数・設定ファイルの一覧と設定値の意味
- インフラ構成図（クラウド構成・ネットワーク・認証情報の所在）
これらは引継書としてまとめてもらい、新ベンダーが現行システムを再現できる粒度になっているかを基準に確認します。
6. 使用OSS一覧とライセンスが明示されているか
OSSライセンス由来の義務は発注者にも及び得るため、どのOSSがどのライセンスで組み込まれているかを把握しておく必要があります。
- 使用OSSの一覧表（ライブラリ名・バージョン・ライセンス種別・公式リポジトリURL）
- ライセンス全文の同梱
- 改変したOSSがある場合、改変箇所の明示
不完全な場合、SBOM（Software Bill of Materials）の整備を依頼します。詳細は次のセクションで扱います。
7. 著作者人格権の不行使特約が明記されているか
著作者人格権（氏名表示権・同一性保持権・公表権）は法律上譲渡できない権利ですが、契約で「行使しない」と取り決めることが一般的な実務です。この特約がないと、改変するたびに「同一性保持権の侵害ではないか」というリスクが残ります。譲渡条項の近くに「著作者人格権を行使しない」旨が明記されているかを確認してください。
OSSライセンスが絡む場合の実務的な確認ポイント
OSSの取り扱いは納品物チェックで特に見落とされやすい論点です。発注者目線で必要最低限を整理します。
主要OSSライセンスを「自社への影響」で3つに分類
発注者の実務影響という観点では、OSSライセンスは大きく次の3つに分けて捉えると判断しやすくなります。
分類 | 代表的なライセンス | 自社への主な影響 |
|---|---|---|
寛容型（パーミッシブ） | MIT、Apache 2.0、BSD | 著作権表示・ライセンス文書の同梱が中心。改変・再配布の自由度は高い |
弱コピーレフト型 | LGPL、MPL 2.0 | 改変したOSS本体は同じライセンスで公開する義務がある。自社プロプライエタリ部分は分離できる |
強コピーレフト型 | GPL、AGPL | OSSと結合したソフトウェア全体を同じライセンス（GPL等）で公開する義務が生じる可能性がある |
「弱コピーレフト型」は実務で使われる呼称で、OSI等の公式分類とは厳密には一致しません。詳細な判定は弁護士・OSS有識者にご相談ください。GPL・AGPLが組み込まれている場合、外部提供形態（SaaS含む）によってはソースコード公開義務が発生し得るため、納品時に必ず確認すべき項目です。
納品時にもらうべき「OSS一覧表」とは
最低限、納品物として次の情報を整理した一覧表（SBOMに相当）を受領することをおすすめします。
- ライブラリ名・バージョン
- ライセンス種別（MIT、Apache 2.0、GPL v3 等）
- 公式リポジトリ・ライセンス文書のURL
- 直接依存／間接依存の区別
- 改変の有無（改変箇所のメモ）
これがないと、別会社への改修依頼時に公開リスクを評価できず、改修着手前に追加調査が必要になります。
GPLが含まれていた場合の自社内利用 vs 外部提供の判断
GPL系ライセンスは利用形態によって義務の発生有無が変わります。
- 社内利用のみ：通常ソース公開義務は生じません
- 顧客への頒布：頒布先にソース提供義務が生じ得ます
- SaaS等のネットワーク提供：通常GPLでは義務は生じないとされますが、AGPLは利用者にもソース提供義務が及び得ます
利用形態が変わる場合は含まれているOSSを再点検し、最終判断は弁護士・OSS専門家へご相談ください。
開発後に別会社へ改修依頼するときの権利整理手順
すでに納品されているシステムについて、別会社へ改修・保守を依頼する場面の実務手順を4ステップで整理します。「ベンダーロックインを避ける」ための中核セクションです。契約形態（請負・準委任・SES）による違いはSESとは？派遣・請負・準委任との違いもご参照ください。
ステップ1：現契約書で「自社が持つ権利」を棚卸しする
現状の契約書を読み返し、自社がどこまでの権利を持っているかを文書化します。
- 著作権の譲渡を受けているか、それとも利用許諾か
- 利用許諾の場合、改変・第三者再委託は許諾範囲か
- ソースコード・設計書は納品物に明記されているか
- 著作者人格権の不行使特約はあるか
- 27条・28条の特掲はあるか（譲渡の場合）
- OSS一覧の納品義務は契約に書かれているか
- 機密保持義務の範囲（誰が・どの情報を・いつまで保護するか）
「権利が曖昧」と感じた箇所は、ステップ3の交渉論点になります。
ステップ2：現ベンダーに正式に請求する事項
自社に権利があると判断できる場合は、現ベンダーへ正式に請求する事項を文書（メールまたは公式レター）でまとめます。
- ソースコード一式（Gitリポジトリのクローンまたはzipアーカイブ）
- 設計書・仕様書・運用手順書の最新版
- OSS一覧表とライセンス情報
- インフラ構成情報・アカウント情報（クラウド管理コンソール・ドメイン・SSL証明書等）
- 蓄積データのエクスポート（DBダンプ・ファイルストレージ）
- 引継書（運用上の注意点・既知のバグ・将来の改修候補）
請求は契約終了の通告と同時または前段で行うのが一般的です。情報が散逸する前に、早めに動きます。
ステップ3：契約に改修権がない・曖昧な場合の交渉アプローチ
改修権が認められていない・記載が曖昧というケースでは、次の交渉ルートが考えられます。
- 覚書による追加合意：現契約はそのままで、改修権・ソースコード引渡し義務を追加する覚書を結ぶ
- 解除条件のもとでの契約継続：保守契約を一定期間延長する代わりに、終了時のソースコード引渡しを条件に加える
- 新規契約での明文化：新ベンダーとの契約で、現ベンダーから受領するもの・代替手段を明確にする
交渉決裂時の法的リスクや、現ベンダーの履行拒否が損害賠償の対象になり得るかはシステム開発の損害賠償・リスク管理ガイドで扱っています。深刻なケースは早期に弁護士へ相談することをおすすめします。
ステップ4：新ベンダーに提供する範囲と秘密保持の設定
新ベンダーへの引継ぎでは、提供範囲を明確にしつつ、秘密保持・成果物の権利帰属を新たに契約で取り決めます。
- 新ベンダーへの提供範囲（ソースコード・設計書・データ・アカウント情報）
- 秘密保持契約（NDA）の締結——個人情報・顧客情報の取り扱い含む
- 新ベンダーが行う改修部分の著作権帰属（譲渡か利用許諾か）
- 旧ベンダー由来のコードと、新ベンダーが追加するコードの権利関係の整理
特に、旧ベンダーから受け取ったソースコードを新ベンダーへ渡す行為が、旧契約のどの条項に基づいて許容されるのかを必ず確認します。改変・再委託権がない契約下で第三者にソースコードを渡すと、契約違反を問われるリスクがあります。
著作権以外も忘れずに：特許・商標・データの権利
著作権の確認ができても、見落としやすい権利が残っています。「漏れに気づく」ことを目的に各論を簡潔に整理します。
業務プロセスを実装したシステムに潜む特許の論点
業務プロセスの新規性が高いシステムでは、ビジネスモデル特許やソフトウェア特許の論点が残っている可能性があります。
- 開発過程で生まれた発明（特許を受ける権利）が誰に帰属するか
- 既存特許に抵触していないかの調査が行われたか
- 別会社で同等機能を実装した場合に、旧ベンダー（または第三者）の特許に抵触しないか
- 契約書に「特許を受ける権利の帰属」条項があるか（なければ書面で取り決め）
特許の調査は専門領域のため、必要に応じて弁理士にご相談ください。
システム名・サービス名の商標
開発したシステムを社外向けサービスとして提供している場合は、商標権の確認も必要です。
- システム名・サービス名・ロゴが商標登録されているか
- 出願人は自社か、ベンダーか（ベンダー名義のままになっているケースに注意）
- 既存商標と類似していないか
- 登録番号と合わせて出願人を確認する
蓄積データ・データベースの著作権と利用権
業務システムの運用に伴って蓄積されるデータは、システムの寿命を超えて使い続ける資産です。
- 蓄積データの所有権・利用権は発注者にあるか（契約に明記されているか）
- データベース著作権（編集著作物としての著作権）の帰属
- 個人情報を含む場合、移行先への提供が個人情報保護法上の同意・通知要件を満たすか
- ベンダー側でのバックアップ・保管期間の取り決め
- 個人情報・顧客情報を含むデータベース移行は、弁護士・個人情報保護担当へ事前相談する
弁護士に相談する前にまとめておきたい論点と、よくある質問
弁護士相談前に手元で整理する4つの情報
弁護士相談は論点が整理されているほど短時間・低コストで進められます。
- 契約書原本：基本契約書・個別契約書・覚書・注文書の全セット。電子契約の場合は監査ログを含む
- 納品物リスト：実際に受領した成果物の一覧と、契約書記載の「納品物」との突き合わせ表
- 取引履歴：請求書・支払明細・主要なメール（特に納期・仕様変更・障害対応の合意記録）
- 現状の困りごとと希望する状態：金銭的解決か、ソースコード入手か、契約解除か等
よくある質問
Q1. 契約書に著作権条項がない場合、過去の請求書や仕様書は権利の証拠になりますか？
A. 譲渡条項がなければ著作権は受託会社に残ったままと解釈されるのが原則です。請求書や仕様書だけで権利譲渡を立証するのは難しいため、覚書による事後合意か、利用許諾範囲の明確化が現実的です。
Q2. 現ベンダーが改修を拒否しています、これは違法ですか？
A. 違法性は契約上の改修義務の有無で決まります。スポット契約で個別の保守義務がなければ改修拒否自体は通常違法ではありません。ただし、納品物の引渡しや契約終了後の引継ぎ協力を理由なく拒否している場合は、債務不履行や信義則違反を問える可能性があります（参考: 損害賠償・リスク管理ガイド）。
Q3. 無償のSaaSやライブラリを業務利用していたら、改修委託先に何を伝えるべきですか？
A. 利用中の外部サービス・OSSライブラリの一覧と、それぞれの利用規約・ライセンスを明示することをおすすめします。GPL系OSSや再配布制限のあるSaaSは新ベンダーでの改修方針に影響します。
Q4. ソースコードの一部だけ渡されました。残りも請求できますか？
A. 契約書の「納品物」条項を確認してください。「ソースコード一式」「全モジュール」と明記されていれば、不足部分の引渡しを請求できる可能性が高くなります。「主要な部分」「成果物」とだけ書かれている場合は解釈の余地があり、覚書での補完または交渉が必要です。
Q5. 別会社へ改修依頼するとき、旧ベンダーへの通知は必要ですか？
A. 契約上の通知義務がなければ法律上当然に必要とはいえません。ただし機密保持義務やソースコードの第三者開示制限が契約に残っていると旧契約違反のおそれがあります。新ベンダーへ渡す前に、旧契約の機密条項・再委託条項を必ず確認してください。
ベンダー乗り換えや内製化の場面で自社の権利を行使できるかは、納品時の確認と契約書の備えで大きく変わります。本記事のチェックリストを起点に、まずは社内で「自社が何を持っていて、何が欠けているか」を棚卸ししてみてください。整理した論点を持って弁護士へ相談すれば、取り得る選択肢が短時間で見えてきます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
