【2026年版】EC基盤選定で情シスが確認すべき技術要件チェックリスト

EC基盤の選定は、事業部が機能とデザインで候補を絞り、最後に情報システム部門へ「稟議とセキュリティ審査をお願いします」と回ってくる流れになりがちです。ところが回ってきた提案書には、機能一覧と料金は書かれていても、稼働率・障害時の連絡体制・連携方式・ログの保全期間といった技術要件はほとんど書かれていません。

 

情シス側が確認を求められるのは「このシステムを入れて、運用と障害の責任を誰が持つのか」です。SaaS型のECプラットフォームは自社でサーバーを保有しないため保守負荷は下がりますが、責任がゼロになるわけではありません。この記事では、EC基盤選定でIT部門が確認すべき技術要件を7カテゴリのチェックリストに整理し、SaaS型ECを運用保守の観点でどう評価するか、移行プロジェクトで情シスが負うリスクをどう先回りするかまで解説します。

 

EC基盤選定で情シスが確認すべき技術要件とは

EC基盤選定で情報システム部門が確認すべき技術要件は、非機能要件・データ連携方式・セキュリティ・第三者認証と監査・アカウント権限管理・アップデート運用・移行と撤退時のデータ持ち出しの7カテゴリです。機能要件は事業部が評価できますが、この7カテゴリは事業部だけでは判断できず、承認後に問題が発覚したときの一次対応窓口は情シスになります。

 

Q：EC基盤の選定で、情シスが最初に確認すべき技術要件はどれですか。
A：最初に確認すべきは「責任分界点」です。稼働監視・脆弱性対応・バックアップ・障害切り分けのそれぞれについて、ベンダー側の作業範囲と自社側の作業範囲を1枚の表にできるかを先に確かめてください。ここが曖昧なままでは、他のどの項目を細かく詰めても運用開始後に「誰も見ていない領域」が残ります。

 

※関連記事： 【2026年版】ECプラットフォームとは？種類・特徴や選び方がわかる完全ガイド

技術要件チェックリスト（7カテゴリ）

提案書やRFPへの回答を受け取ったら、次の7カテゴリで「回答があるか」「回答が数値になっているか」を確認します。数値で答えられない項目は、運用開始後に交渉材料を失う項目です。

※比較基準日：2026年8月時点。認証の準拠バージョンは改訂されるため、選定時点で最新版を再確認してください。

事業部の選定軸と情シスの確認軸は同じではない

事業部は「売上が伸びるか」でシステムを見ます。管理画面の使いやすさ、レコメンドの精度、CRM機能の有無といった観点です。一方で情シスが見るのは「壊れたときにどうなるか」と「他のシステムに何を要求するか」です。この2つは対立するものではありませんが、評価表を共有しないと片方が抜け落ちます。

 

実際に起きやすいのが、事業部が選定を終えた後に情シスへ渡され、基幹システム側のインターフェース改修に3ヶ月必要だと分かって公開日が動くケースです。EC側の要件が固まる前でも、連携先システムの改修余地だけは早い段階で確認しておく価値があります。

非機能要件：可用性・性能・SLAをどう要件化するか

可用性の要件化は「稼働率99.9%以上」と書くだけでは機能しません。稼働率の定義式、定期保守で停止する時間帯、障害発生時の一次応答までの時間の3点をセットで要求してください。

稼働率とSLAの読み方

総務省の「ASP・SaaSにおける情報セキュリティ対策ガイドライン」では、利用者に提供されるサービス時間帯を、契約上のサービス時間から定期保守時間を差し引いたものとして整理しています。つまり、同じ稼働率99.9%でも「定期保守を稼働率の計算から除外しているか」で実質的な停止時間は変わります。ここを確認せずに数値だけを比較すると、比較になりません。

 

あわせて要求したいのが、障害時の連絡フローです。24時間365日の監視体制があるかだけでなく、深夜のセール中に障害が起きた場合に誰へ連絡が入り、誰から折り返しが来るのかを確認します。連絡経路が営業担当経由のみという体制では、初動が翌営業日になりかねません。中堅・大手ECであれば「障害検知から1時間以内の一次応答」を要件の下限に置くのが現実的です。

ピークトラフィックをどう伝えるか

性能要件は、平常時の数値ではなくピーク時の数値で伝えます。具体的には、年間で最も負荷が高い日の同時アクセス数・秒間注文数・SKU数・会員数を提示し、その水準で耐えられるかを確認します。セール開始直後の数分に負荷が集中する事業では、平均PVを伝えても意味がありません。

 

