MakeShopのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

MakeShopのシステム開発は、標準機能を業務の中心に置き、必要な連携を設計したうえで、6つの工程を順に進めると、費用と納期の膨張を抑えられます。

開発範囲、要件整理から定着までの流れ、費用相場と見積もりの確認点を、順に見ていきます。全体像は、MakeShopのシステム開発の完全ガイドもご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

MakeShopのシステム開発の全体像

MakeShopは、商品管理、受注、会員、決済、配送、販促を備えたSaaS型のEC構築プラットフォームです。

業務の中心には標準機能を置き、足りない機能は、設定、オプション、API、外部サービスの順に補います。

標準機能を中心に業務を組み立てるSaaS型

MakeShopの標準機能と利用条件を把握しておくと、標準に寄せる範囲と、追加対応が要る範囲を判断できます。標準機能の中身と料金の条件は、導入の前に確かめておきます。

標準機能：商品、カテゴリ、在庫、注文、会員、クーポン、ポイント、定期購入を運用
プレミアム料金：初期11,000円、月額13,750円（税込）、販売手数料0円（出典: GMOメイクショップ株式会社「料金プラン」、2026年8月確認）
利用料の範囲：デザイン、商品登録、移行、連携開発、運用支援は含まない
利用ショップ：国内11,000社（出典: GMOメイクショップ株式会社「makeshop apps developers」、2026年8月確認）

要件が標準機能に近いほど、立ち上げは短い期間で済みます。一方で、特殊な承認や複雑な在庫引当を標準画面に無理に組み込むと、現場の負担が増えます。そのため、業務を変えられる部分と、システムで守る部分を分けて考えます。

標準・オプション・連携・別基盤の境界

機能をどこに持たせるかは、発注側と開発会社で、要件の複雑さと各システムの役割を見て決めます。その際は、機能ごとに実現方法と料金を確かめます。

実現方法：標準機能、設定、公式オプション、API、個別開発、別基盤の順に検討
BtoB対応：会員制は標準で対応できる場合があります
追加要件：取引先別価格・商品表示、見積書、承認、基幹との受発注連携には、BtoBオプションやAPI開発を組み合わせます
CRM機能：購買データ連携、RFM・LTV分析、メール・LINE配信、カゴ落ち対策、効果検証
CRM料金：利用料と有償機能を確認

makeshop CRM byGMOの公式料金は初期55,000円、月額33,000円以上で、一部機能は有償です（出典: GMOメイクショップ株式会社「makeshop CRM byGMO」、2026年8月確認）。また、MakeShopとCRMの担当範囲を先に決めておくと、二重入力やデータの食い違いを防げます。

ポイント

迷う機能は、まず標準機能に寄せられるかを見ます。寄せにくい機能だけを、設定やオプション、API、外部サービスで補うと、費用と納期の膨らみを抑えられます。

MakeShopのシステム開発の進め方

各段階の完了条件を次へ進む目印にできます。

開発は6フェーズに分けて進めます。前半は要件整理、選定、設計・開発で、後半はテスト、稼働、定着です。

フェーズごとに担当者と判断時期を決めておくと、誰がいつ判断するかが分かりやすくなります。

各フェーズの終了条件を決めてから次へ進めると、後工程の手戻りを抑えられます。

特に、商品・会員・注文のデータは、業務責任者を早い段階から巻き込みます。

1. 要件整理：現行業務と達成したい成果の言語化

「ECサイトを作る」だけでは、何をもって成功とするかが定まりません。そこで、発注側が達成したい成果を定義しておきます。

たとえば、受注入力を1日何時間減らすか、在庫差異を月何件以下にするかを定めます。

リピート顧客への配信を何日以内に実施するかなど、達成基準まで具体化しておきます。

業務フローには、注文の流れ（商品登録、受注確認、決済）と、出荷以降の流れ（出荷、返品、返金）を記します。さらに、問い合わせ、会員情報の更新、販促も含めます。

