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

CBTシステムの発注は、まず方式と委託範囲を決め、その内容をRFPにまとめて候補会社に示すところから始まります。契約形態を選んだうえで委託先を比べ、試験運用を行うと、本番の責任分担を明確にできます。

全体像は、CBTシステム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・CBTシステム開発の完全ガイド

発注・外注で最初に決める事項

CBTはComputer Based Testingの略で、コンピューター上で試験を実施する方式です。また、テストセンターで受けるCBT、自宅などで受けるIBT、紙のPBTを組み合わせるハイブリッド方式もあり、方式が変わると必要な設備と委託範囲も変わります。

発注する側は、試験を誰がどこで、どの規模で運営するかを先に決めておきます。そのうえで、システムを作るかどうかを判断します。

既存サービスの利用と独自開発の使い分け

既存サービスと独自開発は、運営をどこまで任せたいかと、標準機能で要件を満たせるかで選びます。

  • 既存サービス:早期開催や全国会場、申込、決済、コールセンターまで任せたい場合に向きます。
  • 標準機能で対応:問題形式と採点に対応し、独自画面へのこだわりが小さければ、期間と初期投資を抑えられます。
  • 独自開発:問題バンク、複雑な受験資格、記述式・音声問題、IRTが必要なら、専用機能や追加開発の検討が要ります。
  • 深いシステム連携:会員、LMS、資格証明との連携が必要なら、標準サービスで対応できるかを確かめます。

システム提供と試験運営の役割分担

委託先の担当範囲を示すには、「CBTシステムを導入する」という表現より細かい書き方が要ります。会社によって、クラウド環境と管理画面だけを提供する場合もあれば、運営全般を担う場合もあります。そのため、どこまでを委託先が担い、どこからを発注側が担うかを、運営の場面ごとに分けて確かめます。

  • 試験準備:問題登録、受験者への案内、会場・座席の確保
  • 試験当日:受付、監督、採点、結果通知、問い合わせ対応
  • 障害対応:障害時の再受験など、例外時の運営

見積を依頼するときは、システム利用料と運営業務の委託費を分けてもらいます。さらに、主催者側に残る作業も一覧にします。

受験規模と運用条件の数値化

受験規模と運用条件は見積の構成を左右するため、次の数値で整理します。

  • 受験規模:年間人数、1日あたりの人数、ピーク時の同時接続数を整理します。
  • 会場規模:会場ごとの座席数を数えます。
  • 試験条件:試験時間、画像・音声・動画の扱い、通信断からの再開方法を示します。
  • 例外条件:延長時間と再受験のルールを、数値や条件で示します。

たとえば、年間1万人でも、数か月に分散して受ける試験と、1日1万人が一斉に受ける試験では、必要な構成が異なります。そのため、条件をそろえておくと、ベンダー間の見積を比べやすくなります。

ポイント

発注前に、運営をどこまで任せるかと受験規模を数値で決めておくと、委託先の見積を同じ前提で比べられます。既存サービスか独自開発かは、要件を標準機能で満たせるかを手がかりに絞り込むとよいでしょう。

発注形態の選び方

CBTシステムの発注形態をパッケージ・クラウド型、試験運営の一括委託、スクラッチ開発の3種類で示した図
標準機能、運営委託、独自要件の違いから選択肢を見渡せます。

発注形態は、パッケージ・クラウド型、試験運営の一括委託、スクラッチ開発に大別できます。

形態は、試験の独自性、導入期限、受験者規模、将来も自社で担う業務で選びます。そのうえで、知名度や開発言語を比べるとよいでしょう。

迷う場合は、標準サービスで小規模なパイロットを行い、独自開発が必要な部分だけを後から追加する方法もあります。

パッケージ・クラウド型の標準機能の活用