SaaS型ECの場合、インフラのスケーリングはベンダー側の責任範囲に含まれるのが一般的です。ただし「事前連絡が必要か」「大規模セール時に増強の申請が必要か」は製品ごとに異なるため、運用手順として確認しておきます。

バックアップ・復旧目標（RTO・RPO）

データ消失時にどこまで巻き戻せるか（RPO）、どれだけの時間で復旧するか（RTO）は、SaaSでも確認が必要な項目です。バックアップの取得頻度、保管世代数、暗号化の有無、遠隔地へのレプリケーションの有無を聞き取ります。「バックアップは取得しています」という回答だけで通してしまうと、実際の障害時に復旧ポイントが想定より古かったという事態が起こり得ます。

データ連携要件：基幹・WMS・MAとの接続方式の確認項目

データ連携で情シスが確認すべきは、API仕様書が開示されるか、最短の連携間隔がどれだけか、そして自社データをいつでも取り出せるかの3点です。EC単体で完結する業務はほとんどなく、受注は基幹（ERP）へ、在庫はWMSへ、顧客はMAへと流れます。

API仕様書は契約前に開示されるか

API連携の可否を「対応しています」という一言で終わらせないことが重要です。確認すべきは、REST APIかSOAPか、認証方式（APIキー・OAuth等）、レート制限（1分あたりの呼び出し上限）、エラー時のリトライ仕様、仕様変更時の告知方法です。仕様書が契約後にしか開示されない製品では、連携開発の工数を見積もれません。

 

特に注意が必要なのは自社側です。稼働年数の長い基幹システムはAPI接続に対応していないことがあり、その場合はバッチ処理やCSV連携の設計が必要になります。この確認をベンダー任せにすると、後から連携コストが膨らみます。

 

※関連記事： ECサイトで基幹システム連携が必要な理由とは？データ連携の方法やメリット、成功事例を解説

API・バッチ・CSVの使い分けを要件で決める

連携方式は「速いほど良い」ものではありません。在庫連携はリアルタイム性が売上に直結しますが、会計向けの売上データは1日1回のバッチで十分なことが多くあります。方式を業務単位で切り分けて要件化すると、開発費と運用の複雑さを抑えられます。

 

※比較基準日：2026年8月時点。

自社データのエクスポート権を要件に入れる

顧客データ・注文履歴・商品データを「いつでも・追加費用なしで・機械可読な形式で」出力できるかを確認します。将来の乗り換え時だけでなく、分析基盤へデータを持ち出す日常運用でも必要になる項目です。データを取り出せない構成は、そのまま乗り換え不能な状態を意味します。

セキュリティ・監査要件の確認項目

セキュリティ審査では、対策の名称が並んでいるかではなく、準拠バージョン・認証の適用範囲・診断の実施主体と頻度という「検証できる形」で回答があるかを見ます。

PCI DSSは準拠バージョンまで確認する

クレジットカード情報を扱うEC事業者にとって、PCI DSSへの対応状況は必須の確認項目です。ここで重要なのは、準拠しているかどうかだけでなく、どのバージョンに準拠しているかです。PCI DSSは改訂されるため、旧版のままの回答であれば、次の改訂への対応計画を確認する必要があります。あわせて、3Dセキュア2.0（EMV 3-Dセキュア）への対応も確認しておきます。

 

参考として、メルカートのようなSaaS型プラットフォームでは、PCI DSS v4.0.1に準拠していることを公開情報として明示しているケースがあります（2026年8月時点）。準拠バージョンが公開されている製品は、審査時のエビデンス収集が容易になります。

 

※関連記事： ECサイトはセキュリティ対策が重要！その理由や対策方法とは？

ISMS等の第三者認証は「組織」に与えられるものだと理解して確認する

ここは情シス側でも誤解が生まれやすい点です。ISMS（ISO/IEC 27001）認証は、サービスやソフトウェア製品そのものに与えられるものではなく、情報セキュリティマネジメントシステムを運用する組織に対して与えられる認証です。したがって審査の際に確認するのは、次の3点になります。

 

