Tencent Hunyuan で WeChat に顧客向け AI チャットボットを作る方法

要点：Tencent Hunyuan（騰訊混元）は、WeChat 公式アカウントやミニプログラムに届く繰り返しの商品・注文の質問に、WeChat のカスタマーサービスメッセージ API と自社の商品データを使って答えられます。置き換わるのはキーワード自動応答であって、カスタマーサービス担当者ではありません。そして顧客データを扱う公開面に置く以上、最初の 1 通目から中国個人情報保護法（PIPL）の義務が及びます。

中堅消費財ブランドの運用マネージャーが月曜に公式アカウントの受信箱を開きます。90 数件のメッセージ。約 3 分の 1 が「注文はどこにあるのか」。4 分の 1 がサイズについて。十数件が特定の省に発送できるかを尋ね、数件は経費精算用の請求書について尋ねています。本当の問題はおそらく 5 件——破損した商品、色違い、止まったままの返品。

2 人のスタッフが午前中のほとんどをこれに費やします。答えは毎日同じで、どこかに全部書いてあり、そして質問している顧客は購入までタップ 1 回の距離にいます。

標準のキーワード自動応答は既に有効になっていて、あまり役に立っていません。完全一致で照合するため、「什么时候发货」は発送テンプレートに当たり、「还要多久到」は何も返しません。見当違いの定型文を受け取った顧客は言い換えて聞き直しません——そのまま離脱します。

ここが Tencent Hunyuan で埋められる隙間であり、しかも店舗が既にいるエコシステムから出る必要がありません。

なぜ同じ商品の質問が毎日公式アカウントに溢れるのか

消費者向けの WeChat 面は、顧客がたまに使うサポートチャネルではありません。購買の意思決定が起きる場所そのものです。したがって質問は意欲が最も高い瞬間に届き、回答が遅いことのコストは「ユーザーが不快になる」ではなく「売上を失う」です。

量が構造的になる理由は 3 つ。質問が強く集中していること——注文状況、配送対応地域、サイズと仕様、返品交換、請求書でほとんどを占めます。言い回しが極端にばらつくこと。顧客は話すように打つからです。そして途切れず届くこと。夜間も週末も含めて、つまり対応する 2 人が勤務していない時間にも。

キーワード自動応答は、もっと単純な問題のために設計されています。実体はルックアップテーブルで、文字列に一致したら固定のテキストを返すだけ。誰かがその正確な言い回しを先回りしていない限り「我买的那个白色的还有货吗」は処理できませんし、注文を見ることもできません。

必要なのは、尋ねられたとおりの質問を理解し、答える前に実データを参照できるものです。それは別の種類のツールです。

Hunyuan をどこに置くか——公式アカウントの自動応答 vs ミニプログラムのチャット

Hunyuan はテンセントの大規模言語モデル群で、Tencent Cloud 経由で利用できます。WeChat 店舗にとっての実際的な利点は、モデルもクラウドもプラットフォームも同じベンダーであるため、データが店舗の稼働しているエコシステムの外に出ないことです——既に Alibaba Cloud にいる事業者がアリババのモデルを選ぶのと同じ論理です。

接続先の面は 2 つあり、互換ではありません。

公式アカウント（公众号） は、顧客が自発的に投げる質問が着地する場所です。ここでの返信は WeChat のメッセージング API を経由し、API にはサーバーがいつどう返信してよいかの独自ルールがあります。既存の量を吸収するのはこの面です。

ミニプログラム（小程序）のチャットウィジェットは店舗の内側、商品のすぐ隣にあります。UI は自社のものなので、モデルの回答をリアルタイムの在庫表示や注文を開くボタンと並べて出せます。転換を担うのはこの面です。

公式アカウントから始めてください。管理されていない量が既にそこにあります。

Tencent Cloud 経由の呼び出しと、WeChat カスタマーサービスメッセージ API

構成は 3 段です。WeChat が顧客のメッセージを自社運用のサーバーへ配信する。サーバーが質問と関連データを組み立てて Tencent Cloud 上の Hunyuan を呼ぶ。サーバーが WeChat のカスタマーサービスメッセージ API 経由で回答を返す。

設計を規定するプラットフォーム制約が 2 つあります。どの API を使えるかはアカウントの種別と認証状態に依存し、認証済みのサービスアカウントには購読アカウントに無い機能があります。またカスタマーサービスメッセージでの返信は、顧客自身のメッセージから一定の限られた時間枠内でのみ許されます。ルールは変わり、しかも何が可能かを決めるため、着手前に WeChat プラットフォームの最新ドキュメントで両方を確認してください。

この時間枠が意味するのは、これが応答型のシステムであって一斉配信のシステムではないということです——答える相手は今まさに質問した人であり、サポートには最適な形、マーケティングには不適な形です。

実際の商品・注文データに回答を接地させ、モデルに推測させない

有用なアシスタントと赤っ恥を分けるのがこの工程です。

自社データにアクセスできないモデルは「これは在庫がありますか」にもっともらしく、そして誤って答えます。有用であるためには、質問のその瞬間に実データが要ります。現在庫、商品仕様表、配送対応地域リスト、返品ポリシー、そして注文状況であれば実際の注文レコードへの照会です。

