EC運営

ECサイトに必要な機能一覧|カート・決済・会員管理

最終更新日:2026年8月3日 ZenWeb Japan 編集部
結論: ECサイト 機能を決めるときは、機能名の一覧から選ばないでください。お客さまが注文を終えるまでの流れと、公開後に社内で誰が手を動かすか。この2本の線に沿って並べ直すと、最初から要る機能と、後で足せば足りる機能がはっきり分かれます。

01はじめに|機能の一覧を眺めても決まりません

要点: ECサイト 機能の一覧は、どの資料を見てもほとんど同じ顔ぶれです。見比べても差はつきません。決め手は、その機能が自社の注文の流れと運用のどこに効くか。並べる順番を変えるだけで判断は進みます。

「ECサイトに必要な機能を教えてください」。ネットショップのご相談で、いちばん多い質問です。ところが機能名を50個ほど並べてお見せしても、たいてい話は前に進みません。どれも必要そうに見えてしまうからです。

原因は、機能一覧がカテゴリ順で並んでいることにあります。商品管理、カート、決済、会員管理、受注管理……。分類としては正しいのですが、この並びからは「うちに要るかどうか」が読み取れません。

この記事では、2000年創業のWeb制作・システム開発会社であるZenWeb Japanが実際のEC構築案件で使っている並べ方を、そのままご紹介します。軸は2本だけです。お客さま側の流れと運営側の手間。構築の進め方はECサイト制作サービスのページでもご案内しています。

市場は今も伸びています。経済産業省の調査では、2024年の国内BtoC-EC市場規模は26.1兆円、EC化率は9.8%でした。裏を返すと物販の9割はまだ店頭です。背伸びした機能より、確実に注文が完了する形を先に作るほうが結果につながります。

この章のポイント: 機能はカテゴリ順ではなく、注文の流れと運用の手間の2軸で並べ直してください。優先順位はそこから出てきます。

全体の見取り図は動画でもつかめます。先に一度ご覧いただくと、このあとの話が入りやすくなります。

【ECサイトを活用しよう】売れるECサイトを目指す

出典動画:日本政策金融公庫 公式チャンネル(YouTube)


02EC 必須機能 一覧|注文が終わるまでの流れで並べ直す

要点: EC 必須機能 一覧は、お客さまが商品を見つけてから注文を終えるまでの5段階に沿って並べると分かりやすくなります。探す、選ぶ、かごに入れる、支払う、届くのを待つ。どこかが欠けると、注文はそこで止まります。

まずはお客さま側から見ます。買い物をするとき、人は必ず同じ順番を通ります。その順番に機能を当てはめると、こうなります。

  • 探す段階。 商品検索、カテゴリ一覧、絞り込み。品数が100点を超えたあたりから、絞り込みの有無で回遊のしやすさが変わります。
  • 選ぶ段階。 商品詳細ページ、写真の拡大、サイズや色の選択、在庫の表示。「残りわずか」の表示ひとつで、迷っている人の背中の押され方が変わります。
  • かごに入れる段階。 カート機能、数量の変更、送料の自動計算。金額が確定しないと、お客さまは一度離れます。
  • 支払う段階。 決済処理、住所入力、配送日時の指定、注文内容の確認。いちばん離脱が起きる場所です。
  • 待つ段階。 注文完了メール、発送通知、マイページの購入履歴。ここが弱いと問い合わせの電話が増えます。

1本の線として見ると、途中で切れている箇所がそのまま機会損失になることが分かります。よくあるのは、4段階目まで作り込んで通知メールを後回しにするパターンです。「注文できたのか分からない」という電話対応に毎日30分取られます。実装先の選択肢はネットショップ開設の方法を5つ比較した記事で整理しています。

この章のポイント: 機能は5段階の線として見てください。線が切れている箇所が、そのまま売り逃しと問い合わせ対応の原因になります。

03データで見る|ECサイト 機能の優先度|最初から要るものと後でよいもの

要点: ECサイト 機能を「公開時に必須」「半年以内」「後で足せる」の3段階に分けると、初期の見積り範囲が決まります。必須なのは、注文が完了して代金が回収でき、発送指示が出せるところまでです。