パッケージ・クラウド型は、標準機能と保守を利用できる形態です。一方で、独自要件を加える場合は、その追加費用も確認します。

  • 標準機能:問題登録、受験者管理、配信、採点、結果出力を短期間で使えます。
  • 保守負担:ベンダーがOS、ブラウザ、脆弱性へ対応し、自社の保守負担を抑えます。
  • 追加要件:標準外のルールはカスタマイズ費と検証負担を増やし、更新時に個別改修が必要になる場合があります。
  • デモ確認:標準機能と、追加料金になる機能を分けて確かめます。

運営一括委託による主催者の負荷軽減

一括委託は、運営体制を自社だけで整えるのが難しい場合の選択肢になります。

  • 委託業務:システム、会場網、受付、決済、サポート、監督、採点、結果集計。
  • 向いている主催者:初めてCBTを行う資格団体や、全国会場を確保しにくい企業では、委託先の運用実績を選ぶ理由になります。
  • 主催者の判断:問題の正確性、合否基準、本人確認方針、異議申立ての最終判断。

一括委託をしても、主催者の承認が必要な工程は残ります。そのため、どの工程で承認を取るかを契約前に明確にします。

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

スクラッチ開発は、標準サービスで対応しにくい要件に向いています。さらに、主催者の責任と契約上のリスクも確認します。

  • 独自機能:独自採点、複雑な問題分岐、専門的な音声・動画処理。
  • 個別要件:基幹システムとの連携、厳格なデータ保管。
  • 主催者の決定事項:問題移行、受験規約、画面のアクセシビリティ、監督手順、障害時の再受験。
  • 固定価格のリスク:要件が流動的だと変更管理や追加費用で揉めやすいため、先にPoCや要件定義を切り出します。

ポイント

パッケージ・クラウド型、一括委託、スクラッチ開発は、試験の独自性と自社で担う業務の範囲で見比べます。迷うときは、標準で試したうえで不足分だけ後から足す進め方も選択肢になります。

RFPと要件整理の盛り込み内容

RFPの要件を現行業務と将来業務、試験・データ要件、非機能要件と受入基準の3層で整理した図
業務の流れから試験条件、受入条件へ整理が広がります。

RFPはRequest for Proposalの略で、発注者が目的や条件を示し、候補会社から提案と見積を受ける資料です。

候補会社の提案を比べられるようにするには、現行の紙試験の業務フローと、受験者数、方式、問題形式を同じ書式で渡します。さらに、運用体制や納期、予算の考え方も、そろえて伝えます。

現行業務と将来業務の工程別整理

RFPには、現行業務から再受験までを時系列で並べ、工程ごとの責任者を記載します。

  1. 作問、レビュー、問題登録
  2. 受験資格の確認、申込、決済、受験票の発行
  3. 会場予約、当日の受付、本人確認、試験監督
  4. 採点、結果通知、合格証発行、問い合わせ、再受験

各工程の責任者は、主催者、委託先、会場、採点者のいずれかで明記します。特に、版管理や合否の承認者が曖昧なままだと、運用設計の抜けは開発後になって見つかります。

責任分担は、RACIに近い表にまとめ、RFPに添付します。

試験・データ要件の具体化

RFPには、試験機能とデータの扱いを次の項目ごとに具体的に記載します。

  • 問題形式:選択式、複数選択、記述式、並べ替え、音声、動画、画像、作図。
  • 出題条件:問題数、範囲、難易度、ランダム出題、出題回数制限。
  • 受験・成績:試験時間、途中保存、通信断時の再開、合否判定、成績表の項目。
  • 対象データ:個人・本人確認情報、受験ログ、答案、問題原本、採点結果、監査ログ。
  • データ管理:保管場所・期間、削除方法、エクスポート形式。

非機能要件と受入基準の数字での提示

