OUTSOURCING

システム開発の成果物の著作権は誰のものか

システム開発で作られたプログラムの著作権は、契約で決めなければ原則として作った側に生まれます。著作権法の原則、譲渡の契約で27条・28条を特掲する理由、著作者人格権の扱い、汎用的な部品の扱いを、条文とIPAのモデル契約書に沿って整理します。

開発の発注と契約(OUTSOURCING)のコラム

この記事の要点

  • プログラムの著作権は、契約で決めなければ、原則として作った会社(開発会社)に生まれます
  • 著作権を譲り受ける契約では、27条・28条の権利をはっきり書いておかないと(特掲)、譲った側に残ると推定されます
  • 著作者人格権は譲渡できないため、行使しないことを契約で約束してもらう形がよく使われます

システム開発で作られたプログラムの著作権は、契約で何も決めていなければ、原則として作った側、つまり開発会社のものになります。発注者がお金を払ったからといって、自動的に発注者のものになるわけではありません。そのため、著作権をどちらが持つか、持たない側がどう使えるかを、契約書で決めておくことが大切です。

この記事では、著作権法の原則と、契約で決めるときの注意点を整理します。条文は、2026年11月時点で e-Gov 法令検索に掲載されている著作権法で確かめています。

出典:著作権法(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案汎用的に使えるプログラムなどは開発会社に、それ以外は発注者と開発会社の共有にする共有の部分は、どちらも相手への支払いなしで使え、第三者への利用の許諾もできる

どの案でも、持たない側が困らないように、使える範囲を契約で決めておく考え方です。どれを選ぶかは、改修をどこに頼む予定か、同じ仕組みを他社に売る予定があるか、などで変わります。

出典:情報システム・モデル取引・契約書(第二版)(IPA)

契約の前に確かめておきたいこと

著作権の扱いは、開発を始める前の契約で決めておくのが安全です。次の点を確かめておきます。

  • 著作権をどちらが持つか、移す場合はいつ移すか(検収の完了か、支払いの完了か)
  • 27条・28条の権利を含むことが書かれているか
  • 著作者人格権を行使しないことが書かれているか
  • 開発会社が前から持っている部品・汎用的な部品の扱いと、発注者が使える範囲
  • オープンソースのソフトウェアや他社の製品を組み込む場合の扱い
  • ソースコードと設計書を、納品物に含めるか

オープンソースのソフトウェアは、それぞれのライセンスの条件に従って使うもので、著作権を譲り受ける対象にはなりません。確かめ方はオープンソースのライセンスと、発注者が確かめることで説明しています。また、著作権を発注者が持っていても、ソースコードや設計書を受け取っていなければ、改修を別の会社に頼むのは難しくなります(ベンダーロックインを避けるには)。

本記事は、著作権の扱いを一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご相談ください。

当社のご支援

当社は、Webシステム開発やソリューション提供をお受けしています。ご依頼を検討いただく段階で、成果物の権利の扱いや納品物の範囲について気になる点があれば、お気軽にお尋ねください。他社とのいまの契約で、改修や引き継ぎに困らない形になっているかを確かめたい場合も、お問い合わせからご相談ください。

  • 著作権
  • 知的財産
  • 契約
  • 著作権法

この記事に出てくる用語

この記事を書いた人

石田 誠 グループCTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

あわせて読みたい

開発の発注と契約のコラムを見る コラムの一覧に戻る

無料で相談する無料の診断