中国語 生成AIで精度が落ちる4層構造 タイ日系工場での実務対策

「中国語 生成AI」という言葉で検索される課題は、ほとんどの場合「モデルが中国語を知らない」という話ではありません。主要な生成AIは中国語の学習データを大量に持っています。それでも現場で精度が落ちるのは、中国語という言語が、日本語や英語とは違う場所で崩れるからです。簡体字と繁体字の使い分け、同じコードなのに形が違う漢字、空白がないために誰も語の境界を決めていないこと、そしてトークン化のときに存在しない語が勝手に作られること。これらはモデルを変えても消えません。

この記事は、タイの日系工場が中国製設備や中国語話者の取引先と付き合ううえで、中国語処理のどこが壊れているのかを層に分けて切り分け、どこを直せば効くのかを判断できるようにするためのものです。

「中国語だと生成AIの精度が落ちる」と言われるとき、実際に起きていること

現場で挙がる症状は、だいたい次のどれかに収まります。

• 中国製設備のマニュアルを翻訳させたら、同じ部品が段落ごとに違う日本語になった
• 台湾から届いた仕様書と大陸から届いた仕様書を同じフォルダに入れて検索したら、片方しか引っかからない
• 中国語の帳票をOCRにかけたら、数字は合っているのに品名が別の字に化けた
• サプライヤーへの返信を生成させたら、意味は通るのに相手の会社で使っていない用語が混ざった
• 長い技術仕様書を丸ごと読ませようとしたら、想定よりずっと早く上限に当たった

これらは全部「精度が悪い」の一言でまとめられがちですが、原因の層はばらばらです。1つ目と4つ目は語の切り方と用語の問題、2つ目と3つ目は文字の問題、5つ目はトークンの問題です。層を混ぜたまま「もっと良いモデルにすれば直る」と考えると、月額だけ上がって症状が残ります。

タイ語やベトナム語でも同じ構造の話をしています。言語ごとに壊れる場所は違いますが、切り分けの順序は共通です。あわせてタイ語 生成AIの4層モデルとベトナム語 生成AIの4層モデルも参照してください。

なお、この記事は「中国語という言語がなぜ生成AIで扱いにくいか」に絞ります。翻訳業務そのものの自動化の全体像は企業の翻訳自動化で扱っています。

なぜタイの日系工場が中国語 生成AIを気にする必要があるのか

「うちは中国に拠点がないから関係ない」という反応は、タイでは年々成り立たなくなっています。理由は3つあります。

供給網の側から中国語が入ってくる

タイ投資委員会（BOI）の発表によれば、タイのEV供給網には2026年時点で41億ドルを超える投資表明があり、BEV・ハイブリッド・電池・部品・充電インフラを合わせて198件のプロジェクトが動いています。このうちBEV生産そのものには、BYD、SAIC Motor、Aion、Changan Auto、Omoda and Jaecooといった中国メーカーを含む18件・11.8億ドルが投じられ、年産37万台を超える体制が計画されています。また、これに先立つ2025年3月には、中国のSunwoda Electronicによる電池セル製造への10億ドル超の投資が、タイ国家競争力強化委員会によって承認されています。

サプライヤー側の動きも同じ方向です。THAIBIZの分析では、中華系サプライヤーのタイ進出は2025年6月時点で183件に達し、うち加工系（製造業）が125件で最多を占めます。2023年から2025年6月までの2年半だけで90件の新規進出があり、タイのEV優遇政策（EV3.0／EV3.5）が加速の背景にあるとされています。

つまり、自社が中国語を使う意思決定をしなくても、二次・三次サプライヤーとして中国系企業が入ってくる確率が上がっています。図面のやり取り、変更通知、不具合報告の一次情報が中国語で来る場面が増えます。

中国製設備のマニュアルと仕様書

