ブラウザに保存したデータは消える：localStorage の寿命

localStorage は、そのサイトを使い続けているあいだだけ生きるキャッシュに近い。だから「保存したはずのデータが消えた」は、不具合ではなく仕様として起きる。

この記事のゴールは、自分のアプリのデータが消えるのかを自分で判断できるようになること。判断は2つの軸で決まる。使う人の環境と、使う頻度。

1. localStorage とは何か

ブラウザ自体に備わっている保存場所。サーバーを用意しなくても、ブラウザの中に文字列を書いて読める。一人完結型のWebアプリがデータを置くのはここ。

性質は4つ。

• オリジン単位：スキーム・ホスト・ポートの組ごとに分かれる。https://example.com と https://test.example.com は別扱いで、同じ人が同じブラウザで開いても中身は共有されない
• サーバーには送られない：Cookie と違って自動送信されない。サーバー側からは見えない
• 文字列だけ：数値やまとまったデータは文字列に変換して入れる
• 容量は5MB前後

ここまでは「ブラウザの中のメモ帳」と考えてよい。

2. 消える3つの条件

• 利用者が手で消す：ブラウザの設定から消せる。どのブラウザでも起きる
• プライベートブラウジングを閉じる：シークレットウィンドウの中身はそもそも残らない
• しばらく開かないでいると自動で消される

3つ目だけは、ブラウザによって起きたり起きなかったりする。

3. 「7日」の数え方

Safari のエンジン（WebKit）には、そのサイトを7日間使わないでいると、JavaScript が書いたデータを消す仕組みがある。利用者の追跡を防ぐためのプライバシー保護機能で、自作アプリのデータはその巻き添えで消える。

日数の数え方に注意が要る。7日はカレンダーの7日ではなく、ブラウザを使った日数。

• ブラウザを毎日使う人が、そのサイトを7日ぶん開かなければ消える
• ブラウザ自体を1か月使わなければ、その1か月は数えられない
• そのサイトを開いて操作すれば、カウンタは0に戻る

だから毎日使うアプリのデータは消えない。消えるのは放置したとき。

4. どの環境で消えるか

この削除は WebKit の機能なので、そのブラウザが WebKit で動いているかどうかで決まる。

環境	7日で消えるか
iPhone・iPad の全ブラウザ（Safari / Chrome / Firefox）	消える
Mac の Safari	消える
Mac の Chrome・Firefox	消えない
Windows の Chrome・Edge・Firefox	消えない
Android の Chrome	消えない

iPhone・iPad は全ブラウザが対象。iPhone に Chrome を入れても中身は WebKit なので、ブラウザを変えても同じく消える（2026年10月時点。日本でも2025年12月から、法律の上では WebKit 以外のエンジンを使えるようになった。ただ、実際にそうした iPhone 版ブラウザはまだ出ていない）。

Mac は逆で、Safari だけが対象。Mac の Chrome では消えない。同じ Chrome でも、Mac と iPhone で結果が逆になる。

消えない環境もあるが、使う人がどの環境かは選べないし、日本は iPhone の比率が高い。消える前提で設計しておくほうが安全。

5. ブラウザ内の別の保存先に移しても同じ

「localStorage が消えるなら、ブラウザ内の別のところに置けばいい」は、たいてい解決にならない。

保存先	7日削除の対象か
localStorage	対象
IndexedDB	対象
JavaScript が書いた Cookie	対象
サーバーが発行した Cookie	対象外。指定した期限どおり生きる

ブラウザの中に置いている限り同じ。 分かれ目は保存先の種類ではなく、ブラウザの中か、サーバーか。

6. 消えて困るならどうするか

手は3つある。手軽さと確実さは逆の順。

手	手軽さ	確実さ	どういうものか
エクスポート	高い	低い	データをファイルに書き出せるようにする。利用者が実際に使うかは別の話
ホーム画面に追加	ふつう	ふつう	ホーム画面に追加したアプリは7日削除の対象から外れる。ただし全員が追加してくれるわけではない
サーバーに置く	低い	高い	データ共有型にする。作りは重くなるが確実

エクスポートはいちばん手軽に付けられる。 一人完結型のアプリを作った時点で頼んでおくとよい。

プロンプト

このアプリのデータを、いつでもファイルに書き出して保存できるようにして。
書き出したファイルから元に戻せるところまで作って。

7. 自分のアプリはどうなのか

消えたときに何が起きるかで決まる。

消えると	例	深刻さ
作り直せる	TODO、メモ、表示の設定	小さい
数えなおしになる	いいねの重複を防ぐ識別子	ふつう
入れなくなる	ログインキー	取り返しがつかない

取り返しがつかないのは3つ目だけ。 ログインキー方式が「日常的に使うサービス」に限られるのはこれが理由で、年に数回しか開かないサービスだと、次に開いたときには消えていて、そのまま締め出しになる。

判断はこの順でつく。

1. 消えたら何が起きるか。 作り直せるなら、ここで終わってよい
2. どれくらいの頻度で使うサービスか。 毎日開くなら消えない。年に数回なら消える

8. 関連記事

• Webアプリの2つのタイプ：一人完結型と、データをサーバーに置くデータ共有型
• データ共有型Webアプリの基礎知識：サーバーに置く場合の構成
• ログインキーでユーザーアカウント管理：消えると入れなくなる例
• いいねカウントAPIを作る：消えると数えなおしになる例
• Claude Code で一人完結型のWebアプリを作る：毎日使うスタンプカードで、途切れたときに消える例