ブログ

Mozilla Hacksに掲載された 「Why is WebAssembly a second-class language on the web?」 を紹介します。

この記事は、WebAssemblyが2017年の登場以降大きく進化してきた一方で、Web上ではまだJavaScriptほど自然に扱えない、という問題を整理しています。低レベル言語をWebに持ち込める強力な仕組みでありながら、実際に使うには読み込み、リンク、Web API呼び出し、型変換、ビルドツールなど、多くの周辺知識が必要になります。

なぜ“二級市民”に見えるのか

記事の中心にある指摘は、WebAssembly自体の性能や言語機能ではなく、Webプラットフォームとの統合の薄さです。JavaScriptなら <script> で読み込み、DOMやConsole APIをそのまま呼び出せます。一方でWebAssemblyは、読み込みにWebAssembly JS APIを使い、Web APIを呼ぶにはJavaScript側のグルーコードを挟む必要があります。

このグルーコードは、文字列や構造体をJavaScriptとWasmメモリの間で変換し、Web APIへの橋渡しをします。自動生成ツールである程度は隠せますが、言語ごとに仕組みが違い、ビルドやデバッグの負担として残ります。結果として、WebAssemblyは平均的なWeb開発者にとって「必要に迫られたときだけ使う高度な選択肢」になりやすい、という見立てです。

リンク先から見えた補足

記事内で参照されている WebAssembly Community Group は、WebAssemblyの仕様や提案の多くがGitHub上で議論されていることを案内しています。WebAssemblyは単一のブラウザ機能というより、複数のブラウザ実装者とツールチェーン関係者が進める標準化の集合体として見る必要があります。

解決策として記事が注目しているのが WebAssembly Component Model です。Component Modelのドキュメントでは、コンポーネントを相互運用可能なWebAssemblyライブラリやアプリケーションのための広いアーキテクチャとして説明しています。WITでインターフェースを記述し、異なる言語やランタイム間で機能をつなぎやすくする方向です。

また、ES module integration proposal は、WebAssemblyモジュールをJavaScriptのモジュールシステムに近い形で扱うための提案です。さらに Component Modelの仕様リポジトリ や Creating Components を見ると、C/C++、C#、Go、JavaScript、Python、Rustなど複数言語からコンポーネントを作る導線が用意されつつあることが分かります。

気づき

この記事を読んでの気づきは、WebAssemblyの普及を妨げているのは「速いか遅いか」だけではなく、「普通のWeb開発の流れに乗れるか」だという点です。技術的には使えるものでも、読み込み方やAPI連携に大きな段差があると、チームや個人の選択肢には入りにくくなります。

Component Modelが面白いのは、WebAssemblyを単なる高速な実行形式ではなく、言語・ツール・Web APIをまたいで共有できる部品の形式へ近づけようとしているところです。これが進めば、WebAssemblyは「特別な最適化手段」から、「JavaScript以外の言語でも自然にWebを作るための基盤」へ変わっていく可能性があります。

読んでおきたい人

Rust、C/C++、Go、PythonなどからWeb向けのアプリやライブラリを作りたい人、WebAssemblyを導入したいがツールチェーンの複雑さで止まった経験がある人には特に参考になります。WebAssemblyの将来像を、性能の話だけでなく開発体験の話として捉え直せる記事です。

参照元: Why is WebAssembly a second-class language on the web? – Mozilla Hacks（2026年2月26日公開）

Mozilla Hacksに掲載された 「Launching Interop 2026」 を紹介します。

Interop Projectは、Apple、Google、Igalia、Microsoft、Mozillaなどが参加し、Web開発者とユーザーにとって効果の大きい領域でブラウザ間の互換性を高める取り組みです。記事では、2025年の成果を振り返りつつ、2026年に取り組む20のフォーカスエリアと4つの調査エリアが紹介されています。

Interop 2026で扱われるテーマ

2026年の新しいフォーカスエリアには、Cross-document View Transitions、Scroll-driven animations、WebTransport、CSS container style queries、JavaScript Promise Integration for Wasm、CSS attr()、Custom Highlights、Scoped Custom Element Registriesなどが並びます。どれも単体で見ると個別機能の話ですが、Interopで扱われる意味は「複数ブラウザで同じように使えるところまで持っていく」ことにあります。

記事が強調しているのは、新機能だけではありません。Navigation API、CSS scroll snap、CSS anchor positioning、WebRTC、CSS user-select、CSS zoomなど、すでに存在する機能のエッジケースも対象になっています。開発者にとっては、機能があるかどうか以上に、「書いたコードがブラウザごとに微妙に違う挙動をしないか」が実務上の痛点になるためです。

リンク先から見えた補足

記事内で参照されている Web Platform Tests は、複数ブラウザで同じテストを実行するための共通テストスイートです。Interop 2026 dashboard では、そのテスト結果をもとに進捗を追えるようになっています。

