システム開発の著作権・ソースコードは誰のもの?業務委託契約書の知的財産条項で決める項目と、ラボ型・オフショアでの成果物の帰属【2026年版】

「保守を別の会社に移そうとしたら、元の開発会社に『ソースコードは渡せない』『改修は著作権侵害になる』と言われた」——外注したシステムを持つ企業の情報システム担当から、こうした相談をよく受けます。開発費を全額払ったのだから完成したシステムは自社のもの、と思うのは自然です。しかし著作権法の原則はそうなっていません。契約書に何も書いていなければ、権利は開発会社に残ります。

結論から言うと、システム開発の著作権は「お金を払った人」ではなく「作った人(開発会社)」に発生します。自社で改修し、他社に引き継げる状態にするには、契約書で著作権の帰属、利用できる範囲、ソースコードの納品、汎用部品の扱いの4項目を決め、譲渡なら「27条・28条の権利を含む」と「著作者人格権を行使しない」を明記する必要があります。全譲渡が難しくても、ソースコードの納品、改修権、第三者への再許諾権の3点を確保すれば、実務上の大半のトラブルは防げます。

契約時にこれを決めておけば、ベンダーを変えるときも、開発会社が廃業したときも、システムを自社で育て続けられます。逆に、稼働後に「やはり権利がほしい」と交渉すると、費用も手間も膨らみます。権利の問題は契約時にしか手を打てない、というのが実情です。

本記事では、著作権の原則と譲渡・利用許諾の違い、契約書で決める項目のチェックリストと費用とのバランス、起きるトラブルと、ラボ型・オフショア(準委任)で毎月生まれる成果物の帰属・引き渡しの決め方、当社の契約、よくある質問の順に解説します。法的助言ではなく相談前の整理としてお読みいただき、契約の最終判断は弁護士にご確認ください。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。権利のトラブルに共通するのは「契約書に著作権の記載がなかった」ことです。この記事を読み終えるころには、手元の契約書のどこを直せばよいか、次の契約で何を書けばよいかが判断できるはずです。

システム開発の著作権は誰のものか——原則は「作った側」、譲渡と利用許諾の違い、ソースコードと著作権は別

「開発費を払ったのだから、完成したシステムは自社のもの」と考える方は多いのですが、著作権法の原則は逆です。ここでは、著作権が誰に発生するのか、開発会社が権利を持ちたがる理由、譲渡と利用許諾の違い、そしてソースコードの現物と著作権が別物であることを整理します。なお本記事は法的助言ではなく相談前の整理で、契約の最終判断は弁護士にご確認ください。

原則: 著作権はお金を払った人ではなく、作った人に発生する

コンピュータプログラムは著作権法で保護される著作物です(著作権法10条1項9号「プログラムの著作物」)。著作権は登録や申請なしに発生し(著作権法17条2項「著作者人格権及び著作権の享有には、いかなる方式の履行をも要しない」)、システム開発ではコードが書かれた瞬間に、そのコードを書いた開発会社に著作権が生まれます。発注者が開発費を全額負担しても、それだけで権利が移ることはありません。建物を建ててもらえば建物そのものは依頼主のものになりますが、設計図の著作権は設計した側に残る、という関係に近いと考えてください。

例外は内製です。自社の従業員が業務として開発した場合は職務著作(15条)の規定により、原則として会社が著作権を持ちます。外注と内製で権利の扱いが変わる点は、内製化を検討するときの判断材料にもなります。

開発会社が権利を持ちたがる3つの理由

開発会社が著作権を保持したがるのには、合理的な理由があります。1つ目はライブラリやフレームワークの再利用です。ログイン機能や帳票出力など、どの案件でも使う共通の部品を持っており、それを完成システムごと譲渡すると自社の資産を失います。2つ目はノウハウの保護で、長年磨いた設計パターンが競合に流出するリスクを避けたい。3つ目は保守・改修の継続受注で、権利を保持していれば発注者が他社に乗り換えにくくなる、という側面も否定できません。

この3つが組み合わさって、「著作権は開発会社が持つ」という慣行が生まれています。3つ目の理由は発注者にとって不利益ですが、1つ目と2つ目には合理性があります。だからこそ、全部を奪い合うのではなく、線引きで折り合うのが現実的です。

譲渡と利用許諾の比較表——譲渡が難しいときの最低限3点

