Get a Client's Address and Order Number
From an iMessage Screenshot

iMessageがWhatsAppとは異なる抽出シナリオである理由

チャットのスクリーンショットから住所を抽出する方法についてのWhatsApp Businessガイドをお読みになった方なら、基本的な問題はご存知でしょう。チャットメッセージはフォームではなく、必要なデータは会話のテキストの中に埋め込まれています。iMessageもその核心的な課題は同じです。住所や注文番号はメッセージ内にあり、構造化されたフィールドにはありません。しかし、iMessageにはWhatsAppにはない3つの複雑な要素が加わります。

第一に、iMessageはiOS専用です。つまり、スクリーンショットは単一のオペレーティングシステムから取得され、チャットバブルのスタイルは一貫しています（iMessageは青、SMSは緑）。しかし同時に、WhatsAppにはないプラットフォーム固有の視覚要素も存在します。開封確認はメッセージの下に「既読」ラベルとして表示されます。入力中インジケータはアニメーションする省略記号で示されます。リアクション（Tapbacks）はメッセージの上にインラインでアイコンバッジとして浮かびます。これらは必要なデータを一切含みませんが、従来のOCRエンジンが判別する必要がある視覚的なスペースを占有します。

第二に、iMessageはApple Pay Cashをサポートしています。これはAppleの内蔵型ピアツーピア決済システムです。誰かがApple Pay Cashで支払いを行うと、その確認はプレーンなテキストバブルではなく、スタイル付きのダークカードとしてチャット内に表示されます。金額、受取人の名前、取引ステータスは、大きな白いテキストと色付きのステータスバッジを備えたコンパクトな黒いカード内にレンダリングされます。視覚的に、このカードは周囲のチャットバブルとは何の共通点もありません。通常の青いバブル内の住所と、同じビュー内の支払いカードの両方を捉えたスクリーンショットには、1つの画像の中に2つのまったく異なる視覚形式が含まれていることになります。

第三に、iMessageはリッチリンクプレビューを生成します。誰かがURLを貼り付けると、チャットはページタイトル、説明、サムネイルを含むカードを作成します。顧客が注文ページへのリンクを貼り付けた場合、そのプレビューは住所データを含んでいるように見えるが、通常は含んでいない別の視覚要素になります。

結果として、必要なデータは、さまざまにスタイル設定されたUI要素の中に混在して存在し、それらの要素はすべて有用な情報を含んでいるように見える画像が生成されます。抽出方法は、住所を含むバブル、支払い金額を示すカード、リンクのみを含むプレビューの違いを識別する必要があります。

iMessageの注文に関する3つのよくあるシナリオ

すべてのiMessageの注文スクリーンショットが同じように見えるわけではありません。顧客が情報をどのように送信したか、支払いが含まれていたかによって、視覚的なレイアウトは変わります。

シナリオ1：テキストバブル内の住所と注文番号

顧客は会話の中で、住所と注文詳細をプレーンメッセージとして入力します。住所は標準的な青いiMessageバブルに表示されます：

「3421 Maple Street, Apt 4B, Portland, OR 97202に発送できますか？注文番号 #A45-8921」

住所と注文番号は同じメッセージ内にある場合も、連続する2つのメッセージに分かれている場合もあります。バブルのテキストはプレーンで、書式やラベルはありません。住所は標準的なパターン（番地、市区町村、州、郵便番号）に従っており、抽出エンジンは構造によって認識できます。注文番号は英数字形式と注文コンテキストへの近接性によって識別可能です。このシナリオが最も単純です。送信者名とタイムスタンプだけが周囲の要素として存在する、チャットバブルだけのケースです。

シナリオ2：チャット内のApple Pay Cash支払いカード

顧客が同じ会話内でApple Pay Cashでも支払いを行った場合、チャットスレッドには周囲のすべてのバブルと視覚的に区別されるダークカードが含まれます。カードは黒い背景で、中央に大きな白いテキストで金額が表示され、受取人または送信者の名前、ステータスバッジ（「送信済み」、「配達済み」、「保留中」）、および下部に任意のメモが表示されます。

重要なのは、Apple Pay Cashカードに含まれていないものを理解することです。支払い金額と関係者が表示されますが、配送先住所や注文番号は含まれていません。これらはカードの上または下のテキストバブルに残ります。両方を含むスクリーンショットからデータを抽出する場合は、住所（テキストバブルから）、注文番号（同じくテキストバブルから）、支払い金額（カードから）のそれぞれに個別の列が必要です。

