LASSIC Media らしくメディア

リアルタイムにデータをやり取りするWebの世界で、近年じわりと存在感を増している技術があります。それが「WebTransport」です。ひとことでいえば、最新の通信規格HTTP/3（その土台となるQUIC）の上で、ブラウザとサーバーのあいだの低遅延な双方向通信を実現する、新しいWeb APIになります。これまでリアルタイム通信の定番だったWebSocketを補い、より速さや柔軟さが要る場面で持ち味を発揮するもの、と捉えるとつかみやすいでしょう。

とはいえ、WebSocketやWebRTCといった似た技術との違いは、言葉だけでは分かりにくい面もあります。本記事では、リアルタイム機能の開発に関わる情報システム部門・事業部門の担当者に向けて、WebTransportとは何か、どんな仕組みなのか、既存の技術と何が違うのか、どんな場面に向くのか、そして受託・委託開発で押さえておきたい点を整理します。なお、仕様はまだ策定の途中にあるため、実際の採用は最新の公式情報を確かめながら進めてください。

WebTransportとは——HTTP/3で動く新しい通信API

WebTransportとは、ブラウザとサーバーのあいだで、低遅延の双方向通信を行うための新しいWeb APIです。土台になっているのは、最新の通信規格であるHTTP/3、そしてそのさらに下で動くQUICという仕組みになります。QUICはUDPをベースにした通信で、従来のTCPにつきまとった「ひとつのデータが詰まると、後ろのデータもみな待たされる」という弱点をやわらげているのが特徴なのです。この土台の上に立つことで、WebTransportは軽快なやり取りを目指しています。

もうひとつの持ち味が、通信のしかたに幅がある点です。もれなく届けたいデータ向けの「ストリーム」と、多少の欠落より速さを優先する「データグラム」の、二つの送り方を使い分けられます。しかも、ストリームは複数を同時に多重化して扱えるのです。用途に応じて、確かさと速さのバランスを選べる——そこがWebTransportの新しさだといえるでしょう。全体像を、図にまとめました。

仕組み——ストリームとデータグラム

WebTransportの仕組みを、少し具体的に見ていきましょう。通信の送り方は、大きく二種類あるのです。ひとつが「ストリーム」で、こちらはもれなく、順序も保ったまま届けたいデータに向いています。しかも、複数のストリームを同時に流せるため、片方のやり取りが詰まっても、ほかのストリームは影響を受けにくいのです。TCPでは避けにくかった待ち行列の問題を、QUICの仕組みでやわらげているわけです。

もうひとつが「データグラム」で、UDPのように軽く速い送り方になります。届く保証はないぶん、多少の取りこぼしよりも速さが大切な場面で力を発揮します。たとえば、オンラインゲームで刻々と変わるキャラクターの位置情報のように、「少し前のデータが欠けても、次の新しいデータが届けば十分」という種類の通信です。この二つを、目的に応じて選び分けられるのが、WebTransportの柔軟なところだといえます。

WebSocket・WebRTCとの違い

似た技術との違いを押さえると、使いどころの見通しが立ちます。まず、WebSocketとの違いです。WebSocketは、一本の信頼できる通信路を張って双方向にやり取りする、リアルタイム通信の定番でした。シンプルで扱いやすく、多くの用途では今もこれで足ります。WebTransportは、そこに複数ストリームの多重化や、速さ優先のデータグラムといった選択肢を足したもの、と捉えると分かりやすいでしょう。

次に、WebRTCとの違いにも触れておきます。WebRTCは、どちらかといえば端末どうしを直接つなぐ（P2Pの）通信で、映像や音声のやり取りに強みを持つ技術です。サーバーを介した双方向通信を主とするWebTransportとは、得意な領域が異なります。そして、WebTransportが土台とするHTTP/3（QUIC）は、Webページの表示を速くする文脈でも語られる規格です。同じ土台の上で、リアルタイム通信を担うのがWebTransportだ、という関係になります。下の表に、大まかな違いをまとめました。

三つは置き換え合うというより、向く場面が分かれると捉えるのが実態に近いでしょう。要件に照らして選び分ける、あるいは組み合わせる、という発想が役立ちます。

