Servoの埋め込みはcrates.ioに載り、Versoは止まった — ウェブビュー断片化問題の2026年中間点検

はじめに — 断片化を受け入れるか、エンジンを同梱するか
2025年3月 — TauriがVersoを試す
2026年7月のVerso — 公式に停止
同じ期間のServo本体 — 月次リリーストレインとcrates.io
LTS 0.1.x — 約束の中身と、約束ではないもの
では断片化問題は解決したのか — いいえ、計算が変わっただけです
今、何を選ぶか — 判断基準
おわりに
参考資料

はじめに — 断片化を受け入れるか、エンジンを同梱するか

ウェブ技術でデスクトップアプリを作るときの計算は、昔からずっと二択でした。Electronのように Chromium をまるごとアプリに同梱すれば、どのOSでも同じエンジンが動いてレンダリングは一貫しますが、アプリ一つひとつがブラウザを一台背負って配布されるだけのサイズ・メモリコストを払います。逆にTauriはwryを通じて、OSにすでに入っているウェブビューを借りて使います — wryのドキュメントによれば、LinuxはWebKitGTK(GTKが必要)、WindowsはEdge Chromiumベースの WebView2、macOSは WKWebView です。バイナリは小さくなりますが、同じフロントエンドのコードが三つの異なるエンジンの上で動くことになります。

この「三つのエンジン」が、実務でウェブビュー断片化と呼ばれる問題です。CSS・JSの機能サポートが入る時期はエンジンごとに違い、更新周期もOSに縛られてバラバラなので、結局三つのエンジンすべてでテストしなければなりません。Tauri陣営がこの問題を知らなかったわけではありません — だからこそ2025年に出てきた実験がServoベースのウェブビュー Verso であり、本稿はその実験が2026年7月現在どこに立っているのかを、リポジトリとレジストリの記録で直接確認した結果です。要約するとこうです。Versoは正式に停止し、まさにここへ来てServo本体の埋め込みのほうがずっと現実的になりました。

Tauri 2自体についての一般論はTauri 2 深掘り編で、ブラウザエンジンの地形はブラウザエンジン 2026編ですでに扱ったので、ここでは2025年以降の変化だけを絞って見ていきます。

2025年3月 — TauriがVersoを試す

タイムラインの出発点は、Tauriチームが2025年3月17日に公開したExperimental Tauri Verso Integrationです。要旨はこうです。

Servoの埋め込みAPIはあまりに低レベルで、複雑なAPIに怖気づいて諦めた人が多く、筆者自身も正直そのひとりだったと書いています。そこでVersoがその上に高レベルAPIを載せ、Tauriはデフォルトランタイム tauri-runtime-wry の代わりに差し込めるカスタムランタイムtauri-runtime-versoでVersoをつなぐ、というものです。
当時すでに動いていたもの — tauri-cliのワークフロー、React + Vite の CSS ホットリロード、公式の log・opener プラグイン、ウィンドウのサイズ・位置・最大化・最小化・クローズなどのウィンドウイング、data-tauri-drag-region 属性。
ただし「プロダクションで使う既存のバックエンドほど機能が豊富ではない」と明記していました。

この作業の資金の出どころも記録に残っています。NLnetのNGI AssureファンドがServo Webview for Tauri(2022-08〜2024-03)とServo improvements for Tauri(2024-04〜2024-08)の二件のグラントを執行しました。つまりVersoは趣味プロジェクトではなく、期限つきのグラントで回っていた実験であり、この事実がのちの結末を理解する鍵になります。

同じブログ記事の「future works」には、見ておくべき一文があります。長期目標として、Windowsの WebView2 のようにシステムに一度インストールされ複数アプリで共有されるエバーグリーンなVersoに触れつつ、そうなれば「アプリの中にブラウザを同梱しなくて済むぶん、バンドルサイズを大きく減らせる」と書いています。裏返して読めば — Verso方式は、そのエバーグリーン配布が実現するまでは、Electronと同種の「エンジン同梱」コストを払うのだ、とTauriチーム自身が認めていたことになります。

