LINEのチャットスクリーンショットから
日本の住所と注文詳細を抽出する

なぜLINEのチャットが日本の注文書になるのか

LINEは日本で最も広く使われているメッセージングプラットフォームで、人口1億2500万人のうち、月間アクティブユーザーは約9600万人です。小規模小売店、一人親方のフリーランス職人、地域のパン屋、ハンドメイド作家にとって、LINEは単なる顧客との会話ツールではなく、注文を受ける手段です。顧客が「Aを3つ、Bを2つください。住所はこれです」とメッセージを送り、メモを添付するか詳細を入力するだけで注文が成立します。ウェブサイトも、注文フォームも、ショッピングカートも必要ありません。

事業主はチャットのスクリーンショットから住所を読み取り、手作業で配送ラベルシステムや台帳に転記し、注文を処理します。1日あたり15～20件の注文を扱うようになると（花屋やパン屋のような個人経営ではすぐにこのボリュームに達します）、手作業による住所の転記がフルフィルメントプロセスのボトルネックになります。

日本の住所の構造も、さらに難易度を高めています。西洋の住所が通常2～3行の短い行に収まるのに対し、日本の完全な住所は、1つのチャットメッセージに6～7もの異なる構成要素が詰め込まれていることがよくあります。それぞれが配送に不可欠であり、一部でも欠けたり書き間違えたりすると、荷物は届きません。

LINEで見る日本の住所の形式

LINEで送信される典型的な住所は、次のようなものです。

このブロック内のすべての構成要素は特定の配送情報を伝えており、従来の住所パーサーはこれらが固定パターンで並んでいることを前提としています。各部分の意味は次のとおりです。

住所は、1つのテキストブロックとして現れることも、チャットの吹き出し内で複数行に分かれることも、商品の個数や配送希望時間帯などの注文固有の詳細と混在することもあります。フォームが存在しないため、顧客がチャットに自由に入力したものであり、固定されたレイアウトはありません。

この変動性こそが、従来のOCR手法が機能しなくなるまさにその理由です。住所はラベル付きフィールドや標準化された位置にあるわけではありません。たまたま配送情報を含む、複数の文字種が混在した段落なのです。

従来のOCRではなぜ大半が読み取れないのか

従来のOCRエンジン（Tesseract、クラウドOCR API、スキャナー内蔵ツールなど）は、文字を読むために設計されており、文書の構造を理解するようにはできていません。LINEのチャットスクリーンショットに含まれる日本の住所を処理する際、次の3つの根本的な問題に直面します。

第一に、混在する文字種の認識。日本の住所は、漢字（東京都、渋谷区）、ひらがな（建物名に使われる場合あり）、カタカナ（メゾン）、アラビア数字（1-2-3、150-0002）を一文の中で混在させます。特に欧文文書コーパスで訓練された従来のOCRモデルは、これらの文字種間で認識精度にばらつきがあります。〒150-0002という数字は正しく読めても、郵便記号が欠落したり文字化けしたりすることがあり、画数の多い漢字（渋や藤など）は誤認識されたり、断片に分割されたりすることがよくあります。

第二に、固定されたフィールド位置がないこと。請求書や定型フォームでは、郵便番号は決められた枠に、都道府県名はラベル付きの行にあります。しかしLINEのチャット吹き出しでは、住所は顧客の注文依頼、挨拶、場合によっては支払いのスクリーンショットと同じ視覚的スペースを共有しています。「画像の上部付近のテキスト」を探す位置ベースのOCRシステムでは、まったく別の内容を拾ってしまいます。

第三に、フラットなテキスト出力。従来のOCRは、認識された文字を行区切りで直線的に並べた文字列を返します。「この漢字列は都道府県名である」と「この漢字列は建物名である」を区別できません。上記の住所に対する出力は、意味ラベルのない単一のテキストブロックになります。その結果、事業主はOCRの出力を手動で正しいフィールドに再パースしなければならず、自動化の目的が損なわれます。

Visual AIが住所を構造化フィールドとして読み取る仕組み

