ネットショップの受注を1枚のスプレッドシートに集約する設計｜APIで取る範囲とメールに頼る範囲の線引き
ネットショップの受注を1枚のスプレッドシートに集約する設計｜APIで取る範囲とメールに頼る範囲の線引き
自社サイトのほかに楽天・Yahoo!ショッピング・Amazonでも売っていると、注文の確認画面が4つに増えます。朝いちで4つのタブを開き、それぞれの管理画面から注文を拾って手元の一覧に転記する。件数が少ないうちは回りますが、この作業は増えることはあっても減りません。
「全販路の受注を1枚のスプレッドシートに自動で集めたい」という相談は、ここから始まります。先に結論を書きます。
全販路を同じ方法で取りに行こうとすると、たいてい途中で止まります。売上の主力になっている1チャネルだけをAPIできちんと作り、残りは受注通知メールを読ませる。この2段構えが、小規模〜中規模の事業者にとっては現実的な着地点です。
そしてもうひとつ。着手前に「すでに受注一元管理ツールを使っていないか」を必ず確認してください。答え次第で作る量が半分以下になります。
4チャネルの受注を1枚に集約する設計を組んだときの判断を、順番に書いていきます。
全チャネルをAPIで取りに行かない理由
「一元管理」と聞くと、全販路に正式なAPI連携を組む絵を描きがちです。技術的には可能ですが、費用対効果が合わないことが多い。
ある革製品の小売事業者で、実際のEC売上の内訳を1週間分そのまま並べてみたことがあります。
| チャネル | 週の売上 |
|---|---|
| 自社サイト | 約7.4万円 |
| 楽天 | 約7.8万円 |
| Yahoo!ショッピング | 約4.7万円 |
| Amazon | 約0.5万円 |
自社サイトと楽天がほぼ同規模で、Yahoo!がその6割、Amazonは1桁小さい。
このとき、Amazonの正式なAPI（SP-API）を使うには開発者としての審査申請が必要で、通るまで数日から数週間かかります。週5,000円の販路のために、数週間の審査と実装工数をかける判断にはなりません。
売上の分布を見ずに「全チャネルAPI」で見積もると、いちばん手間のかかるチャネルがいちばん売れていない、という構図になりがちです。設計に入る前に、1週間分でいいのでチャネル別の実額を並べてください。方式はそのあとで決まります。
「リアルタイム」の正体
依頼側と作る側でずれやすいのが「リアルタイム」という言葉です。
本当の意味で即時に取れるのは、自社カート（Shopifyなど）のWebhookだけです。注文が作られた瞬間にカート側から通知が飛んでくる仕組みなので、秒単位で反映できます。
一方、モール側は正式なAPIを使ったとしても、多くは「一定間隔で問い合わせて新しい注文を拾う」方式になります。つまり数分から15分程度の遅れが必ず入ります。受注通知メールを読む方式なら、メールが届いたタイミング次第です。
ここを先に共有しておかないと、「リアルタイムで一元管理」と言いながらモールだけ15分遅れる、という説明を後からすることになります。販路ごとに反映の速さが違うのは仕様であって不具合ではないと、着手前に言っておくのが正しい進め方です。
主力チャネルは「速報」と「確定」を分けて設計する
主力の自社カートについては、きちんと作ります。ここでの設計の要点は1つです。
Webhookで受け取ったものをそのまま正としない。翌朝のバッチで洗い直す。
理由は、注文が「作られて終わり」ではないからです。
- 注文直後は「支払い待ち」で、あとから決済が完了する
- お客さまからの連絡でキャンセルになる
- 返金処理が入る
- 発送が済んで状態が変わる
Webhookは「注文が作られた」瞬間の通知です。その後の変化を追いかけなければ、キャンセルされた注文がシートに生き残り続けます。月末に集計して合わないのは、たいていこれが原因です。
加えて、Webhookは通信の失敗などで取りこぼしが起きます。100%届く前提で組んではいけません。
そこで、こういう二段構えにします。
- Webhookで即時に追記する（速報。すぐ見たいという要望はこれで満たす）
- 翌朝のバッチで前日分をAPIから取り直し、シートの内容を上書きして確定させる（正確性はこちらで担保）
このとき必ず、注文IDをキーにした重複チェックを入れてください。同じ注文が二度書かれない作りにしておけば、Webhookとバッチが同じ注文を処理しても行が増えません。これがないと、二段構えにした瞬間に全部の注文が2行ずつ並びます。
権限は既存アプリに足さない
技術的な話ですが、事故になりやすいので書いておきます。
カートのAPIを使うときは「アプリ」を作って権限（スコープ）を与えます。商品の登録に使うアプリと、注文を読むアプリでは必要な権限が違います。
このとき、すでに本番で動いているアプリに権限を追加するのは避けてください。権限を変更すると認証トークンが再発行される場合があり、そのトークンで動いている既存の自動処理が止まります。商品の更新用アプリに注文を読む権限を足したら、商品側の処理が突然エラーを吐き始める、という形で表面化します。しかも止まったことにすぐ気づけません。
正しいのは、受注取得用に別のアプリを新しく作ることです。既存のアプリには一切触らない。アプリを分けておけば、片方の設定変更がもう片方に波及しません。
なお、Shopifyの場合は直近60日以内の注文であれば追加申請なしで取得できます。それより古い注文まで遡って読む必要がある場合だけ、別途申請が必要になります。日次で回す運用なら申請は不要です。
メールを読ませる方式は「静かに壊れる」前提で作る
ここがこの記事でいちばん伝えたい部分です。
受注通知メールを読んでシートに書き込む仕組みは、実装そのものは難しくありません。難しいのは、壊れたときに誰も気づけないという点です。
考えてみてください。メールの書式がモール側の仕様変更で少し変わり、こちらのプログラムが中身をうまく取り出せなくなったとします。プログラムはエラーで止まるかもしれませんし、空のまま処理を終えるかもしれません。
どちらにしても、シートを見ている人の目には「今日は注文が0件だった」としか映りません。売れない日は普通にあるので、疑うきっかけがないのです。
これは自動処理全般に共通する失敗の型です。定期実行の仕組みが「正常終了」を返し続けながら、中身は何もしていない、ということが実際に起こります。実務で確認した例では、毎日決まった時刻に走る処理が52日間ずっと正常終了しながら、中身は認証に失敗して空振りしていたことがありました。処理が最後まで走り切っている以上、実行ログにも異常は出ません。
だから、メール解析の仕組みには最初から次の3つを組み込みます。この3つが無いメール解析は、作る意味がありません。
1. 読み取りに失敗したメールは捨てず、生のまま「未処理」シートへ退避する
失敗を握りつぶさない。生の本文がシートに残っていれば、後から書式の変化を確認して直せます。捨ててしまうと、何が起きたのかを再現する手段が消えます。
2. 「届いたメールの件数」と「シートに書かれた件数」を突き合わせ、合わなければ通知する
これが健全性を見るいちばん確実な方法です。受注メールにラベルを付けて振り分けていれば、その件数はすぐ数えられます。10通届いて7行しか書かれていなければ、3件が落ちている。処理が動いたかどうかではなく、データが期待通りに増えたかで判定するのが要点です。
3. 月に1回、各モールの管理画面の注文件数とシートの件数を突き合わせる
自動チェックをすり抜ける種類のズレは必ず残ります。月1回、5分の目視でいいので、正解データと照合する時間を運用に組み込んでください。
キャンセル通知メールも一緒に読ませる
もうひとつ、メール方式の弱点として押さえておくべき点があります。
受注メールは注文が入った瞬間のスナップショットです。その後キャンセルされても、返金されても、届いたメールの内容は変わりません。何もしなければ、キャンセルされた注文がシートに残り続けます。
対策はシンプルで、キャンセル通知メールも解析対象に含め、該当する注文に「取消」の行や状態を立てることです。注文IDが同じものを探して状態を書き換える、という処理を1つ足すだけです。
受注メールだけを見て「一元管理できた」としてしまうと、シートの合計金額が実際の売上より多くなります。しかも多い方向にずれるので、気づきにくい。
実装の形
具体的な組み方は、こうなります。
- メールソフトのフィルタ機能で、各モールの受注通知メールに自動でラベルを付ける
- 一定間隔で動くプログラムが、そのラベルの付いた未処理メールを読む
- 本文から注文番号・日時・商品・金額などを取り出してシートに追記する
- 処理が済んだメールは「処理済み」ラベルへ移す
4番があることで、同じメールを二度処理しません。この状態管理を入れておくのが、シンプルで壊れにくい形です。
なお受注メールが複数のアドレスに分散しているなら、先に転送設定で1か所へ集約してください。読みに行く場所が増えるほど、片方だけ設定が漏れます。
本当の難所は「取得」ではなく「正規化」
ここまで取得方法の話をしてきましたが、実際に手が止まるのはこの先です。各チャネルから取ってきたデータの形が、まったく揃っていません。
- 注文番号の体系が違う（桁数も文字種も別物）
- 商品コードが違う。同じ商品でもモールごとに別のコードが振られている
- 送料・手数料・ポイント・クーポンの扱いが違う。金額のどこまでが売上なのかが揃わない
- キャンセルの仕様が違う
このまま1枚のシートに流し込むと、行は集まってもチャネルをまたいだ集計ができません。「この商品は全チャネル合計で何本売れたか」を出そうとして、コードがバラバラで数えられない、という状態になります。
対策は、モールの商品コードと自社の品番の対応表を先に1つ作ることです。地味な作業ですが、これがないと一元管理は「行が集まっただけの表」で終わります。
自社側にカテゴリの体系がある場合は、そこに寄せるのが早い。たとえばA=ベルト、B=財布、C=小物、D=パーツ……といった分類が社内にすでにあるなら、集約先ではその分類に統一します。新しい分類を作らず、既存の分類に合わせる。社内の他の資料と数字を突き合わせられる状態を保つためです。
着手前に決めておく7項目
ここまでの内容を、依頼する側・作る側の両方で先に確認しておく項目としてまとめます。
1. すでに受注一元管理ツールを使っていないか
最重要です。ネクストエンジンやCROSS MALLのような受注一元管理ツール、あるいは基幹システム側にすでに全チャネルの注文が集まっているケースがあります。
実際、先ほどの革製品の事業者では、店舗のPOSシステムの倉庫マスタを調べたところ、自社サイト・楽天・Amazon・Yahoo!が最初からすべて「倉庫」として登録されていました。つまり売上ベースでは、全チャネルがすでに1か所へ統合されていたわけです。
もしどこかのツールがモールの受注を集めて基幹システムへ流し込んでいるなら、そのツールのAPIやCSV出力から引いてくるほうが圧倒的に速い。4チャネル分の取得処理を個別に作る必要が消えます。ここを確認せずに着手すると、すでにあるものをもう一度作ることになります。
2. どこに集約するか（既存のスプレッドシートにシートを足すのか、新規に作るのか）
3. 列の構成（標準的には、注文番号／日時／顧客名／商品名・SKU／数量／金額／支払状態／発送状態／チャネル）
4. 顧客名や住所を入れるかどうか
入れるなら共有範囲を絞る必要があります。スプレッドシートは共有が簡単なぶん、個人情報が入った瞬間に扱いが変わります。発送作業に使わないなら、最初から入れないほうが安全です。
5. 各モールの受注メールの実物
キャンセル通知も1通あると理想的です。文面を見ないと解析プログラムは書けません。「こういうメールが来るはず」という一般論では作れず、実際に届いた1通が必要です。ここが揃わないと着手できないので、依頼の段階で用意しておくと早く進みます。
6. 受注メールの届き先アドレス
複数に分かれているなら、転送で1か所に集約します。
7. 用途は「作業一覧」か「分析台帳」か
これで設計が変わります。発送作業のために使うなら、未発送のものが上に来て、処理したら消える形が正しい。売上分析のために使うなら、過去の注文がすべて残り、月別・商品別に集計できる形が正しい。両方を1枚で兼ねようとすると、どちらとしても使いにくい表になります。
進める順番
最後に、実際に作る順番です。
1. 主力チャネルのAPI連携を先に作る。受注メールの実物が揃うのを待たずに着手でき、売上の大半を占める部分なので、ここが動いた時点で価値の大半が出ます。
2. 受注メールが揃い次第、モールごとの解析処理を足す。1チャネルずつ追加します。同時に4つ作らないこと。1つ作って件数の突合が正しく動くところまで見届けてから次へ進みます。
3. すべてを1枚の台帳に統合する。正規化の対応表はこの段階で効いてきます。
この順番なら、途中で止まっても「主力チャネルだけは自動で入ってくる」状態が残ります。全部つながるまで何も使えない作り方をしないのが、この種の仕組みを運用に乗せるコツです。
まとめ
複数の販路の受注を1枚に集める仕組みは、「全部を同じやり方で取る」と考えた瞬間に難易度が跳ね上がります。
- 売上の分布を先に見て、主力だけAPIできちんと、残りはメール解析で割り切る
- 主力チャネルは速報（Webhook）と確定（翌朝のバッチ）を分ける。注文は後から状態が変わる
- APIの権限は既存の稼働中アプリに足さず、新しいアプリを作る
- メール解析は静かに壊れる。失敗メールの退避・件数の突合・月1の目視照合を最初から入れる
- キャンセル通知も解析対象に入れないとシートの売上が実際より多くなる
- 難所は取得ではなく正規化。商品コードの対応表を先に作る
- 着手前に既存の一元管理ツールの有無を確認する。工数が半分以下になることがある
自動化の仕組みは、動き始めた日よりも壊れた日に気づけるかどうかで価値が決まります。件数の突合をひとつ入れておくだけで、「今日は0件だった」と「今日は壊れていた」を区別できます。
graciautoでは、ホームページ制作からEC・店舗業務の自動化まで、設計と実装をあわせて行っています。すでにお使いのツールを活かせる場合も多いので、現状の販路と使用中のシステムをお聞かせいただければ、作る必要のある範囲だけをお出しします。