Shopifyの注文確認メールには
必要な行が含まれている

Shopifyの注文確認メールに実際に含まれるもの

ShopifyはLiquid変数を通じてライブの注文データを取得するテンプレートから注文通知を生成するため、メールは画像として読み取るものではなく、注文レコードのレンダリングされたビューです。 Shopifyの通知変数リファレンスには、これらのテンプレートがアクセスできる内容がリストされています。顧客が見る注文番号（#1004）とその生の形式（1004）、一部のストアが代わりに表示する別のconfirmation_number、顧客のメールアドレス、配送先と請求先住所、そして各商品タイトル、バリアント、SKU、数量、価格を持つline_itemsです。合計も別々の値として届きます。小計、送料、税、関税、割引、総合計に加え、金融ステータス、支払い条件が設定されている場合は支払期日も含まれます。

実際的な結果として、注文データはラベルに隣接してアンカーできるフィールドではありません。これはテンプレートが生成したHTMLレイアウトです。標準のShopify注文確認メールには添付ファイルがなく、開くものもスキャンするものもありません。メッセージ本文が注文ドキュメントです。

注文メールには開くものがありません。必要なフィールドはメッセージ本文そのものです。

同じ注文がストアごとに異なる表示になる理由

Shopifyの注文メールに一つの固定解析ルールを適用できない理由は、テンプレートが編集されることを前提に設計されているからです。設定 > 通知で、ストアは注文確認メールのLiquidを書き換えることができ、Shopifyは販売者が最も頻繁に追加する要素を文書化しています。関税・輸入税を徴収するストア向けのduties行、支払い期限と金額を表示するpayment termsブロック、特定の製品に添付されるケア指示や刻印テキストなどのline itemカスタムプロパティです。

ブランディングも表示に影響します。ロゴURLとアクセントカラーはメールカスタマイズ設定から取得され、各line itemのタイトル、バリアント、プロパティは販売者自身のループによって出力されます。通貨はストアまたはマーケットに従うため、注文合計は購入者の所在地に応じてUSD、EUR、GBPのいずれかで表示されます。また、ストアは連番の注文名の代わりにランダムなconfirmation_numberを表示することもできるため、メール内の識別子が常に期待する番号であるとは限りません。

買い手が受け取るテンプレートだけが重要というわけではありません。Shopifyのスタッフ向け新規注文通知は別のテンプレートであり、出荷確認メールには元の確認メールにはまだない追跡データが含まれます。そのため、1件のサンプル注文のラベルに基づいて構築されたパーサーは、ストアが見出しを変更しただけで機能しなくなり、「テーマは関係あるのか」という販売者の質問には明確な答えがあります。レイアウトはストア固有であり、ラベルは変更可能なのです。

Shopify標準のエクスポートが別のツールである理由

Shopifyの組み込みエクスポートは注文ページにあり、注文データのCSVを書き出します。自社ストアの履歴に関しては無料で、完全で、これに勝るものはありません。一度きりのダンプが必要なら、それを使いましょう。ただし、これは注文が届くたびに更新される記録ではありません。Shopifyのヘルプには仕組みが記載されています。最大50件の注文または現在のページのエクスポートはデバイスに直接ダウンロードされ、51件以上または日付ベースのエクスポートはメールで送信されます。列は固定されており、取引履歴には捕捉済みの支払いのみが含まれ、フィールド選択もスケジュールもありません。

ソースがエクスポートでない場合、その差はさらに広がります。スタッフ通知メールは、管理者アクセスを必要とせず、受信者として追加した誰にでも届きます。別のマーケットプレイスや卸売業者は、Shopifyのエクスポートでは決して見られない独自の注文メールを送信します。梱包リストを必要とする倉庫チームにストアのログイン情報を渡すべきではありません。これらの各ケースでは、メールが情報源であり、それを継続的に届く行に変換することが仕事です。

注文を手作業でシートに取り込むと失敗する理由

手作業による抽出は、予測可能な3つの場面で失敗します。最初は転記です。注文番号、顧客名、合計金額をシートに入力するのは単純な作業ですが、注意力が持続する限界をはるかに超えて繰り返されます。エラーに関する研究はその結果を明確に示しています。Pankoが収集したフィールド監査では、調査対象のスプレッドシートの少なくとも86%にエラーが見つかり、管理された実験では51%にエラーが見つかりました。これは人々が不注意だからというわけではありません。手でデータを再入力する作業には認知的な限界があり、どれだけ注意してもそれを取り除くことはできないのです。

