URUB
URUB
相談
URUB / ARTICLE / 商品別梱包指示・注文備考を出荷に渡し切る|受注確定時のスナッ
#受注処理#出荷管理#梱包指示#注文備考#3PL連携#例外処理

商品別梱包指示・注文備考を出荷に渡し切る|受注確定時のスナップショット、例外照合キュー、3PL連携台帳

2026-09-06
ON THIS PAGE
  1. 01まず分けるべき4種類の情報
  2. 02受注確定時に指示をスナップショット化する
  3. 03Shopify、EC-CUBE、連携基盤で確認する保存先
  4. 043PL連携は「送ったか」ではなく「項目ごとに一致したか」を管理する
  5. 05全件目視をやめるための例外照合キュー
  6. 06変更・障害時まで含めたテスト注文台帳
  7. 07導入時の優先順位と判断基準
  8. 08参考情報

まず分けるべき4種類の情報

出荷指示が連携で抜ける問題は、「備考」という一つの欄に性質の異なる情報を集めると起きやすくなります。設計の出発点は、情報を次の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_zoneinsert_code は連携・照合に使う値です。コード体系を増やしすぎると運用負荷が上がるため、出荷先で振り分けや帳票出力に使うものから始めます。

一方、商品ごとの指示が変更される場合もあります。たとえば、出荷前に破損対策を強化する必要が判明したケースです。このときは商品マスタを更新するだけでなく、影響する未出荷受注を抽出し、受注明細スナップショットを明示的に変更します。変更者、変更理由、変更前後の値、3PLへの再送結果を残してください。

Shopify、EC-CUBE、連携基盤で確認する保存先

カートごとに入力欄やデータモデルは異なります。機能名で判断せず、「誰が入力するか」「何の単位か」「外部連携で取得できるか」で選びます。

Shopify:注文単位と商品単位を取り違えない

Shopifyでは、注文全体への特別指示を記録する order notes、カート単位の追加情報である cart attributes、商品ごとの情報である line item properties が案内されています。Shopify Help Center(確認日:2025年3月8日)

  • 注文全体に対する購入者依頼は、order notes の対象として検討する
  • 商品ごとに購入者が選んだ加工内容などは、line item properties の対象として検討する
  • カート属性は、カート単位の追加情報として用途を明確にする
  • 社内専用の梱包指示は、購入者入力欄に依存せず、商品情報から受注明細向けに生成する

Shopifyの GraphQL Admin API の LineItem には、商品ごとの詳細に使える custom attributes と properties があります。Shopify Developers: LineItem(確認日:2025年3月8日)。ただし、取得可能であることは、利用中のWMSアプリや3PL連携が自動で受け取ることを保証しません。連携仕様書または実データで、対象フィールドがマッピングされるかを確認します。

また、購入者が入力する情報を社内指示に転用する場合は、テーマ、チェックアウト、注文確認画面、通知メールでの表示範囲をテスト注文で確認してください。顧客向けに表示してよい情報と、社内だけで扱う作業指示を同じ項目に置かないことが原則です。

EC-CUBE:ショップ用メモから受注明細へのコピーを要件化する

EC-CUBEでは商品側にショップ用メモを置けても、出荷側が受注明細の固定値を読むためには、注文確定処理でのコピー先が必要です。拡張や連携開発の要件書では、少なくとも以下を決めます。

  1. コピー元の項目名と対象商品種別
  2. コピーの実行契機(注文確定、決済確定など)
  3. 受注明細の保存先と管理画面での表示位置
  4. CSV、API、帳票の出力項目
  5. 商品マスタ更新時に過去受注を更新しない制御
  6. 例外的に受注明細を変更できる権限と履歴

決済未確定注文をいつ出荷指示の対象に含めるかは、決済方法と出荷フローによって変わります。「注文作成時」と「出荷対象化時」のどちらでスナップショットを作るかを、キャンセル・与信・予約販売の扱いと合わせて決めます。

3PL連携は「送ったか」ではなく「項目ごとに一致したか」を管理する

連携対象を注文番号と配送先だけにすると、商品別指示や注文備考は連携成功でも落ち得ます。makeshop利用事業者へのインタビューには、注文備考が基幹連携に含まれないことや、決済と領収書希望の組み合わせを人手で確認していた例があります。これは一社の事例であり一般化はできませんが、連携済みでも例外確認が残り得る確認材料になります。makeshopマガジン(確認日:2025年3月8日)

連携台帳では、注文単位の成否に加え、出荷で必要な項目の照合結果を持たせます。

台帳項目確認内容
注文番号・明細IDカート、基幹、WMS/3PLで突合できる識別子
スナップショット日時・版どの指示を確定したか
商品別指示送信値指示文、温度帯、同梱物コード、検品コード
注文例外送信値注文備考から採用した作業依頼
送信結果送信日時、連携ID、再送回数、エラー本文
受領・照合結果3PL側の受領値、差分有無、確認者
解決記録対応内容、再通知日時、出荷可否

