Published
- 19 min read
Moodle小テストのカンニングはバレる？記録データ・不正対策と検知の限界
はじめに
大学の LMS として Moodle を使っている場面で、小テスト（Quiz）をオンライン実施すると「カンニングはバレるのか」という話題が必ず出てくる。教師側は対策を、受験者側はリスクを気にするわけだが、双方とも Moodle が実際に何を記録しているかは、画面を触らないと分かりにくい。
短く言うと、多くの行動は何らかの形で残る。ただし Moodle 本体に「不正を検知した」と判定する機能はなく、ログや統計があっても、それ単体で処分の根拠になるとは限らない。
本記事では Moodle 5.x を前提に、小テストで教師が取得できる記録を整理する。不正の手口を教えるつもりはない。記録の中身と、不正対策としてどこまで効くか（効かないか）を並べて書く。事前に何が残るかを知っておくこと自体が、カンニングのインセンティブを下げるはずだし、教師側も「ログを見れば全部分かる」と過信しないで済む。
記録は三つの層にある
最初に押さえておきたいのは、情報の取り出し方が三つに分かれる点だ。
| 層 | だいたい誰が触るか | 例 |
|---|---|---|
| 標準 UI（Results の各レポート） | 教師・TA | 成績、回答、設問別正答率、試験全体の所要時間 |
| ログ / DB | 教師（ログ）、管理者（DB） | IP、設問ごとの操作時刻、回答の変更履歴 |
| プラグイン | 機関次第 | SEB、フォーカス監視、設問別の異常時間 |
成績レポートだけ見ていると「これしかない」と思いがちだが、IP や設問ごとの回答時間は別の場所に散らばっている。以下、標準機能から順に書いていく。
どこからデータを見るか
Boost テーマなら、小テストを開いて Results タブに進むのが定番だ。ここから成績・回答・統計・手動採点の四種類のレポートに入れる。
個別の受験内容は Review attempt から確認できる。生徒が受験後に見る画面と同じ形式なので、「この人は何を選んだか」をそのまま追える。
それ以外に、コースの Logs から受験開始や autosave の記録を拾える。サイト全体の監査ログや DB は管理者向けだが、設問別のタイムスタンプなどはこちらにしかない。大学によってカスタムレポートを入れている場合もある。
標準レポートで見られるもの
Moodle 5.0 の Quiz reports に載っている機能を、実務的な観点でまとめる。
成績レポート（Grades）
いちばんよく開く画面だろう。受験者ごとに試行が並び、開始・完了時刻、所要時間（Time taken）、総合点、設問別得点が見える。得点分布のグラフもここにある。
注意したいのは Time taken が試験全体の時間である点だ。ページごと、設問ごとの時間は出てこない。後述するが、ここを誤解している教員は少なくない。
Review attempt を押すと、その受験者の回答・正誤・（設定次第で）正解やフィードバックまで辿れる。複数回受験を許している場合は、初回だけ・最高点だけ、といった絞り込みもできる。
回答レポート（Responses）
成績レポートと表の形は似ているが、表示されるのは得点ではなく生の回答だ。選択肢の文言、数値入力、記述文がそのまま並ぶ。CSV で落として Excel に載せれば、設問ごとに「どの選択肢が何件選ばれたか」を自分で集計できる。
答案が似通っている、過去問が回っている——そういう違和感を掴むときに使うレポートだ。
統計レポート（Statistics）
設問別の正答率や分布を見るなら、ここが中心になる。Statistics report は心理統計寄りの数字が多いが、教員が日常使いする部分だけ抜き出すと次のようになる。
試験全体（Quiz information）では、受験回数、平均点、中央値、標準偏差に加え、歪度・尖度、Cronbach α、誤差比、標準誤などが出る。全部を毎回解釈する必要はないが、得点がどのくらいばらけているか、テスト全体として安定しているかを見る材料になる。
設問構造分析（Quiz structure analysis）では、設問ごとに Facility Index（正答率に近い指標）、識別力（Discrimination index）、ランダム回答時の期待得点などが並ぶ。Facility Index が極端に低い・高い設問は、問題文のミスや難易度の偏りのサインになりうる。
設問名をクリックすると Analysis of individual question responses に入り、選択肢ごとに何 % の人が選んだかが見える。記述式はこの分析の対象外だ。
ランダム問題（同じ枠から別バージョンの設問を引く設定）を使っている場合、バリアントごとの Facility Index を比較して、難易度が揃っているか確認するのが定石だ。
統計の計算は重いので、Moodle は結果を最大 15 分キャッシュする。再計算ボタンもある。CSV や PDF で丸ごと落とせる。
ページごとの回答時間について
ここははっきり書いておく。標準レポートにページ別・設問別の回答時間はない。見えるのは試験全体の Time taken だけだ。設問ごとの時間が欲しければ、DB を掘るか、プラグインを入れるか、大学の管理者に頼む形になる。
手動採点レポート（Manual grading）
Essay など自動採点できない設問向けだ。未採点が何件残っているか、設問単位で一括採点する画面に入れる。記述式を混ぜた小テストを運用しているなら、成績レポートだけでは足りない。
Review attempt で見える範囲
個別の Review attempt では、各設問の最終回答・正誤・得点、試験の開始・終了・全体の所要時間が分かる。設定次第で正解やフィードバックも出る。
試行中に何度か保存を押していた場合、画面に残るのは最終状態だけだ。途中で答えを書き換えた回数や、設問に費やした時間は、標準 UI では追えない。
ログに残るもの
成績レポートに載らない情報の多くは、コースの Logs にある。Moodle フォーラム でも、受験時の IP を確認したい場合はログを Export する運用が紹介されている。
| 情報 | 備考 |
|---|---|
| 受験開始・提出・結果閲覧 | イベント種別で絞れる |
| IP アドレス | 成績レポートには列がない。ログ Export が現実的 |
| User-Agent | 記録される構成ならブラウザ情報も追える |
| Autosave | 既定で約 2 分間隔（サイト設定で変更可） |
autosave の記録に数分の空白ができることがある。タブを切り替えた、通信が切れた、などの疑いにはなる。ただし、これだけで不正と決めつけるのは早い。後半でも触れる。
同一 IP から複数アカウントが受験していた、といった調査は、Export したログを IP でソートすれば始められる。
DB を見ないと分からないもの
Moodle の Question engine では、設問への操作が step として question_attempt_steps などに積み上がる。一般の教員が GUI から触る領域ではないが、「標準レポートに無いもの」として押さえておく価値はある。
| 情報 | 取り方のイメージ |
|---|---|
| 設問ごとの操作時刻 | 各 step の timecreated |
| 設問ごとの回答時間（近似） | step 間の差分、または初回表示から submit まで |
| ページごとの滞在時間（近似） | 1 ページ 1 問なら、設問時間 ≒ ページ時間 |
| 回答の変更履歴 | 同一設問への複数 step |
| autosave のタイミング | AJAX autosave と DB 更新の対応 |
SQL の例は この gist が参考になる。大学によっては研究用プラグインで設問別時間の異常検知までやっている例もある。
プラグインで足せるもの
Moodle 本体だけでは足りない部分を、機関がプラグインや外部ツールで補う。導入有無は大学ごとにまちまちだ。
| ツール | ざっくりした効果 |
|---|---|
| Safe Exam Browser（SEB） | ロックダウンブラウザの強制。Browser Exam Key / Config Key で改ざんクライアントを弾ける（Moodle 3.9 以降はネイティブ連携あり） |
| Quiz access rules 系 | IP 制限、パスワード、時間制限など |
| 不正検知系プラグイン | フォーカス喪失、コピー試行など（製品による） |
| Block Concurrent Sessions | 同一アカウントの同時ログイン制限 |
| プロクタリング連携 | カメラ・画面録画・本人確認 |
SEB の詳細は 公式サイト と Moodle ドキュメントを見てほしい。「SEB を入れたから安心」では済まない話は、後で書く。
よく探される情報はどこにあるか
調べ物で引っかかりやすい項目だけ、三層で整理する。
| 知りたいこと | 標準 UI | ログ / DB | プラグイン |
|---|---|---|---|
| 総合得点・設問別得点 | ○ | ○ | — |
| 試験全体の所要時間 | ○ | ○ | — |
| ページごとの回答時間 | × | △（近似） | △ |
| 設問ごとの正答率 | ○（Statistics） | △ | — |
| 選択肢ごとの選択割合 | ○（Statistics） | △ | — |
| 得点分布 | ○（Statistics） | — | — |
| 生の回答内容 | ○（Responses） | ○ | — |
| IP アドレス | × | ○（ログ Export） | △ |
| 回答変更の履歴 | × | ○ | — |
| タブ切替・コピー | × | △ | ○（製品次第） |
| ロックダウンブラウザ | × | — | ○（SEB 等） |
○ は教員が比較的そのまま触れる、△ は権限・近似・機関依存、× は標準では無理、という意味で使っている。
カンニングはどこまで「バレる」か
ここからは不正抑制の話に移る。Moodle に「不正検知 ON」ボタンはない。ログや統計は、調査を始めるための手がかりであって、記録＝証拠とは限らない。
| 不正の型 | 残りうる痕跡 | 標準 UI で見えるか | 限界 |
|---|---|---|---|
| 答案・問題の共有 | 回答パターンの類似、Statistics の歪み | 部分的 | 共謀の確定は難しい。偶然の一致もある |
| 代受験 | ログの IP、成績の不自然な変化 | IP はログのみ | IP は途中で変わりうる |
| 外部サイト検索 | 設問ごとの長い空白＋短時間回答 | ×（DB/プラグインなら △） | 標準画面だけでは気づきにくい |
| タブ切替 | autosave のギャップ | △ | 通信断など別原因もありうる |
| SEB 回避 | BEK/CK 不一致、autosave ギャップ | △ | SEB 側の議論 でも、事後立証は難しいとされている |
| 複数端末・同時ログイン | Concurrent Sessions、ログ | プラグイン次第 | 標準のみでは弱い |
| パスワード共有 | 受験ログ | ○ | 意図までは分からない |
| ネットワーク制限の迂回 | IP ログ | ログのみ | network address 制限とグループ override の両立に癖がある |
「バレる」と聞いて期待するほど、自動的には追い込めない。何かしら記録は残りうるが、処分や説明責任まで持っていくには、文脈と追加調査が要る、という理解の方が近い。
対策として効く設定
監視技術だけに頼るより、出題設計の方がコスパがいい。Moodle でも繰り返し推されるのは、だいたい次のようなものだ。
- ランダム問題で、受験者ごとに設問セットを変える
- 設問順・選択肢順をシャッフルする
- 時間制限を設ける
- 1 ページ 1 問、戻れない逐次進行にする（完全ではない）
- 受験直後の正解表示を制限し、問題の流出を遅らせる
- 問題バンクを定期的に差し替える
Houston (1983) 以降、ランダム化の効果はよく引用される。Moodle で MCQ を組む話 でも、シャッフルとランダム出題が中心に据えられている。いずれにせよ、意欲的な不正をゼロにはできない。
教員側が過信しがちな点
運用でハマりやすいところだけ、箇条書きにする。
- 記録があっても、それが不正の証明になるとは限らない。統計は「調べ始める理由」止まりのことが多い。
- 成績レポートだけ見っても、ページ別時間・IP・回答変更履歴は分からない。
- SEB を入れても、VM や改ざんクライアント、BYOD だけの監督では限界がある。
- autosave のギャップは参考情報。タブ切替の決定的証拠にはなりにくい。
- プロクタリングや録画を入れるなら、プライバシーと事前告知が先だ。
- 受験者に「何が記録されるか」を伝えること自体が、対策になる（本記事を書いた理由の一つ）。
- 本番前に、SEB・パスワード・時間制限・autosave を受験者視点で一度試す。ここをサボると当日詰む。
おわりに
Moodle 5.x の小テストでは、成績・回答・統計・手動採点の四レポートから、得点や Facility Index（設問別の正答率に近い値）、選択肢の分布、試験全体の所要時間などを、教員が標準 UI だけで確認できる。ページごとの回答時間や IP は、そこには出てこない。
SEB や IP 制限、ランダム出題は有効だが、Moodle が不正を自動判定するわけではない。記録と処分のあいだには、いつも距離がある。教員はその距離を前提に、出題設計と運用、必要なら追加ツールを組み合わせるのが現実的だ。受験者側にとっても、「バレないだろう」より、何が残りうるかを知ったうえで受ける方が、結果的に自分のためになる。