【ITニュース解説】Record and share the screen from the browser — getDisplayMedia, and why Electron does the picker differently

画面やブラウザのタブを共有したり、その内容を録画したりする機能は、現代のWebアプリケーションにおいて非常に重要なものとなっている。ビデオ会議システムやオンライン授業、チュートリアル動画作成など、その用途は多岐にわたる。この記事では、Webブラウザ上でこれらの機能を実装するための主要な技術であるgetDisplayMedia APIと、デスクトップアプリケーションフレームワークであるElectronでの実現方法について、システムエンジニアを目指す初心者にも分かりやすく解説する。

まず、Webブラウザで画面共有や録画を行うための基盤となるのが、getDisplayMedia APIである。これは、WebカメラやマイクをキャプチャするgetUserMedia APIの兄弟のような存在で、その使い方には多くの共通点がある。getUserMediaが物理的なデバイス（カメラやマイク）から映像や音声のストリームを取得するのに対し、getDisplayMediaはユーザーの画面全体、特定のウィンドウ、またはブラウザの特定のタブから映像や音声のストリームを取得する機能を提供する。これにより、Webブラウザの拡張機能や特別なプラグインなしに、数行のコードで画面録画機能を実装することが可能となる。

具体的に画面ストリームを取得するには、JavaScriptでnavigator.mediaDevices.getDisplayMedia()という関数を呼び出す。この関数は非同期処理であり、呼び出す際には画面共有に関するオプションをオブジェクトとして渡す。例えば、映像のフレームレートを毎秒30フレームに設定し、音声も同時に取得したい場合は、{ video: { frameRate: 30 }, audio: true }のように指定する。この関数を実行すると、ブラウザは自動的に組み込みのピッカー（選択画面）を表示し、ユーザーはそこで共有したい画面、ウィンドウ、またはタブを選択して「共有」ボタンをクリックする。Webアプリケーションの制約として、開発者がこのピッカーの見た目を変更したり、事前に特定のウィンドウを選択したりすることはできない。これは、ユーザーが何を共有しているかを明確に意識し、セキュリティを確保するためのブラウザの設計思想によるものだ。ユーザーが共有を許可すると、関数は映像や音声のデータを含むMediaStreamオブジェクトを返す。このMediaStreamは、HTMLの<video>要素のsrcObjectプロパティに設定することで、リアルタイムでのプレビュー表示が可能になる。

取得したMediaStreamを録画するには、MediaRecorder APIを利用する。これはgetUserMediaで取得したストリームを録画する際と全く同じ手順で利用できるため、すでにカメラやマイクの録画を経験しているなら、スムーズに理解できるだろう。MediaRecorderのインスタンスを作成する際には、録画したいMediaStreamと、録画データのMIMEタイプ（データの種類と形式）を指定するオプションオブジェクトを渡す。録画データは、細かく分割された「チャンク」として取得されるため、ondataavailableイベントリスナーを使ってそれらを配列に貯めていく。録画が終了した際に発生するonstopイベントで、貯めたチャンクをBlobオブジェクトに結合することで、最終的な録画データ（動画ファイル）が完成する。このBlobオブジェクトからURLを生成すれば、再生したり、ダウンロードリンクとして提供したりできる。MIMEタイプについては、ブラウザによってサポートしている形式が異なるため、特定の形式をハードコードするのではなく、MediaRecorder.isTypeSupported()メソッドを使って、そのブラウザがサポートしている最適なMIMEタイプを動的に選択することが推奨される。例えば、Chromium系のブラウザはWebM形式（VP9/VP8コーデック）を、SafariはMP4形式をサポートしている傾向がある。

実際のアプリケーションで画面共有機能を安定して提供するためには、いくつかの重要な詳細に注意を払う必要がある。一つ目は、ユーザーがブラウザ自身の「共有停止」バーをクリックして共有を停止した場合への対応だ。Webアプリケーション内の停止ボタンが押されたわけではないため、MediaRecorderは停止せずに動き続けてしまう可能性がある。これを防ぐためには、MediaStream内の映像トラック（getVideoTracks()[0]で取得できる）が発火するendedイベントを監視し、このイベントが発生したらアプリケーション側で録画を停止する処理を行う必要がある。この対応を怠ると、ユーザーは共有を停止したつもりでも、アプリケーションは壊れた録画を続けてしまい、混乱の原因となる。

