JavaScript | Web API：パフォーマンス・セキュリティ － 権限管理設計

「権限管理設計」は“技術”じゃなくて“信頼”の設計

位置情報、カメラ、マイク、通知、センサー、ストレージ…。
Web API の多くは「権限（permission）」をユーザーに確認してから使います。

ここで大事なのは、
「どうやって権限を取るか」よりも
「ユーザーにどう信頼してもらうか」 という視点です。

権限設計が雑だと、
「なんか怖いサイト」「よく分からないけど全部聞いてくるサイト」になります。
逆に、丁寧に設計できると、それだけで“ちゃんとしてるサービス”に見えます。

原則 1: 「必要なときに、必要なものだけ」聞く

まとめて全部聞くのは最悪の UX

よくある悪いパターンは、
ページを開いた瞬間に、いきなり権限ダイアログが連発する設計です。

位置情報も
通知も
カメラも
マイクも

「とりあえず全部許可してね」みたいなやつです。

ユーザーからすると、

何に使うのか分からない
今それが必要なのか分からない
とりあえず「拒否」したくなる

という心理になります。

権限設計の基本は、
「その機能を使う直前に、その機能に必要な権限だけを聞く」 ことです。

位置情報が必要になるのは「近くの店を探すボタン」を押したとき
カメラが必要になるのは「写真を撮るボタン」を押したとき
通知が必要になるのは「通知をオンにする設定」をユーザーが選んだとき

このタイミングで初めて、
ブラウザの権限ダイアログを出すようにします。

例: 位置情報を「ボタンを押したときだけ」聞く

HTML:

<p>
  現在地を使って、近くのカフェを表示できます。<br>
  位置情報はサーバーに保存せず、このページ内だけで利用します。
</p>
<button id="nearCafeBtn">近くのカフェを探す</button>
<p id="message"></p>

JavaScript:

const btn = document.querySelector("#nearCafeBtn");
const message = document.querySelector("#message");

btn.addEventListener("click", () => {
  if (!("geolocation" in navigator)) {
    message.textContent = "このブラウザは位置情報に対応していません。";
    return;
  }

  message.textContent = "ブラウザのダイアログで「許可」を選ぶと、近くのカフェを表示できます。";

  navigator.geolocation.getCurrentPosition(
    (pos) => {
      message.textContent = "現在地を取得しました。カフェを検索中…";
      // 検索処理を書く
    },
    (err) => {
      if (err.code === err.PERMISSION_DENIED) {
        message.textContent = "位置情報の利用が拒否されました。手動でエリアを選択できます。";
      } else {
        message.textContent = "位置情報を取得できませんでした。";
      }
    }
  );
});

const btn = document.querySelector("#nearCafeBtn");
const message = document.querySelector("#message");

btn.addEventListener("click", () => {
  if (!("geolocation" in navigator)) {
    message.textContent = "このブラウザは位置情報に対応していません。";
    return;
  }

  message.textContent = "ブラウザのダイアログで「許可」を選ぶと、近くのカフェを表示できます。";

  navigator.geolocation.getCurrentPosition(
    (pos) => {
      message.textContent = "現在地を取得しました。カフェを検索中…";
      // 検索処理を書く
    },
    (err) => {
      if (err.code === err.PERMISSION_DENIED) {
        message.textContent = "位置情報の利用が拒否されました。手動でエリアを選択できます。";
      } else {
        message.textContent = "位置情報を取得できませんでした。";
      }
    }
  );
});

ここでやっているのは、

ユーザーの操作（ボタン）をきっかけにする
その権限が何に使われるかを事前に説明する
拒否されたときのルートも用意する

という「権限設計の基本形」です。

原則 2: 「用途」と「範囲」を自分の言葉で説明する

ブラウザのダイアログ任せにしない

ブラウザは「位置情報を許可しますか？」と聞いてくれますが、
それだけだとユーザーはこう思います。

何に使うの？
どこまで使われるの？
保存されるの？

だから、アプリ側で先に説明します。

何のために使うのか（例: 近くのカフェを表示するため）
どこまで使うのか（例: このページ内だけで使い、サーバーには保存しない）
いつ使うのか（例: ボタンを押したときだけ）

この 3 つを短く書けると、かなり安心感が出ます。

例: 通知権限を「設定画面」で丁寧に聞く

HTML:

<p>
  お気に入りのカフェのセール情報を通知で受け取ることができます。<br>
  通知は 1 日 1 回までで、いつでもオフにできます。
