フロンティアWeb API 2026年版：WebGPU・WebTransport・WebCodecsは本番投入できるのか

Webプラットフォームは、2024〜2026年の2年間で、その前の10年分以上の新しい能力を獲得しました。

WebGPUは2026年1月にBaseline入り。WebTransportは3月に追随。WebCodecsはSafariのマイナー1リリースを残すのみ。View Transitionsは「クロスドキュメントのアニメーション」をフレームワーク不要で実現できるタグになりました。さらにSpeculation Rules、Document Picture-in-Picture、Compute Pressure──Chromium系ブラウザ向けの「目立たない便利API」も、すでに測定可能なビジネス成果を生んでいます。

CTO・テックリード・VP of Engineeringにとって、もはや問いは「Webは十分に強力か」ではありません。「この四半期、どのフロンティアAPIに賭けるか」「どのAPIはまだ"待ち"か」──意思決定のフレームこそが必要です。

本記事は2026年4月時点での実用ガイドです。各APIについて、現在のブラウザ対応状況、本番投入事例、「採用すべきか／待つべきか」の判断、そして再利用可能な意思決定フレームを提示します。

この記事の対象者: CTO・VPエンジニアリング・テクニカルプロダクトマネージャー、および今後12カ月のロードマップでブラウザ側の新機能採用を検討する開発リード。WebGPU・WebTransport・WebCodecs・WebXRの本番投入を評価中の方。

要点まとめ

• WebGPUは2026年1月にBaseline化。Chrome、Edge、Firefox（Windows + macOS Tahoe）、Safari 26+ がすべて安定版で対応。Linux Firefoxや古いSafariへのWebGL2フォールバックは依然必要だが、「待ちの時代」は終了。
• WebTransportも2026年3月にBaseline化（Safari 26.4が対応）。WebRTCの複雑なシグナリングなしで、低遅延・双方向通信が実用ツールとして使えるようになった。
• WebCodecsは"ほぼBaseline"。Safari 26で全機能対応、Firefoxデスクトップはデコード+多くのエンコードが完了。Zoom Web、Loom、Adobe Premiere Webなどが既に依存している。
• WebNNはまだ本番投入できない（2026年4月時点）。Chrome 147〜149のOrigin Trialのみ。ブラウザ内ML推論は引き続きWebGPU + transformers.js / ONNX Runtime Webが主流。
• View Transitionsの同一ドキュメント版はBaseline、クロスドキュメント版はFirefox未対応。Astro 4・Nuxt 3が一級サポート。プログレッシブエンハンスメントとして使うのが実務的。
• Apple Vision PronoWebXRはVRのみ対応。ARセッションはvisionOS・iOS Safariともに未実装。Quest 3が「ブラウザでフルARが動く唯一の主要デバイス」という状況は変わらず。
• WebUSB・WebHID・WebSerial、Speculation Rules、Document PiPはChromium系のみ。MozillaとWebKitはハードウェア系APIに公式に反対の立場。これらは「いつか他ブラウザに来る」ではなく「永久にChromium専用」と織り込んで判断すべき。

1. 2026年のブラウザ地形：何が変わったのか

最大の変化は、特定のAPIがリリースされたことではなく、Appleの「待たせる」パターンが終わったことです。

2010年代後半から2020年代前半、Webプラットフォームのペースを決めていたのは「WebKitが出荷を拒否している機能」でした。WebGPU、WebTransport、WebCodecs、View Transitionsクロスドキュメント──いずれもCupertino待ち。ところがSafari 17（2023年9月）からSafari 26（2025年9月）までの約24カ月で、その慣性は崩れました。AppleはWebGPU、View Transitions（同一・クロスの両方）、Document Picture-in-Picture、そして完全版のWebCodecsを次々と出荷しました。

具体的なビフォーアフター：

計画への影響：これまで「ポリフィル」「フォールバック」「諦める」のいずれかだった機能が、本格実装の対象になりました。「Chromium専用フロンティア」のカテゴリは縮小しましたが、消滅はしていません。WebUSB・WebHID・Speculation Rulesなど、MozillaとWebKitが公的に反対している一部のAPIは、永久にChromium専用のままと考えるべきです。

2. WebGPU：Baselineになった、で、何ができるのか