すべての自由記述を3PLに送る必要はありません。たとえば配送会社への要望、顧客対応中の問い合わせ、個人情報を含む記述は、作業に必要な範囲へ整理してから渡します。どの備考を「出荷指示として採用するか」を決めずに丸ごと転送すると、必要な指示が埋もれたり、不要な情報まで委託先に渡ったりします。

全件目視をやめるための例外照合キュー

例外照合キューは、全注文を担当者が読むための一覧ではありません。通常処理から外れた注文だけを、理由付きで並べる一覧です。判定条件を固定し、担当者はキューに載った理由を解消します。

最初に設定する判定ルール

次のようなルールから開始すると、対象範囲を絞れます。

  • 商品マスタ上で出荷指示が必須なのに、受注明細スナップショットが空欄
  • 温度帯や同梱物コードが、同一注文内で両立しない組み合わせ
  • 注文備考に作業依頼があるが、3PL送信値が空欄
  • 受注明細のスナップショット変更後、3PLへの再送または受領確認が未完了
  • 3PL受領値と送信値が異なる
  • 指示が必要な商品なのに、連携先の項目長制限などで送信エラーになった

「注文備考に特定の単語がある」ルールは補助的に使います。表記ゆれがあり、注文備考には出荷不要の内容も含まれるためです。まず、購入者向け入力フォームで選択肢を設けられる依頼は構造化し、自由記述は人が採否を判断する扱いにします。

キューのSLAも決めます。たとえば、当日出荷締切の前に一次判定を完了する、3PLへ変更を再通知した注文は受領確認まで出荷確定にしない、といったルールです。ただし、3PLが受領確認データを返せない契約・方式なら、送信ログ、3PL側の帳票、メール等の代替証跡を台帳に紐付けます。

変更・障害時まで含めたテスト注文台帳

実装後に見るべきなのは、管理画面に項目が見えることではなく、最終的な作業者が正しい指示を読めることです。リリース前と、連携先の設定変更後にはテスト注文台帳を更新します。

テストケースカート側の期待値3PL側で確認すること
指示なしの通常商品指示項目は空または既定値通常出荷として処理される
梱包注意がある商品明細に固定された指示がある指示文またはコードが読める
同梱物がある商品同梱物コードが明細にあるピッキング・梱包帳票に反映される
複数商品・異なる指示明細ごとの指示が混ざらない商品単位で判別できる
注文備考あり採用した例外だけが出荷指示になる必要な例外が受領される
商品マスタ更新後の未出荷注文既存受注の指示は変わらない既存注文に旧指示、新規注文に新指示が届く
受注後の指示変更変更履歴と再送待ち状態が残る最新版の受領確認ができる
連携エラー例外キューへ載る出荷に進めない、または代替手順が起動する

テストには、実在する購入者情報や本番の委託先在庫を使わないようにします。また、3PL側がテスト注文を自動出荷しない設定か、取消手順があるかを事前に確認します。

導入時の優先順位と判断基準

一度にすべてを改修できない場合は、次の順で進めると、手戻りを抑えやすくなります。

  1. 出荷に必要な商品別指示と注文例外を棚卸しする
  2. 商品マスタ、注文、受注明細の責任範囲を決める
  3. 受注明細スナップショットと変更履歴を設計する
  4. WMS/3PLへ渡す項目と、送らない項目をマッピング表にする
  5. 欠損・矛盾・再送未完了を拾う例外照合キューを作る
  6. テスト注文で画面、データ、帳票、委託先受領まで通す

標準機能だけで進められる範囲は、カートと連携アプリの仕様によります。商品メモの追加、注文確定時のコピー、外部連携の項目追加、変更履歴、受領値の自動照合は、設定ではなく開発が必要になることがあります。その場合でも、先に台帳と例外キューの項目を決めておけば、改修完了までの間は手作業の確認対象を限定できます。

重要なのは「備考を送る」こと自体ではなく、いつの、どの明細に、どの指示が適用され、委託先が受け取ったかを追える状態にすることです。これにより、商品情報の更新と成立済み受注の作業指示を混同せず、出荷工程の確認を例外に集中させられます。

参考情報

FREE CONSULT

この課題、もっと詳しく相談したい方へ

記事では答えきれない個別の状況にもお応えします。

無料で相談する →
CONSULT/ 無料相談

Stuck?
Let's talk.

この記事を読んでも詰まったら、相談してみてください

記事では答えきれない個別の状況にもお応えします。まずはお気軽にどうぞ。

HOW IT WORKS

  1. 01
    フォームで送信
    お名前とご状況を簡単にお知らせください。
  2. 02
    担当者がご連絡
    1営業日以内に株式会社かいなよりご連絡します。
  3. 03
    無料でご相談
    まずは状況をヒアリングし、最適な方向性をご提案します。