無人店舗システム開発の発注/外注/依頼/委託方法について

無人店舗システムの発注は、まず店舗条件と例外業務を整理し、方式と委託先を選びます。そのうえで1店舗で実証し、運用負荷を確かめてから本番に展開します。

全体像は、無人店舗システム開発の完全ガイドにもまとめています。

▼全体ガイドの記事
・無人店舗システム開発の完全ガイド

無人店舗システムの発注・外注で押さえる全体像

無人店舗システムは、入店認証から商品選択、決済、退店までを一連の流れでつなぐ仕組みです。店舗の機器に加えて、在庫・売上管理と遠隔監視も連携します。

そのため発注では、機器だけでなく業務フローと、障害時に人が介入する方法まで含めて扱います。機器を揃えただけでは、店舗は運営できません。

「無人化する業務」と「人が残る業務」の切り分け

自動化は、収益と顧客体験を改善する業務から選びます。入店や会計を自動化しても、補充や棚の整理、期限確認は人の仕事として残ります。

清掃や返品、問い合わせへの対応も、人が担う業務として残ります。決済に失敗したときの対応も、人が行う必要があります。

残る業務は、担当を決めておかないと現場で誰も手を付けない状態になりやすいものです。そのため発注書には、自社スタッフ、委託先、遠隔オペレーターのうち誰が担当するかを明記します。

店舗モデル別に適する発注先

店舗モデルによって、候補となる方式は変わります。たとえば、商品数が少ない売場や、冷凍・冷蔵商品を扱う小型拠点では、スマート販売機型が候補になります。

  • 夜間のみ無人化:入退店認証とセルフレジを組み合わせたハイブリッド型。
  • 買い回りとレジ待ち解消:QR入店後、カメラや重量センサーで商品を認識するウォークスルー型。

無人店舗システムの発注形態の選び方

短期間で始める場合、既存連携が多い場合、独自モデルの場合に応じた3つの発注形態を示す図。
店舗の始め方や既存連携の量が、方式選びの分かれ目になります。

発注形態は、短期間で小さく始めたいか、既存連携が多いか、独自モデルが必要かで選びます。短期間で始めるならSaaS・パッケージ型、既存連携が多ければクラウドとSIerの組み合わせが適します。独自モデルの場合は、個別開発型を検討します。

方式を決める前に1店舗で検証する範囲を切り出しておくと、初期投資が過大になるのを避けやすくなります。

SaaS・パッケージ型での発注

SaaS・パッケージ型は、完成済みの機能を月額で使う形です。入店認証やセルフレジ、商品管理などの機能が含まれます。

  • 標準機能で足りる場合:店舗数が少なければ、要件定義や開発期間を抑えやすい形態です。
  • 独自要件がある場合:商品コードや会員制度、割引、返品処理に合わせると、追加開発や運用変更が発生します。

公開価格の例として、ネブラスカ技術研究所のデジテールストアは、初期費用40万円から、月額費用4万円からとしています(出典: 株式会社ネブラスカ技術研究所「デジテールストア」、確認日2026年8月)。

この金額は公開されている目安で、改装や端末、決済手数料などは含まれていません。通信、保守、補充人件費も別に確かめる必要があります。そのため、見積もりでは標準料金と追加費用を分けて確認します。

クラウドサービスとSIerの組み合わせ

クラウドサービスとSIerを組み合わせる方式は、機器や決済、業務システムの強みを分けて活用します。

役割がクラウドとSIerにまたがるため、どこまでを誰が受け持つかを先に分けておく必要があります。

  • 役割分担:クラウドで店舗管理・決済・認証を使い、商品マスタや在庫、会員、基幹とのAPI連携はSIerに任せます。
  • 適する案件:多店舗展開や既存事業との接続に向いています。
  • 責任範囲:店舗ゲートや決済、認識エンジンなどを、構成図と一覧表で担当ごとに分けます。

障害時にどこへ連絡するかが曖昧なままだと、復旧が遅れるおそれがあります。そのため、一次窓口、復旧目標時間、ログの受け渡し方法は、契約前に決めておきます。

