ECサイト制作会社の選び方｜比較ポイント・費用・流れを初心者向けに解説

2026年2月17日

ECサイトを作ろうと思って制作会社を探し始めると、最初にぶつかるのがこの壁です。

「制作会社って結局、どこまでやってくれるの？運用や集客も頼めるの？」
「Shopifyや国産ASP、EC-CUBE…何を選べばいいのか分からない」
「費用相場が幅広すぎて不安。見積もりの“制作一式”って何が含まれてるの？」
「安い会社に頼んで、あとから追加費用が膨らむのが怖い」
「デザインは綺麗なのに売れない…ってよく聞くけど、何を見て選べばいい？」
「リニューアルでSEOが落ちたらどうしよう。移行は何に気をつけるべき？」
「相見積もりって何社が妥当？比較の仕方が分からない」

ECサイト制作は“作ること”そのものよりも、公開後に売上を伸ばし続けるための設計が重要です。ところが、制作会社の得意分野はさまざま。
デザインに強い会社もあれば、基幹連携や大規模開発に強い会社、楽天などモール運用に強い会社、集客・改善まで伴走できる会社もあります。目的に合わない相手を選んでしまうと、費用も期間も伸び、公開後の運用も回らなくなりがちです。

そこでこの記事では、初心者でも判断できるように、

依頼前に決めるべきこと（要件整理・RFPの作り方）
制作会社のタイプ別の選び方
失敗しない比較ポイント（チェックリスト）
見積もり・提案の読み方と費用相場
制作の流れ・期間と、公開後90日で成果につなげる考え方

を、できるだけ分かりやすく整理しました。
読み終えた頃には、「自社はどのタイプの制作会社を選ぶべきか」と、「見積もりをどう比較すれば良いか」がはっきりします。

【おすすめ制作会社↓】

プロにまるっとお任せ！ホームページ製作0円から！【サクペジ】
ECサイト制作が補助金活用で、最大75%OFF！【ホームページDX】
初めてのホームページ作成なら、ホームページ.com！初期費オール０円キャンペーン実施中
月額3,300円からのサブスク型ホームページ作成【H.A.S】
月額9,900円コスパ最強【99ホームページ】
SEO重視かつモバイルファーストのレスポンシブデザインでWebサイトの制作を行います。【aruku】
オンライン完結×ハイクオリティ！【ホームページ制作ならアドバン】

まず結論：あなたに合うECサイト制作会社タイプはこれ

とにかく早く小さく始めたい（最小構成・短納期）

向いている人

まずは“売れるか”を確かめたい（検証フェーズ）
商品点数が少ない／運用体制が小さい
「完璧なサイト」より「早く公開」を優先したい

合う制作会社タイプ（探し方のコツ）

スモールスタート特化（テンプレ構築＋最低限の導線設計）
運用前提の軽量設計が得意（更新しやすい、管理が簡単）
いわゆる“制作のみ”でもOK。ただし公開後の改善は自分で回す前提

ここだけは外すと失敗しやすいポイント

商品ページの型（写真・説明・FAQ・配送/返品）が決まっていない
決済・配送・返品が曖昧（後から直すとコスト増）
計測がない（GA4/タグ設計なし）→改善ができない

見積もり・提案で聞くべき質問（初心者向け）

「最短公開までに必須のページは何ですか？」
「公開後に自分で更新できるよう、管理画面と更新手順は残りますか？」
「計測（GA4等）はどこまで入りますか？」

費用・期間の目安（ざっくり）

期間：2〜8週間が多い（素材と要件が揃っているほど早い）
費用：数十万円（軽量）〜（デザイン作り込みや連携が増えると上振れ）

補足：プラットフォーム費用のイメージ（公式の料金体系例）

Shopify：月額制（プランにより月額が変動）
BASE：初期/月額0円から始められ、売上発生時に手数料がかかる体系
STORES：無料プラン・有料プランがあり、手数料率が変動する体系
※実際の金額・手数料は公式で必ず確認してください（出典は末尾）。

売上を伸ばしたい（集客・改善まで伴走）

向いている人

すでに広告・SNS・既存顧客がいて、伸ばすフェーズにいる
「作って終わり」ではなく、CVR/LTV改善が目的
商品点数が増え、運用が複雑になってきた

合う制作会社タイプ

グロース支援型（SEO/広告/CRM/分析→改善提案までセット）
改善の打ち手が多い会社（ABテスト、LP改善、導線改善、CRM施策）
事例で「見た目」だけでなく、数字の改善根拠を話せる会社

成果に直結しやすい“優先領域”

購入までの摩擦：カート離脱、送料表示、支払い手段、配送日
商品ページの説得力：比較軸、レビュー、保証、FAQ、写真
リピート導線：メール/LINE、同梱、定期導線、会員施策

見積もり・提案で聞くべき質問

「直近90日で、どの指標をどう改善しますか？（CVR/AOV/LTVなど）」
「月次の改善は誰が何をやりますか？（施策実行者が明確か）」
「分析はレポート提出だけですか？それとも実装まで含みますか？」

費用・期間の目安

構築：2〜4か月（要件と連携次第）
重要：月額（保守＋改善）が本体になりやすい
- “改善の工数”が契約に含まれるかで成果が変わります

ブランドを強くしたい（世界観・UI/UX重視）

向いている人

価格ではなく体験で選ばれたい（D2C、ギフト、プレミアム商材など）
SNS/店舗/イベントと連動したブランド一貫性が必要
写真・コピー・世界観に投資できる

合う制作会社タイプ

ブランディング×EC（体験設計ができる）
情報設計が強いデザイン会社（見た目だけでなく、導線が上手い）
クリエイティブ制作（撮影・コピー）まで扱えると相性が良い

落とし穴（初心者が陥りやすい）

デザインは良いのに、買いづらい（導線・検索・絞り込みが弱い）
世界観優先で表示が重い（速度低下→CVR悪化）
運用で崩れる（更新するとデザインが壊れる）→運用ルールが必須

提案で確認したいこと

「UIの判断基準は何ですか？（世界観×売りやすさの両立方針）」
「テンプレ化して、運用しても崩れない設計ですか？」
「速度（表示パフォーマンス）をどう担保しますか？」

基幹連携が必須（在庫・受注・会計・物流）

向いている人

在庫・受注・会計・倉庫がすでに回っていて、ECだけが孤立している
手作業が増えてミスが出ている（受注転記、在庫ズレなど）
将来的に商品点数や拠点が増える

合う制作会社タイプ

システム連携に強い開発会社（API・バッチ・権限設計に慣れている）
要件定義が丁寧（現場フローを図にして詰めてくれる）
障害時の切り分け・保守体制が明確

最初にやるべき整理（ここが曖昧だと炎上しがち）

“正”のデータはどこか（在庫/商品マスタ/顧客/受注）
連携の方向（片道か双方向か）
エラー時の運用（誰が、どこを見て、どう戻すか）

提案で必ず確認

「連携はどの方式？（API/CSV/中間DB 等）運用は？」
「例外処理（欠品・分納・返品・キャンセル）はどう設計？」
「保守の範囲（障害対応・監視・改修スピード）は？」

モール中心（楽天・Yahoo・Amazonの運用/制作）

向いている人

自社ECより先に、モールで売上を作りたい
モール内の施策（検索対策、広告、クーポン、セール運用）が重要
商品点数が多く、運用が重い

合う制作会社タイプ

モール運用に強い制作会社/コンサル（制作＋運用がセット）
画像制作やページ制作だけでなく、商品設計・販促設計まで見られる

重要ポイント

モールは“サイトを綺麗にする”より、
露出（検索・広告）→転換（ページ）→再購入（施策）の設計が大事

提案で確認

「モール内でのKPIは？（露出/CTR/CVR/レビュー等）どこから伸ばす？」
「更新頻度が高い前提で、運用体制と制作スピードは？」
「制作物の納品だけでなく、施策の実行まで含む？」

越境EC（多言語・海外決済・配送）

向いている人

海外需要が見込める（訪日客の反応が良い、海外から問い合わせがある）
物流・関税・返品の壁を越えたい
価格表示や通貨、規約など“海外向けの整備”が必要

合う制作会社タイプ

越境の実務経験がある会社（決済・配送・税/関税の勘所を知っている）
多言語対応が「翻訳だけ」で終わらず、現地購買行動に合わせた設計ができる

提案で確認

「言語追加だけでなく、通貨・税・配送・返品まで設計に入っていますか？」
「不正注文対策（チャージバック等）はどうしますか？」
「現地マーケ（広告/SEO/インフルエンサー等）は誰が担いますか？」

BtoB EC（見積・掛け払い・取引先別価格）

向いている人

取引先ごとに価格・掛け率・請求締めが違う
見積→承認→発注の流れが必要
営業と連動した受注が多い

合う制作会社タイプ

BtoBの業務フローに強い会社（権限・承認・請求が理解できる）
CRM/基幹（受注・会計）連携を前提に設計できる会社

提案で確認

「取引先別価格、見積、掛け払い、承認フローは標準でできる？カスタム？」
「営業が使う管理画面はどうなる？（現場が回る設計か）」
「取引先の権限・閲覧制限（商品/価格/在庫）はどう担保？」

サブスクEC（定期課金・LTV設計）

向いている人

継続購入のほうが利益が出る（消耗品、食品、コスメ等）
解約率（チャーン）を下げたい
初回獲得から継続までのシナリオが必要

合う制作会社タイプ

サブスクのKPI設計ができる会社（継続率、回数別LTV、同梱施策など）
CRM（メール/LINE）や同梱物、アップセルの改善まで見られる会社

提案で確認

「初回→2回目→3回目の“壁”をどう越える設計ですか？」
「解約理由の取得と、改善の回し方は？」
「定期の変更（スキップ/周期/同梱）など運用要件に対応できますか？」

ECサイト制作会社とは？依頼できる範囲と「できないこと」

ECサイト制作会社は一言でいうと、「ECの設計・制作・公開（そして契約次第で運用改善まで）」を支援する外部パートナーです。
ただし、ECは「サイトを作れば売れる」ものではなく、公開後の運用が本番になりやすい点が重要です。

初心者が失敗しやすいのは、ここです👇

「制作会社＝なんでもやってくれる」と思い込む
逆に「制作だけ頼めばOK」と思い込む
結果、やるべきことの抜けが出て、公開後に詰む

そこでこの章では、依頼できる範囲と、できない／別途になりがちな範囲を、分かりやすく整理します。

制作だけの会社／運用・改善まで支援する会社の違い

両者の違いは、ざっくり 「ゴールが納品か、成果か」 です。

スクロールできます

項目	制作中心（納品型）	運用・改善（伴走型）
ゴール	公開して納品	売上・CVR・LTVなど改善
契約	一括（プロジェクト型）が多い	月額（保守＋改善）が多い
得意領域	実装・デザイン・構築	分析→施策→実装→検証
向いている状況	まず作る／刷新する	伸ばす／勝ち筋を作る

