WEBアプリのデータ保存技術の種類
WEBブラウザのデータ保存技術には、たくさんの種類がありますが、特徴、容量、主な用途に違いが存在します。
| 名前 | 特徴 | 容量の目安 | 主な用途 |
|---|---|---|---|
| LocalStorage | キー・バリュー形式（文字列のみ）、同期API、永続保存 | 約5〜10MB（ブラウザ依存） | ユーザー設定、テーマ、簡単なキャッシュ |
| SessionStorage | LocalStorageと同様だが、タブを閉じると消える | 約5〜10MB（ブラウザ依存） | 一時的な入力データ、セッション中の状態管理 |
| Cookies | サーバーと自動送受信、サイズ制限あり | 約4KB/個、合計20〜50個程度 | 認証情報、トラッキング、セッションID |
| IndexedDB | 構造化データの保存、非同期API、インデックス検索可能 | 数十〜数百MB（ブラウザ依存） | キャッシュ、履歴、オフラインデータ、構造化DB |
| OPFS（Origin Private File System） | ファイル・ディレクトリ構造、バイナリ対応、WASMと高相性 | 数百MB〜GB級（ブラウザ依存） | SQLite、画像/音声/動画保存、仮想ファイルシステム |
| Cache Storage API | サービスワーカーと連携、HTTPレスポンスをキャッシュ | 数十〜数百MB（ブラウザ依存） | PWAのオフライン対応、静的リソースのキャッシュ |
| File System Access API | ユーザーのローカルファイルに直接アクセス（要許可） | ユーザーのローカルストレージに依存 | テキスト/画像エディタ、ファイルの読み書きアプリ |
| WebSQL（非推奨） | SQLベースのDB、SQLite依存、非推奨 | 数MB〜（ブラウザ依存） | 古いアプリの互換性維持用（新規開発非推奨） |
ざっくり判断すると、実務ではこう考えられそうです👇
- 簡単な設定 → LocalStorage
- 一時データ → SessionStorage
- サーバー連携 → Cookies
- 本格データ → IndexedDB
- 大容量・ファイル → OPFS
👉 「用途で選ぶ」のが最も重要だと思われます
まず全体像をざっくり理解
現在のWebでは、ブラウザの中にデータを保存する方法がいくつもあります。 👇おおまかには、下記のようなイメージのようです
| 種類 | イメージ |
|---|---|
| LocalStorage | 小さなメモ帳 |
| SessionStorage | 一時メモ |
| Cookies | サーバーとやり取りするメモ |
| IndexedDB | 軽いデータベース |
| OPFS | ファイル保存領域 |
| Cache Storage API | 通信データのキャッシュ |
| File System Access API | ローカルPCファイル |
| WebSQL | データベース（非推奨） |
主な保存技術の違い
1. LocalStorage
- 簡単に使える
- データはずっと残る
- 小容量（約5〜10MB）
👉 設定保存に最適
2. SessionStorage
- タブを閉じると消える
- LocalStorageとほぼ同じ使い方
👉 一時データ向け
3. Cookies
- サーバーと自動で送受信される
- 容量がとても小さい（約4KB）
👉 ログイン管理など
4. IndexedDB
- データベースのように使える
- 大容量・非同期処理
👉 本格アプリ向け
5. OPFS（Origin Private File System）
- ファイルとして保存できる
- 画像・動画・DBなどに強い
👉 最近かなり重要になってきた技術
6. Cache Storage API
- 通信結果を保存
👉 PWAでよく使う
7. File System Access API
- ユーザーのPCファイルに直接アクセス
👉 ただし許可が必要
8. WebSQL（非推奨）
- 古い技術
👉 新規開発では使わない
実際の選び方（ここが重要）
ケース①：設定を保存したい
👉 LocalStorage
ケース②：一時的な入力内容
👉 SessionStorage
ケース③：ログイン状態を管理
👉 Cookies
ケース④：データが多い（履歴・一覧）
👉 IndexedDB
ケース⑤：画像・動画・ファイルを扱う
👉 OPFS
ケース⑥：SQLデータベースを使う
👉 OPFS（Sqliteとの組み合わせで可能）
余談ですが、本来、その役割はWebSQLの標準化が担う予定でしたが、残念ながら、仕様策定が止まってしまい、今は互換性維持の為だけに存在しています。
よくある実務パターン
実務では「1つだけを使う」というより、組み合わせて使う例が多そうです。👇
パターン①：組み合わせ
LocalStorage → 設定
IndexedDB → データ本体
パターン②：PWA
Cache API → オフライン表示
IndexedDB → データ保存
パターン③：最近のトレンド
OPFS + SQLite（WASM）
👉 ブラウザ内でDBを動かす
なぜ今こんなに増えているのか？
昔は👇これだけでした
Cookiesのみ
しかし現在は：
👉 Webアプリがネイティブアプリ並みに進化
- オフライン動作
- 大容量データ
- 高速処理
OPFSが注目される理由
1. ファイルとして扱える
- 画像
- 動画
- DBファイル
👉 ブラウザ内でSQLが使える
2. 実務的なメリット
IndexedDBより設計がシンプルになるケースあり
WASMとの相性が良い
File System Access APIとOPFSの違い
一見似ていますが、違います👇
File System Access API
- ユーザーのPCファイルにアクセス
- 毎回「許可」が必要
OPFS
- ブラウザ内の専用領域
- 自動で使える
👉 アプリ用途ならOPFSの方が扱いやすい
まとめ
- Webには複数の保存方法がある
- それぞれ得意分野が違う
- 用途で選ぶのが最重要
- ブラウザによって容量や仕様が違う
- 対応ブラウザ毎の違いに注意
- 古い技術（WebSQL）は使わない