申込受付システム開発は、要件整理から定着まで6段階で進めます。各段階で仕上げるものと次へ進む条件を合わせておくと、受付後の処理負担を減らせます。
開発の全体像、進め方、費用相場、見積もりの確認点の順に解説します。
▼全体ガイドの記事
・申込受付システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
申込受付システム開発の全体像
申込受付システムは、Webやスマートフォンで申込者情報を受け付ける業務システムです。さらに、受付後の確認、審査、承認、決済を管理します。通知、キャンセル、利用実績までも扱います。
問い合わせフォームとの違いは、申込データを業務データとして蓄積する点です。そのため、処理状況、期限、定員、証憑、対応履歴も追跡できます。
フォームと申込受付システムの違い
フォームは、氏名や連絡先などを受け取る入口です。一方で、受付業務のうちフォームだけでは扱いにくい作業は、システムで担えます。
申込受付システムが担う範囲は、次の領域に分けられます。
- 受付制御：期間、定員、先着順・抽選、重複申込を管理します。
- 受付後の処理：自動通知、審査、差戻し、入金照合を扱います。
- 変更対応：キャンセル待ちや申込者の変更・取消に対応します。
たとえば、受付後にExcelへ転記したり、メールを検索して進捗を確認したりする業務では、フォームを導入しても課題が残りやすくなります。
講座の受付では、フォーム、定員、支払状況、受講票、当日の出欠をつなぐと、担当者の負担を減らせます。
伸和トータルエンジニアリングの事例は、イベント登録から申込管理、当日受付までを一貫して扱っています。QRコードの受講票で、紙の印刷や受付作業を減らしたと紹介されています（出典：株式会社伸和トータルエンジニアリング「講演会・研修予約管理システム」開発事例、2026年確認）。
最初に押さえたい主要機能
申込者の作業と運用者の作業を分けて機能を整理すると、必要な範囲を決められます。主な機能は、申込者向け、申込後の操作、運用者向け、出力・受付の4つの面に分けて挙げられます。
- 申込者向け：スマートフォン対応、入力チェック、条件分岐、確認画面の要否。
- 申込後の操作：添付、下書き保存、変更・取消、マイページを検討します。
- 運用者向け：検索、担当割当、状態変更、承認・差戻し、コメント、履歴を整理します。
- 出力・受付：CSV、帳票、枠別定員、抽選、キャンセル待ち、QRコード、当日受付を候補にします。
決済や本人確認を扱う場合は、カード決済、請求書、入金照合、本人確認書類、認証、権限分離を要件に含めます。あわせて、監査ログ、保存期間、削除方法も決めておきます。要配慮個人情報や大量の個人データを受け付ける場合は、通信時・保存時の暗号化、閲覧範囲、バックアップ、障害時の連絡体制も、初期段階で決めます。
申込受付システム開発の進め方
画面を作る前に、受付後の判断者とデータの連携先を決めておくと、開発の手戻りを減らせます。開発は6つの段階に分けて、段階ごとに成果物と次へ進む条件を発注側と開発会社で合意します。
フェーズ1：要件整理と業務全体像の確定
まず、申込入力から受付完了、審査、承認、決済、利用、キャンセルまでを業務フローにまとめます。通常処理に加えて、例外処理もヒアリングの対象にします。申込と運用の両方の例外、成果物、要件の優先度を、この段階で具体的にしておきます。
- 申込の例外：重複申込、入力不備、期限切れ、定員超過の扱い。
- 運用の例外：入金遅れ、返金、添付差替え、担当者不在への対応。
- 成果物：業務フロー、画面・データ項目一覧、権限表を作ります。
- 要件の優先度：外部連携と非機能要件を、MUST・WANTに分けます。
紙、電話、Excel、メールが残っている箇所を調べると、フォーム導入だけでは解決しない課題が見えてきます。受付後の担当者、処理期限の通知先、変更可能な期間、保存年数と削除時期は、発注側で決めておきます。障害時に紙や電話へ切り替えるかも、あわせて確認します。
特に、要件が曖昧なまま開発へ進むと、後工程で追加費用や納期延長が発生しやすくなります。
フェーズ2：要件に合わせた製品・開発会社の選定
方式は同じ機能表に並べて比べ、自社の業務に合う候補を絞ります。あわせて、必要な機能と、運用者が自分で変更したい範囲も比べます。方式によって、向いている業務の範囲が変わります。
- フォームSaaS：単純な募集を、無料または低価格で短期間に始めたい場合の候補です。
- ローコード：複数フォーム、承認、一覧、CSV出力を自社で変えたい場合に向きます。
- 個別開発：独自審査、料金計算、本人確認、基幹連携が中心なら、自由度を得られます。
比較表には、申込者・管理画面、定員・抽選、変更・取消を入れます。さらに、決済、通知、ファイル保管、QR受付も含めます。API、SSO、権限、監査ログも比べます。そのほか、バックアップ、障害復旧目標、運用者の変更範囲も、比較の対象にします。
formrunの料金ページでは無料プランから始められます。ただし、重複回答防止や確認画面、上限設定はプランごとに異なります。
権限管理と閲覧制限も、プランによって違いがあります（出典：formrun「プラン・価格」、2026年確認）。そのため、必要な機能が含まれるプランを確認します。
開発会社については、同用途の実績を確かめます。加えて、要件定義の担当者と設計レビューを確認します。テスト計画やリリース後の保守窓口も見ておきます。
提案書に、画面だけでなく受付後の業務フロー、データ移行、障害時の復旧方法が書かれていれば、各社の提案を同じ観点で比べられます。
フェーズ3：画面・データ・連携の設計と開発
利用者画面に加えて、受付後に担当者が使う管理画面も具体化します。そのうえで、状態ごとの変更条件と担当者を設計します。状態の定義から連携の設計まで、この段階で項目ごとに詰めます。
- 状態の設計：「受付済み」「確認中」「差戻し」「承認」の定義。
- 決済後の状態：「決済待ち」「完了」「取消」などの定義。
- データの分割：申込者、申込、商品・講座・枠、添付書類、決済、通知、操作履歴を、別々のデータとして扱います。
- 連携の設計：項目、送信時期、再送、重複判定、どこまでを誰が受け持つかを記載します。
状態を細かく分けすぎると、運用が複雑になります。そのため、集計、通知、引継ぎで実際に使う状態に絞ります。同じ情報を複数箇所へ二重入力しないよう、データの持ち方も先に決めます。
CRM、会計、kintone、ウェビナーツールとの連携では、申込データがどこへ渡るかを決めます。API連携には、追加の費用と期間が発生する可能性があります。そのため、提案段階から確認します。
画面設計では、片手操作、入力途中の離脱、エラー表示を確認します。さらに、キーボード操作、読み上げ順序、文字サイズも確認します。
デジタル庁は2025年10月、事業者や行政機関向けのウェブアクセシビリティ導入ガイドブックを公開しました。幅広い対象者から申込を受ける場合は、対応方針と試験方法を要件に含めることが推奨されています（出典：デジタル庁「ウェブアクセシビリティ導入ガイドブック」、2025年）。また、発注時に試験項目と成果物を明記します。
フェーズ4：機能・連携・負荷・セキュリティのテスト
テストでは、正常に申込できるかに加えて、業務上の例外をシナリオに含めます。観点は、申込時、受付後、連携・権限の3つに分けて考えます。
- 申込時：二重送信、同じメールアドレスの重複申込、定員直前の同時申込を試します。
- 受付後：抽選通知、添付容量超過、決済失敗、メール不達、キャンセル。
- 連携・権限：差戻し、権限外閲覧、連携先の停止。
受入テストでは、申込者、受付担当者、承認者の役に分かれ、実際の業務手順どおりに操作します。
繁忙期に一斉受付する場合は、想定ピークを基準に負荷試験を行います。確認項目は、画面表示時間、同時接続数、受付完了率です。加えて、メール配信の遅延、決済の再送件数、障害からの復旧時間も測ります。合格ラインは、利用者数、受付時間、業務上の許容範囲から決めます。
発注側は、脆弱性診断や権限テストの結果と対応状況を受け取ります。
IPAは、代表的な脆弱性を解説しています。たとえば、SQLインジェクションやクロスサイト・スクリプティングが挙げられ、CSRFとアクセス制御の欠落も代表例です（出典：IPA「安全なウェブサイトの作り方」、2026年確認）。
申込情報を閲覧できる管理者は限定し、利用者本人の情報だけを表示します。さらに、エラー表示にデータベース情報を出さないことも確認します。
フェーズ5：小規模な稼働と本番運用への移行
稼働前には、データ移行、アカウント、権限を確認します。通知先、受付条件、規約類も、あわせて確認します。そのうえで、まずは一部の用途で試行し、そこから対象を広げます。設定の内容、利用条件、試行運用の記録を、まとめて見直しておきます。
- 初期設定：メール文面、受付期間、定員、料金の確認。
- 利用条件：利用規約とプライバシーポリシーの確認。
- 試行運用：一つの講座か申込区分で、問い合わせや入力ミスを記録。
切替日を決める際は、旧運用の停止時期、既存申込の扱い、障害時の連絡先もあわせて決めます。受付開始時刻と定員は、二人以上で確認します。
また、テスト用データを本番に残さないようにします。リリース判定の条件には、受入テストの完了と重大不具合の解消を含めます。マニュアルと担当者訓練も条件に加えます。
バックアップと復旧手順も確認します。最後に、試行運用で記録した問い合わせや入力ミスを分析し、改善点を反映してから運用対象を広げます。
フェーズ6：運用の改善と現場への定着
稼働後は、受付から処理完了までを計測します。導入効果は、公開できたかどうかだけでなく、業務負担が減ったかで評価します。指標は、申込状況、運用状況、決済・現場の3つに分けて追います。
- 申込状況：完了率、入力離脱率、重複申込率
- 運用状況：処理時間、差戻し率、問い合わせ件数
- 決済・現場：入金照合、当日受付、障害復旧の時間
各指標は月次で確認します。加えて、担当者の手作業による転記件数が、どれだけ減ったかも評価します。
項目、通知文、集計軸への変更要望は、月次の改善会議で優先順位を付けます。比べる観点は、利用者の不便、業務ミス、法令・セキュリティです。さらに、集計の必要性と工数も比べます。
運用者が自分で変えられる範囲と、開発会社へ依頼する範囲は、マニュアルに明記します。あわせて、個人情報漏えい時の連絡ルートも、導入時に整えておきます。
個人情報保護委員会は、報告対象の漏えい等について、速報は発覚日からおおむね3〜5日以内、確報は原則30日以内と案内しています。なお、不正目的のおそれがある場合の確報は60日以内です（出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」、2026年確認）。
契約書では、検知、一次報告、原因調査の担当を決めます。また、利用者通知と再発防止の担当も決めます。
申込受付システムの費用相場とコストの内訳
費用は、フォーム数だけでなく、受付後の業務、連携、セキュリティ、アクセス集中への対応によって変わります。
申込受付専用の公開統計は限られるため、ここに示す金額は、NotebookLMの業務システム相場整理と公開類似案件を組み合わせた目安です。予算検討用の幅としてご覧ください。正式な見積もりではありません。
方式別の初期費用・月額費用・期間の目安
方式によって、初期費用、月額、導入期間は異なります。機能や連携の範囲も合わせて比べます。方式ごとの目安を並べると、規模が大きくなるほど費用と期間が増える傾向が分かります。
- フォームSaaS：初期費用0〜30万円程度、月額0〜10万円程度、導入期間は即日から1か月程度が目安です。
- ノーコード・ローコード：初期費用50〜300万円程度、月額1〜20万円程度、期間1〜3か月程度。
- 小規模な個別開発：初期費用300〜700万円程度、期間2〜5か月程度。
- 中規模の業務システム：700〜1,800万円程度、期間4〜9か月程度。
- 大規模開発：1,800〜4,000万円以上、9〜18か月以上になる可能性があります。
フォームSaaSは、単純な募集や問い合わせ、少数申込に適します。一方で、ローコードは、複数フォームや承認を組み合わせたい場合に向きます。一覧、CSV、軽い連携を加えたいときにも候補になります。
複数部署、審査・承認、決済は、中規模以上になりやすい要素です。CRM・会計連携も、規模を大きくしやすい要素です。
自治体、金融、全国展開は、大規模化の要因です。加えて、大量アクセスや高いセキュリティ要件も、大規模化につながる要因です。
いずれの費用も、機能、利用者数、連携数、テスト範囲によって変わります。参考として、伸和トータルエンジニアリングの事例は、フルスクラッチで約400〜600万円、開発期間は約5か月です。
この事例には、イベント登録、申込管理、QRコード受講票、当日受付が含まれます。小〜中規模の参考ではありますが、自社の要件との差を確認してください（出典：同社公開事例、2026年確認）。
初期費用以外に発生するコスト
見積書では、要件整理、設計、開発、テストの費用を分けて示してもらいます。工程別の割合の目安は、開発の比率が最も大きいことを示します。
- 工程別割合：要件定義は全体の約10%、設計は10〜20%です。
- 工程別割合：開発は全体の40〜60%、テストは10〜20%です。
業務システム全般の相場整理では、工程別の割合が参考になります。これはNotebookLM「業務システム全般_6」のQ&A整理（2026年）の考え方です。
残りには、プロジェクト管理や移行などの作業が入ります。リリース、教育、保守も、この残りに含まれます。そのため、割合だけで見積もりの妥当性を判断せず、作業範囲を確認します。
初期費用以外にも、クラウドやデータベース、ファイル保管の費用がかかります。さらに、メール・SMS、決済手数料、本人確認、ドメイン・証明書も発生します。
監視、バックアップ、脆弱性診断、保守にも費用がかかります。問い合わせ対応、データ移行、外部APIも、費用の対象になります。
月額プランには、フォーム数、管理者数、保存容量の上限がある場合があります。通知数、申込件数、API利用量にも、上限が設けられることがあります。
費用を抑えたい場合は、受付、管理、通知、最低限の集計を第一段階にします。高度な承認、マイページ、決済は、効果と緊急度で第二段階に分けます。QR受付とCRM連携も、同じ基準で第二段階に分けます。
ただし、後から追加しにくいデータ構造や権限設計は、初期段階で拡張性を確保します。
申込受付システムの見積もりを取る際のポイント
相見積もりでは、各社へ同じ前提条件を渡します。「申込フォームを作りたい」とだけ伝えると、各社の想定範囲がずれ、提案価格を比べられなくなります。
依頼書には、申込後の業務、利用者数、ピークを含めます。さらに、連携、セキュリティ、運用体制も記載します。
要件明確化と仕様書に入れる項目
仕様書では、申込の規模や運用条件を具体的に書きます。受付開始日だけでなく、繁忙期や締切直前の集中も伝えます。項目は、申込規模、申込内容、業務処理、既存環境の4つに分けて並べます。
- 申込規模：種類、年間件数、同時受付数、期間、定員、抽選を記載します。
- 申込内容：属性、入力項目、添付書類、変更・取消条件を記載します。
- 業務処理：通知、承認経路、決済、帳票、集計を記載します。
- 既存環境：連携する既存システムとピーク件数を伝えます。
提案の前に、ログインの要否と本人確認方法を決めておきます。複数枠への申込や、家族や代理人による申込の扱いも定めます。
添付ファイルの上限MBや、審査結果を変えられる人を決めておきます。決済失敗時の再試行、キャンセル料と返金方法も確認します。さらに、CSVのダウンロード権限、データ保存期間と削除方法、障害時の代替受付も、回答できる状態にします。
複数社比較と発注先の選び方
初期費用だけでなく、工程や納品範囲を分けて比べます。見積書に「一式」とある項目は、作業、回数、成果物、前提条件を尋ねます。比べる項目は、工程、移行・定着、品質・保守の3つです。
- 工程：要件定義、設計、開発、テストの費用を確認します。
- 移行・定着：データ移行、教育、リリース支援の範囲。
- 品質・保守：権限、負荷試験、脆弱性診断、保守の範囲。
低価格の提案では、管理画面やメール再送などが含まれないことがあります。そのため、同じ業界や業務フローの事例を確認すると、提案の実現性を判断できます。
事例で聞く内容には、申込者・管理者数と連携先があります。開発期間と稼働後の保守内容も聞きます。
2026年1月公開のM-SOLUTIONS事例では、1,300人来場のイベントでQRコードとiPadを使いました。申込管理から当日受付、ブース来場記録までを一つの仕組みで扱っています。大量受付では、現場の受付導線も提案できるかを見ます（出典：M-SOLUTIONS「Smart at event導入事例」、2026年確認）。
見積もりで注意すべきリスクと対策
要件が固まらないまま全機能を請負契約にすると、追加要望の扱いが曖昧になりやすくなります。そこで、要件整理や試作の後に、確定した範囲を開発契約にする方法もあります。契約では、変更管理や検収のほか、個人情報と外部サービスの扱いも確かめます。
- 契約：変更管理、検収、納品物、瑕疵対応、再委託を確認します。
- 個人情報：取扱いと、障害時にどこまでを誰が受け持つか。
- 外部サービス：料金・仕様変更、停止、データ出力、解約時の返却を確認します。
判断の基準は、クラウドやSaaSを採用するかどうかよりも、停止時に受付を続けられるか、保存データを移行できるかです。加えて、障害情報をどこまで公開するかも確認します。
セキュリティ面では、「SSL対応」に加えて、管理者の多要素認証、権限、操作ログを確認します。さらに、バックアップ、診断、パッチ適用は、対応の有無を確かめます。監視と報告期限も確認します。
デジタル庁は、行政手続をスマートフォン等で完結させる方向を示しています。2025年12月末時点で、国民の約8割がマイナンバーカードを保有すると案内しています（出典：デジタル庁「行政手続のオンライン化」、2026年6月）。そのため、行政手続の申込では、本人確認と利用者支援の方法を要件に含めます。
申込受付システム開発でよくある質問（FAQ）
費用や期間は、機能と運用条件によって変わります。FAQの回答は、そのまま使うのではなく、自社の要件整理や見積依頼書に置き換えてご利用ください。
申込受付システムの開発期間はどのくらいですか？
方式や機能によって期間は異なります。外部連携や試験が増える場合は、工程ごとの計画を確認します。目安は、方式と計画の内容ごとに4つの区分で示します。
- フォームSaaS：即日から1か月程度が目安です。
- ノーコード・ローコード：1〜3か月程度が目安です。
- 小規模な個別開発：2〜5か月程度が目安です。
- 審査・連携・試験を含む計画：4〜9か月程度になる場合があります。
審査や決済、複数部署の承認を含めると、期間が延びます。外部連携や大量アクセス試験も、期間を延ばす要因です。そのため、他社事例の約5か月はそのまま当てはめず、フェーズごとに確認します。
申込受付システムはSaaSとスクラッチ開発のどちらがよいですか？
受付条件が定型的で、短期間に始めたい場合は、SaaSが候補になります。一方で、独自業務が価値の中心で製品に合わせにくい場合は、スクラッチ開発を検討します。
フォームSaaS、ローコード、個別開発を比べます。判断材料は、MUST機能と変更したい項目です。さらに、連携の深さと将来の利用者数も見ます。
個人情報を扱う申込受付システムで何を確認すべきですか？
閲覧、変更、出力できる人は、権限表で定めます。認証や暗号化、ログの扱いも確認します。さらに、保存期間、削除、診断、障害報告も確認します。
本人確認書類や要配慮個人情報を扱う場合は、契約書に委託先、再委託先、保管場所を反映します。閲覧者と事故時の連絡期限も、契約書に盛り込みます。
AI機能を使う場合は、申込内容や添付書類を外部モデルの学習に使うかどうか、人が最終判断するかどうかを明確にします。
まとめ
開発を始める前に決めること
まず、申込者の負担、担当者の転記や確認、受付後の標準化のうち、どの課題を解決したいのかを明確にします。目的によって、優先する機能も変わります。
MUST機能、処理期限、利用者数、ピークを決めておくと、製品と開発会社を同じ条件で比べられます。個人情報の扱いと連携先も、あわせて決めておきます。
見積もり依頼から定着までの次の一歩
見積もりから定着までは、業務要件、開発範囲、費用、運用効果の順に確認します。
- 現行業務を一枚のフローにまとめ、例外処理を含む要件メモを作ります。
- 候補先には、受付後の業務を含めた提案を依頼します。
- MUST機能と業務フローを基に、申込者と運用者が使える方式と発注先を選びます。
- 方式ごとの初期費用を、相場と照らして比べます。
- 相場を目安に、連携、決済、保管、監視、保守、セキュリティ試験、運用教育を含めた総額を比べます。
- 稼働後は、申込完了率や処理時間を指標に、改善を続けます。
提案では、画面だけでなく受付後の審査、承認、決済を確認します。通知、キャンセル、連携も確かめます。加えて、状態、権限、テスト、保守の内容も見ておきます。
要件整理から定着までの6段階で、成果物と判断基準を確認しておくと、追加開発や現場の混乱を抑えられます。
初期費用は、フォームSaaSで0〜30万円程度からです。ローコードは50〜300万円程度、小規模開発は300〜700万円程度が目安です。中規模以上は、700〜1,800万円程度です。
▼全体ガイドの記事
・申込受付システム開発の完全ガイド
▼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を創業。