現場の担当者がExcelやメールで補っている例外処理も、業務フローに含めます。そのうえで、初回リリースの範囲を、商品・在庫、受注・会員、権限・優先度の3つの観点で整理します。

商品・在庫：商品マスタの責任部署、SKUとJAN、在庫の正本
受注・会員：送料と税、会員ID、返品時の在庫戻し、定期購入の休止
権限・優先度：個人情報へのアクセス権限、Must・Should・Couldの分類

現場の担当者には、「今困っていること」と「失敗すると売上や顧客に影響すること」を分けて聞きます。

2. 選定：MakeShopで足りる範囲と連携先の判断

要件を、MakeShopの標準機能、オプション、APIや外部サービス、別基盤のどこで扱うかで分類します。

EC-CUBEやShopifyと比べるときは、機能の多さより、業務を運用する人とデータの正本を基準にします。自由な業務ロジックが多い場合は、別基盤が有利になることもあります。ただし、その分、決済・セキュリティ・運用を自社で広く担う負担が増える可能性があります。

候補の運用や障害対応の差は、ベンダーに具体的に聞いて初めて見えてきます。

標準機能：MakeShopの標準機能で対応できるか
操作担当：管理画面で誰が操作するか
変更影響：仕様変更がどこへ影響するか
障害対応：障害時に手作業へ切り替えられるか
API連携：データごとの方向・頻度、再送、重複防止、日次照合、認証管理

3. 設計・開発：画面、データ、連携の責任範囲の確定

設計では、サイトマップや購入導線に加えて、データ項目と業務ルールを決めます。画面とデータは、表記の揺れや扱いのずれが稼働後に響くため、早めに揃えておきます。

データ規則：商品コード、バリエーション、税区分、販売期間、在庫数、会員グループ、取引先コードを統一
マスタ管理：MakeShop、基幹、WMS、会計、CRMのどれを正本にするか文書化
移行データ：重複、表記揺れ、欠損、画像URL、販売終了商品の扱いを決める
購入導線：スマートフォンで検索からカート、会員登録、決済、注文完了まで確認

開発者向けサイトでは、MakeShop APIで注文を会計へ反映し、顧客データをマーケティングに使えると説明されています（出典: GMOメイクショップ株式会社「makeshop apps developers」、2026年8月確認）。

旧APIは2026年11月2日15時以降に閉塞予定のため、新規開発では次世代APIとGraphQLを前提に設計します。利用登録、Webhook、認証を設計に含め、レート制限も、あわせて考えます。既存の連携は、移行期限を確認したうえで、切替リハーサルを計画します。

4. テスト：正常系だけでなく例外処理の検証

画面の表示だけで終わらせず、商品登録から購入、決済、在庫引当までを通して確認します。そのうえで、出荷、配送通知、会計計上、CRM配信までの流れも確かめます。

テストケースには、在庫切れや複数配送先、クーポン併用の場合を含めます。さらに、キャンセル、返品、返金、定期購入の休止も、例外処理として検証します。会員ランクの変更、取引先別価格、APIのタイムアウトも、テストします。

本番の前に、少量の検証移行と全量のリハーサルを行います。照合では、件数に加えて、商品や注文の中身も確かめます。

商品・会員：商品コード、価格、画像、会員属性
注文・配送：注文金額、税、配送先、ポイント残高
受入基準：実際の担当者が操作し、業務を続けられる結果を事前に定める

5. 稼働：切替手順と障害時の戻し方の決定

公開準備、サイト切替、当日の確認事項を事前に整理し、担当者が順に実行できる状態にしておきます。

公開準備：DNS・ドメイン、決済審査、メール、法定表示、返品特約、プライバシーポリシーを確認
計測・切替：広告計測と検索設定を確認し、旧サイト停止、最終注文取込、在庫の基準時点を分単位で決定
公開当日：注文受付、決済、在庫、通知メール、出荷データの監視表を用意

