スクリーンウェイクロック API

W3C 作業草案

このドキュメントの詳細
このバージョン:
https://www.w3.org/TR/2026/WD-screen-wake-lock-20260929/
最新公開バージョン:
https://www.w3.org/TR/screen-wake-lock/
最新編集者ドラフト:
https://w3c.github.io/screen-wake-lock/
履歴:
https://www.w3.org/standards/history/screen-wake-lock/
コミット履歴
テストスイート:
https://wpt.live/screen-wake-lock/
実装レポート:
https://www.w3.org/wiki/DAS/Implementations
編集者:
Kenneth Rohde Christiansen (Intel Corporation)
Marcos Cáceres (Apple Inc.)
以前の編集者:
Raphael Kubo da Costa (Intel Corporation)
(Yandex)
(Yandex)
フィードバック:
GitHub w3c/screen-wake-lock (プルリクエスト, 新しい課題, 公開中の課題)
品質保証リード
Wanming Lin (Intel)

概要

この文書は、ウェブアプリケーションが要求できるようにする API を規定します 画面ウェイクロック。適切な条件下で、かつ許可されている場合、 画面ウェイクロックは、システムがデバイスの 画面をオフにすることを防ぎます。

この文書の位置づけ

この節では、この 文書の公開時点における位置づけについて説明します。現在の W3C 公開文書の一覧およびこの技術報告書の最新改訂版は、 W3C 標準および草案 索引で確認できます。

実装者は、この仕様が極めて 不安定であることに注意する必要があります。 議論に参加していない実装者は、自分たちの知らないところで仕様が 互換性のない形で変更されていることに気付くでしょう。 この 仕様が最終的に候補勧告 段階に到達する前に実装することに関心のあるベンダーは、 GitHub のリポジトリを購読し、議論に参加するべきです。

この文書は、Devices and Sensors Working Group および Web Applications Working Group により、 勧告 トラックを使用する作業草案として公開されました。

作業草案として公開されることは、 W3C およびその会員による承認を意味するものではありません。

これは草案文書であり、いつでも他の 文書によって更新、置換、または廃止される可能性があります。この文書を進行中の作業 以外のものとして引用することは適切ではありません。

この文書は、 W3C 特許 ポリシー の下で活動するグループによって作成されました。 W3C は、 特許開示の公開一覧 (Devices and Sensors Working Group) および 特許開示の公開一覧 (Web Applications Working Group) を、各グループの成果物に関連して 維持しています。これらのページには、 特許を開示するための手順も含まれています。ある個人が、 必須クレーム を含むとその個人が考える特許について実際の 知識を有している場合、 W3C 特許ポリシーの第 6 節 に従ってその情報を開示しなければなりません。

この文書には、 2025 年 8 月 18 日付 W3C プロセス文書が適用されます。

1. はじめに

この節は非規範的である。

現代のオペレーティングシステムは、積極的な電力管理を実装することで バッテリーの駆動時間を延ばしている。つまり、ユーザーの操作が 途絶えると、ホストデバイスはほどなく画面の明るさを下げ、 画面を消灯し、さらには CPU を深い省電力状態に移行させることで、 電力消費を可能な限り抑えることがある。

これはバッテリーの駆動時間を延ばすには優れているものの、場合によっては、 バーコードの読み取り、電子書籍の閲覧、レシピの確認、 聴衆に向けたプレゼンテーションなどのユースケースを妨げることがある。 ウェイクロック:ユースケースも参照。

ウェイクロックは一般に何らかの動作を防止するが、UA (および基盤となる OS)は、バッテリーの状態 (外部電源への接続、放電中、残量不足)に応じてその有効時間を制限したり、 省電力モードが有効な場合にはウェイクロックを禁止したりすることがある。

2. ウェイクロック

この仕様は、次の ウェイクロック 種別を定義する:

  1. 画面ウェイクロックは、画面が 消灯するのを防ぐ。可視状態の文書だけが画面ウェイクロックを 取得できる。

API では、ウェイクロック種別は、 WakeLockType 列挙型の値で表される。

注記

他の仕様が異なるウェイクロック種別を定義することもある。

3. ポリシーによる制御

Screen Wake Lock API は、ポリシー制御される機能を、 文字列 "screen-wake-lock" で識別されるものとして定義する。その 既定の許可リストは 'self' である。

