r/shopify のある出店者がこの作業を正確に記しています。仕入先は注文ごとに出荷通知をメールで送り、それを開いて追跡番号をコピーし、注文に貼り、出荷済みにし、次へ。多い日は三十件で一時間が消えます。別の人は週次版を挙げていました——毎週日曜の夜に三時間のコピペです。
つい端から端まで自動化したくなりますが、最初の一手としては間違いです。そのスレッドの最良の返信が理由を述べています。実用的な版は不一致か未着の行だけを出すもので、全件確認の三時間を例外処理の十分に変えます。
なぜ照合が自動化より先か
完全自動化は店に書き込みます。つまり書き込み権限付きの資格情報が要り、加盟店自身のアプリが要り、開発者審査の待ち行列に並ぶことになります。そして仕入先がメールの雛形を変えたとき——必ず変えます——見える形で不一致が積まる代わりに、黙って間違った出荷処理が走ります。
照合ならそのリスクなしに同じ一時間を取り戻せ、そもそもマッチングが信頼できるかを先に教えてくれます。各プラットフォームで書き込み権限が何を要求するかは、Shopify Admin MCP の解説記事にまとめてあります。
二つのエクスポート
自分の注文。注文番号、受取人名または住所、明細行、現在の出荷状態を含むエクスポートなら何でも構いません。Shopify、WooCommerce、Etsy、eBay はいずれも管理画面から出せ、API 権限は一切不要です。
仕入先の出荷通知。それが届くメールフォルダごと書き出します——多くのクライアントは .mbox や .eml 群で出せます。CSV やポータルのエクスポートがあるならそちらを。より素直で、雛形変更で壊れません。
両方を一つのローカルフォルダへ。そのフォルダが作業場の全てです。
四つの表、うち一覧にするのは三つだけ
この形を明示的に求め、文章での説明で代替させないこと：
- 一致し整合しているもの——件数だけ。一覧にしない。
- 対応する注文がない通知——追跡番号はあるが注文が見つからない。
- 通知のない注文——N 日以上経っても出荷通知がない。
- 曖昧——複数の注文に一致したもの。
まず注文番号で照合し、番号がない場合のみ受取人名＋郵便番号にフォールバックします。表 2～4 には照合に使った元フィールドを必ず添えさせます。そして確信のない一致は表 1 に推測で入れず、表 4 へ回すこと。
表 1 を一覧ではなく件数にすることが、この設計の核心です。平常な日はその数字が 28、他の三つは空、十秒で終わります。
各表が実際に示すこと
表 2、番号はあるが注文がない。多くはキャンセル済み注文に対する出荷か、通知の重複です。確認は安く、二重出荷を二重に支払う前に捕まえることがあります。
表 3、注文はあるが番号がない。これが高くつく表であり、全体を回す理由です。「注文はどこ」の問い合わせになり、モールでは発送遅延の指標になります。失うのは好意だけではなく露出です。
表 4、曖昧。ほぼ常に同じ世帯への二件です。手作業で解く価値があるのは、完全自動の仕組みならどちらかを選び、半分は間違えるからです。
その後に初めて、書き戻す
数週間回して表 4 が安定して空になったなら、マッチングは行動に使える水準です。その段階でも出荷の書き込みは無制限ではなく段階付けされた操作であるべきです。実行前のプレビューと、1 回の呼び出しが触れられる件数の上限。そうすれば誤った一致が黙って二百件を出荷済みにすることはありません。
そこまで行かなくても、照合だけですでに一時間は消えています。残す価値があるのはその部分です。
Orkas での回し方
二つのエクスポートをプロジェクトフォルダに置き、そのままにします。プロジェクトは日をまたいで文脈を保つので、明日の実行は今日の表 3 と比べられます——三日連続で番号のない注文と、今朝現れたものは別の問題です。どちらかを教えるのは差分だけです。ファイルと鍵は手元に残り、モデル呼び出しはプロバイダへ直接向かいます。
週次の店舗業務の残りも同じフォルダに住みます。その流れは店舗レビューのユースケースで説明しています。
これがカバーしないこと
- 見たことのないメール形式では、最初の数回は表 2 を自分で確認する必要があります。
- 荷物が紛失したことは分かりません——出荷の知らせがなかったことだけが分かります。
- 運送会社側の追跡ステータスは別問題です。ここでは番号が存在するかとそれを必要とする注文だけを照合します。