初心者におすすめの考え方

まだ売れるか不明 → まずは制作中心でもOK（ただし計測は必須）
既に広告や集客を回している → 伴走型が成果につながりやすい
どちらでも、最初に「公開後、誰が何をするか」を決めるのが最重要です

✅チェック（見積もり前に決めるとブレない）

公開後の更新：誰がやる？（自社／制作会社／運用代行）
集客・改善：どこまで必要？（SEO・広告・CRM・ABテスト）
数字の責任：レポートだけ？実装まで？KPIまで？

ECサイト制作で発生する主な業務（企画〜運用）

EC制作は「デザインして作る」だけではなく、実際は複数工程の連続です。
特にECは、決済・配送・返品・個人情報など“運営の現実”が絡むため、工程ごとの確認が欠かせません。

要件定義・情報設計（導線/カテゴリ/検索）

ここが弱いと、後工程でお金も時間も溶けます。
要件定義は、「何を、どこまで、どう作るか」を合意する工程です。

主に決めること（例）

目的・KPI：売上／CVR／LTV／リピート率など
販売要件：商品点数、バリエーション、定期、クーポン、会員ランク
導線設計：トップ→カテゴリ→商品→カートの“迷わない道”
検索・絞り込み：条件（価格・サイズ・色・用途など）の優先順位
運用設計：誰が更新し、どこを触るか（属人化を防ぐ）

初心者あるあるの落とし穴

「機能は後で考えます」→ だいたい追加費用が増えます
「カテゴリはとりあえず」→ SEOも導線も後から直すと重いです

デザイン（ブランド/LP/商品ページ）

ECのデザインは“おしゃれ”より、買いやすさが基準です。

見た目以外に重要なこと

商品ページの型：写真／特徴／比較／レビュー／FAQ／配送・返品
購入の安心材料：問い合わせ導線、会社情報、決済の明確さ
スマホ最適化：ECはスマホの離脱対策が成果に直結しやすい

ポイント

「世界観」は大事ですが、速度・読みやすさ・迷わなさを犠牲にすると売上が落ちやすいです。

開発（フロント/バック/連携）

ここは制作会社の“地力”が出ます。
特に差が出るのは 「連携」と「例外処理」 です。

例：連携・実務で揉めやすいところ

在庫：どれが正？（EC？倉庫？基幹？）
受注：キャンセル、分納、返品はどう戻す？
会計：売上計上のタイミング、手数料、送料の扱い
物流：出荷ステータス、追跡番号、配送会社の条件分岐

初心者向けの確認質問

「この仕様は標準機能でできますか？それともカスタムですか？」
「障害が起きたら、誰がどこを見て切り分ける設計ですか？」

運用（更新・分析・改善・キャンペーン）

ECの運用は、制作の延長ではなく “継続改善の仕事” です。

運用でやること（代表例）

更新：バナー、特集、ランキング、在庫変動、価格、商品追加
分析：アクセス、離脱、CVR、広告、購入導線、検索ワード
改善：LP改善、商品ページ改善、カテゴリ改善、導線改善
販促：セール、クーポン、同梱、メール/LINE、リピート施策

ここで重要なのは
「レポート提出」だけで終わらず、改善を実装して検証できるかです。
（契約範囲が曖昧だと、ここが止まりがちです）

見落とされやすい“周辺タスク”（撮影・原稿・商品登録・CS・物流）

初心者が最も抜けやすいのが、ここです。
制作会社に頼んでも、自社側の準備が必要な項目が多いからです。

よくある“抜け”チェックリスト ✅

📸 撮影：商品写真、使用シーン、サイズ感、動画
✍️ 原稿：商品説明、FAQ、比較、特商法、プライバシー
🧾 商品登録：SKU、バリエーション、カテゴリ、タグ、検索用属性
📦 物流：送料ルール、配送日、同梱、ギフト、返品フロー
💬 CS（顧客対応）：問い合わせ窓口、テンプレ、返品対応、レビュー対応
🧩 ツール連携：決済、配送アプリ、メール/LINE、レビュー、分析ツール

「できないこと」になりやすい代表例（契約外になりやすい）

撮影・コピー制作を“丸ごと”やってくれるとは限らない
商品登録（大量）の代行は別料金になりやすい
CS運用（問い合わせ対応）は通常は自社運用（代行は別サービス）
物流の現場改善（倉庫・梱包・オペ設計）は領域が分かれやすい

💡おすすめの整理方法（初心者でも迷いにくい）

制作会社がやる：設計、デザイン、実装、公開、（契約次第で改善）
自社がやる：商品・運用の中身（撮影/原稿/登録/CS/物流）
協力して決める：要件、優先順位、KPI、運用フロー

この3つに分けて「誰が・いつまでに・何をやるか」を表にすると、公開後がめちゃくちゃ楽になります。

制作会社探しの前に決めるべきこと（ここが曖昧だと失敗する）

制作会社選びで失敗する原因の多くは、会社の良し悪し以前に 「発注側の前提が曖昧」 なことです。
ここを先に固めるだけで、提案の質・見積もりの精度・公開後の成果が一気に変わります。

目的とKPI（売上／CVR／LTV／リピート／粗利）

最初に決めるべきは、“サイトの完成”ではなく“事業の勝ち方”です。
目的が違うと、最適な構成・導線・制作会社タイプが変わります。

よくある目的の例

新規獲得を増やす（広告・SEO・SNSからの流入を伸ばす）
購入率を上げる（CVR改善：商品ページ・導線・決済）
平均注文額を上げる（セット提案・アップセル）
継続購入を増やす（LTV改善：CRM・定期・同梱）
粗利を守る（割引依存を避ける、送料設計・原価設計）

初心者向けの“決め方”

まずはKPIを 1つだけ“最優先” にする（他はサブKPI）
“数字が動かせる場所”まで落とす（例：CVR → カート離脱率、商品ページ到達率など）

KPIツリー（例）

売上＝流入 × CVR × 平均注文額
さらにLTVを重視するなら：LTV ＝平均注文額 × 購入回数（継続率）

💡ポイント
「公開後に何を改善するか」まで決めると、提案が“見た目”から“成果”に寄ります。
（計測設計＝GA4等のイベント設計も、この時点で要件に入れるとブレません）

販売形態（D2C／卸・BtoB／モール併用）

販売形態は、ECの仕様に直結します。ここが曖昧だと、提案の前提がズレます。

D2C（自社直販）で決めること

ブランド体験の優先度（世界観 vs 買いやすさ）
リピート導線（メール/LINE、同梱、会員施策）
レビュー・UGCの扱い（表示ルール、運用ルール）

卸・BtoBで決めること

取引先別価格、掛け払い、見積・承認フロー
営業とECの役割分担（営業が使う管理画面が要るか）
受注の例外（分納・欠品・返品・請求締め）

モール併用で決めること

“どこで勝つか”（モール＝集客、自社＝LTV など）
商品・価格・在庫の整合（どれを正にするか）
ブランド毀損を避けるルール（価格・販促の統一）

✅ここを1行で言えると強い

「最初の主戦場は〇〇で、〇〇を伸ばし、最終的に〇〇に繋げたい」

商品点数・カテゴリ設計・更新頻度

ECは「商品数 × 更新頻度」で運用難易度が変わります。
制作会社はここを前提に、設計（カテゴリ/検索）と運用導線（更新のしやすさ）を組みます。

整理する項目（最低限）

商品点数：SKU数／バリエーション（色・サイズ等）の有無
カテゴリ：今ある分類／将来増える分類
検索・絞り込み：ユーザーが選びたい軸（価格・用途・サイズ・素材など）
更新頻度：新商品、季節商品、キャンペーン、在庫変動の頻度

初心者がやりがちな失敗

カテゴリを“社内都合”で作る → ユーザーが迷う
絞り込みが弱い → 商品点数が増えるほど探せなくなる
更新手順が複雑 → 更新が止まり、サイトが古く見える

💡コツ
カテゴリは「商品名」ではなく、買うときの判断軸から設計すると強いです。
例：用途／悩み／シーン／比較軸（価格帯・サイズなど）

必須要件 / あったら嬉しい要件（優先順位つき）

要件は“全部欲しい”になりがちですが、そうすると見積もりも納期もブレます。
おすすめは 優先順位をルール化して、提案を比較可能にすることです。

おすすめの分類（MoSCoW方式）

Must：これがないと運用できない（必須）
Should：できれば入れたい（重要）
Could：余裕があれば（あったら嬉しい）
Won’t：今回はやらない（スコープ外）

要件の例（ECでありがち）

Must：決済・配送・返品ポリシー、スマホ最適化、基本SEO、計測
Should：レビュー、クーポン、会員機能、レコメンド
Could：診断コンテンツ、ライブコマース連携、多言語
Won’t：フルスクラッチ開発（今回は不要）など

✅さらに強くする“ひと工夫”
各Must要件に 「合格ライン（受け入れ条件）」 を1行で書く。
例：

「購入完了までの主要導線でエラーが出ない」
「商品登録を社内で完結できる」
「主要ページの表示が重くならない設計にする」など

予算レンジ（初期・月額・施策費の上限）

予算は「いくらまで」だけでなく、何に、どの範囲まで含めるかを決めないと比較できません。

最低限、分けて考える（TCOの発想）

スクロールできます

区分	代表例	盲点になりやすい点
初期（構築費）	要件定義、デザイン、開発、移行、テスト	“後から必要”が出ると増えやすい
月額（維持費）	保守、サーバー/アプリ、軽微改修	保守だけで“改善”が含まれないことがある
施策費（伸ばす費用）	広告、SEO、CRM、撮影、LP改善	ここがないと“作って終わり”になる

初心者向けの決め方

予算は「レンジ＋上限＋追加条件」をセットで決める
- 上限：これ以上は社内稟議が必要
- 追加条件：追加費用が出る条件（仕様変更、商品数増、連携追加など）
“改善を回すなら”、月額の中身を必ず明文化する
- レポートだけ？改善提案まで？実装まで？どこまで含む？

公開希望日（繁忙期・キャンペーン・新商品）

納期は「制作会社の作業」だけでは決まりません。
実際は 素材（写真・原稿）と要件の確定スピードがボトルネックになりがちです。

逆算の考え方（初心者でも崩れない）

公開日（固定）
↓
テスト期間（決済・配送・メール・在庫など）
↓
実装・デザイン
↓
要件定義（ここが遅れると全部ズレる）
↓
素材準備（写真・原稿・規約・商品情報）

✅公開日が絶対の場合のコツ

“全部入り”ではなく、段階公開を前提にする
- まず必須ページで公開 → その後に特集・コンテンツ・改善を追加
大型施策（セール・新商品）は、公開直後よりも 安定後に置くほうが安全

