WhatsApp Businessチャットから
住所と注文番号を抽出する

住所と注文番号が実際に存在する場所

WhatsApp Businessのチャットスレッドは、メッセージバブルの連なりです。顧客のメッセージは片側（Androidでは緑、iOSでは青）に表示され、ビジネス側の返信は反対側に表示されます。各バブルには、顧客が入力した内容（プレーンテキスト、絵文字、場合によっては商品の写真）がそのまま入っています。「住所フィールド」も「注文番号フィールド」も存在しません。あるのは、次のような文章だけです：

住所、商品、数量、注文番号はすべて同じバブルの中にあります。同じ会話内の複数のメッセージにまたがっていることもあります。住所の形式自体も、国や地域によってまったく異なります：

問題は、住所に専用フィールドがないことだけではありません。国ごとに住所の書き方がまったく異なるのに、WhatsAppはそれらすべてを同じように扱うことです。つまり、チャットバブルに入力された生のテキストとして扱うだけです。標準も、テンプレートも、画面上の予測可能な位置も存在しません。

従来のOCRがチャットデータを抽出できない理由

WhatsApp Businessのチャットのスクリーンショットを撮って、従来のOCRエンジンにかけてみましょう。出力されるのは、上から下へ、左から右へという読み順のテキストの塊です。画面の上部にあるタイムスタンプ、ビジネスのプロフィール名、顧客の電話番号、メッセージバブルの内容、あなたの返信、次のメッセージ。OCRは文字の位置を読み取るだけで、意味は理解しないため、すべてが混ざり合ってしまいます。

従来のOCRツールは、「Rua Augusta, 1500」が住所で「apto 42」が部屋番号であることを認識できません。「Order #4」が注文番号であることもわかりません。すべてをひとつの区別のない文字列として読み取り、自分で断片を拾い出す作業を残します。顧客が3つのメッセージを続けて送ってきた場合（最初に商品リスト、次に住所、最後に注文番号）、出力は連結された混乱した状態になり、手動で解析して解きほぐす必要があります。

これはOCRの解像度や精度の問題ではありません。OCRの仕組み（文字に見える形を見つけること）と、ユーザーが実際に必要としていること（どのテキストが何を意味するかを理解すること）の間の根本的なミスマッチです。チャットのスクリーンショットにはフォームフィールドやラベル、構造化されたレイアウトはありません。そこにあるのは会話であり、会話には理解が必要です。

セマンティック抽出 — チャットを意味で読む

ImageToTable.aiは異なるアプローチを採用しています。画像内のテキスト座標をスキャンする代わりに、人間と同じようにスクリーンショットを見ます。コンテンツを読み、各情報の意味を理解し、リクエストされたものを正確に抽出します。

出力列を定義します — 住所、注文番号。AIはスクリーンショットを読み取り、位置ではなく意味的役割によって各列に一致するテキストを見つけます。番地、市区町村、郵便番号、地域識別子など、テキストを配送先として機能させる要素を認識することで住所を特定します。これらの要素が商品名や数量と一緒に文章内に現れても対応できます。

これがカスタム列抽出パラダイムの仕組みです。必要なものを定義すれば、AIが意味によってそれを見つけます。上記のすべての住所形式のバリエーションに対応できるのは、「ブラジルの住所」がどのようなものかを事前に知る必要がないからです。住所の概念 — 番地、番号、市区町村、郵便番号 — を理解し、チャットテキスト内のどこに現れても識別します。

テンプレート不要。事前にアップロードするサンプル文書も不要。国別の住所形式トレーニングも不要。スクリーンショットをアップロードし、列名を入力するだけで、AIがチャットを読み取ります。

同じセマンティックアプローチは、注文がどのメッセージングアプリで届いても機能します。列定義は同じままで、チャットインターフェースだけが変わります。同じ抽出がiMessageスクリーンショットの注文住所、KakaoTalkスクリーンショットの韓国語住所、LINEスクリーンショットの日本語住所、WeChatチャットスクリーンショットの中国語配送先住所にも適用されます。各プラットフォームには独自の視覚レイアウトがありますが、バブル内のデータは同じように読み取れます。

出力結果 — 注文ごとに1行

WhatsApp Businessのチャットスクリーンショットをまとめてアップロードします — たとえば、1日に受け取った10件の注文など。各スクリーンショットは同じ列定義で同じ抽出処理を実行します。出力は1つのスプレッドシートで、各行が1件の注文を表します：

このテーブルは、住所形式がまったく異なるさまざまな国の注文を、1つの一貫した構造にまとめます。列を追加することもできます — 顧客名、電話番号、注文商品、数量 — 列リストに追加するだけです。AIが同じスクリーンショットを再度読み取り、今度はチャットのヘッダーやメッセージ内容から顧客名を見つけ、テキストから電話番号を抽出し、顧客がリクエストした商品をリストアップします。

