公共くじ販売システム開発の進め方/やり方/流れや方法/手法/工程/手順

公共くじ販売システムの開発は、制度確認、要件定義、設計・開発の順に進めます。そのうえで、テスト・移行、運用開始へと段階を踏むと、制度適合性と説明責任を備えられます。

標準的には8段階で進みます。システムの全体像、費用相場、見積もりの確認点も順に扱います。全体像は公共くじ販売システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・公共くじ販売システム開発の完全ガイド

公共くじ販売システムの定義と全体像

公共くじ販売システムを販売・購入、決済・払戻し、精算・報告、安全・運用の4機能に分けた図解。
購入記録から運用までを、機能ごとに整理できます。

公共くじ販売システムは、複数の販売チャネルで宝くじやスポーツくじを扱うための業務基盤です。購入記録から当せん確認、払戻し、売上精算、収益報告までを一つにつなぎます。

公共くじ販売システムでは、対象業務をオンライン購入に限るのか、売り場端末や金融機関まで統合するのかによって、必要な機能、費用、開発期間が変わります。

「公共くじ」は、一つの法律や運営方式にまとまった言葉ではありません。宝くじとスポーツくじは根拠となる法律が別々のため、企画書では両方を同じ基盤に載せるのかを明記します。

  • 宝くじ:当せん金付証票法に基づく制度です。
  • スポーツくじ:スポーツ振興投票等の実施等に関する法律を根拠とする制度です。

宝くじでは、全国47都道府県と20の指定都市が発売元となり、発売などの事務を銀行などへ委託しています(出典:宝くじ公式サイト「宝くじの仕組み」、2026年確認)。

開発では、発売計画から当せん金の支払いまでの各工程について、自治体と受託銀行のどちらが担うかを要件に反映します。そのなかには、券の製造・配送や売りさばき、抽せん、当せん番号の発表も含まれます。

一方で、スポーツくじは実施主体や販売商品、結果確定の流れが異なります。ここが曖昧なまま進むと、商品マスタや購入上限を後から設計し直すことになり、結果登録や払戻し条件にも作り直しが及びます。

販売から払戻しまでの一貫管理

業務機能と運用機能を分けて整理すると、開発範囲と監査対象を確認できます。

  • 販売・購入:商品や発売、チャネル、会員を管理します。本人確認や購入、券も扱います。
  • 決済・払戻し:決済や売上確定、取消・返金を扱います。抽せん結果の登録、当せん判定、払戻しも含みます。
  • 精算・報告:販売店や受託銀行との精算、自治体などへの報告を行います。
  • 安全・運用:権限や監査ログ、不正利用検知を含めます。問合せ、バックアップ、障害監視、災害復旧、脆弱性診断も入ります。

購入者の注文送信、システムの購入受付、決済事業者の決済確定は、別々の状態として記録します。

たとえば、タイムアウト時に未購入と表示して再購入を促すと、最初の購入も確定して二重購入になる可能性があります。

注文IDや決済照会の結果を、販売停止時刻や端末の通信状態とあわせて、監査証跡として残します。

ポイント

宝くじとスポーツくじは法律が別なので、両方を同じ基盤に載せるかを企画の段階で決めておきます。対象業務をどこまで含めるかで、機能と費用、期間が変わります。

公共くじ販売システムの進め方

公共くじ販売システムの開発を、制度確認・現状調査からRFI・RFP・PoC、要件定義・設計・開発、テスト・移行・運用開始へ進む4段階で示した図。
方式を決める前にPoCを挟む位置が分かります。

画面から作り始めると、制度や精算、監査の条件が後から加わりやすいため、業務の内容と、どこまでを誰が受け持つかを先に固めておきます。

標準的には8段階で進みます。制度確認や現状調査、RFI・RFPの後にPoCを挟み、要件定義、設計・開発、テスト・移行を経て、運用開始に至ります。

企画・現状調査・要件定義の進め方

最初に関係者を洗い出し、データの作成、承認、保管を誰が担うのかを、責任分界表にまとめます。

調査対象は、窓口端末やWebなどの販売チャネルで、スマートフォンや金融機関も含みます。あわせて、商品数と発売期間、日次の取引件数を確認します。ピーク時の同時接続数も、同じ段階で押さえておきます。

また、保存年限と、既存ホストや会計システムとの連携も調べます。RFPには、正常系だけでなく異常時の業務シナリオも記載します。

  • 関係者:発売元や実施主体、受託銀行、販売店、決済会社、払戻し主体を一覧にします。
  • 社内外の担当:会計担当、開発会社、運用会社の役割を明確にします。
  • 異常時の確認:販売停止、通信断、決済タイムアウト、二重送信を想定します。
  • 精算・復旧:売上確定後の取消、抽せんデータの差異、口座不備、端末故障、データセンターの切替を扱います。

