エンジニアが書いたコードの著作権は誰のもの?成果物の権利と契約で確かめる注意点

📘 この記事でわかること
- プログラムの著作権は原則実際につくった受注者に生じることと、発注者が納品後に利用するには契約であらかじめ定めが必要なこと
- 会社勤めで職務著作の要件を満たすと著作者が会社や国に変わることと、業務委託ではプログラム特有の公表要件の緩さに注意が要ること
- 契約書で著作権の帰属・譲渡・利用範囲・改変や表示の扱いを確かめる観点と、確かめたうえで安心して受注につなげる考え方
納品したコードの著作権が誰のものになるのか、契約の場面で確かめないまま案件を始めることがあります。プログラムも著作物のひとつで、権利は受注者と発注者のどちらに生じるのかが曖昧なまま進むと、後から利用の範囲でもめる原因にもなります。本記事では、著作権が生じる仕組みと、会社勤めと業務委託での扱いの違い、契約で確かめておきたい項目を、文化庁の資料に沿って整理します。権利を分かって契約できると、案件を安心して受注する材料になります。
1. コードを書くと、著作権は原則つくった受注者に生じます
案件で書いたコードの権利が、発注者と受注者のどちらにあるのかをはっきり意識しないまま作業を始めることがあります。著作権法では、コンピュータ・プログラムがプログラムの著作物として例示されています1。書いたコードが著作物にあたるという前提があるからこそ、権利が誰に生じるのかを起点に整理しておく意味があります。
特に、成果物の権利を明確にしないまま契約が進むと、納品後の利用や再委託の場面で認識のずれが表面化しやすくなります。案件を選ぶ前に、権利がどちらに生じ、どう移るのかという枠組みを知っておくと、契約書を読む速度も変わってきます。
プログラムは著作物にあたります
著作権法上、プログラムの著作物としてコンピュータ・プログラムが挙げられています1。設計書や仕様書だけでなく、実際に書いたコードそのものが著作物として扱われる対象になるということです。ここが出発点になるため、次に問われるのは「誰が実際にそのコードをつくったか」という点になります。
委託でも、実際に創作した受注者側が著作者になります
著作物の創作を委託した場合、料金を支払ったかどうかにかかわらず、実際に著作物を創作した受注者側が著作者となります2。発注者が費用を負担していても、それだけでは著作者にはなりません。「発注した側が権利を持つ」という思い込みよりも、「実際につくった側に権利が生じる」という原則のほうが、契約を読むときの起点として役立ちます。
契約前に確かめておきたい、著作者の当てはめ
ここまでの原則を、場面ごとに当てはめると次のようになります。受注者が実際にコードを書いた場合は、料金の支払いの有無にかかわらず受注者本人が著作者になります。一方で、会社勤めとして職務著作の要件を満たす場合は、著作者が会社や国など法人側に変わります。業務委託では、契約で権利の移転を定めない限り、著作者は実際に創作した受注者本人のままです。この違いを先に押さえておくと、後の章で扱う契約の確認項目がつかみやすくなります。
| 場面 | 実際に創作した人 | 著作者になるのは |
|---|---|---|
| 受注者がコードを書いて納品した場合 | 受注者本人 | 受注者本人 |
| 料金がまだ支払われていない場合 | 受注者本人 | 受注者本人(支払いの有無は関係ありません) |
| 会社勤めで職務著作の要件を満たす場合 | 法人に所属する人 | 会社や国など法人側 |
| 業務委託で契約による移転がある場合 | 受注者本人 | 契約で定めた移転先 |
出典:文化庁「著作権テキスト」(令和7年度版)をもとに作成
ただし、この原則がそのまま発注者の自由な利用を認めるわけではありません。発注者が納品後にそのコードを使うには、契約が要ります。
2. 発注者が使うには、契約が要ります
著作権が受注者に生じるという原則が分かると、次に気になるのは「では発注者はそのコードを使えないのか」という点です。実際には、契約によって使える範囲が決まります。ここでは、その仕組みを具体的に見ていきます。
納品後の利用には契約をあらかじめ交わします
著作権が受注者に生じるとはいえ、発注者が納品後にそのコードを使えなくなるわけではありません。発注者側が納品後にその著作物を利用するためには、そのための契約をあらかじめ交わしておくことが必要になります3。権利の帰属と、利用の可否は別の話だということです。
権利は自動では移りません
納品したという事実だけで、著作権や利用の許諾が自動的に発注者へ移るわけではありません。契約書に権利の扱いが書かれていなければ、発注者は「納品を受けた」という事実だけを手にしている状態にとどまります。ここを詰めずに進めると、後になって「どこまで使ってよいか」でもめる原因になります。損をするのは、契約を確かめなかった側です。
契約書に利用範囲の記載がない案件を受ける場合は、着手前に発注者へ確認しておくと、後になってからの認識の違いを防ぎやすくなります。契約を確かめずに進める受注よりも、条件を先に文章で残しておく受注のほうが、双方にとって扱いやすい関係になります。
出典:文化庁「著作権テキスト」(令和7年度版)をもとに作成
権利の扱いは契約で決まるという原則は、発注者と受注者の間の業務委託に当てはまるものです。一方で、会社勤めのときは扱いが変わります。
3. 会社勤めと業務委託で違う:職務著作
会社勤めと業務委託とでは、著作権の扱いに違いが生まれます。受注する立場からこの違いを理解しておくと、案件先の契約書に書かれている記載を、より正確に読み解けるようになります。
職務著作の要件を満たすと、会社等が著作者になります
会社勤めの場面では、業務委託とは違う原則が働きます。職務著作の要件を満たす場合には、創作した個人ではなく会社や国が著作者となる場合があります4。会社勤めとして組織の中でコードを書く立場と、業務委託として受注する立場とでは、権利の出発点そのものが変わるということです。
プログラムは公表要件が緩やかです
職務著作が成立するには、通常は法人名義で公表されていることが要件のひとつになります。ところが、プログラムの著作物は公表されないまま使われることもあり、法人名義での公表という職務著作の要件を満たす必要はありません5。社内で使うだけの、外部に公表しないコードであっても、会社勤めの職務著作にはあたり得るということです。
フリーランスとして受注する立場では、会社勤めの職務著作そのものに直接あたることは通常ありません。それでも、この違いを知っておく意味はあります。案件先の担当者が法人に所属するメンバーであるかどうかによって、成果物の権利がどちら側の原則で扱われているのかを見分ける材料になるからです。
会社勤めと業務委託を、権利の面で比べます
ここまでの内容を、会社勤めと業務委託とで比べると次のようになります。会社勤めで職務著作の要件を満たす場合は、著作者が会社や国など法人側になり、権利の移転を別途契約する必要は基本的にありません。業務委託では、著作者は実際に創作した受注者本人のままで、発注者が利用するには契約で移転を定めておく必要があります3。プログラムは公表の有無を問われにくいという点は、どちらの働き方でも共通する注意点です。
| 観点 | 会社勤め(職務著作の要件を満たす場合) | 業務委託 |
|---|---|---|
| 著作者になるのは | 会社や国など法人側 | 実際に創作した受注者本人 |
| 権利の移転 | 職務の中で法人に生じるため、別途の移転手続きは基本的に不要です | 契約であらかじめ移転を定める必要があります |
| 公表の要件 | プログラムは公表されないまま使われることがあります | 同様に、公表の有無は問われにくい領域です |
| 契約で確かめる点 | 職務の範囲や成果物の扱い | 帰属・譲渡・利用範囲 |
出典:文化庁「著作権テキスト」(令和7年度版)をもとに作成
会社勤めと業務委託とで著作者が変わり得ることが分かると、次に気になるのは「では、案件ではどこを確かめればよいか」という点です。だから案件では、契約で権利の扱いを確かめておく必要があります。
4. 案件で確かめる、権利の条項
ここまで、著作権が生じる原則と、会社勤めと業務委託の違いを見てきました。次に、実際の契約書でどこを確かめればよいのかを、具体的な項目に落として見ていきます。
著作権の帰属・譲渡と利用範囲
案件を受注するとき、契約書のどこを見れば権利の扱いが分かるのでしょうか。まず確かめたいのは、著作権の帰属です。受注者に権利が残るのか、発注者へ譲渡するのかで、その後の対応が変わります。次に、譲渡ではなく利用の許諾にとどまる場合は、どの範囲・期間・用途まで利用できるのかという利用範囲の記載を確かめます。
帰属が受注者に残るのか、発注者に移るのかによって、案件が終わった後にそのコードを別の場面で使えるかどうかも変わってきます。譲渡ではなく利用の許諾にとどめる契約のほうが、受注者にとっては後の自由度を残しやすい形になります。
改変や表示の扱い
契約によっては、納品後の改変や、氏名の表示方法についての取り決めが盛り込まれることもあります。ここは個別の契約内容によって扱いが分かれる部分であり、本記事で一律の答えを示すことはできません。気になる点があれば、契約の条文を確かめるか、専門家に相談する対応が望ましい領域です。
取り決めが契約書に見当たらない場合は、実務上どう扱われているのかを発注者にあらかじめ尋ねておくと、後からの相談がしやすくなります。
契約書で確かめておきたい4つの項目
ここまでの内容を、確かめる項目として整理すると次のようになります。著作権の帰属、譲渡の有無、利用範囲、改変や表示の扱いの4点です。契約書を読むときにこの4点を意識しておくと、権利の扱いが分からないまま案件を進めるという状態を避けやすくなります。すべてを一度に覚える必要はなく、契約書を開いたときにこの表を思い出せれば十分です。
| 確かめる項目 | 確認しておきたい内容 |
|---|---|
| 著作権の帰属 | 権利がどちらに生じ、どちらが持つ前提になっているかの記載 |
| 譲渡の有無 | 権利を譲渡するのか、利用を許諾するだけにとどまるのか |
| 利用範囲 | どの範囲・期間・用途まで利用できるかの記載 |
| 改変・表示の扱い | 改変や公表方法についての取り決め(個別の契約内容によって異なります) |
4点を毎回すべて質問する必要はありません。契約書に記載があるかどうかをまず確かめ、記載がない項目だけを尋ねる進め方でも十分です。自分で確かめて理解した契約のほうが、内容を把握しないまま進める契約よりも、後になって困る場面が少なくなります。
出典:文化庁「著作権テキスト」(令和7年度版)をもとに作成
契約条件を確かめながら、自分に合う案件を見る →
権利を分かって契約できることは、安心して受注する力になります。
5. 権利を分かって契約できると、安心して受注できます
確かめられる人は、トラブルを避けられます
契約書の帰属・譲渡・利用範囲を確かめる習慣があると、納品後に「どこまで使われるのか分からない」という不安を抱えたまま働くことが少なくなります。確かめる観点を持たない受注よりも、確かめてから受ける受注のほうが、後になってからの行き違いを避けやすくなります。
逆に、確かめないまま契約を交わすと、納品後に「著作権はどちらのものか」「別の案件で同じ実装を使ってよいか」といった疑問が後から浮かび、そのたびに確認の手間が発生します。先に確かめておくことは、後の手間を減らすことにもつながります。
リモート中心でも、契約は確かめられます
契約の確認は、対面でなければできないものではありません。契約書を読み、必要な点を質問し、合意してから着手するという流れは、リモート中心の働き方でも変わりません。Remoguでは、案件の90%以上がフルリモート可能です6。場所に縛られずに働きながら、権利の扱いが明確な条件で受注するという進め方も、選択肢のひとつになります。
権利の扱いが契約書で明確になっている案件かどうかは、着手前に確認できる情報のひとつです。案件を見比べる段階でこの観点を持っておくと、リモート中心の働き方でも、条件を自分で見極めながら受注先を選べるようになります。
まず登録して、権利の扱いが明確な案件の条件を確かめる →
権利の扱いを確かめてから受注するという進め方は、特別な知識がなくても始められます。まずは、自分の経験に合う案件にどんな条件が示されているかを見てみることが、次の一歩になります。
6. まとめ
ここまでの内容を振り返ります。契約前にこの流れを確かめておくと、案件を安心して受け止められるようになります。
- コードを書くと、著作権は原則として実際に創作した受注者に生じます。
- 発注者が納品後に利用するには、契約であらかじめ権利の扱いを交わしておく必要があります。
- 会社勤めで職務著作の要件を満たすと、著作者は会社や国など法人側に変わります。
- 契約では、帰属・譲渡・利用範囲・改変や表示の扱いの4点を確かめておくと安心です。
- 権利の扱いが明確な案件は、リモート中心でも安心して受注しやすくなります。
権利がどちらに生じ、契約でどう扱われるのかが分かると、案件を選ぶときの見え方が変わります。次に案件を探すときは、契約条件の記載を確かめながら、自分の経験に合う条件をRemoguで見てみることから始めてみましょう。
7. よくある質問
作ったコードの著作権は誰のものですか
著作権法では、コンピュータ・プログラムがプログラムの著作物として例示されています1。著作物の創作を委託した場合、料金を支払ったかどうかにかかわらず、実際に著作物を創作した受注者側が著作者となります2。案件でコードを書いた場合は、原則として受注者本人に著作権が生じます。実際に手を動かしてつくった人が著作者になるという原則は、料金の支払い状況や契約の呼び方が変わっても揺らぎません。
契約がないとどうなりますか
発注者側が納品後にその著作物を利用するためには、そのための契約をあらかじめ交わしておくことが必要になります3。契約で権利の扱いが定められていなければ、発注者は納品を受けたという事実だけを手にしている状態にとどまり、利用の範囲をめぐって行き違いが生じやすくなります。利用範囲や譲渡の有無が契約書に書かれていない場合は、着手前に発注者へ確認しておくと安心です。
会社勤めと業務委託でどう違いますか
職務著作の要件を満たす場合には、創作した個人ではなく会社や国が著作者となる場合があります4。会社勤めではこの職務著作にあたるかどうかが焦点になり、業務委託では、契約による移転がない限り、著作者は実際に創作した受注者本人のままです。案件の契約書に「職務著作」や「著作権の帰属」についての記載があるかどうかを見ておくと、扱いの違いを実務で見分けやすくなります。プログラムは公表されない場合があるため、この違いが契約書の文面だけでは見えにくいこともあります。
リモートの案件でも権利は確かめられますか
契約の確認は、対面でなければできないものではありません。契約書を読み、必要な点を質問してから合意するという進め方は、リモート中心の働き方でも変わりません。権利の扱いが明確な条件を確かめてから受注する進め方は、案件の探し方のひとつになります。権利の扱いを契約で確かめてから受注する進め方は、働く場所にかかわらず変わらない基本の手順です。契約書を読む力は、案件ごとに繰り返し使える技能でもあります。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
権利の扱いは契約によって変わります。まずは契約条件を確かめて選べるリモート案件が、いまどんな条件で並んでいるかを見てみてください。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 文化庁「著作権テキスト」(2025年)
*2 文化庁「著作権テキスト」(2025年)
*3 文化庁「著作権テキスト」(2025年)
*4 文化庁「著作権テキスト」(2025年)
*5 文化庁「著作権テキスト」(2025年)
*6 Remogu(株式会社LASSIC運営)公開情報:扱う案件の90%以上がフルリモート可能