localStorageは、Webブラウザ上で文字列のキーと文字列の値の対を、明示的に削除しない限りずっと保持する単純な永続ストレージAPIです。HTML5の一部としてWHATWGで仕様化が始まり、2011年12月にW3CのWeb Storage勧告として標準化されました。それ以前のブラウザ内データ保存はCookieしかなく、容量4KBの上限・HTTPリクエストごとに送信される無駄・JavaScriptからの扱いにくさが課題でした。localStorageは「同期API」「5MB前後の十分な容量」「HTTPに乗らない」「同一オリジン分離」という分かりやすい設計で、フロントエンド開発の標準的な道具になっています。
この記事の目次
- APIと基本的な使い方
- 5MB制限とオリジン分離
- よく使われる用途と注意点
- sessionStorageとの違いとモダンな代替
- まとめ
APIと基本的な使い方
localStorageの操作は驚くほど簡単で、localStorage.setItem('key', 'value') で保存し、localStorage.getItem('key') で取り出し、localStorage.removeItem('key') で削除、localStorage.clear() で全消去という4つのメソッドが基本です。プロパティ風アクセス（localStorage.key = 'value'）やブラケット記法（localStorage['key']）も使えますが、予約名や数値キーで挙動が変わるため、setItem getItem を使う書き方が推奨されます。格納できるのは文字列のみで、オブジェクトを入れたい場合は JSON.stringify と JSON.parse を併用します。
もう一つ覚えておきたいのが storage イベントです。あるタブで setItem した直後に、同じオリジンを開いている他のタブで window.addEventListener('storage', e => ...) が発火します。これによりタブ間で設定変更やログアウト状態を共有する簡易な同期が可能です。ただし「自分のタブには発火しない」「同期APIなのでメインスレッドをブロックする」という二点は実装時にハマりやすいポイントで、特に大量のデータをまとめて読み書きする処理ではUIフリーズの原因になります。
5MB制限とオリジン分離
localStorageの容量上限は仕様上「最小5MB」と推奨されており、ChromeやFirefox・Safariいずれも1オリジンあたり約5MB（UTF-16換算で約2.5百万文字）が標準です。これを超えると QuotaExceededError が投げられ、保存が失敗します。容量管理APIは用意されておらず、自前で JSON.stringify(localStorage).length を見るなどの工夫が必要です。大量データはIndexedDBへ移行するのが正解で、localStorageはユーザー設定・トークン・小さなキャッシュなど数十KB以下の用途に絞るのが定石です。
保存データはオリジン（スキーム＋ホスト＋ポート）単位で完全に分離されており、https://example.com と http://example.com でも別のストレージ扱いになります。サブドメインも別オリジンとして区別され、a.example.com のデータを b.example.com から見ることはできません。これはCookieの「ドメイン共有」とは大きく異なる挙動で、サブドメイン横断でログイン状態を共有したい場合はCookieやサーバー側のSSO、あるいは postMessage を介したiframe連携を使う必要があります。
よく使われる用途と注意点
もっとも王道の用途は、ユーザーが選んだUI設定の保存です。ダークモードのオン/オフやサイトの言語切り替え、通貨単位の選択、サイドバーの展開状態など、サーバーに送るほどでもないが次回訪問時にも引き継ぎたい情報をlocalStorageに置きます。フォームの下書き自動保存も典型で、入力イベントごとに setItem しておけば、誤ってタブを閉じても再開可能な体験を提供できます。Notionや一部のCMSエディタはこの仕組みで突発的なクラッシュからユーザーを守っています。
注意したいのはセキュリティ面で、localStorageはJavaScriptから無制限に読めるため、XSS（クロスサイトスクリプティング）が成立するとそこに置いた認証トークンはすべて盗まれます。OWASP Top 10にも繰り返し登場する典型的な攻撃経路で、ログインJWTを長期保存するならHttpOnly Cookieを選ぶべきという指針が一般化しています。短命トークンやリフレッシュトークン以外の個人情報は置かない、CSPで信頼するスクリプト元を絞る、といった対策とセットで使うAPIです。
sessionStorageとの違いとモダンな代替
localStorageの双子であるsessionStorageはAPIが完全に同じですが、データの寿命がタブの寿命と等しく、タブを閉じれば消えます。「このタブ限定の作業状態」を持ちたいときに使い分けます。両者を超える容量や型が必要ならIndexedDBへ、サーバーと共有したいならCookieへ、HTTPレスポンス自体をキャッシュしたいならCache APIへ、というように役割分担が明確になっています。
近年は同期APIでメインスレッドをブロックする欠点が嫌われ、「KV Storage」「Storage Buckets API」といった非同期Promise版の提案も出てきましたが、いずれもまだ広範な実装には至っていません。それでもlocalStorageは「とにかく簡単で全ブラウザで動く」という他に代えがたい強みがあり、2020年代後半の今もフロントエンド開発における第一選択肢として現役で使われています。他の高機能APIと組み合わせ、適材適所で割り当てるのが現代の正しい付き合い方です。
まとめ
localStorageは、HTML5時代に登場した最もシンプルな永続ストレージAPIです。5MBの容量・同期API・同一オリジン分離という分かりやすい設計で、ユーザー設定や下書きの保存といった軽量用途には今も最適な選択肢です。セキュリティ上の注意点さえ押さえれば、最も手早く永続化を実現できる道具と言えます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント