Shopify Plusの運用要件定義で考慮すべき例外シナリオ ― エンタープライズEC構築の現場から
ECサイトを構築するプロジェクトで見落とされがちなのが運用要件、より具体的に言えば「例外的シナリオ」の業務フロー設計です。通常の受注処理や商品登録の手順は入念に確認されていても、物流トラブルやお客様からのお問い合わせを起点に発生する例外ケースは、「いざ直面してから考える」となりがちです。
エンタープライズ規模のECでは、この問題の性質が変わります。中小規模なら「担当者が管理画面でその場対応」で済んでいた例外が、ERP・OMS・WMS・会計・CRMといった複数システムにまたがるデータ不整合として現れ、組織の権限・決裁・統制の問題として跳ね返ってくる。当社の経験では、リリース後に発生する問い合わせや障害対応の大半はハッピーパスではなく例外系に集中し、その処理コストが運用コストの構造を決めます。
本コラムは、当社がShopify Plusのエンタープライズ案件で実際に直面してきた例外シナリオの整理です。なお、前半の決済・物流・受注管理はプラットフォームを問わず通用する論点、後半のシステム間連携・自動化・統制がShopify Plusでの構築において特に差がつく領域です。
先に、優先順位の考え方
網羅リストは、優先順位の軸がなければ実務で使えません。当社は例外シナリオを2軸で仕分けることを勧めています。
- 高頻度・低影響（返品、受取拒否、住所変更依頼など）: 例外ではなく標準業務として設計する。担当・手順・処理時間目標を決め、問い合わせを待たずに処理が回る状態にする
- 低頻度・高影響（大量売り越し、決済プロバイダー障害、個人情報の削除依頼など）: 手順書（Runbook）と連絡網を用意し、初動の意思決定者を決めておく。年商数百億円規模では「低頻度」でも絶対数は月数十件になり得るため、頻度の見積もりは注文件数ベースで行う
要件定義の段階で全項目を精緻に設計する必要はありません。ただし「どちらの箱に入るか」の仕分けと、高影響側の初動体制だけは、リリース前に必ず決めておくべきです。
決済まわり
定番の論点です。各項目の詳細設計は実務者に委ねるとして、責任者としては「搭載する全決済手段 × 下記シナリオ」のマトリクスが要件定義の成果物に含まれているかを確認してください。
- 返金: 返金期限・月跨ぎ返金の仕様は決済プロバイダーごとに異なる。代引き・銀行振込・コンビニ払いなど自動返金できない手段の返金フロー（口座収集、手数料負担）。ギフトカード併用注文の部分返金順序
- 与信切れ: 与信保持期間（概ね7〜30日）を超える出荷遅延への対応。予約販売・受注生産では与信切れが恒常的に発生するため、販売形態と決済仕様の突き合わせは必須
- 審査落ち: 後払い決済の審査落ち時の注文処理
- 請求先住所: Shopifyの仕様上、既存注文の請求先住所は変更できない。領収書の宛先修正依頼への回答を決めておく
- 送料無料閾値割れ: 部分キャンセルで送料無料条件を下回った場合に送料を取り直すか
- ポイント: 返金時の残高マイナス、外部ポイント基盤との巻き戻し整合。「返品処理中の注文はポイント減算対象外」といった状態別ルールまで詰める
- インボイス制度: 適格請求書の発行体制（Shopify標準では不可）と、返金時の適格返還請求書
チャージバック・不正利用
ここは一段深く押さえておく価値があります。EMV 3-Dセキュア（国内ECでは2025年3月末までに実質義務化）を導入すると、認証を通過した決済のチャージバック責任は原則カード発行会社側に移ります（ライアビリティシフト）。ただし不正そのものがなくなるわけではありません。3Dセキュア導入後の設計論点は「残った不正への対応をどこまで仕組みで、どこから人でやるか」の線引きです。
- 仕組み側: Shopifyのリスク判定と連動した保留・自動キャンセル、外部の不正注文検知サービスの導入判断
- 人側: カスタマーサポートによるIPアドレス・住所実在性の確認、エビデンス提出（チャージバック反論は期限が短く、担当が決まっていないと間に合わない）
3Dセキュア義務化の詳細は別コラムにまとめています。
会計との突合
経理部門との調整は、EC構築で最も泥沼化しやすい領域のひとつです。最低限、次の3点は要件定義で確認してください。
- 入金と売上の照合: Shopify Paymentsの入金（payout）は手数料控除・返金相殺後の純額で入金される。総額で売上計上する会計と突合するには明細レベルの照合設計が必要
- 計上基準: 売上を受注基準・出荷基準のどちらで計上するか。Shopifyから会計システムへ渡すデータの切り出しタイミングがこれで決まる
- 赤伝処理: 締め後・月跨ぎの返金を会計上どう扱うか
物流まわり
こちらも定番リストは簡潔に。返品（返品不可ポリシーでも商品不良の返送は必ず発生する。返品先・検品基準・在庫の戻し方）、交換品発送（ゼロ円注文の作り方とOMS/WMSでの解釈）、長期不在戻り・再送、配送事故時の再送データ作成、長期休暇の与信と休暇明け出荷集中。受取拒否は当社の経験則で代引き注文の1%前後発生するため、「高頻度側」として標準業務化しておく類の例外です。
売り越しは「構造」から理解する
引当不可・売り越しは、対症療法ではなく発生構造から潰す必要があります。代表的な発生パターンは3つです。
- 決済手段の仕様: 外部リダイレクト型の決済手段（Shopify Payments以外の多く）は決済処理中に在庫チェックが挟まらず、残り1点への同時アクセスで売り越しうる
- 商品構成: セット商品や複数の販売商品が同一の出荷SKUを参照する構成で、引き合いが正しく合算されない
- 同期タイムラグ: WMS/ERPとの在庫連携間隔、実店舗・他モール・B2B（Shopify B2Bで同一在庫を引き当てる場合を含む）との食い合い
対策は、人気商品に実在庫より少ない数を引き当てるバッファ在庫運用、完売商品の再販操作の権限と手順の明確化など。実際に当社が関わった大型案件では、完売済み商品の販売設定を誤って再開してしまい百件超の売り越しが発生した事例がありますが、事前に「売り越し発生時のRunbook」があったため、発生検知から数時間で対象注文の特定・キャンセル・顧客告知まで完了し、以後は再販操作を権限で制限する再発防止に繋げています。この種の事故はゼロにはできない前提で、検知と初動の速さを設計しておくことが実害を決めます。
受注管理まわり
- リスク判定注文: リスク「高」は決済手段別に自動キャンセル/保留を設計、「中」は保留＋目視。保留中の注文がOMSへ自動連携されないことの確認は漏れやすい
- 転売・bot: 未払い前払い注文の自動キャンセル期限、購入数量制限、争奪戦になる商材での抽選販売の検討。配送先の海外転送サービスは「住所表記は普通の日本の住所」であることが多く、機械判別できない前提で運用ルールを作る
- 想定外の国の請求先住所: 外部チャネルやクイックチェックアウト経由で混入し、税・会計・連携に影響する
- 注文後の変更依頼: 出荷ステータスのどの段階まで応じるか。Shopifyの注文編集を使った場合に編集後のデータがOMS/WMS/出荷アプリで正しく再解釈されるかは必ず検証する。購入後にノベルティを追加する類の施策は、この相性問題が凝縮されるため実施前に連携経路全体で検証する
- 複数受注チャネルの並走: 電話注文や店舗など、EC以外のチャネルでは決済・与信の管理系統が別になる。キャンセル・返金の手順をチャネル横断で揃えるか、CS業務を分けるかの設計
システム間連携まわり
エンタープライズ案件では、例外の多くが「業務の例外」ではなく「システム連携の例外」として現れます。当社が要件定義で最も時間を割く領域です。
- Webhookの欠損・重複・順序: ShopifyのWebhookはat-least-once配信。欠損・重複・順序逆転が起こる前提で、突合（リコンシリエーション）バッチを設計し、「注文件数がShopifyとOMSで一致しているか」を誰がいつ確認するかまで決める
- 連携失敗のリカバリ: 一時的な通信エラーによる1件単位の連携失敗は日常的に起こる。リトライと、リトライで救えなかった場合の検知・手動リカバリ手順をセットで用意する。障害時にShopify側・連携基盤側・基幹側のどこで詰まったかを切り分けられる責任分界の定義
- 手動操作と自動連携の衝突: 管理画面での手動編集が連携データと衝突したとき、どちらをマスタとするか。データ項目ごとのマスタ系統定義がないと、現場の善意の手動修正が不整合の温床になる
- マスタ変更: SKUコード変更・廃番・統合時の過去注文・在庫・連携先への影響
- 縮退運転: WMS停止時に受注を止めるか出荷指示だけ溜めるか。決済プロバイダー障害時に該当手段のみ非表示にできるか。Shopify自体の障害時の顧客告知とエスカレーション
自動化の失敗系まで要件に含める
Shopify FlowはPlusでの運用自動化の中核ですが、自動化した例外処理そのものが新たな例外を生むことを織り込む必要があります。実例を挙げます。当社の案件で、リスク高判定の注文をFlowで自動キャンセルする運用をしていたところ、キャンセル自体は正常に動いたものの連携先の基幹システム側で在庫が戻らない不整合が見つかりました。検知後は手動で在庫を補正し、恒久対応として自動キャンセル時の在庫巻き戻しを連携仕様に組み込みましたが、教訓は明確です。
- 自動処理には必ず失敗・遅延したときの検知手段を対で定義する（Flow自体の障害・遅延も実際に起きる）
- リスク高判定のように本番でしか再現できない条件に依存する自動化は、テスト環境で完全には検証できない。「リリース後の初回発生時に結果を必ず確認する」を運用手順に含める
- 大型セールの瞬間的な注文集中時には、ワークフロー実行の遅延も想定する。Launchpadなどでセールを計画する際は、出荷キャパシティだけでなく自動化と連携がその流量に耐えるかを事前に確認する
アプリ・外部サービスのリスク管理
Shopifyの強みであるアプリエコシステムは、エンタープライズでは選定基準を持たないとリスク源になります。要件定義で決めておくべきは以下です。
- 選定基準: 要求する権限スコープの妥当性、ベンダーの事業継続性、個人情報の取り扱い（保存先リージョン、委託先扱いにするか）
- 障害時影響の格付け: そのアプリが停止したとき、チェックアウトが止まるのか、一部機能の劣化で済むのか。決済・チェックアウトに関与するアプリは特に慎重に
- 出口戦略: アプリにデータが溜まる構造（レビュー、ポイント、定期購買など）は、将来の乗り換え時のデータ移行可否を導入前に確認する
組織・統制まわり
システムで対応方法が用意されていても、「誰がやってよいか」が決まっていなければ現場は動けません。
- 権限設計: 返金・キャンセル・価格変更・完売商品の再販操作などの実行権限と、金額による決裁段階。退職・異動時のアカウント棚卸し
- 内部統制（IT統制）: 上場企業・IPO準備企業では、アクセス管理・変更管理の統制をSaaSであるShopify上でどう成立させるかが論点になる。標準の監査ログで追える操作は限定的なため、証跡が必要な操作（価格変更、返金など）は運用ルールと追加の記録手段で補う設計を初期に固める
- CSエスカレーション: 補償対応（送料負担、ポイント付与）の判断基準と決裁ライン。委託先CSの裁量範囲
- 個人情報の削除依頼: Shopify上の削除だけでなく、連携先のCRM・メール配信・データ基盤への削除の伝播まで含めた設計
- ハイパーケア: リリース直後1〜2ヶ月は例外が集中発生する。開発ベンダーの待機と判断者の即応体制を、運用要件として最初から予算化しておく
まとめ ― 例外シナリオへの向き合い方
長いリストになりましたが、要点は3つです。
1. 例外は「業務 × システム連携 × 組織」の交点で起こる。
売り越しひとつ取っても、原因は決済手段の仕様であり、在庫同期のタイムラグであり、再販操作の権限管理です。業務フロー図だけを眺めていても例外は洗い出せません。要件定義の場に、この3つを語れる人を揃えることが出発点です。
2. 例外を自動化で潰すと、自動化自体が新たな例外を生む。
自動キャンセルや自動タグ付けは有効ですが、その自動処理が失敗・遅延したときの検知と復旧まで対で定義して初めて要件と呼べます。事故をゼロにする設計より、検知と初動の速さを買う設計の方が、エンタープライズの実害を確実に減らします。
3. このリストは完成品ではなく、育てるもの。
発生のたびに「誰が・どのデータを・どの手順で直したか」を記録し、Runbookとして蓄積する仕組みをプロジェクトの成果物に含めてください。要件定義の時点で完璧な網羅を目指すより、リリース後に育て続ける前提の運用設計の方が、結果として強いECになります。
最後に。本コラムの内容は、構築を依頼するベンダーの見極めにも使えます。要件定義の席でここに挙げたような質問がベンダー側から出てくるか。出てこないなら、その見積もりに例外系の設計コストは含まれていないと考えたほうがよい、というのが多くの現場を見てきた当社の実感です。