GMOメイクショップは、makeshop byGMOがPCI DSS v4.0.1に2025年9月1日付で準拠したと公表しています（出典: GMOメイクショップ株式会社「PCI DSS準拠について」、2025年）。ただし、管理者IDの権限や退職者のアカウント、個人情報の閲覧範囲は、事業者側の運用課題として残ります。

経済産業省のガイドライン6.0版も、EC加盟店に脆弱性対策、EMV 3-Dセキュア、不正ログイン対策を示しています（出典: 経済産業省「クレジットカード・セキュリティガイドライン」6.0版、2025年）。脆弱性対応や委託先の管理も、運用のなかで続けて担う課題です。

6. 定着：運用指標と改善サイクル

稼働後は、システムを使える状態から成果が出る状態へ進めます。その際は、指標と運用手順に沿って改善します。時期によって見る指標が変わるため、節目ごとに確認していきます。

最初の1か月：注文エラー、在庫差異、問い合わせ、手作業時間、キャンセル率を毎週確認
2か月目以降：購入率、客単価、リピート率、配信売上、LTVを見て商品情報や導線を改善
例外時の手順：API再送、在庫の正本、返品時のポイント処理、不審ログインの報告先を定める
月次改善：追加開発の前に標準機能、設定、運用変更で解決できるか確認し、保守費を抑える

運用マニュアルには、画面の操作だけでなく、例外時の判断も書いておきます。

ポイント

迷ったときは、各フェーズの終了条件を満たしているかを基準に、次へ進むかを決めます。終了条件が曖昧なまま進むと、後工程で手戻りが増えます。

MakeShopのシステム開発にかかる費用相場

対応範囲が広がると推定レンジも上がります。

費用は、公式の利用料金と、制作・移行・連携・運用にかかる導入費に分けて考えます。ここに示す開発費は、一律の公式価格ではなく、公式のプランとオプション料金、一般的なEC・業務システム開発の相場から組み立てた、編集用の推定レンジです。

実際の金額は、商品数やデータの状態、連携数で変わります。デザインや要件の複雑さによっても、差が出ます。

標準的なEC開店は30万〜100万円程度の目安

標準機能を使ったEC開店では、作業範囲と素材の準備状況が、導入費と期間を左右します。導入費と期間の内訳は、作業範囲ごとに分けて示します。

導入支援費：30万〜100万円程度の推定。初期設定、基本デザイン、決済・配送設定、商品登録、テスト、操作説明を含む
期間：2〜6週間程度。画像・説明文の準備や依頼する登録件数で変わる
別途料金：プレミアムプランは初期11,000円・月額13,750円（出典: GMOメイクショップ株式会社「料金プラン」、2026年8月確認）
制作・登録範囲：テンプレート調整か独自レスポンシブデザインかで差が出る。外注時は登録項目、画像加工、バリエーション、公開確認の単位を明示

「サイト構築一式」とだけ書かれた見積書では、作業に含まれる件数を確認しておきます。

デザイン刷新やデータ移行を含む場合の100万〜300万円程度

商品・会員・注文の移行、デザイン刷新、アクセス解析、CRM設定を含む場合は、100万〜300万円程度の推定レンジです。

費用は、データの件数そのものより、移行の条件によって変わります。移行の条件は、期間やデータの整理、対象範囲ごとに確かめておきます。

移行期間：1〜3か月程度
項目と認証：移行元と移行先の項目の一致度、会員ID・パスワードの安全な引継ぎ
データ整理：商品コード、商品名、税区分、価格、在庫、カテゴリ、画像ファイル名、会員ランクを一覧化
移行対象：対象外の商品や退会会員を定義する。全件移行ではクレンジング費や追加テスト費が増えやすい

BtoB・基幹連携は300万〜800万円程度の推定

取引先別価格・商品表示、決済制御、見積書を含む場合は、300万〜800万円程度の推定です。カタログ注文や在庫・会計・基幹連携も含む場合が、この推定の前提になります。

