ECリアーキテクチャの発注は、現行データの分析、数値要件と移行条件の定義、外注先との合意の順に進めます。この順で準備しておくと、売上への影響を抑えた基盤移行につながります。
▼全体ガイドの記事
・ECリアーキテクチャの完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
ECリアーキテクチャの発注前に行う準備
Gartnerの調査によると、年商10億円以上のEC事業者の約65%が、現行システムの拡張性不足を成長の阻害要因に挙げています。
ECリアーキテクチャでは、既存の売上を守りながら移行しなければなりません。ECサイトは24時間365日売上が発生するため、停止は収益の損失に直結します。
Shopify Plusの調査では、月商1億円規模のサイトが1時間停止すると、機会損失は約140万円に相当します。そのため、発注前の準備で移行リスクを洗い出しておきます。
現行システムのトラフィックピーク分析と移行タイミングの設定
移行時期を決めるには、繁忙期の負荷と性能の変化を先に知っておく必要があります。発注前に、Google Analytics 4やAdobe Analyticsで過去2〜3年分の年間トラフィックを分析し、月別・週別・時間帯別に把握します。
分析の対象には、ブラックフライデー（11月第4金曜日）やサイバーマンデーなどのピーク日時を入れます。12月のクリスマスセール、1月の初売り、5月のゴールデンウィークセールも含めます。そのうえで、次の項目を記録します。
- アクセスと負荷：ピーク時の同時セッション数と、通常時との倍率。
- リソース使用率：CPU、メモリ、データベース接続数の推移。
- 性能の閾値：エラー率やレスポンスタイムが悪化し始める水準。
分析後は、移行作業を止める期間を社内で合意し、文書にまとめます。たとえば、10月1日〜1月31日の繁忙期は本番変更を凍結し、月次売上ランキングのバッチが走る月末3日間は大規模なデータベース変更を避けます。
禁止期間を外注先に事前に伝えておけば、プロジェクトの日程に組み込まれ、繁忙期直前の無理なリリースを避けられます。
あるアパレルEC事業者は、ブラックフライデーの2週間前にリリースを強行しました。その結果、新決済システムとの連携バグで約3,000件を処理できず、推定4,000万円の売上損失を招いたうえ、顧客の信頼も大きく低下しました。
特に、移行時期の決定は、技術検討と同等かそれ以上に重要な経営判断です。
リアーキテクチャ向けRFP（提案依頼書）の作成方法
ECリアーキテクチャのRFPには、新規構築より詳しい現行システムの情報が必要です。外注先が現実的な提案と見積もりを作れるよう、次の4カテゴリを記載します。
- 技術スタック：現行基盤、開発環境、インフラ、外部連携の情報。
- 業務要件と制約：現状の課題、移行後の目標、時期、SLA。
- データ移行：移行対象、データ量、クレンジング、整合性確認の要件。
- SEOとマーケティング：URL方針、リダイレクト、構造化データ、流入と売上。
技術情報には、基盤（EC-CUBE、Magento、Shopify、フルスクラッチなど）、言語とバージョン、DB種別・レコード数・容量を記載します。インフラは、オンプレミス、AWS、GCP、Azureなどの構成で示します。
決済・物流・ERPとの連携も、あわせて示します。業務情報には、性能のボトルネック、拡張性の限界、技術的負債を記載します。さらに、ピーク時の処理能力やデプロイ頻度の目標、移行禁止期間、推奨移行ウィンドウを示し、稼働率とレスポンスタイムのSLAも含めます。
データ移行では、商品マスタ、顧客、注文履歴の対象を挙げます。レビューや画像・動画も対象に含めます。各件数と容量、データクレンジングの要否、移行後の整合性確認の方法も示します。
SEOの面では、リダイレクト対象のURL数を概算します。現在設定している構造化データの種類や、自然検索からの流入数と売上への貢献率も記載します。
4カテゴリをそろえると、外注先は現実的なスケジュールと費用を提示しやすくなります。
ピーク時パフォーマンス要件の仕様書への盛り込み方
曖昧な表現のままだと、開発後に速度やセール時の稼働をめぐる問題が起きます。そのため、パフォーマンス要件は仕様書で数値として定義します。
非機能要件の数値定義と負荷テスト合格基準の設定
仕様書では、ページや処理に応じた応答時間の合格値を数値で定めます。次のとおり設定します。
- 商品一覧：通常時・ピーク時ともに95パーセンタイルで2秒以内。
- 商品詳細：95パーセンタイルで1.5秒以内。
- カート・チェックアウト：95パーセンタイルで3秒以内。
- 決済確定処理：APIを含め99パーセンタイルで5秒以内。
- Google Coreウェブバイタル：LCP 2.5秒以内、FID 100ms以内、CLS 0.1以下。
Googleの調査によれば、読み込み時間が1秒から3秒に延びると、モバイルの直帰率は32%増加します。また、速度は売上にも影響します。
スループット要件は現行の実績を基準に設定し、ピーク倍率は分析データから算出します。負荷試験には、k6、JMeter、Gatlingなどを使います。
- 同時接続：通常時は実績の1.5倍以上、ピーク時は通常時の5〜10倍。
- 注文と在庫：毎時最低XX件、注文後10秒以内に在庫反映。
- 持続負荷：500人で10分、エラー率0.1%以下、95パーセンタイル2秒以内。
- スパイク負荷：60秒で0人から1,000人へ増加、10分以内に応答を回復。
注文処理は、現行ピーク実績の2倍を目標にします。あわせて、スパイク時にも正常に動くことを確認します。
負荷テストのシナリオと合格基準を契約書に組み込んでおけば、リリース前の受入条件が明確になり、性能不足によるトラブルを防げます。
オートスケーリングとインフラ設計の発注仕様への反映
AWS、GCP、Azureなどのクラウドを使う場合は、スケーリング、CDN、データベースの条件を仕様書で定めます。
- スケーリング：起動指標とサーバー・コンテナの最小数、最大数。
- 稼働と費用：追加容量は検知後5分以内、月額上限と超過通知の設定。
- CDN配信：CloudFront、Fastly、Cloudflareによる画像・CSS・JavaScriptのキャッシュ。
- DB設計：読み取り専用レプリカ、クエリ時間、接続プールの定義。
画像配信は、ピーク時のサーバー負荷の約60〜70%を占める場合があります。CDNの設定で負荷を半分以下にできるケースもあります。
DBでは、商品検索・一覧などの読み取りと、注文・在庫更新の書き込みを分けます。クエリは95パーセンタイルで100ms以内を目標とし、接続プールも指定します。
外注先が設計の段階から適切なアーキテクチャを選べるよう、DBの役割分担と性能の条件は仕様書に明記しておきます。
段階的リリース計画の発注仕様書への記載方法
全ユーザーを一度に新システムへ移すと、予期しない不具合が全体に及び、売上損失や顧客離反につながります。そこで、カナリアリリース、A/Bテスト、段階的ロールアウトを組み合わせます。
カナリアリリースの仕様書への明記方法
カナリアリリースは、新システムへ流すトラフィックを、全体の1〜5%など少量から段階的に増やす方法です。仕様書には、その技術要件と移行判断の基準を定めます。
- トラフィック分割：新旧システムへの流入割合の制御。
- 並行稼働と同期：注文・在庫データをリアルタイムで同期するか、新システムから旧DBを参照するか。
- 比較監視：エラー率、応答時間、コンバージョン率を新旧で比べるダッシュボード。
トラフィックを分ける機能には、AWS Application Load BalancerのWeight機能やCloudflare Traffic Splittingを使えます。
次の段階へ進む条件は、新システムのエラー率が0.5%以下で、95パーセンタイルの応答時間が要件内に収まった状態が24時間続くことです。条件を満たしたら、次の段階でトラフィックを倍増します。
ロールバック条件は、エラー率が旧システムの2倍を超えた場合か、決済エラーが3件以上起きた場合です。そのときは、全トラフィックを即座に旧システムへ戻します。
判断基準を事前に合意しておけば、本番移行時の意思決定が進み、判断の遅れによるリスクを抑えられます。
大規模ECでの例では、5段階で移行します。1%を48時間、5%を48時間、20%を72時間、50%を72時間監視し、最後に100%へ移行する計画です。
A/Bテストと段階的ロールアウトの要件定義への組み込み
リアーキテクチャ後も、商品ページの改善やチェックアウトの最適化など、継続的な改善を想定します。そのため、A/Bテストの環境を新システムに組み込んでおきます。
- フィーチャーフラグ：LaunchDarkly、Split.ioなどのサービスを使うか、カスタム実装にするかの決定。
- ユーザー別配分：新規会員と既存会員、モバイルとPC、地域ごとの割り当て。
- 効果測定：コンバージョン率、客単価、セッション継続時間などのKPIと、統計的有意性の計測。
機能ごとの公開計画も定めます。たとえば、新チェックアウトは、新規会員、過去6か月以内に購入した既存会員、全ユーザーの順に広げられます。
新レコメンドエンジンは、商品詳細、カート、トップページの順に展開できます。機能ごとに独立した計画を作れば、複数の機能を並行して管理できます。
同じユーザーが旧システムと新システムを行き来しないよう、セッション単位で一貫してルーティングする要件も必要です。
SEO影響を最小化するための要件定義
ECリアーキテクチャでは、SEOへの影響も管理しておく必要があります。自然検索は多くのECサイトにとって主要な集客経路で、順位が下がれば売上にも響きます。
Ahrefs社の調査によれば、リプラットフォーム後に自然検索流入が30〜50%減る例は珍しくなく、元の水準へ戻るまで6か月から1年以上かかる場合もあります。
リダイレクトマップの作成と仕様書への組み込み
URLが変わる場合は、リダイレクトマップを作ります。まず、Google Search ConsoleとGoogle Analytics 4で、全URL、自然検索流入数、検索順位を一覧にします。
続いて、新システムのスラッグルールとカテゴリ階層を確定し、旧URLと新URLを対応させます。10,000件を超える場合は、Screaming Frogなどによる自動マッピングと、SEO担当者の手動確認を組み合わせます。
仕様書では、実装方式と運用条件を具体的に定め、次の基準を受入要件にします。
- 転送方式：301を使い、検索エンジンに評価の移転を認識させない302は禁止。
- 転送経路：AからB、BからCのようなチェーンは最大1ホップまで。
- 速度：リダイレクトによる追加のレスポンス時間を50ms以内。
- 更新管理：Gitなどによる版管理と、新規コンテンツ追加時の更新手順。
- 監視：移行後30日間は毎週、その後3か月は毎月の正常動作の確認。
リダイレクトの登録数が多い場合は、Nginxやロードバランサーで処理するか、アプリケーション層で処理するかを選びます。その際は、性能への影響と選定理由も示します。
構造化データの移行要件と技術的SEO要件の定義
Schema.orgの構造化データは、検索結果に星評価・価格・在庫状況を表示するために使われます。そのため、リッチスニペットの情報を移行後も正確に引き継ぐ必要があります。
現行実装のProduct、Review、BreadcrumbList、FAQPageなどを一覧にし、新システムでも同等またはそれ以上のデータを実装します。Productには、name（商品名）、description（商品説明）、image（商品画像URL）を含めます。
さらに、価格のprice、通貨のpriceCurrency、在庫状況のavailabilityも指定します。また、集計評価のaggregateRatingも加えて、Googleが推奨する構造化データの実装に準拠します。
- サイトマップXML：商品・カテゴリ・ブログ別の自動生成と、各ファイル50,000件以内。
- URL正規化：色・サイズなどのパラメーター付きURLを、canonicalタグで正規化。
- 多言語とクロール：多言語・多通貨対応の場合のhreflang設定と、不要ページのrobots.txtによる除外。
- 表示品質：全ページのCore Web Vitals（LCP・FID・CLS）をGoodに保ち、PCとモバイルの内容をそろえる。
これらを仕様書と受入チェックリストに含めることで、移行後の技術的SEOも確認できます。
決済システム切り替えとPCI DSS対応の発注時確認事項
決済を切り替える際は、慎重な対応が必要です。候補には、Stripe、GMO Payment Gateway、SBペイメントサービスなどがあります。
プロバイダを変えると実装の作業が伴い、PCI DSS（Payment Card Industry Data Security Standard）への対応も必要になります。PCI DSS v4.0は2024年3月に施行され、カード会員データを扱う事業者に準拠を求めます。違反すると、月額5,000〜100,000ドルのペナルティや、カード決済停止のリスクがあります。
決済プロバイダの選定と外注先への確認事項
決済プロバイダや外注先を選ぶ際は、まず準拠実績と統合経験を確認します。そのうえで、対応手段とトークン移行の可否も見ます。
- PCI DSS体制：準拠実績と対象範囲の理解。
- プロバイダ統合：候補社の認定状況と同規模ECでの統合実績件数。
- 決済手段：クレジット、コンビニ、銀行、QR、後払い、BNPL。
- カード移行：定期決済トークンの移行可否と再登録手順。
外注先がQSA（Qualified Security Assessor）などのセキュリティ専門家と連携できる体制かも確認します。
候補として、Stripe、GMO PG、SBペイメントサービス、Squareなどがあります。公式パートナー認定と同規模ECでの統合実績を照合します。
Stripeは、カード番号を自社サーバーに通さないトークン化を採用しています。そのため、自社でPCI DSS SAQ A（負担が最も少ない自己評価問診票）への準拠を実現できるよう設計されています。
一方で、旧来の決済ゲートウェイでは、カード番号が自社サーバーを経由している可能性があります。その場合、PCI DSS準拠の対象範囲は大幅に広くなります。移行前に、外注先と対象範囲の変化を整理します。
定期購入サイトでは、トークン移行が技術的に不可能な場合、会員にカード情報を再登録してもらう必要があります。
再登録の過程で解約率が上がるおそれがあります。ある定期購入型ECサービスでは、変更時に約15%が再登録せず解約したと報告されています。このリスクは数値で把握し、決済切り替えの計画に織り込みます。
PCI DSS対応を契約書・仕様書に反映する方法
契約書では、自社と外注先のPCI DSS準拠の範囲と責任を明確にします。あわせて、セキュリティ診断の実施義務、費用負担、カード会員データのフロー図の提出も定めます。
契約には、四半期ごとの外部スキャン費用をどちらが負担するか、侵害発生から何時間以内に通知するか、認定後の継続的な準拠を誰が担うかも盛り込みます。
Stripeなどの決済プロバイダが提供するSandbox環境では、実カード情報を使わず、本番相当の決済フローを試せます。テスト環境の要件も仕様書に明記します。
- 正常系：カード決済の完了と、コンビニ払い番号の発行の確認。
- 異常系：残高不足、有効期限切れ、不正カードの3Dセキュア認証失敗の確認。
- 障害時：決済APIタイムアウト時の処理と、二重決済の防止の確認。
テストケースを事前に作って受入条件に含めれば、リリース後の決済トラブルを防げます。
受入テストの設計と品質保証の方法
受入テストでは、新機能だけでなく、現行システムと同等の機能が新システムでも動くことを検証します。発注前に外注先と設計を合意しておけば、完了の定義が明確になります。
購入フローのE2Eテスト設計と自動化要件
購入フローのE2E（エンドツーエンド）テストは、ECサイトで特に重要です。PlaywrightやCypressなどで自動テストを構築すれば、手動確認の工数を減らし、既存機能の劣化を継続的に検知できます。
テストの範囲には、主要な購入シナリオを含めます。初回購入から定期購入まで、次の流れを確認します。
- 初回購入：登録（メール認証を含む）、ログイン、検索、カート、住所・決済、注文、確認メール。
- 再注文：マイページの注文、アドレス帳、保存済みカードでの決済。
- 特典利用：クーポン・ポイント適用、割引額、決済後のポイント付与。
- 在庫競合：残り1点を2人が同時購入する場合の排他制御。
- 定期購入：初回申込、翌月の自動決済、解約まで。
自動テストは毎日のCI/CDで実行します。1件でも失敗したら本番デプロイを止める設定も有効です。
決済テスト環境の用意と受入テストの完了条件
本番と独立したサンドボックスを用意し、カード情報を使わず全決済フローを検証できるよう、外注先に環境の提供を求めます。
受入テストでは、決済の正常系・異常系・境界値を確認します。そのうえで、出荷条件には数値の基準を設けます。
- 正常系：VISA通常、Mastercard 3Dセキュア、ポイントとカード併用。
- エラー系：番号・期限・コード誤りの表示、通信切断、APIタイムアウト。
- 境界値テスト：購入額の最大・最小、ポイント・クーポンで決済額が0円になる場合。
- 品質条件：E2E合格率100%、致命的・重要バグ0件、負荷試験合格。
- 公開条件：全URL301と決済テスト全件合格。
Google Lighthouseでは、全ページでパフォーマンス70以上、アクセシビリティ80以上、SEO90以上を求めます。
通信断後に再読み込みしても二重決済が起きないことと、APIタイムアウト時に保留状態を適切に扱うことを確認します。
ペネトレーションテストと脆弱性スキャンでは、重大・高リスクを0件にします。負荷試験の全基準も満たす必要があります。
移行の前後でデータのレコード数を一致させ、サンプルの内容を目視で確認します。完了条件を事前に合意しておけば、検収時の認識違いを防げます。
外注先の選定と契約のポイント
現行システムを稼働させたまま移すため、外注先の管理力、技術力、リスク対応力が事業に直結します。契約にも、リアーキテクチャ特有の条件が必要です。
外注先の評価基準とEC専門能力の見極め方
外注先は、実績と技術適合性、管理体制で比べます。費用の透明性や保守体制も見ます。特に、月商や月間セッション数が近いECの無停止移行実績は確認しておきます。
ブルーグリーンデプロイやカナリアリリースの実装経験も見ます。
- 移行実績：近い規模の案件と無停止移行の経験。
- 技術適合性：移行先技術の知識と設計根拠の説明力。
- 管理体制：長期計画、変更管理、定期レビュー。
- 費用透明性：工程・機能別内訳と並行稼働費。
- 移行後保守：障害対応、保守契約、技術移管。
類似プロジェクトが3件以上ある外注先が推奨されます。反対に、実績のない会社へ初めて依頼する場合は、事業リスクが高くなります。
技術者がヘッドレスEC、マイクロサービス、クラウドネイティブ化に詳しいかを確認します。あわせて、セキュリティ、性能、拡張性を踏まえた技術選定の理由も評価します。
プロジェクトは一般に6か月〜1年以上かかります。そのため、リスク・連絡・変更管理の計画を確認します。スクラムの経験や、2週間ごとのスプリントレビューで発注側の意見を反映できる体制かも見ておきます。
大規模ECの費用は2,000万〜1億円以上になることが多く、「一式」の見積もりには注意が必要です。
重大障害は検知後1時間以内に対応を始め、復旧目標は4時間以内とするSLAなどを確認します。長期保守契約の条件と月額費用、技術移管計画も比較します。
ECリアーキテクチャ契約書に盛り込むべき重要条項
契約では、移行判断とデータの責任と条件を明確にします。性能とSEOについても、責任と条件を定めます。
- 段階移行：完了条件、次段階の判断、旧環境への復帰条件と承認者。
- データ整合性：発注者と外注先のそれぞれの義務、是正手順、費用負担。
- 性能保証：負荷試験合格を公開条件にし、公開後30日間の基準未達時の対応と費用負担。
- SEO保証：移行3か月後の流入85%以上を品質保証条件とする案を検討。
SEO保証を設ける場合は、流入が目標を下回ったときの原因調査と対応義務も、契約に記載します。
まとめ
ECリアーキテクチャの外注では、発注前の準備と、リスクを数値で示した仕様書が成否を左右します。トラフィック分析で移行禁止期間を定め、繁忙期直前のリリースを避けます。
RFPには、技術情報、業務要件、データ移行、SEO要件を盛り込みます。仕様書では、ピーク性能、段階移行の条件、SEOと決済の要件、E2Eテストと決済環境を具体的に定めます。
外注先は、実績、技術適合性、管理体制、費用の透明性、移行後の保守で比べます。準備と連携がそろえば、売上リスクを抑えながら拡張性の高い基盤へ移行できます。
▼全体ガイドの記事
・ECリアーキテクチャの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。