機能別の実装優先度と、後回しにしたときの影響
ECサイトの主要な機能を、公開時に必須・半年以内・後回し可の3段階に分類し、それぞれ後回しにした場合に何が起きるかを整理した表です。
機能 優先度 後回しにすると起きること
カート・送料の自動計算 公開時に必須 金額が確定せず、その場で離脱する
決済(カード+1種類以上) 公開時に必須 代金が回収できない
受注管理・注文完了メール 公開時に必須 発送指示が出せず、問い合わせが増える
在庫の自動連動 公開時に必須 売り越しが起き、お詫び対応になる
SSL・不正注文の検知 公開時に必須 信用を落とし、決済会社から止められる
会員登録・購入履歴 半年以内 再購入のたびに住所を入力させることになる
レビュー・お気に入り 半年以内 迷った人の判断材料が足りない
クーポン・ポイント 後で足せる 施策を打つときまで実害は出にくい
定期購入・サブスク 後で足せる 商材が定期向きでなければ不要
基幹システムとの連携 後で足せる(要設計) 注文が月100件を超えると手入力が限界になる

出典:ZenWeb Japanのクライアント案件データ(日本国内、2024〜2026年)に基づく整理。

公開時に必須なのは5つだけです。注文が完了し、代金が回収でき、発送指示が出せる。ここまでが1本つながっていれば、ネットショップは商売として成立します。残りは売れ始めてから足しても間に合います。

最初に全部そろえようとするから予算が合わなくなります。公開時に要るのは、お金が回収できるところまでです。
この章のポイント: 公開時の必須は5つ。カート、決済、受注、在庫連動、セキュリティです。ここを外さなければ、あとは足していけます。

うちの商材だと、どこまでが必須になりますか。

扱う商品と注文の入り方をうかがえば、公開時に外せない機能をその場で切り分けられます。 ECサイト制作の内容を見る →


04カート機能とは|かごに入れてから買い終わるまでを支える部分

要点: カート機能は「かごに入れるボタン」だけではありません。数量の変更、送料と消費税の計算、在庫の押さえ、決済への受け渡しまでを含みます。ECサイトの中で、いちばん壊れると困る部分です。

カート機能は目に見える部分がごく小さいのに、裏側でいちばん多くの仕事をしています。具体的には、こうした処理を同時に走らせています。

  • 金額の確定。 商品代金に送料と消費税を足して合計を出します。地域別送料や「一定額以上で送料無料」の条件も、ここで判定されます。
  • 在庫の仮押さえ。 かごに入れた時点、または決済に進んだ時点で在庫を確保します。ここが甘いと、最後の1点が2人に売れます。
  • 入力内容の保持。 途中でブラウザを閉じてもかごの中身が残る仕組みです。スマートフォンでの買い物で効いてきます。
  • 決済への受け渡し。 確定した金額と注文内容を決済サービスへ正しく渡します。ずれると金額不一致のエラーになります。

トラブルが起きやすいのは送料の計算です。「北海道と沖縄だけ別料金」「クール便は追加」といった自社ルールは、標準機能で表現しきれないことがあります。見積り前に条件を書き出しておくと、あとで揉めません。

買い物の入り口がスマートフォンに寄っている点も、カート設計に影響します。総務省の令和6年通信利用動向調査では、世帯のスマートフォン保有割合は90.5%でした。指1本で最後まで進める作りかどうか、公開前に実機で確かめてください。

この章のポイント: カート機能で確認すべきは送料ルールです。自社の例外条件を先に書き出しておくと、見積りの精度がまるで変わります。

05決済まわりの機能|支払い方法の数が売上を左右します

要点: 決済で決めることは3つです。どの支払い方法を用意するか、決済代行会社をどこにするか、返金やキャンセルをどう処理するか。支払い方法が1種類のサイトは、それだけで買えないお客さまを生みます。

決済は「クレジットカードが使えれば十分」と思われがちですが、実際はそうでもありません。日本のネットショップでは、次のような支払い方法が組み合わされています。

  • クレジットカード。 主力です。ただしカードを持たない層、使いたくない層は一定数います。
  • コンビニ払い・後払い。 若い層と、カード情報を入れたくない層に効果的です。未回収リスクは代行会社が引き受ける形が一般的です。
  • スマホ決済・キャリア決済。 少額の商材ほど効果が出ます。入力の手間が減るぶん、離脱も減ります。
  • 銀行振込・代金引換。 法人相手や高額商材では今も現役です。
  • 請求書払い。 BtoBで卸をするなら必須級です。掛け売りの与信管理まで含めて設計が要ります。

手数料と導入の手間は方法ごとに違います。何種類そろえるかの考え方はECサイトの決済方法の選び方をまとめた記事で扱っています。

この章のポイント: 決済はカード1種類で始めないでください。買いたいのに買えないお客さまを、気づかないまま取りこぼします。

06データで見る|支払い方法の数と、購入手前での離脱の関係

要点: 支払い方法が1種類から3種類に増えるところで、購入手前の離脱はいちばん大きく動きます。4種類目以降は伸びが鈍ります。ですから、まず3種類を目安に組むのが費用対効果の取りやすい形です。

