公共くじ販売システムの発注は、制度と責任分界、要件を固めてRFPにまとめ、契約と委託先を選ぶ順に進めます。この順で進めると、発注後も継続して運用できる体制につながります。
▼全体ガイドの記事
・公共くじ販売システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共くじ販売システムの発注で最初に整理する事項
公共くじ販売システムは、一般的なECサイトよりも、制度と業務が強く結び付いた業務基盤です。販売から払戻しや監査まで、一連の流れがつながっています。
発注前に制度と業務主体が決まらないまま機能一覧を作ると、受託銀行や決済会社との責任分界がずれ、見積もりと納期が大きく膨らみます。
宝くじとスポーツくじの発注案件の分け方
宝くじは当せん金付証票法に基づき、地方自治体が発売元となります。受託銀行などは発売計画に沿って事務を担い、その事務には券の準備や売りさばき、抽せんから当せん番号の発表、当せん金の支払いまでが含まれます（出典: 宝くじ公式サイト、2026年確認）。
スポーツくじは、スポーツ振興投票の実施等に関する法律に基づき、日本スポーツ振興センターの業務として実施されます。
宝くじとスポーツくじは制度が異なるため、発注書では制度ごとの対象範囲を書き分けておくと、確認漏れを防げます。次の2点を切り分けます。
- 発注対象：宝くじの販売・抽せん・払戻し、またはスポーツくじのネット販売・販促データ基盤のどちらか
- 制度ごとの確認：許認可、接続先、監査方法、保存期間を制度別に確かめる
販売から払戻しまでの責任分界の図
業務の順序と障害時の状態を分けて整理しておくと、どこまでを誰が受け持つかがはっきりします。販売の流れは、まず商品登録と発売期間を設定し、売場やWebで購入を受け付けたあと、決済を承認して購入記録を確定し、最後に抽せんデータを承認します。
- 業務の順に、工程を一つずつ並べます。
- 当せん判定から払戻し、精算、収益配分を経て監査報告まで続け、各工程の登録者と承認者を示します。
- 障害時に利用者へ説明する担当も、図に記載します。
購入画面に完了と表示されても、決済が確定しているとは限りません。そのため、購入番号と決済状態を分けて扱い、発券状態や払戻し状態も個別に管理しておく必要があります。
決済のタイムアウトや二重送信、通信切断、取消の遅れといった場合でも、状態を追える設計が必要です。この設計が曖昧なまま外注すると、テストの段階で仕様の解釈が食い違います。
公共くじ販売システムの発注形態の選び方
発注形態は、対象範囲と発注者の管理力をもとに、既存ベンダーとの関係や制度変更の頻度も見て選びます。一社に任せられるかどうかより、取引の正確性と継続運用をどの体制で担保するかが判断の要点になります。
単一ベンダーへ一括委託する形態
プライムベンダーに企画支援から要件定義、開発、移行、運用保守までを一括で任せる形です。窓口と障害時の指揮系統を一本化しやすいため、複数チャネルを短期間で統合する場合に向いています。
ただし、プライムベンダーがすべての専門領域を自社で内製するとは限りません。そのため、再委託の有無と費用を確かめておく必要があります。
- 契約条件：委託先の開示範囲、管理責任、障害連絡経路、データ持ち出し可否
- 総額：見積書が安くても、再委託費やライセンス費が別なら5年の合計で比べる
- 費用の対象範囲：決済、端末、クラウド、セキュリティ診断、運用監視が再委託される場合、各費用が見積もりに含まれるか確認
プライムSIと専門会社を組み合わせる形態
この形態は、プライムSIが全体を統括し、専門会社が決済や本人認証などの専門領域を受け持つ形です。役割と統合管理を契約で明確にするため、次のとおり整理します。
- 役割分担：プライムSIが公共調達や大規模な基幹連携を統括し、専門会社が決済、本人認証、端末、クラウド、監査、脆弱性診断を担当
- 適する場面：業務知識と金融・決済の技術力を分けて調達でき、直接実績のある会社が一社で見つからない場合にも現実的
- 統合責任：会社間でインターフェースの責任が分かれるため、取りまとめ役を契約で定める
- 会社ごとの管理：API仕様、障害の一次切り分け、リリース承認、テストデータ管理、脆弱性対応期限を決めておく
発注者側に業務と技術を横断するPMOを置くと、この形態の効果を得やすくなります。
企画・開発・運用を段階的に委託する形態
段階委託は、次の順に進めます。
- RFIや現状調査を外部へ委託する
- 要件定義とRFPを固める
- 開発会社を選ぶ
- 保守運用を委託する
企画・要件定義支援、開発、保守運用を分けて委託すると、初期の不確実性を抑えながら提案を比べられます。さらに、要件定義を担う会社と開発会社が異なる場合は、成果物の著作権や設計書の再利用、質問への回答責任を整理しておく必要があります。RFP支援会社が開発まで受注するとは限らないからです。
発注者は、中立的な評価基準と引き継ぎ手順を契約に入れておくと、調達の透明性を保ちやすくなります。
RFPと要件整理で公共くじ販売システムの範囲を決める方法
RFPは、候補会社に同じ条件で伝えるための資料です。そこには業務成果や前提条件、制約、評価方法を書き、販売停止や決済失敗などの異常時も要求に含めます。また、抽せん結果の差異や災害時の切替、払戻しの遅れも示しておくと、提案を実務に近い形で比べられます。
業務・データ・接続先の洗い出し
業務・接続・負荷・既存資産は、次の項目に分けてRFPに記載します。
- 業務機能：商品マスタ、発売期間、券種、価格、販売地域、売場配分、会員、購入履歴
- 業務処理：決済、抽せん結果、当せん判定、払戻し、精算、監査ログ
- 接続先・方式：売場端末、Web、スマートフォン、受託銀行、金融機関、決済事業者、会計、本人確認、通知サービス
- 負荷条件：通常・発売日・抽せん日の1分あたりの購入要求数、同時接続数、日次取引件数、商品登録数、保存年数
- 既存資産：端末・ホストの機種、OS、通信方式、保守期限、データ形式、接続テスト可否
既存資産まで示しておくと、各社の前提の差を小さくできます。
非機能要件と異常系のRFPへの落とし込み
非機能要件には、稼働時間や性能、可用性を含めます。さらに、災害復旧や監視、ログも定めます。
そのうえで、権限や暗号化、脆弱性診断を定めます。バックアップやデータ返却、保守窓口も含めます。
24時間365日運用でも、商品登録から結果公開までを、購入確定や決済、精算、抽せんと同じSLAにする必要はありません。そのため、業務の重要度に応じて、復旧目標時間（RTO）と復旧時点目標（RPO）を分けて定めます。
異常系では、次の業務シナリオをRFPに含めます。
- 決済後の画面切断、購入ボタンの二重送信
- 売上確定後の取消、抽せん承認者の不在
- 払戻し口座への振込失敗、災害時のネットワーク切替
各シナリオでは、データの正しい状態と担当者の操作を受入基準にします。そこに、利用者への表示や再処理の可否、監査ログも加えて確かめます。
価格以外の観点を含むRFPの評価基準
価格以外の評価軸と参加条件をそろえておくと、提案の実現性を比べられます。
- 提案内容：制度理解、同種業務実績、業務設計、移行・テスト計画
- 運用体制：セキュリティ、運用、再委託管理、将来のベンダー交代
- 参加条件：全省庁統一資格、ISO 27001などの認証、専門資格、過去の導入・運用年数を条件とする案件もあります
- 調達例：JSC販促ツール案件は2025年11月公示、利用・保守期間は2026年4月〜2030年3月
- 同案件の条件：導入・構築または運用保守実績、専門資格者数、ISO 27001認証など（出典：JETRO政府公共調達データベース、2025年）
販促ツールは中核の販売システムではありませんが、複数年の運用と実績要件をRFPに含める際の参考になります。
契約形態と公共くじ販売システムの費用相場
本体の標準価格は公開されていません。ここに示すのは提案依頼前の概算レンジで、取扱高や販売チャネルのほか、外部接続や既存資産の再利用によって変わります。
ピーク性能や監査、移行に加え、災害対策や保守時間も金額を左右します。また、公開額には税別と税込が混在するため、比較の条件をそろえます。
段階別の費用レンジと予算の立て方
金額は公開された標準価格ではなく、要件をもとにした概算・推定のレンジです。段階ごとの目安と前提を比べながら、予算の枠を置きます。
- 企画・準備：現状調査、要件定義、RFP支援は500万〜2,000万円程度
- 小規模導入：準パッケージや小規模ネット販売は3,000万〜1億円程度。商品、会員、注文、決済、結果照会を既存精算へ連携する想定
- 複数チャネル：売場端末・Web連携や決済・精算の新規構築は8,000万〜3億円程度
- 大規模更改：全国規模の基幹更改で、複数拠点の災害対策、24時間運用、厳格な並行稼働を含むフルスクラッチは1億5,000万〜5億円超となる可能性
参考になる調達例として、2025年公開のJSCスポーツくじ販促ツールがあります。利用・運用保守期間は2026年4月〜2030年3月です（出典：JETRO政府公共調達データベース、2025年）。周辺のデータ・販促基盤の例で、販売や払戻しの中核開発には当たりません。複数年の契約が結ばれる点は見ておく価値がありますが、本体費用の根拠には使いません。
請負・準委任・保守契約の使い分け
作業の確定度に合わせて契約を分け、範囲や費用の条件を明記します。
- 請負：完成条件が固まった機能開発に向く。成果物、納期、受入基準、瑕疵対応、変更管理を定める
- 準委任：現状調査、RFP支援、PMO、画面改善、運用設計に合いやすい
- 契約の分け方：一律の契約にすると、仕様変更時に請負範囲の解釈がぶつかりやすい
- 保守契約：監視時間、受付、一次切り分け、重大障害の連絡期限、復旧目標を記載
- 保守の対象：脆弱性・法改正対応、商品追加、訓練、データ返却を定める
開発費の15〜25％程度を、年間保守費の概算とする場合もあります。ただし、24時間監視やクラウド、端末、ライセンスが含まれるか、セキュリティ診断や法改正改修が含まれるかで、金額は変わります。
初期費用と5年TCOの比較
初期費用だけでなく、5年間に発生する費用を同じ範囲で積み上げて比べます。
- 基盤・利用費：クラウド、データセンター、端末、決済手数料、ライセンス
- 運用費：監視、ヘルプデスク、脆弱性診断、バックアップ、災害訓練
- 変更・終了費：法改正、商品追加、移行、教育、終了時返却。「別途実費」「想定外の変更」「従量課金」は上限額と単価を確認
- 提案例A：初期7,000万円、保守年2,000万円、ライセンス等年1,000万円なら5年で2億2,000万円
- 提案例B：初期1億円、既存基盤を使い運用年1,000万円なら5年で1億5,000万円
単年度の安さで判断するのではなく、同じ期間と同じ対象範囲で比べます。
委託先の選定と見積比較で確認すべきポイント
委託先は知名度よりも、任せる工程に合う強みで選びます。売場端末やくじ・公営競技の経験、決済・金融接続の経験、公共調達や基幹更改の経験を評価します。
精算・照合や24時間運用の経験も分けて確かめると、提案の適合性を判断しやすくなります。
「公共系」の実績と担当範囲の確認
候補会社には、公共くじ・スポーツくじ・決済・金融・発券端末のうち、どこを担当したかを尋ねます。精算や抽せん、当せん判定、本人認証の実績も確かめます。
「公共システムの実績」と聞いても、販売業務や金銭データを扱った経験があるかは確かめにくいものです。非公開の案件についても、業務内容や規模、運用年数を匿名で説明できるかを聞きます。障害対応や移行方法の説明も求めます。
候補企業が公開している関連分野の情報は、担当実績を確かめる手掛かりになります。
- トータリゼータエンジニアリング：スポーツくじ端末やソフトの開発・保守
- SCSK：くじ・公営競技や決済を含むフロント事例
- NTTデータ：大規模な公共・金融開発とアウトソーシング
- NEC、TIS、BIPROGY：公共・金融基盤、刷新、決済・照合の観点
これらは候補の例にすぎず、公共くじの直接の担当範囲は、提案依頼の際に個別に確認します。
見積書の項目と前提条件の粒度の統一
見積項目と前提条件をそろえ、金額差の理由を確かめられる形にします。
- 開発・品質項目：企画・要件定義、基本・詳細設計、開発、外部接続、端末、テスト、性能検証、セキュリティ
- 運用・利用費：移行、教育、リリース、保守、クラウド、ライセンスを項目化
- 前提条件：担当人数、期間、既存仕様、対象外作業、変更単価を併記
- 比較条件：決済連携の費用、端末数、テスト環境、移行件数、負荷試験回数
- 運用品質：監査ログの保存年数、訓練回数、SLAの時間帯
金額差が大きい場合は、単価よりも先に対象範囲と品質基準を確認します。
セキュリティとベンダー交代の条件の確認
セキュリティと調達条件、終了時の引き継ぎを、それぞれ分けて確認します。
カード情報の保管場所と決済事業者との責任分界を確かめ、ログ監視や脆弱性診断の扱いも見ます。カード情報を保持しない場合も、委託先と管理画面は評価の対象です。
- カード決済：ネット販売でカードの決済を扱う場合、本人認証と責任分界を確認
- 認証の例：宝くじ公式サイトはなりすまし対策に3Dセキュア2.0を利用（出典：宝くじ公式サイト「本人認証サービス」、2026年確認）
- 基準：政府機関などのクラウド調達ではISMAP、カード情報を扱う場合はPCI DSS v4.0.1を確認。法的必須、調達条件、設計上の推奨を区別
- 運用設定：ISMAP登録があっても、設定やID、鍵、ログ、バックアップ、委託先の運用まで定めて初めて全体の安全が保たれる
- 契約終了：データ形式、設計書・ソース、第三者移行支援、再委託先との契約の終わり方、アカウント削除、ログ保管、移行リハーサルを明記
長期の運用では、開始時の価格だけでなく、将来の交代可能性も含めて委託先を選びます。
公共くじ販売システムの発注でよくある質問
候補会社との打ち合わせ前に確認したい質問を、ここにまとめます。費用に加えて、制度適合性や責任分界、運用継続性も確かめる材料になります。
公共くじ販売システムの開発費はいくらですか？
企画・RFP支援は500万〜2,000万円程度、準パッケージや小規模ネット販売は3,000万〜1億円程度が目安です。
複数チャネルの販売基盤は8,000万〜3億円程度、全国規模の基幹更改や災害対策込みでは1億5,000万〜5億円超の場合もあります。
RFPで取扱量や接続先、SLA、移行範囲を示し、個別の見積もりを取得します。公開されている価格ではないためです。
パッケージとフルスクラッチはどちらが良いですか？
商品管理や会員、通知、分析はパッケージやクラウドを活用します。一方で、抽せんや払戻し、精算、監査は専用に設計する進め方が現実的です。
フルスクラッチは業務適合性を高めやすいものの、品質保証や保守要員、移行、ベンダー交代にかかる費用が増えます。5年TCOと制度変更を比べて決めます。
公共くじの実績がない会社にも発注できますか？
発注できます。ただし、公共くじの経験がない場合は、決済や金融接続、精算などの代替実績を確認します。本人認証や監査、24時間運用の経験も含めて見ます。
直接の実績は推測で補わず、担当範囲や規模、運用年数に加え、障害対応や再委託先も確かめます。
制度解釈が必要な領域は、経験のあるコンサルタントや専門会社と組める体制を評価します。
RFPには何を必ず書けばよいですか？
基本として、制度や発注者と運営主体、販売チャネル、取引量を記載します。加えて、外部接続やデータ移行、性能を示し、RTO・RPO、セキュリティも含めます。
運用に関しては、監査ログやテスト、教育、運用の進め方が必要です。また、再委託やデータ所有権、終了時の移行支援も欠かせません。
異常時では、決済のタイムアウトや二重購入、販売停止の受入基準を含めます。抽せんの差異や払戻しの失敗、災害時の切替についても、受入基準に含めます。
まとめ
発注では宝くじとスポーツくじを区別し、発売元と受託銀行、販売店、決済事業者、開発会社の責任を整理します。
単一ベンダーへの一括委託、プライムSIと専門会社の連携、段階委託のなかから、自社の管理体制に合う形を選びます。そのうえで、要件と契約を固めて提案を比べます。
発注前に確認する5つの視点
ここまでの要件整理や障害対応、契約条件、費用比較を、発注前に次の5点で確かめます。
- 制度と業務範囲：対象制度と運営主体の特定
- 取引量とピーク：通常時と発売日・抽せん日それぞれの条件
- 異常系と監査：失敗時の状態と受入基準の決定
- 契約とSLA：責任、対応時間、再委託条件の整合
- 5年TCO：初期費用と運用費を同じ範囲にそろえた比較
企画・RFP支援は500万〜2,000万円、複数チャネルの販売基盤は8,000万〜3億円程度が目安です。
初期開発から保守までを、外部接続や移行、セキュリティ、クラウドを含めて同じ条件で分解し、数字だけで判断しないようにします。
最初の一歩は現状調査とRFI
開発会社へ金額だけを聞く前に、販売から払戻しまでの業務と既存システム、関係者、制約を洗い出します。そのうえでRFIを使い、対応できる会社と方式を把握します。
RFPには、各社が同じ前提で提案できる情報と、異常時の受入基準を入れます。制度適合性と運用継続性を含めて比べることが、安心して販売を続けられる発注につながります。
▼全体ガイドの記事
・公共くじ販売システム開発の完全ガイド
▼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を創業。