問い合わせ対応のAI活用FAQ・既製品・連携開発を
用件別に選ぶ

営業時間を聞かれたときはFAQを見れば答えられるのに、注文の配送状況を聞かれると別の画面を開く。

返金の相談は担当者が判断し、内容に応じて引き継ぎ先を選びます。

問い合わせ対応をAIに任せたいと思っても、窓口に届く用件をまとめて扱うと、必要な仕組みが決まりません。

公開資料だけで答えが決まる用件はFAQ整備と既製品から試し、顧客ごとの照会はデータ接続と権限を確かめ、例外判断は担当者へ渡します。

同じ窓口で組み合わせて使えます。

この記事では、架空の6用件を整理した表と、自社の問い合わせを1件記入するひな型を用意しました。

必要な機能で候補製品を絞り、同じ用件をデモに持ち込んで、自動回答と担当者の処理がつながるかを確かめます。

この記事で分かること

• まず、繰り返し届く用件を1つ選び、固有名詞を除いた架空の質問に書き換えます
• 利用中のシステムで足りるかを先に調べ、足りない機能を扱う製品へ候補を絞ります
• FAQの案内が誤っていたときと、注文データが取得できなかったときでは、直す場所が違います

用件ごとに、
答えに必要な情報を分ける

完成例は、社外の問い合わせを受ける架空の窓口です。

ここにある答えや担当先は説明用であり、実在する企業の対応ルールではありません。

表は編集部が作成した検討例で、AIや製品を実行した結果ではありません。

「質問の種類」だけでなく、「答えの根拠が公開FAQか、顧客別の記録か、人の判断か」で分けると、試す方法が決まります。

AIを入れる前に、FAQのリンクや既存の注文照会画面を分かりやすく案内するだけで用事が済むかも確かめてください。

受付を知らせる定型メールは、質問に答えるAIとは別の役割です。

困っているのが返信漏れや担当者への連絡なら、回答を生成するAIより先に、受付記録・担当者への通知・未対応一覧を整える方法もあります。

誰が続きを処理するかを追えない問題は、FAQ回答だけでは解消しません。

Fのように用件が複数ある問い合わせも残します。

片方だけ答えて「解決」とすると、宛名変更の依頼を見落とすためです。

デモで求める回答と
受付記録の完成例

架空のAでは、デモ用FAQを「営業時間は平日9時から17時。土日祝日は休業」とします。

祝日の営業については「祝日は休業です。営業時間は平日9時から17時です」と回答します。

この用件では、担当者を呼ばずに質問へ答えられます。

一方、「FAQにない臨時営業日は？」には、日付を作らず「臨時営業日は掲載資料で分からないため、受付担当に引き継ぎます」と案内する設計にします。

その案内が届くだけでなく、担当者に次の受付記録が残る状態をデモで求めます。

質問：臨時営業日を知りたい。
案内した内容：掲載資料では分からないため、受付担当へ引き継ぐと案内。
参照した資料：デモ用FAQ「営業時間と休日」。臨時営業日の記載なし。
引き継ぐ理由：FAQに根拠がない。
担当先：受付担当の受信箱。
対応状況：未対応。

いずれも完成後に求める設計例で、製品の出力ログではありません。

架空の営業時間を自社のFAQや実際の返信へ流用しないでください。

受付処理を試作し、
未対応が残るかを試す

弊社で、問い合わせを用件ごとに記録する小さな処理を作り、架空の入力で実行しました。

Fの2用件を受け付けた直後の出力は、次のとおりです。

AIと実際の注文システムは使わず、用件の分類と本人確認済みIDを架空の入力として与えました。

この試作では、受付後の担当先を用件ごとに振り分けています。

配送状況を回答しても、宛名変更が未対応なら受付全体は未完了です。 その後、架空の担当者による完了入力を与えると、宛名変更は対応済み、受付全体は完了になりました。

次に同じ受信データをもう一度処理に渡しました。

受付を増やさず、完了した宛名変更を未対応へ戻さない動作を確認しました。

別の受信データが同じ受付番号を使う場合は、更新として上書きせず、重複・変更として保留しました。

製品デモでも、回答だけでなく、このように未対応の用件・担当先・止めた理由が残るかを見せてもらいます。

Fなら「配送照会は回答済み、宛名変更だけを未対応一覧に残してください」と依頼できます。

試作では、用件の分類と本人確認済みのIDを架空の入力として与えています。

AIによる文章の理解、実際の本人確認、注文システムへの接続、メール送信は試していません。

