試験監督システム開発の進め方/やり方/流れや方法/手法/工程/手順

試験監督システム開発は、不正リスクと運用責任を定めたうえで、要件整理と方式選定から始めます。そのあと、設計・開発とテストを行い、稼働から定着へと進みます。各段階で何を仕上げ、どこで判断するかを決めておくと、導入後の混乱を抑えられます。

全体像は試験監督システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・試験監督システム開発の完全ガイド

試験監督システム開発の全体像

試験監督システムを中心に、受験者対応、試験運営、監督・審査、既存システムとの連携を放射状に示した図。
申込から試験後までの業務が一つの基盤につながります。

試験監督システムは、受験者、監督者、試験管理者をつなぐ業務基盤です。

試験の信頼性は、監視機能に加えて業務全体の流れで決まります。

申込から試験後のデータ削除までを、一続きの業務として設計します。本人確認や採点、異議申立ても、この流れの中で扱います。

試験業務全体を対象にする範囲

対象業務を決める際は、まず受験者対応、試験運営、連携先を洗い出します。

  • 受験者対応:登録から申込・予約、決済、受験票、案内メール、リマインドまで
  • 試験運営:本人確認、端末・カメラ・マイクの動作確認、問題配信、自動採点、合否判定、結果表示まで
  • 監督・審査:警告、チャット・音声連絡、強制退出、判定記録、再受験の承認、問い合わせ対応

既存のLMS、学籍・出願、人事との連携も検討します。採用管理、会員DB、決済サービスとの接続も、候補に入ります。

結果だけでなく、受験資格、予約、本人確認の状態、再受験の可否も、連携の対象になることがあります。

連携先と正データを持つシステムは、先に決めておくと手戻りを抑えられます。

試験のリスクと受験者負担で見る監視方式

監視方式は、試験の厳格性と説明責任に合わせて選びます。

  • 監視なしのIBT:学習確認など、厳格な監視が要らない試験に適します。
  • AI自動監視:受験者が多く、確認対象を絞り込みたい試験に向いています。
  • AIと有人確認:AIが抽出した疑わしい場面を、人が再確認できます。
  • 有人監視・テストセンター:リアルタイム対応や対面環境を要する試験の候補です。

入試や資格試験のように説明責任が重い場合は、人が再審査できる構成が適しています。

方式は、AIの検知率に加えて、誤検知時の再審査担当、判定理由の説明、障害時の再受験条件も見て比べます。

CBT-SolutionsのOLTCは、カメラ映像と試験画面を同時に監視できます。さらに、チャット・音声、警告、強制退出に対応する例も公開されています(出典: 株式会社CBT-Solutions「OLTC」、2026年8月確認)。

受験完了率と公平性まで含めた成功条件

開発の初めに、成功を不正検知だけで決めず、試験目的に合う目標値を設定します。

  • 受験状況:受験完了率、事前動作確認の通過率、問い合わせ率
  • 判定品質:通信断率、誤検知率、再審査時間、結果確定時間
  • 利用者評価:受験者満足度を候補にし、目的に応じた目標値

受験前には、禁止事項や撮影情報、保存期間を伝えます。判定の流れ、再受験条件、問い合わせ先も、あわせて示します。

説明と救済手続きを用意しておくと、誤検知や環境差による不公平を減らせます。

ポイント

迷ったときは、監視の強さより試験のリスクと受験者負担を基準に監視方式を選びます。成功は不正検知だけでなく、受験完了率と公平性でも見ます。

試験監督システム開発の六つのフェーズ

開発は、要件整理、選定、設計開発、テスト、稼働、定着の六段階で進みます。

各フェーズで何を仕上げ、どこで判断するかを決めておくと、納期と品質を両立しやすくなります。

フェーズ1:要件整理による試験と不正の定義

要件整理では、試験の前提、不正の想定、確認方法を順に洗い出し、その結果を資料にまとめます。

  • 試験の前提:目的、受験者数、ピーク時の同時接続数、試験時間、問題形式、受験場所、合否の重要度
  • 既存環境:既存システムと利用者ごとの権限
  • 不正の想定:なりすまし、替え玉、外部検索、生成AI、第三者の助言、問題の持ち出し、複数人受験
  • 確認と対応:本人確認、撮影・記録、要確認事象、人の再審査、再受験条件、問い合わせ応答時間、データ削除時期

