合同会社情報アクセシビリティ機構

MEXCBTにおける性能確保のためのアーキテクチャについて

2026年9月28日
合同会社情報アクセシビリティ機構
代表社員　村田 真

要旨

MEXCBTでは、少なくとも全国の教科調査を一週間以内に実施できる性能を目標とすべきである。紙による全国学力・学習状況調査が原則として同一日に実施されてきたことを考えれば、CBT化によって一定の柔軟性を持たせるとしても、システムの処理能力を理由に長期間へ分散させることは望ましくない。

この目標を実現するため、本意見書では、問題配信と解答収集を別のサービスとして構成すること、および解答収集サービスをステートレスにすることを提案する。ここでいうステートレスとは、解答収集サービスが過去のリクエストやサーバ内のセッション状態に依存せず、各リクエストをそれ自体で解釈し、保存できることを意味する。この構成により、問題配信と解答収集をそれぞれの負荷に応じて独立に拡張でき、解答収集では受検者を特定のWebサーバに固定する必要がなくなる。とくに、選択式問題から音声解答問題へ移るなど解答収集の負荷が急増する場合でも、追加したWebサーバへ直ちにリクエストを振り分けることができる。

1. 性能目標は「全国の教科調査を一週間以内」とする

紙による全国学力・学習状況調査では、悉皆の教科調査は原則として全国で同じ一日に実施されていた。CBT化によって実施日に一定の幅を持たせることには合理性があるが、システムの処理能力を理由として長期間に分散させれば、授業日程の調整、端末や教室の確保、試験監督などの負担を学校側に転嫁することになる。したがって、紙と同じ一日実施を必須とする必要はないとしても、全国の教科調査を一週間以内に実施できることを性能上の目標とするのが妥当である。

この目標を満たすためには、現行構成を前提として個々の処理を高速化するだけではなく、システムのどの機能を分離し、それぞれをどのように拡張可能にするかを見直す必要がある。今回のRFIが、全国規模のCBT基盤として望ましいシステム構成、コンポーネント分割、連携方式についても情報提供を求めていることは、このようなアーキテクチャ上の提案を検討対象としていることを示している。

2. 問題配信と解答収集は別のスケーリング単位とすべきである

問題配信と解答収集は、受検者から見れば一つのCBTの機能であるが、サーバ側では性質が大きく異なる。問題配信は、あらかじめ用意された同一または限定された問題コンテンツを多数の受検者が読み出す処理である。一方、解答収集は、受検者ごとに異なるデータを受け取り、それを確実に保存する処理である。とくにスピーキングテストでは、一件の解答が大容量の音声データとなり、短時間に大量の書き込みが発生する。

したがって、問題配信サービスと解答収集サービスは別のスケーリング単位として構成すべきである。問題配信側に大きな負荷がかかる時間帯には問題配信側を増強し、音声解答の収集などにより解答収集側の負荷が高まる時間帯には、あらかじめ解答収集側を増強できる。両者を分離しておけば、ストレージ、負荷分散、障害対策についても、それぞれの処理特性に適した構成を採ることができる。

問題配信のような読み出し中心の処理と、解答収集のような書き込み中心の処理を分ける考え方は、ソフトウェアアーキテクチャにおけるCommand-Query Separation（CQS）やCommand Query Responsibility Segregation（CQRS）にも見られる。CQSやCQRSがこの構成をそのまま要求するわけではないが、参照と更新という性質の異なる処理を分離し、それぞれに適した構成を採るという点で共通している。

3. 解答収集サービスをステートレスにする

解答収集サービスをステートレスにするということの本質は、クライアントから送られる各リクエストを自己完結的にすることである。すなわち、解答収集サービスは、その受検者から過去にどのリクエストを受け取ったか、現在どの問題まで進んでいるかといったサーバ内のセッション状態を参照しなくても、受け取ったリクエストだけから、どの解答をどの受検に属するものとして保存すべきかを判断できなければならない。そのために必要な受検状態はクライアント側で保持し、解答送信時に必要な識別情報とともにリクエストを構成する。

この方式であれば、一人の受検者を試験開始から終了まで同じ解答収集Webサーバに割り当てる必要がない。ある問題の解答をサーバAが受け取り、次の問題の解答をサーバBが受け取っても支障はない。sticky session（特定サーバへの固定割当て）が不要になるため、ロードバランサはその時点で利用可能な任意のWebサーバへリクエストを振り分けることができる。

この性質は、負荷が問題によって大きく変化するCBTでとくに重要である。たとえば前半が選択式問題で、途中から音声解答問題へ移る場合、解答収集側のCPU、ネットワーク、ストレージへの負荷は短時間に大きく増える。解答収集Webサーバが受検者ごとのセッション状態を持ち、既存受検者が特定サーバに固定されていれば、負荷が高まる直前にWebサーバを追加しても、既存受検者の次の音声解答を新しいサーバへ十分に振り分けることができない。これに対し、各リクエストが自己完結的であれば、追加したWebサーバも直ちにすべての受検者からのリクエストを処理できるため、オートスケールが有効に機能する。

