DeepSeekでFreshdeskの英中バイリンガル・チケットを大量にさばく方法

要点： DeepSeekはFreshdeskのキュー内で言語判定、意図分類、振り分け、返信下書きまでこなせます。英中混在のデスクが本当に壊れるのは翻訳ではなく振り分けの段階です。モデルはキューの手前とレビュー担当の手前に置き、品質は訳文の読み心地ではなく解決したかどうかで測り、チケットのデータがどこへ行くかを把握してください。

二言語を扱うサポートキューの難しさは、一言語の二倍ではありません。それ以上です。違うのは言語だけではないからです。深圳の顧客からの中国語チケットと、シンガポールの顧客からの英語チケットは、どれだけ前提を書くかの慣習が違い、応答速度への期待が違い、しばしば対象製品まで違います。「翻訳が必要だ」と捉えたデスクは最も簡単な部分を解いて、費用のかかる部分に手を付けていません。

この記事はチャネルではなくキューの話です。中国側の顧客が企業微信から来ているなら、それは別の「入り口」の問題で、DeepSeekと企業微信のバイリンガル対応で扱いました。ここでは、二言語のチケットがすでに相当な量でFreshdeskに届いている前提で、ではどうするかを考えます。

混在キューで最初に壊れるもの

翻訳よりずっと前に、振り分けが壊れます。 どのチケットでも最初の判断は「誰が持つか」で、二言語デスクではその判断が、誰も確実に設定していない言語という属性に依存します。顧客は好きな言語で書き、時には一件の中で両方を使います。顧客の国や受信アドレスに基づくルールは十分な頻度で外すので、担当者はそれを信用しなくなり、手作業で仕分け始めます。まさに避けたかった手作業です。

初回応答時間が言語で分岐します。 中国語対応が三人、英語対応が十二人なら、中国語キューの初回応答時間は静かにずれていき、ずれ続けます。デスク全体の一つの指標に平均されて、見た目は問題ないからです。構造的な不具合の最初の確かな証拠になることが多く、しかも数か月遅れて表に出ます。

ナレッジベースが一言語しかありません。 中国語で答える担当者は毎回、英語の記事を読んでその場で訳しており、その成果は何も記録されません。同じ質問に対して六人から六通りの中国語の答えが出て、そのどれもナレッジベースに戻りません。

エスカレーションで情報が落ちます。 中国語で始まり英語話者のエンジニアへ上がるチケットは、翻訳者ではない人が時間に追われて書いた要約として届きます。細部が最も重要な地点で、細部が失われます。

誰も検証できません。 品質のクレームが来ても、バイリンガルの担当者をキューから外してチケットを読ませない限り、もう一方の言語で何が交わされたのかを遡って確認する方法がありません。つまり実際には、誰も見ません。

FreshdeskのチケットライフサイクルにおけるDeepSeekの位置

役に立つ捉え方はこうです。モデルは担当者がチケットを開く前の仕事と、担当者が書いている最中の仕事をします。顧客が満足したかどうかを判断する仕事はしません。

言語判定・分類・振り分け——下書きより先に

まずここを作り、返信の下書きへ飛びたい誘惑に抗ってください。価値の大半はここにあり、最も安全な出発点でもあります。チケット作成時に件名と本文をモデルへ送り、厳しく制限した少数の項目だけを返させます。主要言語、混在かどうか、製品領域、意図カテゴリ、そして感情または緊急度のフラグ。それらをFreshdesk APIでカスタムフィールドへ書き戻し、既存の自動化ルールが他の項目と同じように動くようにします。

うまくいくか厄介物になるかを分ける設計点が二つあります。第一に出力を制約すること。各項目の許容値を明示的に与え、迷ったときはカテゴリを創作せず指定の「不明」を返させます。「不明」に落ちて人が仕分けるチケットは良い結果で、自信満々に誤分類されたチケットはそうではありません。第二に、割り当ての判断そのものにはモデルを関与させないこと。モデルは属性を設定し、振り分けルールが割り当てます。この分離があれば、モデルに触れずに振り分け方針を変えられますし、監査証跡は本来あるべきヘルプデスク側に残ります。

