AI開発の契約書｜発注側が確認する7項目

AI開発の委託契約で後から揉めるのは、成果物の権利と検収の基準です。 生成AIを組み込む開発では出力にばらつきが残るため、従来のシステム開発の契約書をそのまま流用すると「完成した」の判断が割れます。加えて、生成AIが書いたコードの著作権、個人データをAIサービスに入力する条件、外部AIモデルの版数が変わったときの対応という、従来の契約書には載っていない論点が3つ増えました。

この記事では、発注側が契約書で確認する7項目を整理し、不動産会社の情報システム担当が賃貸管理の問い合わせ対応AIを委託する例に当てはめます。読み手として想定しているのは、開発会社から契約書案を受け取り、法務や経営層に回す前に自分で論点を押さえたい担当者です。

確認する7項目（一覧）

この7項目のうち、AI開発で特に差が出るのは2・3・5・6です。 1・4・7は従来のシステム開発でも問題になる項目ですが、AI開発では確認の中身が変わります。順に見ていきます。

前提：契約書の土台はIPAのモデル契約書

システム開発の委託契約には、公的なひな型があります。独立行政法人情報処理推進機構（IPA）が公開する「情報システム・モデル取引・契約書（第二版）」です。2020年4月施行の改正民法に対応した見直しを経て2020年12月に公開され、ユーザ企業とITベンダのどちらかにメリットが偏らない中立的な契約書を目指して作られています。IPAはこのモデル契約書について、契約の時点で双方がシステムの仕様、プロジェクト管理方法、検収方法等について共通理解のもと対話を深めることを期待していると説明しています（出典1）。

第二版の見直しポイントには、請負契約における契約不適合責任（報酬減額請求権の追加、損害賠償と解除の位置づけ、権利行使の期間制限）、成果報酬型準委任契約の位置づけ、中途解除の場合の報酬請求権、セキュリティ、プロジェクトマネジメント義務と協力義務、システム開発における複数契約の関係などが挙げられています（出典1）。Word形式で公開されており、自由にカスタマイズして使えます。

開発会社から届いた契約書案が、このモデル契約書のどの条項に対応しているかを確認するのが、最初の作業です。 モデル契約書から大きく外れている条項があれば、その理由を聞いてください。一方で、モデル契約書は生成AIの普及前に作られたものです。出力のばらつきを前提にした検収、生成AIが作ったコードの権利、外部AIモデルの版数変更といった論点は載っていません。以下の7項目は、モデル契約書を土台にしたうえで、AI開発のために発注側が足すべき確認事項として整理しています。

1. 請負か準委任か

AI開発では、要件定義と精度検証を準委任、実装を請負に分ける多段階の形が実務で使われます。 生成AIを組み込む開発は、作ってみないと精度が分からない部分が残るためです。最初から全体を請負にすると、開発会社は達成できる精度を低めに見積もるか、その分のリスクを金額に乗せます。逆に全体を準委任にすると、成果が出なくても報酬が発生します。

契約書のどこに契約類型が書かれているかを確認してください。表題に「業務委託契約書」とだけあり、本文を読んでも請負か準委任か判別できない契約書は少なくありません。IPAのモデル契約書は「システム開発における複数契約の関係」を見直しポイントに挙げています（出典1）。工程ごとに契約類型を分けると、前の工程の成果と後の工程の責任がどう繋がるかが問題になるため、発注側もこの点を押さえておく必要があると当社は考えています。準委任で作った要件定義書を前提に請負で実装した場合、要件定義の誤りによる不具合をどちらが負うのかは、契約書に書いておかないと判断が割れます。

2. 検収の基準

生成AIを含む開発で最も重要な条項です。「正常に動作すること」「仕様書どおりに動作すること」という表現では検収できません。 生成AIの出力は同じ入力でも表現が揺れるため、「仕様書どおり」の判定が人によって変わります。

契約書本体ではなく別紙で構わないので、次の形で書いてください。

• 評価に使うサンプルの件数と選び方（例：直近3ヶ月の実データから抽出した100件）
• そのまま使える出力の割合（例：修正なしで使えるものが○件以上）
• 人が修正する場合の上限時間（例：1件あたり○分以内）
• 明らかな誤りが出た場合の扱い（再調整の対象か、人が最終確認する運用で受け入れるか）
• 検収期間（実データで動かす日数と、期間内に発注側が指摘しなかった場合の扱い）

