『遷移がなめらかだから』でSPAを選んできた10年に、View Transitions APIが問うもの

公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。

普通のリンクをクリックする。ブラウザが次のページを取りに行き、一瞬画面が白く抜けてから新しいページが表示される。この「一瞬の白抜け」は、Webがそもそも持っている当たり前の挙動だ。ところが、この当たり前を消すためだけに、この10年、多くのチームはReactやVueでルーティングをJavaScript側に持たせるSPA（シングルページアプリケーション）化を選んできた。画面を丸ごと作り直すのではなく、必要な部分だけをJSで書き換えれば、白抜けは起きない。その代償が、肥大化するJSバンドルと複雑な状態管理だったことは、フロントエンド開発者なら誰もが知っている。

もし「なめらかな遷移」がブラウザのネイティブ機能になり、普通のリンクで遷移するだけのサイト（MPA、マルチページアプリケーション）でも同じ体験が得られるとしたら、SPA化を選んできた理由の一つは消える。これがView Transitions APIを巡る編集部の議論の出発点だった。

結論：View Transitions APIには性質の異なる2つの仕組みがあり、両者を一括りにしてはいけない。同一ページ内の状態変化を扱うsame-document（Document.startViewTransition()）は2025年10月にBaseline Newly Availableへ到達済みだが、ページをまたぐcross-document（@view-transitionルール）はまだLimited availability（Baseline未達）で、Firefoxが対応していない。cross-documentが整備されればMPAのままアプリ的な体験とJSバンドル削減が見込めるが、演出の過剰さや前庭障害への配慮を欠けば技術の進歩がUXの退行になる。今日できるのは、未対応ブラウザでも壊れないプログレッシブエンハンスメント（対応環境では強化された体験を、非対応環境でも基本機能を保証する設計手法）として使うことだ。

same-documentとcross-document、混同してはいけない2つの仕組み

ナオ（Web標準を取材する技術記者）が議論の冒頭で釘を刺したのは、「View TransitionsがBaseline入りしたからSPAは不要になる」という極論への警戒だった。実態はもっと入り組んでいる。

same-document view transitions（Document.startViewTransition()）：同一ページ内でDOMを書き換える際に、変化前後をクロスフェードやモーフィングで滑らかに繋ぐ仕組み。主にSPAのルーティングやUI状態の切り替えで使われる。2025年10月14日、Firefox 144が対応したことで全エンジンが揃い、Baseline Newly Availableに到達した。ただしFirefoxの初期実装はview transition typesを含まないなど一部制約がある。
cross-document view transitions（CSSの@view-transitionルール）：普通のリンククリックによるページ遷移（別ドキュメントへの移動）を対象にする仕組み。MPA向け。2026年7月26日時点でMDNはLimited availability（=Baseline未達）と明記している。Chromeは126から、SafariはSafari 18.2から対応しているが（一部機能は部分対応の可能性がある）、Firefoxは未対応のままだ。

項目	same-document	cross-document
主な対象	SPAの画面内状態変化	MPAのページ間遷移
API	`Document.startViewTransition()`	CSS `@view-transition { navigation: auto; }`
Baseline状況	2025年10月にNewly Available到達済み	Limited availability（Baseline未達）
Chrome	対応	126から対応
Safari	対応	18.2から対応（一部機能は部分対応の可能性）
Firefox	対応（144、一部制約あり）	未対応

表はMDNの各ページとweb.dev公式ブログの記載を基にした編集部の整理。「View Transitionsは対応済み」と書く記事があれば、このどちらを指しているのか必ず確かめる必要がある。

なぜ「なめらかな遷移」にSPAが必要だったのか

技術記者のナオは議論の中で、この10年の前提を次のように整理した。

これまでスムーズな遷移にSPAが不可欠だったのは、ブラウザの「ページ読み込み（リロード）」という破壊的な挙動を、JSによるDOM操作で回避し続ける必要があったからです。

普通にリンクをクリックしてページ遷移すると、ブラウザは前のページを完全に破棄し、新しいHTMLをゼロからパースし直す。その間、画面は一瞬白くなり、スクロール位置や入力中のフォームの状態も失われることがある（ブラウザのキャッシュ機構によって保たれる場合もある）。この体験を避けるには、画面遷移そのものをJavaScriptに肩代わりさせ、必要な部分だけを書き換える「SPA化」がほぼ唯一の現実的な道だった。レン（Webパフォーマンスの専門家）は、この構造がもたらした本当のコストを次のように指摘した。

