フリーランスエンジニアの著作権譲渡条項、契約書で権利を守る読み方

新しいクライアントから業務委託契約書が送られてきて、目を通したら「本業務により生じた著作権（著作権法第27条および第28条の権利を含む）は、報酬支払をもって甲に譲渡する」といった一文があった。過去に自分が書いたライブラリや共通コンポーネントを流用しているのに、これにサインして本当に大丈夫だろうか——そんな不安から検索した方も多いのではないでしょうか。

フリーランスエンジニアにとって、著作権譲渡条項は「読めば読むほど分からなくなる」領域です。全部譲渡してよいのか、27条・28条とは何か、著作者人格権不行使特約は何を意味するのか、そして先方雛形をどこまで修正提案してよいのか。判断材料が揃わないまま、なんとなくサインしてしまう方も少なくありません。

しかし、著作権譲渡条項は「サインするか・しないか」の二択で決めるものではありません。譲渡・許諾・独占/非独占・27条28条の特掲・バックグラウンドIPの除外など、条項の各要素を分解して「どこを残し、どこを交渉するか」を組み立てる作業です。2024年11月に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）によって、発注者側が知的財産権の取扱いを一方的に決定することは禁止されており、交渉する法的な後ろ盾も整いつつあります。

本記事では、フリーランスエンジニアが業務委託契約書の著作権譲渡条項を読み解き、自分のノウハウ・共通ライブラリ・再利用資産を守るための実務手順を解説します。契約書の読み方、著作権法27条・28条の落とし穴、フリーランス新法の使い方、サイン前チェックリスト、そして継続案件と信頼関係を壊さない交渉メール文例まで、明日から使える形でまとめました。

フリーランスエンジニアが著作権譲渡条項で立ち止まる理由

「著作権はクライアントに譲渡する」——契約書のこの一行にサインしてよいのか、迷うのは自然なことです。特にフリーランスエンジニアの場合、他案件で書いたコードや自作ライブラリを土台にプロジェクトを進めていることが多く、「どこまでが今回の成果物で、どこまでが自分の資産か」が曖昧になりがちです。

さらに、契約書に書かれる譲渡条項には「著作権法第27条および第28条の権利を含む」という一文が添えられているケースが多く、この一文が実務にどう効くかを正確に理解している方は多くありません。何となく不安を感じつつ「先方の雛形だから仕方ない」と受け入れてしまうと、後で「自分のGitHubで似たコードを公開してよいのか」「他案件で流用してよいのか」といった判断で手が止まる場面が増えてしまいます。

大切なのは、譲渡条項を「サインするかしないか」の二項対立ではなく、「どう読み、どこを交渉するか」の手順の問題として捉え直すことです。本記事ではその手順を、条項の読み方・法的な後ろ盾・チェックリスト・交渉テンプレの順に整理します。継続案件と信頼関係を維持したまま、自分の資産を守るための実務的な道筋を提示します。契約書全般のトラブルパターンに関する広い視点は、フリーランスエンジニアの契約トラブルもあわせてご覧ください。

著作権譲渡条項とは何か（フリーランスエンジニアが失うものと守れるもの）

著作権譲渡条項を交渉する前提として、「譲渡」と「利用許諾（ライセンス）」がまったく別物であることをおさえておく必要があります。この違いを踏まえると、契約書の各条項を分解して読めるようになります。

著作権譲渡と利用許諾（ライセンス）は別物

著作権の扱いには、大きく4つのパターンがあります。

• 全部譲渡: 著作権のすべてをクライアントに移します。受注側は原則として自らも利用できなくなります
• 一部譲渡: 特定の権利（複製権など）のみをクライアントに移し、それ以外の権利は受注側に残ります
• 独占ライセンス: 著作権は受注側に残しつつ、クライアントに独占的な利用権を与えます。受注側も第三者に許諾はできません
• 非独占ライセンス: 著作権は受注側に残し、クライアントに非独占的な利用権を与えます。受注側は他案件でも利用可能です

つまり、譲渡を選ぶかライセンスを選ぶか、独占にするか非独占にするかで、フリーランス側に残る「動ける範囲」は大きく変わります。契約書に「譲渡」と書かれていても、実際にクライアントが必要なのは「自社サービスとして自由に使えること」だけであり、ライセンスで足りるケースも珍しくありません（著作権譲渡ってしなきゃいけないの？（Workship MAGAZINE 弁護士解説））。

ソースコードの著作権はデフォルトで受注者に発生する

もう一つ重要な原則があります。ソースコードの著作権は、書いた瞬間に受注者に自動的に発生します。契約書に「著作権はクライアントに譲渡する」と明記されていなければ、クライアントは著作権を取得できません（誰でもできる著作権契約マニュアル（文化庁））。

