一次返信までの時間を短くする問い合わせ対応と日程調整の自動化｜自動で返す範囲の決め方

社外からの問い合わせで時間が取られている場所

フォームやメールで届く問い合わせのうち、担当者が長く考えて答えているものは多くありません。時間を取っているのは、届いた内容を読んで誰が扱うかを決め、過去に似た問い合わせへ何と返したかを探し、資料の該当箇所を確認して文面を組み立てるところです。そのうえで面談の希望があれば、自分と関係者の空き時間を照らし合わせて候補日を出します。

短くしたいのは、届いてから一次返信を出すまでの時間です。この流れのうち、判断が要るのは「何と答えるか」だけです。仕分けと材料集めと文面の下書き、そして候補日の抽出は、条件を決めれば機械が先に済ませられます。返信の内容そのものを機械に決めさせる話ではなく、人が確定させるまでの手前を短くする、という組み方になります。

社内向けの問い合わせを同じ考え方で扱う設計は 社内問い合わせ対応をAIで自動化する で扱っています。社外向けとの違いは、間違えたときの影響が社外へ出てしまう点と、返信までの時間そのものが評価の対象になる点です。この2つがあるため、社外向けは自動で送ってよい範囲を社内向けより狭く取ります。

問い合わせを3つに仕分ける

最初にやることは、届いている問い合わせを性質で分けることです。ここを飛ばして「問い合わせ対応を自動化する」と決めると、返してはいけない内容まで機械が返す仕組みができます。

問い合わせの性質	見分ける材料	自動化の範囲
定型の回答で完結する（資料請求、料金の目安、対応範囲の確認）	回答が既存の資料に書かれており、相手ごとに変わらない	下書きから送信まで対象にできる
担当者の判断が要る（個別要件、見積、既存契約に関する相談）	回答に条件の当てはめや金額の判断が入る	下書きと材料集めまで。送信は人が確定させる
その場で返してはいけない（クレーム、契約解除、法務が絡む照会）	相手が不利益を主張している、または契約や法令の解釈が関わる	受け付けた事実だけを知らせ、内容は人が書く

3行目を最初に決めておくのが要点です。この区分に当たる問い合わせへ、体裁の整った文面が自動で返ると、相手には「読まれていない」と受け取られます。件名や本文に現れる語だけで判定しきれないため、判断に迷ったものは3行目として扱う、という寄せ方をしておきます。

1行目と2行目の切り分けは、社内の資料に答えが書き切られているかどうかで決まります。料金の目安を公開していない場合、料金の問い合わせは1行目ではなく2行目です。この判断は業種や商材ではなく、自社の資料の状態で決まります。

種類ごとに、どこまで自動で返すかを割り当てる

3つの区分は方針で、日々動かすのは種類ごとの割り当てです。届いている問い合わせをよくある種類まで下ろすと、次の形に落ちます。

問い合わせの種類	自動で返す範囲	人が持つ判断
資料請求・ダウンロードの依頼	資料の送付まで自動で完結できる	なし。送付先の記録だけ残す
料金の目安	公開している価格の記述をそのまま返す	価格を公開していない場合は目安を書かず、受付だけ返す
対応範囲・仕様の確認	資料に記述がある項目だけ返し、無い項目は空欄にする	資料に記述が無い項目への回答
納期・所要期間の確認	標準の期間を返す。相手の希望日への可否は書かない	稼働の状況を見た可否の返答
見積の依頼	受付と、不足している前提条件の確認を返す	金額と条件の確定
既存の契約に関する相談	受付だけ返す。契約の内容には触れない	契約書の読み合わせと回答の全文
不具合の申し出	受付と、切り分けに必要な情報の依頼を返す	原因の見立てと復旧の見通し
苦情・契約解除の申し出	受け付けた事実だけを返す	回答の全文。謝罪の言葉を入れるかどうかも含む
採用・取材など宛先が違うもの	該当の窓口へ回した旨を返す	回す先を誤ったときの引き取り

