インバウンド対応×AIエージェント — 多言語問い合わせを任せる設計

海外からのお客様が増えるほど、現場に積み上がるのが外国語の問い合わせ対応です。

営業時間の質問、行き方、予約の確認、持ち物や決まりごと——内容の大半は定型なのに、言語の壁があるだけで一件ごとの負担が数倍になります。

しかも時差があるため、問い合わせは営業時間外にも届き続けます。

この領域は、AIエージェントがもっとも力を発揮しやすい場所のひとつです。

ただし「多言語チャットを置けば解決」ではありません。

うまくいくかどうかは、導入前の業務整理でほぼ決まります。

私たちは日本語と英語でのコンテンツ運用を自動化して回している経験から、その整理のポイントをまとめます。

最初に決めるのは「任せる範囲」

多言語のチャットを置けば問い合わせが減る、というのは半分しか正しくありません。

実際には、AIが自信を持って答えられる範囲を業務側であらかじめ決めておかないと、誤案内か「分かりません」の連発になります。

私たちの整理は、過去の問い合わせを3つに仕分けることから始まります。

• 定型で答えられるもの — 営業時間、アクセス、料金の案内、よくある質問（AIの担当）
• 条件によって変わるもの — 空き状況、天候次第の案内など（参照先を整えればAIの担当）
• 人が判断すべきもの — 予約の変更・キャンセル、決済トラブル、クレーム、体調・安全に関わる相談（確実に人へ）

最初の2つがAIの担当、最後は人に確実に渡す、という線引きです。

とくにお金と安全に関わるものは最初から人の領域と決めておくことで、残りを安心して任せられるようになります。

多言語対応は「下書き＋人の確認」で回る

外国語スタッフを言語ごとに揃えるのは、多くの現場にとって現実的ではありません。

実務的な解は、AIが各言語で回答の下書きを作り、人が確認して送る体制です。

私たちの日英でのコンテンツ運用もこの形で、外国語が得意な人が常駐していなくても、発信と応対の品質を一定に保てています。

ここでひとつ、運用から言える注意点があります。

翻訳が正確なことと、相手の文化で自然に受け取られることは別問題です。

同じ内容でも、言語圏によって期待される丁寧さや距離感は違います。

あいさつや断り方の「型」を言語ごとに一度決めておくと、AIの出力のばらつきが減り、応対の印象が安定します。

たとえば英語圏のお客様には結論を先に短く、依頼やお断りは率直に。

日本語の感覚のまま前置きの長い文章を訳すと、丁寧なつもりが回りくどい印象になります。

この「言語ごとの応対の型」は一度作れば使い回せる資産で、AIに渡すことで応対全体の品質が底上げされます。

ナレッジは「量」より「構造」

よくある失敗は、マニュアルやFAQをまとめて読み込ませて終わりにすることです。

情報が多くても、構造が曖昧だとAIは正しく引けません。

• 1つの質問に対する答えが1か所に定まっているか
• 古い情報と最新情報が混在していないか
• 「例外」がきちんと例外として書かれているか

ここを整えるだけで、同じモデルでも回答の精度は大きく変わります。

導入の成否は、AIの賢さより「渡す情報の整い方」で決まることが多い。

多言語運用ではもうひとつ原則があります。

正本はひとつの言語で管理し、各言語版はそこから生成することです。

言語ごとに別々のFAQを育ててしまうと、料金改定ひとつで全言語の整合が崩れます。

「日本語の正本を直せば、多言語版の下書きが自動で更新される」流れを作っておくと、更新の負担も整合性の問題も一気に軽くなります。

人への引き継ぎを最初から設計する

AIが答えきれない問い合わせは必ず出ます。

そのときに、会話の文脈を保ったまま人へ渡せるかどうかが体験を分けます。

私たちは「どこで」「誰に」「何を添えて」渡すかを、導入時の設計に必ず含めます。

多言語対応では、引き継ぎにもうひと工夫が要ります。

お客様は外国語で話していて、引き継がれるスタッフは日本語話者——ということが普通に起きるからです。

引き継ぎ時に「ここまでの経緯の日本語要約」をAIが添える設計にしておくと、スタッフは文脈を把握した状態から対応を始められ、お客様は同じ説明を繰り返さずに済みます。

引き継ぎの条件は「AIが困ったら」ではなく、「この種類の問い合わせが来たら」「この情報が確認できなかったら」のように、実装できる言葉で書き出しておくことも重要です。

最初の一歩は「上位10件のFAQ」から

導入の順番も、小さく始めるのが定石です。

過去の問い合わせ記録があれば、件数の多い順に並べてみてください。

多くの場合、上位10件ほどの定型質問が全体のかなりの割合を占めているはずです。

まずその10件について「質問と正解の対」を整え、一番問い合わせの多い言語ひとつで動かし始める。

ここで「AIの下書き→人の確認→送信」の型を作ってから、対象の質問と言語を広げていきます。

いきなり全FAQ・全言語を目指すより、この順番のほうが品質も現場の納得も積み上がります。

効果は「一次解決率」と「営業時間外」で見る

効果測定は、次の2つを見るのが実務的です。

ひとつは一次解決率——人に引き継がずに完結した問い合わせの割合。

もうひとつは営業時間外に対応できた件数——時差のあるお客様への応答は、導入前はそもそも「翌営業日まで待たせていた」ものなので、ここの改善は体験に直結します。

加えて、人が対応した問い合わせの内訳が「定型」から「判断が要るもの」へ移っていれば、狙い通りに機能している証拠です。

繁閑の波に強いのも利点

観光系の問い合わせには、季節や連休による大きな波があります。

人の体制をピークに合わせると閑散期に余り、閑散期に合わせると繁忙期に破綻する——このジレンマに対して、AIの一次対応は量の変動をそのまま吸収できるという強みがあります。

人は「AIから引き継がれた対応」に集中する形にしておくと、繁忙期の体感負荷が大きく変わります。

「忙しい時期ほど応対が雑になる」という悪循環を断てることは、リピートや口コミへの効き方も含めて、数字以上の価値があります。

よくあるつまずき

「チャットを置いて終わり」——導入がゴールになっているパターンです。

ナレッジの更新が止まれば、数か月で「役に立たないチャット」になります。

情報の置き場所と更新の担当を決めるところまでが導入です。

料金や営業時間が変わったのにチャットが古い案内を続ける——これは「AIの間違い」ではなく更新体制の問題ですが、お客様から見れば同じ誤案内です。

「全言語を一気に対応」——問い合わせの実績を見れば、大半は少数の言語に集中しているはずです。

まず一番多い言語で型を作り、そこから広げるほうが、結果として早く整います。

「機械翻訳を通すだけ」——前述のとおり、正確さと「自然に受け取られること」は別問題です。

型を決め、人の確認を挟む工程を最初から設計に入れておくべきです。

まとめ

• お金・安全に関わる対応は最初から人の領域と決め、残りをAIに任せる
• 多言語対応は「AIの下書き＋人の確認」で回す。言語ごとの応対の型を先に決める
• ナレッジは量より構造。正本はひとつ、各言語版は生成で維持する
• 引き継ぎには経緯の要約を添え、条件は実装できる言葉で明文化する
• 繁閑の波はAIの一次対応で吸収し、人は引き継ぎ対応に集中する
• 最初の一歩は上位10件のFAQ×最多言語から。効果は一次解決率と営業時間外対応で測る