この記事の対象: ブラウザネイティブのページ遷移アニメーションを実装したいフロントエンドエンジニア
読了時間: 約6分
ページ遷移のたびにフワッとフェードしたり、ヒーロー画像がなめらかに拡大したり——これまでJavaScriptライブラリに頼っていたページ遷移アニメーションが、ブラウザネイティブのAPIだけで実現できます。View Transitions APIは、少量のCSSとJavaScriptで導入でき、2026年時点では主要ブラウザすべてで動く実務レベルの機能になりました。本記事では基本の使い方から実践パターン、既存ライブラリとの比較まで、現場で迷いやすいポイントを中心に整理します。
View Transitions APIとは
View Transitions APIは、DOMの状態変化をスナップショットとして取得し、自動的にクロスフェードするブラウザネイティブの仕組みです。変化前の状態と変化後の状態をブラウザが内部的に画像として撮影し、それを重ねてアニメーションさせるため、開発者はDOM操作のタイミングをstartViewTransition()に渡すだけで済みます。
SPAでのビュー切り替えだけでなく、MPA（通常のページ遷移）にも対応しており、フレームワークを挟まずにページ遷移アニメーションを組めるのが最大の利点です。従来はBarba.jsのようなライブラリでページ全体をAjaxで差し替えて疑似的に遷移感を出す必要がありましたが、View Transitions APIはブラウザの標準ナビゲーションのままアニメーションだけを差し込めます。
View Transitions API
- 標準のページ遷移のまま
- 追加ライブラリ不要
- CSSだけで演出をカスタマイズ
Barba.js等の従来手法
- Ajaxでページ全体を差し替え
- ライブラリの読み込みが必要
- ルーティングを自前で管理
構成をシンプルに保てる分、演出の自由度は既存ライブラリより控えめです。何を優先するかは後半の比較で改めて整理します。
ブラウザ対応状況（2026年版）
- Chrome / Edge: 完全対応（SPA + MPA）
- Safari: 対応
- Firefox: 対応
主要ブラウザがひととおり対応を終えているため、2026年時点ではプログレッシブエンハンスメントを前提に本番投入して問題ない段階です。非対応環境では単に即座にDOMが切り替わるだけで、エラーにはなりません。document.startViewTransitionの有無をチェックする分岐さえ入れておけば、対応・非対応の両方で破綻しない実装になります。細かい対応バージョンは変わりやすいため、導入前にCan I useなどで最新の状況を確認しておくと確実です。
基本の使い方
document.startViewTransition()（SPA向け）
// ボタンクリックでビュー切り替え
document.querySelector('.nav-link').addEventListener('click', async (e) => {
e.preventDefault();
// View Transition API に対応しているか確認
if (!document.startViewTransition) {
updateDOM(); // 非対応の場合は通常の更新
return;
}
const transition = document.startViewTransition(() => {
updateDOM(); // DOM を更新する関数
});
await transition.finished;
});
function updateDOM() {
// ページの内容を更新する処理
document.querySelector('main').innerHTML = newContent;
}
実装のポイント: startViewTransition()に渡すコールバックの中でDOMを更新すると、ブラウザが「変更前」「変更後」のスナップショットを自動で撮ってくれます。呼び出し側は更新関数を渡すだけでよく、スナップショットのタイミングを意識する必要はありません。
つまずきやすい点: コールバック内で非同期処理（fetchなど）を待ってからDOMを更新しようとすると、スナップショットのタイミングがずれて遷移が固まって見えることがあります。データ取得はstartViewTransition()を呼ぶ前に済ませ、コールバックの中では同期的なDOM更新だけを行うのが安全です。
CSSの::view-transition疑似要素
デフォルトではクロスフェードが適用されますが、CSSでカスタマイズできます。
/* 遷移全体のアニメーション */
::view-transition-old(root) {
animation: fade-out 0.3s ease;
}
::view-transition-new(root) {
animation: fade-in 0.3s ease;
}
@keyframes fade-out {
from { opacity: 1; }
to { opacity: 0; }
}
@keyframes fade-in {
from { opacity: 0; }
to { opacity: 1; }
}
要素ごとの遷移名指定
特定の要素にview-transition-nameを指定すると、その要素だけ個別のアニメーションを適用できます。
.hero-image {
view-transition-name: hero;
}
/* ヒーロー画像は拡大しながら遷移 */
::view-transition-old(hero) {
animation: scale-down 0.4s ease;
}
::view-transition-new(hero) {
animation: scale-up 0.4s ease;
}
つまずきやすい点: view-transition-nameはページ内で一意でなければなりません。同じ名前を持つ要素が同時に2つ以上存在すると、その時点で遷移全体がエラーになり無効化されます。一覧ページのカード画像すべてに同じ名前を付けてしまうミスが起きやすいので、view-transition-name: card-${id}のように動的な値を割り当てる設計にしておくと安全です。
CSSアニメーション全般のキーフレーム設計を細かく詰めたい場合は、ホバーアニメーションのCSS実装｜カードでやりすぎない基準でも「動かしすぎない」バランスの取り方を扱っているので、遷移演出を考える際の参考になります。
MPA（マルチページ）での使い方
通常のHTML間のページ遷移にもView Transitionsを適用できます。
/* 遷移元・遷移先の両ページのCSSに記載 */
@view-transition {
navigation: auto;
}
/* 遷移アニメーションのカスタマイズ */
::view-transition-old(root) {
animation: slide-out 0.3s ease;
}
::view-transition-new(root) {
animation: slide-in 0.3s ease;
}
@keyframes slide-out {
to { transform: translateX(-100%); }
}
@keyframes slide-in {
from { transform: translateX(100%); }
}
MPAでの使用は@view-transition { navigation: auto; }をCSSに追加するだけで有効になります。JavaScriptの記述は不要で、同一オリジン内のリンク遷移すべてに自動で適用される点がSPA向けの実装との違いです。
サイト全体をまたぐ演出なので、テンプレート単位でページが分かれるEC構成でも、テンプレートごとにCSSの読み込みを揃えておけば同じ調子で遷移を統一できます。
実践例
フェード遷移
最もシンプルで使いやすい遷移。ページ全体がフェードアウト→フェードインで切り替わります。
::view-transition-old(root) {
animation: 0.25s ease both fade-out;
}
::view-transition-new(root) {
animation: 0.25s ease both fade-in;
}
スライド遷移
ページが横にスライドして入れ替わる遷移。ニュースサイトやギャラリー、カタログ形式のページ送りに適しています。横方向の動きという意味では、JSに頼らずCSSだけで滑らかな横スクロールを作る手法とも相性がよく、実装の考え方としてCSSのscroll-snapでカルーセル実装｜JS不要の横スクロールUIの作り方も参考になります。
アクセシビリティへの配慮
派手な演出ほど、動きに敏感なユーザーへの配慮を忘れがちです。prefers-reduced-motionメディアクエリで、モーション低減設定のユーザーにはアニメーションを無効化しておきましょう。
@media (prefers-reduced-motion: reduce) {
::view-transition-old(root),
::view-transition-new(root) {
animation: none;
}
}
キーボード操作やフォーカス管理まで含めた実装の考え方は、タブUIの実装とアクセシビリティ｜キーボード操作まで対応する手順でも扱っているので、遷移演出とあわせてアクセシビリティ全体を見直す際に参照してください。
GSAPやBarba.jsとの比較
| View Transitions API | GSAP + Barba.js | |
|---|---|---|
| 依存ライブラリ | なし | GSAP + Barba.js |
| 学習コスト | 低い | 中〜高 |
| カスタマイズ性 | 中程度 | 非常に高い |
| MPA対応 | ネイティブ | Barba.jsが必要 |
| ブラウザ対応 | 主要ブラウザ対応 | 全ブラウザ |
| 追加の読み込み | 発生しない | ライブラリ分発生する |
シンプルな遷移ならView Transitions API、複雑なアニメーション制御にはGSAPが適しています。要素を個別に操作したり、遷移中にタイムラインを細かく制御したりする演出は、現状のView Transitions APIだけでは組みにくく、GSAPのようなライブラリの出番になります。
実際の使い分けの目安として、ページ全体の余白とタイポグラフィの調子で見せるコーポレートサイトやポートフォリオ系は、View Transitions APIのクロスフェードだけで遷移の繋ぎ目が十分に滑らかになり、追加実装がほぼ不要になるケースが多いです。逆に、トップページのヒーローで画像がスクロールに追従して大きく拡大・縮小するようなブランディング重視のLPは、要素ごとのタイムライン制御が必要になり、GSAPで組み込むほうが向いています。遷移そのものを主役にしたいか、控えめに繋ぎ目を消したいかが選ぶ基準になります。
読み込み速度の観点では、ライブラリの追加は当然LCPやJS実行時間に影響します。パフォーマンスとの兼ね合いを整理したい場合は画像 遅延読み込みでLCP 改善｜loading属性とサイズ指定の実装もあわせて確認しておくと、遷移演出とページ速度の両立がしやすくなります。
よくある質問
View Transitions APIはSEOに影響しますか
影響しません。MPAでの利用はブラウザ標準のナビゲーションをそのまま使うため、URLの遷移もクローラーの挙動も変わりません。CSSとJavaScriptだけで見た目の演出を足す仕組みなので、構造化データやページ内容には手を加えません。
非対応ブラウザではどう表示されますか
document.startViewTransitionが存在しない環境では、DOMが即座に切り替わるだけで、エラーは発生しません。アニメーションが無いだけの通常のページ遷移として動作するため、対応チェックの分岐を入れておけばフォールバックとして安全に運用できます。
SPAとMPA、どちらから導入すべきですか
既にMPA構成のサイトであれば、CSSに@view-transition { navigation: auto; }を1行加えるだけで導入できるMPA向けの方が着手コストは低いです。SPAはコールバックの中でDOM更新のタイミングを制御する必要があるため、若干実装の手間が増えます。
view-transition-nameを複数の要素に使い回してもよいですか
同時に画面上へ存在する状態でよいものは避けてください。同じ名前を持つ要素が2つ以上あると、その時点で遷移全体が無効化されます。一覧のカードなど繰り返し要素には、IDを含んだ動的な名前を割り当てるのが安全です。
GSAPと併用することはできますか
できます。ページ全体のクロスフェードはView Transitions APIに任せ、遷移後に表示される個別要素の細かいアニメーションだけGSAPで制御する、という役割分担も現場ではよく使われます。
まとめ
View Transitions APIのポイントをまとめます。
- ブラウザネイティブのページ遷移アニメーションAPIで、2026年時点で主要ブラウザすべてが対応済み
- SPA/MPA両方に対応し、MPAはCSS1行の追加だけで導入できる
- CSSの疑似要素でアニメーションをカスタマイズできる
view-transition-nameで要素ごとの個別遷移が可能。ただし名前の一意性に注意prefers-reduced-motionへの配慮を忘れずに組み込む- シンプルな遷移には最適、複雑な演出制御が必要な場面ではGSAPを検討する
