課金システムのRFP（提案依頼書）は、料金プランの定義、非機能・会計要件の整理、移行条件の契約化の順に進めると、手戻りと隠れコストを抑えやすくなります。
発注側の担当者向けに、RFPと要件定義書の作り方を解説します。なお、全体像は課金システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・課金システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
料金プランと課金パターンの要件化
料金プランと課金パターンは、RFPの最初に具体化しておきます。曖昧なままでは見積もりが過大にも過小にもぶれ、開発後に想定した料金体系へ対応できない恐れがあります。
課金方式と料金プランの定義
RFPの出発点は、自社の料金設計を漏れなく言葉にすることです。将来追加したいプランも書いておくと、拡張に耐える設計を開発会社に提案してもらえます。特に、料金プランの定義が曖昧なまま開発に進むことは、課金システム開発でよく見られる失敗の入り口です。
- 課金方式：月額固定の継続課金、従量課金、両者のハイブリッド
- 料金の設定：初期費用・登録料、無料期間、複数プラン、上位プラン、年払い割引
- 変更時の計算：契約開始・解約・変更の日割基準、差額、返金
月の途中での日割りは、暦日で計算するか営業日で計算するかを決めておきます。あわせて、アップグレード時の差額と解約時の返金の有無も指定します。そのうえで、計算例を添えておくと、想定と異なる挙動を防ぎやすくなります。
決済手段と決済代行の要件
料金プランと並んで、対応する決済手段も定義しておきます。顧客層に必要な決済手段を選び、必須と任意の優先順位をRFPに示します。
SBペイメントの調査では、希望する支払手段がないと60%超が他店で購入するとされています。そのため、選択肢の不足は機会損失に直結します。
- 決済手段：クレジットカード、口座振替、キャリア決済、コンビニ払い、QRコード決済
- 決済代行：代行会社の指定、または複数社をつなぐマルチホーミング
手数料は全体の約4割が3.0〜3.4%に集中し、サブスクでは3.3〜3.4%が突出して高い傾向があります。これは一次データに見られる傾向なので、RFPの検討材料にします。
トランザクション費用は1回数円〜数十円です。振込手数料も含めてコスト構造を把握したうえで、決済代行の組み合わせを検討します。
非機能要件（非保持化・SLA・チャージバック）
課金システムでは、機能要件と同じように非機能要件もRFPで固めておく必要があります。特に、セキュリティ・可用性・チャージバックは、後から加えると改修コストがかかります。
要件が曖昧なまま進めると、リリース後にセキュリティ基準を満たせなかったり、障害で課金が全面停止したりする問題が起こり得ます。
非保持化アーキテクチャとPCI DSS要件
セキュリティ要件の中核は、カード情報の非保持化です。具体的には、カード番号を自社サーバーに保存せず、決済代行のトークンで課金を管理すると、PCI DSSへの準拠範囲を最小限に抑えられます。
- 構成：非通過型・トークン決済を前提とする
- 責任範囲：PCI DSSの自社負担分と決済代行への委託範囲を分ける
- 追加要件：EMV 3-Dセキュア2.xへの対応を必須とする
PCI DSS対応の費用は、コンサルで数十万〜数百万円、QSA審査で年間数百万円規模です。さらに、大企業の改修は年間数千万円に及び、非保持化で対象範囲を縮小すると、開発・セキュリティコストを50〜70%削減できるとされています。
EMV 3-Dセキュア2.xは、2025年3月末にECでの導入が原則義務化された要件です。そのため、非対応の提案は検討対象にならず、RFPの初期段階から記載します。
SLA（稼働率）とチャージバック負担条項
可用性はSLA（サービス品質保証）で定めておきます。課金が止まると、継続課金の機会損失や解約のリスクにつながります。
- 稼働・復旧目標：業界水準は稼働率99.99%以上、月間ダウンタイム4.3分以下。求める稼働率と復旧目標時間をRFPに記す
- 障害時の備え：決済代行の障害に備え、マルチホーミングなどのフォールバックを設計する
- チャージバック対応：異議申立による代金取消の証拠提出フロー、責任者、費用負担を契約要件にする
- 率超過時の扱い：例えば0.9%超でアクワイアラから違約金や決済停止を受けるリスクがあり、損失負担者も定める
収益認識・会計連携の要件定義
見落とされやすいのが、収益認識と会計連携の要件です。継続課金の事業では、課金システムと会計処理の連動を最初から要件に含めておくと、事業が広がったあとの経理の混乱を防げます。
新収益認識基準と前受金管理の要件
新収益認識基準では、年払いのサブスクリプションの売上を、サービス提供期間に応じて月割で計上します。そのため、契約期間と入金情報から毎月の売上計上額と前受金（繰延収益）残高を自動で算出する機能を、RFPで求めます。
契約ごとに残りの提供期間を手作業で追うのは、現実的ではありません。この自動化が、経理の効率と決算の正確性を支えます。
- 代行経由の会計処理：純額入金でも売上は総額計上し、手数料は費用として分ける
- 仕訳連携：総額・純額の表示方針を定め、課金データから仕訳を自動生成する
この仕組みがあれば、契約数が数百・数千に増えても、決算時の手作業が膨らみにくくなります。
既存システム連携とAPI要件の整理
課金システムは単独では完結せず、既存システムとの連携が前提になります。そのため、発注側は連携先とデータの流れを整理し、APIの有無やデータ項目を確認しておきます。
- 連携先：会計ソフト、販売管理、顧客管理（CRM）、ECカート
- データの流れ：課金データを会計へ送り、CRMの顧客データを課金へ取り込む
- 要件の明確化：連携範囲が曖昧だと会計ソフトと接続できない問題が起き、見積もりもぶれる
連携方式を検討する際には、開発費の目安も押さえておきます。オンライン決済のスクラッチ開発費は、クレジットカードのみのシンプルな構成なら50〜200万円です。
複数の決済手段やAPI、管理画面を含む中規模では150〜400万円が目安です。サブスク・多通貨・外部連携を含む大規模では300〜500万円以上で、要件次第では1,000万円を超えます。また、継続課金機能の開発費は、都度課金のみの1.5〜2倍です。
ロックイン回避とデータポータビリティの契約要件
RFPには、将来のベンダーロックインを避けるための契約要件を盛り込みます。乗り換え時にデータを持ち出せず、トークンも移せない場合には、不利な条件でも利用を続けることになり得ます。
トークン移行とデータポータビリティの要件
非保持型では、カード情報を決済代行ごとに固有のトークンで管理します。このトークンを乗り換え先へ移せないと、顧客全員にカードを再登録してもらう必要があり、その過程で顧客を失う恐れがあります。
RFPと契約交渉では、乗り換え時のトークン移行（カード情報の移管）に協力する条項を盛り込めるかを確認します。この協力の有無が、ロックイン回避の決め手になります。
- 移行協力：乗り換え先へのトークン移管に応じる契約条項
- データ出力：契約・課金・顧客データを一括エクスポート
- データ形式：標準的で、他システムに取り込みやすい形式
データポータビリティを契約に明記すると、事業の変化に応じて別の課金基盤へ移る選択肢を確保できます。また、乗り換えの自由は、ベンダーとの健全な力関係を保つうえでも役立ちます。
保守費用と隠れコストの契約条件
運用フェーズの費用は、保守費用と周辺手数料を分けて、契約で明確にしておきます。
- 保守費用：一次データの目安は初期開発費の月額5〜10%。初期500万円なら月25〜50万円
- 保守の範囲：障害対応、軽微な改修、決済代行の仕様変更への追従をRFPで定義する
- 周辺費用：返金・決済失敗の手数料、オプション料金、解約違約金を確認する
- 手数料の例：取消処理は5円〜数十円、決済サービス利用料は決済金額の0.3〜1%
取引量が増えるほど、こうした費用は無視できない金額になります。riplaは、フルスクラッチ受託の立場から、料金プランや非機能要件、会計連携、ロックイン回避を一貫した要件として整理します。
要件定義に時間をかけることが、後の手戻りと隠れコストを抑え、開発コストと運用リスクを小さくする近道です。
まとめ
課金システムのRFPは、四つの柱で組み立てます。料金プランの定義、非保持化・SLA・チャージバックを含む非機能要件、収益認識・会計連携と、ロックイン回避の契約条件です。
料金の曖昧さは、見積もりと開発のブレを生みます。非保持化はPCI DSSコストを50〜70%削減し、収益認識の自動化とトークン移行条項は、経理の混乱と乗り換えの制約を抑えます。
また、要件を文書として固める手間が、後の手戻りと隠れコストを構造的に減らします。
自社のビジネスモデルに照らして、料金プランから非機能要件、契約条項まで丁寧に詰めます。riplaはフルスクラッチ受託と国内開発を組み合わせ、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を創業。