現行サイトからの移行（URL・会員・ポイント・SEO資産）

リニューアル／カート移行で一番怖いのは、「引き継ぎ漏れ」です。
特にSEOは、やるべきことを漏らすとアクセスが落ちやすいので、最初から要件に入れておくのが安全です。

移行で整理すべき“資産”

URL構造（旧URL → 新URLの対応表）
コンテンツ（商品・カテゴリ・ブログ・特集）
会員情報（顧客データ、会員ランク、ポイント、購入履歴）
計測（GA4/タグ、広告計測、コンバージョン定義）
外部連携（配送、決済、レビュー、CRMなど）

SEOの基本チェック（初心者向け）

旧URLから新URLへ、恒久的なリダイレクト（301/308）を用意する
URL対応表は「漏れなく」作る（重要ページほど優先）
サイトマップ、内部リンク、正規URL（canonical）なども移行前提で確認
ドメイン移転がある場合は、Search Consoleの手順も含めて進める

ECでよく詰まるデータ移行（現実的な話）

“全部そのまま”は難しいケースがある（仕様差、データ形式差）
そのため、移行方針は最初に決めるのが重要です
- 例：商品データはCSVで移す／顧客は移すが購入履歴は要相談など

💡結論
移行案件は「制作」ではなく、移行プロジェクトです。
制作会社に依頼する場合も、発注側が「何を引き継ぐか」を先に決めるほど成功します。

プラットフォーム選定｜制作会社の“得意/不得意”が分かれる分岐点

ECサイト制作は「良い制作会社を探す」より先に、土台となるプラットフォーム選びで勝負がほぼ決まります。なぜなら、プラットフォームごとに

できること／できないこと
カスタマイズのしやすさ
保守・セキュリティの責任範囲
外部連携の難易度
が変わり、制作会社の得意領域も分かれるからです。

初心者でもブレない判断軸は、次の3つです。

スピード：早く出して検証したいか
拡張性：独自要件・連携・業務に合わせたいか
運用体制：自社で回すのか、伴走が必要か

クラウド/ASP（例：Shopify系・国産ASP系）の向き不向き

クラウド/ASPは、ざっくり言うと 「機能がすでに用意されていて、月額で使う」 方式です。制作は“組み立て”に近く、早い・安全・運用しやすいのが強みです。

向いているケース

まずは最短で公開したい（スモールスタート）
標準機能＋アプリ/拡張で十分（一般的なD2C、ギフト、定期など）
保守・アップデートを自分で抱えたくない
セキュリティや決済まわりを「平台側の責任範囲」に寄せたい

向かないケース（苦労しやすい）

独自の業務フローが強い（BtoBの特殊要件、複雑な承認、特殊な価格体系など）
基幹連携が複雑で、標準連携では足りない
“アプリ増し増し”になって運用が重くなる未来が見える

制作会社選びで差が出るポイント

Shopifyなら「テーマ構築」だけでなく、チェックアウト周辺・速度・運用設計まで見られる会社が強い
国産ASPなら、そのASPの作法（テンプレ・制約・拡張方法）を熟知している会社が強い
“見た目”より、運用者が毎日触る管理のしやすさを設計できる会社が当たり

初心者向け：見積もり前に確認する質問

「標準でできること／追加（アプリ・オプション）になることを線引きして説明できますか？」
「アプリやオプションを増やした場合の、月額・運用負荷の見立ては？」
「スピード対策（表示速度・画像最適化）は提案に含まれますか？」

費用イメージ（公式に“最低料金”が明示されやすい）

Shopify、makeshop、futureshop等は、公式ページで月額・初期費用の目安が提示されています（最新は必ず公式で確認）。
※「制作費（構築費）」は別途見積もりになるのが一般的です。

オープンソース（例：EC-CUBE系）の向き不向き

オープンソースは 「土台のソフトを自分で用意し、必要に応じて自由に改造できる」 方式です。強みは自由度ですが、裏返すと 保守・セキュリティ・品質責任が重くなる傾向があります。

向いているケース

既存業務に合わせた“独自要件”が明確（独自UI、独自フロー、特殊な商品仕様など）
将来的に大きく作り替える前提がある（長期運用で育てる）
社内またはパートナーで、保守体制を組める

向かないケース

「とにかく早く出したい」＋「運用担当が少ない」
セキュリティ対応（アップデート・脆弱性対応）を回せない
要件が曖昧で、開発が膨らみやすい

制作会社選びで差が出るポイント

“作れる”より 「保守できる」 が重要です
- アップデート方針（いつ、誰が、どう適用するか）
- カスタマイズの設計思想（将来の改修しやすさ）
EC-CUBEの場合、ライセンスの考え方（頒布・ソース開示の要否など）も含めて説明できる会社が安心です

初心者向け：見積もり前に確認する質問

「保守は月額で何を含みますか？（アップデート、障害対応、軽微改修など）」
「カスタマイズは、将来のアップデートで壊れない作り方ですか？」
「セキュリティ情報の収集〜パッチ適用までの運用手順はありますか？」

パッケージ/エンタープライズの向き不向き

パッケージ/エンタープライズは、ざっくり 「大規模運用を前提にした商用基盤」です。BtoB/BtoC、オムニチャネル、権限・組織、複雑な価格やプロモーションなどを前提にしやすい一方、導入はプロジェクト型になりがちです。

向いているケース

年商規模が大きく、要件が複雑（複数ブランド、複数拠点、海外展開など）
顧客データや基幹データと密に連携し、全体最適を狙いたい
ガバナンス（権限・監査・セキュリティ・運用品質）が重視される

向かないケース

要件が固まっていない（決めながら作ると大きく膨らむ）
スピード優先で早期に小さく検証したい
EC専任体制が薄い（意思決定が遅いと炎上しやすい）

制作会社選びで差が出るポイント

“制作”より 要件定義・PM・運用設計が強い会社が必要
Salesforce Commerce Cloud / Adobe Commerce / SAP / Oracle などは、導入経験（設計パターン・落とし穴）で差が出ます
「導入後の変更管理（改修・リリース・障害）」の運用品質を提案できる会社が安心

初心者向け：見積もり前に確認する質問

「要件定義の成果物は何ですか？（業務フロー、データ連携図、非機能要件など）」
「運用フェーズの体制（改善、障害、追加開発）はどう組みますか？」
「“標準機能でやる/カスタムする”の判断基準は？」

フルスクラッチが必要になる条件（例外パターン）

フルスクラッチは、“本当に必要な場合だけ”選ぶのが鉄則です。多くのケースでは、クラウド/ASPやパッケージで代替できます。

フルスクラッチが検討に上がる典型条件

既存のプラットフォーム制約が事業モデルと衝突する
- 例：超特殊な価格計算、独自の在庫引当ルール、複雑な権限・承認など
外部連携・データ基盤の前提が特殊で、既製品が合わない
事業上のコア機能が「ECそのもの」で、独自性が競争力になる

フルスクラッチで失敗しやすい条件

要件が曖昧（途中で増える）
運用・保守の体制が弱い（作った後に回らない）
“全部自前”が目的化（本当は一部だけで良い）

初心者向け：現実的な落としどころ

まずは既製品で検証 → 伸びた部分だけ拡張
“全部スクラッチ”ではなく、ヘッドレス/コンポーザブルなど段階的に独自化
（この設計が得意な制作会社は、長期的に強いです）

モール（楽天等）と自社ECで、設計思想がどう変わるか

同じ「EC」でも、モールと自社ECは“勝ち方”が違います。制作会社に依頼する前に、ここを言語化するとブレません。

モールの設計思想（楽天・Yahoo・Amazon等）

最優先は露出（モール内検索・ランキング・広告）
次に転換（商品ページの説得力、レビュー、価格・配送条件）
制約がある前提で、運用と改善を回す（ページ表現や導線に制限がある）

自社ECの設計思想

最優先は 体験の自由度（ブランド・UI/UX・導線・CRM）
SEOや広告の“入口”を広げつつ、LTV（リピート）を伸ばしやすい
計測・改善の自由度が高い反面、集客は自分で作る必要がある

現実的に強い戦略（初心者でも組みやすい）

モールで新規獲得 → 自社でリピート・ファン化
自社でブランド体験 → モールで露出補完
※どちらに寄せるかで、向く制作会社（モール運用型／自社グロース型）が変わります。

外部連携の整理（ERP／WMS／POS／CRM／MA／決済）

外部連携は、プラットフォーム選定の“最後の地雷原”です。ここを雑にすると、後から一番コストが跳ねます。
初心者でも失敗しにくい整理は、「データの正（マスター）を決める」→「連携方式を決める」→「例外処理を決める」です。

まず決めるべき“正（マスター）”チェック

商品マスターはどこが正？（ERP？EC？PIM？）
在庫の正はどこ？（WMS？基幹？）
顧客の正はどこ？（CRM？EC会員？）
受注の正はどこ？（EC？OMS？基幹？）

連携先別：見るべきポイント（早見表）

スクロールできます

連携先	主なデータ	つまずきやすい所	制作会社に確認する質問
ERP（基幹）	商品/在庫/受注/売上	データ整合・締め処理	「どのデータをどちらが正にする？」
WMS（倉庫）	出荷・在庫・追跡	欠品・分納・返品	「例外時（返品/キャンセル）はどう戻す？」
POS	店舗在庫・会員・ポイント	同期タイミング	「リアルタイム？バッチ？許容ズレは？」
CRM	顧客属性・LTV	ID統合・同意管理	「会員IDをどう統合？同意はどう扱う？」
MA	セグメント・配信	イベント定義	「どのイベントを送る？粒度は？」
決済	決済結果・不正検知	二重決済・与信	「失敗時の復旧フローは？」

連携方式の基本（初心者向け）

API：リアルタイム寄り。設計が良いと強いが、例外処理が重要
CSV/バッチ：安定しやすいが、反映遅延の設計が必要
中間DB/ETL：大規模で強いが、設計・運用がプロジェクト化しやすい

初心者が“必ず”押さえるべき確認

「障害が起きたとき、誰がどこを見て切り分けますか？」
「ログ・監視・アラートはどうしますか？」
「例外（欠品/分納/返品/キャンセル）を“仕様”として定義していますか？」

失敗しない比較ポイント12選（チェックリスト）

制作会社の比較は「会社の雰囲気」ではなく、成果が出る再現性で見たほうが外しにくいです。
まずはこのチェックリストを、相見積もり（2〜4社）の同じ質問表として使ってください。

各項目：◎/○/△で評価
「口頭の説明」だけでなく、成果物・根拠・契約文面まで確認
迷ったら、公開後3か月に何が残るか（運用できるか）で決める

①実績の見方：業界・規模・課題が近い事例があるか

実績は「有名企業」より、自社と条件が近い成功例があるかが重要です。

チェック観点（初心者向け）