この基準を作るのは発注側の仕事です。 開発会社に任せると、達成しやすい基準が設定されます。ただし、発注側が一方的に高い数値を置くと見積りが跳ねるので、要件定義の段階で「現状の人手ではどの程度の精度か」を測り、それを基準にするのが現実的です。人がやっても間違える業務に対して、AIに100%を求める基準は成立しません。

検収基準が数値で書かれていると、請負契約における契約不適合の判断も明確になります。IPAのモデル契約書第二版は、改正民法で請負の契約不適合責任に報酬減額請求権が追加されたことや、権利行使の期間制限への対応を見直しポイントとしています（出典1）。基準が「正常に動作すること」のままだと、何が不適合かを争う段階で止まります。数値で書いておけば、「基準未達なら再調整、それでも未達なら減額または解除」という流れを条項に落とせます。

検収期間は、実データで一定期間動かせる長さが要ります。2週間程度あると、開発中のテストでは出なかった入力パターンを確認できます。検収期間が短すぎると、問題が納品後に発覚して不具合か仕様変更かで揉めることになります。

3. 成果物の権利

確認するのは次の3点です。

1. 著作権が譲渡されるか、利用許諾か
2. 改変してよいか
3. 他社に引き継いで改修させてよいか

3番目が抜けていると、将来別の会社に依頼できません。 開発会社を変える可能性を考えるなら入れてください。

AI開発では、ここにもう一つ論点が加わります。生成AIが書いたコードの権利です。文化審議会著作権分科会法制度小委員会が2024年3月に取りまとめた「AIと著作権に関する考え方について」では、人が何ら指示を与えず、または簡単な指示を与えるにとどまり、生成のボタンを押すだけでAIが生成したものは「思想又は感情を創作的に表現したもの」ではなく、著作物に該当しないと考えられるとされています。一方、人が思想又は感情を創作的に表現するための「道具」としてAIを使用したと認められれば著作物に該当し、AI利用者が著作者となると考えられ、その判断は人の「創作意図」と「創作的寄与」の有無によって、個別具体的な事情に応じて行われるとされています（出典2）。同文書は法的拘束力を持つものではないと明記されていますが、現行法の解釈として公的に示された整理です。

契約書への影響は次のとおりです。「成果物の著作権は発注者に譲渡する」という条項だけでは、生成AIが作った部分について譲渡すべき著作権が存在しない可能性があり、条項が空振りする恐れがあります。 対策は、著作権の帰属条項に頼りきらず、次を並べて書くことです。

• 成果物（著作物に該当するか否かを問わない）を発注側が利用・複製・改変できること
• 第三者に改修を委託できること
• 成果物の引渡義務（ソースコード・プロンプト・設定を含む）
• 開発会社が成果物を第三者に提供する場合の制限（自社の業務ロジックが他社に流用されないか）

汎用的な部品（ライブラリや開発会社が以前から持つ共通モジュール）は、開発会社側に権利が残ることがあります。これ自体は一般的ですが、その部品を含めて自社で使い続けられるか、他社に改修を委託したときにその部品が使えるかは確認してください。 併せて、生成AIの出力が既存の著作物と類似していた場合の扱いも見ておく価値があります。同文書は、AI生成物の利用が既存の著作物の著作権を侵害するかは、類似性と依拠性という通常の著作権侵害と同様の基準で判断されるとしています（出典2）。第三者の権利侵害が判明した場合の対応と費用負担をどちらが負うのか、条項で決めておいてください。

4. 納品物の範囲

契約書の成果物一覧に、次が含まれているかを確認します。

「動くもの」だけが納品物になっている契約は避けてください。 引き継げない状態になります。AI開発では、プロンプトと設定が納品物から漏れやすい点に注意が要ります。コードは渡されたが、AIへの指示文が開発会社の管理画面にしか存在しない、という状態では改修も移行もできません。

認証情報については、外部AIサービスのAPIを誰の名義で契約するかを決めてください。開発会社名義だと、契約終了時にAPIキーを引き継げず、利用料の請求先も変えられません。発注側名義で契約し、開発会社に権限を付与する形が、後の引き継ぎでは楽になります。

