生成AIの著作権補償が外れる条件一覧｜守られる使い方を確かめる

「法人向けのプランには著作権の補償が付いているから、生成した画像はそのまま広告に使っていい」「補償があるなら、社内での確認は省いても問題ないはずだ」。生成AIの導入が進んだ会社では、こうした受け止め方が静かに広がることがあります。提供元が大きな約束を打ち出しているのは事実なので、そう考えたくなるのも無理はありません。けれども、補償はどんな使い方でも守ってくれる無条件の保証ではありません。本当は、決められた使い方をした場合に限って、提供元が防御を引き受けるという条件付きの約束です。この記事では、補償が外れる条件の型と、自社の契約でそれを確かめる手順を整理します。

「補償があるから大丈夫」が誤解になる理由

著作権の補償が話題になったのは、2023年の秋ごろからです。大手の提供元が相次いで、法人向けの利用者が生成物をめぐって第三者から訴えられた場合に、防御や賠償の負担を引き受けると発表しました。生成AIを業務に使うかどうか迷っていた会社にとって、この発表は大きな安心材料になりました。問題は、見出しの言葉だけが社内に広まり、条件の部分が伝わらないことです。

公表されている各社の文書を読むと、補償には必ず前提があります。対象となる契約やサービスが決まっている、提供元が用意した安全のための仕組みを使っている、侵害しようとして使っていない、といった前提です。これらを満たさない使い方をしていれば、補償を求めても対象外とされる可能性があります。しかも、そうした使い方は、現場の担当者が「便利だから」と悪気なく選んでいることが多いのです。

さらに、補償は訴えられたあとの負担を軽くする仕組みであって、侵害そのものを起こさない仕組みではありません。訴えられれば、補償があっても対応の手間や取引先への説明、広告の差し替えといった負担は自社に残ります。補償は最後の備えであり、確認を省く理由にはならないと位置づけておくことが出発点になります。

著作権の補償は、何を約束しているのか

各社が出している約束の中身は、おおむね「生成物が第三者の知的財産を侵害していると主張されたとき、提供元がその防御を引き受け、条件を満たせば不利な判決などで生じた負担も引き受ける」というものです。呼び名は各社で異なり、マイクロソフトは顧客著作権コミットメント、オープンAIはコピーライト・シールドといった名前で打ち出しています。

グーグルは2023年10月に公式ブログで、2つの層からなる補償を説明しました。1つは、自社のモデルを作るために使った学習データが第三者の知的財産を侵害しているという主張に対するもの、もう1つは、利用者が生成したもの（生成物）が侵害しているという主張に対するものです。このように、学習の側の問題と、生成物の側の問題を分けて書いている例があります。

マイクロソフトの場合、この約束は同社の製品条項に定められており、補償の対象になるかどうかの前提として、条件を満たしていることを請求の際に示す必要があると説明されています。つまり、補償は自動で降りてくるものではなく、条件を満たしていたことを自社が示して、初めて求められるものです。

約束の向きにも注意が要ります。補償が扱うのは、自社が第三者から「侵害している」と主張されたときの防御です。反対に、自社の生成物を他社にまねされたときに守ってくれる約束ではありませんし、自社が他社の侵害を見つけたときに代わりに争ってくれるものでもありません。社内で「補償がある」と伝えるときは、どちら向きの話なのかを添えておくと、期待のずれを防げます。

主な提供元が公表している約束の範囲

ここでは、2026年9月時点で私たちが公開情報として確認できた範囲を表にまとめます。条文は改定されることがあり、ここに書いたのはあくまで公表されている説明の要約です。自社の契約に何が適用されるかは、必ず契約時点の原文で確かめてください。