言語が推測ではなく信頼できる項目になると、多くのデスクが到達できないもう一つのことが可能になります。言語別のレポートです。初回応答時間、解決時間、再オープン率、満足度を、すべてチケット言語で切る。先ほどのずれが、まだ安く直せるうちに見えるようになる唯一の方法です。

下書き＋レビュー方式の返信と、品質の正直な測り方

返信の下書きは目立つほうの半分で、二番目に作るべきものです。うまくいく型は地味です。モデルが該当するナレッジ記事とチケット履歴に基づいて顧客の言語で下書きを作り、担当者が直して送る。書き手は担当者のままで、自動送信は一切しません。

DeepSeekがこの仕事に向いているのは、中国語と英語のどちらかを翻訳先として扱うのではなく、両方をネイティブに扱うからです。これは語調に効きます。英語から訳した中国語の返信は訳文らしく読め、中国語で書かれた返信はサポートらしく読めます。ホスト型APIを使うか、オープンウェイトのモデルを自社基盤で動かすかで、データガバナンスの絵は大きく変わります。この選択は後段で扱います。

測り方こそ、多くのチームが自分を騙すところです。翻訳品質のスコアが教えるのは文章が流暢かどうかであって、顧客の問題が解決したかどうかではありません。的外れでも流暢な返信は、どちらのスコアも良く出ます。結果を映すものを測ってください。下書きと実際に送った文面の編集距離、初回接触解決率、七日以内の再オープン率、そして言語別の満足度。下書きが大幅に書き直されているなら、原因はたいていモデルではなくナレッジベースです。下書きがそのまま送られていて再オープン率が上がっているなら、レビュー工程が静かに形式化しています。

現実的な展開——パイロットキュー、品質ゲート、そして拡大

まず分類だけを、本番トラフィックで、結果は担当者に見せずに走らせる。 二週間、受信チケットにモデルを掛け、振り分けに使われないフィールドへ出力を書きます。そのうえで、言語とカテゴリの判定を実際のデスクの処理と突き合わせます。自社の実チケットにおける本当の精度が分かります。ベンチマークでは分からず、外していても代償はありません。

一つの製品領域だけで振り分けを有効にする。 傾向が見える程度の量があり、失敗を吸収できる程度に影響の小さいキューを選びます。手動での付け替えを目立たせ、簡単にし、担当者がどれだけ使うかを見ます。その回数こそが本当の精度の指標で、自前の評価より正直です。

志願した少人数の担当者に下書きを開放する。 自分から試す人は下書きの何が悪いかを教えてくれます。押し付けられた人は迂回します。志願グループにはワンクリックで悪い下書きを報告する手段を用意し、最初の一か月はすべての報告に目を通してください。

用語集は拡大の後ではなく前に作る。 この段階までに、繰り返し起きる翻訳問題が集まっているはずです。訳してはいけない製品名、公式の中国語表記がある機能名、業界一般とは違う自社独自の用語。その一覧が、このプロジェクトで最も効き目のある成果物です。

野心ではなく量に合わせて広げる。 前のキューの再オープン率が安定してから次へ進みます。ここでの失敗は劇的な事故ではなく、返信品質の緩やかな低下です。徐々に起きるので、誰もそれを展開のせいだとは考えません。

AI支援のバイリンガル分類 vs バイリンガル人材の採用 vs デスクの外注

