生成AIを組み込んだ受託開発と著作権｜AI生成コードの権利処理・表明保証・OSS混入を弁護士が解説

「GitHub Copilotを入れて、開発スピードは確かに上がりました。ただ、大手のお客様から回ってきた契約書に『本件成果物に関する著作権その他一切の知的財産権は、検収完了と同時に委託者に移転する』と書いてあります。AIが書いた部分も含めて、これは譲渡できるのでしょうか」——受託開発を手がける会社から、こうしたご相談を受けることがあります。逆に発注する側からは「ベンダーがAIでコードを書いているようだが、うちが納品物を使って訴えられたときは誰が責任を持つのか」というご質問が寄せられます。

結論から申し上げると、この問題は「AI生成コードの著作権は誰のものか」という問いの立て方をしている限り、契約書は書けません。AIが生成した部分には、そもそも著作権が発生していない可能性があるからです。存在しない権利は、譲渡条項をどれだけ強く書いても移転しません。にもかかわらず現場の契約書は「全成果物の権利を移転する」という一文で処理し続けており、そこに第三者権利侵害の表明保証（非侵害保証）が重なることで、ベンダー側が実質的に無限責任を負う構造ができあがっています。

この記事では、文化庁「AIと著作権に関する考え方について」（令和6年3月15日・文化審議会著作権分科会法制度小委員会）を一次資料に、①AI生成部分に著作権は発生するのか、②「全成果物の著作権譲渡」条項とAI生成コードの緊張関係、③第三者権利侵害の表明保証をどちらが持つのか、④契約書に現れ始めた「AI利用の申告義務」条項、⑤OSSライセンス混入との二重リスク——を、発注側とベンダー側の双方の視点から整理します。あわせて経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」（平成30年6月）および「AIの利用・開発に関する契約チェックリスト」（令和7年2月）を参照します。

AI生成部分に著作権は発生するのか｜「譲渡できないもの」を譲渡する契約になっていないか

最初に押さえるべきは、AI生成物の著作物性です。ここが定まらないと、権利帰属条項も表明保証条項も設計できません。AI開発から社内でのAI利用までを含めた全体像はAI開発・AI活用の法律問題 総合ガイドで俯瞰できます。

著作物の定義に立ち返る｜「思想又は感情を創作的に表現したもの」

著作権法2条1項1号は、著作物を「思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するもの」と定義します。ソフトウェアについては同法10条1項9号が「プログラムの著作物」を例示しています。ただし同法10条3項は、その保護は「その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない」と明記しています。アルゴリズムそれ自体、APIの呼び出し規約それ自体は、AI利用の有無を問わず著作権では守られません。

そして自社の従業員が業務として書いたコードについては、同法15条2項が「法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする」と定めており、何もしなくても会社に帰属します。問題は、そのコードの一部または大部分をAIが生成した場合に、この15条2項が乗る「著作物」が存在しているのかという点です。

文化庁が示した3つの判断要素｜プロンプト・試行回数・選択

文化庁の考え方は、AI生成物の著作物性について「個々のAI生成物について個別具体的な事例に応じて判断されるものであり、単なる労力にとどまらず、創作的寄与があるといえるものがどの程度積み重なっているか等を総合的に考慮して判断される」とし、判断要素として次の3つを挙げています。

① 指示・入力（プロンプト等）の分量・内容——「創作的表現といえるものを具体的に示す詳細な指示は、創作的寄与があると評価される可能性を高める」。他方で「長大な指示であったとしても、創作的表現に至らないアイデアを示すにとどまる指示は、創作的寄与の判断に影響しない」とされています。ここは実務で誤解が生じやすい箇所です。長いプロンプトを書いたから権利が生まれるわけではありません。

② 生成の試行回数——「試行回数が多いこと自体は、創作的寄与の判断に影響しない」。ただし「①と組み合わせた試行、すなわち生成物を確認し指示・入力を修正しつつ試行を繰り返すといった場合には、著作物性が認められることも考えられる」とされています。③ 複数の生成物からの選択——「単なる選択行為自体は創作的寄与の判断に影響しない」とされ、候補から選んだだけでは足りません。

さらに重要なのは、加筆・修正に関する記述です。文化庁の考え方は「人間が、AI生成物に、創作的表現といえる加筆・修正を加えた部分については、通常、著作物性が認められる」としつつ、「もっとも、それ以外の部分についての著作物性には影響しない」と述べています。つまり著作物性は成果物全体で一括判定されるのではなく、部分ごとに判定されるという整理です。

