ソースコードの著作権は誰のものか：保守会社を変えるとき・直したいときに、契約書と著作権法で確かめること

「別の会社に保守を頼みたいので、ソースコードを渡してほしい」。そうお願いしたら、「著作権は当社にあるので渡せません」と言われた。逆に、新しい会社から「著作権がどちらにあるか分からないと、手を付けられません」と言われた。業務システムを何年も使っていると、こうした場面に出会うことがあります。

お金を払って作ってもらったのだから、自社のものだと考えるのは自然です。でも、法律と契約の上では、そう単純ではありません。一方で、著作権が開発会社に残っていても、発注した会社が何もできないわけでもありません。

経済産業省の DX レポート（2018年）は、ドキュメントが整っていない、分かる人がいない、といった理由で既存のシステムがブラックボックスになっていることを、多くの企業の課題として挙げました。JUAS の「企業IT動向調査報告書2026」でも、回答した東証上場企業などの IT 予算の配分は、平均で75.9%が今の事業を維持・運営するための費用でした。動いているシステムを、誰が、どの権利で直していくのか。ソースコードの著作権は、その土台になる問題です。

この記事は、保守会社や開発会社を変えたい方、これから業務システムの開発を発注する方に向けて書いています。次のことを順にまとめます。

• ソースコードの著作権が、最初に誰に生まれ、契約でどう動くか
• 著作権が開発会社にあっても、発注した会社ができること
• 「著作権」と「ソースコードを受け取れるか」が別の問題であること
• 場面ごとの考え方と、渡してもらえないときの選択肢
• これから契約するときに決めておくこと

なお、この記事は条文と公的な資料をもとにした一般的な整理です。個別の契約の判断は、契約書の条文と、必要に応じて弁護士などの専門家の意見をもとに行ってください。

結論：「著作権」と「受け取れるか」と「直してよいか」を分けて確かめる

ソースコードの扱いで迷ったら、次の3つを分けて確かめます。

1. 著作権はどちらにあるか：会社の従業員が仕事として書いたプログラムの著作者は、原則としてその会社（開発会社）です。発注した会社に移るかは、契約書で決まります
2. ソースコードを受け取れるか：著作権とは別に、契約で決めた「納入物」にソースコードが入っているかで決まります
3. 直したり、ほかの会社に頼んだりしてよいか：著作権が開発会社にあっても、自社で使うために必要な範囲の複製や手直しは著作権法で認められています。ほかの会社への開示を禁じる約束がないかは、契約書で確かめます

この3つを混ぜて話すと、今の会社とも新しい会社とも話がかみ合いません。まず手元の契約書を読み、3つのそれぞれについて「書いてあること」と「書いていないこと」を分けてください。

ソースコードと著作権の基本

プログラムは「著作物」として守られる

著作権法は、プログラムを「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」と定め（第2条第1項第10号の2）、著作物の例として「プログラムの著作物」を挙げています（第10条第1項第9号）。業務システムのソースコードも、これに当たります。

ただし、守られるのは書かれた表現です。同じ条の第3項は、プログラムを書くための言語、規約（決まりごと）、解法（アルゴリズム）は保護の対象にならないと定めています。つまり、「受注を登録すると在庫が引き当てられる」という仕組みや考え方そのものは、著作権で独占されるものではありません。

最初の著作者は、多くの場合「開発会社」

では、プログラムを書いたのは誰か。著作権法第15条第2項は、会社の発意で、その会社の業務に従事する人が仕事として作ったプログラムの著作者は、契約や勤務規則などに別の定めがない限り、その会社だと定めています。

法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

（著作権法 第15条第2項）

開発会社の従業員が業務として書いたソースコードなら、著作者は開発会社です。プログラム以外の著作物では、会社の名義で公表することも条件になっていますが、プログラムの場合はその条件がありません。

発注した会社がお金を払ったことだけで、著作権が移るわけではありません。移るかどうかは、次に見る契約で決まります。

著作権の行き先は、契約で決まる

モデル契約の3つの案

IPA が公開している「情報システム・モデル取引・契約書（第二版）」は、業務システムの受託開発の契約のひな型です。その第45条（納入物の著作権）には、次の3つの案が用意されています。

