出荷指示が連携で抜ける問題は、「備考」という一つの欄に性質の異なる情報を集めると起きやすくなります。設計の出発点は、情報を次の4種類に分けることです。
| 種類 | 例 | 正本 | 出荷時に必要な状態 |
|---|---|---|---|
| 顧客向け商品情報 | ギフト対応の可否、配送条件 | 商品マスタ・商品ページ | 購入者への表示内容として管理 |
| 商品別の社内作業指示 | 割れ物、同梱物、温度帯、封入物、検品項目 | 商品マスタ | 受注確定時の値を受注明細へ固定 |
| 注文単位の例外 | 配送希望、領収書に関する依頼、購入者備考 | 注文 | 対象注文だけに紐付けて伝達 |
| 受注後の変更 | 住所訂正、同梱物の差し替え、出荷保留解除 | 変更履歴を持つ注文管理 | 変更前後と再通知の有無を記録 |
ここでいう「正本」は、常に出荷担当者が画面で読む場所ではありません。たとえば商品別の梱包注意は商品マスタを正本にしても、出荷時に参照する値は受注明細に複製した値にします。商品マスタは未来の受注を変えるための情報、受注明細は成立済み注文を処理するための記録、と役割を分けるためです。
EC-CUBE 4には、フロントには表示されない管理用の「ショップ用メモ」が商品情報にあります。ただし、これは商品にメモを持たせる機能であり、注文確定時の内容を受注明細へ保存することまでを意味しません。EC-CUBE公式マニュアル(確認日:2025年3月8日)を前提に、スナップショット保存の可否は個別に確認してください。
「商品にメモ欄がある」ことと、「そのメモが対象受注・WMS・3PLへ渡る」ことは別要件です。画面、API、CSV、帳票の経路ごとに確認します。
商品マスタを更新した翌日に、未出荷の過去注文の指示まで変わる設計は、作業内容を後から再現できません。特に季節の同梱物、キャンペーン用封入物、検品条件の変更では、いつの注文にどの指示が適用されるかが曖昧になります。
そこで、受注確定を契機に商品別指示を受注明細へコピーし、その値を通常更新しない要件を置きます。EC-CUBEの開発Issueでも、商品ごとの梱包注意・同梱物・出荷確認事項を管理者用メモとして持ち、注文確定時に受注明細へコピーする設計案が示されています。ただし、これは標準機能の提供を示す資料ではなく、実装検討上の要件例として扱うべきものです。Issue #6821(確認日:2025年3月8日)
自由記述だけでは、連携先で欠損を検知しにくくなります。WMSや3PLに判定してほしい条件は、可能な範囲でコードと値に分解します。
受注明細スナップショット(例)
- packing_instruction_text: 「ガラス瓶。緩衝材で固定」
- temperature_zone: AMBIENT / CHILLED / FROZEN
- insert_code: LEAFLET_2025_SPRING
- inspection_code: LOT_CHECK
- instruction_version: 2025-03-01
- snapshotted_at: 受注確定日時
packing_instruction_text は作業者が読む補足、temperature_zone や insert_code は連携・照合に使う値です。コード体系を増やしすぎると運用負荷が上がるため、出荷先で振り分けや帳票出力に使うものから始めます。
一方、商品ごとの指示が変更される場合もあります。たとえば、出荷前に破損対策を強化する必要が判明したケースです。このときは商品マスタを更新するだけでなく、影響する未出荷受注を抽出し、受注明細スナップショットを明示的に変更します。変更者、変更理由、変更前後の値、3PLへの再送結果を残してください。
カートごとに入力欄やデータモデルは異なります。機能名で判断せず、「誰が入力するか」「何の単位か」「外部連携で取得できるか」で選びます。
Shopifyでは、注文全体への特別指示を記録する order notes、カート単位の追加情報である cart attributes、商品ごとの情報である line item properties が案内されています。Shopify Help Center(確認日:2025年3月8日)
Shopifyの GraphQL Admin API の LineItem には、商品ごとの詳細に使える custom attributes と properties があります。Shopify Developers: LineItem(確認日:2025年3月8日)。ただし、取得可能であることは、利用中のWMSアプリや3PL連携が自動で受け取ることを保証しません。連携仕様書または実データで、対象フィールドがマッピングされるかを確認します。
また、購入者が入力する情報を社内指示に転用する場合は、テーマ、チェックアウト、注文確認画面、通知メールでの表示範囲をテスト注文で確認してください。顧客向けに表示してよい情報と、社内だけで扱う作業指示を同じ項目に置かないことが原則です。
EC-CUBEでは商品側にショップ用メモを置けても、出荷側が受注明細の固定値を読むためには、注文確定処理でのコピー先が必要です。拡張や連携開発の要件書では、少なくとも以下を決めます。
決済未確定注文をいつ出荷指示の対象に含めるかは、決済方法と出荷フローによって変わります。「注文作成時」と「出荷対象化時」のどちらでスナップショットを作るかを、キャンセル・与信・予約販売の扱いと合わせて決めます。
連携対象を注文番号と配送先だけにすると、商品別指示や注文備考は連携成功でも落ち得ます。makeshop利用事業者へのインタビューには、注文備考が基幹連携に含まれないことや、決済と領収書希望の組み合わせを人手で確認していた例があります。これは一社の事例であり一般化はできませんが、連携済みでも例外確認が残り得る確認材料になります。makeshopマガジン(確認日:2025年3月8日)
連携台帳では、注文単位の成否に加え、出荷で必要な項目の照合結果を持たせます。
| 台帳項目 | 確認内容 |
|---|---|
| 注文番号・明細ID | カート、基幹、WMS/3PLで突合できる識別子 |
| スナップショット日時・版 | どの指示を確定したか |
| 商品別指示送信値 | 指示文、温度帯、同梱物コード、検品コード |
| 注文例外送信値 | 注文備考から採用した作業依頼 |
| 送信結果 | 送信日時、連携ID、再送回数、エラー本文 |
| 受領・照合結果 | 3PL側の受領値、差分有無、確認者 |
| 解決記録 | 対応内容、再通知日時、出荷可否 |
すべての自由記述を3PLに送る必要はありません。たとえば配送会社への要望、顧客対応中の問い合わせ、個人情報を含む記述は、作業に必要な範囲へ整理してから渡します。どの備考を「出荷指示として採用するか」を決めずに丸ごと転送すると、必要な指示が埋もれたり、不要な情報まで委託先に渡ったりします。
例外照合キューは、全注文を担当者が読むための一覧ではありません。通常処理から外れた注文だけを、理由付きで並べる一覧です。判定条件を固定し、担当者はキューに載った理由を解消します。
次のようなルールから開始すると、対象範囲を絞れます。
「注文備考に特定の単語がある」ルールは補助的に使います。表記ゆれがあり、注文備考には出荷不要の内容も含まれるためです。まず、購入者向け入力フォームで選択肢を設けられる依頼は構造化し、自由記述は人が採否を判断する扱いにします。
キューのSLAも決めます。たとえば、当日出荷締切の前に一次判定を完了する、3PLへ変更を再通知した注文は受領確認まで出荷確定にしない、といったルールです。ただし、3PLが受領確認データを返せない契約・方式なら、送信ログ、3PL側の帳票、メール等の代替証跡を台帳に紐付けます。
実装後に見るべきなのは、管理画面に項目が見えることではなく、最終的な作業者が正しい指示を読めることです。リリース前と、連携先の設定変更後にはテスト注文台帳を更新します。
| テストケース | カート側の期待値 | 3PL側で確認すること |
|---|---|---|
| 指示なしの通常商品 | 指示項目は空または既定値 | 通常出荷として処理される |
| 梱包注意がある商品 | 明細に固定された指示がある | 指示文またはコードが読める |
| 同梱物がある商品 | 同梱物コードが明細にある | ピッキング・梱包帳票に反映される |
| 複数商品・異なる指示 | 明細ごとの指示が混ざらない | 商品単位で判別できる |
| 注文備考あり | 採用した例外だけが出荷指示になる | 必要な例外が受領される |
| 商品マスタ更新後の未出荷注文 | 既存受注の指示は変わらない | 既存注文に旧指示、新規注文に新指示が届く |
| 受注後の指示変更 | 変更履歴と再送待ち状態が残る | 最新版の受領確認ができる |
| 連携エラー | 例外キューへ載る | 出荷に進めない、または代替手順が起動する |
テストには、実在する購入者情報や本番の委託先在庫を使わないようにします。また、3PL側がテスト注文を自動出荷しない設定か、取消手順があるかを事前に確認します。
一度にすべてを改修できない場合は、次の順で進めると、手戻りを抑えやすくなります。
標準機能だけで進められる範囲は、カートと連携アプリの仕様によります。商品メモの追加、注文確定時のコピー、外部連携の項目追加、変更履歴、受領値の自動照合は、設定ではなく開発が必要になることがあります。その場合でも、先に台帳と例外キューの項目を決めておけば、改修完了までの間は手作業の確認対象を限定できます。
重要なのは「備考を送る」こと自体ではなく、いつの、どの明細に、どの指示が適用され、委託先が受け取ったかを追える状態にすることです。これにより、商品情報の更新と成立済み受注の作業指示を混同せず、出荷工程の確認を例外に集中させられます。
記事では答えきれない個別の状況にもお応えします。