支払い方法の数と、決済画面での離脱の起きやすさ
用意した支払い方法の数ごとに、決済画面での離脱の起きやすさを相対的な棒グラフで示したモデル試算の表です。
支払い方法の数 離脱の起きやすさ(相対) 取りこぼしやすい層
1種類(カードのみ) ██████████ カード非保有層、法人
2種類(+コンビニ払い) ███████ 法人、少額購入の層
3種類(+スマホ決済) █████ 法人・掛け売り希望
4種類(+後払い) ████ ごく一部
5種類以上 ████ ほぼなし(手数料負担は増える)

出典:ZenWeb Japanのクライアント案件データ(日本国内、2024〜2026年)をもとにしたモデル試算。相対比較の目安です。

棒の縮み方を見てください。1種類から3種類までは目に見えて短くなり、そこから先はほとんど変わりません。効果が出るのは3種類目までが、おおよその線です。5種類以上そろえても、増えるのは月々の手数料と締め作業だけになりがちです。

この章のポイント: 支払い方法は3種類が目安。増やしすぎても離脱は減らず、手数料と経理の手間だけが積み上がります。

07会員管理 ECの機能|リピートを生む仕組みと、要らない場合

要点: 会員管理 ECの機能は、繰り返し買われる商材では効きますが、そうでなければ登録の手間が邪魔になります。判断の目安は「同じお客さまが年に2回以上買うか」。買わない商材なら、ゲスト購入を主にしてください。

会員管理の機能は、ふつう次の要素で構成されます。

  • 会員登録とログイン。 メールアドレスとパスワード、またはSNSアカウントでの連携です。
  • マイページ。 購入履歴、配送先の登録、再注文。ここが使いやすいと2回目の注文が驚くほど速くなります。
  • 顧客情報の管理。 運営側から購入回数や累計金額で顧客を絞り込める機能です。
  • 会員ランクとポイント。 購入額に応じた優遇。定着施策の道具ですが、設計を誤ると原価を圧迫します。

ここで一度立ち止まっていただきたいのが、「会員登録は本当に必要か」という点です。オーダー家具や記念品のように一生に数回しか買わない商材で登録を必須にすると、それだけで購入をやめる人が出ます。逆に、消耗品や食品のように定期的に買われる商材なら、会員管理の有無が年間売上に効いてきます。

おすすめは、ゲスト購入を残したまま注文完了画面で会員登録を勧める形です。買う前に手間をかけさせず、買ったあとに関係をつくる。なお会員が増えれば個人情報の保管量も増えます。個人情報保護法への対応や退会時のデータの扱いは、公開前に制作会社と確認しておいてください。

この章のポイント: 会員登録を必須にするかは商材で決まります。年2回以上買われないなら、ゲスト購入を主にするほうが売れます。

会員機能を入れるか、まだ迷っています。

商材と購入サイクルをうかがえば、入れる場合と入れない場合の費用差までお出しできます。 ECサイト制作の進め方を確認する →


08運営側の機能|受注・在庫・顧客をどこで見るか

要点: 運営側の機能は、お客さまに見えないぶん見落とされます。受注管理、在庫管理 連携、顧客管理、売上の集計。ここが弱いと、注文が増えたぶんを人手で埋めることになり、売れるほど苦しくなります。

軌道に乗ったあと、いちばん時間を食うのは管理画面での作業です。よく問題になるのは次の4つです。

  • 受注管理。 注文の一覧、ステータスの変更、伝票番号の登録、発送メールの送信。1日20件を超えると、一括操作の有無で作業時間が変わります。
  • 在庫管理 連携。 ECの在庫と、実店舗や倉庫の在庫を合わせる仕組みです。手動更新のままだと必ずどこかでずれます。
  • 顧客管理。 問い合わせ履歴と注文履歴が同じ画面で見えるか。分かれていると電話口で待たせることになります。
  • 売上の集計。 商品別、期間別、流入経路別。数字が出ないと、次にどこへ手を入れるか決められません。

とくに在庫管理 連携は、後回しにされやすいわりに影響が大きい部分です。ECと販売管理システムがつながっていないと、注文メールを見ながら基幹システムへ手入力する運用になります。入力ミスと出荷の遅れはここから生まれます。

売上が伸びない原因が、実は運営側の詰まりだったという例も少なくありません。切り分け方はネットショップが売れない原因と改善方法の記事で整理しています。連携そのものの設計はWebシステム開発サービスの範囲です。

この章のポイント: 運営側の機能を削った分は、人の作業時間で払うことになります。注文が増えるほど負担も増えます。