さらに、Interop 2026のGitHub上の一覧を見ると、各フォーカスエリアごとに提案、テスト、仕様、MDNドキュメントが紐づけられていることが分かります。たとえばCSS attr()、contrast-color()、dialogs and popovers、fetch uploads and ranges、IndexedDBのgetAllRecords()などは、開発者が日常的に触れるAPIやUI実装に近い領域です。

また、記事内リンクの State of HTML 2025 や State of CSS 2025 は、開発者の関心や痛点を把握する材料として参照されています。Apple、Google、Igalia、MicrosoftもそれぞれInterop 2026の発表を出しており、同じ年に同じ領域へ取り組むこと自体が、このプロジェクトの重要な価値になっています。

気づき

この記事を読んでの気づきは、Interopは「次に流行るWeb機能の一覧」ではなく、「仕様・テスト・実装のズレを減らすための運用」だという点です。新しいAPIが増えることよりも、曖昧な仕様を直し、足りないテストを足し、ブラウザごとの差分を測れる状態にすることが、結果として開発者の時間を大きく節約します。

特に印象的なのは、テストの点数が高くても、実際の挙動がブラウザ間でずれていれば十分ではない、という視点です。Web開発で困るのは「非対応」だけではなく、「対応しているはずなのに微妙に違う」状態です。Interop 2026は、その見えにくいコストを減らす取り組みとして読むと、かなり実務的な意味が見えてきます。

読んでおきたい人

フロントエンド開発者、UIコンポーネントやデザインシステムを作る人、ブラウザ互換性で時間を取られた経験がある人には特におすすめです。個別の新機能を追うだけでなく、Webプラットフォームがどうやって安定した共通基盤になっていくのかを知る入口になります。

参照元: Launching Interop 2026 – Mozilla Hacks（2026年2月12日公開）

Mozilla Hacksに掲載された 「Behind the Scenes Hardening Firefox with Claude Mythos Preview」 を紹介します。

この記事は、Claude Mythos Previewを含むAIモデルを使ってFirefoxの潜在的なセキュリティバグを見つけ、修正していった舞台裏を説明しています。単に「AIがバグを見つけた」という話ではなく、再現可能なテストケースを作り、既知バグとの重複を整理し、トリアージし、修正をリリースへ流し込むところまで含めた、実運用のセキュリティパイプラインとして語られているのがポイントです。

AIレポートを信号に変えるには仕組みが要る

記事では、AI生成の脆弱性報告は少し前まで誤検知が多く、オープンソースの保守者にとって負担になりがちだったと説明されています。そこから状況が変わった理由として、モデル自体の能力向上に加え、Mozilla側がモデルを使うためのハーネスや検証手順を整えたことが挙げられています。

重要なのは、モデルにコードを眺めさせるだけではなく、仮説を立て、再現用のテストケースを作り、実際に動かして確認する流れです。Firefoxのような大規模なコードベースでは、検出そのものよりも、重複排除、優先順位付け、修正、リリース管理まで接続することが実用化の鍵になります。

リンク先を読むと見える背景

記事内で参照されている 「The zero-days are numbered」 では、Firefox 150でClaude Mythos Preview由来の271件の脆弱性修正が含まれたことが説明されています。続く Anthropic Red Teamとの先行協力の記事 では、再現可能なテストケースを含む報告だったこと、Firefox 148で22件のCVEにつながる修正が行われたことが紹介されています。

一方で、Firefox側はAIだけに頼っているわけではありません。IPC Fuzzing with Snapshots では、プロセス分離されたブラウザのIPC境界を効率よく検査するためのスナップショットファジングが説明されています。RLBoxの記事 では、WebAssemblyを中間表現として使い、危険になり得るライブラリを細かく隔離する防御層が紹介されています。

また、Firefox 150のリリースノート には「Various security fixes」としてセキュリティ修正への導線があり、Mozilla Foundation Security Advisory 2026-30 ではFirefox 150で修正されたCVEが公開されています。公開アドバイザリや Client Bug Bounty Program まで含めて見ると、AI支援の発見は、既存の透明性あるセキュリティ運用に組み込まれていることが分かります。

この記事の読みどころ

開発者にとって参考になるのは、AIを「魔法の監査役」として扱っていない点です。Mozillaは、モデルの出力をそのまま信じるのではなく、プロジェクト固有のテスト環境、ファジング基盤、バグ管理、リリース運用に接続して、実際に修正可能な情報へ変換しています。

大規模プロダクトだけでなく、一般的な開発チームでも示唆があります。AIにコードを読ませるだけで終わらせず、再現テスト、重複確認、影響度評価、修正後の回帰テストまで流れを作ることが、AI支援のセキュリティレビューを現実的な品質改善に変える条件になりそうです。

参照元: Behind the Scenes Hardening Firefox with Claude Mythos Preview – Mozilla Hacks（2026年5月7日公開）

Mozilla Hacksに掲載された 「Trustworthy JavaScript for the Open Web」 を紹介します。

