願書受付システム開発の発注/外注/依頼/委託方法について

願書受付システムの発注では、入力フォームだけでなく、出願・決済・書類確認・受験票・合否照会までの業務全体を対象に、学校種別と運用規模に合う委託先を選ぶことが重要です。

本記事では、願書受付システムを外注・委託するときの発注形態、RFPと要件整理、契約形態、費用相場、委託先の選定、見積書の比較方法を順番に解説します。公立高校、私立中高、大学・専門学校では必要な承認フローやピーク時の負荷が異なるため、公開価格だけでなく、制度変更や障害時まで含めた総額と責任分界を確認できるように整理します。

▼全体ガイドの記事
・願書受付システム開発の完全ガイド

願書受付システムを発注する前に押さえる全体像

願書受付システムは、志願者がWebから情報を登録するだけのサービスではありません。志望校や試験区分の選択、検定料の支払い、顔写真や調査書の提出、学校・中学校・教育委員会などによる確認、受験票の発行、合否照会、入学手続きまでをつなぐ業務基盤です。発注の起点を「画面を作ること」に置くと、現場の承認や例外処理が抜けやすくなります。

私立中高や大学では、志願者本人が登録し、保護者が支払いを行い、学校が出願内容を確認する場合があります。公立高校では、志願者、中学校、高校、教育委員会がそれぞれ別の権限で確認・承認することがあります。誰がどの項目を入力し、誰が差し戻し、誰が最終確定するのかを業務フローに落とし込むことが、発注時の最初の要件です。

「入力を保存したら完了」なのか、「決済と必要書類の提出まで終わって完了」なのかで、画面設計も問い合わせ対応も変わります。未払い、写真の未提出、学校による確認待ち、差し戻し中などの状態を別々に表示し、志願者が次に何をすべきかを示す必要があります。家にプリンターがない家庭へのコンビニ印刷、スマートフォンだけで操作する家庭への配慮、電話や窓口による代替導線も、要件の一部として整理します。

サーバーやアプリケーションの開発だけでなく、募集要項のマスタ登録、既存の学籍・校務・入試判定・会計システムとの連携、決済代行、メール配信、データ移行、職員研修、問い合わせ窓口、繁忙期の監視までを含めるかを決めます。デジタル庁は高校入試について、出願から入学許可書発行までを17のプロセスで整理しています（出典: デジタル庁「令和6年度教育関連の事業成果」、2025年）。このプロセスをチェックリストにすると、出願だけを見た発注漏れを防ぎやすくなります。

発注形態はクラウド・パッケージ・独自開発のどれがよいですか？

結論として、標準的な出願・決済・受験票発行を短期間で始めたい場合はクラウドや教育向けパッケージが適しています。自治体独自の承認、特殊な選抜制度、既存基幹システムとの密接な連携が必要な場合は、パッケージの追加開発や独自開発を組み合わせます。最初から開発方式を決めるのではなく、要件のうち標準機能で対応できない部分の量と、毎年変わる制度への追随方法で判断します。

クラウドSaaSは、サーバー構築やOS更新を自校で抱えずに利用しやすく、複数校で共通の仕組みを使う場合にも向きます。導入前には、利用月だけ課金されるのか、登録者数か出願件数か、決済手数料が別かを確認します。サービス提供会社が実施する制度改定、バックアップ、監視、障害復旧の範囲も、月額料金だけでは判断できない重要な比較項目です。

教育向けパッケージは、受験票、合否照会、受験料決済、入学手続きなど、入試で頻出する機能を持つことが多いです。既存サービスの導入実績があれば、想定外の運用を洗い出す参考になります。ただし、同じ「Web出願」でも、個人単位の出願と中学校経由の出願、推薦・一般・併願、調査書の差し戻しなどの対応範囲は異なります。実際のテスト画面と操作権限を確認してから採用します。

独自開発や大幅なカスタマイズでは、自校の業務フローに合わせて画面、データ、承認、帳票、APIを設計できます。一方で、開発後の制度変更、脆弱性対応、性能改善、担当者交代時の引き継ぎも発注者の責任として残りやすいです。画面とデータベースだけでなく、権限分離、操作ログ、二者確認、暗号化、日次バックアップ、復旧訓練、データ返却までを開発範囲と保守契約に含めることが必要です。

RFPと要件整理はどのように進めますか？

RFPは、単なる機能一覧ではなく、発注者が解決したい業務課題と評価条件を候補会社へ伝える文書です。願書受付では、募集要項の設定から出願、書類確認、決済、受験票、合否、入学手続きまでを時系列に書き、通常時だけでなく締切直前や差し戻し時の処理も示します。候補会社が同じ前提で提案できるため、見積金額と納期の比較がしやすくなります。

まず、志願者、保護者、中学校、高校、大学、教育委員会、入試事務局、決済事業者の役割を分けます。そのうえで「下書き」「入力確認依頼」「中学校確認済み」「高校受付済み」「決済待ち」「書類差し戻し」「出願完了」「合否発表済み」などの状態を並べます。各状態で変更できる項目、通知の宛先、操作できる担当者、取り消しの可否を決めると、管理画面の要件が具体化します。

出願開始日、締切日、合否発表日はアクセスが集中するため、平常時ではなくピーク時の同時接続数、1時間あたりの登録件数、メール送信数、ファイル容量を想定します。「十分な性能」ではなく、想定ピーク、目標応答時間、負荷試験の実施条件をRFPに書きます。障害時は、目標復旧時間、データ復旧時点、連絡手段、報告期限、代替受付の手順を候補会社から回答してもらいます。

個人情報保護もSSL対応だけで終わらせません。志願者情報、顔写真、調査書、成績、合否情報を分類し、誰が閲覧・出力・削除できるか、委託先が再委託するか、保管期間終了後にどう削除するかを確認します。文部科学省は教育情報セキュリティポリシーに関するガイドラインを2025年3月に改訂し、クラウド活用を前提に情報資産の管理や安全対策を見直しています（出典: 文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年3月）。

初年度からすべてを独自化すると、要件定義が長引き、テスト不足につながります。初回稼働では、出願、決済、書類提出、承認、受験票、合否照会、必要な帳票と問い合わせ対応を必須とし、分析ダッシュボードや他サービス連携の拡張は第二段階に分ける考え方が有効です。ただし、後から追加する機能のためにAPI、データ項目、権限モデルを最初から拡張可能にしておく必要があります。

契約形態とスケジュールは何を確認しますか？

願書受付システムは、入試日程という動かしにくい期限に合わせて稼働させる必要があります。契約書には開発方式だけでなく、成果物、検収条件、制度改定時の扱い、障害対応、個人情報の取扱い、データ返却、終了時の削除、再委託、知的財産権を明記します。特に「本番稼働したら納品」ではなく、模擬出願と職員リハーサルを終えた状態を検収条件にすることが大切です。

要件と成果物が明確で、納品物を基準に検収できる場合は請負契約が選択肢になります。固定価格で発注しやすい反面、契約後に「この帳票も必要」「例外の併願ルールがあった」と判明すると、変更費用や納期延長が発生します。RFPの段階で対象画面、帳票、連携、テスト、移行、研修を一覧化し、対象外を明確にしておくことが必要です。

要件を一緒に検証しながら進める場合や、稼働後の改善・運用支援を含める場合は、準委任契約で作業時間や体制を確保する方法があります。発注者側にも優先順位を決める責任があるため、定例会議、意思決定者、課題管理、月次の成果確認を契約・計画に含めます。開発部分を請負、企画・運用部分を準委任に分けるなど、業務の性質に応じて組み合わせることもあります。

既存SaaSの設定・校正・テストは1〜3か月、標準パッケージに独自帳票や連携を加える場合は3〜6か月、複数校・自治体向けの独自開発は6〜12か月以上を仮置きできます。ただし、これは要件による目安であり、開発会社が保証する一律の期間ではありません。募集要項の確定、マスタ登録、受験生向けテスト、職員研修、問い合わせ訓練、負荷試験、リハーサル、予備期間を入れて、入試開始日から逆算します。

デジタル庁は2026年6月更新の高校入試デジタル化ダッシュボードで、2025年度調査時点の都道府県ごとの取組状況を公開しています。地域の実施要項や先行事例を確認し、自校の制度でどこまでデジタル完結するかを決めることが、無理な納期を避ける助けになります（出典: デジタル庁「高等学校入学者選抜事務手続のデジタル化に関するダッシュボード」、2026年6月23日更新）。

