DeepSeekとAlibaba Cloudで中国の規制に適合したカスタマーサポートボットを構築する方法

要点： DeepSeekを中国本土のAlibaba Cloudリージョン内で動かし、顧客との会話が国境を越えないようにする。その背後に人間へのエスカレーション経路を用意する。そしてICP備案、等級保護（MLPS）の等級付け、PIPL、生成AIサービスの届出を、後から片づける事務ではなく設計の入力として扱う。モデル選定は、この中で最も簡単な部分です。

中国本土の顧客に対応している企業にとって、カスタマーサポート用チャットボットの検討には、多くのAI導入ガイドが完全に無視している制約が付いてきます——その会話が物理的にどこで起きるか、です。サポートチャットには氏名、注文番号、電話番号、住所、苦情が含まれます。PIPL上の個人情報です。それを中国国外にホストされたモデルへ流せば、ごく普通の製品判断が越境データ移転に変わります。DeepSeekのオープンウェイトモデルを中国国内のAlibaba Cloudインフラで動かす構成は、その問題を設計段階で回避する組み合わせです。本記事では、アーキテクチャ、それを形づくるコンプライアンス層、そして最初の一年を生き延びられるかを決める運用作業を扱います。

なぜDeepSeekとAlibaba Cloudなのか

現実的な理由が三つあります。いずれもベンチマークの点数の話ではありません。

中国語に強く、自前でホストできる。 DeepSeekはオープンウェイトのモデルを公開しており、他社のエンドポイントを呼ぶのではなく、自分が管理するインフラ上に配置できます。規制対象のデータフローにおいて、この違いが決定的です。自前ホスティングは「どのベンダーが顧客データを見るか」という問いを「自社環境の外の誰も見ない」に変えます。

Alibaba Cloudは既定の適法な着地点。 中国本土リージョンを運営し、国内で一般公開されるサービスに必須のICP備案の手続きに対応し、モデル配置のためのGPUコンピュートとマネージドAIプラットフォームを提供しています。Alibaba CloudはプラットフォームサービスでDeepSeekの配置を提供してきましたが、対応するモデルの種類やサイズのラインナップは変わります。ブログ記事（本記事を含む）ではなく、現在のコンソールで確認してください。

レイテンシと到達性は現実の問題。 中国本土の外のサーバーから応答するチャットボットは、国内の利用者にとって遅く不安定です。これはモデルの良し悪しとは無関係です。域内ホスティングは、体験の問題とコンプライアンスの問題を一つの判断で同時に解きます。そうした機会は多くないので、活かす価値があります。

率直な反対側の事実として、これはSaaSチャットボットに申し込むより重い取り組みです。インフラを運用することになり、インフラには所有者が必要です。そのコストは実在し、本記事の最後の節が存在する理由でもあります。

アーキテクチャ：Alibaba Cloud上のDeepSeekでサポートボットを構成する

チャットボット自体はシステムのごく一部です。重要なのは境界と知識です。

機能する構成はこうです。顧客との接点（自社サイト、WeChatアカウント、アプリ内チャット）が、本土リージョン内のAlibaba Cloud ECSまたはコンテナサービス上で動くアプリケーション層へメッセージを渡します。その層は自社のナレッジベース——製品ドキュメント、ポリシー、配送ルール——から関連内容を検索し、DeepSeekモデルを呼びます。モデルはGPUインスタンス上での自前ホスティングでも、同一リージョン内のマネージドモデルサービス経由でも構いません。回答が顧客へ返り、やり取り全体がログに残り、常に見える位置にワンタップで人間へつながるエスカレーション経路があります。

この設計を「動く」から「成立する」に変える性質が二つあります。記憶ではなく検索から答えること——モデルは学習時に吸収した内容ではなく、自社の文書に基づいて答えるべきです。返金ポリシーについての自信満々の誤答は、まさに学習済み知識から生まれます。目に見える人間への出口——すべての会話は人にたどり着けなければならず、苦情、返金、そしてモデル自身が不確かと判断したものについては、顧客に要求される前にボットの側から引き渡すべきです。

データ所在地とICP備案

混同されがちな二つの別々の要件です。ICP備案は、一般公開されるサイトやサービスを中国本土のインフラでホストするための前提条件です。ドメインとホスティング事業者に紐づき、所要期間は日ではなく週単位で、中国に登記された法人が必要です。ボットのドメインが国内から配信されるなら、これはクリティカルパス上にあり、技術作業の後ではなく前に着手すべきものです。

データ所在地は別の問いで、顧客データが最終的にどこに留まるかです。モデル、アプリケーション層、ナレッジベース、会話ログをすべて同一の本土リージョン内に置けば、通常運用で越境移転は発生しません。それが狙いです。避けるべき失敗は「部分的な域内化」です——モデルは国内にあるのに、ログ、分析、エスカレーションのキューが会話記録を海外本社のシステムへ送っている状態。それは越境移転であり、設計時ではなく監査時に発覚しがちなものです。構築前に、会話が書き留められる場所をすべて洗い出してください。