この記事のテーマは、Webアプリで実行されるJavaScriptをどう信頼するかです。エンドツーエンド暗号化をうたうメッセージングアプリや、金融・医療のような高機密なWebアプリでは、ブラウザ上で動くコードそのものが安全であることが重要になります。しかし従来のWebでは、ユーザーのブラウザに届くJavaScriptはサーバーが配信するため、サーバーが侵害された場合に、特定のユーザーへ改変コードを配るリスクが残ります。

WAICTが解こうとしている問題

記事で紹介されているWAICTは、Web Application Integrity, Consistency and Transparencyの略です。Webアプリが配るクライアント側コードをマニフェストに結びつけ、そのマニフェストを公開監査できるログへ記録することで、「実行されたコードが公開された内容と一致しているか」を検証しやすくする考え方です。

これにより、強い信頼モデルが必要なサイトはWAICTの enforcement にオプトインし、公開ログに記録されていないコードが届いた場合にはブラウザ側で拒否できるようになります。攻撃を完全になくすというより、これまで見えにくかった改変や差し替えを、観測・検証可能なものにする方向の提案です。

参照リンクから見えた補足

記事内で参照されている waict.dev では、WAICTの説明に加えて、ブラウザ対応チェックやデモアプリへのリンクが用意されています。そこでは、Firefox Nightlyで初期プロトタイプが試せること、現時点では他のブラウザが明確な立場を示していないことも説明されています。

また、WAICTの仕様リポジトリでは、WAICTがSubresource IntegrityやIntegrity-Policyの考え方を土台にしつつ、サイト全体のリソースとマニフェスト、公開ログの証明を組み合わせようとしていることが分かります。仕様案には、reportモードとenforceモード、マニフェストURL、max-ageなどのヘッダー設計も含まれています。

関連する講演は Real World Crypto 2026 の文脈で紹介されており、Firefox Nightlyは将来版の機能を早期に試すためのチャンネルとして案内されています。つまりWAICTは、すぐに一般サイトへ導入する完成機能というより、実装・標準化・フィードバックを進めるための初期段階の提案として読むのがよさそうです。

開発者が注目したい点

WAICTの面白さは、Webの配信モデルを維持しながら、アプリのコード完全性と透明性を上げようとしている点です。特に、E2EE、セキュアな業務アプリ、ウォレット、内部向け管理画面など、サーバーを完全には信頼しきれない脅威モデルを扱うプロダクトでは、今後の議論を追う価値があります。

まだ実験段階ではありますが、「ブラウザで開くだけで使える」というWebの強みと、「配信されたコードを第三者が検証できる」というセキュリティ要件をどう両立させるかを考えるうえで、重要な記事です。

参照元: Trustworthy JavaScript for the Open Web – Mozilla Hacks（2026年5月5日公開）

Mozilla Hacksに掲載された 「Announcing Web Serial Support in Firefox」 を紹介します。

この記事のポイントは、デスクトップ版Firefox 151でWeb Serial APIがサポートされることです。これにより、Webアプリからマイコン、開発ボード、3Dプリンタ、USB電力計などのシリアル接続機器と直接やり取りできるようになります。専用のネイティブアプリやインストーラに頼らず、ブラウザ上のUIからハードウェアを扱える場面が広がるのが大きな変化です。

どんな用途で効いてくるか

記事では、AdafruitのCircuitPython導入ツールや、ESP32系ボード、Raspberry Pi Pico、Home AssistantとESPHomeのような実例が紹介されています。教育、電子工作、ホームオートメーション、プロトタイピングのように、ブラウザと小型デバイスを組み合わせるワークフローでは特に恩恵がありそうです。

もうひとつ面白い例として、USB電力計から取得したデータをFirefox上で可視化し、Firefox Profilerにエクスポートする使い方も挙げられています。Webの技術が、単なる画面表示だけでなく、実世界の測定やデバイス制御にも自然につながっていく流れが見えます。

セキュリティとプライバシーの設計

ハードウェアにアクセスできるAPIだけに、許可の扱いも重要です。Firefoxでは、サイトが勝手に接続機器一覧を取得するのではなく、ユーザーが明示的にポートを選んだ場合にだけアクセスできる設計が説明されています。サイト単位・ポート単位で許可されるため、不要なフィンガープリンティングを抑える考え方です。

また、Firefox Enterprise PoliciesではWeb Serialが初期状態で無効になっており、組織側が明示的に許可・禁止を管理できる点も紹介されています。業務環境での利用を考える場合、この制御は重要な判断材料になります。

読んでおきたい理由

Web Serialは、Webアプリの可能性をハードウェア領域へ広げるAPIです。すでにChrome系ブラウザで使われてきたワークフローがFirefoxでも扱いやすくなることで、教材、開発ツール、デバイス設定画面、測定ツールなどの選択肢が増えます。

Webとデバイス連携に関心がある開発者、電子工作や教育向けツールを作っている人、ブラウザベースの設定・計測UIを検討している人には、ぜひ読んでおきたい記事です。

参照元: Announcing Web Serial Support in Firefox – Mozilla Hacks（2026年5月21日公開）