フリーランスエンジニアのAIコード著作権、納品前に押さえる実務

「Copilotで書いたコード、このまま納品して本当に大丈夫だろうか」。日々の開発でAIコーディングツールを使い倒しているフリーランスエンジニアほど、ふとした瞬間にこの不安が頭をよぎるのではないでしょうか。生産性は確かに上がっている。けれど、契約書には「AIツール使用」に関する条項が見当たらない、あるいは曖昧な表現しか書かれていない。そんな状態のまま納品を続けていてよいのか、判断材料が手元にない人は多いはずです。

問題を難しくしているのは、論点が「使ってよいか悪いか」の二項対立ではないことです。AI生成コードの著作権の扱い、利用ツールごとの規約や補償の有無、契約書に条項がない場合のデフォルト解釈、クライアントとの事前合意の進め方、さらには「AI使用禁止」と言われたときの落としどころまで、複数のレイヤーが絡んでいます。どこか1つだけ押さえても、別のレイヤーで足をすくわれかねません。

特にフリーランスは、複数クライアントを並行で抱えているケースが多く、案件ごとに前提条件が違います。A社では当たり前に使っているCursorが、B社では情報セキュリティポリシーで禁止対象だった、というのは珍しい話ではありません。納品後にトラブルが顕在化すれば、単に1案件を失うだけでなく、継続発注の信頼関係そのものが揺らぎます。

本記事では、Webアプリ・業務システムの実装で稼働するフリーランスエンジニアを想定読者に、(1) 2026年時点でAI生成コードの著作権がどう整理されているか、(2) GitHub Copilot・Cursor・Claude Codeの利用規約と補償の違い、(3) 契約書に条項がない場合のデフォルト解釈と事前合意の進め方、(4) 「AIツール使用禁止」と言われたときの現実的な対応策、を実務目線で順に解説します。

なお、本記事は一般的な情報提供を目的としたものであり、個別の契約・案件に関する法的判断は弁護士・弁理士への相談を推奨します。それを前提に、納品前に押さえておきたい実務の型を整理していきましょう。

フリーランスエンジニアがAI生成コードの著作権でつまずく本当の理由

フリーランスエンジニアがAI生成コードの著作権で不安になる場面は、たいてい次のような形をとります。「契約書には『成果物の著作権はクライアントに譲渡』とだけ書いてあるが、AIツール使用については一言も触れられていない」「別案件のキックオフで突然『弊社はAIツール使用禁止です』と言われた」「秘密保持契約（NDA）にAI入力の可否が書かれておらず、ソースコードをCopilotに読ませてよいのか判断がつかない」。

ここで多くの人が陥りがちなのが、「白か黒か」で考えてしまうことです。「AIで書いたコードは著作物にならないから譲渡できない、だから納品はNG」あるいは「契約書に書いていないから自由に使ってよい」という、極端な結論に振れがちです。しかし実務上の正解は、その中間にあります。

AI生成コードを巡る論点は、大きく3つのレイヤーに分けて整理すると見通しが立ちます。1つ目は著作権法上の論点（誰の著作物になるか、他者著作物への依拠性はないか）、2つ目はツール側の利用規約とリスク補償の論点（学習に使われるか、侵害クレーム時に補償があるか）、3つ目は個別契約と事前合意の論点（クライアントとの間で何を取り決めるか）です。

この3層を一度に解こうとすると混乱しますが、レイヤーごとに整理すれば「自分の案件で何をチェックすればよいか」が見えてきます。本記事の後半では、各レイヤーで具体的にどう動くかをチェックリスト形式で提示します。まずは法的な前提から押さえていきましょう。

AI生成コードの著作権はどうなるのか（2026年時点の法的整理）

「AIで生成したコードの著作権はそもそも誰のもの？」という疑問は、フリーランスにとって最初の関門です。納品物の著作権をクライアントに譲渡する条項があっても、譲渡対象が著作物として成立していなければ、その譲渡条項自体が空振りになる可能性があるためです。ここでは2026年時点の整理を、フリーランスの実務に関係する範囲で確認しておきましょう。

