フォームの入力内容を保存して復元する — 難しいのは「いつ保存するか」と「いつ消すか」

公開 2026-10-25 ／ 更新 2026-10-25 ／ 文：ランツ

先に結論

入力内容を保存して復元する処理そのものは、10行ほどで書けます。 解説記事もたくさんあります。詰まるのは、そこではありません。

MDNが beforeunload についてはっきり書いています。

「入力途中でアプリを切り替えて、そのままブラウザを閉じる」のは、 スマホでは珍しくありません。そこで保存されないなら、何のための自動保存か分かりません。

Cookieには入れない

2.9倍に膨らむ

Cookieに入れると、中身がそのまま入るわけではありません。 値をURLエンコードする必要があるので、日本語は大きく膨らみます。

現実的なフォーム1件ぶんで測りました。

測ったのは氏名・メール・電話・郵便番号・住所・本文という、 問い合わせフォームによくある組み合わせです。 特別に長いデータではありません。

Cookie 1つあたりの上限はおおむね4KB程度とされています。 2,539文字という時点で、その枠の半分以上を1つのフォームで使っています。

しかも毎回送られる

Cookieの本質的な問題はサイズではなく、サーバーに送られることです。 保存したいだけなのに、同じドメインへのリクエストすべてに付いていきます。

「タブを閉じたら消えていい」なら sessionStorage が安全です。 消す処理を書き忘れても、勝手に消えます（詳しく）。

いつ保存するか

普通に遷移すると、全部発火する

ページを離れるときに発火するイベントは複数あります。 普通にリンクをクリックして遷移した場合に、どれが発火するかを測りました。

全部発火します。だから開発中は問題が見えません。 beforeunload で保存するコードを書いて、手元で試して、動いた、で終わってしまいます。

beforeunloadは発火しないことがある

問題が出るのは、開発中には再現しにくい状況です。 MDNが具体例を挙げています。

スマホでフォームを書いている途中に電話が来る、という場面を想像してください。 アプリを切り替えて、戻ってこずにブラウザを終了する。 自動保存が一番役に立つべき場面で、保存されていません。

visibilitychange は、画面が隠れた時点で発火します。 アプリを切り替えた瞬間がそれです。その後どうなっても、保存はもう済んでいます。

置くだけで遅くなる副作用もある

beforeunload には、もう1つ代償があります。

bfcache は、戻るボタンでページを瞬時に表示するための仕組みです。 beforeunload を1つ置いただけで、それが効かなくなります。 「保存のために置いたリスナーが、戻る操作を遅くする」という形になります。

beforeunload を完全に捨てるわけではありません。 「保存していない変更があります。本当に離れますか」という確認ダイアログを出す用途には、これしかありません。 保存の処理はそこに置かない、という話です。

「毎回保存は重い」は本当か

「input のたびに保存すると重いから、離脱時にまとめて保存する」という説明をよく見ます。 本当にそうなのか測りました。

まず、1文字打つと何回イベントが出るのか。

1文字につき1回です。では、その1回の保存にどれだけかかるのか。

つまり、素直に毎回保存してよいということです。 そのうえで visibilitychange でも保存しておけば、取りこぼしが減ります。 どちらか一方を選ぶ必要はありません。

なお、これは文字列を1つ書くだけの測定です。 保存のたびにフォーム全体を走査して JSON.stringify するなら、その分は乗ります。 気になるなら、そこを測ってください。保存そのものは問題になりません。

何を保存しないか

ここが一番事故につながります。フォームを全部まとめて保存すると、入れてはいけないものが混ざります。

ここで方式の選択が効いてきます。 「保存するものを明示する」のか、「保存しないものを除外する」のかです。 分かれ目は、あとからフォームに項目が増えたときに何が起きるかです。

許可制にしてください。 「保存されなくて不便」で済むのと、「保存されてはいけないものが残る」のとでは、被害が違います。

いつ消すか

ここを書いていない解説が大半です。 保存する処理だけ入れて消さないと、こうなります。

消すタイミングは3つ決めておけば足ります。

まとめたコード

ここまでの判断を全部入れた形です。

