一般的なベストプラクティス

Messengerエクスペリエンスの設計は、モバイルやウェブのアプリ設計とは異なります。もちろん一部のユニバーサルUXの原則は当てはまりますが、ツールや期待される動作は、他のメッセージングプラットフォームと比べても、大きく異なります。

従来のアプリでは設計が難しかったインタラクションが簡単にできる場合も、その逆の場合もあります。Messengerで創りたいエクスペリエンスの設計と構築を始める人に役立てていただけるよう、当社の経験に基づくベストプラクティスとガイドラインを集めました。Messengerプラットフォームでの作業を始めるにあたり、これらをぜひ活用してください。

アクセストークンの管理

Messengerプラットフォームでアクションを実行するには、pages_messagingアクセス許可を持つページアクセストークンが必要です。有効なページアクセストークンがあると、基本的には、ページに成り代わる許可がアプリに付与されます。ページアクセストークンはたいていユーザーにより裏付けられます。つまり、ユーザーがアクセスを管理し、ユーザーはいつでもアクセスを終了できます。

安定した本番アプリの場合、ユーザーにより裏付けられるページアクセストークンには、特定のユーザーアクションによりアクセストークンが無効になりアプリの実行が妨げられるというリスクがあります。不安定にならないようにするため、システムユーザーにより裏付けられる安定したアクセストークンを使うことをおすすめします。これにより、アクセストークンは、実質的に個人ではなく事業者によって裏付けられるようになります。システムユーザーを作成するには、アプリとページの所有者が両方とも同じ事業者であることが必要です。

もう1つのベストプラクティスは、グラフAPIエラーコード190を処理することです。これは、アクセストークンが有効でなくなったことを示しています。事業者は、該当するページ/アプリ管理者に対して、アプリがページに成り代わる機能を再び有効にするための新しいトークンを発行する必要があることを警告する通知を実装してください。

{
    "error": {
        "message": "Access token is no longer valid",
        "type": "OAuthException",
        "code": 190,
        "fbtrace_id": "ANtXl05DDie3Dau970_10Ah"
    }
}

送信API呼び出しとWebhooksのセキュリティ保護

本番アプリでは、攻撃を防止し、既存のアクセストークンのセキュリティ侵害を軽減するため、API呼び出しと着信Webhookをセキュリティ保護することを強くおすすめします。

app secretは、アプリダッシュボードの[設定] > [基本]メニューで取得できるアプリのプロパティです。同じメニューで、app secretを新しいものに[リセット]することができます。app secretは次のものとして使われます。

• X-Hub-Signatureと呼ばれる署名HTTPヘッダーでセキュリティ保護されたWebhooks
• appsecret_proofと呼ばれる署名パラメーターでセキュリティ保護されたAPI
• アプリAPI呼び出しのコンテキストでアプリアクセストークンを識別する

Webhooksのセキュリティ保護

提供される署名を検証することにより、app secretで着信Webhooksをセキュリティ保護することができます。各着信WebhooksにHTTPヘッダーX-Hub-Signatureがあります。着信ペイロードであるこの署名は、送信者がapp secretを知っていること、また意図された受信者が該当アプリであることを確認するために使うことができます。これは、Webhook注入攻撃を無視し、複数のアプリに対して同じコールバックURLが設定された場合の混乱を回避するのに役立ちます。着信Webhooksを検証する方法について詳しくはこちら

API呼び出しのセキュリティ保護

API呼び出しのセキュリティを強化するには、アプリダッシュボードの[app secretが必要]の設定を有効にし、API呼び出しにappsecret_proofパラメーターを含めることができます。App Secret Proofの設定と実装方法について詳しくはこちら

設計戦略

自動化を使うにしても、ライブメッセージを実装するにしても、あなたとあなたがMessengerでやり取りする相手にとって、どんなエクスペリエンスにしたいかを決めておくことは大切です。メッセージを送信する前に、時間をかけて次のことをします。