そもそもAI生成コードは「誰の著作物」になるのか

日本の著作権法では、著作物は「思想又は感情を創作的に表現したもの」と定義されています。文化庁が公表しているAIと著作権に関する考え方についてでは、生成AIによる出力物について、人間の創作的寄与の度合いに応じて著作物性の有無が判断されるという整理が示されています。

つまり、プロンプトを一行投げて出てきたコードをそのまま使った場合と、エンジニアが要件定義・設計・プロンプト調整・出力レビュー・修正を重ねた結果としてのコードでは、扱いが変わり得るということです。受託開発の現場で多い「人間が設計し、AIが実装の下書きを出し、人間がレビュー・修正して仕上げる」という使い方であれば、人間の創作的寄与が認められる余地があると考えられます。一方、生成物をそのままコピー＆ペーストしただけの部分は、著作物として保護されない可能性があります。

フリーランス契約で多い「成果物の著作権譲渡」条項とAI生成コードの相性

フリーランスの業務委託契約では、「本件成果物に関する著作権（著作権法第27条及び第28条の権利を含む）は、検収完了をもって乙から甲に譲渡されるものとする」のような条項が一般的です。問題は、譲渡できるのは「自分が持っている著作権」だけだという点です。

AI生成コードの一部に著作物性が認められない場合、その部分の著作権そのものが存在しないため、譲渡条項があっても「譲渡される権利が無い」という事態が起こり得ます。これは契約違反というより、契約条項が想定どおりに機能しないという意味でクライアント側の期待を裏切るリスクです。

実務的には、「成果物にAI生成部分が含まれることを前提に、当該部分について第三者からの権利主張がないよう適切に検証する義務を負う」といった形で、譲渡条項とは別の表明保証条項で補完するのが現実的な落としどころです。具体的な追記文例はのちほど提示します。

もう1つのリスク「他者著作物への依拠性」と侵害の成立条件

著作権侵害が成立するには、「類似性」と「依拠性」の2つが必要というのが日本の判例の枠組みです。文化庁の整理では、AI利用者が既存の著作物を認識した上で類似物を生成させた場合や、AIが学習段階で取り込んだ著作物に類似する出力が生成された場合には、依拠性が認められる可能性があるとされています（参考: 文化庁「AIと著作権について」）。

コード生成の文脈で具体的に言えば、Copilotが学習元のGitHub公開リポジトリの実装と酷似するスニペットを出力し、それを納品物に組み込んでしまった場合、当該スニペットの元コードに著作物性があり、かつ依拠性が認定されれば、納品物がそのまま侵害物となる可能性があります。これがフリーランスにとって最も実務的な懸念です。

幸い、後述するように主要ツールには「公開コードと類似する出力を抑制するフィルタ」が用意されており、設定で大幅にリスクを下げられます。重要なのは、ツール設定の有無を「事故が起きてから」ではなく「納品前」に確認しておくことです。

GitHub Copilot・Cursor・Claude Codeの利用規約と補償を比較する

ツール選択と設定で回避できるリスクは、想像以上に大きいというのが実務感覚です。同じ「AIコーディングツール」でも、商用利用の前提・データの学習可否・侵害クレーム時の補償の有無は、プランや設定で大きく変わります。2026年時点の主要3ツールについて、フリーランスの業務利用目線で整理してみましょう。

GitHub Copilot — Copilot Copyright Commitmentと業務利用の前提

GitHub Copilot Business / Enterpriseには、Microsoftが提供するCopilot Copyright Commitment（CCC）という補償スキームが付随します。Copilotの出力が第三者の著作権を侵害したとして顧客企業が訴えられた場合、Microsoftが防御費用と賠償金を負担するという内容です（参考: Microsoft Customer Copyright Commitment Required Mitigations）。

ただしこれには条件があり、Microsoftが提供するガードレールやフィルタを有効化していることが前提です。Copilotの場合、公開コードと類似する出力を抑制するDuplicate Detection Filter（Finding public code that matches GitHub Copilot suggestions）の有効化が代表的な要件として扱われてきました。フリーランスとして案件で使う場合、自分の契約しているプランがBusiness以上であるか、フィルタがオンになっているかを確認しておく価値があります。