つまり、譲渡条項は「クライアントが権利を取るために必要な仕組み」であり、フリーランス側から見れば「明示しなければ手放す必要がないもの」を、明示して手放しているという理解が正確です。「譲渡＝当然」ではなく、「譲渡か許諾か、どちらの契約設計にするか」を交渉できる余地があるということを、まずおさえておきましょう。

著作者人格権は譲渡できない — ただし「不行使特約」で実質縛られることがある

著作権と別に「著作者人格権」があります。これは公表権・氏名表示権・同一性保持権から成り、著作者の人格に強く結びついているため譲渡することができません（著作権法第59条）。

ただし、多くの業務委託契約書には「著作者は著作者人格権を行使しないものとする」という「不行使特約」が入っています。これがあると、たとえばクライアントが成果物を勝手に改変したり、開発者名を伏せて配布したりしても、フリーランス側から異議を唱えられなくなります。GitHubに事例として掲載したり、登壇資料で技術ポイントを紹介したりする際に、この特約の書き方が効いてくるため、範囲を確認する必要があります。

契約書で見落としがちな著作権法27条・28条の落とし穴

譲渡条項を読むうえで、フリーランスエンジニアが特に注意したいのが「著作権法第27条および第28条の権利を含む」という一文です。この一文があるかどうかで、譲渡後に自分が動ける範囲が大きく変わります。

著作権法61条2項 — 27条・28条は「特掲」しないと譲渡されない

著作権法第61条2項には、著作権を譲渡する契約において「第27条（翻訳権・翻案権）または第28条（二次的著作物の利用に関する原著作者の権利）に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する」と規定されています（著作権法第61条2項の権利の意味（みやはら総合法務事務所））。

つまり、契約書に単に「著作権を譲渡する」と書かれているだけであれば、27条・28条の権利は自動的にフリーランス側に残ります。逆に、「著作権法第27条および第28条の権利を含む」と特掲されている場合、これらの権利まで含めてクライアントに渡ることになります。

27条（翻案権）が譲渡されるとエンジニアが失うもの

27条は「翻訳・翻案する権利」を規定しています。ソフトウェア文脈では、コードの改変・機能追加・別言語への移植・大幅なリファクタリングなどが「翻案」にあたる可能性があります。

27条がクライアント側に移ると、たとえば以下のような影響が想定されます。

• 納品したコードをベースに、フリーランス側で改良版を作って別案件に展開することができなくなります
• 同じ設計思想の派生ライブラリを自分のGitHubで公開する際に、権利上のグレーが生まれます
• 保守フェーズで発注者以外の第三者（他のフリーランス・別会社）が改変する際、フリーランス側が関与できません

28条（二次的著作物の利用権）が譲渡されるとエンジニアが失うもの

28条は、原著作物から派生した「二次的著作物」に対して、原著作者が持つ権利を規定しています。ソフトウェア文脈でいえば、納品したコードを翻案して作られた別バージョンについて、フリーランス側が持つ権利です。

28条がクライアント側に譲渡されると、派生したモジュールやリファクタリング後のコードに対しても、フリーランス側から利用や共有の主張ができなくなります。「せめて自分が書いた部分の派生物には関与したい」という余地が失われる、と理解するとイメージしやすいでしょう（「著作権（著作権法第27条及び第28条の権利を含む。）」とは（契約書ヒヤリハット集））。

「27条28条を含む」を残すかどうかの判断軸

すべての案件で27条・28条の特掲を削除する必要はありません。判断のポイントは次の3点です。

1. 成果物が汎用的か固有か: SaaS基盤やライブラリなど汎用性の高いコードほど、フリーランス側に権利を残す価値が高くなります
2. 継続保守を誰が行うか: フリーランス側が長期保守を担う契約なら、27条・28条を含めない方が保守作業の自由度が上がります
3. バックグラウンドIPとの重なり: 過去の自作ライブラリを土台にしている場合、27条・28条まで譲渡すると自分の資産に矛盾が生じます

フリーランス新法が著作権譲渡条項に効かせる歯止め

「先方雛形だから変更できない」——契約書修正を諦めてしまう最大の理由がこれです。しかし2024年11月1日に施行されたフリーランス新法（正式名称: 特定受託事業者に係る取引の適正化等に関する法律）によって、発注者側が一方的に条件を決められる時代は終わりつつあります。

フリーランス新法の全体像と2024年11月施行のポイント

フリーランス新法は、業務委託の受注者（特定受託事業者）を保護するための法律で、取引条件の書面明示義務・報酬支払期日・受領拒否の禁止・買いたたきの禁止・一方的な内容変更の禁止など、幅広い保護を発注者に義務付けています（フリーランスが安心して働ける環境づくりのための法律（政府広報オンライン）、フリーランス法特設サイト（公正取引委員会））。