• 目標を定める。利便性、面白さ、またはその両方を組み合わせた設計にする場合は、戦略や実現したい目的をよく把握するなら、最適なエクスペリエンスを作るのに役立つでしょう。
• 利用者に実行してほしいアクションを決める。利用者にどのようなアクションを取ってほしいか、実行して欲しい複数のタスクがあるか、それらのタスクをMessenger外でどのようにして実行するのか、などです。インタラクションの設計段階で、利用者が実行する可能性があるすべての操作手順を決めておきましょう。
• 展開方法の計画を立てる。利用者がタスクを実行した後にもやり取りをどのように継続できるかなど、どのように機能性をさらに広げて、エクスペリエンスを拡充しライフサイクルを伸ばせるかを考えます。

本当に効果のある少数の機能に集中します。あまりに多くのことをすると、利用者が混乱し、満足度が低下します。

会話 vs.GUI

Messengerエクスペリエンスはすべて、ある程度会話形式で動作します。スマートフォンの利用者はチャットに慣れており、Messengerプラットフォームで構築するすべてのインタラクションは、チャットエクスペリエンスの延長として認識されます。そのため、ボットからの返信が完全に自動化されていたとしても、Messengerでの会話は、モバイルやウェブアプリでのやり取りよりもさらに人間っぽく親しみやすい感じになります。人間味を出すのに一番必要なのは、やはり会話です。Wit.aiに組み込まれている自然言語処理機能をこれに追加すると、受け取ったメッセージの意図を自動解析し、実際の会話のようにMessenger botとやり取りすることができます。

とはいえ、アプリでやり取りしている人からすると、すべてのリクエストや返答を入力するよりも、ボタンをクリックしたりリストから選択したりする方がはるかに簡単です。特に、選択肢が2、3個しかない場合はそう言えます。この数十年で進化したグラフィカルユーザーインターフェイス(GUI)では、画像をタップして開く、地図をピンチして拡大するなど、UIでオブジェクトを直接操作できます。

Messengerでは、シンプルなテキストメッセージからGUIまで、あらゆる構成要素を幅広く利用できます。これにより、シンプルで人間味のあるチャットと便利なGUIを程よく柔軟に混ぜ合わせて1つのエクスペリエンスに実装し、最適なインタラクションを実現できるようになります。

設計の原則

Messengerアプリを作成する際は、以下の設計の原則を考慮してください。これらをすべて行う必要はありませんが、これを開始点にすることができます。

簡潔にする

ほとんどの利用者が、スマートフォンでボットを利用します。外出中であったり、他のアプリを使用中であったり、Messengerで別のスレッドを開いているなど、他に目が向きやすい環境です。中断が予期されます。利用者が、操作を中断してそのまま忘れてしまうこともあります。これを回避するには、インタラクションをできるだけ短くすることです。これが不可能な場合は、コンテキストを維持し、再確立する方法を検討してください。

モーダルを避ける

特定の応答を待っていると、ボットはモーダル状態になります。例えば、利用者に検索結果を表示したら、次に送信されるメッセージは自動的に絞り込みとして処理しがちです。でも、処理の途中で利用者の注意がほかに向いたり、検索の実行中に、利用者がそれを中断しようとするとどうなりますか？混乱やストレスが生じることになります。解決策の1つは、やり取りを簡潔にし、ボットを暫定的な状態ではなく、通常の状態に維持することです。

会話とGUIをミックスする

Messengerプラットフォームでは、シンプルなテキストメッセージ、構造化されたテンプレート、ウェブビューのGUIインタラクションなど、さまざまなスレッドコンポーネントを使うことができます。用途によって、それぞれに長所と短所があります。Messengerのエクスペリエンスを構築する際は、よりわかりやすく、直感的に伝わるフォーマットを選ぶようにしてください。最適なエクスペリエンスを生み出すには、会話とUIでのインタラクションを組み合わせる方法が効果的であることが少なくありません。

会話のエチケットを守る

言語、メッセージのトーン、長さ、ボットの応答速度を慎重に検討してください。Messengerボットで、自動応答と人間による応答の両方をサポートしている場合は、混乱や不快感を与えないように注意してください。例えば、自動応答を、人間による応答のように見せかけたりしないでください。