09データで見る|在庫管理 連携の有無で変わる月間の手作業時間

要点: 在庫管理 連携がないと、注文が増えるほど手作業の時間も比例して伸びます。月100件を超えるあたりで、担当者1人の負担が無視できなくなります。投資判断は、この分岐点を目安にしてください。

月間注文件数別|手作業にかかる時間の目安
月間の注文件数ごとに、在庫と受注の連携がない場合とある場合で、手作業にかかる月間時間を比較した表です。
月間注文件数 連携なし(手入力) 連携あり
〜30件 約4時間 約2時間 約2時間
31〜100件 約13時間 約5時間 約8時間
101〜300件 約38時間 約10時間 約28時間
301〜700件 約85時間 約18時間 約67時間
701件〜 運用が破綻しやすい 約28時間

出典:ZenWeb Japanのクライアント案件データ(日本国内、2024〜2026年)に基づく目安。作業内容により前後します。

注目していただきたいのは101〜300件の行です。月38時間は担当者のほぼ1週間分にあたります。連携の初期費用が数十万円だとしても、この時間を1年払い続けるのと比べれば判断は難しくありません。

逆に月30件までなら手作業でも回ります。連携は「今」ではなく「いつ」を決める投資だとお考えください。最初から入れる必要はありませんが、後で入れられる設計にしておくことは大事です。

この章のポイント: 月100件が分かれ目です。そこを超える見込みが立った時点で、連携の検討を始めてください。

10機能を決める順番|見積りを取る前にやる3つのこと

要点: 見積りを取る前に、自社側で3つだけ決めておいてください。例外ルールの洗い出し、注文件数の見込み、公開希望日です。この3つがあると機能の要否がほぼ機械的に決まり、見積りの精度も上がります。

制作会社に丸投げすると、たいてい「とりあえず全部入り」の見積りが返ってきます。高くなるのは機能が多いからではなく、削る根拠がこちらから示されていないからです。

  1. 例外ルールを書き出す。 送料の例外、値引きの条件、得意先ごとの価格、発送のタイミング。「うちは特別」と思っている部分を全部書きます。標準機能で収まるかどうかが費用の分かれ目です。
  2. 1年後の注文件数を見込む。 月に何件くらいか、ざっくりで構いません。在庫管理 連携や一括処理を今入れるかの判断材料になります。
  3. 公開希望日を決める。 展示会や季節商戦など動かせない日があるなら先に伝えます。期日から逆算すると、初期リリースに含める機能が絞られます。

この3点をまとめた紙を持って相談に行くと、話は驚くほど速く進みます。整理の手順は要件定義の進め方を解説した記事で、見積書の読み方はECサイト構築費用の内訳と相場の記事ホームページ制作の費用相場の早見表が参考になります。

この章のポイント: 例外ルール、注文件数の見込み、公開希望日。この3枚を先に用意すれば、見積りは自然と実態に近づきます。

11データで見る|機能を後から追加したときの費用差

要点: 同じ機能でも、最初から入れる場合と後から足す場合では費用が変わります。データの持ち方に関わる機能ほど差が大きく、見た目に近い機能ほど差は小さくなります。ここを知っておくと、初期に何を入れるかの判断が変わります。

追加時期による費用の変わり方
主要な機能について、構築時に含めた場合と公開後に追加した場合の費用の変わり方を、倍率と理由とともに整理した表です。
機能 構築時に入れる 公開後に足す 差が出る理由
会員管理・購入履歴 基準 約2.0〜2.5倍 既存の注文データを会員に紐づけ直す作業が要る
在庫管理 連携 基準 約1.8〜2.2倍 稼働中のデータを止めずに合わせる必要がある
定期購入 基準 約1.8〜2.0倍 決済の契約と請求の仕組みを作り直す
支払い方法の追加 基準 約1.1〜1.3倍 設定と審査が中心で、作り直しは少ない
クーポン・ポイント 基準 約1.1〜1.4倍 金額計算の部分だけを差し替えれば済む
レビュー表示 基準 約1.0〜1.2倍 既存データへの影響がほとんどない

出典:ZenWeb Japanの見積りデータ(日本国内、2024〜2026年)に基づく倍率の目安。同一機能を同一環境で比較した場合の相対値です。

表の上半分と下半分で性格がはっきり分かれています。データの持ち方に関わる機能は後から足すと高くつき、見た目に近い機能は後からでも変わりません。予算を削るときに落としてよいのは下半分です。上半分を落とすと、1年後に倍額で買い直すことになります。工数の見方はシステム開発の見積もりの見方の記事でも解説しています。