真ん中の列で線を引いているのは、相手の役に立つ情報を含めて返せるかです。上の4行は資料に書かれた内容を返せるため、一次返信がそのまま回答か、回答の一部になります。見積より下の行で返しているのは回答ではなく、届いたことを待たせずに知らせる通知です。この違いを混ぜると、受付通知を回答と数えてしまい、返信までの時間だけが短く見えます。

納期の行を「標準の期間まで」に切っているのは、相手が聞いているのがたいてい自分の希望日への可否だからです。標準の期間を返すだけでは相手の質問に答えていないため、この行は自動で返しつつ担当者へも渡し、可否は人が続けて出します。

割り当ては固定ではなく、資料が整うほど上へ動きます。料金を公開すれば料金の行は自動で完結する側へ移り、仕様の一覧を書き足せば対応範囲の行の空欄が減ります。自動で返せる件数を増やす作業は、多くの場合、仕組みではなく資料の側にあります。

受付から送信までの流れをつなぐ

仕分けの結果ごとに処理を分けると、全体は次の形になります。

3bで担当者へ渡すときは、問い合わせの本文だけでなく、過去の類似する問い合わせと参照した資料の該当箇所も一緒に渡します。渡す情報が本文だけだと、担当者は結局ゼロから探すことになり、短縮できるのは仕分けの時間だけになります。

3cは、受け付けたことを知らせる文面だけを自動で送り、内容には触れません。ここで「ご不便をおかけしました」のような踏み込んだ文言を機械に書かせると、事実関係が確定する前に非を認めた形になりかねません。定型の受付通知にとどめます。

返信文で事実をどう扱うか

返信の下書きは、過去の返信履歴とサービス資料を参照させて作ります。ただし、参照させれば正しい文面になるわけではありません。分けて設計するのは次の2つです。

言い回しは履歴から学ばせてよい。 挨拶の運び方、質問への答え方の順序、締めの一文は、過去に送った返信を参照させると自社の調子に寄ります。

事実は決められた記述からしか引かせない。 価格、納期、対応範囲、実績の数値は、参照先を1か所に定めて、そこに書かれた表現をそのまま使わせます。過去の返信履歴には、当時の価格や期間限定の条件が混ざっています。履歴を材料に価格を書かせると、現在は無い条件を提示することになります。

そのうえで、参照先に無い情報は書かせないという動作を明示的に入れます。相手が聞いている項目に対応する記述が見つからないとき、それらしい文章で埋めるのではなく、その項目を空欄にして担当者へ渡します。社外へ出る文面では、この「書かない」動作が精度そのものより効きます。

参照先の作り方には、資料を検索して引く形と、モデル側に学習させる形があります。価格や条件のように改定が入るものは、資料を差し替えれば反映される前者が向きます。判断の材料は RAGとファインチューニングの違い にまとめています。

メールの本文から項目を取り出して後続の処理へ渡す組み方そのものは、受発注業務をAIで自動化する と同じ形になります。取り出した値をそのまま登録するのではなく、確からしさで人の確認を挟む点も共通です。

面談の日程調整で決めておくこと

面談の希望が含まれる問い合わせでは、候補日の提示まで進めます。ここで扱う判断は3つです。

誰が対応するか。 問い合わせの内容と、担当の割り当て規則（地域、既存取引の有無、順番）を突き合わせて決めます。規則が決まっていない状態で自動化すると、空いている人へ割り当てるだけの仕組みになり、後から担当を付け替える手間が増えます。

どの空き時間を出すか。 カレンダーの空きをそのまま出すと、移動の時間や準備の時間まで候補になります。前後に確保する時間、1日に入れてよい件数、提示する候補の数と範囲を決めておきます。

いつ確定するか。 相手が候補から選ぶまでの間、その枠を仮に押さえるか、押さえないかを決めます。押さえない場合は、相手が選んだ時点で埋まっている可能性が残ります。押さえる場合は、期限を過ぎたら自動で解放する処理を入れないと、カレンダーが仮の予定で埋まります。

二重予約が起きる経路と、それぞれの止め方

候補を出したときの状態を信用したまま登録すると、重なりが後から見つかります。重なりが入り込む経路は3つに分かれ、それぞれ止め方が違います。