積極的に構造化する

自由形式で入力された回答を認識できることも大切ですが、実装が難しかったり、ボットとやり取りしている人にとって面倒になったりすることもあります。ユーザー入力を構造化するために、ボタン、クイック返信、固定メニューを活用してください。これにより、インタラクションが効率化され、期待値が伝えやすくなります。

予測可能にする

リクエストの処理中は、それがわかるようにします。入力インジケーターを使って、ボットがメッセージを入力中であることを知らせます。サブスクリプションには、明確なオプトイン機能を付けてください。配信する内容やタイミングを利用者の同意なしで変更することがないようにしてください。

思慮深く通知する

すべてのメッセージにプッシュ通知が必要なわけではありません。慎重に通知を使用することによって、その効果性を上げることができます。

エラーに対して丁寧に対応する

リクエストを理解できない場合は、再度ボットの機能を説明します。ヘルプ機能を強調したり、ボタン、クイック返信、固定メニューを使って明確にしたりします。各エラーをフィードバックとしてとらえるようにしてください。利用者からの想定外の応答は、頻繁に生じます。

別個のエンティティを作らない

通常、MessengerボットのIDは、新しいページを作成するのではなく、既存のFacebookページに関連付けるようにしてください。これにより、よりボットが見つけやすくなり、それがあなたまたはあなたのビジネスの公式ボットであるという安心感を得やすくなります。

言葉遣いとメッセージのトーン

会話を中心に開発されたMessengerというプラットフォームでインタラクションが発生するため、ボットが提供するエクスペリエンスやその利用価値を説明する際に使う言葉は重要です。

以下に示すメッセージ作成に関するベストプラクティスを使えば、Messengerで利用者が事業者のエクスペリエンスを見つけてサービス内容を理解していくにつれ、利用者との信頼関係を継続的に築き上げていくことができます。事業者とのやり取りの仕方を利用者が理解すればするほど、より高い確率で利用者のエンゲージメントを維持することができます。

同じボイスを維持する

プラットフォームツールを使ってMessengerで利用者にリーチしながら、あなたがそこで行われるインタラクションをコントロールすることになります。ボイスはあなたの個性です。自然で人間味を感じられるトーンにしてください。

• 親しみやすさを重視するようにしてください。利用者になじみがあり、ブランドらしさを感じさせる言葉やフレーズは引き続き使いましょう。
• 新しい個性を作らないでください。利用者に混乱を生じさせ、正しいサービスとやり取りができているか不安を感じさせることになります。

期待値を設定する

大まかに設定した目標やタスクに基づいて、利用者に何ができるのか、利用者に何をしてほしいのかが正確に伝わるようなメッセージにします。Messengerボットの主な機能を、できるだけ詳しく伝えてください。

• 利用者にリーチしたり、返信したりする頻度を知らせるようにしてください。事業者の対応可能な時間帯や返信レベルを利用者が知っているなら、いつ返事が来るかを予測できます。
• ライブメッセージに対応していない(または今後も対応しない)場合は、そうであるとほのめかさないでください。できることを明確にしておけば、利用者はそれに応じて対応します。

コンテキストを提供する

ボットのエクスペリエンスを理解できるように、利用者の各ステップをコンテンツを使って案内します。例えば、利用者が今どのステージにいるのか、何がお願いされているのか、次に何が起こるのかなどです。

• 利用者のアクションを確認するようにしてください。そうすることによって、実際に「対話」しているような印象を与え、サービスに対する信頼性が高くなります。
• 利用者を待たせないでください。利用者からのリクエストがあった場合は、リクエストを受け取ったことを知らせ、そのリクエストに対応できるかどうか、できる場合はいつになるのかを伝えます。

メッセージを書く

Messengerで利用者とやり取りを始める前に、すでに会話したことがあるつもりで、プロンプトや返答のストックを作成しましょう。インタラクションをどのように誘導したいのか考えて、あらゆる可能性を想定します。それができたら、次のことをしてみてください。

