オンライン試験システム開発の進め方/やり方/流れや方法/手法/工程/手順

オンライン試験システム開発の進め方は、試験の目的と厳格性を決め、要件整理から選定、設計開発、テスト、稼働、定着までを段階的に進めることが基本です。

採用試験や社内昇格試験、資格検定、学校の入試、研修後テストでは、必要な本人確認や監視、問題管理、受験者数、既存システムとの連携が異なります。この記事では、オンライン試験システムを導入する担当者がベンダー任せにせず判断できるように、6つのフェーズごとの確認項目、方式の選び方、2026年時点の費用相場、見積もりの見方を具体的に解説します。

▼全体ガイドの記事
・オンライン試験システム開発の完全ガイド

オンライン試験システムとは何ですか？全体像を整理します

オンライン試験システムは、申込、受験資格の確認、問題配信、本人確認、受験、採点、合否判定、結果通知までを一連の業務として管理する仕組みです。単に問題を表示する機能だけでなく、試験の公平性を守る運用と、障害や問い合わせに対応する業務設計まで含めて検討する必要があります。

IBTは受験者が自宅や職場からインターネット経由で受験する方式です。会場を用意しなくてもよく、受験機会を増やしやすい一方、受験者ごとのパソコン、ブラウザ、通信品質、カメラやマイクの状態が異なるため、事前の環境チェックと通信断時の救済ルールが欠かせません。CBTはテストセンターなどの管理された端末で受験する方式です。本人確認や会場監督、端末スペックを標準化しやすく、資格試験や大規模試験に適しています。PBTは紙を使う集合型試験で、オンライン化の比較対象として現行業務を棚卸しする際に重要です。全国約45,000名の公益財団法人の試験では、PBTからCBTへ移行し、申込、決済、試験システム、会場、合否通知、コールセンターまでを一体運営した事例が公開されています（出典: 日本通信紙株式会社「PBT試験からCBT試験へ移行」導入事例）。

対象範囲は、受験者・団体・試験科目・受験資格の管理、問題バンク、出題範囲と配点、問題や選択肢のランダム化、制限時間、途中保存、再受験、免除設定、自動採点、記述答案の採点、合否通知、受験料決済、領収書、バウチャー、結果帳票、CSVやAPI連携まで広がります。社内研修ならLMSのテスト機能だけで足りる場合がありますが、採用や昇格では本人確認と監視ログ、資格試験や入試では監査証跡、問題漏えい対策、障害時の振替、問い合わせ窓口まで必要になりやすいです。最初から全機能を作るのではなく、「今回の試験で必須」「次回以降に追加」「運営代行で補う」に分けると、費用と開発期間を抑えながら開始できます。

方式を決める前に、用途、規模、厳格性の3軸を整理します。用途では研修・理解度確認、採用・昇格、資格・入試のどれかを分類します。規模では年間受験者数だけでなく、最も多くの人が同時に開始するピーク同時接続数を確認します。厳格性では、問題の機密性、なりすましの影響、合否に対する異議申立ての可能性を評価します。例えば数十人の社内テストに顔認証と有人監視を標準搭載すると、受験者の負担と費用が過大になりやすいです。一方、国家資格のように不正や採点ミスが社会的な問題になる試験では、監視、レビュー、ログ、冗長化を省けません。3軸を1枚の整理表にすることが、パッケージ、クラウド、スクラッチの判断をぶれにくくします。

オンライン試験システム開発の進め方を6フェーズで解説します

開発は、画面や機能の一覧から始めると、試験制度の未確定部分が後から変更になりやすいです。現行試験の業務を分解し、誰が何をいつ判断するかを決めてから、方式と製品を選びます。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズを、成果物と判断基準が分かる順番で整理します。

最初に、試験の目的、対象者、年間回数、受験者数、同時接続数、試験時間、問題形式、合格基準、再受験、免除、受験料、結果通知日を定義します。次に、申込受付、受験資格審査、問題登録、試験実施、採点、合否確定、問い合わせ、再採点、証明書発行の担当者と承認者を洗い出します。チェック項目は、(1)問題の著作権と機密区分、(2)記述・画像・動画・音声の出題有無、(3)採点者が複数いる場合のダブルチェック、(4)本人確認に使う情報、(5)顔画像や映像・音声・監視ログの保存期間、(6)通信断や本人確認失敗時の再受験条件です。成果物として、業務フロー、試験要件一覧、データ項目表、例外対応一覧を残します。特に「合格基準を後から変更できるか」「採点確定後に訂正できるか」は、通常機能と監査ログの両方に影響するため、発注前に決める必要があります。

