STORESのシステムを発注するときは、標準機能の導入、外部連携、独自開発の3つに分けて考えます。そのうえで、課題整理と要件定義から始め、検証や契約、開発、運用へと順に進めると、会社ごとの提案を比べやすくなります。
発注の形から委託先の選び方まで、流れに沿って見ていきます。
▼全体ガイドの記事
・STORESのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
STORESのシステム発注前に分ける3つのパターン
依頼を「STORESのシステムを作ってほしい」とまとめると、内容が曖昧なままです。外注する領域を分けておくと、不要な開発を避けられ、見積も比べやすくなります。
既存STORESの導入で店舗運営を整えるケース
ネットショップやPOSレジのほか、キャッシュレス決済や予約、モバイルオーダーなどの標準機能を使う場合は、導入支援会社や業務設計に強い会社へ依頼できます。
- 初期設定：商品登録、店舗情報、スタッフ権限を整えます。
- 移行と教育：既存商品のCSV移行と操作研修。
- 運用整備：マニュアルを整え、標準機能と運用で補う範囲を決めます。
目的は現場で使える状態をつくることです。そのため、機能が足りなくても、すぐに大規模開発へ進まず、先に標準機能でできることを確かめます。
STORESと会計・在庫・CRMを連携するケース
基幹システムや会計ソフトのほか、在庫管理、顧客管理、分析基盤とつなぐ場合は、連携開発を発注します。そのうえで、CSVの定期取込で足りるか、APIやWebhookによるリアルタイム連携が必要かを見極めます。
- 取引の追跡：商品コードや注文番号などを、同じ取引IDで管理します。
- 例外への対応：失敗時の再送と重複登録の防止を含めます。
- 日次突合：決済、返品、返金、在庫引当、入金結果を照合します。
これらが発注範囲から漏れると、連携自体は動いていても、月末処理に手作業が残ることがあります。
STORES型サービスを新規開発するケース
自社ブランドのアプリや独自の会員・ポイント・予約、複数店舗の本部管理、マルチテナントの店舗運営サービスを作る場合は、新規開発にあたります。
対象はEC画面だけではなく、POS、注文、決済まで広がります。さらに、在庫や権限、監査ログのほか、通知や障害復旧も含みます。
- 置き換え：STORESを全面的に置き換えるかの判断です。
- 併用：決済やネットショップにSTORESを使い、独自業務だけを開発する方法もあります。
- 開発範囲：会員制度や店舗運営が強みなら、独自開発を検討します。
標準機能で足りる領域まで作らないことは、費用を抑える近道です。
STORESのシステム発注・外注の進め方
まず目的と現状を整理し、RFPと提案比較、契約を進めます。その後、検証と開発を経て、受入テストと運用移行へ進みます。候補会社を決める前に、比較の前提をそろえておきます。
最初に解決したい業務課題と対象範囲
依頼では、「STORESを導入したい」より先に、何を改善するかを書きます。たとえば、店舗とECの在庫差異、イベント後にネットショップを非公開にする作業、会計ソフトへの転記を減らす課題などが該当します。
独自会員の購買履歴を一元化したい場合も、業務課題として示せます。
- 店舗と販売：店舗数、ECサイト数、SKU数の記載
- 取引と利用者：月間注文数、月間取引数、利用者数の記載
- 既存環境：POS、会計、予約、CRM、決済端末、物流を記載します。
「全部連携したい」とだけ伝えると、会社ごとに作業範囲が異なり、金額を比べられなくなります。
現行業務とデータの正の棚卸し
商品や在庫、注文といったデータごとに、正しいデータを持つシステムを決めておきます。決済や返金、入金、会計のデータも対象になります。
商品名やSKUがECとPOSで異なり、店舗ごとに在庫の数え方も違い、返品を表計算で管理している状態では、連携しても正しい結果にはなりません。
- データ更新：更新元と更新頻度、許容する反映遅延を定めます。
- 失敗時の運用：通知先と再処理方法、保存期間の決定
- 具体的なルール：注文はSTORESを正とし、会計へ日次で連携する例があります。
たとえば、在庫はPOSとECの販売時に減らし、毎日23時に突合する方法があります。さらに、返金は担当者の承認後に反映するなど、運用ルールもRFPに書いておきます。
1店舗または1業務のPoCによる実データに近い検証
まず1店舗または1業務に絞って検証し、全店舗への展開は後にします。商品登録や注文、決済を試し、さらに在庫減算や取消、返品、返金も確かめます。
- 実データに近い条件での、通信障害や同じ注文の再送、日次の売上突合の検証
- 正常系に加え、二重送信や端末の電源が途中で切れた場合も確認します。
PoCの目的は、本開発の見積条件を具体化することです。そのために、APIやCSVの制約、現場の入力負担、データの正を洗い出し、運用上の例外も見つけます。
検証項目と合格条件を契約書や発注書に添付しておくと、PoC後の追加費用も説明しやすくなります。
RFPと要件整理で決めること
RFPは、候補会社に同じ条件で提案してもらうための依頼書です。仕様書まで完成させる必要はありませんが、業務背景や対象範囲、データ、制約を整理します。そのうえで、希望時期や予算の考え方、提案依頼もまとめます。
RFPの業務・データ・非機能要件
業務要件には、誰が、いつ、どの画面で何を処理するかを書きます。たとえば、店舗スタッフの会計で在庫を減らし、本部担当者が返金を承認する流れを示します。
EC注文を出荷担当へ渡す業務や、月末に売上と入金を照合する業務も、シナリオとして扱えます。
- 可用性と性能：営業時間中の可用性、ピーク時の注文数、応答時間の記載
- 運用と復旧：バックアップ、ログ保存、障害時の復旧目標、問い合わせ時間を定めます。
- アクセス管理：多要素認証、権限分離、監査ログを記載します。
決済がある場合は、カード情報を自社で保存しないことを定めます。あわせて、PSP・STORES側と自社側のどちらが何を担うかを確かめます。
API・CSV・SDKの方式と制約
連携方式は、「APIで」と書くより前に、取得・更新できる項目と認証方法を確認します。さらに、レート制限やページング、エラーコードも見ておきます。
- 仕様変更：変更通知やSandboxの有無を確認します。
- CSV：文字コードと取込上限の確認
- SDK：アプリから金額や品名を渡し、端末で決済する仕組み
STORES 決済の公式SDKは、カード、電子マネー、QRコードを読み取り、決済情報をアプリへ戻す仕組みです。公式ページでは、初期費用と月額使用料は不要と案内されています。
PCI-DSS基準に準拠した決済システムを導入できます。ただし、開発者登録や加盟店審査、利用規約、アプリの責任範囲は、別途確認が必要です。
データ移行と受入テストの条件
旧システムからの移行では、商品コードの重複や販売終了商品、顧客の同意情報、在庫数の扱いを、あらかじめ決めておきます。
未発送注文や返金済みの注文も対象になります。さらに、移行前のバックアップと、移行後の件数照合も作業範囲に含めます。
- 正常系：画面表示の確認にとどまらず、現場の業務が完了するかを確かめます。
- 例外系：在庫切れや取消、返品、返金、部分出荷、通信断を試します。
- 再実行：決済失敗、同一注文の再送、権限のない操作の確認
不合格だった場合に備えて、修正期限と再テストの方法も決めておきます。
契約形態と責任分界の選び方
契約は、準委任、請負、フェーズごとの組み合わせが一般的です。選ぶときは、要件の確定度と成果物の明確さを見ます。さらに、変更の多さや、発注側の管理工数も判断材料になります。
要件整理や継続的な改善に向く準委任契約
準委任契約は、専門家の知識や作業時間を提供してもらう形です。導入方針や業務棚卸し、RFPを進めるときに使いやすい形です。さらに、API調査やPoC、アジャイル開発にも適しています。
- 作業範囲：稼働範囲、体制、作業時間の報告方法を定めます。
- 成果確認：成果の確認方法と、発注側の意思決定者を明確にします。
- 品質：レビュー、テスト、セキュリティ、文書、引継ぎ、障害対応の水準を定義します。
準委任であっても、品質を保証しなくてよいわけではありません。あわせて、現場責任者も明らかにしておきます。
成果物と完成条件を確定できる部分の請負契約
請負契約は、合意した成果物を完成させて引き渡す形です。確定した画面や連携バッチ、移行ツール、テスト仕様書などに使います。
- 納品と検収：納品物、検収期間、修補範囲の定め
- 権利と委託：知的財産権や再委託、秘密保持を確認します。
- 契約不適合：成果物が契約内容に合わない場合の対応
要件が固まらないまま全工程を請負にすると、変更のたびに追加見積や納期調整が起きやすくなります。
たとえば、要件定義とPoCは準委任、仕様確定後の一部開発は請負とする方法もあります。契約を分けるときは、前工程の成果物を次工程の前提にします。
決済・個人情報・障害対応の責任分界と契約条項
契約では、次の項目について、関係者ごとの役割と個人情報の扱いを明確にしておきます。
- 関係者：決済事業者やSTORES、開発会社、発注企業、店舗スタッフが関わります。
- 決済対応：カードを保持しない主体、決済失敗の窓口、返金・チャージバックの判断者の決定
- 障害対応：API障害時にどこまで復旧を支援するか
- 個人情報：顧客情報・購買履歴の利用目的と権限、委託先・再委託先
- 保存と削除：ログ保存と、契約終了時の情報の返却・消去
経済産業省は2025年3月に改訂内容を公表し、EC加盟店の対策を示しています。そのうえで、脆弱性対策やEMV 3-Dセキュア、不正ログイン対策を確かめます。
最新のガイドラインと自社の取引形態を照らし合わせ、専門家にも確認します。
STORESのシステム発注・外注費用の相場
費用は、STORESの利用料や決済手数料、端末費に加えて、導入支援費や連携開発費を分けて考えます。
データ移行費、教育費、保守費も分けて見ます。月額0円のプランでも、運用全体が無料とは限りません。
次に示す開発費は、リサーチノートにある業務システム一般の相場と、類似するEC・POS連携案件から組み立てた目安です。STORES公式の開発価格ではありません。
公式料金のプラン・サービスごとの確認
2026年8月時点で確認できるSTORES ネットショップの公式料金ページでは、次の条件が案内されています。
- フリープラン：ネットショップは月額0円で、決済手数料は5.5％からです。
- スタンダード：年契約は月額3,300円（税込）、月額契約は3,960円（税込）です。決済手数料は3.6％からです。
- 料率：対象決済手段と契約期間で変わるため、売上規模に合わせて確かめます。
- 対面決済と端末：フリープランは端末費用27,720円（税込）、スタンダードは1台無料との案内があります。
- ポイント連携：ポイント・ランクシステムとのSTORES連携は月額22,000円からです。
STORES全体の料金ページでは、サービス構成に応じて、対面決済の料率や端末費などの別条件が示されています。
最新の条件は、契約するサービスの公式料金ページで確かめます。
外部連携の費用は50万円から1,200万円程度の幅
連携費は、対象機能と期間をそろえて比べます。次に示す目安は、要件や既存システムの仕様、テスト範囲によって変わります。
- CSVなどの単方向連携：50万〜200万円、1〜3か月程度です。
- API連携：認証、エラー再処理、日次突合を含み、150万〜600万円、2〜5か月程度です。
- 複数店舗の統合：在庫・顧客・ポイント、本部画面を含みます。権限や通知、運用設計も含み、300万〜1,200万円、4〜12か月程度です。
商品・注文・売上の単方向連携や、簡易ダッシュボードは、CSV連携の範囲に含まれます。
比べるときは、連携の本数よりも、返品や返金、在庫調整、障害時の再処理まで含めたシナリオで見ます。
STORES型の新規開発は1,000万円以上の想定
独自の会員・予約・ポイント・注文管理や、決済SDK、マルチテナント、外部API基盤を含む中規模サービスを想定します。その場合、費用は1,000万〜5,000万円、期間は6〜18か月程度が推定レンジです。
決済やPOS、予約、EC、分析をコアプロダクトとしてフルスクラッチで開発し、多店舗や高負荷、監査対応も必要になる場合があります。
この場合、5,000万円〜1億円以上、12か月から2年以上となる可能性があります。
これらは要件と体制から算出した推定で、一律の市場価格ではありません。人月単価の仮置きは次のとおりです（出典: 業務システム全般のNotebookLM調査ノート、2026年）。
- PM：月90万〜150万円です。
- 設計SE：月65万〜110万円です。
- プログラマー：月50万〜90万円です。
- テスター：月45万〜80万円です。
要件定義と設計、実装、テストのほか、移行や教育、保守も別行にします。そのうえで、最終的には要件定義後の見積を採用します。
委託先の選定と見積比較の観点
委託先は、知名度や初期費用だけでなく、STORESと自社業務の境界を整理できるかで選びます。導入支援、EC・POS連携、個別開発のどれに強いかは、会社ごとに異なります。
似た規模・業務の実績と担当体制
「EC開発の経験」の有無に加えて、店舗数やSKU、月間注文数を聞きます。さらに、連携先や決済の扱い、移行件数、リリース後の保守も確かめます。
可能であれば、提案会社が直接担当した範囲と、再委託した範囲を分けて示してもらいます。
- 担当者：営業、PM、業務設計者、エンジニア、テスター、保守窓口の配置
- 継続体制：要件定義からリリースまで、同じ責任者が関わるかどうか
- 変更時の備え：契約後に体制が変わる場合の条件と代替要員を契約に入れます。
機能・工数・前提条件を同じ粒度で比べる見積
合計金額は、判断材料の一つにすぎません。要件定義やUI設計、API調査、実装は、別々の行に書いてもらいます。テストや移行のほか、マニュアルや研修、リリース立会い、保守も、項目ごとに分けます。
各項目の工数と単価を確かめます。「連携一式」「テスト一式」「保守一式」のように一式と書かれた項目は、含まれる作業を質問します。
- 開発条件：店舗数、SKU数、月間注文数、API本数、画面数を、会社間で同じ条件にします。
- 運用条件：同時利用者数、移行件数、テストケース数、希望納期の条件
- 総費用：月額、追加店舗費、端末を比べます。API保守やクラウド、障害対応、改修単価も比べます。
初期費用が安くても、運用費が高ければ、5年間の総費用で逆転することがあります。
運用・障害・引き継ぎまでの確認項目
API障害で注文が重複した場合や、決済後に在庫更新が失敗した場合について、復旧方法を質問します。
返金後に会計連携が止まった場合の手順も確かめます。監視やログ、再処理、問い合わせ窓口について説明がない場合は、注意が必要です。
- 引継ぎ資料：画面一覧、データ項目、API仕様、環境構成、アカウント一覧
- 運用資料：バックアップ、障害対応手順、テスト結果の確認
- 権利と設定：ソースコードや設定の引き渡し条件を確認します。
運用保守費は、初期開発費の年15〜25％程度を仮置きする考え方もあります。また、SaaS利用料や決済手数料、クラウド費は、別に見積もります。
2026年時点のSTORES発注で見ておきたい最新動向
2026年時点では、システムを安く作ることだけでなく、外部サービスを組み合わせて早く検証することが重視されます。
さらに、データ連携とセキュリティを継続して運用できるかも問われます。STORESの標準機能やSDKを活用し、独自開発は競争力のある部分に絞るのが現実的です。
標準機能・連携・独自開発の段階的な組み合わせ
標準業務が中心なら、STORESのSaaSを第一候補にします。独自業務が一部ある場合は、STORESと外部連携基盤を組み合わせます。
会員・ポイント・予約・料金計算・マルチテナントが差別化要因なら、独自サービスとして開発する余地があります。
- 1店舗のPoCでの検証
- 数店舗でのパイロット
- 本部展開を経た、全店への展開
各段階で、在庫差異や決済成功率、返品処理時間を確かめます。さらに、会計突合の差異やスタッフの操作時間も見ておくと、次の投資を判断しやすくなります。
決済情報を持たない設計と3Dセキュア・脆弱性対策
決済を組み込む際は、カード情報の保管を避け、自社システムの責任範囲を決めます。
- カード情報：カード番号を自社データベースへ保存しない設計が基本です。
- 決済結果：SDK利用時も、注文・在庫への反映は自社の責任です。
- 取引追跡：決済成功や注文登録の失敗、再送、返金、チャージバックを、同じ取引IDで追います。
- 発注時の対策：診断、管理者認証、ログ監視、委託先管理をRFPに記載します。
STORES ネットショップ公式ページは、3Dセキュア2.0の標準対応を案内しています。
経済産業省の2025年改訂ガイドラインでも、EC加盟店の対策が示されています（出典: 経済産業省「クレジットカード・セキュリティガイドライン」改訂発表、2025年）。そのうえで、脆弱性対策やEMV 3-Dセキュア、不正ログイン対策も確かめます。
導入事例で見る業務改善の結果
事例から、販売機会や手作業の変化を発注条件に落とし込みます。
- 現状値：非公開時間、在庫修正件数、月末の突合時間、返金処理の滞留、問い合わせ件数を記録します。
- 導入後の目標：記録した現状値をもとに設定します。
「bon but」の事例では、イベントで売れた商品をネットショップの在庫から減らせず、最大3日ほどネットショップを非公開にすることがあったとあります。
STORES レジとの在庫連動後は、イベント中も公開でき、決済端末でのまとめ買いが増えたと紹介されています（出典: STORES「bon but」導入事例、確認日2026年8月）。
STORESのシステム発注・外注でよくある質問
費用のほか、標準機能と開発範囲について回答します。連携方式や契約、運用の考え方も取り上げます。
STORESの導入は開発会社に依頼する必要がありますか？
標準機能だけなら、必ずしも開発会社へ依頼する必要はありません。商品登録や教育、移行、業務整理に不安があれば、導入支援会社へ相談します。
会計・在庫・CRMとの独自連携が必要なら、開発会社へ相談します。
STORESと外部システムの連携費用はどのくらいですか？
単方向のCSV連携は50万〜200万円で、初期検討の目安です。認証や再処理、日次突合を含むAPI連携は、150万〜600万円程度です。
店舗とECの在庫や顧客、ポイント、本部管理まで統合する場合は、300万〜1,200万円程度になることがあります。
いずれも要件定義後に確定するもので、公式の一律価格ではありません。
STORES 決済SDKを使えば自社で決済機能を作れますか？
自社アプリから決済情報を渡し、端末で処理する構成は検討できます。公式ページでは、SDKの初期費用と月額使用料は不要と案内されています。
加盟店審査や規約、アプリ開発は、別途必要です。さらに、注文や在庫への結果反映と、障害時の再処理も必要です。カード情報を自社に保存しない設計や、責任分界も確かめます。
安い見積と高い見積はどこを比較すればよいですか？
見積ごとに、要件定義や設計、実装、テストの範囲を比べます。さらに、移行や教育、保守、障害対応まで含まれているかも確かめます。
再処理や返品・返金、日次突合が除外されていないか確かめます。権限や監査ログ、リリース後の問い合わせが、見積から漏れていないかも見ます。
初期費用と5年間の総費用を、同じ条件で比べます。
まとめ：標準機能と独自開発を分ける発注の考え方
既存STORESの導入、外部連携、STORES型サービスの新規開発に分けて考えます。業務とデータの正を整理したうえで、RFPに連携方式や例外処理、非機能要件を書きます。さらに、移行やテスト、保守も書きます。
標準機能で始め、独自性のある部分に絞った開発
標準機能で解決できる領域まで作ると、費用と保守負担が増えます。1店舗または1業務のPoCで、在庫や決済を検証します。さらに、返品と返金、入金も確かめます。
効果を確認できた機能から、段階的に展開します。
見積依頼で確認する5年間の運用と責任分界
初期費用に加えて、月額や決済手数料、端末費を含めます。さらに、移行や教育、保守に加え、追加改修や障害対応まで含めて、総費用を比べます。
データの正や再処理、セキュリティを確かめます。契約やソースコード、設定の引き渡しも押さえておくと、導入後の手戻りを減らせます。
▼全体ガイドの記事
・STORESのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。