もう1つは設備側です。射出成形機、検査装置、搬送ライン、産業用ロボット、電源設備といった領域で中国製の装置を導入している工場は、タイでは珍しくありません。ここで問題になるのは、英語版マニュアルが存在しても中国語版と内容が一致しないことです。改訂が中国語版で先に入り、英語版が追いつかない。エラーコード表やパラメータ一覧は中国語のまま添付される。保守業者からのFAQ回答は中国語のチャットで来る。結果として、正確な情報は中国語側にしかない、という状態が生まれます。

中国語話者の従業員・委託先とのやり取り

3つ目は人です。タイ拠点に中国語話者の技術者が常駐する、あるいは中国系の委託先に工程の一部を出す、という形が増えています。日常のやり取りは英語やタイ語で回っても、技術的な詰めの場面では中国語のほうが速い。そうすると、議事メモ、作業指示、検査基準の細部が中国語で残ります。数年後にトレーサビリティを問われたとき、その中国語の記録を読める人が社内にいるかどうかが効いてきます。

この3つは、いずれも「中国語を業務言語として選んだ結果」ではなく「入ってきてしまった結果」です。だからこそ、専任の中国語人材を増やす方向ではなく、既存の担当者が中国語の一次情報を扱えるようにする方向で考える価値があります。

中国語の処理は4層に分かれる — 文字層・語層・トークン層・意味層

中国語のテキストがモデルに届くまでには、性質のまったく違う4つの層を通ります。層ごとに、壊れ方も直し方も違います。

重要なのは順序です。下の層が崩れていると、上の層でどれだけ良いモデルを選んでも直りません。逆に、文字層と語層は一度整えれば長く効き続けます。中国語の場合、日本語話者が想像するより文字層の比重が大きいのが特徴です。

第1層 文字層 — 簡体字 繁体字 AI処理で最初に壊れるのはここ

簡体字と繁体字は1対1で対応しない

「簡体字と繁体字は変換すれば済む」という前提は、実務では成り立ちません。簡体字への統合の過程で、複数の繁体字が1つの簡体字にまとめられた例が多数あるためです。

簡体字から繁体字へ戻すときは、どの繁体字を選ぶかを文脈で判断しなければなりません。ここを単純な文字置換で処理すると、「理发」が「理發」になるような誤りが出ます。正しくは「理髮」です。逆方向（繁体字から簡体字）は基本的に多対一の対応なので比較的安全ですが、それでも固有名詞や人名では例外が出ます。

つまり、社内文書の正本をどちらの字体にするかを決めておかないと、検索も集計も分岐します。

同じUnicodeコードでも字形が違う

もう1つ、日本語話者が見落としやすいのがUnicodeの統合漢字（CJK統合漢字）です。中国大陸・台湾・香港・日本・韓国で使われる漢字は、字形に差があっても原則として「同じ字」として1つのコードポイントに統合されています（ただし、元となる各国の文字集合で別々に符号化されていたものは統合されません）。実際にどの形で表示されるかは、フォントと言語タグで決まります。

たとえば「骨」「直」「次」「令」「者」などは、中国語フォントで表示したときと日本語フォントで表示したときで形が変わります。バイト列としては同一なので検索は当たりますが、印刷物やPDFの見た目は変わります。そしてOCRの側から見ると、これは深刻です。中国語フォントの字形で印刷された書類を、日本語圏の字形で学習したモデルに読ませると、認識率が落ちる方向に働きます。

さらに、異体字選択子（IVS）が付いた文字は、対応フォントがなければ表示上ほとんど区別がつかないのに、基底文字だけの場合とはバイト列が異なります。取引先から受け取ったExcelの品名列にIVS付きの文字が混じっていると、完全一致の突き合わせが静かに失敗します。

大陸・香港・台湾・シンガポールで用語が違う

字体だけでなく語彙も分岐します。製造業で頻出するものを挙げます。

シンガポールは字体としては簡体字を使いますが、語彙には独自のものがあります。香港は繁体字を使いつつ、語彙は大陸寄りの語が入ることがあります。

