この業務で整えたいこと
Shopifyを導入する目的は、見栄えのよいストアを公開することだけではありません。商品を登録し、注文を受け、在庫を確認し、発送し、お客様へ必要な連絡をする流れを、担当者が無理なく回せる状態にすることです。公開直後は注文数が少なくても、情報の持ち方や例外時の判断が曖昧だと、商品数や販売チャネルが増えたときに運用が崩れます。
この記事では、特定の商材や販売規模を前提にせず、最初に確認すべき作業と人の判断を整理します。Shopifyの機能、アプリ、料金、決済条件は変更されるため、設定時には必ず公式情報と管理画面を確認してください。
最初に決める4つのこと
| 観点 | 決める内容 | 例 |
|---|---|---|
| 商品 | 誰が商品情報と販売可否を更新するか | 商品担当がSKU・価格・公開状態を管理 |
| 注文 | どの状態を誰が確認するか | 未処理、保留、発送済みを毎日確認 |
| 在庫 | 販売可能数と入荷予定をどう扱うか | 在庫切れは非表示、予約商品は別ルール |
| 例外 | 自動化せず人が判断する条件 | 高額注文、住所不備、返品、決済エラー |
活用例：注文から発送まで
たとえば、注文が入ったら担当者に通知し、在庫と配送先を確認して発送する業務を考えます。注文を受けた時点で自動的に発送済みにするのではなく、在庫不足、配送先の確認、ギフト対応、決済上の確認が必要な注文を分けます。通常の注文は発送作業へ進め、例外は担当者が見つけられる一覧や通知に残します。
購入者には、注文確認、発送、遅延や返品など必要な連絡を適切なタイミングで行います。メールを増やすことが目的ではなく、購入者と社内担当者の双方が次に何をすべきか分かる状態にすることが重要です。
自動化の前に確認すること
- トリガーとなる注文・在庫・顧客情報は正しいか
- 条件に合わない注文をどこで人が確認するか
- 通知先、担当者、期限が明確か
- 在庫、決済、返品、個人情報に関する変更を自動完了にしていないか
- テストデータで想定どおりに動くことを確認したか
Shopify Flowはトリガー、条件、アクションを組み合わせて反復作業を扱えます。ただし、ワークフローが実行されたことと、業務が正しく完了したことは同じではありません。実行履歴、通知、在庫状態、注文状態を見て、例外の扱いを改善します。
運用を続けるための考え方
商品情報、注文、在庫、顧客情報を別々の担当者が扱う場合も、同じ注文番号・SKU・顧客情報を手がかりに確認できるようにします。スプレッドシートやチャットへ転記する場合も、どちらが正しい情報源なのかを決めます。更新担当が曖昧な二重管理は、在庫差異や発送漏れの原因になります。
月に一度は、問い合わせが多い商品、在庫切れ、発送遅延、返品、手作業で確認した注文を振り返ります。必要になった作業だけを標準化・自動化し、意味のない通知やタグを増やさないことが、長く使える運用につながります。
情報を一か所に寄せる
運用が複雑になる原因の一つは、商品情報が商品ページ、表計算、チャット、倉庫システムなどに分散し、どれが最新か分からなくなることです。Shopifyの管理画面で扱う商品、注文、顧客、在庫の情報と、外部の在庫システムや会計システムの役割を分けます。連携を始める前に、各項目の正しい情報源、更新担当、更新のタイミングを決めます。
たとえばSKUや商品名を複数の場所で編集すると、商品ページと出荷指示で異なる情報が表示される可能性があります。価格、販売可否、在庫数、配送条件、問い合わせ状況について、誰が何を更新するのかを決めておけば、差異が出たときに確認する場所も明確になります。連携ツールは情報源を増やすためではなく、決めた情報を必要な場所へ安全に渡すために使います。
商品マスタの「正本」を項目ごとに決める
商品情報を一つの表へ集めることと、正本を決めることは別です。Shopify、倉庫システム、会計、仕入先表、スプレッドシートには、それぞれ得意な役割があります。すべてを同時に編集できる状態にすると、更新の速さではなく差異の発見に時間を使うことになります。
まず、各項目について「最終的に誰が正しいと判断するか」を一つだけ決めます。連携先は正本のコピーまたは補助情報として扱い、差異を見つけたときは正本を確認してから修正します。
| 項目 | 正本の候補 | 更新責任者 | 連携先ではどう扱うか | 更新時の確認 |
|---|---|---|---|---|
| SKU | 商品マスタ | 商品運用担当 | 参照専用。連携先で採番しない | 重複、バリエーションとの対応 |
| 商品名・説明 | Shopifyまたは承認済み商品マスタ | 商品担当・編集担当 | 販売チャネル向けに表示を変える場合は版を分ける | 公開対象、表記、法令・権利 |
| 販売価格 | 価格管理表またはShopify | 価格決定者 | 連携先で自動上書きしない | 適用日時、税込・税抜、セール条件 |
| 在庫数 | 倉庫・在庫管理側、またはShopify | 在庫責任者 | 集計・通知用に複製する | 予約、引当、入荷予定、棚卸差異 |
| 重量・配送属性 | 商品マスタ | 物流担当 | 配送計算・出荷指示へ参照渡し | 梱包変更、配送不可条件 |
| 仕入・原価情報 | 限定アクセスの原価台帳 | 購買・管理者 | 商品ページや広い共有表へ渡さない | 閲覧権限、更新根拠 |
SKUは、同じ商品を見つけるための基準です。色・サイズのようなバリエーションごとに在庫や出荷判断が変わるなら、商品名ではなくSKUで追える状態にします。人が読める商品名は変更できますが、SKUを無計画に変えると、過去の注文、倉庫、広告、会計、外部連携の照合が難しくなります。
変更を「すぐ反映する情報」と「承認して反映する情報」に分ける
すべての更新を同じ速度で反映する必要はありません。在庫数のように日々変わる値と、商品名・配送属性・税務に関わる情報を同じ自動化で扱うと、誤更新の影響が大きくなります。
| 変更の種類 | 例 | 自動反映の可否 | 人が確認する地点 |
|---|---|---|---|
| 頻繁に変わる運用値 | 在庫数、入荷予定、販売停止フラグ | 条件とログがあれば候補 | 差異、負在庫、急増減 |
| 表示に影響する値 | 商品名、画像、説明、公開状態 | 下書き・候補作成まで | 表記、権利、購入者への影響 |
| 金額・契約に関わる値 | 価格、割引、税、送料条件 | 原則は承認後 | 適用日時、対象、戻し方 |
| 追跡用の補助情報 | 更新日時、担当、データ取得元 | 自動記録しやすい | 元データとの照合 |
たとえば、スプレッドシートで商品候補を整えた後にMakeやGASでShopifyへ渡す場合、最初は「差分一覧を作る」までに留めます。担当者がSKU、価格、公開状態を確認し、承認した行だけを反映対象にする方が、商品情報の誤上書きを防げます。
連携前に作る差分確認表
商品マスタを連携する前には、差分を処理する表を用意します。これは一時的な作業メモではなく、誰が何を確認したかを残す運用台帳です。
| 列 | 用途 | 例 |
|---|---|---|
sku |
商品を一意に照合するキー | TSHIRT-BLK-M |
source_updated_at |
正本側の更新時刻 | 2026-08-02 10:15 |
shopify_updated_at |
Shopify側の確認時刻 | 2026-08-02 09:55 |
changed_fields |
差異が出た項目 | price, weight |
proposed_value |
反映候補 | price: 3980 |
decision |
承認・差し戻し・保留 | 確認待ち |
reviewer |
判断した担当者 | 担当者名または役割 |
applied_at |
実際の反映時刻 | 空欄なら未反映 |
rollback_reference |
戻す値・参照先 | 変更前の版または履歴ID |
この表があれば、連携の失敗時に「どの商品が、どこまで更新されたか」を調べられます。個人情報や認証値を表へ入れず、必要な人だけが編集できる権限にしてください。
商品マスタ運用のチェックリスト
| タイミング | 確認内容 |
|---|---|
| 新商品登録前 | SKU規則、バリエーション、販売可否、配送属性、更新責任者が決まっているか |
| 連携開始前 | 項目ごとの正本、差分判定、停止条件、テストSKU、戻し方があるか |
| 価格・公開状態変更前 | 適用日時、対象SKU、承認者、購入者への影響を確認したか |
| 週次 | Shopify、在庫側、商品マスタの差異と未処理の確認待ちを見たか |
| 月次 | 不要な連携、過剰な権限、使われない項目、SKU規則の例外を見直したか |
購入者の体験から確認する
管理画面の設定が終わっていても、購入者が迷わず購入できるとは限りません。商品を探す、バリエーションを選ぶ、送料と到着目安を見る、決済する、注文確認を受け取る、配送状況を知る、問い合わせるという一連の流れを、実際に確認します。スマートフォン表示、在庫切れ、クーポン、住所の入力ミス、配送できない地域など、通常と異なる場面も確認対象です。
この確認はデザインのためだけではありません。問い合わせが発生しやすい箇所、受注後に人が確認しなければならない箇所、返金や返品の判断が必要な箇所を見つけるためです。購入者への案内と社内の手順がつながっていれば、注文量が増えたときも説明の食い違いを減らせます。
変更を安全に進める手順
テーマ、アプリ、配送設定、決済設定、Flowを一度に変えると、問題が起きた理由を特定しにくくなります。変更は目的ごとに分け、変更前の状態、変更内容、確認する注文や画面、戻す方法を記録します。まずテスト環境または限定的な条件で確認し、実行履歴や注文状態を見た上で広げます。
特に決済、在庫、注文キャンセル、返金、個人情報、外部公開に関わる操作は、便利だからという理由だけで自動化しません。自動化は、担当者が確認するべき仕事を消すものではなく、確認すべき注文を見つけやすくするために使います。例外を通知し、人が判断した結果を残す設計にすることで、運用の責任範囲を保てます。
外部サービスとつなぐ前の判断
メール、広告、会計、倉庫、CRM、表計算、チャットなどと連携すると、Shopifyの情報をより広く活用できます。一方で、連携先が増えるほど、データの重複、同期遅れ、権限の過剰付与、エラー時の見落としも起きやすくなります。最初は「どの業務で、誰が、何分困っているか」を確認し、解決したい一つの作業からつなぎます。
連携で渡す情報は必要最小限にします。注文番号、商品、数量、配送状態などで足りる場合に、氏名、住所、購入履歴すべてを送る必要はありません。連携後は、テスト注文を使ってデータが期待どおり届くか、失敗した場合に誰へ通知されるか、同じ注文が重複処理されないかを確認します。アプリの導入数を増やすことではなく、運用上の確認作業を減らし、例外を早く見つけることが目的です。
料金と運用負担を分けて考える
プランやアプリの月額料金だけで導入を判断すると、後から設定・教育・保守の負担が見えにくくなります。必要なスタッフアカウント、在庫ロケーション、販売チャネル、レポート、アプリ、外部連携、決済手数料などを、実際の業務と合わせて確認します。料金や提供条件は変わるため、導入時点で公式の料金・機能ページを確認してください。
小さく始める場合でも、誰が商品を追加し、誰が注文を確認し、休暇中は誰が対応するかを決めます。ツールの契約より先に運用の持ち主を決めることで、ストアが放置されることや、重要な通知が誰にも届かないことを防げます。費用対効果は、売上だけではなく、確認漏れ、問い合わせ、手作業、引き継ぎのしやすさも含めて判断します。
商品管理での進め方
色やサイズの表記、SKU、販売可否、説明文の更新担当を決め、商品情報を一貫して管理します。
ここでは、作業を一度に大きく変えないことが重要です。まず現状の手順と困る場面を確認し、次に変更後の確認条件を決めます。設定やFlowを有効にした後は、テスト注文やテストデータで実行結果を確認します。期待しない通知、更新、公開が起きた場合にすぐ停止できるよう、変更前の状態と戻し方も残します。
チームで共有するチェックリスト
| タイミング | 確認内容 | 担当の例 |
|---|---|---|
| 設定前 | 対象商品、注文、在庫、例外条件 | 運用担当 |
| 公開前 | 画面、決済、送料、メール、在庫 | ストア担当 |
| 自動化前 | トリガー、条件、通知先、停止条件 | 運用担当・管理者 |
| 定期確認 | 実行履歴、例外、問い合わせ、差異 | 担当チーム |
まとめ
Shopifyは、販売を始めるための画面ではなく、日々のコマース運用を整える基盤です。商品、注文、在庫、顧客、例外対応を小さな単位で確認し、必要な作業だけを自動化してください。
次に読む記事
公式情報
Shopifyを検討する
ストア開設や運用機能は、Shopify公式サイトで、最新の料金・機能・利用条件を確認してください。
公開後に見直すこと
公開したストアは、設定したら終わりではありません。最初の数件から十数件の注文を、担当者が実際の画面と通知を見ながら処理し、注文から発送、問い合わせ、返金までの流れを確認します。想定どおりに進まなかった場面は、操作の手順ではなく、どの情報が不足していたか、誰の判断が必要だったかを記録してください。
毎月または販売施策の切り替え時には、商品情報、在庫数、送料、決済、通知先、外部アプリの権限を見直します。売上だけを見るのではなく、問い合わせ件数、発送遅延、在庫差異、手作業で直した件数も確認すると、次に整えるべき業務が判断しやすくなります。