• 少量時のコスト — 採用が有利です。月に数百件までなら、本当にバイリンガルな担当者が二人いれば問題は完全に解け、何かを作る工数より安く済みます。
• 大量時のコスト — AI支援の分類が明確に有利です。追加で千件を分類する限界費用は小さく、バイリンガル人材を一人増やす限界費用は小さくありません。しかも多くの市場でバイリンガルの技術サポート人材は本当に希少です。
• 複雑な案件の品質 — 採用の勝ちで、差は大きい。熟練したバイリンガル担当者は、機微、苛立ち、曖昧さを、どんな下書きワークフローにも真似できない形で扱います。だからこそバイリンガル人材は定型ではなく難案件に置くべきです。
• 時間帯のカバー — 外注が有利です。適切な時間帯に人がいるベンダーは、小さな自社チームには作れない夜間対応をくれます。企業が外注する本当の理由はここであることが多い。
• 製品知識 — AI支援の有無にかかわらず自社が有利です。外注デスクが製品の深さを身につけるには数か月かかり、担当者が入れ替わるたびに失われます。この方式への不満は、たいていここに集約されます。
• 顧客データの統制 — 自社運用モデルの内製が最も強く、次にホスト型APIの内製、外注が最後です。外注はすべてデータ処理の委託であり、契約書もそのように整えるべきです。
• 改善の速さ — AI支援が有利です。体系的な問題を直すのはプロンプトと用語集の編集で、その瞬間からすべてのチケットに効きます。同じ問題をチーム全体で直すには、人を再教育する必要があります。

うまくいっているデスクの多くは、勝者を選ばずに組み合わせに落ち着きます。定型量の言語判定・振り分け・初稿はAI、エスカレーションと品質レビューは小さなバイリンガルチーム、誰も入りたがらない時間帯は外注、という形です。

実際に持ちこたえる品質統制

推奨ではなく強制される用語集。 製品名、機能名、エラーコード、法務表現は、毎回のプロンプトに入る用語データベースに属します。製品命名の責任者と月次で見直してください。恥ずかしい出力の最大の発生源がここです。

言語ごとの語調仕様。 サポートの中国語とサポートの英語は語彙以上に違います。率直さの度合い、適切とされる謝意の量、断り方の言い回し。各言語でのデスクの声を書き出し、プロンプトに入れてください。英語の語調ガイドを訳せば通じる、とは考えないことです。

明示的なエスカレーション基準。 モデルが決して下書きしてはならないものを先に定義します。返金、契約上の約束、セキュリティインシデント、法的な脅し、規制当局の名前が出るもの。これらは下書きを付けずに即座に人へ回します。下書きは錨になり、時間に追われたレビュー担当は書き直すのではなく手直ししてしまうからです。

本当に続けられる抜き取り監査率。 AI支援チケットの一定割合——五パーセントが妥当な出発点です——を決め、バイリンガルのレビュー担当が毎週、両言語のやり取りを通しで読みます。見つかったことは個別事案ではなく傾向として追ってください。三週間で止まる監査は、ないより悪い。証拠なしに安心だけを生むからです。

目に見える停止スイッチ。 デスクの全員が、あるキューの下書きを止める方法を知っていて、許可を求めずに止めてよいことになっているべきです。深夜三時にモデルが変な出力を始めたら、気づいた人が止められなければなりません。

正しく進めるために——チケットデータ、越境移転、ITに任せる範囲

サポートチケットは中小企業が日常的に扱うデータの中でも特に機微で、統制が最も薄い部類です。一件の中に顧客の氏名、連絡先、注文履歴、セッショントークンが映り込んだスクリーンショット、同僚の病気休暇への何気ない言及が同居し得ます。その内容をモデルのエンドポイントへ送ることは処理活動であり、顧客が中国本土にいる場合は個人情報保護法の下での越境移転になり得て、義務は量とデータ種別によって変わります。香港のPDPOとシンガポールのPDPAは、通知の仕方や委託先との契約について独自の要件を課します。どれもプロジェクトを不可能にはしませんが、後から発見するのではなく設計すべき事柄にします。

実務上の統制は、ごく普通のものをきちんとやることです。送信前に伏せる——添付を外し、カード番号や識別子を決定的な規則でマスクし、中身が分からないスクリーンショットを画像エンドポイントへ送らない。配置は意図して選ぶ——ホスト型APIは立ち上がりが速い代わりに、相手の条件のもとで相手の基盤にデータを置きます。統制下のリージョンでオープンウェイトのモデルを動かせば、チケット内容は境界内に留まりますが、運用の手間は自分持ちです。どちらも正当な選択で、ただ一方は「なんとなく」選ばれてはいけません。APIキーはヘルプデスク自身の設定から出してシークレット管理に置き、費用アラートを付けてください。壊れたチケットでループする連携は、週末のあいだ平然とループし続けます。

