1. TOP
  2. ブログ
  3. 「Google Chrome 104」安定板のリリースで実装されたRegion Captureとは

「Google Chrome 104」安定板のリリースで実装されたRegion Captureとは

細かなバージョンアップを繰り返し、順調に進化を続けている「Google Chrome」。
2022年6月には安定板としてChrome104がリリースされ、いくつかの新機能が実装されています。
今回の記事では、その中でも画面共有を便利にする新たな機能「Region Capture」を中心にご紹介していきましょう。

この記事でわかること
・Region Captureとはなにか
・Google Chrome 104で搭載されたその他の機能について
・ブラウザとアプリの境界線について

Region Captureとは

「Region Capture」は、DOM要素を指定して画面を共有できるようにする新機能です。
ChromeやSafari、Edgeといったモダンブラウザには、画面共有できる機能がすでに実装されています。この機能を使って、WEB会議などのサービスを利用することが可能となります。

しかしこれまでは、タブごとの指定しかできなかったため、本来であれば見せたくない部分まで共有してしまったり、入子状態になることで無限にループする画面が表示されたりすることがありました。
今回、Region Capture機能を使うことにより、このような不都合を避け、見せたい部分だけを切り取って画面共有することができるようになります。

現在のところ、対応しているDOM要素は、<div>と<iframe>の2種類だけとなっています。

これを利用して、例えば現在表示しているタブの中でiframeで指定してあるVideo Trackの部分だけ切り抜いて共有することが可能です。
タブの他の領域に表示されている参加者一覧など不要な部分を共有から外すことで、前述のような不都合が生じるのを避けることができます。

Region Captureの制限と特徴

「Region Caputure」には以下のような制限と特徴があります。

・CropTarget.fromElements()に渡すことができるDOM要素には制限があり、現在のところ<div>と<iframe>のみ

・生成されたCropTargetはシリアライズが可能。postMessageでiframeなどに渡すことができる

・cropTo()で切り出せるビデオトラックは、同じタブのビデオのみ

・ターゲット領域がウィンドウ外に出ると、映像は取得されない

・切り出した映像は、RTC Peer Connectionを使ってWeb RTCで送信することができる

などです。

Googleはユースケースの中で、従来の方法で画面共有した時にユーザーがウィンドウのリサイズをした際に発生する問題について言及しています。
従来の方法だとリサイズに合わせて適切な共有をすることが困難であり、時には意図しない範囲が切り取られてしまうなどの問題が起こります。
しかし、DOM要素を指定することでうまくこの問題を回避し、ウィンドウサイズに合わせた適切な表示をすることが可能となります。

このように、ブラウザ上で動作するWEB会議システムなどを利用する時に、新しく実装された「Region Capture」が威力を発揮することになります。もちろん、WEB会議にかかわらず、さまざまなWEBサービスでの応用が考えられますので、開発者サイドにも利用者にも大きな恩恵が期待できる新機能です。*注1

Google Chrome 104で搭載されたその他の機能

今回発表された「Chrome104」には、他にも多くの新機能が実装またはテスト導入されています。

◯Media Queries Level 4をサポート

メディアクエリは閲覧する画面の状態に応じてスタイルシートを切り替えることができる仕組みで、レスポンシブルデザインを実現することができます。
Level4のサポートで、メディア特性クエリの指定方法に不等号やブーリアン値が使えるようになりました。これにより視認性が高く、わかりやすい指定が可能となります。

例えば最小ビューポートを指定するとき、従来であれば

@media (min-width: 400px)

だったものが、Media Queries Level 4の構文なら不等号を使うことで

@media (width >= 400px) 

と表現することができます。
これだけであれば大した違いはないように思えますが、いくつかの幅指定を複合させる場合に明らかな差が出てきます。

◯Shared Element Transitions機能がオリジントライアル開始

ネイティブアプリは、いくつかの画面をスムーズに切り替えながら、ユーザーにとって使いやすいUIを提供しています。
しかしWEBアプリの場合、この画面遷移が相対的に難しく限られた画面の中でサービスを完結させることが多くなります。
たとえ画面遷移をしたとしてもレスポンスに影響が出たり、ネイティブアプリほどの使い勝手を実現しにくいという課題を抱えています。

Shared Element Transitions機能はこの問題を解決する仕組みであり、スムーズに画面遷移ができるようにしてくれます。
CSSアニメーションを利用することで、画面遷移する際にフェードインやスライドインなどの効果を実現することも可能です。これまでのWEBアプリではなかった新しい操作感を提供してくれる機能です。

オリジントライアルは、新しい機能をユーザーに提供することでフィールドテストをおこなう目的で利用されています。ユーザビリティ・実用性・効果をWeb標準化コミュニティにフィードバックすることで、新機能をテストしブラッシュアップしていくことになります。

この他にも、コントロールをグループ化してカーソルキーで移動できるようにする機能や、ユーザーがクレジットカードデータの保存をオプトアウトできる機能など、多くの項目が追加されています。*注2

ブラウザとアプリの境界線

ブラウザは元々、HTMLで記述されたページを表示する目的で開発されたものです。HTML言語を使うことによって、異なる環境やOSでも同じように表示することが可能となり、インターネットの普及を支える重要な基盤技術の一つとなりました。

