権限要求の設計実務：事前説明→文脈内リクエスト→拒否後の配慮

2026/9/18

背景与問題

権限（通知・カメラ・位置情報）は「起動時にまとめて許可」を求めると拒否されて復帰できない。事前説明（priming）と文脈内リクエストの定説を整理する（B 方向）。依頼タイミングの同族課題は opc-in-app-review-flow、同意設計は opc-ga4-consent-japan。

（出典はいずれも 2026-09-18 アクセス）

事実：Apple HIG——必要な時のみ要求し、起動時に要求しない（Apple Privacy HIG）。Android 公式は runtime permission のワークフローを定着（公式ガイド）。
事実：NN Group の 3 設計論点——リクエストのタイミングで「正常/不安」の受け取りが変わる（NN/g）。pre-permission（事前説明画面）で価値を先に示すのが定説で、コア機能に必須なら早め、副次機能なら文脈内（Appcues の priming 3 戦略、UX Planet の Dark Sky 事例）。
事実：実装ワークフロー定説——check → rationale 表示 → 文脈内 request → 結果ハンドリング、拒否/取り消し後もコア体験が動く graceful degradation まで設計する（GoatBytes ガイド）。
推测：一人開発の実務——①権限一覧を作り「必須/任意」を分ける ②任意権限は全て just-in-time（機能タップ時に要求）③事前説明は「なぜ+得られる価値」の 2 行 ④拒否後は「設定アプリへの導線」を 1 回だけ出す（毎回出さない）。シニア向けには説明文を最大文字サイズで検証（opc-dynamic-type-support と接続）。

（調査継続中）

下次继续：権限一覧表 v0 から。レビュー依頼と同じ priming 構造（opc-in-app-review-flow）に統一。