株式会社renue
コマースエージェント
コマースエージェントで、この記事のテーマを実務に落とし込めます
renueが社内で運用しているシステムをサービス化したものです。何ができるか、どう動くかをサービスページでご覧ください。
Shopifyとは：ストア構築・販売管理とプランの違い
Shopifyは、オンラインストアの作成と、商品・注文・在庫等の管理を行うクラウド型のコマース基盤です。テーマを使った画面づくり、決済や配送の設定、アプリによる拡張等を組み合わせます。ただし、必要な業務が追加費用なしで全部そろうわけではありません。販売する商品、対象の国・地域、運営体制と連携先を整理し、標準機能、追加アプリ、独自実装を分けて確認します。
Shopify公式の新規ストア向けチェックリストも、販売目的とチャネル、プラン、商品、決済・配送、公開前の検証を分けています。プランは売上規模だけで選ばず、スタッフの人数と権限、必要な販売方法、管理や連携の条件から比較します。商品ページを作れることと、日々の注文・問い合わせへ対応できることは別に確認する必要があります。
スタッフ・B2B・海外販売の条件を確かめる
主要なプランにはBasic、Grow、Advanced、Plusがあります。確認した公式案内では、追加スタッフはBasicにはなく、Growは5、Advancedは15、Plusは無制限という違いがあります。外部のコラボレーターやPOS専用の担当とは区分が異なるため、実際に誰がどの管理操作を行うかを確認します。上位プランだから社内のすべての権限を共通にしてよいという意味ではありません。
現在のB2B機能のプラン別案内では、Basic・Grow・Advanced・Plusが対象です。B2BはPlusだけと決め付けず、必要な機能で比較します。下位3プランでは新しいShopify Marketsがカタログ機能の条件で、有効なB2Bマーケットカタログは全体で最大3つです。Plusはカタログ数無制限、会社やロケーションへの直接割り当て等に対応します。会社別の価格、支払条件、注文方法を具体化して選びます。
海外販売では、表示する言語・通貨と、実際の決済、税・関税、配送、返品や問い合わせを分けて確認します。販売チャネルの条件も地域や商品・プランで異なります。「越境に強い」という評価だけから、すべての国へ同じ設定で販売できるとは判断しません。2026年10月25日に確認した公式情報を基に、まず自社の販売範囲と運営で必要なことをそろえます。事業と現場の優先順位を整理する際は、DX戦略と実行計画の考え方も参照できます。
Shopifyの料金と構築費用：契約条件と総費用を分ける
以下は2026年10月25日に確認した日本向け公式料金ページとPlusの公式案内の例です。年払いの月額換算と、毎月の支払い、Plusの契約年数を混同しないようにします。利用規約の料金の項目は、適用される税金が料金に含まれないと説明しています。契約時には請求通貨、支払周期、税と追加費用を確認してください。
| プラン | 確認した日本円の料金例 | 支払・適用条件 |
|---|---|---|
| Basic | 月額換算3,650円 | 年払い時。月払いは4,850円 |
| Grow | 月額換算10,100円 | 年払い時 |
| Advanced | 月額換算44,000円 | 年払い時 |
| Plus | 月額368,000円から／398,000円から | それぞれ3年契約／1年契約。標準的な設定・統合の例で、取引量等による変動料金の場合あり |
プラン料金のほか、決済、外部サービス、アプリ、テーマ、ドメイン、制作・移行、運用の費用を確認します。決済手数料は、プランや決済方法、カード等の条件で異なります。外部決済の事業者へ払う料金と、Shopify側で発生する手数料も分けて確認します。すべての決済方法を同じ率で計算したり、プランの月額だけを運営費としたりしないことが大切です。
構築の見積もりは、商品・機能・連携・引継ぎの範囲で比べる
制作費と期間は、画面数だけでは決まりません。商品データの整理、テーマの調整、必要な機能、既存ストアからの移行、在庫・受注等の連携、検証、運営担当の教育によって変わります。自作なら必ず数日、外注なら一律の金額といった相場表で確定せず、どこまでを社内で準備し、何を依頼するかをそろえて見積もります。
Shopifyの中国語のプラン解説も、サブスクリプション以外にテーマやアプリ、決済等を考える内容です。ただし、同ページの海外向け料金・提供条件を日本へ換算して使うことはできません。日本向けの現行案内と自社の契約を基準にします。立ち上げ時の支出、運営中の支出、社内の作業負担を分ける方法は、費用対効果と業務改善の評価でも整理しています。無料体験や初期の特典が終了した後の費用も確認しましょう。
ECサイト構築の進め方：公開前に注文から対応完了まで確認する
まず、販売する商品と対象顧客、販売地域、運営担当、必要な決済・配送と返品の方針を整理します。次に、プランとテーマ、商品ページの構成、ドメイン、必要なアプリや既存システムとの連携を検討します。機能を追加する前に、標準機能で対応できる範囲と、自社固有の業務ルールを分けます。追加するアプリごとに費用、管理するデータ、権限、更新・保守を確認する必要があります。
商品データには、名称、説明、画像、価格、バリエーション、在庫や配送に必要な項目をそろえます。旧ストアから移行する場合は、商品・顧客・注文等の移行対象、識別子と重複、移行中の更新、URLの扱いを決めます。入力できたことと、公開画面や検索・カートで正しく使われることを別に確認します。テーマの見た目だけで、注文後の業務まで整ったと判断しないようにします。
決済と配送は、対象地域の公式案内で確認する
日本のShopify ペイメントの決済方法は、対応するカードとApple Pay・Google Pay・Shop Pay等を案内しています。顧客の地域や通貨に条件がある方法もあります。たとえばJCBは日本円の取引という条件を確認します。日本のShopify ペイメントはオンライン販売向けで、対面のPOS決済とは別の条件です。日本語の管理画面があることを、すべての決済や配送の対応保証にはしません。
公開前は、公式のテスト方法と自社の環境・権限に沿って、購入の成功と失敗、取消・返金、出荷や部分出荷、通知、在庫の変化を確認する計画を立てます。決済が成功しても、出荷システムや担当者へ正しく渡らなければ、業務としては未完了です。テストと実取引、テスト用データと実顧客データを混同せず、確認対象と結果を記録します。送信や返金等の外部への作用も対象として扱います。
公開時には、商品や価格、送料、連絡先、各種ポリシー、スマートフォン表示、問い合わせ先と運営担当を最終確認します。公開後もエラー、注文・在庫の不一致、通知や問い合わせを確認します。テーマや連携プログラムを変更する場合は、検証した版と反映した版、設定と戻す条件を残します。独自の開発・配布が関わる部分は、CI/CDの検査・公開・復旧と合わせて設計できます。
SNSから販路を広げる場合は、EC基盤の構築に加えて、販売チャネルごとの審査・設定と受注後の対応を確認します。ソーシャルコマース・ライブコマースの導入と運用では、TikTok ShopとInstagramの購入経路、Shopify連携、配信・在庫・問い合わせの役割、購入率の分母と採算を分けて整理しています。
BtoBの窓口を設ける場合は、会社別の取引条件、売り手の受注確認、買い手社内の購買承認を分けて設計します。BtoBコマースのセルフサービス・見積と購買承認の確認点では、相談を残す取引やデータ連携の例外対応、AIに任せる範囲を整理しています。Shopifyの機能選定と合わせ、誰がどの条件を確認して注文を確定するかを検討してください。
ShopifyのAI・外部連携と、用途に合う支援サービス
ShopifyのSidekickの公式説明は、ストアのデータを使った支援と、適用前に変更を確認へ出す仕組みを案内しています。商品説明等の生成や作業の支援を使えることと、内容の正しさ、販売条件、顧客へ送ってよいかの判断は別です。生成した商品説明や画像を公開する前に、実際の商品・仕様との一致、根拠と表現、価格や提供条件を確認します。
AIを業務へ組み込む場合は、読み取るデータ、提案する範囲、変更できる対象、承認する担当を決めます。注文の変更や顧客への送信等は、案の生成と実行結果を分けて確認します。利用できる機能はストア等の条件によって異なり、自然言語で指示できることから、すべての操作や連携が無条件に実行できるとは判断しません。導入前の検証は、PoCの設計と本番移行も参考になります。
ストア構築・既存システム連携と、問い合わせ対応を分けて相談する
商品・受注・在庫等の既存業務との連携や、現場の要件整理から設計・実装・運用までを進める場合は、renueのFDE支援へ相談できます。対象のストア、既存システム、データ形式、APIや権限、利用件数、失敗・再実行と運営担当を整理し、利用基盤と必要な対応の範囲を確認します。今回の対象がストア全体の構築なのか、特定の連携・運用の改善なのかを明確にして進めます。
問い合わせフォームやメールからの取り込み、分類・リード台帳、返信下書きと履歴が課題なら、コマースエージェントが関連します。現在の公開案内ではShopify等の問い合わせ取り込みと、ラベル単位の許可に基づく返信を扱っています。初期は下書きと人の承認から始め、自動送信する範囲を運用上の判断と分けて決めます。サービス名から、商品・在庫・注文の全管理や広告運用まで一括で担うと推測しないようにします。
ECの問い合わせを営業担当へ引き継ぐ場合は、受付、回答の下書き、送信の承認、商談化の判断を分けて設計します。関連するAI SDRの機能比較・承認設計と導入評価では、文案の作成と実行、有効な相談と受注を区別し、CRM連携や人への引き継ぎを確認する方法を整理しています。
運営の改善では、売上だけでなく、商品閲覧から購入までの状況、粗利に関わる費用、返品・取消、問い合わせと対応時間を、同じ期間・対象で確認します。AIやアプリの導入だけで売上や利益が増えると保証せず、確認・修正や継続運用の負担も測ります。担当者が交代しても扱える手順と権限、異常時の連絡先を残し、変更した内容と結果を追える状態にしましょう。
