JavaScript | Web API：ストレージ系 API － 容量制限

ストレージの「容量制限」をちゃんと意識すると設計が変わる

localStorage / sessionStorage は便利ですが、
「無限に保存できる魔法の箱」ではありません。
どちらもブラウザごとに 容量制限 があり、それを超えると保存に失敗します。

初心者のうちはあまり意識されないところですが、
ここを理解しておくと「何をどれだけ保存するか」の設計が一段レベルアップします。

だいたいどれくらい入るのか（ざっくり感覚）

おおよそ「数 MB」レベルだと思っておく

ブラウザや環境によって細かい数字は違いますが、
localStorage / sessionStorage の容量は、だいたい 5MB 前後 と言われます。

ここで大事なのは、
「テキストならそこそこ入るけど、画像や巨大データを入れる場所ではない」
という感覚です。

例えば、短い文字列の設定や、小さめの JSON データなら問題ありませんが、
大きなログ、巨大な配列、画像を Base64 文字列にして突っ込む、などをやり始めると、
あっという間に限界に近づきます。

ドメインごとに制限されるイメージ

容量制限は「ブラウザ全体」ではなく、
基本的には オリジン（ドメイン＋プロトコル＋ポート）ごと にかかります。

つまり、
https://example.com で使える localStorage の容量は、
そのオリジン全体で共有されます。

同じオリジンで複数のアプリが localStorage を使っている場合、
「誰かが使いすぎると、他のアプリも巻き込まれる」可能性があります。

容量を超えたらどうなるのか

setItem で例外が投げられる

容量制限を超えて setItem しようとすると、
多くのブラウザでは 例外（エラー）が投げられます。

典型的には QuotaExceededError というエラーです。

イメージとしてはこうです。

try {
  localStorage.setItem("bigData", hugeString);
} catch (e) {
  console.error("保存に失敗しました", e);
}

try {
  localStorage.setItem("bigData", hugeString);
} catch (e) {
  console.error("保存に失敗しました", e);
}

ここで重要なのは、
「容量オーバーは“静かに失敗する”のではなく、“例外として表に出てくる”」
ということです。

つまり、本気でストレージを使い込む設計をするなら、
setItem が失敗する可能性を頭に入れておく必要があります。

「たまたま動いているだけ」の状態を避ける

小さなアプリだと、容量制限にぶつからないことも多いです。
でも、それは「たまたま今は大丈夫なだけ」です。

もし将来、保存するデータ量が増えたり、
ユーザーの環境によって制限が厳しかったりすると、
急に setItem が例外を投げ始める可能性があります。

プロとしては、
「容量制限にぶつかる可能性がある API を使っている」
という意識を持っておくことが大事です。

容量制限を意識した設計の考え方

「何でもかんでも保存しない」という発想

まず一番大事なのは、
「とりあえず全部 localStorage に突っ込む」設計をやめること です。

例えば、こういう線引きを考えられます。

本当に必要なものだけ保存する
ユーザー設定（テーマ、言語、表示オプションなど）
軽量なキャッシュ（最近開いた項目の ID など）

保存しなくてもいいものは保存しない
簡単に再取得できる大量データ
ログやデバッグ情報
一時的な状態（これは sessionStorage やメモリで十分なことが多い）

「保存できるから保存する」のではなく、
「本当に“残しておく価値があるもの”だけを保存する」
という視点が重要です。

データを「圧縮」する発想を持つ

容量が気になり始めたら、
「どうやってデータを小さく表現するか」を考えます。

例えば、
オブジェクトのキーを短くする（createdAt → c など）
不要な情報を保存しない（サーバーからまた取れるものは保存しない）
配列の中身を ID のみにする（詳細情報はサーバーから再取得）

極端な圧縮は読みづらさとトレードオフですが、
「何でも丸ごと JSON にして保存」から一歩進んで、
「本当に必要な最小限の情報だけを保存する」
という発想を持てると、容量の使い方がうまくなります。

具体例：大きめのデータを保存しようとして失敗するケース

大量のログをそのまま保存してしまう

例えば、アプリ内でユーザーの操作ログを全部 localStorage に保存しているとします。

function logAction(action) {
  const logsJson = localStorage.getItem("logs");
  const logs = logsJson ? JSON.parse(logsJson) : [];
  logs.push({
    action,
    at: Date.now(),
  });
  localStorage.setItem("logs", JSON.stringify(logs));
}

function logAction(action) {
  const logsJson = localStorage.getItem("logs");
  const logs = logsJson ? JSON.parse(logsJson) : [];
  logs.push({
    action,
    at: Date.now(),
  });
  localStorage.setItem("logs", JSON.stringify(logs));
}

最初は問題なく動きますが、
ユーザーが長時間使い続けると、
logs がどんどん増えていきます。

ある日、setItem で QuotaExceededError が飛ぶようになります。

ここで初めて「容量制限があったんだ…」と気づく、というパターンです。

対策の例：古いログを捨てる

容量を意識した設計にするなら、
例えば「最新 100 件だけ保存する」と決めることができます。

function logAction(action) {
  const logsJson = localStorage.getItem("logs");
  const logs = logsJson ? JSON.parse(logsJson) : [];
  logs.push({ action, at: Date.now() });

  const MAX_LOGS = 100;
  const trimmed = logs.slice(-MAX_LOGS);

  try {
    localStorage.setItem("logs", JSON.stringify(trimmed));
  } catch (e) {
    console.error("ログの保存に失敗しました", e);
  }
}

function logAction(action) {
  const logsJson = localStorage.getItem("logs");
  const logs = logsJson ? JSON.parse(logsJson) : [];
  logs.push({ action, at: Date.now() });

  const MAX_LOGS = 100;
  const trimmed = logs.slice(-MAX_LOGS);

  try {
    localStorage.setItem("logs", JSON.stringify(trimmed));
  } catch (e) {
    console.error("ログの保存に失敗しました", e);
  }
}

ここでやっているのは、

増え続ける構造をそのまま保存しない
「どこまで残すか」をルールとして決める
setItem が失敗する可能性も一応受け止める

という、容量制限を前提にした設計です。

容量制限を前提にした「割り切り」を持つ

localStorage / sessionStorage は「軽量ストレージ」として割り切る

大事なのは、
localStorage / sessionStorage を
「ちょっとした設定や軽いキャッシュを置く場所」
として割り切ることです。

ユーザー設定
軽い状態の保存
小さめの JSON データ

こういう用途にはとても向いています。

逆に、
大量のデータ、長期的に増え続けるログ、
画像や大きなバイナリを Base64 にして保存する、
といった用途には向いていません。

そういうものが必要になったら、
IndexedDB やサーバー側ストレージなど、
別の選択肢を検討するフェーズです。

初心者として持っておいてほしい感覚

最後に、あなたの頭の中に置いておいてほしいのは、この感覚です。

ストレージには「容量制限」がある（だいたい数 MB）
「何でも保存する場所」ではなく、「本当に必要なものだけ置く棚」だと考える
増え続けるデータ構造をそのまま保存しない（どこかで切る・捨てるルールを決める）
setItem が例外を投げる可能性があることを知っておく
容量が気になり始めたら、「何を保存しないか」「どう小さく表現するか」を考える

おすすめの小さな練習は、
自分のアプリで localStorage に保存しているキーを全部書き出してみて、

これは本当に必要か
これはもっと小さくできないか
これはサーバーから再取得すればいいのではないか

と一つずつ問い直してみることです。

「容量制限」を知っているかどうかで、
ストレージを“雑に使う人”と“設計して使う人”の差が、静かに開いていきます。