商材の近さ：単価・購入頻度・検討期間
規模の近さ：商品点数、運用体制、広告の有無
立ち位置の近さ：新規立ち上げ／リニューアル／伸ばすフェーズ
プラットフォームの近さ：同じ土台で成果が出ているか

確認すると強い資料

施策前後の課題整理（どこが詰まっていたか）
何を変えて、どの順番で改善したか（打ち手の優先順位）

成果の根拠（CVR/ROAS/LTV等）を説明できるか

「数字を出せない」はNDAで仕方ない場合もありますが、“考え方”と“因果”は説明できます。

質問例

「CVRが上がった要因は、どの導線・どのページの改善でしたか？」
「ROAS改善は、LP/計測/配信設計のどこを触りましたか？」
「LTV改善は、同梱・メール/LINE・定期設計のどこで効きましたか？」

赤信号（避けたい）

画面キャプチャだけで、改善の筋が説明できない
“なんとなく良くなった”で終わる（再現性がない）

②設計力：導線・検索・カテゴリ・購入体験の設計思想

ECで一番差が出るのは、実はデザインより設計（迷わなさ）です。

チェック観点

ユーザーの「探し方」に合わせたカテゴリ設計（用途・悩み・比較軸）
絞り込み（フィルタ）が“使える”粒度になっているか
カート〜購入完了までの摩擦が少ないか（送料、決済、入力負荷）

質問例

「カテゴリと絞り込みは、誰のどんな探し方を想定していますか？」
「購入直前の最終確認画面で、必須表示やミス防止はどう設計しますか？」

赤信号

「見た目は後で整えるので」ばかりで、導線が語れない
検索・絞り込みの設計が弱い（商品点数が増えると崩壊しがち）

③デザイン力：世界観だけでなく“売れる”理由があるか

“おしゃれ”は大事ですが、ECは信用と理解がないと売れません。

チェック観点

ファーストビューで「何が・誰に・どう良いか」が伝わる
商品ページの型（写真→特徴→比較→不安解消→購入）が整っている
スマホで読みやすい（文字量、余白、ボタン、追従導線）

質問例

「このデザインで不安が減る根拠は？（返品、保証、レビューなど）」
「世界観とCVRのバランスは、どう判断しますか？」

赤信号

作品集がビジュアル中心で、購入体験の説明がない
デザインが凝りすぎて更新すると崩れる（運用で破綻）

④技術力：拡張性・保守性・速度・障害対応

初心者ほど「公開できた」で安心しがちですが、ECは運用で詰むことが多いです。

チェック観点

速度（表示が重くならない設計・画像最適化）
保守性（誰が見ても直せる構造、ドキュメント）
障害対応（切り分け、監視、復旧フロー）

質問例

「ステージング環境（テスト用）はありますか？」
「障害時、誰がどこを見て切り分けますか？連絡SLAは？」

赤信号

“作った人しか触れない”構造
速度や障害対応が「起きたら考える」

⑤集客支援：SEO/広告/CRM/コンテンツの支援範囲

集客は“できる/できない”ではなく、どこまで責任範囲かが大事です。

チェック観点

SEO：構造設計、テンプレ最適化、移行対応、コンテンツ方針
広告：計測設計、LP改善、配信設計の提案/運用
CRM：メール/LINE、同梱、会員、定期の改善

質問例

「制作後の集客は、戦略/実行/改善のどこまでやりますか？」
「やらない領域（範囲外）も明確にできますか？」

赤信号

「SEOは作れば勝手に上がる」系の説明
広告で“成果保証”を軽く言う（現実的でない）

⑥分析力：計測設計→改善提案までのプロセス

分析はレポート提出で終わると意味が薄いです。“次の一手”が出るかで判断します。

チェック観点

計測イベントの設計（何を見れば改善できるか）
ダッシュボードやレポートの見せ方（意思決定できる形）
改善サイクル（仮説→施策→検証→反映）

質問例

「最初の30日で、どの数字を見て、何を改善しますか？」
「改善提案は出ますか？実装まで含みますか？」

赤信号

数字の説明が抽象的（具体的な改善案に落ちない）
計測は“入れるだけ”で、運用が設計されていない

⑦運用支援：更新・商品登録・キャンペーン運用の実務

運用支援は“やります”より、作業の粒度で確認するのがコツです。

チェック観点

誰が更新するか（自社/制作会社/代行）
商品登録や画像差し替えの範囲
セール・クーポン・特集更新の回し方

質問例

「月に何回、どんな更新を想定していますか？」
「運用マニュアルと引き継ぎは、どこまで残りますか？」

赤信号

運用は“別途相談”のみで、現実的な回し方が見えない
更新のたびに制作会社に依存する設計

⑧セキュリティ：個人情報/権限/脆弱性対応の方針

ECは個人情報と決済があるので、“大丈夫です”はNGです。方針と手順を確認します。

チェック観点

管理画面の権限設計、2要素認証、ログ管理
脆弱性対応（定期点検、アップデート、緊急対応）
決済周りの責任分界（自社・決済会社・プラットフォーム）

質問例

「脆弱性情報をどう収集し、どの頻度で対策しますか？」
「インシデント時の連絡体制と初動手順はありますか？」

赤信号

セキュリティの話を避ける／説明できる担当がいない

⑨法務・権利：著作権/データ引き渡し/再委託の扱い

制作会社選びで見落とされがちですが、揉めるのは“権利と引き渡し”です。

チェック観点

デザイン・ソースコード・画像の権利は誰に帰属？
アカウント（ドメイン、解析、広告、決済）の名義は誰？
再委託がある場合の管理（品質・秘密保持）

質問例

「納品物は何ですか？“手元に残るもの”を一覧でください」
「解約時に、データ・設定・手順はどう引き継げますか？」

赤信号

引き渡し範囲が曖昧（“運用できない状態”になりやすい）
再委託の有無・範囲が不透明

⑩体制：PM・デザイナー・エンジニアの配置と連絡導線

プロジェクトは、スキルより体制で崩れることがあります。

チェック観点

PMが窓口として機能するか（意思決定を支えるか）
専任/兼任の度合い（忙しすぎないか）
連絡ルートが一本化されているか

質問例

「体制図（役割と担当）を見せてください」
「窓口が不在のときの代替は？エスカレーションは？」

赤信号

窓口が頻繁に変わる
誰が最終責任者かわからない

⑪コミュニケーション：進捗報告頻度、議事録、意思決定

“相性”は重要ですが、仕組みがあるとブレません。

チェック観点

定例頻度（週1など）と、進捗レポートの型
議事録（決定事項・宿題・期限）が残るか
仕様変更の扱い（変更管理）

質問例

「議事録テンプレを見せてください」
「決定事項はどこで管理しますか？（決定ログ）」

赤信号

口頭中心で記録が残らない
仕様変更が“その場のノリ”で進む

⑫費用の透明性：追加費用条件が明文化されているか

初心者が一番困るのは、途中で増える費用です。最初に“増える条件”を確定させます。

チェック観点

見積の内訳が分かれている（要件定義/デザイン/開発/移行/テスト等）
追加費用の条件が明記されている（仕様変更、商品数増、連携追加など）
検収条件（何をもって完了か）が書かれている

質問例

「追加費用が出る条件を、文書でください」
「スコープ変更の見積もりは、どのタイミングでどう出ますか？」

赤信号

一式見積だけで内訳がない
“やってみないと分からない”が多い

見積もり・提案の読み方｜「比較できる形」に整える

見積もりや提案書は、そのまま読むと会社ごとに書き方・範囲・前提が違いすぎて比較できません。
初心者がやるべきことはシンプルで、まず 「同じ条件で並べる」 ことです。

✅ 同条件（スコープ・前提・成果物）を固定する
✅ 内訳を“工程別”に分解してもらう
✅ 追加費用が出る条件を先に潰す
✅ 提案の筋（課題→打ち手→優先順位→スケジュール）を確認する

見積もり内訳テンプレ（同条件で比較する）

まず、各社に同じフォーマットで出してもらうと、比較が一気にラクになります。
下のテンプレを「見積依頼メール」に貼り付けて使うイメージです。

初期：要件定義／設計／デザイン／開発／移行／テスト／公開

初期費用（構築費）テンプレ例

スクロールできます

区分	含めてほしい内訳（例）	見るポイント
要件定義	要件整理、業務フロー、画面一覧、非機能要件（速度/権限/監視）	「何が決まれば着手」か明確か
情報設計	サイト構造、カテゴリ/検索設計、導線、ワイヤー	迷わない購入導線になっているか
デザイン	トップ/カテゴリ/商品/カート、ガイド、UIルール	見た目だけでなく“売れる理由”があるか
実装（フロント）	テーマ/テンプレ実装、レスポンシブ、速度配慮	更新して崩れない設計か
実装（バック）	決済、配送、会員、クーポン、在庫/受注	例外処理（欠品/返品等）まで想定できているか
外部連携	ERP/WMS/POS/CRM/MA等（方式：API/CSVなど）	データの正（マスター）が定義されているか
移行	URL/商品/顧客/ポイント等の移行、リダイレクト設計	「何を引き継ぐか」が具体的か
テスト	単体/結合/受入、決済・配送・メール検証	テスト観点が薄いと後で事故りやすい
公開	本番反映、切替手順、ロールバック	公開当日の体制が書かれているか
ドキュメント	運用マニュアル、更新手順、引き継ぎ会	“属人化しない”形で残るか
PM/管理	進行管理、定例、議事録、課題管理	連絡導線と意思決定が回る設計か

比較を強くするコツ

「何ページ作りますか？」より、ページ“種類”で揃える（例：商品ページはテンプレ1種＋例外2種など）
「外部連携」は対象システム名・データ・方式・頻度まで書いてもらう
「移行」は対象データ一覧を出してもらう（“移行一式”は危険）

月額：保守／改善／運用代行／サーバー・アプリ費

月額は“保守”と“改善”が混ざると比較不能になりがちです。分けて出してもらうのが鉄則。

スクロールできます

区分	内訳（例）	確認ポイント
保守	障害一次対応、軽微改修、監視、バックアップ	対応時間（平日/夜間）とSLA
セキュリティ運用	脆弱性対応、アップデート、権限管理	誰が・どの頻度で・何をするか
改善（グロース）	分析→施策提案→実装→検証（ABテスト等）	工数が何時間含まれるか
運用代行	商品登録、特集更新、バナー差替え、キャンペーン設定	“作業の粒度”が明確か
プラットフォーム/アプリ	月額利用料、アプリ/プラグイン費	ここは公式費用＋見積で分けると透明

初心者が陥りやすい落とし穴

「月額＝保守だけ」で、改善が一切含まれていない（伸びない）
アプリや外部ツールが増えて、月額がジワジワ膨らむ（予算超え）

追加費用が出やすいポイント（事前に潰す）