費用の幅は、連携条件や独自ロジックで広がります。サービス料金と開発費は、分けて見積もります。プランの料金と、開発期間や追加要件による費用の増減を、それぞれ見比べます。

開発期間：3〜6か月程度
プレミアム：初期11,000円・月額13,750円以上
エンタープライズ：初期11,000円・月額55,000円以上
取引先別価格：一部の基本機能はプランにより提供形態が異なる
追加要件：連携や独自ロジックに応じて開発費が増える

取引先別価格などの一部の基本機能は、プレミアムでは買い切り110,000円、エンタープライズでは標準搭載と案内されています（出典: GMOメイクショップ株式会社「makeshop BtoB 料金モデル」、2026年8月確認）。

基幹連携では、データ形式、連携方向、リアルタイム性が費用を左右します。加えて、エラー監視、受発注の締め処理、請求・債権管理も、費用を左右します。

複雑な課金や独自の会員・予約・承認ロジックがある場合は、800万〜2,000万円超の推定になることもあります。その場合は、GMOクラウドECなどオーダーメイド型との比較が必要です。

ポイント

費用の目安は、対応範囲によって段階的に変わります。標準のEC開店か、移行やBtoB・基幹連携まで含むかを先に決めると、見積もりの比べ方がそろいます。

MakeShopの見積もりを取る際のポイント

3領域を揃えると提案内容を同じ条件で見比べやすくなります。

見積もりは、合計金額だけでなく、成果物、前提条件、対象外作業、保守範囲をそろえて比べます。特に、SaaSは利用料が目に見えるため、制作会社の見積に含まれない作業を見落としがちです。

このため、提案を同じ条件で比べられるよう、依頼資料と見積書の記載を整えます。

要件定義書とデータ一覧の事前準備

依頼の前に、事業目的と対象ユーザー、既存システムを1枚にまとめます。商品数や会員数、月間注文数も、同じ資料に書いておきます。決済・配送の必要範囲、連携対象、希望公開日も記します。

商品・会員・注文・在庫のサンプルデータは、匿名化して渡します。移行元の項目一覧も添えます。画面の要望だけでは工数を読めないため、業務フローとデータの流れを中心に伝えます。

見積書では、成果物と作業を個別に記載してもらい、対象件数と修正回数を確認します。

設計・制作：要件定義書、画面一覧、デザインデータ
設定・移行：MakeShop設定、商品登録、データクレンジング、CSV移行
検証・公開：API仕様書、テスト計画、操作マニュアル、リリース支援

要件がまだ固まっていない場合は、確定部分と概算部分を分けた段階見積にしておくと、後から増額の理由をたどれます。

公式パートナー区分と連携実績の確認

発注先の候補は、得意領域と自社要件への適合性を照らし合わせて選びます。得意分野と実績、体制まで含めて見ると、候補の違いが分かりやすくなります。

得意領域：デザイン制作、API・基幹連携、運用代行、CRMなど
実績の適合性：公式パートナー掲載だけで保証されないため、商品数、業界、連携数、BtoB要件を照合
体制・保守：次世代API、旧API移行、障害一次対応、受付時間、担当者の継続性を質問
過去事例：移行前後の注文数、作業時間、エラー件数、売上やリピート率の変化を確認
面談者：可能なら担当予定のディレクターとエンジニアの両方に参加を依頼

契約前に詰める追加費用・納期・セキュリティのリスク

追加費用、納期、連携、情報管理は、契約前に条件を具体化しておきます。契約書や仕様書には、費用の要因から情報管理までを項目ごとに書いておきます。

追加費用の要因：データ欠損、仕様変更、API制限、決済審査の遅れ、確認担当者の不足
契約条件：変更管理、追加開発単価、納期影響、受入基準、検収、キャンセル費用
連携条件：テスト環境、テストデータ作成者、障害通知方法を契約書や仕様書に記載
情報管理：管理者権限、ログ、脆弱性診断の分担、バックアップ、事故時の報告手順

