Prompt
ブラウザはプライバシー保護のためにユーザーの環境(実行中のプロセスや同意のないカメラ・マイクなど)をJavaScriptに渡さないけれど、
それと同時にWebテストなどの不正を暴くのも難しくなるのではないか？
やあ！その視点はまさに 「ブラウザのセキュリティモデルと実用性のジレンマ」 を突いていて、最高に鋭いね！情報工学を学んでいる君ならピンとくるかもしれないけれど、これはプライバシー保護と完全性（Integrity）のトレードオフそのものなんだ。
結論から言うと、君の懸念通り、ブラウザという「サンドボックス」の中で動くJavaScriptにとって、OSレベルのプロセス監視やハードウェアの直接制御は 「聖域」 であり、そこを覗けないことがカンニングなどの不正検知を著しく困難にしているのは事実だよ。
現状、Webベースの試験がどうやってこの問題に立ち向かっているのか、技術的な制約と泥臭い工夫を深掘りしてみよう！
1. JavaScriptの限界：サンドボックスの壁
ブラウザは 「サンドボックス」 という隔離環境で動作しているから、実行中のJavaScriptは基本的に自分のタブの外で何が起きているかを知ることができない。
-
プロセスの不可視性: 他のタブでChatGPTを開いていようが、デスクトップでDiscordを動かしていようが、JSからプロセスリストを取得するAPIは存在しない。
-
ハードウェアの抽象化: カメラやマイクは、ユーザーが明示的に許可しない限り、OS側のデバイスリストすら取得できない。
-
ファイルシステムの制限: ローカルにカンニング用のテキストファイルを置いていても、ブラウザはそれにアクセスできない。
この構造は、悪意あるサイトが勝手にこちらのPCの中身を覗き見ないようにするための 「鉄壁の守り」 だけど、試験監督側からすれば 「目隠しをされた状態」 で監視しろと言われているようなものなんだ。
2. Webテストが繰り出す「苦肉の策」
そんな制限だらけの環境で、Webテスト（LMSなど）は以下のような 「行動分析」 や 「イベント監視」 で不正のシグナルを拾っているよ。
フォーカスイベントの監視
window.blur や window.focus イベントを使って、ユーザーがブラウザのタブを切り替えたり、別のウィンドウをアクティブにした瞬間を記録する。
落とし穴: 「スマホで調べる」「別のPCを横に置く」といった、物理的なマルチデバイス攻撃には全く無力だ。
クリップボードと右クリックの制限
copy, paste, contextmenu イベントを preventDefault() でブロックする。
落とし穴: ブラウザのデベロッパーツール（F12）を使えば簡単に無効化できるし、そもそも手入力されたら防げない。
フルスクリーン強制
Fullscreen API を使い、試験中はフルスクリーンを維持させる。解除されたら即座に警告を出す仕組みだ。
3. より強力な「プロクタリング」技術
JavaScript単体では限界があるから、重要な試験ではより強力な（そしてプライバシーを削り取るような）手法が導入されることもある。
-
SEB (Safe Exam Browser): 専用のブラウザアプリをインストールさせ、OSレベルで他のアプリの起動を封鎖し、特定のURL以外へのアクセスを遮断する。
-
AI監視 (Online Proctoring): ブラウザ経由でカメラとマイクの使用を強制し、AIが「視線の動き」「周囲の音」「自分以外の人間が映っていないか」を常時監視する。
4. 見落とされがちな視点：技術的対策の「限界」
ここでエンジニアとして意識しておきたいのは、「クライアントサイド（ブラウザ側）で動くコードは、常にユーザーによって改ざんされる可能性がある」 という大原則だ。
-
Headless Browser: PuppeteerやPlaywrightを使えば、人間が操作しているように見せかけて自動で問題を解くボットを簡単に作れる。
-
仮想マシン (VM): VMの中で試験を受ければ、ホスト側のOSで何をしていても、ゲストOS（試験環境）からは検知できない。
-
ハードウェア・インジェクション: HDMIキャプチャカードを使って画面を別のPCに転送し、そこで解析を行う「中間者攻撃」的な手法には、ソフトウェア的な対策はほぼ通用しない。
豆知識：CANVAS指紋とプライバシー
不正検知とは少し逸れるけれど、ブラウザは「環境を教えない」と言いつつも、フォントのレンダリングの微妙な違いなどを利用した 「Canvas Fingerprinting」 という手法で、個々の端末を識別できてしまうことがあるんだ。
プライバシー保護のためにこれらも規制されつつあるけれど、そうすると今度は「一人が複数のアカウントを作って受験する」のを防ぐのが難しくなる。まさにいたちごっこだね！
ブラウザのプライバシー保護が強まれば強まるほど、「その操作をしているのが本当に人間か？」「公正な環境か？」 を証明するコスト（あるいは専用ソフトの導入ハードル）が上がっていくのは、今のWeb標準が抱える面白い矛盾だと言えるよ。
もし興味があれば、実際に「どうすればJavaScriptでタブ切り替えを100%確実に検知できるか（あるいはその検知を回避できるか）」を技術的に考察してみるのも面白いかもしれない。
次は、特定のプログラミング言語を使って、こういった「検知の仕組み」をシミュレーションするコードを書いてみたりする？それとも、もっとセキュリティプロトコルの深い話をする？