問い合わせ対応に AI を入れたいが、顧客に間違った回答を送ってしまうのが怖い——顧客サポートの責任者からも、社内ヘルプデスクを抱える情シスからも、同じ趣旨の相談を受けます。当社に来る生成 AI の相談でも、問い合わせ対応は件数が多く、試作を作ったまま本番に進めずに止まっている例をよく見ます。理由は精度ではありません。AI が書いた文章を、誰が、どこまで確認してから相手に届けるのかが決まっていないからです。この線が引けていない試作は、担当者が全件を読み直すことになり、AI を入れる前より遅くなる。
この記事は、顧客サポートと社内ヘルプデスクの問い合わせ対応を、FDE（Forward Deployed Engineer）型で本番稼働させるときの設計だけを扱います。答えるのは3つ。問い合わせをどう分類し、どの区分を AI に任せるか。一次回答の下書きに何を書かせ、何を書かせないか。そして、人が確定する範囲とエスカレーション（人への引き渡し）をどう設計するか。Anthropic の顧客サポート実装ガイドと「効果的なエージェントの作り方」、OpenAI のエージェント構築ガイド、個人情報保護委員会の注意喚起、Zendesk・kintone の公式ドキュメントで確認できる範囲と、当社が経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験を一般化して書いています。
問い合わせ対応の AI は「全件自動返信」でも「全件下書き」でもなく、問い合わせを定型か非定型か、間違えたときの損害が小さいか大きいかで4区分に分け、区分ごとに AI の関与を変える。AI が担うのは分類・根拠付きの一次回答の下書き・人への引き渡しの3つで、送信の確定・返金や契約に関わる判断・苦情への回答は人が持つ。人へ回す引き金は「確信度が低い」と「取り返しのつかない操作」の2つ。合格基準は回答の正確さ・引き渡しの正しさ・顧客の満足度で決め、本番後も週次で測る。
この記事の要約
問い合わせ対応の AI が止まる理由——「全件自動」か「全件下書き」の二択で考えている
問い合わせ対応の AI 導入が試作で止まる会社には、設計の型が2つあります。1つは「チャットボットが全部答える」型。もう1つは「AI が下書きを作り、担当者が全件読んで送る」型。前者は最初の誤回答で止められ、後者は担当者の読む時間が書く時間と変わらず、効果が出ないまま使われなくなる。どちらも、問い合わせを一枚岩として扱っているのが原因です。
Anthropic は「効果的なエージェントの作り方」（2024年12月）で、LLM を使う仕組みは「できるだけ単純な解を探し、必要なときだけ複雑さを足す」ことを勧め、入力を分類して専用の後続処理へ振り分ける「ルーティング」の例として、一般的な質問・返金依頼・技術サポートを別々の処理へ送る顧客サービスを挙げています。同じ文書の付録では、顧客サポートが AI エージェントに向く理由として、会話の流れに沿って外部の情報と操作が必要になること、そして成功を「利用者が定義した解決」で明確に測れることを挙げている。つまり、問い合わせは種類ごとに扱いを変え、成功の定義を先に置く。当社の FDE 方式の進め方と同じ順番です。
OpenAI のエージェント構築ガイド（2025年）も、エージェントが向く業務の第一に「複雑な判断」を挙げ、例として「顧客サービスにおける返金の承認」を出しています。裏を返せば、返金の承認は判断が要る業務であり、AI が勝手に完了させてよい処理ではない。同じガイドは、人が介入する引き金を「失敗回数の上限を超えたとき」と「取り消せない・影響の大きい操作」の2つに整理し、後者の例として注文の取消・高額の返金の承認・支払いを挙げています。問い合わせ対応の設計とは、この「AI が判断材料を作る範囲」と「人が確定する範囲」の境界線を、問い合わせの種類ごとに引く作業です。
当社が相談を受ける範囲でも、止まり方は似ています。試作で精度の数字が出ても、外れた分の誤回答がどの問い合わせで起き、誰がそれを止めるかが決まっていないと、責任者は本番の判断ができない。評価設計の記事で書いた「精度と合格は別の話」が、問い合わせ対応では最も分かりやすく出ます。だから FDE は、精度を上げる前に、問い合わせの棚卸しと4区分から始めます。
対象範囲の決め方——問い合わせを4区分に分け、区分ごとに AI の関与を変える
FDE が着任して最初にやるのは、過去の問い合わせの棚卸しです。着任1週間の記事で書いた業務分解とデータ棚卸しを、問い合わせ対応では「直近3〜6か月分の問い合わせを、件名・本文・回答・所要時間・担当者の単位で並べる」作業として行います。メール、チャット、電話のメモ、社内なら Slack や Teams の質問も含める。並べた結果を、2つの軸で分けます。1つ目は、過去の回答から答えが決まる「定型」か、案件ごとに判断が要る「非定型」か。2つ目は、間違えたときの損害が小さいか、大きいか。損害の大きさは、金銭（返金・値引き・契約）、法的な争い（苦情・解約・個人情報）、信用（役員・大口顧客・報道）の3つで見ます。
2軸で4区分にすると、AI に任せる範囲が機械的に決まります。当社が置く基準を表にします。
| 区分 | 例 | AI がやること | 人がやること | 自動送信 |
|---|---|---|---|---|
| 定型・損害小 | パスワード再設定、営業時間、納期の目安、操作手順、社内システムの使い方 | 分類、根拠付きの一次回答の下書き | 送信前の確認（本番初期）。実績が積めたら事後の抜き取り確認へ | 実績を見て段階的に可 |
| 定型・損害大 | 請求金額の説明、契約内容の照会、返品条件、勤怠・給与の照会 | 分類、根拠付きの一次回答の下書き | 全件、送信前に確認して確定 | 不可 |
| 非定型・損害小 | 仕様の相談、使い方の提案、社内ルールの解釈 | 分類、関連する過去回答と資料の提示 | 回答を書く。AI の提示は材料 | 不可 |
| 非定型・損害大 | 苦情、解約の申し出、法的な主張、個人情報の開示請求、障害の一報 | 分類と人への引き渡しのみ | 最初の返信から人が書く | 不可 |
表の右上、非定型で損害が大きい区分に AI の文章を使わないのは、精度の問題ではなく、相手が「機械に処理された」と受け取った時点で損害が確定するからです。苦情の一次返信は、内容の正しさより早さと人が読んだという事実が問われる。AI がやるのは、その問い合わせを苦情と判定して、責任者に数分以内に届けることだけです。逆に、左下の定型で損害が小さい区分は、AI の得意な領域で、Anthropic のガイドが「大量の反復的な問い合わせ」を AI 導入の第一の指標に挙げているのもこの区分です。件数もこの区分に集まりやすく、当社は棚卸しの初期見積もりとして全体の半分前後をここに置いています。実際の割合は業種と商材で変わるので、棚卸しの実数が出た時点で置き換えます。
社内ヘルプデスクの場合は、同じ4区分に「相手が社員である」という条件が加わります。顧客より損害の見積もりが小さくなりがちですが、人事・給与・評価・健康に関わる問い合わせは損害大に置きます。ただし、法律上の扱いと社内での秘匿度は分けて見ます。個人情報保護法が「要配慮個人情報」と呼ぶのは、第2条第3項が定める、本人の人種・信条・社会的身分・病歴・犯罪の経歴・犯罪により害を被った事実など、不当な差別や偏見が生じないよう取扱いに特に配慮を要する情報です。健康に関する情報のうち、健康診断の結果や、その結果に基づく医師の指導・診療の事実は、施行令第2条でここに加えられています。要配慮個人情報は、取得の時点であらかじめ本人の同意が要り（法第20条第2項）、第三者へ渡すときも本人の同意を省くオプトアウトの手続きが使えません（法第27条第2項ただし書）。一方、給与額や人事評価は要配慮個人情報には当たりません。当たらないから軽い、という話ではなく、社内での秘匿性が高く、別人に届いた時点で取り返しがつかない情報です。法律上の区分と社内の秘匿度のどちらかに引っかかれば損害大に置く、という決め方にしています。一方で、社内システムの操作方法や申請の出し方は、根拠となる社内文書が揃っていれば定型・損害小に入り、自動送信まで持っていきやすい。社内ヘルプデスクは顧客サポートより早く自動送信に到達する業務です。
棚卸しの段階で必ず決めるのが「AI が答えに使ってよい資料」の一覧です。FAQ、マニュアル、規程、過去の回答のうち、現行で正しいと責任者が認めたものだけを AI の参照範囲にする。古い FAQ が混ざっていると、AI は古い方を根拠に正しそうな文章を書きます。参照範囲の一覧は、後で述べる引き継ぎの成果物にもなるので、着任1〜2週目に情シスと現場で確定させます。
一次回答の下書き——根拠を添え、約束・値引き・法的判断を書かせない
下書きの設計で決めるのは、書かせることより書かせないことです。Anthropic の顧客サポート実装ガイドは、AI に与える行動規範の例として「提供している商品の範囲内の情報だけを答える」「将来の商品計画を推測しない」「権限のない約束や合意をしない。情報と案内だけを提供する」「競合他社に言及しない」を挙げています。同じガイドの本番前の補強項目には、回答を提供した情報に根拠付ける、会社の方針と既知の事実に照らして確認する、契約上の約束を避ける、明示的に必要で許可された場合を除き個人を特定できる情報を回答から取り除く、が並ぶ。当社はこれを日本の問い合わせ対応向けに次の形にしています。
| 下書きに含めるもの | 下書きに含めないもの |
|---|---|
| 回答の本文（参照範囲の資料に根拠があるものだけ） | 返金・値引き・無償対応など金銭に関わる約束 |
| 根拠にした資料名と該当箇所（担当者が確認できるように） | 納期・復旧時刻・対応可否の確約 |
| 分類の結果と確信度（高・中・低） | 法的な見解、契約条項の解釈 |
| 不足している情報と、相手に確認すべき項目 | 参照範囲にない情報の補完（推測で埋めた文章） |
| 人に回すべきと判断した理由（該当する場合） | 相手の個人情報の復唱（氏名・住所・口座など。必要な項目のみ） |
根拠の提示は、担当者の確認時間を決める要素です。下書きの下に「参照した資料と該当箇所」が付いていれば、担当者は本文を読み直すのではなく、根拠が正しいかを見るだけで済む。当社が伴走した現場でも、根拠が付いてから確認が楽になったという声は出ますが、担当者の体感であって実測ではありません。効果を主張するなら、確認を開始してから送信するまでの時間を問い合わせ管理システムの記録で測り、根拠の提示を入れる前後で並べます。根拠のない文章を AI が書いたときは、担当者が「根拠なし」として差し戻し、その件は参照範囲の不足として週次で扱います。
「書かせない」項目を守らせる方法は2段です。1段目は AI への指示文で、含めない項目を明示し、該当する問い合わせは人に回すよう書く。2段目は出力の機械チェックで、金額・日付・「保証」「必ず」「法的」などの語が下書きに含まれたら、送信前確認を必須にする。OpenAI のガイドは、防護策の種類として、話題の範囲を判定する分類器、安全性の分類器、個人情報の除去、不適切な内容の判定、道具ごとの危険度の評価、単純な規則による保護（禁止語・入力長・正規表現）、出力の検証を挙げ、「データの保護と内容の安全性に集中し、実際に起きた失敗から防護策を足していく」やり方を勧めています。最初から全部を作らず、本番で起きた失敗を週次で防護策に足す。この順番が FDE 方式に合います。
個人情報の扱いは、下書きの設計の中で最初に決めます。個人情報保護委員会は2023年6月2日の注意喚起で、個人情報取扱事業者が生成 AI に個人情報を含む文章を入力する場合は、特定された利用目的の達成に必要な範囲内であることを確認すること、本人の同意なく個人データを入力し、それが応答結果の出力以外の目的で取り扱われる場合は個人情報保護法の規定に違反する可能性があるため、提供事業者が当該データを機械学習に利用しないこと等を確認すること、の2点を求めています。問い合わせの本文には、氏名・連絡先・注文番号のような個人を特定できる情報が入ることが多い。したがって、学習に使われない契約の AI サービスを選び、処理地域と保持期間を確認したうえで、下書きには必要な項目以外の個人情報を復唱させない。この6項目の決め方はデータの扱いの記事に譲ります。
エスカレーション設計——人へ回す2つの引き金と、人が確定する範囲
分類の軸は4つにします。意図（何を聞いているか）、緊急度（障害・期限・金銭が絡むか）、感情（怒り・不安の強さ）、そして確信度（分類自体がどれだけ確からしいか）。軸の中身は当社が問い合わせ対応向けに置いたものですが、「機械が項目を予測し、確からしさを添え、担当者が直せる」という形は問い合わせ管理システムの標準機能にあります。Zendesk の「インテリジェントトリアージ」は、チケットごとに話題・感情・言語・固有情報（製品名など）を予測し、各項目に確からしさの度合いを付け、その値をトリガー・ビュー・自動化・SLA・キューで使えるようにしていて、担当者が予測値を修正できる。軸の取り方は当社の4つと同じではありません。感情は重なりますが、意図と緊急度は Zendesk でいう話題と固有情報から自社の業務に合わせて組み立てる項目で、確信度は各予測に付く確からしさに当たります。自社で AI を組む場合も、この4軸を出力させ、担当者が直せる項目として問い合わせ管理システムに書き戻す設計にします。
人へ回す引き金は2つだけです。OpenAI のガイドの整理に沿って、1つ目は「失敗の上限を超えたとき」。分類の確信度が低い、参照範囲に根拠が見つからない、相手の意図を2回聞き返しても確定しない、のいずれかで人へ回す。2つ目は「取り消せない・影響の大きい操作」。返金・解約・契約変更・個人情報の開示・アカウントの停止は、AI が下書きまでは作っても、実行と送信は人が確定する。この2つ以外の引き金を増やすと、ほぼ全件が人に回って「全件下書き」型に戻るので、引き金は増やさず、代わりに損害大の区分の定義を精密にします。
引き渡しの設計で決めるのは、誰に、何を添えて、何分以内に届けるかです。苦情と障害の一報は責任者へ、返金と契約は権限を持つ担当へ、社内ヘルプデスクなら人事系は人事へ、システム系は情シスへ。添えるのは AI の要約・分類・確信度・参照した資料で、下書きの本文は添えない（人が最初から書くべき区分だからです）。kintone で問い合わせを管理している会社なら、kintone のプロセス管理でステータスと作業者を定義し、AI の分類結果に応じて作業者を変える形で組めます。プロセス管理は業務の流れに沿った進捗管理の機能で、レコードの画面のボタンで確認・承認や次の担当者への引き渡しができる。これで「誰の手元で止まっているか」が一覧で見える状態になります。
人が確定する範囲は、送信の確定だけではありません。表にします。
| 人が持つ判断 | 内容 | 誰が | いつ |
|---|---|---|---|
| 送信の確定 | AI の下書きを相手に届けるかどうか。自動送信の区分でも、権限の設定上は人が持ち、AI に委任している形にする | 担当者 | 送信前（自動送信の区分は事後の抜き取り） |
| 金銭・契約の確定 | 返金、値引き、無償対応、契約変更、解約の受理 | 権限のある担当・責任者 | 実行前。AI は下書きと判断材料のみ |
| 苦情・法的主張への回答 | 最初の返信から人が書く。AI は分類と要約だけ | 責任者 | 受信から数分以内に人へ届く設計 |
| 参照範囲の更新 | AI が根拠に使う FAQ・規程・過去回答の追加と削除 | 現場責任者（Echo 役） | 週次 |
| 区分の変更 | ある種類の問い合わせを自動送信に上げる、または下書きに戻す | 経営または部門長 | 月次。実測値を見て決める |
| 停止 | 誤回答が連続したときに AI の下書きを止め、全件を人に戻す | 現場責任者 | 即時。手順を引き継ぎ文書に書く |
表の最後の「停止」は、忘れられがちですが最初に作ります。誤回答が同じ原因で2件続いたら、その区分の AI 関与を「分類のみ」に落として全件を人に戻す。停止の判断者と手順を決めておくと、責任者は「止められる」と分かって本番に踏み切れます。受け入れ側の体制の記事で書いた論点一覧に、「停止の基準」と「区分の変更」を経営判断の論点として載せておくと、月次で実測値と一緒に決められます。
評価と本番判断——測る数字と合格基準
本番に入れるかどうかは、テストセットに対する合格率と、業務上の受け入れ基準で決めます。問い合わせ対応では、テストセットは棚卸しした過去の問い合わせから作れるので、他の業務より用意しやすい。区分ごとに50〜200件を取り、人が付けた正解（正しい分類、正しい回答の要点、人へ回すべきかどうか）と AI の出力を比べる。
何を測るかは、Anthropic の顧客サポート実装ガイドの成功基準がそのまま使えます。同ガイドは、問い合わせの理解の正確さ（目標95%以上）、回答の関連性（90%以上）、会社・商品情報の正確さ（100%）、根拠となる資料の提示（追加情報が有益な場面の80%）、話題からの逸脱のなさ（95%）、人への引き渡しの正しさ（引き渡すべき会話を正しく引き渡した割合95%以上）を性能の基準として、顧客感情の維持または改善（90%の会話）、人の介入なしに処理できた割合（問い合わせの複雑さにより70〜80%が目安）、顧客満足度（5点満点で4以上）、平均処理時間（人より短く）を業務上の基準として挙げている。当社はこのうち、本番投入の可否を決める基準を3つに絞ります。回答の正確さ、引き渡しの正しさ、顧客（社内なら社員）の満足度です。
3つに絞る理由は、区分ごとに合格基準の重みが違うからです。定型・損害小の区分では、人の介入なしに処理できた割合が効果を決める。定型・損害大の区分では、正確さが100%に近くないと担当者が全件を読み直すことになり、下書きの意味がない。非定型・損害大の区分では、引き渡しの正しさだけが問われ、苦情を「一般的な質問」と分類した1件が、他の全件の正解を打ち消す。だから合格基準は「全体で精度9割」ではなく、「損害大の区分で引き渡し漏れゼロ、定型・損害小の区分で正確さ何%以上」のように区分ごとに置きます。
数字の決め方と、経営・現場・情シスの誰が何を決めるかは評価設計の記事に書いた3層評価と同じです。問い合わせ対応で1つ足すとすれば、本番後の測り方です。自動送信に上げた区分は、送信済みの回答から週に一定件数を抜き取り、担当者が採点する。下書きの区分は、担当者が下書きをどれだけ直したかを記録する（直さず送った、一部直した、全部書き直した、の3段階で足ります）。「全部書き直した」が増えた種類の問い合わせは、参照範囲が古いか、区分が間違っているかのどちらかで、週次で直す対象になります。
満足度は、回答の末尾に1問だけ付けます。「この回答で解決しましたか」の二択で十分で、5段階にすると回答率が落ちる。社内ヘルプデスクなら、問い合わせ管理システムの解決ボタンで代用できます。AI が関与した件と人が最初から書いた件の解決率を並べて、AI の関与が解決率を下げていないことを月次で確認する。この数字が、区分を自動送信に上げる判断の材料になります。
FDE 方式での進め方——分類だけの稼働から始めて、区分ごとに上げていく
問い合わせ対応の本番化を、当社は「AI の関与を段階的に上げる」形で進めます。最初の本番は、AI が分類だけを行い、回答は全件人が書く状態です。この状態でも、振り分けと優先順位付けの手間が減り、分類の正しさを本番データで測れる。次に、定型・損害小の区分だけ下書きを出し、担当者が確認して送る。実績が積めたら、その区分を自動送信に上げる。定型・損害大は下書き止まりで固定します。
| 時期 | やること | 本番の状態 | 決める人・決めること |
|---|---|---|---|
| 1〜2週目 | 問い合わせの棚卸し、4区分の仮置き、参照範囲の一覧作成、個人情報の扱いの確定 | 変更なし（人が全件対応） | 情シス（データの扱い）、現場責任者（参照範囲） |
| 3〜4週目 | 分類の稼働、テストセットの作成、引き渡し先と通知の設定 | AI が分類のみ。回答は人 | 現場（分類の正解付け）、責任者（引き渡し先） |
| 5〜8週目 | 定型・損害小の下書き稼働、根拠の提示、機械チェック、停止手順 | AI が下書き、担当者が送信前に全件確認 | 部門長（下書き開始の可否、停止基準） |
| 9〜12週目 | 定型・損害大の下書き稼働、自動送信の区分の選定、抜き取り確認の運用 | 一部の区分を自動送信、事後の抜き取り確認 | 経営（自動送信の可否、月次の実測値で判断） |
| 13週目以降 | 引き継ぎ。参照範囲の更新・区分の変更・停止を Echo 役だけで回す | FDE は質問対応のみ | Echo 役（週次運用）、経営（月次の区分見直し） |
この進め方の要は、本番の状態を週単位で変えることです。「分類のみ」の本番は、AI が書いた文章が相手に届かないので、誤回答が顧客の手元に出ることはありません。残るのは誤った振り分けによる対応の遅れで、これは担当者が一覧を見れば気づける範囲に収まります。この状態なら情シスも責任者も止めにくく、そこで実測した分類の正しさが、次の段階に上げる根拠になる。PoC で止まる会社の記事で書いた「本番に乗らない7つの原因」のうち、問い合わせ対応でよく当たる「誰も本番投入を決められない」は、決める材料を本番データで積む順番にすると解けます。
引き継ぎの成果物は4つです。参照範囲の一覧（何を根拠にしてよいか、誰が更新するか）、4区分の定義表（どの問い合わせをどの区分に置くか、変更の判断者）、防護策の一覧（含めない項目、機械チェックの語、停止の基準と手順）、そしてテストセットと採点の記録。引き継ぎの記事で書いたランブックの形式に沿って、画面と操作の単位で書き、Echo 役が1サイクル（週次の参照範囲更新と抜き取り確認）を1人で回せた時点で引き継ぎ完了とします。
最後に、この業務で FDE を頼むときに発注側が着任前に決めておくとよいことを3つ挙げます。問い合わせ管理システムをどれにするか（メールのままか、Zendesk や kintone のような記録が残る道具に寄せるか）。参照範囲の資料の責任者を誰にするか。苦情と障害の一報を受ける責任者を誰にするか。3つとも FDE には決められず、決まっていないと着任後の2週間が待ち時間になります。失敗パターンの記事の「判断者不在」は、問い合わせ対応では「苦情を誰が受けるか決まっていない」という形で現れます。
まとめ
問い合わせ対応の AI は、全件自動でも全件下書きでもなく、問い合わせを定型か非定型か、損害が小さいか大きいかで4区分に分け、区分ごとに AI の関与を変える。AI が担うのは分類、根拠付きの一次回答の下書き、人への引き渡しの3つで、送信の確定・金銭と契約の判断・苦情への回答は人が持つ。人へ回す引き金は「確信度が低い」と「取り消せない操作」の2つに絞り、防護策は本番で起きた失敗から週次で足す。合格基準は回答の正確さ・引き渡しの正しさ・満足度を区分ごとに置き、損害大の区分では引き渡し漏れゼロを条件にする。
本番は「分類のみ」から始めて、定型・損害小の下書き、自動送信へと週単位で上げていく。各段階の実測値が次の段階に上げる根拠になるので、経営は「なんとなく良さそう」ではなく数字で判断できます。着任前に発注側が決めるのは、問い合わせ管理の道具、参照範囲の資料の責任者、苦情を受ける責任者の3つ。この3つが決まっていれば、FDE は着任1週目から棚卸しに入れます。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
問い合わせ対応の AI を、「分類だけ」の本番から段階的に上げていきます
過去の問い合わせの棚卸しと4区分の設計、根拠付きの一次回答の下書き、人へ回す引き金と停止の手順、区分ごとの合格基準と本番後の抜き取り確認まで、貴社の問い合わせ管理の道具（メール・Zendesk・kintone など）と既存の体制に合わせて設計します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、顧客サポートと社内ヘルプデスクのどちらもご相談いただけます。