1つ目は、認証を取得しているのがどの法人かです。プラットフォームを提供している会社なのか、その親会社なのか、あるいは開発を委託している別会社なのかで、意味は大きく変わります。2つ目は、認証の適用範囲です。認証登録証には対象となる事業・拠点が記載されており、当該サービスの開発・運用部門が範囲に含まれていなければ、実質的な担保になりません。3つ目は、登録番号と有効期限です。番号が開示されていれば、認証機関の登録簿で現況を確認できます。

 

たとえばメルカートの場合、サービスを提供する株式会社メルカートがISMSの認証登録（IS97670）を取得しており、サービスの開発・運用部門もしっかりと適用範囲に含まれているため、実効性のあるセキュリティ体制が担保されています。

 

クラウド基盤側の準拠標準も別枠で確認します。SaaS型ECの多くはパブリッククラウド上で稼働しており、基盤側がISO 27001やSOC 1・SOC 2などの標準に適合して設計・管理されているかは、アプリケーション層の対策とは別の論点です。

脆弱性診断は「誰が・どの頻度で」実施しているか

脆弱性対策は、実施主体で意味が変わります。開発工程でのソースコード検査、リリース前のアプリケーション診断、稼働環境での改ざん監視は、それぞれ別の対策です。特に「外部のセキュリティ専門機関による診断を定期的に実施しているか」は、社内チェックのみの体制と比べて客観性が高く、審査資料としての説明力があります。

 

加えて、脆弱性が公表された場合の対応フローを確認します。深刻度の判定は誰が行い、緊急パッチはどのリードタイムで適用され、利用企業への告知はどの手段で届くのか。この経路が定義されていない製品は、有事に情シスが情報収集から始めなければならなくなります。

アカウント・権限・操作ログ

管理画面は、外部からの攻撃だけでなく内部不正のリスクにもさらされます。確認すべき標準機能は、2要素認証、管理画面のIP制限、機能単位の権限設定、個人情報の表示制御、パスワードとアカウントの有効期限です。これらがオプション扱いか標準搭載かで、追加費用と設定負荷が変わります。

 

そして見落とされがちなのが操作ログです。誰がいつどの顧客データを閲覧・出力したかの記録が取得されているか、その保全期間はどれだけか、必要時に情シスが自ら参照できるのか、それともベンダーへの依頼が必要なのか。個人情報の漏えい疑義が生じた際、この記録の有無が調査可否を分けます。

SaaS型ECの保守運用｜ベンダーと自社の責任分界点

SaaS型ECではアプリケーションとインフラの保守はベンダー側が担いますが、アカウント管理・自社データの内容・連携先システム側の改修・業務観点の検証は自社に残ります。クラウドサービスの利用では、事業者と利用者が責任を分担する「責任共有モデル」が前提になります。IaaSではOSより上の層が利用者責任、PaaSではアプリケーションとデータ、SaaSではアプリケーション上で扱うデータが中心という整理が一般的です。

ECの業務に当てはめた責任分界表

抽象的なレイヤ図のままでは運用設計に落ちません。EC運営で日常的に発生する作業に置き換えると、次のように整理できます。

※比較基準日：2026年8月時点。実際の分担は契約内容により異なるため、契約書とサービス仕様書で確認してください。

パッケージ型・スクラッチとの保守負荷の違い

同じEC基盤でも、提供形態によって情シスの負荷は大きく変わります。オンプレミスのパッケージ型やフルスクラッチでは、OSやミドルウェアのパッチ適用、サーバーのキャパシティ管理、バージョンアップ計画の立案までが自社側に入ります。自由度は高い一方で、担当者1人あたりの管理対象が増えます。

 

SaaS型は逆に、基盤保守がベンダー側へ寄る分、自社でコントロールできる範囲が狭くなります。この構造を理解しておくと、稟議での説明もしやすくなります。

SaaSでも自社に残る4つの責任

整理すると、SaaS型ECを採用しても情シスの手元には次の4つが残ります。①管理画面のアカウントと権限の棚卸し、②自社データの保持方針と出力データの管理、③連携先システム側の維持と改修、④アップデート適用後の業務検証です。この4つを「誰の担当か」まで決めずに稼働させると、退職者アカウントが残り続けるといった典型的な問題が起こります。

自動バージョンアップの運用リスクと情シスの備え

SaaS型ECの自動バージョンアップは、パッチ適用の工数がなくなる一方で「適用タイミングを自社で選べない」というリスクを伴います。情シスが備えるべきは、告知の受領経路と、適用後に何を確認するかの手順化です。

 

