AIチャットボットの誤回答の責任は、何から決めればよい？
まず「誤回答をゼロにする」という約束を求めるのをやめてください。誤回答が起きた後に誰が何をするかを、契約書の条項として決めるところから始めます。正確さの保証を交渉の起点にすると、受注側が応じられず話が止まります。
出力の正確さへの不安は、御社だけのものではありません。総務省の令和8年版情報通信白書の図表Ⅰ-2-1-8では、生成AIの利用について企業が懸念するリスクが整理されています。そこには「出力結果の正確性に関する懸念」が挙げられています（出典: 総務省『令和8年版情報通信白書』図表Ⅰ-2-1-8）。
懸念が発注側と受注側で共通しているからこそ、契約書の書き方が分かれ目になります。
最初に決める3つのこと
条項の文面を考える前に、次の3点を社内で決めてください。受注側に何を求めるかは、ここが決まってから形になります。
- 誤回答が起きたとき、御社が実際に困る場面はどこか（所要時間の目安: 30分）
- 誤った回答を誰が見つけるのか（つまずきやすい点: 「利用者が教えてくれる」という前提を置いてしまいがちです）
- 見つけた後、何時間以内に止めたいのか（所要時間の目安: 30分）
この3点が決まっていないと、受注側に求める義務の輪郭が描けません。3番目の時間は、契約書の是正期限にそのまま使います。具体的な条項の文面は、後述の「契約書に入れる5つの条項」で扱います。
「正確性の保証」を求めると交渉が止まる理由
学習済みモデルの性能は、契約を結ぶ時点では分かりません。経済産業省のガイドラインも、この前提に立って作られています（出典: 経済産業省『AI・データの利用に関する契約ガイドライン（AI編）』2018年6月公表）。
ですから「回答は常に正確であること」と書いても、受注側は受けられません。受けたとしても、履行できない条項が残るだけです。
代わりに書くのは、誤回答が出た後の検知、報告、是正の義務です。性能そのものではなく、性能が足りなかったときの手続きを約束させる形になります。この考え方の根拠は、次の見出しで詳しく扱います。
そもそも出力の正確さは契約で保証できる？
学習済みモデルの性能は、契約締結の時点では分かりません。そのため国のガイドラインも、性能を事前に確約させる前提を置いていません。保証を求める交渉ではなく、段階ごとに責任の所在を決める交渉に切り替える必要があります。
経済産業省のガイドラインが示す探索的段階型
経済産業省は2018年6月に「AI・データの利用に関する契約ガイドライン（AI編）」を公表しています（出典: 経済産業省『AI・データの利用に関する契約ガイドライン（AI編）』2018年6月公表）。
このガイドラインは、AIの開発を4段階に分け、段階ごとに契約を結ぶ探索的段階型の進め方を示しています。理由は明確です。従来型のソフトウェア開発と違い、学習済みモデルの内容や性能が契約を結ぶ時点では分からないからです。
発注する側から見ると、出力の正確さを契約時に一律で確約させる前提が置きにくいという意味になります。そこで、誤った出力が出た場合の扱いを段階ごとに決めておくことになります。
段階ごとに契約を分ける4つの区切り
ガイドラインが想定する段階と契約は次の4つです。誤回答が出たときに御社が何を言えるかは、どの段階にいるかで変わります。
| 段階 | 想定される契約 | 誤回答が出たときの位置づけ |
|---|---|---|
| アセスメント段階 | 秘密保持契約 | 実現できるかを見る段階です。精度は評価の対象外です |
| PoC段階 | 導入検証契約書 | 誤回答の多さ自体が検証結果です。是正は求めません |
| 開発段階 | ソフトウェア開発契約書 | 合意した基準に対する不足として扱います |
| 追加学習段階 | 利用契約書 | 運用中の事象として、検知と是正の義務で扱います |
御社が誤回答の責任を問えるのは、主に開発段階と追加学習段階です。PoC段階で誤回答が多いことを理由に費用の返還を求めても、契約の性質と合いません。
段階の分け方そのものの決め方は、別記事「AI開発の外注、PoCと本開発を分ける契約の決め方」で扱っています。本記事は、各段階で誰が何を負うかに絞って進めます。
責任を分ける相手は誰？開発者・提供者・利用者の区分
AI事業者ガイドラインは取組を開発者、提供者、利用者の3つの主体に分けています。契約書でも、この区分に合わせて責任範囲を書き分けます。「AIベンダ」とひとまとめにすると、誰に何を求めるのかが曖昧になります。
このガイドラインは、総務省と経済産業省が従来の3件のガイドラインを統合・改訂して取りまとめたものです。第1.0版が2024年（令和6年）に公表されています（出典: 総務省「AI事業者ガイドライン案に関する意見募集の結果及びガイドラインの公表」）。
主体の整理は次のとおりです。
| 主体 | 役割 | 誤回答に対する立場 |
|---|---|---|
| 開発者 | AIモデルを開発する | モデル自体の性質に関わります |
| 提供者 | AIを組み込んだシステムやサービスを提供する | 御社の窓口になる相手です |
| 利用者 | 提供されたAIを業務で使う | 御社がここに当たります |
御社が「利用者」に当たる場合の責任
チャットボットを外注して自社サイトに置く場合、御社は利用者であり、同時に来訪者に対する提供者でもあります。ここが見落としやすい点です。
来訪者から見れば、誤った案内をしたのは御社のサイトです。受注側との契約でどう取り決めていても、来訪者への一次対応は御社が担います。
ですから契約書では、受注側に対する請求権と、来訪者への対応手順を別のものとして考えます。
受注側が「提供者」として負う範囲
受注側が基盤モデルを自ら開発していない場合、受注側は提供者に当たります。モデルの性質そのものには手が届きません。
したがって受注側に求められるのは、組み込み方と運用の範囲です。具体的には、回答の対象範囲の設定、参照する社内文書の管理、回答できない質問の扱い、記録の保存です。
モデルの精度そのものを受注側の責任とする条項は、履行できないため実務上機能しません。求める相手と内容を一致させることが、交渉を進める前提になります。
契約書に入れる5つの条項と、その書き方の手順
誤回答の定義、検知と報告の義務、是正の期限、損害の範囲、運用開始後の追加学習の扱いの5つを、番号順に決めていきます。順番には理由があります。定義が決まらないと、後の4つはどれも書けません。
手順1から手順5までの決め方
- 誤回答を定義する（所要時間の目安: 1時間から2時間）。「間違った回答」では条項になりません。社内文書と異なる内容を答えた場合、回答できない質問に推測で答えた場合、といった形で場合を列挙します。
- 検知と報告の義務を書く（所要時間の目安: 30分）。誰が、どの手段で、何時間以内に相手へ知らせるかを決めます。受注側が自ら検知するのか、御社が通報するのかを明記します。
- 是正の期限を書く（所要時間の目安: 30分）。手順1で列挙した場合ごとに期限を変えてください。回答を止めるまでの時間と、原因を直すまでの時間は別に書きます。
- 損害の範囲と上限を決める（つまずきやすい点: 上限額の根拠を用意せずに交渉に入ると、金額だけの折衝になります）。対象に含める損害と、含めない損害を先に書き分けます。
- 運用開始後の追加学習の扱いを決める（つまずきやすい点: 御社が社内文書を差し替えた後の誤回答まで受注側の責任にすると、受注側は追加学習を引き受けません）。どちらが文書を更新するかで責任の所在が変わります。
手順4の損害の上限は、受注側の提示額をそのまま受け入れる場面が多い項目です。手順1で列挙した場合のうち、どれが実際に費用を生むのかを考えてから臨んでください。
つまずきやすい点: 「誤回答」の定義を書かずに進めてしまう
最も多いのは、定義を飛ばして是正の期限だけを決めてしまう進め方です。これをすると、事象が起きた後に「これは誤回答に当たるのか」という議論から始まります。
定義は完璧でなくて構いません。社内文書と食い違う回答、という1行だけでも、議論の起点としては十分に機能します。
実装者としての注意点: 回答ログを残す設計になっているか
契約書の条項は、記録がなければ使えません。誤回答があったと主張するには、いつ、どの質問に、どう答えたかを示す必要があります。
ここで技術的にはまりやすいのは、ログの保存期間と、参照した社内文書の版が記録されているかという2点です。回答文だけを保存していると、当時どの文書を見て答えたのかが追えません。文書を差し替えた後では、同じ質問を投げても再現しません。
ですから発注の段階で、回答ログに質問、回答、参照文書の識別子、日時を含めることと、保存期間を要件として書いてください。この1行があるかどうかで、5つの条項が機能するかが決まります。