2つ目は注文の構造です。複数商品の注文は、ヘッダーと繰り返される明細行のブロックで構成されており、フラットなシートではどちらかを選ぶ必要があります。ShopifyのCSVエクスポートは明細行ごとに1行を出力し、注文レベルのフィールド（合計金額を含む）は最初の行以降は空白になります。そのため、誰かが合計金額を下までコピーすると、エクスポートされたシートで売上が二重計上されることになります。メールから手でコピーする場合は逆の問題が発生します。注文番号と合計金額は保持しやすくても、3番目と4番目の明細行が静かに失われてしまうのです。

3つ目は量です。実際の注文フローでは、手動プロセスは優雅に劣化しません。レコードが失われます。ある小さな食料品店はr/shopifyのスレッドでこの失敗を次のように説明しています。「注文情報の一部（注文番号、金額、場所、地域）をエクセルシートに転記し、それを使って場所に応じてドライバーに注文を割り当てています。毎週金曜日に非常に人気のあるセールがあり、最大70件の注文が入ることがあります...すべて手動で行うと、当然注文が漏れてしまいます。」1日に70件の注文は大きな店舗ではありません。それは単に、他のことをしながら正確にコピーできる人間の能力を超えているだけなのです。

解決策：メールをルーティングし、列に名前を付ける

データはすでにメールで届くので、必要な作業は、届いたメールを行に変換することです。 このステップを実現するImageToTable.aiの機能が2つあります。1つ目はEmail Inboxです。これはアカウント専用のアドレスです。このアドレスをストアと共有するか、転送ルールを設定して通知をそこに届くようにすると、誰もファイルをダウンロードまたはアップロードすることなく、メッセージが処理キューに入ります。注文データはメッセージ本文にあるため、受信トレイが本文を読み取るように設定します。ストアがPDF請求書も送信する場合は、本文と添付ファイルの両方を読み取るように設定します。Auto-Processはメッセージが届くとすぐに抽出を実行し、送信者ホワイトリストにより、メーリングリストや無関係なメールが削除対象の行になるのを防ぎます。

2つ目はCustom Column Extractionです。Order Number、Order Date、Customer Name、Customer Email、Shipping Method、Item Count、Line Items、Subtotal、Shipping、Tax、Discount、Order Total、Currency、Financial Statusなど、必要な列名を入力します。AIが各メールを読み取り、値の意味を理解してそれらの値を特定するため、同じ列セットがデフォルトテンプレート、カスタマイズされたテンプレート、スタッフ通知のすべてで機能し、ストアごとのルールは不要です。入力した名前がシートのヘッダーになります。

セットアップは、注文ごとではなく一度だけ設定する短い設定リストです：

1つの形式について明確にしておくべき点があります。標準的な出力は注文メールごとに1行で、Line Items列に明細が保持されます。SKUレベルのレポート用に商品ごとに1行が必要な場合は、エクスポート後にシート上で分割できます。その際、数式は表示され、確認が容易です。

出力結果のイメージ

完了したバッチは、注文ごとに1行、指定したフィールドを列として持つ1つのテーブルです。 以下の例では読みやすさのために少数の列を使用していますが、シートには定義したすべての列が含まれます。

表内の値は例です。Order NumberとOrder Dateはメール本文から、商品数と明細は本文内の商品テーブルから、Totalは印刷された注文合計から取得されます。日付と金額は抽出時に標準化されるため、クレンジング作業なしでレポートに使用できるファイルになります。シートが完成すれば、合計、ピボット、並べ替えは、手入力されていない列に対しても機能します。

できないこと

Shopify連携ではありません。 ImageToTable.aiは、ルーティングされたメールを読み取ります。アプリストアのコネクタも、ネイティブのShopify接続も、ストアへの書き戻しもありません。Shopifyにデータがプッシュされることも、注文ステータスが変更されることもありません。出力はスプレッドシートであり、ストアがシステム・オブ・レコードのままです。

