オンライン試験システム開発の発注/外注/依頼/委託方法について

オンライン試験システムの発注・外注は、受験方式と監視レベル、受験者数、運用代行の範囲を先に決め、RFPで同じ条件を複数社に示して比較することが成功の近道です。

オンライン試験は、研修後の理解度テストから採用試験、社内昇格試験、資格検定、学校入試まで用途が幅広く、必要な機能と費用も大きく変わります。この記事では、発注形態の選び方、要件整理とRFPの作り方、契約形態、費用相場、委託先の選定、見積書の比較方法まで、発注担当者が社内稟議からベンダー選定まで進めるための実務を解説します。

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

オンライン試験システムの発注で最初に決めること

発注で最初に決めるのは、製品名や画面デザインではなく、どの試験をどの厳格さで運営するかです。研修の理解度確認と国家資格では、本人確認、監視、問題管理、障害対応、監査証跡に求められる水準が異なります。

採用試験や社内研修であれば、受験者登録、制限時間、自動採点、合否通知、受験履歴が整えば始められる場合があります。一方で、資格試験や入試では、なりすまし、問題漏えい、生成AIや外部資料の利用、通信断、端末差、採点訂正まで想定しなければなりません。試験が止まった場合に受験機会や合否の公平性へ影響するなら、ベンダーに求めるSLA、監視体制、振替ルール、問い合わせ窓口を発注条件に含めます。

候補を絞るときは、用途、規模、厳格性の3軸を使うと、価格だけの比較を避けられます。用途は研修・社内テスト、採用・昇格、資格・入試に分け、規模は数十人、数百人、数千人から数万人に分けます。厳格性は、監視なし、環境チェックと本人確認、AI監視と人手レビュー、会場監督を含む運用というように段階化します。同じオンライン試験でも、数十人の社内テストに大規模CBTの構成を採用すれば過剰投資になり、重要試験を簡易なアンケート機能で代用すれば公平性を損ないます。

オンライン試験システムの発注形態はどれを選ぶべきですか？

結論として、短期間で標準的な試験を始めるならクラウド型、既存業務との統合や厳格な運用を重視するなら専用環境・パッケージ型、独自の採点や受験体験が競争力になるならスクラッチ型が候補です。ただし、すべてを新規開発する必要はありません。問題配信や採点エンジンは既存サービスを利用し、会員管理や業務フローなど差別化したい部分だけを連携・開発する構成も現実的です。

クラウド型は、サーバー調達や基本的なアップデートを自社で抱えずに済み、数十人から数百人の社内試験を比較的短期間で始めやすい方式です。受験者管理、問題登録、自動採点、合否判定、結果出力が標準化されているため、初回は設定と問題データの登録に集中できます。導入前に、同時アクセス数、動画・音声の対応、外部認証、データのエクスポート、保存期間、退会後の削除、問い合わせ対応が料金内か確認します。

パッケージ型や専用クラウドは、問題バンク、受験者DB、SSO、LMS、人事・会員システム、決済、資格証発行などを組み合わせやすい方式です。自社のセキュリティポリシーやデータ保管要件を反映しやすい一方、初期設定、カスタマイズ、移行、負荷試験の費用が加わります。オンプレミスを選ぶ場合は、導入時の費用だけでなく、OSやミドルウェアの更新、脆弱性対応、バックアップ、障害復旧を誰が担うかまで5年程度のTCOで比較します。

独自の出題アルゴリズム、記述・動画・音声を使った評価、複雑な受験資格、既存データとの高度な連携、監査用の詳細ログなどが必要なら、スクラッチ開発を検討します。ただし、試験システムは一度動けば終わりではなく、問題の改訂、再採点、本人確認の誤判定、ブラウザ更新、障害時の振替を継続的に扱います。開発会社へすべてを任せる場合でも、標準機能で代替できる部分と独自開発する部分をRFPで分け、将来の保守費を見える化します。

発注前の要件整理はどの順番で進めますか？

要件整理は、機能一覧を先に埋めるより、試験業務の現状と本番のリスクを可視化する順番が適切です。申込から結果通知までの業務を時系列に並べ、誰が何を判断し、どのデータを次の工程へ渡すかを確認します。そのうえで、必須要件、できれば欲しい要件、将来検討の要件に分けると、見積もりの前提がぶれにくくなります。

まず、受験者の募集、申込、本人確認、受験資格の審査、受験料決済、受験票の発行、端末確認、受験、採点、再採点、合否判定、結果通知、問い合わせ、合格証発行までを書き出します。団体申込や免除科目、再受験、欠席、受験料返金がある場合は、通常ケースだけでなく例外ケースも記録します。試験事務局がExcelやメールで行っている作業をそのままシステム化するのではなく、重複入力や承認漏れをなくす業務ルールも同時に決めます。