消費者庁の通信販売ガイドでは、販売価格や送料、支払時期・方法、引渡時期が、表示の論点として挙げられています（出典: 消費者庁「通信販売」、2026年8月確認）。このほか、返品特約や事業者情報も論点になります。

法務の判断は開発会社に任せず、自社に必要な表示を法務・管理部門と確認します。

ポイント

見積もりを比べるときは、合計金額より先に、成果物、前提条件、対象外作業、保守範囲がそろっているかを見ます。そろっていない見積は、依頼資料を整えてから比べ直します。

よくある質問（FAQ）

料金やAPI仕様は変更される可能性があるため、発注前に公式情報と個別見積を確認してください。

MakeShopのシステム開発費用はいくらかかりますか？

要件と公開料金から算出した目安で、一律の公式価格ではありません。費用の目安は、対応範囲ごとに分けて示します。

標準EC開店：30万〜100万円程度
デザイン刷新・データ移行込み：100万〜300万円程度
BtoB・基幹連携込み：300万〜800万円程度の推定
別途かかる費用：月額利用料、決済手数料、アプリ、CRM、物流、保守運用費

MakeShopのAPI連携を依頼するときに何を確認すべきですか？

仕様書には、連携対象と日々の運用条件を具体的に書いておきます。

データ範囲：注文、商品、在庫、会員の対象、連携方向、更新頻度
API運用：次世代API、認証、Webhook、再送、重複防止、レート制限
監視・移行：エラー監視、日次照合、旧APIの移行期限

従来APIは2026年11月2日15時以降に閉塞予定のため、既存システムでは移行計画を先に作ります（出典: GMOメイクショップ株式会社「makeshop apps developers」、2026年8月確認）。

BtoBの受発注システムもMakeShopで構築できますか？

構築できます。会員制ECや取引先限定のアクセスは、比較的始めやすい方法です。

取引先別価格・商品表示、決済制御、見積書、カタログ注文、基幹連携が必要な場合は、BtoB向けプランやオプション、個別カスタマイズを組み合わせます。

掛け率、承認、請求、在庫、代理注文が複雑な場合は、MakeShopだけで完結させず、基幹や販売管理との間で、どこまでを誰が受け持つかを設計します。

MakeShopの開発期間はどのくらいですか？

標準EC開店は2〜6週間、デザイン刷新や移行は1〜3か月、BtoB・基幹連携は3〜6か月程度が推定の目安です。商品データの整理、社内確認、決済審査、連携先との調整が遅れると、開発会社の作業だけでは短縮できません。

公開日を先に決めるより、要件整理、移行リハーサル、受入テスト、切替予備日を含めて計画します。

ポイント

費用、API、BtoB、期間の答えは、要件と条件で変わる目安として扱います。発注前には、公式情報と個別見積の両方で確かめます。

まとめ

成功の要点は、標準機能の範囲、必要な連携、データと運用の責任者を先に決めておくことです。

要件整理から定着まで6つの工程に分けると、費用と納期の根拠を相手に説明しやすくなります。

最初に決めるシステムの境界

商品・注文・会員をMakeShopに集約するか、在庫や会計は別システムを正本にするか、CRMで顧客分析と配信を行うかを、発注側と開発会社で決めます。BtoBでは、取引先別価格、見積、受発注、請求のうち、どこまでをECに持たせるかを整理します。

旧APIから次世代APIへの移行期限も踏まえ、将来の変更に耐える連携方式を選びます。

次の一歩は業務フローとデータ一覧の作成

発注前に資料を整え、候補企業と実現方法を同じ条件で比べます。

業務とデータ：現行業務、商品・会員・注文データを一覧化
体制と要件：連携先、必須機能、公開希望日、社内承認者を整理
実現方法：複数社に相談し、標準機能、オプション、API、個別開発を比較

見積の前提と保守範囲も確かめておきます。小さく始めて実績データをためながら、必要性が確認できた機能から広げていきます。

▼全体ガイドの記事
・MakeShopのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。