キーワードのリストを作成する

ブランドに関連する用語は何ですか？利用者はどのような言葉遣いで話しかけてきますか？トリガーとなりうる言葉やそのバリエーションを網羅しておくと、自作のヘルプコマンド、プロンプト、返答を定義する際に役立ちます。

• リストの作成時には、グローバルな視点で考えるようにしてください。地域、言語、文化に応じて定義が変わる場合があることを考慮してください。翻訳した場合にメッセージの長さに影響があるかを考えます。
• 言葉を創作したり、新しい用語や俗語を使用したりしないでください。微妙な言い回しはそのニュアンスをうまく翻訳できないため、利用者にMessengerボットでのやり取りを説明する際には、シンプルな言葉遣いにすることをおすすめします。

やり取りを綿密に計画する

タスク、期待値、確立したいコンテキストに基づいて、送信するプロンプトと応答をすべて書きます。書きながら、利用できるメッセージタイプも考慮してください。例えば、メッセージをテキストのみにする場合と、ボタンを含める場合によって、言葉の選択や配置がどのように変化するかを検討します。

• 実現したいこと、利用者に実行して欲しいアクション、利用者が事業者に期待することなど、意図を中心に書いてください。こうすれば、期待値を設定したりコンテキストを提供したりするのもより簡単になります。
• 各メッセージの複数のバージョンを作成するようにしてください。そうすることでめりはりがつき、またかと思われたり、飽きられたりしなくなります。いつも同じようなメッセージばかり送っていると、利用者は反応しなくなってしまいます。
• 一方的な会話をしないようにしてください。あなたの目標は、会話していると相手の目標とは異なる場合があります。それぞれの利用者の反応やリクエストの内容を考慮して、それにふさわしい返事を返しましょう。
• 質問だけを投げかけないでください。単独で質問だけすると、回答の仕方は自由ということになり、想定外の回答が返ってくる可能性があります。質問をする場合は、特定の回答が設定されたボタンをメッセージに追加して、利用者に選んでもらうようにしましょう。

あらゆるやり取りが、既存のエクスペリエンス、そしてそれを促進するメッセージを吟味し改善する機会となります。利用者の反応を見ながら、どんな機能をどのように拡張していくべきか見極めてください。

マーケティングメッセージ(定期通知)

質の高いユーザーエクスペリエンスを実現するには、質の高いマーケティングメッセージを、受信を期待している相手に送信する必要があります。

ユーザーは、受け取るマーケティングメッセージを予期していなければなりません。以下の方法で、この期待値を設定することができます。

• オプトインリクエスト(タイトルや画像も含む)に、ユーザーが受け取るマーケティングメッセージのタイプ(注文の最新情報、おすすめの商品、特定のクーポンなど)を含める
• 1人のユーザーに複数のオプトインリクエストを送信する場合は、各リクエストに、ユーザーが受け取るマーケティングメッセージのタイプを明記する

マーケティングメッセージは、ユーザーにとって価値がありそうな、ユースケースに合ったものにする

ユーザーは、メッセージをブロックするなどの方法でメッセージエクスペリエンスに関するフィードバックを提供できます。その結果、マーケティングメッセージの利用が制限される場合があります。オプトインリクエストとマーケティングメッセージを定期的に見直し、上述のベストプラクティスに従っているかどうかをチェックするようにしてください。マーケティングメッセージの利用でレートや機能が制限される場合は、ユーザーにとって価値のある関連性の高いメッセージエクスペリエンスを構築する方法を検討してください。

会話らしくするためのヒント

メッセージを書く際には会話らしさを意識します。ただし構築するエクスペリエンス、使うメッセージタイプ、実際に伝える内容に影響しないようにします。会話らしくするには日常の話し言葉を使いますが、中心となる機能やツールの内容を伝えること、また信頼感を犠牲にするほど砕けた表現にするという意味ではありません。

