ソースコード・リポジトリの譲渡とライセンス｜契約書で必ず書くべき条項

システム開発における納品フェーズでは、作成されたソースコードの権利を誰が持ち、どのように管理するかが最大の論点となります。特に受託開発において、ソースコードの譲渡（著作権譲渡）が適切に行われていないと、将来的なM&Aや他社への保守切り替えの際に甚大な法的・技術的リスクを招くことになります。

本記事では、IT実務者の視点から、ソースコードおよびリポジトリを安全に譲渡するために「契約書に書くべき条項」と「リポジトリ移転の技術的手順」を網羅して解説します。

ソースコード譲渡とライセンスの基礎知識

まず整理すべきは、「ソースコードが手元にあること」と「著作権を持っていること」は別物であるという点です。

著作権の帰属先を明確に定義する重要性

日本の著作権法では、特段の合意がない限り、プログラムの著作権は「作成した人（または法人）」に帰属します（著作権法第15条）。つまり、発注側が開発費用を支払っていても、契約書に「著作権を譲渡する」旨の記載がなければ、権利は開発会社に残ったままとなります。この状態で他社に改修を依頼したり、コードを転用したりすると、著作権侵害を指摘されるリスクが生じます。

著作権譲渡と利用許諾（ライセンス）の違い

全てのコードを譲渡することが必ずしも正解とは限りません。以下の2つのパターンから選択するのが実務的です。

• 著作権譲渡型: コードの全権利を発注者に移転する。発注者は自由に改変・再販が可能。
• 利用許諾型: 著作権は開発会社に保持したまま、発注者に「使用する権利」を与える。SaaSのカスタマイズ案件などに多い。

忘れがちな「著作者人格権の不行使」条項

著作権（財産権）を譲渡しても、「著作者人格権（公表権、氏名表示権、同一性保持権）」は作者本人に残り、譲渡することができません。これが残っていると、発注者がコードを勝手に改変した際に「同一性保持権の侵害」として訴えられる理論的リスクが残ります。そのため、契約書には必ず「乙（開発者）は甲（発注者）に対し、著作者人格権を行使しないものとする」という一文を入れる必要があります。

このようなITインフラや資産の整理は、将来的なコスト削減にも直結します。例えば、不要なSaaSライセンスの整理については以下の記事が参考になります。

SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

契約書に必ず盛り込むべき5つの重要条項

トラブルを未然に防ぐため、以下の条項が契約書（個別契約または業務委託契約）に含まれているか確認してください。

1. 権利譲渡の範囲（共通ライブラリの除外）

開発会社にとって、自社で使い回している「共通関数」や「汎用モジュール」まで譲渡してしまうと、他社の開発ができなくなります。

「本件成果物のうち、乙が本件業務の遂行前から保有していた汎用的なプログラム（以下『共通ライブラリ』という）の著作権は乙に留保されるものとし、乙は甲に対し、本件成果物を利用するために必要な範囲で、共通ライブラリの非独占的な使用権を許諾するものとする。」

このように、譲渡対象から共通部分を除外するのが実務上の落とし所です。

2. 契約不適合責任（旧：瑕疵担保責任）

納品されたソースコードにバグがあった場合、いつまで無償補修を求めることができるかを定めます。実務上は「検収完了から3ヶ月〜6ヶ月」とされるのが一般的です。

3. 秘密保持と機密情報の破棄

リポジトリ譲渡後、開発会社のローカル環境やテストサーバーにコードが残ることはセキュリティリスクです。「納品完了後、乙は本件成果物に関する全ての複製物を遅滞なく破棄または返却しなければならない」旨を明記します。

4. 第三者の知的財産権（OSS）の保証

現代の開発でオープンソース（OSS）を利用しないケースは稀です。しかし、GPLライセンスのように「利用したプログラムも公開しなければならない」強い制約があるものが混入すると、商用利用に支障が出ます。「第三者の知的財産権を侵害していないこと、およびOSSのライセンス条件を遵守していること」を開発側に保証させます。

5. 譲渡のタイミングと対価の支払い

「著作権は、対価の全額が支払われた時に甲に移転する」という条項を入れることで、開発会社側は未払いリスクをヘッジできます。

GitHub/GitLabリポジトリ譲渡の実務ステップ

法的な契約が完了したら、次は技術的な移転作業です。単にzipファイルを送るのではなく、Gitリポジトリのオーナー権限そのものを移譲するのが現代のスタンダードです。

オーナー権限譲渡（Transfer Ownership）の手順

GitHubを例に、開発会社アカウントから発注者アカウントへリポジトリを譲渡する手順は以下の通りです。

1. リポジトリの「Settings」タブを開く。
2. 最下部の「Danger Zone」にある「Transfer」ボタンをクリック。
3. 新しいオーナー（発注者側）のユーザー名またはOrganization名を入力。
4. 発注者側に承認メールが届くので、承諾する。

※GitHubの公式ドキュメント（Transferring a repository）も参照してください。

譲渡前に実施すべき「機密情報のスキャン」

最も多い事故が、.envファイルやsettings.jsonなどの設定ファイルに、AWSのアクセスキーやDBのパスワード、外部APIのトークンがハードコードされたまま譲渡されるケースです。
たとえ最新のコミットから消しても、Gitの履歴（History）を辿れば過去のキーが筒抜けになります。

譲渡前に以下のツールでスキャンを実施し、履歴を含めて削除する必要があります。

• gitleaks: リポジトリ内の機密情報を検知する標準的なOSSツール。
• BFG Repo-Cleaner: 履歴から大きなファイルやパスワードを削除するためのツール。

社内でのアカウント管理や権限整理については、こちらのガイドも役立ちます。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

主要なリポジトリホスティングサービスの機能比較

各プラットフォームによって、譲渡の仕様や制限が異なります。主要3サービスの比較表を以下に示します。

譲渡後に発生しやすいトラブルと回避策

「コードは受け取ったが、動かない」という事態は、情シスの現場で頻発します。

環境依存の問題で「自社環境でビルドできない」

開発者のローカル環境にのみ存在する設定や、特定のバージョンのコンパイラに依存している場合に起こります。これを防ぐには、Docker等を用いたコンテナ化された開発環境を納品物に含めるよう契約で定義するのが最も効果的です。

依存ライブラリの脆弱性やライセンス違反

納品されたコードが古いライブラリを使用しており、重大な脆弱性（CVE）を抱えていることがあります。検収時に npm audit や pip list --outdated 等を実行し、セキュリティリスクがないかを確認するステップをフローに入れましょう。また、ライセンスが商用利用不可のものが含まれていないかも、ライセンスチェッカー（例：FOSSA, Snyk）で確認すべきです。

IT資産の健全性を保つことは、経営データの可視化にもつながります。

【完全版・第5回】freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術

まとめ：円滑な譲渡がプロジェクトの価値を守る

ソースコードの譲渡は、単なるファイルの受け渡しではなく、「法的権利の移転」と「技術的負債のチェック」を同時に行うプロセスです。
契約書で自社の権利を保護しつつ、GitHub等のプラットフォーム機能を正しく使い分け、セキュリティスキャンを徹底することで、将来にわたって保守可能な資産を確保することができます。

もし、こうしたリポジトリ管理やIT資産の整理において、既存のExcel管理などに限界を感じている場合は、AppSheetなどのローコードツールを活用して管理台帳をDX化することも検討に値します。