学校・教育機関向け入試管理システム開発の発注/外注/依頼/委託方法について

学校・教育機関向け入試管理システムの発注・外注は、出願フォームの制作会社を探す前に、出願から合否判定・入学手続きまでの対象業務と責任分担を決めて進めることが成功の要点です。

入試業務は、学校種別、入試方式、志願者数、利用者の権限、既存の学籍・校務・会計システムとの連携によって必要な仕組みが変わります。この記事では、発注形態の選び方、RFPと要件整理、請負・準委任などの契約形態、2026年時点の費用目安、委託先の選定と見積比較、導入後のテストや障害対応まで、発注担当者が比較検討しやすい順番で解説します。

▼全体ガイドの記事
・学校・教育機関向け入試管理システム開発の完全ガイド

学校・教育機関向け入試管理システムを発注・外注する前に全体像を整理します

発注前に最初に確認したいのは、入試管理システムを「Web出願の受付」として導入するのか、「入試業務全体の基盤」として外注するのかという範囲です。名称が同じでも、募集要項の公開、出願、検定料決済、書類確認、受験票、試験会場、採点、合否判定、合格発表、入学手続きまで含むかによって、見積もりも委託先に求める経験も大きく変わります。

出願受付を中心にする場合は、志願者のアカウント登録、志望先の選択、顔写真や調査書のアップロード、検定料の決済、受付状況の確認、受験票の発行が主な対象になります。一方で、採点結果の取込、配点や加点を踏まえた合否判定、判定会議の承認、合格発表、入学金の収納、学籍システムへの連携まで求める場合は、単なるフォーム開発ではなく、重要な業務データを扱う基幹システムとして発注します。RFPでは対象工程を「必須」「将来拡張」「対象外」に分け、対象外の業務を現場の手作業で残す場合も明記します。

私立中高、大学、専門学校、自治体の公立高校では、入試区分、提出書類、在籍中学校の確認、試験科目、合否判定、帳票が異なります。志願者・保護者は自分の出願と決済だけ、中学校は自校の生徒の確認だけ、入試担当者は担当区分だけ、教育委員会や法人本部は集計だけを閲覧できるように、権限と承認経路を分けます。発注時には利用者数だけでなく、同時接続数、学校数、入試区分数、年間の制度変更回数、問い合わせ窓口の対象者まで伝えることが、過不足のない見積もりにつながります。

発注形態はどの方法を選ぶべきですか？

発注形態は、標準クラウドやSaaSを利用する方法、パッケージに設定変更を加える方法、要件に合わせて個別開発する方法、複数の方式を組み合わせる方法に分けて考えます。最適な選択は「安い方式」ではなく、学校固有の選抜ルールと、年度更新や障害対応を誰が担うかまで含めて決まります。

標準クラウドやパッケージは、出願、決済、帳票、合否照会など、一般的な業務を短期間で使い始めやすい方式です。インフラ監視や脆弱性対応、バックアップを提供会社に任せやすく、校内に専門の保守要員が少ない学校でも運用を組み立てやすいです。導入前には、募集年度や入試区分を毎年変更できるか、志願者課金や決済手数料がいくらか、データを解約後に返却できるか、ピーク時の性能保証と障害時の連絡先が契約に書かれているかを確認します。

独自の選抜区分、複雑な判定ルール、複数キャンパスの統合、学籍・成績・会計・採点システムとの連携がある場合は、個別開発またはハイブリッド方式が候補になります。ただし、すべてをスクラッチで作ると、制度改定のたびに改修費が発生し、担当者が異動した後の保守も課題になります。出願・決済・合否照会はクラウド、学内の判定や既存データは個別開発で連携するように、標準化する部分と自校固有の部分を切り分けると、柔軟性と継続性を両立しやすくなります。

入試は本番日が動かしにくいため、全校一斉に切り替える前に、1校・1入試区分・1回の出願受付で試す方法も有効です。PoCでは、志願者登録から書類確認、決済、受験票、帳票出力までを少数のテストデータで確認し、現場が理解できるか、紙との二重入力が残らないか、問い合わせがどこに集中するかを見ます。課題を整理してから対象校や工程を広げる段階導入にすると、要件の見落としと本番直前の追加開発を減らしやすいです。

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

RFPは、開発会社へ「入試管理システムを作ってください」と依頼するだけの文書ではありません。解決したい業務課題、対象範囲、利用者、データ、品質条件、納期、予算、提案してほしい事項を同じ条件で比較するための依頼書です。現行業務を整理せずにRFPを出すと、会社ごとに前提が変わり、安い見積もりに見えても後から追加費用が膨らみます。