また、Business / Enterpriseでは入力したコードがモデル学習に使用されない契約上の保証があります（参考: GitHub Copilot Business）。これはNDA下でクライアントのソースコードを扱う際の前提条件として効いてきます。Free / Pro / Pro+のような個人プランは、2026年4月24日以降、デフォルトでユーザー操作が学習対象になる可能性があり、業務利用にはオプトアウト設定が必須です（参考: GitHub Copilot 個人プランのポリシー管理）。

Cursor — プライバシーモードと商用利用時の注意点

Cursorには「Privacy Mode」という設定があり、有効化するとプロンプトやコードがCursor側に保持されず、学習にも使われない設計になっています（参考: Cursor Data Use & Privacy Overview）。注意点は、Free / Proプランではプライバシーモードがデフォルトでオフという点です。意識的にオンにしない限り、コードが学習対象になる可能性があります。

Cursor Businessプランでは、組織レベルでプライバシーモードを強制でき、個別のメンバーが解除できないようロックできます。複数クライアントを扱うフリーランスがチームメンバーとして招待されているケースでは、組織側で強制設定されているか確認しておくと安心です。著作権侵害時の包括的な補償スキームについては、Copilot Business のような明示的なIP保証よりは個別契約・利用規約ベースの整理になるため、機密性の高い案件ではエンタープライズ契約の条件を確認するか、後述のローカル運用の選択肢と組み合わせる必要があります。

Claude Code — データ取り扱いと納品物への影響

Claude Codeは、Anthropicの商用利用規約下では、入力データを学習に使用しないことが明示されています。Claude for Work（Team / Enterprise）やAPI経由の利用は商用規約が適用されるため、業務利用に適しています。一方、2025年10月以降、Free / Pro / Maxの個人プランはデータ学習の利用が初期設定でオプトインとなり、Claude Codeを個人プラン経由で利用する場合は明示的に学習をオフにする必要があります（参考: Updates to Consumer Terms and Privacy Policy）。

Claude Codeを実際にフリーランス業務に組み込む際の生産性面の工夫については、Claude Codeで生産性を上げるフリーランスエンジニア向け活用法も参考になります。

フリーランスが業務利用で選ぶ際のチェック観点

最低限、納品物に関わる案件で押さえておきたいチェック観点は以下のとおりです。

• 入力コードがモデル学習に使われない契約・設定になっているか
• 著作権侵害クレームが起きた場合の補償スキームの有無
• 公開コードと類似する出力を抑制するフィルタの有無と有効化状態
• 組織アカウントで設定が強制ロックされているか、個別解除可能か
• 利用規約が変更された場合の通知タイミング（特に学習方針の変更）

これらを満たしやすいのは、現状ではCopilot Business / Enterprise、Cursor Business、Claude for Work（Team / Enterprise）といった業務向けプランです。「ツールが優秀かどうか」より「業務利用前提のプランか」を選択基準に置く方が、結果として案件継続の安定につながります。

客先納品前に必ず確認すべき3つのポイント

ツール選択と契約の整理ができたら、次は納品物そのものをチェックするフェーズです。ここでは、納品前のセルフチェックを3つに絞って整理します。

使用ツールの設定確認（学習オフ・パブリックコードフィルタ）

まず確認すべきは、自分が使っているツールが現在どの設定で動いているかです。チェックポイントは以下です。

• GitHub Copilot: 「Suggestions matching public code」がBlockになっているか（個人プランの場合）、Business以上のプランで組織側のポリシーが適用されているか
• Cursor: 設定画面でPrivacy Modeがオンになっているか、Businessプランで組織強制になっているか
• Claude Code: 商用プラン（API / Team / Enterprise）で利用しているか、個人プランの場合は学習へのデータ提供がオフになっているか

これらは「設定すれば終わり」ではなく、ツール側のポリシー変更で初期設定が変わることがあります。重要な納品の直前には、設定画面のスクリーンショットを残しておくと、後日「設定していました」の証拠になります。

OSSライセンス汚染チェック（コピーレフト混入の検知）