実務上の意味はこうです。「レーザ溶接」の仕様書を検索するとき、大陸系サプライヤーの文書は「激光焊接」、台湾系の文書は「雷射焊接」で書かれています。同義語辞書を持たないまま片方だけで検索すると、もう片方は永久に出てきません。これは第1層と第2層の境界にある問題で、モデルを変えても直りません。

句読点と記号

中国語は全角の句読点（，。；：）を使い、並列には頓号（、）を使います。ここに半角のカンマやピリオドが混ざると、分かち書きと文分割の両方が乱れます。中国語の書類をExcelやメールから取り込むと、半角記号が混ざるのは日常的に起きます。文字層の正規化には、この記号の統一も含めておく必要があります。

第2層 語層 — 空白がない言語で「どこで語を切るか」を誰も決めていない

中国語には英語のようなスペースによる語境界がありません。文字が連続して並ぶだけです。したがって、どこで語を切るかは処理系が決めます。そして、その決め方は本質的に曖昧さを含みます。

曖昧性は「たまたま」ではなく構造的なもの

よく引かれる例に「部分居民生活水平」があります。本来は「部分／居民／生活／水平」（一部の住民の生活水準）と切るべき文字列です。ところが、この中には「分居」（別居）や「民生」（国民生活）という、それ自体は正しい単語が同時に含まれています。つまり、辞書を引くだけでは複数の切り方が同時に成立してしまいます。

このタイプの曖昧性は中国語処理の研究で古くから知られており、切り方の候補が重なる交差型と、まとめても分けても意味が通る組み合わせ型に大別されます。後者の代表例が「才能」で、1語として読めば「才能」、2語に分ければ「才／能」（そうしてはじめて〜できる）になります。どちらが正しいかは前後の文脈でしか決まりません。

形態素解析ツールは何をしているか

jiebaのような中国語形態素解析ツールは、この曖昧性に対して辞書照合と統計モデルの組み合わせで答えを出します。おおまかには、まず接頭辞辞書（prefix dictionary）で文字列から取りうる語の候補をすべて拾って有向非巡回グラフ（DAG）を作り、動的計画法で最も確率の高い切り方の経路を選びます。辞書に載っていない語（未登録語）については、隠れマルコフモデル（HMM）とViterbiアルゴリズムで文字の位置ごとの役割を推定して語を切り出します。

ここが実務の勘所です。未登録語の扱いは統計任せになるということは、自社の型番、部品名、設備名、社内略語は、放っておけば高い確率で誤って分割されるということです。「MX-3200型伺服压机」のような文字列は、ユーザー辞書に入れなければ意味のある単位で残る保証がありません。

jiebaにはユーザー辞書を読み込む仕組みがあり、語と品詞と頻度を指定して登録できます。pkuseg、HanLP、LTPなど他のツールでも同様の仕組みがあります。やるべきことは単純で、自社で使う固有名詞のリストを作って登録する、これだけです。難しいのは技術ではなく、リストを誰が作って誰が更新し続けるかを決めることです。

語層が崩れると何が連鎖するか

語の切り方は、検索、チャンク分割、キーワード一致、分類、集計のすべての土台です。ここが崩れると、上に載るものが全部ずれます。RAGを組む場合はとくに影響が大きく、チャンクの境界が語の途中に入ると、その語は検索でもう拾えません。RAGの構築そのものについてはRAG構築の費用と進め方で扱っています。

第3層 トークン層 — 中国語のトークン化で何が起きるか

なぜ漢字1文字がトークン1個とは限らないか

現在の主要なLLMは、バイト単位のBPE（Byte Pair Encoding）系のトークナイザを使っています。BPEは、学習データの中で頻繁に隣り合うバイト列のペアを順番に結合していき、その結合ルールを固定します。

ここで中国語に固有の事情が効きます。UTF-8では、一般的な漢字1文字は3バイトを占めます。したがって、その漢字に対応する結合ルールが十分に学習されていなければ、漢字1文字が複数のトークンに分かれます。逆に、頻出する2文字語には結合ルールが存在し、2文字で1トークンになることもあります。つまり、同じ文字数の中国語文書でも、トークナイザによってトークン数は変わります。