願書受付システムの費用相場と見積の内訳

願書受付システムの相場は、学校種、志願者数、利用月数、決済方式、書類確認、既存システム連携、複数校対応で大きく変わります。公開価格があるサービスの例と、公開価格が少ない独自開発の推定を分けて考えることが大切です。以下の金額は発注前の予算取りに使うレンジであり、個別案件の確定価格ではありません。

標準機能を使う小規模なクラウド利用では、初期費用0〜30万円、月額0〜5万円程度を予算の起点にできます。株式会社テラポートのCampus ENTRYサブスクリプションでは、利用月のみ月額最大45,000円（税別）で、決済データ処理手数料は有償出願1件につき100円と公開されています（出典: 株式会社テラポート「Campus ENTRYサブスクリプション」、調査時点の公開料金）。別の公開例では初期費用無料で出願1名あたり2,750円という従量課金もあります。

ただし、月額と従量課金は別の軸です。出願件数、決済額、利用月数、収納代行の固定費を仮の件数で計算し、少人数の年と締切直前に件数が増える年の両方を試算します。写真や証明書類の保管、SMS、コンビニ印刷、個別サポートが別料金なら、同じ見積書に加えて比較します。

標準パッケージの設定、独自帳票、権限設定、テスト、研修を含む場合は、初期100万〜300万円、年間保守30万〜100万円程度を一つの目安にできます。コーディア株式会社は、シンプルなベース版のWeb出願システムについて、開発費100万円プラス税から、保守費年50万円プラス税から、サーバー代込みと公開しています（出典: コーディア株式会社「Web出願システム」、公開ページ確認時点）。これは一校・標準機能に近い公開例であり、決済代行、独自API、データ移行、負荷試験、複雑な併願ルールを含む金額とは限りません。

学籍・校務・入試判定・会計とのAPI連携、複数課程、学校単位の承認、教育委員会の全体集計、SSO、詳細な帳票を含む中規模案件は、初期300万〜1,000万円程度を推定レンジとして予算化します。自治体や複数校を横断し、住民向け問い合わせ、セキュリティ審査、移行、研修、ピーク負荷、災害時継続まで含む案件では、1,000万〜3,000万円以上になる可能性があります。これらは公開された一律相場ではなく、一般的なWeb業務システムの工数と、リサーチノートで整理した公開価格を基にした推定レンジです。

見積書では、開発費だけでなく、初期設定、要件定義、UI設計、連携、データ移行、テストサイト、負荷試験、脆弱性診断、サーバー・監視、メール配信、決済手数料、保守、制度改定、ヘルプデスク、紙や電話の代替運用を分けて記載してもらいます。5年間の総保有コストで比較すると、初期費用が安くても毎年の従量費や改修費が大きいサービスを見つけやすくなります。

委託先の選定と見積比較で確認するポイント

委託先は、機能の多さよりも、入試特有の運用を理解し、繁忙期に責任を持って支援できるかで選びます。候補を2〜4社程度に絞り、同じRFP、同じ想定出願件数、同じ連携範囲で提案と見積を依頼します。価格だけでなく、実績の規模、担当体制、テスト方法、障害時の窓口、制度改定費を同じシートで比べることが有効です。

「導入校数が多い」という説明だけでなく、自校と近い学校種・志願者規模・選抜方式の実績を確認します。公立高校なら中学校確認、高校受理、教育委員会集計、合格発表までの運用を見ます。私立中高なら説明会予約、個人出願、併願、入学金決済を見ます。大学・専門学校なら学部・方式別の設問、大学入学共通テスト関連、合否・入学手続き、入試業務の一括委託まで確認します。

候補会社の見積書で、要件定義、画面、管理機能、帳票、外部連携、決済、通知、ファイル保管、権限、テスト、移行、研修、保守が一式にまとめられている場合は、内訳を分けてもらいます。「標準対応」「設定で対応」「追加開発」「対象外」を機能ごとに示してもらうと、A社だけが高いのか、B社が多くを対象外にして安く見せているのかを判定できます。