宛名変更の完了も入力しただけで、請求書は変更していません。

受付台帳は1回の実行中に保存する試作です。

サーバーの再起動後の保持や同時処理は未検証です。

実製品の性能や導入成果を示す結果ではありません。

最終の受付記録をExcelで見る（架空データ）。

Fの完了後も、権限外・取得失敗・本人未確認の3件が未対応で残ります。

試作の入力・出力と再実行用のコード

8回の入力／各操作後の出力・アクセス記録／ローカルで再実行するPythonコード

同じフォルダーに入力とコードを保存し、Python 3で実行すると、受付記録CSVと操作ごとの出力を作成します。

外部への通信やAPI呼び出しはありません。

本文の整理ひな型を使うために、コードを実行する必要はありません。

最終CSVは現在の状態だけを示します。

担当者による完了入力では理由が書き換わるため、前の失敗理由を見る場合は操作ごとの出力を使ってください。

実運用の履歴保存を保証する試作ではありません。

自社の問い合わせを
1件記入する

まず、繰り返し届く用件を1つ選び、固有名詞を除いた架空の質問に書き換えます。

実メールや注文番号、氏名を、未承認のAIサービスに貼り付ける必要はありません。

次のひな型をメモやExcelへコピーして、各欄を埋めます。

空欄は推測で埋めず「未決定」と書いてください。

これは業務を整理するひな型で、AIへ入力するプロンプトではありません。

質問の例：
回答の根拠になるFAQ・資料の場所と更新日：
顧客別情報は必要か。必要なら何の情報か：
AIに任せたい作業（案内／回答案／回答／受付／照会）：
人へ渡す条件：
渡す担当先と、営業時間外の受付方法：
担当者へ残すもの（質問・回答内容・参照資料・渡す理由）：

架空のCを記入すると、次のようになります。

質問の例：自分の注文の配送状況を知りたい。
回答の根拠になるFAQ・資料の場所と更新日：注文管理画面。更新時刻は照会時に取得したい。
顧客別情報は必要か。必要なら何の情報か：必要。本人の注文の配送状況。
AIに任せたい作業（案内／回答案／回答／受付／照会）：まず照会画面への案内。窓口内の照会は次の検討対象。
人へ渡す条件：本人確認できない、他人の注文、情報取得失敗、更新時刻不明。
渡す担当先と、営業時間外の受付方法：受注担当。時間外は受付記録を残して次の営業日に担当者が見る。
担当者へ残すもの（質問・回答内容・参照資料・渡す理由）：質問、案内済みの内容、照会できなかった理由。注文情報は社内の許可された保存先で管理する。

担当先が「人」だけでは、引き継いだ後の仕事が決まりません。

担当部署と時間外の扱いまで記入します。

返答期限を利用者へ案内するなら、実際に守れる社内ルールを先に決めてください。

記入した1件は、まず社内の問い合わせ責任者に見せ、回答根拠と担当先が現在のルールに沿うかを照合します。

未決定の社内ルールは製品側に決めてもらわず、責任者が判断します。

候補製品は、
何を基準に絞ればよいですか？

FAQの中で案内が食い違っている場合は、責任者が正しい条件を決め、古い資料を回答の参照先から外します。

何を答えるべきか決まらないままAIを選んでも、正誤を判定できません。

利用中のシステムで足りるかを先に調べ、足りない機能を扱う製品へ候補を絞ります。

新しいチャットボットを選ぶ前に、受付システムの担当窓口へ、記入した1件を見せてください。

「この用件の回答と受付記録を、今のシステムの機能や追加設定で扱えますか」と聞きます。

注文照会を含むなら、注文システムの管理担当者にも、本人確認と閲覧制限を維持した接続が可能かを尋ねます。

現在のシステムでは足りない場合、または受付システムをまだ使っていない場合は、次の順で候補の公式ページを読みます。

1. 自社の窓口に対応するか。 Webのチャットだけでよいのか、メールでも回答を受けたいのかを決めます。チャット対応という説明だけで、メールにも使えるとは判断しません。
2. FAQ回答だけか、顧客別の照会も必要か。 A・Bなら資料を使った回答を調べます。Cなら注文システムとの接続まで候補の条件に加えます。FAQを読み込める機能と、現在の注文状況を取得する機能は別です。
3. 担当者が続きを管理できるか。 D・E・Fを扱うなら、問い合わせ先の案内だけで足りるか、担当先へ会話を渡して未対応を管理する必要があるかを決めます。