</p>
<button id="enableNotifyBtn">通知をオンにする</button>
<p id="notifyMessage"></p>

JavaScript:

const btn = document.querySelector("#enableNotifyBtn");
const msg = document.querySelector("#notifyMessage");

btn.addEventListener("click", async () => {
  if (!("Notification" in window)) {
    msg.textContent = "このブラウザは通知に対応していません。";
    return;
  }

  msg.textContent = "ブラウザのダイアログで「許可」を選ぶと、セール情報を通知できます。";

  const result = await Notification.requestPermission();

  if (result === "granted") {
    msg.textContent = "通知が有効になりました。いつでも設定からオフにできます。";
    // 通知登録処理を書く
  } else if (result === "denied") {
    msg.textContent = "通知は拒否されました。後からブラウザの設定で変更できます。";
  } else {
    msg.textContent = "通知の設定は保留されました。";
  }
});

const btn = document.querySelector("#enableNotifyBtn");
const msg = document.querySelector("#notifyMessage");

btn.addEventListener("click", async () => {
  if (!("Notification" in window)) {
    msg.textContent = "このブラウザは通知に対応していません。";
    return;
  }

  msg.textContent = "ブラウザのダイアログで「許可」を選ぶと、セール情報を通知できます。";

  const result = await Notification.requestPermission();

  if (result === "granted") {
    msg.textContent = "通知が有効になりました。いつでも設定からオフにできます。";
    // 通知登録処理を書く
  } else if (result === "denied") {
    msg.textContent = "通知は拒否されました。後からブラウザの設定で変更できます。";
  } else {
    msg.textContent = "通知の設定は保留されました。";
  }
});

ここで大事なのは、
「ユーザーの不安を先回りして潰す説明」 を入れていることです。

頻度（どれくらいの頻度で通知するか）
取り消し可能性（いつでもオフにできるか）

このあたりを書いておくと、
「一度許可したら終わりではない」と伝わって、心理的ハードルが下がります。

原則 3: 「拒否されても成立する」設計にする

権限は“取れたらラッキー”くらいの気持ちで設計する

権限は、拒否されるのが普通です。
「拒否されたら何もできません」は、設計として弱いです。

位置情報が拒否されたら、エリアを手動選択させる
カメラが拒否されたら、画像アップロードで代替する
通知が拒否されたら、メールやページ内のバッジで知らせる

こういう「代替ルート」を用意しておくと、
権限を取れなくてもサービスとして成立します。

例: 位置情報がなくても検索できる UI

HTML:

<p>
  現在地を使って近くのカフェを探すか、エリアを選択してください。
</p>
<button id="useLocationBtn">現在地で探す</button>

<select id="areaSelect">
  <option value="">エリアを選択</option>
  <option value="shinjuku">新宿</option>
  <option value="shibuya">渋谷</option>
</select>
<button id="searchByAreaBtn">エリアで探す</button>

<p id="result"></p>

JavaScript（位置情報部分だけ抜粋）:

useLocationBtn.addEventListener("click", () => {
  if (!("geolocation" in navigator)) {
    result.textContent = "位置情報に対応していません。エリアを選択してください。";
    return;
  }

  navigator.geolocation.getCurrentPosition(
    (pos) => {
      // 現在地で検索
    },
    (err) => {
      if (err.code === err.PERMISSION_DENIED) {
        result.textContent = "位置情報は拒否されました。エリアを選択して検索できます。";
      } else {
        result.textContent = "位置情報を取得できませんでした。エリアを選択してください。";
      }
    }
  );
});

useLocationBtn.addEventListener("click", () => {
  if (!("geolocation" in navigator)) {
    result.textContent = "位置情報に対応していません。エリアを選択してください。";
    return;
  }

  navigator.geolocation.getCurrentPosition(
    (pos) => {
      // 現在地で検索
    },
    (err) => {
      if (err.code === err.PERMISSION_DENIED) {
        result.textContent = "位置情報は拒否されました。エリアを選択して検索できます。";
      } else {
        result.textContent = "位置情報を取得できませんでした。エリアを選択してください。";
      }
    }
  );
});

ここでのポイントは、
「拒否されたときのメッセージが“行き止まり”になっていない」 ことです。

「ダメでした」で終わらせず、
「だからこうしてください」と次の行動を提示します。

原則 4: 「権限の状態」をちゃんと把握して、無駄に聞かない

Permissions API で状態を確認する

ブラウザには navigator.permissions という API があり、
一部の権限について「状態」を確認できます。