会話風のトーンを使うかどうかは、やり取りの相手と、その人に実行してもらいたいタスクを考慮して決めます。ビジネスオーディエンスに話しかける場合や、個人情報の確認を利用者に依頼するような場合は、砕けすぎた表現を使用すると、相手は警戒心を抱き、やり取りする意欲が損なわれてしまう可能性があります。

会話風のトーンはエクスペリエンスを下支えするものであって、それ自体を決定づけるものではありません。メッセージの意味を変えることなくやり取りに会話風のトーンを盛り込む簡単な方法をいくつかご紹介します。

能動態を使う

能動態の文章では、その文の主語が何かをします。受動態の文章では、主語に対して何かがなされます(受け身になります)。能動態は、より直接的であり、表現も簡潔になります。「ニュース速報はCNNによって配信されます」よりも「CNNがニュース速報を配信します」の方がわかりやすく、文章も短くシンプルになります。

短縮形を使う

言葉やひとまとまりの言葉の短縮形を使うと、メッセージをより簡単に会話らしくすることができます。例えば、「We cannot wait to get started」だと堅苦しい印象ですが、「We can’t wait to get started」とすれば口調も軽く砕けた印象になります。

1人称と2人称の使い方を統一する

メッセージの話し手を統一し、1人称単数(話し手が個人の場合は「私」)にするか、1人称複数(話し手が企業の場合は「当社」または「Spring」)にするのかを決めます。利用者のことを指す場合は2人称(お客様、お客様の)を使い、利用者に対して話しかけるようにし、一方的に話さないようにします。

文法に注意する

普段の口調よりも砕けた調子でやり取りする場合でも、文章作成の基本的なルールは守るようにしてください。砕けた口調を使う場合でも、相手に真剣に受け止めてもらう必要があります。綴り、大文字の使用、文章構造が正しければ、利用者の意識をエクスペリエンスに集中させ、伝えたい内容を明確にできます。

句読点に注意する

句読点、省略、感嘆符、「いいね！」などをどこでどのように使うかも、Messengerのエクスペリエンスの印象を左右する要素のひとつです。全体のトーンに与える影響に注意して、熱意、不安、その他の感情を伝えるのに必要であれば、積極的に使いましょう。

トーンを考慮する

会話風の言葉でメッセージを作成するといっても、まったく新しいことを始める必要はありません。ボイスはあなたの個性であり、トーンはその個性の表現方法です。会話風にするというのは、単により個人的なやり取りにするということです。うまくいくかどうか自信がなければ、実際に声に出してみて、どのように聞こえるのかを確認してみましょう。

配信チャネルによって同じ内容の注文確認のトーンがどう変わるのか、例を挙げます。

心から出た、なじみのある文章にしましょう。ブランドとエクスペリエンスを一番よく知っているのはあなた自身です。あなたとオーディエンスにとって何が最適であるかを自分で判断してください。必要であれば、ためらわずにその都度調整していきましょう。

アップデートとアラート

エクスペリエンスに関連するメッセージをタイミングよく送信して、利用者に常に最新の情報を伝えるようにします。アクションが完了したらフォローアップメッセージでそのアクティビティを確認し、その後に必要なステップがある場合はそのステップを伝えます。サブスクリプションモデルを構築する場合は、毎日同じ時刻にアップデートを送信するようにします。

プッシュ通知ではアップデートやアラートをプレビューできるため、利用者がMessengerを開いていなくても新しいメッセージの着信を知ることができます。また、通知を使うと、利用者に簡単に再エンゲージを促すことができます。

エラー発生

一部のツールではやり取りを自動化することができますが、人とのコミュニケーションであることを常に念頭に置くようにしてください。つまり、メッセージと意図の解釈は異なる場合があるということです。理解できない、または意味のわからないリクエストを受け取ったときは、その旨をはっきり伝えましょう。わかりやすく説明するように求めたり、こちら側でできることやできないことを伝えたりします。

メッセージのやり取りは、利用者のエンゲージメントを維持するチャンスだと思ってください。会話を始めるためのものか、会話を継続させるためのものかに関係なく、エクスペリエンスのしくみとそれが提供する価値について何を期待できるかを利用者に明確に示すやり取りを継続してください。