製品の公式資料から、使える機能と条件を確認できます。

おすすめ順や性能比較ではありません。

自社の条件に関係する製品だけを調べ、公開資料で分からない部分はデモの質問に残します。

外部情報への接続が必要というだけで、専用開発が必要とは決まりません。

連携機能を備える製品でも、自社の注文管理方法や閲覧制限が合うかは別に調べます。

候補製品を調べるときは、次の表の空欄をデモ担当者に埋めてもらいます。

「対応できます」だけなら、どの画面・設定・追加作業で実現するかを聞いてください。

資料の「同期」は、原本の変更が直ちに回答へ反映されるという意味とは限りません。

Zendeskの該当するAI agents向け公式資料では、外部情報は最終同期時点の内容を検索し、同期は通常24時間ごとと説明しています。

この資料は2026年3月10日より前にAI agents - Advancedを購入した顧客を対象外としているため、対象外の契約にはそのまま当てはめません。

Zendesk公式：ナレッジ接続

臨時休業や規約の変更を扱うなら、原本の修正時刻と、AIが新条件で答えた時刻を別々に記録します。

反映まで古い答えを出す恐れがあれば、その用件の自動回答を一時停止する方法もデモで確かめます。

デモで回答と
引き継ぎを確かめる

候補を絞ったら、公式ページのデモ窓口へ記入した1件を渡します。

次の依頼文の［ ］を自社の窓口へ差し替え、不要な依頼は削ってから送ってください。

実メールや個人情報は添付しません。

社外の問い合わせ対応で、添付の用件を扱えるか検討しています。
自社で使う窓口は［Web／メールなど、該当するもの］です。
架空データを使い、正しい回答、根拠がない場合の対応、担当者画面に残る受付記録を見せてください。
個別照会が必要な用件では、本人の情報だけを照会する設定と、取得失敗時の挙動も見たいです。
標準機能と設定でできる部分、追加の連携・開発が必要な部分を、用件ごとに教えてください。

デモでは通常の質問だけでなく、回答できない条件も試します。

以下はA・C・Eの確認例で、製品で観測した結果ではありません。

デモの終わりには担当者画面を開き、先に示した完成例と受付記録を照合します。

URLを案内しただけなのか、受信箱へ会話が届いたのかを区別してください。

Finのチャットでは、有人の担当先が未設定だと引き継ぎを提案しない仕様です。

メールを含む実際の窓口で、担当先の設定を見せてもらってください。

Intercom公式：有人引き継ぎの設定

注文情報を「返答に出さない」ことと、「権限外の注文を取得できない」ことは別です。

返答に含めなくても、接続機能が実行される場合があります。

照会は接続先で本人の注文だけに制限し、デモでは返答とアクセス記録の両方を見ます。

架空の注文番号を変えたときに、別の顧客の情報を取得していないかを製品担当者と照合してください。

Intercom公式：接続機能の実行と失敗時の処理

取得失敗の作り方や権限の設定が分からなければ、製品担当者に架空データの検証環境で再現してもらいます。

本番の注文画面を壊したり、実在する顧客の情報を入れたりして試す必要はありません。

試せない項目は未確認として残し、その用件の自動回答を始めない判断もできます。

デモで不合格になったら、
どこを直しますか？

FAQの案内が誤っていたときと、注文データが取得できなかったときでは、直す場所が違います。

回答が不自然という理由だけで、AIへの指示を長くし続けないようにします。

自社のシステムに標準の接続機能がなく、必要な閲覧制限や引き継ぎも設定で満たせない部分を、連携開発の対象にします。

窓口全体を作り直す前に、表のどの行が不足しているかを特定してください。

開発を依頼する場合も、「問い合わせ対応を全部AIにしたい」では必要な仕事が決まりません。

たとえばCなら、本人確認済みの利用者を注文情報に結び付け、閲覧できる注文だけを取得し、失敗時は受付記録を残すところまでが設計条件です。

相談には、記入した1件と、標準機能では満たせなかった箇所を使います。

顧客名や実メール本文は不要です。

「Webで受け付け、注文画面を見て、受注担当へ渡している。本人の注文だけを照会する部分が、候補製品で未確認」のように、今の手順と不足を伝えてください。

問い合わせ対応の仕組みを相談する

メールでの回答案と保留の具体例は、メール自動返信のAI活用で扱っています。

社内ルールや社員からの質問を対象にする場合は、社内問い合わせのAI活用を参照してください。