スクラッチ開発による独自モデル

標準サービスでは差別化できない要件がある場合は、個別開発を検討します。

  • 対象となる要件:独自商品、入店体験、購買分析、本部管理。
  • 一体設計できる範囲:カメラや重量センサー、ゲート、決済、クラウド、管理画面まで。
  • 自社で負担する費用:機器の更新、認識精度の改善、OSや決済仕様の変更。
  • 実証と受入条件:限定商品や時間帯で試し、誤認識1件あたりの返金と問い合わせ工数、通信断からの復旧、スタッフの対応可否を確かめます。

ポイント

短期間で小さく始めるなら、SaaS・パッケージ型から検討します。既存連携が多ければクラウドとSIerの組み合わせ、独自モデルが要るなら個別開発を比べます。

RFPと要件整理の準備範囲

RFP(提案依頼書)は、何を、なぜ、いつまでに、どの条件で提案してほしいかを伝える文書です。

機能一覧に加えて、店舗の現状と目標KPIを書きます。顧客や商品、時間帯の条件も示します。既存システムと運用体制、予算の考え方を書き、評価基準も加えると、提案と見積もりを比べやすくなります。

現場の例外から整理する業務要件

業務要件は、通常の購買手順だけでなく、現場で起きる例外や店舗条件から整理します。

  • 購買時の例外:入店失敗や商品を棚に戻す操作、複数人の同時利用、セットの分割、決済失敗、返品、未成年者の酒類購入。
  • 店舗条件:面積や営業時間、1日の取引数、ピーク時間、SKU数、冷蔵・冷凍設備、通信、電源、入口と出口、スタッフの到着時間。
  • 認識の確認対象:類似包装、量り売り、セット商品、季節商品。

無人店舗の品質は、例外時の安全な処理と顧客への説明で大きく変わります。自動化率だけを見ると、この部分を見落としがちです。

RFPの機能・非機能・運用条件の分け方

RFPでは、機能と非機能、食品の衛生管理を分けて記載します。

  • 店舗機能:入店認証、年齢確認、商品登録、決済、返金、在庫、売上、クーポン。
  • 管理機能:遠隔監視、アラート、権限管理、レポート。
  • 非機能:稼働、応答時間、通信断時の動作、監査ログ、バックアップ、保存期間、個人情報、セキュリティ更新、復旧目標。
  • 食品の衛生管理:温度、補充、清掃、廃棄、ロット、衛生記録。

厚生労働省は、2021年6月1日から、原則としてすべての食品等事業者にHACCPに沿った衛生管理を求めています(出典: 厚生労働省「HACCP(ハサップ)」、2026年確認)。同省は、衛生管理計画と実施記録も案内しています。

そのため、温度や清掃の記録を、システムに残すのか、別帳票と連携させるのかを、発注前に決めておきます。

受入基準と検証方法の示し方

「認識精度を高くする」とだけ書くと、完成後に認識がずれても、何をもって合格とするかが分かりません。そこで、対象商品と照明、カメラの死角を決めます。さらに、同時利用人数と評価期間も定め、受入基準を作ります。

  • 取引品質:誤請求率、決済成功率、入店失敗率。
  • 対応品質:アラート通知、復旧、返金処理にかかる時間。

数値を決められない場合は、測定方法と改善協議の条件を定めておきます。提案書では、標準機能と追加開発を分け、将来対応と対象外も明記してもらいます。実証で確認する内容と、本番展開時の追加内容も区別します。

ポイント

RFPには、通常の購買手順に加えて現場の例外と店舗条件を書きます。機能と非機能、運用条件を分け、受入基準も示すと、提案を比べやすくなります。

無人店舗システムの契約形態の選び方

契約形態は、要件が固まっているか、検証しながら進めるか、完成済みサービスを使うかで選びます。現場条件によって判断が変わるため、企画・実証・本番展開を分けると、リスクを抑えやすい場合があります。

仕様と成果物を明確にできる場合の請負契約

請負契約は、成果物を完成させて検査し、納品する形態です。画面やAPI、機器設定を成果物として明示できる場合に適します。テスト仕様書と操作マニュアルも、成果物として定めておきます。

