入試管理システム開発の発注/外注/依頼/委託方法について

入試管理システムの発注・外注は、Web出願だけでなく、採点・合否判定・入学手続きまでの業務範囲と責任分担を先に決めてから、RFPと見積条件をそろえて進めることが成功の近道です。

入試業務は学校種、入試方式、志願者数、既存の教務・学籍・会計システムによって必要な仕組みが大きく変わります。この記事では、入試管理システムを発注・外注するときの形態選び、要件整理とRFP、契約形態、2026年時点の費用目安、委託先の選定と見積比較、テストや障害時の確認項目まで、発注担当者が社内で説明しやすい順番で解説します。

▼全体ガイドの記事
・入試管理システム開発の完全ガイド

入試管理システムを発注・外注する前に全体像を整理します

入試管理システムの発注で最初に行うことは、製品名を探すことではなく、どの業務をどのデータでつなぐかを決めることです。出願フォームだけを外注するのか、書類確認、試験準備、採点、合否判定、合格発表、入学手続きまでを含めるのかで、必要な設計と費用は大きく変わります。

大学や専門学校では、学部・学科、入試区分、選択科目、志望順位、併願、検定料、面接、小論文、活動実績、推薦書などを扱います。総合型選抜や学校推薦型選抜では、PDFや画像ファイルを受け付けるだけでなく、誰がどの評価項目を確認し、いつ判定会議へ渡すのかまで設計する必要があります。合否判定では配点、傾斜配点、加点、最低基準、補欠、繰り上げなどを扱うため、判定結果と変更履歴を後から説明できることが重要です。

高校入試では、受験生や保護者だけでなく、中学校、高等学校、教育委員会が関係します。出願内容の確認、出願承認、調査書や志願者一覧の送付、志願変更、受検番号の採番、受験票、合否通知、入学許可書まで、複数の組織の権限とデータ受け渡しを考えなければなりません。デジタル庁は出願準備から入学許可書発行までを17プロセスに整理し、編集・演算可能な電子データのまま完結させる方向を示しています（出典: デジタル庁「令和6年度教育関連の事業成果」、2025年）。

委託先へ任せる範囲は、要件整理、画面・帳票の設計、開発または設定、データ移行、テスト、研修、運用監視、問い合わせ対応、年度更新、障害対応に分けて記載します。一方、募集要項の最終承認、入試制度や判定基準の決定、合否の承認、受験生への告知など、学校側が担うべき判断まで「システム会社に任せる」と曖昧にしてはいけません。RFPには業務責任者、承認者、データ管理者、障害時の判断者を明記します。

発注形態はSaaS・パッケージ・スクラッチから選びます

発注形態は、初期費用だけでなく、制度変更への追従、年度更新、データの持ち出し、サポート体制、障害時の復旧責任を含めて比較します。標準機能に業務を合わせられる学校はSaaSやパッケージが候補になり、独自の判定や複雑な組織間連携が競争力に直結する場合は個別開発を検討します。

SaaS型は、事業者がクラウド環境、アプリケーションの保守、脆弱性対応、バックアップなどをまとめて提供する形態です。自校でサーバーを用意する必要がなく、標準化されたWeb出願、合否照会、入学手続きから導入しやすい点が利点です。制度変更への対応がサービス料金に含まれるか、出願件数や利用校数による従量課金、契約終了時のデータ返却形式、保管期間、障害時の連絡先を契約前に確認します。

パッケージ型は、入試業務でよく使う機能を持つ製品を導入し、学校固有の帳票、権限、判定条件、既存システム連携を設定または追加開発する形態です。SaaSより柔軟に業務へ合わせやすく、スクラッチより短期間で始めやすい一方、製品の標準仕様から外れるほどカスタマイズ費と将来の改修費が増えます。見積書では、本体ライセンス、初期設定、追加開発、連携、移行、研修、保守を分けて提示してもらいます。

スクラッチ型は、学校法人や教育委員会の業務に合わせて画面、データ構造、判定ロジック、連携機能を新しく設計する方法です。特殊な併願ルール、複数法人をまたぐ認証、独自の評価基準などを実装しやすい反面、要件定義の難しさ、初期費用、テスト量、担当者交代後の保守体制が課題になります。完成時のソースコード、設計書、テスト仕様書、運用手順書、データベースのバックアップ方法を納品物として定義し、開発会社が変わっても引き継げる状態にします。