公開コードフィルタを有効にしていても、すべてのライセンス問題を機械的に検知できるわけではありません。特に注意したいのが、GPL系のコピーレフトライセンスを持つコードが意図せずプロジェクトに混入するケースです。

実務的には、(1) 重要なロジック部分はAI出力をそのまま使わず必ずレビュー・書き直しを行う、(2) 既知のOSSスニペットに酷似していないか、出力されたコードをそのまま検索エンジンで検索してみる、(3) ライセンススキャンツール（FOSSA、Snyk Open Source、ScanCodeなど）をCIに組み込む、といった対策が考えられます。

少なくとも納品前には、AIが大量に書いた部分について「これは本当にゼロから生成されたコードか、それとも既存OSSに酷似していないか」を一度疑う習慣を持つことが、依拠性リスクを下げる現実的な手段です。

「成果物の著作権譲渡」条項とAI生成コードの整合性確認

契約書に「成果物の著作権は甲に譲渡」と書かれているにもかかわらず、AI生成コードに著作物性が認められない部分が混在している、というケースを思い出してください。納品前にこの整合性をチェックする観点は次のとおりです。

• 設計や独自ロジックなど、人間の創作的寄与が明確な部分はどこか
• AI出力をほぼそのまま使っている部分はどこか、その割合はクライアントの期待と乖離していないか
• 譲渡条項とは別に、第三者の権利を侵害していないことを表明保証する条項があるか

もしこのチェックで違和感を感じたら、納品前にクライアントに「成果物にAI生成部分が含まれます」と一言伝え、契約上の取り扱いを確認しておくのが安全です。これは次の章で詳しく扱います。

契約書にAIツール使用条項がない場合のデフォルト解釈と事前合意の進め方

フリーランスが最も悩むのが、「契約書にAIツール使用の可否が書かれていない場合、どう解釈すべきか」です。経済産業省が令和7年（2025年）2月に公表したAIの利用・開発に関する契約チェックリストは、この論点を整理する上で参考になります。実務で押さえておきたいポイントを見ていきましょう。

条項なし＝OKではない理由（秘密保持条項との衝突）

「契約書にAI禁止と書いていないから自由に使ってよい」と判断するのは早計です。理由は2つあります。

1つは、ほとんどの業務委託契約に秘密保持条項が含まれており、「業務上知り得た情報を第三者に開示してはならない」と規定されている点です。クライアントのソースコードをAIツールにそのまま投入する行為が「第三者への開示」に該当するかは、ツールのデータ取扱（学習に使われるかどうか）によって解釈が分かれます。学習に使われる設定のままだと、秘密保持義務違反を問われるリスクがあります。

もう1つは、成果物の著作権譲渡条項の前提となる「権利の存在」が、AI生成部分について揺らぐ点です。先に整理したとおり、譲渡できるのは自分が持っている著作権だけです。クライアント側が「全部譲渡される前提」で発注している場合、AI生成部分の存在を共有しないままだと、後から認識齟齬が生じる可能性があります。

経済産業省のチェックリストでも、ユーザ（発注者）とベンダ（受注者）の間で入力データの範囲・学習利用の可否・成果物に含まれるAI生成物の取扱を事前に整理することが推奨されています（参考: 「AIの利用・開発に関する契約チェックリスト」の要点解説（Business & Law））。これは発注側企業向けの内容ですが、受注者であるフリーランスにとっても「事前に確認しておくべき項目リスト」として利用できます。

クライアントへの事前確認メール文例（コピペ可）

突然「AI使ってますがいいですか？」と切り出すと身構えられがちなので、業務効率化の文脈で素直に共有するのが現実的です。以下はそのままコピペできる文例です。

件名: 開発業務におけるAIコーディング支援ツールの使用について（ご確認のお願い）

〇〇株式会社
△△様

いつもお世話になっております。〇〇です。

開発業務の生産性向上のため、GitHub Copilot Business（または Cursor Business / Claude Code）の
ようなAIコーディング支援ツールを利用しております。