得意な場面と、向かない場面

WebTransportが持ち味を発揮するのは、速さや同時性が強く求められる場面です。たとえば、多人数が同時に参加するオンラインゲーム。あるいは、遅れの少なさが大切なライブ配信や、大量の機器からひっきりなしに届くデータの受け口など。こうした「低遅延で、たくさんのやり取りをさばきたい」用途では、複数ストリームやデータグラムという選択肢が効いてきます。従来の手段では取り回しにくかった通信を、すっきり扱える余地があるのです。

反対に、そこまでの速さや同時性が要らない場面では、無理に採り入れる必要はありません。ふつうのチャットや通知、軽いリアルタイム更新であれば、扱い慣れたWebSocketで足りることが多いものです。新しい技術ほど、情報や事例がまだ少なく、対応する環境も限られます。「わが社の要件に、その持ち味がほんとうに必要か」を見極めてから選ぶ姿勢が、遠回りを避ける近道になります。

導入で押さえる点

WebTransportを実際に採り入れる際は、いくつかの前提を押さえておくと見通しが立ちます。まず、対応する環境です。主要なブラウザは対応を広げつつありますが、利用者の使う環境によっては、まだ使えない場合もあります。そのため、WebTransportが使えないときにはWebSocketなど従来の手段に切り替える、といった二段構えを用意しておくと危なげがありません。いきなり全面的に頼り切るのではなく、逃げ道を残しておく構えです。

次に、仕様がまだ固まりきっていない点です。WebTransportの仕様は策定の途中にあり、細部が今後変わる余地が残っています。だからこそ、最新の公式情報を折にふれて確かめながら進めるのが堅実なのです。あわせて、サーバー側もHTTP/3に対応している必要があるため、既存の構成でそのまま使えるとは限りません。どこに手を入れる必要があるのかを、早い段階で見積もっておきたいところでしょう。

受託・委託開発で押さえる実務ポイント

WebTransportを使った開発を外部と進める場合は、いくつかの点を早めにすり合わせておくと見通しが立ちます。出発点になるのが、「そもそもWebTransportが要件に見合うか」の見極めになります。求めているのが本当に低遅延や大量の同時通信なのか、それとも扱い慣れた手段で足りるのか。ここを取り違えると、新しさに引っ張られて、かえって手のかかる作りになりかねません。目的から逆算して技術を選べる相手かどうかが、ひとつの目安です。

そのうえで、対応環境の幅や、使えないときの切り替え、サーバー側の対応といった論点を、設計の早い段階で共有しておきます。仕様が動いている領域のため、最新の状況を追いながら、フォールバックまで含めて設計できる相手だと、任せたあとも落ち着いて進めやすくなるものです。要件の見極めから、技術の選定、フォールバックの設計、検証までを見通して伴走できるかどうかを、委託先選びの視点にするとよいでしょう。

まとめ：WebTransportで押さえる3つの視点

WebTransportは、HTTP/3という新しい土台の上で、リアルタイム通信の選択肢を広げる技術です。押さえておきたい視点は三つに整理できます。第一に、WebTransportはHTTP/3（QUIC）の上で低遅延の双方向通信を実現する新しいWeb APIで、もれなく届けるストリームと速さ優先のデータグラムを使い分けられること。第二に、WebSocketを置き換えるものではなく、ゲームや配信など低遅延が強く求められる場面で持ち味を発揮すること。第三に、仕様が策定の途中で対応環境にも幅があるため、フォールバックを用意し、最新の公式情報を確かめながら進めるのが堅実であること。まずは、自社の要件にその持ち味がほんとうに必要かを見極めるところから始めるとよいでしょう。判断に迷う部分は、公式情報の確認とあわせて、外部の知見を頼るのも手堅い選び方といえます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　参考：MDN Web Docs「WebTransport API」（https://developer.mozilla.org/ja/docs/Web/API/WebTransport_API）。仕様・機能の一般的な参考として。
2. *2　参考：W3C「WebTransport」Working Draft（https://www.w3.org/TR/webtransport/）。策定状況の参照先として。

Tweet