全譲渡を求めると難色を示されることは多く、汎用ライブラリが組み込まれた部分は技術的にも切り離せません。その場合でも、ソースコードの納品、改修権、他のベンダーに保守・改修を委託できる再許諾権の3点を利用許諾の範囲として契約に明記すれば、実務上の大半のトラブルは防げます。

ソースコードの現物と著作権は別——両方をそろえて初めて「自社のシステム」

見落とされがちなのが、ソースコード(現物)と著作権(権利)が別物だということです。ソースコードのファイルを受け取っても、著作権が開発会社に残っていれば、改変して使うには許諾が要る状態があり得ます。逆に、著作権を譲り受けてもソースコードの現物を渡してもらえなければ、実際には手を入れられません。納品義務は当然には発生せず、契約書に「ソースコード一式を納品物に含む」と書かなければ、開発会社が引き渡す義務を負わないとする解釈もあります。

つまり、「ソースコードを納品してもらう」ことと「著作権を譲り受ける(または改修権と再許諾権の許諾を受ける)」ことは、別々に契約書に書く必要があります。権利は契約時にしか手を打てない、というのが私の持論です。次章では、契約書で具体的に何を決めるかをチェックリストにします。

業務委託契約書の知的財産条項で決める項目——4項目+27条28条・著作者人格権・OSS・生成AI、費用とのバランス

契約書のどこを見ればよいかは、実は限られています。当社が受発注の双方で契約書を確認してきた経験では、争点になるのは帰属・利用範囲・ソースコードの納品・汎用部品の扱いの4項目に集約されます。ここでは、そのチェックリストと、OSS・生成AI・特許・競業避止の扱い、費用とのバランスを整理します。

決める4項目(表)

②の「他社に改修を依頼できるか」が、乗り換えの自由度そのものです。ここが制限されていると、実質的にその開発会社から離れられなくなります。

譲渡の文言——27条・28条と著作者人格権の不行使がないと自由に改修できない

著作権を譲渡する場合でも、契約書に「著作権法第27条及び第28条の権利を含む」という記載がなければ、改変する権利(翻案権)と二次的著作物に関する権利は譲渡されないと推定されます。「著作権譲渡」と書いてあるのに、実は自由に改修できない契約書は珍しくありません。あわせて、譲渡できない著作者人格権(勝手に改変されない権利など)については「開発会社は著作者人格権を行使しない」という一文を入れるのが実務上の定番です。この2つがそろって初めて、将来自由に改修していける状態になります。

OSS・生成AIコード・特許・営業秘密・競業避止

現代の開発では、オープンソースソフトウェア(OSS)や生成AIが書いたコードが混ざるのが普通です。「著作権を発注者に譲渡」と契約してもOSS部分の権利は移らず、それぞれのライセンス(MIT・GPL等)に従って使う前提です。GPL系など改変・配布時に義務が生じるものもあるため、どのOSSを使ったかの部品表を受け取っておくと安心です。生成AIコードの権利の考え方はまだ発展途上で、少なくとも「第三者の権利を侵害していないことの保証」を契約に入れてもらうのが現実的です。当社もAIを活用した開発体制のため、この保証とレビュー体制は契約時にご確認いただいています。

特許権(特定のビジネスロジックが特許を受けている場合)と営業秘密(自社のビジネスロジックや顧客データ)は、著作権とは別に条項が要ります。「同じものを競合に売られないか」という不安には、全譲渡ではなく、範囲を限定した競業避止条項(「◯◯業界向けの△△機能は他社に提供しない」)を置く方法が合意されやすく、当社が契約交渉に立ち会う場面でもこの形に落ち着くことがほとんどです。「同様のシステムを提供しない」のような広い書き方は、開発会社の事業全体を縛るためまず合意されません。

費用とのバランス(表)と契約前チェックリスト

判断の基準は「将来、別の会社に改修を頼める状態にしておきたいか」です。契約前に、次を確認してください。著作権の帰属が書かれているか、27条・28条と人格権不行使の文言があるか、他社に改修を依頼できると明記されているか、ソースコード一式・手順書・設計書が納品物に含まれるか、汎用部品と個別実装の線引きがあるか、OSSの部品表とライセンスを確認したか、第三者の権利非侵害の保証があるか、開発会社が廃業しても継続できる状態か。稼働後に交渉すると費用も手間も膨らむ。契約時に決める、が教訓です。

起きるトラブルと、ラボ型・オフショア(準委任)で毎月生まれる成果物の帰属・引き渡しの決め方、当社の契約

