Shopifyとヤマト運輸を連携する方法｜送り状発行から追跡番号反映までの実務設計

「shopify ヤマト 連携」で調べる人の多くは、Shopifyで受けた注文をヤマト運輸で出荷し、送り状を発行し、追跡番号をShopifyへ戻し、顧客へ発送通知を出すところまで止めずに回したいはずです。

ここで最初に確認すべき一次情報があります。ヤマト運輸の公式FAQ「B2クラウドでamazon・筆まめ・shopifyのデータと連携し、送り状を発行できますか？」では、「amazon・筆まめ・shopifyとは連携することができません」と明記されています。一方で、ExcelやCSVで受注データを出力できる場合は外部データから発行で印刷できることも示されています。

つまり、「B2クラウドを契約すればShopify注文が自動で流れて送り状が出る」と考えてはいけません。Ship&coのShopifyとヤマト運輸の連携のような配送連携アプリを使うのか、ShopifyからCSVを出してB2クラウドへ取り込むのか、OMS/WMSや独自APIを挟むのかを、注文件数、出荷現場、返品、例外監視まで含めて決めます。

Shopifyとヤマト運輸の連携で最初に決めるべきなのは、アプリ名ではなく「Shopify注文から送り状発行、追跡番号反映、フルフィルメント更新までの責任分界」です。

先に結論：B2クラウドはShopifyと標準で直接連携しない前提で設計する

Shopify注文をヤマト運輸で発送する実務は、次の5段階に分けると整理しやすくなります。

段階	主な処理	設計で決めること
受注確定	Shopifyで注文、支払、配送先、商品明細を確認する	どの注文状態を出荷対象にするか
送り状データ作成	B2クラウド、配送連携アプリ、OMS/WMSへ注文情報を渡す	CSV/API/アプリのどれを使うか
ヤマト送り状発行	宅急便、クール宅急便、代引き、時間帯などを指定する	サービス種別、品名、配送希望日、温度帯のマッピング
出荷実績戻し	送り状番号、配送会社、出荷日をShopifyへ戻す	tracking number、tracking company、fulfillmentの更新方法
顧客通知・監視	発送メール、注文ステータス、未出荷・連携失敗の確認	通知タイミング、例外担当、再実行手順

Shopify公式ヘルプのFulfilling your own orders individuallyでは、注文を手動でフルフィルメントし、追跡番号を追加し、必要に応じて顧客へ通知できることが説明されています。また、同じページでは、複数ロケーションや分割フルフィルメント、追跡番号の追加、配送会社の選択にも触れています。日本向け販売の配送観点はShipping in Japanも確認対象です。

ただし、Shopify上で追跡番号を登録できることと、ヤマトの送り状発行から出荷完了まで自動でつながることは別です。ここを分けて設計します。

CSV・API・配送連携アプリの違い

Shopifyとヤマト運輸の間をつなぐ方式は、大きくCSV、配送連携アプリ、OMS/WMS、独自APIに分かれます。小規模ならCSVで十分なこともありますが、出荷件数、分割出荷、返品、複数倉庫、顧客通知まで考えると、手作業の限界が早く来ます。

方式	向いているケース	できること	弱いところ	事前に決めること
Shopify CSV + B2クラウド外部データ取込	出荷件数が少なく、担当者が毎日確認できる	Shopify注文をCSVで加工し、B2クラウドで送り状発行	CSV加工ミス、追跡番号の戻し忘れ、例外の見落とし	CSV列、締め時間、二重出力防止、追跡番号登録方法
配送連携アプリ	送り状発行と追跡番号反映を短く始めたい	Shopify注文取得、ヤマト送り状発行、追跡番号writeback	アプリの対応項目に業務を合わせる必要がある	対応サービス、料金、クール便、代引き、分割出荷可否
OMS/WMS連携	複数モール、複数倉庫、在庫引当、返品検品がある	受注、在庫、出荷指示、追跡番号戻しを統合	導入設計が重く、現場ルールの棚卸しが必要	在庫正本、出荷指示の起点、返品・欠品処理
独自API/カスタムアプリ	既存基幹、独自倉庫、監視基盤まで作る	Shopify Admin API、Webhook、独自DBで柔軟に連携	保守、API権限、再実行、障害対応が必要	正本、同期イベント、冪等性、ログ、監視
手動入力	月数件の検証段階	Shopify注文を見てB2クラウドに手入力	入力漏れ、住所ミス、出荷通知漏れ	いつ自動化へ切り替えるか

B2クラウドはヤマトの送り状発行に必要な選択肢です。ただし、Shopifyと標準で直接つながる前提ではなく、Shopifyからどう受注データを出し、どう取り込み、どう追跡番号を戻すかを別に設計します。

Shopify側のAPIやWebhookを使う場合は、Shopify API連携の設計方法とShopify Webhookの実装設計で整理したように、イベント受信、重複排除、再実行ログ、監視を最初から持たせます。