対象となるのは、従業員を雇用しない個人事業主（および一人法人）であり、多くのフリーランスエンジニアがこれに含まれます。取引条件の明示は書面またはメール等のテキストで行う必要があり、口頭合意だけでは違反となります。

知財の一方的決定禁止 — 「先方雛形だから」は理由にならない

新法の中でも著作権譲渡条項の交渉に直接効くのが、「知的財産権の取扱いを含む契約条件を、発注者側が一方的に決定することを禁じる」という趣旨の規制です。従来、多くの契約書は発注者側の雛形をそのまま使い、著作権は自動的に発注者に譲渡される設計が「業界慣行」となっていました。しかし新法下では、この慣行を根拠として交渉を拒むこと自体が問題視されうる状況になっています（フリーランス新法のポイントと業務委託契約書の見直し（IT弁護士 大阪））。

フリーランス側から「知的財産の帰属について、以下の点について協議させてください」と切り出すことは、新法の理念に沿った正当なアプローチです。決して「難しい要求をしている」わけではありません。

取引条件明示義務と「著作権帰属」の書面化

新法では、業務内容・報酬・支払期日など主要な取引条件を書面またはテキストで明示する義務が発注者に課されています。著作権の帰属や譲渡範囲もこの「主要な取引条件」に含まれると解釈するのが実務上の一般的な見解です。

つまり、契約書に曖昧な譲渡条項しか書かれていない場合、フリーランス側から「範囲を明確化してください」と質問すること自体が、新法の明示義務を補完する行為として位置づけられます。「面倒な質問をする人」ではなく、「法律に沿った健全な確認をする人」として振る舞える根拠が整っているわけです。

サインする前に確認する8つのチェックポイント

契約書を受け取ったら、まず以下の8項目を順に確認してください。「典型的な問題ある表現」と「望ましい表現」を対比しています。契約書の他の条項（報酬・納期・検収など）で発生しがちな落とし穴をあわせて把握したい方は、フリーランスエンジニアの契約トラブルも参照してください。

このチェックリストを手元に置き、契約書を開いたときに一項目ずつ照合してください。すべてを100点にする必要はなく、案件の性質と自分のリスク許容度に応じて優先順位をつけると現実的です。

交渉で使える代替条項の具体例と提案メール文例

修正提案は「角が立つ」と感じるかもしれませんが、条項レベルの言い回しと丁寧なメール文があれば、多くのクライアントは前向きに検討してくれます。ここでは3パターンの代替条項と、実際に送るメール文例を紹介します。

代替条項パターン1 — バックグラウンドIPを除外する追記例

過去に自作したライブラリや共通コンポーネントを流用している場合は、「バックグラウンドIP」の除外を明記します。

前条にかかわらず、乙が本業務開始以前より独自に開発・保有する著作物（以下「バックグラウンドIP」という）、および乙が汎用的に利用する再利用可能なコード・ライブラリ・フレームワークは、譲渡の対象外とする。ただし乙は、成果物の目的の範囲内で甲がバックグラウンドIPを利用することを許諾する。

この一文があれば、自作ライブラリを土台に開発を進めても、権利上の矛盾が生じません。

代替条項パターン2 — 譲渡を非独占ライセンスに置き換える提案

クライアントが「自社サービスに使えれば十分」というタイプなら、譲渡ではなく非独占ライセンスで足ります。

乙は甲に対し、本業務の成果物について、期限の定めなく、地域を限定せず、非独占的に利用する権利を許諾する。乙は、成果物およびそこに含まれる知見を、他の業務・自らのポートフォリオにおいて利用できるものとする。

この設計であれば、著作権は乙（フリーランス）に残り、他案件やポートフォリオでの利用余地を確保できます。

代替条項パターン3 — 著作者人格権不行使特約を限定する提案

不行使特約を「一律で行使しない」ではなく、「正当な理由がある場合は行使しうる」と限定します。

乙は、甲による成果物の利用が本契約の目的の範囲内にある限り、著作者人格権を行使しない。ただし、成果物が本契約の目的を超えて改変・公表され、乙の名誉または声望を害する場合はこの限りではない。

無断改変で自分の名前が汚される事態を避けるための最低限のセーフティネットです。

クライアントに送る交渉メール文例（コピペ可）

条項の修正提案は、以下のようなメールで丁寧に切り出せば角が立ちません。

○○様

お世話になっております。契約書ドラフトをご送付いただきありがとうございました。

内容を確認したうえで、著作権の取扱いについて2点ご相談させてください。