二つ目は、画面共有が終了したら必ずすべてのトラックを解放することである。MediaStreamは、共有が明示的に終了されるまでアクティブな状態を保ち、「共有中」のインジケーターが表示され続ける。不要になったら、stream.getTracks().forEach((t) => t.stop())のように、ストリーム内のすべてのトラックに対してstop()メソッドを呼び出すことで、リソースを解放し、ユーザーへの「共有中」表示も停止できる。

三つ目は、ユーザーが実際に何を共有しているかを知ることの重要性である。ユーザーはモニター全体、単一のウィンドウ、またはブラウザの単一のタブを選択する可能性がある。これらによって、録画される解像度、フレームレート、そして音声の有無が異なる場合がある。stream.getVideoTracks()[0].getSettings()メソッドを呼び出すことで、共有されている画面の各種設定情報（例:displaySurfaceプロパティで「monitor」「window」「browser」のいずれか、幅、高さ、フレームレートなど）を取得できる。この情報に基づいて、アプリケーションの動作を適応させたり、ユーザーに警告を表示したりすることが可能になる。

音声の取得については、audio: trueを設定することでリクエストできるが、これは画面共有機能の中で最も不安定な部分である。ブラウザのタブ内の音声はChromium系のブラウザで比較的良好にサポートされているものの、システム全体の音声をキャプチャする機能はOSに依存し、特にmacOSでは制限が多い。そのため、音声の取得を期待する前に、stream.getAudioTracks().lengthで実際に音声トラックが取得できたかを確認し、ユーザーに確実に提供できない音声を約束しないよう注意が必要である。

getDisplayMediaはデスクトップ版のChromium、Firefox、Safariでサポートされており、セキュリティ上の理由からHTTPS接続されたページまたはlocalhostでのみ動作し、必ずユーザーの何らかの操作（ボタンクリックなど）がトリガーとなる必要がある。iOS/iPadOSのようなモバイル環境ではサポートされていないため、このAPIはデスクトップ環境向けの機能と認識しておくべきだ。

次に、Electronフレームワークを使ったデスクトップアプリケーションにおける画面共有の実現方法と比較してみよう。WebブラウザのgetDisplayMediaでは、ユーザーが共有する画面を選択するためのピッカーはブラウザが提供し、そのUIを開発者が制御したりカスタマイズしたりすることはできない。これは、セキュリティ上の重要な境界であり、ユーザーが意図しない情報を共有しないためのブラウザ側の保証である。

一方、Electronでは、この選択体験を完全に開発者が制御できる。Electronは、Web技術（HTML, CSS, JavaScript）でデスクトップアプリケーションを開発するためのフレームワークであり、通常のWebブラウザよりも高い権限を持つ「メインプロセス」を利用できる。このメインプロセスから、desktopCapturerというAPIを呼び出すことで、システム上の利用可能なすべての画面やウィンドウの情報を、サムネイルやタイトル付きで取得できるのだ。開発者はこれらの情報を元に、自由にデザインしたカスタムピッカーダイアログをアプリケーションのUIとして構築できる。ユーザーがそのカスタムピッカーで共有したいソース（画面やウィンドウ）を選択すると、そのソースIDをgetUserMedia APIのオプション（chromeMediaSourceという制約）に渡すことで、指定された画面やウィンドウのストリームを取得できる。

つまり、根底にある画面キャプチャのエンジンはWebブラウザのgetDisplayMediaとElectronのdesktopCapturerで共通の部分が多いものの、ユーザーインターフェースの制御において大きな違いがある。WebのgetDisplayMediaは、ブラウザとHTTPS環境さえあればすぐに画面録画機能を実装できる手軽さが最大のメリットだが、ピッカーUIをカスタマイズできないという制限がある。対してElectronは、デスクトップアプリケーションとして配布する必要があるという手間はあるものの、ユーザーに提供する選択UIを完全に自由に制御できるという大きなメリットがある。どちらを選択するかは、アプリケーションの要件やユーザー体験の設計に依存する。手軽さを重視するならWeb APIを、より高度なカスタマイズ性とデスクトップ環境との密な連携を求めるならElectronを選択することになるだろう。