最終更新: 2026-08-16

チャットボットのメッセージ設計｜最適な応答文字数

チャットボットの応答は、文字数の設計を誤ると読まれません。長すぎればスクロールの途中で離脱され、短すぎれば「答えになっていない」と受け取られます。プラットフォームごとの上限 (LINE の文字数制限など) を押さえたうえで、表示幅と会話のテンポに合わせて文字数を決めるのが設計の要点です。

チャットボットの文字数制限

主要なチャットプラットフォームには、それぞれ異なる文字数制限があります。Slack メッセージの書き方も参考にしてください。

制限値はプラットフォームのアップデートにより変更される場合があります。開発前に最新の公式ドキュメントを確認しましょう。

最適な応答文字数と認知負荷の関係

技術的な上限とは別に、ユーザー体験の観点から扱いやすい応答の長さがあります。実務上の目安として置きやすいのは、1 回の応答で 100〜200 文字程度です。

この帯に落ち着く理由は、メッセージバブルの読み方が「一息で読み切る」前提だからです。チャット画面ではユーザーは記事を読むときのように腰を据えず、通知や作業の合間に短時間で目を通します。1 バブルの中で戻り読みが必要になると、それまでの文脈を保ったまま処理できなくなり、読み飛ばしか離脱に転びます。200 文字を超えたら「1 バブルに 2 つの用件が入っていないか」を疑うのが実用的な判断基準です。

メッセージの文字数帯ごとの特性を整理すると、以下のようになります。

短すぎる応答 (30 文字未満) は情報不足に感じられ、長すぎる応答 (300 文字超) はスクロールが必要になり読み飛ばされがちです。複雑な内容を伝える場合は、1 つのメッセージに詰め込むのではなく、複数のメッセージに分割して段階的に提示する方が効果的です。

応答メッセージの文字数を事前に確認するには、文字数カウントスが便利です。テンプレートメッセージを作成する際に、文字数が適切な範囲に収まっているかチェックしましょう。

メッセージ設計のポイント

効果的なチャットボットのメッセージを設計するには、以下の原則を守ります。

• 結論ファースト: 回答の核心を最初に提示し、補足情報は後に続ける
• 1 メッセージ 1 トピック: 複数の話題を 1 つのメッセージに混ぜない
• 選択肢の提示: ユーザーの次のアクションを明確にするボタンやクイックリプライを活用する
• 人間らしい口調: 機械的な表現を避け、自然な会話調で応答する
• エスカレーション導線: ボットで解決できない場合の有人対応への切り替えを用意する

選択肢のラベルは 10〜20 文字程度に収めると、スマートフォンでもタップしやすくなります。ボタンが 3 つ以上ある場合は、最も利用頻度の高い選択肢を先頭に配置しましょう。

会話のフローを設計する際は、ユーザーが目的を達成するまでのステップ数を最小限に抑えます。3 ステップ以内で回答にたどり着ける構造が理想です。分岐が多すぎると、ユーザーは迷子になり離脱率が上がります。

ターン数と離脱率の相関

チャットボットの会話設計で見落とされがちなのが、ターン数 (ユーザーとボットのやり取りの往復回数) と離脱率の関係です。ターンが伸びるほど離脱が増えるのは経験的に知られており、設計の出発点として次のような段階で捉えると考えやすくなります (継続率は実測値ではなく、設計判断のための推定の目安です)。

目安として重要なのは、4 ターン目あたりに折れ線があるという感覚です。ユーザーは「3 回試して解決しないなら、このボットでは解決しない」と見切りをつけやすく、そこから先は説明を足しても取り戻せません。この前提に立つと、設計指針は次のように整理できます。

• FAQ 型の問い合わせは 3 ターン以内で回答を完結させる
• 4 ターン目に到達した時点で、有人エスカレーションの選択肢を提示する
• 複雑な手続き (住所変更、返品処理など) は、途中経過を明示して「あと○ステップです」と伝える
• ターン数が増える場合は、各ターンのメッセージ文字数を短く (80 文字以下に) 抑え、テンポを維持する

ウェルカムメッセージは、ボットの第一印象を決める重要な要素です。50〜100 文字程度で、ボットの機能と使い方を簡潔に伝えましょう。「こんにちは！○○サポートボットです。ご質問のカテゴリを選んでください」のように、次のアクションを明示する構成が効果的です。

プラットフォーム別の注意点