要件をもとに、LMS内蔵テスト、試験特化クラウド、パッケージ・専用環境、スクラッチまたはオープンソース拡張を比較します。研修や社内テストであれば、短期間で始めやすいSaaSが有力です。採用や昇格では、問題のシャッフル、本人確認、監視、再判定までを確認します。資格試験や入試では、CBT会場、監査証跡、冗長化、障害時の振替、コールセンターを含めて、システム会社と運営会社の役割分担を見ます。デモでは、受験者画面だけでなく、管理者が問題を登録して出題セットを作り、採点を訂正し、ログを出力する流れを実演してもらいます。比較のチェック項目は、問題データをCSVやAPIで持ち出せるか、SSOに対応するか、同時接続数の上限、監視判定の人手介入、SLA、障害時の連絡時間、解約後のデータ返却です。価格が安くても、問題登録や監視、問い合わせが別契約なら総額は変わるため、同じRFPで条件をそろえます。

設計では、受験者、試験、問題、出題セット、答案、採点、監視イベント、合否、決済、問い合わせのデータ関係を定義します。画面設計では、受験前の端末・ブラウザ・カメラ・マイク確認、本人確認、受験中の残り時間、途中保存、通信断からの復帰、終了後の完了表示を先に作ります。管理者側には、問題の版管理、承認前後の権限分離、出題ミスの訂正履歴、採点者の作業履歴、結果公開の予約、CSV出力が必要です。不正対策はカメラを付ければ十分ではありません。問題プール、設問と選択肢のシャッフル、ブラウザ制御、本人確認、視線や離席などの検知、有人レビューをリスクに応じて組み合わせます。生成AIによる不正回答も想定し、監視システムが疑わしいと判定しただけで不合格にせず、証拠の確認、再判定、異議申立ての手順を設計します。標準機能で賄える箇所と、独自開発する差別化箇所を分けることが、品質と費用のバランスを保つポイントです。

テストは、機能が動くかだけでなく、公平に受験できて正しく結果が確定するかを確認します。単体・結合・総合テストに加えて、受験者端末のOS、ブラウザ、画面サイズ、カメラやマイクの許可状態、通信速度の差を組み合わせます。試験当日を想定し、開始直後の同時アクセス、制限時間終了、途中保存、通信断、ブラウザ再起動、本人確認失敗、監視判定の誤検知、決済失敗、採点訂正、結果通知の重複をテストします。大規模試験では、ピーク同時接続数に安全率を加えた負荷試験と、障害時に別経路へ切り替えられるかのBCP確認が必要です。受験者を少人数募集するパイロットでは、操作時間、問い合わせ内容、非対応端末、合理的配慮の不足を記録します。合格判定のテストデータは、合格境界、不合格境界、免除、再受験、記述採点の組み合わせを用意し、結果が担当者の経験ではなく仕様どおりになることを確認します。

本番稼働前には、試験責任者、システム管理者、監視担当、採点担当、問い合わせ窓口、ベンダーの連絡先を明確にします。受験案内には、推奨端末、対応ブラウザ、事前確認の期限、本人確認書類、禁止事項、通信断時の連絡方法、再受験の条件を記載します。試験当日は、開始前の稼働確認、アクセス数、エラー率、監視キュー、決済状況、問い合わせ件数を見られるダッシュボードが役立ちます。障害が起きた場合に備え、一定時間の延長、別日への振替、受験料の扱い、答案の有効性、受験者への一斉告知をあらかじめ承認しておきます。個人情報を扱うため、氏名、本人確認書類、顔画像、映像、音声、監視ログの利用目的、アクセス権限、保管期間、削除方法、委託先を文書化します。高リスクの試験では、脆弱性診断、暗号化、MFA、監査ログ、バックアップ、インシデント連絡、委託先監査を契約と運用手順の両方に落とし込みます。

稼働後は、システムを納品物として終わらせず、試験運営の品質を測ります。KPIは、受験完了率、本人確認失敗率、通信断からの復帰率、問い合わせ件数、平均回答時間、採点訂正件数、監視判定の人手レビュー率、結果通知までの時間などから選びます。受験者アンケートでは、操作の分かりやすさだけでなく、端末準備の負担、監視への納得感、合理的配慮、問い合わせの解決度を確認します。問題については、正答率、識別力、分野別の偏り、出題ミスを分析し、次回の問題バンク更新に反映します。運営チームには、問題登録、承認、試験設定、当日監視、採点確定、障害報告、監視ログのレビューを手順書と訓練で定着させます。まずは低リスクの社内試験でPoCを実施し、少人数パイロットを経て本番へ広げる段階導入にすると、システム上の問題と制度上の問題を分けて改善できます。

オンライン試験システムの費用相場とコストの内訳を解説します

費用は、受験者数だけでは決まりません。監視の厳格性、問題形式、同時接続数、既存システム連携、試験運営の代行範囲、データ保管、負荷試験、セキュリティ診断によって大きく変わります。以下の金額は、公開料金と公的な試算をもとにした2025〜2026年時点の予算検討用レンジです。試験の重要度や要件が違うサービスの金額を、そのまま横並びにしないことが大切です。

研修や社内テスト向けのクラウドは、比較記事の相場として月額1万円〜50万円程度が一つの起点です。公開料金の例では、インソースのLeafが50IDで月額16,250円、300IDで67,500円、1,000IDで115,000円、3,000IDで225,000円を掲げています。また、制限時間機能は初期120万円から、シャッフルテスト機能は初期240万円からとされており、月額だけで判断できないことが分かります（出典: 株式会社インソース「Web試験運用パッケージ」料金ページ、税抜表示）。数十〜数百人が定期的に受験する場合、初期設定や問題登録を含む初年度費用をおおむね20万円〜300万円程度で仮置きし、監視、本人確認、決済、個別連携が必要なら上振れ要因として別に積み上げます。無料や低価格のプランでは、問題登録、サポート、データ保管、同時接続超過、解約時のデータ出力が別料金でないか確認します。

買い切り型や専用環境では、公開比較情報の目安として、数十名で50万〜100万円、数百名で100万〜300万円、数千名で500万円以上というレンジが示されることがあります。SSO、会員データベース、LMS、人事システム、決済、資格証発行、API連携、問題バンクの移行を加えると、初期費用は500万〜2,000万円程度まで広がる可能性があります。ここは市場平均ではなく、機能と連携の組み合わせから算出する予算レンジです。費用内訳は、要件定義、試験制度設計、画面とデータ設計、開発・設定、問題登録・移行、クラウド基盤、負荷試験、脆弱性診断、マニュアル、教育に分けます。パッケージを選ぶ場合も、標準機能の適合率を確認し、足りない箇所だけ追加開発する方が、全面スクラッチよりTCOを抑えやすいです。

数千〜数万人規模では、システムだけでなく会場、端末、監督者、本人確認、コールセンター、受験料決済、障害時の振替、監査対応までが費用になります。厚生労働科学研究のCBT試算では、TAOクラウドや初期開設などを含む初年度費用が約700万〜800万円となる例があり、別の大規模試算では約1万人・全国13会場の条件で開発費2億6,800万円の例もあります（出典: 厚生労働科学研究補助金「CBTシステムの費用概算」等）。医療系試験など特殊な条件を含むため、市場平均として断定できませんが、大規模試験は数千万円から数億円までの幅になり得る根拠になります。開発期間も、標準クラウドの設定・問題登録なら1〜3か月、既存連携や監視を含むと3〜6か月、独自問題バンク・高度な本人確認・大規模負荷試験を含むスクラッチなら6〜12か月以上を見込みます。