サポートの案件がIT の案件に変わるのが、この層です。BrocentのAPAC ITサポートソリューションは、まさにこの形の課題を前提に組み立てられています。階層をまたぐ多言語対応と、香港・中国本土・シンガポールにまたがるデスクが実際に必要とする地域規制への理解。AI+サポートは分類スキーマ、プロンプト、レビュー関門の設計を支援し、出力を速いだけでなく検証可能にします。管理型ITサポートは、実運用の量を担い始めたあとの連携、認証情報、監視を引き受けます。Brocentは2007年の北京での創業以来アジアで管理型ITを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

AIの翻訳が十分な品質かどうか、どう測ればよいですか？

翻訳指標では測りません。結果を測ってください。七日以内の再オープン率、初回接触解決率、チケット言語別の満足度。先行指標として、生成した下書きと送信した文面の編集距離を加えます。編集距離が下がりつつ再オープン率が上がっているなら、担当者が丁寧に読まなくなっています。固定サンプルに対する週次のバイリンガル抜き取り監査を回し、傾向として追ってください。

中国語のチケットにAIがレビューなしで返信してよいですか？

金銭、契約、セキュリティ、規制当局に触れるものは駄目です。そして多くの中小デスクにとって、正直な答えは「それ以外もまだ早い」です。機能する中間解は、実質的な内容を含まない受付確認と状況更新だけを自動送信し、答えは必ず人を通すことです。ベンダーのベンチマークではなく、自社チケットで六か月分の品質データが貯まってから見直してください。

チケット内容が国境を越えると個人情報保護法の義務が生じますか？

生じ得ます。個人がどこにいるか、どんなデータか、どれだけの量かによります。チケット本文には日常的に個人情報が含まれるので、国外のモデルエンドポイントへ送ることは技術的な細部ではなく、根拠を要する移転として扱ってください。顧客の相当割合が中国本土にいるなら、拡大の後ではなく前に配置方針をレビューに掛けることです。稼働中の連携にデータ所在の要件を後付けするのは高くつきます。

どのくらいの量から、バイリンガル人材の採用より有利になりますか？

万能の数字はありませんが、形は一貫しています。月に数百件までなら採用が単純に優れています。そこから数千件までの帯では、エスカレーション要員としてバイリンガル人材が必要なまま、振り分けと下書きでAI支援が勝ち始めます。それ以上になると、制約はコストではなく採用そのものになります。本当にバイリンガルな技術サポート人材は多くの市場で見つけにくく、給与の行よりもその希少性が決断を動かします。

一件の中に二言語が混ざっている場合はどうしますか？

主要言語を無理に決めず、「混在」を独立した分類値として扱ってください。無理に決めるところに振り分けの誤りが集中します。空いているバイリンガル担当者がいればそこへ回し、下書きは顧客の直近のメッセージで使われた言語で作らせます。たいていはその言語で答えを望んでいますが、決めつけずに確認する価値はあります。

Freshdesk以外のヘルプデスクでも使えますか？

使えます。ここに書いたことでFreshdesk固有のものは何もありません。必要なのは、チケット作成時のWebhookまたはトリガー、カスタムフィールドを書き戻せるAPI、そして送信前に担当者が下書きを見られる場所の三つです。Zendesk、ServiceDesk Plus、そして多くの現代的な製品はいずれも備えています。拡大の前に書き込み側のレート制限を確認してください。最初にぶつかる制約はそこです。

まずどこから

一か月分のチケットを書き出し、言語ごとの件数を数え、それぞれの初回応答時間を見てください。その二つの数字に意味のある差があるなら、この記事の問題はすでにあり、分類の工程だけで元が取れます。まずそれを作り、二週間は隠して走らせ、振り分けに使う前に判定と担当者の実際の行動を突き合わせます。返信の下書きは用語集ができるまで待ってください。分類スキーマ、データ取り扱いの設計、ヘルプデスク連携をまとめて整えたい場合は、お問い合わせください。