cl100k_base以降の世代のトークナイザは、それ以前の世代に比べて中国語の語彙を多く含んでいるとされますが、英語ほどの効率ではありません。中国語対応を明示的に強化したモデルのトークナイザでは、中国語の語彙がさらに厚くなっている傾向があります。具体的な倍率は文書の分野や字体によって変わるため、自社の実文書で数えるのが唯一の確実な方法です。まずは代表的な社内文書を数本、候補モデルのトークナイザに通してトークン数を数える。これだけで、月額の見積もりと文脈長の設計の精度が大きく変わります。

誤った結合が起きる

もう1つ、中国語で報告されている現象があります。The Digital Orientalistの記事「To Merge or Not to Merge: The Pitfalls of Chinese Tokenization in General-Purpose LLMs」では、「他是学科技的，他不相信神秘和超自然的事物」という例文を複数のモデルのトークナイザにかけたところ、実際には語として存在しない語を1つのトークンに結合してしまう例（LLaMA系モデルで報告された「的事」の誤結合）や、文脈を無視した結合をする例（DeepSeekでの「他不」「的事物」の誤結合）が、複数のモデルで報告されています。

原因はBPEの仕組みそのものにあります。BPEは学習データでの出現頻度の順に結合ルールを固定するため、推論時には文脈を見ません。頻度が高いという理由だけで、文脈上は誤った結合を先に適用してしまいます。「的」は中国語で最も頻出する文字の1つなので、後ろの文字と結合したルールが上位に来やすい構造になっています。

実務的な含意は限定的ですが、無視もできません。トークン境界が語の意味的な境界とずれると、モデルが語を1つの意味単位として扱いにくくなります。とくに、短い断片を大量に処理する用途（品名の名寄せ、短文の分類、キーワード抽出）では、この影響が出やすくなります。この点だけを理由にモデルを決めるべきではありませんが、短文処理で不可解な誤りが続く場合の原因候補としては覚えておく価値があります。

第4層 意味層 — 中国語 LLMをここで初めて選ぶ

文字層と語層を整え、トークン層でコストと文脈長の見当をつけて、はじめてモデル選定の話になります。2026年時点で中国語を扱う際に名前が挙がる主要なモデルは次の通りです。ここでは定性的な傾向のみを書きます。公開されているベンチマークスコアは測定条件によって大きく変わるため、この記事では具体的な点数で優劣を断定しません。

加えて、欧米系のフロンティアモデルも中国語を高い水準で扱います。日本語と中国語を往復させる用途では、日本語側の品質も同時に問われるため、中国語専用のモデルが常に最適とは限りません。

選定で見るべきは、ベンチマークの総合点ではなく次の点です。

• 自社の文書で、簡体字と繁体字のどちらでも同じ品質が出るか
• 用語集を渡したときに、その用語を最後まで守るか（長い文書で途中から崩れないか）
• 指定した出力形式（表、JSON、決まった見出し構成）を守るか
• 中国語から日本語に訳したときに、日本語側が製造業の用語として自然か
• データをどこで処理するか（後述のPDPAの論点に直結します）

そして最も重要なのは、これらを判断するための評価セットを自社で持つことです。自社の実文書から30件から50件を選び、正解を人手で作る。これがないと、モデルを変えたときに良くなったのか悪くなったのかを誰も言えません。

用途別に見る — 翻訳・中国語 OCR・名寄せでどの層を直せば効くのか

層の話は抽象的になりがちなので、用途に落とします。

読み方は単純です。症状が起きている用途を見つけ、その行の「支配的な層」から手を付けます。右端の列は、よく試されるが効きにくい対策です。

社内からの中国語での問い合わせを受ける仕組みを作る場合は社内問い合わせ自動化、多言語のチャットボットとして外向きに出す場合はチャットボット導入の費用と進め方もあわせて参照してください。

