システム開発の著作権は誰のもの？｜ソースコードを渡してもらえないときの確認と進め方

ソースコードを渡してもらえないとき、最初に論点を分ける

今の開発会社との関係を見直したい。自社で改修したい、別の会社に保守を頼みたい。そう考えて「ソースコードを送ってください」と依頼したところ、「著作権は当社にあるのでお渡しできません」と返ってきた。発注担当者が次の手に迷う場面は少なくありません。

よくある誤解は、「開発費を払ったのだから、システムは丸ごと自社のもの」という考え方です。実際には、機器や媒体の所有権、プログラムの著作権、使ってよい範囲を定める利用許諾、ソースコードを引き渡す義務は、それぞれ別の論点です。代金の支払いだけでは、どれも自動的には決まりません。

先に結論を書くと、システム開発の著作権は、契約に定めがなければ原則として開発会社に残ります。ただしソースコードを受け取れるかどうかは、著作権とは別に、契約で納入物をどう定めたかで決まります。

本記事では、この論点の分け方を著作権法と IPA (情報処理推進機構) のモデル契約から整理し、既存の契約書の読み方と、渡してもらえないときの進め方を扱います。開発会社の乗り換え全体の手順は システム引き継ぎの進め方 を、保守運用だけを移す場合は システム保守の引き継ぎ を、開発が途中で止まった場合は システム開発の失敗から立て直す を参照してください。

所有権・著作権・利用許諾・引き渡し義務は別の話

ソースコードをめぐる話がこじれるのは、別々の権利を「自社のもの」という一言でまとめてしまうためです。まず 4 つの論点を分け、データも加えた全体像を押さえます。

論点	対象	何で決まるか	よくある誤解
所有権	納入された媒体や機器などの有体物	民法と契約 (所有権の移転時期)	所有権が移ればプログラムも自由に使える
著作権	プログラムの著作物	著作権法 (原則は作った側) と契約による譲渡	開発費を払えば発注者に移る
利用許諾	著作物を使ってよい方法と範囲	著作権者との契約	使えている以上、改変も委託もできる
ソースコードの引き渡し	ソースコードの複製物・関連ドキュメント	契約の納入物の定め	著作権を持っていれば当然もらえる
データ	業務データ・ログなど	契約と、現実に誰がアクセスできるか	自社のデータなので所有権で返してもらえる

民法 85 条 は「物」を有体物と定めています。所有権が及ぶのは媒体や機器であり、プログラムそのものは著作権の領域です。データについても、公正取引委員会の競争政策研究センターで配布された経済産業省の資料 AI・データの利用に関する契約ガイドラインの概要 が、データは無体物で民法上の所有権の対象にならず、利用権限は契約で定めると整理しています。

著作権と引き渡しの関係も見落としやすい点です。著作権が自社にあっても、手元に複製物がなければ改修は始められません。逆に著作権が開発会社に残っていても、契約でソースコードを納入物に含めていれば、ソースコード自体は受け取れます。

FIXIT

お金を払って作ってもらったのに、自分の会社のものじゃないの？

Shiori

整理すると、「物の所有」「著作権」「使ってよい範囲」「受け取れるもの」は別々なんです。

FIXIT

えっ、全部まとめて決まるわけじゃないんだ。

Shiori

はい。どれも契約で決まることが多いので、該当する条項を 1 つずつ探します。

システム開発の著作権は、原則として開発会社に帰属する

著作権法では、プログラムは著作物の例として挙げられています (著作権法 10 条 1 項 9 号)。ただし著作物は「思想又は感情を創作的に表現したもの」と定義されており (2 条 1 項 1 号)、保護されるには創作性が要ります。定型的な短いコードのように、表現の選択の幅が小さい部分は保護されないことがあります。著作者は「著作物を創作する者」であり (2 条 1 項 2 号)、会社の発意に基づいて従業員が職務として作ったプログラムは、作成時の契約や勤務規則に別段の定めがなければ会社が著作者になります (15 条 2 項)。著作権の発生に登録などの手続きは要りません (17 条 2 項)。

発注者の立場から読み替えると、開発会社の社員が書いたプログラムの著作権は、契約で移していない限り開発会社に残る、ということです。発注者が費用を負担したかどうかは、著作者を決める条文の要件に入っていません。

開発会社が別の会社や個人のフリーランスに外注していた場合は、外注先が作った部分の権利がどこにあるかも論点になります。15 条 2 項が対象にしているのは「法人等の業務に従事する者」が職務上作るプログラムなので、外注先の個人が書いた部分は、その個人が著作者になりえます。開発会社との契約でその権利がまとめて開発会社に移されているかどうかが、発注者に権利を移せるかの前提になります。

