ブラウザ画面録画 (Screen Recorder)

Webブラウザ上で動作する画面録画機能は，HTML5標準のMediaDevices APIを中核として構築されています．特に本ツールで利用されている navigator.mediaDevices.getDisplayMedia メソッドは，OSレベルのウィンドウマネージャーやコンポジタと連携し，ユーザーが指定したディスプレイ全体，特定のアプリケーションウィンドウ，あるいはブラウザの特定のタブの画面描画情報を取得する役割を担います．

この処理プロセスにおける最大の特徴は，通常のgetDisplayMedia呼び出しでは，ページ側が共有対象を無断で決定できないという点にあります．メソッドが呼び出されると，ブラウザ自身が提供する安全な権限確認UI（ユーザーインターフェース）が画面上にオーバーレイ表示され，ユーザーはそこで共有したい対象を明示的に選択して許可を与える必要があります．

この選択プロセスを経ることで，意図しない画面情報の共有を防ぐ構造となっています．共有が許可されると，選択されたサーフェスの映像が連続的なフレームとしてMediaStreamオブジェクトにカプセル化され，JavaScript側での取り扱いが可能となります．この仕組みにより，ブラウザのセキュアな環境を維持しながらも，OSのグラフィックスレイヤーからの映像ストリーム取得が実現されています．

また，共有対象がアクティブなタブであるか，バックグラウンドのウィンドウであるかにかかわらず，ブラウザの実装とOSの制約に基づいた適切な更新頻度で映像フレームが生成されます．

画面の映像ストリームと同時に，音声のストリームを取得するためには，複数のAPIを組み合わせた厳格な権限管理の仕組みを理解する必要があります．映像とシステム音声を取得する getDisplayMedia に加えて，ユーザーの物理的なマイクデバイスから音声を取得する際には navigator.mediaDevices.getUserMedia メソッドが用いられます．

これらのAPIはそれぞれ独立した権限モデルを持っており，実行時にブラウザからOSに対して個別のデバイスアクセス許可を要求します．マイクの利用については，ユーザーが明示的に許可ボタンを押下した場合にのみストリームの取得が成功します．一方でシステム音声（PC内で再生されている音）の取得については，getDisplayMedia 呼び出し時のオプションで audio: true を指定することでブラウザに要求を出しますが，これが実際に許可されるか，あるいは選択肢としてユーザーに提示されるかは，OS（Windows，macOS，Linux等）や利用しているブラウザ（Chrome，Edge，Firefox，Safari等）の種類，さらには共有対象として「タブ」を選んだか「画面全体」を選んだかによって大きく挙動が異なります．

特定の環境下ではシステム音声の共有がOSレベルで制限されていることもあり，いかなる場合でも必ずシステム音声が録音できるとは限りません．このようなブラウザおよびOSの多様な制約下において，取得可能なストリームを適切にハンドリングし，エラーが発生した場合でも映像ストリームのみで録画を継続するようなフォールバック処理が実装されています．

画面録画において，システム音声とマイク入力の両方を同時に記録したい場合，単一のMediaRecorderに対して複数の音声トラックを直接渡すことはできません．この課題を解決するため，本ツールではWeb Audio APIが提供する AudioContext を用いて，リアルタイムな音声ストリームのルーティングとミキシング（混合）処理を実行しています．

ユーザーがマイクを含める設定を有効にした上で録画を開始すると，まず getDisplayMedia から取得されたシステム音声（もし存在すれば）と，getUserMedia から取得されたマイク音声のストリームが，それぞれ独立した MediaStreamAudioSourceNode としてWeb Audio APIのグラフ内に取り込まれます．

次に，これらのソースノードから出力されるデジタル波形データは，MediaStreamAudioDestinationNode という最終的な出力ノードに向けて接続されます．この過程で，ハードウェア由来のマイク音声に対するノイズ抑制やエコーキャンセレーションは取得時点でブラウザ側に委ねられており，AudioContext内部ではピュアな波形データの合成が行われます．

合成された単一の音声トラックは，画面の映像トラックと束ねられて新しいMediaStreamを形成し，録画エンジンへと引き渡されます．このミキシング機構により，オンライン会議の様子と自身の解説を同時に記録するような用途に対応可能となりますが，前述の通りシステム音声の取得可否は環境に依存するため，入力ノードの動的な有無判定が極めて重要な役割を果たしています．

