試験監督システム開発の発注/外注/依頼/委託方法について

試験監督システムの発注は、試験の目的とリスクを整理するところから始めます。続けて要件と運用条件を明文化し、PoCと受入テストで確かめれば、公平性と受験者の利便性を両立できます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

試験監督システムの発注・外注の全体像

試験監督システムは、受験申込から結果通知までをつなぐ業務システムで、問題を表示するだけのWebテストとは性格が異なります。受験申込、本人確認、端末チェック、問題配信、監視、疑わしい行動の記録、採点、結果通知、問い合わせ対応を、この一連の流れでつなぎます。

発注時には、開発の範囲だけでなく、試験当日の運用担当者も決めておく必要があります。

Webテストと試験監督システムの違い

Webテストは、問題を配信して解答を集計する機能が中心です。

試験監督システムは、本人確認に加えて、許可された端末や場所での受験と禁止操作の有無を確かめ、後から説明できる証跡を残します。

• 本人確認：顔写真や身分証で受験者を照合する仕組みです。
• 受験状況の監視：カメラ、マイク、画面共有などで受験の様子を見ます。
• 操作の記録：タブ切替や離席、複数人の検知を記録する機能です。

監視機能を組み合わせるぶん、通常のLMSやアンケートフォームより要件は複雑になります。

開発と試験運営の分担

開発会社、既製プラットフォーム会社、運営会社は、それぞれ得意分野が異なります。そのため、発注先を探すときに開発会社だけを比べると、判断を誤りやすくなります。

• システム開発会社：独自の機能や連携の開発を担います。
• プラットフォーム提供会社：既製の試験環境を提供します。
• 運営会社：有人監視やヘルプデスクの運営が中心です。

システムを所有したいのか、安定して試験を実施したいのかを分けて考えます。なお、運営委託を含めると、監督者の採用や当日対応を自社で抱えずに済む場合があります。

発注形態の選び方

発注形態は、既製クラウド、既製サービスの連携・カスタマイズ、独自開発の3段階で考えます。試験回数が少ないのに大規模な開発を選ぶと、過剰投資になります。逆に、特殊な要件を標準SaaSだけで賄うと、手作業が増えます。

既製クラウド・運営委託が向いているケース

資格試験や社内研修のように、標準的な問題形式と合否判定で短期間に始めたい場合に適しています。

• 既製クラウド：標準機能だけで試験を始められる選択肢です。
• 試験運営委託：当日の監視や受験者対応も任せられます。

CBT-SolutionsのOLTCは、条件が整えば50万円（税別）から導入できると案内されています（出典: 株式会社CBT-Solutions「OLTC」、2026年確認）。

ただし、この価格は開発一式の確定価格ではありません。受験者数、監視、連携の条件で変わるため、問題登録やヘルプデスクを含むかどうかも確認します。

SaaS＋API連携・カスタマイズが向いているケース

申込は自社サイト、受験者情報は人事や学務のデータベース、結果はLMSや資格管理システムで扱う場合に当てはまります。SaaSを中心に据え、APIやCSVで既存システムと連携します。

• 既製サービスに任せる機能：本人確認や監視など、専門性の高い機能です。
• 個別に開発する機能：申込画面、権限、帳票、結果通知の部分です。

既製サービスに任せる部分を増やすほど、初期投資を抑えられます。そのぶん、将来の試験追加にも対応しやすくなります。

契約の前に、APIの利用制限やデータの返却形式、障害時にどこまでを誰が受け持つかを確かめます。

スクラッチ開発を選ぶべき条件

独自開発を選ぶかどうかは、必要な機能と運用の責任を合わせて見極めます。

• 独自要件：独自の問題形式や採点、学籍・出願・人事システムとの密接な連携が、競争力や事業継続に直結する場合。
• 規模・監査：厳格な監査や数万人規模のピーク対応が必要な場合。
• 開発・運用範囲：受験者・監督者画面、映像・操作ログの保管、再接続など。
• 長期費用：負荷試験、脆弱性診断、当日ヘルプデスクを含め、5年程度の運用費と改修費をTCO（総所有コスト）で判断します。

