- 公開日
AIの性能が上がっても、何のために使うか、誰が運用に責任を持つか、どの誤りを受け入れられないか、何をもって仕事を終えたとするかは、人間側で決める必要があります。モデルの能力は、その判断に使う材料です。良い回答が増えたことだけで、顧客への約束や操作の権限が自動的に広がるわけではありません。
これは、すべての回答を毎回人が作り直すという意味ではありません。繰り返し使える基準を人が定め、その範囲でAIを使い、外れた場合の戻り先を用意します。性能向上によって減らせる確認があるかは、目的と影響を固定して確かめます。
「できる」と「任せる理由」は別に考える
例えば、AIが問い合わせへ自然な文章で答えられることと、企業として返金を約束してよいことは別です。前者は文章を作る能力、後者は顧客対応方針や権限に関わります。同じ回答能力を持つAIでも、社内担当者の下書き支援に使うか、利用者へ直接回答するかで必要な管理は変わります。文章力が上がるほど、権限のない約束ももっともらしく書かれるため、読みやすさが増したことを許可範囲を広げる理由にはできません。
NIST AI RMF CoreのGOVERN 2は、役割・責任・連絡経路の明確化や、AIの開発・導入に伴うリスク判断についての経営側の責任を扱っています。これは、モデルに責任者という役名を付ければ済む、という考え方ではありません。以下では、この論点を日常の問い合わせ対応へ当てはめた設計例を示します。個別の法的責任を判定するものではありません。
利用目的も「問い合わせを自動化する」だけでは判断に使いにくい表現です。「担当者が、公開FAQに基づく回答案と確認が必要な点を短時間で把握できるようにする」と決めれば、速さだけでなく、誤った約束を混ぜないことや引き継ぎの分かりやすさも成果に含まれます。何を良くしたいかが定まると、性能のどこを見るべきかも絞れます。
導入会議で、先に三つの決定を残す
架空の文具店が、問い合わせ対応AIを導入する場面を考えます。初期の用途は、担当者向けの回答案作成です。入力は利用が認められた問い合わせ本文と承認済みFAQで、AIから顧客へ直接送信する機能は接続しません。
FAQには「窓口の受付は平日10時から17時」「注文ごとの納期は担当者が確認して回答」と書かれています。届いた問い合わせは「来週月曜日の行事に使いたい。金曜日までに届きますか」です。注文番号も配送状況も、この段階では提供されていません。
導入会議で決めるのは、次の三点です。
| 決める事項 | この例での決定 | 未決定だと困ること |
|---|---|---|
| 責任と戻り先 | 窓口責任者が対象業務と停止基準を決め、担当者が回答案を確認する | 誤案内を誰が修正し、運用を誰が止めるか分からない |
| 許容するリスク | 配送状況を見ずに到着日を約束する案は採用しない | 自然な文章であることを理由に、根拠のない約束が通る |
| 完了条件 | 回答案、根拠FAQ、未確認事項、確認先が揃い、担当者が受け取れる | 文章を出しただけで、問い合わせ対応が終わったことになる |
この表は架空の業務方針です。すべての組織へ同じ担当構成を求めるものではありません。小さな組織では一人が複数の役割を担えますが、どの判断をどの立場で行ったかが分かるようにします。
また、責任者に名前を置くだけでは運用できません。FAQを修正できるのか、誤案内を見つけた際にAIの利用を止められるのか、担当者が不在のときに誰へ連絡するのかも決めます。実際に使える権限と時間がなければ、確認責任だけを割り当てても確認は進みません。
許容リスクは、平均点だけでは決められない
この例で「回答が大体正しければよい」とする基準は曖昧です。受付時間の語順が少し不自然なことと、未確認の到着日を保証することでは、顧客への影響が違います。そこで、文章の読みやすさは修正可能な品質項目、根拠のない納期の約束は差し戻す項目として区別します。
NIST AI RMF 1.0のRisk Toleranceの説明でも、同フレームワーク自体がリスク許容度を定めるわけではなく、用途や文脈によって判断が変わるとしています。同じ説明は、法令や規制上の要件がリスク許容度に影響し得ることにも触れています。組織が自由に基準を決めてよいという意味ではないため、業務側では、法令に加えて顧客との契約や社内規程と矛盾しないかも確かめます。
業務で決めるときは、誤りが誰へ届くか、いつ訂正できるか、訂正までに相手が行動するかを考えます。担当者だけが読む下書きでも、忙しい時間帯に確認せず転記される運用なら、その使われ方を含めて見直します。「人が見る予定」という説明と、人が根拠を照合できる運用は同じではありません。
許容できない誤りを決めることは、誤りが絶対に起きないという保証でもありません。発見したらその案を採用しない、関連する回答を点検する、原因を直すまで対象機能を止める、といった対応を決めるための基準です。発生確率を測れていない段階で、便宜的な数字を安全性の証拠として加えないようにします。
依頼文へ落とし、回答と業務の完了を分ける
元の依頼が「お客様に喜ばれる回答を作って」だけでは、納期が分からないときの処理が決まっていません。目的を残しながら、次のように直せます。
問い合わせへの回答案を、承認済みFAQに基づいて作ってください。
注文ごとの納期はFAQだけでは判断せず、未確認としてください。
回答案、使ったFAQの箇所、担当者が確認すべき事項を分けて示してください。
顧客への送信や納期の約束はせず、担当者へ戻してください。この条件で期待する案は、「到着予定日は注文と配送状況の確認が必要です。担当者が確認します」といった内容です。併せて、注文を特定するために必要な情報を、所定の窓口で確認する課題を残します。AIが注文番号を作ったり、一般的な配送日数から金曜日到着を断定したりする案は差し戻します。ここでの出力は未実行の説明例です。
担当者は、案の納期に関する記述をFAQと照合し、顧客へ伝える前に注文管理情報を確かめます。AIの下書き作成は、この引き継ぎが整えば終了できます。しかし、顧客の問い合わせ対応は、確認結果を踏まえた回答が所定の方法で届けられるまで続きます。二つの完了を分けると、AIが作業を終えた後に残る仕事が見えます。
「人に渡した」と記録する際も、誰がどの情報を受け取るかを確認します。共有先に資料へのアクセスがない、未確認事項が本文から消えている、担当が決まっていない場合は、引き継ぎを完了扱いにしません。根拠や問い合わせ全文を必要以上に複製せず、業務に必要な範囲で参照できる方法を選びます。
モデル更新では、維持する基準と変える運用を分ける
新しいモデルへ切り替えるときも、「根拠のない納期を約束しない」という業務上の基準は、能力が上がったという理由だけでは変えません。窓口責任者、差戻し先、完了条件も引き継ぎます。そのうえで、同じ問い合わせと同じFAQを使い、未確認の情報をどう扱うかを改めて確かめます。
確認の材料には、FAQだけで回答できる受付時間の質問、注文情報が足りない納期の質問、資料同士が食い違う質問などを用意できます。ここで測るのは、新モデルの一般的な賢さではなく、この用途の基準を満たすかです。実施前の期待を「更新で改善した」と報告せず、実際の回答、差戻し、確認負担を記録して判断します。
一方、更新を契機に「顧客へ直接返答する」「注文情報も参照する」と用途を広げるなら、以前と同じ作業のモデル交換ではありません。送信の権限、情報へのアクセス、利用者への説明、誤案内の訂正方法など、新しい影響を人間側で再検討します。目的が変わると、必要な責任体制や完了条件も変わるからです。委任を広げる前には、次の問いに証拠を添えて答えられるかを確かめます。
| 問い | 答えるための証拠 |
|---|---|
| 同じ問い合わせ例で、以前より誤りが減ったか | 更新前後で同じ例と判定基準を使った比較 |
| 範囲外の約束をしないか | 納期の保証や返金を求める問い合わせでの結果 |
| 不足情報を推測で埋めないか | 注文情報が欠けた問い合わせでの結果 |
| 自動化する対象を限定できるか | 対象となる問い合わせの種類と、除外する条件 |
| 誤って送った場合に対応できるか | 送信結果の記録、訂正の手順、責任者 |
更新後に確かめたのが下書きの品質だけなら、直接送信まで広げてよい根拠にはなりません。確認の負担を減らすために、AIに「問題なし」といった判定を付けさせることもできますが、その表示だけで担当者の確認を終えず、根拠となるFAQの該当箇所と判断待ちの部分を並べて渡します。
残すべきなのは、古い指示文のすべてではなく、判断の根拠が追える状態です。能力向上を活かしながら、誰が何を受け入れ、どの条件で見直すと決めたかを残します。それによって、AIの回答の良し悪しと、業務として使い続けてよいかを別々に判断できます。
AIの擬人化による能力の誤認と見直し方は「AIの擬人化で生じる能力誤認を、役割と限界の表示から見直す」、アバターAIの表情や声が理解と信頼に与える影響の評価は「アバターAIの表情と声の違和感を理解と信頼から分けて評価する」で解説しています。
重要判断で、AIに任せる範囲と人間の決定・記録・訂正の流れを分ける方法は「重要判断でAIの役割と人間の決定責任を明確にする」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIを使う前の安全確認チェックリスト（AIKYで確かめる12項目）」にまとめています。
