自発的なAIメッセージ機能を構築する前に、「ノー」の声に耳を傾ける
AIが自律的に会話を始める機能の導入を検討しているなら、まずは人々が「何も言われたくない」と思う場面を突き止めてください。想定されるユーザーをリサーチインタビューに任意参加の形で招待し、求めていないメッセージが歓迎されない日常の瞬間について尋ね、設定を元に戻せるプロトタイプを使ってメッセージのコンセプトを検証しましょう。明確な「連絡しないでほしい」という意思表示は、乗り越えるべき反論ではなく、理解し尊重すべき製品要件として捉えてください。目標は、人々がどのような連絡であれば歓迎することを選ぶのか（あるいは一切歓迎しないのか）を明らかにすることです。
機能の背後にある問いから始める
AIを「よりプロアクティブ（自発的）にする」という提案の裏には、リマインダー、提案、状況確認、あるいはルーティンに紐づいたメッセージなど、いくつもの異なるアイデアが隠れている場合があります。これらはまったく異なる体験です。リクルーティングを始める前に、想定される具体的な挙動を平易な言葉で書き出してください。何がメッセージ送信のきっかけとなるのか、どのような文面なのか、そしてユーザーはそれをどこで目にするのか。これにより、その機能がすでに存在するかのように見せかけることなく、参加者に具体的な反応を示してもらう材料を提供できます。
調査の問いはオープンにしておきましょう。たとえば、「どのような状況であれば、この種のメッセージを受け取りたいと思いますか？ また、どのような状況では受け取りたくないですか？」といった形です。そのアイデアが好きかどうかや、どのくらいの頻度でメッセージが欲しいかだけを尋ねるのは避けてください。大まかな肯定的な回答は、重要な境界線を覆い隠してしまうことがあります。たとえば、料理中のちょっとした通知は歓迎しても、仕事中や移動中、他の人と過ごしている時間は静かにしていてほしい、といったケースです。これらは発見のための問いかけであり、ユーザーがこう答えるはずだという主張ではありません。
設計している体験の実際のユーザー、または利用が見込まれるユーザーをリクルーティングし、参加に同意してもらう前に招待内容を明確に説明してください。GOV.UKのユーザーリサーチガイダンスでは、目的とアクティビティを明確にし、参加を任意とし、中断や同意撤回の権利を明示することを推奨しています。また、参加者が事前に準備し、安心して参加できるかを判断できるように、前もって情報を提供することも推奨されています（Getting informed consent for user research、Finding participants for user research）。
単なる好みではなく、状況について尋ねる
短いインタビューでは、最近の日常的な具体例から始めましょう。普段どのようなデジタルメッセージに気づくか、どんなときに好意的に受け取る傾向があるか、そして無視したり消去したりするときには何が起きているかを尋ねます。次に、時間帯、何をしているか、自分から始めた行動かどうか、近くに他の人がいるかといったコンテキスト（文脈・状況）を掘り下げます。参加者に抽象的な理想を予測させるのではなく、観察可能なルーティンや選択に焦点を当てて議論を進めてください。
中立的で役に立つ質問の例には、「最近、忙しいときにアプリから連絡が届いたときのことを教えてください」「その瞬間にこのようなメッセージが役に立つとしたら、どのような点ですか？」「この機能に静かにしていてほしいと感じる場面はありますか？」などがあります。続けて「その状況の何が他と違っているのでしょうか？」と尋ねます。参加者が境界線を自ら定義できるよう、十分な間を持たせてください。彼らが口にしていない理由で沈黙を埋めたり、「はい」を望ましい回答として誘導したりしてはいけません。
連絡の形式ごとに分けて尋ねてください。ある機能の利用中にアプリ内で短い提案が表示されるのは構わないが、アプリを閉じているときにプッシュ通知が来るのは嫌だと感じる人もいます。特定のアクティビティにオプトインした後に限ってメッセージを希望する人もいれば、自発的なメッセージは一切不要だという人もいるでしょう。Appleの通知に関するドキュメントでも、これに関連するプロダクト上の区別がなされています。通知の許可は目的が理解できる状況で求めるよう推奨されており、通知が邪魔になる可能性があることも説明されています（Asking permission to use notifications）。プラットフォームのガイドラインは、あなたのプロダクトのユーザーが何を好むかを決定づけるものではありません。インタビューを通じて、彼ら自身の言葉と状況を明らかにすべきです。
リサーチへの招待を真に任意のものにする
リサーチへの参加案内は、調査対象となっているプロアクティブ機能のような形式にしてはいけません。セッションが調査目的であること、参加者に何をしてもらうか、どのような情報を収集するか、そして調査結果がどのように使われるかを明記してください。同意は率直に求めましょう。通常の体験へのアクセスを損なうことなく、簡単に辞退できるようにします。個人情報の収集に関するGOV.UKのガイダンスでは、直接的で明確な選択肢を提示し、拒否したことによってサービスの利用が妨げられてはならないと定められています（Collecting personal information from users）。
メモを取ったり録音・録画を行ったりする前に、それらの選択肢を説明し、具体的な記録方法について同意を得てください。インタビューには同意しても、録音は断る参加者もいます。質問をスキップできること、一時停止や中断ができることを明確に伝えてください。GOV.UKのガイダンスでは、メモや録音・録画を行う前にインフォームドコンセントを得ること、そして合意された用途のみに使用することを推奨しています（Taking notes and recording user research sessions）。
終了時には、記録された内容に問題がないか確認し、後から選択を見直したい場合の連絡方法を伝えてください。メモはデザイン上の問いに焦点を絞り、不要な個人情報の収集は避けます。リサーチチームの目的は、参加者を説得して機能を受け入れさせることではなく、連絡に関する好みを理解することであると説明してください。
元に戻せるプロトタイプでアイデアを検証する
インタビューの後、浮かび上がってきた利用状況をいくつかのメッセージコンセプトへと落とし込みます。日常的な活動に紐づいた中立的な例を用い、文面だけでなく、トリガーと配信されるコンテキストを提示してください。メッセージは単なる文章ではありません。利用中に届くのか、後から表示されるのか、あるいはプロダクトの外で届くのかを参加者が知る必要があります。実際の機能と誤解されないよう、コンセプトにはプロトタイプであることを明確に表示してください。
参加者には、「この例を表示する」「このアクティビティで試す」「プロアクティブなメッセージは不要」といった、元に戻せる選択肢を試してもらいます。プロトタイプが通知をシミュレートする場合は、試用を停止する方法を示し、停止が確実に機能することを確認してください。参加者がその特定のテストに明示的に同意していない限り、テストの一環として実際のメッセージを送信してはいけません。継続的な設定に縛られることなく体験を評価できるよう、試用期間は十分に短く設定してください。
回答だけでなく行動も観察します。参加者はその例を有効にすることを選ぶか、無視するか、提案された条件を変更するか、それともオフにするでしょうか？ 各操作がどのような動作をすると予想したか尋ねてください。これは応用的なリサーチ手法であり、特定のコントロールがあらゆる製品に適していることを証明するものではありません。核心となる検証項目は、参加者がその選択を理解し、ストレスなく元に戻せるかどうかです。
拒否の意思表示を、実行可能な境界線として記録する
「ノー」と言うことの意味は様々です。ある特定のタイミング、特定のメッセージタイプ、特定のアクティビティを拒否している場合もあれば、あらゆる自発的な連絡を拒否している場合もあります。その境界線と前後の状況を、参加者自身の言葉で記録してください。状況と選択ごとに知見を整理すると効果的です。たとえば「選んだアクティビティ内なら歓迎」「限られた状況でのみ許容」「明確に不要」などです。「連絡不要」という結果を「時々のメッセージを好む」という大まかな傾向の中に埋もれさせず、独立した知見として可視化しておきましょう。
ユーザーが発言した事実と、自分たちの解釈を明確に区別してください。たとえば、「参加者はアクティブなセッション外でのメッセージを拒否した」は客観的事実の観察ですが、「セッション中のみのオプションが必要かもしれない」はデザイン上の推論です。不確実性もそのまま記録してください。1回のインタビューで潜在的な境界線を特定することはできますが、その傾向が対象ユーザー全体でどの程度一般的なものかを確立することはできません。
得られた知見を活用して、その機能を開発すべきかどうか、そしてデザインにどのような選択肢を用意しなければならないかを判断します。ユーザーから連絡を望まない具体的な状況が語られた場合は、それをコンセプトに反映させて再テストを行ってください。参加者が自発的な連絡を一切望まない場合は、その結果をプロトタイプやリサーチの要約に反映させます。耳を傾ける目的は、ユーザーの「ノー」によってデザインを変更できるようにすることです。
初回リサーチサイクルの実践的な進め方
トリガー、メッセージ内容、配信コンテキストを含め、提案する自発的な挙動を1つ定義して記述する。
明確で任意参加のリサーチ招待を用いて利用が見込まれるユーザーを募り、セッションの詳細を事前に共有する。
最近受け取ったメッセージや、連絡が歓迎される／限定的に許容される／不要となる具体的な状況について尋ねる。
「プロアクティブな連絡は不要」という選択肢を含め、明確な選択肢を持つ、プロトタイプであることが明示されたモックアップを提示する。
参加者が選択を元に戻せるようにし、操作感や機能が彼らの期待通りに動いているかを観察する。
直接的な観察記録とデザイン上の推論を分けて整理し、明確な「オフ」の選択肢を次のコンセプトへと引き継ぐ。
この手順を踏むことで、チームは思い込みに基づいて開発を進めてしまう前に、自発的な連絡がその体験において本当に必要とされているかを把握できます。インタビューによって人々が置かれている状況が明らかになり、元に戻せるプロトタイプによって具体的な選択肢に対する反応を確認できます。これらが組み合わさることで、「ノー」という声が有用なデザインインプットとなり、ユーザーが真に静けさを選べる手段を提供できるようになります。