const KEY = 'draft:contact';
const VERSION = 2;                       // フォームの形を変えたら上げる
const MAX_AGE = 7 * 24 * 60 * 60 * 1000; // 7日
const FIELDS = ['name', 'email', 'tel', 'body'];   // 許可制。ここに無いものは保存しない

const form = document.querySelector('#contact');

function save() {
  const data = {};
  for (const n of FIELDS) {
    const el = form.elements[n];
    if (el) data[n] = el.value;
  }
  try {
    localStorage.setItem(KEY, JSON.stringify({ v: VERSION, t: Date.now(), data }));
  } catch {
    // プライベートモードや容量超過で落ちることがある。保存できなくても止めない
  }
}

function restore() {
  let saved;
  try { saved = JSON.parse(localStorage.getItem(KEY) || 'null'); } catch { return; }
  if (!saved) return;
  if (saved.v !== VERSION) return clear();          // 形が変わっている
  if (Date.now() - saved.t > MAX_AGE) return clear(); // 古い
  for (const [n, v] of Object.entries(saved.data)) {
    const el = form.elements[n];
    if (el) el.value = v;
  }
}

function clear() { try { localStorage.removeItem(KEY); } catch {} }

// 復元は最初に1回
restore();

// 保存は入力のたび（実測で0.004ms。まとめる必要はない）
form.addEventListener('input', save);

// 画面が隠れた時点でも保存する。beforeunload は使わない
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') save();
});

// 送信が「成功したら」消す。押した時点ではない
form.addEventListener('submit', async (e) => {
  e.preventDefault();
  const res = await fetch(form.action, { method: 'POST', body: new FormData(form) });
  if (res.ok) clear();
});

AIに任せるときの注意

判定の目安です。出てきたコードに beforeunload で保存する処理があったら、置き換えてください。 visibilitychange になっていれば現代的です。

よくある質問

Cookieではだめですか

動きますが向きません。同じドメインへのリクエストすべてに付いていきます（表3）。 測ったところ、889バイトのJSONがCookieでは2,539文字になりました（表2）。

beforeunloadで保存してはいけないのですか

保存には使わないでください。 MDNが「モバイルプラットフォームでは確実に発生するとは限りません」と明記しています（詳しく）。 離脱の確認ダイアログを出す用途には、いまもこれを使います。

input のたびに保存すると重くないですか

重くありません。実測で setItem 1回が0.004ms、 100文字入力しても合計0.38msでした（表9）。 まとめる理由を性能に求めるのは間違いです。

localStorageとsessionStorageはどちらがいいですか

「タブを閉じたら消えていい」なら sessionStorage が安全です（表4）。 消す処理を書き忘れても勝手に消えます。 ブラウザを閉じたあとも復元したいなら localStorage です。

パスワードも保存していいですか

絶対にだめです。平文で端末に残ります（表10）。 保存する項目を配列で明示する許可制にすれば、そもそも混ざりません。

送信したのに古い内容が復元されます

消す処理が入っていません（表12）。 送信が成功したら消してください。 押した時点で消すと、通信が失敗したときに入力が消えます。

共有パソコンで前の人の入力が出ます

同じ原因です。sessionStorage にしておけば、タブを閉じた時点で消えます（表4）。

フォームの項目を変えたら表示が壊れました

古い形のデータが復元されています。 保存するときにバージョン番号を一緒に入れ、違えば捨ててください（コード）。

まとめ

• 保存する処理自体は簡単。判断が要るのは「どこに」「いつ保存して」「いつ消すか」。
• Cookieには入れない。889バイトのJSONが2,539文字になり、しかも毎リクエスト送られる（実測）。
• beforeunload で保存しない。MDNが「モバイルでは確実に発生するとは限りません」と明記している。
• beforeunload を置くと bfcache が効かなくなる（Firefox・MDN）。戻る操作が遅くなる。
• 保存は visibilitychange（hidden）。画面が隠れた時点で確定する。
• 通常の遷移では4つとも発火する（実測）。だから手元のテストでは問題が見えない。
• 「毎回保存は重い」は実測で否定された。100文字で0.38ms。素直に毎回保存してよい。
• 保存する項目は許可制。拒否制だと、項目が増えたときに事故になる。
• パスワードとカード番号は保存しない。平文で端末に残る。
• 送信が「成功したら」消す。押した時点で消すと、失敗時に入力を失う。