このページは Cloud Translation API によって翻訳されました。

ウェブ権限に関するおすすめの方法

Marian Harbach

Thomas Steiner

権限プロンプトは、ユーザーのプライバシーとセキュリティに危険をもたらす可能性のある強力な機能を保護するためのウェブの主なメカニズムです。権限プロンプトを使用すると、リクエスト元のウェブサイトに該当する機能へのアクセスを許可する意思がユーザーにあることを確認できます。権限プロンプトは、メディアのキャプチャ（カメラとマイク）、位置情報、ストレージへのアクセス、MIDI、通知など、さまざまな API で使用されます（詳細については、MDN の Permissions API のドキュメントをご覧ください）。

このガイドでは、Chrome の使用状況の統計情報とユーザー調査に基づいて、ユーザーに権限プロンプトを表示するためのベストプラクティスについて説明します。これらのベストプラクティスに従うと、ユーザーに不要なプロンプトが表示される回数が減り、デベロッパーが「ブロック」の判断を下す回数も減ります。最後に、権限制限付き API を操作するためのコードパターンと、ユーザーがブロックされた状態から復旧できるようにするためのベストプラクティスについて説明します。

プロンプトのベストプラクティス

権限をリクエストするタイミングは、ユーザーがリクエストの理由と、許可することで得られるメリットを理解できるタイミングにする必要があります。可能であれば、ユーザーが別の方法で同じ機能を実行できるようにする必要があります。一般的なガイドラインとして、権限をリクエストするタイミングを慎重に選択してリクエストの頻度を減らすことで、ユーザーが回復が困難なブロック状態に陥る可能性を低減できます。以下のベストプラクティスでは、これらの各提案について詳しく説明します。

ページの読み込み時やユーザーの操作なしで尋ねない

ページの読み込み時にユーザーに権限を求めることは、実店舗に足を踏み入れたお客様に機密情報を尋ねるのと同じことです。許可プロンプト（ニュースレター登録や Cookie の同意に関する他の複数のプロンプトとともに表示される）は、非常に不快なものです。ユーザーは、質問される理由やメリットを理解できません。

ウェブアプリが特定の機能にアクセスできない場合でも、その機能が必要な理由をユーザーに理解してもらう必要があります。たとえば、権限プロンプトの前に、権限の必要性を説明する独自のプロンプトを追加し、ユーザーに選択肢を提供します（可能であれば、同じ機能を実現するための代替手段を提供するなど）。ページの読み込み時よりも権限を要求するタイミングが思いつかない場合のために、このガイドの後半にいくつかの例があります。

権限をリクエストするのに適さない状況として、事前のユーザー操作がない状況（一時的なユーザーアクティベーション）も同様です。Chrome のテレメトリーによると、パソコン版 Chrome の権限プロンプトの 77% が、ユーザーの意図を示すごく基本的なシグナルなしで示されているため、そのようなプロンプトのうち 12% しか許可されません。ユーザーの操作後、許可率は 30% に増加します。そのため、ユーザーがなんらかの形でページを操作した後にのみ、権限をリクエストしてください。

ユーザーが質問の理由を理解できる場合にのみ質問する

権限に関する判断は、多くの場合プライバシーに関する判断です。コンテキスト整合性フレームワークに基づいて、プライバシーに関する判断はコンテキストに大きく依存することを認識しています。アクセスが必要な理由を理解することが、この重要な要素と考えられます。したがって、ユーザーに価値を提供するために必要な機能（そして実際に価値が得られるとユーザーが同意する可能性が高い）のみをリクエストするようにしてください。また、その機能が役に立つ理由がユーザーにとって明白なタイミングで権限をリクエストする必要があります。使用コンテキストをユーザーが簡単に理解できるようにすることが目的です。

Google のユーザー調査によると、サイトがアクセスを求める理由を理解し、メリットがあると認識しているユーザーは、アクセスを許可する可能性が大幅に高くなります。また、アクセスを許可することで得られる価値を理解するために、馴染みのないサイトを事前に調査してみてユーザーがいることもわかっています。多くの場合、ユーザーは権限プロンプトを閉じたり無視したりします。1 回だけのアクセス許可では、最初に 1 回のアクセスを許可する場合があります。アプリはこれらの動作をサポートする必要があります。

同じ機能を実現する代替手段を可能な限り提供する

一部の機能の結果は、ユーザーにとって有益ではない場合があります。たとえば、GPS センサーのないデスクトップデバイスの位置情報は、ユーザーが VPN に接続しているため、間違った位置情報を返すことがあります。他のユーザーは、これらのイベントを自分で制御し、キーの組み合わせで手動でトリガーすることを好むため、クリップボードへのアクセスを許可したくない場合があります。このような状況では、同じ結果を得るために別の手段を用意することが重要です。たとえば、位置情報の権限をリクエストする場合は、ユーザーが郵便番号や住所を入力できるテキストフィールドを用意します。クリップボードを使用する場合は、コピーする要素をキーの組み合わせまたはコンテキストメニューで選択してコピーできることを確認します。通知では、プッシュ通知ではなくメールを受け取るようにユーザーに提示します。