1. 私が過去より独自に開発・保有しているライブラリや汎用コンポーネントを、本プロジェクトの効率化のために活用したいと考えております。これらを「バックグラウンドIP」として譲渡対象外とし、御社にはプロジェクト目的の範囲でご利用いただく形でご相談できませんでしょうか。

2. 現条項では「著作権法第27条および第28条の権利を含む」と特掲されておりますが、御社の運用目的（例: 自社サービスとしての利用・保守）を伺ったうえで、非独占ライセンスまたは27条・28条を留保する形での落としどころをご検討いただけますと幸いです。

いずれも本プロジェクトの円滑な進行と、御社のご利用範囲を制限しない形でのご提案として考えております。ご都合のよろしいタイミングで、5〜10分ほどお時間をいただければ幸いです。

何卒よろしくお願いいたします。

「一方的な要求」ではなく「相談」の形にすること、そして「相手の目的を確認したうえで」というスタンスを見せることが、継続案件と信頼関係を維持する鍵です。

よくある論点 — OSS・AI生成コード・保守フェーズの著作権

譲渡条項の周辺で混同されがちな3つの論点も、簡単におさえておきましょう。

OSSライセンス汚染は譲渡では解決しない

成果物にOSS（オープンソースソフトウェア）が含まれる場合、そのOSSのライセンス条件は譲渡契約とは別のレイヤーで効きます。特にGPLなどコピーレフト型のライセンスは、譲渡条項でどう書こうと制約は変わりません。契約書には「成果物に含まれるOSSは各OSSのライセンス条件に従う」旨を明示し、両者で認識を合わせておくのが安全です。

AI生成コードは譲渡対象になるのか

AI（Copilot・Cursor・ChatGPT等）で生成したコードは、「著作物性」自体が議論の途上にあります。人間の創作的関与が薄いと判断されれば著作権が発生せず、譲渡対象にすらならないという解釈もあります。実務上は、契約書に「AI生成物の取扱いを別途協議する」条項を追加しておくのが現時点で無難な選択肢です。AI 生成コードの著作権論点をさらに掘り下げたい方は、フリーランスエンジニアのAIコード著作権もあわせてご覧ください。

保守フェーズ・追加開発の著作権帰属を別途明示する

初期開発の契約に加えて、後日の保守や機能追加を担う場合、そこで新たに書いたコードの著作権帰属も別途明示しておく必要があります。「保守業務については別途契約または追記合意による」と一文を入れておくと、後で揉めるリスクを下げられます。

著作権リテラシーを継続案件獲得の武器に変える

著作権譲渡条項を読み解ける・提案できるフリーランスエンジニアは、クライアントから見ても「安心して継続発注できる相手」に映ります。単に権利を守るためだけでなく、契約リテラシーそのものが継続契約と単価交渉の武器になる、という視点で締めましょう。

「契約を読める」フリーランスがクライアントから選ばれる理由

契約書に対して質問・提案ができるフリーランスは、発注側から見れば「後で揉めない相手」です。逆に、契約書を確認せずすべて受け入れるフリーランスは、後日のトラブル時にコストがかかる可能性が高く、意外にも継続案件で選ばれにくくなる傾向があります。

リテラシーを単価と継続契約に還元する

契約書を読める・改善提案ができるという事実は、価格交渉の場面でも効いてきます。「契約書レベルまで理解している専門家」というポジションを取れれば、単なる実装者ではなく、要件整理から契約設計まで含めて相談できるパートナーとして扱ってもらえるからです。著作権リテラシーへの投資は、目の前の1案件だけでなく、フリーランスとしての中長期の収入安定に効いてくる投資です。

まとめ

フリーランスエンジニアが業務委託契約書の著作権譲渡条項でつまずかないために、押さえるべきポイントを再掲します。

1. 譲渡と利用許諾（ライセンス）は別物であり、非独占ライセンスで足りるケースが多いです
2. ソースコードの著作権はデフォルトで受注者に発生します。譲渡は「明示しないと発生しません」
3. 「著作権法第27条および第28条の権利を含む」と特掲されているかを必ずチェックしましょう
4. 著作者人格権不行使特約は、範囲を限定する交渉が可能です
5. フリーランス新法により、発注者が知財の取扱いを一方的に決定することは禁止されています
6. バックグラウンドIP・OSS・ポートフォリオ利用の条項を明示しましょう
7. 交渉は「相談」の形で丁寧に切り出し、代替条項テンプレを添えて送りましょう
8. 契約リテラシーは継続案件と単価交渉の武器になります

明日からの1アクションとしては、いま手元にある契約書を開いて、「27条28条が特掲されているか」と「バックグラウンドIPの記載があるか」の2点だけでも確認してみてください。この2つを確認できるだけで、あなたの契約リテラシーは1歩前進します。