Shopify構築の流れ｜要件定義〜公開の全ステップ

要件定義・設計・構築・テスト・公開。言葉としては分かっても、自分の案件がいまどこにいるか、次に何を決めればいいかは別の話です。

進行で迷うことの多くは、フェーズ間の境目で起きます。この記事では、Shopify構築を5つのフェーズに分け、各フェーズで決めること、抜けやすい論点を整理します。公開までにかかる期間の目安と、自社・フリーランス・制作会社のどこで進めるかの判断材料も載せています。教科書通り順番には進まず、並行作業と後戻りが前提になる実態にも触れます。

つまずきやすい3つの落とし穴も先取りで載せているので、自分のプロジェクトを位置づけながら読み進められます。

1.全体像

1-1. 5つのフェーズで決まること

Shopify構築は、要件定義・設計・構築・テスト・公開の5つのフェーズで進みます。それぞれが違う役割を担っており、前のフェーズの結論が次のフェーズの入力になります。

各フェーズが「なぜ必要か」と「具体的に何を決めるか」を順に整理します。

ただし、この5つは順番に一列で進むわけではありません。完成の見本を詰めながら、商品データの構造を別ラインで進める、という進行は珍しくありません。逆に、構築フェーズに入ってから業務フローの抜けに気づいて要件定義に戻ることもあります。フェーズの境目で「ここまで決まったか」を確認することが、後戻りを最小化する助けになります。工程の数は減りません。ただし、どこまで自社で持つかは相手によって変わります。相談の段階で「今どのフェーズで、次に何を決めるのか」を言える会社なら、細かい進行管理は相手側に置けます。

1-2. 構築期間の目安

標準的な構築の場合、相談の開始から公開までで約3か月です。社内での決定や修正対応にかかる時間を見込むと、3〜4か月が現実的なラインになります。テーマの活用が中心で外部システム連携のない小規模な構築であれば、1.5〜2か月で公開できるケースもあります。

図の期間は、商品登録1000点まで、デザイン修正3回までを前提としたモデルケースです。商品数が増えれば登録作業が伸び、修正回数が増えればデザインフェーズが伸びます。

図の通り、フェーズは一部重なって進みます。デザインと実装を進めながら、外部システム連携や計測の設定を別ラインで進めるのが実際の進め方です。要件定義が全部終わってから次に進むわけではありません。

発注側で準備するもの

図で破線になっている工程は、制作を外部に任せる場合でも発注側の作業として残ります。着手が遅れると、そのまま公開日が後ろに動く部分です。

決済サービスの申込は、リードタイムが読みにくい項目です。Shopify Paymentsは管理画面から設定できますが、コンビニ決済や後払いのような国内向けの決済手段は外部の決済代行サービスとの契約が必要になります。審査期間は手段と事業者によって異なり、たとえばKOMOJU経由でPayPayを申請する場合、審査結果の通知は2〜3営業日とされています（KOMOJU公式ブログ／2026年9月時点）。公開日が決まっている場合は、要件定義の段階で申込時期まで決めておくと安全です。

なお、カスタマイズ開発を含む場合は、この期間から数週間〜数か月伸びます。既存のアプリでは要件を満たせず、独自の業務ロジックを組み込む場合が該当します。伸びる幅は要件の内容によって変わるため、一律の目安が出せない部分です。構築期間の目安をご相談ください。要件をお聞きしたうえで、公開希望日から逆算した進行をお出しします。

2.要件定義フェーズ

ECサイトはネット上のお店です。実店舗を新しく開くとき、「何を売るか」「どうお金を受け取るか」「商品をどう届けるか」を決めずに開店する人はいません。要件定義は、この開店前の決め事を一つずつ言葉にする段階です。

ただし、最初から全部を決める必要はありません。着手の段階で必要なのは、次の3つだけです。

この3つが分かれば、必要な機能とおおよその構築規模が見えます。残りの論点は、設計を進めながら順に埋めていく形で構いません。今の時点で答えが出ない項目があっても、読み進めて問題ありません。

2-1. 機能要件で決めること｜商品・決済・配送・顧客対応