著作者人格権にも触れておきます。公表権・氏名表示権・同一性保持権からなる著作者人格権は、著作者の一身に専属し、譲渡できません (59 条)。そのため、契約で著作権を譲り受けても、改変に対して同一性保持権 (20 条) を主張される余地が残ります。20 条 2 項 3 号はプログラムを実行できるようにするための改変などを例外としていますが、範囲は限られています。実務の契約書では「著作者人格権を行使しない」という条項を置くのが一般的で、IPA のモデル契約も各案にこの定めを入れています。

「著作権を譲渡する」と書いてあっても、改修の権利が残ることがある

既存の契約書に「成果物の著作権は発注者に譲渡する」と書いてあれば安心、とは言い切れません。ここで確認したいのが、著作権法 27 条・28 条と 61 条 2 項 の関係です。

条文	内容 (要約)	発注者にとっての意味
27 条	著作物を翻訳・編曲・変形・翻案する権利	既存プログラムを改修して別のものにする場面に関わる
28 条	二次的著作物の利用について、原著作物の著作者が同じ種類の権利を持つ	改修後のプログラムを使う場面に関わる
61 条 1 項	著作権は全部または一部を譲渡できる	契約で発注者へ移せる
61 条 2 項	譲渡契約で 27 条・28 条の権利が特掲されていなければ、譲渡した者に留保されたものと推定する	「著作権を譲渡する」だけでは改修の権利が残ると推定される

改修や機能追加が翻案にあたるかは個別の判断になりますが、少なくとも契約書の文言としては「著作権 (著作権法第 27 条及び第 28 条の権利を含む。)」と明記されているかを確認します。IPA のモデル契約の解説も、27 条・28 条の権利は特掲されていなければ譲渡した者に留保したものと推定されるため、モデル契約ではこれらも譲渡されることを明記した、と説明しています。

61 条 2 項は「推定」なので、契約の経緯などほかの事情から覆る余地はあります。ただ、覆すには発注者側が事情を示す必要があり、そこで争うこと自体が負担です。文言が足りない契約書を見つけたら、関係が悪化する前に、確認書や覚書で扱いを明確にしておくほうが現実的です。

経済産業省・IPA のモデル契約では、著作権を 3 案で扱っている

発注者と開発会社のどちらの言い分が「普通」なのかを考えるときの参考になるのが、経済産業省の研究会がまとめ、IPA が改訂している 情報システム・モデル取引・契約書 第二版 です。第二版 (2020 年 12 月公開、2025 年 4 月に R1 へ改訂) の基本契約では、納入物の著作権について 3 つの案が用意されています。

案	著作権の帰属	発注者の利用
A 案	発注者や第三者が従前から持っていたものを除き、すべて開発会社	著作権法 47 条の 3 と 47 条の 6 に基づき、自ら実行するのに必要な限度で複製・翻案できる
B 案	汎用的なプログラムなどを除き、委託料の完済時に開発会社から発注者へ移転	開発会社に残った部分は A 案と同様に利用できる
C 案	新たに作ったプログラムは、汎用的なものを除き発注者と開発会社の共有	共有者の合意を契約であらかじめ与え、第三者への利用許諾を含めて互いに行使できる

C 案の定めは、共有著作権の行使に共有者全員の合意が要る (著作権法 65 条 2 項) ため、その合意を契約の時点で済ませておくものです。

解説では、ソフトウェアの再利用を促すため、原則として開発会社に著作権を帰属させる規定を A 案としています。つまり「著作権は当社にあります」という開発会社の回答は、契約が A 案に近い内容であれば、業界の標準的な取り決めに沿っている可能性があります。一方的に不当だと決めつけず、まず自社の契約がどの型に近いかを確かめるのが先です。

ソースコードの受け取りについて、同じ解説は、ソースコードや付帯ドキュメントの開示・交付を受けるには、納入物にソースコードを明記するか、エスクロウ制度を活用すれば対応できると整理しています。個別契約の記載例でも、納入物の一覧に設計書やマニュアルと並んで「ソースプログラム」が挙がっています。著作権の帰属とは別に、納入物の欄を見る必要があるということです。

既存の契約書で確認する条項

手元の契約書を読むときは、基本契約だけで判断しないことが大切です。個別契約、注文書と注文請書、見積書の前提条件、保守契約、途中で交わした覚書まで集めてから確認します。発注前の条項設計は AI 開発の契約は準委任と請負どちらが正解か で扱っているので、ここでは「すでにある契約をどう読むか」に絞ります。