商品認識や店舗導線を試す実証の段階では、途中の変更が追加費用や納期の延長につながるおそれがあります。そのため、変更管理と再見積もりの条件を契約書に定めておきます。

検証や継続改善を進める場合の準委任契約

準委任契約は、専門家に業務を委託する形です。要件整理や設計・開発の支援、運用改善を進めます。現地調査で課題が見つかる場合や、実証後に認識方式を変える場合に適しています。

店舗スタッフの運用を見ながら画面を改善していく案件にも向きます。作業時間や体制に応じた支払いになるため、範囲と稼働上限を明確にし、成果物と報告方法も決めておきます。

契約で残す機器・データ・障害対応の責任分界

契約では、機器とデータ、障害時の対応ごとに責任分界を決めておきます。

  • 機器・障害:カメラや重量センサー、ゲート、決済端末、通信、電源、工事、交換費、駆け付け、代替運用。
  • 決済・データ:決済失敗時の返金、誤認識時の負担、ログ所有権、個人情報の削除、終了後のデータ返却。
  • 顔識別機能:利用目的、撮影主体、保存期間、アクセス権、問い合わせ窓口。

個人情報保護委員会は、顔識別機能付きカメラについて、利用目的の通知や公表、掲示などの留意点を示しています(出典: 個人情報保護委員会「犯罪予防や安全確保のための顔識別機能付きカメラシステムの利用について」、2026年確認)。

防犯目的の顔特徴データをマーケティングへ転用するような場合は、目的の違いを押さえる必要があります。そのため、委託先任せにしない体制を整えます。

ポイント

契約形態は、要件が固まっているか、検証しながら進めるかで選びます。固まっていれば請負、検証や改善を続けるなら準委任が向いています。

無人店舗システムの費用相場とコスト内訳

夜間無人・簡易構成から大規模な個別基盤まで、4方式の初期費用推定レンジを比較した横棒図。
構成が大きくなるほど、推定レンジも上方へ広がります。

費用は、既製サービスを使うか、センサーやAI、基幹連携を個別開発するかで変わります。そのため、公開価格と推定レンジを分けたうえで、初期費用と月額を見積もります。工事と決済も含め、保守や運用人件費も同じ見積もりに入れます。

方式別の初期費用レンジ(推定)

リサーチノートと公開価格をもとにした初期費用の推定は、方式ごとに幅があります。

  • 夜間無人・簡易構成:1店舗で300万〜800万円程度。
  • 既存システムとの個別連携:センサー・カメラとPOS・在庫・決済をつなぎ、800万〜2,000万円程度。
  • AI認識の新規店舗モデル:ウォークスルー型で2,000万〜5,000万円程度。
  • 大規模な個別基盤:本部、分析、24時間監視、既存基幹、BCPを含め5,000万円〜1.5億円超の可能性。

これらは統計的な相場ではなく、機器やソフトウェア、連携、テスト、工事の積み上げから作った推定です。金額は、店舗面積や取引量、SKU数で変わります。さらに、APIやカメラ台数、冷蔵設備、セキュリティ要件でも変わります。

記事の金額をそのまま予算にせず、同じRFPをもとに複数社へ見積もりを依頼します。

初期費用以外に毎月・毎年かかる費用

無人化の費用対効果を判断するには、運用費と導入後の総額を一緒に見ておく必要があります。

  • システム・設備費:利用料、クラウド、通信、決済、機器保守・交換、更新、セキュリティ、電気代。
  • 現場運用費:監視、清掃、補充、棚卸、返金処理。
  • 3〜5年の総保有コスト:初期費用、月額固定費、取引量連動費、機器交換周期、撤去費。

人件費の削減だけを効果と見ると、補充や例外処理にかかる人員を見落としがちです。専用機器や現地保守が別料金の場合、月額が安くても総額が逆転する可能性があります。

追加APIや商品登録、返金対応も、別料金かどうかを確かめておきます。

費用対効果の測り方(人件費と売上機会)

