
この記事の要点
- プログラムの著作権は、契約で決めなければ、原則として作った会社(開発会社)に生まれます
- 著作権を譲り受ける契約では、27条・28条の権利をはっきり書いておかないと(特掲)、譲った側に残ると推定されます
- 著作者人格権は譲渡できないため、行使しないことを契約で約束してもらう形がよく使われます
システム開発で作られたプログラムの著作権は、契約で何も決めていなければ、原則として作った側、つまり開発会社のものになります。発注者がお金を払ったからといって、自動的に発注者のものになるわけではありません。そのため、著作権をどちらが持つか、持たない側がどう使えるかを、契約書で決めておくことが大切です。
この記事では、著作権法の原則と、契約で決めるときの注意点を整理します。条文は、2026年11月時点で e-Gov 法令検索に掲載されている著作権法で確かめています。
プログラムは著作物として守られる
プログラムは、著作権法で守られる著作物です。著作権法10条は、著作物の例として「プログラムの著作物」を挙げています(第1項第9号)。
ただし、守られるのはプログラムの表現で、プログラムを書くために使う言語(プログラム言語)、その使い方の約束(規約)、指令の組み合わせの方法(解法)には及びません(10条第3項)。同じ処理を、別の書き方で書いたプログラムは、別の著作物になり得るということです。画面の設計書や仕様書などの文書も、内容によっては著作物になります。
著作権は、作った側に生まれる
著作権は、著作物を作った人(著作者)に、手続きなしで生まれます(17条第2項)。会社の発意にもとづいて、その会社の従業員が仕事として作ったプログラムは、作った時の契約や勤務規則に別の定めがなければ、その会社が著作者になります(15条第2項)。プログラムの場合は、会社の名前で公表するかどうかは問われません。
この2つを合わせると、開発会社の従業員が発注者のために作ったプログラムは、契約で別に決めていなければ、開発会社が著作者となり、著作権も開発会社が持つことになります。発注者に著作権を移したい場合は、契約で著作権を譲り受けることを決めておく必要があります。用語の説明は知的財産権の帰属にまとめています。
譲渡の契約では、27条・28条を書いておく
著作権を譲り受ける契約では、「著作権法27条及び28条の権利を含む」と書いておくことが大切です。61条第2項は、著作権を譲渡する契約で27条または28条の権利が譲渡の目的としてはっきり書かれていない(特掲されていない)ときは、これらの権利は譲った側に残ると推定する、と定めているためです。
27条の権利は、著作物を翻訳・変形・翻案する権利です。28条の権利は、元の著作物をもとに作られた二次的著作物の利用について、元の著作者が持つ権利です。プログラムでは、機能を足したり作り替えたりすることが翻案に当たり得るため、27条・28条の権利が開発会社に残ったままだと、発注者が自由に改修を進めにくくなるおそれがあります。
著作権を譲り受ける契約で、27条・28条の書き方による違い
- 27条・28条の権利を含むと書いた翻案などの権利も、譲渡の対象になる
- 書いていない27条・28条の権利は、譲った側に残ると推定される
権利が開発会社に残ったままだと、発注者が自由に改修を進めにくくなるおそれがあります。契約の判断は弁護士などの専門家にご確認ください
著作者人格権は、行使しないと約束してもらう
著作者には、著作権とは別に、著作者人格権があります。まだ公表していない著作物を公表する権利(公表権・18条)、名前を表示するかどうかを決める権利(氏名表示権・19条)、意に反して内容を変えられない権利(同一性保持権・20条)です。
著作者人格権は、著作者の一身に専属し、譲渡することができません(59条)。そのため、著作権を譲り受けても、著作者人格権は開発会社に残ります。実務では、開発会社が発注者や発注者の指定する者に対して著作者人格権を行使しないことを、契約で約束してもらう形がよく使われています。IPAの「情報システム・モデル取引・契約書」の条項例にも、著作者人格権を行使しないとする文言が入っています。
なお、同一性保持権については、特定のコンピューターで動かないプログラムを動くようにするため、またはより効果的に動かすために必要な改変には当てはまらない、という定めもあります(20条第2項第3号)。
汎用的な部品をどう扱うか
開発会社は、多くの案件で使い回す部品や、案件の前から持っているプログラムを組み込んで開発することがよくあります。こうした部品の著作権まで発注者に移すと、開発会社はほかの案件で同じ部品を使えなくなります。
IPAのモデル契約書は、納入物の著作権について、いくつかの案を示しています。
| 案 | 著作権の持ち方 | 持たない側の使い方 |
|---|---|---|
| A案 | 開発会社に残す(発注者や第三者が前から持っていたものを除く) | 発注者は、自ら使うために必要な範囲で複製・翻案できる |
| B案 | 汎用的に使えるプログラムなどは開発会社に、それ以外は委託料の支払いが終わった時に発注者に移す | 開発会社に残る部分は、発注者が自ら使うために必要な範囲で複製・翻案できる |
| C案 | 汎用的に使えるプログラムなどは開発会社に、それ以外は発注者と開発会社の共有にする | 共有の部分は、どちらも相手への支払いなしで使え、第三者への利用の許諾もできる |
どの案でも、持たない側が困らないように、使える範囲を契約で決めておく考え方です。どれを選ぶかは、改修をどこに頼む予定か、同じ仕組みを他社に売る予定があるか、などで変わります。
契約の前に確かめておきたいこと
著作権の扱いは、開発を始める前の契約で決めておくのが安全です。次の点を確かめておきます。
- 著作権をどちらが持つか、移す場合はいつ移すか(検収の完了か、支払いの完了か)
- 27条・28条の権利を含むことが書かれているか
- 著作者人格権を行使しないことが書かれているか
- 開発会社が前から持っている部品・汎用的な部品の扱いと、発注者が使える範囲
- オープンソースのソフトウェアや他社の製品を組み込む場合の扱い
- ソースコードと設計書を、納品物に含めるか
オープンソースのソフトウェアは、それぞれのライセンスの条件に従って使うもので、著作権を譲り受ける対象にはなりません。確かめ方はオープンソースのライセンスと、発注者が確かめることで説明しています。また、著作権を発注者が持っていても、ソースコードや設計書を受け取っていなければ、改修を別の会社に頼むのは難しくなります(ベンダーロックインを避けるには)。
本記事は、著作権の扱いを一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご相談ください。
当社のご支援
当社は、Webシステム開発やソリューション提供をお受けしています。ご依頼を検討いただく段階で、成果物の権利の扱いや納品物の範囲について気になる点があれば、お気軽にお尋ねください。他社とのいまの契約で、改修や引き継ぎに困らない形になっているかを確かめたい場合も、お問い合わせからご相談ください。
- 著作権
- 知的財産
- 契約
- 著作権法
この記事に出てくる用語
関連する法令・指針(参考情報)
- 法令
著作権法 第10条(著作物の例示)
著作物の例として、言語・音楽・美術などと並んで、プログラムの著作物を挙げています(第1項第9号)。プログラム言語・規約・解法には、この法律による保護は及びません(第3項)。
- 法令
著作権法 第15条(職務上作成する著作物の著作者)
法人などの発意にもとづき、その業務に従事する人が職務上作成するプログラムの著作物は、作成の時の契約や勤務規則などに別段の定めがなければ、その法人などが著作者になります(第2項)。
- 法令
著作権法 第17条(著作者の権利)
著作者は、著作者人格権と著作権を持ちます。これらの権利を持つために、登録などの手続きは要りません(第2項)。
- 法令
著作権法 第27条(翻訳権、翻案権等)
著作者は、著作物を翻訳・編曲・変形・脚色・映画化するなど、翻案する権利を専有します。著作権を譲渡する契約では、第61条第2項とあわせて扱いが問題になる権利です。
- 法令
著作権法 第28条(二次的著作物の利用に関する原著作者の権利)
元の著作物をもとに作られた二次的著作物の利用について、元の著作物の著作者は、二次的著作物の著作者と同じ種類の権利を持ちます。
- 法令
著作権法 第59条(著作者人格権の一身専属性)
著作者人格権は、著作者の一身に専属し、譲渡することができません。
- 法令
著作権法 第61条(著作権の譲渡)
著作権は、その全部または一部を譲渡できます。譲渡の契約で、第27条・第28条の権利を譲渡の目的として明記していないときは、これらの権利は譲渡した側に残ると推定されます(第2項)。
- 指針
独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」(第二版(2020年12月22日))
情報システムの受託開発(一部の企画を含む)と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。
法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは法令・指針の参考情報と凡例をご覧ください。
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。