独自試算 — 対応の型によってコストと効果はどう変わるか

ここからは架空の工場モデルに基づく試算です。前節までに引用したEV投資額やサプライヤー進出件数は実在の公表データですが、以下の数値はすべて説明のために設定したモデル値であり、実在の企業の実績ではありません。自社の数字に置き換えて検算できるよう、途中の計算をすべて書きます。

モデル工場の設定

中国語対応が必要な業務量と、現状（人手のみ）の所要時間は次の通りです。

現状の月間コストは 220時間 × 600 THB = 132,000 THB です。

3つの構成

構成A — 汎用生成AIをそのまま使う（層を直さない）

既存の汎用生成AIのライセンス（月3,000 THB）だけで運用し、用語集も正規化も入れません。要素数は1つです。

構成B — 文字層と語層を直す

構成Aに加えて、設備用語1,200語の簡繁・日本語対訳辞書と、簡繁の正規化ルールを実装します。要素数は3つ（汎用AI、対訳辞書、正規化ルール）です。

構成C — 4層すべてに手を入れる

構成Bに加えて、中国語帳票用のOCRテンプレートを整備し、候補モデルのトークン数を実測したうえで中国語対応LLMを選定します。要素数は5つ（正規化ルール、対訳辞書、帳票OCR、トークン設計、中国語対応LLMと評価セット）です。構成Cでは汎用AIのライセンス3,000 THBは中国語対応LLMの費用に置き換わるため、二重には計上していません。

所要時間の変化

帳票の読み取りが構成AとBで変わらないのは、この業務が第1層のOCR側の実装に依存しており、汎用AIの利用や用語辞書では短縮されないためです。逆に、構成Cで9分から3分に落ちるのは、OCRテンプレートと簡繁の後処理を入れて目視確認の範囲を絞れるからです。

費用と効果

初期費用の内訳を層に対応させます。どの費用がどれだけの時間短縮を生むのかを、分単位まで割り付けます。

構成Aの削減56時間は初期費用0の汎用AIライセンスだけで生じる分（翻訳25分→16分、メール12分→8分）です。上表の割り付けが前掲の削減時間と合うかを確認します。構成Bが構成Aに上乗せする分は 17 + 17 = 34時間で、90 − 56 = 34時間と一致します。構成Cが構成Bに上乗せする分は 40 + 8 + 9 = 57時間で、147 − 90 = 57時間と一致します。つまり、どの費用行を削っても、その行に書かれた時間短縮がそのまま消えます。

月次費用の内訳です。

削減時間を金額に直し、純便益を出します。

この表の読みどころは、12か月で見ると3構成の差が思ったより小さいことです（367,200／403,200／439,200 THB）。差が開くのは2年目からで、24か月では構成Cが構成Aの約1.7倍になります。初期費用を1年で回収する前提の稟議に構成Cを載せると、数字上は弱く見えます。評価期間の置き方で結論が変わる、という点を先に共有しておくほうが安全です。

感応度 — 削減時間が想定の7割にとどまった場合

削減時間の見積もりは前提の中で最も不確実な部分です。ここだけを7割に落とし、費用は据え置いて再計算します。単価600 THBと各費用は前提として変えません。

12か月時点の順位が入れ替わります。効果が想定の7割にとどまる場合、12か月では構成Aが最も有利で、構成Cが最下位です。24か月まで見て、ようやく構成Cが構成Bをわずかに上回ります（603,360 対 597,600 THB）。

この結果は「構成Cをやめるべき」という意味ではありません。削減時間が本当に出るかどうかを、投資を確定させる前に小さく検証すべきだという意味です。次に述べる90日の進め方は、この検証を先に置く順序になっています。

タイ・ASEAN拠点で追加になる論点

PDPAと越境データ移転