機能の要件に加えて、サービス品質と受入試験の条件も、RFPに示しておきます。

  • 性能・可用性:同時接続数、応答目標、稼働率、バックアップ、復旧時間。
  • 運用・環境:問い合わせの一次応答、障害連絡の経路、対応ブラウザ・端末。
  • セキュリティ:脆弱性診断の時期、ログ保存期間。
  • 受入試験:通信断、停電、端末交換、本人確認失敗、時間延長、管理者権限の誤操作を再現します。

IPAの2026年度CBT試験調達資料は、開始前の脆弱性検査、暗号設定、保護されたネットワークを確認項目としています(出典: IPA「令和8年度 情報処理技術者試験等のCBT方式による試験実施業務」、2026年)。

ポイント

RFPは、現行業務の流れと受験者数、方式、問題形式を同じ書式で示し、試験・データ要件から受入基準まで具体的に書くと、候補会社の提案を比べやすくなります。

請負と準委任の使い分け

契約形態は、開発の成果物と責任範囲をどこまで確定できるかで選びます。

CBTは試験ルールや問題データを検討しながら仕様が変わりやすいため、固定価格では変更のたびに追加の見積が出やすくなります。

発注者は、要件定義やPoCを準委任、仕様確定後の機能開発と納品を請負、稼働後の保守と運営委託を月額で契約すると、管理しやすくなります。

要件定義やアジャイル開発に向く準委任

準委任は、要件が固まる前の調査や段階的な開発で活用できます。

  • 契約の性質:専門業務の遂行に報酬を払い、成果物の完成は一律に約束しません。
  • 向く作業:要件調査、業務整理、画面試作、技術検証、優先順位付け。
  • 発注者の確認:月次作業、稼働時間、会議体、成果確認、未消化作業の扱い。
  • PoC:問題データを使って仕様を固める段階にも活用できます。

発注者は担当者任せにせず、契約した業務の進捗を自ら確認します。

範囲と受入基準が確定した開発での請負

請負は、完成物と責任範囲を定められる開発に適しています。

  • 契約の性質:定めた仕事の完成と成果物の引き渡しに、報酬を支払います。
  • 対象例:申込・問題管理・受験画面、採点機能、連携API。
  • 契約書:納品物、検収期間、瑕疵対応、仕様変更、再委託、知的財産権を確認します。
  • 終了・保守:コード・データ返却と移行支援を定め、保守契約を分けます。

受入後の保守を開発契約と分けると、障害対応の責任が明確になります。

運用委託のSLAと例外時の費用

稼働後の契約では、保守、試験運営、例外時の対応範囲を分けておきます。

  • システム保守:監視、バックアップ、障害の一次対応、脆弱性対応、OS・ブラウザ更新。
  • 試験運営:問題登録、会場手配、問い合わせ、採点、結果通知。
  • SLA・例外対応:稼働率、重大障害の連絡時間、復旧目標、再受験の判断、受験料の返金。
  • 追加費用:繁忙期の追加要員や、予定外の問題改定にかかる費用。
  • 解約時:データ形式と移行期間を定め、将来の選択肢を守ります。

ポイント

開発の範囲と受入基準が確定しているかで、請負か準委任かを選びます。仕様がまだ固まらない段階は準委任で進め、確定後の機能開発と納品を請負にすると、管理しやすくなります。

CBTシステムの発注・外注費用の相場

費用の構造は、既存サービスを使うか、独自システムを開発するかで異なります。公開された定価が少ないため、費用は項目ごとに分けて見積もります。初期設定、問題登録、受験者課金に加えて、決済、会場、保守、追加開発、運営代行も一つずつ見積もります。

次に示す金額は、公開料金例や研究資料に基づく目安です。ただし、税区分や会場費、試験時間など、条件によって変わるため、契約価格を断定する数字ではありません。

既存CBTサービスの初期費用と受験者課金