送り状発行に必要な注文項目マッピング

送り状発行で詰まるのは、注文番号や氏名だけではありません。ヤマトの送り状では、配送先、電話番号、品名、配送希望日、時間帯、温度帯、代引き、請求先、営業所止めなど、Shopifyの標準項目だけでは足りない判断が出ます。

送り状側で必要な項目	Shopify側の候補	設計上の注意
送り状管理番号・注文番号	order name、order ID	Shopify注文番号とB2クラウド側管理番号を対応表に残す
お届け先氏名	shipping address name	法人名、部署名、氏名の分割を確認する
郵便番号・住所	shipping address	都道府県、市区町村、番地、建物名の欠落を検知する
電話番号	shipping phone、customer phone	未入力時の扱い、携帯番号の形式、国番号を確認する
品名	商品名、SKU、固定文言	長すぎる商品名、セット品、食品・雑貨などの品名表記を決める
配送希望日	checkout拡張、アプリ、note attributes	最短出荷日、休業日、締め時間、倉庫カレンダーと合わせる
配送時間帯	note attributes、cart attributes	ヤマトの時間帯区分へ正規化する
温度帯	shipping profile、商品メタフィールド、タグ	常温、冷蔵、冷凍を商品単位で持つ
代引き金額	payment gateway、total price	Shopify側決済と代引きを併用する場合の二重請求を防ぐ
配送サービス種別	商品区分、注文タグ、配送名	宅急便、クール、コンパクト、ネコポス等の対象を決める
追跡番号	B2クラウド/アプリ/WMSの出荷実績	Shopify fulfillmentへ戻すキーを注文番号だけにしない

配送希望日や時間帯は、Shopifyの標準配送設定だけでは表現しきれないことがあります。Shopifyの送料設定を運用設計で決める方法で扱ったように、checkout表示、配送プロファイル、商品区分、CS案内を揃えないと、現場が送り状を出す段階で判断に迷います。

日時指定・クール便・代引き・分割出荷の注意点

ヤマト連携では、日本の配送実務に特有の条件を先に棚卸しします。ここをアプリ導入後に見つけると、出荷現場が手修正することになります。

論点	典型的な詰まり方	設計方針
配送希望日	注文日から近すぎる日付が選ばれる	受注締め時間、休業日、商品別リードタイムを反映する
時間帯指定	Shopify側の表記とヤマト側の区分が一致しない	選択肢をヤマト側の区分へ正規化し、自由入力にしない
クール便	常温商品と冷蔵・冷凍商品が同じ注文に入る	温度帯別に分割出荷、同梱可否、送料表示を決める
代引き	Shopify決済済み注文と代引き注文が混ざる	支払方法タグで送り状種別を分け、二重請求を防ぐ
分割出荷	一部欠品、予約商品、複数ロケーションで出荷が分かれる	Shopify fulfillmentを明細単位で管理し、追跡番号を複数持てるようにする
営業所止め・置き配	住所欄や備考に自由入力される	対応可否を決め、不可ならcheckoutやFAQで制限する
返品	返送用送り状、返品追跡番号、検品が別管理になる	返品受付、返送、検品、返金、在庫復帰を別ステータスにする

特にクール便は、送料設定、商品メタフィールド、送り状種別、梱包指示が全部つながっていないと崩れます。商品ページでは「冷蔵」なのに、Shopify注文の出荷データには温度帯がなく、B2クラウドで毎回手選択する、という状態は事故の温床です。

追跡番号writebackとShopifyフルフィルメント更新

送り状を発行して終わりではありません。ヤマトの送り状番号をShopifyへ戻し、注文を出荷済みにし、顧客通知を正しいタイミングで送る必要があります。

Shopify公式ヘルプでは、注文のフルフィルメント時または後から追跡番号を追加でき、追跡番号は発送確認メールや発送更新メールに表示されると説明されています。配送会社が自動判定されない場合や誤判定される場合は、配送会社を選択するか、追跡URLを入力する設計も必要です。

Shopify状態	出荷実務の状態	更新内容	注意点
Unfulfilled	注文受付、未出荷	まだ追跡番号はない	支払未確定、住所不備、在庫欠品を出荷対象にしない
In progress	ピッキング・梱包中	出荷準備中として扱う	現場が使うなら、誰がいつ変更するかを決める
Fulfilled	ヤマト送り状発行・出荷確定	tracking number、carrier、出荷日を登録	送り状発行だけで出荷済みにするか、集荷完了で更新するか決める
Partially fulfilled	一部商品だけ出荷	明細単位で数量と追跡番号を登録	分割出荷時に未出荷明細を残す
Cancelled / Refunded	キャンセル・返金	出荷停止、必要なら送り状取消	出荷済み後のキャンセルは返品フローへ回す