成果物が丸ごと無権利になるわけではない

ここで双方が安心してよい点を確認しておきます。文化庁の考え方は「人間による、ある作品の創作に際して、その一部分にAI生成物を用いた場合、（中略）AI生成物の著作物性が問題となるのは、当該AI生成物が用いられた一部分についてであり、仮に当該一部分について著作物性が否定されたとしても、当該作品中の他の部分、すなわち人間が創作した部分についてまで著作物性が否定されるものではない」と明記しています。つまりCopilot等の補完で書かれた行が混じっていることを理由に、システム全体の著作物性が否定される事態は想定しにくいということです。危険なのは「全部が無権利になること」ではなく、「どこが権利で守られ、どこが守られていないのかが誰にも分からないまま、権利で守られている前提の条項だけが並んでいること」です。

AI関与の態様と契約上の扱いを対応させる

「著作物性がない」は「自由に使われてよい」と同義ではない

著作物性が否定されても、守る手段がなくなるわけではありません。文化庁の考え方は「著作物性がないものであったとしても、判例上、その複製や利用が、営業上の利益を侵害するといえるような場合には、民法上の不法行為として損害賠償請求が認められ得る」と述べています。加えて、秘密管理性・有用性・非公知性の3要件を満たせば営業秘密として保護され得ますし、契約で「使ってよい範囲」を書けば、その違反は債務不履行になります。著作権が使えない領域では、契約と秘密管理が主戦場になります。

「全成果物の著作権を譲渡する」条項が、AI生成コードにぶつかるとき

受託開発契約の権利帰属条項は、多くの場合ひとつの文で書かれています。「本件成果物に関する著作権（著作権法27条及び28条の権利を含む）その他一切の知的財産権は、委託料の完済と同時に委託者に移転する」——この一文が、AI生成コードの存在によってどう機能不全を起こすのかを見ます。AI開発の委託契約書全体のチェック順序はAI開発委託契約書のチェックポイントで整理しています。

存在しない権利は移転しない｜譲渡条項は静かに空振りする

譲渡条項は、対象となる権利が存在していることを前提とします。AI生成部分について著作権が発生していなければ、移転するものは何もありません。しかもこの空振りは納品の時点では誰にも見えません。動くシステムが納品され、検収が通り、代金が支払われる。問題が表に出るのは、発注側が第三者からクレームを受けたとき、あるいは成果物を自社の別事業や他社への提供に転用しようとしたときです。このとき発注側は「権利は全部当社に移転しているはずだ」と主張し、ベンダー側は「あの部分に著作権は発生していないので、当社が持っていた権利も存在しない」と応じます。契約書の文言はどちらの主張も否定しないため、交渉が長引きます。

発注側が本当に欲しいのは「権利」ではなく「使える状態」

経済産業省のAI編ガイドラインは、実務では「何か問題があると困るため、とりあえず権利を全て取得しておけば安全である」との発想に陥るケースが散見されると指摘し、権利帰属をめぐる議論に多大なコストを費やすことが常に必要とは限らないと警告しています。この指摘は、AI生成コードが混在する受託開発でより強く当てはまります。権利を取得しても、その権利が存在しなければ何も得られないからです。

発注側が実現したいことを分解すると、たいていは次の4つに収まります。①納品後も自社で自由に改変・保守できる、②別のベンダーに保守を引き継げる、③自社グループ内・自社の顧客向けに展開できる、④ベンダーが同じものを競合他社に提供しない。この4つは、いずれも権利の移転がなくても、利用許諾と制限条項で実現できます。契約上の債務として組み立てるため、対象物に著作権が発生しているかどうかに左右されません。

「譲渡」から「利用権＋制限」へ組み替える4つの部品

もっとも、実務では権利譲渡条項を全面的に取り下げる交渉は通りにくいのが現実です。現実的な着地は、譲渡条項は維持したまま「譲渡の対象に著作権が発生していない部分については、本条に定める内容の利用を許諾する」という受け皿の一文を足すことです。これで、著作物性が争点になっても発注側の目的は達成され、ベンダー側は存在しない権利について責任を追及されずに済みます。契約書の一般的なチェック観点は契約書チェックの50項目および業務委託契約書のチェックポイントで整理しています。知的財産の帰属条項そのものの設計は委託契約における知財の帰属もあわせてご覧ください。

実際に届くご相談の形｜「うちの権利にするか、譲るか」から始まる

