システム開発を外注するときの著作権の決め方｜契約で外せない5つの項目

外注したシステムの著作権は、だれのものになるか

外注したシステムの著作権は、契約で決めない限り、プログラムを書いた開発会社のものです。

著作権は、作品を作った人に自動で生まれる権利です。システム開発では、プログラムを書いた会社が「作った側」になります。開発会社の社員が仕事として書いたプログラムは、原則としてその会社が著作者になります。

発注側が開発費を全額払っていても、それだけで著作権は移りません。お金を払うことと、権利を譲り受けることは、別の話として扱われます。

私は2022年から AI・システム開発の会社を経営し、開発会社として契約書を交わす側に立ってきました。開発会社の側から見ると、権利の条項は「書いていないことは、作った側に残る」という前提で読むものです。

「著作権を譲渡する」と書くだけでは足りない理由

「著作権を譲渡する」とだけ書いた契約では、システムを改変する権利が開発会社に残ると推定されます。

著作権法の第61条第2項は、譲渡の契約で第27条・第28条の権利が「譲渡の目的として特掲されていないときは」、これらの権利は譲渡した者に留保されたものと推定する、と定めています。

第27条は、翻案（作り変え）する権利です。第28条は、作り変えたもの（二次的著作物）を利用する権利です。システムでいえば、機能の追加や改修がこれにあたります。

つまり、改修して使い続けたいなら、契約書には「著作権（著作権法第27条及び第28条に規定する権利を含む）を譲渡する」と書く必要があります。たった一言の違いで、あとから改修の自由が失われることがあります。

権利の決め方は3つの型から選ぶ

著作権の決め方は、「発注側に移す」「開発会社に残して使わせてもらう」「部分ごとに分ける」の3つの型から選びます。

IPA のモデル契約書（第二版）でも、権利の帰属は1つに決め打ちせず、ベンダー（開発会社）に帰属させる案、汎用的なプログラムはベンダーに・それ以外は発注側に帰属させる案などの選択肢を示しています。第二版は2020年12月22日に公表されました。

どの型を選ぶかは、そのシステムを自社の事業の資産として持ち続けたいかで決まります。中核のシステムなら「発注側に移す」か「部分ごとに分ける」を選んでください。

契約で外せない5つの項目

契約書では、①権利の帰属、②著作者人格権、③ソースコードと設計書、④部品と再委託、⑤保守とデータの5つを必ず確かめてください。

5つのうち、あとから最も直しにくいのは③と④です。契約を交わしたあとに「ソースコードは渡せない」「その部分は下請けの権利だ」と言われると、交渉の余地がほとんどありません。

システム開発の進め方と、権利の決め方を相談する →要件の整理から、契約で決めておくことまで一緒に確認します。

よくある失敗例

権利の失敗は、契約の時点では気づかず、改修や会社の状況が変わったときに表に出ます。

権利の持ち主があいまいなシステムは、あとから改修を別の会社に頼むときや、保守の会社を替えるときに話が進みません。だれがどの権利を持っているかを一つずつ説明できる状態にしておくことが、システムを事業の資産として扱う前提です。

AI で書いたコードの権利はどう考えるか

AI が書いたコードに著作権が生まれるかは、人がどこまで創作的に関わったかで判断する、というのが文化庁の示している考え方です。

文化庁は、文化審議会の小委員会が2024年3月に取りまとめた「AIと著作権に関する考え方について」を公表しています。AI の生成物が著作物になるかは、指示の内容や、人が加えた修正などの創作的な関与の程度で個別に判断する、という整理です。

開発の現場では、AI で書いたコードと人が書いたコードが混ざることが増えています。そのため、契約では「成果物のうち AI で生成した部分も含めて、発注側が自由に利用・改変できる」ことを明記しておくと、あとで迷いません。

発注前に開発会社へ確かめる8つの質問

契約書の案を受け取る前に、次の8つを開発会社に質問すると、権利の考え方の違いを早い段階で見つけられます。

質問への答えが「契約書のひな形どおりです」だけで終わる場合は、そのひな形の該当する条文を見せてもらってください。答えにくそうな質問ほど、契約の前に決めておく価値があります。

質問の結果は、見積りと一緒に比べてください。見積りが安くても、権利が開発会社に残り、改修のたびに同じ会社に頼むしかないなら、使い続けるほど費用がかさみます。権利の条件は、見積りの金額と同じくらい比べる対象になります。