生成AI（Claude）で作る、顧客体験にこだわったLINEチャットボットの設計
みなさんこんにちは、リテールアプリ共創部のmorimorikochanです、
今回は、顧客体験にこだわったチャットボットの設計およびデモの実装をしてみたので解説したいと思います。
よくみるチャットボット、こうなっていませんか
日頃からECサイトなどでよく目にするチャットボットですが、操作していてこんな経験ないでしょうか？
- チャットボットなのに、提示された選択肢を何回も選ぶだけ
- 選び続けた先が「その他のお問い合わせはこちら」で、結局電話をかける
- ポイントや配送について「私の場合」を聞いているのに、返ってくるのは規約の一般論
- 言い回しを少し変えただけで「わかりませんでした」
また、チャットボットを運用している方はこんな経験ないですか？
- 回答率が上がらない。そもそも使われない
- FAQやシナリオのメンテが続かない。質問を1つ増やすたびに分岐ツリーの改修が要る
- 「わかりません」のログは溜まるが、改善に繋がらない
- 結局オペレーターの負荷が減らない
これらの問題の多くは、ボットがシナリオ型であることに起因します。
そもそも、シナリオ型ボットはあらかじめ用意した質問と分岐に顧客を誘導する仕組みです。
会員情報を参照できないわけではありませんが、「配送状況の照会」のような決まった用件ごとに専用の分岐を作り込む必要があり、分岐の外に出た質問には一般論しか返せません。多くの現場では、その作り込み自体がコストに見合わず、FAQの分岐止まりになります。
一方で、これらの問題の多くは生成AIで解決できます。
生成AIはユーザーの自由な言い回しのまま質問を解釈可能で、会員情報やFAQなどをAPIやRAG経由で生成AIと繋げばそのユーザーの状況や背景を踏まえて答えを返せるためです。
実際、最近は生成AIをチャットボットに導入した事例がよくみられます。
ただし、生成AIを載せただけのチャットボットなら安価なサービスがいくらでもあり、実際に成果を分けるのは顧客の体験を設計し直せているかどうかだと私は考えています。
この記事では主に、生成AIを正しく使い顧客体験を向上させるためのLINEチャットボットの設計についてデモ動画付きで解説したいと思います。
改善したい顧客体験とそれに対する設計方針
すでに記載したような体験を整理し、それに対してどのように設計することで解消するかを一覧表にしてみました。
| # | 改善したい顧客体験 | 設計方針 |
|---|---|---|
| 1 | ID連携済みの会員なのに「注文番号をご入力ください」。「私の場合」を聞いても規約の一般論 | ID連携で本人を特定し、規約の一般論ではなくユーザーの状況踏まえて回答 |
| 2 | 選択肢を選ばされ続ける。自由に書くと"わかりません" | ボタンではなく自然言語で受け、誤字、表記ゆれ、話し言葉のまま理解する |
| 3 | FAQにないことをそれらしく間違えて答える | FAQと規約を検索し、根拠がある時だけ断言し、根拠がなければ正直に言う |
| 4 | さっきの話を忘れる | 会話の文脈を保持し"それ"や"これ"の指示語が通じる |
| 5 | 曖昧に聞くと即「わかりません」 | わからなければ聞き返す |
| 6 | 有人チャットに繋がっても最初から説明し直し | 会話の要約付きで有人チャットに引き継ぐ |
| 7 | 返事が遅い・無反応 | 処理中もエラー時も状況を伝える |
この中で顧客体験に特に重要かつ基本的な部分は主に1と3です。
1は自社の会員DBや注文システムと繋がなければ実現できず、3は自社のFAQと規約を検索できる形に整備しなければ実現できません。
いずれも汎用のチャットボットSaaSで対応している場合もありますが、自社の情報資産と繋ぐ方法が限定的であり実運用は難しい場面が多いです。
ここからは、これら7つの設計を1つずつ実際に作ったLINEのチャットボットの動きで確かめていきます。
7つの設計に沿ってLINE公式アカウントのチャットボットを生成AI（Claude Sonnet5）使って作ってみた
以下のシチュエーションで、LINE公式アカウントのチャットボットを生成AI（Claude）でデモ実装してみました。
- 架空のホームセンター"モクレンホームセンター"
- 会員の山田さんがID連携を済ませた状態で話しかけます。
- 会員DBには保有ポイント（1,250pt、うち500ptが8月31日失効）と注文履歴3件
- FAQには返品、送料、組立サービス、割引券の併用など約30件が入っている
また、生成AIのモデル・プラットフォームには、Amazon BedrockのClaude Sonnet 5を使用しました。
また、各種ツールの実行には現在ベータ版のツールランナー（SDK）を利用しました。ツールランナーはClaudeでアプリケーションを作る人にとって、簡単にツールを定義できる便利機能なのでそのうち別で記事にしようと思います。
設計1: 会員を特定した状態で回答する
以下のデモ動画では、チャットボットが質問に対しユーザーを特定した状態で、そのユーザーの保有ポイントや直近の注文を答えます。
このLINEチャットボットの裏側では、LINE MessagingAPIのWebhookが利用されており、Webhookのメッセージには送信元ユーザーのIDが含まれています。
サーバーがWebhookのメッセージを受け取るとユーザーを特定し、生成AI（Claude）が自律的にコンテキストを踏まえて注文情報検索ツールや会員情報ツールを呼び出し、保有ポイントや直近の注文を返答することができます。
このとき、生成AIが出力したLINEユーザーIDや会員IDをツールに渡すことは絶対に避けなければなりません。生成AIに渡されたLINEユーザーIDや会員IDが改変されずにツールに渡す保証が一切なく、場合によっては間違ったユーザーの情報でツールを実行してしまい、なりすましや不正な権限昇格が発生してしまいます。そのため、生成AIを経由せずプログラムから直接ツールにIDを渡す必要があります。
設計2: 言い回しが崩れていても通じる
以下のデモ動画ではユーザーの質問が同時に2つひらがなで入っていますが、チャットボットはこの難しい質問を正しく解釈し返答しています。
シナリオ型チャットボットであれば、このような難しい質問を適切に扱うためには複雑な分岐やロジックを事前に定義し考えうる様々なパターンをあらかじめ網羅しておく必要がありますが、生成AI型のチャットボットであれば言い回しが崩れても正しく理解し、なおかつ、返品送料とポイント返還の両方を1回の回答で返します。
設計3: 根拠がある時だけ断言する
以下のデモ動画では、FAQに明記されている内容と明記されていない内容を質問し、それに対してチャットボットが回答しています。
| FAQに明記されている場合 | FAQに明記されていない場合 |
|---|---|
 |
 |