従量費は、志願者数だけでなく、出願件数、決済件数、利用月、ファイル容量、通知数を入れて年度別に計算します。保守費には、平日日中の問い合わせだけでなく、出願締切や合否発表の夜間・休日対応が含まれるかを聞きます。障害が決済会社、クラウド基盤、システム会社のどこにあるかにかかわらず、発注者が受験生へ説明できる窓口と連絡手順を契約で決めます。

多要素認証、管理者権限の分離、操作ログ、通信・保存データの暗号化、WAFやレート制限、脆弱性診断、バックアップ、復旧試験、再委託先の管理を確認します。顔写真や証明書のダウンロード履歴、合否データの公開予約、二者確認など、漏えいと誤発表の両方を防ぐ設計が必要です。事故発生時の報告時間、調査協力、証跡の保存、本人や学校への説明分担も質問します。

受験生向けには、スマートフォンでの入力、入力途中の保存、エラー表示、決済の再試行、メール再送、コンビニでの印刷、よくある質問、電話や窓口への切り替えを確認します。受験生に不利益を生じさせないことを前提に高校入試のデジタル化を進める方針が示されているため、システムを使えない人を切り捨てる設計にしないことが重要です（出典: デジタル庁「高等学校入学者選抜事務手続のデジタル化に関するダッシュボード」、2026年）。

よくある質問（FAQ）

ここでは、願書受付システムの発注・外注を検討するときに、担当者からよく寄せられる質問へ回答します。費用だけでなく、学校種別、導入時期、運用支援、契約終了時の扱いまで確認することがポイントです。

標準的なクラウド利用なら初期0〜30万円、月額0〜5万円程度、標準パッケージや一校向けのカスタマイズなら初期100万〜300万円、年間保守30万〜100万円程度が予算取りの目安です。複数校・自治体向けや既存システム連携を含む独自開発は、300万〜1,000万円程度、さらに大規模なら1,000万〜3,000万円以上の推定レンジになります。公開価格や要件に基づく目安であり、決済手数料、制度改定、ヘルプデスクなどを含むかで変わります。

短納期、標準的な入試業務、運用負担の軽減を優先するならクラウドSaaSや教育向けパッケージが向いています。自治体独自の承認、特殊な選抜、既存基幹システムとの密な連携が必須なら、パッケージの追加開発や独自開発を検討します。どちらを選ぶ場合も、API、データ返却、制度改定、障害時の復旧、個人情報の削除条件を契約前に確認します。

学校種、志願者数、募集区分、出願期間、ピーク時の件数、関係者の役割、必要な画面・帳票・連携、決済方式、書類提出、権限、ログ、バックアップ、障害時の目標、導入希望日、研修とサポート範囲を書きます。必須機能と将来機能、既存データの移行可否、対象外の業務も明記します。候補会社には、標準対応・追加開発・対象外、初期費用・年間費用・従量費・制度改定費を分けて回答してもらうと比較しやすくなります。

既存SaaSの設定・校正・テストで1〜3か月、パッケージの追加開発を含めて3〜6か月、複数校・自治体の独自開発で6〜12か月以上を仮置きします。実際には要件定義、募集要項の確定、マスタ登録、決済・通知テスト、職員研修、受験生向けリハーサル、予備期間が必要です。入試開始日から逆算し、候補会社へ本番稼働だけでなく、テストサイト利用開始日と検収日も提案してもらいます。

まとめ

願書受付システムの発注・外注では、最安の入力フォームを探すのではなく、入試業務を安全に完了できる運用基盤を選ぶことが重要です。クラウド、パッケージ、独自開発の選択肢を、学校種、志願者数、承認フロー、既存システム連携、制度変更の頻度で比較します。

最初に17プロセスを参考に業務フローを整理し、出願完了の条件、関係者の権限、ピーク時の性能、障害時の代替手順、個人情報の保持・削除を決めます。そのうえで、初期費用・年間保守・従量費・決済費・制度改定費を分けたRFPを作り、複数社へ同じ条件で依頼します。

見積比較では、実績の近さ、テストとリハーサル、24時間対応の有無、SLA、監査ログ、バックアップ、セキュリティ審査、受験生サポート、データ返却まで確認します。料金は公開価格の例と自校の要件に基づく推定を区別し、5年間の総保有コストで判断します。要件整理から開発、運用改善まで伴走できる委託先を選ぶことが、入試本番の不安を減らします。

▼全体ガイドの記事
・願書受付システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。