各プラットフォームはメッセージバブルの表示幅が異なり、同じ文字数でも見え方が大きく変わります。以下は主要プラットフォームのメッセージバブル表示特性の比較です。

この表から分かるように、LINE では 1 行あたり約 16〜20 文字しか表示されません。200 文字のメッセージは 10 行以上になり、スマートフォンの画面をほぼ埋め尽くします。一方、Slack のデスクトップ版では同じ 200 文字が 4〜5 行で収まります。つまり、同じ文字数でもプラットフォームによって「長い」と感じるかどうかが変わるのです。

LINE Bot では、リッチメッセージやカルーセルなどのテンプレートメッセージを活用すると、テキストだけでは伝えにくい情報を視覚的に表現できます。ただし、テンプレートごとに文字数制限が異なるため、事前に確認が必要です。カルーセルのタイトルは 40 文字、説明文は 60 文字が上限で、この制約内で要点を伝える文章力が求められます。

Facebook Messenger では、2,000 文字の制限に加えて、クイックリプライのラベルは 20 文字までという制約があります。ボタンのタイトルも 20 文字以内に収める必要があります。日本語は 1 文字あたりの情報量が多いため、20 文字でも十分な意味を伝えられますが、英語では 20 文字は約 3〜4 単語に相当し、表現の幅が狭くなります。

Slack Bot は 40,000 文字と余裕がありますが、ビジネスチャットの文脈では簡潔さが求められます。Block Kit を使ったリッチなメッセージ表示を活用し、情報を構造化して提示しましょう。Slack 特有の注意点として、マークダウン記法 (*太字*、`コード`) がメッセージ内で使えるため、文字数にはマークダウン記号も含まれる点を考慮する必要があります。

WhatsApp Business API では、テンプレートメッセージとセッションメッセージで制限が異なります。テンプレートメッセージは事前に審査が必要で、ヘッダー (60 文字)、本文 (1,024 文字)、フッター (60 文字) の各パートに個別の制限があります。公式ドキュメントでは審査に最大 24 時間かかるとされているため、テンプレートの文字数は余裕を持って設計し、頻繁な修正を避けるのが実務上のポイントです。

Web チャットウィジェットは技術的な文字数制限がない場合が多いですが、チャットウィンドウの表示幅を考慮した設計が必要です。一般的なウィジェットの幅は 300〜400px で、1 行あたり 20〜30 文字程度で自然に改行される長さを意識し、長文は段落を分けて送信しましょう。ウィジェットの幅はカスタマイズ可能な場合が多いですが、モバイル表示では画面幅いっぱいに広がるため、デスクトップとモバイルの両方でメッセージの見え方を検証することが重要です。

多言語チャットボットの文字数設計

多言語対応のチャットボットでは、言語によって同じ内容でも文字数が大きく変わる点に注意が必要です。同じ内容でも日本語は英語より短く収まり、短い定型文では 2〜3 倍の差が出ることもあります。この差を無視した設計は UX の劣化を招きます。各言語のロケール設定に応じた文字数調整が不可欠です。

以下は、同じ意味の文を日本語と英語で比較した例です。

この情報密度差は、メッセージバブルの見た目に直接影響します。日本語で 100 文字のメッセージは、英語に翻訳すると 200〜280 文字になることが多く、バブルの高さが 2〜3 倍に膨らみます。多言語チャットボットを設計する際は、以下の点を考慮しましょう。

• 言語ごとに最適文字数の目安を設定する (日本語: 100〜200 文字、英語: 150〜300 文字)
• テンプレートメッセージは最も文字数が多くなる言語を基準にバブル幅を設計する
• 選択肢のラベルは、日本語で 10 文字以内なら英語では 20 文字以内を目安にする
• 表意文字を使う言語は短く収まりやすく、表音文字を使う言語は同じ内容でも文字数が伸びる。対応言語ごとに実際の翻訳文で文字数を測り、最も長くなる言語を基準に置く

エラーメッセージとフォールバック応答の設計

チャットボットの品質は、正常系の応答だけでなく、エラー時やユーザーの意図を理解できなかった場合の応答 (フォールバック) で大きく差がつきます。フォールバック応答の設計パターンを段階的に整理します。

フォールバック応答には 3 つのレベルがあり、段階的にエスカレーションする設計が効果的です。