既存のチケットシステム・CRMとの接続

引き継ぎで文脈が失われるなら、このボットの価値はほとんどありません。重要な統合点は二つ。エスカレーション（ボットが完全な会話記録と、自分が解決済みの内容を添えてチケットを作成し、人間が会話をやり直さずに済むようにする）と、参照（注文状況、アカウント状態——読み取り専用、範囲を限定し、巧妙に言い換えた質問で他の顧客のレコードを露出させないこと）。

CRMやヘルプデスクが中国国外にある場合、その統合自体が越境データフローであり、モデル選定と同じ厳しさで検討する必要があります。現実的な緩和策は、中国側の会話ストアを域内に保持し、同期するのは最小限——チケット番号、ステータス、カテゴリ——にとどめて会話記録そのものは送らないか、支援システムの域内インスタンスを別途動かすことです。たいていはプロジェクト全体で最も厳しい制約であり、誰かがコードを書き始める前にホワイトボードで解決しておく価値があります。

現実的な導入の進め方

個々の手順より順序が重要です。第一に、法人、ドメイン、ICP備案の経路を確定します。他のすべてがここに依存します。第二に、環境を立ち上げます。本土リージョンのVPC、アプリケーション層のコンピュート、DeepSeek用のGPUインスタンスまたはマネージドエンドポイント、ナレッジベースと会話ログのデータストア。セキュリティグループとアクセス設計は既定のままにせず、意識的に決めてください。

第三に、モデルを調整する前に検索層を作ります。実際のサポート素材——FAQ、ポリシー、配送マトリクス——をシステムが検索できる形に変換し、そこを正しくすること。回答品質は、モデルのサイズよりも検索品質にはるかに強く左右されます。第四に、実際の過去会話に対して社内で動かし、自社のサポートチームに採点してもらいます。「もっともらしいが誤り」を見抜けるのは彼らだけです。第五に、狭く低リスクな範囲で試験運用します。注文状況とFAQのみ、返金なし、苦情対応なし、人間への引き渡しは常時表示。その後、試験運用の成功率ではなく、会話記録が示す事実に基づいて範囲を広げます。

DeepSeek＋Alibaba Cloud vs 海外ホスト型LLMチャットボット

• データの流れ——域内配置なら顧客の会話は中国本土に留まり、評価・記録すべき移転が発生しません。海外ホスト型はメッセージごとに個人情報が越境し、PIPLの越境移転メカニズムが適用対象になります。チェックボックスではなく実際の法務ワークストリームです。
• 中国国内利用者の体験——域内配信は一貫して高速です。海外エンドポイントはモデルの優劣に関係なく本土の利用者にとって遅く不安定で、回答の途中で止まるサポートボットはボットがないより悪いものです。
• 導入の手間——海外SaaSのチャットボットなら午後のうちに動きます。域内構築には法人、ICP備案、クラウド基盤、そして運用する人が必要です。時間単位ではなく週単位——それが率直なトレードオフです。
• 中国語の品質——どちらの方式でも良質な中国語は出せますし、主要モデルはこの点で強力です。専門的な正確さを決めるのは検索層と自社の文書であって、モデルの「国籍」ではありません。ここを決定要因にしないでください。
• 継続コストの形——自前のGPU容量は固定の月次コミットで、大量なら割安、少量なら無駄になります。マネージドエンドポイントや海外SaaSは従量課金で初期は安価です。実際の会話量を見積もってから選んでください。損益分岐は具体的な数字であり、想定より低いことがよくあります。

コンプライアンスの層

この案件に関わる規制は四つあり、それぞれ独立しています。

PIPL（個人情報保護法） は会話に含まれる個人情報を規律します。適法な根拠、AI処理を明示したプライバシー通知、データ最小化、保存期間の設定が必要です。越境移転には、量と機微性に応じて安全評価・標準契約条項・認証のいずれかの仕組みが要求されます。域内配置は、それを不要にするための設計です。

等級保護（MLPS／等保2.0） は情報システムを等級付けし、等級に応じたセキュリティ要件を課します。個人情報を保持する顧客向けシステムは通常その範囲に入ります。等級付けと必要な評価にはリードタイムがあるため、レビューで発覚する前に自社の位置づけを早めに確認してください。

生成AIサービスに関する規則。 中国の生成AIサービス暫定管理弁法は、公衆に向けて生成AIサービスを提供する事業者に、届出を含む義務を課しています。自社サイト上のカスタマーサービスボットがこれに該当するかは、提供の形態と対象によって変わる、実際の法的論点です。中国の資格を持つ弁護士の見解を早期に得てください。ローンチ日が変わり得ます。

ICP備案は前述のとおりホスティングの前提条件です。すでに中国で事業を営む企業にとって、どれも特別なものではありません。ただしすべてにリードタイムがあり、いずれも後から手当てするより設計時に織り込むほうが安く済みます。

これを正しくやるために：データ所在地、APIキー、そしてITを巻き込むべき時

