ブラウザストレージとIndexedDBのトランザクションモデル

IndexedDB は「非同期トランザクショナル KVS」

IndexedDB は、ブラウザ内に構造化データを保存する非同期のキーバリューデータベースです。Web ストレージ が文字列だけの同期 API なのに対し、IndexedDB は任意の構造化複製可能オブジェクト（オブジェクト、配列、ArrayBuffer、Blob、Date など）をそのまま格納でき、すべての操作が非同期かつトランザクション内で行われます。この2点が設計の根幹です。

非同期である理由は、I/O がメインスレッドを止めないためです。localStorage の読み書きは同期でメインスレッドをブロックしますが、IndexedDB の各操作はリクエストオブジェクトを返し、完了は success / error イベント（または Promise ラッパー）で受け取ります。これは イベントループ のタスクとして処理が積まれることを意味します。

データの階層は次のとおりです。1つの origin は複数のデータベースを持て、各データベースは複数のオブジェクトストア（リレーショナル DB のテーブルに相当）を持ちます。各ストアはレコードを主キーで一意に並べ、追加でインデックスを張れます。

オブジェクトストアとインデックスの内部

オブジェクトストアは内部的に主キーでソートされた木構造（多くの実装で B-tree 系）として保持されます。これにより、主キーの範囲取得（IDBKeyRange）や openCursor による順次走査が、全件スキャンなしで効率的に行えます。キーには文字列・数値・日付・配列が使え、仕様で定義された全順序で比較されます。

インデックスは「インデックス対象プロパティの値 → 主キー」という対応を保つもう1つのソート済み構造です。インデックス経由の検索は、まずインデックス上で対象キーを二分探索し、得られた主キーでストア本体を引く、という2段の参照になります。インデックスには制約を付けられます。

• unique：インデックスキーの重複を禁止。違反する書き込みはトランザクションごと失敗（abort）する。
• multiEntry：対象プロパティが配列のとき、各要素を個別のインデックスエントリにする。タグ検索のような多対多に使う。

トランザクションの3モードとスコープ

IndexedDB のすべての読み書きはトランザクション内でのみ可能で、transaction(storeNames, mode) で対象ストア（スコープ）とモードを指定して開始します。モードは3種類です。

versionchange は通常の transaction() では作れず、open(name, version) のバージョン番号を上げたときの upgradeneeded イベント内でのみ得られます。ストアやインデックスの作成・削除といったスキーマ変更は、この中でしか行えません。versionchange 中は、その DB に対する他の接続をブロックするため、開いたままの古いタブがあると blocked イベントが発生して昇格が止まります。

分離レベルとロックの粒度

IndexedDB のトランザクション分離は、仕様上直列化（serializable）に近い強い保証を持ちます。これを支えるのがスコープ単位のロックです。トランザクションは開始時に宣言したストア集合に対し、モードに応じたロックを取ります。

ロックの両立性（同一ストアに対して）:
  readonly  と readonly   → 両立する（並行読み取り可）
  readwrite と 何か       → 両立しない（書き込みはストアを排他）

スコープが重ならなければ:
  別々のストアを触る readwrite どうし → 並行に走れる

重要なのは、ロックの単位が**レコードではなくストア（テーブル相当）**である点です。あるストアに対する readwrite トランザクションは、そのストア全体を実質的に占有し、スコープが重なる他のトランザクションは前のものが終わるまで待たされます。実装は宣言されたスコープに基づいてトランザクションを順序付け、結果として「同時に走るトランザクションが互いに干渉しない（直列実行と同じ結果になる）」ことを保証します。アプリ側でロックを取る必要はありません。

書き込み中に制約違反や明示的な abort()、あるいはハンドラ内の例外が起きると、そのトランザクションの全変更がロールバックされます。部分適用は起こらないため、複数レコードの整合した更新を1トランザクションにまとめるのが安全です。

ストレージ量管理と退避（eviction）

ブラウザはオリジンごとに使用量を計測し、デバイスの空き容量に応じたクォータ（多くは全体の数十%を上限とする動的な値）を割り当てます。使用量は navigator.storage.estimate() で概算を取得できます。ここで決定的に重要なのが、ストレージが2つの**永続性モード（persistence）**に分かれる点です。

best-effort のデータは、ディスクが逼迫したときブラウザによって退避され得ます。退避は通常 origin 単位で行われ、各 origin の保存物（IndexedDB だけでなく Cache Storage なども含む）がまとめて消去されます。選定方針は概して **LRU（Least Recently Used）**で、最後にアクセスされてから最も時間が経った origin から消去対象になります。レコード単位で部分的に間引かれるのではなく、origin の領域が丸ごと飛ぶ、というのが退避の実像です。

Persistent Storage の取得

退避から保護したい場合は、navigator.storage.persist() で永続化を要求します。これは Promise を返し、許可されれば true、拒否されれば false を返します。

// 現在の永続性モードを確認
const persisted = await navigator.storage.persisted(); // true / false

// 永続化を要求（ユーザー操作や利用実績に応じて許可される）
if (!persisted) {
  const granted = await navigator.storage.persist();
  // granted が true なら、この origin は退避対象から外れる
}

// 使用量とクォータの概算
const { usage, quota } = await navigator.storage.estimate();

許可されるかどうかはブラウザのヒューリスティクスに依存します。サイトがインストール済み PWA である、通知許可がある、エンゲージメントが高い、といった条件で自動的に許可されたり、明示的な許可ダイアログが出たりします（実装差が大きい）。許可されると、その origin のストレージは容量逼迫時の退避対象から外れ、ユーザーが明示的に削除しない限り保持されます。オフライン主体のアプリでは、永続化要求は PWA とサービスワーカー の設計とセットで考えるべき要素です。

なお、永続化は「無限に書ける」という意味ではありません。クォータ上限は依然として存在し、超過時の put は QuotaExceededError で失敗します。永続化が保証するのは「勝手に退避されない」ことであって、容量無制限ではない点を取り違えないでください。

まとめ

IndexedDB は、スコープ単位ロックによる直列化に近い分離と自動コミットを備えた、非同期トランザクショナル KVS です。設計の要点は、(1) 1つの整合した更新を1トランザクションにまとめ、その寿命内では IndexedDB 操作だけを連続させる、(2) インデックスは読み取り高速化と書き込みコストのトレードオフで選ぶ、(3) 失っては困るデータは persistent を要求しつつサーバーにも複製する、の3つです。退避ポリシーと永続性モードの理解は、クライアントを「キャッシュ」として正しく扱うための前提になります。機密トークンの置き場所など保存先全般の判断は Cookie とセッション も合わせて整理してください。