AIで複数言語の顧客サポートを実現する方法

要点

多言語チームを採用したり、言語ごとに別々のボットを構築する必要はありません。現代のAIモデルはデフォルトで多言語対応しているため、ヘルプドキュメントと過去のチケットで学習した1つのエージェントが、どの言語で届いたチケットも読み取り、80以上の言語で同じ言語で返信します。設定は一度だけ、市場ごとではありません。

注意点は、流暢さと正確さは同じではなく、最初に崩れるのはトーンだということです。つまり、本当の作業は翻訳ではなく、2つの判断です。定型文を機械翻訳するだけのエージェントではなく、自社のナレッジから回答するエージェントを選び、実際の過去のチケットで言語ごとにテストしてから、顧客と会話させること。この2つをきちんと行えば、直接的な効果があります。CSA Researchによると、購入者の75%が、サポートが自分の言語で提供された場合、再購入する可能性が高いと回答しています。

すでにヘルプデスクを運用している場合、最も速いルートは、ヘルプデスクに接続し、既存のドキュメントから学習し、過去のチケットでシミュレーションできるAIヘルプデスクエージェントです。

これが思った以上に大きなレバーである理由

多言語サポートは、拡張後に取り組む「あったらいいもの」として扱われがちです。しかしデータによれば、これは収益の壁に近く、多くの企業がカスタマーサービスにAIを活用する主な理由のひとつです。

CSA Researchは29カ国の8,709人の消費者を調査し、76%が母国語での商品情報を好み、40%は別の言語のサイトでは絶対に購入しないことがわかりました。Unbabelの2021年の多言語CXレポートでは解約率も示されており、68%の人々が自分の言語でサポートを提供するcompetitors（競合他社）に乗り換えると回答しています。

このギャップは仮説ではなく現実です。Intercomのサポートチームとエンドユーザーの調査によると、88%のチームが複数言語のサポートを提供していると主張していますが、実際にそれを体験した顧客は28%に過ぎません。「提供している」と「体験した」の間のスペースで、顧客は静かに離れていきます。同調査では29%の企業が多言語サポートの欠如により顧客を失ったことも明らかになっています。

「Googleで何かを検索して母国語の結果を見ると、そのサイトのスタッフの中に話せる人がいると期待してしまう。」 – r/webdevの開発者、2025年2月

この引用が、偽ることが難しい理由のすべてです。母国語での返信は、本物のサポートが背後にあるという約束として読まれます。その約束をスケールで守ることが課題であり、それが次の問い「どうやって？」につながります。

実際に行う3つの方法

実質的にはアプローチは3つしかなく、品質、速度、コストのバランスがそれぞれ異なります。

ネイティブスピーカーのエージェントを採用する。 品質のゴールドスタンダードですが、スケールアップが最も難しい方法です。Intercomによるとサポートマネージャーの85%が複数言語を話すスタッフの採用が困難と回答しています。新しい市場ごとに新規採用、シフトカバー、席が必要になり、成長が採用を上回った時点で機能しなくなります。

ヘルプデスクに機械翻訳を追加する。 安価ですぐに使えます。Zendeckの自動翻訳やFreshdeskの多言語テンプレートなどのツールは、受信メッセージと返信をその場で翻訳します。問題は、顧客がそれに気づくことです。

「ウェブコピーやUIのAI翻訳はほぼすぐに気づく。ぎこちなくて安っぽい感じがする。」 – r/webdevの開発者、2025年2月

自社のナレッジでAIエージェントを動かす。 これが多くの人が知らない選択肢で、本質的に異なります。返信を翻訳するのではなく、エージェントは質問を読み取り、自社のヘルプセンターと過去のチケットから回答を見つけ、顧客の言語で新しい返信を書きます。翻訳ではなく、回答しているのです。繰り返しが多いティア1のボリュームには、これが最初に選ぶべき手段で、現代のサポートチケット自動化の多くで採用されているモデルです。ニュアンスやブランドに敏感なケースには人間の言語専門家を残すことと相性がよいです。AIと人間のトレードオフの詳細はこちらをご覧ください。

1つのAIエージェントが80以上の言語をカバーする方法

私はeeselでエージェント側に携わっており、最もよく受ける質問は「言語ごとに別々に設定する必要がありますか？」というものです。答えはノーで、なぜかを理解しておくことは予算計画やテストの方法が変わるため重要です。

基盤モデルはもともと多言語対応しています。すでにスペイン語、日本語、ドイツ語など80以上の言語を理解しているため、言語ごとのパイプラインを構築する必要はありません。ナレッジベースに一度接続すれば、そのナレッジがすべての言語での回答の源泉になります。本当のエンジニアリングは翻訳ではなく、その周辺の2つのことにあります。検索（ドキュメントから正しい回答を見つけること）とガードレール（回答しないタイミングを知ること）です。

2つ目の部分が信頼において重要です。優れたエージェントは信頼度ベースのルーティングを使用します。確信がある場合は顧客の言語で返信し、確信がない場合は推測するのではなく人間向けのドラフトを作成するか転送します。エージェントは自社のチケット履歴から言語パターンを学習するため、各市場での顧客の実際の言い回しを把握できます。