業務フロー図や権限一覧、データ項目一覧を残しておくと、開発会社との認識のずれを防げます。

例外処理一覧やKPI案も残しておくと、後の確認に役立ちます。

フェーズ2:既製サービス・連携・開発範囲の選定

方式選定では、既製クラウドや試験運営委託、SaaSとAPI連携を比べます。パッケージのカスタマイズやスクラッチ開発も、同じ基準で比べます。

  • 既製サービス:問題形式と監視方式が標準的で、短期間に始めたい場合に有力です。
  • SaaS+API:既存のLMSや人事システムとの接続が必要な場合に候補です。
  • カスタマイズ・スクラッチ:独自の採点や審査、権限が競争力になる場合が対象です。

機能数だけで決めると実際の運用の差が見えにくいため、同じシナリオを使ってデモを依頼します。確認するのは、動作確認の失敗や通信断、AI誤検知への対応です。監督者の警告や異議申立て、一斉ログインへの対応も見ておきます。

障害からの復旧方法と、記録の残り方も比べておきます。契約前には、標準機能と追加開発の境界、更新時の責任を確かめます。データの保管場所や解約時の返却方法も、同じ時期に確認します。

フェーズ3:受験者・監督者・管理者の画面の設計開発

画面とデータは、利用者の役割と情報の扱い方に沿って設計します。

  • 受験者画面:申込から終了まで迷わず進める画面(本人確認、環境確認、途中保存、再接続を含む)
  • 監督者画面:多数の受験者を一覧表示し、通信状態と警告履歴から必要な人だけ拡大できる画面
  • 記録するデータ:問題・解答、本人確認情報、映像・音声、操作ログ、判定、問い合わせ履歴(分けて扱う)
  • 保護と監査:閲覧権限、暗号化、保存期間、削除、監査ログ、AI判定と人の最終判断を別々に記録
  • アクセス対策:MFA、SSO、最小権限、管理画面の制限、バックアップ、脆弱性診断(設計に含める)

フェーズ4:機能・端末・負荷・運用の一体テスト

テストでは、機能から運用まで一体で確かめます。

  • 負荷試験:ピーク人数での一斉ログイン、カメラ接続、問題取得、映像・操作ログ送信、結果確認
  • 容量設計:開始直前に集中する試験は、平均同時接続数だけでは決めません
  • 端末確認:OS、ブラウザ、カメラ、マイク、画面共有、通信速度、ポップアップ、電源、スマートフォンの設置状態
  • 総合リハーサル:本人確認失敗、生活音、眼鏡・照明による誤検知、通信断、ブラウザ停止、映像欠損、サポート連絡まで
  • 資料の修正:実際に使ったうえでの、受験者向けマニュアルと監督者向け台本の修正

フェーズ5:稼働日に判断できる体制づくり

稼働日に迷わず判断できるよう、担当者、時系列、障害対応を事前に整えておきます。当日は、ログイン集中、本人確認、監視開始、警告の順に場面が進みます。その後も、通信障害、途中保存、採点、結果通知の場面で判断が要ります。

  1. 試験事務局、監督者、ヘルプデスク、開発会社、クラウド運用担当の役割分担
  2. ログイン集中から結果通知までを時系列に並べ、誰が何分以内に判断するかを台本に記す
  3. 障害時の受験継続、保留、振替、再受験の基準(復旧まで受験者を待たせない対応を含む)
  4. 案内文、問い合わせ受付、障害記録、責任者への連絡先の準備(当日の判断を一人に頼らないため)

フェーズ6:KPIと審査改善による運用の定着

試験ごとに指標を振り返り、数値と運用の両面から改善します。

  • 受験状況:受験完了率、事前動作確認の通過率、問い合わせ率、通信断率
  • 本人確認と審査:本人確認失敗率、誤検知率、再審査時間、結果確定時間
  • 監督負荷:監督者1人あたりの確認人数

数値が悪いときは、まずシステムや問題文表示を見直します。受験者案内、監督者研修、監視ルール、再受験基準も、見直しの対象になります。

顔画像や映像を保存する場合は、定めた保存期間が過ぎたあとに削除します。

AIモデルや判定ルールの更新履歴も残しておくと、次回の説明に役立ちます。

ポイント

