History APIとSPAルーティングの内部（pushState/popstate）

なぜ履歴 API の挙動を正確に押さえる必要があるのか

SPA の「遷移してもページが白くならない」体験は、ブラウザの History API が支えています。React Router・Vue Router をはじめ、あらゆるクライアントルーターはこの API の上に実装されています。ところが History API は発火の非対称性という独特の落とし穴を持ち、ここを誤解すると「戻るボタンで画面が更新されない」「スクロール位置が飛ぶ」「履歴が二重に積まれる」といった不具合を生みます。本記事は pushState / popstate を中心に、SPA ルーターが依存する原理を内部レベルで解きほぐし、最後に刷新版の Navigation API までを扱います。

セッション履歴とエントリ：何が積まれているか

ブラウザのタブはセッション履歴（session history）を持ち、これは履歴エントリ（history entry）の配列と、現在位置を指すインデックスで構成されます。戻る・進むはこのインデックスを増減させる操作にすぎません。各エントリは少なくとも次を保持します。

• URL：そのエントリのアドレス。
• state オブジェクト：pushState の第1引数で結びつける任意のシリアライズ可能な値。history.state で読み出せる。
• スクロール位置：そのエントリを離れた時点のスクロール座標（後述の復元に使う）。

history.length は履歴エントリの総数を返します（最大値はブラウザ依存で、おおむね数十〜数百で頭打ち）。重要なのは、JavaScript からはインデックスや他エントリの URL を直接読めない点です。セキュリティ上、見えるのは現在エントリの history.state と location だけで、history.go(n) のように相対移動の操作だけが許されています。

pushState / replaceState：履歴を操作する2つの命令

SPA ルーターの心臓部がこの2命令です。どちらもページ遷移（ナビゲーション）を一切起こさず、履歴エントリと URL だけを操作します。

pushState は「戻れる遷移」を作るとき（リンククリックでの画面切り替え）、replaceState は「戻り先を増やしたくない更新」（フィルタ条件の URL 反映、リダイレクト的な置換）に使います。第2引数の title は歴史的経緯でほぼ無視されるため空文字を渡すのが慣例です。URL は同一オリジンでなければ例外（SecurityError）になります。

ここで決定的に重要な性質が2つあります。

• ナビゲーションは起きない：pushState してもサーバーへの要求も load も走らない。アドレスバーの URL が変わるだけ。
• popstate は発火しない：これが最大の落とし穴。pushState は履歴を積むが、popstate を鳴らさない。

つまり SPA ルーターは「pushState で URL を変える」と「画面を描き替える」を自分で順に呼ぶ必要があります。pushState が描画を肩代わりしてくれることはありません。

// SPA ルーターのリンク遷移の最小形
function navigate(url, state) {
  history.pushState(state, '', url); // 履歴に積む。popstate は鳴らない
  render(location.pathname);          // 描画は自前で呼ぶ（ここが肝）
}

// アンカーを横取りして全リンクをルーター経由にする
document.addEventListener('click', (e) => {
  const a = e.target.closest('a');
  if (!a || a.origin !== location.origin) return; // 外部リンクは素通し
  e.preventDefault();                              // 既定のフル遷移を止める
  navigate(a.href, { from: location.pathname });
});

popstate の発火条件：ここを取り違えると戻るが壊れる

popstate は「セッション履歴の現在位置が移動したとき」に発火します。具体的には次のケースです。

• ユーザーが戻る／進むボタンを押した。
• history.back() / history.forward() / history.go(n) を呼んだ。
• 同一ドキュメント内のフラグメント（#section）への移動で履歴位置が動いた。

逆に、pushState / replaceState では発火しません。また、別ドキュメントへ実際にナビゲートする戻る・進む（SPA 外への離脱）では、ページがアンロードされるため popstate ではなく通常のロードになります。popstate はあくまで「同一ドキュメント内で履歴インデックスが動いた」合図だと捉えるのが正確です。

popstate ハンドラでは event.state（＝移動先エントリに紐づけた state、history.state と同値）を読み、それに応じて描画を復元します。