最初に、募集要項の作成から入学手続きまでを、志願者・保護者、在籍中学校、志願先学校、入試事務局、教育委員会などの役割別に書き出します。各工程で「誰が入力するか」「誰が確認するか」「差戻しや再提出ができるか」「確定後に誰が変更できるか」を整理します。紙の調査書や答案を残したままWeb化すると、入力、スキャン、確認、Excel転記の二重作業が残るため、紙をなくせない理由と、電子化する場合の確認者を要件に含めることが重要です。

機能要件には、入試区分・学科・日程・会場の設定、志願者登録、顔写真やPDFの提出、重複チェック、在籍校の承認、決済、受験番号の採番、受験票、得点取込、合否判定、合格発表、入学手続き、帳票、問い合わせ履歴を記載します。非機能要件には、締切直前や合格発表時の想定アクセス、復旧目標、バックアップ、監査ログ、認証、権限、脆弱性診断、サポート時間、障害時の代替運用を記載します。特に合否判定は、計算式だけでなく入力値、判定ルール、承認者、変更履歴を後から追えることを必須条件にします。

入試管理システムは、氏名、住所、顔写真、出身校、調査書、得点、評価、合否、納付情報などを扱います。文部科学省は令和7年3月に教育情報セキュリティポリシーに関するガイドラインを改訂しており、教育委員会や学校設置者は自組織のポリシーとの整合を確認する必要があります（出典: 文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年）。RFPには、保存場所、暗号化、MFAなどの認証、最小権限、管理者の職務分離、操作ログ、再委託、事故報告、データ削除・返却を明記します。

連携については、学籍・教務・会計・決済・採点・メール配信などの接続先、連携項目、CSVかAPIか、エラー時の再送方法、データの責任者を整理します。性能条件は「アクセスに強い」と書かず、志願者数、出願締切時の同時接続数、合格発表の公開時刻、帳票の一括出力件数などを候補会社へ提示します。条件が曖昧なままでは、各社が異なる前提で見積もるため、比較の精度が落ちます。

契約形態は請負と準委任をどう使い分けますか？

入試管理システムでは、要件が決まっている部分と、現場ヒアリングをしながら決める部分が混在します。そのため、要件定義から保守までを一つの契約で固定するより、工程ごとに契約の性質を合わせるほうが、変更と責任の境界を管理しやすいです。契約名だけで判断せず、成果物、作業範囲、検収、変更手続き、障害対応の条件を具体的に確認します。

準委任は、専門家が決められた業務を行うことに重きを置く契約で、現状分析、業務整理、RFP作成支援、要件定義、導入伴走、稼働後の改善などに合わせやすいです。制度や現場運用が固まりきっていない段階で、完成品と納期だけを請負契約にすると、前提変更が追加請求や納期延長につながりやすくなります。発注者側も会議への参加、資料提供、レビュー期限を守ることが必要です。

画面、帳票、連携仕様、判定ロジック、テスト条件が確定した後の開発は、成果物と検収条件を定めた請負契約にしやすいです。ただし、請負だから変更が無料になるわけではありません。入試区分の追加、帳票の増加、連携項目の変更などが起きた場合の見積再提示、承認者、納期調整のルールを変更管理票に落とし込みます。

契約書と個別契約書には、要件定義書、画面・帳票一覧、連携仕様書、テスト計画書、操作マニュアルなどの成果物を列挙します。検収は「納品した日」ではなく、受入テストの合格条件、未解決不具合の扱い、再テストの期限まで決めます。知的財産の帰属、第三者ソフトウェアのライセンス、秘密保持、個人情報の取扱い、再委託先の承認、事故発生時の報告時間、バックアップとデータ返却も、発注前に法務・情報セキュリティ担当と確認します。

特に合否発表や検定料決済の障害は、開発会社だけで解決できない場合があります。決済事業者、クラウド基盤、メール配信、学校のネットワークのどこで障害が起きたかを切り分ける連絡網と、電話窓口、一次回答の時間、代替受付、復旧後のデータ再登録方法を合意します。責任分界を曖昧にしたまま価格だけを下げると、本番時の判断が遅れます。

学校・教育機関向け入試管理システムの費用相場と見積比較のポイント