配送連携アプリを使う場合は、追跡番号writebackとShopify fulfillment status更新がどのタイミングで走るかを確認します。CSV運用の場合は、B2クラウドで発行した送り状番号をShopifyへ手入力またはCSV/APIで戻す手順が必要です。独自連携なら、Shopify Admin APIでフルフィルメントを更新する処理を作り、同じ追跡番号を二重登録しない冪等性を持たせます。

ヤマト連携の成否は、送り状を出せるかではなく、追跡番号がShopifyへ戻り、顧客通知と未出荷監視までつながるかで判断します。

注文タグ、WMS/OMS handoff、顧客通知

注文が増えると、Shopify管理画面だけで出荷判断をするのは難しくなります。注文タグやメタフィールドを使い、出荷対象、保留、クール便、代引き、住所確認、分割出荷、返品対応中などの状態を見える化します。

管理したい状態	Shopify上の表現例	外部連携で使う意味
ヤマト出荷対象	yamato、配送名、配送プロファイル	B2クラウド/アプリ/WMSへ渡す対象
クール便	cool-refrigerated、cool-frozen	送り状種別、梱包、送料確認
代引き	cod、支払方法	代引き金額、決済済み注文との分離
住所確認	address-check	出荷保留、CS確認、再実行待ち
分割出荷	partial-fulfillment	明細別追跡番号、未出荷残の監視
WMS送信済み	sent-to-wms	二重送信防止
追跡番号戻し済み	tracking-updated	顧客通知済み、再通知防止

OMS/WMSを使う場合は、Shopifyから直接ヤマトへ渡すのではなく、OMSが出荷可能判定をし、WMSが送り状発行または出荷実績を返す構成になります。Shopifyと楽天を連携する前に決める業務設計でも整理したように、複数チャネルではShopifyをすべての正本にするより、OMS/WMSを受注・在庫・出荷の正本にした方が安定することがあります。

顧客通知は「早ければよい」ではありません。送り状発行直後で荷物が倉庫に残っている状態だと、追跡ページが未反映のまま問い合わせが来ます。出荷確定、集荷引き渡し、追跡番号反映のどの時点でShopifyの発送通知を送るかを決めます。

例外監視チェックリスト

ヤマト連携は、通常フローより例外監視が重要です。連携が失敗しても、注文は増え続けます。未出荷、追跡番号未反映、住所不備、WMS送信失敗を毎日見られるようにします。

監視項目	見る条件	初動
未出荷注文	支払済みから一定時間経過してもUnfulfilled	在庫、住所、配送希望日、WMS送信状態を確認
送り状未発行	出荷対象タグあり、送り状番号なし	B2クラウド取込、アプリエラー、CSV出力漏れを確認
追跡番号未反映	送り状発行済みだがShopifyにtracking numberなし	writebackログ、CSV戻し、APIエラーを確認
顧客通知未送信	Fulfilledだが通知なし	通知設定、メールアドレス、アプリ側送信設定を確認
住所不備	郵便番号、都道府県、番地、電話番号の欠落	CS確認タグを付け、出荷対象から外す
クール便不一致	商品は冷蔵/冷凍だが送り状が常温	商品メタフィールド、注文タグ、送り状種別を補正
代引き金額不一致	注文合計と代引き金額が合わない	決済状態、送料、手数料、返金を確認
分割出荷残	一部Fulfilledで残明細が放置	欠品、予約、別倉庫、キャンセル判断を確認
返品未処理	返品受付済みだが検品・返金が未完了	返送追跡番号、検品結果、在庫復帰を確認
連携エラー再発	同じSKUや配送方法で失敗が続く	マッピング表を修正し、再実行ルールを更新

WebhookやAPIを使う場合は、HTTP 200だけを成功と見ず、「送り状番号が戻った」「ShopifyがFulfilledになった」「顧客通知が送られた」までを業務成功として監視します。

まとめ

Shopifyとヤマト運輸の連携は、配送設定の話だけではありません。B2クラウドはShopifyと標準で直接連携しないため、CSV、配送連携アプリ、OMS/WMS、独自APIのいずれかで、Shopify注文をヤマトの送り状発行へ渡す設計が必要です。

最低限用意したいのは、次の5点です。

用意するもの	目的
連携方式比較表	CSV、配送連携アプリ、OMS/WMS、APIのどれで始めるかを決める
送り状項目マッピング	注文番号、住所、電話、品名、日時指定、クール便、代引きを対応させる
ステータス遷移表	Unfulfilled、In progress、Fulfilled、Partially fulfilledを出荷実務と揃える
追跡番号writeback手順	ヤマト送り状番号をShopify fulfillmentへ戻し、顧客通知につなげる
出荷例外監視表	未出荷、送り状未発行、追跡番号未反映、住所不備、分割出荷残を検知する

送り状が印刷できるだけでは、Shopify運用は安定しません。配送希望日、時間帯、クール便、代引き、分割出荷、返品、顧客通知、WMS/OMS handoff、連携失敗の監視まで含めて設計して初めて、出荷業務は止まりにくくなります。