window.addEventListener('popstate', (event) => {
  // 戻る・進むで現在エントリが変わった。event.state は移動先エントリの state
  render(location.pathname, event.state);
});

hashchange と pushState：2系統のルーティング

URL のフラグメント（# 以降）だけを変える遷移は、pushState とは別系統で hashchange イベントを発火させます。歴史的に History API が普及する前の SPA はこのハッシュルーティング（/#/users のような URL）に依存していました。

History ルーティングはきれいな URL を作れる代わりに、/users/42 への直リンクやリロードでサーバーが 404 を返さないよう、サーバー側で「未知のパスはすべて index.html を返す（SPA フォールバック）」設定が必須です。フラグメントはサーバーに送信されないため、ハッシュルーティングはこの設定が不要ですが、URL が冗長になり SEO 上も不利です。現代は History ルーティング＋フォールバックが標準です。

スクロール復元：飛ぶ／飛ばないを制御する

ブラウザは既定で、戻る・進みのときに離脱時のスクロール位置を自動復元します。これは MPA では望ましい挙動ですが、SPA では「描画が非同期で間に合わず、復元のタイミングがズレて変な位置に飛ぶ」問題を起こします。この自動復元は history.scrollRestoration で制御できます。

// 自動復元を切り、ルーター側でスクロールを完全管理する
if ('scrollRestoration' in history) {
  history.scrollRestoration = 'manual'; // 既定は 'auto'
}

// 描画完了後に自前で復元（state に保存しておいた座標へ）
window.addEventListener('popstate', (event) => {
  render(location.pathname, event.state).then(() => {
    const y = (event.state && event.state.scrollY) || 0;
    window.scrollTo(0, y);
  });
});

'manual' にすると自動復元が止まり、復元の責任がアプリ側に移ります。SPA ルーターの多くは、遷移時に現在のスクロール位置を replaceState で現エントリの state に書き戻し、戻ったときに popstate ハンドラで scrollTo する、という流れを組みます。新規遷移（pushState）ではトップへスクロール、復帰（popstate）では保存位置へ、と方針を分けるのが定石です。

Navigation API：発火の非対称性を構造的に解消する

History API の本質的な弱点は、「URL を変える操作（pushState）」と「描画を起こす合図（popstate）」が非対称で、開発者が両者を手で繋ぎ、さらにスクロールや遷移の中断を個別に面倒見る必要がある点でした。これを根本から作り直したのが Navigation API（window.navigation）です。Chromium 系で先行実装され、仕様は WHATWG HTML に統合されています。

中核は navigate イベントです。リンククリック、navigation.navigate(url)、戻る・進む、フォーム送信まで、あらゆる同一ドキュメント内遷移を1つのイベントで一元的に捕捉できます。さらに event.intercept({ handler }) を呼ぶと「この遷移は SPA が自前で処理する」と宣言でき、ハンドラの非同期完了までを遷移の一部としてブラウザが管理します。

navigation.addEventListener('navigate', (event) => {
  // 横取りすべきでない遷移は素通し（別オリジン・ダウンロード等）
  if (!event.canIntercept || event.hashChange || event.downloadRequest) return;

  event.intercept({
    async handler() {
      // 描画完了まで Navigation API が「遷移中」として扱う
      await render(new URL(event.destination.url).pathname);
    },
  });
});

event.destination は遷移先の URL・state・履歴インデックスを保持し、event.signal（AbortSignal）で遷移キャンセル時の取得中断まで標準化されています。navigation.entries() で履歴エントリ配列を読めるため、History API では不可能だった現在位置以外のエントリ参照もできます。

Navigation API は2026年初頭に主要4ブラウザ（Chrome・Edge・Firefox・Safari）が出揃い、Baseline Newly Available（新たに利用可能）に到達しました。ただし古いバージョンのブラウザがまだ残るため、当面はNavigation API を優先しつつ未対応環境では History API にフォールバックする二段構えが現実解です。主要なルーターも段階的に Navigation API への対応を進めています。

まとめ