「お金を払って納品されたのだから、成果物はもう自社のもの」——業務委託で外部のフリーランスや制作会社に発注している担当者の多くが、無意識にこう考えています。ところが著作権法の世界では、この感覚は通用しません。報酬を支払い、納品を受けただけでは、著作権は発注者に移らないのが原則です。
さらにやっかいなのは、発注者のリスクが「権利をちゃんともらえるか」だけにとどまらない点です。受託者が他人の作品や素材、コードを流用していた場合、それを公表・利用する発注者自身が、権利者から責任を問われることがあります。「外注したのだから自社は関係ない」とはならないのです。
とはいえ、法務専任部署のない中小・中堅企業の担当者にとって、著作権法の条文を一つひとつ読み解くのは現実的ではありません。本当に知りたいのは「業務委託の著作権で、発注者として何に気をつければいいのか」という勘所と、「契約書のどこを見ればトラブルを防げるのか」という具体的な点検ポイントのはずです。
そこで本記事では、発注者が著作権でつまずく注意点を、発注前→契約→検収→公表・利用→再利用という発注プロセスの時系列に沿って整理します。条文の網羅でも単一論点の深掘りでもなく、「自社のどの段階を点検すべきか」が分かる地図として読み進めてください。なお、著作権を確実に「取得する」ための帰属判定や契約条項の細部については、姉妹記事業務委託の著作権帰属｜準委任・請負別の判定と確実に取得する契約条項で詳しく扱っているため、本記事は注意点の全体像に紙幅を集中します。
業務委託の著作権で発注者がつまずく理由｜注意点の全体像
最初に、なぜ発注者が著作権でつまずくのか、その構造を押さえておきましょう。ここが理解できると、以降の各段階の注意点が「自社のどこを点検すべきか」という具体的な課題に変わります。
「納品されたら著作権もこちらのもの」が成り立たない理由
著作権は、作品を創作した人（受託者）にその時点で自動的に発生し、原始的に帰属します。これを原始帰属の原則と呼びます。重要なのは、発注者が報酬を支払っても、成果物の納品を受けても、それだけでは著作権は移転しないという点です。著作権を発注者のものにするには、契約のなかで明確に「譲渡する」と取り決めておく必要があります。
つまり「お金を払った＝こちらのもの」は、所有権の感覚であって著作権の話ではありません。納品されたデータやファイルという「現物」は手元にあっても、それを改修したり二次利用したりする「権利」は受託者に残ったまま、という状態が起こりうるのです。この前提を取り違えると、後述する再利用や乗り換えの段階で「権利が足りない」という事態に直面します。
発注者の注意点は「取得側」と「侵害を負わされる側」の2方向ある
発注者がつまずく注意点は、大きく2つの方向に分けて捉えると整理しやすくなります。
ひとつは「もらった著作権をちゃんと使えるか」という取得側のリスクです。譲渡条項が抜けていて権利が手に入らない、人格権の問題で改変が止まる、といった落とし穴がここに含まれます。
もうひとつが、見落とされがちな「自社が誰かの権利を侵害して責任を負わされないか」という侵害側のリスクです。受託者が他人の著作物を流用していた、納品コードにライセンス違反のOSSが混入していた——こうしたケースで、成果物を公表・利用する発注者が責任を問われることがあります。
この2方向を、発注前・契約・検収・公表・再利用という時系列の各段階で点検していく、というのが本記事の読み方です。次の章から、段階ごとの具体的な注意点を見ていきましょう。
【発注前の注意点】受託者選定と成果物の「出所」を確認する
トラブルの芽は、契約を結ぶより前の受託者選定の段階ですでに生まれています。多くの記事が契約条文から解説を始めますが、発注者の行動としては、その前に確認できることがあります。
出所不明の素材・コードが紛れ込むリスクと事前確認項目
受託者が制作物に使う画像・フォント・イラスト・コード・デザインの「出所」が不明確だと、後の工程で第三者の著作物や規約違反の素材が紛れ込むリスクが高まります。出所が曖昧な受託者に発注してしまうと、検収や公表の段階になってから侵害リスクが顕在化し、対応コストがふくらみます。
発注前のヒアリングや実績確認の際に、次のような点を確認しておくと予防になります。
- 過去の制作物について、使用素材やコードの権利処理をどのように行っているか
- ストック素材やフォントを使う場合、商用利用可能なライセンスを取得しているか
- オープンソースソフトウェア（OSS）や生成AIをどの程度・どのように利用する方針か
- 制作物に第三者の権利を侵害しないことを保証してもらえるか
完璧な調査をする必要はありません。発注前に出所への意識を共有しておくだけでも、後工程のリスクは大きく下がります。
再委託・外注がある場合に発注前に確認すべきこと
受託者がさらに別のフリーランスや下請けに作業を再委託しているケースもあります。この場合、実際に手を動かした人と、契約相手である受託者が別人になり、権利関係が一段複雑になります。再委託先が権利処理を怠れば、その影響は最終的に発注者にまで及びます。
発注前には、再委託・外注の有無と、再委託する場合に受託者がその成果物の権利を適切に取得して発注者に引き渡せる体制になっているかを確認しておきましょう。再委託を認めるかどうか、認める場合の条件は、後述する契約の段階で明文化しておくと安心です。
【契約時の注意点】最低限おさえる著作権条項とよくある抜け
契約書は、著作権リスクへの備えがもっとも凝縮される場所です。ここでは深掘りはせず、発注者が「最低限おさえるべき点」と「テンプレ流用で抜けやすい点」に絞って整理します。条項設計や帰属判定の詳細は、姉妹記事業務委託の著作権帰属に譲ります。
譲渡条項・27条/28条の特掲・人格権不行使の3点（取得を確実にする最低ライン）
成果物の著作権を確実に自社のものにするために、契約で最低限おさえたいのが次の3点です。いずれも「なぜ必要か」とセットで理解すると、抜けに気づきやすくなります。
- 著作権の譲渡条項：著作権を受託者から発注者へ譲渡することと、譲渡される時期（対価の支払時か、納品時か）を明記します。これがなければ、報酬を払っても権利は受託者に残ります。
- 27条・28条の特掲：著作権法では、翻案権（27条）と二次的著作物の利用に関する権利（28条）は、契約で「これらの権利も含めて譲渡する」と特掲しないと、譲渡対象から外れたと推定されます。特掲がないと、後で成果物を改修・改変・二次利用しようとしたときに権利が足りなくなります。
- 著作者人格権の不行使特約：著作者人格権（公表権・氏名表示権・同一性保持権）は譲渡できない権利です。特に同一性保持権は「作品を勝手に改変されない権利」で、不行使の特約がないと、改修・改変の場面で受託者の同意が必要になり、改変が止まりうる点に注意が必要です。
第三者の権利非侵害の表明保証と補償条項（侵害リスクへの備え）
取得を確実にする3点に加えて、発注者を守るうえで欠かせないのが、侵害リスクへの契約上の備えです。具体的には次の2つです。
- 表明保証：成果物が第三者の著作権その他の権利を侵害していないことを、受託者に保証してもらう条項です。
- 補償（インデムニティ）条項：万一、第三者から権利侵害の主張を受けて発注者が紛争に巻き込まれた場合、その解決費用や損害を受託者が負担することを定める条項です。
委託先に成果物が第三者の権利を侵害しないことを保証してもらい、権利侵害の紛争に巻き込まれた際の解決費用を委託先が負担すると定めておくことは、発注者の予防手段として重要とされています（著作権のネタ帳）。これらが、のちほど解説する「第三者侵害の責任が発注者に跳ね返る」リスクへの主要な備えになります。
テンプレ流用で抜けやすい注意点
契約書をテンプレートから流用していると、案件の実態と条項がかみ合わず、権利処理が抜けることがあります。よくあるのが、準委任契約（成果物の完成ではなく業務の遂行を約束する契約）のテンプレに、成果物の著作権処理の規定が含まれていないケースです。準委任でも成果物が生まれる以上、譲渡条項を補わないと権利が受託者に残ります。
このほか、再委託に関する規定、納品物の範囲（ソースコードや元データを含むか）、検収の方法といった点も、テンプレでは曖昧なまま放置されがちです。テンプレをそのまま使うのではなく、自社の案件に当てはめて「この契約で抜けている処理はないか」を一度点検することをおすすめします。
【検収時の注意点】盗用・OSS・生成AIコードの混入を見抜く
成果物を受け取る検収の段階は、侵害リスクを水際で止められる最後のチャンスです。ところが、ここをすり抜けて納品物がそのまま公表・利用されてしまう事例が少なくありません。発注者がつまずきやすい3つの混入リスクを見ていきます。
盗用・剽窃・素材規約違反の検収チェック
第一に、他社の著作物やストック素材を無断で流用したもの、ライセンス規約に違反した素材が、成果物に紛れていないかを確認します。デザインやコンテンツでは、他社の作品に酷似していないか、使用素材のライセンスが商用利用・利用範囲を満たしているかが論点になります。
すべてを完璧に検査するのは難しいものの、デザインの類似や素材の出所について、納品時に受託者へ確認し、その回答を記録に残しておくだけでもリスクは下がります。委託先に制作物の作成経過を確認し、確認した経過を証拠化しておくことが予防手段になるとされています（著作権のネタ帳）。
OSS混入リスク（GPL伝搬・ソース公開義務）と検収・契約での手当て
ソフトウェアやアプリの開発委託で特に注意したいのが、納品コードへのOSS（オープンソースソフトウェア）の混入です。OSSは便利な反面、それぞれにライセンス条件があり、条件に違反した利用は著作権侵害になりえます。納品物に混入したOSSがライセンス条件に違反していると、著作権者やOSS団体から責任追及を受けるおそれがあります（IT法務.COM（弁護士法人内田・鮫島法律事務所））。
なかでもGPLのような「伝搬性」の強いライセンスは要注意です。GPLが適用されたOSSを組み込むと、自社のために開発してもらったプログラムまでGPLの派生物とみなされ、その一部のモジュールがソースコードの公開義務を負ってしまう、という事態が起こりえます（IT法務.COM）。社外秘のはずのコードを公開せざるをえなくなるリスクがあるわけです。
発注者が混入を把握しないまま納品されるケースがあるため、対策は検収と契約の二段構えが有効です。検収段階では、出荷・公開前に利用OSSのライセンスを遵守できているか（著作権表示、ソースコードの入手方法の通知など）をチェックします（IT法務.COM）。契約段階では、使用するOSSについて事前承認を得る義務や、利用OSSのリスト提出義務を受託者に課す方策が考えられます（IT法務.COM）。
生成AIコード・成果物の権利と侵害リスク（発注者視点の確認）
近年は、受託者が生成AIを使ってコードやコンテンツを作成するケースも増えています。生成AIによる成果物には、いくつかの不確実性が残ります。AIの学習データに由来する第三者の権利侵害が生じる可能性、そしてAIが自動生成した部分の著作物性（そもそも著作権が発生するのか）といった論点です。
発注者としては、受託者が生成AIをどの範囲で利用したか、生成物について第三者の権利を侵害しないことを保証できるかを、検収・契約の段階で確認しておくと安心です。生成AIコードの権利・侵害をどう確認するかの具体的な観点は、受託者向けの内容ではありますがAIコード著作権リスクを防ぐ実務チェックリストも参考になります。発注者視点では「誰がどう作ったか」を申告・合意してもらうことが、後のトラブルを避ける第一歩です。
【公表・利用時の注意点】第三者侵害の責任が発注者に跳ね返る
ここが、発注者がもっとも見落としやすく、かつ切実なリスクです。「外注先のミスなのに、なぜ自社が責任を負うのか」と感じるかもしれませんが、そうなりうる構造を理解しておくことが、自社を守るうえで欠かせません。
なぜ受託者の侵害が発注者の責任になるのか（公表者・利用者の責任）
受託者が他人の著作物・素材を流用していた成果物を、発注者が自社の名義で公表・利用すると、その公表・利用という行為自体が著作権侵害となりえます。著作権侵害に対して権利者は、侵害行為の差止めや損害賠償を請求できますが（特許庁）、その矛先はまず、世の中に向けて公表している発注者に向かいやすいのです。
委託先に制作物を委託した場合でも、その制作物が第三者の著作権を侵害しており第三者から責任追及を受けたときは、第三者との関係では「委託先のせい」にして責任を免れることは通常できないとされています（著作権のネタ帳）。また、デザインを検証せずに利用してしまうと、発注者に注意義務違反が認められるリスクも指摘されています。「外注したから自社は無関係」という発想は通用しない、と理解しておきましょう。
表明保証・補償条項でリスクを配分する（限界も含めて）
この侵害リスクを受託者へ適切に配分する契約上の手段が、契約時の章で触れた表明保証と補償（インデムニティ）条項です。第三者の権利を侵害していないことを受託者に保証させ、侵害紛争が起きた場合の解決費用を受託者に負担させることで、最終的な損失を受託者側に求めやすくなります。
ただし、これらの条項には限界もあります。第一に、権利者との関係では、契約があっても発注者が侵害の主体として一次対応（公表停止・差止め対応など）を迫られる点は変わりません。第二に、受託者に資力がなければ、補償条項があっても実際の費用回収は困難です。つまり、契約での備えは万能ではなく、前章の検収で混入を未然に防ぐことと組み合わせた二段構えが重要になります。契約と検収の両輪で、初めてリスクを実効的に下げられるのです。
著作者人格権（同一性保持権）で改変・改修が止まる注意点
公表・利用の場面でもうひとつ見落とされがちなのが、著作者人格権の問題です。著作権（財産権）を譲り受けても、著作者人格権は受託者本人に残り続けます。これは譲渡できない権利だからです。
なかでも同一性保持権は、作品を意に反して改変されない権利です。たとえばデザインの一部を後から修正したい、システムを改修したいといった場面で、人格権の不行使特約を結んでいないと、受託者が同一性保持権を理由に改変へ同意しないことがあり、改変・改修が止まりうるのです。「権利は全部もらったはず」と思っていても、人格権の手当てが抜けていると後で動けなくなる——これが、もらった後に顕在化する典型的な落とし穴です。
【再利用・乗り換え時の注意点】後で使えない・改修できないを防ぐ
成果物は、納品されて終わりではありません。後から改修したい、別の用途に二次利用したい、別のベンダーへ引き継ぎたい——こうした再利用のフェーズで初めて顕在化する落とし穴があります。時系列の締めとして整理します。
改修・二次利用・乗り換えで権利が足りなくなるパターン
再利用の段階で「権利が足りない」と気づく典型的なパターンは、これまでの各章で触れてきた抜けが原因です。
- 27条・28条の特掲が譲渡対象から漏れていて、改修や二次利用ができない
- 人格権の不行使特約がなく、改変をめぐって受託者と揉める
- 複数のフリーランスが関わった成果物で、一部の人の権利が残っており、全員の同意が得られず再利用が止まる
特に複数人が関わった成果物は、共同著作物として全員の同意が必要になる場面があり、権利関係が複雑です。誰がどの部分を作り、その権利がどう処理されているかを発注時から整理しておくことが大切になります。複数関与のケースの詳しい考え方は、姉妹記事業務委託の著作権帰属で扱っています。
著作権の譲渡と現物（ソース・アカウント）の引渡しは別物
最後に、見落とされやすい実務上のポイントです。著作権という「権利」を譲り受けることと、ソースコード・元データ・各種アカウントといった「現物」を引き渡してもらうことは、別の話です。
権利はあっても、ソースコードや編集可能な元データが手元になければ、実際には改修も乗り換えもできません。逆に、現物だけ受け取って権利処理が済んでいなければ、使えるようでいて法的には使えない、という事態に陥ります。乗り換えを見越して、契約・納品の段階で「権利」と「現物（ソース・元データ・アカウント情報）」の両方を確保することを取り決めておきましょう。
業務委託の著作権 注意点チェックリスト（時系列まとめ）
ここまでの注意点を、自社の発注プロセスに当てて点検できるよう、段階別のチェックリストにまとめます。すべてに完璧に対応する必要はありませんが、抜けている段階があれば優先的に手当てを検討してください。
発注前
- 受託者が使用素材・コード・デザインの出所と権利処理をどう管理しているか確認した
- OSS・生成AIの利用方針を確認した
- 再委託・外注の有無と、その場合の権利処理体制を確認した
契約時
- 著作権の譲渡条項と譲渡時期を明記した
- 27条・28条の特掲を入れた（改修・二次利用に備える）
- 著作者人格権の不行使特約を入れた（改変に備える）
- 第三者の権利非侵害の表明保証と補償（インデムニティ）条項を入れた
- 準委任テンプレ等で権利処理が抜けていないか点検した
検収時
- 盗用・剽窃・素材の規約違反がないか確認・記録した
- OSSの混入（特にGPL等の伝搬性ライセンス）をチェックし、利用OSSの申告を受けた
- 生成AIの利用範囲と非侵害の保証を確認した
公表・利用時
- 公表前に成果物が第三者の権利を侵害していないか最終確認した
- 同一性保持権（人格権）の手当て（不行使特約）が済んでいるか確認した
再利用・乗り換え時
- 改修・二次利用に必要な権利（27条・28条）が揃っているか確認した
- 著作権の譲渡だけでなく、ソース・元データ・アカウントの現物引渡しを確保した
帰属判定や契約条項の細部をさらに詰めたい場合は、姉妹記事業務委託の著作権帰属を参照してください。
よくある質問（FAQ）
Q. 業務委託で納品された成果物が他社の著作物に似ていた場合、発注者も責任を負いますか？
負う可能性があります。受託者が他人の著作物を流用していても、それを自社名義で公表・利用する発注者は、侵害の主体として差止めや損害賠償を求められうるためです。第三者との関係で「委託先のせい」にして責任を免れることは通常できないとされています（著作権のネタ帳）。検収での確認と、契約での表明保証・補償条項による備えが重要です。
Q. 著作権を譲り受けていれば、成果物を自由に改修・二次利用できますか？
必ずしもできません。翻案権（27条）と二次的著作物の利用に関する権利（28条）は、契約で特掲しないと譲渡対象から外れたと推定されます。また、著作者人格権（同一性保持権）は譲渡できないため、不行使特約がないと改変に受託者の同意が必要になり、改修が止まることがあります。
Q. 納品されたコードにOSSが混入していたら、発注者にどんなリスクがありますか？
ライセンス違反による著作権侵害の責任追及を受けるおそれがあります。特にGPLのような伝搬性の強いライセンスが混入すると、自社のために開発したプログラムまでソースコードの公開義務を負う事態が起こりえます（IT法務.COM）。検収でのライセンスチェックと、契約での事前承認・OSSリスト提出義務が有効です。
Q. 生成AIで作られた成果物の著作権はどう扱えばよいですか？
学習データ由来の第三者侵害の可能性や、AI生成部分の著作物性など、不確実な論点が残ります。発注者としては、受託者に生成AIの利用範囲を申告してもらい、第三者の権利を侵害しないことを保証できるかを検収・契約段階で確認しておくと安心です。
Q. 契約書に著作権の記載がない場合、納品済みの成果物は使えないのですか？
著作権は受託者に残ったままになるため、改修・二次利用などの行為には制約が生じる可能性があります。現物のデータは手元にあっても、それを加工・再配布する権利が伴わない状態です。後からでも譲渡の合意書を交わすなど、権利処理を補うことを検討してください。
Q. 表明保証や補償条項を入れておけば、第三者侵害のリスクはなくなりますか？
なくなりはしません。権利者との関係では、契約があっても発注者が一次対応を迫られる点は変わらず、受託者に資力がなければ費用回収も困難です。契約での備えは、検収で混入を未然に防ぐ取り組みと組み合わせた二段構えで初めて実効性を持ちます。
まとめ｜時系列で注意点を点検し、深掘りは姉妹記事へ
業務委託の著作権で発注者がつまずく注意点は、発注プロセスの各段階に分散しています。本記事の内容を行動ステップに集約すると、次のようになります。
- 発注前：受託者選定の段階で、使用素材・コードの出所と権利処理、OSS・生成AIの利用方針、再委託の有無を確認する
- 契約時：譲渡条項・27条/28条の特掲・人格権不行使という取得の最低ラインに加え、第三者非侵害の表明保証と補償条項を入れる
- 検収時：盗用・OSS混入・生成AIの不確実性をチェックし、混入を水際で止める
- 公表・利用時：第三者侵害が発注者に跳ね返るリスクと、人格権で改変が止まるリスクに注意する
- 再利用・乗り換え時：改修・二次利用に必要な権利と、ソース・現物の引渡しの両方を確保する
ここで改めて押さえたいのは、著作権は「もらう側（取得）」だけでなく「侵害を負わされる側」の両面で点検が必要だ、という核心です。前者だけに気を取られていると、後者の落とし穴に足をすくわれます。
より詳しい論点については、帰属判定・譲渡条項・複数関与の整理は業務委託の著作権帰属、著作権・知財保護の運用全般はフリーランス業務委託で著作権・知財を守る契約と運用の実践ガイドが参考になります。
著作権の注意点を発注プロセスにあらかじめ組み込んでおくことは、トラブルを避けるだけでなく、外部人材を安心して活用し続けるための土台になります。本記事のチェックリストを使って、まずは自社の発注のどの段階に抜けがあるかを点検してみてください。