権利を決めていないと何が起きるのか、そして請負の一括開発とは違う「準委任で毎月生まれる成果物」をどう扱うのか。上位の解説記事は請負の納品を前提にしたものが大半で、ラボ型やオフショアの継続開発の実務はあまり書かれていません。ここでは、トラブルの実例、準委任での決め方、海外の会社と契約するときの準拠法、当社の契約、今から交渉する場合の進め方を整理します。

起きるトラブル3つ——ソースコード未開示、他社改修が翻案権侵害、差止請求。廃業・音信不通のリスク

当社が相談を受ける中で代表的なトラブルは3つあります。1つ目はベンダー変更時のソースコード未開示で、新しい開発会社はゼロから作り直すか解析しながら作業するしかなく、コストが大幅に膨らみます。2つ目は改修費の高騰と「同意なしに変更できない」制約で、他社に改修を依頼すると元の開発会社から翻案権の侵害だと警告されるケースです。3つ目は、極端な場合、著作権者である開発会社がシステムの使用差止を請求できる法的根拠を持つことです。

これに加えて、開発会社が廃業したり音信不通になったりしたときのリスクも見落とせません。権利もソースコードも相手側にあると、会社が無くなった瞬間にシステムを触れる人が誰もいなくなる。いずれもその開発会社と付き合い続ける限りは表面化せず、担当者が辞めたとき、廃業したとき、条件が合わなくなって乗り換えたいときに問題になります。

私が2018年からホーチミンで約100社の相談を受けてきた中でも、「保守を別会社に移そうとしたら、ソースコードは渡せない、改修は著作権侵害だと言われた」という相談は繰り返し出てきます。契約書に著作権の記載がなかったケースがほとんどです。

準委任で毎月生まれる成果物はどう決めるか——月次の帰属、リポジトリ、契約終了時の一式引き渡し

ラボ型やODCは準委任契約で、納品という区切りがなく、成果物が毎週・毎月生まれ続けます。請負のように「検収完了後に譲渡」と書くだけでは、いつの時点のどこまでが発注者のものか曖昧になります。決めておくべきは4点です。

• 帰属のタイミング: 月次の稼働報告時、またはリリース時に、その期間に作成した成果物の著作権(27条・28条を含む)が発注者に帰属する旨を明記する
• リポジトリの置き場: Gitリポジトリを発注者側のアカウントに置くか、開発会社側に置く場合は発注者に常時のアクセス権を付与する。コードとドキュメントが常に発注者の手元にある状態を作る
• 契約終了時の引き渡し: ソースコード一式、設計書、環境構築とデプロイの手順書、使用ライブラリと外部サービスの一覧、アカウント情報を、終了時に引き渡す義務と協力の範囲を明記する
• 開発会社側の汎用部品: 開発会社がもともと持つ共通部品は留保のうえ利用許諾とし、個別実装は発注者に帰属させる線引きを書く

準委任は完成責任がない分、成果物が「自社の手元にある」状態を契約と運用で作ることが要注意です。毎週動くものが増えていく体制だからこそ、権利と現物の両方が常に発注者側にある形にしてください。

海外の会社と契約するときの準拠法と、当社の契約

オフショアで海外法人と直接契約すると、準拠法や裁判管轄が海外の法制度になることがあり、トラブル時の交渉や権利の主張が難しくなります。当社は日本国内の法人と日本法準拠で契約し、海外送金も不要です。契約書には、月の稼働と人数、増減員の条件に加えて、成果物の帰属と契約終了時の引き渡しを明記します。2,000名以上のIT人財データベースから直接アサインするため、再委託や多重下請けによる権利関係の複雑化も起きません。実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年・ブリッジSEで3,000USDと単価を公開し、1名から最短2週間で始められ、増員は約1週間、縮小と交代は1か月単位です。

開発はGitのプルリクエストで標準化し、日本人PMが設計レビューとコードレビューを行うため、コードとドキュメントは常に確認できる状態です。介護記録SaaS「CareViewer」や決済アプリの継続開発でも、成果物はリポジトリ単位で発注者が把握できる形で進めています。仕様書がない既存システムを引き継ぐ場合は、現状調査からお受けしています。

今から交渉するなら——契約更新・次の改修のタイミングで3点を取り決める