FAQに記載がある質問（組み立てサービスってお願いできる？）には、サービス内容と料金を答えたうえで、参照したFAQを末尾に出典として示します。
FAQに記載がない質問（植栽の植え込みサービスってやってる？）には"確認できませんでした"と否定しています。
生成AI導入で最も警戒される"知ったかぶり"（ハルシネーション）を、根拠のある時だけ断言するという設計で抑えています。
ただし、この設計がどこまで効くかは、FAQ検索がきちんと根拠にたどり着けるか、モデルが「根拠なしに断言しない」という指示をどれだけ守るかで変わります。
モデルのバージョンを入れ替えたりプロンプトを直したりするたびに精度が変わるので、想定質問に対する回答を定期的に評価する仕組みをセットで用意しておくと安心です。Claudeの公式ドキュメントでも詳しく解説されているので参考になります。
設計4、5: 以前の会話も踏まえて回答し、不明瞭な質問は聞き返す
以下のデモ動画では、チャットボットが過去のメッセージの内容を踏まえて回答しています。ユーザーの"変更したい"、というような述語が省略されたメッセージでもチャットボットが推測し回答するためユーザーがスムーズに問い合わせることができます。
仕組みとしては、直近の会話全てをコンテキストとして生成AIに入れてメッセージを生成しています。便利な一方、コンテキストに大量の会話を入れると回答精度が落ちる・応答が遅くなる・ハルシネーションする、などといったリスクがつくので、どこまでの会話をコンテキストに入れるかうまく設計する必要があります。
設計6: 会話の要約付きでエスカレーション
以下のデモのスクリーンショットでは、"返品したい"という依頼に対し、チャットボットに権限がないため、有人のオペレーターにエスカレーションしています。エスカレーション内容は以下のように管理画面に表示されています。
| ユーザーからの返品依頼 | オペレーターの画面に要約が表示される |
|---|---|
 |
 |