境界を描き、そのうえで検証する。 コンプライアンスの説明は、最も検討されていない構成要素の水準までしか強くなりません。ログ転送、エラー監視、分析SDK、バックアップ先、サードパーティのチャットウィジェット——どれもが会話データを静かにリージョン外へ運び得ます。すべての送信先を図に描き、稼働中のシステムをその図と突き合わせてください。実装は設計から必ずずれていきます。

認証情報とアクセス権。 クラウドアカウント、モデルエンドポイントのキー、データベース認証情報は、ここでは同じ影響範囲に入ります。共有のroot的アカウントではなく最小権限のロールを使い、シークレットはマネージドの保管庫へ置き、計画的にローテーションし、セキュリティグループは必要なトラフィックだけに絞ること。試験運用中に広く開けたまま二度と見直されない——これは中国クラウドのレビューで最も多い指摘です。

運用する人が必要です。 自前推論はインフラです。パッチ適用、容量、モデルバージョンの更新、監視、そしてセール中の月曜午前九時にエンドポイントが落ちたとき起きている誰か。AIプロジェクトが「モデル選定」として立ち上げられたとき、過小評価されるのはたいていこの部分です。

Brocent（博迅）のマネージドITクラウドサービスは、まさにこの領域——中国本土でのICP適合ホスティングとAlicloud ECSの運用、そして多くの社内チームが人員を割けていない継続的な管理——をカバーします。AI+サポートサービスがユースケースの整理と統合実装を担い、マネージドITサポートが認証情報の衛生管理・監視・変更管理で、適法な状態を適法なまま保ちます。最初の一歩が顧客向けではなく社内向けのシステムであれば、DeepSeekで中国の規制に適合した社内ナレッジアシスタントを構築する方法が、よりリスクの低い出発点を扱っています。当社は2007年の北京での創業以来アジア全域でマネージドITとセキュリティの案件を手がけており、本社はシンガポール、香港オフィスは2016年から稼働しています。

よくある質問

既存の海外ホスト型チャットボットを中国市場にそのまま使えますか？

技術的には動きます。メッセージはたいてい通ります。しかし法的には、会話のたびに個人情報が越境することを意味し、PIPLの越境移転メカニズムが適用対象となり、記録の残るコンプライアンス作業が必要になります。実務上も、中国本土の利用者にとって遅く不安定です。少量なら受け入れる企業もありますが、既定でそうなるのではなく、助言を得たうえで意識的に決めるべき判断です。

ICP備案には実際に何が必要ですか？

中国に登記された法人、ドメイン、備案を提出する中国本土のホスティング事業者、そして法人とサイト内容に関する提出書類です。数週間かかり、中国国内から公開配信されるものはこれが通るまで公開できません。設計の後ではなく、設計と並行して着手してください。

PIPLや等級保護（等保）との関係は？

PIPLは会話に含まれる個人情報——適法な根拠、通知、最小化、保存、越境ルール——を規律します。等保はシステム自体を等級付けし、その等級に応じたセキュリティ要件を課します。両者は独立しており、片方を満たしても他方は満たされません。どちらにもリードタイムがあります。域内配置はPIPLの越境の論点を簡単にしますが、残りを免除するものではありません。

既存のCRMやヘルプデスクと併用できますか？

できますし、そうすべきです。文脈を失う引き継ぎはボットがないより悪いからです。複雑なのは、CRMが中国国外にある場合、その統合自体が越境フローになる点です。通常の答えは、会話記録は域内に保持し、最小限のメタデータだけを同期するか、支援システムの域内インスタンスを別に用意することです。

モデルは自前でホストすべきですか、マネージドエンドポイントで十分ですか？

本土リージョン内のマネージドモデルサービスでもデータは域内に留まり、運用負荷をはるかに抑えて主要な所在地の懸念に対処できます。自前ホスティングはモデルバージョンの管理と分離を強化し、大量なら安くなり得ます。特別な理由がなければマネージドから始めてください。自前で推論を運用する負担は、日常的に過小評価されています。

ボットが間違えたらどうなりますか？

必ず間違えると想定して設計してください。すべての会話に見える形の人間へのエスカレーション経路、返金や約束についての自律的な権限を与えないこと、苦情を調査できる期間の会話記録の保持、そしてエスカレーションと低確信度の回答の週次レビュー。人間へと丁寧に引き継げるボットは良い製品であり、顧客と自信たっぷりに議論するボットは負債です。

どこから始めるか

技術を選ぶ前に、法務の下ごしらえと件数見積もりを済ませてください——法人、ICPの経路、そして「これは月に何件の会話を実際に処理するのか」という率直な問い。次に、実際のサポート素材の上に検索層を作り、顧客が一人も触れる前に過去のチケットで検証します。ローンチは狭く。FAQと注文状況、人間への引き渡しは常にワンタップ、最初の四半期は週次で会話記録をレビューする。そして、インフラとコンプライアンスの側が自社チームの手薄な部分であれば、そこがパートナーを入れる通常のタイミングです——中国本土でこれをきちんと運用するとどうなるか、お問い合わせからご相談ください。