問題要件では、単一選択、複数選択、記述、画像、動画、音声の形式、配点、分野別の出題数、選択肢のシャッフル、問題の出題期間、問題の改訂履歴、公開範囲を決めます。採点要件では自動採点と人手採点の境界、部分点、合格基準、再採点、採点結果の確定者を明確にします。受験環境では対応OS・ブラウザ、スマートフォン可否、カメラ・マイク、通信速度、途中保存、再接続、試験中の問い合わせ方法を記載します。大学入試センターが2025年に公開した「CBT導入時の検討事項リスト」も、受験者端末や運用モデルを整理する際の参考になります。

本人確認書類、顔画像、カメラ映像、音声、監視ログは、受験者の個人に関する情報として扱う必要があります。個人情報保護委員会のガイドライン（2026年改正）では、本人を判別できる映像情報や、特定の個人を識別できる音声録音情報が個人情報に該当する事例として示されています。そのため、利用目的、取得時の説明、委託先の範囲、アクセス権限、暗号化、保存期間、削除方法、国外保管の有無をRFPに含めます。監視をAIに任せる場合も、誤検知の人手レビュー、受験者からの異議申立て、合理的配慮、判定の再確認を決めておくことが重要です。

オンライン試験システムのRFPには何を書きますか？

RFPは「高機能なシステムが欲しい」と伝える文書ではなく、ベンダーが同じ条件で提案と見積もりを作るための発注仕様書です。背景、目的、対象者、想定規模、業務フロー、必須要件、非機能要件、納期、予算の考え方、提案方法、契約条件を一つの文書にまとめます。未確定な項目は無理に決めず、提案してほしい選択肢として明示すると、各社の提案力も比較できます。

業務要件には、試験の種類、受験者数、年間の実施回数、申込期間、試験時間、同時受験者数、問題数、合格基準、再受験、免除、団体申込、決済、結果通知を記載します。データ要件には、受験者、試験、科目、問題、選択肢、解答、採点、合否、監視記録の項目と保持期間を整理します。運用要件には、問題登録の担当者、試験当日の監視者、問い合わせ窓口、障害時の意思決定者、月次レポート、保守時間を記載します。受験者数は年間の延べ人数だけでなく、ピーク時の同時アクセス数と、開始直後にアクセスが集中する割合を分けて示します。

「安全で使いやすい」という表現だけでは、各社が異なる前提で見積もってしまいます。可用性、性能、拡張性、セキュリティ、操作性、保守性を、可能な範囲で測定できる条件に変換します。例えば、同時受験者数、画面応答の目標、復旧時間、バックアップ頻度、障害連絡の初動、脆弱性診断の実施時期、ログの保存期間、MFAの対象、管理者権限の分離を記載します。IPAの「IT製品の調達におけるセキュリティ要件リスト」第2.1版（2026年）は、調達時のセキュリティ要件を具体化する際の確認材料になります。

提案依頼時には、初期構築、月額・年額、受験者単価、監視単価、問題登録・移行、連携開発、テスト、教育、保守、運用代行、追加費用を分けて記載するよう依頼します。標準機能、設定、カスタマイズ、外部サービス、オプションを同じ見積書で区別してもらいます。さらに、代替案として「標準クラウドで早く始める案」「専用環境で統制を高める案」「段階導入で初期投資を抑える案」を求めると、価格とリスクの関係を判断しやすくなります。

契約形態は請負と準委任をどう使い分けますか？

契約形態は、成果物と仕様を固められる工程は請負、要件を検証しながら進める工程は準委任とする使い分けが基本です。オンライン試験は、試験制度や問題データ、監視方針が途中で変わりやすいため、最初から全工程を一つの請負契約に固定すると、変更管理と追加費用の交渉が複雑になりやすいです。法務・情報システム部門と相談し、成果物、責任分界、検収方法、変更手順を契約書と仕様書に落とします。

請負契約は、要件定義書、画面・API仕様、プログラム、テスト結果、操作マニュアルなど、納品対象が明確な場合に向いています。検収では、正常系の画面が動くことだけでなく、通信断からの復帰、制限時間、問題シャッフル、途中保存、採点訂正、権限分離、同時アクセス、バックアップ復元などを受入テストに含めます。重大な不具合の定義、修正期限、検収期間、第三者サービスの障害時の扱い、納品後の著作権・利用権も確認します。