追加費用は悪ではありません。問題は、条件が曖昧で“いつの間にか増える”ことです。
先に「増える条件」を文章で潰すと、トラブルが激減します。

仕様変更・ページ追加・商品点数増・連携追加

ここは“契約前に線引き”しておくべき代表格です。

追加費用が出る典型パターン

要件定義後の仕様追加（例：会員ランクをやっぱり入れたい）
ページ種類の増加（例：LPが想定より増える）
商品点数・SKUが増える（登録/移行/画像加工が膨らむ）
連携が増える（ERP/WMS等が後出しで追加）

潰し方（そのまま依頼文に書けます）

ベースラインを固定する
- 例：商品点数〇〇、ページ種類〇種、連携〇本まで
変更手順を固定する
- 例：変更要求 → 影響範囲 → 追加見積 → 承認後に着手
“検収条件”を固定する
- 何をもって完了か（公開基準、バグ許容範囲、手戻り条件）

多言語・サブスク・会員ランク等の複雑要件

このあたりは、見積もりの段階で「標準でできる」が曖昧だと膨らみやすい領域です。

追加になりやすい理由

仕様の分岐が多い（価格表示、税/配送、会員権限、定期の変更ルールなど）
テストケースが急増する（例外処理が増える）
外部ツール（決済・CRM・翻訳）に依存しやすい

確認のしかた

「標準機能で可能／拡張で可能／開発が必要」を3段階で書いてもらう
“例外”の扱いを聞く
- 返品、キャンセル、スキップ、途中解約、権限変更など

提案書で見るべき観点（“良さそう”で決めない）

提案書はデザインが綺麗でも、筋が悪いと成果に繋がりません。
初心者は「一貫性」と「優先順位」だけ見ればOKです。

課題→打ち手→優先順位→スケジュールが一貫しているか

良い提案に必ずあるもの

課題が具体的（例：商品ページ到達率が低い、カート離脱が高い等）
打ち手が“どの画面の何を変えるか”まで落ちている
優先順位が明確（まずここ→次にここ）
スケジュールが現実的（素材準備・テスト期間が含まれる）
前提とリスクが明記されている（自社側の宿題も含む）

悪い提案でよくあるサイン

かっこいい言葉は多いが、どこをどう変えるかが曖昧
“全部やります”で優先順位がない
素材（写真・原稿・商品情報）の準備が計画に入っていない

比較用のミニ採点（各社に同じ質問）

「最初の30日で何を改善し、どう検証しますか？」
「公開時点で“最低限必要な状態”は何ですか？」
「公開後3か月で、何が社内に残りますか？（運用できる状態か）」

契約で必ず押さえる項目（トラブル予防）

契約は難しく見えますが、初心者は “揉めやすい所だけ”先に押さえればOK です。
（重要案件は、最終的に専門家チェックも検討してください）

成果物の権利・ソース/データの引き渡し範囲

ここが曖昧だと、将来「直せない」「移れない」状態になります。

最低限、文章で確定したい成果物

デザインデータ（どの形式で渡すか）
ソースコード（範囲：テーマ/テンプレ/カスタム部分）
設定値（アプリ設定、計測設定、メール設定など）
ドキュメント（運用手順、構成図、連携仕様）
移行データ（変換ルール、対応表、リダイレクト表）

権利の考え方（超重要）

著作権の扱いは大きく「譲渡」か「利用許諾」かで変わります
“納品した＝自由に使える”とは限らないので、範囲を明文化するのが安全です

再委託・秘密保持・解約条件・瑕疵対応

運用が始まってから揉めやすいのはこの領域です。

再委託（下請け）

あること自体は普通ですが、
- どの工程を誰が担当するか
- 品質責任の所在
- 秘密保持の範囲
  を明確にしておくと安心です。

秘密保持（NDA）

顧客データ、売上、広告、在庫、価格など、守る対象を列挙
共有手段（チャット/ファイル/アカウント管理）も決めると事故が減ります

解約・契約終了

いつまでに何を引き渡すか（データ、設定、ドキュメント）
月額契約の更新単位（自動更新の条件）
ドメイン/解析/決済など“名義”が誰か（ここが地雷になりがち）

瑕疵（不具合）対応

何を不具合とみなすか（仕様かバグか）
期間と範囲（無償対応の条件）
緊急度の基準（売上に直結する障害の扱い）

ECサイト制作の費用相場｜何にいくらかかる？

ECサイト制作の費用は、ざっくり言うと 「初期（作る）＋月額（回す）＋変動（広告/手数料など）」 で決まります。
同じ“ECサイト”でも、何をどこまで作るかで金額が大きく変わるので、まずは「費用が動くポイント」を押さえてから、内訳を見ていくと迷いません。

パターン別：費用が変わる要因（規模・機能・連携・移行）

費用が上下する要因は、主にこの8つです（初心者でも判断しやすい順）。

土台（プラットフォーム）：クラウド/ASPか、オープンソースか、パッケージか
デザイン：既存テンプレ寄せか、フルオリジナルか
商品点数・カテゴリ：商品登録の量、検索/絞り込み設計の複雑さ
“例外”の多さ：セット販売、予約、ギフト、同梱、返品ルール、会員ランクなど
外部連携：在庫・受注・会計・物流（ERP/WMS/POS/CRM/MA）
移行の難易度：URL、会員、ポイント、受注履歴、SEO資産をどこまで引き継ぐか
運用体制：自社で回すか、運用代行まで頼むか
品質要件：速度、権限、監視、障害対応、セキュリティ運用のレベル

目安として、費用が跳ねやすいのは「連携」「移行」「例外」です。
逆に、コストを抑えやすいのは「段階リリース（最小で公開→伸ばす）」です💡

初期費用の内訳（設計/デザイン/開発/テスト/移行）

初期費用は、見積書の“項目名”より 何が含まれているかで判断します。代表的な内訳は次の通りです。

要件定義・設計：目的/KPI、導線、カテゴリ、検索/絞り込み、運用ルール、非機能（速度/権限/監視）
デザイン：トップ/カテゴリ/商品/カート、UIルール、購入体験の作り込み
開発：テンプレ実装、アプリ設定、カスタム機能、外部連携、メール/決済/配送設定
テスト：決済・配送・メール・例外（欠品/返品/キャンセル）までの検証
移行：商品/会員/ポイント、リダイレクト（URL移行）、計測設定、公開手順
ドキュメント/引き継ぎ：運用マニュアル、更新手順、体制の整理

初期費用の相場感（目安）

※あくまで「制作会社に依頼した場合の一般的な目安」です。要件次第で上下します。

最小構成（テンプレ中心・連携なし・移行軽め）：30万〜150万円
標準（テンプレ＋部分カスタム・基本アプリ・移行あり）：150万〜500万円
本格（オリジナル度高め・連携1〜2本・改善前提の設計）：500万〜1,500万円
大規模（複数連携・権限/監視・BtoB/多言語など複雑要件）：1,500万円〜

見積で初心者が見落としやすい“別料金”はここです👇

写真撮影・採寸・原稿（商品説明）
商品登録（CSV整備、画像加工）
返品/規約/表示（法務チェック）
計測（GA4/タグ設計）や広告アカウント整備

月額費用の内訳（保守/改善/運用/ツール/アプリ）

月額費用は「固定費」と「人件費（委託費）」に分けて考えるとスッキリします。

A. 固定費（サービス利用料）

プラットフォーム月額（Shopify、makeshop、futureshop等）
アプリ/オプション（月額課金の拡張）
ドメイン、メール配信、CRM/MA、検索強化、レビュー、接客ツール等

B. 委託費（人が動く）

保守：障害一次対応、軽微改修、バックアップ、アップデート対応
改善（グロース）：分析→提案→実装→検証（毎月の改善サイクル）
運用代行：商品登録、特集更新、バナー差し替え、キャンペーン設定

月額の相場感（目安）

固定費（プラットフォーム＋アプリ）：数千円〜数万円（構成次第で増減）
保守のみ：月3万〜15万円
保守＋改善（伴走）：月10万〜50万円
運用代行まで込み：月20万〜80万円（作業量で変動）

ポイントは、月額に「改善」が入っていないと、公開後に伸びにくいこと。
逆に、改善を入れるなら “何を見て、どう回すか”（指標と会議体）がセットになっている会社が安心です。

コスト最適化の考え方（段階リリース・優先順位）

コスト最適化の基本は 「全部入りで作らない」 です。ECは公開後に学習して伸ばすほうが成功確率が上がります。

おすすめの段階リリース例

Phase1（公開最優先）：売れる導線・商品ページの型・決済/配送・最低限のSEO
Phase2（CVR改善）：比較表、FAQ、レビュー、特集、絞り込み最適化
Phase3（LTV改善）：会員施策、定期、同梱、メール/LINE、CRM連携
Phase4（業務最適化）：基幹/WMS連携、OMS、権限/監視の強化

費用を抑えやすい判断ルール

迷った機能は「今の売上に直結するか？」で切る
アプリで済むものはアプリで（ただし“増えすぎ”には注意）
移行は「SEO資産」「会員資産」「業務継続」に関係するものを優先
デザインは“更新して崩れない”を最優先（運用コストが下がる）

補助金・助成金を使うときの注意点（要件・スケジュール）

補助金は強力ですが、初心者がつまずきやすい落とし穴もあります。大事なのは 「対象経費」より先に「時間」と「手続き」 です。

共通の注意点（これだけ覚えればOK）

申請〜採択まで時間がかかる（締切直前は特に危険）
原則“後払い”：いったん立替が必要になりやすい
交付決定前の発注・着手がNGになるケースがある
見積・契約・成果物の要件が厳格（証憑・納品物が重要）
gBizIDが必要な制度が多い（取得に時間がかかる）

代表例としてよく検討される制度

小規模事業者持続化補助金：販路開拓の一環としてEC/販促を組み立てやすい
ものづくり補助金：業務プロセス改善や生産性向上の文脈で採択を狙う（要件が重め）
デジタル化・AI導入補助金（旧IT導入補助金）：原則として“登録されたITツール”の導入が前提
- つまり、制作会社への一式発注というより、補助対象の仕組みに沿った調達が必要になります

制度は公募回で細部が変わるため、最終判断は必ず最新の公募要領・公式資料で確認してください。

制作の流れと期間｜最短で成果につなげる進め方

EC制作は「順番」と「決め切るポイント」を間違えると、納期も費用も膨らみやすいです。最短で成果につなげるコツは、①要件を早く固める → ②迷う部分は段階リリースに逃がす → ③公開後90日で改善を回すの3点です。

まず全体像（目安）を置きます。※規模・連携・移行量で上下します。

スクロールできます