迷ったときは、各フェーズで何を仕上げ、どこで判断するかを先に決めてから次へ進みます。既製サービスか開発かの選定では、同じシナリオでデモを比べると違いを確かめられます。

試験監督システムの費用相場とコストの内訳

既製クラウドや運営委託、SaaSとAPI連携、独自MVP開発、大規模な本番基盤の初期費用レンジを横棒で比較した図。
方式が変わると、見積もりの価格帯も段階的に広がります。

費用は、受験者数や試験回数、監視方式によって変わります。映像・音声の保存期間、既存システムとの連携、受験者サポートの範囲も、費用を左右します。

以下の金額は、公開価格とリサーチノートを組み合わせた2026年時点の目安です。試験監督システム全体に共通する公定価格ではありません。

初期費用と、1人あたり・1回あたりの従量費は分けて確認します。

既製クラウドや運営委託の初期費用の目安(0万〜100万円程度)

既製方式は、小規模導入の初期費用と監視単価を分けて比べます。

  • 初期費用:標準的な問題形式を小規模導入する場合、0万〜100万円程度が比較レンジです。
  • OLTCの入口価格:環境条件が整えば50万円(税別)から導入できます。開発一式の確定価格ではありません。
  • 価格の条件:OLTCの料金は、試験設定や配信、監督、受験者サポートなどで変わります。
  • AI自動監視:公開価格がないサービスも多いため、比較用に1人あたり1,000〜5,000円程度を仮置きできます。
  • 有人個別監視:3,000〜15,000円程度を仮置きします。両単価は、類似サービスをもとに編集部が推定したもので、特定ベンダーの価格ではありません。

監督者や問い合わせ対応が費用に含まれるかを確かめます。本人確認や保存、再受験については、別に確かめておきます。OLTCの料金は、株式会社CBT-Solutionsの公開情報をもとにしています(出典: 株式会社CBT-Solutions「OLTC」、2026年8月確認)。

SaaSとAPI連携の費用の目安(300万〜1,000万円程度)

SaaSとAPI連携では、追加する業務機能と導入準備を分けて見積もります。

  • 費用・期間:申込サイト、LMS、人事、SSO、決済、帳票を接続する場合は、300万〜1,000万円程度、2〜6か月程度が目安です。
  • 上振れ要因:連携先、データ変換、問題移行、セキュリティ審査、受験者サポート、独自の合否判定が増えると、費用が上がります。
  • 適する組織:監視や試験エンジンは新たに作らず、独自の申込・会員・結果管理を加えたい組織
  • 導入事例:CBT-Solutionsでは、打ち合わせからOnline Test Centerでの試験開始まで約2か月と紹介されています。

事例では問題データと運用設計が整っていたため、自社要件にそのまま当てはまるとは限りません。準備期間は分けて見積もります(出典: 株式会社CBT-Solutions「生産マイスター検定」導入事例、2026年8月確認)。

独自MVP開発の費用の目安(800万〜2,000万円程度)

独自MVPでは、必要な機能と別途費用、検証範囲を分けて考えます。

  • 構築範囲:受験者・管理者画面、監督者コンソール、本人確認、監査ログ、再接続、最低限のAI連携
  • 費用・期間:800万〜2,000万円程度、4〜8か月程度(仮置き)
  • AIモデル開発:新規開発では、監視データ準備、精度評価、説明可能性の検証が別途必要です。
  • 検証と拡張:1試験・1運用での受験完了率と誤検知率の計測

複数試験を一つの基盤で管理する場合や、独自採点・審査、基幹連携を重視する場合は、MVP後の追加開発を含めた総額で判断します。

全機能を一度に作らず、検証結果を踏まえて本番機能へ広げると、不要な開発を抑えられます。

大規模な本番基盤の費用の目安(2,000万〜6,000万円以上)

複数試験や大規模運用では、初期費用だけでなく運用費も含めて比べます。

  • 対象規模:大学、資格団体、大企業が複数試験を運用し、数万人規模のピークに備える構成
  • 求める要件:有人監視センター、テストセンター連携、多言語、冗長化、第三者診断、厳格な監査など
  • 初期費用・期間:2,000万〜6,000万円以上、8〜18か月程度が比較レンジです。
  • 上振れ:高可用性、リアルタイム映像、運用要員を含むと6,000万円〜1.5億円超の可能性があります。個別要件から算出した編集部推定です。
  • 別途費用:クラウド、監視要員、問い合わせ、映像・音声・ログ保存、バックアップ、脆弱性対応、保守改修