利用にあたっては、以下を前提としております。
・ご提供いただいたソースコード・仕様情報がモデル学習に使用されない契約プラン
・公開コードと類似する出力を抑制するフィルタを有効化
・成果物は人間によるレビュー・修正を経て納品

念のため、貴社のセキュリティポリシー・知的財産管理上、上記の利用形態に
ご懸念がないかご確認いただけますでしょうか。

ご懸念がある場合は、利用範囲の限定や代替ツールでの対応も可能です。
お手数ですがご回答のほどよろしくお願いいたします。

ポイントは、(1) 利用前提（学習に使われないプラン・フィルタ有効）を明示すること、(2) 懸念がある場合の代替案を先に示すことです。「使わせてください」ではなく「こういう前提で使っているが問題ないか」というスタンスにすることで、合意形成のハードルが下がります。

業務委託契約への追記条項例（使用ツール・データ取り扱い・補償の3点）

新規契約や契約更新のタイミングであれば、契約書本体に条項を追加するのが理想です。文例として以下のような追記が考えられます。

（AIツールの利用）
第〇条 乙は、本業務の遂行にあたり、生成AIを用いたコーディング支援ツールを
利用することがある。利用するツール及びその利用条件は次のとおりとする。

1. 入力データがモデル学習に使用されないプランまたは設定で利用すること
2. 公開コード類似性検出フィルタ等、第三者著作権侵害の抑制機能を有効化すること
3. 生成物は乙によるレビュー・修正を経て成果物に組み込むこと

2. 乙は、本成果物に含まれる生成AIによる出力部分について、第三者の知的財産権を
侵害しないよう合理的な注意を払う。万一、第三者から本成果物に関し権利侵害の
主張がなされた場合、乙は誠実に対応するとともに、利用ツールベンダの補償スキーム
(GitHub Copilot Copyright Commitment 等)を活用することができる。

これはあくまでサンプルであり、案件の規模・性質・クライアントの要求水準によって調整が必要です。重要な案件や金額が大きい案件では、弁護士に条項のレビューを依頼することを強く推奨します。

クライアントから「AIツール使用禁止」と言われたときの対応策

事前確認の結果、「弊社はAIツール使用禁止です」と返ってくるケースもあります。ここで「分かりました」と引き下がる前に、禁止の理由を分解してみると、対応策が見えてくることが少なくありません。

なぜクライアントは禁止するのか（典型的な3つの懸念）

「AI禁止」の背景にあるのは、主に次の3つの懸念です。

1. 情報漏洩懸念: 自社のコードや顧客情報がAIベンダーの学習データに混入することへの不安
2. 著作権・ライセンス懸念: AI生成コードが第三者の著作権を侵害したり、コピーレフトライセンスを引き込んだりするリスク
3. 品質懸念: AI生成コードがレビューを経ずに納品される、または人間が理解できていないコードが混入することへの不信感

「禁止」と言われた瞬間に終わるのではなく、「どの懸念をお持ちですか」と一歩踏み込めば、選択肢が広がります。

情報漏洩懸念へのカード

情報漏洩懸念に対しては、学習オフ設定が契約上保証されているプランを提示するのが王道です。Copilot Business / Enterprise、Cursor Business、Claude for Workなど、入力データが学習に使われない契約プランの利用を提案します。それでも不安が残る場合は、ローカルで動くLLM（Llama系、Qwen系などをローカルマシン・自社サーバーで動かすパターン）や、Azure OpenAI Service・AWS Bedrock経由でクライアント自社のクラウド環境内に閉じ込める提案も選択肢になります。

著作権懸念へのカード

著作権懸念に対しては、Copilot Copyright Commitment のようなベンダー側の補償スキームを持ち出すと話が進みやすくなります。Microsoftが防御費用と賠償金を負担するという仕組みは、クライアント側の法務にとって理解しやすい安心材料です。あわせて、Duplicate Detection Filterによる公開コード類似性の抑制機能、納品前のOSSライセンススキャンの実施なども、リスク低減策として提示できます。

品質懸念へのカード

