入試管理システムの発注は、対象業務と責任範囲の整理、RFPと契約の合意、5年間の費用比較とテストの順に進めると、安全な入試運用につながります。
発注形態の選び方から受入テストまで、各段階で押さえる点を順に説明します。全体像は入試管理システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・入試管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
入試管理システム発注の全体像
発注では、製品を探す前に対象業務とデータのつなぎ方を決めておきます。先に決めておかないと、候補の製品を同じ基準で比べにくくなります。
対象を出願フォームだけにするか、書類確認から入学手続きまで含めるかで、設計も費用も変わります。
大学・専門学校は評価情報と判定ロジックの整理
大学や専門学校では、学部・学科と入試区分ごとに条件が分かれ、選択科目や志望順位も扱います。併願や検定料も対象になります。面接や小論文、活動実績、推薦書といった評価資料も、対象に含めます。
- 提出書類：総合型・学校推薦型選抜では、PDFや画像ファイルでの提出を受け付けます。
- 評価の流れ：評価項目ごとの確認者と、判定会議へ渡す時期。
- 判定ルール：配点や傾斜配点、加点、最低基準、補欠、繰り上げの扱い。
判定結果と変更履歴は、後から経緯を説明できるように残しておきます。
高校入試は受験生・中学校・高校・教育委員会をまたぐ流れ
高校入試では、受験生と保護者に加えて、中学校、高等学校、教育委員会が関わります。組織ごとに権限とデータの受け渡しを決めておくと、どこで誰が確認するかが分かります。
- 出願承認：出願内容の確認、承認、志願変更の対応。
- 試験準備：調査書や志願者一覧の送付、受検番号の採番、受験票の用意。
- 結果と入学：合否通知から入学許可書の発行までを、一続きにつなげます。
デジタル庁は、出願準備から入学許可書の発行までを17プロセスに整理しています。その方向は、編集・演算可能な電子データのまま完結させることです（出典：デジタル庁「令和6年度教育関連の事業成果」、2025年）。
発注範囲と自校に残す責任の切り分け
委託範囲は工程ごとに書き出し、委託先が受け持つ範囲を明記します。要件整理や設計、開発・設定は、委託先がどこまで担うかを示します。
移行、テスト、研修は、それぞれ担当の範囲を区切って書きます。監視、問い合わせ、年度更新は、受け持つ範囲を分けて書きます。障害対応も、委託先の範囲を明確にします。
- 学校が決めること：募集要項、入試制度、判定基準、合否の最終承認。
- 責任者の明記：業務、承認、データ管理、障害時の判断を、誰が担うかをRFPに書きます。
受験生への告知のように、学校側で判断すべきことを委託先に任せきりにしないよう、責任を明確にしておきます。
発注形態の選び方（SaaS・パッケージ・スクラッチ）
発注形態は、初期費用だけでなく、制度変更や年度更新への対応、障害復旧の責任まで比べて選びます。データ持ち出しやサポートの条件も、形態ごとに確かめます。
標準機能に業務を合わせられる学校は、SaaSやパッケージが候補になります。独自判定や複雑な組織間連携が競争力に直結する場合は、個別開発を検討します。
SaaS型は標準機能と運用負担の軽さを優先する学校向け
SaaS型は、事業者がクラウド環境とアプリを提供し、保守や脆弱性対応、バックアップまで含めて運用する形態です。学校が標準機能に業務を合わせられる場合は、SaaS型が候補になります。
- 導入しやすさ：自校のサーバーが不要で、Web出願や合否照会、入学手続きから始められます。
- 契約前の確認：制度変更への対応、件数課金、データの返却形式と保管期間。
障害時の連絡先も、契約の前に確かめておきます。
パッケージ型は標準機能に学校固有の設定を加えたもの
パッケージ型は、入試向けの製品を導入したうえで、学校固有の帳票や権限、判定条件などを設定します。既存システムとの連携も、必要に応じて追加で開発します。
- 柔軟性：SaaSより業務に合わせやすく、スクラッチより短い期間で始められる形態です。
- 見積の内訳：ライセンスや初期設定、追加開発と連携、移行、研修、保守を分けて示す。
標準仕様から離れるほど、カスタマイズ費用と将来の改修費が増えていきます。
スクラッチ型は独自ルールが多い場合の候補
スクラッチ型は、学校法人や教育委員会の業務に合わせて、画面やデータ構造を新しく設計します。判定ロジックや連携機能も、一から組み立てます。
- 適する要件：特殊な併願や複数法人の認証、独自評価を実装しやすい形態です。
- 主な負担：要件定義、初期費用、テスト、担当交代後の保守体制が課題になります。
納品物には、ソースコードや設計書、テスト仕様書、運用手順書を含めます。開発会社が変わっても引き継げるよう、データベースのバックアップ方法も決めておきます。
入試業務をプロセス単位で分解したRFPと要件整理
RFPは、課題と対象範囲、利用者、データの扱いを示す文書です。品質や納期、予算、提案事項も、ここに書きます。
候補会社ごとに前提がずれると見積を比べにくくなるため、同じ条件を示しておきます。そこで、現状業務と将来業務を図や一覧で示し、必須要件と提案要件を分けます。
紙・Excel・システムの受け渡しまでの現状業務
募集要項の作成から入学手続きまで、工程を順に並べます。出願、書類確認、入金照合は、受付の段階として続けて並べます。受験票と会場は、試験の準備として並べます。
採点、判定、発表は、結果を出す段階として並べます。そのうえで、工程ごとに入力者と承認者を記録し、帳票やデータ形式、締切も残しておきます。
- 転記と修正：転記の有無と、ミスが出たときの直し方。
- 高校入試：中学校、高校、教育委員会の間での承認と差戻し。
- 大学入試：入試区分ごとの評価者と判定会議を、分けて記します。
必須機能と追加提案を分けた要件
初年度に必要な機能は、必須要件にします。一方で、AIや分析ダッシュボードのような便利な機能は、優先度を分けて提案要件に置きます。
- 入試情報：募集区分、科目、日程、会場のマスタを管理します。
- 出願と試験：アカウント、Web出願、書類、決済、受験票、結果取込を含めます。
- 判定と入学：合否判定、結果通知、入学手続きに対応します。
- 安全と運用：権限、操作ログ、バックアップを備えます。
独自判定、ファイル暗号化、エラー再送、年度更新、データ出力も、導入初年度に必要かを見て優先順位を決めます。
RFPに明記する連携・セキュリティ・運用条件
教務や学籍、会計などとの接続方式を、RFPで指定します。CSVかAPIかを決め、項目名と文字コードもそろえておきます。
- 連携とデータ：暗号化、エラー再送、重複登録、年度切替を定義します。
- 管理条件：データ所有者と、契約終了時の返却形式を決めます。
- 安全対策：権限、認証、ログ、バックアップ、委託先管理を、自校の基準と照合します。
文部科学省のガイドラインは令和7年3月に改訂されました。インシデント報告も含めて、自校のポリシーと照らし合わせます（出典：文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年）。
業務の不確実性で選ぶ契約形態（請負・準委任・保守）
業務には、要件が決まっている部分と、ヒアリングしながら決める部分が混在します。そのため、要件定義は準委任、確定した開発は請負に分けます。稼働後の改善と保守は、別契約にする方法が現実的です。
契約書では、成果物と検収の方法、変更手続き、納期を定めます。瑕疵対応や知的財産も、ここで決めておきます。さらに、再委託や秘密保持、個人情報、障害時の責任も明記します。
請負契約の締結前に決める完成物と検収基準
請負契約は、定めた成果物を完成させ、発注者が検収する契約です。画面や帳票、連携、テスト仕様を確定できる開発に向いています。
検収基準は、入試区分ごとに検収ケースを具体化して書きます。「合否判定が正しいこと」のような表現では、基準として不十分です。
- 判定ケース：境界値、欠席、辞退、補欠、繰り上げのケース。
- 変更ケース：訂正と再発表を検収条件に入れます。
要件整理や継続的な改善に使いやすい準委任契約
準委任契約は、専門家が一定の業務を遂行する契約です。現行業務の調査やRFP作成支援、データ項目の整理などに適しています。プロトタイプや運用改善、保守も対象になります。
- 完成責任：成果物の完成責任や品質保証は、請負とは扱いが異なります。
- 別途合意：会議体、稼働時間、担当者、報告書、課題管理、判断期限の取り決め。
制度変更と追加要望の変更管理
入試制度や募集要項は年度ごとに変わります。そのため、発注後に新しい判定条件や帳票が必要になる場合があります。
- 変更票：内容と理由、影響する画面やデータ、テストの記録。
- 費用と日程：追加費用、納期、承認者の記録。
- 保守範囲：標準の年度更新と個別開発を分けて扱います。
変更を保守範囲と照らし合わせておくと、契約後の費用トラブルを減らせます。
入試管理システムの費用相場（発注範囲別）
費用には一律の公定価格がなく、学校種や志願者数、入試方式によって変わります。対象校や連携先、カスタマイズの量も影響します。
以下の金額は、2025〜2026年の公開価格と、教育機関向けの類似案件、業務範囲をもとにした目安です。公式統計ではなく、推定レンジを含みます。
小規模なクラウド・Web出願の初期費用の目安（30万〜50万円）
一校で標準的なWeb出願、受験票、合否照会を導入する場合の初期費用は、30万〜50万円程度が目安です。月額は2万〜10万円程度です。この数字は、小規模なクラウド型校務・Web出願の公開情報と類似案件に基づく推定です。
- 含まない範囲：採点、独自判定、複数校連携は、この目安に含まれません。
- 別請求の確認：件数課金、決済手数料、保管、窓口、設定、研修の有無。
別に請求される費用は、年間額に合算して比べます。
パッケージ導入と個別カスタマイズの推定費用（200万〜1,000万円程度）
出願や受験票、判定、入学手続きなどの機能に加え、固有の画面や連携を行う場合の推定レンジです。教育機関向け開発の公開見積の解説をもとにした、類似案件の目安です。公式の一律相場ではありません。
- 見積項目：要件定義、設定、独自開発、移行、連携ごとに内訳を示してもらう。
- 品質と運用：負荷試験やセキュリティテスト、研修、保守の範囲。
大学法人や広域導入は3,000万〜7,000万円超の推定規模
複数キャンパスや複数校、教育委員会が関わり、教務・学籍・会計・認証・データ基盤まで刷新する場合は、この規模になることがあります。災害復旧環境も対象に含む場合があります。
この金額は、公立大学化に伴う分離案件や大学の事業報告を参考にした推定で、入試機能だけの価格ではありません。
- 開発後の予算：負荷試験、専用窓口、学校向け研修、監視を含めます。
- 長期運用：障害時の代替手段と、5年間の保守費も予算化します。
導入期間の目安（標準設定3〜6か月、連携込み6〜12か月）
既存SaaSの標準設定なら3〜6か月、パッケージや複数連携を含む場合は6〜12か月が目安です。大学全体のスクラッチ刷新は、12〜24か月を見込みます。
ただし、製品公式に4〜6か月とある場合も、対象の機能と前提は限られています。本番の6〜9か月前には要件を凍結しておきます。加えて、受験生向けテストや職員研修、判定リハーサル、障害時訓練まで計画に入れます。
同じ条件で見る委託先の実力と見積比較
委託先は、同じ校種や入試方式、近い志願者規模での運用経験で比べます。知名度や導入社数だけで判断すると、自校の条件とずれることがあります。どこまでの業務を運用した経験なのかも、あわせて確かめます。
たとえば、システムディは2025年3月、大阪府教育庁で約190校・約3万5,000人の出願から合格発表までを運用した実績を公表しました。（出典：株式会社システム ディ「大阪府立学校 統合型校務支援クラウドサービス導入事例」、2025年）規模の実績と、自校の判定や連携、支援条件に合うかは、別に確かめる必要があります。その確認には、提案デモと質問が役立ちます。
大学向け・高校向け・広域向けの得意領域
提案デモでは、自校で必要な範囲を実際に再現してもらいます。
- 大学の総合型・国際出願：志望理由、推薦文、ポートフォリオの受付と評価。
- 大学の一貫運用：出願から入学手続きまでをまとめたい場合の、教務・学籍・会計との連携。
- 高校・自治体：中学校の承認、調査書、志願変更、複数校の集計。
高校や自治体では、保護者からの問い合わせへの対応も確かめておきます。
また、三菱総研DCSと大日本印刷は2025年10月、デジタル採点と合否判定支援サービスを開始しました（出典：三菱総研DCS「入試業務の『採点』『合否判定』をデジタル化するサービスを2025年10月提供開始」、2025年）。
5年間の総額で比べる見積
初期費用だけで判断すると、継続して払う費用を見落とすおそれがあります。そこで、同じ列に継続費用と一時費用を分けて書き、比べます。
- 利用と決済：ライセンスや利用料、件数課金、決済手数料をそろえる。
- 導入：設定、個別開発、連携、移行、テスト、研修を含める。
- 運用と終了：窓口、監視、保守（年度更新を含む）、制度変更、障害、データ返却を確かめる。
5年間を想定し、通常運用費と追加費用を分けると、従量課金型と買い切り型を公平に比べられます。
委託先への具体的な質問（障害・データ・制度変更）
「安全対策はありますか」という聞き方に加えて、合格発表時の同時接続数や負荷試験、監視、検知時間、復旧目標を尋ねます。
- 障害対応：代替手段と、受験生への告知支援の内容。
- 個人情報：調査書の閲覧者、管理者権限、ログの保管年数。
- 委託管理：委託先と再委託先の管理方法。
実際に、秋田県は2026年3月、合否通知のシステム障害を公表しました。その際の連絡や再発防止、別経路での結果確認も、評価の対象にします（出典：株式会社システム ディ「令和8年度秋田県公立高等学校入学者選抜1次募集の合否通知におけるシステム障害について 第2報」、2026年）。
入試シナリオで検証する受入テストと本番運用
受入テストでは、実データに近い検証データを使い、募集要項の登録から入学手続きまでを通して確かめます。画面が表示されるかだけでなく、業務の流れがつながるかを見るためです。
結果が担当者の意図どおりかを確かめます。また、実施者と承認者を分け、結果や証跡、未解決の課題、再テスト日を残しておきます。
合否判定の受入条件（境界値と二重照合）
判定結果と一緒に、使ったルールとデータの版を記録しておきます。さらに、ケースごとに独立して計算した結果と照合します。
- 得点条件：合格ライン前後、同点、欠席、未受験、配点変更、加点のケース。
- 選抜条件：併願、志望順位、補欠、繰り上げ、辞退を含める。
- 判定後：訂正時の変更者、理由、承認者、変更前後の値を残す。
ピーク負荷と停止時の代替手段の訓練
出願締切の直前や検定料の支払いが集中する時期、合格発表時、職員の同時ログインを想定して、負荷試験を行います。
- 部分障害：決済、通知、受験生画面の個別停止を試す。
- 代替手段：電話窓口、学校の掲示、認証済みの別画面。
- 再公開と告知：時間をずらした公開の手順と、案内文の事前準備。
結果画面が開かない場合にも、受験生に不利益が出ないよう、対応を事前に決めておきます。
年度更新と職員交代を前提にした運用手順
募集要項や入試区分、科目、日程は、年度ごとに更新します。会場や検定料、帳票、判定条件も更新の対象になります。
- 引き継ぎ：年度更新チェックリスト、権限申請、承認フローを残す。
- 日常運用：問い合わせの一次切り分け、バックアップ復元、障害連絡網を記す。
- 定例確認：学校と委託先の責任者による、入試年度の前後のレビュー。
定例レビューを契約に含めると、仕様変更の見落としを抑えられます。
よくある質問
発注前によく寄せられる質問に答えます。費用や期間、契約、連携、障害対応に関するものが中心です。
入試管理システムの発注はいつから始めるべきですか？
標準設定なら本番の6か月前、複数連携や独自判定がある場合は、9〜12か月以上前から始めます。
RFPや選定、契約から、要件定義、開発、登録、研修、テスト、判定リハーサルまで、それぞれに時間が必要です。
募集要項の決定時期から逆算して、遅くとも本番の6〜9か月前には主要要件を凍結しておきます。
Web出願だけを外注しても入試業務は効率化できますか？
Web出願を外注すると、紙の願書入力や検定料の消込は減らせます。ただし、出願後の転記や名簿作成が残ると、効率化の効果は限られます。
試験名簿や得点入力、判定、学籍登録が残る場合も、同じ考え方が当てはまります。段階的に導入するなら、将来の連携を考慮します。
- 先に定める項目：志願者ID、データ出力、帳票をRFPに含める。
- 将来の連携：採点、判定、入学手続きへのデータのつなぎ込み。
後からデータを使い回せる設計が必要です。
入試管理システムはSaaSとスクラッチのどちらがよいですか？
標準的な出願や受験票、合否照会、入学手続きから始める学校では、SaaSやパッケージが候補になります。
独自判定や組織間連携、特殊な評価を重視する学校は、個別開発を検討できます。スクラッチが常に優れているとは限りません。
制度変更や安全対策、年度更新、担当交代、保守の終了まで、責任を持てるかを見ます。そのうえで、標準機能と独自開発の境界を決めます。
費用を抑えながら入試管理システムを発注する方法はありますか？
初年度に必要な業務と、将来追加する業務を分けて考え、標準機能を優先します。
要件定義や個別開発、連携、テスト、保守を分けた見積を取り、複数社を同じ条件で比べます。
費用だけを削ると、年度更新や障害対応、職員研修が不足しやすくなります。判断は、5年間の総額と運用体制で行います。
まとめ
発注前には、業務範囲と見積比較の両面で判断の基準を決めておきます。年度変更や障害対応も含めて、継続して運用できるかを確かめます。
先に決める発注範囲と責任分担
まず、大学・専門学校向けか、高校・教育委員会向けかを明確にします。次に、出願から採点、判定、入学手続きまでの範囲を決めます。
SaaS、パッケージ、スクラッチは、初期費用だけでなく、制度変更やデータ返却、保守、障害対応まで比べます。
見積の比較軸（5年間の総額と運用品質）
発注条件の抜けを防ぐため、見積と運用の確認事項をそろえておきます。
- RFP：現状業務、必須機能と連携、安全対策（権限・ログ・バックアップ）、テスト、代替手段、委託先の責任を記載します。
- 見積内訳：初期費用、月額・従量費、改修、連携、研修、保守を分けて示す。
- 価格の比較：公開価格、類似案件、推定レンジを区別し、同じ条件で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を創業。