タイの個人情報保護法（PDPA）は、個人データを国外へ移転する際に条件を課します。中国語の帳票や取引先とのメールには、担当者名、連絡先、署名といった個人データが含まれることが普通です。これを海外のAPIに送る場合、どの国のどの事業者で処理されるのかを把握しておく必要があります。中国語対応で中国国内のサービスを選ぶ場合は、タイのPDPAに加えて中国側のデータ関連法規も関わるため、処理場所の選択は技術判断ではなく法務判断として扱ってください。

実務的な回避策としては、送信前に個人データを除去する（人名や連絡先を伏せ字に置き換える）前処理を入れる方法があります。技術的には難しくありませんが、除去すべき項目の定義を法務と合意しておくことが前提です。

契約書・仕様書の言語優先順位条項

中国系サプライヤーとの契約では、中国語版と英語版の両方が作られることがよくあります。ここで、どちらが優先するかを定める条項（言語優先順位条項）が入っているかを確認してください。入っていない場合、解釈が割れたときに拠り所がありません。

生成AIの文脈でこれが効いてくるのは、翻訳した文書を社内の正式な参照文書として扱うかどうかの線引きです。AIが訳した日本語版は、契約上は参考訳にすぎません。作業指示や検査基準として使うなら、誰が内容を確認して承認したかの記録を残す運用にしておく必要があります。

簡体字と繁体字のどちらを正本とするか

これは技術ではなく取り決めの問題ですが、影響は文字層の全体に及びます。大陸系サプライヤーが多ければ簡体字、台湾系が多ければ繁体字が自然ですが、重要なのはどちらかに決めることです。決めたうえで、取り込み時に正本の字体へ正規化し、原本は原本として別に保管する。この運用にしておくと、検索も集計も分岐しません。

決めずに両方が混在したまま数年運用すると、後から正規化するコストは文書量に比例して増えます。早いうちに決めるほど安く済む種類の意思決定です。

中国語文書の保管とトレーサビリティ

品質記録や検査成績書を中国語で受け取っている場合、監査の場面で「この記録の内容を誰が確認したか」を問われます。AIによる翻訳を経由しているなら、原本（中国語）と訳文の対応関係、訳文を確認した人、確認日を残す設計にしておいてください。翻訳の履歴を残さない運用は、後から作り直せません。

最初の90日で何をするか

第1〜30日 — 数えることに集中する

この期間は実装しません。現状を数えます。

• 中国語で入ってくる文書を種類別に集め、月間の件数とページ数を数える
• 送り元が大陸系か台湾系か香港系かを分類し、字体の混在状況を把握する
• 現状の処理にかかっている時間を、業務ごとに実測する（見積もりではなく実測）
• 頻出する用語を50語から100語ほど抜き出し、簡体字・繁体字・日本語の対応表の下書きを作る
• 代表的な文書3本から5本を候補モデルのトークナイザに通し、トークン数を数える

この30日の成果物は、前節の試算表の「月間の量」「1件あたり所要時間」を自社の数字で埋めたものです。ここが埋まらないまま次に進むと、投資判断の根拠がありません。

第31〜60日 — 小さく検証する

削減時間が本当に出るかを、最小の投資で確かめます。

• 用語50語程度の暫定辞書を作り、翻訳の下訳に適用して所要時間を測り直す
• 簡繁の正規化を1つの文書種類にだけ適用し、検索の当たり方が変わるかを見る
• OCRについては、帳票1種類・20枚程度でテンプレートを試作し、目視確認にかかる時間を測る
• 評価セットの原型として、実文書から30件を選んで正解を人手で作る

この60日目の時点で、感応度分析の「7割」が現実的な数字なのか、もっと出るのか出ないのかが分かります。ここで数字が出なければ、範囲を狭めるか、対象業務を絞る判断ができます。

第61〜90日 — 範囲を決めて固定する

• 正本とする字体を決め、文書管理の規程に書く
• 用語辞書の更新責任者と更新頻度を決める
• 個人データの前処理範囲を法務と合意する
• 検証結果に基づいて、構成A・B・Cのどれで進めるかを決める
• 評価セットの版を切り、以後のモデル変更はこの版で比較すると決める