正直なところ：これが壊れる場所

これが多くのベンダーページが省略している部分です。流暢さと正確さは同じではなく、AIは間違っていてもとても正しそうに聞こえることが得意です。

「AIは多くの他言語より英語への翻訳の方が優れていることが多い…流暢に聞こえるのは得意ですが、必ずしも正確や適切ではありません。自信ありそうに見えて、実際には間違っていたり不自然だったりすることがあります。」 – r/TranslationStudiesのローカリゼーション専門家、2026年1月

これは自社エージェントでも経験しており、だから私は慎重なのです。初期に、ドイツ語やオランダ語を話す顧客に向けたドラフトに、UIの内部テキストや空のプレースホルダーが返信に直接漏れているケースがありました。名前が入るべき場所に生のfirst_nameトークンがそのまま残っているようなものです。英語では即座に気づきます。レビュアーが読めない言語では素通りしてしまい、それはまさにサポート担当者が本当にいないのだと顧客に伝えてしまうような細部です。その一度の経験が、現在すべての展開において言語ごとに過去のチケットでシミュレーションしてから公開する理由です。

初期に壊れる別のものは、ブランドボイスです。あるオペレーターは率直に述べました。

「以前は人間の翻訳者チームがいましたが、AI支援翻訳に切り替えました。私たちは'個性的な'ブランドアイデンティティを持っていましたが…AIツールにはそれができません。でも数字は上がりますね。」 – r/BetterOfflineのオペレーター、2025年9月

結論は「AIを使うな」ではありません。AIは大量の繰り返し業務を担いながら、トーンに気を配り、ニュアンスのあるケースは人間に任せるべきということです。ボイスのコントロールや整備されたエスカレーション設定ができないツールは問題を引き起こします。コミットする前に最高のAIヘルプデスクソフトウェアと比較検討する価値があります。

実際の展開方法

これらすべてを踏まえて、私が取る手順を紹介します。意図的につまらない内容ですが、つまらなさがドイツ語での公開ミスを防いでくれます。

1. ヘルプドキュメントと過去のチケットを接続する。 これがエージェントの真実の源泉です。ナレッジベースが充実しているほど、すべての言語が良くなります。全言語が同じ源泉から引き出しているからです。
2. 言語別に分けた実際の過去のチケットでシミュレーションする。 これが省略されて後悔するステップです。数千件の過去チケットに対してエージェントを動かし、言語ごとのカバレッジを確認します。ドイツ語が80%でも、ボリュームの少ない言語が40%かもしれません。クレーム後ではなく、公開前にドキュメントを補充すべき場所がわかります。
3. 確実な返信のみで公開する。 エージェントが確信しているケースは自動処理させ、その他はすべて人間に転送します。「AIがすべてに答える」に切り替えるのではなく、まず簡単な勝利を任せます。これは1言語で機能するティア1のデフレクションパターンと同じで、すべての言語に拡張したものです。
4. 精度が維持されたら自律性を広げる。 数字が安定したら、エージェントにより多くを任せます。チームによる修正が反映されるため、時間の経過とともに自社の特定の言い回しに対してより良くなっていきます。

これは理論ではありません。eeselの顧客である融資マーケットプレイスのSmavaは、完全自動化されたZendeskエージェントを運用しており、月に10万件以上のドイツ語チケットを処理しています。これは私たちの最大規模の展開の一つです。このボリュームが機能するのは、言語処理とガードレールがスケールアップ前にテストされていたからです。

実際のコスト

ここでの価格の驚きは嬉しいものです。コストは対応言語数ではなくチケット量に応じて発生します。1つのエージェントがすべてを処理するため、日本語サポートを追加しても日本語の請求書は来ません。言語ごとのライセンスもなく、新しい市場を担当する追加の席も必要ありません。

各言語が新しい採用や翻訳ツールの新しいティアを意味していた従来のモデルとは大きな違いです。eeselのような従量課金制では、言語に関係なくエージェントが処理する1チケットあたりの料金を支払うだけで、座席料はかかりません。人間エージェントとのより広いコスト比較を見ると、2〜3市場以上をカバーすると差が急速に広がります。

eeselですべての言語をサポート

Zendesk、Freshdesk、Gorgias、Front、またはHelp Scoutを使っている場合、eeselは数分でヘルプデスクに接続し、80以上の言語を既に話し、持っているヘルプドキュメントと過去のチケットから回答する新しいチームメンバーのように機能します。差別化要素はシミュレーションモードです。実際のチケット履歴全体で動かし、各言語でどう回答したかを正確に確認し、ギャップを埋めてから、確信のないチケットでは推測しないよう信頼度ベースのルーティングで公開します。クレジットカード不要で無料で試せます。

多言語サポートはかつて採用の問題でした。今はセットアップとテストの問題であり、それははるかに良い問題です。ナレッジベースを正しく構築し、公開前にシミュレーションし、人間が必要なケースには人間を残せば、翻訳チームを構築せずに顧客に自分の言語で答えることができます。