オンライン試験システムの開発は、試験制度の整理、方式とサービスの選定、設計・テスト・定着の順に進めます。この順で進めると、公平で運用しやすい試験につながります。
各段階で何を決めるかを、発注側の担当者の目線で説明します。システムの全体像は完全ガイドでも確認できます。
▼全体ガイドの記事
・オンライン試験システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オンライン試験システムの全体像
試験の流れは、申込と受験資格の確認から始まり、問題配信と本人確認、受験を経て、採点と合否判定、結果通知で終わります。オンライン試験システムは、この流れ全体を管理します。また、問題の表示だけでなく、公平性を守る運用や障害・問い合わせ対応も検討します。
IBT・CBT・PBTの使い分け
3つの方式は、受験者がどこで受けるかと、試験をどこまで管理するかで選び分けます。
- IBT：自宅や職場から会場なしで受験でき、機会を増やせます。端末、ブラウザ、通信品質を確かめ、カメラとマイクも見ます。通信断時の救済も決めます。
- CBT：テストセンターなどの管理端末で受験します。本人確認や会場監督、端末仕様をそろえやすく、資格試験や大規模試験に適します。
- PBT：紙を使う集合型の試験です。オンライン化を比べる際に、現行業務を一覧にできます。
全国約45,000名の公益財団法人の試験では、PBTからCBTへ移行した事例があります。この導入事例では、申込と決済から、試験会場、合否通知、コールセンターまでを一体で運営しています（出典：日本通信紙株式会社「PBT試験からCBT試験へ移行」導入事例）。
システム化する範囲
必要な機能は、申込から結果通知までを4つの領域に分けると、漏れなく洗い出せます。
- 受験・試験管理：対象者、団体、科目、受験資格、制限時間
- 問題・採点管理：問題バンク、配点、ランダム化、自動・記述採点
- 受験後の処理：合否通知、決済、領収書、バウチャー、結果帳票
- 連携・例外対応：途中保存、再受験、免除、CSV・API連携
社内研修であれば、LMSのテスト機能だけで足りる場合があります。一方で、採用や昇格では本人確認と監視ログが求められやすく、資格試験や入試では監査証跡と漏えい対策に加えて、障害時の振替と問い合わせ窓口も必要になりやすいです。
機能は、今回必須のもの、次回以降に追加するもの、運営代行で補うものに分けます。このため、最初から全機能を作らず、費用と開発期間を抑えて開始できます。
方式選定の観点：用途、規模、厳格性
方式がぶれないよう、受験の目的、同時接続数、不正時の影響を先に確かめておきます。
- 用途：研修・理解度確認、採用・昇格、資格・入試
- 規模：年間受験者数と、開始が重なるピーク同時接続数
- 厳格性：問題の機密性、不正の影響、異議申立ての可能性
たとえば、数十人の社内試験に顔認証と有人監視を標準で載せると、受験者の負担や費用が過大になりやすいです。反対に、国家資格のように不正や採点ミスが社会問題になる試験では、監視やレビューに加えて、ログと冗長化も省けません。
この3つの観点を一覧にしておくと、方式を選びやすくなります。
オンライン試験システム開発の進め方と6フェーズ
画面や機能の一覧から開発を始めると、試験制度の未確定部分が後から変更になりがちです。そのため、まず業務を分解し、担当者と判断時点を決めてから、方式や製品を選びます。
全体は6つのフェーズで進みます。要件整理から始まり、方式とサービスの選定、設計と開発、テスト、稼働を経て、定着で終わります。各段階では、成果物と判断基準を明確にしておきます。
フェーズ1：試験制度と業務の要件整理
発注前に試験条件を具体化しておくと、必要な機能と運営の担当者を判断できます。
- 試験条件：目的、対象者、年間回数、受験者数、同時接続数
- 試験内容：時間、問題形式、合格基準、再受験、免除
- 運営条件：受験料、結果通知日、担当者、承認者
申込と受験資格審査、問題登録、試験について、担当者と承認者を洗い出します。採点と合否確定、再採点も、誰が判断し誰が承認するかを決めます。問い合わせと証明書発行については、担当者と承認者を明らかにします。
チェック項目は、問題の著作権と機密区分に加えて、記述や画像、動画、音声を出題するかどうかです。複数の採点者によるダブルチェックや、本人確認情報の扱いも決めます。
顔画像や映像、音声、監視ログの保存期間も確かめます。通信断や本人確認失敗時の再受験条件も、あわせて確認します。
成果物として、業務フローと試験要件一覧を残します。データ項目表と例外対応一覧も、あわせて残しておきます。
「合格基準」と「採点確定後の訂正」は、発注前に決めておきます。これらは通常機能と監査ログの両方に影響するため、後から変更しにくい条件を先に合意します。
フェーズ2：方式とサービスの選定
方式とサービスの候補は4つあり、要件に合わせて同じ条件で比べて選びます。
- LMS内蔵テスト：研修や社内テスト向け
- 試験特化クラウド：試験運用に必要な機能を利用
- パッケージ・専用環境：専用の設定や環境を用意
- スクラッチ・OSS拡張：独自要件に合わせて開発
研修や社内テストであれば、短期間で始めやすいSaaSが有力です。採用・昇格では、問題のシャッフルと本人確認を確かめます。監視と再判定の方法も、あわせて見ておきます。
資格試験や入試では、CBT会場や監査証跡、冗長化が対象になります。障害時の振替やコールセンターについても、システム会社と運営会社の役割を確認します。
デモでは、受験者画面だけでなく、問題登録から出題セットの作成、採点訂正、ログ出力までを実演してもらいます。
比較項目には、CSVやAPIでのデータ持ち出しとSSO、同時接続上限を入れます。加えて、人手介入やSLA、障害時の連絡時間も比べます。
解約後のデータ返却も確かめておきます。問題登録、監視、問い合わせを別契約にすると総額が変わるため、同じRFPで条件をそろえます。
フェーズ3：試験日から逆算する設計と開発
設計では、データの関係から判定の仕組みまで、5つの対象を決めておきます。
- データ：受験者、試験、問題、出題セット、答案、採点、監視イベント、合否、決済、問い合わせの関係
- 受験者画面：端末・ブラウザ・カメラ・マイク確認、本人確認、残り時間、途中保存、通信復帰、完了表示
- 管理機能：問題の版管理、承認前後の権限分離、出題ミスの訂正履歴、採点者の作業履歴、結果公開予約、CSV出力
- 不正対策：問題プール、設問・選択肢のシャッフル、ブラウザ制御、本人確認、視線・離席検知、有人レビュー
- 判定と開発範囲：生成AIの不正も想定し、証拠確認・再判定・異議申立てを設け、標準機能と独自開発を分ける
カメラの設置は、不正対策の一部にとどまります。疑わしい判定だけで不合格にしないよう、証拠の確認と再判定の手順を用意します。標準機能で賄う範囲と独自開発する範囲の切り分けは、品質と費用のバランスに関わります。
フェーズ4：受験者の失敗を防ぐテスト
テストでは、機能だけでなく、公平に受験できるか、結果が正しく確定するかを確かめます。その際は、端末と通信、受験時の操作、例外と結果の3つの面から条件を組みます。
- 端末・通信：OS、ブラウザ、画面、カメラ、マイク、通信速度
- 受験時の操作：開始直後の同時アクセス、時間終了、途中保存、通信断、ブラウザ再起動
- 例外・結果：本人確認失敗、誤検知、決済失敗、採点訂正、通知重複
単体、結合、総合の各テストを行います。大規模な試験では、ピーク同時接続数に安全率を加えた負荷試験も欠かせません。障害時に別の経路へ切り替えられるかどうか、BCPも確認します。
少人数のパイロットでは、操作時間や問い合わせ内容を記録します。非対応端末や合理的配慮の不足も把握し、結果に影響する課題を本番前に見直します。
合格境界と不合格境界、免除を組み合わせ、さらに再受験と記述採点も加えたデータを用意します。そのうえで、仕様どおりの判定になるかを確かめます。
フェーズ5：稼働時の役割と障害対応
試験日までに、役割と受験案内を決めておきます。当日の監視方法や障害時の判断は、事前に定めておきます。
- 役割：試験責任者、システム管理者、監視・採点担当、問い合わせ窓口、ベンダー連絡先
- 受験案内：推奨端末、対応ブラウザ、事前確認期限、本人確認書類、禁止事項、通信断時の連絡、再受験条件
- 当日の監視：稼働状況、アクセス数、エラー率、監視キュー、決済状況、問い合わせ件数
- 障害時の判断：延長、振替、受験料、答案の有効性、受験者への一斉告知を事前承認
- 個人情報：氏名等の利用目的、権限、保管期間、削除方法、委託先を文書化
本人確認書類と顔画像は、対象に含めます。映像と音声、監視ログも同様に扱います。
高リスクの試験では、脆弱性診断や暗号化、MFAを契約と手順に含めます。監査ログとバックアップ、インシデント連絡、委託先監査も、同じ契約の中で扱います。
フェーズ6：定着に向けたKPIと改善
稼働後は、試験運営の品質を測る指標を置きます。受験状況、運営負荷、判定精度の変化を追います。
- 受験状況：完了率、本人確認失敗率、通信断からの復帰率
- 運営状況：問い合わせ件数、平均回答時間、結果通知までの時間
- 判定状況：採点訂正件数、監視判定の人手レビュー率
受験者アンケートでは、操作性や端末準備の負担を確かめます。監視への納得感や合理的配慮、問い合わせの解決度も見ます。問題の正答率や識別力、分野別の偏り、出題ミスは、次回の問題バンクに反映します。
問題登録から監視ログのレビューまでを、手順書と訓練で定着させます。低リスクの社内試験でPoCを行い、少人数パイロットを経て本番へ広げると、制度とシステムの課題を分けて改善できます。
オンライン試験システムの費用相場と内訳
費用は、受験者数に加えて、監視の厳格性や問題形式、同時接続数で変わります。連携や運営代行、保管、試験の内容によっても変わります。
次に示すのは、公開料金と公的試算に基づく、2025〜2026年時点の予算検討用のレンジです。要件の異なる金額を単純に比べないことが大切です。
クラウド・SaaSの月額と初期費用
クラウド・SaaSの見積もりは、月額料金と初期機能費を分けて比べます。
- 月額相場：研修・社内テスト向けは比較記事で1万円〜50万円程度
- Leafの月額例：50IDは16,250円、300IDは67,500円
- Leafの月額例：1,000IDは115,000円、3,000IDは225,000円
- 初期費用：制限時間機能は120万円から、シャッフルテスト機能は240万円から（税抜）
- 初年度予算：数十〜数百人の定期受験なら、設定・問題登録込みで20万〜300万円程度
Leafの料金例は株式会社インソース「Web試験運用パッケージ」料金ページに基づきます（出典：株式会社インソース、税抜表示）。
監視や本人確認、決済、個別連携が必要な場合は、費用が上振れする要因になります。問題登録やサポート、保管に加えて、接続超過や解約時のデータ出力も、追加料金になるかを確かめます。
パッケージ・専用環境の初期費用と連携費
公開比較情報では、買い切り型や専用環境の目安として、数十名で50万〜100万円が示されています。数百名では100万〜300万円、数千名では500万円以上というレンジです。
連携や移行を加えると、初期費用はさらに広がります。具体的には、SSOや会員DBとLMS、人事の連携に加えて、決済や資格証発行、API、問題バンクの移行まで含めると、500万〜2,000万円程度になる可能性があります。
この金額は、機能と連携の組み合わせで算出する予算レンジで、市場平均を示すものではありません。内訳は、設計・開発、移行・基盤、導入支援の3つに分かれます。
- 設計・開発：要件定義、試験制度、画面・データ設計、開発・設定
- 移行・基盤：問題登録・移行、クラウド基盤、負荷試験
- 導入支援：脆弱性診断、マニュアル、教育
パッケージでも、標準機能の適合率を確かめます。不足する部分だけを追加で開発すれば、全面スクラッチよりもTCOを抑えられます。
大規模CBTの運営費を含む試算
大規模CBTでは、システム以外の運営費も加わります。費用と期間は、試算例や開発方式によって変わります。
- 運営費：会場、端末、監督者、本人確認、コールセンター、決済、振替、監査
- 初年度試算例：TAOクラウド・初期開設などを含み、約700万〜800万円
- 大規模試算例：約1万人・全国13会場で開発費2億6,800万円
- 開発期間：標準クラウドは1〜3か月、連携・監視込みは3〜6か月
- スクラッチ期間：独自問題バンク等を含むと6〜12か月以上
費用例の出典は、厚生労働科学研究補助金「CBTシステムの費用概算」等です。医療系試験などの特殊な条件を含むため、市場平均とは断定できません。ただし、数千万円から数億円になり得る根拠にはなります。
ランニングコストと試験1回あたりの総額
年間費用には、月額や保守だけでなく、1受験あたりの従量課金も合算します。あわせて、試験1回あたりの運営費も比べます。
- 利用・運営：月額・保守、受験課金、決済手数料、本人確認・監視、有人レビュー
- 試験の実施：問題登録、窓口、会場、バックアップ、ログ保管、脆弱性対応
- 例外対応：再受験、障害対応。長時間の有人監視は少人数でも単価を上げます
- 比較見積もり：初年度、2年目以降、試験1回追加、受験者1名追加、同時接続数増加、監視レベル変更
自社で問題登録をし、自動採点を中心にすると、受験者が多くても単価を下げられる場合があります。ただし、低い初期費用の契約では、期間や最低利用数、超過料を確かめます。移行費と削除証明も、あわせて確認しておきます。
オンライン試験システムの見積もりのポイント
見積もりの差は、開発単価より前提条件から生まれます。そのため、受験者数だけでなく、試験の重要度や運営範囲も示します。
監視方式や連携、セキュリティ、納期も、同じ資料に記載します。実現方法の区分を付けてもらうと、調整がしやすくなります。
要件定義書とRFPに入れる数値
見積もり条件の抜けを防ぐため、試験規模や運営、連携、例外処理をRFPに記載します。
- 試験条件：目的、方式、対象者、年間人数、最大同時接続数、時間、問題数・形式・登録件数
- 制度・運営：合格基準、再受験、受験料、結果通知、監視レベル、本人確認、端末要件
- 導入条件：障害対応、保管期間、既存連携、希望納期。問題データのサンプルも渡す
- 問題サンプル：数件用意し、問題文、選択肢、正解、解説、配点、分野、難易度、公開可否、版、著作権者を含める
- 連携・監視：APIの項目・頻度・認証・再送・責任分界、AIの検知内容と証拠、再判定する担当者と期限
「連携したい」という記載では、要件が不足します。画面一覧と業務フローに、通常ケースと例外ケースを加えておくと、追加開発を減らせます。
複数社の比較と運用範囲の確認
比較先は、システム提供会社と試験運営会社、両方を担う会社に分けて考えます。確認する項目も、そろえておきます。
- 対応・実績：方式、受験者規模、運営範囲、課金単位
- 機能・データ：本人確認、監視、所有権、エクスポート、API・SSO
- 運用・安全：障害時のSLA、セキュリティ認証、脆弱性対応、問い合わせ体制、課金単位
「大規模対応」と説明されても、それだけで判断しないことが大切です。最大同時接続数や負荷試験の条件を確かめ、ピーク時の監視体制と障害時の振替実績も見ます。
公式発表の実績は参考になります。ただし、自社と試験形式、規模、監視レベルが同じとは限りません。
契約前には、実機デモとサンプル問題での移行テスト、少人数PoCを行います。担当者が運用画面を使えるかも確かめます。
見積もりに含めるセキュリティと個人情報
試験では、個人情報や答案を扱うことがあります。そこで、利用目的や同意などを整理し、システム要件と契約に反映します。
- 対象情報：氏名・連絡先、本人確認書類、顔画像、映像・音声、監視ログ、答案、合否
- 取扱条件：利用目的・同意、第三者提供・委託、権限、保存期間、削除、海外委託先、漏えい連絡
- 調達時の参考：IPAの第2.1版ガイドブックは2026年2月更新（出典：IPA、2026年2月更新）
- 安全対策：TLS、保存データ暗号化、MFA、診断、監査ログ、バックアップ、BCP、事故対応、委託先監査
- 端末要件：大学入試センターの2025年8月公開リスト第2版は運用モデル、端末、OS、最小要件を扱う
端末要件と合理的配慮は、後回しにせず、設計とテストの費用に含めます。
費用を抑えるときに削る範囲
費用を削るときは、試験で失敗したときに取り返せる機能から見直します。初回の範囲は、対象、機能、開発の進め方の3つの面から絞れます。
- 対象を限定：初回は社内試験にし、有人監視を運用で補う
- 機能を段階化：選択式に絞り、決済・資格証発行を後工程へ回す
- 開発を分ける：要件整理とPoCを先行し、段階リリースする
採点履歴や問題の版管理、権限分離は、優先して残します。さらに、バックアップと通信断時の救済、個人情報のアクセスログも、優先して残します。
見積書には、前提と、含むもの・含まないものを明記してもらいます。変更単価と受入条件、保守開始日も、あわせて書いてもらいます。
金額が合わない場合は、リスク、代替手段、次回リリースの順に調整します。特に、機能を一括で削らないことが大切です。
オンライン試験システム開発でよくある質問
導入前の不安は、機能の有無だけでなく、試験制度と運用の境界が曖昧なことから生じます。そこで、費用と運用の前提も含めて回答します。
オンライン試験システムはSaaSとスクラッチのどちらが良いですか？
標準的な選択式の研修や社内テストを短期間で行うなら、SaaSやLMSのテスト機能が向いています。独自の受験資格や問題管理、監視が必要な場合は、試験特化クラウドやパッケージを基盤に追加開発します。
採点や連携、監査証跡についても、必要に応じて追加開発の対象にします。合否判定や監視に独自性が必要な場合だけ、スクラッチを検討します。
また、標準化できる部分に既存サービスを使うと、初期費用と保守負担を抑えられます。
オンライン試験でカメラ監視や顔認証は必須ですか？
監視や顔認証の要否は、試験の重要度や不正の影響、プライバシー、合理的配慮を踏まえて判断します。
- 社内の理解度確認：問題プール、時間制限、選択肢のシャッフル、受験宣誓で足りる場合があります
- 採用・昇格・資格・入試：必要に応じ本人確認や監視を加え、AI検知だけで処分せず人手レビューと異議申立てを用意
- 画像・音声を取得：利用目的、同意、保管期間、権限、削除方法を事前に説明
オンライン試験システムの開発期間はどれくらいですか？
開発期間は方式と試験要件で変わるため、試験日から逆算して段階導入を検討します。
- 標準クラウド：初期設定と問題登録で1〜3か月
- 連携・監視あり：LMS、人事、決済、会員DB連携などを含み3〜6か月
- 独自開発：問題バンク、本人確認、大規模負荷試験まで作ると6〜12か月以上
期間に影響するものには、問題データの整理や制度の承認、端末の検証があります。セキュリティ審査やパイロットも、期間に影響します。試験日が決まっている場合は、必須機能を先行させ、分析や高度な自動化を次回に回します。
通信断や本人確認失敗が起きたときはどうしますか？
通信断や本人確認の失敗に備えて、事前確認から事後検証までの対応を決めます。
- 事前確認：試験前の端末と通信の確認、受験中の途中保存と再接続ができる状態
- 復旧しない場合：延長や振替、再受験の条件に加えて、答案と返金、窓口、本人確認の再実施
- 事後検証：アクセスログや答案、監視記録、システム状態の保存と、受験者ごとの不利益の確認
- 原因と再発防止：受験者の環境だけに原因を求めず、ベンダー側のログも照合したうえで、再発防止策を定着フェーズに反映します。
オンライン試験システム開発の進め方のまとめ
開発の前には、試験の目的や受験者数、同時接続数を整理します。公平性と運営体制も、あわせて確かめておきます。そのうえで、IBT・CBT・LMS・運営代行を、用途、規模、厳格性で比べます。
標準化できる部分にはクラウドやパッケージを使い、独自性が必要な部分に開発費を配分します。
成功しやすい進め方の要点
制度や製品選定、設計と検証、運用、費用のそれぞれで、判断材料をそろえます。
- 要件整理：合格基準、問題版管理、再採点、個人情報、障害時救済を決める
- 選定・設計：管理画面、データ移行、監視レビュー、SLA、運営範囲を確認し、本人確認やAI対策を過信しない
- テスト・改善：端末差、通信断、同時アクセス、採点境界を検証し、KPIとパイロット結果を次回に反映
- 費用判断：初期費用だけでなく、試験1回の運営費と2年目以降のTCOを見る
次に作る資料：要件一覧とRFP
要件一覧とRFPを使い、現行業務から本番判断まで段階的に準備します。
- 現行業務から、用途と受験者数、ピーク同時接続数、問題形式を洗い出します。監視レベル、既存連携、希望日、予算レンジも加えて、1枚にまとめます。
- 必須の機能、将来に回す機能、運用で補う機能を分け、同じ条件の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を創業。