現状

WebGPUは2026年1月にBaseline入りしました。実装状況：

• Chrome / Edge: v113（2023年5月）から安定版。Linuxは2024年中にフラグ解除。
• Safari:Safari 26.0（2025年9月）でmacOS Tahoe 26、iOS 26、iPadOS 26、visionOS 26にて安定版対応。
• Firefox: Windowsはv141（2025年7月）から安定版。macOS Tahoe 26 ARM64はv145から。Linux・Android・Intel Mac対応は2026年中に進行中。

実務上の死角はLinux FirefoxとA12世代以前の旧iPhone。日本の主要B2BおよびプロシューマーマーケットなどでWebGPUを主路線、WebGL2を5〜10%のテール向けフォールバックとして配置すれば十分です。

本番事例

• Figmaは2025年9月からWebGPUの段階的本番ロールアウトを開始。GPU種別・OS・ブラウザごとのメトリクスを監視しながらパーセンテージを上げています。動機はWebGLのバグの温床だったグローバルステートからの脱却と、CPUからGPUへの並列処理移行。
• Three.jsはr171（2025年9月）以降、WebGPURendererを推奨レンダラとして提供。設定不要のインポート、WebGL2への自動フォールバック付き。
• transformers.js v3（Hugging Face、2024年10月）はWebGPUバックエンドを追加。Whisper-baseがWebAssembly-SIMDより約5倍高速化。
• **WebLLM (MLC AI)**はLlama-3クラスのモデルをApple Siliconノートブック上で15〜25トークン/秒で動作させており、すべてWebGPUコンピュート上で完結します。

採用判断

今すぐWebGPUを主路線にすべきケース:

• 新規のThree.js / Babylon.jsプロジェクト（WebGPUレンダラが推奨デフォルト）
• ブラウザ内ML推論（transformers.js、ONNX Runtime WebのWebGPU EP）
• GPGPUコンピュート──パーティクル、流体、画像処理パイプライン
• ドローコール多発でWebGL2がフレームバジェットを超えているシーン

WebGL2フォールバックを残すべきケース:

• Linux Firefoxユーザー（macOS / Linuxバックエンドが安定するまで）
• A12 SoC未満のiOS端末（iPhone XS / 2018年以前）
• 厳格なブラウザポリシーがある法人顧客

注意点: WebGPUのシェーダーコンパイルは非同期。コールドロード時の初回フレームコストは200msを超えることがあります。GPUShaderModuleとパイプラインステートを積極的にキャッシュし、重要パイプラインは初回ユーザー操作前にアイドル時間で温めておくこと。

3. WebTransport：2026年3月にBaseline化

現状

WebTransportは2026年3月、Safari 26.4の対応によりBaseline入りしました：

• Chrome / Edge: M97（2022年1月）から安定版、フラグなし。
• Firefox: v114（2023年6月）から安定版。
• Safari:26.4（2026年3月）から安定版。

WebTransportはHTTP/3 / QUIC上で、双方向の信頼性ストリームと不信頼性データグラムを単一APIで提供します。これまでの「制御はWebSocket、低遅延はWebRTC DataChannel」という手作りの構成を置き換えます。

本番事例

• Cloudflareはエッジ全体でWebTransportエンドポイントを提供。Workers + Durable Objectsとの組み合わせで、チャット・ゲーミング・オブザーバビリティ向けのファンアウトパターンに使用。
• ライブメディア配信プラットフォームは、LL-HLSからWebTransportへの移行を進めており、グラス・トゥ・グラスで500ms以下の遅延を狙っています。
• クラウドゲーミングとリモートデスクトップはデータグラム経路を入力・フレームACKに、信頼性ストリームをコントロールプレーンに使用。

パフォーマンス利得

ロスのあるネットワークでは、QUIC経路がWebSocket-over-TCPに対しておよそ1RTT分有利（0-RTT再開）、加えてパケットロス時のヘッドオブラインブロッキングを回避します。実測値はモバイル住宅ネットワーク上で30〜50%の遅延ジッタ削減に集中しています。

採用判断

今すぐ使うべき:

