AIがユーザーに連絡するタイミングと頻度をユーザー自身が選べるようにする方法
ユーザーは、AIから連絡を受け取るかどうか、どのような種類のメッセージを受信するか、そしてそれらのメッセージがいつ届くかを自分で決定できるべきです。使いやすい設計は、明示的なオプトインから始まり、ユーザーがスケジュールと頻度を設定できるようにし、本質的に異なるメッセージタイプを明確に区別し、一時停止やオフの設定を簡単に見つけられるようにします。また、選択されたタイムゾーンや、配信に影響を与える可能性のある要素についても説明します。これらの設定機能は明確な約束を交わすものであり、製品のスケジューリングおよび配信システムはそれを確実に遵守できなければなりません。
明確かつ任意（オプトイン）の選択から始める
何に同意しているのかをユーザーが理解できるタイミングで許可を求めてください。連絡の種類は、わかりやすい言葉で説明します（例：ユーザーがリクエストしたリマインダーや定期的なアップデートなど）。どこに届くのか、どのくらいの頻度で送信される可能性があるのかを明記してください。OS標準のパーミッション通知のみを説明代わりに使うのは避けてください。ユーザーは決定を下す前に、アプリが何を送信しようとしているのかを知る必要があります。
U.S. Web Design System（米国ウェブデザインシステム）は、サービスが実際にサポートできるチャネルについてのみ連絡の希望設定を収集し、可能であれば連絡の条件や予想されるタイムラインを説明することを推奨しています。これをAI製品に適用すると、実際に利用可能な配信オプションのみを表示し、それぞれの目的を明記することを意味します。通知の設定を、無関係な機能を利用するための条件にしてはいけません。USWDS: Contact preferences
オプトインは、ユーザーがいつでも見直せる選択肢として扱ってください。Appleの通知ガイダンスでは、通知タイプごとの明確なオプトインまたはオプトアウトと、アプリ内で通知設定を管理する方法を提供することを推奨しています。製品は、アプリ独自のスケジュールを把握するために無関係な端末の設定を探し回らせるのではなく、現在の選択内容をまとめた設定ページを用意することで、この原則に従うことができます。Apple: Managing notifications
スケジュールを具体的にする
平日の午後6時から8時の間や、特定の曜日の定期的な時間帯など、自分のルーティンに合った時間枠をユーザーが選べるようにします。曜日と開始・終了時間はセットで表示してください。コントロールが「連絡時間枠」を設定するものである場合は、その時間内の任意のタイミングで届くのか、特定の時間に届くのかを説明します。特定の日に送信対象となるメッセージがない場合、システムがその日をスキップするのか、メッセージを次回へ繰り越すのかを明記してください。
実用的なデザインとしては、「週に1回」や「平日」といった分かりやすいプリセットをいくつか用意しつつ、製品が対応している場合はカスタムスケジュールも設定できるようにするとよいでしょう。プリセットは曖昧なラベルではなく、具体的なスケジュールとして表示されるべきです。たとえば、「毎週」であれば選択された曜日と時間を表示し、「週に最大3回」であれば、3回が上限なのか目標なのかを明記する必要があります。これはデザイン上の推奨事項です。プラットフォームのドキュメントはスケジュール配信をサポートしていますが、独自の送信ルールを決定し説明するのは製品チームの責任です。
タイムゾーンは正確に扱ってください。スケジュールには、特定の地域名またはデバイスの現在のローカルタイムゾーンを明記し、旅行時にスケジュールが現在地に合わせて移動するのか、元のタイムゾーンに固定されたままになるのかをユーザーに伝えます。単なるUTCオフセットの表記は、夏時間のルールや各国のタイムゾーン規制が変更された場合に誤解を招く可能性があります。IANAのタイムゾーンデータベースは地域のルールを記録しており、オフセットや夏時間の変更を含む各国の政策決定を反映して更新されています。IANA: Time Zone Database
適切な確認表示の例としては、「現在の現地時間で毎週火曜日の午後7:00。このスケジュールはお使いの端末のタイムゾーンに追従します」といったものが挙げられます。この文言は、実装が実際にユーザーの現在のタイムゾーンを追跡している場合にのみ正確となります。スケジュールが選択したタイムゾーンに固定されたままである場合は、代わりにその地域名を明記してください。ユーザーが移動したり、端末のタイムゾーンが変更されたりした場合は、適用されている有効なスケジュールを表示し、それを見直す手段を提供してください。
メッセージの種類とチャネルを分ける
ユーザーはある種類の連絡は欲しくても、別の種類は不要だと考える場合があります。任意のリマインダー、製品アップデート、その他の異なるカテゴリをひとまとめの「AI通知」スイッチに束ねるのではなく、別々に選択できるようにしてください。製品の実際の動作に対応していないカテゴリを捏造したり、ユーザーが選択していないメッセージを送信するための口実としてカテゴリを作成したりしてはいけません。
この分離は、プラットフォーム側の設定管理とも合致しています。現代のAndroidバージョンでは通知をチャンネルに割り当てることが必須となっており、ユーザーはチャンネルの動作を変更できます。Androidのガイダンスでも、受信する通知をユーザーがカスタマイズできるチャンネル構成を推奨しています。アプリは、「スケジュールされたリマインダー」など、ユーザーが認識しやすい言葉でチャンネルに名前を付け、それぞれに何が含まれるかを説明できます。Android Developers: Create and manage notification channels
チャンネルのリストは、把握しやすいように短く保ちます。1つのチャンネルは、ユーザーが個別に判断したいと思える有意義な選択肢を表すべきです。製品自体の設定画面でも、内容とスケジュールを説明し続ける必要があります。OSのチャンネル設定は通知の表示有無や表示方法を変更することはできますが、アプリの送信ポリシーを説明したり、製品内のスケジュール設定に代わるものではありません。
一時停止、再開、オフのコントロールをすぐ手の届く場所に置く
一時停止と恒久的なオフのスイッチの両方を提供してください。一時停止は、指定した日まで、あるいはユーザーが再開するまでといった期間を明示し、スケジュールされたメッセージがスキップされるのか保留されるのかを示す必要があります。オフのコントロールは、どのカテゴリやチャネルに影響するかを明記し、変更された状態を即座に確認できるようにしてください。再開する際は、次に何が起こるかを示さずに以前のスケジュールを黙って復元してはなりません。
これらのコントロールは、通知設定画面から利用できるようにし、可能な場合は通知のアクションや直接の設定リンクからもアクセスできるようにします。Androidは通知内のアクションをサポートしており、ユーザーに将来の通知を管理するためのシステムレベルの方法を提供しています。そのコントロールは端末やAndroidのバージョンによって異なります。したがって、完全なスケジュールを表示し、製品レベルの設定を変更するためのアプリ内ルートは引き続き有用です。Android Developers: Notifications
端末レベルの設定も依然として重要です。ユーザーはアプリ独自のスケジュールとは無関係に、OSレベルでアプリの通知をオフにしたり、チャンネルの動作を変更したりできます。インターフェースは、アプリ内の設定がそれらの選択を上書きするかのように示唆してはなりません。システムの通知が無効になっている場合は、ユーザーが設定画面を開いたときに明確なステータスを表示し、通知を再度有効にするよう繰り返し促すことは避けてください。
システムが適用できる頻度制限を設定する
最大で1日1通、週あたりの上限、あるいはユーザーが選択した日数など、明確な頻度の選択肢をユーザーに提供します。カウント期間と、何をもって1通のメッセージとするのかを定義してください。複数のカテゴリからメッセージが送信される可能性がある場合は、制限がカテゴリごとに適用されるのか、製品全体に適用されるのかを明確にします。カテゴリごとの制限では全体の配信数が多くなってしまう可能性があるため、優れた設計には全体の上限も含まれることがよくあります。
上限設定は、すべての送信経路がそれを遵守して初めて機能します。スケジュールされたリマインダー、再試行、遅延メッセージ、および異なる機能によって開始されたメッセージを、すべて同一の設定状態に照らしてチェックしてください。メッセージが遅延した場合、有効期限切れにするのか、許可された時間枠内で後から届けるのか、それとも破棄するのかを決定し、ユーザーにとって重要な挙動を説明します。端末が再接続された際に、ユーザーが明示的にその動作を選択していない限り、見逃した複数のメッセージを一度に送信することは避けてください。
プラットフォームの配信機能は、製品の送信判断と同じではありません。Firebase Cloud Messagingによると、メッセージは通常すぐに配信されますが、デバイスが利用できない場合や配信が遅れる場合があり、サービスは設定された有効期間内であればメッセージを保存して後から配信を試みることができます。つまり、製品はすべての通知が正確な分単位で表示されると約束すべきではありません。指定された時間枠内での送信をスケジュールすることは約束できますが、端末やプラットフォームの状況によって表示されるタイミングが影響を受ける可能性があることを説明すべきです。Firebase: Set the lifespan of a message
この違いは頻度にも影響します。通知がキューに入れられて遅れて到着した場合、システムはユーザーがその後そのカテゴリを一時停止またはオフにしていないか、また送信によって現在の上限を超えないかを再確認する必要があります。誠実な設計では、ユーザーの最新の選択によって不適格となった場合、キューに入っている古いメッセージをキャンセルまたは抑制します。
設計のためのシンプルな意思決定手順
設定画面をユーザーに理解しやすい約束事にするために、次の手順を活用してください：
製品が実際に送信できるメッセージの種類を特定し、選択可能な各カテゴリをわかりやすくします。
希望する各カテゴリと配信チャネルについて、ユーザーにオプトインを求めます。任意の連絡をあらかじめ選択状態にしてはいけません。
曜日、時間または時間枠、および最大頻度をユーザーが選択できるようにします。上限が全体的なものか、カテゴリごとのものかを明記してください。
タイムゾーンを表示し、端末のゾーンが変更されたときにスケジュールがユーザーに追従するかどうかを明示します。
一時停止、再開、オフのコントロールを見えやすい場所に配置し、現在のステータスと次の連絡可能時間を表示します。
配信前に、スケジュール、上限、一時停止ステータス、カテゴリの設定を再確認します。端末への配信は遅延する可能性があるものとして扱い、製品がコントロールできる範囲の言葉で約束内容を説明してください。
簡潔な設定概要を用意すると、取り決めを簡単に確認できるようになります：「スケジュールされたリマインダー：オン。現地時間の火曜日と木曜日、午後7時〜8時。上限：すべてのカテゴリを合わせて週に2回まで。いつでも一時停止またはオフにできます。」正確な選択肢は実際の機能を反映している必要があります。製品が表示された上限を強制できなかったり、現地時間を確実に追従できなかったりする場合は、そのコントロールを提示する前に実装を変更するか、説明する内容を絞り込むべきです。