要件定義で最初に決めるのが機能要件です。商品・決済・配送・顧客対応の4つを、一つずつ言葉にしていきます。

軸	決めること	公開時に必須か
商品	商品数、コレクションの分け方、バリエーションの組み合わせ	必須
決済	クレジットカード、コンビニ決済、後払いのどこまで対応するか	必須
配送	送料の条件（全国一律・地域別・重量別）、送料無料ライン、配送業者	必須
顧客対応	会員登録の有無、問い合わせ項目、返品交換ルール	一部は公開後でも可

ポイント制度や会員ランクのような顧客育成の仕組みは、公開後の運営を見ながら追加する形が一般的です。公開時点で必須なものと、後から足せるものを分けて考えると、構築期間を抑えられます。

2-2. 業務フローを想像する｜注文後に誰が何をするか

機能要件の次に詰めるのが、業務フローです。お客さまから注文が入ったあと、誰が・どのタイミングで・何をするか。この一連の動きを把握しておくことで、必要なアプリや人員体制が見えてきます。

主な流れは次の通りです。

注文数が少ないうちは、これらをすべて手作業で回せます。

一連の流れを把握しておくと「ここはアプリで自動化したほうがいい」「ここは人が見ないとダメ」といった判断ラインが整理されていきます。

2-3. 要件定義で抜けやすい論点｜会計・物流・カスタマーサポート

機能要件と業務フローを描いても、まだ抜けやすい領域が残ります。会計・物流・カスタマーサポートの3つです。後回しにすると、公開後に運営が詰まる原因になります。

要件が固まっていない段階でご相談ください ここまで読んで「決めることが多い」と感じた方は少なくないはずです。実際、Raboに届くご相談のほとんどは、要件が固まる前の段階から始まっています。 商品と売上規模の見込みだけ分かっていれば、必要な機能と抜けやすい論点はこちらで洗い出します。会計連携や物流体制の整理も、構築の設計と合わせて進める形でお手伝いします。

3.設計フェーズ

要件定義で「何が必要か」が固まったら、設計フェーズで「どう作るか」を詰めていきます。

3-1. ページ構成と見た目を決める

設計フェーズでまず取り組むのが、ページ構成とデザインの方向性です。どのページを用意し、どんな順番でお客さまに見せるか。ブランドの世界観をどう表現するか。サイトの骨格を決める作業です。

Shopifyの一般的なECサイトで必要なページは次のようなものです。

ページが決まったら、お客さまがトップから商品ページまでどう辿るか、回遊導線を設計します。

デザインの方向性は、テーマ選びと並行して決めます。Shopifyには無料・有料あわせて多数のテーマがあり、業種や雰囲気に合わせて選べます。テーマで賄える表現と、カスタムが必要な表現を切り分けることも、この段階で見えてきます。

日本のECでは、購入の多くがスマートフォンから発生します。PC画面で美しくても、スマホで操作しにくいサイトは購入に至りません。弊社では、デザインのイメージをスマホ画面から作り始めています。

3-2. 商品データを構造化する｜バリエーション・コレクション・属性

商品データの構造は、設計フェーズで一番慎重に決めるべき領域です。一度組んだ構造を後から大きく変えると、運用負担と修正コストの両方が膨らみます。

Shopifyでは、色やサイズのような区分の種類を「オプション」、その組み合わせ一つひとつを「バリエーション」と呼びます。

色(赤・青)とサイズ(S・M)を設定した場合、オプションは色とサイズの2つ、バリエーションは「赤のS」「赤のM」「青のS」「青のM」の4つです。在庫数や価格を持つのはバリエーションの側です。

設計で決めるのは、次の3つです。

バリエーション：要件定義で洗い出した「別々に在庫を数えたい区別」をどう組み合わせるか
コレクション：カテゴリに相当する仕組み。お客さまがどう探すかに合わせて分け方を決める
メタフィールド：素材・原産地・賞味期限など、標準の項目では持てない情報の追加

いずれにも上限があります。オプションは1商品につき3つまで、バリエーションは合計2,048通りまで、画像などのメディアは1商品につき250点までです(Shopify公式チェンジログ、Shopifyヘルプセンター／2026年9月時点)。