この章のポイント: 削るなら見た目寄りの機能から。データ構造に関わる機能は、後で倍近い費用がかかります。

12入れたのに使われない機能|よくある3つ

要点: 予算をかけたのに、公開後ほとんど使われない機能があります。多いのは、社内に運用する人がいない機能です。作る前に「誰が毎週触るか」を確かめれば、無駄な投資を減らせます。

ご相談の場でよく話題になる、使われないまま残りやすい機能を3つ挙げます。

  • 凝った検索の絞り込み。 商品が50点しかないのに5階層の絞り込みを入れる。お客さまは一覧を眺めるだけで済んでしまいます。品数が増えてからで十分です。
  • サイト内チャット。 導入したものの、返信する担当者が決まっていない。応答が遅いチャットは、置いていないより印象が悪くなります。
  • 高機能な分析ダッシュボード。 見るのは最初の1か月だけ、というケースが目立ちます。まずは無料の解析ツールで足ります。

共通しているのは、機能ではなく運用する人が足りていない点です。開発費を出す前に「この機能を毎週触るのは誰ですか」と自問してみてください。名前が出てこなければ、まだ早いということです。

この章のポイント: 担当者の名前が出てこない機能は、まだ入れなくて大丈夫です。運用する人がいて初めて機能は効きます。

13まとめ|ECサイトの機能は「回る形」から決める

要点: ECサイト 機能は、一覧から選ぶのではなく注文の流れと運用の手間から逆算するのが近道です。公開時はカート、決済、受注、在庫連動、セキュリティの5つ。あとは売れ行きを見ながら足していけば間に合います。

ここまでの流れをまとめます。

  • お客さま側は5段階で見る。 探す、選ぶ、かごに入れる、支払う、待つ。線が切れているところが機会損失です。
  • 公開時の必須は5つ。 カート、決済、受注管理、在庫の連動、セキュリティ。
  • 支払い方法は3種類を目安に。 それ以上は手数料と経理の手間が増えるだけになりがちです。
  • 会員管理は商材で決める。 年2回以上買われるかどうかが判断の線です。
  • 削るなら見た目寄りから。 データ構造に関わる機能を削ると、後で倍近くかかります。

そして公開してからが本番です。売れ行きを見ながら機能を足していける形にしておくこと。それが、最初に全部そろえることよりずっと大事です。自社ECとモール出店で迷っているなら自社ECとモール出店の違いをまとめた記事を、土台選びにはShopifyとEC-CUBEの比較記事をご覧ください。


14よくある質問

要点: ECサイト 機能について、ご相談の場でよくいただく質問をまとめました。公開時の最低ライン、会員登録の要否、在庫連携の時期、あとから追加できるかどうかが中心です。

1. ECサイトに最低限必要な機能は何ですか

カート機能、決済、受注管理、在庫の連動、セキュリティ対策の5つです。この5つがそろっていれば、注文を受けて代金を回収し、発送指示を出すところまで回ります。レビューやポイントは、売れ始めてから足しても遅くありません。

2. 会員管理 ECの機能は必ず入れるべきですか

商材によります。同じお客さまが年に2回以上買う商材なら入れる価値があります。一生に数回しか買わない商材では、登録の手間が購入をやめる理由になります。迷ったら、ゲスト購入を残したまま、注文完了後に登録を勧める形が無難です。

3. 在庫管理 連携はいつ入れるのがよいですか

月間の注文が100件に近づいたころが目安です。それ以下なら手作業でも回りますが、100件を超えると手入力の時間が急に増えます。後から足すと費用が上がるので、最初の設計時に「後で連携できる形にしておく」ことだけは伝えておいてください。

4. 機能はあとから追加できますか

できます。ただし費用の増え方は機能によって違います。支払い方法の追加やレビュー表示は後からでもほぼ変わりません。一方、会員管理や在庫連携のようにデータの持ち方に関わるものは、2倍前後になることがあります。

5. カート機能はゼロから作るべきですか

ほとんどの場合、既存のカートを使うほうが合理的です。ゼロから作る価値があるのは、標準機能では表現できない取引ルールが業務の中心にある場合だけです。迷う段階でしたら、まずは条件を書き出してご相談ください。

必要な機能を、一緒に切り分けませんか。

扱う商品、送料や値引きの例外ルール、想定する注文件数をうかがい、公開時に入れる機能と後回しでよい機能を仕分けします。費用と期間の目安までお伝えします。ご相談は無料です。

無料で相談する →

まずは、いまお困りのことを聞かせてください

ご相談は無料です。要件が固まっていない段階でも構いません。内容をうかがったうえで、進め方とお見積りをご提案します。