入試管理システムには、学校種別や規模を問わず適用できる公定価格はありません。初期費用だけでなく、月額・年額利用料、志願者課金、決済手数料、帳票や連携の追加費用、年度更新、保守、問い合わせ、セキュリティ診断、本番サポートまで含めた総額で比べます。以下は、2026年時点で確認できる公開価格・導入事例とリサーチノートをもとにした目安であり、個別案件の確定見積もりではありません。

単一校の出願受付を中心とした小規模なカスタムWeb出願では、株式会社コーディアが初期100万円プラス税から、保守が年50万円プラス税からという価格例を公開しています。設問、画像・PDF、帳票、管理画面、合否発表などの追加や連携で変わるため、これを入試管理全体の相場と見なしてはいけません。公開例と機能範囲から整理すると、単一校の入口は初期100万〜300万円、年間保守50万〜150万円程度と推定できますが、これは公開例をもとにした参考レンジです。

低初期費用の従量課金型では、初期費用0円、志願者1人あたり2,750円という公開例があります。この料金だけで計算すると、300人で82万5,000円、1,000人で275万円になりますが、年間利用料、決済手数料、サポート、帳票カスタムなどを含むかはサービスによって異なります。公立高校や教育委員会の広域導入では、デジタル庁のサービスカタログに初期費用3,000万円以上、5年総額の運用費1億円、導入期間6か月から1年という公開例があります（出典: デジタル庁サービスカタログ「School Engine Web出願システム」、2024年冬版）。

大規模なスクラッチ開発や複数校の統合、学籍・採点・会計連携、監査・冗長化まで含める場合は、初期1,000万〜5,000万円超、開発6〜12か月程度となる案件もあります。ただし、このレンジは入試管理だけの統計ではなく、小規模カスタム例と自治体向け公開価格からの推定です。大学法人全体の認証・学務・会計・データ基盤まで統合する場合も数千万円単位になり得るため、対象範囲を付けずに金額だけを社内共有しないことが大切です。

見積書では、要件定義・業務整理、画面と帳票、認証と権限、決済、ファイル保管、メール、既存システム連携、データ移行、インフラ、監視、負荷試験、セキュリティ診断、受入テスト、研修、本番切替を項目別に確認します。安い見積もりでも、RFPに書いた採点や合否判定が「将来対応」、繁忙期の監視が「別途」、過去データの移行が「発注者作業」になっていれば、実際の予算は変わります。

ランニングコストには、クラウド利用料、ユーザーや志願者に応じた従量料金、決済手数料、保守、問い合わせ、年度更新、制度変更対応、脆弱性対応、バックアップ、障害時の休日・夜間サポートが含まれます。3年または5年の総保有コストにして比較し、初年度だけ安い提案と、年度更新まで含めて安定する提案を同じ土俵に置きます。稼働後に学校側が行うマスタ設定や問い合わせ対応の工数も、見えない費用として見積もります。

比較表には、機能、対象校、入試区分数、志願者数、同時接続、連携先、納期、保守時間、データ所有権、セキュリティ、サポートを横並びで記載します。各社へ同じRFPを渡したうえで、標準機能、設定で対応、追加開発、対象外を分けてもらうと、単価だけでは分からない差が見えます。特に「合否判定対応」と書かれていても、判定ロジックの作成、結果の承認、訂正、ログ、帳票まで含むかを確認します。

2025年3月のシステムディの導入事例では、大阪府立学校約190校、約3万5,000人について、出願登録から合格発表までの運用を完了したと公表されています（出典: 株式会社システムディ「大阪府立学校 統合型校務支援クラウドサービス導入事例」、2025年）。このような広域運用を評価するときは、実績校数だけでなく、出願締切や合格発表のピーク、専用コールセンター、障害訓練、自治体の承認プロセスまで質問します。

委託先の選び方と発注後のリスク対策を確認します

委託先は、開発実績の多さだけでなく、入試業務を理解して要件の抜けを指摘できるか、繁忙期に責任者が対応できるか、導入後の制度変更を支援できるかで評価します。学校や教育委員会の個人情報を扱うため、営業資料だけで判断せず、実際の運用担当者、開発責任者、保守窓口と面談し、提案内容を検証します。