上限に収まるかの確認と、超える場合の実現方法は制作側で判断する範囲なので、発注側で決めるのは「何を別々に扱いたいか」までで足ります。

一点だけ、発注側で影響が出るのが命名です。オプション名やコレクション名の表記がブレていると、CSVでの一括登録のあとにまとめ直す作業が発生します。商品数が多い場合は、登録を始める前に命名ルールを決めておくと、後の作業量が大きく変わります。

3-3. 標準・アプリ・カスタム開発の振り分け

要件定義で挙げた機能を、

この振り分けを誤ると、構築フェーズで「実装できない」「コストが想定外に膨らむ」といった問題が出てきます

カスタム開発：既存のアプリでは要件を満たせない場合、独自の業務ロジックを組み込む場合

振り分け自体は制作側の作業ですが、費用に直結するため見積りの内訳として確認しておく価値があります。アプリは月額が積み上がり、カスタム開発は初期費用が一気に上がります。テーマ側で対応できる機能をアプリで足していないかも、見ておきたい点です。

4.構築・実装フェーズ

構築フェーズは、要件定義と設計で決めたものを、実際に動くサイトとして組み上げる段階です。作業の中心は制作側に移ります。

4-1. テーマカスタマイズ｜デザインを動く画面に

設計フェーズで作ったデザイン見本をもとに、Shopifyのテーマを編集して、ブランドに沿った画面に仕上げていきます。

有料テーマは買い切りで、Shopifyテーマストアでは1点あたり100〜500ドル程度が中心です(2026年9月時点。テーマストアの表示価格をご確認ください)。カスタマイズの深さは、管理画面上で色や配置を調整するレベルから、CSSやLiquidを編集してレイアウトを変えるレベル、テーマの構造を書き換えるレベルまで幅があります。細かく作り込むほど、工数とコストが上がります。

発注側で効いてくるのは、レビューの進め方です。「もう少し色を濃く」「ボタンの位置を変えたい」といった細かい修正が積み重なると、想定外の工数を生みます。レビュー回数の上限を事前に決めておく、フィードバックは溜めて一度に出すといった進め方で、期間を短く抑えられます。

4-2. アプリの組み込みと設定

選定したアプリを、実際に動く状態にするまでの工程です。アプリは入れただけでは機能せず、配送業者の選択や通知ルールなど、設定項目を一つひとつ埋めていく必要があります。

論点になるのは順序と干渉です。決済、出荷、マーケティングといった依存関係に沿って入れる必要があり、複数のアプリが同じ要素を取り合って動作が不安定になることもあります。ここは制作側で確認しながら進める範囲です。発注側で見ておきたいのは、月額費用が想定を超えて積み上がっていないかという点です。

4-3. 外部システム連携｜決済・物流・会計・計測

Shopify外のシステムとつなぐ作業が、外部連携です。ここがつながって初めて、お店としての運営が回ります。

決済：Shopify Paymentsに、コンビニ決済(KOMOJUなど)や後払い決済(Paidyなど)を組み合わせる
物流：出荷自動化アプリ(シッピーノ、OPENLOGI、ロジレスなど)を介して倉庫システムとつなぐ
会計：freeeやマネーフォワードに売上データを連携する
計測：GA4や広告媒体のタグを設置し、購入完了までのコンバージョン計測を組む

このうち計測は、公開後に広告を配信する予定がある場合に効いてきます。商品の分類やタグの付け方が、そのまま広告の配信対象の切り分けに使われるため、設計フェーズで決めた商品データの構造と揃えておく必要があります。

外部連携は、Shopify単体のテストでは見つからない不具合が出やすい領域です。連携先の仕様変更やデータ形式の食い違いなど、想定外の動きが出ることがあるため、連携後は本番に近い形でテストします。

次のテストフェーズで、本番運営に耐えるかを確認していきます。

5.テストフェーズ

テストフェーズは、要件定義で描いた業務フローと、構築で組み上げたサイトを突き合わせる段階です。実店舗で言えば、開店前のリハーサルに当たります。お客さまが入ってきて、商品を選び、会計をして、商品を持ち帰るまでの一連の動作を、実際に流して確認します。