フェーズ	目安期間	遅れやすい原因
要件定義〜設計	2〜6週間	決めるべきことが未確定、社内承認が遅い
デザイン〜開発	4〜12週間	途中の仕様追加、素材不足、連携の例外対応
移行〜テスト〜公開	2〜6週間	データ整備不足、決済/配送/メールの検証漏れ
公開後90日（改善）	12週間	計測不足、改善の担当不明、施策の優先順位が曖昧

STEP1：要件定義（ゴール・KPI・要件・体制の確定）

ここが曖昧だと、後工程が全部ブレます。初心者ほど「作る話」より先に「運用の現実」を決めるのが重要です。

このSTEPで決めること（最低限）

ゴール：売上／CVR／LTV／リピート／粗利の最優先KPI
スコープ：今回やること／やらないこと（段階リリース前提でOK）
機能：Must/Should/Could（優先順位つき）
体制：意思決定者、窓口、素材準備担当、運用担当
非機能：速度、権限、監視/バックアップ、障害時の連絡

成果物（あとで揉めないための必須）

要件一覧（優先順位つき）
画面/ページ種類一覧（「何ページ」より「何種類」）
外部連携一覧（対象システム・データ・方式・頻度）
追加費用が出る条件（仕様変更・ページ追加・連携追加など）

最短化のポイント

迷う機能は「公開後に追加」に逃がす（ただし計測は最初から）
仕様変更の手順を決める（変更→影響→追加見積→承認→着手）

STEP2：情報設計（導線・カテゴリ・検索・コンテンツ）

ECの勝敗は、デザインより“迷わず買える設計”で決まりやすいです。

ここでやること

サイト構造：トップ→カテゴリ→商品→カートの最短導線
カテゴリ設計：ユーザーの探し方（用途・悩み・比較軸）に合わせる
検索/絞り込み：商品点数が増えても崩れない軸を決める
コンテンツ設計：特集、比較、FAQ、配送/返品、会社情報など信頼要素

成果物

サイトマップ（ページ構成）
ワイヤーフレーム（主要テンプレ）
商品ページの型（見出しの順番・要素の並び）

よくある失敗

カテゴリが社内都合で、ユーザーの探し方とズレる
絞り込みが弱く、商品点数が増えるほど探せなくなる

STEP3：デザイン（UI/UX・コンポーネント設計）

「見た目を作る」だけでなく、運用しても崩れない仕組みに落とすのが重要です。

ここでやること

UI/UX：スマホ前提の可読性、ボタン配置、入力負荷の最小化
コンポーネント設計：見出し・ボタン・カード等の共通パーツ化
信頼設計：返品・保証・配送・レビュー・問い合わせ導線を自然に配置

成果物

デザインカンプ（主要テンプレ）
UIルール（フォント、余白、ボタン、色、写真比率など）
更新時のルール（バナー差し替えのサイズ等）

最短化のポイント

まず“売上に直結するテンプレ”（商品・カテゴリ・カート周り）を優先
LPや特集は「型」を先に作り、量産しやすくする

STEP4：開発（連携・決済・配送・会員・管理画面）

差が出るのは「連携」と「例外処理」です。正常系だけで作らないのがコツです。

ここでやること

決済：支払い手段、与信/失敗時、返金の運用
配送：送料ルール、配送日、追跡、同梱、ギフト
会員：登録/ログイン/権限、ポイント、会員ランク（必要なら）
連携：在庫・受注・会計・倉庫など（API/CSV/バッチ）
管理画面：更新担当が迷わない導線、権限設計、ログ

成果物

実装済み環境（テスト/本番）
連携仕様（データ項目、タイミング、エラー時の扱い）
運用手順（誰が何を更新するか）

最短化のポイント

例外を先に洗い出す：欠品、分納、返品、キャンセル、二重決済
連携は「データの正（マスター）」を決めてから作る

STEP5：移行（商品/顧客/コンテンツ/SEO資産）

移行は制作というより移行プロジェクトです。ここが雑だと公開後に痛みます。

移行対象の代表例

商品：SKU、画像、説明文、カテゴリ、属性（絞り込み用）
顧客：会員、購入履歴、ポイント（どこまで引き継ぐか）
コンテンツ：特集、ブログ、FAQ、規約
SEO資産：URL対応表、リダイレクト、内部リンク、サイトマップ

最短化のポイント

移行は「全部」ではなく、成果に効く資産（SEO/会員/運用継続）優先
商品データは早めにCSV整備（ここが遅れると全体が止まります）

STEP6：テスト（決済・配送・メール・速度・端末）

ECは“買えない”が致命傷です。買うまでの流れを重点的に潰します。

最低限やるべきテスト（初心者向け）

決済：成功/失敗、返金、注文メールの整合
配送：送料計算、配送日指定、追跡、同梱
例外：キャンセル、欠品、返品フロー（運用が回るか）
端末：主要スマホ/ブラウザ
速度：画像最適化、重いページの特定

最短化のポイント

“テスト観点表”を作り、誰が何を確認したか残す（やり直し防止）

STEP7：公開（切替・監視・初動施策）

公開当日は「切替」より「事故らない運用」が重要です。

公開前に決めておくこと

切替手順：いつ、誰が、何をするか（ロールバック含む）
監視：エラー通知、決済失敗の検知、在庫ズレの確認
初動施策：告知（SNS/メルマガ）、指名検索の受け皿、主要LPの整備

公開直後にやること（最優先）

注文が正常に流れているか（決済→受注→出荷→メール）
主要ページの計測が取れているか（イベント/コンバージョン）

公開後90日プラン（改善ロードマップ）

「公開＝完成」ではなく、公開＝改善のスタートです。90日で成果につなげるなら、やることは3段階に分けると迷いません。

0〜30日：計測整備・ボトルネック特定

この期間のゴール

“どこで落ちているか”を数字で言える状態にする

やること

計測の確認：購入、カート投入、チェックアウト到達、検索利用など
レポート整備：週次で見る指標を固定（ブレない運用）
ボトルネック特定：
- 流入が弱いのか
- 商品ページの到達が弱いのか
- カート離脱が高いのか

よく効く即効施策

送料・返品・納期の表示を分かりやすく（不安を減らす）
商品ページの情報不足を埋める（FAQ、比較、サイズ感、レビュー導線）

31〜60日：CVR改善（LP/商品ページ/導線）

この期間のゴール

“買うまでの摩擦”を減らし、CVRを底上げする

やること（優先順）

商品ページ改善：写真・比較軸・FAQ・レビュー・保証の強化
カート改善：入力負荷、エラー文言、決済手段の最適化
導線改善：カテゴリ/絞り込み、回遊（関連商品・セット提案）

効果が見えやすい指標

商品ページ到達率、カート投入率、チェックアウト到達率、購入完了率

61〜90日：LTV改善（CRM/リピート/単価）

この期間のゴール

1回買って終わりを減らし、継続購入を増やす

やること

CRM導線：メール/LINE（購入後フォロー、再入荷、関連提案）
単価改善：セット、まとめ買い、送料無料ライン設計（粗利も確認）
リピート施策：同梱物、レビュー依頼、定期/会員施策（必要なら）

見る指標

リピート率、2回目購入率、平均注文額、粗利、LTV

依頼前に準備するもの（RFPテンプレ）

RFP（提案依頼書）は、制作会社を“選ぶための資料”というより、提案を同じ土俵に揃えて比較するための設計図です。
初心者ほど、ここを作るだけで次が一気にラクになります。

見積もりのブレが減る（「一式」や想定外の追加が減る）
提案の質が上がる（課題に刺さる打ち手が出やすい）
公開後の運用が回る（やるべきことが明確になる）

以下は、そのままコピペして使えるテンプレです。
※最初は「書ける範囲だけ」でOK。空欄があると制作会社から質問が返ってきて、要件が固まっていきます。

会社・ブランド概要／ターゲット

目的：提案の前提（誰に何を売るのか）を揃える

記載する内容（テンプレ）

会社概要：業種／従業員数／拠点／販売チャネル（店舗・卸・D2C・モール等）
ブランド概要：コンセプト／強み／価格帯／主力商品
ターゲット：年齢層／性別／地域／利用シーン／購入動機
購買の特徴：単価／リピート頻度／検討期間（即決か比較検討か）

書き方のコツ

“ペルソナ”より先に、購買行動を書いたほうが提案が具体化しやすいです
例：
- 「比較検討が長い（レビュー・保証が重要）」
- 「衝動買いが多い（特集・ランキングが効きやすい）」

現状課題（数字と現場の声）

目的：制作が“見た目”で終わらず、課題解決に寄るようにする

数字（分かる範囲でOK）

月商／粗利率（ざっくりでOK）
流入：SEO／広告／SNS／メルマガ／モール内など比率
CVR（購入率）、カート離脱、平均注文額、リピート率
問い合わせ件数、返品率（あれば）

現場の声（めちゃくちゃ重要）

よくある問い合わせ：サイズ、納期、返品、支払い、在庫など
運用の詰まり：商品登録が重い／更新が属人化／キャンペーン設定が難しい
クレームや機会損失：発送遅れ、在庫ズレ、決済エラー、表示が遅い等

書き方のコツ

数字が少なくても、「困っている瞬間」を具体例で書くと提案精度が上がります
例：
- 「新商品を出すたびに登録と画像加工で3日かかる」
- 「クーポンの条件が複雑で設定ミスが出やすい」

要件チェックリスト（Must / Want）

目的：スコープを固定して“比較できる見積もり”にする

Must（ないと困る）例

決済：クレカ、コンビニ、代引き、後払い等（必要なもの）
配送：送料ルール、配送日指定、追跡番号通知
商品：バリエーション（色・サイズ）、在庫管理、検索・絞り込み
重要ページ：特商法、プライバシー、返品・交換、会社情報、FAQ
計測：購入計測、主要イベント（カート投入など）

Want（あると嬉しい）例

レビュー、会員ランク、ポイント、クーポン高度化
レコメンド、セット販売、ギフト、予約販売
サブスク（定期）、多言語、BtoB機能（見積・掛け払い等）

優先順位の付け方（初心者向け）

Mustにも「優先度A/B/C」を付ける（A＝絶対、B＝できれば、C＝後でも）
迷う機能は「公開後追加」に逃がしてOK（ただし追加条件は明記）

連携要件（在庫・受注・会計・発送・CS）

目的：後から一番お金が跳ねやすい“連携”を、先に見える化する

まず決めること

データの正（マスター）はどこか
- 商品マスター：どれが正？
- 在庫の正：どれが正？
- 顧客の正：どれが正？
- 受注の正：どれが正？

連携一覧テンプレ

連携先：ERP／会計／WMS（倉庫）／配送システム／POS／CRM／MA／CSツール
データ：商品、在庫、受注、出荷ステータス、追跡番号、顧客属性など
方式：API／CSV／バッチ（毎時/毎日）など
例外：欠品、分納、キャンセル、返品、返金の扱い

質問にすると強い