HTML言語は「ハイパーテキスト」と「マークアップ言語」を融合させたものです。
ハイパーテキストは簡単にいうと「リンクを文章に埋め込む」ことです。青字・アンダーラインで装飾された文字列をクリックすると、そこに埋め込まれているURLを参照し、リンク先のページを開いてくれます。

この仕組みにより、ユーザーは意識することなく関連する情報を世界中のサーバーから次々に閲覧することができるようになります。

またマークアップ言語は元々、学術文章を印刷する際の体裁を整えるための仕組みでした。
文章の要素ごとにタグをつけることによって、最も美しく適切な大きさやフォントで印刷されるようにするものです。版組のための仕組みとしてスタートしたのが元来のマークアップ言語でした。
このマークアップ言語がWEBページに採用されることで、新たなタグが開発・導入されていき、現在のように様々な機能を実現することができるように進化しました。

このような進化により、WEBサービスは今や個別の端末上で動作するネイティブアプリと遜色ない機能や性能を持つことができるようになりました。
もちろん、インターネット回線の速度が向上したことや、スマホやタブレットなど常時ネットアクセス可能な端末が広く一般に普及したことも大きな要因となっています。

開発者側にとってWEBアプリ開発には、いくつかの決定的なメリットがあります。
一つ目は端末ごとの差異を気にせず開発できるという点です。ネイティブアプリの開発には、スマホだけでも膨大な種類が存在し、画面サイズやOSなども異なります。そのため、全てのバリエーションでうまく動作するかどうかのチェックは、事実上不可能です。

WEBアプリであれば、そんなことはほとんど気にせずに済みます。いくつかの主要なブラウザでの動作さえ確認できれば良く、OSごとに異なるプログラムを組む必要もありません。そのため、開発スピードとコストに圧倒的な差が出ます。

もう一つの大きなメリットとしては、プラットフォームの審査を待つ必要が無いという事です。
iPhoneアプリの場合、Apple Storeに登録するために厳しい審査を通過しなければいけません。iPhoneは、Apple Store以外からアプリをインストールすることが原則できませんので、Apple Storeへの登録はiPhoneアプリの開発者にとって最初のハードルとなります。

Androidも事情は似たようなものであり、審査と言うハードルが開発者にとって常に重荷になります。
さらに無事審査を通過しユーザーに提供できるとなっても、一定の手数料がプラットフォーマーに徴収されてしまいます。エンドユーザーにはその分も加味した価格設定で提供せざるを得ません。
しかしWEBアプリであれば、これらのハードルが一切関係なくなります。

近年では、DWA(Progressive Web Apps)という仕組みが登場しています。
この仕組みを利用すると、ブラウザで利用するWEBアプリであるにもかかわらず、プッシュ通知などネイティブアプリしかなかった機能が使えるようになります。
端末上にまるでネイティブアプリのようにアイコンを配置し、WEBアプリと意識せずに使うことが可能です。*注3

【まとめ】

今回の記事ではGoogle Chrome 104のリリースに関して、「Region Capture」などの機能の一部についてご紹介しました。
一時はIEだけが唯一絶対のブラウザという時代もありましたが、現在はChromeやSafari、Opera、Edgeなど数多くのモダンなブラウザが存在し、ユーザーが自由に選択することができます。
それぞれが個性を活かし新たな機能の開発競争をすることで、私たちにとってより良いWEBサービスの実現に結び付き、新しい可能性が広がっていくのではないでしょうか。

建築・土木業向け BIM/CIMの導入方法から活用までがトータルで理解できる ホワイトペーパー配布中!

❶BIM/CIMの概要と重要性
❷BIM/CIM導入までの流れ
❸BIM/CIM導入でよくある失敗と課題
❹BIM活用を進めるためのポイント
についてまとめたホワイトペーパーを配布中


▼キャパの公式Twitter・FacebookではITに関する情報を随時更新しています!

■参考文献

注1 

W3C “Region Capture”

https://w3c.github.io/mediacapture-region/#definitions

Chrome Developers “Better tab sharing with Region Capture”

https://developer.chrome.com/docs/web-platform/region-capture/

Zenn 「Chrome M104で実装されるRegion Captureを試してみた」

https://zenn.dev/mganeko/articles/region-capture

WebRTC M104 リリースノート

https://groups.google.com/g/discuss-webrtc/c/PZxgk-aUFhw

GIgazine 「「Google Chrome 104」安定版リリース、画面共有を便利にするRegion Capture機能を実装」

https://gigazine.net/news/20220803-google-chrome-104/

注2

窓の杜 「「Google Chrome 104」がベータ版に ~「Region Capture」などの新機能をサポート」

https://forest.watch.impress.co.jp/docs/news/1420381.html

SOFTANTENNA 「Chrome 104 Betaがリリース – Region Captureや新しいMedia Query Syntaxのサポートなど」

注3

Pantograph 「PWAとは?Webサイトを「ほぼアプリ化」する方法」

https://pantograph.co.jp/blog/production/pwa.html

    ホワイトペーパーフォームバナー

    【DL可能な資料タイトル】

    • ・プログラムによる建築/土木設計のQCD(品質/コスト/期間)向上
    • ・BIM/CIMの導入から活用までの手引書
    • ・大手ゼネコンBIM活用事例と建設業界のDXについて
    • ・デジタルツイン白書
    • ・建設業/製造業におけるデジタルツインの実現性と施設管理への応用

    詳細はこちら>>>

    カテゴリ一覧

    PAGE TOP