準委任契約は、作業時間や専門知識の提供を受けながら、要件定義、PoC、運用設計、データ移行、継続改善を進める場合に使いやすい形態です。試験の実証を少人数で行い、受験者の操作や問い合わせを見てから本番仕様を決める場合は、準委任で検証し、その後に確定した開発範囲を請負へ移す方法があります。ただし、作業時間だけを管理すると成果が見えにくいため、月次の成果物、課題一覧、意思決定事項、次月の計画、品質指標を定例会で確認します。

契約で見落とされやすいのが、問題データの著作権、受験者データの所有権、監視映像の保管者、ログの利用範囲、解約時のデータ返却、API停止時の代替手段です。クラウドを使う場合は、ベンダーの障害とクラウド基盤の障害を誰が受け付け、何時間以内に連絡するかを決めます。個人情報を扱う委託先には、再委託の承認、アクセス権限、監査、事故報告、削除証明、国外のデータセンター利用を確認し、契約と運用手順を一致させます。

オンライン試験システムの費用相場はどのくらいですか？

費用は、標準クラウドの月額利用から、連携・監視を含む数百万円規模、独自開発と大規模運用を含む数千万円から数億円規模まで広がります。受験者数だけでなく、同時アクセス、問題形式、本人確認・監視、運用代行、既存システム連携、セキュリティ試験が金額を左右するため、単一の「オンライン試験システムの相場」で判断してはいけません。以下は公開料金と公的試算をもとにした2025〜2026年時点の予算検討用レンジです。

研修や社内テスト向けのクラウドは、比較情報上、月額1万円から50万円程度が一つの目安です。公開料金の実例として、インソースのLeafは、50IDで月額16,250円、300IDで67,500円、1,000IDで115,000円、3,000IDで225,000円です。テスト制限時間機能は初期120万円から、シャッフルテスト機能は初期240万円からと案内されています（株式会社インソース「Web試験運用パッケージ」、2026年確認）。同じように見える月額サービスでも、問題登録、初期設定、カスタマイズ、サポートが別費用の場合があるため、初年度総額で比べます。

数百人から数千人を対象に、問題バンク、SSO、LMSや人事DBとのAPI連携、決済、本人確認、監視ログ、負荷試験を組み込む場合は、初期費用が数百万円から1,000万円超まで広がることがあります。公開相場の比較情報では、数百名規模のパッケージ導入を100万円から300万円程度、数千名規模を500万円以上とする例がありますが、監視や運用代行を含むかで前提が変わります。したがって、発注時は初期費用だけでなく、年間利用料、受験者単価、同時接続超過、データ保管、保守、問い合わせ、脆弱性診断を合算します。

大規模試験では、システム開発だけでなく、会場、端末、監督者、申込・決済、コールセンター、問題バンク、監査、障害時の振替まで費用になります。厚生労働科学研究のCBT費用試算では、受験者約1万人、全国13会場を想定し、TAO実装や問題バンクなどを含む開発費2億6,800万円の例が示されています（厚生労働科学研究補助金、2024年度公開資料）。これは医療系試験の特殊条件を含む個別試算で、市場平均ではありませんが、数万人級の厳格な試験を新規構築する場合に、数千万円から数億円になり得ることを示す参考材料です。

委託先の選定と見積比較では何を確認しますか？

委託先は、システムを開発できるかだけでなく、試験を安全に運営できるかで選びます。受験者規模、試験方式、監視の厳格性、運用代行の範囲、既存連携、障害対応、データの持ち出しやすさを同じ質問票で確認します。価格が安い会社を選ぶのではなく、見積もりの前提が自社の業務と一致し、想定外の追加費用と運用負担が少ない会社を選ぶことが重要です。

「導入実績があります」という説明だけでは不十分です。IBTかCBTか、ピーク時の同時受験者数、申込・決済から合否通知までの範囲、問題登録や採点の担当、コールセンターの有無、障害発生時の対応実績を確認します。日本通信紙の公開事例では、約4万5,000名のPBTからCBTへの移行で、Web申込、決済、CBTシステム開発・運営、会場、合否通知、コールセンターまで受託範囲が示されています（日本通信紙、2026年確認）。このように、自社が必要とする業務範囲を実際に担った実績かを見極めます。

提案書だけで判断せず、自社の代表的な問題を使った実機デモを依頼します。受験者登録、環境チェック、本人確認、問題シャッフル、途中保存、通信断からの復帰、採点、合否通知、管理者ログの確認までを一通り操作します。CBT-SolutionsのIBTサービスでは、24時間365日の受験、多様な問題形式、問題・選択肢のランダム出題、試験前の環境チェック、API連携やシングルサインオンなどが案内されています（株式会社CBT-Solutions、2026年確認）。機能の有無だけでなく、運用担当者が迷わず使えるか、設定変更の権限を分けられるかを見ます。

