#79「11月のWebプラットフォームの新機能」
web.devで公開されているNew to the web platformシリーズの2025年11月の内容を日本語でお届けします!
※ オフラインのため、音声ファイルを再生できません。ネットワーク状況をご確認の上、再度アクセスしてください。
菅原 : 皆さん、こんにちは! ミツエーリンクスの菅原です!
加藤 : 加藤です!
菅原 : ミツエーテックラジオは、株式会社ミツエーリンクスのスタッフが、Webデザイン、 Webフロントエンドなどの、Web技術に関する、ニュースやツールをシェアするポッドキャストです。今回はweb.devに公開されている11月にWebプラットフォームに追加された新機能から、3個のトピックをご紹介します。各機能のブラウザのサポート状況なども紹介していきますが、12月8日時点の内容ですので、ご注意ください。
ミツエーリンクスのWebサイトで公開している文字起こしページには、各機能の仕様や参考リンクなども載せていますので、そちらもぜひご覧ください!では早速まいりましょう!
Atomics.waitAsync()
菅原
: まず1つ目はAtomics.waitAsync()メソッドが、Firefox 145でサポートされました。名前からして、ちょっと難しそうなんですけども、まずは基本となるAtomics APIが何か、から教えてもらっていいですか?
加藤 : はい。Atomics APIを理解するにはまず、SharedArrayBufferを知る必要があって、さらに、SharedArrayBufferの効果を理解するためには、JavaScriptがシングルスレッドであること、そしてWeb Workersの必要性を、理解する必要があります。
菅原 : なるほど…結構寄り道が必要な感じですね。
加藤 : そうですね。あのー複数のAPIが関係しているので、ちょっと難しいように思えますけども、それぞれのコンセプトはそこまで難しくないので、1つずつ理解すれば大丈夫だと思います。まず、JavaScriptがシングルスレッドっていうのは聞いたことあるんじゃないかなと思うんですが、どうですか?
菅原 : えーと、簡単に言えば、一度に1つのことしかできない、ということでしょうか。
加藤 : そうですね。JavaScriptがなぜシングルスレッドなのか、というところから話し始めると長くなってしまうので、ここではそういうものだ、っていう前提で話しますけども、JavaScriptがシングルスレッドであるがゆえに起きてしまう問題として、例えば1秒間に何万回もループするような重い処理をすると、ブラウザが固まってしまうっていう問題があります。
菅原 : ブラウザがフリーズして、スクロールができないとか、クリックが効かないという状態でしょうか。
加藤 : そうですね。それを避けるために用意されているのが、Web Workersです。これは別のスレッドでJavaScriptを動かす仕組みで、一部の処理をWorkerに逃がすことで、ユーザーの操作を妨げることなく、重い処理もできるようになります。
菅原 : なるほど。重い処理はWorkerに任せて、処理の結果をレンダリングするのはメインスレッドで、という役割分担ができるということですね。何となくわかりました。
加藤
: はい。ここで出てくる新しい問題が、メインスレッドとWorkerスレッドは、メモリを直接共有できないということです。それぞれのスレッドで扱っているデータを共有したいときは、postMessage()関数でデータをやりとりする必要があって、やりとりするデータが大きくなるほど、ここのコストが無視できなくなってきます。今度はそれを解決するためにSharedArrayBufferっていうのが出てきます。SharedArrayBufferは、複数のスレッドから同時に参照できるメモリで、これまではデータ自体をpostMessageで丸ごと送っていたんですけど、SharedArrayBufferがあると、同じメモリを共有したまま「ここ更新しましたよ」みたいな合図を、スレッド間でやりとりするだけで済むようになります。
菅原 : 何となくのイメージですが、複数のスレッドから同時に同じメモリを参照できるって、ちょっと危険な感じがしますね。
加藤 : はい、その通りで、あのー片方のスレッドが値を読み込んで処理している間に、もう一方のスレッドが同じ値を変更してしまったりすると、何が正しいか分からない状態になってしまいます。この「どっちが先に書いたか分からなくなる」ような競合している状態のことを、レースコンディションと呼びますけども、この問題を解決するのが、Atomics APIです。
菅原 : おーやっと出てきましたね。
加藤
: はい。ちょっと長かったですね。Atomics APIは、スレッド間のやりとりを整理する交通整理役みたいなもので、「今からこの場所はこっちのスレッドが使うので、他は触らないでください」といった制御ができる仕組みですね。もともとAtomics APIには、ほかのスレッドの処理が終わるのを待機するためのwait()関数というのがあったのですけど、これは同期的に止まるAPIなので、メインスレッドで使ってしまうと、待機している間、画面ごと止まってしまうという問題がありました。
菅原
: なるほど。それでwaitAsync()が必要になるわけですね。
加藤 : はい、その通りです。
菅原
: waitAsync()自体の説明は一瞬でしたね。普通の情報サイトでは積極的にWorkersを使うこと自体あまりないかもしれませんが、逆に画像処理とかが必要になると、ほぼ必須になりそうなので、知っておいて損はないですね。
加藤 : そうですね。
菅原
: waitAsync()はFirefox 145でサポートされたことで、すべてのモダンブラウザで利用できるようになりました。
参考リンク
- 25.4.14 Atomics.waitAsync | ECMAScript® 2026 Language Specification
- Atomics.waitAsync() - JavaScript | MDN
ToggleEvent source プロパティ
菅原
: 続いては、ToggleEventのsourceプロパティについてです。button要素などによって、ポップオーバーやdialog、details要素の開閉状態が変わったときに、ToggleEventというイベントが起きますが、そのイベントオブジェクトにsourceプロパティが追加されて、どの要素がそのイベントを起こしたのか、トリガーとなった要素が含まれるようになりました。
加藤
: はい。これまではbutton要素などがクリックされたタイミングで、そのbutton要素を変数に入れておくなどして、開発者が、トリガーとなった要素を管理しておく必要がありましたけども、それが少し楽になる感じですかね。
菅原
: そうですね。sourceプロパティはChrome、Edge、Firefoxではサポートされていますが、Safariではまだサポートされていません。
参考リンク
- 6.5.1 The ToggleEvent interface | HTML Standard
- 6.5.1 ToggleEventインターフェイス | HTML Standard 日本語訳
- ToggleEvent: source property - Web APIs | MDN
Integrity-Policy および Integrity-Policy-Report-Only HTTP ヘッダー
菅原 : 最後はIntegrity-PolicyとIntegrity-Policy-Report-Onlyの2つのHTTPヘッダーです。これまた難しそうな機能ですね。
加藤
: はい。これもちょっと、寄り道をして、まずはサブリソース完全性、略してSRIというセキュリティ機能について、知っておく必要があります。SRIは、外部から読み込むJavaScriptやCSSが、知らない間に改ざんされていないかをブラウザ側で検証する仕組みで、具体的にはlink要素やscript要素のintegrity属性に、コンテンツのハッシュ値をあらかじめ指定しておくことで、その指定されたハッシュ値と、今から読み込もうとしているファイルのハッシュ値が、一致しているかを、ブラウザが確かめてくれるというものですね。
菅原 : これは、一致しない場合はスタイルが適用されたりスクリプトが実行されることはない、ということですか?
加藤
: そうですね。ただWebサイトが大規模になってくると、サイト内のすべてのlink要素やscript要素にintegrity属性がついているかを、人力で確認していくっていうのは結構大変ですよね。
菅原 : たしかに…見落としたりとかはしそうですね。
加藤
: そうですよね。それを解消するのが、Integrity-Policyヘッダーです。Integrity-Policyヘッダーは「このWebサイトでは、すべてのscriptに有効なintegrity属性が指定されていないといけない」というサイト全体の方針、ポリシーを宣言します。
菅原
: 結構強力ですね…。これは、例えばハッシュ値があっていないscriptだけでなく、そもそもintegrity属性がないscriptなんかも弾かれるということでしょうか。
加藤 : そうなりますね。あのー、さすがにいきなりこのヘッダーを適用するのはなかなかハードルが高いので、そのためにIntegrity-Policy-Report-Onlyという2つ目のヘッダーがあります。これは、違反が見つかったときにブロックするんじゃなくて、指定したエンドポイントにレポートを送信するためのヘッダーですね。
菅原 : なるほど、まずはReport-Onlyのほうを有効にして、今のサイトの状態を確認しながら改善を進められるということですね…。よく考えられてますね。
加藤 : そうですね。あのー、サプライチェーン攻撃はいつ起きるか分からない、もしかしたらすでに起きているかもしれないので、こういった機能は積極的に、活用していきたいところですね。
菅原 : Integrity-Policy、Integrity-Policy-Report-OnlyはChrome、Edge、Firefoxではサポートされていますが、Safariではまだサポートされていません。
参考リンク
- 3.8. Integrity-Policy | Subresource Integrity
- 3.8. 完全性施策ヘッダ | Subresource Integrity
- Integrity-Policy header - HTTP | MDN
- Integrity-Policy-Report-Only header - HTTP | MDN
クロージング
菅原 : 以上、11月にWebプラットフォームに追加された新機能の紹介でした!今回の新機能は、私にはちょっと難しかったです。普段の仕事で使う機会が少なそうというか。ただ、知っておくことで「ここであれが使えるかも!」という引き出しになるので、やっぱりこういう新機能をチェックするのは、ためになるなと思いました。
加藤 : うん、そうですね。あのー今必要かどうかに関係なく、こういう技術を知っているのと知らないのとでは、何か対策が求められたときに、とれる選択肢も変わってくるので、やっぱりこう…Webプラットフォームの動向をチェックしておくっていうことは、大事だなと改めて思いました。
菅原 : 最後に、ミツエーリンクスではスマートなコミュニケーションをデザインしたいUIデザイナー、UI開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますので、チェックしてみてください。
また、このPodcastはApple Podcast、Amazon Music、Spotify、YouTubeで配信していますので、お好みのプラットフォームでフォローいただけると、エピソードをすぐ視聴できます!こちらもぜひご活用ください。「#ミツエーテックラジオ」でご意見、ご感想、こんなこと話してほしいというリクエストなどもお待ちしております。それでは今日はこの辺で!ありがとうございましたー!
加藤 : ありがとうございました!