このやり方は「検索して渡す」であって「学習させる」ではありません。サーバーが関連する事実を取得し、質問と一緒にモデルへ渡し、渡されたものだけから答え、それ以外は分からないと言うよう指示します。回答の鮮度はデータベースと同じになり、価格の変更は価格を変えるだけで済み、何かを再学習させる必要はありません。

注文状況は特に慎重に扱う価値があります。最も量が多い質問であり、同時に誤答が最も痛い質問だからです。顧客の WeChat 上の識別で本人を特定し、サーバー側で注文を引き、モデルには実レコードを言い換えさせます。配達日を推測させては絶対にいけません。

実践的な構築手順——FAQ リストから稼働する店舗チャットボットまで

1. 1 か月分の実際の質問を書き出して分類する。推測ではなく実際のメッセージログを使います。バケットに分けて数える。多くの事業者で、注文状況・配送・サイズ・返品交換・請求書が大半を占めます。月に数件しかないものは今回のスコープ外です。

2. バケットごとに正典となる回答を 1 つ書き、その事実がどこにあるかを決める。返品ポリシーや請求書発行のように静的なテキストのものと、在庫・注文状況・対応地域のように都度参照が必要なものがあります。静的なものは初週に出せて、参照が要るものは連携が必要なので、印を付けて区別します。

3. まずサーバーを立てて公式アカウントに接続する。メッセージを受け取り、記録し、プレースホルダを返す。AI を入れる前にこの経路を端から端まで通します。最終的に出る問題の大半はプラットフォーム連携の問題で、今見つけるほうが安上がりです。

4. 静的回答のバケットにだけ Hunyuan をつなぐ。質問と承認済みの回答テキストを渡し、そのテキストだけからブランドの声で答え、範囲外なら引き継ぐよう指示します。これだけで相当な量を処理でき、しかもリスクはほぼありません。あなたが書いていないことは言えないからです。

5. ライブデータをつなぐ前に 1 週間観察する。会話をすべて読みます。バケットから漏れた質問と、より重要な点として、元のテキストを超えた回答が無いかを探します。それが止まるまで指示を締めていきます。

6. 注文照会を慎重につなぐ。チャットで注文番号を尋ねるのではなく WeChat のセッションで本人確認し、顧客に必要な情報だけを返し、モデルにはレコードの状態を解釈させずそのまま伝えさせます。一部出荷・返金処理中・キャンセル済みといった異常な状態の注文でテストしてください。自信満々の誤答が苦情になるのはそこです。

7. エスカレーション経路を作り、人を配置する。どの会話にも人に届く見える道、未照合または機微な質問での自動引き継ぎ、そして営業時間中にチームが実際に見るキュー。

8. 在庫と配送対応地域の照会は最後に足す。変化が激しく、古い回答はそのまま顧客とのもめ事になります。パイプラインを信頼できるようになってから接続してください。

9. 最初は週次、その後は月次で見返す。答えられなかった質問が来月のバケットです。ボットの回答に起因する苦情は、その週のうちに直す欠陥です。

AI 自動応答 vs WeChat 標準のキーワード自動応答 vs 有人カスタマーサービス

• Hunyuan による AI 自動応答。多様な言い回しを理解し、24 時間答え、ライブデータを参照できます。繰り返しの情報系の大半をうまく処理します。代償はサーバー、連携、そして継続的な保有責任で、キーワード照合では起こり得ない形で自信満々に誤ることが時折あります——接地とエスカレーションが「あれば良いもの」ではない理由です。
• 標準のキーワード自動応答。無料、即時、完全に予測可能——あなたが書いたテキストしか返せません。この予測可能性には本当に価値があり、営業時間のような固定の告知には今も正しい道具です。想定外の言い回しには全滅しますが、現実の質問はたいてい想定外です。
• 有人カスタマーサービス。判断、苦情、例外、そして金銭に関わるすべてを扱い、ポリシーを読み上げるのではなく実際にもめ事を終わらせられる唯一の選択肢です。夜間や販促ピークをコスト増なしに埋めることはできず、しかも今答えている内容の大半は人でなくても済みます。

機能する組み合わせは 3 つ全部です。固定の告知はキーワード応答、情報系の大半は AI、判断を含むものはすべて人へ。

必ず人に引き継ぐべき場面

金銭に関わるものすべて。返金、価格の争い、補償、決済の失敗。過大請求されたと思っている相手にボットがポリシーを読み上げれば、事態は悪化します。

苦情は、穏やかなものも含めて。「この品質はちょっと」は情報の問い合わせではありません。速やかに人へ渡すことが、それが公開レビューになるのを止める手段です。

注文に関する紛争すべて。荷物の紛失、誤配送、破損、止まった返品。これらに要るのは手順の説明ではなく、注文に対して動ける人です。

モデルが接地できない質問すべて。取得したデータに答えが無いなら、正しい振る舞いはそう言って会話を渡すことです。ここは必ず実地で検証してください。接地されていないモデルは、扱っていない商品について尋ねられると、しばしば作り出します。