注記

4. 権限とユーザーへの確認

[PERMISSIONS] API は、ウェブサイトがユーザーに権限を要求し、 どの権限を持っているかを照会するための統一的な方法を提供する。

ユーザー エージェントは、ウェイクロックを拒否することができる。 対象は、 特定の ウェイクロック種別と特定の Documentであり、その理由は、 プラットフォームの設定やユーザーの選好など、 実装固有の任意の理由でよい。

次のことが 推奨される:ユーザーエージェントは、邪魔にならない何らかの通知で、 ウェイクロックが有効であることをユーザーに知らせるとともに、 継続中の動作を ブロックするための手段、または 単に通知を 閉じるための手段をユーザーに提供する。

4.1 "screen-wake-lock" 強力な機能

"screen-wake-lock" 強力な機能は、 この仕様で定義する機能を有効にする。

4.2 権限アルゴリズム

"screen-wake-lock" 強力な機能は、権限取り消し アルゴリズムを定義する。画面 ウェイクロック権限取り消しアルゴリズムを呼び出すには、次の手順を実行する:

  1. document を、現在のグローバルオブジェクトに 関連付けられた Document とする。
  2. lockList を、 document.[[ActiveLocks]]["screen"] とする。
  3. それぞれについて、lock を lockList の各項目として:
    1. ウェイクロックを解放する手順を、document、lock、および "screen" を用いて実行する。

5. 概念

タスクソースのうち、この仕様で言及する タスクに 用いるものは、画面ウェイクロックタスクソースである。

プラットフォーム ウェイクロックという用語は、ユーザーエージェントが 状態の照会、およびウェイクロックの取得と解放のために やり取りするプラットフォームのインターフェースを指す。

プラットフォームウェイクロックは、基盤となるプラットフォーム (例えば、ネイティブのウェイクロックフレームワーク)によって、またはハードウェアを 直接制御できる場合はユーザーエージェントによって定義できる。

6. Document インターフェースへの拡張

6.1 内部スロット

内部スロット 初期値 説明
[[ActiveLocks]] 順序付きマップであり、ウェイクロック種別を空の リストに対応付ける。 順序付きマップであり、ウェイクロック 種別を、 リストに対応付ける。その WakeLockSentinel オブジェクトからなるリストは、 次の文書に関連付けられる: この Document。

7. Navigator インターフェースへの拡張

WebIDL[SecureContext]
partial interface Navigator {
  [SameObject] readonly attribute WakeLock wakeLock;
};

8. WakeLock インターフェース

WakeLock インターフェースを使うと、文書は 画面ウェイクロックを取得できる。

WebIDL[SecureContext, Exposed=(Window)]
interface WakeLock {
  Promise<WakeLockSentinel> request(optional WakeLockType type = "screen");
};

8.1 request() メソッド

request(type) メソッドの手順は次のとおりである:

  1. document を、this の 関連するグローバルオブジェクトに 関連付けられた Document とする。
  2. もし document が 完全にアクティブでなければ、次の値で拒否されるプロミスを返す:"NotAllowedError" DOMException。
  3. もし document が 使用を許可されていない ポリシー制御される機能の名前が "screen-wake-lock" であれば、次の値で拒否されるプロミスを返す:"NotAllowedError" DOMException。
  4. もし ユーザーエージェントが ウェイクロックを拒否する対象の種別がこの type であり、対象の文書が document であれば、次の値で拒否されるプロミスを返す: "NotAllowedError" DOMException。
  5. もし document の 可視性状態が "hidden" であれば、次の値で拒否されるプロミスを返す:"NotAllowedError" DOMException。
  6. promise を、新しい プロミスとする。
  7. 次の手順を 並列に実行する:
    1. state を、使用する 権限を要求する対象を "screen-wake-lock" とした結果とする。
    2. もし state が "denied" であれば:
      1. グローバルタスクをキューに入れる。使用するのは 画面ウェイク ロックタスク ソースであり、document の 関連するグローバルオブジェクトを与え、 promise を "NotAllowedError" DOMException で拒否する。
      2. これらの手順を中止する。
    3. グローバルタスクをキューに入れる。使用するのは 画面ウェイクロックタスク ソースであり、document の 関連するグローバルオブジェクトを与え、 次の手順を実行する:
      1. もし document が 完全にアクティブでなければ:
        1. promise を "NotAllowedError" DOMException で拒否する。
        2. これらの手順を中止する。
      2. もし document の 可視性状態が "hidden" であれば:
        1. promise を "NotAllowedError" DOMException で拒否する。
        2. これらの手順を中止する。
      3. もし document.[[ActiveLocks]]["screen"] が 空であるならば、 次の手順を 並列に 実行する:
        1. ウェイクロックを 取得する手順を、 "screen" を用いて呼び出す。
          注記
      4. lock を、新しい WakeLockSentinel オブジェクトとし、その type 属性の設定値を type とする。
      5. 追加する対象を lock とし、追加先を document.[[ActiveLocks]]["screen"] とする。
      6. promise を lock で解決する。
  8. promise を返す。

9. WakeLockSentinel インターフェース

WebIDL[SecureContext, Exposed=(Window)]
interface WakeLockSentinel : EventTarget {
  readonly attribute boolean released;
  readonly attribute WakeLockType type;
  Promise<undefined> release();
  attribute EventHandler onrelease;
};

WakeLockSentinel オブジェクトは、プラットフォームウェイク ロックへのハンドルを提供し、手動で解放されるか、 基盤となる プラットフォームウェイクロックが解放されるまで保持する。その 存在により、プラットフォームウェイクロックは、指定された ウェイクロック 種別について有効に保たれる。また、すべての WakeLockSentinel インスタンスのうち、 指定された ウェイクロック種別のものを解放すると、基盤となる プラットフォームウェイク ロックが解放される。

注記

9.1 内部スロット

WakeLockSentinel インスタンスは、 次の 内部 スロットを持つものとして作成される:

内部スロット 初期値 説明(非規範的)
[[Released]] false 指定された WakeLockSentinel が解放されたかどうか。

9.2 released 属性

released のゲッターの手順は、 this.[[Released]] を返すことである。

注記

9.3 type 属性

type のゲッターの手順は、this の ウェイクロック種別を返すことである。

9.4 release() メソッド

release() メソッドの手順は 次のとおりである:

  1. もし this の [[Released]] が false であれば、 ウェイクロックを解放する手順を実行する。その際、lock の設定値を this とし、type の設定値を 次の値とする: this の type 属性の値。
  2. 次の値で解決されるプロミスを返す: undefined。

9.5 onrelease 属性

onrelease 属性は、イベントハンドラー IDL 属性であり、"onrelease" イベント ハンドラーに対応する。その イベントハンドラーのイベント種別は "release" である。

これは、指定された WakeLockSentinel オブジェクトのハンドルが解放されたことをスクリプトに通知するために使われる。その原因は、 release() メソッドの 呼び出し、または ウェイクロックを解放した ユーザーエージェントによるものである。

注記
注記

9.6 ガベージコレクション

WakeLockSentinel オブジェクトに 1つ以上のイベントリスナーが、 "release" に対して登録されており、かつ WakeLockSentinel オブジェクトがまだ 解放されていない間は、次の強参照の存在が 必須である: 参照元は Window オブジェクトであり、そこから WakeLockSentinel オブジェクトのコンストラクターが 呼び出されたものとする。参照先は、 WakeLockSentinel オブジェクト自身である。

WakeLockSentinel オブジェクトによって、 画面ウェイクロックタスクソースにキューに入れられたタスクがある間は、必須である、次の強参照が存在することが。 参照元は Window オブジェクトであり、その WakeLockSentinel オブジェクトの コンストラクターがそこから呼び出されたものとする。参照先は、その WakeLockSentinel オブジェクトである。

10. WakeLockType 列挙型

ウェイクロック種別を記述するため、この仕様は、 次の列挙型を定義して ウェイクロック種別を表す:

WebIDLenum WakeLockType { "screen" };
screen
画面ウェイクロックの種別。

11. ウェイクロックの管理

この節は、各 ウェイクロック種別に等しく、 独立して適用される。ただし、特定の ウェイクロック種別が明示的に 言及されている場合を除く。

ユーザー エージェントが ウェイクロックを 取得するには、基盤となるオペレーティングシステムにロックの適用を 要求する。基盤となるオペレーティングシステムへの要求に 戻り値があっても、それは確認されない。言い換えると、ユーザーエージェントには、 必須である、ウェイクロックの取得を助言的なものとしてのみ扱うことが。

逆に、ユーザーエージェントが ウェイクロックを解放するには、 基盤となるオペレーティングシステムにウェイクロックの適用を終了するよう 要求する。ロックが解放されたとみなされるのは、オペレーティングシステムへの 要求が成功した場合だけである。

ウェイクロックが 適用可能であるのは、 オペレーティングシステムの状態がロックの適用を許す場合である (例えば、バッテリーに十分な残量がある場合)。

画面ウェイクロックについて、次のことは 禁止される:適用可能であることが、 ユーザーが手動で画面を消灯した後から、再び点灯するまで 続くこと。

注記

11.1 ウェイクロックの自動解放

ユーザーエージェントは、いつでも ウェイクロックを解放することができる。例えば、 次の場合である:

11.2 文書が完全にアクティブでなくなった場合の処理

Document document が、それまでの 完全にアクティブな状態を失った場合、ユーザーエージェントは次の 手順を実行しなければならない:

  1. それぞれについて、lock を document.[[ActiveLocks]]["screen"] の各項目として:
    1. ウェイクロックを解放する手順を、document、lock、および "screen" を用いて実行する。

11.3 文書が可視状態でなくなった場合の処理

この仕様は、次の ページ可視性変更時の手順を、可視性状態 state と document を引数として定義する:

  1. もし state が "hidden" でなければ、これらの手順を中止する。
  2. それぞれについて、lock を document.[[ActiveLocks]]["screen"] の各項目として:
    1. ウェイクロックを解放する手順を、document、lock、および "screen" を用いて実行する。

11.4 ウェイクロック取得アルゴリズム

ウェイクロックを 取得するには、指定された type に対して、 次の手順を実行する:

  1. もし種別 type のウェイクロックが 適用可能でなければ、 これらの手順を中止する。
  2. 基盤となるオペレーティングシステムに、ウェイクロックを 取得するよう、種別 type を指定して要求する。

11.5 ウェイクロック解放アルゴリズム

ウェイクロックを 解放するには、指定された document、 lock、および type に対して、次の 手順を実行する:

  1. もし document.[[ActiveLocks]][type] が lock を含んでいなければ、これらの手順を中止する。
  2. lock を、 document.[[ActiveLocks]][type] から取り除く。
  3. もし document.[[ActiveLocks]][type] が 空であるならば、次の手順を 並列に実行する:
    1. 基盤となるオペレーティングシステムに、ウェイクロックを 解放するよう、種別 type を指定して要求し、success を、操作が成功した場合は true、 そうでなければ false とする。
    2. もし success が true であり、かつ type が "screen" であれば、 次を実行する:
      1. 期限が切れると画面が実際に消灯する、 プラットフォーム固有の非アクティブタイマーをリセットする。
      注記
  4. lock の [[Released]] を true に設定する。
  5. イベントを発火する。名前を "release"、対象を lock とする。

12. セキュリティ上の考慮事項

画面ウェイクロックにより、デバイスのさまざまな構成要素、特に ディスプレイが、通常より高い電力消費で動作することが ある。これにより、デバイスの自動ロックが妨げられたり、 バッテリーの消耗が速まったりするなど、望ましくない影響が生じることがある。 バッテリーの消耗が速まることは、モバイルデバイスでは特に問題となる。 固定電源をすぐに利用できないことが多いためである。 予期しないときにバッテリーが完全に切れると、 ユーザーは通話の発信や着信、およびネットワークサービスを 利用できなくなることがあり、これには緊急通報サービスも含まれる。

実装が画面ウェイクロックの要求を無視することは 許容される。例えば、 バッテリー残量が少ない場合や、ユーザーがデバイスを 省電力モードにしている場合である。

13. プライバシー上の考慮事項

次のことが 推奨される:ユーザーエージェントは、画面ウェイクロックが 有効であることをユーザーが知るための UI や表示を提供する。 そのような UI は、特定のウェブアプリケーションが デバイスの電力消費に悪影響を及ぼしているかどうかをエンドユーザーが判断し、 希望に応じて対処する助けとなり得る。

14. 例

この節は非規範的である。

例 1: 画面ウェイクロックを取得して解放する
function tryKeepScreenAlive(minutes) {
  navigator.wakeLock.request("screen").then(lock => {
    setTimeout(() => lock.release(), minutes * 60 * 1000);
  });
}

tryKeepScreenAlive(10);

この例では、ユーザーがチェックボックスをクリックすることで 画面ウェイクロックを要求できる一方、ウェイクロックの状態が変わった場合は、 チェックボックスのチェック状態を更新する:

const checkbox = document.createElement("input");
checkbox.setAttribute("type", "checkbox");
document.body.appendChild(checkbox);

const sentinel = await navigator.wakeLock.request("screen");
checkbox.checked = !sentinel.released;
sentinel.onrelease = () => checkbox.checked = !sentinel.released;

この例では、2つの異なるウェイクロック要求を作成し、 それぞれ独立して解放する:

let lock1 = await navigator.wakeLock.request("screen");
let lock2 = await navigator.wakeLock.request("screen");

lock1.release();
lock2.release();

15. 適合性

非規範的と明記された節に加え、この仕様に含まれるすべての作成ガイドライン、図、例、および注記は 非規範的である。この仕様のそれ以外の内容はすべて規範的である。

この文書のキーワード 許容される(MAY)、必須である(MUST)、禁止される(MUST NOT)、および 推奨される(RECOMMENDED)は、 次に記述されるとおりに解釈する: BCP 14 [RFC2119] [RFC8174]。 ただし、ここに示すように、原文ですべて 大文字で表記されている場合に限る。

この仕様は、単一の製品について適合性基準を定義する。その製品は、 ユーザーエージェントであり、この仕様に含まれるインターフェースを実装するものである。

A. 謝辞

この節は非規範的である。

この取り組みに貢献した Mounir Lamouri、Sergey Konstantinov、Matvey Larionov、Dominique Hazael-Massieux、Domenic Denicola、Thomas Steiner、Anne van Kesteren に、 心より感謝する。

B. 変更点

この節は非規範的である。

この節は、以前の公開版からの変更点を記録する。

B.1 2017年12月14日の勧告候補からの変更点

C. 索引

C.1 この仕様で定義する 用語

C.2 参照によって定義される用語

D. IDL 索引

WebIDL[SecureContext]
partial interface Navigator {
  [SameObject] readonly attribute WakeLock wakeLock;
};

[SecureContext, Exposed=(Window)]
interface WakeLock {
  Promise<WakeLockSentinel> request(optional WakeLockType type = "screen");
};

[SecureContext, Exposed=(Window)]
interface WakeLockSentinel : EventTarget {
  readonly attribute boolean released;
  readonly attribute WakeLockType type;
  Promise<undefined> release();
  attribute EventHandler onrelease;
};

enum WakeLockType { "screen" };

E. 参考文献

E.1 規範的な参考文献

[dom]
DOM 標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://dom.spec.whatwg.org/
[ECMASCRIPT]
ECMAScript 言語仕様. Ecma International. URL: https://tc39.es/ecma262/multipage/
[html]
HTML 標準. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 現行 標準. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra 標準. Anne van Kesteren; Domenic Denicola. WHATWG. 現行標準. URL: https://infra.spec.whatwg.org/
[PERMISSIONS]
権限. Marcos Caceres; Mike Taylor. W3C. 2025年10月6日. W3C 作業草案. URL: https://www.w3.org/TR/permissions/
[PERMISSIONS-POLICY]
権限ポリシー. Ian Clelland; Ari Chivukula. W3C. 2026年9月22日. W3C 作業草案. URL: https://www.w3.org/TR/permissions-policy-1/
[RFC2119]
RFC において要件レベルを示すために 使用するキーワード. S. Bradner. IETF. 1997年3月. 現行最良慣行. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC8174]
RFC 2119 のキーワードにおける大文字と小文字の曖昧さ. B. Leiba. IETF. 2017年5月. 現行最良慣行. URL: https://www.rfc-editor.org/info/rfc8174/
[WEBIDL]
Web IDL 標準. Edgar Chen; Timothy Gu. WHATWG. 現行標準. URL: https://webidl.spec.whatwg.org/

E.2 参考情報の文献

[wake-lock-use-cases]
ウェイクロック: ユースケース. Marcos Caceres; Natasha Rooney; Dominique Hazaël-Massieux. W3C. 2014年8月14日. W3C 作業部会ノート. URL: https://www.w3.org/TR/wake-lock-use-cases/