RFPでは、販売停止が全チャネルに反映されるまでの時間を定めます。さらに、障害時に購入者へ表示する内容や、復旧後に照合する帳票まで決めておきます。要件定義は、PoCの結果を受けて固めます。

PoCを挟んだ方式の選定と設計・開発

方式ごとに、制度への適合性と追加改修の範囲を比べます。制度固有の条件や運用責任も、選定の材料になります。

  • 専用・準パッケージ:既存部品を使えて短期化しやすい一方、固有条件が多いと改修費が増えます。
  • クラウド・ハイブリッド:Web、会員、分析、監視を伸縮させやすい方式です。
  • フルスクラッチ:業務に適合させやすい一方、品質保証と将来保守が必要です。

クラウドを選ぶ場合は、決済・精算をどこに置くかと、データの所在を確認します。鍵管理や、障害時の責任の分け方も確かめます。

本番開発の前に行うPoCでは、決済連携や3Dセキュアを検証します。加えて、販売停止の同期とピーク負荷を見ておき、データ照合と災害切替も確かめます。

特に、購入確定と決済確定がずれたときの再照会を先に確かめておくと、設計後の大幅な作り直しを防げます。

制度や精算、監査の要件はウォーターフォールで管理し、画面や分析機能はアジャイルで改善する、ハイブリッドな進め方が適しています。

テスト・移行・運用訓練の段取り

各テストでは、受入基準と証跡を残します。

重要な業務の検証では、二者承認や職務分掌も確認します。

抽せん対象データの確定から照合までの手順は、担当者一人では完了しない形になっているかを検証します。

  1. 単体テストや結合テスト、性能テスト、セキュリティテストを行います。
  2. 障害テストと業務リハーサルを実施します。
  3. 抽せん対象データの確定、結果登録・承認、当せん判定、払戻しを検証します。
  4. 日次締めと販売店・受託銀行との照合を確認します。

移行の対象には、商品マスタと会員情報、購入履歴があります。

未払戻し情報や精算残高も含まれ、移行の前後で件数と金額を照合します。

新旧システムを一定期間並行稼働させるときは、どちらを正とするかを決めておきます。

差異を誰が何時間以内に解消するかも、事前に定めます。

本番直前に、災害時の切替、販売停止、問合せ窓口の訓練を行います。そのうえで、SLAと運用手順書を実際に使える状態に整えます。

ポイント

業務と責任の範囲は、画面を作る前に固めます。方式を決める前にPoCで制度への適合と改修範囲を確かめ、本番直前には災害時の切替や販売停止の訓練を行います。

公共くじ販売システムの費用相場とコスト内訳

公共くじ販売システムの開発費用を規模別に示す4パネル図。企画・要件整理は500万円から2,000万円程度、準パッケージ導入または小規模ネット販売は3,000万円から1億円程度、複数チャネル基盤は8,000万円から3億円程度、全国規模の基幹更改は1.5億円から5億円超。
対象範囲が広がるほど、費用の幅も大きくなります。

公共くじ販売システムの標準的な価格は公開されていません。そのため、公開調達情報と公共・金融系システムの要件をもとに、提案依頼前の概算レンジを示します。

税別か税込か、端末や機器の有無、複数年保守の有無で金額が変わります。そのため、総額だけで判断せず、内訳を分けて見ます。

規模別の開発費用と期間

規模ごとの概算レンジをつかんだうえで、機能数だけでなく、既存精算や銀行接続の複雑さも踏まえて比べます。

  • 企画・要件整理:500万円から2,000万円程度、期間は1〜3か月です。
  • 準パッケージ導入または小規模ネット販売:3,000万円から1億円程度、期間は6〜12か月です。
  • 複数チャネル基盤:8,000万円から3億円程度、期間は12〜24か月です。
  • 全国規模の基幹更改:1.5億円から5億円超、期間は18〜36か月です。

企画・要件整理には、制度の整理や現状調査が含まれます。さらに、RFP支援と非機能要件の定義も含みます。

準パッケージ導入や小規模ネット販売では、商品、会員、注文の管理が中心になります。決済や結果照会も主な作業です。ただし、既存精算や銀行接続が複雑だと、同じ機能数でも費用は高くなります。

複数チャネル基盤には、売り場端末とWebに加えて、決済や精算、当せん、監査の機能を含みます。ピーク対策やデータ移行も対象に入ります。

全国規模の更改では、複数データセンターや24時間運用、厳格な業務リハーサルを含む場合があります。

ここに示す金額は確定価格ではありません。金額は取扱高とチャネル数で上下し、既存資産の再利用やSLA、RTO・RPOの条件でも変わります。