• クライアント・サーバー両方をコントロールできる場合（B2B、社内ツール、専用アプリ）
• 利用CDNがHTTP/3対応（Cloudflare、Fastly、Akamaiは対応、独自オリジンサーバーは未対応の場合あり）
• UDPがブロックされる企業ネットワークでWebSocketフォールバックを許容できる

待つべき:

• 厳格なUDP制限のある企業ネットワークが主流のトラフィックミックス──フォールバックの複雑さが利得を食い潰す
• 既存のWebSocketスタックが遅延予算を満たしている──移行のための移行は工数の無駄

注意: WebTransportはサーバー側にHTTP/3が必要。ALB背後のレガシーオリジン、クラシックロードバランサ、HTTP/2のみのリバースプロキシではインフラ整備が先。

4. WebCodecs：ほぼBaseline、本番実績豊富

現状

WebCodecsはVideoEncoder、VideoDecoder、AudioEncoder、AudioDecoderを提供──プラットフォームのハードウェアコーデックパイプラインに直接アクセスします。MediaRecorderや<video>要素の抽象化を完全にバイパス。

• Chrome / Edge: M94（2021年9月）から安定版。
• Safari:VideoEncoder/Decoderは Safari 16.4（2023年3月）から、音声+残りはSafari 26（2025年9月）で完了。
• Firefox: デスクトップはデコード+多くのエンコードが2024年中に完了。Androidは未対応。

日本市場のミックスでは、WebCodecsを「Baseline+注釈つき」として扱うのが妥当。VideoEncoder.isConfigSupported()で実行時にハードウェアコーデックの存在を確認すること。AV1エンコは2026年時点でChrome専用、HEVCエンコはプラットフォームライセンス+ハードウェア対応が必要です。

本番事例

• Zoom WebクライアントはWebCodecs + WebAssembly + WebTransport上で再構築済み。デスクトップSDKシムへの依存を解消。
• Loomはブラウザ内動画エンコード・トリムをWebCodecsで実装。編集操作で従来のMediaRecorder比約10倍高速化を報告。
• Twitchの低遅延プレーヤーはLL-HLS+では到達できなかった1秒未満のパイプラインにVideoDecoderを採用。
• Discordは画面共有・ステージ機能のH.264ハードウェアエンコにWebCodecsを使用。
• **Adobe Premiere Web（ベータ）**はクライアント側プレビューエンコにWebCodecsを使用。

採用判断

今すぐ使うべき: ブラウザ内動画ツーリング全般──スクリーンレコーダー、ビデオチャット、低遅延プレーヤー、Web版NLE、リアルタイムエフェクトパイプライン。

注意点:

• コーデック対応はプラットフォーム依存──必ずfeature detectionを。
• AV1エンコは2026年時点でChrome専用。普遍的カバレッジが必要ならAV1+H.264のデュアルコーデック構成を。
• Firefox AndroidはWebCodecsを完全に欠如。モバイルFirefox観客向けにはフォールバックが必要。

5. View Transitions：同一ドキュメントは無料、クロスドキュメントは仕上げ

現状

View Transitionsには2つのサーフェスがあります：

• 同一ドキュメント（document.startViewTransition）: Chrome 111、Safari 18、Firefox 133+。Baseline。
• クロスドキュメント（マルチページアプリ）: Chrome 126、Safari 18.2。Firefox: 未対応、2026年中に進行。

SPAでは同一ドキュメントView Transitionsを「全員にリーチするエンハンスメント」として扱えます。MPA / 静的サイト構成（Astro、Eleventy、フォーム駆動ナビゲーションのプレーンHTML）では、クロスドキュメント版は依然Chrome + Safariのみ。

本番事例

• Astro 4.0（2023年12月）はクロスドキュメントAPIを使う<ViewTransitions />を一級サポート。多くのスターターテンプレートでデフォルト。
• **Nuxt 3.10+**はページトランジション設定経由でView Transitionsを統合。
• Linear、GitHub（一部のレビューフロー）、Chrome.com自体が同一ドキュメントトランジションをアプリ内ナビゲーション仕上げに使用。

採用判断

プログレッシブエンハンスメントとして今すぐ使うのが妥当。SPAならif (!document.startViewTransition) return;でゲート。フォールバック（瞬時スナップ）はUXとして許容できるので、コストはほぼゼロ。