既存CBTサービスの費用は、初期費用、従量費、保守に分けて確認します。

  • 初期導入:50万〜100万円程度。環境準備、設定、会場・コールセンター教育を含む公開例です。
  • 配信費:公開単価は受験者1人あたり3,000円です。
  • 問題登録・修正:1回・科目あたり5万〜20万円程度です。
  • 決済手数料:公開例では1件あたり数百円です。
  • 初年度試算:1,000人、配信単価3,000円、決済手数料150円、2科目の問題登録、保守50万円以上を前提に、初期費用を含む初年度は約500万円前後です。

根拠は株式会社CBT-Solutions「CBTを導入するうえでの費用はどれくらい?」の公開情報です。

この試算は既存サービスの運営費であり、独自開発費は含みません。なお、従量単価や長時間試験の加算、キャンセルと再受験の扱いも、見積の段階で確かめます。

独自開発の規模別の予算目安

独自開発には、公開された価格がほぼありません。そのため、次に示すのは、CBT固有の定価ではなく、要件と工数に基づく予算の目安です。

  • 小規模MVP:選択式中心の1試験、数百人、外部会場・決済利用で500万〜1,500万円程度。
  • 中規模:問題バンク、管理画面、会員・決済連携、複数試験、成績分析、障害復旧で1,500万〜5,000万円程度。
  • 大規模:全国会場、自宅IBT、本人確認・オンライン監督、記述式採点、IRT、LMS・資格証明連携、高可用性を含むと5,000万円〜2億円以上の可能性。
  • 研究試算:医師国家試験想定のCBTと問題バンクの開発費は2億6,800万円です。
  • 小規模試行:厚生労働科学研究費補助金「CBTシステムの費用概算」(2024年)では、初期開設費25万円程度、年間費用700万〜800万円程度です。

ただし、費用は要件定義、設計、開発、テストのどこまでを含むかで変わり、問題作成や会場運営まで含むとは限りません。このため、これらは、規模と運用方式で金額が大きく変わる事例として参考にします。

ランニングコストと隠れた費用の洗い出し

システム外の費用も含め、運営環境に合わせて総額を積み上げます。

  • システム・問題:クラウド、監視・保守、脆弱性診断、問題登録・改定、画像・音声編集、決済。
  • 試験運営:会場、端末・ヘッドセット、本人確認・監督、コールセンター、通知、資格証明書発行。
  • 学内環境:端末更新、ネットワーク増強、監督者研修、予備端末、アクセシビリティ対応。

大学入試センターの「CBTに関する課題解決事例集」(2025年)も、端末や運用だけでなく、学内合意や予算まで一体で検討しています。

ポイント

費用は既存サービスか独自開発かで構造が変わるため、公開された料金例は目安として扱います。見積は、問題登録や決済、会場、保守などの項目を同じ前提条件で比べて判断します。

CBTシステムの委託先選定と見積比較

委託先は、開発実績の数だけでなく、試験方式と運用責任に合うかで選びます。

全国会場型と自宅IBT型では必要な知見が異なります。また、選択式と音声・記述式でも、評価の軸が変わります。

同じRFPを複数社に送り、見積を同じ単位で比べます。比較の軸は、初期費用や従量課金、保守などです。

会場網と試験運営の実績

運営実績は、試験方式や規模が自社の条件に近いかで見ます。

  • 試験実績:会場型・自宅型、年間配信件数、同時受験規模、国家・資格・社内試験。
  • 会場対応:希望地域の会場数、座席追加、災害・停電時の代替会場、監督者教育。
  • 導入事例:受験者数、問題形式、移行期間、障害対応、主催者側の作業量を聞きます。

事例の詳細を聞いておくと、発注後の運用を具体的に想定できます。

問題形式・連携・セキュリティの適合性