提供元	公表の時期と文書	公表されている主な前提
マイクロソフト	2023年9月に発表。製品条項に規定。軽減策の説明は公式の技術文書（2026年7月更新）	組み込みの安全機能やフィルターを無効にしない、侵害物を作ろうとしない、クラウド版の生成AIでは所定の軽減策を実装する
グーグル	2023年10月の公式ブログ。対象サービスは一覧のページで公開	意図的に侵害する生成や利用をしていない、出典の表示など責任ある利用のための道具を使っている
オープンAI	2023年11月に発表。法人向けのチャットと開発者向けの接続が対象と説明	知っていた・知るべきだった場合、安全機能の不使用、改変や他製品との組み合わせ、商標などを除外すると定めている例がある

表を見ると、言葉は違っても、前提の型はかなり共通していることが分かります。対象になる契約とサービスが限られていること、安全のための仕組みを使うこと、侵害を意図しないこと、の3つはどの社にも見られます。ここから先の各章は、この共通する型ごとに外れる条件を見ていきます。

なお、表に載せていない提供元でも、同じような約束を出している場合があります。画像生成を主にする提供元などでは、法人向けの契約にだけ補償を付けている例もあります。自社が使っているサービスについては、この表の3列目と同じ形で前提を書き出してみると、自社の使い方のどこが危ないかが見えてくるはずです。

外れる条件1：対象の契約・プラン・機能でない

最初に確かめるべきは、そもそも自社の使い方が対象に入っているかです。補償は多くの場合、法人向けの有料の契約に限られ、個人向けのプランや無料の利用には付いていません。社員が個人のアカウントで生成した画像を業務に使っていれば、会社として法人契約を結んでいても、その生成物は補償の外にあると考えるべきです。同じ提供元のサービスでも、契約の種類によって補償の有無が分かれることを押さえておきます。

機能の単位でも線が引かれていることがあります。グーグルは対象になるサービスを一覧のページで公開しており、一般提供されている版のモデルで使う場合、といった限定が付いている例があります。試験提供の段階の機能は、対象から外れる可能性があります。オープンAIについても、第三者が提供する機能から出てきた生成物は除外すると定めている例が紹介されています。

マイクロソフトの技術文書には、分かりやすい例があります。対話型の業務アシスタントを自社で組み立てる製品で、外部で動いている別のモデルをつないだ場合、そのモデルからの生成物は、同社のクラウドで動き所定の条件を満たすものでない限り、補償の対象外になると説明されています（2025年6月1日から）。つないだモデルが変われば、補償の有無も変わるということです。

条件は、厳しくなる方向にだけ変わるわけではありません。同じ技術文書によれば、開発支援の製品については2026年4月3日から追加の軽減策が求められなくなり、それまで必要だった公開コードとの重複を検出する機能の利用も、補償の条件ではなくなりました。以前の条件のまま社内ルールを作っていると、実態と合わなくなることがあります。対象と条件は、文書の更新日とあわせて確かめます。

外れる条件2：安全機能やフィルターを切った・使わなかった

2つ目の型は、提供元が用意した安全のための仕組みを使わなかった場合です。マイクロソフトは、製品に組み込まれたフィルターなどの安全機能を無効にしたり、回避したりしていないことを条件としています。オープンAIについても、提供された引用・フィルター・安全機能を無効にした、無視した、使わなかった場合を除外すると定めている例があります。便利さのために設定を緩めることが、そのまま補償を手放すことになりうるわけです。

クラウド版の生成AIを自社の仕組みに組み込む場合、条件はさらに具体的になります。マイクロソフトの技術文書では、文章を生成する用途について、既存の文章の再現を見つけるフィルターと、指示の乗っ取りを防ぐフィルターを、検出したら止める設定で有効にすることが求められています。加えて、侵害を避けるよう指示するシステム側の指示文を入れること、第三者の内容が出力されないかを評価し、その結果と対策の報告を保管することも条件に挙がっています。

細かな点ですが、見落とされやすい規定もあります。同じ文書では、生成した文章をあとから検査する方式のフィルターを使う場合、後から保護対象の素材と判定された出力は補償の対象外になると説明されています。また、新しい軽減策が追加されたときは、掲載から6か月以内に実装する必要があるとされています。一度設定して終わりではなく、条件の更新を追い続ける必要があるのです。

