Google Stitch でパーミッション・同意ダイアログを設計した——「お願い」するUIがいかに難しいか

2026.04.16

アプリを使い始めたとき、「通知を許可しますか？」「位置情報へのアクセスを許可しますか？」というダイアログが突然現れる——そんな体験を誰もが持っているはずだ。

私はずっと、そのダイアログを「仕方なくOSが出すもの」として受け身に捉えていた。設計者としてではなく、一ユーザーとして。

Google Stitch でパーミッションダイアログを設計することになったとき、初めてその難しさと向き合った。

「許可してください」とお願いするUIは、ユーザーの自由な意思決定を尊重しながら、プロダクトにとって必要な情報を得なければならない。その二つのことを、たった1枚の画面でやりとげなければならない。

それは、思っていた以上に繊細な設計問題だった。

結論から言うと——パーミッション・同意ダイアログの設計で最も重要なのは「タイミング」と「理由の説明」だ。「許可」を求める前に「なぜ必要か」を丁寧に説明し、ユーザーが判断しやすい文脈を作ることが、許可率と信頼感を両立させる鍵になる。

パーミッションダイアログとは何か

パーミッション（許可）ダイアログとは、アプリがユーザーのデバイス機能（カメラ・マイク・位置情報・通知など）にアクセスする際、または個人情報を利用する際にユーザーの同意を求めるUIのことです。iOS・Android では OS レベルで表示されるシステムダイアログと、その前段として表示されるアプリ独自の「プレパーミッション画面」の2段階設計が一般的です。

また、Webサービスにおける Cookie 同意バナー（GDPR対応）や、データ利用同意画面なども広義のパーミッションUIに含まれます。

なぜパーミッション設計が難しいのか

パーミッションダイアログの設計が難しい理由は、複数の相反する要求が同時に存在するからだ。

プロダクト側の要求：できる限り「許可」を得たい
ユーザー側の要求：不必要なアクセスを避けたい / 何に使われるかわかってから判断したい
法的・倫理的要求：ユーザーの自由な意思決定を妨げてはならない

この三つを同時に満たすUIを設計しなければならない。「許可させる」ための強引なUIは短期的には許可率を上げても、長期的にはユーザーの信頼を損なう。

「プレパーミッション」の考え方

iOS や Android では、一度「拒否」されたパーミッション要求はOSのダイアログを再表示できない（ユーザーが設定から手動で変更するしかない）。

この制約があるため、モバイルアプリ設計では「システムダイアログの前に、アプリ独自のプレパーミッション画面を表示する」というパターンが広く使われている。プレパーミッション画面で「なぜこの許可が必要か」を説明してから、ユーザーが「OK」を押した後に初めてシステムダイアログを表示する。

プレパーミッション画面があることで、理解した上で判断したユーザーだけがシステムダイアログまで到達するため、拒否率が下がる。

Stitch でパーミッションUIを設計した体験

通知許可を求めるプレパーミッション画面をStitchで設計しようとして、最初に書いたプロンプトは「通知許可を求めるダイアログを作って」というものだった。

出てきたのは、「通知を許可しますか？」という見出しと「許可する」「あとで」の2つのボタンがあるシンプルなモーダルだった。

見た目は悪くない。でも、「何のために通知が必要なのか」が書いていなかった。ユーザーがこれを見て「許可しよう」と思う理由が、何もなかった。

「許可の理由」を丁寧に説明する設計

プロンプトを書き直した。「通知許可を求めるプレパーミッション画面。画面の構成：①通知アイコン（上部）、②見出し「大切なお知らせを見逃さないために」、③説明テキスト「支払い確認・残高アラート・お得な情報をお届けします。通知はいつでも設定から変更できます」、④「通知を許可する」ボタン（主）、⑤「あとで設定する」テキストリンク（従）。温かみのある配色、モバイル向け。」

今度出てきた画面は、最初のものとはまるで別物だった。ユーザーが「なぜこの許可が必要か」を理解した上で判断できる、丁寧な設計になっていた。

実際に使ってみてわかったのは、プレパーミッション画面で最も重要なのは「許可のメリット」と「後から変更できること」の2点を明示することだということだ。

「断る選択肢」をどう設計するか

パーミッション設計で最も悩んだのが、「拒否ボタン」の扱いだった。

プロダクト視点では「拒否ボタンを目立たせたくない」という気持ちがある。でも「拒否しにくいUI」はユーザーの自由な意思決定を妨げ、法的リスクにもなりうる（特にGDPR/個人情報保護法の観点から）。

Stitch で複数パターンを生成して比較した：

パターンA：「許可する」ボタン（大・主）+「許可しない」ボタン（小・従）
パターンB：「許可する」ボタン（大・主）+「あとで」テキストリンク
パターンC：「許可する」「許可しない」が同じサイズで並ぶ対等デザイン

法的観点と信頼感の観点では、パターンCが最も問題が少ない。ユーザーの選択の自由が視覚的に担保されている。一方でプロダクトの許可率を考えるとパターンAが高くなりやすい。