MPA構成ではChrome + Safariユーザー向けにクロスドキュメントトランジションを出荷し、Firefoxは「トランジションなし」としてフォールバック。多くのユーザーは気づかないし、気づくユーザーには洗練された体験を提供できます。

アクセシビリティの注意: 必ずprefers-reduced-motion: reduceチェックでラップ。トランジション中のフォーカス順をテストすること──スクリーンリーダーがアニメーション途中でアナウンスを発火することがあり、不快な体験になります。

6. WebNN：まだ「待ち」──WebGPU + ONNX Runtime Webを使う

現状

Web Neural Network APIは、ブラウザにプラットフォームのNPU（Apple Neural Engine、Intel/Qualcomm/AMD AIアクセラレータ）への直接アクセスを提供する設計です。

• Chrome:M147〜M149でOrigin Trial。Androidは除外。2026年4月時点で安定版未到達。
• Edge: ChromeのOTスケジュールに追従。
• Safari、Firefox: 未対応。

W3C仕様は2026年1月にCandidate Recommendation入り、生成AIユースケース対応の作業継続中。WebNNがデフォルト経路になる本番投入時期の現実的な見通しは2027年以降です。

代替スタック

2026年のブラウザ内ML本番投入では、実用的なスタックは：

• WebGPUコンピュートを推論バックエンドに
• transformers.js v3でHugging Faceモデル（テキスト・ビジョン・音声）
• ONNX Runtime WebのWebGPU実行プロバイダで一般的なONNXグラフ
• MLC WebLLMで〜8BパラメータまでのLLMワークロード

このスタックで既にWhisper、Llama-3-8B、Stable Diffusion-Turbo派生、BERT系分類器、ほとんどのVision Transformerが消費者ハードウェアで実用速度で動作します。

再評価のタイミング

WebNNがWebGPUに対して持つ優位性は、専用NPUへのアクセス──Copilot+ PC、ニューラルエンジン搭載のApple Silicon、Snapdragon Xラップトップなどで効きます。INT8量子化トランスフォーマー推論をNPU搭載ハードウェアで最後の2〜4倍引き出す必要がある場合、2026年後半に再評価を。それ以外ではWebGPUが堅実な賭けです。

7. WebXR：Vision Pro登場、しかしAppleのARはまだVR専用

現状

• Chrome（デスクトップ + Android）: M79（2019年12月）から安定版。ARモジュールはARCoreでM81以降のAndroid。
• Meta Questブラウザ: WebXR完全対応、ハンドトラッキング含む。immersive-arパススルーは2023年から。
• Apple Vision Pro Safari（visionOS 2.0+）: visionOS 2（2024年9月）からWebXRデフォルト有効。VRセッションのみ──immersive-arモジュール未実装。
• iOS Safari、macOS Safari、Firefox: WebXR非対応。

2025年最大の動きはVision PronoWebXRデフォルト有効化。WebKitの「Natural Input for WebXR」（gaze + pinchをselectイベントに）と組み合わさり、Vision ProはQuest 3に続いて「実用的なWebXRストーリーを持つ2台目の主要デバイス」になりました。

注釈：visionOSは依然immersive-arをサポートしません。MR体験はネイティブアプリでの提供が必須。ブラウザベースARはモバイルChrome+ARCoreのみが選択肢で、Quest設置台数より消費者リーチは小さい。

本番事例

• Matterportは3D不動産ツアーをQuestとVision PronoWebXRで提供。
• 8th Wall（Niantic）──主にマーカーベースAR、マーケティング活用が増加。
• 産業トレーニングベンダ（Bosch、Volkswagen）はBabylon.js + WebXRでブラウザベースVR訓練を出荷。

採用判断

今すぐ使うべき: 観客がQuest、Vision Pro、AR対応モバイルで、デスクトップ／iPhone Safariユーザーには2Dフォールバックを許容できる場合。

待つべき: クロスデバイスの没入型ARが必要な場合。visionOSのARサポートが律速依存。公開されたタイムラインなし。「iPhoneでのAR」を要求するB2Cキャンペーンには、ネイティブAR（USDZ Quick Look、ARKitアプリ）が依然唯一の現実的な経路です。

8. シングルベンダー・フロンティア：Chromium専用APIの実用ガイド