5-1. 注文から出荷までの通しテスト

テストフェーズの中心が、注文から出荷までの通しテストです。お客さまが注文してから、商品が手元に届くまでの一連の流れを、本番に近い形で実際に流して確認します。

通しテストでは、次のような項目を順に確認します。

決済の動作確認には、Shopify Paymentsのテストモードが使えます。実際のお金を動かさずに挙動を確認できる機能です。KOMOJUやPaidyのような外部の決済サービスは対象外なので、各サービス側のテスト方法を別途確認します。最後に少額の実決済テストを行うと安全です。

このテストは、運用マニュアルの確認も兼ねます。手順通りに操作して迷う箇所がないかを見ておくと、公開後の運用が楽になります。

5-2. 画面と決済の動作確認｜表示崩れ・金額・税送料

見た目と金額計算が想定通りに動くかを、複数の環境で確認します。手元の環境だけで済ませると、公開後にトラブルが見つかります。

表示崩れ：PC・スマートフォン・タブレットの主要サイズと、Chrome・Safari・Edgeでの表示
決済手段ごとの動作：用意したすべての手段で実際に注文を入れ、画面遷移とメールまで確認
税・送料の計算：地域別送料、送料無料ライン、消費税を複数のパターンで確認
割引・クーポン：併用したときの計算結果と、適用の優先順位

確認の実務は制作側で進めます。発注側で決めるのは、どこまで直したら公開してよいかの基準です。軽微な表示崩れを公開後に回すか、直してから公開するかを事前に決めておくと、当日の判断が早くなります。

5-3. 表示速度のチェック

公開前に主要ページの速度を計測し、改善できる部分は最適化を済ませます。

計測には、Googleが提供するPageSpeed InsightsやLighthouseが使われます。ここで見るCore Web Vitals（LCP、CLS、INP）は、Googleがページエクスペリエンスの指標として公開しているものです。表示速度が購入率にどれだけ影響するかは商材や客層によって幅があるため、まず自社サイトの現状値を把握するところから始めます。

6.公開フェーズ

公開フェーズは、これまで準備してきたサイトを、独自ドメインで本番として動かし始める段階です。

表示速度に効くのは、

画像の重さ、アプリの数、テーマのコード品質、外部スクリプトの4つです。

改善は突き詰めればきりがないため、スコアを100点に近づけることに時間を使うより、お客さまの体感として「待たされない」レベルを確保するほうが現実的です。

6-1. 公開当日の作業｜独自ドメイン・DNS切り替え・動作確認

公開当日の作業は、独自ドメインの設定とDNSの切り替えが中心です。

DNSレコードをShopify側に向ける設定そのものは管理画面から進められますが、反映には数時間から最大48時間かかることがあります。既存サイトからの移行では、旧サイトを停止するタイミングとのズレで、お客さまから見てサイトが繋がらない瞬間が出ないよう調整します。切り替えの日時は、この2つを踏まえて決めます。

公開前後にチェックする主な項目は次の通りです。

公開直後に重大な問題が見つかった場合、一旦旧サイトに戻すか、応急処置で凌ぐかの判断が必要になります。事前に「こうなったら切り戻す」という基準を決めておくと、当日の判断がぶれません。

6-2. 運用フェーズへの引き継ぎ｜マニュアルと体制

公開はスタートラインで、ここから運用が始まります。運用が止まらず回るための体制とマニュアルを整えることまでが、構築プロジェクトの範囲です。

運用フェーズに入って必要になるのは、主に次の要素です。

運用マニュアルは、構築フェーズの後半から少しずつ作っておくと、公開時にスムーズに引き継げます。テストフェーズで動作確認をした手順が、そのままマニュアルの素材になります。

公開後によく出るのが、「商品の追加方法が分からない」「在庫の更新でミスが出る」といった運用面のつまずきです。マニュアルが整っていれば多くは防げますが、それでも不明点は出てきます。制作会社との保守契約や、運用サポートのアプリを活用するのも手です。

運用への引き継ぎが終われば、構築プロジェクトは完了です。ここから先は、実際の注文や問い合わせを通じて改善を重ねながら、ECサイトを運用していく段階です。