5. 自社データの取り扱い

開発の過程で、業務データを渡すことになります。次を明記してもらってください。

• 委託業務以外に利用しないこと
• 開発完了後のデータの扱い（返却・削除と、その証明）
• 開発で使う外部AIサービスへの入力に関する取り扱い（学習利用の禁止、保管場所、保存期間）

3番目は見落とされやすい項目です。 個人情報保護委員会は2023年6月2日付の「生成AIサービスの利用に関する注意喚起等」で、個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合には、特定された利用目的を達成するために必要な範囲内であることを十分に確認すること、また、あらかじめ本人の同意を得ることなく個人データを含むプロンプトを入力し、その個人データが応答結果の出力以外の目的で取り扱われる場合は個人情報保護法に違反することとなる可能性があるため、提供事業者が当該個人データを機械学習に利用しないこと等を十分に確認することを求めています（出典3）。

つまり、開発会社が業務データをAIサービスに入力する時点で、発注側の個人情報保護法上の義務が問われ得ます。契約書には、開発会社が使う外部AIサービスを特定し、学習に利用されない契約・設定であること、入力データの保管場所と保存期間、これらを発注側が確認できることを書いてください。開発中にテスト用として本番の顧客データを渡すなら、マスキングの範囲と方法も決めておきます。判断の観点はAI開発のセキュリティにまとめています。

6. 不具合対応の期間と範囲

納品後に問題が見つかった場合の扱いです。従来は「不具合」と「仕様変更」の2区分で足りましたが、AI開発では3つ目の区分が要ります。

3つ目が、AI開発の契約書に固有の論点です。 外部のAIモデルは開発会社が管理しているものではなく、提供元の都合で更新や提供終了が起きます。2026年7月時点の主要なモデルはChatGPTのGPT-5.6、ClaudeのOpus 5とFable 5、GeminiのGemini 3.6 Flashですが、版数は年に何度も変わり、旧版は一定期間で使えなくなります。モデルが変わると、同じプロンプトでも出力の傾向が変わり、検収時の精度を下回ることがあります。これは開発会社の過失による不具合ではなく、発注側の仕様変更でもありません。

契約書では、モデル変更が起きたときの対応（誰が検知し、誰が再調整し、費用はどうするか）を独立した条項にしてください。当社では、単発のミニ開発は納品後1ヶ月の動作フォローの中で影響を確認し、それ以降はAI開発顧問のチャット相談・コードレビューの中で影響確認と再調整の方針を扱い、再調整の実装が必要な場合は都度見積りとしています。どちらの形にせよ、契約書に書かれていないと「不具合だから無償で直せ」「仕様変更だから有償だ」の対立になります。

不具合対応の条項では、対応する期間（納品から何ヶ月か）、無償で対応する範囲、対応の期限（連絡から何営業日か）の3点も確認します。「不具合」と「仕様変更」の線引きを、例で示してもらってください。 言葉の定義だけでは、実際の場面で判断が割れます。

7. 再委託の可否

実作業を別の会社や個人に外注することは珍しくありませんが、自社のデータがどこまで共有されるかは確認しておく必要があります。

• 再委託には発注側の事前承諾を要すること
• 再委託先にも同等の秘密保持義務とデータ取扱いの義務が課されること
• 再委託先を開示してもらえること

AI開発では、外部AIサービスの利用そのものを再委託とみなすかどうかも整理しておきます。AIサービスの提供事業者は開発会社の下請けではありませんが、発注側のデータがそこに渡る点では同じです。5の条項で外部AIサービスを特定しているなら、再委託条項との重複や矛盾がないかを見てください。

業種×部門で当てはめる

7項目を実際の業務に当てはめて確認します。以下は想定の典型例で、特定の顧客の実績ではありません。

例：不動産会社の情報システム部門でAI開発の委託契約書を確認する

賃貸管理を手がける不動産会社で、入居者と入居希望者からの問い合わせ対応をAIで一次処理する開発を委託する場面を想定します。対象は、物件ポータル経由の反響メールへの返信ドラフト作成、入居者からの設備トラブルや更新手続きに関する問い合わせの分類と回答案の作成、賃貸管理システムからの物件・契約情報の参照です。契約書案を受け取った情報システム担当は、営業部門や管理部門の要望を踏まえつつ、次の順で7項目を確認します。