弁護士法人ブライトの顧問先からも、この論点は繰り返し寄せられます。特徴的なのは、相談の入り方が「AI生成コードの著作権はどうなりますか」ではないという点です。実際に届くのは、Web制作や広告制作物を受託している会社からの「制作物の著作権を自社に残すか、クライアントに譲渡するか、譲渡するならどんな条項を入れるべきか」という相談であり、同じ時期に同じ会社から「生成AIで作成した画像を広告に使うときのリスクと、回避のための注記の書き方」という別の相談が来ます。会社の中では、この2つは別の話として扱われています。

また、受託開発を手がけるITスタートアップからは、大手顧客との契約について「成果物の権利帰属の時期、契約不適合責任の範囲、再委託時の責任上限、そして知的財産権の非侵害保証の妥当性」をまとめて確認したいという形で相談が来ます。これらは1本の契約書の中で連動しており、権利帰属だけを直しても表明保証が残っていればリスクは減りません。さらに、過去に代表者個人が作成したプログラムの著作権が会社に帰属しているのかが、事業譲渡や増資の局面で初めて論点になるケースもあります。

第三者権利侵害の表明保証（非侵害保証）は、どちらが持つのか

権利帰属よりも金額のインパクトが大きいのは、こちらです。「本件成果物は第三者の知的財産権を侵害しないことを受託者は保証する」という一文が、AI生成コードの混在によって性質を変えます。入力側と出力側で侵害判断の枠組みが違う点は生成AIの業務利用と著作権侵害リスクで整理しています。

侵害成立の枠組み｜類似性と依拠性

文化庁の考え方は、生成・利用段階について「従前の人間がAIを使わずに行う創作活動の際の著作権侵害の要件と同様に考える必要がある」とし、既存の判例では「ある作品に、既存の著作物との類似性と依拠性の両者が認められる際に、著作権侵害となるとされている」と整理しています。類似性については「既存の著作物の表現上の本質的な特徴を直接感得することのできるもの」について認められてきたとされ、AI生成物についても同様に判断されると述べています。問題は依拠性です。生成AIの場合、学習に使われた著作物を利用者が認識していないまま、それに類似したものが生成され得ます。文化庁の考え方は、この点を3つの場合に分けています。

依拠性の3類型｜「知らなかった」がどこまで効くか

① 利用者が既存の著作物を認識していた場合——「生成AIを利用して当該著作物の創作的表現を有するものを生成させた場合は、依拠性が認められ、AI利用者による著作権侵害が成立すると考えられる」とされています。既存の著作物そのものを入力する場合や、特定の固有名詞を入力する場合が例示されています。

② 認識していなかったが、学習データに当該著作物が含まれる場合——「客観的に当該著作物へのアクセスがあったと認められることから、（中略）当該著作物に類似した生成物が生成された場合は、通常、依拠性があったと推認され、AI利用者による著作権侵害になりうる」とされています。ここが実務上もっとも重い記述です。知らなかったことは、依拠性の否定に直結しません。ただし、学習した著作物の創作的表現が生成段階で出力されない状態が技術的に担保されていると法的に評価できる場合には、利用者がその事情を主張することで依拠性が否定される場合はあり得るとも述べられています。

③ 認識しておらず、学習データにも含まれない場合——「偶然の一致に過ぎないものとして、依拠性は認められず、著作権侵害は成立しない」とされています。

「知らなかった」で消えるもの・残るもの

侵害が認められた場合に受け得る措置は、故意・過失の有無で変わります。文化庁の考え方は、差止請求は「故意及び過失の有無を問わず可能」、損害賠償請求は「侵害者に故意又は過失が認められることが必要」、刑事罰は「侵害者に故意が認められることが必要」と整理し、故意・過失が認められない場合には「受け得る措置は、差止請求に留まり、刑事罰や損害賠償請求の対象となることはない」と述べています。ただし続けて、認識していなかった場合でも「不当利得返還請求として、著作物の使用料相当額として合理的に認められる額等の不当利得の返還が認められることがあり得る」としています。

この表がベンダー側に示しているのは、「うちは知らなかった」という主張は損害賠償を防ぐ盾にはなり得ても、差止めは止められないということです。システム開発では、差止め＝稼働停止・改修工数が最大のコストになります。

無限定の非侵害保証が飲めない理由と、限定の4パターン

ベンダー側が無限定の非侵害保証を負えない理由は、調査が原理的に完了しないことにあります。自社が使っている生成AIの学習データに何が含まれているかを、ベンダーは確認できません。文化庁の考え方が示す②の類型では、学習データに含まれていれば通常は依拠性が推認されます。つまりベンダーは、自分で確認できない事実を保証の対象にしていることになります。これは調査を尽くしても消えないリスクです。