年間費用は、月額利用料や保守費だけでなく、1受験あたりの従量課金、決済手数料、本人確認・監視、有人レビュー、問題登録、コールセンター、会場、バックアップ、ログ保管、脆弱性対応、再受験、障害対応を合算します。例えば、受験者が少なくても有人監視の時間が長ければ単価は上がります。反対に、受験者が多くても問題を自社登録し、自動採点中心で、会場を持たなければ単価を下げられる場合があります。見積書では「初年度」「2年目以降」「試験1回追加」「受験者1名追加」「同時接続数増加」「監視レベル変更」の5パターンを出してもらうと、サービス間の比較がしやすいです。初期費用が低く見えるサービスほど、契約期間、最低利用数、超過料金、データ移行費、解約時の削除証明まで確認します。

オンライン試験システムの見積もりを取る際のポイントです

見積もりの差は、ベンダーの開発単価よりも前提条件の差から生まれます。受験者数だけを伝えて金額を求めるのではなく、試験の重要度、同時接続、監視方式、運営代行、連携、セキュリティ、納期を同じ資料で提示します。依頼時に「標準機能で実現」「設定・移行で実現」「追加開発が必要」「運用で代替」の区分を付けてもらうと、削れる費用と削ってはいけない費用が見えます。

最低限、試験の目的、方式、対象者、年間受験者数、最大同時接続数、試験時間、問題数、問題形式、問題登録件数、合格基準、再受験、受験料、結果通知、監視レベル、本人確認、端末要件、障害時対応、保管期間、既存連携、希望納期をRFPに記載します。問題データは、問題文、選択肢、正解、解説、配点、分野、難易度、公開可否、版、著作権者の項目を持つサンプルを数件渡します。API連携は「連携したい」ではなく、送受信する項目、頻度、認証方式、エラー時の再送、責任分界を定義します。監視は「AI監視あり」だけでは不十分で、何を検知し、どの証拠を残し、誰が何時間以内に再判定するかを確認します。画面一覧と業務フローに加えて、通常ケースと例外ケースを用意するほど、後から発生する追加開発を減らしやすくなります。

比較先は、システムを提供する会社、試験運営を代行する会社、両方を担う会社に分けて見ます。質問項目は、対応方式、実績の受験者規模、試験運営の範囲、本人確認・監視の方式、問題データの所有権、データのエクスポート、API・SSO、障害時のSLA、セキュリティ認証と脆弱性対応、問い合わせ体制、課金単位です。ベンダーが「大規模対応」と説明しても、実際の最大同時接続数、負荷試験の条件、ピーク時の監視体制、障害時の振替実績を確認します。公式発表の導入実績は参考になりますが、自社と同じ試験形式・受験者規模・監視レベルであるとは限りません。契約前に実機デモ、サンプル問題での移行テスト、少人数PoCを実施し、担当者が運用画面を使えるかを確かめます。

オンライン試験では、氏名や連絡先だけでなく、本人確認書類、顔画像、映像、音声、監視ログ、答案、合否情報が扱われることがあります。利用目的と同意、第三者提供や委託、アクセス権限、保存期間、削除、海外の委託先、漏えい時の連絡を整理し、システム要件と契約に反映します。2026年2月にIPAが更新した「IT製品の調達におけるセキュリティ要件リスト活用ガイドブック」第2.1版は、調達者が要件を整理し、利用・運用時の注意点を確認するための資料です（出典: IPA、2026年2月更新）。この資料を参考に、TLS、保存データの暗号化、MFA、脆弱性診断、監査ログ、バックアップ、BCP、インシデント対応、委託先監査をRFPの確認欄にします。さらに、2025年8月に大学入試センターが第2版を公開したCBT導入時の検討事項リストでは、運用モデル、受験者端末、OS、最小要件などが検討項目になっています。端末要件と合理的配慮を後付けにせず、設計・テスト費用に含めます。

費用を削る場合は、試験の失敗時に取り返せる機能から見直します。例えば、初回は社内試験に限定して有人監視を運用で補い、問題形式を選択式に絞り、決済や資格証発行を後工程に回す方法があります。一方で、採点結果の履歴、問題の版管理、権限分離、バックアップ、通信断時の救済、個人情報のアクセスログは、安易に削ると後から復旧できないため優先して残します。納期が厳しい場合は、全機能を一度に請負契約に固定せず、要件整理とPoCを先行し、段階リリースにします。見積書では、前提条件、含むもの、含まないもの、変更時の単価、受入条件、保守の開始日を明記してもらいます。金額が合わないときは、機能を一括削除するのではなく、リスク、代替手段、次回リリースの順で調整します。