デモは実データで試し、機能と運用、契約条件をまとめて確かめます。

  • 問題機能:版管理、画像・音声・動画、ランダム出題、記述式採点。
  • 受験・管理:時間延長、自動保存、通信復旧、権限分離、監査ログ、CSV・API連携。
  • 本人確認・AI監視:誤検知の人手確認、異議申立て、映像・生体情報の範囲と削除時期。
  • 契約条件:利用プランと追加費用を見積書に記載してもらいます。
  • 情報保護:個人情報・試験問題を機密扱いし、3段階以上の権限、暗号化、TLS、検査、監視、事故報告、再委託先、保管地域を確認します。

文部科学省のMEXCBT(出典: 文部科学省「文部科学省CBTシステム(MEXCBT)」、2024年11月時点)には、約2.8万校、約890万アカウントが登録され、学力・自治体調査などに利用されています。

MEXCBTのような大規模な利用では、機能に加えてデータ連携と運用の統制も選定条件になります。

見積書の前提条件をそろえた比較

見積は、共通の前提条件と費用項目をそろえて比べます。

  • モデル条件:受験者1,000人、60分、2科目、会場型、既存問題支給、平日問い合わせ対応。
  • 費用内訳:初期設定、月額保守、配信、決済、問題登録、会場、監督、窓口、追加開発、脆弱性診断。
  • 人数別試算:100人、1,000人、1万人の3案で従量課金と固定費型を比べます。
  • 対象範囲:問題のデジタル化、受入試験、マニュアル、研修、再受験、データ移行、リリース後改善。
  • 回答区分:「含む」「含まない」「条件付き」「別途」で回答を求め、未確定事項も比べます。

安い見積では必要な作業が対象外になっていることがあり、高額でも不要な機能や過剰な会場が含まれる場合があります。見積の中で不確実な部分は、準委任の要件定義やPoCで先に確かめられます。

発注後から本番開始までの確認事項

本番前のパイロットで確認する実施規模、試験の流れ、会場条件、是正管理を並べた図
4項目をそろえると、本番前の確認範囲を把握できます。

本番までの成否は、システムの完成度だけでなく、問題データと運用手順の準備にも左右されます。

紙問題を移す際は、文字や画像の解像度、音声、選択肢の順序を照合します。また、照合の対象には、正答と配点、出題範囲、公開期間も含めます。なお、候補資料では、問題準備済みなら約2か月の導入例があります。

独自開発を含める場合や、セキュリティ診断、会場調整、受入試験を加える場合は、別のスケジュールになります。

本番前の実データによるパイロット

本番前のパイロットでは、限られた会場や受験者で、一連の運用を確かめます。

  • 実施規模:全国展開の前に、1〜2会場または限定した受験者で試します。
  • 試験の流れ:画像・音声を使い、受付、本人確認、開始、途中保存、通信断、時間延長、採点、結果通知、問い合わせを確認します。
  • 会場条件:ネットワーク速度、端末画面、ヘッドセット、周囲の音、監督手順を記録します。
  • 是正管理:見つかった問題に責任者、期限、再テスト条件を付け、本番前に解消します。

運用手順と障害時の判断の文書化

本番前には、関係者の連絡網を作ったうえで、障害の深刻度ごとの対応を決めておきます。

  • 連絡体制:主催者、委託先、会場監督、コールセンター、採点担当者の連絡網を作ります。
  • 想定事象:ログイン不能、本人確認失敗、端末故障、通信断、問題誤り、合否への異議。
  • 判断・案内:判断者、記録内容、再受験・返金・結果保留の案内を決めます。
  • AI不正検知:検知だけで失格にせず、人の確認と異議申立ての手順を設けます。

本番後の運用KPIの見直し

本番後は、品質、受験状況、試験内容を月次で点検し、その結果を契約更新に反映します。

  • サービス品質:稼働率、障害件数、問い合わせ初回応答、採点・結果通知の遅延。
  • 受験状況:完了率、ログイン失敗率、再受験率、AI検知の誤検知率、会場別トラブル。
  • 試験内容:問題別正答率。改定時は版管理と再テストの記録を残します。
  • 更新時テスト:OS・ブラウザ更新時に受験画面、音声、本人確認、管理画面を回帰テストします。