（IPA「情報システム・モデル取引・契約書（第二版）」より）

「すべて発注した会社に移す」という案は、ひな型には入っていません。B案・C案でも、ほかの開発にも使える汎用的なプログラムは開発会社に残す形になっています。手元の契約がどの案に近いか、汎用的な部分をどう定めているかを確かめてください。実際の契約は、両社の話し合いでひな型と違う定めにすることもできます。

「著作権を移す」と書いてあっても確かめること

契約書に「著作権は発注者に移転する」と書いてあっても、安心するのは早いかもしれません。著作権法第61条第2項は、次のように定めています。

著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。

（著作権法 第61条第2項）

第27条は翻訳や翻案（手を加えて新しいものを作ること）の権利、第28条はそうして作られたものの利用に関する権利です。プログラムを直していくには、まさにこの権利が関わります。モデル契約の A案でも、開発会社に帰属させる権利として「著作権法第27条及び第28条の権利を含む」と書かれています。自社の契約で著作権を移しているなら、同じように第27条・第28条の権利を含むと書かれているかを確かめてください。

著作者人格権は、移せない

著作権とは別に、著作者には「著作者人格権」があります。著作権法第59条は、著作者人格権は著作者だけのもので、譲渡できないと定めています。その一つの同一性保持権（第20条）は、著作者の意に反して著作物を改変されない権利です。

ただし、プログラムについては例外があります。第20条第2項第3号は、特定のコンピューターで動かないプログラムを動くようにするため、またはより効果的に動くようにするために必要な改変には、同一性保持権が及ばないと定めています。それ以外の改変も含めて扱いをはっきりさせたい場合は、契約で人格権をどう扱うかを確かめておきます。

著作権が開発会社にあっても、できること

著作権が開発会社に残っている契約でも、発注した会社が自社のシステムを使い、直していく道はあります。

自社で使うための複製と手直し

著作権法第47条の3は、プログラムの複製物の所有者が、自分でコンピューターで実行するために必要な範囲で、そのプログラムを複製できると定めています。

プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において実行するために必要と認められる限度において、当該著作物を複製することができる。

（著作権法 第47条の3第1項）

第47条の3が認めるのは複製です。同じ範囲で手を加えること（翻案）は、第47条の6第1項第6号が認めています。モデル契約の第45条第2項も、A案のように著作権が開発会社にある場合に、発注した会社がこれらの規定に従って複製・翻案できることを確認する形になっています。

なお、モデル契約の条文は翻案の根拠を「第47条の6第1項第2号」と書いていますが、2026年11月時点の著作権法では、第47条の3第1項に対応する翻案は第47条の6第1項第6号です。モデル契約を元にした契約書では、号の番号が今の条文と合わないことがあるので、条文を引くときは今の法令で確かめてください。

ここで注意したいのは「自分で実行するために必要な範囲」という限定です。自社のシステムを動かし続けるための手直しと、そのプログラムを元に別の製品を作って売ることは、まったく別の話です。

ほかの会社に保守を頼むこと

自社で直せる範囲があるとしても、多くの会社は保守を外の会社に頼みます。その点について、モデル契約の解説には、次の考え方が示されています。

著作権を有しないユーザが情報システム子会社その他アウトソーシングベンダに保守運用を委託することは可能である。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

つまり、著作権が今の開発会社にあることだけを理由に、別の会社に保守を頼めないわけではない、というのがモデル契約の考え方です。ただし、手元の契約に「第三者に開示しない」「第三者に改変させない」といった約束が入っていれば、その約束に従う必要があります。秘密保持の条項や、ソフトウェアの利用許諾の条項も読んでください。

「著作権」と「ソースコードを受け取れるか」は別の問題

ここまで著作権の話をしてきましたが、実務でもっと困るのは、そもそもソースコードが手元にないことです。そして、ソースコードを受け取れるかは、著作権とは別に決まります。

受け取れるかは「納入物」で決まる

モデル契約では、開発会社が作って渡すもの（納入物）の明細を、個別の契約で決めます。個別の契約の例では、納入物の一覧に「ソースプログラム」が入っています。モデル契約の解説は、ソースコードを確実に受け取る方法について、次のように書いています。