90日目の成果物は、動くシステムではなく「決まった前提」です。中国語対応は、決めていないことが多いほど後で高くつきます。

よくある失敗とその回避策

モデル選定から始めてしまう

最も多い失敗です。「どのLLMが中国語に強いか」を調べるところから始めると、文字層と語層が崩れたまま第4層だけを取り替えることになります。用語がぶれる、検索が当たらないといった症状はモデルを替えても残るため、何度も乗り換えて時間を失います。回避策は、症状を前掲の用途別表に当てて支配的な層を先に特定することです。

簡繁変換を単純な文字置換で実装する

簡体字から繁体字への変換を1対1の置換表で書くと、「发」を「發」に固定してしまい、髪に関する語がすべて壊れます。回避策は、変換方向を簡体字側へ一方向に統一するか、文脈を見る変換ライブラリを使い、固有名詞は変換対象から除外することです。

用語辞書を作って更新をやめる

初期に1,200語の辞書を作っても、新しい設備が入り、新しいサプライヤーが増えれば、辞書は陳腐化します。辞書は訳語を強制する仕組みなので、更新されない辞書は古い訳語をそのまま強制し続けます。回避策は、更新の担当と頻度を90日目の時点で決めておくことです。試算では月4〜6時間の保守工数を見込んでいますが、これは削れる費用ではありません。

評価セットを作らずに「精度が上がった気がする」で進める

評価セットがないと、モデルを替えたときの良し悪しを議論できません。担当者の印象が根拠になり、次の担当者に引き継げません。回避策は、実文書30件程度で構いませんので正解を作り、版を固定することです。30件でも、ないのとは決定的に違います。

台湾・香港からの文書を大陸の設定のまま処理する

字体だけでなく語彙が違うため、大陸向けに作った同義語辞書では台湾文書の検索が当たりません。回避策は、辞書に大陸語彙と台湾語彙の対応列を持たせることです。前掲の用語対応表がその最小形です。

個人データの扱いを決めずにAPIへ送り始める

PoCだからという理由で、実際の取引先メールをそのまま外部APIに投げる運用が始まってしまうことがあります。回避策は、検証段階から個人データの前処理を入れるか、検証には個人データを含まない文書だけを使うことです。

よくある質問

中国語 生成AIとは何を指しますか

中国語のテキストを入力または出力に含む生成AIの利用全般を指します。中国製のモデルを使うことと同義ではありません。欧米系のフロンティアモデルで中国語を扱う場合も含まれます。この記事では、モデルの出自ではなく、中国語という言語が処理のどの層で崩れるかという観点で整理しています。

中国語のOCR精度はどのくらい出ますか

中国語OCRは簡体字・繁体字とも高精度化が進んでおり、複数の技術解説では95%を超える認識率を達成するシステムも登場していると報告されています。ただし、繁体字は簡体字より字形が複雑なため、誤認識のリスクは相対的に高いとされます。また、この種の数値は印刷品質、フォント、レイアウト、スキャン解像度に大きく左右されるため、自社の帳票で実測することを勧めます。実務では、認識率そのものより、誤りが起きたときにどこで検知できるかの設計のほうが効きます。

簡体字と繁体字はAIで変換すれば済みますか

済みません。簡体字1文字が複数の繁体字に対応する場合があり、どれを選ぶかは文脈で決まるためです。簡体字から繁体字への変換は誤りが出やすく、逆方向のほうが安全です。実務では、正本とする字体を1つ決め、取り込み時にそちらへ正規化する運用が最も安定します。

中国語 LLMは中国製のモデルを選ぶべきですか

用途とデータの扱いによります。中国語だけを扱い、中国語の細部の自然さが重要なら中国製モデルが有利な場面があります。一方、日本語と中国語を往復させる用途では日本語側の品質も同時に問われますし、タイ拠点で個人データを扱うならPDPAと処理場所の論点が先に来ます。ベンチマークの総合点だけで決めず、自社の評価セットで比較してください。