4つのうち、交渉が着地しやすいのは3番目の対応義務型です。発注側が本当に困るのは「金銭賠償が足りないこと」ではなく「システムが止まること」だからです。賠償額の上限を争う前に、「侵害を申し立てられたときに誰が何をするか」を先に決めるほうが、双方にとって実利があります。

「AI利用の申告義務」条項｜契約書に現れ始めた新しい実務

ここ数年、受託開発契約に新しい類型の条項が入り始めています。「受託者は、本件業務の遂行において生成AIを利用する場合、事前に委託者へ書面により通知し、承諾を得るものとする」という趣旨の条項です。従来の契約書には存在せず、ひな形の蓄積もないため、書きぶりの差が実務に大きく効きます。

なぜ発注側が申告を求めるのか

発注側の動機は3つあります。第一に、成果物を実際に使うのは発注側であり、差止請求を受ける立場に立つのは発注側だからです。前掲のとおり差止めは故意・過失を問いません。第二に、発注側自身がその成果物を自社の顧客に提供している場合、顧客に対して同じ非侵害保証を負っているためです。第三に、秘密情報のインプット問題です。

この第三の点について、経済産業省の契約チェックリストは「（学習目的利用であるかにかかわらず）第三者が知的財産権又は法的に保護された権利利益を有する情報をインプットとして提供することは、権利侵害となる可能性がある。例えば、第三者の著作物をインプットとして提供する際に、権利制限規定の適用がされない場合には、複製権や翻案権、公衆送信権等の著作権を侵害するおそれがある」と指摘しています。ベンダーが発注側から預かった仕様書・設計書・既存コードを生成AIに入力する行為自体が、契約違反や権利侵害を構成し得るということです。同チェックリストは、秘密保持契約等で「第三者」への提供が禁止されている場合について「『第三者』の範囲は一様ではなく、各種の法令や契約ごとに異なる意義を有していることが通常であり、個別の検討を要する」とも注意を促しています。AIサービス提供事業者が秘密保持契約上の「第三者」に当たるかは、契約文言ごとに読み分ける必要があります。社内でAI契約書レビューを使う場面の落とし穴はAI契約書レビューの落とし穴で、SaaS利用にともなうIT法務の全体像はSaaS・IT企業の法務で整理しています。

申告義務条項の3つの設計レベル

どのレベルを選ぶかは、成果物の性質で決まります。発注側が第三者にそのまま再提供する成果物であれば事前承諾型に寄せる合理性があり、社内利用にとどまる業務システムであれば事後報告型で足りることが多いはずです。一律に禁止型を入れると、契約と現場が乖離し、いざ問題が起きたときに「そもそも守られていなかった条項」として双方の主張が崩れます。

ベンダー側の受け方｜「棚卸しできるか」を先に確かめる

申告義務条項を提示されたベンダーが最初にすべきことは、文言交渉ではありません。自社の開発環境で、どのAI機能が、誰の権限で、どの情報を外部に送っているかを列挙できるかどうかの確認です。IDEの補完機能、コードレビュー支援、テストコード生成、ドキュメント生成、翻訳——このうちどれが「生成AIの利用」に当たるのかは条項の定義次第で変わります。列挙できないうちに事前承諾型を受けると、契約締結の翌日から違反状態が始まります。そのうえで交渉すべきは、①「生成AI」の定義（ローカル実行の補完機能を含むか、学習に用いられない設定を含むか）、②申告の単位（プロジェクト単位か、ツール単位か）、③申告漏れがあった場合の効果（解除事由とするのか、是正機会を与えるのか）の3点です。特に③を定めずに事前承諾型を受けると、軽微な申告漏れが解除事由に読まれる余地が残ります。

OSSライセンス混入｜AI生成コードと重なる二重リスク

AI生成コードの話をしていると、必ずもう一つのリスクが顔を出します。オープンソースソフトウェア（OSS）のライセンス混入です。この2つは似て見えますが、リスクの経路が違います。混同したまま1本の条項で処理すると、どちらも防げません。

別の経路で入ってくる2つのリスク

