この記事の要点
- AI開発の契約は、成果物の性能を事前に確定できないため、一括請負ではなく段階ごとの準委任契約に分けるのが基本形。精度保証は通常つきません
- 発注側が最低限おさえる論点は「学習済みモデル・パラメータの権利」「提供データの目的外利用」「精度未達時の責任と支払い」「第三者の権利侵害時の負担」の4つ
- 経済産業省が非IT企業向けに「AIの利用・開発に関する契約チェックリスト」を公開しており、ベンダーとの打ち合わせでそのまま確認事項として使えます
- 外部の生成AI・LLM APIを組み込む開発は、既存ガイドラインの想定外の論点（入力データの学習利用、API提供元の規約の連鎖、モデル変更）が追加で発生します
- 契約書のレビューより先に、目的・評価指標・提供可能データを社内で確定させるほうが、トラブル回避には効きます
AI開発の見積書と契約書がベンダーから届いたものの、どこを見れば妥当なのか分からない。そんな状態で押印の判断を迫られている方は少なくありません。原因はシンプルで、AI開発は「何ができあがるか」を契約時点で確定できないからです。仕様書どおりに動けば完成、という従来のシステム開発の物差しが使えません。この記事では、法務専任がいない会社でも契約前にベンダーへ何を確認すべきかが分かる状態を目指して、公的資料の使い方から具体的な確認項目まで整理します。なお本記事は一般的な情報の整理であり、個別案件の法的判断は弁護士にご相談ください。
目次
AI開発の契約は通常のシステム開発契約と何が違う？
最大の違いは、契約時点で成果物の性能を確定できない点にあります。AIの精度は投入する学習データの質と量に左右され、着手前には誰にも読み切れません。そのため一括請負でまとめて契約するのではなく、アセスメント→PoC→開発→追加学習という段階に分け、各段階を準委任で契約するのが公的ガイドラインの推奨する型です※2。
従来の受託開発は、要件定義で仕様を固め、その仕様どおり動くかどうかで完成を判定できました。AI開発ではこの前提が崩れます。同じアルゴリズム、同じ開発者でも、データが変われば結果が変わります。だからベンダーは「作ってみないと分からない」としか言えず、発注側は「分からないものに払えない」と感じます。この構造的なズレを、契約の切り方で吸収するわけです。
なぜAI開発では「精度○％を保証する」契約にならないのか
成果物の精度は学習データに依存し、ベンダーの努力だけでは制御できないためです。性能保証を負う契約が絶対に成立しないわけではありませんが、その場合ベンダーはリスク分を見積に上乗せするため、費用は大きく上振れします。保証を求めるほど高くなる、という関係です。
たとえば製造ラインの不良品検知。過去の不良品画像が数十件しか残っていない現場は珍しくありません。正常品が数万件あっても、検知したいNGサンプルが数十件では、学習に必要な情報量が足りません。ここで「検知率95%を保証してください」と求めても、誠実なベンダーほど受けられないのです。
ただし「保証しない＝何も約束しない」ではありません。評価に使う指標（検知漏れ率、処理時間、業務削減時間など）と、評価に使うデータセットを契約時に合意しておけば、達成・未達の判断そのものは客観的にできます。約束するのは結果ではなく、判定のルールだと考えてください。
請負契約と準委任契約、AI開発ではどちらを選ぶべきか
探索の要素が強いアセスメント・PoC段階は準委任、仕様と実現可能性が固まった実装段階は請負も選択肢になります。フェーズごとに切り替える前提で考えるのが現実的です。
| 比較軸 | 請負契約 | 準委任契約 |
|---|---|---|
| 責任の性質 | 仕事の完成義務 | 善管注意義務（適切に業務を遂行する） |
| 契約不適合責任 | あり | 原則なし |
| 報酬の発生条件 | 成果物の完成・引き渡し | 作業の遂行（工数・期間ベース） |
| 発注側のリスク | ベンダーがリスク分を見積に上乗せ／受注辞退 | 成果が出なくても費用が発生する |
| 向いているフェーズ | 要件が固まった実装・システム連携 | アセスメント、PoC、追加学習 |
準委任は発注側から見れば「成果が出なくても払う」契約です。不安に感じるのは当然でしょう。とはいえPoC段階で請負を強要すると、ベンダーは不確実性を価格に織り込むか、そもそも受けません。防御策は契約類型そのものより、期間と金額を区切って都度判断できる形にすることです。3か月・数百万円単位で区切れば、外れたときの損失は限定できます。
経産省が示す「探索的段階型」の4フェーズと契約の切り方
経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」は、①アセスメント②PoC③開発④追加学習の4段階に分け、段階ごとに契約を結ぶ「探索的段階型開発方式」を示しています※2。いきなり本開発の一括契約を結ばないための、実務上の型です。
| フェーズ | 何を決めるか | 主な成果物 | 契約類型の目安 |
|---|---|---|---|
| ①アセスメント | そもそもAIで解けるか、データはあるか | 報告書・実現可能性の評価 | 準委任（またはNDAのみで簡易実施） |
| ②PoC | 試作モデルで目標水準に届くか | 検証用モデル・検証レポート | 準委任 |
| ③開発 | 本番運用に耐える形に実装する | 学習済みモデル・システム | 準委任または請負 |
| ④追加学習 | 運用しながら精度を維持・改善する | 再学習済みモデル・運用報告 | 準委任（保守運用契約） |
期間と費用の目安は案件規模で大きく変わりますが、アセスメントは数週間、PoCは2〜3か月程度を1区切りとする例が多く見られます。金額を判断する材料としては、開発規模と工数の関係が公開されている統計も参考になります※6。重要なのは「次のフェーズに進むかを、前のフェーズの結果を見てから決められる」構造にしておくことです。
※2 経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」（2018年6月公表、2019年12月に1.1版）
※6 IPA「ソフトウェア開発分析データ集」リンク
経産省「AIの利用・開発に関する契約チェックリスト」には何が書かれている？
経済産業省が公表した、法務体制が手薄な企業・非IT企業向けの実務資料です※1。AIを「使う」契約と「開発してもらう」契約それぞれについて、確認すべき項目が質問形式で並んでいます。分量が絞られているため、ベンダーとの打ち合わせにそのまま持ち込んで確認事項として使えるのが特徴です。
チェックリストは誰向けの資料で、どこで入手できるのか
想定読者は、AIサービスを利用する側・開発を依頼する側の事業会社であり、特に法務専任がいない中小企業です※1。経済産業省のウェブサイトで無償公開されており、ダウンロードして社内で回覧できます。
使い勝手の違いは分量に出ます。契約ガイドライン本体は解説とモデル条項を含む大部の資料で、担当者が業務の合間に読み切るのは現実的ではありません。チェックリストは論点が項目化されているため、社内稟議の添付資料にも、相見積を比較する際の共通の物差しにも転用できます。
チェックリストで問われる主要項目（利用時・開発時）
問われる内容は、大きく「どんなデータを渡すか」「成果物の権利を誰が持つか」「品質をどう約束するか」「トラブル時の責任をどう分けるか」の4系統に整理できます。既存AIサービスを利用するケースと、開発を委託するケースでは重心が変わります。
| 系統 | AIを利用する場合の確認点 | AI開発を委託する場合の確認点 |
|---|---|---|
| データ | 入力データが学習に使われるか、保存期間 | 提供データの利用範囲、加工後データの権利、返還・削除 |
| 権利 | 出力物の利用範囲、二次利用の可否 | 学習済みモデル・パラメータの帰属と利用許諾 |
| 品質 | サービスレベル、仕様変更の通知 | 評価指標、評価データ、未達時の扱い |
| 責任 | 免責範囲、賠償上限 | 権利侵害時の責任分担、再委託先の管理 |
そのまま使える質問文にしておくと打ち合わせが速くなります。「当社が提供したデータは、本件以外の案件で再利用されますか」「学習済みモデルを他社に提供する予定はありますか」「精度が目標に届かなかった場合、どの時点で中止判断をしますか」。この3つを最初の面談で聞くだけでも、ベンダーの姿勢はかなり見えます。
「AI・データの利用に関する契約ガイドライン」との使い分け
契約ガイドラインはモデル条項と解説を含む詳細版※2、チェックリストは要点を絞った実務版※1です。まずチェックリストで論点を洗い出し、実際の条文交渉の段階でガイドラインのモデル条項を参照する。この順番が現実的です。
| 契約チェックリスト※1 | 契約ガイドライン（AI編）※2 | |
|---|---|---|
| 想定読者 | 法務が手薄な事業会社・中小企業 | 契約実務担当者・法務 |
| 内容 | 確認項目の質問リスト | 解説＋モデル契約書・条項例 |
| 使いどころ | ベンダー選定、社内検討、打ち合わせ | 条文の作成・修正交渉 |
論点ごとに見る資料も分かれます。開発体制と契約の切り方はガイドライン※2、社内で最初に論点を洗うならチェックリスト※1、AIの開発・提供・利用にあたって守るべき考え方は「AI事業者ガイドライン」※3、生成物と著作権の整理は文化庁が示す考え方※5、個人データを扱うなら個人情報保護法※4。どの疑問でどれを開くかを決めておくと、調べ直しの手間が減ります。
※1 経済産業省「AIの利用・開発に関する契約チェックリスト」
※2 経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」
※3 経済産業省・総務省「AI事業者ガイドライン」リンク
※4 個人情報保護委員会「個人情報保護法」リンク
※5 文化庁「AIと著作権に関する考え方について」
AI開発契約で必ず確認すべき4つの論点（知財・データ・責任・侵害）
発注側が最低限おさえるべきは、学習済みモデル・パラメータの権利帰属、提供した学習用データの利用範囲、精度未達時の責任と支払い、第三者の権利侵害が起きたときの負担。この4点です。どれか一つでも曖昧なまま進めた契約は、運用が始まってから揉めます。
学習済みモデル・パラメータの権利は発注側とベンダーどちらのものか
法律上、自動的には決まりません。学習済みモデルやパラメータは著作権や特許で明確に保護されるとは限らず、契約で権利帰属と利用範囲を書かなければ「誰のものか分からない」状態になります。
放置するとどうなるか。ベンダーは自社の資産だと考えて他社案件に転用し、発注側は自社の費用で作ったものだと考えます。両者の理解がずれたまま数年経ってから発覚する、という展開です。
実務上の落としどころは、所有権を奪い合わずに利用許諾で調整することです。用途・分野・期間・地域を限定してライセンスを設計します。発注側が本当に確認すべきは「同じモデルを競合他社に提供できるか」。ここが自社の競争力に直結します。「同業種への提供を◯年間制限する」といった限定であれば、ベンダーも受け入れやすい条件です。あわせて、そのモデルを土台に作った派生モデルや再利用モデルがどちら側の資産になるかも、条文で分けておいてください。
提供した学習用データはどこまで使われる？目的外利用と返還・削除
契約に定めがなければ、渡したデータがベンダー側の他案件で再利用されても止められない場合があります。利用目的の限定、第三者提供の禁止、契約終了時の返還・削除義務を明記するのが基本です。
確認する軸は次のとおりです。
- 利用目的の範囲（本件開発に限定されているか）
- 前処理済み・アノテーション済みデータの権利がどちらに帰属するか
- 再委託の有無と、再委託先の管理義務
- データの保存場所（クラウドのリージョン、国外に出るか）
- 個人情報を含む場合の委託先監督義務※4
- 秘密保持義務の存続期間
- 契約終了時の返還・削除の方法と証明
- アノテーション作業を外部の作業者に出す場合の情報管理
見落とされやすいのがアノテーションです。画像やテキストにラベルを付ける作業は人手が要るため外部に流れやすく、その過程で顧客情報が社外の作業者の画面に映ります。個人情報を含むデータを委託する場合、委託元には委託先を監督する義務があります※4。ベンダーの先まで確認してください。
精度が出なかったら費用は払うのか（契約不適合責任と免責）
準委任契約では、所定の作業を適切に行った時点で報酬が発生します。したがって精度が目標に届かなくても、原則として費用は支払うことになります。だからこそ「どの数値に届かなければ次に進まないか」を先に決めておくことが、発注側の最大の防御になります。
PoCの契約時に中止判断のゲート基準を置きます。たとえば「検知漏れが5%を超える場合は本開発に進まない」と決めておけば、PoCの数百万円で損失を止められます。逆にこれを決めずに進むと、「もう少しデータを増やせば改善するかもしれません」という提案に対して、断る根拠を持てません。追加投資が延々と続く構図です。
免責条項も見ておきましょう。ベンダーの免責が広すぎて善管注意義務の中身が空洞化していないか、作業内容や試行結果の報告義務が定められているか。報告義務があるだけでも、途中経過が見えないまま終わる事態は避けやすくなります。
AIの出力が第三者の権利を侵害したら誰が責任を負うのか
学習データの収集元や出力物が著作権・肖像権・個人情報を侵害した場合、契約に定めがなければ責任の所在で争いになります。基本形は、発注側が「自ら提供したデータの適法性」を、ベンダーが「自ら収集したデータと開発手法」をそれぞれ表明保証する形です。
著作権については、学習させる段階と、生成・利用する段階で法的な整理が異なります※5。この点は生成AIを組み込む開発で特に効いてくるため、出力物を社外に出す用途なら人の確認プロセスを運用に組み込む前提で設計してください。AIの出力には誤りが含まれる可能性があり、そのまま公開する運用はリスクを抱えます※3。
損害賠償の上限も確認します。受領済み委託料相当額に限定される例が多く、間接損害や逸失利益が除外されるのも一般的です。問題は、その上限が想定される実損に見合うかどうか。停止すれば業務が止まる基幹業務に組み込むなら、上限額と実損の差を認識したうえで、運用側の代替手段まで含めて設計するのが現実的な対処になります。
※3 経済産業省・総務省「AI事業者ガイドライン」リンク
※4 個人情報保護委員会「個人情報保護法」リンク
※5 文化庁「AIと著作権に関する考え方について」
生成AI・LLM APIを使う開発では、追加でどの条項を見るべき？
既存の公的ガイドラインは、自社データで学習済みモデルを作るケースを主に想定しています※2。外部のLLMをAPIで組み込む開発では、論点がずれます。追加で見るべきは、入力データの学習利用、出力物の権利と重複リスク、API提供元の利用規約との整合、モデル変更・提供終了時の対応の4点です。
「生成AI開発の契約ガイドライン」という一冊にまとまった公的資料は、現時点では整備の途上にあります。実務では、契約ガイドライン※2とチェックリスト※1で契約の骨格を押さえ、著作権は文化庁の考え方※5を、開発・提供・利用の姿勢はAI事業者ガイドライン※3を、そして各API提供元の利用規約を組み合わせて読む必要があります。
入力したデータはLLM提供元の学習に使われないか
API経由の利用では、入力データを提供元の学習に使わない扱いが一般的です。ただし契約プラン、利用するエンドポイント、リージョンによって条件が変わります。ベンダー任せにせず、提供元の規約レベルで確認してください。
確認する項目は、学習利用の有無とオプトアウトの方法、入力データの保持期間、データが保存されるリージョン、ログとして取得される範囲。国外にデータが保存される場合は、個人情報の越境移転の規制も関係します※4。契約面での有効な打ち手は、「どのモデルの、どのプランを使うか」を仕様書に明記させることです。口頭の説明だけだと、途中で安価なプランに切り替わっても気づけません。
生成物の権利は誰のものになるのか（他社と同じ出力が出るリスク）
多くのAPI提供元は、出力物に関する権利を利用者側に帰属させる建て付けをとっています。ただしAI生成物には著作物性が認められない可能性があり、他社が似た入力で類似の出力を得ることも防げません※5。生成物そのものの独占を前提にしたビジネス設計は避けるのが無難です。
では何を押さえるか。実利があるのは周辺の資産です。作り込んだプロンプト、RAGで参照する社内データベース、チューニング用に整備したデータセット、評価用のテストケース。これらの権利帰属と持ち出し可否を契約で明確にしておくほうが、事業上の価値を守れます。
API提供元の利用規約は発注者にどう連鎖するのか（バックトゥバック）
ベンダーが外部LLMを使って開発する場合、提供元の利用規約にある制限は、実質的に発注者側にも及びます。禁止用途、責任上限、免責の範囲。ベンダーとの契約が上位の規約と矛盾していないか、いわゆるバックトゥバックになっているかを確認する必要があります。
ここは見落とされやすい論点です。確認の質問は3つで足ります。「使用するモデルとプランはどれですか」「提供元の規約で禁止されている用途に、当社の想定利用は該当しませんか」「提供元起因の障害や仕様変更が起きたとき、御社はどこまで対応しますか」。3つ目に「提供元の責任範囲に準じます」とだけ返ってくる場合、その先のリスクは発注側が持つことになります。納得したうえで受けるのか、運用でカバーするのかを決めてください。
契約書の確認ポイント、発注側の目線で整理します。hikeに相談する
モデルの提供終了・バージョン変更にどう備えるか
外部モデルは提供元の判断でバージョンが上がり、旧バージョンの提供が終了することもあります。同じプロンプトでも出力の傾向が変わるため、稼働中の業務に影響が出ます。契約段階で、移行対応の費用負担と対応期限を決めておきましょう。
契約に入れておきたい項目は次のとおりです。
- モデル変更時の再検証・再チューニングを誰の費用で行うか
- 提供終了時の代替モデルへの移行支援の有無と期限
- 特定モデルに依存しない設計（切り替え可能な抽象化）を要件に含めるか
- 保守運用契約で、月次の出力品質評価をスコープに入れるか
- 評価用のテストケースを発注側に引き渡すか
運用フェーズの費用が読めないという不安は、この5つを契約時に決めておけばかなり小さくなります。
※1 経済産業省「AIの利用・開発に関する契約チェックリスト」
※2 経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」
※3 経済産業省・総務省「AI事業者ガイドライン」リンク
※4 個人情報保護委員会「個人情報保護法」リンク
※5 文化庁「AIと著作権に関する考え方について」
契約書を受け取る前に社内で決めておく7項目
AI開発の契約トラブルは、条文の巧拙より、目的・評価基準・提供データが社内で未確定なまま契約に進んだことが原因で起きます。次の7項目を発注側で確定させてからベンダーに向かうと、交渉が一気に楽になります。
- 解決したい業務課題と、成功と言える状態の定義
- 評価指標と、評価に使うデータ
- 中止判断のライン（この数値に届かなければ進まない）
- 提供可能なデータの範囲と、社内での承認
- 成果物を将来どう使いたいか（他部門への横展開、他社への提供の有無）
- 予算の上限と、フェーズごとの配分
- 社内の意思決定者と、稟議のタイミング
目的・評価指標・中止ラインをどう言語化するか
「AIで業務を効率化したい」は契約に落ちません。「現在3時間かかる作業を50%削減する」「見落としを1%以下にする」という測定可能な形にし、その数値に届かなければ次フェーズに進まないラインまで決めます。
非エンジニアでも設定できる指標はいくつもあります。作業にかかる時間、担当者の人数、月あたりの処理件数、差し戻し・やり直しの件数、問い合わせの一次回答までの時間。こうしたビジネス指標を決めるのが発注側の役割です。適合率や再現率といった技術指標は、ビジネス指標から逆算してベンダーと相談すれば決まります。順序を逆にしないでください。技術指標だけ先に決めると、数値は達成したのに現場の負担が減らない、という結果になりがちです。
提供できるデータの棚卸しと社内承認（どこで止まるか）
データの所在・量・品質・権利関係を、契約前に棚卸ししておきます。ここが未確認のままだと、PoC開始後にデータが出せず作業が止まる事故が起きます。
- データの保管場所と、システムから抽出できるかどうか
- 件数と、対象期間（季節変動をカバーできているか）
- ラベル・正解データの有無と、付ける場合の作業量
- 顧客・取引先との既存契約で第三者提供が制限されていないか
- 個人情報の有無と、匿名加工・仮名加工の要否※4
- 社内でデータ提供の承認を出せる責任者は誰か
実際によくあるのは、顧客との保守契約に「取得データを第三者に開示しない」条項があり、ベンダーへの提供が止まるケースです。契約後に法務が指摘して2か月遅延、といった事態は珍しくありません。棚卸しは技術の話ではなく、契約と承認の話だと考えてください。
発注側に不利になりがちなNG条項と修正の言い出し方
よくあるのは、成果物の権利が全面的にベンダー帰属、提供データの利用目的が無限定、損害賠償の上限が極端に低い、PoCから本開発への移行条件が未定義、の4パターンです。いずれも全面拒否ではなく、範囲を限定する形で交渉するのが現実的です。
| よくある条文 | 発注側に何が不利か | 修正依頼の一言 |
|---|---|---|
| 本件成果物の権利は一切ベンダーに帰属する | 自社データで作ったモデルが競合にも使われうる | 「当社の業種内での他社提供を◯年制限いただけますか」 |
| 提供データを本件その他の目的で利用できる | 顧客データが他案件に流用される | 「利用目的を本件開発に限定し、終了時の削除を明記してください」 |
| 賠償額は委託料の◯%を上限とする | 停止時の実損に対して上限が小さすぎる | 「上限は委託料相当額まで引き上げられますか。難しければ運用でどう補うか教えてください」 |
| 本開発への移行は別途協議とする | PoCの成否判断があいまいなまま追加費用が発生する | 「PoCの評価指標と、次に進む判断基準を契約書に入れてください」 |
ベンダー側の主張にも合理性があります。権利を渡せば同種の案件で再利用できず、賠償上限を上げればリスク分を価格に反映せざるを得ません。対立ではなく、リスクをどちらがどこまで持つかの分担調整だと位置づけて話すほうが、交渉はまとまります。
※4 個人情報保護委員会「個人情報保護法」リンク
まとめ：AI開発契約は「決められないこと」を前提に設計する
AI開発の契約は、確定できない部分をどう扱うかの設計です。要点を再掲します。
- 一括請負ではなく、アセスメント・PoC・開発・追加学習の段階に切って契約する
- 学習済みモデルの権利は所有権の奪い合いではなく、用途・期間・分野を区切った利用許諾で調整する
- 提供データの利用目的を限定し、契約終了時の返還・削除まで書く
- 精度未達でも準委任なら費用は発生する。だから中止判断のラインを先に決める
- 外部の生成AIを使うなら、API提供元の規約まで遡って確認する
次の一歩は3ステップです。まず経済産業省のチェックリスト※1をダウンロードして社内で埋め、次に提供可能なデータの棚卸しを行い、その状態でベンダーに相談してください。この順番を守るだけで、届いた契約書のどこを見ればよいかが自分で判断できるようになります。なお本記事は一般的な整理であり、個別案件の法的判断については弁護士にご確認ください。
※1 経済産業省「AIの利用・開発に関する契約チェックリスト」
よくある質問
AI開発契約書のひな形はどこかで手に入りますか
経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」にモデル契約書と条項例が収録されています※2。ただしそのまま使えるものではなく、対象データの種類、フェーズの区切り方、権利の配分は案件ごとに調整が必要です。ひな形は交渉の出発点であって、完成品ではないと考えてください。
NDA（秘密保持契約）はいつ締結すべきですか
データの概要を見せる前、つまりアセスメント段階に入る前が原則です。サンプルデータの受け渡しを伴う場合は、NDAだけでは足りません。利用目的の限定、保存場所、再委託の可否、返還・削除の方法を定めたデータ提供の条項を別途用意する必要があります。
PoCで作ったモデルをそのまま本番で使えますか
多くの場合、そのままでは使えません。PoCの成果物は検証を目的とした試作であり、本番運用に必要な処理速度・監視・障害対応・保守の対象外とされているのが一般的です。PoC契約の時点で、成果物の利用範囲と本番転用の可否を確認しておいてください。
開発途中でベンダーを変更できますか
ソースコード、学習用データ、前処理スクリプト、学習済みモデル、設定パラメータの引き渡し条項がなければ、事実上できません。特に前処理スクリプトと評価用テストケースは移行の可否を左右します。引き渡す成果物の範囲を、契約書に具体的に列挙しておくことが唯一の備えです。
補助金を使う場合、契約上の注意はありますか
交付決定前に契約・発注をすると補助対象外になる制度が多く、契約締結のタイミングが重要になります。2026年時点の制度でも、対象経費や申請要件は年度ごとに変わります※7。着手前に必ず最新の公募要領で確認し、必要なら契約書の日付やフェーズ分割の設計を制度側に合わせてください。
契約書のレビューは弁護士に頼むべきですか
金額規模と、そのAIへの事業依存度で判断します。基幹業務に組み込む、あるいは数千万円規模になるなら依頼する価値があります。その際は、学習済みモデルの権利帰属やデータ利用といったAI特有の論点を扱った経験があるかを確認してください。一般的なシステム開発契約の知見だけでは、論点を拾い切れないことがあります。
※2 経済産業省「AI・データの利用に関する契約ガイドライン（AI編）」
※7 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク