Web Locks API

なぜブラウザに排他制御が要るのか

同じオリジンのアプリを複数タブで開くと、各タブは独立した実行コンテキストを持ちながら、IndexedDB や localStorage、同じリフレッシュトークンといった共有資源へ同時にアクセスします。トークンのリフレッシュを全タブが同時に走らせればリフレッシュエンドポイントを多重に叩き、キャッシュの再構築を並走させれば無駄な二重書き込みが起きます。従来はこれを localStorage への書き込みとポーリングや、独自のミューテックス擬似実装で回避してきましたが、いずれもタブがクラッシュした場合の解放漏れや、原子性の欠如が課題でした。Web Locks API（navigator.locks）は、この「オリジン内・複数コンテキスト間の排他制御」をブラウザ本体の責務として提供する専用APIです。

スコープ付きロックという設計

Web Locks API の中心は navigator.locks.request(name, callback) です。特徴的なのは、ロックの取得・解放を明示的な lock()/unlock() 呼び出しではなく、コールバックのライフタイムに紐づけるスコープ付きロックとして設計している点です。

await navigator.locks.request("token-refresh", async (lock) => {
  // このコールバックの実行中だけロックを保持
  const token = await refreshAccessToken();
  await saveToken(token);
}); // コールバックがresolve/rejectした時点で自動解放

callback が返す Promise が解決（成功・失敗いずれも）すると、ブラウザは自動的にロックを解放します。呼び出し側が解放を忘れるという事故が構造的に起こりません。同様に、ロックを保持しているタブが閉じられる・クラッシュする・ページ遷移すると、そのタブに属する実行コンテキストが破棄された時点でブラウザがロックを強制解放します。デッドロックが半永久に残るリスクは、他の自作排他制御より小さくなっています。

exclusiveとshared、キューの規則

request の第2引数（省略可能なオプション）で mode を指定できます。既定は "exclusive"（排他）で、同名ロックを同時に1コンテキストしか保持できません。"shared" を指定すると、読み取り専用処理のように同時保持を許す共有ロックになります。

// 複数タブが同時に読み取り可能
navigator.locks.request("cache-read", { mode: "shared" }, async () => {
  return readFromCache();
});

// 書き込みは排他。shared保持者がいる間は待機する
navigator.locks.request("cache-read", { mode: "exclusive" }, async () => {
  return rebuildCache();
});

同じロック名に対する要求はキューに積まれ、**原則として要求された順（FIFO）**で許可されますが、仕様は「実装がリソースの公平性のために順序を変えてよい」余地も残しており、厳密なFIFOを前提にした設計は避けるべきです。sharedモード同士は同時に許可され、exclusiveの要求はキュー内の既存の保持者・先行する要求がすべてはけるまで待たされます。

待機を避けるifAvailableと、強制奪取のsteal

既定の request はロックが空くまで待機しますが、待たずに「今すぐ空いていなければ諦める」判定も可能です。ifAvailable: true を指定すると、ロックが即座に取れない場合コールバックには lock 引数として null が渡され、待機せずに即座に解決します。

await navigator.locks.request("token-refresh", { ifAvailable: true }, async (lock) => {
  if (lock === null) {
    return; // 他のタブが既にリフレッシュ中なので何もしない
  }
  await refreshAccessToken();
});

もう一つの特殊オプションが steal: true です。これは既存の保持者・待機中のキューをすべて破棄し、強制的にロックを奪取します。奪われた側のコールバックは中断されず実行され続けますが、そのロックへの参照はもはや有効な保持を意味しません。名前の通り緊急避難的な機能で、通常のアプリケーションロジックでは ifAvailable までにとどめ、steal は「明らかに固まった処理を強制的にリセットしたい」限定的な場面に留めるのが妥当です。

リーダー選出パターンへの応用

Web Locks API の代表的な応用が**リーダー選出（leader election）**です。複数タブが起動している中で「バックグラウンド同期やWebSocket接続を担当するのは1タブだけにしたい」という要求に対し、各タブが同じ排他ロックを取り合い、取れたタブがリーダーとして振る舞う、という単純な仕組みで実現できます。

function becomeLeaderForever() {
  navigator.locks.request("app-leader", async () => {
    startWebSocketConnection();
    // ロックを握ったまま解放しないPromiseを返し続ける
    return new Promise(() => {}); // タブが閉じるまで保持
  });
}

becomeLeaderForever();

ここでのポイントは、コールバックがあえて解決しないPromiseを返すことです。ロックはコールバックの生存期間に紐づくため、意図的に解決させなければリーダーであるタブがロックを保持し続け、そのタブが閉じられた瞬間に自動解放され、キューで待っていた次のタブへ即座にリーダー権が移ります。明示的な「離脱通知」やハートビートを自作する必要がなく、ブラウザのコンテキスト破棄検知に選出の継続性を委ねられる点が、この応用の実務的な強みです。

BroadcastChannelとの使い分け

BroadcastChannelとWeb Locks APIは、しばしば同じ「マルチタブ調整」の文脈で語られますが、解決する問題が異なります。BroadcastChannelは状態やイベントを全コンテキストへ同報する通信路であり、誰が処理を担当するかという排他制御の仕組みは持ちません。全タブが同じメッセージを受け取って各自処理すれば、むしろ多重実行になります。一方Web Locks APIは**「誰か1つだけが処理する」という相互排他**を保証しますが、処理結果を他のタブへ伝える通信機能は持ちません。

まとめ