入試管理システムの発注は、対象業務の整理、要件の確定、契約と委託先の比較、段階導入の順に進めると、現場に合う運用につながります。
対象範囲によって見積もりと委託先に求める経験が変わるため、まず範囲を決めます。要件をRFPにまとめると、各社の提案を同じ条件で比べられます。
▼全体ガイドの記事
・学校・教育機関向け入試管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
学校・教育機関向け入試管理システムの発注・外注前に整理する全体像
発注前に、Web出願の受付だけを任せるのか、入試業務全体の基盤まで任せるのかを決めておきます。対象範囲によって見積もりと委託先に求める経験が変わるため、この判断は最初に行います。
出願だけの外注と入試全体の委託の区別
名称が同じでも、募集要項の公開から入学手続きまでのどこを含めるかで、見積もりや委託先に求める経験が変わります。
そのため、対象工程を明確にし、RFPでは「必須」「将来拡張」「対象外」に分けて書きます。対象外を手作業で残す場合は、その旨も明記します。
- 出願受付：アカウント登録、志望先選択、顔写真・調査書の提出、検定料決済、受付確認、受験票発行を含みます。
- 入試業務全体：採点取込、配点や加点を踏まえた判定、判定会議の承認、合格発表、入学金収納、学籍連携まで扱います。
- 対象外の工程：現場の手作業で残す業務と、その責任分担。
採点結果の取込から学籍システム連携まで求める場合は、重要な業務データを扱う基幹システムとして発注することになります。
学校種別と利用者別の役割を示す発注条件
私立中高、大学、専門学校、自治体の公立高校では、入試の形が異なります。入試区分や提出書類、試験科目、判定方法、帳票も違います。そのため、権限と承認経路は利用者ごとに設計します。
- 志願者・保護者：自分の出願と決済を扱います。
- 在籍中学校：自校の生徒の確認を担当します。
- 入試担当者：担当する入試区分だけを閲覧します。
- 教育委員会・法人本部：集計だけを閲覧できる範囲。
利用者数のほか、同時接続数、学校数、入試区分数、年間の制度変更回数、問い合わせ窓口の対象者を伝えると、見積もりの過不足を防げます。
発注形態の選び方
発注形態は、標準クラウド・SaaS、パッケージ、個別開発、複数方式の組み合わせから検討します。安さだけでなく、学校固有の選抜ルール、年度更新、障害対応の担当も見て比べます。
導入速度と運用負担を重視する場合の標準クラウド・パッケージ
一般的な業務を短期間で始めたい学校には、標準クラウドやパッケージが候補になります。インフラ監視、脆弱性対応、バックアップも、提供会社に任せる形になります。
- 業務範囲：出願、決済、帳票、合否照会が標準機能に含まれるかどうか。
- 年度更新：募集年度や入試区分を毎年変更できるか。
- 料金とデータ：志願者課金、決済手数料、解約後のデータ返却。
- 繁忙期の支援：性能保証と障害時の連絡先が契約にあるか。
校内に専門の保守要員が少ない場合も、提供会社へ運用を委ねやすい点が利点です。
独自ルールと既存連携を重視する場合の個別開発・ハイブリッド
独自の選抜区分、複雑な判定、複数キャンパスの統合、学籍・成績・会計・採点との連携が必要なら、個別開発やハイブリッドが候補です。
すべてをスクラッチで作ると、制度改定のたびに改修費が発生します。さらに、担当者の異動後も保守を続ける体制が課題になります。
出願・決済・合否照会をクラウドにし、学内判定や既存データ連携を個別開発にする方法があります。標準化する範囲と自校固有の範囲を分けると、柔軟性と継続性を両立しやすくなります。
PoCと段階導入による本番リスクの抑制
入試の本番日は動かしにくいため、全校一斉切替の前に小さく試す方法が有効です。PoCでは、少数のテストデータで一連の業務を確かめます。
- 対象を絞る：1校、1入試区分、1回の出願受付で試します。
- 操作を確認する：登録、書類確認、決済、受験票、帳票出力を通して見ます。
- 運用を確認する：現場の理解、紙との二重入力、問い合わせの集中先。
課題を整理してから対象校や工程を広げる段階導入では、要件の見落としや本番直前の追加開発が減ります。
RFPと要件整理の進め方
RFPは、「入試管理システムを作ってください」と頼むだけの文書ではなく、業務課題などを同じ条件で比べるための依頼書です。
対象範囲、利用者、データ、品質条件を整理し、さらに納期、予算、提案事項も書き出します。現行業務の整理を後回しにすると、後から追加費用が膨らむおそれがあります。
工程・担当者・データの流れで見る現行業務
募集要項の作成から入学手続きまでを、志願者・保護者、在籍中学校、志願先学校、入試事務局、教育委員会などの役割別に書き出します。そのうえで、各工程で誰が入力・確認するか、差戻しや再提出ができるか、確定後に誰が変更できるかを整理します。
- 志願者・保護者：出願情報や書類を提出します。
- 在籍中学校・志願先学校：書類や入力内容の確認。
- 入試事務局・教育委員会：手続き、承認、集計を担います。
紙の調査書や答案を残したままWeb化すると、入力、スキャン、確認、Excel転記の二重作業が残ります。そのため、紙をなくせない理由と、電子化後の確認者も要件に含めます。
RFPでの機能要件と非機能要件の分け方
機能要件と非機能要件を分けると、各社の対応範囲を比べやすくなります。合否判定は、計算式だけでなく、入力値、判定ルール、承認者、変更履歴をたどれることを必須にします。
- 入試設定：区分、学科、日程、会場を扱います。
- 出願・選考：登録、顔写真・PDF提出、重複確認、在籍校承認まで。決済、受験番号、受験票、得点取込も含みます。
- 結果・事務：合否判定、発表、入学手続き、帳票、問い合わせ履歴。
- 品質と運用：繁忙時アクセス、復旧目標、バックアップを定めます。監査ログ、認証、権限、脆弱性診断、サポート時間、代替運用も含めます。
セキュリティ・連携・繁忙期の具体的な条件
システムは、氏名、住所、顔写真、出身校、調査書を扱います。さらに、得点、評価、合否、納付情報も扱います。
文部科学省は令和7年3月にガイドラインを改訂しました（出典：文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年）。
学校設置者は、自組織のポリシーとの整合を確認します。そのうえで、RFPではセキュリティ、連携、繁忙期の条件を具体的に示します。
- セキュリティ：保存場所、暗号化、MFAなどの認証、最小権限、職務分離、操作ログを記載します。
- 委託管理：再委託、事故報告、データの削除・返却の条件。
- 連携：学籍・教務・会計・決済・採点・メール配信の接続先と項目を整理します。CSVかAPIか、エラー時の再送、データ責任者も決めておきます。
- 性能：「アクセスに強い」ではなく、志願者数、締切時の同時接続数、合格発表時刻、帳票の一括出力件数で示します。
条件が曖昧だと各社の前提がずれ、比較精度が落ちます。
請負と準委任の使い分け
要件が決まった部分と、現場へのヒアリングで決める部分が混在するため、工程ごとに契約を合わせると、変更と責任の境界を管理しやすくなります。
契約名だけで判断せず、成果物、作業範囲、検収、変更手続き、障害対応の条件を具体的に確認します。
要件定義・改善は準委任、確定後の開発は請負という考え方
現状分析、業務整理、RFP作成支援、要件定義、導入伴走、稼働後の改善は、準委任と合わせやすい作業です。準委任は、専門家が決められた業務を行うことを重視する契約です。
- 要件が未確定の段階：請負では前提変更が追加請求や納期延長につながりやすくなります。
- 発注者の対応：会議参加、資料提供、レビュー期限の順守が必要です。
- 仕様確定後の開発：画面、帳票、連携仕様、判定ロジック、テスト条件を固め、成果物と検収条件を定めて請負にします。
- 変更管理：請負でも変更は無料ではありません。入試区分、帳票、連携項目の追加では、見積の再提示、承認者、納期調整を変更管理票に記します。
契約書に入れる検収・個人情報・再委託・障害時の責任
契約書や個別契約書には、成果物と検収条件を列挙します。納品日だけでなく、受入テストの合格条件、未解決不具合の扱い、再テストの期限も決めます。
- 成果物：要件定義書、画面・帳票一覧、連携仕様書、テスト計画書、操作マニュアルを定めます。
- 権利と情報：知的財産、第三者ソフトのライセンス、秘密保持、個人情報の扱い。
- 委託と事故：再委託先の承認、事故報告時間、バックアップ、データ返却を決めます。
法務・情報セキュリティ担当は、契約条件を発注前に確認します。
合否発表や検定料決済の障害は、開発会社だけで解決できない場合があります。そのため、クラウド基盤、決済事業者、メール配信、学校ネットワークの切り分け連絡網を合意しておきます。
電話窓口、一次回答時間、代替受付、復旧後の再登録方法も決めます。どこまでを誰が受け持つかが曖昧なまま価格を下げると、本番時の判断が遅れます。
学校・教育機関向け入試管理システムの費用相場と見積比較のポイント
入試管理システムに、学校種別や規模を問わず使える公定価格はありません。ここで示すのは、2026年時点の公開価格、導入事例、リサーチノートをもとにした目安で、個別案件の確定見積もりではありません。
比較では、初期費用に加えて、利用料、志願者課金、決済手数料を見ます。さらに、追加機能、年度更新、保守、問い合わせ、診断、本番支援も含めた総額で比べます。
公開価格から見る小規模・クラウド・広域導入のレンジ
公開価格と対象範囲を分けて比べると、参考となる費用幅が見えます。
- 単一校のカスタムWeb出願：入口の参考レンジは初期100万〜300万円、年間保守50万〜150万円程度です。
- 従量課金型：初期費用0円、志願者1人あたり2,750円の公開例があります。
- 広域導入：公開例では初期3,000万円以上、5年運用費1億円、導入期間6か月から1年です。
- 大規模な個別開発：初期1,000万〜5,000万円超、開発6〜12か月程度となる案件もあります。
コーディアは初期100万円プラス税から、保守は年50万円プラス税からの価格例を公開しています。金額は、設問、画像・PDF、帳票の範囲で変わります。さらに、管理画面、合否発表、連携の追加でも変わります。
志願者1人あたり2,750円を当てはめると、300人で82万5,000円、1,000人で275万円になります。ただし、利用料、決済手数料、サポート、帳票カスタムの扱いはサービスごとに異なります。
広域導入の価格例は、デジタル庁サービスカタログに掲載されたものです（出典: デジタル庁サービスカタログ「School Engine Web出願システム」、2024年冬版）。
大規模開発のレンジは、入試管理だけを対象にした統計ではなく、小規模カスタム例と自治体向け公開価格からの推定です。
大学法人全体の認証、学務、会計、データ基盤まで統合する場合も数千万円単位になり得ます。対象範囲を添えずに金額だけを社内共有しないことが大切です。
初期費用・連携費用・保守費用の分け方
見積項目を分けると、発注後に増える費用を見つけやすくなります。要件定義から本番切替まで、作業の抜けを確かめます。
- 開発準備：要件定義・業務整理、画面・帳票、認証・権限の見積項目。
- 機能と連携：決済、ファイル保管、メール、既存連携、データ移行の見積項目。
- 品質と導入：インフラ、監視、負荷試験、セキュリティ診断の見積項目です。受入テスト、研修、本番切替も含みます。
採点や合否判定が「将来対応」、繁忙期監視が「別途」、過去データ移行が「発注者作業」なら、見積額と実予算が変わります。
ランニング費用には、クラウド、従量料金、決済手数料、保守、問い合わせが含まれます。さらに、年度更新、制度変更、脆弱性対応、バックアップの費用も入ります。休日・夜間の障害サポートの有無も確認します。
3年または5年の総保有コストで比べます。学校側のマスタ設定や問い合わせ対応の工数も、見えにくい費用として見積もります。
金額より前提条件と除外項目を見る見積比較
各社へ同じRFPを渡し、機能や運用条件を横並びにします。「合否判定対応」の範囲も、判定、承認、訂正、ログ、帳票まで確認します。
- 規模と機能：対象校、入試区分数、志願者数、同時接続、連携先を比較します。
- 運用条件：納期、保守時間、データ所有権、セキュリティ、サポート。
- 対応区分：標準機能、設定対応、追加開発、対象外を分けてもらいます。
2025年3月の事例では、大阪府立学校約190校、約3万5,000人の出願登録から合格発表までの運用を完了しました（出典：株式会社システムディ「大阪府立学校 統合型校務支援クラウドサービス導入事例」、2025年）。
広域運用の実績は、校数だけでなく、締切・発表のピーク、専用コールセンター、障害訓練、自治体の承認プロセスまで尋ねます。
委託先の選び方と発注後のリスク対策
委託先は開発実績だけでなく、業務理解、繁忙期の対応、制度変更の支援力で評価します。運用、開発、保守の担当者と面談し、提案内容を確かめます。
学校種別・規模・工程が自校に近い実績
候補会社には、自校に近い学校種別や規模での運用経験を尋ねます。繁忙期と年度更新を含め、必要な工程の実績を確認します。
- 導入環境：導入先の学校種別、最大志願者数、複数校の権限設定。
- 繁忙期対応：締切時アクセス、決済障害、合否発表の運用。
- 継続運用：年度更新と、自校が必要とする工程での利用状況を確かめます。
三菱総研DCSは、miraicompassシリーズが2024年12月時点で全国1,950校に採用されたと公表しています。
2025年10月には、採点と合否判定の決定プロセスを支援するサービスの提供開始も発表しました（出典: 三菱総研DCS「入試業務の採点・合否判定をデジタル化するサービス」、2025年）。導入校数だけでなく、自校が必要とする工程まで利用されているかも確認します。
デモとPoCで試す例外処理
デモでは通常の登録に加え、例外処理を実演してもらいます。帳票は匿名化して渡し、現場の言葉で操作できるかも確かめます。
- 出願と書類：入力不備、重複出願、差戻し、受験票の再発行を試します。
- 決済と通知：決済失敗やメール不達時の対応。
- 判定と権限：判定後の訂正、辞退、繰り上げ合格、権限誤りからの復旧を試します。
- 記録と連携：監査ログとCSV連携エラーの表示。
また、中学校の承認後に修正できる項目も確認します。操作性の検証は、導入後の教育負担を見積もる材料になります。
本番リハーサルと運用体制の発注条件
開発完了後は、本番と同じ順番でリハーサルします。年度切替から入学手続きまでの業務を通して確認します。
- 年度準備：募集要項変更、マスタ登録、権限設定を行います。
- 選考と発表：得点取込、合否判定、公開前承認、合格発表。
- 負荷試験：締切前の集中、発表時の一斉アクセス、帳票の大量出力を試します。
性能不足が見つかった場合の増強手順も決めます。運用では、学校側のデータ管理責任者、業務責任者、システム管理者を定めます。
委託先の一次窓口と二次対応者も決め、マニュアルや研修を用意します。教職員が異動しても引き継げる体制が必要です。
文部科学省のガイドライン改訂も考慮し、セキュリティ要件を見直す費用と手順を契約や保守計画に残します。
学校・教育機関向け入試管理システムのよくある質問（FAQ）
発注では費用、開発期間、クラウドの安全性、出願だけの導入可否が論点になります。提案依頼や社内稟議で確認される内容をまとめます。
学校の入試管理システムはSaaSと個別開発のどちらがよいですか？
標準的な出願、決済、受験票、合否照会を早く始めるなら、SaaSやパッケージが候補です。独自判定、複数校統合、深い既存連携には、個別開発やハイブリッドを検討します。
対象工程、制度変更、運用体制、5年程度の総保有コストを比べて選びます。
入試管理システムの発注から稼働までにどのくらいかかりますか？
単一校の標準的なWeb出願は、要件整理、設定、テスト、研修を含めて数か月単位で進める場合があります。
複数校や教育委員会向けでは、連携、セキュリティ審査、移行、リハーサルを含め、6か月から1年程度とする公開例があります。
稼働年度から逆算し、要件確定、受入テスト、研修、リハーサルの期限を置いて見積もります。
RFPが作れない場合は開発会社に任せてもよいですか？
業務整理やRFP作成支援は外部へ委託できます。ただし、対象工程、優先順位、承認者、予算上限、情報セキュリティ方針まで任せると、完成後に現場と合わないおそれがあります。
現行帳票、業務フロー、過去の問い合わせ、既存システムの連携仕様は学校側が用意し、支援会社と必須要件や提案要件を固める進め方が安全です。
クラウド型の入試管理システムは安全に利用できますか？
クラウドか自社運用かだけでは、安全性は決まりません。学校のポリシーと契約条件に照らして、認証、権限、暗号化、ログを確認します。さらに、脆弱性対応、バックアップ、復旧も見ます。
委託先と再委託先、データ保管・返却、障害時の連絡体制も確認します。調査書、得点、合否を扱うため、最小権限、監査可能性、事故報告手順まで評価します。
まとめ
発注時は、出願、書類、決済、受験票の範囲を決めます。さらに、採点、合否判定、発表、入学手続きまでの対象も決めておきます。
RFPには、学校種別、志願者数、入試区分、権限、既存連携を記します。繁忙期、セキュリティ、運用支援も書いたうえで、同じ条件で複数社へ依頼します。
工程ごとに分けて比べる発注形態・契約・費用
標準クラウドやパッケージは導入速度と運用負担、個別開発は独自ルールと連携、ハイブリッドは両者のバランスを見ます。
要件整理は準委任、仕様と検収条件が確定した開発は請負、稼働後の改善や保守は別契約にする方法があります。
費用は初期額だけでなく、従量料金、決済、年度更新、保守、障害支援を含む3年または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を創業。