web.dev が Navigation API - a better way to navigate, is now Baseline Newly Available を公開し、Navigation API が主要ブラウザで Baseline（広く利用可能）に到達したことを報告しました。従来 History API（pushState / popstate）で煩雑だった SPA のクライアントサイド遷移・履歴管理・スクロール位置復元・遷移の中断/インターセプトが、Navigation API で統一的に扱えるようになります。navigation.addEventListener('navigate', ...) で遷移をインターセプトし、intercept({ handler }) で非同期に画面を更新し、navigation.entries() で履歴を管理できる。View Transitions API とも素直に組み合わせられます。これは単なる新 API ではなく、「滑らかな画面遷移を、自前のフラグ管理に頼らず、標準仕様で壊れにくく作れるようになった」という転換点です。
受託 Web 制作の現場では、「SPA 風の滑らかな遷移を入れたが、戻る/進むが効かない」「リロードするとスクロール位置が先頭に飛ぶ」「ローディング中に別リンクを押すと前のページが上書きされる」といった事故が繰り返されてきました。受託でフロントを支える立場では、これは 「滑らかに見せられるか」ではなく、「戻る/進む・スクロール・中断まで含めて壊れない遷移を、標準 API で・引き継ぎ可能な形で実装して引き渡せるか」を設計に組み込む課題だと捉えています。これまで 体感速度を上げるストリーミングSSR（GH Media） で扱った 体感速度の作り込み、View Transitions でページ遷移を演出する（GH Media） で扱った 遷移演出と接続して、本記事では 「フロント遷移設計・実装支援」を 受託パッケージとして整理します。
なぜ「いま」画面遷移を作り直すのか
| 観点 | History API / 自前実装（従来） | Navigation API（2026） |
|---|---|---|
| 遷移の捕捉 | popstate を頼りに手探り | navigate イベントで一元的に捕捉 |
| 履歴管理 | pushState を自前で整合 | navigation.entries() で参照可能 |
| スクロール復元 | 自前で保存/復元、よく壊れる | 標準で scroll 制御をフック可能 |
| 遷移の中断 | フラグ管理で力技、競合しやすい | signal で中断可能、宣言的 |
| View Transitions | 配線が複雑 | intercept() 内で素直に統合 |
| 引き継ぎ | 属人化して塩漬け | 標準 API で読み解ける |
つまり 「滑らかに見える」ことと「戻る/進む・スクロール・中断まで壊れない」ことは別物であり、受託でも 「標準 API に寄せ、履歴とスクロールと中断を一貫して扱い、第三者が読み解ける形で引き渡す」ことが品質の前提になりました。これにより 「途切れない画面遷移」を成果物として保証できます。
Navigation API でできること
① 遷移のインターセプト
navigate イベントを購読し、同一オリジン内の遷移だけを intercept() で横取りして、非同期にコンテンツを差し替えます。フルリロードを避けつつ、URL とブラウザ履歴は正しく進みます。event.signal を使えば、遷移中に次の遷移が始まったときの 中断も宣言的に書けます。
navigation.addEventListener('navigate', (event) => {
// 横取りすべき遷移だけに絞る
if (!event.canIntercept || event.hashChange || event.downloadRequest) return;
const url = new URL(event.destination.url);
if (url.origin !== location.origin) return;
event.intercept({
async handler() {
const html = await fetchPage(url.pathname, { signal: event.signal });
renderMain(html); // 中断されたら signal で fetch ごと止まる
},
});
});② スクロール復元と履歴管理
navigation.entries() で 履歴エントリの一覧を参照でき、各エントリに状態を紐づけられます。スクロール位置の復元はブラウザ標準の挙動にフックでき、「戻ったら元の位置に戻る」「リロードしても先頭に飛ばない」を自前の保存ロジックを書かずに成立させられます。受託では、この 標準挙動を前提にした上で、必要な箇所だけ明示制御します。
③ View Transitions との連携
intercept() の handler 内で DOM を差し替える際に View Transitions API を重ねるだけで、フェードやスライドのアニメーションが付きます。遷移の捕捉（Navigation API）と見た目の演出（View Transitions）が役割分担されるため、配線が単純になります。演出設計の詳細は View Transitions でページ遷移を演出する（GH Media） を参照してください。
受託で提供する「フロント遷移設計・実装支援」5 フェーズ
フェーズ 1: 現状診断（1 週間）
- 既存遷移の挙動棚卸し（戻る/進む・スクロール・中断の再現テスト）
- 自前 History 実装・SPA ルータの依存マップ作成
- 成果物: 遷移不具合の一覧と再現手順、対応方針メモ
フェーズ 2: 設計（1 週間）
- 横取り対象 / 対象外の遷移境界の定義
- スクロール復元・履歴・中断のポリシー策定
- 成果物: 遷移設計書、対象 URL マトリクス、フォールバック方針
フェーズ 3: 実装（1〜3 週間）
navigateインターセプト層の実装と局所化- スクロール復元・中断・View Transitions の組み込み
- 成果物: 遷移層の実装、最小再現サンプル、コードコメント
フェーズ 4: 検証・引き渡し（1 週間）
- 戻る/進む・リロード・連打・低速回線での回帰テスト
- 非対応環境でのフォールバック確認
- 成果物: テスト結果、運用手順書、構成図
フェーズ 5: 継続保守（継続）
- ブラウザ挙動・仕様更新の定点観測
- 新規ページ追加時の遷移レビュー
- 成果物: 月次レポート、回帰テストの維持
受託向け実装標準セット
| レイヤ | 推奨 | 避ける |
|---|---|---|
| 遷移捕捉 | navigate イベントで一元化 | リンクごとに個別 JS |
| 横取り判定 | canIntercept / オリジン / hash で絞る | 全遷移を無条件で横取り |
| 中断制御 | event.signal で fetch ごと中断 | 自前フラグで競合管理 |
| スクロール | 標準復元 + 必要箇所だけ明示制御 | 全画面で自前保存/復元 |
| 演出 | View Transitions を重ねる | アニメを手書きで配線 |
| フォールバック | 非対応時は通常遷移に退避 | 横取り失敗で白画面 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| SPA 風の滑らかな遷移を入れたい | 純粋なマルチページの静的サイト |
| 戻る/進む・スクロール事故が起きている | 1〜2 ページの LP |
| 検索→詳細の回遊が多い EC / メディア | 入力フォーム単体の完結ページ |
| 既存の自前 SPA ルータが塩漬け | 外部 CMS 任せで遷移制御が不要 |
| 体感速度を作り込みたい | 更新頻度が極端に低い告知ページ |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 横取り対象 URL / 画面 | 境界の合意 |
| 挙動保証 | 戻る/進む・スクロール・中断 | テスト観点 |
| フォールバック | 非対応環境の退避動作 | 対象ブラウザ |
| 演出方針 | View Transitions の適用範囲 | 過度な演出の抑制 |
| 引き渡し | 構成図 / 実装解説 / 手順書 | 保守体制 |
| 継続保守 | 仕様追従 / 回帰テスト | 運用費用 |
価格モデル — フロント遷移設計パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 遷移診断 | 25 万円〜 | 1 サイト | 不具合棚卸し + 設計方針レポート |
| 標準実装 | 90 万円〜 | 中規模 | インターセプト層 + スクロール/中断実装 |
| 本格対応 | 180 万円〜 | 大規模 | + View Transitions + 全画面回帰テスト |
| Lite 保守 | 4 万円〜 / 月 | 小規模 | 仕様追従 + 軽微修正 |
| Standard 保守 | 12 万円〜 / 月 | 中規模 | + 新規ページ遷移レビュー + 回帰維持 |
顧客側 ROI 試算（回遊の多いメディア / EC 想定）
| 項目 | 自前実装で構築 | 遷移設計で構築 | 差分 |
|---|---|---|---|
| 戻る/進む事故 | 問い合わせ多発 | 標準 API で予防 | サポートコスト削減 |
| スクロール先頭飛び | 離脱を誘発 | 復元で維持 | 回遊・滞在の向上 |
| 連打/中断バグ | 二重表示が発生 | signal で防止 | 表示信頼性の向上 |
| 体感速度 | フルリロードで重い | 部分更新で軽快 | CV / 回遊率の改善 |
| 年間効果 | — | — | 離脱削減 + 保守工数の圧縮 |
遷移診断（25 万円〜）だけでも、「いまの遷移が、戻る/進む・スクロール・中断のどこで壊れているか」を可視化できること自体に価値があります。遷移の不具合は、たいてい本番でユーザーに見つけられてから報告されます。体感速度全体の作り込みは 体感速度を上げるストリーミングSSR（GH Media） と併読してください。
ハマりやすい 5 つの落とし穴
落とし穴 1: 全遷移を無条件で横取りする
外部リンクやダウンロードまで止まります。canIntercept とオリジンで絞り込みます。
落とし穴 2: 中断を考えない
連打で前のページが上書きされます。event.signal で fetch ごと中断します。
落とし穴 3: スクロールを全部自前で抱える
標準復元と競合して先頭飛びが残ります。標準挙動を前提に、必要箇所だけ明示制御します。
落とし穴 4: フォールバックを用意しない
横取り失敗で白画面になります。非対応時は通常遷移に退避させます。
落とし穴 5: 演出を盛りすぎる
View Transitions が重く、体感はむしろ悪化します。演出は控えめに、速さを優先します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | 遷移不具合の棚卸し + 再現手順の整理 |
| Week 2 | 横取り境界 + スクロール/中断ポリシー設計 |
| Week 3〜5 | インターセプト層実装 + 局所化 |
| Week 6 | View Transitions 連携 + 回帰テスト |
| Week 7〜13 | 仕様追従 + 新規ページ遷移レビュー |
まとめ — 「滑らかに見せる」から「途切れない状態で引き渡す」へ
Navigation API が Baseline に入ったことで、SPA の遷移・履歴・スクロール復元・中断を 自前のフラグ管理ではなく標準 API で扱えるようになりました。受託でフロントを支える立場では、横取り境界を定義し、スクロールと中断を一貫して扱い、フォールバックと構成図まで添えて引き渡す 「フロント遷移設計・実装支援」が、途切れない画面遷移を成果物として届ける主力サービスです。Baseline を前提にした技術選定の考え方は Web Platform Baseline をコーポレートサイトに（GH Media） も併読してください。
弊社では遷移診断 / 標準実装 / 本格対応 / Lite / Standard の各段階で本パッケージを提供しています。「戻る/進むが効かない」「スクロール位置が飛ぶ」「連打で表示が壊れる」といったご相談は お問い合わせフォーム からお気軽にどうぞ。
