外注したシステムのソースコードは誰のものか｜著作権の帰属と契約での決め方
開発費を払って外注したシステムなら、そのソースコードは当然自社のものだと考える発注者は少なくありません。しかし、著作権法の原則では、ソースコードの著作権は実際に作った側に生じます。契約で何も決めていなければ、費用を払ったかどうかに関係なく、著作権は開発会社に残ります。
普段は気にならなくても、別の開発会社に改修を頼みたい、システムを自社のサービスとして他社に提供したい、開発会社が事業をやめてしまった、といった場面で問題が表面化します。著作権が手元にないと、改修や再利用のたびに開発会社の許諾が必要になる場合があるためです。
一方で、著作権を発注側にすべて移すことが常に最善とは限りません。開発会社が以前から持っている部品や、どの案件でも使う汎用的なプログラムまで譲渡を求めると、開発会社はその部品を使えなくなり、見積もりが高くなったり、交渉がまとまらなかったりします。
この記事では、外注したシステムのソースコードの著作権が誰に帰属するのかという原則と、契約でどう決めるのが発注側にとって合理的かを、判断基準とともに解説します。
契約で決めなければ著作権は開発会社に残る
著作権法第10条第1項第9号は、プログラムを著作物の例として挙げています。ソースコードは、条件を満たせば著作物として保護されます。
著作者は実際に作った側
著作権法では、著作物を創作した者が著作者となり、著作権を持つのが原則です。会社の従業員が仕事として作ったプログラムについては、著作権法第15条第2項により、作成時の契約や勤務規則などに別段の定めがない限り、その会社が著作者になります（職務著作）。
つまり、開発会社の社員が書いたソースコードは、開発会社が著作者として著作権を持ちます。発注者が費用を払っていても、発注者は開発会社の従業員の使用者ではないため、職務著作の規定によって発注者に著作権が生じることはありません。開発会社が個人のフリーランスに作業を任せていた場合は、そのフリーランス個人に著作権が生じ、開発会社との契約で移転しているかどうかが問題になります。
著作権がなくても使うことはできる
著作権が開発会社に残っていても、発注者が納品されたシステムを使えないわけではありません。著作権法第47条の3は、プログラムの複製物の所有者が、自らコンピュータで実行するために必要な限度で複製できると定めています。契約書でも、通常は発注者がシステムを利用できることが前提になっています。
問題になるのは、利用の範囲を超える場面です。たとえば、別の開発会社に依頼してソースコードを大きく改修する、システムを自社の商品として他社に販売・提供する、といった行為には、著作権者の許諾が必要になる場合があります。契約で著作権の扱いを決めておくのは、こうした将来の選択肢を確保するためです。
著作権を譲渡するときの三つの落とし穴
契約書に「成果物の著作権は発注者に帰属する」と一行書いてあれば安心、というわけではありません。著作権の譲渡には、書き方によって効果が変わる点がいくつかあります。
翻案権などを明記しないと移らないと推定される
著作権法第61条第2項は、著作権を譲渡する契約で、第27条（翻訳権、翻案権等）と第28条（二次的著作物の利用に関する権利）が譲渡の対象として特に明記されていない場合、これらの権利は譲渡した側に残ると推定する、と定めています。
ソースコードを改修して新しいバージョンを作ることは、翻案にあたる場合があります。「著作権を譲渡する」とだけ書いた契約では、改修に関わる権利が開発会社に残っていると推定されるおそれがあるため、「著作権（著作権法第27条及び第28条の権利を含む）」と明記するのが一般的です。
著作者人格権は譲渡できない
著作権とは別に、著作者には著作者人格権があります。著作権法第59条により、著作者人格権は著作者だけに属し、譲渡できません。このうち同一性保持権（第20条）は、著作物を意に反して改変されない権利です。
プログラムについては、特定のコンピュータで実行できるようにするための改変や、より効果的に実行できるようにするための改変は、同一性保持権の例外とされています（第20条第2項第3号）。ただし、機能追加のような改変がすべて例外にあたるとは限らないため、契約書で「受注者は著作者人格権を行使しない」と定めておくのが実務上の対応です。
移転の時期と、移転しない部分
著作権が移る時期も確認が必要です。「委託料の支払完了時に移転する」と定めるのが一般的で、支払いが分割の場合は、最後の支払いまで著作権は開発会社に残ります。
また、開発会社が以前から持っていたプログラムや、多くの案件で使う汎用的な部品、第三者のライブラリは、譲渡の対象から除かれるのが通常です。どこまでが「新たに作った部分」で、どこからが「既存の部品」なのかが契約書で分からないと、後で争いになります。
実務では、契約書の別紙や納品物の一覧に、開発会社が持ち込む既存の部品や、利用する第三者のライブラリを列挙してもらう方法がよく取られます。一覧があれば、移転の対象とそうでない部分の境目が明確になり、将来の改修や他社への引き継ぎの際にも判断の根拠になります。
著作権の帰属の決め方のパターン
独立行政法人情報処理推進機構（IPA）と経済産業省の「情報システム・モデル取引・契約書」（第二版）は、納入物の著作権について三つの選択肢を示しています。
| パターン | 内容 | 発注者ができること |
|---|---|---|
| A案（開発会社に帰属） | 発注者や第三者が従前から持っていたものを除き、著作権はすべて開発会社に帰属する | 自ら実行するために必要な限度での複製・翻案。改修や他社提供には許諾が必要になる場合がある |
| B案（汎用部分を除き発注者に移転） | 開発会社や第三者が従前から持っていたもの、汎用的に利用できるプログラムを除き、委託料の完済時に著作権が発注者に移る | 移転した部分は自由に改修・利用できる。汎用部分は利用の範囲で使える |
| C案（汎用部分を除き共有） | 新たに生じたプログラムの著作権を、汎用的なプログラムを除き、発注者と開発会社の共有（持分均等）とする | 双方が相手に対価を払わずに、第三者への利用許諾も含めて行使できる |
B案とC案では、条文の中で著作権法第27条・第28条の権利を含むことが明記され、開発会社が著作者人格権を行使しない旨も定められています。著作権の移転の対価は委託料に含まれるものとされています。
このほか、著作権は開発会社に残したまま、発注者に広い範囲の利用許諾（ライセンス）を与える方法もあります。改修や第三者への提供まで許諾の範囲に入れれば、実務上は譲渡に近い自由度を確保できます。ただし、許諾は契約関係を前提にしているため、許諾の範囲、期間、対価、開発会社の事業が終わった場合の扱いまで書いておく必要があります。
共有にする場合は注意点があります。共有の著作権は、原則として共有者全員の合意がなければ行使できません（著作権法第65条第2項）。C案のように、各自が単独で利用・許諾できることを契約で明記しておかないと、かえって身動きが取れなくなります。
参考：情報システム・モデル取引・契約書（第二版）／IPA（情報処理推進機構）
自社に合う決め方を選ぶ判断基準
どのパターンが適切かは、システムを将来どう扱いたいかによって変わります。次の基準で整理すると判断しやすくなります。
| 将来の扱い | 選び方の目安 |
|---|---|
| システムを自社の商品やサービスとして他社に提供する | 発注者への移転（B案）が基本。既存部品の利用許諾の範囲に、第三者への提供を含める |
| 将来、別の開発会社や社内チームで改修したい | 発注者への移転か、改修を含む広い利用許諾。翻案権の扱いを必ず明記する |
| 業務で使うだけで、改修は同じ開発会社に任せる予定 | 開発会社への帰属に、利用の範囲を明確にした許諾を組み合わせる方法でも足りる場合がある |
| 開発会社のパッケージやフレームワークを土台にしている | 土台部分は開発会社に残るのが通常。追加開発部分の扱いと、土台部分の利用条件を分けて決める |
| 業務ノウハウが詰まっていて、競合に使われたくない | 移転に加え、秘密保持や同種システムへの転用制限を別途定める |
判断で迷うのは、「念のためすべて移転してほしい」と考えたときです。開発会社が汎用的な部品まで渡すと、他の案件でその部品を使えなくなるため、見積額が上がったり、移転の範囲を巡って交渉が長引いたりします。発注側にとって本当に必要なのは、多くの場合「自社の業務に固有の部分を自由に改修・利用できること」です。汎用部品は開発会社に残し、その部品を含めてシステムを使い続け、改修できる許諾を得るという形で、必要な自由度を確保できることが多いでしょう。
著作権法第10条第3項は、プログラム言語、規約、解法（アルゴリズム）は著作権の保護が及ばないとしています。著作権で守れるのはソースコードの具体的な表現であり、業務の仕組みや処理の考え方そのものではありません。ノウハウを守りたい場合は、著作権ではなく秘密保持の条項で手当てすることになります。
もう一つ考えておきたいのが、開発会社との関係が終わる場合です。著作権を移転していても、最新のソースコードが手元になければ、別の会社に改修を頼むことはできません。開発会社が管理するリポジトリにしかコードがない状態は避け、リリースのたびに最新のソースコードと設計資料を受け取る、または発注側が管理するリポジトリで開発してもらうといった取り決めをしておくと、権利の面と実務の面の両方で選択肢を確保できます。
著作権とあわせて確認したいこと
著作権の帰属を決めても、それだけでは改修や引き継ぎができないことがあります。著作権の条項とあわせて、次の点を契約書や納品物の一覧で確認してください。
- ソースコードそのものが納品物に含まれているか（実行ファイルだけの納品になっていないか）
- 設計書、データベースの定義、ビルドや環境構築の手順書が納品物に含まれているか
- 利用しているオープンソースソフトウェア（OSS）の一覧と、それぞれのライセンス条件
- 開発会社が外部に作業を任せた部分の権利が、開発会社にきちんと移っているか
- 生成AIを使って書いたコードの扱いについて、取り決めがあるか
OSSは、著作権を発注者に移す対象にはなりません。OSSの著作権は元の作者に残り、ライセンス条件に従って利用することになります。ライセンスによっては、改変したソースコードの公開を求められるものもあるため、システムを他社に提供する予定がある場合は特に、利用しているOSSのライセンスを確認する責任を誰が負うのかを決めておきましょう。
生成AIで作ったコードの著作物性について、文化審議会著作権分科会法制度小委員会が2024年3月にまとめた「AIと著作権に関する考え方について」では、人間の創作的寄与があればAI生成物も著作物と認められうるとの考え方が示されています。どこまでが著作物にあたるかは個別の判断になるため、契約では「生成AIを利用した成果物も、他の成果物と同様に扱う」「利用するAIサービスの規約上の制約を開発会社が確認する」といった形で、扱いを揃えておくのが現実的です。
開発会社の再委託先が作った部分にも注意が必要です。再委託先がフリーランスの場合、その人に生じた著作権が開発会社に移っていなければ、開発会社は発注者に移転できません。重要なシステムでは、再委託先との契約で権利が開発会社に移転していることを確認しておくと安心です。
参考：AIと著作権に関する考え方について／文化庁（文化審議会著作権分科会法制度小委員会）
まとめ
外注したシステムのソースコードの著作権は、契約で何も決めなければ、実際に作った開発会社に残ります。発注者は納品されたシステムを使うことはできますが、別の会社での改修や他社への提供には、著作権者の許諾が必要になる場合があります。
著作権を移す場合は、翻案権など著作権法第27条・第28条の権利を含むことの明記、著作者人格権を行使しない旨の定め、移転の時期、移転しない既存部品の範囲を確認してください。すべての移転を求めるより、自社固有の部分を移転し、汎用部品は利用許諾で使う形の方が、費用と交渉の面で現実的な場合が多くあります。
これから発注する案件があれば、まず「このシステムを将来、他社に提供するか」「別の会社で改修する可能性があるか」の二点を社内で決めてください。そのうえで、契約書の著作権条項と納品物の一覧を照らし合わせれば、自社に必要な権利が確保されているかを判断できます。