1つのバッチに、インド、ブラジル、ナイジェリア、インドネシアの顧客からのスクリーンショットを含めることができます — まとめて処理され、まとめて抽出され、1つのスプレッドシートで納品されます。国ごとの設定も、形式別のテンプレートも不要です。

課題となる点 — 正直な境界線

チャットのスクリーンショットは、このツールが扱う中で最も構造化されていない入力です。意味抽出はうまく機能しますが、魔法ではありません。実際の制限は次のとおりです:

住所が複数のメッセージに分かれている場合。 顧客が1通目のメッセージで番地を、次のメッセージで市区町村を、3通目でPINコードを送信し、その間に取引先からの返信が挟まることもあります。1枚のスクリーンショットではすべてを捉えきれない可能性があります。解決策は、会話のスレッド全体をスクリーンショット（可能ならスクロールキャプチャ）にして、AIに完全なコンテキストを与えることです。

テキストではなく音声メッセージの場合。 顧客が住所を音声メモで送信した場合、スクリーンショットから抽出するテキストがありません。音声文字起こしはスクリーンショット抽出には含まれない別の機能です。顧客に住所を入力してもらうか、音声メモを別途文字起こしする必要があります。

曖昧な住所やランドマーク基準の住所。 「いつもの場所に送って」や「スルレアの大きなモスクの近く」には、抽出可能な住所の構成要素が含まれていません。AIはテキストに正式な住所が存在しないことを正しく認識し、捏造せずにその旨をフラグ付けします。こうした注文は、配達先の確認のためにフォローアップメッセージが必要です。

1枚のスクリーンショットに複数の住所がある場合。 顧客が同じ注文で2つの別々の場所への配達を依頼する場合 — 「半分はオフィスに、半分は自宅に送って」— 曖昧さが生じます。抽出では両方の住所が返されますが、それを注文構造にどうマッピングするかはあなたが決定する必要があります。配達ラベル列（「オフィス」/「自宅」）を追加すると、曖昧さを解消するのに役立ちます。

絵文字とステッカー。 AIは絵文字をコンテキストの手がかりとして読むことができますが（テキストの横にある📍ピンは「これは位置情報関連」を示します）、住所のテキストを覆うステッカー画像は盲点になります。ステッカーの後ろにあるテキストはスクリーンショットに表示されません。

これらはチャット抽出を避けるべき理由ではありません。チャットのスクリーンショットを扱うあらゆるツールが直面する現実的な境界線です。これらを知ることで、スクリーンショットのワークフローをその境界線に合わせて設計できます — 会話のスクロール全体をキャプチャし、重要な注文では顧客に住所を入力してもらい、曖昧な指示にはフォローアップで確認する、というように。

注文ワークフローへの影響

手動でのWhatsApp注文処理における本当のコストは、住所をスプレッドシートに打ち込む作業そのものではありません。それは積み重なりです。1日に10件の注文があり、それぞれから住所と注文番号を書き写す手間、月曜朝のバックログ、どのメッセージを処理したか分からなくなって同じ注文を二重に処理してしまうミス、お客様のメッセージにある似たような通り名を読み違えて誤った場所に配達してしまう事故——こうしたことの積み重ねが本当のコストなのです。

Redditである小さな飲食店の経営者は、こう簡潔に語っています。「WhatsAppの注文を手動でスプレッドシートにコピーするのに、あまりにも時間を費やしすぎていた」。別の水販売事業を営む方は、すべての顧客がWhatsAppで注文し、すべてを手動で処理している——顧客が増えるごとにボトルネックが大きくなると指摘しています。

手動のコピーペーストからスクリーンショットベースの抽出に移行すると、情報がシステムに入力される時点でワークフローが変わります。スクリーンショットはすでに記録です——お客様のメッセージを保存するために撮影します。そのスクリーンショットを読み取って詳細を打ち直す代わりに、直接アップロードします。住所と注文番号は、キーボードを経由せずにスプレッドシートに直接入力されます。以前は1件あたり1分かかっていた注文確認も、スクリーンショットを撮るのと同じタイミングで処理できるようになります。

スプレッドシートもより便利になります。住所が構造化された列に入力されれば、市区町村で並べ替えてルートごとに配達をグループ化したり、注文番号の範囲でフィルタリングしてバッチを確認したり、サブセットをエクスポートして配送チームに送信したりできます。チャットスレッドに散らばっていた注文番号が、数秒でスキャンできる1つのリストになります。

よくある質問

住所と注文番号はすでにスクリーンショットの中にあります——WhatsAppの注文会話をキャプチャするたびに。問題は、それらを再び手入力するか、AIに読ませるかです。一方の方法はコピー＆ペーストの繰り返しに留まります。もう一方は、スクリーンショット自体を注文ワークフローの入力に変えます。支払いスクリーンショットからのデータ抽出に適用されるのと同じ原則がここにも当てはまります：インターフェースがドキュメントでなくてもデータはそこにある——位置ではなく意味で読み取るツールが必要なだけです。