オンライン試験システム開発でよくある質問

オンライン試験の導入では、機能の有無よりも、試験制度と運用の境界が曖昧なことが不安につながります。ここでは、導入前に多い質問へ、費用と運用の前提を含めて回答します。

研修や社内テストのように標準的な選択式問題を短期間で実施するなら、SaaSやLMSのテスト機能が向いています。資格試験や入試のように、独自の受験資格、問題管理、監視、採点、外部連携、監査証跡が必要なら、試験特化クラウドやパッケージを基盤に追加開発する方法が現実的です。独自性が本当に合否判定や監視に関わる場合だけスクラッチを検討し、標準化できる部分は既存サービスを使うと、初期費用と保守負担を抑えやすいです。

必須ではなく、試験の重要度、なりすましや不正の影響、受験者のプライバシー、合理的配慮を踏まえて決めます。社内の理解度確認なら問題プール、時間制限、選択肢のシャッフル、本人の受験宣誓だけで足りる場合があります。採用、昇格、資格、入試では本人確認や監視を追加し、AIの検知結果だけで処分せず、人手によるレビューと異議申立てを用意します。顔画像や映像・音声を取得する場合は、利用目的、同意、保管期間、アクセス権限、削除方法を事前に説明します。

標準クラウドの初期設定と問題登録なら1〜3か月、LMS・人事・決済・会員DBとの連携や監視要件を含むと3〜6か月、独自の問題バンクや本人確認、大規模負荷試験まで作り込むと6〜12か月以上が目安です。期間を左右するのは開発人数だけでなく、問題データの整理、試験制度の承認、端末検証、セキュリティ審査、パイロットの有無です。試験日が決まっている場合は、必須機能だけで先行リリースし、分析や高度な自動化を次回に回す段階導入を計画します。

試験前に端末と通信の動作確認を行い、受験中は途中保存と再接続を可能にする設計が基本です。それでも復旧しない場合に備え、延長、別日への振替、再受験、答案の扱い、受験料の返金、問い合わせ窓口、本人確認の再実施条件を決めます。障害が起きた時点のアクセスログ、答案、監視記録、システム状態を保存し、受験者ごとに不利益が出ていないか確認します。原因を受験者の環境だけに帰すのではなく、ベンダー側のログと突き合わせて、再発防止策を試験後の定着フェーズへ反映します。

オンライン試験システム開発の進め方をまとめます

オンライン試験システムの開発では、先に機能一覧を作るのではなく、試験の目的、受験者数、同時接続数、必要な公平性、運営体制を整理します。IBT、CBT、LMSテスト、試験運営代行の違いを用途・規模・厳格性の3軸で比較し、標準化できる部分はクラウドやパッケージを使い、独自性が必要な部分に開発費を配分します。

要件整理では合格基準、問題の版管理、再採点、個人情報、障害時の救済を決めます。選定では受験者画面だけでなく管理画面、問題データの持ち出し、監視の人手レビュー、SLA、運用代行の範囲を確認します。設計開発では、本人確認やAI不正対策を過信せず、テストでは端末差、通信断、同時アクセス、採点境界を再現します。稼働後は受験完了率、問い合わせ、監視判定、採点訂正、障害をKPIとして、パイロットの学びを次回試験に反映します。見積もりは初期費用だけでなく、試験1回の運営費と2年目以降のTCOで判断します。

まず現行の試験業務を棚卸しし、用途、受験者数、ピーク同時接続数、問題形式、監視レベル、既存連携、希望日、予算レンジを1枚にまとめます。そのうえで、必須機能、将来機能、運用で補う機能を分け、同じ条件のRFPを複数社へ提示します。PoCや少人数パイロットを挟み、受験者が迷わず、運営担当者が結果を説明でき、障害時にも不利益を抑えられることを確認してから本番へ進むことが、オンライン試験を定着させる近道です。

▼全体ガイドの記事
・オンライン試験システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。