保守・インフラ・セキュリティを含めた5年TCO

継続運用に必要な費目を分けて、5年TCO(総所有コスト)で比べます。初期費用と合わせて見ると、全体の負担が分かります。

  • 基盤・機器:クラウドまたはデータセンター、端末・機器の保守です。
  • 運用・安全:監視、ヘルプデスク、脆弱性診断、セキュリティ評価を含みます。
  • 継続対応:バックアップ、災害復旧訓練、法改正や商品追加への改修です。

年間の保守・監視・インフラ・セキュリティ費用は、初期開発費の15〜25%程度、または年2,000万円から1億円超となるケースがあります。

稼働時間やSLAによって幅があるため、複数年の運用費は、初期費用とは分けて確認します。

日本スポーツ振興センターの令和7年度落札情報では、スポーツくじ販売促進に係るマーケティングツールの利用・運用保守が2億8,278万1,422円でした(出典:日本スポーツ振興センター「落札・結果情報 令和7年度」、2026年確認)。

広告宣伝向けデータマネジメント・プラットフォームの利用・運用保守は1億2,034万2,200円でした(出典:日本スポーツ振興センター「落札・結果情報 令和7年度」、2026年確認)。

これらは販促とデータ基盤の調達で、販売・払戻しの中核開発とは別のものです。周辺の基盤でも億単位になり得る点が、費用を見るうえで参考になります。

文部科学省の令和7事業年度資料では、スポーツ振興投票等業務の業務経費が約481.7億円、スポーツ振興投票業務運営費が約285.8億円です(出典:文部科学省「令和7事業年度スポーツ振興投票等業務事業計画・予算・資金計画案」、2025年)。

これは事業全体の予算で、システム開発費そのものではありません。システムの費用を比べるときは、機能、外部接続、機器を分けて見ます。セキュリティと移行、教育と運用も、項目ごとに分けて確認します。

ポイント

金額は規模と対象範囲で大きく変わるため、総額だけで比べないようにします。保守や運用費は初期費用と分け、5年TCOで比べます。

公共くじ販売システムの見積もりを取る際のポイント

複数社から見積もりを取るときは、金額の安さよりも、同じ前提条件で比べられるかを先に確かめます。要件が曖昧なまま価格を求めると、外部接続や監査、障害対応、移行が契約後に加わり、予算と納期が変わります。

RFPに書く数量・品質・異常系の条件

数量と品質の前提をそろえておくと、提案各社が同じ条件で費用と性能を示せます。

  • 販売条件:商品やチャネル、期間、購入上限を示します。決済手段と払戻し方法も含みます。
  • 利用規模:日次取引件数、ピーク接続数、会員数、端末台数です。
  • 連携・保管:データ保存年限、本人確認方法、外部システムを整理します。
  • 非機能要件:稼働時間や目標稼働率、RTO・RPOを示します。障害の検知・連絡・復旧時間、バックアップ頻度、ログの改ざん防止、権限分離も示します。

数量が未確定なら、少・中・大の3ケースで、追加費用と性能条件を提示してもらいます。また、脆弱性診断や災害時の切替方法は、非機能要件に含めます。

カード決済を扱う場合は、PCI DSS v4.0.1の対象範囲、3Dセキュアへの対応、決済情報を保持するかどうかを確認します。PCI SSCの文書では、PCI DSS v4.0.1が現行文書として掲載されています。さらに、一部の将来日付要件は2025年3月31日から有効です(出典:PCI Security Standards Council、2026年確認)。

複数社の提案を体制と実績で比較

提案を比べるときは、見積総額だけでなく、体制の中身も確認します。

  • 開発体制:作業分担、担当者の経験、再委託先を確認します。
  • 運用体制:障害時の連絡網や法改正への対応を確かめます。
  • 契約終了時:データ返却と移行支援の内容を見ます。

公共調達や金融系基幹の経験があっても、くじ販売や抽せん、払戻しを直接手がけたとは限りません。

販売停止を全チャネルに反映する設計や、決済タイムアウト後の再照会、抽せん結果の二者承認について質問します。

RTO・RPOを満たす切替訓練を、何回実施するかも確認します。

契約終了時には、運用ノウハウの引き継ぎも、業務シナリオに沿って確認します。

直接実績、類似実績、提案上の仮説を分けて見ると、提案を比べやすくなります。異常系テストや再委託先も、あわせて確認します。

法令・セキュリティ・クラウドの責任の分け方

クラウドの認証だけでなく、発注者やクラウド事業者、SI会社、決済事業者の責任範囲を確認します。