Visual AI — Custom Column Extractionの背後にある技術 — は、まったく異なるアプローチで同じスクリーンショットを処理します。文字をスキャンしてテキストダンプを出力する代わりに、画像を全体として解釈し、意味のある領域を特定し、各領域で見つけたテキストに意味を割り当てます。

抽出したいフィールドを定義するだけで、AIは各構成要素が何であるかを理解することでそれらを特定します。ページ上のどこにあるべきかを推測するわけではありません。

LINEの住所スクリーンショットの場合、次のような列を定義できます。

• 郵便番号 — AIが〒記号を見つけ、それに続く数字コードを読み取ります
• 都道府県 — AIは都、道、府、県で終わる漢字を都道府県名として識別します
• 市区町村 — 都道府県に続く市区町村名
• 番地・建物名 — 丁目・番地・号の並びと建物名
• 氏名 — 通常は住所の後に単独の行にある氏名
• 電話番号 — 数字のパターンで認識される携帯電話番号

AIが住所を正しくセグメント化するのに役立つ視覚的な手がかりがいくつかあります。〒記号は住所ブロックの開始を示す信頼できるアンカーとして機能します。漢字の接尾辞（都・道・府・県）は都道府県の境界を示します。ハイフン付きの数字パターン（1-2-3）は丁目・番地・号の並びを示します。そして、住所の後に単独の行に現れる名前は、受取人として認識されます。

重要なのは、AIが「日本の住所は最大の地理単位から始まり、最小の単位で終わる」と事前に教えられる必要がないことです。言語自体が構造的なマーカーを提供しており、AIはそれを読み取るよう訓練されているため、意味的な階層を理解します。

これは、支払いスクリーンショット、他の言語のチャットメッセージ、または固定レイアウトのないあらゆる文書からデータを抽出する場合にも適用される同じパラダイムです。出力列を定義すれば、AIは「LINEの日本の住所」用に事前構築されたテンプレートに一致させるのではなく、テキストの意味を理解することで一致する値を見つけます。ハブ記事「非テーブルソースからのスクリーンショットデータ抽出」で説明されているように、ソースが完全に非構造化されていても、画像内にデータは存在します。違いは、セマンティック抽出がコンテンツを、それがどこに表示されているかではなく、何であるかとして読み取ることです。

住所だけじゃない — そのスクリーンショットには他に何があるか

LINEの注文スクリーンショットに住所だけが含まれていることはほとんどありません。同じチャットの吹き出しや近くのメッセージには、通常、顧客の注文詳細が含まれており、それらを住所と一緒に抽出することで、単一のスクリーンショットが完全な注文レコードに変わります。

LINEの注文スクリーンショットから一般的に抽出できるフィールドは次のとおりです。

• 商品名と個数 — 顧客がリクエストしている製品
• 合計金額 — 顧客が合計を計算している場合、または支払いスクリーンショットが含まれている場合
• 配送希望日時 — 多くの場合、希望する時間帯として指定されます
• 備考 — ギフトラッピングのリクエストや代替品の希望などのメモ

これらすべての情報は同じスクリーンショット（同じチャットスレッド、同じ画像）に存在するため、住所を取得するのと同じ列定義を使用して、1回のパスで抽出できます。結果は、完全な注文（送り先、送るもの、送る時期）を含むスプレッドシートの1行になります。異なるスクリーンショットやメッセージ間で住所と注文アイテムを手動で照合する必要はありません。

よくある質問

住所、注文された商品、配送希望日時 — これらはすべて、事業主がすでにスマートフォンで持っているスクリーンショットの中に存在しています。問題は、そのスクリーンショットがギャラリーの単なる画像のままになるのか、それとも今日のフルフィルメントワークフローの入力レコードになるのか、ということです。

日本では、LINE経由での注文処理がなくなることはありません。それは顧客にとっても企業にとっても、最も抵抗の少ない方法だからです。課題は、「顧客が送信した」状態と「住所が配送システムに登録された」状態のギャップを埋めることです。つまり、スクリーンショットを視覚的な参考資料から、フルフィルメントの次のステップを動かす構造化データへと変換し、一文字も再入力する必要をなくすことです。