外れる条件3：侵害を知っていた・似せる指示をした

3つ目の型は、利用者の側に侵害の意図や認識があった場合です。グーグルは、利用者が意図的に他人の権利を侵害するために生成物を作ったり使ったりしていないことを条件にしています。マイクロソフトも、侵害する素材を作ろうとしないことを求めています。オープンAIについては、利用者が生成物の侵害を知っていた、または知るべきだった場合を除外すると定めている例が紹介されています。

実務で問題になりやすいのは、指示文の書き方です。特定の作品の登場人物、特定の作家や画家の名前、特定の商品の見た目などを挙げて「これに似せて」と指示すれば、似たものが出てくることを予想していたと受け取られるおそれがあります。「知っていた」「意図した」の判断材料になりうるのは、残っている指示文そのものです。

「知るべきだった」という言葉にも注意が要ります。明らかに有名な作品にそっくりな画像が出てきたのに、確かめずにそのまま使った、といった場合がこれに当たるかどうかは、最終的には個別の判断になります。社内では、似ていると気づいた生成物は使わず、作り直すという決まりを置いておくほうが安全です。どこからが「知るべきだった」に当たるかの解釈は、法務に確かめてください。

外れる条件4：使う権利のない素材を入力した

4つ目の型は、入力に関するものです。補償が守るのは、原則として提供元のサービスが生成したものについての主張です。利用者が入力した素材そのものの権利は、利用者の責任とされます。オープンAIについては、利用者が入力や追加学習の素材を使う権利を持っていなかった場合を除外すると定めている例があり、マイクロソフトも、使う権利のない素材を入力しないことを求めています。

よくあるのは、他社の広告画像や雑誌の写真を読み込ませて「この雰囲気で作って」と頼む使い方です。また、購入した素材集の画像を入力に使う場合も、その素材集の利用条件が生成AIへの入力を認めているかは別に確かめる必要があります。入力に使った時点で、補償の前提から外れる素材があることを知っておきます。

社内の資料でも同じことが起きます。取引先から預かった資料、外部の制作会社が作った原稿、写真家から借りた画像などは、自社が自由に使える素材とは限りません。入力してよい素材の範囲を、自社で作ったもの、権利を確かめたもの、に絞ると決めておくと、この条件から外れる事故を減らせます。

入力には、ふだんの指示文だけでなく、自社向けにモデルを調整するための学習用の素材も含まれます。オープンAIについて紹介されている除外の条項でも、入力と並んで追加学習の素材が挙げられています。過去の広告や他社の記事を集めて自社専用のモデルを調整しようとする場合は、その素材の一つひとつについて使う権利があるかを確かめてから進める必要があります。

外れる条件5：生成物を改変した・他の製品と組み合わせた

5つ目の型は、生成したあとの扱いです。オープンAIについては、生成物が改変・変換された場合や、同社以外の製品やサービスと組み合わせて使われた場合を除外すると定めている例が紹介されています。生成物をそのまま使うことは少なく、文章を書き直したり、画像を加工したりするのが普通なので、この条件は実務への影響が大きいと考えられます。

どの程度の手直しが「改変」に当たるのかは、公表された文書からは読み取れないことが多く、ここでは断定できません。誤字を直す程度と、別の画像と合成して新しい広告を作る程度とでは、扱いが違う可能性があります。重要なのは、侵害だと主張された部分が、生成された時点で既にあったのか、人が加えた手直しで生まれたのかを、あとから説明できるようにしておくことです。

そのためには、生成したままの状態と、手直しを加えたあとの状態の両方を保存しておくのが確実です。広告や資料に使う画像であれば、元の生成物、使った指示文、加工の内容を1組にして残します。手直しの前と後が残っていれば、どこが問われているのかを切り分けられるので、補償を求めるときの材料にもなります。

外れる条件6：商標など、著作権以外の権利