保守費は、初期開発費の年15〜25%程度を仮置きします。有人監視やピーク時の増強も従量費として年間TCOに含めると、初期見積もりだけでは判断しにくくなります。

ポイント

迷ったときは、見積もりの金額だけを比べず、含まれる範囲と前提条件をそろえてから判断します。初期費用と運用費は分けて見ます。

試験監督システムの見積もりを取る際のポイント

見積もりで確認する機能と前提条件、監視と運用の費用、個人情報・セキュリティ・データ削除、負荷試験・受入条件・契約責任を4枚のカードに示した図。
確認領域をそろえると、各社の見積もりを同じ土台で比べられます。

見積もりの差は、開発会社の単価だけでなく前提条件の違いから生まれます。そのため、RFPに条件を明記し、同じ基準で比べます。

記載する条件の柱は、受験者数、試験回数、ピーク時間です。問題形式や監視方式、保存期間も書きます。既存システムとサポート時間も書きます。稼働日や再受験条件も、条件として記載します。

機能の範囲と前提条件を分けた記載

機能と前提条件を分けると、見積もりに含まれる範囲を比べられます。

  • 画面・試験機能:受験者・監督者・管理者画面、問題登録、採点を分けた項目
  • 監視・認証:本人確認、録画、リアルタイム監視、AI検知、有人再審査の別々の項目
  • 周辺機能:再接続、通知、帳票、権限、ログ、API、SSO、決済、サポート

「監視対応一式」と書かれていても、含まれる範囲は項目ごとに確かめます。

前提には、受験者数や同時接続数、対応ブラウザを書きます。試験時間や映像解像度、保存期間、試験回数も、前提として記載します。問題数、連携件数、管理者・監督者数も書きます。

前提外の追加単価と、変更時の手順も書面に残しておくと、開発途中の予算超過を防ぎやすくなります。

監視と運用の費用を初期開発費と分けた見積もり

監視方式ごとに担当範囲を明記し、初期費用と運用費は分けて見積もります。

  • AI自動監視:AIが自動で監視する範囲
  • AI抽出と有人審査:候補の抽出と、人による再審査の分担
  • 有人監視・テストセンター:リアルタイム監視や会場対応の範囲

監督者1人あたりの受験者数と、担当者を決めておくと、費用と運用リスクを把握できます。担当者は、警告や強制退出、異議申立ての場面ごとに決めます。判定確定や音声対応も含めます。

料金は、受験者1人あたりと試験1回あたりで分けます。月額や年間固定の費用は、別に示してもらいます。オプションや障害時の追加費用も、区別して示してもらいます。

保存容量や監視員の待機、土日祝のサポートが除外されると、試験直前に追加費用が生じます。再受験や振替、ヘルプデスクも除外されていないか確かめます。

個人情報・セキュリティ・データ削除の明記

情報の種類ごとに扱いを定め、利用目的と保護策を見積もりに含めます。

  • 対象データ:顔画像、本人確認書類、映像、音声、操作ログ、判定履歴(試験の重要度に応じた扱い)
  • 利用と委託:利用目的の通知、同意取得、委託先、海外クラウドの所在
  • 保護策:暗号化、アクセス権限、MFA、監査ログ、バックアップ、脆弱性診断、インシデント対応
  • 保存と削除:保存期間と削除証跡(見積もりに含める)

個人情報保護委員会のガイドラインでは、顔画像だけでなく映像や音声も個人に関する情報に含まれ得ると整理されています(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年8月確認)。

教育機関は、文部科学省が令和7年3月に改訂した「教育情報セキュリティポリシーに関するガイドライン」と自組織の規程を照合します。セキュリティ審査の工数も、見積もりに含めておきます。

負荷試験・受入条件・契約責任の確認

受入条件と契約上の責任を具体的に決めておくと、完成後の認識違いを防げます。

  • 受入条件:想定ピーク時の受験完了率、ログイン集中時の応答、映像・音声の欠損、再接続の基準
  • 試験・記録:本人確認失敗や監督者の警告、判定履歴、結果連携、データ削除の条件
  • 試験基準:負荷試験の人数、試験時間、通信条件、合格基準(契約書や仕様書に記載)
  • 開発会社の責任:要件定義責任者、品質保証、障害時のSLA、監視員教育、運用移管
  • 契約終了と委託:所有権、第三者サービス停止時の対応、データの返却・消去。委託時は、最終判定者と説明責任者の役割も明確にします。