見積比較では、初期費用、月額費用、従量費用、開発費、連携費、問題登録費、監視費、運用代行費、保守費、教育費、クラウド費、セキュリティ費を同じ分類に並べます。そのうえで、受験者数を数十人、数百人、数千人の3ケースに変えたときの総額を出してもらいます。初期費用無料でも、決済手数料、監視、同時接続超過、データ保管、サポート、カスタマイズが別請求なら、年間総額は高くなる可能性があります。安さの理由と、安さが成立する条件を質問することが大切です。

発注から公開までの進め方とスケジュール

オンライン試験システムは、要件定義から本番公開までを一気に進めるより、PoC、少人数パイロット、本番の段階導入が安全です。標準クラウドの設定と問題登録なら1〜3か月、既存LMS・人事・決済との連携や監視要件を含むと3〜6か月、独自の問題バンクや本人確認、大規模負荷試験を含むスクラッチ開発なら6〜12か月以上を見込むのが一般的な計画です。試験日が決まっている場合は、開発完了日ではなく、リハーサルと予備日を含めた運用開始日から逆算します。

PoCでは、代表的な問題を登録し、受験者のログイン、本人確認、受験、採点、結果出力、管理者操作を確認します。パイロットでは、実際の受験者に近い人数で、端末・ブラウザの組み合わせ、通信環境、問い合わせ、監視判定、再受験を検証します。通信断、カメラが使えない、本人確認に失敗する、問題文に誤りがある、採点結果を訂正する、受験者が試験開始時刻に集中するという失敗シナリオを意図的に試すと、本番で初めて発覚する問題を減らせます。

本番前に、試験事務局向けの運用台本を作ります。開始前のシステム確認、受験者への案内、本人確認失敗時の手順、通信断時の再開、監視アラートの確認、問い合わせの優先順位、試験延長や振替の判断者、合否確定、結果通知までを時間順に書きます。システム会社、試験運営会社、会場、監視担当、社内責任者の連絡先とエスカレーション条件を一枚にまとめると、障害時に判断が遅れにくくなります。

よくある質問（FAQ）

最後に、オンライン試験システムの発注時に特に相談の多い疑問へ回答します。自社の試験をどの方式で始めるか迷う場合は、質問の条件を整理してからベンダーへ相談すると、過不足のない提案を受けやすくなります。

標準的な研修・社内試験で短期導入を優先するならクラウド型、独自の採点や複雑な連携、厳格な監査が必要ならパッケージ・専用環境・スクラッチ型が候補です。最初から全面的に作り込むのではなく、標準クラウドでPoCを行い、差別化が必要な部分だけ開発する段階導入も有効です。

すべての試験で必須ではありません。研修の理解度確認なら問題シャッフルや制限時間、受験履歴で足りる場合がありますが、採用・昇格・資格・入試など本人性と公平性が重要な試験では、本人確認、環境チェック、監視、人手レビューを組み合わせる必要があります。顔画像や映像・音声を扱う場合は、取得目的、同意・説明、保管期間、アクセス権限、誤判定時の救済手順まで要件に含めます。

要件をそろえたうえで、少なくとも複数社から比較できる状態にすることが大切です。社数を増やすことより、同じRFPに対して初期費用、ランニング費用、受験者単価、監視、運用代行、保守、連携、追加条件を同じ形式で回答してもらうことを優先します。提案内容に差がある場合は、安い・高いと判断する前に、含まれていない業務や前提条件を洗い出します。

標準クラウドの設定と問題登録は1〜3か月、既存システム連携や監視を含む案件は3〜6か月、独自開発と大規模負荷試験を含む案件は6〜12か月以上が目安です。実際には、問題データの整理、受験制度の確定、本人確認の審査、リハーサルに時間がかかります。試験日が固定されている場合は、開発期間だけでなく、受入テスト、パイロット、修正、予備日を含めて計画します。

まとめ

オンライン試験システムの発注では、最初に試験の用途、受験者規模、必要な厳格性を定めます。そのうえで、クラウド、パッケージ、専用環境、スクラッチ開発、運営委託のどこまでを選ぶかを決め、申込から合否通知までの業務フローをRFPに落とします。

費用は、研修・社内テスト向けの月額サービスから、大規模CBTの数千万円・数億円規模まで幅があります。初期費用だけでなく、問題登録、監視、決済、保守、問い合わせ、連携、セキュリティ、障害対応を含む初年度・複数年の総額で比較します。実績は導入社数だけでなく、受験者規模と運用範囲、実機デモ、障害時の判断体制まで確認します。

要件が固まりきらない場合は、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を創業。