願書受付システムの発注は、業務の範囲を決め、発注形態を選び、RFPで要件をそろえたうえで、同じ条件の見積を比べる順に進めます。
この順で進めると、入試業務全体を安全に運用しやすくなります。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・願書受付システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
願書受付システムを発注する前に押さえる全体像
願書受付システムは、出願から入学手続きまでをつなぐ業務基盤です。
志願者が情報を登録する画面は、その入口にあたります。
対象業務には、志望校と試験区分の選択、検定料の支払い、顔写真や調査書の提出が含まれます。
このシステムは、学校などによる確認や受験票の発行、合否照会も扱います。
発注の起点を画面作成だけに置くと、現場の承認や例外処理が抜けやすくなります。
発注の範囲は、業務全体の流れから決めます。
志願者から事務局まで関係者が多い業務
学校種によって担当者や承認の流れが違うため、発注前に業務フローへ落とし込みます。私立と公立では、確認や承認を担う人の範囲が異なります。
- 私立中高・大学：志願者が登録し、保護者が支払い、学校が出願内容を確認する場合があります。
- 公立高校：志願者、中学校、高校、教育委員会が、それぞれ別の権限で確認・承認する場合があります。
誰が入力し、誰が差し戻し、誰が最終確定するかを決めておくと、発注要件が明確になります。
出願完了の条件の決め方
出願完了を保存時点とするか、決済と書類提出まで含めるかで、画面設計と問い合わせ対応が変わります。
- 状態表示：未払い、写真未提出、学校確認待ち、差し戻し中を区別して表示。
- 次の操作：志願者の画面に、次に必要な手続きを示す。
- 代替手段：コンビニ印刷と、電話・窓口での受付導線。
家庭にプリンターがない志願者や、スマートフォンだけで操作する志願者もいるため、そうした場合も想定して要件に含めます。
システム以外にも及ぶ発注範囲
システム開発に加えて、周辺業務をどこまで委託するかも決めます。対象になりうる作業は、発注範囲と照らし合わせて洗い出します。
- 導入準備：募集要項のマスタ登録、既存データ移行、職員研修。
- システム連携：学籍・校務・入試判定・会計、決済代行、メール配信。
- 稼働後の支援：問い合わせ窓口、繁忙期の監視、サーバー運用。
デジタル庁は、高校入試を出願から入学許可書の発行まで17プロセスに整理しています（出典：デジタル庁「令和6年度教育関連の事業成果」、2025年）。
発注時に17プロセスを確認表にすると、出願だけを対象にした発注漏れを防ぐ助けになります。
発注形態の選び方（クラウド・パッケージ・独自開発）
短期間で標準的な出願、決済、受験票発行を始めたいなら、クラウドや教育向けパッケージが候補になります。一方で、自治体独自の承認や特殊な選抜には、追加開発や独自開発を検討することになります。
既存の基幹システムと密に連携する必要がある場合も、追加開発や独自開発を組み合わせます。方式は先に決めず、標準機能で対応できない要件の量と、制度変更への対応方法を見てから選びます。
クラウドSaaSの強み（短納期と運用負担の軽さ）
クラウドSaaSは、自校でのサーバー構築やOS更新を抑えやすい方式です。複数校で同じ仕組みを共有する場合にも向いています。
- 課金単位：利用月のみか、登録者数や出願件数に応じるか。
- 追加料金：決済手数料が月額とは別にかかる場合の負担。
- 運用範囲：制度改定、バックアップ、監視、障害復旧の担当者。
月額料金だけでなく、サービス提供会社が担う作業と復旧範囲も比べます。
教育向けパッケージの強み（実績と標準業務）
教育向けパッケージには、受験票、合否照会、受験料決済、入学手続きなどの機能が備わっている場合があります。
導入実績があると、想定外の運用を洗い出す参考になります。
たとえば、個人出願か中学校経由か、推薦・一般・併願をどう扱うかを確かめます。そのうえで、調査書の差し戻しなども含めて、実際のテスト画面と操作権限を見てから採用します。
独自開発を選ぶ場面（特殊要件と連携要件）
独自開発や大幅なカスタマイズなら、自校に合わせて画面、データ、承認、帳票、APIを設計できます。ただし、開発後の制度変更や脆弱性対応、性能改善、担当交代時の引き継ぎは、発注者の責任になりやすいです。
権限分離や操作ログ、二者確認、暗号化などのセキュリティ対策を範囲に含めます。日次バックアップと復旧訓練も範囲に入れ、データ返却は保守契約に定めます。
RFPと要件整理の進め方
RFPは、解決したい業務課題と評価条件を候補会社に伝える文書です。機能の一覧だけでなく、発注の前提をそろえる役割もあります。
募集要項の設定から入学手続きまでの流れを、時系列で記載します。出願や決済、合否などの各段階も、そのなかに含めます。
締切直前や差し戻し時の処理も示しておくと、同じ前提で提案を受けられます。さらに、見積金額と納期も比べやすくなります。
役割と状態で書き出す業務フロー
関係者の役割と申請状態を並べると、管理画面に必要な操作が見えてきます。
- 関係者：志願者、保護者、中学校、高校、大学、教育委員会、事務局、決済事業者。
- 申請状態：「下書き」「入力確認依頼」「中学校確認済み」「高校受付済み」。
- 完了まで：「決済待ち」「書類差し戻し」「出願完了」「合否発表済み」など。
発注側は、各状態で変更できる項目と通知先、操作担当者、取り消しの可否を決めます。
非機能要件の数字と証跡の指定
出願開始日や締切日、合否発表日は、アクセスが集中しやすい日です。そのため、平常時ではなくピーク時の利用を想定して要件を書きます。
- 負荷条件：同時接続数、1時間あたりの登録件数、メール数、ファイル容量。
- 性能条件：想定ピーク、目標応答時間、負荷試験の実施条件。
- 障害対応：目標復旧時間、データ復旧時点、連絡手段、報告期限、代替受付。
個人情報は、SSLによる保護に加えて、志願者情報や顔写真、調査書、成績、合否情報を分類しておきます。閲覧や出力、削除の権限、再委託、保管期間後の削除方法も確かめます。
文部科学省は2025年3月に、教育情報セキュリティポリシーに関するガイドラインを改訂しました。クラウド活用を前提に、情報資産管理と安全対策を見直しています（出典：文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年3月）。
必須機能と将来機能の切り分け
初年度から全機能を独自に作り込もうとすると、要件定義が長引き、テスト不足につながります。
- 初回稼働：出願、決済、書類提出、承認、受験票、合否照会。
- 初回稼働：必要な帳票と問い合わせ対応。
- 第二段階：分析ダッシュボード、他サービスとの連携拡張。
後から機能を足せるよう、API、データ項目、権限モデルは最初から拡張できる形にしておきます。
契約形態とスケジュールの確認事項
願書受付システムは、入試日程という動かしにくい期限に合わせて稼働させる必要があります。そのため、契約書には開発方式、成果物、検収条件を明記します。
発注側は、制度改定や障害対応に加え、個人情報やデータの返却・削除、再委託、知的財産権の扱いも定めます。
検収条件には、模擬出願と職員リハーサルの完了を含めます。本番稼働の日だけで納品を判断しないためです。
請負契約の使いどころ（範囲と検収条件）
要件と成果物が明確で、納品物を基準に検収できる場合は、請負契約が候補になります。固定価格で発注しやすくなります。
契約後に帳票や例外的な併願ルールが判明すると、変更費用や納期の延長が起きる場合があります。そこで、RFPに画面、帳票、連携、テスト、移行、研修を列挙し、対象外も明らかにしておきます。
準委任契約の使いどころ（要件整理と継続改善）
要件を一緒に検証する場合や、稼働後の改善・運用支援を続ける場合は、準委任契約で時間や体制を確保できます。
準委任では、発注者側も優先順位を決める必要があります。定例会議や意思決定者、課題管理、月次の成果確認も、計画に含めます。
開発は請負、企画や運用は準委任とするなど、業務に応じて組み合わせられます。
本番前の期間の見積り
方式ごとの期間をいったん仮置きし、要件に合わせて候補会社と調整します。
- 既存SaaS：設定・校正・テストに1〜3か月。
- 標準パッケージ：独自帳票や連携を加える場合は3〜6か月。
- 独自開発：複数校・自治体向けは6〜12か月以上。
いずれも要件で変わる目安であり、開発会社が期間を保証するものではありません。入試開始日から逆算して、予備期間も含めて工程を組みます。
工程には、募集要項の確定やマスタ登録、受験生テスト、職員研修、問い合わせ訓練を含めます。負荷試験やリハーサル、予備期間も入れ、開発会社に提案してもらいます。
デジタル庁は2026年6月更新のダッシュボードで、2025年度調査時点の都道府県の取組状況を公開しています（出典：デジタル庁「高等学校入学者選抜事務手続のデジタル化に関するダッシュボード」、2026年6月23日更新）。
地域の実施要項や先行事例を確認し、自校の制度でどこまでデジタル完結させるかを決めておくと、無理な納期を避ける材料になります。
願書受付システムの費用相場と見積の内訳
相場は学校種や志願者数、利用月数で変わり、決済方式や書類確認、既存連携、複数校対応によっても変わります。公開価格のあるサービス例と、公開価格が少ない独自開発の推定は、分けて扱います。金額は予算取りのレンジで、確定価格ではありません。
小規模なクラウド利用の費用の目安
小規模なクラウド利用では、標準機能を前提に費用の目安を確かめます。
- 課金の試算：出願件数、決済額、利用月数、収納代行の固定費。
- 件数の想定：少人数の年と、締切直前に件数が増える年。
- 追加料金：写真・証明書類の保管、SMS、コンビニ印刷、個別サポート。
標準機能を使う場合は、初期費用0〜30万円、月額0〜5万円程度が予算の起点になります。
Campus ENTRYは、利用月のみの場合は月額最大45,000円（税別）で、有償出願1件につき決済データ処理手数料100円です（出典：株式会社テラポート「Campus ENTRYサブスクリプション」、調査時点の公開料金）。
別の公開例では、初期費用が無料で、出願1名あたり2,750円の従量課金がかかります。月額と従量課金は分けて試算し、追加料金も同じ見積書に含めて比べます。
標準パッケージと一校向け開発の費用の目安（100万〜300万円）
見積もりでは、標準パッケージの導入範囲と、公開価格の前提条件を確かめます。
- 導入作業：パッケージ設定、独自帳票、権限設定。
- 稼働準備：テストと研修を含めて費用を確認。
この範囲の初期費用は100万〜300万円、年間保守は30万〜100万円程度が目安です。コーディア株式会社は、シンプルなベース版の開発費を100万円プラス税から、保守費を年50万円プラス税からと公開しており、サーバー代も込みです（出典：コーディア株式会社「Web出願システム」、公開ページ確認時点）。
これは一校・標準機能に近い公開例で、決済代行や独自API、データ移行、負荷試験、複雑な併願まで含むとは限りません。
連携や複数校対応を含む独自開発の費用の幅
独自開発の予算は、案件規模と見積範囲をそろえて検討します。
- 中規模案件：学籍・校務・入試判定・会計とのAPI連携、複数課程、学校単位の承認で300万〜1,000万円程度。
- 広域案件：自治体・複数校を横断する場合、1,000万〜3,000万円以上の可能性。
中規模案件には、教育委員会の全体集計、SSO、詳細な帳票も含みます。この推定レンジは一律の公開相場ではありません。一般的なWeb業務システムの工数と、リサーチノートの公開価格をもとにした目安です。
広域案件では、住民向け問い合わせ、セキュリティ審査、移行、研修に加えて、ピーク負荷や災害時の継続まで費用に含む場合があります。初期設定、要件定義、UI設計、テストサイト、負荷試験、脆弱性診断は、明細にしてもらいます。
保守や制度改定、ヘルプデスク、紙や電話の代替運用は、別に記載してもらいます。サーバーや監視、メール配信、決済手数料も分けて示してもらい、5年間の総保有コストで比べます。
初期費用が安くても、毎年の従量費や改修費が大きいサービスは、総保有コストで見分けやすくなります。
委託先の選定と見積比較で確認するポイント
委託先は、機能数よりも入試運用への理解と繁忙期の支援体制で選びます。そのうえで、候補を2〜4社程度に絞ります。
候補には、同じRFP、想定出願件数、連携範囲をもとに、提案と見積を依頼します。各社の条件は、同じシートに並べて比べます。
比べる項目は、価格や実績の規模、担当体制、テスト方法、障害時の窓口、制度改定費です。
学校種別と入試フローの実績
導入校数だけでなく、自校に近い学校種や志願者規模、選抜方式の実績も確かめます。
- 公立高校：中学校確認、高校受理、教育委員会集計、合格発表。
- 私立中高：説明会予約、個人出願、併願、入学金決済。
- 大学・専門学校：学部・方式別設問、大学入学共通テスト関連、合否・入学手続き、入試業務一括委託。
発注側は、自校の業務に近い実績があるかどうかを、各フローの対応範囲まで確かめます。
同じ粒度の見積書の比べ方
見積書に一式表記がある場合は、費目ごとの内訳を候補会社に求めます。そうすると、対象範囲の違いを見分けやすくなります。
- 開発範囲：要件定義、画面、管理機能、帳票、外部連携、決済、通知。
- 運用準備：ファイル保管、権限、テスト、移行、研修、保守。
- 機能別の扱い：「標準対応」「設定」「追加開発」「対象外」を明示。
同じ粒度の見積なら、A社の金額が高いのか、B社が多くを対象外にして安く見せているのかを判定できます。
従量費は、志願者数に加えて、出願・決済件数、利用月、ファイル容量、通知数をもとに、年度別に計算します。
平日日中の問い合わせに加えて、締切や合否発表時の夜間・休日対応も確かめます。障害の発生箇所が決済会社、クラウド基盤、システム会社のどこであっても、受験生向けの窓口と連絡手順は契約で決めます。
提案書で確認するセキュリティと受験生支援
提案書では、情報保護と受験生支援の両方を確かめます。セキュリティ対策は、次の項目と照らし合わせます。
- アクセス管理：多要素認証、管理者権限の分離、操作ログ。
- 技術対策：通信・保存データの暗号化、WAF、レート制限、脆弱性診断。
- 復旧と委託：バックアップ、復旧試験、再委託先の管理。
写真や証明書のダウンロード履歴、合否データの公開予約、二者確認も確かめます。こうした確認が、漏えいと誤発表の両方を防ぎます。
事故が起きた場合の報告時間や調査協力、証跡保存、本人や学校への説明分担も、質問しておきます。
受験生向けには、スマートフォンでの入力や途中保存、エラー表示、決済の再試行、メール再送を確かめます。コンビニ印刷やFAQ、電話・窓口への切り替えも対象で、使えない人も取り残さない設計にします。
デジタル庁は、受験生に不利益を生じさせない高校入試のデジタル化方針を示しています（出典：デジタル庁「高等学校入学者選抜事務手続のデジタル化に関するダッシュボード」、2026年）。
よくある質問（FAQ）
発注や外注では、費用だけでなく、学校種別や導入時期、運用支援、契約終了時の扱いも確かめます。
願書受付システムの発注費用はいくらかかりますか？
願書受付システムの費用は、標準機能の利用から複数校向けの独自開発まで、発注範囲によって変わります。
- クラウド：初期0〜30万円、月額0〜5万円程度。
- パッケージ・一校向け：初期100万〜300万円、年間保守30万〜100万円程度。
- 独自開発：300万〜1,000万円程度。大規模なら1,000万〜3,000万円以上。
上の金額は、公開価格や要件に基づく目安で、確定価格ではありません。決済手数料や制度改定、ヘルプデスクの範囲によっても変わります。
クラウドSaaSと独自開発はどちらを選べばよいですか？
短納期や標準的な入試業務、運用負担の軽減を優先するなら、クラウドSaaSや教育向けパッケージが向いています。
自治体独自の承認や特殊な選抜、基幹システムとの密な連携が欠かせないなら、追加開発や独自開発を検討します。
いずれの方式でも、API、データ返却、制度改定、障害復旧、個人情報の削除条件は、契約前に確かめておきます。
RFPには何を書けば見積を比較しやすくなりますか？
比較条件をそろえるため、RFPには次の情報を記載します。
- 学校と募集：学校種、志願者数、募集区分、出願期間、ピーク件数、関係者の役割。
- 機能と連携：画面・帳票、決済方式、書類提出、既存システム連携。
- 運用と安全：権限、ログ、バックアップ、障害時の目標。
- 導入条件：希望日、研修・サポート、必須・将来機能、データ移行、対象外業務。
- 見積回答：標準・追加開発・対象外と、初期・年間・従量・制度改定費。
発注から本番稼働まで何か月かかりますか？
目安は方式ごとに仮置きし、実際の要件に応じて見直します。
- 既存SaaS：設定・校正・テストに1〜3か月。
- パッケージ：追加開発を含めて3〜6か月。
- 独自開発：複数校・自治体向けは6〜12か月以上。
本番までには、要件定義と募集要項の確定を済ませておきます。そのうえで、次の準備を進めます。
- マスタ登録
- 決済・通知テスト
- 職員研修
- 受験生向けリハーサル
期間は要件によって変わるため、予備期間も含めて入試開始日から逆算します。テストサイトの利用開始日と検収日も、候補会社に提案してもらいます。
まとめ
発注では、最安の入力フォームより、入試業務を安全に完了できる運用基盤を選びます。
クラウド、パッケージ、独自開発を、学校種、志願者数、承認フロー、既存連携、制度変更の頻度で比べます。
RFPに書く業務と、受け持ちの範囲
17プロセスを参考に業務フローを整理して、出願完了の条件と関係者の権限を決めます。
ピーク時の性能や障害時の代替手順、個人情報の保持・削除も、RFPに定めます。
初期費用、年間保守、従量、決済、制度改定の費用を分けて示したRFPを作り、複数社へ同じ条件で依頼します。
価格と稼働後の安心の比べ方
見積では、価格だけでなく、稼働後の支援や安全対策も合わせて比べます。
- 体制：自校に近い実績、テスト・リハーサル、24時間対応、SLA。
- 運用と安全：監査ログ、バックアップ、審査、受験生支援、データ返却。
- 費用と継続性：公開価格と推定を分け、5年間の総保有コストを比較。
要件整理から開発、運用改善まで伴走できる委託先を選ぶと、入試本番の不安を減らせます。
▼全体ガイドの記事
・願書受付システム開発の完全ガイド
▼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を創業。