状態は大きく分けて 3 つです。

granted（許可済み）
denied（拒否済み）
prompt（まだ聞いていない／毎回聞く）

例えば、通知の状態を確認するコードはこうです。

if ("permissions" in navigator) {
  navigator.permissions
    .query({ name: "notifications" })
    .then((status) => {
      console.log("通知の状態:", status.state);
    });
}

if ("permissions" in navigator) {
  navigator.permissions
    .query({ name: "notifications" })
    .then((status) => {
      console.log("通知の状態:", status.state);
    });
}

これを使うと、

すでに denied なのに、何度もダイアログを出そうとする
すでに granted なのに、毎回「許可してください」と説明する

といった「しつこい・無駄な挙動」を避けられます。

状態に応じて UI を変える

例えば、通知の設定画面でこういう分岐ができます。

granted のとき
「通知はオンです。ブラウザの設定からいつでもオフにできます。」

denied のとき
「通知はブラウザ側で拒否されています。変更するにはブラウザの設定を開いてください。」

prompt のとき
「通知をオンにできます。ボタンを押すとブラウザのダイアログが表示されます。」

これをコードにすると、イメージはこんな感じです。

async function setupNotificationUI() {
  const msg = document.querySelector("#notifyState");

  if (!("Notification" in window)) {
    msg.textContent = "このブラウザは通知に対応していません。";
    return;
  }

  if (!("permissions" in navigator)) {
    msg.textContent = "通知の状態を確認できませんが、ボタンから設定できます。";
    return;
  }

  const status = await navigator.permissions.query({ name: "notifications" });

  if (status.state === "granted") {
    msg.textContent = "通知はオンになっています。ブラウザの設定から変更できます。";
  } else if (status.state === "denied") {
    msg.textContent = "通知はブラウザで拒否されています。設定から変更できます。";
  } else {
    msg.textContent = "通知をオンにできます。ボタンを押すと確認ダイアログが表示されます。";
  }
}

async function setupNotificationUI() {
  const msg = document.querySelector("#notifyState");

  if (!("Notification" in window)) {
    msg.textContent = "このブラウザは通知に対応していません。";
    return;
  }

  if (!("permissions" in navigator)) {
    msg.textContent = "通知の状態を確認できませんが、ボタンから設定できます。";
    return;
  }

  const status = await navigator.permissions.query({ name: "notifications" });

  if (status.state === "granted") {
    msg.textContent = "通知はオンになっています。ブラウザの設定から変更できます。";
  } else if (status.state === "denied") {
    msg.textContent = "通知はブラウザで拒否されています。設定から変更できます。";
  } else {
    msg.textContent = "通知をオンにできます。ボタンを押すと確認ダイアログが表示されます。";
  }
}

こうやって、
「今どういう状態なのか」をユーザーと共有する のも、権限設計の一部です。

原則 5: 「権限を前提にしない」アーキテクチャにする

権限がなくても“壊れない”コードを書く

権限設計で一番やってはいけないのは、
「権限がないとコードが例外で落ちる」状態です。

例えば、位置情報 API がない環境で
いきなり navigator.geolocation.getCurrentPosition を呼ぶと、
エラーになるブラウザもあります。

なので、必ず存在チェックを挟みます。

if (!("geolocation" in navigator)) {
  // 非対応のときの処理
} else {
  // 対応しているときだけ呼ぶ
}

if (!("geolocation" in navigator)) {
  // 非対応のときの処理
} else {
  // 対応しているときだけ呼ぶ
}

同じように、
Notification や navigator.permissions も
存在チェックをしてから使うのが基本です。

権限がない
API 自体がない
ユーザーが拒否した

こういう状況を全部「普通のケース」として扱い、
「そのときどう振る舞うか」を先に決めておく のが、権限管理設計です。

初心者として「権限管理設計」で掴んでほしい感覚

権限管理は、API の使い方を覚えることよりも、
ユーザーとの関係性をどう設計するか、という話に近いです。

必要なときに、必要な権限だけを聞く
用途・範囲・頻度を短く説明してからダイアログを出す
拒否されても成立する UI・フローを用意する
Permissions API などで状態を把握し、無駄に聞かない
権限や API を前提にせず、「ない世界」も普通に動くようにする

あなたがコードを書くときに、
「この権限、本当に今必要？」「拒否されたらどうする？」
と一度でも自問できるようになったら、
それはもう“ただ API を叩く人”から
“権限を設計できるエンジニア”に一歩踏み出しています。