中国語の帳票が簡体字と繁体字で混在しています。何から手を付けるべきですか

まず、どちらを正本にするかを決めてください。そのうえで、取り込み時に正本の字体へ正規化する処理を入れます。この2つだけで、検索の取りこぼしと集計の二重計上はかなり減ります。OCRのテンプレート整備はその次で構いません。

まとめ

中国語で生成AIの精度が出ないという相談は、多くの場合モデルの問題ではありません。簡体字と繁体字が1対1で対応しないこと、同じUnicodeコードでも地域によって字形が違うこと、空白がないために語の切り方が構造的に曖昧であること、そしてBPEが文脈を見ずに結合ルールを固定していること。これらは文字層・語層・トークン層で起きており、第4層でモデルを替えても消えません。

タイの日系工場にとって、中国語は選んで導入する言語ではなく、EV供給網と中国製設備を通じて入ってくる言語です。だからこそ、専任人材を増やす方向ではなく、既存の担当者が中国語の一次情報を扱えるようにする方向で設計する価値があります。

試算で見た通り、4層すべてに手を入れる構成が最も大きな効果を生みますが、1年目の差は小さく、効果が想定を下回ると順位が逆転します。だから最初の90日は実装ではなく、数えることと小さく検証することに使ってください。決めるべきことは、正本の字体、辞書の更新責任者、個人データの前処理範囲、そして評価セットの版です。この4つが決まっていれば、あとはどの構成で進めても大きくは外しません。

検討段階でのご相談について

中国語で精度が出ないという課題は、どの層で起きているかを切り分けるところから始められます。自社の中国製設備マニュアルや中国語帳票がどの層で崩れているかを一度見てみたい、簡繁の正規化をどこまでやるべきか整理したい、評価セットの作り方だけ相談したい、といった検討段階でも構いません。お問い合わせはこちらからご連絡ください。

参考情報

• Thailand Secures $4.1 Billion in EV Chain Investments as Southeast Asia Auto Hub Pivots to Next-Gen Tech – Thailand Board of Investment — タイのEV供給網への投資表明額41億ドル、198件のプロジェクト、BEV生産18件・11.8億ドル・年産37万台超に関する公式発表（2026年7月3日）
• Thailand approves Sunwoda to invest $1B in EV battery cell plants – TechNode Global — Sunwoda Electronicによる電池セル製造投資の承認に関する報道（2025年3月17日）
• 中華系サプライヤーのタイ・ASEAN進出シナリオ – THAIBIZ — 中華系サプライヤーのタイ進出183件、加工系125件、2023年〜2025年6月の新規90件という内訳の分析（野村総合研究所系、2026年2月）
• To Merge or Not to Merge – The Pitfalls of Chinese Tokenization in General-Purpose LLMs – The Digital Orientalist — 汎用LLMのトークナイザにおける中国語の誤結合の実例と、BPEに起因する原因の解説（2025年2月4日）
• jieba – Chinese text segmentation — 接頭辞辞書、有向非巡回グラフ（DAG）、動的計画法、HMMとViterbiによる未登録語処理の実装と、ユーザー辞書の登録方法
• China LLM Guide 2026 – Top Chinese LLMs Compared – Swift Horse AI — DeepSeek、Qwen、Kimi、GLMを中心とした中国製LLMの用途別の傾向に関する比較（2026年6月）
• Parsing Through Boundaries in Chinese Word Segmentation – arXiv — 中国語の分かち書きの境界の取り方が下流の解析に与える影響に関する研究（2025年3月）
• Maximum Overlapping Ambiguous String データセット – 清華大学自然語言処理組 — 交差型の曖昧性を集めた中国語分かち書きの評価データセット
• Personal Data Protection Act B.E. 2562 – Office of the Personal Data Protection Committee Thailand — タイの個人情報保護法の条文
• Cross-border personal data transfer under Section 29 – Office of the Personal Data Protection Committee Thailand — 適切な保護措置による越境データ移転の要件