7.構築体制の選び方

社内にエンジニアを採用して内製するか、制作会社に外注するか。企業のShopify構築では、この2つが体制の選択肢になります。

どちらを選んでも、要件定義から公開までの流れは変わりません。大きく変わるのは、その工程を誰が担うか、そして構築で得た知識をどこに置くかです。

比較の観点	社内にエンジニアを採用して内製	制作会社に外注
着手までに必要なこと	採用と立ち上がりの期間が、構築の前に加わる	相談の時点で担当者が揃っている
費用の発生の仕方	人件費として毎月固定で発生する	構築時に集中し、公開後は保守の範囲で発生する
必要な社内知識	Shopifyの仕様、アプリ選定、国内の決済・物流の実務を社内に持つ	自社の業務を説明できれば進む
要件定義の進め方	自社の業務を一番知る立場で書ける。抜けやすい論点は自力で気づく必要がある	他社案件で見てきた論点を持ち込んでもらえる
公開後の改修	社内で即日着手できる	依頼と見積りの工程が入る
知識の残り方	社内に蓄積される	契約が終われば社外に出る

内製が効いてくるのは、公開後も継続してサイトを触る前提がある場合です。 ECが事業の中核にあり、商品の入れ替えやキャンペーンページの追加が月単位で発生するなら、改修のたびに外部へ依頼する工程が消えます。構築で得た知識も社内に残り、次の改修の速度が上がります。

逆に、1回作って大きく変えない想定であれば、採用にかけた費用を回収しにくい形になります。

見落とされやすいのが、既存のエンジニアに兼務させる場合です。基幹システムの保守やコーポレートサイトの管理と並行させると、構築期間中に必要な稼働を確保できず、公開日が後ろにずれます。内製を選ぶ判断は、人がいるかではなく、その人の稼働を構築に割けるかで決まります。

外注が向くのは、初めてのEC立ち上げで、公開日が先に決まっているケースです。会計ソフトや倉庫システムとの連携があり、公開後の集客まで含めて設計したい場合も、要件定義の段階から並走してもらう形が取れます。

判断の分かれ目は、公開までの作りやすさよりも、公開後にどれだけ手を入れ続けるかにあります。月に何回サイトを触ることになるかを見積もると、どちらに寄せるかが決まります。

体制を1つに決める必要もありません。構築は外部に任せ、公開後の運用と改修を社内で持つ分け方は、実際によく取られます。ただし担当を分けると、両者の間に業務が落ちる箇所が出てきます。

7-1. 契約が分かれると、調整は発注側に残る

体制を考えるときに見落とされやすいのが、契約を何本結ぶことになるかという点です。

構築をA社、広告運用をB社、SEOをC社に分けて発注すると、契約は3本になります。このとき、それぞれに要件を説明し、進行を突き合わせるのは発注側の仕事です。

問題が起きたときの切り分けも発注側に残ります。広告の成果が出ないとき、それが構築時のサイト設計に原因があるのか、広告の運用に原因があるのかは、双方に聞いても答えが出ないことがあります。どちらの担当範囲でもない領域が生まれるためです。

一社で一貫して担当できる場合、この調整が発生しません。窓口が1つになり、構築時点で決めた商品分類やタグの設計が、そのまま広告の配信設計に引き継がれます。

ただし、費用の合計が下がるとは限りません。減るのは発注側の調整工数と、責任範囲が曖昧になるリスクです。金額の比較だけでは見えない部分なので、見積りを並べるときは対応範囲の広さも一緒に見てください。

弊社の場合

Raboの対応範囲は、次の4点が特徴です

構築と広告運用を同じ体制で担当します

構築の設計段階から、公開後の広告配信で使う形に合わせて商品の分類やタグ、計測の設定を決めます。公開後に広告用の設計をやり直す工程が発生しません。

役割分担を提案時に明示します

ご提案の段階で、どの業務を弊社が担い、どこを貴社にお願いするかを一覧でお出しします。素材提供、商品情報の入力、法定表記、商品撮影、公開後の分析まで含めた表です。着手後に「これはどちらの担当か」で止まる状況を避けるためです。

各フェーズで判断いただく項目を事前に共有します