確認する条項	見るポイント
納入物の定義	ソースコード、ビルド手順、設計書、データベースの定義が含まれているか
著作権の帰属	誰に帰属するか、27 条・28 条の権利を含むと明記されているか
著作権の移転時期	検収時か、委託料の完済時か。未払いの請求が残っていないか
汎用部分の留保	開発会社が従前から持つライブラリや汎用プログラムを除外しているか
利用許諾の範囲	自社での改変、第三者への保守委託が許されているか
著作者人格権	行使しない旨の定めがあるか
契約終了時の措置	ソースコードやドキュメントの引き渡し、データの返還や消去が定められているか
環境とアカウントの名義	サーバー、クラウド、ドメイン、リポジトリの契約者が誰になっているか
再委託	再委託先 (個人の外注を含む) が作った部分の権利を、開発会社がまとめて扱える定めになっているか

特に見落としやすいのが、環境とアカウントの名義です。サーバーやリポジトリが開発会社の名義で契約されていると、著作権の問題とは別に、発注者が自分で中身を取り出せません。ロックインを避けるために握る資産の考え方は ベンダーロックインを避ける発注設計 にまとめています。

契約書が見つからない、そもそも発注書とメールだけで進めた、という場合もあります。その場合は見積書や提案書の記載、納品時のやり取りが手がかりになるため、削除せずに集めておいてください。

ソースコードやデータを渡してもらえないときの進め方

渡してもらえないと分かった時点で、強い言葉で要求したくなるかもしれません。ただ、乗り換えが済むまでシステムの面倒を見ているのは今の開発会社です。関係を必要以上に悪化させないよう、次の順序で進めます。

flowchart TD
  A["1. 契約と資料を集め<br/>論点ごとに整理する"] --> B["2. 対象と根拠を書いた<br/>書面で依頼する"]
  B --> C{"回答の内容"}
  C -->|契約上の義務あり| D["引き渡しの時期と<br/>形式を詰める"]
  C -->|義務なし・判断が割れる| E["3. 有償の買い取りや<br/>利用許諾を交渉する"]
  E --> F["4. 折り合わなければ<br/>弁護士に相談する"]

1. 契約と資料を集め、論点ごとに整理します。前章の表に沿って、ソースコードの引き渡し、著作権、利用許諾、データ、アカウントのそれぞれについて、契約上どうなっているかを書き出します。未払いの請求が残っていないかもあわせて確認します。
2. 書面で依頼します。口頭や電話だけで済ませず、対象 (リポジトリ一式、データベースのダンプ、設計書、インフラの構成情報など)、根拠となる条項、受け取りたい形式、回答期限を書いたメールや文書で依頼します。何を求めたかが記録に残り、相手も社内で検討しやすくなります。
3. 契約上の義務がない、または解釈が割れる部分は交渉に切り替えます。著作権の有償での買い取り、改変と第三者への委託を含む利用許諾、汎用部分を除いた範囲だけの譲渡など、選択肢はいくつもあります。開発会社にとっても、自社の汎用部品を手放さずに済む形なら応じやすくなります。
4. 折り合わないときや、相手から法的な主張が返ってきたときは、IT や著作権に詳しい弁護士に相談します。ここまでに整理した表と書面のやり取りが、そのまま相談資料になります。

交渉がまとまる前に、手元にある古いソースコードや、正式な引き渡しを経ずに入手したコードを新しい開発会社に渡して改修させるのも避けてください。著作権者から許された範囲を超えて改変したり第三者に提供したりすると、発注者のほうが著作権を侵害する側になりえます。その場合は侵害の停止や予防を求める差止請求 (112 条) や、損害賠償の請求 (著作権法 114 条は損害額の推定を定めています) を受けるおそれがあります。複製物の所有者が自ら使うために必要な限度での複製と翻案は、著作権法 47 条の 3 と 47 条の 6 第 1 項 6 号で認められています (詳しくは FAQ の保守の質問を参照)。これを超える改変や第三者への提供には、著作権者の許諾が要ります。

FIXIT

いきなり弁護士に頼むのって、大げさじゃない？

Shiori

優先順位で言うと、契約の確認と書面での依頼が先です。そこで解決することもあります。

FIXIT

じゃあ、どこで相談に切り替えるの？

Shiori

交渉しても折り合わないときや、相手から法的な主張が返ってきたときです。

受け取れたあとに確認すること、受け取れなかったときの選択肢

ソースコードを受け取れても、それだけで次の開発会社がすぐ作業を始められるとは限りません。受け取った直後に、次の点を確認しておきます。