RFPと要件整理は入試業務をプロセス単位で分解します

RFPは、開発会社へ「入試管理システムを作ってください」と依頼する文書ではなく、解決したい業務課題、対象範囲、利用者、データ、品質条件、納期、予算、提案してほしい事項を同じ条件で比較するための文書です。候補会社が独自の前提で見積もらないように、現状業務と将来業務を図や一覧で示し、必須要件と提案要件を分けます。

まず、募集要項の作成、出願受付、書類確認、検定料の入金照合、受験票、会場、採点、合否判定、合格発表、入学手続きを業務フローに並べます。各工程について、入力者、承認者、使っている帳票、データの形式、締切、転記の有無、ミスが起きた場合の修正方法を記録します。高校入試なら中学校と高校、教育委員会の間の承認と差戻し、大学入試なら入試区分ごとの評価者と判定会議を別々に描くと、要件の抜けを見つけやすくなります。

必須機能には、募集区分・科目・日程・会場などのマスタ管理、志願者アカウント、Web出願、書類受付、検定料決済、受験票発行、試験結果取込、合否判定、結果通知、入学手続き、権限、操作ログ、バックアップを含めます。追加提案には、AIや分析ダッシュボードなどの便利な機能を置く前に、まず独自判定、ファイルの暗号化、エラー再送、年度更新、データ出力など、導入初年度に必要な機能を優先します。

既存の教務、学籍、会計、本人認証、決済、校務支援システムと、CSVで連携するのかAPIで連携するのかを指定します。項目名、文字コード、ファイルの暗号化、エラー時の再送、重複登録の扱い、年度切替、データの所有者と返却形式も必要です。文部科学省の「教育情報セキュリティポリシーに関するガイドライン」は令和7年3月に改訂されているため、アクセス権限、認証、暗号化、ログ、バックアップ、委託先管理、インシデント報告を自校のポリシーと照合します（出典: 文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年）。

契約形態は請負・準委任・保守を業務の不確実性で選びます

入試管理システムでは、要件が決まっている部分と、現場ヒアリングをしながら決める部分が混在します。そのため、すべてを一つの契約形態に押し込めるより、要件定義は準委任、確定した開発は請負、稼働後の改善と保守は別契約に分ける方法が現実的です。契約書には、成果物、検収条件、変更手続き、納期、瑕疵対応、知的財産、再委託、秘密保持、個人情報、障害時の責任を記載します。

請負契約は、定めた成果物を完成させ、発注者が検収する前提で進める契約です。確定した画面、帳票、連携、テスト仕様、納品物があり、受入条件を文章にできる開発に向いています。入試案件で「合否判定が正しいこと」とだけ書くのではなく、入試区分ごとのテストケース、境界値、欠席、辞退、補欠、繰り上げ、訂正、再発表のケースを検収条件に落とし込みます。

準委任契約は、専門家が一定の業務を遂行することを目的とする契約です。現行業務の調査、RFP作成支援、データ項目整理、プロトタイプ、運用改善、保守のように、作業内容を進めながら具体化する場面に適しています。一方で、成果物の完成責任や品質保証が請負と同じになるわけではないため、会議体、稼働時間、担当者、報告書、課題管理、判断期限を別途合意します。

入試制度や募集要項は年度ごとに変わるため、発注後に新しい判定条件や帳票が出る可能性があります。変更要求は、内容、理由、影響する画面・データ・テスト、追加費用、納期、承認者を一枚の変更票で管理します。標準の年度更新に含まれる変更と、学校固有の追加開発を区別しておくと、保守契約後の費用トラブルを減らせます。

入試管理システムの費用相場を発注範囲別に確認します

入試管理システムには一律の公定価格がなく、学校種、志願者数、入試方式、対象校数、連携先、カスタマイズ量で価格が変わります。以下の金額は、2025〜2026年に確認できる公開価格、教育機関向け類似案件、入試業務の範囲から整理した目安です。入試管理システム全体の公式統計ではない推定レンジを含むため、予算の確定ではなく、RFPの比較軸として使います。

一校単位で標準的なWeb出願、受験票、合否照会などを導入する場合は、初期30万〜50万円程度、月額2万〜10万円程度が一つの目安です。これは小規模なクラウド型校務・Web出願に関する公開情報と類似案件からの推定であり、採点、独自の合否判定、複数校連携を含む金額ではありません。出願件数課金、決済手数料、ファイル保管、コールセンター、初期設定、研修が別請求になる場合があるため、年間費用に合算して比較します。