スケジュールには、期間だけでなく貴社に判断いただく項目を併記します。要件定義では対応範囲と優先順位、デザインフェーズでは確定稿、テストでは公開可否の判断基準です。判断が必要なタイミングが事前に分かるため、社内での調整を先回りして進められます。 Shopify Select Partnerとして、B2C・B2B・Shopify Plusのいずれの構築にも対応しています。

公開したい日から逆算して、進行をご提案します

「この時期に公開したい」という希望がある場合は、そこから逆算したスケジュールをお出しします。今の準備状況で間に合うか、どこを削れば間に合うかも含めてお伝えします。商品登録や決済の申込にどれくらい時間を見ておくべきかも、案件の規模に合わせてお示しします。

8.つまずきやすい2つのポイント

ここまで5つのフェーズを順に見てきました。最後に、フェーズ解説とは別の角度から、構築プロジェクトでつまずきやすい2つのパターンを取り上げます。事前に知っておくだけで、避けられる落とし穴です。

8-1. 曖昧な要件が構築フェーズの手戻りになる

要件定義で「必要かどうかわからないから後回し」と判断した機能が、構築フェーズに入ってから「やっぱり必要だった」と判明することがあります。このとき発生するのは、次の4つの作業です。

曖昧になりやすい論点は次のようなものです。

このリストのうち一つでも「まだ決めていない」ものがあれば、構築に入る前に言葉にする時間を取ります。

8-2. 運用設計の後回しリスク

運用設計とは、サイト公開後に日々の業務を回すための設計です。具体的には次のような要素が含まれます。

運用設計が後回しになる理由は、構築の作業に意識が集中するからです。サイトを作ることが目的化して、それを動かすことが視野から抜け落ちます。

運用設計は、構築フェーズと並行で進めます。構築の進捗に合わせて、「この機能の運用は誰がどう回すか」を一つずつ決めていきます。テストフェーズに入る頃には、運用マニュアルの骨格ができている状態が理想です。

「サイトを作る」と「サイトを運用する」は、別のプロジェクトです。両方を並行で進めることで、公開後の混乱を最小化できます。

9.よくある質問

9-1. 公開後の運用は自社だけで回せる？

商品追加、在庫更新、注文対応といった日々の作業は、管理画面の操作を覚えれば自社で回せます。運用マニュアルが整っていれば、EC運営の経験がない担当者でも引き継げる範囲です。

自社だけでは対応しにくいのは、アプリのアップデートに伴う不具合、テーマの改修、外部連携が止まったときの調査です。この3つが発生する頻度は低いものの、起きたときに売上が止まります。保守契約を結ぶか、対応できる相談先を確保しておくかの判断が必要になります。

9-2. 既存サイトからの移行はどう進める？

既存サイトからの移行は、構造分析・データ移行・SEO引き継ぎ・公開タイミングの4軸で計画します。

まず構造分析で、既存のURL、商品データ、会員情報、注文履歴を把握します。次に、何をShopifyに移行し、何を捨てるかを決めます。SEO評価を維持するために、旧URLから新URLへのリダイレクト設計も必要です。最後に、公開タイミングと旧サイトの停止タイミングを調整します。

会員情報のうちパスワードは移行できないため、移行後にお客さまへパスワードの再設定を案内する必要があります。この告知をいつ、どの文面で出すかも、公開タイミングと合わせて決めておきます。

9-3. 商品登録は構築と並行して進められる？

進められます。商品データの構造が固まった段階から、CSVでの登録作業を始められます。1000点規模の登録は数週間かかるため、構築の完了を待たずに着手するほうが、公開日を守りやすくなります。

並行して進める場合、商品名やコレクションの命名ルールを先に確定させておく必要があります。ルールが決まらないまま登録を始めると、後からCSVを作り直すことになります。

Shopify構築のご相談

Raboは、Shopify Select Partnerとして構築から運用支援、広告運用までを担っています。B2C・B2B・Shopify Plusのいずれの構築にも対応しています。

ご相談時にお持ちいただきたいのは、次の3点だけです。

要件定義の前の段階から、一緒に整理していきます。ご相談は無料です。