ソースコードや付帯するドキュメントの開示・交付を受けることは、納入物にソースコードを明記するか、エスクロウ制度の活用により対応可能である。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

逆に言えば、納入物にソースコードが書かれていない契約では、渡してもらえるかを今の会社と話し合って決めることになります。＠IT の連載「「訴えてやる！」の前に読む IT訴訟 徹底解説」の第40回（細川義洋氏、2017年）では、ソースコードの引き渡しが争われた大阪地方裁判所の判決（平成26年6月12日）を取り上げ、合意がなければ開発会社にソースコードを引き渡す義務はないと判断された、と解説しています。

著作権が自社にあっても、手元にあるとは限らない

逆の場面もあります。著作権を移す契約だったのに、ソースコードを受け取っていない。あるいは、受け取ったけれど、何年も前の版で、今の本番とは違う。この場合、著作権は自社にあっても、実際に直す材料がありません。

確かめる場所は、契約書の本体だけではありません。個別の契約書、注文書、見積書の「納入物」の欄、検収のときに受け取った一覧も見てください。受け取ったソースコードが今の本番と同じかは、技術の確認になるので、引き継ぎ先の会社に調べてもらいます。

よくある5つの誤解

ここまでの内容を、引き継ぎの相談でよく聞く思い込みに当てはめて整理します。

1.「お金を払ったのだから、著作権は自社のもの」

払った対価は、作る作業に対するものです。会社の従業員が仕事として書いたプログラムの著作者は、原則として開発会社です（第15条第2項）。発注した会社に移るのは、契約でそう決めた場合です。契約書を見ずに「自社のもの」と思い込んで話を始めると、今の会社との話し合いがこじれやすくなります。

2.「著作権がないから、自社では何もできない」

反対の思い込みです。著作権が開発会社にあっても、自社で使うために必要な範囲の複製と手直しは、著作権法で認められています（第47条の3、第47条の6）。モデル契約の解説も、ほかの会社に保守を頼むことはできるという考え方です。できないことがあるとすれば、それは多くの場合、著作権ではなく契約の約束（秘密保持など）によるものです。

3.「著作権が自社にあれば、ソースコードも渡してもらえる」

著作権と、ソースコードという「もの」を受け取れるかは別です。受け取れるかは、納入物にソースコードが入っているかで決まります。著作権を移す契約でも、納入物が実行できる形のプログラムだけなら、ソースコードは手元に来ません。

4.「今のシステムと同じ動きのものを作ると、著作権の侵害になる」

著作権で守られるのは、書かれたプログラムの表現です。プログラムの言語、規約、解法（アルゴリズム）は保護の対象になりません（第10条第3項）。今の業務の流れや画面の役割を整理し、新しいシステムの要件にして一から書くことと、今のソースコードを写すことは違います。ただし、どこまでが「表現」かの線引きは個別の判断になるので、今のソースコードを流用する場合は、権利の扱いを確かめてからにします。

5.「最初の納品で受け取ったから、もう大丈夫」

最初の納品のときにソースコードを受け取っていても、その後の改修のたびに受け取っていなければ、手元の版は古くなっていきます。改修の契約ごとに、納入物にソースコードが入っているか、受け取った版を本番と照らし合わせているかを確かめてください。

場面ごとの考え方

手元の契約書の状態ごとに、考え方をまとめます。

場面3：納入物に入っていないとき

今の会社に、渡してほしい理由と範囲を書面で伝えて相談します。保守を別の会社に移すことを伝えるのは気が引けるかもしれませんが、隠して進めるより、早めに相談したほうが協力を得やすくなります。開発会社にとっても、共通の部品やノウハウを守れる形なら応じやすいので、「このシステムの保守に必要な範囲」と目的を絞って頼むのがこつです。費用を払って引き渡しや引き継ぎの協力をしてもらう形もあります。

場面5：連絡がつかないとき

開発会社が事業をやめた、連絡がつかない、という場合は、ソースコードを手に入れるのが難しくなります。著作権法第63条の2は、許諾を受けて使う権利（利用権）を、著作権を後から取得した人などにも主張できると定めています。一方、著作権の移転を第三者に主張するには、登録が必要です（第77条）。法的な整理は専門家に相談しつつ、実務では、動いているシステムから仕様を把握し直す、作り直しや置き換えを比べる、といった道を並行して考えます。