これらのAPIはChromeとEdgeに搭載され、FirefoxとSafariには出荷されません。それでもChromium主体の観客には価値があります。

Speculation Rules API

状況: Chrome 122（2024年2月）。Safari、Firefox、ロードマップなし。

何をするか: 宣言的にprefetchとprerenderを指定。同一オリジン・クロスオリジンのルールを記述すれば、ブラウザが「次に行きそうなページ」を事前レンダリングし、ナビゲーションが実質ゼロ秒に。

実測値（本番デプロイ）：

• Scalemates.com: P95 LCPが約500ms高速化。P75 LCPは537ms（プリレンダー）vs 714ms（標準）。59%のナビゲーションがプリレンダーをトリガー。
• Ray-Ban: スペキュレーティブプリロードによりデスクトップコンバージョンが156%増加。

採用判断: トラフィックの50%以上がChromium系であるコンテンツサイトやコマースフロー。観客の半分にメリットなしでもROIは高い。<script type="speculationrules">を1ブロック追加するだけ。Astro、Next.js、Nuxtでフレームワークサポートあり。

Document Picture-in-Picture

状況: Chrome 116（2023年8月）、Edge 116。Safari 18.4（2025年3月）で対応。Firefox未対応。

何をするか: 任意のHTML（<video>に限らず）をフローティングの常時最前面ウィンドウに配置できます。Google Meet、Slackハドル、YouTube Musicが採用。

採用判断: ブラウザ内ミーティング、通話、メディアアプリで「フォローミー」モードに価値があるなら。Safari対応が2025年に到達したことで、消費者観客の約95%で実用化。

WebUSB / WebHID / WebSerial

状況: Chrome / Edge安定版（WebUSBは2017年から、WebHIDとWebSerialは2021年から）。FirefoxとWebKitは公的に「有害」のスタンス──クロスブラウザ出荷はありません。

採用判断: キオスク、POS、ハードウェアプログラミングツール、ブラウザデプロイをコントロールできるB2B社内アプリ。Square、Stripe Terminalブラウザ SDK、Espruino IDE、Arduino IDE Webが依存。

避けるべき場面: 消費者向けクロスブラウザ製品。ベンダ集中リスクは「永続的」と扱う。

Compute Pressure API

状況: Chrome 125（2024年5月）デスクトップ、その後モバイル。Safari、Firefox未対応。

何をするか: nominal | fair | serious | criticalのCPU圧力状態を提供。アプリは適応する──ビデオ解像度を下げる、エフェクトを無効化、物理演算を間引く。

Google Meetが熱圧力下のレイアウト降格に使用。動画・ゲーム・グラフィック重い系アプリでChromium観客が重要なら、プログレッシブエンハンスメントとして実装する価値あり。

File System Access vs Origin Private File System

showOpenFilePicker()等はChrome専用継続。OPFS──Origin Private File System──はクロスブラウザ（Chrome、Safari、Firefox対応）。許可ダイアログなしのサンドボックス化ローカルファイルストレージが欲しいときの正解。VS Code Web、Excalidraw、PhotopeaがパフォーマンスクリティカルなファイルIOにOPFSを使用。

9. フロンティアAPIに賭ける前の5つの問い

本記事に挙げていないAPI（Web Locks、Background Fetch、Storage Buckets、Sanitizer API、fenced framesなど）にもそのまま使える再利用可能なフレームです。

1. あなたのユーザベースでの真のブラウザ対応率はどうか？

直近30日のアナリティクスを引き、caniuse.comとクロスチェックして、APIが使えるセッションの実パーセンテージを計算する。「Chromium系だから全員カバー」と思い込まないこと──iOSのChromeはWebKitです。「Firefoxはもう死んだ」とも思わないこと──多くのB2Bや開発者ツール観客では5〜15%。

2. フォールバック経路のコストは？

30%のユーザにフォールバックが必要なら、自問する：本当に2つの実装をビルド・テスト・保守するか？ 答えが「主路線をしっかり作って、フォールバックはスタブにする」なら、そのフォールバックは既に壊れている。コミット前に正直になること。

3. ユーザに見える ROI vs 実装コストは？

毎日叩かれるツールでエンコ20%高速化はエンジニアリング価値あり。セッションあたり1回しか走らないフローで100ms節約は無価値。先に測定、次にAPI選定。