重なりが起きる経路	起きる場面	止め方
候補を出してから相手が選ぶまでの間に別の予定が入る	相手の返信が翌日以降になる、社内の打ち合わせが先に入る	予定を登録する直前に空きを再確認し、埋まっていれば代わりの候補を出して送り直す
同じ枠を複数の相手へ同時に提示している	同じ日に複数の問い合わせが届き、それぞれへ同じ候補日を出す	提示した枠と提示先を記録し、提示中の枠は次の候補から外す。または提示の時点で仮に押さえ、期限が来たら解放する
同じ問い合わせから予定が2件作られる	相手が候補を2回選ぶ、返信が重複して届く、予約ページと返信の両方から選ばれる	1件の問い合わせに対して予定は1件だけ作る決めにし、2件目は既存の予定の変更として扱う

1つ目は確定の直前の再確認で止まりますが、2つ目と3つ目は再確認だけでは残ります。同じ枠を2人へ提示している場合、どちらの登録も再確認の時点では空いているため、先に選んだ相手の予定が入った後で2人目が同じ枠を選びます。同じ問い合わせから2件作られる場合は、そもそも空きの確認をすり抜けます。

見る範囲も決めておきます。担当者の予定が個人のカレンダーと部署のカレンダーに分かれていたり、会議室や移動の時間を別に持っている場合、片方だけを見て候補を出すと、提示した時点で既に重なっています。候補を出すときに参照するカレンダーを列挙し、そのすべてが空いている枠だけを候補にします。

それでも重なりは残るため、見つかった後の手順も先に決めます。どちらの予定を残すか、相手へ変更をお願いする連絡を誰が出すか、その文面を誰が書くかです。この連絡は自動で送らず人が出します。相手の予定を動かしてもらう依頼であり、こちらの都合で起きた重なりだからです。あわせて、同じ担当者の同じ時刻に予定が2件ないかを定期的に照合すると、当日まで気付かない状態を避けられます。

時間帯の書き方をそろえる

時間帯のずれは、相手と自社の所在地が違う場合に起こります。候補日を出す文面には時間帯を明示し、内部の記録は同じ基準の時刻で持ちます。文面に書かれた時刻と登録された時刻がずれると、面談当日まで気付けません。

候補日の伝え方と、確定した後のやりとり

候補日を出すところまでを決めても、相手にどう選んでもらうかを決めていないと、そこから先が手作業に戻ります。伝え方は2通りあり、どちらを選ぶかで確定までの手順が変わります。

候補日の伝え方	相手の側の手間	重なりと運用への影響
返信の本文に候補日を3〜4件書き、相手が文章で選ぶ	追加の操作が不要で、相手の環境を選ばない	選ばれた日時を読み取って登録する工程が残る。返信が届くまでの間に枠が埋まりうる
予約ページのURLを送り、相手が空き枠から選ぶ	リンクを開く操作が要る。社内の規程で外部サイトを開けない相手がいる	選ばれた時点で枠が確保されるため重なりにくい。空き枠をそのまま外へ見せてよいかの判断が要る

どちらか一方に寄せきらないほうが止まりません。原則を予約ページにしたうえで、開けない相手には返信の本文に候補日を書く経路を残しておきます。この切り替えは相手ごとの属性で決められるため、判定の条件に入れておけます。

確定した後のやりとりも設計に含めます。前日のリマインドを送るかどうか、日程の変更依頼が来たときにどこまで機械で扱うか、相手が現れなかったときに誰が追いかけるかを先に決めておきます。変更依頼は「来週以降で」のように条件だけが書かれてくることが多く、候補日を出し直すところまでは機械で作れますが、相手の事情を汲んだ調整が要る場合は担当者へ渡します。

変更とキャンセルは、最初に候補日を出したのと同じ経路で扱えるようにします。別の経路で処理すると、カレンダー上の予定と受付の記録が食い違い、どちらが正しいかを確かめる作業が増えます。

送信前の確認から自動送信へ移す

最初から自動で送る設計にはしません。送信前に人が確認する運用で始め、記録を見て種別ごとに移していきます。