同じ顧客からの繰り返しの質問。2 度目があるのは 1 度目が届いていない証拠なので、繰り返さずエスカレーションします。

ここを外さない——顧客の個人情報、PIPL 対応、そしていつ IT を呼ぶか

注文を照会した瞬間から、あなたは個人情報を取り扱っています。WeChat の識別子、注文履歴、住所、電話番号は PIPL 上の個人情報であり、それらを扱う公開のチャットボットは明確に適用範囲内です。適法な根拠、明確なプライバシー通知、必要最小限の取得、定めた保存期間——これらの義務は店舗本体と同じくこのシステムにも及びます。

モデルには回答に必要なものだけを渡す。「配達中です」と言うために顧客の住所全体は要りません。取得は狭く、隠せるものは隠し、本人特定の照会はプロンプトではなく自社システム側に留めます。

データがどこへ行き、どれだけ保持されるかを確認する。実際に使うサービスとリージョンについて Tencent Cloud の現行条項を確認し、会話ログの保存期間は意識的に自分で決めてください。ログを取るのが簡単だからと全会話を永久保存するのは、既定値ではなく判断です。

中国大陸だけの事業でないなら、越境は特に注意する。中国と海外の双方の顧客を持つブランドは、気づかないうちに個人情報を越境させてしまいがちで、それには別途の要件が伴います。店舗が複数市場にまたがるなら設計段階で解決してください——当社の APAC IT サポートチームが PIPL・PDPO・PDPA・APPI をまたいで対応しているのは、こうした問いが一つの法域で収まることがまれだからです。

ボットの出力は公開されたブランドの発信として扱う。保証、配送日数、製品の主張について述べたことは、ブランドが述べたことです。承認済みの回答テキストは、その責任者と一緒にレビューし、ログを保持してください。

サーバーは本番システムとして守る。API 認証情報を保持し、注文データに触れます。アクセス制御、シークレット管理、パッチ適用、監視は、ここでは基本要件であってオプションではありません。

方式の選定、接地とエスカレーションのルール設計、モデルに何を見せてよいかの審査は AI+ サポートの仕事です。その下のサーバー、認証情報、連携は通常のマネージド IT サポートです。社内向けの対応版と比較検討しているなら、DeepSeek による WeChat Work でのバイリンガル対応が従業員向けの側を、Alibaba Cloud でのカスタマーサービスチャットボット構築がもう一方の主要エコシステムでの同じ課題を扱っています。

よくある質問

カスタマーサービスの担当者を完全に置き換えますか？

いいえ。そう捉えることが典型的な失敗です。取り除かれるのは繰り返しの情報系の質問——注文状況、配送、サイズ——で、これらはメッセージ件数の大半でありながら難易度のほとんどを占めません。残るのは苦情、紛争、判断であり、本来チームが時間を使うべきだった部分です。人数を減らす計画ではなく、同じ人がより良い仕事をする計画にしてください。

顧客の注文データがモデルを通るのは安全ですか？

何を送るか、サービスをどう設定したかに依存します。だからこそ接地の設計が重要なのです。取得は狭く、回答に必要なフィールドだけを送り、本人特定は自社システムに留め、実際に使うサービスとリージョンについて Tencent Cloud の現行のデータ取扱い・保存条項を確認してください。PIPL の下で個人情報を処理するシステムとして扱ってください。実際にそうだからです。

WeChat Work 自身の AI 機能と何が違いますか？

製品も対象も違います。WeChat Work（企业微信）は社内向けの業務プラットフォームで、そのアシスタントが相手にするのは従業員と社内サポートデスクです。こちらは消費者向けの WeChat、公開面であり、まだ何の関係も無いかもしれない顧客に答えます。公開面では誤答の許容度がはるかに低く、扱うのが従業員ではなく顧客の個人情報である分、コンプライアンス上の義務も重くなります。

顧客が中国語と英語を切り替えても対応できますか？

言語処理そのものは概ね可能ですが、思い込まず自社のコンテンツで検証してください。より難しいのは、承認済みの回答テキストや商品データが中国語しか無い場合、英語の回答は「誰も英語でレビューしていない原文」のその場翻訳になる、という点です。海外顧客が実際のセグメントなら、回答を両言語で書き、それぞれ承認してください。

運用コストはどのくらいですか？

3 つの要素です。メッセージ量に比例する Tencent Cloud のモデル利用、サーバーのホスティング、そして連携を作り保守するエンジニアリング工数——最後が最も過小評価されがちです。今その質問群が消費しているスタッフの時間と、夜間に失っている売上と比べて価格を判断し、継続的な保守は一度きりのプロジェクト費用ではなく恒久的な費目として扱ってください。

顧客に誤った情報を与えてしまったらどうしますか？

起きる前提で設計します。すべての回答を取得データに接地させ、推測するくらいなら答えを拒むようモデルに指示し、人への引き継ぎをどの会話でも見えるようにし、苦情が実際の発言まで遡れるようログを残します。そのうえで毎週ログを読んでください。静かに誤っていた回答が見つかるのは最初の 1 か月で、それがパターンになる前に見つけられます。