試験監督システムの発注・外注の進め方

まず、試験の目的と当日の業務を整理してから、ベンダーへ相談します。完全な仕様書は必要ありませんが、受験者数、監視方式、試験回数の3点は、相談の時点で揃えておきます。

連携先、保存データ、開始希望時期も併せて伝えると、前提が揃い、ベンダーの見積もりを同じ土台で比べられます。

試験の目的とリスクの定義

まず、試験が入学判定や資格認定などのどの用途に使われるかを明確にします。用途によって必要な監視の強さや異議申立ての扱いが変わるため、ここを先に決めておきます。

• 不正リスク：替え玉や生成AI・検索の利用、問題の漏えいを洗い出します。
• 運用リスク：通信断、誤検知、アクセシビリティ不足への備えを検討します。
• 判断基準：「不正とみなす行為」「警告する行為」「人が再確認する条件」「再受験を認める条件」を決めます。

判断基準を先に決めておくと、AIのアラートを過信する設計を避けやすくなります。

RFPでの機能・非機能・運用の書き分け

RFPには、機能要件、非機能要件、運用要件を分けて書きます。

• 機能：申込、予約、決済、本人確認、問題バンク、ランダム出題の範囲。
• 機能：記述式、自動採点、監督者の警告、結果通知、CSV・API連携。
• 非機能：同時接続数、ピーク時の処理、復旧目標、対応ブラウザ、スマートフォン利用。
• 非機能：SSO、MFA、暗号化、監査ログ、脆弱性診断に関する条件。
• 運用：試験前の動作確認、当日の問い合わせ、通信断、再受験、異議申立ての手順。

映像の保存期間と削除方法も、運用要件に書いておきます。

PoCと受入テストによる検証

候補を絞ったら、1種類の試験を限られた受験者で試すPoCを行います。

• 受験の成立：カメラ・マイク確認の通過率と受験完了率。
• 運用負荷：問い合わせ率と、監督者1人が確認できる人数。
• 障害対応：通信断からの復帰の確認。
• 判定確認：AIアラートの再審査にかかる時間。

CBT-Solutionsの公開事例では、打ち合わせからOnline Test Centerでの試験開始まで約2か月かかっています（出典：株式会社CBT-Solutions「生産マイスター検定導入事例」、2026年確認）。

約2か月という期間は、問題準備や説明会を含む個別事例のもので、独自開発の納期とは異なります。

受入テストでは、正常系に加えて、カメラ断やPC再起動、複数人の映り込みを確かめます。さらに、監督者の警告や結果データの二重登録も対象にします。

テスト項目と合格条件、再試験の扱いは、契約書や発注仕様書に残しておきます。そうすると、納品後の認識違いを防げます。

契約形態と役割分担

契約では、開発費に加えて、クラウド利用や監視、個人情報の扱いも複数の契約や条項で整理します。要件の確定度と運用期間に合わせて契約形態を選び、発注者と委託先の責任範囲を明文化します。

請負・準委任・SaaS利用の使い分け

要件定義を終えた開発は、成果物と合格条件を明確にできるため、請負契約と相性がよい場合があります。

• 請負契約：成果物と合格条件を定めた開発で使われます。
• 準委任契約：作業時間や役務を前提とし、企画やPoC、アジャイル開発、専門家支援に適する場合があります。
• SaaS利用：利用規約やサービス約款で条件を整理します。
• 運営委託：業務委託契約とSLAによる役割の取り決め。

複数の契約にまたがる障害では、一次窓口と原因調査の責任を前もって決めておく必要があります。

試験当日のSLAと運用分担

SLAでは、稼働時間と障害の重要度に加え、受付から一次回答までの時間と復旧目標を取り決めます。