契約更新時は利用量と障害対応の実績から、会場数、保守レベル、委託範囲を見直します。

よくある質問(FAQ)

発注時には、費用や既存サービスと独自開発の違い、委託範囲について質問されます。また、問題データと導入期間も、見積の前に確かめておきたい項目です。

CBTシステムの外注費用はどのくらいかかりますか?

既存サービスは初期費用と受験者課金、独自開発は規模によって金額が大きく変わります。公開されている数字を、次の項目ごとに示します。

  • 既存サービス:初期50万〜100万円程度、配信は1人3,000円程度の公開例です。
  • 運用費:問題登録・修正、決済手数料、保守費用もかかります。
  • 公開試算:受験者1,000人・2科目では初年度約500万円前後です。
  • 独自開発:小規模500万〜1,500万円程度、大規模5,000万円〜2億円以上の幅があります。

金額は、見積の前提条件をそろえてから、委託先ごとに比べます。

CBTシステムの導入には何か月かかりますか?

導入期間は、既存基盤の活用や新規開発、試験準備の範囲で変わります。

  • 標準機能の設定:問題準備済みで既存基盤を使う場合、2か月程度の例があります。
  • 追加準備:問題デジタル化、会場調整、受入試験、診断、運用研修で期間が延びます。
  • 独自開発:問題バンク、連携、記述式、オンライン監督では6〜12か月程度が推定レンジです。
  • 大規模基盤:12〜24か月程度を計画し、パイロット期間を別に確保します。

委託先にはセキュリティ要件をどう確認すればよいですか?

脆弱性検査の時期と結果、暗号化、TLSを確認します。権限分離や操作・監査ログ、保管場所についても確かめます。さらに、バックアップの方法も確認します。

事故報告、再委託先、削除・返却方法も質問します。個人情報に加え、試験問題や答案も機密情報として扱います。

閲覧・出力できる人を確かめます。AI監視や本人確認では、保存情報、人による審査、異議申立ても仕様と契約に含めます。

開発会社と試験運営会社はどちらに依頼すべきですか?

全国会場の運営から採点までを任せる場合は、試験運営の実績がある会社が適しています。申込・決済やサポート、監督も含めて、委託範囲を確かめます。

独自会員管理、LMS・基幹連携、複雑な採点や問題管理を重視する場合は、開発会社の技術力を評価します。

一社では不足する場合は、両社の役割を明確にし、障害時の一次窓口やデータ連携、契約責任を一本化できる体制を選びます。

まとめ

CBTシステムの発注では、CBT、IBT、PBTのどの方式を採るか、既存サービスと独自開発のどちらを選ぶかを、最初に定めます。

システムと試験運営の委託範囲を定めたうえで、その内容をRFPにまとめます。委託範囲と受験規模、問題形式を中心に盛り込み、会場や本人確認、障害対応の項目も、本文の一覧に沿って整理します。

契約後の運用とデータの出口

契約と手順には、問題改定や再受験、脆弱性・ブラウザ対応を含めます。問い合わせやデータ返却・移行の扱いも、同じ契約で決めておきます。主催者と委託先の判断範囲を分けたうえで、稼働後のKPIも定めます。

同じRFPによる複数社の比較

発注先は、価格と運用責任の両面から、共通の条件で比べます。

  • 既存サービス:初期費用、受験者課金、問題登録、決済、保守で比べます。
  • 独自開発:規模、連携、セキュリティ、運用費を見て、要件に応じ請負と準委任を組み合わせます。
  • 運営体制:会場網、問題形式、実績、障害対応、データの出口を確認します。
  • 最終判断:追加費用と責任範囲のずれを抑え、公平性と受験者体験を守れる委託先を選びます。

▼全体ガイドの記事
・CBTシステム開発の完全ガイド

会社紹介

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

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

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

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

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

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