• 本番で動いているものと同じ版か。最終の改修が反映されているか
• 手順どおりにビルドし、検証環境で起動できるか
• パスワードや API キーなどの秘密情報が、別途安全な方法で引き渡されているか
• データベースの定義と、実際のデータの対応が分かるか
• 利用しているオープンソースのライセンスと、有償ライブラリの契約者が誰か

設計書が残っていない場合でも、ソースコードがあれば仕様を読み解く手段はあります。進め方は 仕様書のないレガシーを AI で読み解く方法 で紹介しています。

交渉しても受け取れなかった場合は、画面操作や帳票、業務担当者へのヒアリングから現行の挙動を洗い出し、作り直す道が残ります。ソースコードがない分だけ調査の工数が増えるため、見積もりの考え方は リプレイス案件の見積の考え方 を参考にしてください。

作り直しが著作権侵害にならないかは、何を使うかで分かれます。プログラムの著作物の保護は、プログラム言語、規約、解法 (電子計算機への指令の組合せの方法) には及びません (著作権法 10 条 3 項)。画面・帳票・業務から仕様を洗い出し、別のコードとして書き起こすことと、既存のコードを書き写したり改変して流用したりすることは、分けて考えます。前者はコードの表現を使わないため著作権の問題になりにくい一方、後者は元のコードの表現を使うため侵害の問題が生じえます。手元に旧コードの一部が残っているなど判断が分かれる場合は、作業を始める前に弁護士に相談してください。

これから発注するときに契約へ入れておく条項

同じ状況を繰り返さないために、次の発注では契約の段階で扱いを決めておきます。入れておきたいのは次の内容です。

1. 納入物として、ソースコード、ビルドとデプロイの手順、インフラの構成情報、データベースの定義を明記する
2. 著作権を移すなら「著作権法第 27 条及び第 28 条の権利を含む」と書き、移転の時期 (検収時か完済時か) を決める
3. 開発会社に残す汎用部分がある場合は、その範囲と、自社での改変や第三者への保守委託を含む利用許諾を定める
4. 著作者人格権を行使しない旨を入れる
5. サーバー、クラウド、ドメイン、リポジトリは発注者の名義で契約し、開発会社には権限を付与する形にする
6. 契約終了時のソースコードとドキュメントの引き渡し、データの返還、引き継ぎへの協力期間を決める
7. 再委託先 (個人の外注を含む) が作った部分の権利を、開発会社がまとめて移転または許諾できる定めを入れる

著作権の譲渡を求めると、見積もりにその対価が反映されることがあります。IPA のモデル契約の解説も、著作権の譲り受けを希望するなら、事前に提案依頼書で明らかにし、委託料の構成要素として見積もりを依頼すると説明しています。パッケージ製品のようにソースコードの譲渡が難しい場合は、SOFTIC のソフトウェア・エスクロウ のように、倒産などの条件でソースコードを開示する仕組みを検討する方法もあります。発注先を比べる段階での見方は AI 開発の発注前に確認する 10 項目 にまとめています。

FIXIT の運用 ─ 契約書の権利条項と、実際の構成を突き合わせる

FIXIT は AI 駆動開発のクリエイティブスタジオとして、他社が開発したシステムの引き継ぎの相談を受けています。その一環として、契約書の権利条項と実際の構成の突き合わせもお引き受けしています。引き継ぎや改修を前提にせず、現状調査だけを単独でお受けすることもできます。契約書で納入物や名義がどう定められているかと、実際にどのリポジトリとデータがあり、どの環境が誰の名義になっているかを並べ、食い違っている箇所を洗い出します。

契約の解釈そのものは弁護士の領域なので、私たちは法的な判断を代わりに行いません。担当するのは技術面の整理です。受け取ったソースコードが本番と一致しているか、ビルドできるかを確かめ、引き継ぎに足りない技術情報を一覧にします。

自社のクライアントワークでも、ソースコードや環境構築の手順を一式お渡しし、発注者が別の体制へ移れる状態を前提に進めています。

ソースコードを渡してもらえないと分かったら、まず契約書と関連資料を 1 か所に集め、所有権・著作権・利用許諾・引き渡し・データの 5 つに分けて書き出してください。相手に何を求められるのか、何を交渉すべきなのかが、その表から見えてきます。

乗り換え全体の段取りは システム引き継ぎの進め方 で、刷新まで視野に入れる場合は システム刷新・リプレイス のページで紹介しています。契約書と現状の構成を見ながら、どこまで引き継げるかを一緒に整理したい場合は、お問い合わせ からご相談ください。