この設計原則は、Roy FieldingがRESTアーキテクチャを定式化した博士論文でも、Client-Stateless-Server制約として示されている。そこでは、各クライアントからサーバへのリクエストは、それ自体がリクエストを理解するために必要な情報をすべて含み、サーバ側に保存されたクライアントのコンテキストに依存しないことが求められる。

同じ考え方は、現在のクラウドアーキテクチャでも重視されている。The Twelve-Factor App は、アプリケーションを「ステートレスでshare-nothingなプロセス」として実行し、将来のリクエストが別のプロセスで処理されることを前提とすること、またprocess modelによってscale outすることを推奨している。AWS Well-Architected Frameworkも、REL05-BP06「可能な限りシステムをステートレスにする」において、異なるクライアントリクエスト間でサーバ内のローカル状態に依存しない構成とすることで、任意のサーバが任意のリクエストを処理でき、horizontal scalingと障害耐性が得られるとしている。さらにREL07では、需要の変化に応じてリソースを自動的に追加・削除できる構成を求めている。

ステートレス化は、解答収集Webサーバの障害への耐性にも直結する。あるWebサーバが停止しても、そのサーバだけに保持されていた受検者固有のセッション情報が失われることはなく、クライアントは次のリクエストを別の解答収集Webサーバへ送ればよい。送信中に障害が発生した場合も、永続保存が完了したことをクライアントが確認するまでは解答を保持し、別のサーバへ再送できるようにする。また、各解答に一意な識別子を付与するなどして、再送による重複保存を防ぐ必要がある。

学校内ネットワークの一時的な混雑や切断については、これとは別にクライアント側の再送機構で対応する。送信できなかった解答をクライアント側に保持し、通信回復後に再送することで、短時間の通信障害を受検結果の喪失につなげない。サーバ障害と学校内ネットワーク障害は異なる問題だが、保存完了が確認できるまでクライアントが解答を保持し、任意の解答収集Webサーバへ安全に再送できることを共通の設計原則とすることで、双方に対応できる。

4. 分離・ステートレス構成には約20万人規模の実装・試験実績がある

ネットラーニング株式会社がMEXCBTのために開発したCBTでは、問題配信系と解答収集系を分離し、解答収集Webサーバをステートレスにする構成が実装されている。約20万人の受検者を想定した性能試験では、各受検者が約30秒、約1MBの音声を12分間に4回送信する条件、すなわち合計約80万件、約800GBの音声データを送信した。この試験では、解答収集の平均応答時間は約0.083秒であり、音声データの欠損は発生しなかった。

この性能試験は、全国規模のMEXCBTについてそのまま性能を保証するものではない。しかし、問題配信と解答収集を分離し、解答収集リクエストをステートレスに処理する構成が、少なくとも約20万人規模の負荷を想定して実装・試験されていることを示す実績である。詳細は、Paul Grudnitski，村井拓海，佐々木公博，村田真による日本テスト学会2025年大会論文「数十万人同時に英語スピーキングテストを実施するためのCBTのアーキテクチャ」に報告されている。

5. MEXCBTへの提案

以上から、MEXCBTについて次の方針を提案する。

  1. 全国の教科調査を一週間以内に実施できる性能を目標とする。
  2. 問題配信サービスと解答収集サービスを分離し、別のスケーリング単位とする。
  3. 解答収集サービスは、各リクエストを自己完結的に処理できるステートレスなサービスとする。
  4. 解答収集Webサーバについてsticky sessionを不要とし、任意の受検者からの次のリクエストを、新たに追加したWebサーバを含む任意のサーバで処理できるようにする。
  5. 保存完了が確認できるまで解答をクライアント側に保持し、サーバ障害または学校内ネットワーク障害が発生した場合には安全に再送できるようにする。

参考文献

  1. 文部科学省「令和9年度『文部科学省CBTシステム（MEXCBT）の改善・活用推進事業』にかかる情報提供依頼（RFI）実施要項」2026年。 https://www.mext.go.jp/a_menu/other/mext_03631.html
  2. Paul Grudnitski，村井拓海，佐々木公博，村田真「数十万人同時に英語スピーキングテストを実施するためのCBTのアーキテクチャ」日本テスト学会、2025年。 https://info-a11y.jp/papers/jartest2025.pdf
  3. Bertrand Meyer, Object-Oriented Software Construction, 2nd ed., Prentice Hall, 1997. https://bertrandmeyer.com/oosc2/
  4. Martin Fowler, “CQRS,” 2011. https://martinfowler.com/bliki/CQRS.html
  5. Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, Doctoral Dissertation, University of California, Irvine, 2000. https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
  6. Adam Wiggins, The Twelve-Factor App, “VI. Processes” and “VIII. Concurrency.” https://www.12factor.net/processes、https://12factor.net/concurrency
  7. Amazon Web Services, AWS Well-Architected Framework, Reliability Pillar, “REL05-BP06 Make systems stateless where possible” and “REL07 Design your workload to adapt to changes in demand.” https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_stateless.html、https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html
  8. 文部科学省「令和6年度全国学力・学習状況調査に関する実施要領」2023年。 https://www.mext.go.jp/content/20231221-mxt_chousa02-000033188-1.pdf