• 連絡と補償：連絡手段と、補償の考え方。
• 受験者対応：問い合わせ窓口の担い手。
• 監視体制：監督者の教育と交代要員の確保。
• 判定責任：不正の疑いを最終的に誰が判断するかを決めます。

JJSplusのHURREP公式情報では、有人監視やAI検知、画面共有などを組み合わせた運用が紹介されています。自社に必要な時間帯や言語、監視人数に対応できるかも、契約の前に確かめます。

データ・知的財産・再委託の契約条項

契約では、個人情報の取扱い、知的財産、事業者が変わるときの引き継ぎを明確にしておく必要があります。

個人情報保護委員会は「個人情報の保護に関する法律についてのガイドライン（通則編）」を示しており、同ガイドラインでは、映像や音声も個人に関する情報に含まれると説明されています（2026年確認）。

• 情報の保護：顔画像や本人確認書類、映像、音声、操作ログ、判定履歴の目的と保存期間。
• 管理と委託条件：保存場所、暗号化、アクセス権限、監査、漏えい報告の取り決め。返却・削除、海外移転、再委託の承認も含みます。
• 知的財産：問題データ、採点ロジック、画面、連携部分ごとの著作権と利用権。
• 変更への備え：標準形式でのデータ返却、API仕様書、ソースコードや設定情報の扱い。
• AIモデルの更新：判定結果が変わる場合の、更新履歴と影響範囲の記録。

試験監督システムの費用相場

試験監督システムの費用は、受験者数や試験回数、監視方式によって変わります。問題形式や連携数も影響し、映像の保存期間と受験者サポートの時間帯も費用を左右します。なお、一律の公定価格は示されていないため、数字は目安として捉えます。

2026年時点の価格は、公開サービスの入口価格と開発工数の試算を分けて見ると、比べやすくなります。

発注形態別の費用レンジ

発注形態ごとの費用は、公開価格と編集部の試算を区別して読む必要があります。

• 既製クラウド・運営委託：小規模導入の初期費用は、0万〜100万円程度が確認の目安です。
• SaaS＋自社システム連携：300万〜1,000万円程度の仮置き。
• 独自開発のMVP：監視画面や管理画面を含めて、800万〜2,000万円程度を検討の起点とします。
• 大規模・高要件の開発：大学、資格団体、大企業向けで複数試験を含む場合、2,000万〜6,000万円以上が目安です。

OLTCの公開例は、条件が整えば50万円（税別）からです。監視員、問題登録、決済、ヘルプデスク、連携の有無によって、この額は変わります。

SaaS連携の試算は、導入期間を2〜6か月程度と見ています。要件定義から連携、テスト、セキュリティ審査までを含んでいます。なお、これは個別の市場統計ではなく、比較用のレンジです。

独自開発のMVPは4〜8か月程度を想定しています。ただし、いずれの期間も確定した納期ではありません。

数万人規模のピーク対応や有人監視センター、多言語、第三者診断まで含む場合は、要件によって6,000万円〜1.5億円超になることもあります。

これらは、一般的な開発工数に映像配信や高可用性、個人情報の要件を加味した編集部の推定です。確定した相場とは分けて読みます。

見積書の初期費用と運用費の分け方

見積もりは、初期構築と運用の項目を分けて確かめます。

• 初期構築：要件定義や設計、受験者・管理・監督者の各画面。
• 連携と移行：認証・決済との連携、問題登録と移行。
• 品質確認：負荷試験や脆弱性診断、マニュアル、研修の費用。
• 継続費用：監視サービス、クラウド、保守をそれぞれ別に記載します。
• 映像関連：保存の容量と期間、閲覧や再審査の作業費。

AI自動監視は受験者1人あたり1,000〜5,000円程度、有人個別監視は3,000〜15,000円程度を仮に置けます。これは公開共通価格ではなく、監視条件を踏まえた編集部の推定です。