ポイント

迷ったときは、RFPに条件を明記し、同じ基準で各社の見積もりを比べます。機能、監視と運用、個人情報、受入条件を項目ごとに分けると、金額の差の理由が見えます。

試験監督システム開発でよくある質問

初期検討でよく問われるのは、既製サービスで足りるかどうかや、AIと有人の使い分けです。

開発期間や個人情報の扱いも、質問として多く挙がります。

試験監督システムは既製サービスで十分ですか?

標準的な選択式試験で、監視方式と問題形式が既製サービスに合い、短期間で始めたい場合は十分な可能性があります。

独自採点や複雑な申込、既存基幹との深い連携がある場合は、SaaS+API連携やカスタマイズを検討します。

特殊な審査や独自のデータ保管要件があるときも、検討の対象になります。

AI監視と有人監視はどちらがよいですか?

選ぶ際は、試験の厳格性や受験者数を基準にします。予算や説明責任も、判断材料になります。AIは、大量の受験者から確認対象を絞る用途に向いています。

有人監視は、その場での注意喚起や例外の判断に適しています。特に、公平性が必要な試験では、AIの検知を人が再確認する方法が現実的です。

試験監督システムの開発期間はどのくらいですか?

方式別の期間は、既製サービス、連携、独自開発の順に長くなる傾向があります。

  • 既製サービス:条件が整えば、設定から運用開始まで数週間〜2か月程度
  • SaaS連携:2〜6か月程度が比較の目安
  • 独自MVP:4〜8か月程度が比較の目安
  • 本番基盤:8〜18か月程度が比較の目安

期間は、問題データの準備やセキュリティ審査を含むかどうかで変わります。受験者説明や負荷試験を含むかも、期間を左右します。

サーティファイのスマート入試は、特別なインストール不要で、申込から30日で実施できると案内しています(出典: 株式会社サーティファイ「教育機関版スマート入試」、2026年8月確認)。

顔画像や監視映像はどのように扱えばよいですか?

本人確認や不正判定に必要なデータを決めたうえで、受験者へ説明する事項と示す事項を整理します。

  • 説明する事項:利用目的、取得情報、保存期間
  • 示す事項:閲覧担当者、委託先、削除方法

保存しない方式が選べる場合は、証跡の必要性とプライバシー負担を比べます。保存する場合は、暗号化とアクセス制御を設計します。監査ログや削除証跡も、設計に入れます。

教育機関では、文部科学省のガイドラインと自組織の規程を確認します。

法務や情報セキュリティの担当者は、早い段階から巻き込んでおきます。

ポイント

迷ったときは、既製サービスで足りるか、AIと有人のどちらが合うかを、試験の厳格性と受験者数で判断します。期間は方式ごとの目安で比べ、映像は利用目的と保存期間を示してから扱います。

まとめ

開発は監視機能から作り始めず、まず試験目的と不正の定義を決めます。

そのうえで、受験者への説明と、判定と救済のルールを固めてから進めます。

要件整理から定着までの六つの段階を順に進めると、システムと試験運営のずれを小さくできます。

1試験のPoCと同じ条件の見積もり依頼

初期相談では、受験者数とピーク、試験方式、問題形式を一枚にまとめます。監視強度や本人確認も、その中に含めます。既存連携とデータ保存、当日サポートも、その中に入れます。

1試験・1拠点のPoCで、受験完了率や誤検知率、問い合わせ率を測ります。監督者負荷も測り、その結果をもとに本番範囲を決めると、判断しやすくなります。

費用と機能に加えた公平性と定着の比較

見積もりは、初期費用に加えて年間TCOで比べます。年間TCOには、受験者単価、監視員、問い合わせが含まれます。さらに、保存や保守、再受験、障害対応も含めて考えます。

AIの誤検知を人が再確認できるか、判定理由と異議申立てを記録できるかを確かめます。受験者への説明ができるかも、確かめておきます。これらを押さえると、公正な試験運営につながります。

▼全体ガイドの記事
・試験監督システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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