SPAが抱えてきた最大のコストは、遷移の滑らかさを保つために、非表示のページでも事前にリソースをプリフェッチし、メモリ上に保持し続ける「過剰なリソース消費」です。

つまり「なめらかな遷移」という体験価値のために、JSバンドルの肥大化、複雑な状態管理、見えないページの先読みによるメモリ消費という3つのコストを、多くのチームが払い続けてきたことになる。

cross-documentが普及したら何が変わるのか

ハルト（SPAを長年構築してきたフロントエンド開発者）は、長年の実装経験を踏まえてこう語った。

cross-documentが整備されれば、静的サイトでも高度な演出が可能になり、JSによるルーティング制御の重圧からは解放される。だが、それは「SPAが不要になる」ことと同義ではない。ページを跨いだ共有メモリや高度な状態の同期という、SPAが担ってきた本質的な役割は、依然としてJSによる制御を必要とする。

つまりcross-documentが解決するのは「見た目の連続性」であって、複雑なアプリケーションが必要とする状態同期そのものではない、という切り分けだ。リコ（UIモーションデザイナー）はデザイナーの立場から、この見た目の連続性が持つ意味を補足した。

遷移の価値は「情報の連続性」の提示にあります。cross-documentが整備されれば、MPAのまま、ブラウザのネイティブ機能としてこの文脈を提示できます。これは、演出のために重いJSを読み込む必要がない、軽量なサイト制作への大きな転換点です。

小規模事業者の立場から発言したソラ（Webサイトを持つ小さな事業者代表）は、この転換点の意味をより具体的な言葉で表現した。

これまで、小規模なサイト運営者が「アプリのような使い心地」を実現しようとすると、高額な開発費を払ってSPAを構築するか、複雑なJSを抱えてサイトの表示速度を犠牲にするかの二択を迫られてきました。cross-documentが普及すれば、私たちは「普通のWebサイト（MPA）」のまま、最小限のコストで高度な体験を提供できるようになります。

静的サイトジェネレーターで作られたブログやコーポレートサイトのような、そもそもSPAにする必要のないサイトほど、この恩恵は大きい。普通のHTMLとCSSにわずかな追加を施すだけで、ページ間の遷移に文脈的な連続性を持たせられる可能性がある。

反論1：Firefox未対応のまま本番採用してよいのか

議論はここで、実装上の現実的な懸念に移る。テツオ（事実確認を担う編集者）が指摘したのは「非対称性」の問題だ。

same-documentは2025年10月にBaselineへ到達し全エンジン対応を終えましたが、cross-documentは現在もLimited availabilityであり、Firefoxが未対応のままです。つまり、同じコードを書いても、ブラウザによって「滑らかな遷移」がある環境と、そうでない環境が明確に分断されます。

cross-document view transitionsは、ブラウザベンダーが協調して相互運用性を改善する枠組み「Interop 2026」のフォーカスエリアに含まれている。これは前向きな材料ではあるが、あくまで協調作業が進行中という段階であり、いつBaselineに到達するかを確定的に予測できる材料ではない。「2026年中にBaselineへ到達する」と断定するのは時期尚早だ。

反論2：演出は本質的価値か、前庭障害への配慮はあるか

もう一つの反論の軸は、アクセシビリティだった。ミサ（アクセシビリティの研究者）は次のように警鐘を鳴らした。

開発者がprefers-reduced-motionを無視して「滑らかな遷移」を強制することは、前庭障害を持つユーザーにとって致命的なUXの欠陥となります。技術の進歩が、特定のユーザーを排除するものであってはなりません。

prefers-reduced-motionとは、OSやブラウザの設定で「動きを減らす」を選んでいるユーザーに向けて、CSSがそれを検知できるメディアクエリだ。画面全体の要素が連動して動く遷移演出は、前庭障害（平衡感覚に関わる障害）を持つ人にとって、単なる「かっこいい演出」ではなく、めまいや身体的な不快感を引き起こす障壁になり得る。