6つ目の型は、守られる権利の範囲です。見出しでは「著作権の補償」と呼ばれていても、実際の約束がどの権利を対象にしているかは各社で書き方が異なります。グーグルの説明は知的財産という広い言葉を使っていますが、オープンAIについては、利用者が生成物を商取引で使ったことに基づく商標などの権利の主張を除外すると定めている例が紹介されています。

マーケティングの現場で特に気をつけたいのが、この商標の扱いです。生成した画像に他社のロゴに似た図柄が入っていた、生成した商品名やキャッチコピーが他社の登録商標と重なっていた、といった問題は、著作権ではなく商標の問題として扱われることがあります。広告やパッケージに使うものほど、補償の外にある権利に触れやすいのです。

このほか、人物の肖像や、実在の人物に似た声、特定の地域や団体の名称なども、著作権とは別の権利や規制の問題になりえます。補償の対象に入っているかどうかは、契約の文言を法務が読んで確かめるしかありません。社内では、商品名・ロゴ・人物が入る生成物は、補償の有無にかかわらず個別に確認すると決めておくのが現実的です。

外れる条件7：手続きと記録を守れない

最後の型は、訴えられたあとの手続きです。先に触れたとおり、マイクロソフトは、補償を求めるときに関連する条件をすべて満たしていたことを示す必要があると説明しています。フィルターの設定や評価の報告を求められたときに出せなければ、条件を満たしていたと示すことが難しくなります。条件を守っていても、守っていた記録がなければ示せないということです。

一般に、補償の約束には、請求を受けたら提供元に知らせること、防御の進め方を提供元と調整すること、必要な情報を提供することといった手続きが組み合わされていることが多いものです。具体的な期限や協力の範囲は契約によって異なるので、ここでは一律に書きません。自社の契約で、知らせる期限、知らせる先、自社で勝手に和解してよいかどうかを確かめておきます。

また、補償に上限額が付いているかどうかも、契約ごとに確かめる項目です。上限の有無や金額は、公表された説明だけでは分からないことがあり、個別の契約書や注文書に書かれている場合もあります。どの文書のどこに書かれているかを、次の章のチェックリストと合わせて一度書き出しておくと、いざというときに慌てずに済みます。

補償が外れる条件のチェックリスト

ここまでの7つの型を、社内で使える形のチェックリストにまとめます。1つでも当てはまれば、その使い方は補償の外にある可能性があります。当てはまるかどうかの最終的な判断は、原文を読んだ法務が行います。

チェックリストは、生成AIを使うすべての場面で毎回確かめるものではありません。社外に出すもの、特に広告・製品・販売物に使うものに絞って確かめるほうが、現場に定着しやすくなります。社内の会議資料や下書きにまで同じ確認を求めると、誰も守らなくなります。

自社の契約で確かめる手順

チェックリストの前提になるのは、自社の契約に何が書かれているかです。補償の条件は、利用規約、製品ごとの条項、技術文書、個別の注文書などに分かれて書かれていることがあり、1つの文書を読んだだけでは全体が分かりません。次の順に確かめます。

この作業の結果は、法務だけが持つのではなく、生成AIを実際に使う部署にも分かる言葉で共有します。条文の言葉のままでは現場に伝わらないので、「この設定は変えない」「この指示は書かない」という形に置き換えて伝えるのが効果的です。

こうすると補償が外れる、という使い方

条件を現場の行動に置き換えると、避けるべき使い方が具体的に見えてきます。次のような使い方は、どれも悪気なく選ばれやすいものです。

• 出力が止められるのが面倒で、管理画面のフィルターを緩める：安全機能を切ったことになり、前提から外れうる
• 有名な作品の名前を挙げて「この画風で」と頼む：似せる意図があったと受け取られるおそれがある
• 他社の広告画像を読み込ませて参考にさせる：使う権利のない素材を入力したことになりうる
• 社員が個人のアカウントで作った画像を広告に使う：法人契約の補償の対象に入らない
• 生成した画像を別の素材と合成し、元の生成物を消す：どこが問われたのかを切り分けられなくなる
• 便利そうな外部のモデルを勝手につなぐ：つないだモデルの出力が対象外になることがある