「例外（返品・欠品・キャンセル）まで含めて設計できますか？」
「障害時、誰がどこを見て切り分けますか？復旧手順は？」

運用体制（誰が何をやるか）

目的：公開後に止まらない設計にする（運用できないECは伸びない）

運用担当の棚卸し

商品登録：誰が、どこまで（SKU、画像、説明文）
更新：バナー、特集、ランキング、価格改定
分析：週次の数字確認、改善優先順位の決定
CS：問い合わせ対応、レビュー対応、返品対応
物流：出荷・同梱・ギフト・在庫調整

制作会社に確認すべきこと

運用マニュアルはどこまで出るか（画面操作・CSV・ルール）
更新を自社で回す前提の設計か（依存しない作りか）
月額に「改善」が含まれるか（レポートだけで終わらないか）

競合・参考サイト（良い点/避けたい点）

目的：好み・方向性・NGを早めに合意して、手戻りを減らす

書き方テンプレ

競合（3〜5社）：URLまたは名前／強い理由（価格、世界観、訴求、導線等）
参考サイト（3〜5件）：
- 良い点：例）「カテゴリが探しやすい」「商品ページの比較が上手い」
- 避けたい点：例）「情報が多すぎて読みにくい」「購入ボタンが遠い」

ポイント

「デザインが好き」だけでなく、売れる要素（不安解消・比較・導線）を書いておくと提案が強くなります。

素材の準備（商品画像・原稿・規約・配送ポリシー）

目的：スケジュール遅延の最大原因＝素材不足を先に潰す

最低限準備したいもの

商品情報：商品名、説明、価格、SKU、サイズ、素材、注意事項
画像：メイン、詳細、使用シーン、サイズ感（できれば統一ルール）
規約：特商法、プライバシー、利用規約、返品・交換、配送ポリシー
配送・納期：送料ルール、配送日、同梱、ギフト、海外対応の有無
会社情報：住所、連絡先、営業時間、問い合わせ導線

初心者がハマりやすい注意

画像サイズや比率がバラバラ → 表示崩れ＆運用負荷が増える
原稿が後回し → 商品ページが弱くなりCVRが伸びない
返品・配送ルールが曖昧 → 問い合わせ・クレームが増える

意思決定フロー（稟議・承認者・締切）

目的：納期遅延の原因1位＝社内承認の遅れを防ぐ

決めること

意思決定者：最終承認者、現場責任者、窓口
稟議：必要な資料（比較表、見積、体制、リスク）と締切
変更管理：仕様変更の承認ルール（誰がOKを出すか）
定例：週1など、意思決定の場を固定（議事録も残す）

制作会社に伝えるとスムーズ

「この日までに要件確定しないと、公開日が動く」ライン
“判断が遅れやすい項目”（デザイン、機能追加、連携、移行範囲）

よくある失敗パターンと回避策

ECサイト制作は「作って終わり」になりやすいので、失敗パターンを先に知っておくと勝率が上がります。
ここでは、初心者が特につまずきやすい5パターンを、起きる理由 → 兆候 → 回避策（具体策）の順で整理します。

デザインだけで選んで“売れない”

起きる理由

見た目は良いのに、購入導線・不安解消・比較の要素が弱い
ブランド表現を優先しすぎて、情報が探しにくい／買いにくい
“制作物としての完成度”は高いが、成果（CVR/LTV）に責任範囲がない

よくある兆候

提案が「世界観・トーン」中心で、導線やCVRの話が薄い
商品ページの設計が「写真が大きい」以外の根拠がない
計測（GA4等）の話が後回し、または触れられない

回避策（これをやると外しにくい）

デザイン評価を「綺麗」ではなく、次の3点で見る
1. 迷わない（カテゴリ・絞り込み・パンくず）
2. 不安が減る（返品・配送・保証・問い合わせ）
3. 比較できる（特徴・スペック・レビュー・FAQ）
商品ページの“型”を先に合意する（制作の早い段階で）
- 例：ファーストビュー → ベネフィット → 証拠（レビュー/実績）→ 不安解消（FAQ/返品）→ 購入導線
制作会社にこの質問をする（答え方で地力が分かる）
- 「このデザインでCVRが上がる理由を、どの要素で説明しますか？」
- 「優先順位は？（まず商品ページ、次にカート等）」

初期費用だけで決めて追加費用が膨らむ

起きる理由

見積の前提（ページ種類・商品点数・連携範囲・移行範囲）が曖昧
“一式”見積で、何が含まれるか分からない
途中で要望が増え、変更管理がないまま積み上がる

よくある兆候

内訳が少なく、「制作一式」「移行一式」「調整一式」が多い
“追加条件”の説明が口頭のみ
見積が安い代わりに、テスト・移行・運用引き継ぎが薄い

回避策（最初に固めるだけで防げる）

見積は必ず「同条件比較」に整える
- ページ数ではなく、ページ種類（テンプレ種類）で揃える
- 商品点数・SKU数・連携本数・移行対象を固定する
追加費用の条件を“文章”で先に確定する
- 仕様変更／ページ追加／商品点数増／連携追加
- 追加見積の手順（依頼→影響→見積→承認→着手）
“段階リリース”を前提にする（最小で公開→追加）
- 最初から全部入れないことで、変更の爆発を抑えられます

要件が固まらず炎上（スコープ管理不足）

起きる理由

発注側の目的・KPIが曖昧で「なんとなく良さそう」が増える
意思決定者が不明で、承認が遅い／意見がぶつかる
“決める順番”が逆（デザインから入って後で要件が増える）

よくある兆候

仕様が毎週増える（会議ごとに要望が追加）
「それもできますか？」が頻発する
いつまでに何を決めるか（締切）がない

回避策（進行が安定する型）

要件をMust/Wantに分け、Mustに優先度を付ける
- Must（A/B/C）＋ Want（今回は保留でもOK）
“決定ログ”を作る（議事録とは別で、決定事項だけ残す）
- 決めたこと／決めた日／決めた人／影響範囲
体制（RACI）を明確にする
- 誰が決める（承認者）／誰が準備する（素材担当）／誰が運用する（更新担当）
仕様変更は「変更管理」で処理する（気分で進めない）
- 変更要求→影響→追加見積→承認→着手
  これを徹底するだけで炎上率が下がります

公開後に運用が回らない（担当不在・改善不在）

起きる理由

“制作完了＝ゴール”になっていて、運用の設計がない
更新が制作会社依存（自社で触れない・触ると壊れる）
計測が弱く、改善の優先順位が決められない

よくある兆候

運用マニュアルや引き継ぎが薄い／存在しない
更新・商品登録の作業範囲が契約で曖昧
月額は「保守のみ」で、改善が含まれていない

回避策（初心者でも回る形）

公開前に「運用の棚卸し」をやる（誰が何をやるか）
- 商品登録、特集更新、価格改定、キャンペーン設定、CS、物流、レビュー対応
“公開後90日”の改善計画を契約前に作る（簡易でOK）
- 0〜30日：計測整備・ボトルネック特定
- 31〜60日：CVR改善（商品/導線/カート）
- 61〜90日：LTV改善（CRM/単価/リピート）
運用を止めないための最低条件を明文化する
- 例：更新手順、権限、CSV運用、テンプレの使い方、問い合わせ導線

権限・アカウント管理が曖昧で引き継げない

起きる理由

ドメイン、解析、広告、決済、プラットフォームの所有者が制作会社側になっている
2段階認証やパスワード管理が個人任せ
解約時の引き渡し範囲が契約で定義されていない

よくある兆候

「こちらで取得しておきますね」が多い（名義が不明）
アカウント一覧がない／権限管理がない
担当者が退職した瞬間に詰む

回避策（これだけは必須）

“アカウント台帳”を作り、所有者を原則「自社」にする
- ドメイン、DNS、メール、GA4/GTM、Search Console、広告、決済、プラットフォーム、主要アプリ
権限は個人ではなく、共有用メール＋権限分離で管理
- 管理者／運用者／閲覧者を分ける
- 2FAは必須（復旧コードの保管も）
契約で「引き渡し範囲」を確定する
- ソース、デザインデータ、設定値、連携仕様、運用マニュアル、URL対応表、移行データ
- 解約時にいつ何を渡すか（期限・形式）まで書く

【目的別】おすすめECサイト制作会社リスト（比較表付き）

「おすすめ」は目的次第で変わるので、ここでは タイプ別に“当てにいく” 方式で整理します。
まずは 表で候補をざっと俯瞰 → 自社の目的に近いタイプの会社を2〜4社に絞ってRFP→相見積 が最短ルートです。
（下の社名は“代表的な候補例”。対応領域は各社で変動するため、最終は公式のサービス範囲で確認してください。）

タイプ別に探す（あなたの条件に近い順に当てる）

比較表（候補の俯瞰用）

スクロールできます

目的タイプ	候補例（制作会社/支援会社）	強みの方向性	向いているケース	見るべきポイント
UI/UX・デザイン重視	LIG / スパイスファクトリー / アートピースなど	購入体験設計・画面品質	ブランド/世界観、CVR改善を重視	商品ページの型、導線・検索設計、運用して崩れない設計
実績・導入事例重視	ecbeing / インターファクトリー（ebisumart）/ EC-CUBE関連など	大規模・基盤・安定運用	要件が多い、社内関係者が多い	要件定義の厚み、保守/監視、連携・移行の経験
低予算・短納期	楽天系の制作特化（Ryuki Design等）/ 小規模向け制作代行など	早く形にする	まず小さく開始、最小構成で検証	“含まれる範囲”の明確さ、追加費用条件、公開後の改善導線
モール（楽天等）中心	Ryuki Design / モール運用代行各社（例：EC研究室、R6B等）	モール内の勝ち筋	楽天/Yahoo/Amazonが主戦場	商品ページ制作＋運用（広告/イベント/分析）まで一体か
集客・マーケ伴走	コマースメディア / AnyMind など	集客→改善の運用力	広告/CRM/SEOまで含めて伸ばしたい	計測設計→改善サイクル、施策の優先順位づけ
基幹連携・大規模開発	ecbeing / スパイスファクトリー / インターファクトリー等	ERP/WMS/POS連携	在庫・受注・会計・倉庫が必須	連携方式（API/CSV）と例外処理、障害時の運用設計
越境EC	GMOグローバルEC / Shopify系パートナー各社など	多言語・海外決済/配送	海外販売、ローカライズ	税・決済・配送、言語/通貨、現地マーケの有無
BtoB EC	ecbeing BtoB / アイル（アラジンEC）等	法人取引の要件	見積・掛け払い・取引先別価格	権限/承認フロー、価格体系、既存基幹との整合
サブスクEC	Shopify系パートナー / マーケ伴走型支援など	LTV設計・継続率	定期購入、アップセル前提	継続のKPI設計、CRM、解約理由の回収と改善