段階	扱う範囲	次へ進める条件
第1段階	すべての種別で下書きだけを作り、人が確認して送る	下書きの手直しがどこに集中しているかが記録から読める
第2段階	資料請求など、回答が完全に固定の種別だけ自動で送る	その種別で手直しがほぼ発生しない状態が続いている
第3段階	料金の目安や対応範囲など、資料の記述をそのまま使う種別へ広げる	事実の記述が参照先と一致しており、無い情報を書いていない
第4段階	面談の候補日の提示まで自動で行う	割り当ての規則と仮押さえの扱いが決まり、二重予約が出ていない
対象外	判断が要るもの、その場で返せないもの	段階を問わず人が確定させる

進める判断は、体感ではなく手直しの記録で行います。第1段階で人が下書きをどう直したかを残しておくと、直しが集中している箇所が種別ごとに見えます。直しの多くが事実の記述に関するものなら、参照先の資料を直すのが先で、自動送信へ進める段階ではありません。

戻す条件も同時に決めます。誤った内容を送ってしまった場合に、その種別を第1段階へ戻す判断を誰がするかを決めておかないと、問題が起きた後の対応が個別の判断になります。

効果をどう見るか

見るのは2つです。返信までの時間と、取りこぼしの件数です。

返信までの時間は、届いてから最初の返信を出すまでの間隔を種別ごとに測ります。全体の平均だけを見ると、自動で返した定型のものが平均を引き下げ、担当者が扱う問い合わせの遅れが隠れます。種別ごとに分けないと、改善したい部分の数字が見えません。

取りこぼしは、届いたのに返信していない問い合わせの件数です。仕組みを入れる前は、この件数を把握していないことがほとんどです。受付の記録を残す形にすると、返信の有無を機械的に照合できるようになります。件数が減ったかどうかより、まず数えられる状態にすることに意味があります。

このほかに、面談まで進んだ件数と、下書きへの手直しの割合を記録します。面談まで進んだ後、提案書の下書きを同じ考え方で組む設計は 提案書作成をAIで自動化する で扱っています。どちらも下書きまでを機械が用意し、外へ出す内容は人が確定させる形です。手直しの割合は、自動送信へ進めてよいかの判断に直接使います。効果額の出し方や投資判断への持ち込み方は、AI導入の効果測定と投資判断 の考え方が使えます。

社外へ出る文面と情報の取り扱い

問い合わせの本文には、相手の氏名や連絡先、場合によっては相手の社内事情が含まれます。これを外部のサービスへ渡してよいかは、利用する契約の形態と社内の規程を突き合わせて判断します。入力した内容が学習に使われない形になっているか、保存の場所と期間がどうなっているかを確認します。

判断の枠組みそのものは 生成AIの社内利用ルールをどう作るか で扱っています。問い合わせ対応では、扱う情報が社外の第三者のものである点が社内文書と違います。自社の判断だけで扱いを決められない情報が含まれるため、渡す範囲を狭く取り、氏名や連絡先を処理の対象から外せる場合は外します。

送った文面と、そのとき参照した資料は記録として残します。後から「なぜこの金額を提示したか」を確認する必要が出たときに、記録が無いと経緯を追えません。

どこから手を付けるか

順序は次の形になります。

1. 直近1か月の問い合わせを3つの種別に分類し、それぞれの件数を数える
2. 1行目に当たる種別について、返信の材料になる資料が揃っているかを確認する
3. 判断が要るものとその場で返せないものを、人へ渡す経路として先に作る
4. すべての種別で下書きを作り、人が確認して送る運用を始める
5. 手直しの記録を見て、固定の文面で足りる種別から自動送信へ移す
6. 割り当ての規則と仮押さえの扱いを決めてから、日程調整を対象に入れる

3を4より先に置くのは、渡す経路が無い状態で下書きを作り始めると、扱えない問い合わせが行き場を失うためです。6を最後にするのは、日程調整が相手のカレンダーにも影響するため、間違えたときの手戻りが返信より大きいからです。

検証から本番運用へ進める判断や見積の考え方は AIエージェント開発の進め方 を参照してください。問い合わせ対応は入口と出口がはっきりしているため、範囲を区切って始めやすい業務です。