AI生成コードのリスクは「生成されたものが既存の著作物に類似し、依拠性が推認される」経路で発生します。これに対しOSSのリスクは「他人の著作物であることが明らかなコードを、ライセンス条件に従わずに使う」経路です。前者は著作権侵害そのものが争点になり、後者はライセンス契約の違反が争点になります。厄介なのは、生成AIがOSSを学習している場合、AI生成コードとしてOSS由来のコードが入ってくる——つまり2つの経路が重なることです。

コピーレフト型ライセンスと、SBOMを納品物にする発想

OSSライセンスの中には、いわゆるコピーレフト型と呼ばれるものがあります。派生物を配布する際に同じライセンスでの提供を求め、ソースコードの開示を要求するタイプです。成果物にこうしたライセンスのコードが混入し、かつ成果物が「配布」に当たる形で提供されると、発注側が自社のソースコードの開示を求められる立場に置かれる可能性があります。しかも同じライセンスでも、社内利用にとどまるのか、SaaSとして提供するのか、顧客に引き渡すのかで結論が変わるため、「危険なライセンスの一覧表」では処理できません。

防ぐには検出の仕組みが必要です。実務では、ソフトウェア構成表（SBOM）とライセンススキャンの検査結果を、「努力義務」ではなく「納品物」として契約に書き込みます。納品物であれば、提出がなければ検収を通さないという処理ができます。あわせて、混入が発見された場合に①ベンダーの費用で代替実装する、②ライセンス条件に従った提供に切り替える、③当該機能を削除する——のどれを選ぶ権利を発注側が持つのかを先に決めておくと、発見時の交渉が短くなります。

AI生成部分の申告とOSS申告を、1本の条項で処理しない

実際の契約書で頻繁に見かける失敗は、「受託者は、本件成果物にオープンソースソフトウェアまたは生成AIにより生成された部分が含まれる場合、事前に委託者に通知する」という書き方です。OSSは「どのライセンスの、どのコードが、どこに入っているか」を特定できる情報であるのに対し、AI生成部分は「どこまでがAI生成か」の線引き自体が困難です。同じ粒度の申告を求めることに無理があります。OSSは構成表レベルの特定を求め、AI生成は利用したサービスと用途のレベルで報告を求める——という具合に、要求する情報の粒度を分けた別条項として設計し、表明保証・責任上限もこの2つで別枠にしておくと、後の交渉が整理されます。

発注側・ベンダー側のチェック順序と、弁護士に相談すべきケース

最後に、この記事の内容を自社の契約書に当てはめる順序を示します。論点が多いため、順番を間違えると議論が発散します。

契約書を開いたら、この5ステップで読む

ステップ1：権利帰属条項の対象範囲を確認する。「本件成果物」の定義に、中間生成物・ドキュメント・テストコード・環境構築スクリプトのどこまでが含まれているかを読みます。定義が広いほど、著作物性が疑わしい部分を抱え込みます。要素ごとの帰属の初期設定は学習済みモデル・学習用データの権利帰属で切り分けています。

ステップ2：譲渡条項に受け皿の一文があるかを見る。著作権が発生していない部分についての利用許諾が書かれていなければ、そこが穴です。ベンダーにとっても、後日「譲渡できていない」と責められないための防御になります。

ステップ3：表明保証と責任上限をセットで読む。責任上限条項、免責条項、そして「本契約に定める責任上限は、第三者の知的財産権侵害には適用しない」といった除外規定の有無まで通しで読みます。この除外規定が入っていると、上限を設けた意味がなくなります。

ステップ4：AI利用とOSSの申告義務の粒度を確認する。1本の条項にまとめられていないか、定義が現場で判定できる言葉になっているかを見ます。

ステップ5：自社が発注側か受託側かで、優先順位を切り替える。発注側は「止まらないこと」を優先し、受託側は「調査できない事実を保証していないこと」を優先します。

弁護士に相談したほうがよいケース

次のような場面では、条項の書きぶりだけでなく事業構造との整合を確認する必要があるため、契約書を実際に見ながらの検討をおすすめします。①成果物を自社製品に組み込んで再提供する場合——保証の連鎖が末端で切れていないかの確認が必要です。②ひな形に「責任上限は知的財産権侵害には適用しない」と書かれている場合——AI生成コードを使う開発では、この一文の意味が従来より重くなっています。③「AI利用禁止」条項を提示された場合——現場の実態と乖離していないかの確認が先です。④すでに納品済みの成果物についてAI利用の有無を問われている場合——回答の仕方が後の責任論に影響します。⑤OSS混入の指摘を第三者から受けた場合——提供形態に応じた検討が必要です。

法務部がない会社の、外部法務部として