※この表は「候補の当たり」を付けるための早見表です（網羅リストではありません）。参照元：制作会社比較記事・Shopify公式パートナーディレクトリ等。

UI/UX・デザイン重視で選ぶ制作会社

このタイプが強い領域

迷いにくい導線（カテゴリ・検索・絞り込み）
商品ページの“説得構造”（比較・不安解消・購入導線）
運用しても崩れないコンポーネント設計

候補例

LIG / スパイスファクトリー / アートピースなど

失敗しない見極め

「見た目」より CVRが上がる理由を言語化できるか
商品ページのテンプレ（型）を最初に合意できるか

実績・導入事例が豊富な制作会社

このタイプが強い領域

中堅〜大手の複雑要件（権限・監視・運用フロー）
大規模移行（会員/ポイント/SEO資産）
インフラやセキュリティ運用の整備

候補例

ecbeing / インターファクトリー（ebisumart）/ EC-CUBE（提供元・関連パートナー）など

失敗しない見極め

事例は「業界」より 課題の近さ（移行・連携・運用）で見る
保守の中身（監視/障害時対応/改修のSL）を確認する

低予算・短納期に強い制作会社

このタイプの考え方

低予算＝悪ではなく、段階リリース（最小→改善） に向く
ただし、範囲が曖昧だと追加費用が膨らみやすい

候補例

楽天制作特化（Ryuki Design等）/ 小規模向け制作代行の各社

失敗しない見極め

見積の「含む/含まない」をテンプレで揃える（設計/移行/テスト/公開）
公開後の改善（計測・小改修）の動線があるか

モール（楽天等）運用に強い制作会社

モールは“制作＋運用”がセットで強い

LP/商品ページ制作だけだと、売上は伸び切りにくい
広告・イベント・クーポン・楽天内SEO・レビュー運用 まで一体だと成果が出やすい

候補例

Ryuki Design / 楽天運用代行・制作支援各社（例：EC研究室、R6B等）

失敗しない見極め

制作物の納品だけでなく、数字（ROAS/CVR等）で改善提案が出るか
商品登録・更新・イベント対応までどこまで任せられるか

集客・マーケ支援に強い制作会社

このタイプが強い領域

計測設計（何を見るか）→改善（何を変えるか）→検証（どう判断するか）
広告/SEO/CRM（メール・LINE）の組み合わせ

候補例

コマースメディア / AnyMind など

失敗しない見極め

“レポート提出”で終わらず、実装までの体制があるか
90日で何をするか（0-30/31-60/61-90）の計画が作れるか

基幹連携・大規模開発に強い制作会社

このタイプが強い領域

ERP/WMS/POS/会計などと“つなぐ”前提の設計
例外処理（欠品/分納/返品/返金）の運用設計

候補例

ecbeing（BtoB含む）/ インターファクトリー / スパイスファクトリー等

失敗しない見極め

連携の「方式」「頻度」「障害時の切り分け」を図にできるか
データの正（マスター）をどこに置く設計か

越境ECに強い制作会社

このタイプが強い領域

多言語・通貨・税・海外配送・海外決済
ローカライズ（翻訳だけでなく、商習慣・訴求の調整）

候補例

GMOグローバルEC / Shopifyパートナー各社（日本拠点のパートナーを検索して選ぶ）

失敗しない見極め

物流（関税/DDP等）と決済の設計が提案に含まれるか
海外向けの集客（広告/CRM/インフルエンサー等）まで範囲があるか

BtoB ECに強い制作会社

BtoBで必須になりやすい要素

取引先別価格、掛け払い、見積・承認、権限管理
既存の受発注フローを崩さずデジタル化

候補例

ecbeing BtoB / アイル（アラジンEC）など

失敗しない見極め

“現場の運用”まで落とした要件定義（承認・締め・請求）ができるか
既存システム（会計/在庫/顧客）との整合を説明できるか

サブスクECに強い制作会社

サブスクは制作より“継続設計”が勝負

継続率、解約理由、アップセル、同梱などの設計が重要

候補例

Shopify中心の制作パートナー / マーケ伴走型の支援会社など

失敗しない見極め

KPI（継続率・LTV）を前提に、施策の優先順位が組めるか
解約理由の取得→改善までの運用が用意できるか

各社紹介テンプレ（読むだけで比較できる形に統一）

得意領域（プラットフォーム/業界/規模）

対応プラットフォーム（例：Shopify/国産ASP/EC-CUBE/パッケージ等）
得意な商材・業界（食品、アパレル、コスメ、BtoBなど）
得意な規模（小規模立ち上げ／中堅の成長／大規模・多拠点）

支援範囲（制作・運用・集客・物流/CS）

制作：要件定義、設計、デザイン、開発、移行、テスト、公開
運用：更新、商品登録、キャンペーン運用、保守、障害対応
集客：SEO、広告、CRM（メール/LINE）、コンテンツ
周辺：撮影、原稿、CS、物流連携（どこまで実務を担うか）

費用感（初期/月額/施策）

初期：設計/デザイン/開発/移行/テストがどこまで含まれるか
月額：保守のみか、改善（施策実装）まで含むか
施策費：広告運用/CRM/制作追加の単価ルールが明確か
追加費用条件：仕様変更・ページ追加・連携追加の扱い

強み（設計・デザイン・開発・改善）

設計：導線・カテゴリ・検索・購入体験の思想があるか
デザイン：運用しても崩れないルール設計があるか
開発：拡張性、速度、障害対応、セキュリティ運用
改善：計測→仮説→実装→検証のサイクルが回るか

向いている企業／向かない企業

向いている：課題・要件・体制が一致しているケースを具体化
向かない：予算感、スピード感、運用リソースが合わないケース
代替案：段階リリース、プラットフォーム変更、運用内製/外注の切り分け

よくある質問（FAQ）

制作会社と運用代行は分けるべき？

結論は「分ける／まとめるのどちらも正解」ですが、初心者は次のルールで判断すると失敗しにくいです。

まとめる（制作＝運用も同じ会社）が向くケース

公開後も 継続的に改善したい（CVR/LTVの伸びしろが大きい）
社内にEC担当が少なく、意思決定と実行を速く回したい
仕様理解が必要な“連携”が多い（在庫・受注・会計・物流など）

分ける（制作と運用を別会社）が向くケース

運用は内製できるが、制作だけプロに任せたい
モール運用（楽天など）は専業の運用代行が強い、など領域が分かれる
1社依存を避けたい（コスト管理・リスク分散）

初心者が一番安全なやり方（おすすめ）

まずは 制作会社に「公開後90日」だけ伴走してもらう
- 0〜30日：計測整備・不具合/ボトルネック潰し
- 31〜60日：CVR改善
- 61〜90日：LTV改善
その間に、運用を「内製／代行／ハイブリッド」どれにするか決める

分ける場合の注意点（ここで揉めがち）

“責任の境界”を文章で決める（例：不具合／改善／更新作業の範囲）
アカウント（GA4/GTM/決済/Shopify等）の所有者は原則自社にして、権限付与で運用する

リニューアルでSEOを落とさないために必要なことは？

SEOで一番事故が多いのは「URL変更」と「内部リンク/正規化の崩れ」です。公開前に8割決まります。

最低限のチェックリスト（重要順）

旧URL → 新URLの対応表（全件）を作る
“近いページへまとめて転送”より、原則は 1対1で対応させる
301リダイレクトをサーバー側で設定する（恒久転送）
新サイト側は、内部リンクを旧URLのまま残さない（新URLへ直す）
新URLのサイトマップを用意する
重複ページが出るなら canonical（正規URL） を設計する
ドメイン変更なら、Search Console の アドレス変更も検討する
公開後は Search Console で クロール/インデックス/404/リダイレクトを監視する

初心者がやりがちなNG

重要ページだけ転送して、他を放置（404大量発生）
転送のチェーン（A→B→C）を作る（評価もユーザー体験も落ちやすい）
タイトル/見出し/本文を“気分で”大きく変えすぎる（意図せず別ページ扱いに近づく）

制作会社に投げると良い質問

「URL対応表は誰が作り、どのタイミングで検証しますか？」
「公開後、何を見て“問題なし”と判断しますか？」（監視項目と判断基準）

Shopify等の“アプリ追加”はどこまで必要？

アプリは便利ですが、入れすぎると 月額コスト増・表示速度低下・運用が複雑化しがちです。目安は「本当に必要な欠けている機能だけ」。

まずは“標準＋テーマ”で満たせるか確認

テーマ設定でできること（表示・導線・軽微なUX改善）
公式機能でできること（基本的な販売/配送/決済/レポート等）

アプリを入れる判断基準（迷ったらこれ）

売上に直結する（CVR/LTVが上がる根拠がある）
運用工数が減る（手作業が明確に減る）
代替手段が高コスト（開発よりアプリが現実的）

入れがちな定番カテゴリ（必要な時だけ）

レビュー、定期購入（サブスク）、検索/絞り込み強化、配送最適化、CRM（メール/LINE）など

安全に増やすコツ

いきなり複数入れず、1つ入れて1つ効果検証（数値が動いたか）
請求（アプリ課金）と権限（インストール権限）を必ず管理する
使わないアプリはアンインストールし、履歴も把握する

商品登録や撮影はどこまで任せられる？

かなり任せられます。ただし成果に直結するので、丸投げより「型を決めて任せる」がうまくいきます。

任せやすい領域（外注向き）

商品登録（CSV整備、属性の付与、画像リサイズ/圧縮）
撮影（物撮り、モデル撮影、切り抜き、色調整）
原稿制作（説明文、FAQ、比較表、ガイドページ）
特集/LP制作（テンプレ化できると強い）

任せにくい領域（自社の関与が必要）

商品の“推しポイント”の定義（何が価値か）
返品/保証/配送ポリシーの最終決定（CSや現場運用に直結）
ブランドトーン（言葉遣い、世界観の線引き）

失敗しない発注のコツ

まず 商品ページのテンプレ（型）を決める（見出し順・写真構成・必須項目）
撮影は カット定義を作る（正面/背面/使用シーン/サイズ感など）
1カテゴリ分だけ 試作→レビュー→量産（最初から全量発注しない）

公開後の保守・改善はどの契約形態が最適？

初心者は「保守だけ」か「保守＋改善（伴走）」で迷いがちです。違いは、ざっくりこうです。

スクロールできます

契約形態	向いている状況	注意点
保守のみ（月額固定）	小さく安定運用したい／改修は少なめ	“改善”は別途になりやすい
保守＋改善（リテイナー）	公開後に伸ばしたい／改善を回したい	月に使える工数・優先順位付けが重要
運用代行込み	社内に手がない／更新・登録まで任せたい	作業量の定義が曖昧だと揉める
スポット（都度見積）	たまに改修するだけ	速度が出にくい／費用が読みにくい
成果報酬型（条件付き）	施策の成果が測りやすい領域のみ	指標定義と計測設計が必須