便利なパターンとして、アクセスが有益な理由を説明する際に代替 UI を使用する方法があります。位置情報 API をトリガーするボタンの横に位置情報を入力するオプションが表示されている場合、ユーザーは住所を入力することもできることを理解しているため、何が起こるかを自分でコントロールしていると感じます。同様に、プッシュ通知とメールのどちらで通知を受け取るか、カメラとマイクのアクセスを許可せずに会議に参加するかを選択できる場合、ユーザーはトレードオフをより自然に理解できます。

ブロック状態に陥らないでください。復元は困難です

ユーザーが権限制限付きの機能へのアクセスを完全に許可しないように決定すると、ブラウザはその決定を尊重します。アクセスを要求し続けることができれば、悪質なサイトによってユーザーにプロンプトが次々と届いてしまいます。そのため、機能のブロック状態から復元するには、ユーザーが意図的に少し手間をかけるようにしています。そのため、多くのユーザーがアクセスを許可しない可能性が高い状況では、ユーザーに権限を尋ねないでください。

一般的な方法は、いわゆる事前プロンプトを使用することです。事前プロンプトでは、これから何が起こるか、アプリがリクエストする機能がなぜ必要なのかをユーザーに説明します。ブラウザの権限プロンプトをトリガーするのは、このような事前プロンプトにユーザーが肯定的な反応を示した場合のみです。ユーザーがその状態から復元する必要がある場合もあります。詳しくは、ブロックされた状態からユーザーを復元するをご覧ください。

第三者のコンテンツに注意する

注意が必要な、予期しない権限プロンプトのソースがあります。サイトにサードパーティスクリプトを含めると、表示するつもりのない権限プロンプトがトリガーされることがあります。特に、そのようなプロンプトがすでに概説されているベストプラクティスに従っていない場合、ウェブサイトのユーザーエクスペリエンスに影響する可能性があります。ユーザーエクスペリエンスを常に管理できるように、独自のコードに追加するサードパーティのライブラリとスクリプトのドキュメントをよく読んでください。

権限をリクエストするタイミング

以下に、すでに説明したベストプラクティスに沿って、権限をリクエストするのに適したタイミングの例をいくつか示します。

ユーザーが、住所を手動で入力するためのフォームフィールドの横にある [現在地を使用] ボタンをクリックした後。
ユーザーが動画チャンネルまたは投稿を定期購入した後、更新がメールまたは通知としてスマートフォンやパソコンに配信されることを説明するダイアログで肯定的なボタンをクリックした。
ユーザーがビデオ通話に参加するための準備ページにアクセスし、事前プロンプトで自分の映像と音声を共有することを肯定的に回答した後（Google Meet のケーススタディを参照）。

権限を求めるコードパターン

API の使用許可の取得方法は、API によって異なります。一部の（通常は古い）API では、API を初めて使用しようとしたときにブラウザが自動的に権限を要求するモデルが使用されます。たとえば、Geolocation API で navigator.geolocation.getCurrentPosition() を呼び出す場合です。

try {
  navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
  console.error(error);
}

他の API では、静的メソッドを使用して最初に権限を明示的にリクエストする必要があるモデルが使用されます。たとえば、通知を許可する Notification.requestPermission() や、Device Orientation Events API の一部であるあまり一般的でない DeviceOrientationEvent.requestPermission() などです。一部のブラウザでは、特定の API に対する権限が自動的に付与される場合があります。たとえば、Chrome ではデバイスの向きに常にアクセスできますが、Safari ではプロンプトが表示されます。

const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
  /* Use the API. */
}

権限の状態を確認する方法

特定の API を使用できるかどうかを確認するには、Permissions API の navigator.permissions.query() メソッドを使用します。

const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
  // Use the API.
}

対応ブラウザ

ソース

ブロックされた状態から復元できるようユーザーをサポートする

ユーザーがアクセスの問題をトラブルシューティングできるように、Permissions API を使用してアクセスがブロックされていることを検出し、設定を変更する方法に関するガイドをユーザーに提供します。たとえば、ユーザーが権限制限付きの機能に関連付けられた UI 要素を操作した場合は、前のセクションで説明したパターンを使用して、トラブルシューティングダイアログを開きます。権限の状態を変更する手順はブラウザによって異なるため、ユーザーエージェント文字列と、プロダクトで最もよく使用されるブラウザに基づいて、一致する説明を提供することをおすすめします。

Chrome では、アドレスバーの左側にある [調整] アイコンをクリックして [サイト管理] に移動する必要があります。ここで、それぞれの権限をオンに切り替えることができます。場合によっては、機能を使用する前にページを再読み込みする必要があります。その場合は、ウィンドウの上部にメッセージバーが表示され、該当するボタンをクリックすると再読み込みが提案されます。

Chrome ブラウザのサイト管理。

サイト管理を使用して権限を変更した後の再読み込みプロンプト。

権限を制御するための同様の UI は他のブラウザにも存在します（Firefox での動作をご覧ください）。