最初に見るのは5の自社データの取り扱いです。反響メールには入居希望者の氏名・連絡先・希望条件が含まれ、入居申込に進めば勤務先や年収、緊急連絡先の情報も扱います。これらは個人データであり、外部AIサービスに入力する前に、個人情報保護委員会の注意喚起が示す2点、すなわち利用目的の範囲内であることと、提供事業者が機械学習に利用しないことの確認が必要です（出典3）。契約書には、開発会社が使うAIサービスを名指しで特定し、学習利用の禁止と保管場所、開発中に渡すテストデータのマスキング方法を明記してもらいます。既存の賃貸管理システムがクラウドで提供されているなら、そのシステム側の利用規約でAPI連携やデータの外部送信が許されているかも、情報システム担当が確認する項目です。

次に2の検収基準です。営業部門は「反響への返信が早くなればよい」と言いますが、これでは検収できません。直近3ヶ月の反響メールから100件を抽出し、返信ドラフトのうち担当者が修正なしで送れるものの割合、修正する場合の1件あたりの時間、物件条件を誤って案内した件数を基準に置きます。ここで基準を作るのは情報システム担当と営業部門であり、開発会社ではありません。現状の人手での返信にどの程度の修正が入っているかを先に測っておくと、基準の置き方に根拠が出ます。

3と4では、プロンプトと設定が納品物に含まれているか、賃貸管理システムとの連携部分のコードを発注側で改変し、他社に委託できるかを見ます。物件紹介文や返信文の生成に使うプロンプトには、自社の接客方針や表現ルールが詰まっています。これが開発会社の管理画面にしか存在しない状態は避けます。6では、モデル変更時の対応を保守の範囲に含めるかを決め、1では要件定義と精度検証を準委任、実装を請負に分ける多段階契約になっているかを確認します。

最後に、AIに任せない範囲を契約書の仕様に書き込みます。重要事項説明は宅地建物取引士が行う法定業務（宅地建物取引業法第35条・出典4）であり、AIの役割は下書きと記載漏れの確認補助までです。契約条件の確定や入居審査の判断も人が担うと仕様に明記することで、6の不具合対応で「AIが誤って案内した」責任の範囲も明確になります。不動産業務への当てはめは不動産業のAI開発活用でも扱っています。

当社が自社で運用して分かったこと

当社は自社サイト500ページ超をAIで開発・運用し、記事の自動公開パイプラインとサイト上のAIチャットも自社で構築して運用しています。そこで実感しているのは、外部AIモデルの版数変更が想定より頻繁に起きることです。モデルが更新されると、同じプロンプトでも出力の長さや口調が変わり、パイプラインの検証項目に引っかかることがあります。当社の場合は自社運用なので都度調整しますが、これが受託開発だったら「不具合か仕様変更か」で揉める典型的な場面です。

この経験から、当社がご提案する契約では、モデル変更への対応を不具合とも仕様変更とも別の区分として扱い、対応の範囲と費用の考え方を先に決めるようにしています。また、納品物にはソースコードと仕様書に加えてプロンプトと設定を含め、他社に引き継げる状態でお渡しすることを前提にしています。

当社の契約条件と費用

業務自動化ミニ開発（300,000円〜・税抜・単発）は納品後1ヶ月の動作フォローを含み、AI組込み開発（800,000円〜・税抜・要件見積）は保守の範囲を要件に応じて見積ります。AI開発顧問（300,000円/月・税抜・最低3ヶ月）は、Claude Code環境の構築と開発伴走、社内メンバーの内製化支援、月次の開発ロードマップ設計、チャット相談・コードレビューが範囲です。モデル変更時の影響確認と再調整の方針はこのチャット相談・コードレビューの中で扱い、再調整の実装が必要な場合は都度見積りです。契約類型は、要件定義と精度検証を準委任、実装を請負に分ける形を基本にご提案しています。案件の内容によっては、全体を請負または準委任のいずれかにまとめる形もあり得ます。

初回30分の相談は無料・オンライン対応・秘密厳守です。他社から受け取った契約書案について、この記事の7項目に沿って確認すべき点をお伝えすることもできます。

商談で聞かれる質問