4. ベンダ集中リスクは？

タイミングのずれでChromium専用なAPIもあれば（Speculation Rules、Document PiP──両方ともいずれSafariとFirefoxに来る可能性は高い）、MozillaとWebKitが明示的に反対しているからChromium専用のAPIもあります（WebUSB、WebHID、WebSerial）。後者は「永久にシングルベンダー」と扱い、リスクをコストに織り込むこと。

Mozillaは標準ポジション、WebKitは標準ポジションを公開しています。賭ける前に読むこと。

5. クリーンに feature detect & degrade できるか？

1行で済むAPIもある: if ('startViewTransition' in document)。実フォールバック実装が必要なAPIもある: if (await navigator.gpu?.requestAdapter())はWebGL2レンダラを別途用意する必要がある。先にAPIなし経路を計画することで、問い2への正直さが強制されます。

10. Utsuboについて

Utsuboは大阪を拠点とするインタラクティブクリエイティブスタジオです。以下の領域で活動しています：

• WebGPUおよびThree.js開発──本番グレードのWeb Graphics、リアルタイムビジュアライゼーション、ブラウザ内MLパイプライン
• 没入型Web体験──ストーリーテリングサイト、プロダクトコンフィギュレーター、ゲームスタジオ向けWebサイト
• インタラクティブインスタレーション──美術館、リテール、公共空間

WebとPhysicalの両面で2024年からWebGPUの本番運用実績があり、2025年大阪・関西万博では100万パーティクル規模のリアルタイムインスタレーションを納品。Awwwards、FWA、The Webby Awardsで評価されています。

WebGPU、WebTransport、WebCodecs、WebXRの実プロジェクト評価をご検討中なら、アーキテクチャ・ベンチマーキング・本番ロールアウト（地味だが必須のフォールバック実装も含む）でお手伝いできます。

技術的な詳細はWebGPU + Three.js移行ガイド、Three.js 2026年版レビュー、Three.jsベストプラクティス100選もご参照ください。

11. ご相談ください

2026年のWebプラットフォームで野心的なものを構築中ですか？私たちはエンジニアリングチームと協業し、WebGPU採用、リアルタイム通信アーキテクチャ、ブラウザ内ML、没入型Web体験のプロジェクトに取り組んでいます。

パートナーシップをご検討中なら、プロジェクトについてお話ししましょう：

• 何を構築しているか、どのような制約があるか
• 観客とタイムラインに対してどのフロンティアAPIが適切か
• 私たちが実行をお手伝いするのに適したパートナーかどうか

プロジェクトについて相談する

メールをご希望ですか？ contact@utsubo.co

フロンティアAPI採用チェックリスト

今後12カ月で出荷を検討中のフロンティアAPIに対して、このリストを当ててみてください。

• 自社アナリティクスから実ブラウザ対応率を取得した（汎用グローバル統計ではなく）
• caniuse.comでChrome / Edge / Safari / Firefox の安定版状況を確認した
• 出荷していないベンダ（あれば）を特定し、その公式標準ポジションを読んだ
• フォールバック経路なしで完結できるセッションの割合を試算した
• 先にフォールバック経路を設計した──そして実際にビルド・テストする予算を確保した
• ユーザに見えるROI（遅延、コンバージョン、機能性）を定量化した──「気持ちが良い」だけではなく
• 実行時にfeature detectする（User Agent sniffingではなく）
• 採用メトリクスをログに残し、フォールバック廃止の判断材料にする
• APIのOrigin Trial / Candidate Rec / Baseline ステータスを確認した──「ベータ出荷中」ではなく
• アクセシビリティへの影響を確認した（特にView Transitions、WebXR）

出典・参考資料

• caniuse — WebGPU
• caniuse — WebTransport
• caniuse — WebCodecs
• caniuse — View Transitions
• Figma Rendering: Powered by WebGPU
• WebKit blog — Safariリリースノート
• Chrome Platform Status
• Mozilla 標準ポジション
• WebKit 標準ポジション
• Chrome — Speculation Rulesでプリレンダー
• Hugging Face — transformers.js v3
• visionOS 2でWebXRがデフォルト有効

よくある質問