オンプレミス環境に慣れていると、更新は自社の判断で計画するものという前提になります。SaaSではこの前提が変わります。年間の更新回数が多い製品ほど機能は新しく保たれますが、その分、告知を読み飛ばした場合の影響も増えます。参考として、メルカートは年間240回の自動バージョンアップを実施しており（2026年8月時点の公開情報）、追加開発なしで法改正対応や機能追加が反映される設計になっています。

 

情シス側で用意しておくとよいのは、次の3点です。1つ目は、リリースノートの受領経路を担当者個人のメールではなく共有メールボックスやチャンネルに向けること。2つ目は、検証環境（ステージング）が提供されるかを契約時に確認し、提供される場合は主要業務フローのチェックリストを作っておくこと。3つ目は、カスタマイズやテンプレート改修を入れている箇所を一覧化し、更新時に影響を受けやすい箇所として優先確認することです。

 

「自動更新だから何もしなくてよい」と読み替えてしまうと、繁忙期の直後に表示崩れや帳票の不整合が見つかるといった事態につながります。運用負荷は確実に下がりますが、ゼロにはなりません。

移行プロジェクトで情シスが負う3つのリスクと回避策

EC移行プロジェクトで情シスが負うリスクは、①連携先システム側の改修見落とし ②移行データの品質責任 ③切替直後の障害切り分け体制の3つに集約されます。いずれもEC基盤側の性能ではなく、自社側の準備で決まる領域です。

リスク①：連携先システム側の改修が見落とされる

EC側の仕様が変われば、受注データを受け取る基幹システムの取込仕様も変わります。項目の追加、桁数の変更、コード体系の差異といった細かな差分が、そのまま基幹側の改修工数になります。ところがプロジェクト計画では、EC構築のスケジュールだけが引かれていることが少なくありません。

 

回避策は、要件定義の段階で連携先システムごとに「改修が必要か・不要か・未確定か」の三分類を作り、未確定を残さないことです。ベンダー側の見積もりには自社側システムの改修費は含まれません。ここを別枠で予算化しておくと、稟議のやり直しを避けられます。

リスク②：移行データの品質責任は自社に残る

商品データ・会員データ・注文履歴・ポイント残高の移行では、移行の実作業をベンダーが担っても、「そのデータが正しいか」の判断は自社にしか下せません。長年運用してきたサイトほど、重複会員、退会済みなのに残っているデータ、欠損した住所情報などが蓄積しています。

 

回避策は、移行の範囲（何年分を移すか）と品質基準（不完全なデータをどう扱うか）を移行作業の開始前に文書で決めておくことです。移行中に判断待ちが発生すると、そこでスケジュールが止まります。データ移行は技術作業ではなく意思決定を含む作業だと捉えておくと、体制の組み方が変わります。

リスク③：切替直後の障害切り分け体制がない

公開直後の不具合は、EC基盤側・連携先システム側・ネットワーク側・設定ミスのどこに原因があるか切り分けが必要です。この一次切り分けの窓口が決まっていないと、事業部からの問い合わせがすべて情シスに集まり、情シスがベンダーへ転送するだけの中継役になります。

 

回避策は、公開後2〜4週間を「立ち上がり期間」として位置づけ、①事業部からの一次受付担当 ②ベンダー側の窓口と連絡手段 ③エスカレーションの判断基準（売上が止まる事象は即時、表示崩れは翌営業日など）を事前に決めておくことです。書面で1枚にまとめておくだけで、初動の速さは大きく変わります。

 

なお、RFPの作り方、見積もりの比較方法、契約条項（ソースコードの帰属や追加開発の単価など）については、外注プロセスの観点で別記事に整理しています。

 

※関連記事： ECサイト構築・リニューアルを外注する前に整えておくべき要件定義の全手順

メルカートなら情シスの運用保守負荷をこう抑えられる

クラウドECプラットフォーム「メルカート」は、情報システム部門の審査で確認されることの多い項目を、標準機能と公開情報として整えています。以下は2026年8月時点の公開情報です。

 

セキュリティ基盤では、WAFを標準適用してSQLインジェクションやクロスサイトスクリプティングなどの攻撃を緩和し、データベースは透過的暗号化（TDE）で保護、バックアップは暗号化された状態でレプリケートする構成をとっています。管理画面側にも2要素認証、IP制限、機能単位の権限設定、個人情報の表示制御、アカウント有効期限などを標準機能として搭載しており、これらを追加開発せずに利用できます。

 