勤務時間の削減だけでなく、営業時間を延ばしたことによる取引数の変化も測ります。待ち時間や購買率、欠品率も、導入前後で比べます。

問い合わせや誤請求、補充時間の変化も測ります。遠隔対応工数も、導入の前後で見比べます。

月間の追加粗利と削減費用の合計が、月間の運用費を上回る地点を、1店舗の損益分岐点として計算します。

ポイント

費用は、公開価格と推定レンジを分けて読みます。初期費用だけでなく、3〜5年の総保有コストで見積もりを比べ、同じRFPで複数社に依頼します。

無人店舗システムの委託先選定と見積比較のポイント

委託先は、知名度や価格だけでなく、店舗運用とシステム開発を一緒に考えられるかで選びます。種類としては、完成済みサービスの会社、無人決済の専門会社、小売基盤に強い大手SIer、業務要件と開発を支援する会社があり、得意範囲はそれぞれ異なります。

委託先の実績の確認範囲(方式・業態・運用)

実績は、導入件数だけでなく、自社と近い店舗条件や運用を基準に見ます。

  • 導入条件:方式や業態、店舗数を確かめます。小型食品販売機と数千SKUの店舗とでは、認識技術や在庫管理、補充業務が異なります。
  • 稼働後の支援:近い事例や保守、障害対応の実績、スタッフ教育について質問します。

たとえば、NTTデータのCatch&Goは、専用アプリのQRコードで入店し、商品を手に取って退店すると決済が行われる、ウォークスルー型です。

同サービスは、カメラと重量センサーによる行動分析も案内しています(出典: NTTデータ「デジタル店舗運営サービス Catch&Go」、2026年確認)。

2026年には、同サービスを使ったLawson Goの開設情報も公開されています。自社の商品や導線、顧客登録の条件に、この仕組みが合うかを照合します。

見積の比較方法(同じ費目と前提条件)

見積書は費目ごとに分けてもらうと、各社の金額を同じ条件で比べられます。

  • 開発:要件定義、設計、アプリ、管理画面、API。
  • 機器と工事:機器の費用と工事費。
  • テスト・教育・移行:作業にかかる費用。
  • 保守・監視・撤去:保守と監視、撤去にかかる費用。

「作業一式」と書かれた項目では、対象範囲と工数、納品物を確かめます。回数と追加料金も含め、前提条件まで見積もりに書いてもらうと、後から費用が発生しない透明性が保てます。

  • 費用と機器:初期費用、月額、決済手数料、機器購入・レンタル、通信。
  • 運用と責任:保守、駆け付け、返金負担、商品登録、既存POS/API。
  • 継続・終了条件:ログ保存、セキュリティ更新、撤去費。

公開価格がない会社には、同じ店舗条件で概算と前提を示してもらいます。

提案評価のセキュリティと遠隔運用

提案評価では、接続機器を守る対策と、障害時の運用をまとめて確かめます。

  • 接続環境:店舗機器やゲートウェイ、クラウド、スマートフォン、決済サービスの構成を把握します。
  • セキュリティ:機器認証、通信暗号化、ネットワーク分離、権限、操作ログ、脆弱性対応、バックアップ、更新を評価します。
  • 障害時の運用:通信断、停電、扉・温度異常、決済失敗、誤認識、商品不足、迷惑行為時の再起動・解錠・営業停止・有人切替・顧客案内をデモで見ます。

カード情報を自社で保持しない設計かどうかや、決済事業者の審査条件は、早めに確かめておきます。完成画面だけでなく、障害時の操作を見せてもらうと、運用の実態が見えてきます。

ポイント

委託先は、近い方式や業態の実績と、稼働後の障害対応を説明できるかで選びます。見積もりは同じ費目と前提条件で並べ、公開価格がない会社には概算と前提を示してもらいます。

発注後の開発・実証・運用開始の流れ

要件定義から設計・開発、機器設置、テスト・実証、改善を経て本番展開へ進む工程図。
実証と改善を挟むことで、本番展開までの確認段階を見渡せます。

発注後は、要件定義から設計・開発、機器設置、テストへ進みます。そのうえで、実証と改善を経て本番展開に至ります。