保守費用は、初期開発費の年15〜25％程度を仮に置いておきます。そのうえで、クラウドや監視要員の費用、問い合わせ対応、ピーク時の増強、脆弱性対応まで含めて、年間TCOを作ります。

受験者1,000人、5,000人、1万人の3パターンで、年間の試験回数と監視方式を揃えて見積もります。初期費用が安くても、従量課金や有人対応が加わると総額が逆転することがあります。そのため、受験者数の増加も見込んで、3年分の費用を比べます。

費用を抑えつつ品質を保つ方法

試験の重要度に合わせて監視レベルを変えると、必要な公平性を保ちながら費用を調整できます。

• 練習テスト：監視なしの実施。
• 本試験：AI検知と人による再審査の組み合わせ。
• 国家資格級の試験：有人監視の導入を検討します。

初回は標準の選択式問題とCSV連携に絞り、利用状況を見て機能を追加する方法もあります。記述式や多言語、複雑な帳票は後から加えられます。また、問題データを自社で登録すれば、毎回の作業委託費を抑えられる場合があります。

委託先選定と見積比較のポイント

委託先は、試験目的に合う実績と運用体制を軸に選びます。知名度や価格も比べますが、それだけで選ぶことは避けます。

開発会社に相談する場合も、試験運営会社やプロクタリング会社との連携の有無を確かめます。

候補には同じRFPを渡し、受験者数や試験回数、保存期間、監視方式の条件を揃えて見積もりを依頼します。

候補会社の実績とデモ

実績は、オンライン試験の導入件数に加えて、自社に近い試験の条件や当日の体制から確かめます。

• 試験条件：規模、監視方式、問題形式、受験者属性の比較。
• デモ範囲：受験者登録から受験までの流れを見ます。警告や再接続、判定、結果出力も含みます。
• 運用体制：当日の問い合わせ対応の内容。

CBT-Solutionsは、公式情報で16人同時監視やチャット・音声による受験者対応を掲げています（出典: 株式会社CBT-Solutions「OLTC」、2026年確認）。

同時監視の条件や監督者数は試験設計で変わるため、自社のピーク人数で再確認します。

AI監視では、検知率に加えて、アラートの対象と誤検知を人が確認できるかを聞きます。判定理由を受験者や主催者へ説明できるかも、あわせて聞きます。さらに、モデル更新時に過去の判定を再計算するかどうかも確認します。

有人監視では、監督者の教育と1人あたりの担当人数を確かめます。加えて、スーパーバイザーの配置や多言語対応、夜間・休日の対応も見ます。

見積書の5つの費用区分

見積書は、費用が発生する場面ごとに5つの区分へ分けて比べます。

• 初期構築：構築、問題登録、動作確認の費用。
• 従量費：1回あたり、または1人あたりの費用。
• 年間固定費：継続利用で発生する費用。
• オプション：API連携などの追加機能にかかる費用。
• 障害・再試験：障害や再受験のときにかかる費用。

監視料に事後確認が含まれるか、API費用が何本目から発生するかを確かめます。見積書の「一式」とある項目は、内容や数量、単価、完了条件を質問します。

価格以外には、要件への適合や期間、拡張性を評価します。セキュリティや運用、データ移行、契約の柔軟性も併せて見ます。

最も安い見積もりでも、映像取得の遅延や障害連絡の自社対応、海外受験ができないことによって、担当者の隠れた工数が膨らむ場合があります。比較表には「できる・条件付きでできる・できない・要確認」の区分で記録しておくと、社内説明に使えます。

発注前に確認したい失敗リスク

発注前には、試験の技術面や判定、個人情報、受験者対応のリスクを洗い出します。

教育機関では、2025年3月に改訂された文科省のガイドラインも確かめておきます（出典：文部科学省「教育情報セキュリティポリシーに関するガイドライン（令和7年3月）」、2025年）。