ソースコードがないとき・渡してもらえないときの選択肢

話し合ってもソースコードが手に入らない場合に、取れる道は主に3つです。

1. 今のシステムを使い続けながら、周りを変える：直せない部分には手を付けず、入出力のデータを使って、周りに新しい仕組みを足していく
2. 少しずつ置き換える：業務の一部から、新しいシステムに移していく
3. 作り直す：今の動きを把握したうえで、新しく作る

どれを選ぶかは、システムが業務にどれだけ深く入っているか、使っている部品のサポートがいつ切れるか、業務の進め方を変えたいかで決まります。判断の基準は「古いシステムは直すか、作り直すか」にまとめています。作り直す場合も、今の動きを把握する作業は必要です。仕組みや考え方は著作権で独占されないので、今の業務の流れを整理して、新しいシステムの要件にすることはできます。

これから契約するときに決めておくこと

これから業務システムの開発を発注する場合や、保守契約を結び直す場合は、次の項目を契約書で確かめておくと、将来の引き継ぎで困りにくくなります。

• 著作権の行き先（モデル契約の A案・B案・C案のどれに近いか）
• 著作権を移す場合、「第27条及び第28条の権利を含む」と書かれているか
• 著作権が開発会社に残る場合、自社での複製・手直しと、ほかの会社への保守の委託ができるか
• 納入物に、ソースコードと、組み立て・反映の手順、設計の資料が入っているか
• 改修のたびに、最新のソースコードを受け取る決まりがあるか
• ソースコードの置き場所（Git など）の管理者が、自社のアカウントになっているか
• 保守契約が終わるときに、引き継ぎに協力してもらえるか、その費用はどうなるか
• 秘密保持の条項が、ほかの会社への保守の委託を妨げない書き方になっているか

契約書を読む順番

手元の契約書を読むときは、次の順番で見ると迷いにくくなります。

1. 契約書の束をそろえる：基本契約書、個別の契約書、注文書、見積書、検収の書類、保守契約書
2. 「著作権」「知的財産」の条項を探す：誰に帰属するか、第27条・第28条の権利を含むか、汎用的な部分の扱い
3. 「納入物」「成果物」の定めを探す：ソースコード、資料、手順書が入っているか
4. 「秘密保持」「第三者」の条項を探す：ほかの会社に開示・委託してよいか
5. 保守契約の「期間」「解約」「終了」の条項を探す：いつ、どう終わらせられるか、終わるときに何を返すか

読んだ結果は、「書いてあること」「書いていないこと」「解釈に迷うこと」の3つに分けてメモします。「解釈に迷うこと」は専門家に、「書いていないこと」は今の会社との話し合いで決めます。

保守会社を変えるときの進め方の全体（契約の確かめ方、引き継ぐものの一覧、日程の組み方、新しい会社の選び方）は、無料の「保守会社の変更 実務ガイド」（PDF）にまとめています。引き継ぐものを一つずつ追う「保守引き継ぎ管理表」（Excel・登録不要）もあわせてお使いください。

おわりに

ソースコードの著作権の問題は、引き継ぎの場面で突然表に出てきます。そのときに「著作権」「受け取れるか」「直してよいか」を分けて考えられれば、今の会社とも新しい会社とも、話を前に進められます。

引き継ぎの具体的な手順は「開発会社を途中で変えるとき」に、引き継いだ後に最初にやることは「システムの保守を引き継いだら、最初にやること」にまとめています。

クリーヴァは、ほかの会社が作った業務システムの保守や、引き継ぎのご相談もお受けしています。ソースコードや資料がそろっていない状態からでも、まず今のシステムで何が分かり、何が足りないかを一緒に確かめるところから始められます。

出典（2026年11月11日に確認）

• 著作権法（第2条・第10条・第15条・第20条・第27条・第28条・第47条の3・第47条の6・第59条・第61条・第63条の2・第77条）
• IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉」（2020年12月22日公開）
• 経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（2018年9月7日）
• 一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査報告書2026」
• ＠IT「「訴えてやる！」の前に読む IT訴訟 徹底解説（40）」（細川義洋）（2017年4月24日）