リコも、モーション設計の立場からこの懸念に同調した。

「動き」は、情報の遷移を補完するためのものであり、実装の複雑さを隠蔽するためのものではありません。

さらにパフォーマンス専門家のレンは、演出そのものが持つ見落とされがちなコストを指摘した。

cross-documentが普及しても「遷移のコスト」そのものが消えるわけではありません。MPAにおけるページ遷移は、本質的に新しいドキュメントのパースとリソースの再取得を伴います。たとえ視覚的な遷移がネイティブ機能で滑らかになっても、背後で発生するネットワーク・レイテンシやメインスレッドの負荷は、SPAのJSによる制御とは異なるメカニズムでユーザー体験に影響を与えます。

つまり「遷移がなめらかに見える」ことと「実際に遷移が速い・軽い」ことは別問題であり、演出だけを整えてデータ読み込みの遅さを隠す設計は、かえってユーザーを混乱させる危険がある。

読者への持ち帰り：今日どう使い分けるか

編集部の議論が最終的に着地したのは、「SPAかMPAか」という二択ではなく、プログレッシブエンハンスメントとしての段階的な使い分けだった。

same-document（Baseline到達済み）
  → 既存のSPA内の画面遷移・状態変化を滑らかにする用途には
    使ってよい段階。ただし prefers-reduced-motion への
    対応は必須で「装飾」ではなく「義務」として扱う

cross-document（Limited availability）
  → 対応ブラウザには強化された遷移演出を、
    Firefox等の未対応ブラウザには
    「今まで通りの普通のページ遷移」を提供する
    設計にする。演出前提の機能は作らない

図は議論の結論を基にした編集部の整理。CSSの@supportsやJavaScriptのCSS.supports("view-transition-name: a")のような機能検出を使えば、対応ブラウザにだけ演出を適用し、非対応ブラウザでは何も壊れない実装が可能になる。これはView Transitions APIそのものの設計原則でもある。未対応ブラウザは単に演出を無視して通常のページ遷移を行うだけで、コンテンツやリンクの機能自体は損なわれない。

デモ：対応・未対応の両方で壊れない遷移を体験する

デモを開くでは、写真ギャラリー風の3ページ（一覧・詳細×2）を用意した。一覧のカードをクリックすると、cross-document view transitions対応ブラウザでは、クリックしたカードがそのまま詳細ページの大きな画像へなめらかに拡大するモーフィング遷移が起こる。これはview-transition-nameというCSSプロパティで、遷移前後の要素を紐づけることで実現している。ページ全体の切り替えには@view-transition { navigation: auto; }を使い、通常のリンクによるページ遷移（cross-document）をブラウザが自動的に演出する。

デモにはページ内に「このブラウザは対応/未対応」の機能検出表示を入れており、CSS.supports("view-transition-name: a")のような判定で、view-transition-nameプロパティへの対応をその場で確認できる。ただしこの判定は、same-documentのみ対応のブラウザでも「対応」となるため、cross-document遷移が実際に動くかどうかの厳密な判定ではない点はデモ内にも注記した。また、OS側で「視差効果を減らす」等の設定(prefers-reduced-motion: reduce)を有効にしている場合は、CSSでアニメーションそのものを無効化し、演出なしの瞬時な切り替えになる。対応していないブラウザで開いても、普通にリンクをクリックしてページが切り替わるだけで、機能や内容は一切損なわれない。これがこの記事で議論した「プログレッシブエンハンスメント」の実例そのものだ。

出典を読むときのポイント

MDN「Document: startViewTransition() method」：same-document view transitionsが「Baseline 2025 Newly available」であることを実機のバッジで確認した一次資料。
MDN「@view-transition」：cross-document view transitionsが2026年7月26日時点で「Limited availability」(Baseline未達)であることを実機のバッジで確認した一次資料。
web.dev公式ブログ「Same-document view transitions have become Baseline Newly available」：same-documentが2025年10月14日にFirefox 144の対応をもってBaseline Newly Availableに到達した経緯を確認した。
WebKit公式ブログ「Announcing Interop 2026」：cross-document view transitionsがInterop 2026のフォーカスエリアに含まれることを確認した。
web-platform-tests/interop issue #1110：Cross-document View TransitionsのInteropに関する課題管理の記録。