まとめ：問い合わせの一次返信と日程調整を組むときの要点

• 届いている問い合わせを、定型で完結するもの・担当者の判断が要るもの・その場で返してはいけないものの3つに分け、種別ごとに自動化の範囲を決める
• 3つの区分は方針で、実際に動かすのは種類ごとの割り当て。資料請求や料金のように資料の記述で返せる種類は一次返信がそのまま回答になり、見積や契約の相談は受付だけを返して回答は人が書く
• 「受付だけ返す」を回答と数えない。数えると返信までの時間だけが短く見える
• 判定に迷ったものは、返してはいけない側へ寄せる。体裁の整った文面が誤って返る影響のほうが大きい
• 返信文は、言い回しを過去の履歴から学ばせる一方で、価格や納期のような事実は決められた記述からしか引かせない。参照先に無い情報は書かせず担当者へ渡す
• 日程調整では、担当の割り当て規則、提示する空き時間の条件、仮押さえの期限を先に決める
• 二重予約は3つの経路で起きる。確定の直前の再確認で止まるのは1つ目だけで、同じ枠の重複提示は提示先の記録か仮押さえ、同じ問い合わせからの二重登録は「予定は1件だけ作る」という決めで止める。重なりが見つかった後の連絡は自動で送らず人が出す
• 候補日は予約ページで選んでもらう形を原則にしつつ、外部サイトを開けない相手には返信の本文で候補日を出す経路も残す。日程の変更とキャンセルは最初と同じ経路で扱う
• 送信前に人が確認する運用から始め、手直しの記録を見て種別ごとに自動送信へ移す。戻す条件も同時に決めておく
• 効果は返信までの時間と取りこぼしの件数で見る。時間は種別ごとに分けて測らないと、遅れている部分が平均に隠れる

Augueでは、問い合わせの仕分けから返信の下書き、日程調整までを含むAIエージェントの開発に対応しており、どこまでを自動で送りどこから人が確定させるかの線引きから一緒に設計できます。自社の問い合わせのどれを対象にできるか判断したい方は、是非ご相談ください。

関連する記事

社内向けの問い合わせ対応は 社内問い合わせ対応をAIで自動化する、メールを読み取って後続の処理へ渡す型は 受発注業務をAIで自動化する、過去資料の使わせ方は RAGとファインチューニングの違い、面談の後に提案書の下書きを組む側は 提案書作成をAIで自動化する を参照してください。

よくある質問

既製のチャットボットや日程調整ツールを入れるのと、自前で組むのはどちらがよいですか？

問い合わせの種類が少なく、回答が固定の文面で足りるなら既製のツールで用が足ります。自前で組む必要が出るのは、既存の顧客管理や在庫のデータを見ないと返せない問い合わせが多い場合と、返信の記録を自社の基準で残したい場合です。判断の材料は、直近の問い合わせのうち何割が固定の文面で返せるかという実数です。

導入にかかる費用と期間の目安はどれくらいですか？

一律の金額は出せません。接続するシステムの数と、返信の材料になる資料がどれだけ整っているかで大きく変わります。見積を比べるときは、資料を整える工程が誰の作業として入っているか、公開後に返信内容を見直し続ける費用が含まれているかを確認します。この2つが抜けた見積は、動き出したあとで追加になります。

英語など日本語以外の問い合わせも同じ仕組みで扱えますか？

仕組みとしては同じですが、返信の材料になる資料がその言語で用意されているかが分かれ目になります。資料が日本語しかない状態で他言語の返信を作らせると、価格や条件の言い回しが訳の過程でずれます。当面は受付と種別の判定だけを共通にして、返信そのものは担当者が書く形から始めるのが無難です。

返信の精度が上がらないとき、何を見て原因を切り分けますか？

種別の判定を間違えているのか、種別は合っているが文面の材料が足りないのかを分けて見ます。判定の誤りなら仕分けの条件を見直し、材料の不足なら参照している資料の側を直します。この切り分けができるように、受け取った問い合わせと判定した種別、参照した資料、送った文面を対にして残しておきます。