WeChatチャットのスクリーンショットから
中国の配送先住所と電話番号を読み取る

WeChatの住所メッセージの実際の見え方

WeChatのチャットで送られる典型的な中国の配送先住所は、ビッグエンディアン方式の階層構造になっています。最も大きな地理単位が最初に、最も小さな単位が最後に来て、その後に受取人の名前と電話番号が続きます。完全なメッセージは次のようになります。

この1つの文字列から、人間の読者は瞬時に6つの異なるデータポイントを識別します。省、市、区、番地と建物（路/号/楼/室）、受取人、携帯電話番号です。住所には構造があります。中国の住所形式は世界で最も一貫した階層型郵便システムの一つですが、その構造は完全に単語の意味の中に存在しており、視覚的な区切りは一切ありません。改行も、列の区切りも、フォームフィールドもありません。漢字と数字が連続した1つのブロックがあるだけです。

住所は完璧に構造化されています。ただ、構造化されて見えないだけです。そして、まさにそれが従来のOCRが最も苦手とする入力なのです。

同じ形式は、あらゆるWeChat注文シナリオで繰り返し現れます。WeChat販売者（微商（ウェイシャン））から服を購入する顧客は、住所を1つのメッセージで送ります。代購（ダイゴウ）の購入者は同じ方法で配送情報を確認します。WeChat経由で配送指示を受け取るレストランの仕入先も、同じ種類のテキスト（省から電話番号まで、すべて1つのブロック）を受け取ります。誰が送ったかに関わらず、内容は同じです。地理的階層＋名前＋電話番号、すべてが1つの文字列に連結されており、人間は0.5秒で解析できる一方、機械はそれを1つの未分化なテキストの塊として誤読します。

階層構造の問題 — フラットな文字列は住所ではない

難しいのは、中国語の文字を認識することではありません。最新のOCRは印刷された中国語を高い精度で読み取ります。文字認識の技術は何年も前から信頼できるものです。難しいのは、中国の住所が文字の羅列ではなく、文字列として表現された階層構造であることです。従来のOCRは、文字列全体を1行のテキストとして扱います。「浙江省杭州市西湖区文三路478号华星科技大厦12楼1208室 王芳 13812345678」を1つのフィールド、つまり意味的な区切りのない連続した文字列として出力します。

住所が完全な形で書かれていない場合、問題はさらに複雑になります。同じ省内の販売元から注文する場合、顧客が省を省略することがあります。「浙江省」がなく「杭州市西湖区文三路478号」となるケースです。市と区だけを書く場合もあります。「深圳南山科技南路18号」— 省を省き、区にはよく知られた略称を使います。建物名を省略し、番地と近くのランドマークだけを記載する住所もあります。従来のOCRは、それが住所であること自体を認識できないため、これらのバリエーションを正規化する方法がありません。

最も簡単に分離できそうに見える電話番号にも、住所ブロック内に落とし穴があります。中国の携帯電話番号は「1」で始まる11桁です。単独であれば明確なパターンです。しかし、「12楼」や「1208室」のような建物番号も含む住所文字列の末尾にある場合、単純にすべての数字の並びを抽出するツールは、「478」（建物番号）、「12」（階数）、「1208」（部屋番号）、「13812345678」（実際の電話番号）をすべて拾ってしまう可能性があります。どの数字グループが電話番号で、どれが住所の構成要素なのかを区別する方法がないのです。

電話番号のパターン（11桁、1で始まる）は人間が見つけるのは簡単です。しかし、それが住所を見ていることを理解しないツールは、ページ上のすべての数字を拾い上げ、すべてを「データ」と呼んでしまいます。

ビジュアルAIが同じスクリーンショットを異なる方法で読み取る仕組み

ここで抽出アプローチは、文字認識から意味理解へと変わります。スクリーンショット内のすべてのテキストをスキャンしてフラットなブロックとして出力する代わりに、ビジュアルAIツールは「これはどのような情報で、各情報はどこに属するのか？」と問いかけながら画像を読み取ります。