映像と音声が統合されたMediaStreamは，最終的に MediaRecorder APIに入力され，クライアントのローカル環境でエンコード処理（圧縮・変換）が行われます．ここで最も重要となるのが，どのような動画形式（MIMEタイプとコーデック）で記録するかという決定プロセスです．

ウェブ標準において広範にサポートされているのはWebM形式（video/webm）ですが，内部の圧縮アルゴリズムには複数の選択肢が存在します．本ツールの実装では，まず高い圧縮効率を誇る「VP9コーデックとOpus音声」の組み合わせ（video/webm;codecs=vp9,opus）の利用を試みます．

MediaRecorder.isTypeSupported() メソッドを用いてブラウザがこの設定でのエンコード能力を持っているかを判定し，対応していない場合は次点の候補として「VP8コーデックとOpus音声」（video/webm;codecs=vp8,opus）へフォールバックします．

さらにそれも対応していない古い環境や特殊なブラウザ向けには，純粋な video/webm を指定してブラウザのデフォルトコーデックに委ねるという三段階の判定ロジックが組み込まれています．この厳格なコーデック選択機構により，出力されるWebMファイルの互換性と品質をブラウザの能力の範囲内で最適化しています．

エンコードの処理自体はブラウザ内部および端末のCPUやGPUに依存して実行されるため，特定の特許技術を要する形式での出力は行わず，オープンな規格であるWebMに特化することで安定性を確保しています．

MediaRecorder によるエンコードが開始されると，圧縮された動画データは一定のタイミングで ondataavailable イベントを通じて細切れのチャンク（データの断片）として出力されます．これらの録画チャンクは，ネットワークを介して録画片を外部の保存先へアップロードする実装はなく，実行中のブラウザのローカルメモリ領域に確保された配列内に順次蓄積されていきます．

これはページ上で録画片を保持する構成を実現するための基幹設計ですが，データの保管場所が揮発性のメモリ上であるという重要な特性を持っています．ユーザーが録画停止ボタンを押下する，あるいはブラウザの共有停止UIを操作することで録画プロセスが終了すると，メモリ上に蓄積された無数のチャンク配列が結合され，単一の巨大な動画データオブジェクトであるBlob（Binary Large Object）が生成されます．

このBlobに対して URL.createObjectURL を呼び出すことで，ブラウザ内部で一時的に参照可能な仮想URLが発行され，画面上のプレビュー用プレイヤーやダウンロード用リンクに紐付けられます．ダウンロード操作が行われると，仮想URLを経由してメモリ上のBlobデータがブラウザのダウンロード処理を通じて .webm 拡張子のファイルとして保存されます．

この一連のライフサイクルにおいて，不要になったObject URLの解放やストリームトラックの停止処理を適切に行うことで，リソースのリークを防いでいます．

前章で述べたように，本ツールの録画データは最終的な保存操作が完了するまでブラウザのメモリ上に蓄積され続ける仕様となっています．このため，数時間に及ぶような長時間の画面録画を継続した場合，ブラウザがプロセスに割り当て可能なメモリの限界値（ヒープサイズ制限）に達し，予期せぬクラッシュや録画データの消失を招くリスクが伴います．

メモリの枯渇による途中終了や，タブの偶発的なリロードに対する自動的な録画復旧機能は備わっていません．したがって，実践的な運用においては，長時間の会議や作業を録画する際，端末のメモリ状況に応じて短い録画で動作を確認し，必要に応じて分割する方法があります．さらに，ブラウザやOSのアップデートにより，getDisplayMedia における権限プロンプトの仕様変更や，ハードウェアアクセラレーションによるエンコード性能の変動が起こり得るというブラウザ依存性にも留意が必要です．

重要なオンライン通話や再現の難しい事象を記録する前には，数秒から数十秒程度の短いテスト録画を実施し，意図した画面が正しくキャプチャされているか，音声が適切に混合されているか，そしてファイルとして正常に保存可能であるかを事前に確認するプロセスを経ることで，録画失敗のリスクを低減させることができます．