AI生成コードの権利処理は、法律の知識だけでは判断できません。自社の開発現場でどのツールがどう使われているか、成果物を誰にどう提供しているか、その事業構造まで分かっていないと、書ける条項が決まらないからです。弁護士法人ブライトは「法務部がない会社の、外部法務部。」を掲げ、顧問より一歩、会社の中へ入って伴走します。大阪を拠点に顧問先130社以上の実名を公開しており、契約書の作成・レビューだけでなく、現場の運用に落ちるかどうかまで一緒に確認します。顧問弁護士サービスの内容はサービスのご案内、企業法務の取扱分野は企業法務のトップページでご確認いただけます。

よくあるご質問

Q. 「AIが生成した部分の著作権も当社に譲渡する」と契約書に書けば安心ですか。

A. その一文だけでは目的を達成できない場合があります。譲渡は権利が存在していることを前提とする仕組みであり、AI生成部分について著作権が発生していなければ移転するものがありません。実務では、譲渡条項に加えて「著作権が発生していない部分については本条と同内容の利用を許諾する」という受け皿の一文を置く方法が採られます。

Q. ベンダーが生成AIを使っていたことを知らずに納品を受けました。当社に責任が及びますか。

A. 成果物が第三者の著作物に類似していた場合、成果物を使用する側が差止請求を受ける可能性があります。文化庁の考え方は差止請求を故意・過失の有無を問わず可能と整理しており、「知らなかった」ことは差止めを防ぐ理由になりません。他方、損害賠償請求は故意または過失が認められることが必要とされています。契約上の表明保証と責任上限の内容を確認したうえで、ベンダーへの求償可能性を検討することになります。

Q. 受託側として、非侵害保証はどこまで受けてよいのでしょうか。

A. 一般的には、自社で調査できない事実を無限定に保証しない、という線引きが出発点になります。生成AIの学習データに何が含まれているかは受託者側で確認できないため、そこを保証の対象に含めると、調査を尽くしても消えないリスクを負うことになります。実務では「知る限り」の限定、責任上限の設定、侵害の申立てを受けた場合に代替実装や許諾取得を自らの費用で行う対応義務型への転換が用いられます。どれが妥当かは委託料の水準と成果物の提供形態次第ですので、契約書を拝見しての検討が必要です。

Q. 発注側として「成果物の権利をすべて譲渡させる」ことに法的な問題はありますか。

A. 取引上の力関係によっては、独占禁止法上の優越的地位の濫用や、下請取引の規律との関係が問題になり得ます。なお、かつて「下請代金支払遅延等防止法（下請法）」と呼ばれていた法律は、2026年1月1日に施行された改正により「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」へと名称が変わっています（同日以降はこちらが現行名です）。同法2条3項の「情報成果物作成委託」にはプログラムの作成委託が含まれ（同条7項1号）、同法5条2項2号は、委託事業者が中小受託事業者に「自己のために金銭、役務その他の経済上の利益を提供させること」によって中小受託事業者の利益を不当に害してはならないと定めています。権利の取得を求めるのであれば、対価を積算し、交渉の経緯を記録に残しておくことが要点になります。

Q. 大阪の会社ですが、AIを使った受託開発の契約について相談できますか。

A. はい。弁護士法人ブライトは大阪を拠点とし、大阪・関西の中小企業を中心に企業法務のご相談をお受けしています。受託開発契約の権利帰属条項・表明保証条項のレビュー、AI利用の申告義務条項の設計、OSS混入への対応、発注側・受託側それぞれの立場での交渉方針の検討など、契約書を拝見しながらご相談いただけます。企業法務のご相談は初回無料です。詳しくはサービスのご案内をご覧ください。

この記事の監修者

和氣 良浩（わけ よしひろ）

弁護士法人ブライト｜代表弁護士／パートナー弁護士

弁護士歴20年（2006年登録）／大阪弁護士会／大阪大学法学部卒

専門：顧問弁護士・企業法務・M&A・経営権紛争・事業再生

受託開発契約における権利帰属条項の受け皿設計、第三者権利侵害の表明保証と責任上限の組み立て、AI利用の申告義務条項の粒度調整、OSSライセンス混入への備えなど、生成AIをめぐる契約実務を継続的に相談できる顧問弁護士をお探しの方は、弁護士法人ブライトにお問い合わせください。大阪を拠点に顧問先130社以上の実名を公開しており、企業法務部の弁護士歴平均14年以上のチームで対応します。企業法務窓口：0120-929-739（平日9:00〜18:00）