すでに稼働中のシステムで契約に権利の記載がない場合、まず現在の契約書と納品物を確認し、ソースコードが手元にあるかを把握してください。そのうえで、開発会社に著作権譲渡またはソースコードの納品・改修権・再許諾権の3点を追加で交渉します。稼働後の交渉は費用が発生しやすいため、次回の改修や保守契約の更新のタイミングで併せて取り決めるのが現実的です。あなたの契約書には、成果物の帰属と引き渡しが書かれているでしょうか。書かれていないなら、次の更新が交渉の機会です。

システム開発の著作権・知的財産でよくある質問

システム開発の知的財産について、発注者から相談の場で繰り返し聞かれる質問を5つにまとめました。契約書を確認する前の整理にお使いください。

Q1. 開発費を全額払えば、著作権も自社のものになりますか?

なりません。著作権は作った側(開発会社)に発生するのが原則で、契約書で「譲渡する」と定めて初めて移ります。支払いの有無とは別の問題です。譲渡なら「27条・28条の権利を含む」と「著作者人格権を行使しない」の文言も必要です。

Q2. 著作権の譲渡を断られたらどうすればよいですか?

ソースコードの納品、改修権(翻案権の許諾)、第三者への再許諾権の3点を利用許諾の範囲として契約書に明記してください。個別実装は譲渡、汎用部品は許諾という線引きも、開発会社が応じやすい形です。

Q3. ソースコードを納品してもらえば、著作権は気にしなくてよいですか?

いいえ。現物があっても著作権が開発会社に残っていれば、改変して使うには許諾が要る場合があります。「ソースコードの引き渡し」と「著作権の譲渡または改修権・再許諾権の許諾」の両方を契約に入れてください。

Q4. オープンソースを使った部分の権利はどうなりますか?

「著作権を発注者に譲渡」と契約してもOSS部分の権利は移らず、それぞれのライセンス(MIT・GPL等)に従います。どのOSSを使ったかの部品表を受け取り、GPL系など義務が生じるものがないか確認してください。

Q5. ラボ型(準委任)で毎月生まれるコードの権利はどうなりますか?

契約次第です。月次またはリリース時に成果物の著作権が発注者に帰属する旨、リポジトリへの常時アクセス、契約終了時の一式引き渡しを明記してください。当社は日本国内の法人と日本法準拠で契約し、帰属と引き渡しを契約書に書いています。権利と現物を常に手元に置く設計が、準委任の安心の土台。

まとめ: 権利は契約時にしか手を打てない——帰属・利用範囲・納品・汎用部品を決め、準委任なら月次帰属と引き渡しを書く

システム開発の著作権は、開発費を払った人ではなく作った人(開発会社)に発生します。プログラムは著作物で、コードが書かれた瞬間に開発会社に権利が生まれ、契約書で譲渡または利用許諾を定めない限り移りません。開発会社が権利を持ちたがるのにはライブラリの再利用とノウハウ保護という合理的な理由があり、全譲渡を求めると費用が上がるため、個別実装は譲渡・汎用部品は許諾・ソースコードは納品という線引きが現実的です。譲渡が難しくても、ソースコードの納品、改修権、第三者への再許諾権の3点を確保してください。ソースコードの現物と著作権は別物で、両方をそろえて初めて自社のシステムになります。

契約書で決めるのは、著作権の帰属、利用できる範囲(自社改修・他社への依頼)、ソースコードの納品(一式・手順書・ライブラリ一覧)、汎用部品の扱いの4項目です。譲渡なら「著作権法第27条及び第28条の権利を含む」と「著作者人格権を行使しない」の文言が要ります。OSSはライセンスに従い部品表を受け取り、生成AIコードは権利非侵害の保証を、ノウハウは範囲を限定した競業避止条項で守ります。

ラボ型・オフショア(準委任)では成果物が毎月生まれ続けるため、月次またはリリース時の帰属、リポジトリへの常時アクセス、契約終了時の一式引き渡し、開発会社側の汎用部品の許諾を明記してください。海外法人との直接契約は準拠法が海外になることがあり、当社は日本国内の法人と日本法準拠で契約し、帰属と引き渡しを契約書に書き、Gitでコードとドキュメントを常に確認できる状態で進めています。契約の基礎は業務委託契約とは、契約形態の違いは準委任と請負の違いもあわせてご覧ください。現在の契約と体制をお聞かせいただければ、権利と引き渡しの整理を含めた概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。契約の最終判断は弁護士にご確認ください。