個別開発の期間は、既存サービスの設定で済む場合が1〜2か月、1店舗の個別連携なら3〜6か月が推定の目安です。AI認識を含む場合、実証から本番までは6〜12か月以上かかるのが目安です。

機器の調達や電気・ネットワーク工事も、計画に入れておきます。加えて、決済審査や商品テスト、教育も含めます。

実証店舗の設計(検証する仮説を絞る)

実証では、システムの動作だけでなく、顧客の入店登録や商品認識、決済を確かめます。さらに、補充負荷や問い合わせ件数も見ます。

対象店舗と商品、営業時間を決めます。測定期間と成功・撤退条件も事前に定めておき、次の項目を測ります。

  • 認識の正解率:商品認識の精度。
  • 誤請求への対応:問い合わせ時間と返金工数。
  • 遠隔オペレーター:解決時間。

認識精度が高くても、例外処理に人手がかかるままでは、店舗全体の費用対効果は改善しないおそれがあります。

本番展開前の運用マニュアルと教育

本番前には、通常の購買手順と例外時の対応を、マニュアルにまとめておきます。

  • 顧客対応:入店できない顧客への案内、返金、返品、未成年者への対応。
  • 設備・障害対応:停電、通信断、機器故障、温度異常、迷惑行為、警察・警備会社への連絡。
  • スタッフ教育:最初の連絡先、営業停止の画面、顧客への説明を練習します。

スタッフは全機能を覚えなくても、自分の役割の手順を確実に動けるようにしておけば足ります。

店舗を増やす際は、1店舗目で見つかった例外を、標準手順と設定テンプレートに反映します。共通機能と店舗別の設定を分けておかないと、保守や教育の費用が増えます。

無人店舗システムの発注・外注でよくある質問

費用、方式、運用について、発注前によくある疑問を取り上げます。答えが条件によって変わる内容は、同じ前提で委託先に確かめます。

無人店舗システムの開発費用はいくらですか?

公開価格の例と、開発全体の推定は分けて考えます。1店舗の夜間無人・簡易構成は、300万〜800万円程度です。

個別のセンサー・カメラと既存のPOS・在庫・決済を連携する場合は、800万〜2,000万円程度が推定の目安です。

機器や工事、保守の内容で、金額は変わります。決済や既存連携も金額を左右します。そのため、RFPを作ったうえで、初期費用と3〜5年の総保有コストを見積もってもらいます。

最初から完全無人の店舗を発注すべきですか?

完全無人から始めるより、夜間無人や限定商品、1店舗の実証から進める方法が現実的です。削減効果が見込める時間帯や業務から、段階的に広げていきます。

補充や清掃、返品は、人が関わる業務の代表例です。問い合わせや誤認識、決済失敗への対応も、先に洗い出しておきます。

無人店舗システムの委託先はどう選べばよいですか?

似た業態や商品数、店舗規模での実績があり、機器からソフトウェア、既存システム、現場運用まで、責任範囲を説明できる会社を選びます。

見積もりに加えて、障害時の窓口や返金負担、保守時間を比べます。API、データ所有権、契約終了時の移行も確かめておきます。可能なら、実証デモや導入先への確認も行います。

まとめ

発注前の店舗条件と業務範囲の確定

店舗モデルや商品、営業時間を整理します。取引数や既存システム、残す業務も含め、完全無人を前提にせず検討します。その後、SaaS・パッケージ型、クラウドとSIer、スクラッチ開発を比べます。

RFPには、通常時と例外時の要件を記します。そのうえで、方式と委託先を同じ条件で検討します。

小規模な実証による総保有コストと運用負荷の確認

費用は、公開価格と推定レンジを区別したうえで、3〜5年の総保有コストで比べます。機器や工事、決済を含めます。さらに、保守や通信、補充、返金も、この総額に加えます。

契約では、成果物や受入基準、責任分界を明確にします。データと障害対応の取り決めも、契約に残しておきます。そのうえで、1店舗で顧客体験や運用負荷、投資回収を確かめてから展開します。

▼全体ガイドの記事
・無人店舗システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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