オンライン試験システムの発注は、試験の用途と規模を決め、要件をRFPにまとめ、同じ条件で委託先を比べる順に進めます。
この順で進めると、各社が同じ前提で提案と見積もりを出せるため、公平な運営につながります。
▼全体ガイドの記事
・オンライン試験システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オンライン試験システムの発注で最初に決めること
発注時は、製品名や画面デザインより先に、試験の種類と必要な運営水準を決めます。研修の理解度確認と国家資格とでは、必要な機能や費用が異なるためです。
試験の用途と失敗時の影響
試験の用途によって、必要な機能と運営水準は異なります。想定する事態の幅も用途で変わり、資格試験や入試は、採用試験や社内研修より幅が広いため、確認の範囲も広くなります。
- 採用試験・社内研修：受験者登録、制限時間、自動採点、合否通知、受験履歴が整えば始められる場合があります。
- 資格試験・入試：なりすまし、問題漏えい、生成AI・外部資料の利用、通信断、端末差、採点訂正も想定します。
試験停止が受験機会や合否の公平性に影響する場合は、停止時の扱いも条件に含めます。SLAや振替ルールに加えて、監視体制と問い合わせ窓口も決めておきます。
用途・規模・厳格性の3軸による候補の絞り込み
候補を比べるときは、用途・規模・厳格性をそろえて見ます。そうすると、価格だけに偏らずに選べます。用途では試験の目的を、規模では受験者数を、厳格性では監視や本人確認の段階を見比べます。
- 用途：研修・社内テスト、採用・昇格、資格・入試の区分。
- 規模：数十人、数百人、数千人から数万人までの区分。
- 厳格性：監視なし、環境確認・本人確認、AI監視・人手レビュー、会場監督までの段階。
たとえば、数十人の社内試験に大規模CBTを採用すると過剰投資になります。逆に、重要試験を簡易なアンケートで代用すると、公平性を損ないます。
オンライン試験システムの発注形態の選び方
短期間で標準的な試験を始めるなら、クラウド型が候補になります。既存業務との統合や厳格な運用を重視するなら、専用環境・パッケージ型が候補です。
独自の採点や受験体験が競争力になる場合は、スクラッチ型を検討します。ただし、すべてを新規開発する必要はありません。
たとえば、問題配信や採点エンジンは既存サービスを使い、会員管理や業務フローなど必要な部分だけを連携・開発する方法もあります。
クラウド・SaaS型：小規模な検証と早期導入の場合
クラウド型は、サーバーの調達や基本的なアップデートを自社で抱えずに済みます。そのため、数十人から数百人の社内試験を比較的短期間で始められます。標準機能を使えるので、初回は設定と問題データ登録に集中できます。
- 標準機能：受験者管理、問題登録、自動採点、合否判定、結果出力を使えます。
- 同時利用：同時アクセス数と、動画・音声への対応。
- データ・支援：外部認証、データのエクスポート、保存期間、退会後の削除、問い合わせ対応が料金に含まれるかどうか。
パッケージ・専用環境型：統制と連携を重視する案件
パッケージ型や専用クラウドは、自社のセキュリティ方針やデータ保管要件に反映しやすい方式です。その分、初期設定から負荷試験までの費用も見込んでおく必要があります。
- 連携対象：問題バンク、受験者DB、SSO、LMS、人事・会員システム、決済などの組み合わせ。
- 付帯機能：監視ログや資格証発行などの要件。
- 運用責任：オンプレミスの場合、OSやミドルウェアの更新、脆弱性対応、バックアップ、障害復旧の担当。
導入費だけでなく、5年程度のTCOで比較します。運用の担当が決まっていないと、この比較の前提がそろいません。
スクラッチ開発の採用条件
独自の出題アルゴリズム、記述・動画・音声の評価、複雑な受験資格が必要な場合は、スクラッチ開発を検討します。加えて、高度な既存データ連携や監査用の詳細ログが必要な場合も、検討の対象になります。
- 独自要件：標準機能で代替できない部分の特定。
- 継続運用：問題改訂、再採点、本人確認の誤判定、ブラウザ更新、障害時の振替を扱う体制。
- 保守費：ブラウザ更新や障害時の振替を含む将来費用を一覧にします。
開発会社にすべてを任せる場合も、標準機能で代替する部分と独自開発する部分をRFPで分けておきます。そうすると、各社の見積もりを同じ基準で比べられます。
発注前の要件整理の進め方
要件整理では、機能一覧を作る前に、試験業務の現状と本番のリスクを洗い出します。次に、申込から結果通知までの流れを追い、工程ごとの判断やデータの受け渡しを確認します。そのうえで、要件を必須、できれば欲しい、将来検討に分けると、見積もりの前提がぶれにくくなります。
申込から合否通知までの業務フローの洗い出し
通常業務と例外対応を、一連の流れとして並べます。工程を洗い出しておくと、システム化する範囲と運用ルールを決められます。
- 申込前後：募集、申込、本人確認、受験資格審査、受験料決済、受験票発行。
- 受験・判定：端末確認、受験、採点、再採点、合否判定、結果通知。
- 試験後：問い合わせ、合格証発行、団体申込、免除科目などの例外処理。
再受験、欠席、受験料返金も、例外として記録します。また、Excelやメールの作業を新しいシステムへ移す際は、重複入力や承認漏れを防ぐルールも一緒に定めます。
問題・採点・受験環境の要件の具体化
問題形式、採点方法、受験環境は、それぞれ分けて定義します。担当者や委託先が判断できるよう、具体的に書いておきます。
- 問題：単一・複数選択、記述・画像・動画・音声、配点、分野別出題数、シャッフル、出題期間、改訂履歴、公開範囲。
- 採点：自動・人手の境界、部分点、合格基準、再採点、結果の確定者。
- 受験環境：対応OS・ブラウザ、スマートフォン可否、カメラ・マイク、通信速度、途中保存、再接続。
加えて、試験中の問い合わせ方法も要件として書き添えます。参考になる資料には、大学入試センターが2025年に公開した「CBT導入時の検討事項リスト」があります。
不正対策・個人情報・障害対応の要件
本人確認書類や顔画像は、受験者の個人に関する情報として扱う必要があります。さらに、カメラ映像や音声、監視ログも、個人に関する情報として扱う対象になります。
個人情報保護委員会のガイドライン（2026年改正）は、映像情報や音声録音情報が個人情報に該当する事例を示しています。
- 取扱条件：利用目的、取得時の説明、委託先の範囲、アクセス権限の決定。
- 保護方法：暗号化、保存期間、削除方法、国外保管の有無。
- 判定対応：AI監視の誤検知の人手レビュー、異議申立て、合理的配慮、判定の再確認。
同ガイドラインでは、本人を判別できる映像情報や、特定の個人を識別できる音声録音情報が挙げられています。
オンライン試験システムのRFPの記載内容
RFPは、各社が同じ条件で提案と見積もりを作るための発注仕様書です。「高機能なシステムが欲しい」と伝えるにとどまると、各社の前提がそろいません。
まず、背景と目的、対象者、想定規模を書きます。そのうえで、業務フロー、必須・非機能要件、納期を示します。予算の考え方、提案方法、契約条件も書き添えます。
未確定の項目は無理に決めず、提案してほしい選択肢として示します。そうすると、各社の提案力も比べられます。
業務・データ・運用体制の記載
業務量、管理データ、運営担当は、分けて記載します。年間の人数だけでは、処理負荷が伝わりにくいためです。
- 業務要件：試験種類、受験者数、年間実施回数、申込期間、試験時間、同時受験者数、問題数、合格基準。
- データ要件：受験者、試験、科目、問題、選択肢、解答、採点、合否、監視記録と保持期間。
- 運用要件：登録、監視、問い合わせ、障害判断、月次報告、保守の担当。
業務要件には、申込や再受験、免除も含めます。さらに、団体申込、決済、結果通知も加えます。運用要件では、問題登録の担当、当日の監視者、問い合わせ窓口を記載します。障害時の意思決定者、月次レポート、保守時間も書き添えます。
受験者数は、年間の延べ人数に加えて、ピーク時の同時アクセス数と、開始直後にアクセスが集中する割合を分けて示します。
非機能要件の測定できる書き方
「安全で使いやすい」とだけ書くと、各社は異なる前提で見積もります。そのため、可用性、性能、拡張性を、測定できる条件に直します。セキュリティや操作性、保守性も、同じように測定できる条件へ置き換えます。
- 性能・復旧：同時受験者数、画面応答の目標、復旧時間、バックアップ頻度。
- セキュリティ：障害連絡の初動、脆弱性診断の時期、ログ保存期間、MFAの対象。
- 運用性：操作性、保守性、管理者権限の分離。
調達条件を具体化するときは、IPAの「IT製品の調達におけるセキュリティ要件リスト」第2.1版（2026年）が確認材料になります。
提案書と見積書の提出形式の統一
費目と機能区分をそろえると、価格差が生じる条件を読み取れます。そこで、各社には同じ形式で回答を依頼します。
- 費用：初期構築、月額・年額、受験者単価、監視単価、保守、運用代行。
- 作業費：問題登録・移行、連携開発、テスト、教育、追加費用。
- 機能区分：標準、設定、カスタマイズ、外部サービス、オプション。
発注側は、提案の方向性も比べられるよう、標準クラウドで早く始める案、専用環境で統制を高める案、段階導入で初期投資を抑える案を求めます。
契約形態の使い分け（請負と準委任）
仕様と成果物を固められる工程は請負、検証しながら進める工程は準委任が基本です。
試験制度や問題データ、監視方針は途中で変わることがあります。そのため、最初から全工程を請負に固定すると、変更管理や追加費用の交渉が複雑になりやすいです。
発注側は、法務・情報システム部門と協力して、成果物や検収方法、変更手順を契約書と仕様書に記します。どこまでを誰が受け持つかも、契約書で明確にします。
請負契約の完成条件と検収基準
納品物が明確な工程では、成果物と受入条件をそろえておきます。受入テストでは、正常な動作だけでなく、障害や訂正の動作も確認します。
- 成果物：要件定義書、画面・API仕様、プログラム、テスト結果、操作マニュアル。
- 受入テスト：通信断からの復帰、制限時間、問題シャッフル、途中保存、採点訂正。
- 契約条件：重大な不具合の定義、修正期限、検収期間、第三者障害、納品後の著作権・利用権。
さらに、権限分離や同時アクセス、バックアップ復元も、受入テストに含めます。また、第三者サービスの障害時の扱いも確認します。
準委任契約が向く工程（探索・運用・継続改善）
要件定義やPoC、運用設計は、専門知識や作業の提供を受ける準委任が使いやすい工程です。データ移行や継続改善でも、準委任を使う場面になります。
- 少人数検証：操作や問い合わせを確かめてから、本番仕様を決める流れ。
- 段階契約：検証後に確定した開発範囲を、請負へ移す方法。
- 進捗確認：月次成果物、課題、決定事項、翌月計画、品質指標。
作業時間の長さだけでは成果が見えにくいため、定例会で成果と課題を確かめます。
データ・知財・障害時の責任の分け方（契約への記載）
契約では、データ、知財、障害時の責任を明確にします。解約後や外部サービス停止後の対応も、あらかじめ決めておきます。
- データ・知財：問題データの著作権、受験者データの所有権、監視映像の保管者、ログの利用範囲。
- 解約・停止：解約時のデータ返却、API停止時の代替手段。
- 委託管理：再委託の承認、アクセス権限、監査、事故報告、削除証明、国外データセンターの確認。
クラウド基盤とベンダーのどちらが障害を受け付け、何時間以内に連絡するかも定めます。最後に、契約と運用手順を一致させます。
オンライン試験システムの費用相場の目安
標準クラウドは月額1万円から50万円程度です。一方、連携や監視を含む案件では、初期費用が数百万円から1,000万円超になることがあります。独自開発と大規模運用を含む試験では、数千万円から数億円に及ぶ場合もあります。
受験者数のほかに、同時アクセス、問題形式、本人確認・監視も金額を左右します。さらに、運用代行、既存連携、セキュリティ試験も影響します。
次に示すのは、公開料金と公的試算に基づく2025〜2026年時点の予算検討用の幅です。単一の相場だけで判断しないよう、幅で捉えます。
研修・社内テスト向けの月額と初期設定の分け方
研修・社内テスト向けクラウドは、比較情報上、月額1万円から50万円程度が目安です。ID数が増えると月額も上がるため、利用人数を基準に見比べます。
- 50ID・300ID：Leafの月額は16,250円・67,500円です。
- 1,000ID・3,000ID：Leafの月額は115,000円・225,000円です。
- 追加機能：制限時間は初期120万円から、シャッフルは240万円からです。
料金は株式会社インソース「Web試験運用パッケージ」（2026年確認）によります。
問題登録や初期設定は別費用の場合があります。カスタマイズとサポートについても、別費用かどうかを確かめます。そのため、初年度総額で比べます。
専用環境・連携を含む中規模案件の費用幅
数百人から数千人規模で連携や監視を組み込む案件では、初期費用が数百万円から1,000万円超まで広がることがあります。
- 連携・運用：問題バンク、SSO、LMS・人事DBとのAPI連携、決済。
- 本人確認・試験：監視ログや負荷試験も費用に影響します。
- 公開相場例：数百名は100万円から300万円程度、数千名は500万円以上です。
相場例は、監視や運用代行を含むかどうかで前提が変わります。そのため、初期費用に加えて年間利用料と受験者単価を合算します。さらに、同時接続超過とデータ保管、保守も含めます。問い合わせや脆弱性診断も、合算の対象です。
大規模CBT・独自開発の公的試算の位置づけ
大規模試験では、開発費のほかに運営費も見積もる必要があります。そのため、費用項目と公的試算の前提を並べて整理します。
- 運営費：会場、端末、監督者、申込・決済、コールセンターも対象です。
- 想定規模：厚生労働科学研究の試算は約1万人・全国13会場です。
- 開発費の例：TAO実装や問題バンクを含み、2億6,800万円です（厚生労働科学研究補助金、2024年度公開資料）。
- 試算の位置づけ：医療系試験の個別値で、市場平均ではありません。
- 参考範囲：市場平均ではありませんが、数万人級の厳格な試験を新規構築する場合、数千万円から数億円になり得る参考材料です。
委託先の選定と見積比較の確認事項
委託先は、システムを開発できるかに加えて、安全に試験を運営できるかで選びます。
受験者規模や試験方式、監視の厳格性は、同じ質問票で各社に確認します。運用代行や既存連携、障害対応、データの持ち出しやすさも、同じ項目で尋ねます。そのうえで、見積もりの前提が自社業務と一致し、追加費用と運用負担が少ない会社を選びます。
導入実績の確認範囲（受験者数と運用範囲）
導入実績は、件数だけでなく中身まで確認します。方式やピーク人数、担当範囲を見て、自社の業務範囲と照らし合わせます。
- 方式・規模：IBTかCBTか、ピーク時の同時受験者数。
- 受託範囲：申込・決済、問題登録、採点、合否通知、窓口。
- 運営実績：コールセンターや障害時対応の経験。
日本通信紙の公開事例では、約4万5,000名のPBTからCBTへの移行が示されています。この事例の受託範囲は、Web申込から決済、開発・運営までです。さらに、会場、合否通知、窓口も含まれます（日本通信紙、2026年確認）。
実機デモと障害時シナリオによる技術力の確認
自社の代表的な問題を使ったデモを依頼します。受験者と管理者、それぞれの操作と、障害時の復旧を確かめます。
- 受験の流れ：登録、環境確認、本人確認、受験、採点、合否通知。
- 障害対応：問題シャッフル、途中保存、通信断からの復帰。
- 管理機能：ログ確認、設定変更、権限分離の操作性。
CBT-SolutionsのIBTでは、24時間365日の受験、多様な問題形式、問題・選択肢のランダム出題が案内されています。また、試験前の環境チェックやAPI・シングルサインオンも紹介されています（株式会社CBT-Solutions、2026年確認）。
見積書の分類統一と総額・追加条件の比較
費目を共通の分類にそろえると、規模別の総額と追加条件を比べられます。受験者数を変えた見積もりも、各社に依頼します。
- 基本費用：初期、月額、従量、開発、連携、保守。
- 運営費用：問題登録、監視、運用代行、教育、クラウド、セキュリティ。
- 比較条件：数十人、数百人、数千人の総額と追加条件。
初期費用が無料でも、決済手数料や監視、同時接続超過が別請求なら、年間総額は高くなる可能性があります。データ保管やサポート、カスタマイズも、別請求かどうかを確かめます。最後に、安さの理由と成立条件を見ます。
発注から公開までの進め方とスケジュール
段階導入では、PoC、少人数パイロット、本番の順に進めるのが安全です。
期間の目安は、標準クラウドが1〜3か月、連携や監視を含む案件が3〜6か月です。一方、独自の問題バンクや本人確認、大規模負荷試験を含む開発では、6〜12か月以上を見込みます。
試験日が決まっている場合は、開発完了日ではなく運用開始日から逆算し、リハーサルと予備日を確保します。
PoCとパイロットによる本番前のリスク確認
PoCでは代表的な問題と管理操作を確認し、パイロットでは実受験に近い条件で検証します。また、規模を段階的に上げて、課題を見つけます。
- PoC：代表的な問題の登録から、ログイン、本人確認、受験、採点、結果出力、管理者操作まで。
- パイロット：端末、ブラウザ、通信、問い合わせ、監視、再受験。
- 失敗シナリオ：通信断、カメラ不調、本人確認失敗、問題文の誤り。
採点訂正や開始時刻のアクセス集中も、意図的に検証します。そうすると、本番で初めて判明する問題を減らせます。
試験当日の運用台本と判断基準
試験事務局向けの台本を作り、開始から結果通知までの作業を順に書き出します。作業ごとに、判断する人も決めておきます。
- 開始前のシステム確認と、受験者への案内。
- 本人確認失敗、通信断、監視アラート、問い合わせへの対応。
- 試験延長・振替、合否確定、結果通知の判断と実施。
連絡先は、システム会社や運営会社、会場の分をまとめます。加えて、監視担当と社内責任者の連絡先も書き添えます。最後に、エスカレーション条件も一枚に記します。
よくある質問（FAQ）
発注時によくある疑問を、順に答えます。自社の条件を整理してからベンダーへ相談すると、過不足のない提案を受けやすくなります。
オンライン試験システムはクラウドとスクラッチのどちらがよいですか？
短期導入を優先する標準的な研修・社内試験には、クラウド型が候補です。
独自採点や複雑な連携、厳格な監査には、専用環境やスクラッチ型を検討します。また、標準クラウドでPoCを行い、差別化が必要な部分だけを開発する段階導入も有効です。
オンライン試験ではカメラ監視や顔認証が必須ですか？
すべての試験で必須というわけではありません。研修の理解度確認なら、問題シャッフルや制限時間、受験履歴で足りる場合があります。
採用・昇格・資格・入試など、本人性と公平性が重要な試験では、本人確認と環境チェックに、監視や人手レビューを組み合わせる必要があります。
顔画像や映像・音声を扱う場合は、取得目的や同意・説明を要件に含めます。さらに、保管期間やアクセス権限、誤判定時の救済手順も書き添えます。
オンライン試験システムの見積もりは何社から取るべきですか？
少なくとも複数社から比べられるようにします。社数を増やすことより、同じRFPに対して共通の条件で回答を受け取ることを優先します。
初期費用や運用費、受験者単価をそろえて比べます。監視や代行、保守、連携についても、同じ条件で並べます。提案に差がある場合は、含まれない業務や前提を洗い出します。
オンライン試験システムの開発期間はどれくらいですか？
標準クラウドは1〜3か月、連携や監視を含む案件は3〜6か月、独自開発と大規模負荷試験は6〜12か月以上が目安です。
問題データや受験制度の整理、本人確認審査、リハーサルにも時間がかかります。試験日が固定なら、受入テストとパイロットを行います。修正と予備日も、計画に含めます。
まとめ
発注判断の基本：3軸と総額比較
発注では、用途と受験者規模、必要な厳格性を先に定めます。そのうえで、方式と委託範囲を選び、申込から合否通知までの業務をRFPにまとめます。
RFPと小規模検証から始める進め方
費用は、月額サービスから数千万円・数億円規模まで幅があります。初年度や複数年の総額で見て、実績やデモ、障害時の判断体制も確かめます。
要件が固まらない場合は、PoCとパイロットを行います。通信断や本人確認失敗、問題ミスを検証します。採点訂正やアクセス集中も、あわせて確かめます。適切な責任の分け方を定め、公平で継続的に改善できる試験を目指します。
▼全体ガイドの記事
・オンライン試験システム開発の完全ガイド
▼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を創業。