最終的に選んだのはパターンBに近い形——「許可する」ボタンは大きく、「あとで設定する」はテキストリンクで目立たせすぎないが存在を明示する——という設計だった。

Cookie同意バナーの設計

Webサービスで避けられないのが、Cookie同意バナーの設計だ。GDPRや日本の個人情報保護法の改正によって、多くのWebサービスがCookie同意UIを設計しなければならなくなっている。

同意バナーで守るべき原則

Cookie同意バナーの設計には法的な制約が伴う。特に以下の点は重要だ：

「同意する」と「拒否する」（または「必要なもののみ許可する」）が同等に選択しやすいデザインであること
「×で閉じる＝同意」という設計は多くの規制において問題とされている
「詳細設定」へのアクセスが明確に提供されていること

Stitch でこれを生成するとき、「Cookie同意バナー。必須Cookieのみ許可するボタンと、すべて許可するボタンを視覚的に対等な大きさで表示。詳細設定リンクも明示する。画面下部固定バナー形式。」というプロンプトが有効だった。

「信頼を壊さない」デザインの基準

パーミッション・同意UIの最終的な基準は「このUIを見たユーザーが、このプロダクトを信頼できると感じるか」だと思っている。

その基準で生成された画面を評価すると、「強引に許可させようとしている」「拒否を難しくしている」「何に同意しているかがわかりにくい」という問題点が浮かびやすくなる。

よくある失敗と対処法

失敗1：理由なく許可を求める——「通知を許可しますか？」だけでは、ユーザーが判断する材料がない。「何の通知か」「どのくらいの頻度か」「いつでも変更できるか」を必ず明示しましょう。
失敗2：タイミングが早すぎる——アプリを初めて開いた直後に複数のパーミッションを求めるのは離脱率を高めます。ユーザーがアプリの価値を体験した後、その機能が実際に必要になった瞬間に要求するのが最も効果的です。
失敗3：「許可しない」選択肢を見えにくくする——法的リスクに加え、ユーザーの信頼を損ないます。「あとで」「スキップ」など、拒否に近い選択肢は存在を明示しましょう。
失敗4：複数の許可を一度に求める——「カメラ・マイク・位置情報をすべて許可してください」という画面は、ユーザーに「監視されている」という印象を与えます。1つの機能が必要になった時点で、その1つだけを求めましょう。
失敗5：拒否後のフォローがない——許可を拒否したユーザーに対して、その機能が使えない旨と「設定から変更できます」という案内を必ず表示しましょう。拒否後に何の案内もないと、ユーザーは機能が使えない理由すらわからなくなります。

よくある質問（FAQ）

Q. Google Stitch でプレパーミッション画面とシステムダイアログをセットで設計できますか？

A. システムダイアログ（OSのネイティブUI）は実際のOS表示と完全に同一にはなりませんが、Stitch で「iOS/Androidのシステムパーミッションダイアログのモックアップ」を生成することは可能です。プロンプトに「iOSのネイティブ通知許可ダイアログのデザインで」と指示すると、OSのスタイルに近いUIが生成されます。ただし実際の見た目はOSバージョンによって異なるため、参考デザインとして使いましょう。

Q. GDPRに準拠したCookie同意バナーをStitchで設計するときの注意点は何ですか？

A. GDPR準拠のCookie同意バナーには「同意と拒否が対等に選択できること」「同意前に個人データを処理しないこと」「詳細設定へのアクセスを提供すること」という原則があります。Stitch で設計するとき、「同意する」と「拒否する」を同サイズで表示し、「詳細設定」リンクを明示するプロンプトを書きましょう。ただし法的要件は地域・業種によって異なるため、法律の専門家への確認を推奨します。

Q. パーミッション許可率を高めるために、Stitch でどんな設計が有効ですか？

A. 許可率を高めつつ信頼を損なわない方法として有効なのは、①機能を使う直前のコンテキストでパーミッションを求める（contextual permission）、②許可のメリットを具体的に1〜2文で説明する、③「あとで変更できる」ことを明示する——の3点です。Stitch のプロンプトにこれらを含めることで、コンバージョンと信頼性を両立した設計ができます。

Q. プライバシーポリシーへのリンクはパーミッション画面に必ず入れるべきですか？

A. 個人情報の利用を伴うパーミッションの場合は、プライバシーポリシーへのリンクを含めることが強く推奨されます（法的義務となる場合もあります）。Stitch で設計する際は「画面下部に12pxのグレーテキストでプライバシーポリシーへのリンクを表示」という指示を加えましょう。

Q. 同意ダイアログの「文章（コピー）」はStitchが自動生成してくれますか？

A. はい。Stitch はUIレイアウトと同時にコピーテキストも生成します。パーミッションの種類（通知・位置情報・カメラなど）と対象ユーザーをプロンプトに明示すると、その文脈に合ったコピーが生成されます。ただし日本語コピーの品質にはばらつきがあるため、生成されたテキストは必ず確認・修正してください。特に法的リスクのある文章（個人情報の利用目的など）は、法務部門や専門家のレビューを受けることを推奨します。