
IndexedDBは、ブラウザに大量の構造化データを保存し、インデックスを使って検索できるクライアントサイドのNoSQLデータベースです。W3Cが2010年9月に最初の草案を発表し、2015年に勧告候補(CR)に到達した後、現在もWHATWG IndexedDB仕様として更新されています。それまでブラウザ内のストレージはCookieやlocalStorageのような単純なキーと文字列の対が中心でしたが、IndexedDBはオブジェクトストア・トランザクション・インデックスといった本格的なDB機能を提供し、オフラインで動くWebアプリの永続化基盤として広く採用されています。
この記事の目次
- オブジェクトストアとインデックスの構造
- 非同期APIと容量の上限
- オフラインWebアプリでの活用
- 他のクライアントストレージとの違い
- まとめ
オブジェクトストアとインデックスの構造

IndexedDBは階層構造を持ち、最上位の「データベース」はオリジン(スキーム+ホスト+ポート)ごとに複数作成できます。データベースの中には「オブジェクトストア」が並び、リレーショナルDBのテーブルに相当しますが、保存するのは行ではなくJavaScriptオブジェクトそのものです。主キーはオブジェクト内のフィールド名で指定したり自動採番させたりでき、副次的な検索のために「インデックス」を任意のフィールドへ作れます。文字列・数値・Date・ArrayBuffer・Blobまで幅広い型を構造化複製アルゴリズムで永続化できる点が、JSONテキストしか保存できない他のAPIとの差です。
操作はすべて「トランザクション」を介して行われ、readonly readwrite versionchange の三つのモードがあります。トランザクションは自動的にコミットされ、明示的なBEGIN/COMMITは不要です。スキーマ変更は versionchange トランザクションのみで可能で、データベースのバージョン番号を上げることで onupgradeneeded イベントが発火し、その中で新しいオブジェクトストアやインデックスを追加できます。バージョン管理が明示的なため、リリースをまたいだスキーマ変更も安全に扱えます。
非同期APIと容量の上限

IndexedDBのAPIは完全に非同期で、すべての操作がIDBRequestオブジェクトを返し、onsuccess onerror ハンドラで結果を受け取ります。Promiseベースで設計されていない歴史的な経緯から、生のAPIはコールバック地獄に陥りやすく、Dexie.jsやidb(Jake Archibald作)といったPromiseラッパーライブラリを使う運用が一般的です。Service Worker内からもアクセスでき、オフライン時のキャッシュ管理やプッシュ通知受信時のデータ保存に活躍します。
保存容量はlocalStorageの5MBに比べて桁違いに大きく、各オリジンに対しブラウザ全体ストレージの数十パーセントを割り当てる方式です。Chromeの場合は利用可能ディスクの最大60%まで使え、実用上は数GB単位のデータも保存できます。navigator.storage.estimate() で残量を確認したり、navigator.storage.persist() でユーザーの許可を得て永続化を保証したりするAPIも備えており、ブラウザの自動クリーンアップから守る仕組みが整っています。
オフラインWebアプリでの活用

IndexedDBは、GmailのオフラインモードやOutlook on the WebのようなWebメールクライアントでメッセージ本文や添付ファイルを丸ごとブラウザに保存する用途に使われています。数万通のメールをローカルでインデックス検索できるのは、まさにIndexedDBのインデックス機能の恩恵です。Notionのようなドキュメントアプリでも、ローカル編集中のページデータを保持して再接続時にサーバーへ同期する仕組みに活用されています。
PWA(Progressive Web App)の文脈ではService WorkerによるネットワークキャッシュとIndexedDBによるアプリデータキャッシュを組み合わせ、初回ロード後はオフラインでも操作可能なアプリを構築できます。FigmaやGoogle DocsのようなWeb GUIアプリも、編集途中のドキュメントをIndexedDBに保存して突然のネットワーク断や再読込でも作業を失わないように設計されています。近年はWasmで作られたSQLite(sql.js・SQLite-Wasm)の永続化バックエンドとしてIndexedDBを使う「ブラウザ内RDB」構成も増えており、本格的なSQL操作をクライアント側で完結させる事例も出てきました。
他のクライアントストレージとの違い

localStorageは同期APIで5MB制限のため、設定値やトークンの保存には便利ですが大量データには不向きです。Cache APIはHTTPリクエストとレスポンスのペアを保存することに特化しており、Service Workerのオフラインキャッシュには最適ですが、構造化データの検索には使えません。Cookieはサーバーへ自動送信されるためサイズ的にも用途的にも別物です。IndexedDBはこれら全てを補完する位置にあり、「大量・構造化・型豊富・検索可能」という枠を埋めています。
2023年頃から普及してきたOrigin Private File System(OPFS)は、ブラウザ内に通常のファイルシステムを持ち込むAPIで、SQLiteのページファイルなどをそのまま置けます。IndexedDBより低レイヤーで高速ですが、インデックス機能は自前で実装する必要があります。複雑な検索や型保存が必要ならIndexedDB、単純なファイル読み書き性能が欲しいならOPFS、という使い分けが2020年代後半の主流になりつつあります。
まとめ
IndexedDBは、ブラウザという制約のある環境にNoSQLデータベースの世界を持ち込んだWeb標準の中核ストレージです。容量・型・検索のいずれもlocalStorageを大きく超えており、オフライン対応アプリ・PWA・ブラウザ内SQLiteの永続化基盤として、現代Webアプリ開発に欠かせない存在になっています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

コメント