これらの使い方に共通するのは、現場の担当者が「補償があるから大丈夫」と思い込んでいる点です。補償の条件を知らないまま便利な方向に寄せると、守られていると思っていた範囲から外れていくのです。

社内ルールへの落とし方：補償が効く使い方に寄せる

社内ルールにするときの考え方は、補償の条件を満たす使い方を、いちばん楽な使い方にしておくことです。たとえば、フィルターなどの安全機能の設定は個々の利用者に触らせず、管理者だけが変えられるようにします。設定を変えるときは、補償への影響を法務と確かめる手順を挟みます。こうすれば、便利さのために設定を緩める判断が、現場で勝手に行われないようになります。

指示文については、禁止する書き方を具体的に示します。特定の作品名・作家名・商品名を挙げて似せる指示は書かない、他社の制作物を入力に使わない、といった形です。あわせて、社外に出す生成物については、指示文・生成したままの状態・手直しの内容を1組にして保存する決まりを置きます。記録は、条件を満たしていたことを示すための材料になります。

契約の面では、社員が個人のアカウントで生成したものを業務に使わないことを明記し、法人契約のアカウントを必要な人に配ります。外部のモデルをつなぐときや、新しいサービスを使い始めるときは、補償の有無と条件を確かめてから許可する流れにします。ルールは、条件の改定に合わせて年に1回以上見直すようにしておきます。

ルールを作っても、使う人が知らなければ効きません。新しく生成AIを使い始める人には、補償の条件を踏まえた「してはいけない使い方」を短く説明する時間を設けます。さらに、広告や販売物の入稿の流れにチェックリストの確認欄を組み込めば、確認が個人の注意力に頼らない形になります。確認欄に記録が残ることは、それ自体が条件を守っていたことを示す材料にもなります。

AIに条項を下読みさせる範囲と、法務が原文で読む範囲

補償の条件を確かめる作業のうち、AIに任せやすいのは下読みです。利用規約や製品条項の文書を渡し、補償に関わる条項を抜き出させ、対象・除外・手続き・上限の4つに分けて一覧にさせる。複数の提供元の文書を並べて、同じ型の条件がどこに書かれているかを対応させる。長い文書を読む手間が大きく減ります。

• 抜き出させるときは、条項の番号と原文の文言をそのまま書かせ、要約だけで済ませない
• 見つからなかった項目は「見つからない」と書かせ、推測で埋めさせない
• 文書の版の日付を必ず記録させ、古い版と混ぜない

反対に、AIに判断させてはいけないのは、自社が対象に入るかどうか、自社の使い方が条件を満たしているかどうかです。AIの要約は条文の細かな言い回しを落とすことがあり、除外の条件を読み違えることもあります。根拠として原文のどこを読んだかを書かせ、最後は法務が原文で確かめるという線を守ってください。AIは読む手間を減らす道具であって、契約の解釈を任せる相手ではありません。

まとめ

生成AIの著作権補償は、生成物が第三者の権利を侵害していると主張されたときに提供元が防御を引き受けるという約束ですが、無条件ではありません。対象外の契約やサービスで生成した、安全機能やフィルターを切った、侵害を知っていた・似せる指示をした、使う権利のない素材を入力した、生成物を改変した、商標など著作権以外の権利が問われた、手続きや記録を守れなかった、といった場合には外れる可能性があります。各社の条件は改定されるので、自社の契約について、補償が書かれた文書、対象のサービス、除外の条件、上限額、手続きを原文で確かめ、更新を追う担当を決めておきます。社内ルールは、補償が効く使い方をいちばん楽な使い方にする方向で作ります。AIには条項の抜き出しと一覧づくりの下読みを任せ、根拠の箇所を書かせたうえで、対象かどうかは法務が原文で判断します。まずは社内で使っている生成AIのサービスと契約の種類を一覧にするところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。