品質懸念に対しては、人間レビューのフロー設計を可視化するのが効果的です。「AI出力をそのまま納品しない」「重要なロジックは必ず人間が再実装する」「テスト網羅率を○%以上で維持する」といった運用ルールを文書化して提示すれば、「機械任せの納品」というイメージを払拭できます。

それでも禁止された場合の落としどころ

ここまで提示しても禁止が覆らないケースもあります。その場合の現実的な落としどころは、AI不使用での工数再見積もりです。AIで30%短縮できていた工数を元に戻すなら、契約金額や納期もそれに応じて調整する必要があります。これはクライアントへの抵抗ではなく、「合意した条件で持続可能に納品するための調整」として伝えると角が立ちません。

最終的にお互いの条件が合わない場合は、無理に受注を続けるよりも、AI活用を受け入れてくれるクライアントに軸足を移すという判断もあり得ます。フリーランスの強みは、案件の選択権を持っていることです。AI活用前提でやり取りできる発注企業と継続的に出会える環境を持っておくことが、長期的な収入安定の土台になります。

フリーランスとして継続的に案件を獲得するためのAI活用スタンス

ここまでの内容を一段引いて眺めると、フリーランスがAIコーディングツールと向き合う上でのスタンスが見えてきます。

「黙って使う」ではなく「設計として提示する」スタイルへ

リスクを最小化する最も効率的なやり方は、AI利用を隠さず、設計として明示することです。「Copilot Businessを使い、Duplicate Detection Filterを有効化し、納品前にOSSライセンススキャンを通しています」と言える状態は、それ自体がフリーランスとしての信頼性のシグナルになります。同業のフリーランスがざっくりとAIを使っている中で、契約・補償・設定まで設計として提示できる人は、それだけで差別化要因を持っているとも言えます。

このスタンスは、AI協働開発全般にも応用が利きます。設計・実装・レビューの中で人間とAIの役割分担を意識しながら案件を進める考え方は、Vibe Coding×フリーランスエンジニアの整理も参考になります。

法務・契約リテラシーを単価交渉の武器にする

クライアントが本当に求めているのは「速く納品してくれるエンジニア」だけではなく、「自社のリスクを増やさないエンジニア」です。AI利用の前提条件・契約条項・補償スキームまで含めて整理して提示できるフリーランスは、発注側の法務・情報セキュリティ部門にとっても扱いやすく、結果として継続発注の対象になりやすくなります。

短期の生産性向上だけでなく、中長期で安定した案件獲得を目指すなら、AIリテラシーと契約リテラシーをセットで磨いておくのが最も費用対効果の高い投資です。「AIを使えるエンジニア」は増えてきていますが、「AI利用を契約・補償の設計まで含めて語れるエンジニア」はまだ希少です。この立ち位置を取れれば、案件マッチングの場面でも単価交渉の場面でも、明確な強みとして機能します。

まとめ

最後に、納品前に押さえておきたいチェック項目を整理しておきます。

• 利用しているAIツールが業務向けプラン（Copilot Business / Cursor Business / Claude for Work など）か確認した
• ツール側で学習オフ・公開コード類似フィルタなどの設定が有効になっている
• 著作権侵害クレーム時の補償スキーム（Copilot Copyright Commitmentなど）の有無を把握している
• 契約書の秘密保持条項・成果物の著作権譲渡条項を読み直し、AI生成コードとの整合性を確認した
• 契約書にAIツール条項がなければ、事前確認メールで合意形成を行った
• 「AI禁止」と言われた場合の交渉カード（学習オフプラン・補償スキーム・品質管理フロー・工数再見積もり）を整理している
• 重要案件・金額の大きい案件では弁護士・弁理士への個別相談を選択肢に入れている

明日から動くなら、まずは現在進行中の案件1つを取り上げ、上のチェックリストを当てはめてみてください。空欄が見つかった項目から順に、1日1つずつ埋めていくだけで、納品物に対する不安は確実に小さくなっていきます。

繰り返しになりますが、本記事は一般的な情報提供を目的としたものであり、個別の案件における法的判断は弁護士・弁理士への相談を推奨します。それを前提に、AIを活用しながらも信頼を積み上げられるフリーランスとして、安定した案件獲得を続けていきましょう。