• 通信・障害：試験当日の通信量の想定と、通信断時の猶予、再受験の判断。
• 判定・映像：AIアラートを不正判定と誤認しないことと、顔画像や映像を長期保存しない条件。
• 受験者支援：体験試験を用意し、カメラを使えない場合の代替手段も決めます。
• 利用環境：端末や通信環境の差、スマートフォンの配置、支援が必要な人への配慮。
• 個人情報と端末：権限やアプリは最小限にし、撮影内容と削除時期を説明します。

自校や自治体の情報セキュリティ基準とクラウド利用方針に合っているかも、確かめる必要があります。

よくある質問

発注では、費用のほかに、監視の公平性や個人情報、当日の責任分担についての質問がよく出ます。委託先との初回相談の前に確認しておきたい疑問に、質問ごとに答えます。

試験監督システムは無料で発注できますか？

小規模な試験は、無料フォームや既存LMSで配信できます。

• 機能の範囲：厳格な本人確認や有人監視、監査ログ、受験者サポートまで、無料で得られるとは限りません。
• 総費用：重要な試験は、監視や保存、問い合わせ、障害対応を含めた年間TCOで比べます。
• 価格条件：公開価格がある場合も、条件と追加費用を見て判断します。

AI監視と有人監視はどちらを選べばよいですか？

選ぶときは、試験の重要度や受験者数、受験者の環境、誤検知時の救済方法で決めます。

AI監視は大量の受験からアラートを絞り込みやすく、有人監視はその場の状況確認や声かけに強みがあります。高い公平性が必要な試験では、AIを補助に使い、疑わしいケースを人が再確認する方式が候補になります。

RFPがなくても試験監督システムを外注できますか？

RFPがなくても外注はできますが、候補ごとに前提が違うため、価格と納期を比べにくくなります。

• 最低限の条件：目的や受験者数、試験回数、監視の希望、既存システムを1枚にまとめます。
• 開始・保存条件：開始時期と保存データを整理しておくと、初回提案の精度が上がります。
• 要件整理の支援：ベンダーに依頼するなら、要件定義の費用と成果物を見ておきます。

監視映像や顔画像はどのくらい保存しますか？

保存期間は、試験の性質や異議申立ての期間を踏まえ、必要最小限に定めます。

• 保存期間の条件：契約や社内規程も踏まえて決めます。
• 長期保存の負担：長く残すほど安心とは限らず、漏えい時の影響や保管費、閲覧管理の手間が増えます。
• 保存方式：保存しない方式や、アラート部分だけを短期間残す方式も検討します。
• 削除と再審査：利用目的や削除日、削除の証跡、再審査期限を、RFPとプライバシー通知に記載します。

まとめ

発注時には、試験の目的と不正リスク、受験者数を整理します。監視の強さと既存システムとの連携も、あわせて決めておきます。そのうえで、既製クラウド、既製サービスの連携・カスタマイズ、独自開発を比べ、開発と運営の委託範囲を決めます。

発注前にRFPへ入れる項目

RFPと見積もりには、試験運営の条件と費用の比較の軸を揃えて書きます。

• 業務と要件：受験申込から結果通知までの業務、機能・非機能要件、当日の運用。
• 例外と受入：個人情報の保存と削除、障害時の再受験、受入テストの条件。
• 費用区分：初期費用、従量費、年間固定費、オプション、障害・再試験費用ごとに分けます。
• 長期比較：受験者数別の3年TCOで比べると、導入後の予算差を把握しやすくなります。

小規模な検証と本番発注の順序

候補会社には同じ条件で提案を依頼し、デモとPoCで本番運用を検証します。

• 試験環境：動作確認と、通信断への対応。
• 監視・判定：誤検知の再審査と、監督者の操作。
• データ連携：結果連携が要件どおりに動くかどうか。

価格のほかに、公平性と受験者の安心を守れるか、担当者が継続して運用できる体制かも見極めます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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