チケット販売システムの発注は、業務の流れを整理し、要件と例外を明文化したうえで、発注形態と契約を選ぶ順に進めます。販売から精算までを先に整理しておくと、予算超過や運用トラブルを防ぎやすくなります。
発注形態、RFPと要件、費用、委託先の4点を説明します。
▼全体ガイドの記事
・チケット販売システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注・外注の出発点は業務フローの整理
最初に作るのは、販売開始から公演後の精算までをつないだ業務フローです。
チケット販売システムは、ECサイトに近い画面に加えて、在庫の同時引当、入場時の認証、売上の締めも扱います。キャンセルや公演中止への対応も含む業務基盤であるため、画面だけを中心に考えると、業務側の要件が抜けやすくなります。
興行運営の基盤としての範囲定義
発注前に扱う範囲を決めておかないと、委託先ごとに見積の前提がずれてしまいます。
- 販売・在庫：先着・抽選、座席指定、在庫引当。
- 購入後の業務：決済・発券・QR認証、会員管理、売上精算まで。
- 例外対応：払戻し・リセール・分析まで、範囲に含めます。
対象となるのは、興行入場券や施設入場券の販売管理です。
特に座席指定では、空席の表示だけでなく、購入手続き中の仮押さえとタイムアウトも設計します。また、決済失敗時の在庫返却や複数チャネルの二重販売防止も、同じ状態遷移として扱います。
Gettii公式は、インターネット・窓口・電話・プレイガイドのチケットを一元管理できることを案内しています。
Gettiiは、座席指定・抽選・リセール・紙と電子の入場にも対応しています（出典：Gettii公式機能案内、2026年8月確認）。
発注者・委託先・販売会社の役割分担
開発会社に任せれば全部解決すると考えると、要件に抜けが出たり、どこまでを誰が受け持つかが曖昧になったりします。そのため、役割は発注前に分けておく必要があります。
- 発注者：販売方針・料金・券種・業務ルール・データ保有方針を決めます。
- 委託先：要件をシステムに落とし込み、設計・開発・テスト・運用支援を担当します。
- 販売会社：販売チャネルや発券網を提供します。個別システムを受託開発するとは限りません。
- 参加者：販売・受付・経理・問い合わせ・情報システム・個人情報管理の各担当者にも参加を求めます。
- 現場確認：通信断時の対応、部分払戻し、手数料控除の締め方を実務の担当者に聞き、画面仕様だけでは見えない要件を把握します。
発注形態の選び方：SaaS・ASP、パッケージ、個別開発
発注形態は、初期費用の安さだけでなく、年間公演数や最大販売枚数を見て選びます。あわせて、販売開始時のアクセス集中、座席の複雑さ、会員データの活用も確認します。
紙と電子の併用、リセールや払戻しの要否も見ます。そのうえで、標準化できる業務はサービスに寄せます。一方で、競争力や独自性に直結する部分だけを追加開発すると、費用とリスクのバランスを取りやすくなります。
SaaS・ASPが向く小規模イベントと早期導入
SaaS・ASPは、サーバーや基本機能を自社で持たず、月額料金や販売手数料で利用する形態です。
- イベント規模：単発イベントや自由席中心の公演に向きます。
- 導入時期：短期間で販売を始めたいときに候補になります。
- 標準機能：管理画面・決済・購入者メール・QR受付が標準でそろえば、開発期間と運用負担を抑えられます。
複数プレイガイドの在庫統合、複雑な会員先行、独自精算は、標準機能では足りない場合があります。
ファンクラブ連携や特別な本人確認が必要な場合は、契約前にAPIとデータ返却形式を確認します。
障害窓口、販売終了後の閲覧期間、解約時の移行条件まで含めて、契約前の確認項目に入れます。
パッケージ＋追加開発の業務適合と拡張性
座席管理・抽選・会員先行・精算・入場認証が必要で、独自画面や連携も加えたい場合に適します。また、興行運営の実績がある基盤を使えば、在庫ロックや払戻しをゼロから作る範囲を減らせます。
標準仕様に業務を合わせる必要があるため、カスタマイズの範囲は先に確認しておきます。特に、標準機能を変更しすぎると、更新時のテストが増え、個別開発に近い費用になることがあります。そのうえで、機能一覧では、標準・設定変更・追加開発・対象外を分けて示します。
スクラッチ開発の検討条件：独自要件と大規模負荷
スクラッチ開発は、独自要件と販売規模に応じて検討します。
- 適する要件：独自の会員基盤・販売ルール・複数会場の在庫を、特殊な精算や厳しいピーク性能と一体で設計します。
- 大規模公演：全国規模の人気公演で販売開始直後にアクセスが集中し、抽選・本人確認・公式リセールを提供する場合は、合理性が高まります。
- 過剰になる場合：イベント数が少なく、自由席とQR受付で足りる場合は、過剰になることもあります。
- 外部サービス：決済・メール・SMS・本人認証・CDNやWAFには、専門サービスを利用します。
- カード情報：自社データベースに保存しない構成にすると、開発範囲とセキュリティ負担を抑えられます。
RFPと要件整理：販売開始から公演後まで
RFPは、委託先に「何を、いつまでに、どの条件で提案してほしいか」を伝える資料です。
まず、年間公演数、最大販売枚数、ピーク時の同時アクセスを記載します。さらに、販売チャネルや座席の有無、紙対応、会員DB・会計・問い合わせ体制も書いておくと、見積条件をそろえやすくなります。
例外ケースまで含めた業務フロー
まず「公演登録→販売準備→販売→決済→発券→入場→精算→分析」の基本線を作り、そこに各段階の例外を足していきます。
- 公演登録と販売準備では、販売期間や購入枚数の制限を設定します。
- 販売と決済では、仮押さえ、キャンセル、二重決済、未入金を扱います。
- 発券と入場では、通信断や重複入場に備えます。
- 精算と分析の段階では、全額・部分払戻し、延期、座席変更、リセールを確認します。
例外を先に決めておけば、委託先が通常購入だけを対象と解釈する余地を減らせます。
公演中止では、販売を止めたうえで、購入者への通知と返金額の計算、決済会社との照合が続きます。さらに、チケットの無効化と問い合わせ履歴の保存も必要になります。そのため、要件定義の段階で責任者と承認手順を決めておきます。
利用者とデータの流れで書く機能要件
機能要件は、利用者ごとの操作とデータの流れが分かる形で書きます。
- 座席管理：管理者が会場図と席種・ブロック・販売対象を設定し、購入者が選ぶと在庫を仮押さえします。
- 決済失敗：決済に失敗した場合は、一定時間後に在庫を戻すことを明記します。
- 利用者ごとの操作：購入者・販売受付担当・経理・システム管理者について、操作とデータ更新を示し、見積の前提を明確にします。
- 販売・発券機能：会員先行・抽選・招待券・割引・複数券種・コンビニ発券・電子チケット・窓口や電話の予約・プレイガイド連携が、標準機能か追加開発かを確認します。
- 外部連携：会員DBや会計とのつなぎ方について、方向・同期頻度・再送方法・個人情報の項目・データ責任者をRFPに含めます。
非機能要件と発注者側の準備
販売開始の日に安定して動くよう、非機能要件では次の項目を決めて記載します。
- 性能：想定同時接続数、ピーク注文数、画面応答時間。
- 稼働と障害対応：可用性、監視時間、障害時の停止と再開、バックアップ。
- その他の記載項目：RTO・RPO、脆弱性診断、ログ保存期間、権限分離、MFA。
発注者側では、次の準備を整えておきます。
- 資料：会場図、既存会員データの形式、過去の売上、決済会社の情報。
- 体制：担当者の稼働時間、受入テストの参加者、承認者。
要件が確定してから大きく追加したり、移行作業を丸ごと任せたりすると、納期の遅れや追加費用につながります。
契約形態の選び方：要件の確定度と変更管理
契約では、開発費だけでなく、要件定義・設計・テスト・データ移行・導入支援ごとに分けて考えます。さらに、保守・障害対応・追加改修についても、別に扱いを決めます。
要件が確定している範囲は請負、調査や整理が必要な範囲は準委任とし、工程ごとに契約を分ける方法もあります。
請負契約の成果物・検収・変更手続き
請負契約は、成果物を完成させ、発注者が検収する形に適しています。
- 納品物：画面・API・バッチ・管理マニュアル・テスト結果・移行データ・運用手順書を明記します。
- 検収条件：「問題なく動く」だけでは足りず、座席の同時購入・抽選・決済失敗・通信断入場・公演中止・部分払戻しを受入シナリオにします。
- 変更管理：仕様変更の申請者・影響調査・追加費用・納期変更・承認者を決め、記録に残します。
- 段階導入：販売開始日が決まっていれば、必須機能を先にリリースし、公式リセールや分析機能を第二段階へ回すかどうかも判断します。
準委任契約の使いどころ：要件定義と継続改善
準委任契約は、専門家の作業や支援に対して稼働時間や役割を定める形です。既存システム調査・RFP作成支援・業務フロー整理・要件定義・技術検証・運用改善に適します。
作業時間の確保とは別に、販売開始に必要な成果が得られるかを見ておく必要があります。そのため、月次の成果物・意思決定事項・課題一覧・次月の作業範囲・品質指標を見て、請負へ移る時期を定めます。
開発会社が要件整理から支援する場合でも、業務ルールを最終的に決める決裁者は発注者側に置きます。
保守契約の障害対応と公演日の体制
通常営業時間の問い合わせ対応と、公演日の緊急対応は分けて考えます。アクセス集中・決済障害・QR認証の不具合・誤った座席設定・公演中止の場面ごとに、一次判断者、連絡手段、状況共有までの時間を決めます。
OS・ミドルウェア更新・脆弱性対応・監視・バックアップ・軽微な設定変更・機能追加・データ抽出・問い合わせについて、保守費に含まれる範囲を確かめます。
販売データの返却・ログ保存・解約時の移行支援も、契約に含めておくと、将来の乗り換えに備えられます。
チケット販売システムの費用相場とコストの内訳
費用は、初期開発費だけでなく、利用料や手数料、紙の発券・配送費、入場端末費用まで含めて見ます。また、個別開発は要件定義から保守・追加改修までを含め、3年程度の総保有コストで比べます。
SaaS・ASPの公開手数料と追加費用
小規模・単発イベントの予算目安は、公開料金などから整理した参考値です。ただし、座席管理・会員連携・導入支援・運用代行が加わる場合は、個別見積もりになります。
- 基本料金：初期費用0〜50万円、月額0〜10万円程度に、販売手数料が加わる例があります。
- PassMarket：ベーシックは税込3.564%、プロフェッショナルは5.5%です。
- EventRegist：有料チケット販売額の8%に、振込手数料が加わります。
- teket：自由席などは8%、指定席は10%です。基本使用料と発券手数料は無料です。
料金例の出典は、各社の公式案内です（PassMarket公式料金案内、EventRegist公式料金案内、teket公式利用料金表、2026年8月確認）。
たとえば、年間売上が1,000万円なら、手数料3.564%で約35.6万円、7%で70万円になります。同じ売上で手数料が8%なら80万円、10%なら100万円です。
決済・振込・返金・紙発券にかかる費用も、条件をそろえて比べます。
個別開発の要件別推定レンジ
個別開発は公開された一律の相場が少ないため、リサーチノートの業務システム相場をもとにした推定を示します。
見積前に使う推定レンジで、チケット販売固有の要件を組み合わせたものです。
- MVP（Minimum Viable Product）：最小限の販売機能で、500万〜1,500万円程度、3〜6か月程度が目安です。
- 中規模：座席指定・抽選・会員先行・複数券種・払戻し・会計連携・管理画面を含みます。費用は1,500万〜5,000万円程度、期間は6〜12か月程度です。
- 大規模：高負荷や多様な連携を含む要件が対象です。
MVPでは、イベント登録・販売ページ・決済PSP連携・QR入場・基本管理に絞ります。
大規模では、ピーク負荷、公式リセール、本人確認を含みます。ほかにも、複数プレイガイドの在庫統合やファンクラブ連携が加わります。さらに、分析基盤と24時間監視も必要になります。
大規模の場合、費用は5,000万円〜2億円以上、期間は12〜24か月程度になる可能性があります。
金額と期間は要件別の推定レンジです（出典：NotebookLMリサーチノート「チケット販売システム」、2026年8月確認）。このレンジは、発注先や品質を保証する金額ではありません。
費用の内訳は、要件定義10〜15%、基本設計15〜20%、開発30〜40%を仮置きします。結合・総合テストは15〜20%、移行・導入は5〜10%とし、負荷試験や受入テストは削らない計画です。
稼働後の保守・改修は、初期開発費の年10〜20%程度を仮置きし、契約時に対象範囲を確認します。
3年TCOで見る費用の比較
初年度の費用だけでなく、年間売上・販売枚数・公演数・会員数・サポート時間・追加開発回数の前提をそろえて、3年間の固定費と変動費を計算します。そのうえで、利用料、売上手数料、決済と返金を合算します。さらに、端末費用、発券費用、保守費用、移行費用も含めます。
販売量が増えるほど、売上連動型と固定費型の差は大きくなります。たとえば、低い初期費用のSaaSでも、手数料によって総額がパッケージを上回る場合があります。
開発費が高くても、会員データの活用や業務削減の効果があるなら、価格以外の効果も含めて判断します。そのため、比較表には、削減作業時間や販売機会の増加も記載します。
委託先選定と見積比較で確認すべきポイント
委託先は、知名度よりも同種業務の経験と依頼範囲を確認します。標準サービス導入・API連携・個別開発・販売代行・問い合わせ対応のどこまでを担うのかを分けて評価します。
実績の確認：運用条件まで
実績は、導入社数だけでなく、似た条件で安定して運用できているかを確認します。可能であれば、同規模の導入先に、販売開始日や公演当日の支援体制を尋ねます。
- 販売規模：イベント種別・最大販売枚数・ピークアクセスを確かめます。
- 運用条件：座席・抽選・紙と電子・入場端末数・払戻し件数について、同様の経験があるかどうかを聞きます。
- 支援体制：問い合わせ窓口と障害時の復旧方法を聞きます。
個人情報やカード決済を扱うため、権限管理・MFA・操作ログ・脆弱性対応を確認します。さらに、バックアップや再委託の管理、データ削除の仕組みも見ます。
経済産業省は2025年3月のガイドライン6.0で、EC加盟店に脆弱性対策を求めています。
経済産業省は、EMV 3-Dセキュアと不正ログイン対策についても求めています（出典：経済産業省「クレジットカード・セキュリティガイドライン」改訂発表、2025年）。
見積書の工程・前提・対象外の比べ方
見積書では、要件定義・開発・保守ごとに費用を並べます。工程は次の順で書かれているかを確かめます。
- 設計：基本設計と詳細設計が分かれているか
- テスト：テストと負荷試験が別の工程として書かれているか
- 移行：安い見積では、この工程が抜けていることがあります。
- 研修：対象と範囲の書き方
- リリース支援：見積に含まれているかどうか
工程ごとの人日や期間、担当者の役割に加えて、外部サービス費・クラウド費・ライセンス費・交通費・税の扱いもそろえます。
工程と前提をそろえるのは、安い見積にテストや移行が含まれていないことがあるためです。
比較表には、標準機能・設定対応・追加開発・別途見積・対象外の区分を設けます。
- 販売・決済：在庫ロック・決済照合・二重決済防止の扱い。
- 公演運営：抽選通知・部分払戻し・オフライン入場を確認します。
- 管理・連携：CSV・API・ログ・監視の対象範囲。
回答が曖昧な項目は、発注後に追加費用や納期変更が起きる候補として残しておきます。
法令・不正転売・払戻しの要件化
法令と不正対策は、法務・主催者・委託先で分けて整理します。
- 法令確認：該当する場合は、券面や販売時の表示、購入制限、本人確認、公式リセールを確認します。
- 不正対策：多要素認証・購入枚数制限・BOT対策・決済時の本人認証・購入履歴監視・重複入場確認を組み合わせます。
- リセール管理：元チケットの無効化に加えて、名義変更・再発行・返金・手数料の状態遷移を設計します。
公式リセールを後から追加する場合は、状態遷移を最初からデータ設計に含めておくと、後付けの改修を減らせます。
文化庁は、同法に基づく適正な流通の確保に関する措置を、2026年6月にも案内しています（出典：文化庁「チケット不正転売禁止法」、2026年6月更新）。
よくある質問（FAQ）
チケット販売システムの外注では、費用だけでなく、標準機能に任せる範囲と運用責任者を決めることが大切です。発注前によく寄せられる質問に答えます。
チケット販売システムはSaaSと個別開発のどちらがよいですか？
単発・小規模で、自由席とQR受付が中心なら、初期費用を抑えて早く始められるSaaSが向いています。
複雑な座席・会員先行・基幹連携・大規模ピークがある場合は、追加開発や個別開発を検討します。
独自精算やリセールを重視する場合も、検討の対象になります。
チケット販売システムの開発費用はどれくらいですか？
SaaSは初期費用0〜50万円、月額0〜10万円程度に販売手数料約3.5〜10%が加わる例があります。
個別開発はMVPで500万〜1,500万円、中規模で1,500万〜5,000万円です。
大規模では5,000万円〜2億円以上という推定です。いずれも要件整理前の予算目安です。
RFPには最低限何を書けばよいですか？
RFPには、イベント種別、公演数、販売枚数を記載します。そのほかの項目は、次の5つの分類で整理します。
- 販売の条件：ピークアクセス、座席、抽選
- 他システムとの接続：会員連携、外部連携
- 購入から入場まで：決済、紙対応、入場
- 返金の扱い：払戻し、リセール
- 期間と費用：納期、予算の考え方
決済失敗・通信断・公演中止・部分払戻し・移行・障害時の連絡体制も含めておくと、見積もりを比べやすくなります。
発注時にセキュリティや不正転売対策も相談できますか？
相談はできますが、法務判断と実装の責任範囲は分けて考えます。整理するのは、個人情報の権限管理・暗号化・ログ・保存期間と、PSPやPCI DSSの適用範囲です。
EMV 3-Dセキュア・MFA・購入制限・本人確認・公式リセール・入場時の無効化も確認します。そのうえで、標準対応と追加対応は見積書で分けます。
まとめ
発注前に、公演登録から在庫引当・決済・発券・入場・精算・払戻し・リセール・分析まで整理します。そのうえで、SaaS・ASP、パッケージ＋追加開発、スクラッチ開発から、自社に合う形を選びます。
発注前に決めるべきこと
年間公演数・販売枚数・ピークアクセスは、発注前に数字で定めます。あわせて、次の項目も決めておきます。
- 販売の仕組み：座席や抽選、販売チャネル
- 入場の形：紙と電子の比率
- データの連携：会員DB、会計との連携
- 再販の扱い：払戻しとリセール方針
RFPには、二重販売防止・決済失敗・通信断入場・公演中止・部分払戻し・データ移行・障害対応も含めます。
委託先と見積を比較する基準
委託先の実績と見積は、同じ基準にそろえて比べます。
- 実績：ピーク負荷・座席管理・抽選・入場・精算・払戻し・リセール・セキュリティ・運用支援を比べます。
- 見積条件：工程・成果物・前提・対象外・外部サービス費・保守・変更手続き・データ返却の扱いをそろえます。
初期費用だけでなく、3年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を創業。