出願、書類受付、受験票、帳票、試験結果取込、合否判定、入学手続きに加えて、学校固有の画面や既存システム連携を行う場合は、初期200万〜1,000万円程度を推定レンジとして置くケースがあります。教育機関向けシステム開発の公開見積解説を基にした類似案件の目安で、入試管理システムの公式一律相場ではありません。要件定義、マスタ・帳票設定、独自開発、データ移行、連携、負荷・セキュリティテスト、研修・保守を項目別に分けて、どこまで含むかを確認します。

複数キャンパス、複数校、教育委員会、教務・学籍・会計・認証・データ基盤・災害復旧環境まで含む統合型刷新では、3,000万〜7,000万円超の規模になる場合があります。公立大学化に伴う学務システム分離などの類似案件や大学の事業報告を参考にした推定であり、入試機能だけの価格ではありません。大規模導入では、開発費だけでなくピーク負荷試験、専用窓口、学校向け研修、監視、障害時の代替手段、5年間の保守費まで予算化します。

既存SaaSの標準設定なら3〜6か月、パッケージ導入と複数の連携なら6〜12か月、大学全体のスクラッチ刷新なら12〜24か月を目安に計画します。製品公式の導入案内で4〜6か月と示されるサービスもありますが、これは対象機能と前提条件が限定された導入期間です。入試年度に間に合わせるには、本番の6〜9か月前に要件を凍結し、受験生向けテスト、職員研修、判定リハーサル、障害時訓練まで終える計画が必要です。

委託先の選定と見積比較では同じ条件で実力を見ます

委託先は、知名度や導入社数だけで決めず、自校と同じ校種、同じ入試方式、近い志願者規模で、どこまでの業務を運用した経験があるかで見ます。2025年3月にシステムディは大阪府教育庁で約190校・約3万5,000人の出願登録から合格発表までを運用した実績を公表しています（出典: 株式会社システム ディ「大阪府立学校 統合型校務支援クラウドサービス導入事例」、2025年）。このような規模の実績は参考になりますが、実績があることと、自校の判定・連携・支援条件に適合することは別なので、提案デモと質問で確かめます。

大学の総合型・国際出願なら、志望理由、推薦文、ポートフォリオなどの受付と評価ワークフローに実績があるかを見ます。大学入試の出願から合否照会、入学手続きまでをまとめたい場合は、教務・学籍・会計との連携と入学後のデータ受け渡しを確認します。高校や自治体では、中学校の承認、調査書、志願変更、複数校の集計、保護者の問い合わせ対応に強いかを見ます。2025年10月には、三菱総研DCSと大日本印刷がデジタル採点と合否判定支援の新サービスを提供開始しており、出願から採点・合否判定までをつなぐ動きが進んでいます（出典: 三菱総研DCS「入試業務の『採点』『合否判定』をデジタル化するサービスを2025年10月提供開始」、2025年）。必要範囲をデモで再現してもらいます。

見積比較では、初期費用の合計だけを並べると判断を誤ります。ライセンスまたは利用料、出願件数課金、決済手数料、初期設定、個別開発、連携、データ移行、テスト、研修、問い合わせ窓口、監視、年度更新、保守、制度変更、障害対応、契約終了時のデータ返却を同じ列でそろえます。5年間の利用を想定し、通常運用費と一時的な追加費用を分けると、安く見える従量課金型と高く見える買い切り型を公平に比較できます。

質問は「セキュリティ対策はありますか」だけで終えず、合格発表時刻にアクセスが集中した場合の同時接続数、負荷試験の方法、監視と検知の時間、復旧目標、代替手段、受験生への告知支援を聞きます。個人情報や調査書を誰が閲覧できるか、管理者権限をどう分けるか、操作ログを何年保管するか、委託先や再委託先をどう管理するかも確認します。2026年3月には秋田県の合否通知でシステム障害が公表されているため、機能表だけでなく、障害時の連絡・再発防止・別経路での結果確認まで評価項目にします（出典: 株式会社システム ディ「令和8年度秋田県公立高等学校入学者選抜1次募集の合否通知におけるシステム障害について 第2報」、2026年）。