WebGPUは2026年に本番投入できますか？

はい。WebGPUは2026年1月にBaseline入りしました──Chrome 113+、Edge 113+、Safari 26+（macOS Tahoe、iOS、iPadOS、visionOS）、Firefox 141+（Windows）/ 145+（macOS Tahoe ARM64）が安定版で対応しています。Linux Firefoxと A12未満のiPhoneはWebGL2フォールバックが必要。Three.js、Babylon.js、transformers.js、Figmaは既に本番で使用しています。

2026年、WebSocketの代わりにWebTransportを使うべきですか？

WebTransportは2026年3月にSafari 26.4対応とともにBaseline入りしました。クライアントとサーバーを両方コントロールでき、CDNがHTTP/3対応で、観客がUDPフレンドリーなネットワークを許容できる場面では、WebTransportがより適切なツールです。低遅延マルチプレイ、クラウドゲーミング、リアルタイムオブザーバビリティでは、ロスのあるモバイルネットワーク上でWebSocketに対して30〜50%の遅延ジッタ削減を実現します。一般的なリクエスト/レスポンスやチャットワークロードでは、WebSocketの方がシンプルで十分です。

2026年、ブラウザ内MLにWebNNを使えますか？

まだです。WebNNはChrome Origin Trial M147〜M149で、SafariやFirefoxの実装はありません。2026年の本番ブラウザMLには、WebGPU + transformers.js v3 + ONNX Runtime Web（WebGPU実行プロバイダ）の組み合わせが実用スタック。ワークロードがCopilot+ PCやApple SiliconのNPUアクセスから明確に恩恵を受ける場合、2026年後半にWebNNを再評価してください。

WebXRはiPhoneやVision ProのARに対応していますか？

いいえ。2026年4月時点で、Vision Pro（visionOS 2.0+）のWebXRはVRセッションのみ対応──immersive-arは未実装です。iOS SafariはWebXRに全く対応していません。ブラウザベースARの唯一の主要選択肢はAndroid Chrome + ARCore。iPhoneのARには、ネイティブARKitアプリとUSDZ Quick Lookが本番経路として残ります。

WebUSB、WebHID、WebSerialは使う価値がありますか？

はい、ただしChromiumをコントロールできる環境のみ──キオスク、B2B社内ツール、ハードウェアプログラミング、POSシステムなど。MozillaとWebKitはセキュリティ上の理由で3つすべてに公的に反対しており、クロスブラウザ出荷はありません。永久にシングルベンダーAPIとして扱い、それに合わせて予算を組むこと。

フロンティアAPIの正しいフォールバック戦略は？

先にフォールバック経路を設計すること。APIなしのユーザに何が見えるかを明確に説明できず、実装する予算もないなら、そのAPIは出荷できません。User Agentスニッフではなく、実行時のfeature detection（if ('feature' in window)）を使うこと。採用メトリクスをログに残し、利用率が閾値を下回ったらフォールバックを廃止できるようにすること。多くのAPIでは「Baselineブラウザ向けにフロンティア経路、テール向けに洗練されたフォールバック、エントリーポイントで単一のfeature detect」が正しいパターンです。

WebGPUはWebGLよりどれくらい速いですか？

ワークロードに完全に依存します。ドローコール多発のシーンでは、WebGLのドローコールごとのバリデーションオーバーヘッドが消えるため、WebGPUは通常2〜10倍高速。GPGPUコンピュート（パーティクル、ML推論、画像処理）では、WebGLのトランスフォームフィードバック回避策に対して10〜100倍高速になり得ます──さらにWebGLでは不可能だったコンピュートシナリオを可能にします。シンプルなシーンでは差は小さく、シェーダコンパイル時間が初回フレームコストを支配することがあります。

観客がミックスのとき、Speculation Rulesに賭けるコストは？

低い。Speculation Rulesは静かに劣化します──非Chromiumブラウザは<script type="speculationrules">タグを完全に無視。観客の50%にメリットがなくても、残り50%は実質ゼロ秒のナビゲーションを得ます。本番デプロイ（Scalemates、Ray-Ban）はLCPとコンバージョンの有意な改善を報告。唯一のリスクは過剰プリレンダーで、eagernessを保守的に設定し、サーバ負荷を監視すること。