メールを読み取ります。チャットは対象外です。 テキストメッセージやWhatsAppで送信された注文詳細は、別のチャネルです。Email Inboxは、メールでアドレスに届いたものだけを認識するため、それらのメッセージはドキュメントとして存在するようになった時点で転送する必要があります。

抽出は行いますが、照合は行いません。 このツールは列を埋め、上記のLine Item Checkを実行できますが、注文を銀行入金と照合したり、返金を特定の注文に紐付けたり、送料が正しいか検証したりはしません。これらは判断であり、シート上で担当者が行うものです。

過去分の一括エクスポートは、引き続きエクスポート機能の役割です。 過去数年間の注文を移行する場合、ShopifyのCSVエクスポートが適切なソースです。このワークフローは、新規注文の継続的なフロー、セカンドチャネル、そしてストアへのアクセス権を持たずにデータを必要とする人々のために価値を発揮します。

精度は高いですが、完璧ではありません。 印刷されたテーブルデータに対して最大99%の精度を謳っていますが、これは特定の入力タイプに対する当社独自の数値です。Review ModeとBbox verificationは、金額を扱うフィールドのために存在します。抽出されたセルにホバーすると、元のメッセージ上のソース領域がハイライトされ、編集した値はAIの読み取り結果に戻すことができます。

周辺のワークフローが必要な場合は、メール全体を読み取るメールパーサーが一般的なケースをカバーし、スクリーンショットからeコマース注文データを抽出するが、メールではなく画像として届くバージョンを扱います。確認がメールではなくテキストメッセージとして届く場合は、SMS注文確認ウォークスルーがそのチャネルをカバーし、抽出結果をGoogle Sheetsに送信するが、ほとんどのチームが使用する送信先をカバーします。

よくある質問

カスタムテーマやカスタマイズされた注文確認テンプレートを使用しているストアでも機能しますか？

はい。抽出はラベルや位置の一致ではなく意味に基づいて値を読み取るため、見出しの変更、レイアウトの並べ替え、関税行の追加があっても新しいルールは不要です。列名を一度定義すれば、同じセットがストアが送信するすべての注文テンプレートに適用されます。

注文データはメール本文と添付ファイルのどちらにありますか？

本文にあります。標準のShopify注文確認メールは添付ファイルのないHTMLメッセージのため、受信トレイはメッセージ本文を読み取るように設定されています。ストアがPDF請求書も添付する場合は、本文と添付ファイルの両方の設定に切り替えると、両方が同じ行に読み取られます。

スタッフ向け新規注文通知も顧客確認メールと同様に読み取れますか？

はい。スタッフ向け新規注文通知は別のテンプレートから生成されますが、同じ注文データ（注文番号、顧客、明細項目、合計）が含まれています。列は意味に基づいて照合されるため、同じ設定で受信トレイにルーティングされたどちらのテンプレートも取得できます。

複数商品の注文はどのように処理されますか？

各注文メールが1行になり、明細項目はLine Items列に取得されます。SKUレベルのレポート用に商品ごとに1行必要な場合は、エクスポート後にスプレッドシートでその列を分割してください。数式は表示され、確認しやすくなっています。

異なる通貨の注文合計を取得できますか？

はい。通貨は列として抽出され、後処理で日付と金額が標準化されるため、USD、EUR、GBPで販売するストアでも一貫した1つのシートが生成されます。すべての行を単一通貨にする必要がある場合は、使用する為替レートを適用する計算列を追加してください。

無料トライアルはありますか？

サインアップは無料で、自分の注文でテストできるクレジットが含まれています。注文メールをいくつか転送して列が埋まるのを確認し、支払い前に出力を判断してください。このページのデモはアカウントなしで実行できます。

注文がインボックスから消えたわけではない

滞留した注文を整理の問題として捉えがちですが、もっと整ったメールボックスや丁寧なコピー＆ペーストで解決するかのように考えるのは誤りです。注文は決して消えていません。時間通りに届き、人が記録に変換して初めて意味を持つ形式で置かれていたため、誰かが思い出したときだけ支払い可能になり、ピッキング可能になりました。記録作成を到着の瞬間に移せば、問題は「誰かが覚えているか」ではなく「行がそこにあるか」になります。それは、チームが他の作業をしている間にシステムが実行できるチェックです。