課金システムの開発を外部ベンダーに発注するとき、成否を分けるのが要件定義とRFP（提案依頼書）の質です。「継続課金ができるシステムが欲しい」といった曖昧な依頼でベンダーに丸投げすると、自社の課金パターンに合わない見積もりが返ってきたり、開発の途中で「その仕様は聞いていない」という認識のズレが噴出したりします。課金システムは、料金プラン・決済・セキュリティ・会計が複雑に絡む領域だからこそ、要件を文書として正確に固める作業が、後の手戻りとコスト超過を防ぐ最大の保険になります。
本記事は、課金システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から実践的に解説する「要件定義特化」の内容です。料金プランと課金パターンの要件化、非保持化アーキテクチャやSLA・チャージバック条項といった非機能要件、収益認識・会計連携の要件、そしてベンダーロックインを避けるデータポータビリティの契約要件まで、一次データとあわせて具体的に解説します。読み終えるころには、ベンダーに渡すRFPの骨格が描けるはずです。なお、課金システムの全体像をまだ把握していない方は、まず課金システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・課金システムの完全ガイド
料金プランと課金パターンの要件化
課金システムのRFPで最初に、そして最も丁寧に書くべきなのが、料金プランと課金パターンの要件です。ここが曖昧だと、見積もりが過大にも過小にもブレ、開発に入ってから「想定していた料金体系に対応できない」という致命的な手戻りが発生します。自社が提供する、あるいは将来提供したい料金プランを、漏れなく言語化することがRFPの出発点です。
課金方式と料金プランを網羅的に定義する
RFPには、自社が扱う課金方式を具体的に列挙します。月額固定の継続課金なのか、利用量に応じた従量課金なのか、両者を組み合わせたハイブリッドなのか。初期費用や登録料の有無、無料トライアル期間の設定、複数プランの併存、上位プランへのアップグレード、年払い割引の有無まで、料金設計のバリエーションを書き出します。この段階で「将来こういうプランを増やしたい」という拡張性の要望も含めておくと、ベンダーが拡張に耐える設計を提案しやすくなります。
あわせて、月の途中での契約開始・解約・プラン変更時の日割計算（プロレーション）のルールを明記します。日割の基準を暦日とするか営業日とするか、アップグレード時の差額をどう扱うか、解約時に日割返金するかどうか。こうした計算ルールは、後から「思っていた挙動と違う」というトラブルになりやすいため、RFPの段階で具体的な計算例とともに示すのが理想です。料金プランの定義が曖昧なまま開発に進むことが、課金システム開発で最も多い失敗の入り口です。
決済手段と決済代行の要件を定める
料金プランと並んで定義すべきが、対応する決済手段です。クレジットカード、口座振替、キャリア決済、コンビニ払い、QRコード決済など、自社の顧客層に必要な決済手段を列挙します。SBペイメントの調査では「希望の支払手段がないと60%超が他店で購入する」とされており、決済手段の網羅性は機会損失に直結します。RFPでは、どの決済手段が必須でどれが任意かを優先順位づけして示すと、ベンダーが現実的な提案をしやすくなります。
決済代行（PSP）については、特定の代行会社を指定するのか、複数の代行をつなぐマルチホーミングを想定するのかを明記します。決済手数料率も要件に関わる重要な数字で、一次データでは全体の約4割が「3.0〜3.4%」に集中し、サブスクは「3.3〜3.4%」が突出して高い傾向にあります。トランザクション費用（1回数円〜数十円）や振込手数料も含めたコスト構造を理解したうえで、どの代行をどう組み合わせるかをRFPの検討材料に入れておくべきです。
非機能要件（非保持化・SLA・チャージバック）
課金システムでは、機能要件と同じくらい非機能要件が重要です。とくにセキュリティ・可用性・チャージバックといった項目は、後から追加しようとすると大きな改修コストがかかるため、RFPの段階で要件として固めておく必要があります。ここを曖昧にすると、リリース後に「セキュリティ基準を満たしていない」「障害時に課金が全停止した」といった深刻な問題に直面します。
非保持化アーキテクチャとPCI DSS要件
セキュリティ要件の中核が、カード情報の非保持化です。自社サーバーにカード番号を保存せず、決済代行のトークンで課金を管理する非保持型のアーキテクチャを要件とすることで、PCI DSSという国際セキュリティ基準への準拠範囲を最小化できます。一次データでは、PCI DSS対応はコンサルで数十万〜数百万円、QSA審査で年間数百万円規模、大企業の改修は年間数千万円に及ぶとされ、非保持化によりこの対象範囲を縮小すれば開発・セキュリティコストを50〜70%削減できるとされています。
RFPでは、非通過型・トークン決済を前提としたシステム構成を要件として明示し、PCI DSSのどの範囲を自社が負い、どこを決済代行に委ねるかを切り分けます。あわせて、EMV 3-Dセキュア2.x への対応を必須要件として記載します。これは2025年3月末でECにおける導入が原則義務化された要件であり、対応していない提案はそもそも検討対象になりません。セキュリティを後付けにすると改修コストが跳ね上がるため、非保持化はRFPの最初から織り込むべき非機能要件です。
SLA（稼働率）とチャージバック負担条項
可用性の要件としては、SLA（サービス品質保証）を明記します。決済まわりの業界水準は稼働率99.99%以上（月間4.3分以下のダウンタイム）が目安とされ、課金が止まることは継続課金では即座に機会損失と解約リスクにつながります。RFPでは、求める稼働率の水準、障害時の復旧目標時間、決済代行が障害を起こした場合のフォールバック（マルチホーミングなど）をどう設計するかを要件として示します。
チャージバックについては、その運用フローと負担の所在を契約要件として整理します。チャージバック（異議申立による代金取消）が発生した際の証拠提出フロー、チャージバック率が一定（例えば0.9%超）を超えた場合のアクワイアラからの違約金や決済停止のリスク、その損失を誰が負担するか。これらを曖昧にしたまま契約すると、トラブル発生時に責任の所在で揉めます。RFPの段階でチャージバック対応の体制と費用負担を要件化しておくことが、運用フェーズのリスクを抑えます。
収益認識・会計連携の要件定義
課金システムの要件定義で見落とされがちでありながら、後で経理を苦しめるのが、収益認識と会計連携の要件です。多くの競合製品やRFPテンプレートはここが手薄ですが、継続課金ビジネスでは、課金システムと会計処理の連動を最初から要件に含めておくことが、事業拡大後の経理の破綻を防ぎます。
新収益認識基準と前受金管理の要件
新収益認識基準のもとでは、年払いのサブスクリプションの売上を、サービス提供期間に応じて月割で計上する必要があります。RFPでは、課金システムが契約期間と入金情報をもとに、毎月の売上計上額と前受金（繰延収益）残高を自動算出できることを要件とします。手作業で契約ごとの残り提供期間を追いかけるのは現実的でないため、この収益認識の自動化を課金システムに織り込むことが、経理の効率と決算の正確性を担保します。
あわせて、決済代行を経由する取引の会計処理を要件化します。決済代行からは手数料を差し引いた純額で入金されるため、総額での売上計上と手数料の費用計上を正しく分ける必要があります。総額表示か純額表示かといった会計方針を要件として示し、課金データから会計仕訳を自動生成できる連携を求めます。収益認識の要件を最初から固めておけば、契約数が数百・数千に増えても、決算時の手作業が膨れ上がらずに済みます。
既存システム連携とAPI要件の整理
課金システムは単独では完結せず、会計ソフト、販売管理、顧客管理（CRM）、ECカートなど、既存システムとの連携が前提になります。RFPでは、どのシステムとどの方向にデータを連携するか（課金データを会計へ送る、CRMの顧客データを課金へ取り込むなど）を、連携先ごとにAPIの有無やデータ項目とあわせて整理します。連携要件が曖昧だと、開発後に「会計ソフトとつながらない」という問題が発覚します。
連携方式の検討にあたっては、開発費の目安も把握しておくべきです。一次データでは、オンライン決済のスクラッチ開発はシンプルなクレカのみで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作りを支援しています。要件定義に時間をかけることが、結果的に開発コストと運用リスクを最小化する最短経路です。
まとめ
課金システムのRFP・要件定義を整理すると、その骨格は「料金プランと課金パターンの網羅的な定義、非保持化・SLA・チャージバックの非機能要件、収益認識・会計連携の要件、ロックイン回避とデータポータビリティの契約要件」という四つの柱で構成されます。料金プランの曖昧さは見積もりと開発のブレを生み、非保持化はPCI DSSコストを50〜70%削減し、収益認識の自動化は経理の破綻を防ぎ、トークン移行の契約条項は乗り換えの自由を守ります。これらを文書として固める手間が、後の手戻りと隠れコストを構造的に減らします。
RFPを作るときに大切なのは、「機能を並べる」ことではなく「自社の料金体系・会計・リスク・将来の乗り換えまでを要件として言語化する」という視点です。自社のビジネスモデルに照らし、料金プランの定義から非機能要件、契約条項までを丁寧に詰めてください。riplaはフルスクラッチ受託と国内開発を組み合わせ、後悔しない要件定義とRFP作成、その先の課金システム構築を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。