Q1. 契約書の確認はどこまで手伝ってもらえますか

当社が担うのは、契約書案をこの記事の7項目に沿って読み、AI開発の観点で曖昧な条項と、その条項が曖昧なまま進んだ場合に起きることを整理してお伝えするところまでです。検収基準の数値案や納品物一覧の案は、要件定義をご依頼いただいた場合に業務ヒアリングを踏まえて作成します。初回相談では確認すべき点の整理までを行います。法的な有効性の判断や条文の起案は、顧問弁護士など法務の専門家の領域です。 当社は開発者として、法務が判断するための材料を揃える立ち位置になります。

Q2. 導入後の運用は誰がやりますか

日常の運用は発注側の担当者が担います。具体的には、検収時に決めた基準で月に一度、出力の抜き取り確認を行うこと、精度が落ちたときに運用手順に沿って原因を切り分けること、モデル変更の通知を受けたときに当社に連絡することです。納品時に、これらの手順を画面付きで引き渡します。改修が必要になった場合は都度見積りです。社内で改修できる体制を作りたい場合は、AI開発顧問でコードレビューと開発伴走の形でご一緒します。「納品後の窓口はどこか」「モデル変更時の対応は誰の負担か」は契約前に確認してください。

Q3. 依頼前に何を用意すればよいですか

3点です。第一に、対象業務の現状、つまり誰が月に何時間かけていて、どの程度の頻度で間違いが起きているかの記録。これが検収基準の土台になります。第二に、扱うデータの一覧と、その中に個人データや取引先の機密がどの程度含まれるか。第三に、既存システムとの連携が必要なら、そのシステムの利用規約とAPIの有無。いずれも完成している必要はなく、初回の相談で一緒に整理できます。既に他社の契約書案があれば、それを持ち込んでいただくのが最も早い進め方です。

まとめ

• 契約書の土台はIPAのモデル契約書（第二版）。AI特有の論点は発注側が足す
• 契約で問題になるのは「成果物の権利」と「検収の基準」
• 「正常に動作すること」では検収できない。件数・割合・修正時間を数値で決める。基準を作るのは発注側の仕事
• 簡単な指示だけでAIが生成したものは著作物に当たらないと考えられる（文化庁）。譲渡条項に頼らず、利用・改変・第三者委託の許諾と引渡義務で担保する
• 個人データを含む入力は、利用目的の範囲内か・学習に利用されないかを確認する（個人情報保護委員会）
• 納品物にコード・プロンプト・仕様書が入っているか確認する
• 不具合・仕様変更に加えて「モデル変更への対応」を独立した区分にする

あわせて読みたい

• AI開発のセキュリティ｜発注前に確認すべきデータの扱い・学習利用・保管場所
• AI受託開発の進め方｜発注から納品までの流れ
• AI開発の相見積もり｜同じ条件で比べる
• AI開発の要件定義｜発注前に整理すべき5項目チェックリスト
• AI開発の保守・運用費用｜納品後にかかるAPI利用料・改修コストの内訳
• 不動産業のAI開発活用｜物件情報・問い合わせ・書類作成の自動化と費用
• システム開発会社の選び方｜東京で探す
• AI開発の記事一覧

出典

1. IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開） — ユーザ企業とITベンダの取引構造を透明化する中立的なモデル契約書。改正民法対応（請負の契約不適合責任・成果報酬型準委任・中途解除時の報酬）、セキュリティ、プロジェクトマネジメント義務と協力義務、複数契約の関係などの見直しポイント
2. 文化庁「AIと著作権について」 — 文化審議会著作権分科会法制度小委員会「AIと著作権に関する考え方について」（令和6年3月15日）とその概要、「AIと著作権に関するチェックリスト＆ガイダンス」（令和6年7月31日）。AI生成物の著作物性（創作意図・創作的寄与）、生成・利用段階の類似性・依拠性
3. 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（令和5年6月2日） — 個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する際の注意点（利用目的の範囲内であることの確認、提供事業者が機械学習に利用しないこと等の確認）
4. e-Gov法令検索「宅地建物取引業法」（昭和27年法律第176号） — 第35条（重要事項の説明等）。宅地建物取引業者は、宅地建物取引士をして重要事項を記載した書面を交付して説明させなければならない