公共くじ販売システムの費用は、対象範囲、販売チャネル、運用・災害対策によって、500万円〜5億円超まで変わります。
範囲が広がり、チャネルが増え、運用や災害対策が厚くなるほど、費用は大きくなります。
▼全体ガイドの記事
・公共くじ販売システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共くじ販売システムの概要
公共くじ販売システムは、発売から監査までを複数の関係者で管理する業務基盤です。
宝くじとスポーツくじの制度と責任分界の違い
宝くじとスポーツくじは制度が異なるため、業務を担う主体と責任範囲を先に分けておきます。
- 宝くじ：都道府県と20の指定都市が発売元です。
- 受託銀行：発売などの事務を担います。
- スポーツくじ：実施主体と販売・払戻しの運用が異なります。
宝くじは当せん金付証票法に基づく制度です。
宝くじ公式サイトは、券の印刷、売りさばき、抽せん、当せん番号の発表、当せん金の支払いを受託銀行等の業務として挙げています（出典: 宝くじ公式サイト「宝くじの仕組み」、2026年閲覧）。
自治体、受託銀行、販売店、開発会社の責任範囲が曖昧だと、取引を確定させる主体を決められず、後から揉めやすくなります。
スポーツくじは、スポーツ振興投票の実施等に関する法律に基づく制度です。
両方を扱う場合は、共通化できる商品マスタと、分けて持つべき法令・規約・精算ルールを、要件定義の段階で切り分けます。
販売・決済・抽せん・払戻しを一つの業務フローで扱う範囲
販売画面だけでなく、取引の正しさを示す記録と、異常時にも業務を続けられる仕組みまで設計する必要があります。
- 販売：商品マスタ、発売期間、売り場端末、Web、スマートフォンの管理
- 取引：会員情報、購入履歴、決済、売上確定、取消・返金を扱います。
- 結果処理：抽せん、当せん判定、払戻し、日次締め、販売店・銀行との照合を行います。
- 運用：権限、操作ログ、不正購入検知、障害監視、バックアップ、災害復旧を整えます。
問い合わせ対応まで含めて、実運用に必要な機能を洗い出します。
ネット販売では、購入記録を紙の券ではなく電磁的記録として預かる運用もあります（出典: 宝くじ公式サイト「ネット購入」、2026年閲覧）。
購入時刻と決済受付、購入確定、当せん金の受取口座を一貫して追跡できる設計が必要になります。そのため、購入画面の開発だけでなく、状態管理と照合にも費用がかかります。
公共くじ販売システムの開発の進め方
開発は、制度確認と現状調査を済ませてから要件定義に入り、PoCを経て設計・開発へ進みます。テスト、移行、運用設計は、その後に続きます。制度の整理と異常系の洗い出しを省くと、後工程で大きな手戻りが生じます。
要件定義で最初に決める制度・業務主体・取引量
要件定義では、対象制度と関係者、システム化の範囲を決め、取引量は数字で示します。
- 制度と主体：宝くじかスポーツくじかの別と、発売元や実施主体。
- 業務範囲：銀行、販売店、決済会社、払戻し主体それぞれの範囲。
- 取引量：チャネル数、商品数、発売回数、注文数、同時接続数を数えます。
- 復旧条件：保存年限、RTO、RPOを数値化します。
RFPには、決済タイムアウトや二重送信、売上確定後の取消、販売停止中の注文を記載します。抽せん結果の登録ミスや払戻しの失敗、通信断、災害切替も、業務シナリオに含めます。異常時の業務まで書いておくと、開発会社は同じ前提で見積もれます。
ログの保存年数、承認者、復旧時間まで定めておくと、会社ごとの見積もりを同じ条件で比べられます。
決済・照合・ピーク負荷を小規模に試すPoC
費用とリスクが大きい箇所は、全機能を開発する前にPoCで確かめます。
- 決済：3Dセキュアを含む決済連携と、再試行の動き
- 状態同期：端末とWebで、販売停止や購入確定の状態がそろうか
- 照合：売上データと金融機関データの突き合わせ
- ピーク負荷：想定ピーク時の応答時間
抽せん結果の二者承認や、購入確定と決済確定のずれも、検証の対象に含めます。
宝くじ公式サイトは、2022年9月5日から3Dセキュア2.0に対応したと説明しています（出典: 宝くじ公式サイト「本人認証サービス」、2026年閲覧）。カード会社によっては、ワンタイムパスワードや生体認証が必要になります。そのため、画面の動きだけでなく、重複購入の防止と、問い合わせ時の追跡番号まで確かめます。
本番移行のリスクを抑える段階テストと並行稼働
テストは、単体と結合から始まり、性能とセキュリティ、障害と業務リハーサルへと進みます。
- 単体・結合・性能・セキュリティの確認
- 障害、業務リハーサル、災害切替の検証
- 並行稼働で、日次締めと報告書を突き合わせる
端末とWebから同じ注文が届く場合や、決済だけが成功する場合も再現します。抽せん結果の承認者が不在のときなど、現場が困る状態も確かめておきます。
移行対象は、購入履歴、会員情報、未払戻しデータです。商品マスタと販売店情報も対象に含まれます。移行前後の件数と金額を照合したうえで、新旧システムを一定期間並行して動かします。切り替え後の事故対応費も含めて見ておくと、後からの想定外の出費を抑えられます。
公共くじ販売システムの費用相場とコストの内訳
標準価格は公開されていないため、ここで示すのは、2025〜2026年の公開調達と公共・金融系システムの要件から整理した概算です。税別か税込か、単年か複数年か、機器やライセンスを含むかによって、金額は変わります。
段階別の開発費の幅
開発費と期間の目安は、方式と対象範囲によって変わります。
- 企画・RFP支援：500万円〜2,000万円、1〜3か月です。
- 準パッケージ：3,000万円〜1億円、6〜12か月です。
- 複数チャネル：8,000万円〜3億円、12〜24か月です。
- 基幹更改：1.5億円〜5億円超、18〜36か月です。
複数チャネルでは、売り場端末とWebを連携させ、決済や抽せんから払戻し、精算までを作ります。
基幹更改では、全国規模の販売、24時間運用、複数拠点の災害対策を含めます。さらに、厳格な監査と長期の並行稼働まで加わると、5億円超になる可能性があります。
費用を開発、人員、接続、移行、検査に分けた内訳
見積書は、作業ごとと接続先ごとの試験工数を分けて確かめます。
- 開発：要件定義、画面、業務ロジック、管理画面にかかる工数と担当人員
- 連携：端末、決済、抽せん、当せん判定、精算、照合との接続
- 移行・教育：データ移行、教育、マニュアル、受入支援
- 検査・保護：診断、ログ、鍵管理、バックアップ、災害復旧
外部接続が増えると、認証やエラー処理の設計、疎通試験が必要になり、障害時に誰がどこまで受け持つかも複雑になります。
PCI DSS v4.0.1は2024年6月に公開されました（出典: PCI Security Standards Council「PCI DSS v4.0.1」、2024年）。
カード情報を扱う範囲では、対象の確認や評価への対応が、追加費用になる場合があります。
初期費用とは別に見る年間保守費と5年TCO
初期費用だけでは全体が見えないため、保守と5年TCOを分けて比較します。
- 年間費用：初期開発費の15〜25％程度が目安です。
- 金額の目安：年2,000万円〜1億円超になる場合があります。
- 5年TCO：ライセンス、クラウド、端末更新、保守を合算した額です。
24時間365日の一次監視や、休日・発売日の復旧体制を契約すると、運用費は増えます。
日本スポーツ振興センターは、2025年11月27日にデータマネジメント基盤を1億2,034万2,200円で落札しました。
2026年1月7日には、マーケティングツールの利用・運用保守を2億8,278万1,422円で落札しています（出典: 日本スポーツ振興センター「落札・結果情報 令和7年度」、2026年閲覧）。
いずれも中核の開発費ではありません。ただし、周辺の基盤でも複数年の契約が億単位になることがあります。また、初期費用が安くても、独自ライセンスや特定ベンダーへの依存によって、改修の単価が上がる場合があります。
公共くじ販売システムの費用が変動する要因
ネット専用か端末を含むか、販売だけか払戻しや精算まで含むかによって、費用は変わります。
工数を左右する販売チャネル数とピーク時の取引量
チャネル数とピーク時の取引量は、平均値だけでなく同時接続数で見積もる必要があります。
- 販売経路：Web、スマートフォン、売り場端末の連携
- 関連画面：金融機関、会員サイト、キャンペーンサイトを扱います。
- ピーク条件：同時接続数、毎秒注文数、決済応答時間を基準にします。
発売日や抽せん日の前後は注文が集中するため、チャネル間で注文の状態をそろえる必要があります。根拠のない「秒間数万件」という前提は、必要以上のインフラと試験費用を招きます。
負荷モデルは、アクセスログと発売計画をもとに作ります。そこに購入件数と同時操作を重ね、安全率を加えます。
費用を左右する既存資産と外部接続の複雑さ
既存資産を再利用できるかどうかと、外部接続の方式や、どこまでを誰が受け持つかを確かめます。
- 既存資産：ホスト、端末、銀行精算、会計、顧客管理、分析基盤の確認
- 古い方式：変換処理、再送制御、照合、手動運用の設計
- 検証済み部品：決済、会員、通知を使えるなら、新規で作る範囲を絞る。
パッケージやSaaSでは、ライセンス、データの所在、API制限を確かめます。契約が終わるときのデータ返却と再委託の条件も、安さだけで決めないよう押さえておきます。
可用性・監査・セキュリティの水準と費用
可用性、監査、セキュリティの要求は、対象業務の重要度に応じて分けて考えます。
- 可用性：24時間365日運用、複数拠点、自動切替の検討
- 復旧：遠隔地バックアップと厳格なRTO・RPOの確認
- 統制：本人確認、限度額、不正検知、権限分離、二者承認の設計
- 監査：操作ログ、暗号鍵、脆弱性診断の対象
商品マスタや分析基盤を、購入確定・決済・精算・抽せん関連と分けておくと、重要度に応じて冗長化の度合いを使い分けられます。対象データと管理者の操作は、基本設計の段階で定めておくほど、後の手戻りを減らせます。
公共くじ販売システムのコストを抑える工夫
コストを抑えるには、機能を一律に減らすより、投資の優先順位を決めるほうが効きます。
対象範囲を分けた段階導入
最初は、利用者と現場が必要とする範囲に絞り込みます。そのうえで、利用データを見ながら、次の投資判断を更新します。
- 第一段階：商品マスタ、会員登録、購入、決済、履歴、結果照会の開発
- 第二段階：分析、キャンペーン、販売店向け画面の追加
- 共通基盤：取引IDと履歴の設計を、最初の段階から行う。
払戻しや精算、監査ログ、データ連携を後から足せるよう、境界を決めておきます。逆に、取引データを画面側だけに保存すると、会計や監査へつなぐ費用が高くなります。
準パッケージとクラウドの使い分け
標準化しやすい機能は準パッケージやクラウドに任せ、制度に固有の領域は専用設計を検討します。
- 標準化領域：商品、会員、通知、CMS、分析、監視が対象です。
- 制度固有領域：購入確定、抽せん、当せん判定、精算は分けて扱う。
- クラウド確認：ISMAP、保存場所、ログ、鍵、バックアップの確認
制度に固有で監査が必要な領域は、専用設計や分離環境のほうが変更費用を抑えられる場合があります。また、クラウドを使う場合は、ピーク時の伸縮や常時稼働の料金に加えて、監視とログ保管、専用接続の料金も、5年分で比べます。
将来の改修費を抑える共通部品と標準化
複数の業務で使う機能は共通化しておくと、商品を追加するときのテストや運用手順を減らせます。
- 共通部品：認証、権限、通知、監査ログ、帳票、ファイル連携を一つにまとめる。
- 商品管理：個別画面ではなく、商品マスタとルール設定で広げる。
- 発注者資産：API、辞書、手順、テストデータ、障害履歴を残す。
- 契約条件：所有権、再委託、データ返却、移行支援の明記
特定ベンダーだけが理解できる独自仕様を減らせば、将来ベンダーを変えるときの費用を抑えられます。
公共くじ販売システムの見積もりを取る際のポイント
見積もりを頼む前に、対象範囲と関係者、取引量、外部接続を整理しておきます。セキュリティと可用性、移行、運用期間も洗い出します。要件が未確定なら、企画・要件定義・RFP支援の見積もりを分けて依頼します。
RFIとRFPで確認する項目の違い
RFIでは市場と候補会社を確かめ、RFPでは同じ条件で各社の提案を求めます。
- RFI：対応可能な会社、端末・決済の経験、標準機能の確認
- RFP：機能、非機能、業務シナリオ、受入基準、納期の提示
- 体制：再委託、保守、契約終了時の移行支援の提示
- 公共調達：資格、実績、ISMAP、PCI DSS、個人情報管理の確認
資格名だけでなく、同規模の取引量での実績や、発売日・障害時の対応実績を質問します。再委託先とその役割も、具体的に確かめます。
複数社の提案の機能・体制・TCOによる比較
合計金額だけでは判断できないため、工程別の費用、体制、5年TCOをそろえて比べます。
- 工程別費用：要件定義、設計、開発、試験、移行、教育ごとに分ける。
- 別途条件：性能試験、診断、休日対応、端末交換、法改正の扱い
- 担当体制：責任者、業務、決済、セキュリティ、端末、運用の各担当
含む、含まない、別途の三つに分けると、安い提案の前提が見えてきます。
障害時の指揮系統やエスカレーション、交代時の引き継ぎ方法も、提案書に書いてもらいます。
契約前に定める追加費用と責任分界
追加費用が発生する条件と、発注者・接続先・ベンダーの責任分界は、契約の前に決めておきます。
- 追加要因：不明な接続、商品追加、制度改正、データ不良
- 性能・障害：性能不足、再委託先の変更、休日対応
- 契約条件：SLA、監視、復旧、脆弱性、監査協力の取り決め
- 終了条件：所有権、再委託の承認、データ返却、移行支援の取り決め
提供データや試験環境、保証する性能は分けて整理し、前提が変わったときの変更管理の手順も決めておきます。
運用保守は、開発の完了後ではなく、RFPの段階で5年分の費用と責任を示してもらいます。
よくある質問
相場は概算にすぎないため、価格は条件をそろえてから確定します。そろえる条件には、取扱量、チャネル、既存資産があります。法令・監査と運用期間も、そろえる対象に入ります。
公共くじ販売システムの開発費はいくらですか？
企画・RFP支援は500万円〜2,000万円、準パッケージは3,000万円〜1億円が目安です。複数チャネルは8,000万円〜3億円、基幹更改やDR込みは1.5億円〜5億円超が目安です。
税区分と対象範囲をそろえ、運用期間と既存システムとの接続条件も合わせて比較します。
パッケージを使えば開発費を大きく下げられますか？
標準化しやすい機能では、パッケージやクラウドで開発期間を短くできる可能性があります。ただし、抽せんや当せん判定、払戻しを無理に合わせると、追加改修が増えます。精算と監査ログも、無理に合わせると追加改修の対象になります。
パッケージの場合も、5年TCOと、ベンダーを交代するときの移行費まで確かめる必要があります。
見積もりで特に確認すべき項目は何ですか？
まず、販売チャネルとピーク時の取引量、既存接続を確かめます。決済と抽せん、払戻しと移行の範囲も、見積もりで確認しておきます。
性能試験、セキュリティ、監査は、見積もりの対象に入るかを確かめます。障害対応や法改正、端末更新、5年間の保守費も、含まれているかを見ておきます。
「別途」の条件と単価、発注者・受託銀行・ベンダーの責任分界を明確にします。
まとめ
費用は500万円〜2,000万円から、複数チャネルの8,000万円〜3億円まで幅があります。
基幹更改や災害対策を含む場合は、1.5億円〜5億円超が目安です。
費用は、決済や購入記録から抽せん、払戻し、精算、監査、運用継続までの範囲で決まります。
最初に決める制度と責任分界
宝くじとスポーツくじを区別し、関係者の役割と異常時の業務をRFPに記載します。
- 制度：発売元・実施主体・受託銀行・販売店の整理
- 取引：決済タイムアウト、二重購入、販売停止を想定します。
- 継続：抽せん承認、災害切替、日次照合の決定
決済会社と払戻し主体の役割も、制度ごとにRFPへ明記します。
5年TCOで比べる開発会社の選び方
5年TCOには、開発と接続、端末、クラウドを含めます。セキュリティや移行、教育、保守も、5年TCOの中で比べます。
- 標準化領域：段階導入や準パッケージによる効率化
- 中核領域：購入確定・抽せん・払戻し・精算・監査は制度適合性を優先します。
- 継続性：運用を止めない条件を含めた会社選び
見積もりの金額だけで選ばず、法改正と障害対応を含めて5年TCOを比べます。中核領域には制度適合性と運用継続性を優先して予算を配分し、長期の費用を抑えることにつなげます。
▼全体ガイドの記事
・公共くじ販売システム開発の完全ガイド
▼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を創業。