監査・コンプライアンスの観点では、クレジットカード業界の国際基準PCI DSS v4.0.1に準拠しています。また、サービスを提供する株式会社メルカートがISMSの認証登録（IS97670）を取得しており、認証主体と登録番号が公開されているため、稟議書や審査資料に転記する際の確認が容易です。アプリケーションレイヤについては外部のセキュリティ専門会社による診断を定期的に実施し、稼働基盤であるAzureはISO 27001やSOC 1・SOC 2などの標準に適合するよう設計・管理されています。自社起因のセキュリティ事故は0件を維持しています。

 

運用面では、年間240回の自動バージョンアップにより、法改正対応や新機能の追加が自社での開発コストなしに反映されます。バージョンアップに伴う費用が都度発生しないため、複数年のTCO（総所有コスト）を試算しやすい構造です。加えて、構築中から公開後まで専任チームが伴走し、この支援体制への評価がサポート満足度97%という数値に表れています。基幹システムやWMS、MAとの連携についても、要件定義の段階から技術面の相談が可能です。

 

「事業部が候補を絞ってきたが、技術要件の確認項目を洗い出したい」という段階でのご相談にも対応しています。

よくある質問（FAQ）

ここでは、EC基盤の技術要件と運用保守に関するよくある質問とその回答についてまとめました。

Q1: SaaS型ECを選べば、情報システム部門の作業はなくなりますか？

A: なくなりません。サーバー・OS・ミドルウェアの保守やアプリケーションの脆弱性対応はベンダー側の責任範囲になりますが、①管理画面のアカウントと権限の棚卸し、②自社データの保持方針と出力データの管理、③基幹システムやWMSといった連携先システム側の維持・改修、④バージョンアップ適用後の業務検証は自社に残ります。クラウドサービスは事業者と利用者が責任を分担する責任共有モデルが前提のため、契約時に責任分界を1枚の表にしておくことをおすすめします。

Q2: ECプラットフォームのSLAは、どの水準を求めるべきですか？

A: 数値そのものより、定義と運用を確認することが先です。具体的には、稼働率の計算式（定期保守時間を除外しているか）、計画停止の年間回数と実施時間帯、障害検知から一次応答までの時間、連絡窓口と時間帯の4点を書面で確認してください。年商数十億円規模のECであれば、24時間365日の監視体制と、障害検知から1時間以内の一次応答を下限として交渉するのが現実的です。稼働率99.9%という表記だけでは、実際の停止時間は比較できません。

Q3: 基幹システムとの連携は、APIとCSVのどちらで要件化すべきですか？

A: 業務単位で切り分けるのが基本です。在庫連動や会員情報の同期のようにリアルタイム性が売上へ直結する処理はAPI、受注データの基幹連携や売上集計は日次バッチ、商品マスタの一括更新や初期移行はCSVという組み合わせが実務では多くなります。全てをリアルタイム化すると開発費と障害点が増えるため、要件を絞ることでコストを抑えられます。なお、稼働年数の長い基幹システムはAPIに対応していない場合があるため、自社側の接続可否をEC側の選定と並行して確認してください。

まとめ

EC基盤選定で情報システム部門が確認すべき技術要件は、①非機能要件（可用性・性能・SLA）②データ連携方式 ③セキュリティ ④第三者認証・監査 ⑤アカウントと権限管理 ⑥アップデート運用 ⑦移行と持ち出しの7カテゴリです。このうち最初に固めるべきは責任分界点で、稼働監視・脆弱性対応・バックアップ・障害切り分けの担当を1枚の表にできるかが分かれ目になります。

 

評価の際は、対策の名称ではなく検証できる形の回答を求めてください。稼働率は定義式とあわせて、PCI DSSは準拠バージョンまで、ISMSなどの第三者認証は「組織に対する認証」であることを踏まえて認証主体と適用範囲まで確認します。この一手間が、稼働後の監査対応と障害時の初動を左右します。

 

SaaS型ECは保守負荷を下げますが、アカウント管理・自社データ・連携先システム・適用後検証の4領域は自社に残ります。移行プロジェクトでは、連携先システム側の改修、移行データの品質基準、切替直後の障害切り分け体制の3点を事前に決めておくことで、公開直前の手戻りを大きく減らせます。技術要件の洗い出し段階からの相談先をお探しの場合は、お気軽にお問い合わせください。