よくある失敗は、すべてのエラーに同じ「申し訳ございません」メッセージを返すことです。ユーザーは「何が問題なのか」「次に何をすればいいのか」を知りたいのであり、謝罪だけでは行動に移せません。エラーメッセージには必ず「原因の示唆」と「次のアクション」の 2 要素を含めましょう。

具体的なエラーメッセージの改善例を示します。

• 改善前: 「申し訳ございません、もう一度お試しください」(21 文字)
• 改善後: 「ご質問の意図を正確に把握できませんでした。以下のカテゴリから選んでいただくか、別の表現でお試しください。」(52 文字)

改善後のメッセージは文字数が増えますが、ユーザーに具体的な行動指針を示すことで、会話の継続率が向上します。

応答速度と「タイピング中」表示の最適化

実装上の細部ですが、即座に返答するよりも 1〜3 秒の「タイピング中」表示を挟む設計が広く採られています。送信と同時に長文が現れると、読み手は「用意された定型文を出しただけ」と受け取り、質問が読まれた感覚を持てません。わずかな遅延が会話のリズムを作ります。

ただし、この最適な遅延時間はメッセージの長さに比例させるべきです。50 文字程度の短い応答なら 1 秒、200 文字の応答なら 2〜3 秒が自然です。長文なのに即座に返ってくると「定型文だ」と見抜かれ、短文なのに 3 秒待たされると「遅い」と感じられます。メッセージの文字数に応じた遅延の目安は以下のとおりです。

よくある失敗パターン

• ウェルカムメッセージで選択肢を 6 つ以上提示してしまう。選択肢が多すぎると「選択のパラドックス」が発生し、ユーザーが何も選ばずに離脱する確率が上がります。3〜4 つに絞るのが最適です。5 つ以上必要な場合は「その他」を設けて 2 階層にする方が離脱を防げます。
• エラー時に「申し訳ございません、もう一度お試しください」とだけ返す。ユーザーは何が間違っていたのかわからず、同じ操作を繰り返してフラストレーションが溜まります。具体的な代替手段を提示しましょう。
• 1 つのメッセージバブルに複数の質問を詰め込む。「お名前と電話番号、ご希望の日時を教えてください」のように 3 つの情報を一度に求めると、ユーザーはどこから答えればよいか迷います。1 メッセージ 1 質問を徹底し、段階的に情報を収集する設計にしましょう。
• 会話の文脈を無視したリセット。ユーザーが 5 ターン目で「やっぱり最初の選択肢に戻りたい」と言った場合に、最初からやり直しを求めるのは UX の大きな劣化です。直前の分岐点に戻れる「戻る」機能を実装しましょう。

プロのテクニック

• ボットの応答に「確認質問」を挟む。「○○についてお調べしますね。よろしいですか？」のように、ユーザーの意図を確認するステップを入れると、誤解による不満を大幅に減らせます。確認質問は 30〜50 文字に収め、「はい/いいえ」で答えられる形式にするのがポイントです。
• 会話の終了時に具体的な次のアクションを提案する。「関連する FAQ はこちらです」「担当者への問い合わせはこちら」のように、ユーザーの次の行動を明示すると満足度が向上します。
• 選択肢の文字数を揃える。「商品について」「配送について」「返品について」のように、選択肢のラベルを同じ文字数帯 (±2 文字) に揃えると、視覚的に整理された印象を与え、選択しやすくなります。
• 会話の進捗を可視化する。「ステップ 2/4: お届け先の確認」のように、全体のステップ数と現在位置を示すと、ユーザーは残りの手順を予測でき、途中離脱が減少します。

まとめ

チャットボットの応答メッセージは、プラットフォームの文字数制限を守りつつ、1 回あたり 100〜200 文字を目安に設計すると読みやすくなります。1 バブルは戻り読みせずに一息で読み切れる長さに収め、超えるようなら用件を分けます。結論ファースト、1 メッセージ 1 トピック、選択肢の提示を基本原則として、ユーザーがストレスなく情報を得られるメッセージを心がけましょう。

特に見落とされがちなのが、ターン数と離脱率の関係です。4 ターン目あたりでユーザーは見切りをつけるため、FAQ 型の問い合わせは 3 ターン以内で完結させ、それ以上かかる場合は有人エスカレーションの導線を用意しましょう。多言語対応では、同じ内容でも言語によって文字数が大きく変わる点を踏まえた設計が不可欠です。メッセージテンプレートの文字数確認には、文字数カウントスをご活用ください。