発注後は受入テストと本番運用を入試シナリオで検証します

入試システムは、納品日に画面が表示されれば終わりではありません。募集要項の登録から出願、書類確認、決済、受験票、試験結果、合否承認、発表、入学手続きまでを実データに近い検証データで通し、担当者が意図した結果になることを確認します。テストの実施者と承認者を分け、結果、証跡、未解決課題、再テスト日を残します。

合否判定のテストでは、合格ラインの前後、同点、科目欠席、未受験、配点変更、加点、併願、志望順位、補欠、繰り上げ、辞退、判定後の訂正を用意します。プログラムの結果だけに依存せず、別の担当者が独立して計算した結果と照合し、判定ルールとデータの版を記録します。判定会議で変更があったときは、変更者、変更理由、承認者、変更前後の値を残せることが必要です。

出願締切直前、検定料の支払集中、合格発表の開始時刻、学校職員の同時ログインを想定して負荷試験を行います。決済だけ失敗した場合、通知だけ遅れた場合、学校側は使えるが受験生側が使えない場合など、部分障害も試します。結果画面が開かないときに、電話窓口、学校掲示、別の認証済み画面、時間をずらした再公開など、受験生に不利益が出ない代替手段と告知文を事前に決めます。

導入後は、募集要項、入試区分、科目、日程、会場、検定料、帳票、判定条件を年度ごとに更新します。担当者が異動しても作業できるように、年度更新チェックリスト、権限申請、承認フロー、問い合わせの一次切り分け、バックアップ復元、障害連絡網を手順書にします。学校側の運用責任者と委託先のサポート責任者が、入試年度の前後に定例レビューを行う契約にすると、仕様変更の見落としを抑えられます。

よくある質問

入試管理システムの発注では、費用、期間、契約、既存システムとの連携、障害対応について同じ疑問が出やすいです。ここでは、発注前に特に確認したい質問へ直接回答します。

標準設定だけなら本番の6か月前、複数の連携や独自判定がある場合は9〜12か月以上前から始めることを勧めます。RFP作成、候補会社の選定、契約、要件定義、開発、データ登録、研修、受入テスト、判定リハーサルに時間が必要です。新年度の募集要項が決まる時期から逆算し、遅くとも本番の6〜9か月前には主要要件を凍結します。

紙の願書入力や検定料の消込を減らす効果はありますが、出願後にExcelへの転記、試験名簿の作成、得点入力、合否判定、学籍登録が残ると効率化は限定的です。出願だけを第一段階にする場合でも、志願者ID、データ出力、帳票、将来の採点・判定・入学手続きとの連携方法をRFPに含め、後からデータを使い捨てにしない設計にします。

標準的な出願、受験票、合否照会、入学手続きから始める学校はSaaSやパッケージが検討しやすく、独自の判定、組織間連携、特殊な評価を重視する学校は個別開発が候補になります。ただし、スクラッチが常に優れているわけではありません。制度変更、セキュリティ、年度更新、担当者交代、保守終了まで自校と委託先が長期に責任を持てるかを基準に、標準機能と独自開発の境界を決めます。

まず、初年度に必要な業務と将来追加する業務を分け、標準機能を優先します。次に、要件定義・個別開発・連携・テスト・保守を分離した見積を取り、複数社を同じ条件で比較します。費用だけを削ると、年度更新や障害対応、職員研修が不足しやすいため、5年間の総額と受験生に不利益を出さない運用体制まで含めて判断します。

まとめ

最後に、発注前に押さえるべき判断基準を、業務範囲と見積比較の二つに整理します。入試年度の変更や障害時の対応まで含め、価格だけでなく継続運用できるかを確認します。

入試管理システムの発注・外注では、最初に大学・専門学校向けか、高校・教育委員会向けかを明確にし、出願から採点、合否判定、入学手続きまでの対象範囲を決めます。そのうえで、SaaS、パッケージ、スクラッチの違いを、初期費用だけでなく制度変更、データ返却、保守、障害対応まで含めて比較します。

RFPには現状業務、必須機能、データ連携、権限、ログ、バックアップ、受入テスト、代替手段、委託先の責任範囲を記載します。見積は初期費用、月額・従量費、カスタマイズ、連携、研修、保守を分け、公開価格・類似案件・推定レンジの違いを理解したうえで、同じ条件の複数社を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を創業。