AIチャットボットの誤回答は誰の責任になる？
誤回答の責任を一律に定めた公的基準はありません。契約での合意が分かれ目になります。
「AIが間違えたらベンダの責任」と考えて発注すると、後で困ります。公的なガイドラインは、責任の持ち主を決めてくれません。決めているのは別のことです。
公的なガイドラインが決めていること
総務省と経済産業省は共同で「AI事業者ガイドライン」を作成しています。AIの開発・提供・利用に必要な基本原則を示すものです。
このガイドラインは、事業者が自主的に取り組むための参考という位置づけです。法令のような拘束力は持ちません。従来の3つのガイドラインを統合・改訂したもので、第1.0版は令和6年に公表されました。出典: 総務省「AI事業者ガイドライン案に関する意見募集の結果及びガイドラインの公表」。
契約面では、経済産業省が2018年6月15日に「AI・データの利用に関する契約ガイドライン」を公表しています。民間事業者が契約を結ぶときの参考資料です。「データ編」と「AI編」に分かれています。
AI編は、大企業から中小企業までを契約当事者として想定しています。AIソフトウェアの開発契約とAI技術の利用契約を解説しています。出典: 経済産業省「AI・データの利用に関する契約ガイドライン」。
決めていないこと
これらの資料を読んでも、「誤回答が出たら誰が責任を負うか」は出てきません。一律に定めた公的な基準は確認できていません。
確認できるのは、次の3つの枠組みまでです。
- 性能保証を契約でどう定めるか
- 段階を分けて合意するという進め方
- 品質をどの軸で評価するか
つまり、責任の線は御社とベンダが引くことになります。引かなければ、誤回答が出た後に揉めます。
当社がAIチャットボットを構築する側として見ても、ここを曖昧にしたまま公開する案件は後で止まります。「誰が気づき、誰が直すか」を決めていないと、誤回答は放置されます。
次のセクションでは、なぜ性能を保証できないのかを整理します。ここを理解すると、契約に書くべきことが変わります。
なぜ性能を保証できないのか？
統計的な機械学習を使う以上、原理的に性能の保証が難しい場面があるとされています。これはベンダの怠慢ではなく、技術の性質です。
ここを理解しないまま「100%正しく答えること」を求めると、契約が成立しません。あるいは、形だけの保証条項が入って実態と合わなくなります。
未知の入力で起きること
機械学習は、学習したデータの分布をもとに答えを出します。母集団から離れた外れ値のような入力が来たとき、予想外の動きをすることは性質として当然とされています。
出典: 経済産業省の契約ガイドラインの策定に関わった実務家による解説。業界では常識とされる一方、一般には理解されていない点として挙げられています。
AIチャットボットで言えば、次のような入力が未知のデータに当たります。
- 想定していない言い回しや略語での質問
- 2つ以上の質問が1文に混ざった問い合わせ
- 自社に存在しないサービス名を前提にした質問
- 公開後に追加された制度や料金に関する質問
4番目は、時間が経つほど増えます。学習や参照元を更新しなければ、古い情報を自信をもって答え続けます。
技術的な性質と契約のリスク分配は別
保証が難しいことと、契約で何も決められないことは別の話です。技術的な性質と契約上のリスク分配は別の問題であり、当事者間の合意によって性能保証を定めることは可能という整理が示されています。出典: 同解説。
したがって、契約の作り方は2段構えになります。
| 決めること | 内容の例 |
|---|---|
| どこまでを保証に含めるか | 想定質問の一覧に対する正答率、対象外の入力の扱い |
| 保証できない部分をどう扱うか | 誤回答が出た場合の修正の責任と期限、免責の範囲 |
「保証する、しない」の二択ではありません。保証の範囲を狭く定め、その外側を運用で拾う形にします。
当社がAIチャットボットを構築する場合も、想定質問の一覧を作り、その範囲での動作を確認する形を取ります。一覧の外側は、運用で見つけて直す対象として扱います。契約に落とす項目は次のセクションで整理します。
契約で決めておく項目は？
誤回答の定義、直すまでの時間、直す責任の持ち主、再発時の扱いの4点を契約に落とします。この4点が決まっていれば、公開後の揉め事はほぼ防げます。
逆に、よくある「誠実に対応する」という一文だけでは何も決まっていません。誰がいつまでに何をするかが書かれていないためです。
段階を分けて合意する
経済産業省の契約ガイドラインAI編は、段階を分けて合意する進め方を示しています。学習済みモデルの内容と性能が契約の時点では確定しないためです。
示されているのは、アセスメント段階、PoC段階 (概念実証)、開発段階の3段階です。出典: 同ガイドラインの実務解説。契約を1本にまとめず、段階ごとに合意する形になります。
この考え方は、公開後の運用にも使えます。段階ごとに決める項目を整理します。
| 段階 | 決めること |
|---|---|
| 公開前 | 想定質問の一覧と、その範囲での動作確認の基準 |
| 公開直後 | 人が回答を確認する期間と頻度 |
| 定常運用 | 誤回答を直す責任の持ち主と、着手までの時間 |
| 変更時 | 制度や料金の改定を誰がいつ反映するか |
PoCと本開発の契約の分け方そのものは、当社の「AI開発の外注、PoCと本開発を分ける契約の決め方」で解説しています。
品質をどの軸で見るか
品質の評価軸として参照できるのが、QA4AIコンソーシアムの「AIプロダクト品質保証ガイドライン」です。5つの軸を示しています。
- Data Integrity (データがきちんとしているか)
- Model Robustness (精度が高く頑健性が確保されたモデルか)
- System Quality (システム全体として品質が確保できているか)
- Process Agility (開発プロセスが機動的か)
- Customer Expectation (顧客の期待)
初版は2019年6月で、その後改訂が重ねられています。出典: QA4AIガイドラインの解説記事。産業技術総合研究所の「機械学習品質マネジメントガイドライン」も同種の参照先として挙げられています。
誤回答の文脈で効くのは、5番目のCustomer Expectationです。顧客の期待が高いまま公開すると、同じ誤回答でも苦情の重さが変わります。回答の冒頭にAIが答えていると明示するかどうかも、この軸の話になります。
契約に落とすときは、1番から4番を開発側の責任範囲、5番を発注側が決める表示と告知の責任として分けると整理しやすくなります。
誤回答を見つける運用体制はどう作る？
人が目を通す場所を1か所に決め、そこを必ず通す形にします。全件確認は続きません。
最初の1週間は全件を見られます。1か月後には誰も見ていません。これは担当者の怠慢ではなく、全件確認という設計が続かないだけです。
どこに人を挟むか
当社はAIによる記事生成パイプラインを自社運用していますが、自動公開は実装していません。公開の引き金は、人が実際に記事を読んで承認することだけです。生成物はすべて承認待ちで止まります。
加えてフェイルセーフを置いています。公開予定時刻から72時間を超えて承認されなかった記事は、自動で保留に戻します。出典: 当社パイプラインの運用設定 (公開予定時刻起点)。担当者が不在のときに新規公開がゼロになるのが正しい挙動、という考え方です。
品質判定も単一のAIに委ねていません。2系統で判定し、食い違った場合は自動棄却も自動通過もさせません。不一致フラグを付けて人の判断に上げます。出典: 当社パイプラインの実装。
AIチャットボットに置き換えると、次の形になります。
- 想定質問の一覧の外側に当たる入力を機械で検出し、人の確認待ちに回す (所要時間の目安: 設計で半日、実装で1日から2日)
- 回答に自信度の低い印が付いたものを、翌営業日までに1人が確認する (つまずきやすい点: 確認する人を複数にすると誰も見なくなります)
- 判定が分かれる質問は自動で返さず、問い合わせフォームへ誘導する
実装者視点で言うと、ハマりやすいのは2番です。確認の担当を「気づいた人」にすると機能しません。曜日と人を固定してください。
記録を残して再発を見る
誤回答を直しても、記録が残っていなければ再発に気づけません。残すのは質問文、返した回答、参照した元の情報、直した内容の4点です。
当社のパイプラインでも、設定変更は影響度で3階層に分け、重い変更ほど人の承認を必須にしています。出典: 当社パイプラインの実装。チャットボットの回答元の差し替えも、同じ考え方で扱えます。
無人化で難しいのは、自動化する部分の実装ではありません。人がどこで必ず介在するかを決め、その介在が抜けたときにシステムが安全側に倒れるようにすることです。