2026年7月のVerso — 公式に停止

ここからはリポジトリの記録を見ていきます。日付はすべてGitHub/GitLabのAPIとcrates.ioのレジストリから直接確認した値です。

時点	出来事	根拠
2024-07-13	開発者 Wu Yu Wei によるVerso 0.1紹介記事	wusyong.github.io
2025-03-13	GitLabの`verso-browser/verso`プロジェクト作成 — 開発の本拠地がGitLabへ移り、GitHubはミラーへ	GitLab API `created_at`
2025-06-17	GitLab `main`ブランチの最終コミット	GitLab commits API
2025-07-10	GitLabプロジェクトの最終アクティビティ	GitLab API `last_activity_at`
2025-09-27	プリビルド`versoview`の最終リリース v0.0.9(Servoコミット19da3bcに固定)	tauri-apps/verso releases
2025-10-03	`tauri-runtime-verso`の最終コミット(トラブルシューティング文書の追加)	GitHub commits API
2025-10-08	GitHubミラーへのアーカイブ告知コミット(PR #312)、続いてリポジトリをアーカイブ	versotile-org/verso

アーカイブされたGitHubミラーのREADME告知は丁寧かつ率直です。要旨を訳すと — Versoは現在もはやメンテナンスされていない。このプロジェクトは、Servoが成熟したブラウザへ育つには何が必要かを確かめる試みであり、主要な貢献のいくつかはServo本体へすでに統合されている(開発の舞台裏を綴った記事、2025-05-13)。しかしServoに大きな改訂版が続けざまにリリースされるあいだ、「限られた人員と資金のためにそのペースについていけず」、しばらくリポジトリをアーカイブして再開の機会を待つ、とあります。

GitLab側のREADMEには、さらに実用的な一文が残っています — 「現時点ではServoshell(Servoのデモブラウザ)のほうがより良いユーザー体験を提供するだろう」と、Versoのリポジトリ自身が書き残しています。

いくつか細部も押さえておく価値があります。第一に、tauri-runtime-versoはcrates.ioに一度も公開されたことがありません — READMEのインストール手順は今もgit依存のままです。第二に、プリビルドのversoviewバイナリはx64 Linux/Windows/macOSとarm64 macOSの四種類だけで、最後のバージョン0.0.9が固定するServoは2025年9月時点のコミットです。つまり今この実験を動かしてみると、10か月古いServoの上で動くことになります。第三に、Tauri組織のフォークtauri-apps/versoに2026年5月4日のプッシュはありましたが、中身を開くとCIのログ色とGitHub Actionsのバージョン警告の整理だけ — メンテナンス再開ではなく、リポジトリの掃除です。最後に、この移行がコミュニティに何を残したかを示す数字を一つ — 本稿執筆時点(2026-07-17)で、アーカイブされたGitHubミラーはスター5,404個、本拠地となったGitLabプロジェクトはスター29個です。

同じ期間のServo本体 — 月次リリーストレインとcrates.io

Versoが止まっているあいだ、Servo本体には正反対の方向のことが起きていました。埋め込みが「リポジトリをクローンしてどうにかリンクする」ものから、「レジストリから取ってくる」ものへ変わったのです。

2025-10-20、ServoがGitHubリリースv0.0.1を皮切りに月次リリースへ入りました(v0.0.2は2025-11、v0.0.3は2025-12、v0.0.4は2026-01、v0.0.5は2026-02、v0.0.6は2026-03)。
2026-04-13、公式ブログServo is now available on crates.ioとともにservoクレート0.1.0がcrates.ioに公開されました。Servoをライブラリとして使う初のcrates.ioリリースです(rc1は4月4日)。デモブラウザのservoshellはcrates.ioに公開する計画はないと明言されています。
以後、月次トレインはそのまま回り続けます — 0.2.0(2026-06-05)、0.3.0(2026-06-15)、そして本稿執筆の前日にあたる2026-07-16に0.4.0がcrates.ioに公開されました(同時点でのGitHubリリースノートはまだありませんが、このプロジェクトにはクレートを先に公開し、ノートをあとから付ける傾向があります)。

ブログ記事の自己評価は抑制的です — バージョン番号が示すとおり1.0ではなく、「1.0がServoにとって何を意味するかという議論すらまだ終わっていない」と書かれています。上がっていくバージョン番号は、埋め込みAPIに対する「高まる自信」の表現だ、というのが公式の言い回しです。

月次アップデートがどれほどの密度で回っているかは、最新の月次記事であるMay in Servo(2026-06-30掲載)で確認できます — 0.3.0には5月一か月分のコミット391件が詰め込まれ(3月は534件)、埋め込みAPIの項目としては最小サポートRustバージョンが1.86.0から1.88.0へ上がったこと、クッキー・環境設定・診断APIの作業、SpiderMonkey 140.10.1への更新に含まれたメモリ安全性の修正が明記されています。埋め込み側から見た大きめの機能(たとえばマルチウィンドウ、プロキシ対応)は、December in Servo以降、月次記事のたびに着実に登場しています。

LTS 0.1.x — 約束の中身と、約束ではないもの

crates.ioのバージョン一覧を見ると、順序がおかしいリリースが二つあります — 0.3.0(6月15日)のあとに出た0.1.2(7月5日)です。これがServoのLTSラインです。0.1.0と同時に発表されたLTSポリシーはServo BookのLTS文書に明記されています。

6か月ごとに、そのとき最新の通常リリースをもとに新しいLTSブランチを作り、サポート期間は次のLTSへ乗り換える時間を含めて9か月を見込む。
LTSブランチはセキュリティ修正のみを受け取る。パッチリリースは必要に応じて出され、固定スケジュールはない。
対象範囲はservoライブラリとその依存関係だけで、servoshellは明示的に除外される。
LTSブランチでは最小サポートRustバージョンを上げない。
crates.ioへの公開は「可能な限り」である — 下位クレートのCVE修正が旧バージョンへバックポートされない場合、git依存が必要になり得ると事前に警告している。

この約束が絵に描いた餅でないことは、リリース記録が示しています。v0.1.1(LTS)はSpiderMonkeyをESR 140.10へ上げる依存関係パッチで(5月25日にcrates.ioへ公開)、v0.1.2(7月初旬)はSpiderMonkeyをESR 140.12へ上げ、Mozillaのセキュリティ勧告MFSA 2026-48・2026-58の修正を取り込み、セキュリティ関連の変更24件をLTSへバックポートしたとリリースノートに記されています。JSエンジンのセキュリティパッチを埋め込み側が追いかけて受け取れる経路ができたということであり、これこそ「ウェブエンジンをアプリに同梱する」際にいちばん怖い運用コストに触れる変化です。

ただし、同じ文書にある限界事項は、原文の趣旨のまま訳しておきます — Servoはそのまま(AS IS)提供され、セキュリティを含めいかなる保証もなく、LTSは関心を持つコミュニティメンバーによるベストエフォートであり(現時点で明示されているメンテナーは一人です)、1.0未満であるためプロダクション利用は慎重に評価すべきである。特にこの一文が核心です。

既知の、信頼されたコンテンツをレンダリングするアプリでServoを使うことと、任意のコンテンツをレンダリングするブラウザとして使うこととでは、リスクプロファイルがまったく異なります。

デスクトップアプリの埋め込みはおおむね前者に該当し、Servoチーム自らがその境界線を引いてくれたことになります。

では断片化問題は解決したのか — いいえ、計算が変わっただけです

正直な決算をするとこうなります。

今日のTauriはやはりwryです。 tauriクレートは2026年7月1日の2.11.5が最新で、デフォルトランタイムは変わらずOSのウェブビューを借りるtauri-runtime-wryです。WebKitGTK・WKWebView・WebView2の三エンジンでテストしなければならない現実は、2026年中盤になっても変わっていません。Versoランタイムはその代替になれないまま止まりました。

Servoの経路は断片化をなくす代わりに、同梱コストを呼び戻します。 Servoを埋め込んだアプリはどのOSでも同じエンジンでレンダリングしますが、そのエンジンをアプリと一緒に配布しなければなりません — Tauriチームがエバーグリーンな共有Versoを長期課題に挙げていた理由は、まさにこれです。サイズがどれだけ膨らむかについては、tauri-runtime-versoで作ったアプリのサイズ・メモリの実測値を公開した資料を私は見つけられませんでした — 数字をでっち上げるより、「公表された測定値がない」と書いておくほうが正確です。確かなのは方向だけです。OSのウェブビューを借りれば小さくなり、エンジンを積めば大きくなります。

成熟度のギャップは数の問題ではなく、種類の問題です。 WebKit・Chromiumは数十年に及ぶウェブ互換性作業が積み上がったエンジンで、Servoはまだ1.0の定義すら議論中のエンジンです。月次リリースのたびに破壊的変更が見込まれると公式文書が言うAPIの上に製品を載せるなら、6か月周期のLTSに乗るか、アップグレード作業を常時の予算に組み込むかのどちらかが必要です。

今、何を選ぶか — 判断基準

今日プロダクションのデスクトップアプリを配備しなければならないなら — 選択肢は2025年と同じです。サイズ・メモリが優先ならTauri + wryへ進みつつ三エンジンのテストコストをCIへ織り込み、レンダリングの一貫性が譲れないならElectron系のエンジン同梱を受け入れる、という選択です。この比較の一般論はクロスプラットフォームデスクトップアプリ 2026編にあります。
Tauri + Servoの組み合わせが気になるなら — tauri-runtime-versoは今でもクローンして動かせますが、2025年9月のversoview 0.0.9に固定された、コミットの止まった実験だという事実を知ったうえで触ってください。ここに製品を載せる根拠は現状ありません。
自分のアプリの信頼されたコンテンツだけをレンダリングする埋め込み先なら — 今回、本当に見張る価値が出てきたのはservoクレート自体です。crates.ioから取得でき、LTSブランチが実際にセキュリティバックポートを行っており、月次記事で埋め込みAPIの変更が告知されます。プロトタイプをLTS(0.1.x)に乗せておき、半年後に次のLTSへの移行コストを測り直すのが現実的な第一歩です。
使ってはいけない場面 — 任意のウェブをレンダリングする用途(Servoの文書が引いたまさにその線)、ウェブ互換性の問題を抱えきれないチーム、そして安定したAPIの上でしか回らない組織です。1.0未満という言葉は飾りではありません。

おわりに

2025年春に描かれた絵 — 「VersoがServoを包み、TauriがVersoを載せて、OSウェブビューの断片化から抜け出す」 — は実現しませんでした。人員と資金がグラント終了とともに引き上げると、ラッパー層のほうが先に止まり、その事実をリポジトリたちが淡々と記録しています。代わりに、予想外の進展が下の層から来ました。Servo本体が月次リリースとcrates.io公開、そしてセキュリティバックポートが実際に回るLTSまで備えたことで、「Rustアプリにウェブエンジンをライブラリとして入れる」という文が、2026年には文字どおりcargo add servoになりました。

断片化問題そのものは解決していません。今選べるのは相変わらず「三エンジンでテストする」か「エンジンを持ち運ぶ」かのトレードオフだけで、Servoは後者のコスト構造を変えられる候補として、ちょうどレジストリに登場したばかりです。次の確認時点ははっきりしています — 最初のLTSの9か月サポートが終わる2027年初頭、二つ目のLTSブランチが約束どおり出るかどうか。そのときこの実験がインフラになったかどうかを、あらためて数え直せばよいのです。