ISMAPは、政府のセキュリティ要求を満たすサービスを評価・登録する制度です(出典:国家サイバー統括室「政府情報システムのためのセキュリティ評価制度」、2026年確認)。政府情報システムの調達では、ISMAP登録サービスから調達する考え方が示されています。

自治体や関連団体に制度が直接適用されるかを確認します。適用されない場合でも、同等の統制が必要かどうかを仕様に記載します。

  • 情報管理:個人情報や口座情報、購入履歴、当せん情報、操作ログの保存環境と、暗号化鍵の管理者を定めます。
  • 再委託・改修:再委託先のアクセス範囲と、法令・規約変更時の改修費が保守に含まれるかを、契約で決めます。
  • 調達資料:見積書、要件定義書、SLA、セキュリティ仕様書、運用設計書を一体で確認します。

ポイント

見積もりは、同じ前提条件で比べられるよう、RFPに数量や品質、異常系を具体的に書きます。提案は総額だけでなく、体制と実績も比べます。

よくある質問(FAQ)

検討の段階で多く問われるのは、費用に加えて、対象制度や販売範囲です。決済や抽せん、払戻し、運用責任の範囲も、よく挙がります。

開発会社に相談する前に確かめたい代表的な疑問に、順に答えます。

公共くじ販売システムの開発費はいくらですか?

企画・要件整理は500万円から2,000万円程度、準パッケージ導入や小規模ネット販売は3,000万円から1億円程度です。

複数チャネル基盤は8,000万円から3億円程度、全国規模の基幹更改や複数データセンターでは1.5億円から5億円超が目安です。

取引量やチャネル数、外部接続によって変わるほか、端末やSLA、移行範囲でも変わります。そのため、要件をそろえたうえで、複数社から見積もります。

パッケージとフルスクラッチのどちらを選ぶべきですか?

商品や精算の標準的な業務を短期間で立ち上げたいなら、専用・準パッケージを比べます。

制度固有の販売条件や、チャネル同期、既存ホスト連携、監査要件が多い場合は、パッケージを核に追加開発する方式やフルスクラッチを検討します。

PoCで適合性と改修範囲を確かめ、初期費用や5年TCOを比べたうえで、保守性とベンダー交代のしやすさで判断します。

開発会社を選ぶときに何を確認すべきですか?

宝くじまたはスポーツくじの直接実績があるかを確認します。そのうえで、決済や金融機関との接続、売り場端末、精算・照合、公共調達の経験も見ます。

24時間運用や災害復旧の経験も確かめます。さらに、購入と決済の状態分離、抽せん結果の二者承認、販売停止の同期について質問します。

異常系テストや再委託先、契約終了時のデータ移行も確認します。直接実績、類似実績、提案上の仮説を分けて示す会社は、提案の透明性を比べやすいです。

開発期間はどのくらいかかりますか?

販売チャネルや外部接続が増えて対象範囲が広がるほど、開発期間も延びます。下の4つの区分は、その広がりに対応しています。

  • 企画・要件整理:1〜3か月が目安です。
  • 準パッケージ導入または小規模ネット販売:6〜12か月が目安です。
  • 複数チャネル基盤:12〜24か月が目安です。
  • 基幹更改・災害復旧を含む案件:18〜36か月が目安です。

発売日や抽せん日から逆算し、要件定義とPoCの期間を先に確保します。ただし、制度確認や外部接続を省くと、本番後の障害や追加費用につながります。性能試験やセキュリティ評価、業務リハーサル、並行稼働を省いた場合も同じです。

まとめ

公共くじ販売システムの開発では、画面の作成より先に、自治体や受託銀行、販売店、決済会社、払戻し主体の役割を整理します。そのうえで、購入、抽せん、払戻し、精算、報告を、監査可能なデータでつなぎます。

開発を成功させるための要点

まず、宝くじとスポーツくじの制度を分けて要件に書きます。次に、購入確定と決済確定を別々の状態として管理します。さらに、抽せん結果と精算データに、二者承認と監査ログを組み込みます。

RTO・RPOや販売停止、災害切替は、契約と運用手順に反映します。法改正への対応やデータ返却も、契約に盛り込みます。

最初に作る資料

発注先を比べる前に、対象範囲と非機能条件を整理し、相談や調達に使える資料にまとめます。

  • 要件整理シート:対象制度、関係者と、どこまでを誰が受け持つかを記載します。販売チャネルや取引量、外部接続、異常系も含めます。
  • 調達準備:セキュリティ、RTO・RPO、5年TCOを記載したうえで、RFIやRFPを実施します。

発注先は、制度適合性や運用継続性、説明責任を含めた総コストで選びます。

▼全体ガイドの記事
・公共くじ販売システム開発の完全ガイド

会社紹介

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

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

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

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

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

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