カスタム列抽出を使用すると、「配送先住所 (收货地址)」、「受取人名 (收件人)」、「電話番号 (联系电话)」など、抽出したい列を定義します。AIは、中国語の住所形式の文脈の中で各情報が何を意味するかを理解することで、一致する値を特定します。省が省を示すことや、路が道路名を示すことを教える必要はありません。中国語住所の構造的文法を理解しているため、これらのマーカーを識別します。これは、中国地理を学んだことがなくても、「浙江省」が省であることを本能的に理解するのと同じです。

意味論的アプローチが住所ブロックの各構成要素をどのように処理するかを以下に示します。

この方法が機能するのは、AIがスクリーンショットに表示されている都市名や通り名を正確に知る必要がないからです。AIが知るべきなのは、その位置にある何かが都市として機能し、何かが通りとして機能し、何かが電話番号として機能する、ということです。抽出は、中国の住所形式における各セグメントの構造的な役割によって行われます。この形式は、地域による違いはあるものの、世界で最も一貫性のある郵便階層の一つです。

正式な領収書ではない支払いスクリーンショットからデータを抽出する場合と同じ原理がここでも適用されます。つまり、出力する列を定義し、AIはテンプレートに一致させるのではなく、値の意味を理解することでスクリーンショット上の該当する値を見つけ出します。入力がWeChat Payの確認画面であれ、配送先住所が書かれたチャットメッセージであれ、方法は同じです。意味に基づく抽出は、位置ではなく意味によって読み取ります。

複数のWeChat注文をバッチ処理する

WeChat販売者は、注文を一度に一つだけ受け取るわけではありません。忙しい日には、チャットログは複数の顧客からの住所メッセージで溢れかえります。それぞれ名前も都市も配送指示も異なります。10件の住所を手動で書き写すということは、10件のメッセージを読み、10個の電話番号をコピーし、10個の名前を注文シートや配送ラベルに入力することを意味します。この作業は毎回同じで、エラーのパターンも毎回同じです。電話番号の数字の入れ替え、番地の読み間違い、地区の誤認などです。

バッチ処理は、このワークフローを変えます。各顧客の住所メッセージが表示されたスクリーンショットをすべてまとめてアップロードします。列定義（「配送先住所」「受取人」「電話番号」）を一度設定するだけで、AIがバッチ内のすべてのスクリーンショットを読み取り、統合されたテーブルを出力します。顧客ごとに1行で、住所、名前、電話番号が3つのきれいな列に整理されます。

出力されたテーブルは、Excelに直接エクスポートするか、ImageToTable.aiのGoogleスプレッドシートアドオンを使ってスプレッドシートから離れることなく直接書き込むことができます。各行が1つの注文となり、配送ラベルとして印刷したり、注文管理システムにインポートしたり、フルフィルメントチームと共有したりする準備が整います。1件あたりの作業時間は、読んで入力するのに約1分かかっていたものが、確認のための数秒に短縮されます。

抽出の価値は、1つの住所で数秒を節約することではありません。手作業を増やさずに、1日10件の注文を30件に拡大できることにあります。なぜなら、ボトルネックは住所を読むことではなく、毎回それを打ち直すことだからです。

同じバッチワークフローは、前述した住所形式のバリエーションにも適用できます。バッチには、完全に構造化された住所（省→市→区→路→名前→電話番号）のメッセージが10件、省が省略されたものが2件、顧客が通り名の代わりにランドマークを含めたものが1件、省レベルが存在しない直轄市（北京や上海）のものが1件含まれているかもしれません。AIはこれらすべてを同じパスで処理します。なぜなら、すべての住所がまったく同じテンプレートに従っていると仮定するのではなく、構造的な構成要素によって各住所を読み取るからです。

異なる市場の顧客に対応するなど、WhatsAppでも注文を処理している販売者の場合、同じアプローチはWhatsApp Business経由で送信された住所メッセージにも拡張できます。抽出する列は同じままで、チャットインターフェースが変わるだけです。

よくある質問