候補会社へは、同じ学校種別の導入先、最大の志願者数、複数校をまたぐ権限設定、出願締切時のアクセス、決済障害、合否発表、年度更新の実績を尋ねます。三菱総研DCSは、miraicompassシリーズについて2024年12月時点で全国1,950校に採用されていると公表し、2025年10月にはデジタル採点と合否判定の決定プロセスを支援するサービスの提供開始を発表しています（出典: 三菱総研DCS「入試業務の採点・合否判定をデジタル化するサービス」、2025年）。実績を聞くときは、サービスの導入校数だけでなく、自校が必要とする工程まで使われているかを確認します。

デモでは、志願者の登録だけでなく、入力不備、重複出願、書類の差戻し、決済失敗、メール不達、受験票の再発行、判定後の訂正、辞退や繰り上げ合格までを実演してもらいます。中学校が承認した後に修正できる項目、管理者が権限を誤った場合の復旧、監査ログの表示、CSV連携のエラー表示も重要です。実際の帳票を匿名化して渡し、現場担当者が日常業務の言葉で操作できるかを確認すると、導入後の教育負担を見積もりやすくなります。

入試システムは、開発完了時に動けば終わりではありません。年度切替、募集要項の変更、マスタ登録、権限設定、試験当日の得点取込、合否判定、公開前承認、合格発表、入学手続きまで、本番と同じ順番でリハーサルします。負荷試験では、出願締切前の集中、合否公開の一斉アクセス、帳票の大量出力を確認し、性能不足があった場合の増強手順を決めます。

運用設計では、学校側のデータ管理責任者、業務責任者、システム管理者、委託先の一次窓口、二次対応者を定めます。操作マニュアルや研修を用意し、教職員の異動があっても引き継げるようにします。文部科学省のガイドラインが今後改訂される可能性も踏まえ、セキュリティ要件を見直すときの費用と手順を契約や保守計画に残すことが、長期運用の安心につながります。

学校・教育機関向け入試管理システムのよくある質問（FAQ）

発注を進めると、費用の考え方、開発期間、クラウドの安全性、出願だけの導入可否について質問が出ます。ここでは、提案依頼や社内稟議で確認されやすい論点を、対象範囲と責任分担が分かるように回答します。

標準的な出願、決済、受験票、合否照会を早く始めたい場合はSaaSやパッケージが候補です。独自の判定ルール、複数校統合、既存の学籍・採点システムとの深い連携が必要な場合は個別開発やハイブリッドを検討します。方式を先に決めず、対象工程、制度変更、運用体制、5年程度の総保有コストを比較して選びます。

単一校の標準的なWeb出願であれば、要件整理、設定、テスト、研修を含めて数か月単位で進める場合があります。一方、複数校・教育委員会向けで、連携、セキュリティ審査、データ移行、本番リハーサルまで含む場合は、6か月から1年程度の導入期間を公開するサービス例があります。正確な期間は開発月数ではなく、稼働年度から逆算して、要件確定、受入テスト、研修、リハーサルの期限を置いて見積もります。

業務整理やRFP作成の支援を外部へ委託することは可能です。ただし、学校側が決めるべき対象工程、優先順位、現場の承認者、予算上限、情報セキュリティ方針まで丸ごと任せると、完成後に現場と合わないリスクがあります。現行帳票、業務フロー、過去の問い合わせ、既存システムの連携仕様を学校側で提供し、支援会社と一緒に必須要件と提案要件を確定する進め方が安全です。

クラウドか自社運用かだけで安全性は決まりません。認証、権限、暗号化、ログ、脆弱性対応、バックアップ、復旧、委託先と再委託先、データの保管・返却、障害時の連絡体制を、学校のポリシーと契約条件に照らして確認します。個人情報だけでなく調査書や得点、合否を扱うため、デモの便利さと同時に、最小権限と監査可能性、事故時の報告手順まで評価することが必要です。

まとめ

学校・教育機関向け入試管理システムを発注・外注するときは、まず出願、書類、決済、受験票、採点、合否判定、発表、入学手続きのどこまでを対象にするかを決めます。そのうえで、学校種別、志願者数、入試区分、権限、既存システムとの連携、繁忙期のアクセス、セキュリティ、運用サポートをRFPに書き、同じ条件で複数社へ提案を依頼します。

標準クラウドやパッケージは導入速度と運用負担、個別開発は独自ルールと連携、ハイブリッドは両者のバランスを見ます。要件が固まらない整理・要件定義は準委任、仕様と検収条件が確定した開発は請負、稼働後の改善や保守は別契約にする方法が現実的です。金額は初期費用だけでなく、従量料金、決済、年度更新、保守、障害時のサポートまで含む3年または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を創業。