これは、支払い情報が通常プレーンテキストで共有されるWhatsApp Businessとは顕著な違いです — 「あなたの番号に$85を送りました」— レンダリングされたカードではなく。カード形式により支払い確認が視覚的に目立ちますが、他の情報から分離されているため、抽出エンジンがカードを個別の視覚コンポーネントとして認識できれば、個別に抽出しやすくなります。

シナリオ3：プレビューカード付きの注文リンク

一部の顧客は、小売店のウェブサイトからURLを貼り付けて注文情報を共有します。iMessageはリッチリンクプレビューを生成し、角丸のコンテナ内にサムネイル、ページタイトル、説明文がカードとしてチャットに表示されます。実際の住所や注文番号は、リンクに付随するテキストバブルに表示される場合もあれば、リンクを開いて初めて確認できる場合もあります。プレビューカード自体には通常、完全な配送先住所や完全な注文番号は表示されません。顧客が住所を別途入力せずにリンクだけを送信した場合、そのデータはスクリーンショットに表示されないため、抽出できません。これはあらゆる抽出方法に当てはまる制限です。画面上に情報が表示されていなければ、抽出することはできないのです。

iMessageの視覚的ノイズを読み解く

iMessageのスクリーンショットには、開封確認、入力中インジケータ、Tapbacks（絵文字リアクション）、メッセージエフェクト、タイムスタンプ、連絡先アバターが含まれることがあります。住所と注文番号を取得したい場合、これらの要素は視覚的ノイズになります。画像を左から右へ処理する従来のOCRエンジンは、「Read」をテキストとして、「入力中」インジケータをピリオドとして、絵文字リアクションをUnicode文字として読み取り、それらすべてが住所と同じ出力ストリームに混ざってしまいます。その結果、「3421 Maple Street」と「Read」と「...」が連続して並ぶテキストブロックが生成され、手動でのクリーンアップが必要になります。

視覚言語モデルはスクリーンショットを異なる方法で処理します。画像を完全な視覚的シーンとして解釈し、各要素の意味的な役割を認識します。「これは開封確認ラベル」「これは住所を含むチャットバブル」といった具合に、各領域内のテキストを読み取る前に分類します。開封確認のテキストは住所抽出を汚染せず、入力中インジケータが出力に文字化けとして現れることもありません。各UIコンポーネントは、含まれるテキストだけでなく、視覚的な機能によって分類されます。

同じ原則、つまりスクリーンショットはテーブルではないが、画像の各部分が何を表しているかを理解することでデータを抽出できるという考え方は、支払いスクリーンショットと同様にiMessageのインターフェースにも当てはまります。ここでの具体的な違いは、iMessageの視覚的ノイズがドキュメントコンテンツではなくインタラクティブなUI要素で構成されており、抽出方法がその2つを区別する必要があるという点です。

抽出できるものとできないもの

抽出する列名を定義することだけが、スクリーンショットから何を出力するかを指定するために必要な手順です。iMessageの注文スクリーンショットの場合、該当する列は配送先住所、注文番号、支払い金額（Apple Pay Cashカードから）、そして顧客名（会話ヘッダーから）です。抽出エンジンは各列の定義を読み取り、各視覚要素の意味的な役割を理解して対応する値を特定し、スクリーンショットごとに1行を出力します。異なる顧客からの15件のiMessageスクリーンショットのバッチ（それぞれ異なるメッセージ形式とApple Pay Cashカードを使用）から、15行の単一テーブルが生成されます。

注意すべき制限があります。Apple Pay Cashカードのデータには取引金額のみが含まれます。配送先住所や注文番号は含まれません。これらはテキストバブル内にあり、別途抽出する必要があります。スクリーンショットが入力された住所ではなくリンクプレビューを捉えている場合、住所は画像内に単に表示されていません。住所が複数のバブルにまたがって分散している複数メッセージのスレッドでは、すべての部分を含めるのに十分な会話をスクリーンショットが捉えている必要があります。また、開封確認や入力中インジケータは、意味的抽出を妨げるものではありませんが、顧客が入力を完了する前にスクリーンショットが撮影された場合、関心のある視覚領域の定義が難しくなります。

バッチ処理の場合、ワークフローは他のスクリーンショットカテゴリと同じです。画像をアップロードし、列を一度定義して、まとめて処理します。iMessageスクリーンショットと、データが純粋なプレーンテキストであるSMS注文確認が混在するバッチも、同じ列構造に従い、抽出方法は各入力画像の視覚形式に個別に適応します。

よくある質問