オペレーターの画面には、会話の履歴以外にもユーザーが返金するまでにいたった背景や流れが会話の要約としてまとめられており、これをもとにスムーズに引き継ぎ、ユーザーが説明を最初からやり直させられるといった体験をなくすことができます。
仕組みとしてはそこまで難しくなく、エスカレーション時に今までの会話の要約を生成AIに出力してもらい、それを画面に表示しています。
ちなみに、エスカレーション自体もツールとして定義しており、ツールが実行されるとそれをトリガーに要約処理も走ります。
設計7: 送信直後に反応がある
今までのデモ動画で、メッセージ送信直後にローディング表示が出ていたことに気付いたでしょうか。
通常、生成AIの回答には数秒~数十秒かかりますが、その間ボットが無反応だと顧客には届いていないように見えてしまい、連投や離脱が起きてしまい体験が悪いです。これを防ぐために処理開始前にローディングのような"受け取った合図"を表示させています。
LINE MessagingAPIではローディングを表示するためのAPIが用意されており、今回はそれを呼び出しています。
ただし、このローディングは最大でも60秒間しか表示できず、60秒を超えた場合は消えてしまうためそれまでに何らかのフィードバックをユーザーに返さないと結局体験が悪くなってしまいます。
仮にサーバーの処理に時間がかかってしまい60秒経過した場合は、"まだ処理を継続している旨"のメッセージを送ることが重要になると感じています。
より顧客体験をよくする2つの設計
ここまではよくあるチャットボットの課題を解消するための設計でしたが、より顧客体験をよくするようなアグレッシブな設計を2つ紹介します。
写真で問い合わせられる
以下のデモでは、ユーザーが写真を添付すると、写真に写っている商品を取り扱っているかをボットが返信しています。
テキストのみで商品の種類や型番を調べてチャットで正確に伝えるハードルは高く、チャットボットが正確に回答できる可能性も低くなります。
このような場合チャットボットに写真を添付できるようにしておくことで、商品の写真をそのまま送ってもらい、商品の対象を特定してから答えることができます。
仕組みとしては、LINE MessagingAPIのWebhookのメッセージの添付された画像のIDから画像を取得し、Claudeに画像をそのまま読み込ませています。LINEの場合はテキストと画像がそれぞれ別のメッセージになってしまうため扱いにくく、デモではテキストを送ってからさらに画像を送る方法をとっています。
最近はClaudeなど多くの生成AIのモデル・環境は画像入力に対応しています。
ただし、画像を入力としたときはテキストに比べて精度が不安定になりやすく、本番運用を行う際は前述の通り精度の評価を十分に行う必要があります。テキストに比べてデータセットを作成しにくい点にも注意が必要です。
ユーザーが次の行動をできるように
以下のデモでは、顧客が"電話番号"を聞くとチャットボットが電話番号をコピーできるボタン付きで返答しています。
みなさんはチャットbotとの会話の中で、会員番号や電話番号を拾い外部のブラウザやアプリにコピペする場面はよくないでしょうか。
チャットボットの応答がテキストだけだと、テキストの中から部分的にコピーする手間がかかり、体験がよくありません。
このような場合、本文と分けた吹き出しやカード状のUI（LINEの場合だとFlex Message）にコピー用のボタンを添えてあげると、ユーザーの次の行動がスムーズに進められて体験が良いです。
今回は、LINEのFlexメッセージのクリックアクションでコピーボタンを実現しています。
また、こういったリッチなUIのレイアウトを生成AIを使えばリアルタイムに変更することも可能そうに感じています。未検証ですがいつかブログのネタにしたいです。
費用
今回のデモを実行するために必要なランニング費用は、大きくLINE MessagingAPIのメッセージ送信費用と生成AIの利用料金の2つありました。
LINE MessagingAPIのメッセージ送信費用については月額費用で、契約しているプランによって異なりますが、メッセージの送信方法を工夫したりミニアプリと組み合わせて外部チャット化することで"メッセージ通数のカウント"を抑えることができます。
また、生成AIの利用料金は厳密に計算/測定しておらずざっくり計算ですが、3往復やりとりを行うと約5~10円程度料金が発生する計算になりました（デモではモデルにはAmazon BedrockのClaude Sonnet 5を利用しておりプロンプトキャッシュは無効化にしています）。
例えば1ヶ月にお問い合わせが1万回発生しそれぞれ3往復のやりとりが発生すると5~10万円程度/月となり多くの企業によっては無視できない金額になってくるのではないかと感じています。
モデルの調整やプロンプトキャッシュの有効化など料金を下げる手段は色々ありますが、性能が下がったりユースケースによっては逆に料金が上がることもあり得るので慎重に検討することが必要です。
セキュリティとガバナンス
チャットボットではユーザーの情報を扱うため、セキュリティやガバナンス統制が重要になってきます。
今回のデモ構成ではどう対処しているかを答えます。
会話データはAIの学習に使われるか
この構成で利用しているAmazon Bedrockは、入出力をモデルの学習に利用しないことを公式に明示しています。
さらに、Sonnet4.5やHaiku4.5などであれば日本向けの推論プロファイルを使うことで処理を日本国内（東京・大阪リージョン）で完結させることも可能です。
- Data protection - Amazon Bedrock
- Introducing Amazon Bedrock cross-Region inference for Claude Sonnet 4.5 and Haiku 4.5 in Japan and Australia
会員情報はどこまでAIに渡るのか
会員情報は、会員DBを丸ごとAIに渡すのではなく、最低限必要な項目だけツール経由で渡すことになります。
また、ツール内はプログラムで動作するため、ユーザーの権限・種類に応じて取得項目を制限したり拒否することも可能です。
不適切な出力をしたり、勝手に手続きしたりしないか
生成AIは同じ入力でも毎回同じ出力になるとは限りません。プロンプトで「変なことを言わないで」と指示するだけでは、それはお願いであって強制ではないため、防御にはなりません。そこで、制御を何層かに分けます。
- 操作を絞る（制御の中心）：チャットボットが呼べる操作はツールとして列挙したものだけです。返金のような影響の大きい操作は最初から持たせず、エスカレーションして人間が判断します。
- 実行前に確認を挟む：配送日変更のような手続きは、生成AIが依頼内容を提出するところまでとし、実行はプログラム側が顧客の同意（"はい"といったメッセージなど）を受けてから行います。生成AIの判断だけで手続きが走ることは避けるべきです。
- 発言範囲を絞る：回答範囲を自社の商品・サービスの案内に制限し、範囲外の話題は丁寧に断ります。デモではシステムプロンプトで実現していますが、本番ではAmazon Bedrock Guardrailsのようなサービスで入出力のチェックを重ねるのが現実的です。
- 監査ログを残す：それでも不適切な出力や手続きが起きたときに備え、会話を監査ログとして残しておけば、早期発見と影響範囲の特定ができます。
まとめ
顧客体験にこだわったLINEチャットボットの設計を、実際に動くデモとあわせて解説しました。
- ID連携で本人を特定し、一般論ではなくその人の状況で答える
- 言い回しが崩れていても理解する
- 根拠がある時だけ断言する
- 会話の文脈を保持する
- わからなければ聞き返す
- 会話の要約付きで有人チャットに引き継ぐ
- 送信直後に反応を見せる
また、さらに顧客体験をよくする設計として、写真での問い合わせと、答えを次の行動にそのまま使える形で返すUIを紹介しました。
いまLINEで運用中のチャットボットに課題を感じている方や、これから顧客体験を軸にチャットボットを作りたい方は、ぜひお問い合わせください。
