「記憶するAI」が実現する、ティア（ランク）別の超・パーソナライズ接客術
顧客ランクに応じて接客態度・回答内容・オファーを自動変更し、VIP顧客に特別な体験を自動提供する高度なパーソナライズ接客を解説します。添付ファイルの長期記憶機能と組み合わせた超・個別対応AIの設定方法も詳しく紹介します。
「以前送った資料のことなんだけど…」
お客様のそんな一言に、即座に反応できるスタッフは何人いるでしょうか？
VIP には執事のように、新規にはていねいに——ランクと記憶で変わる接客が、リピーターを育てます。
Socrates（ソクラテス）は、「顧客ティア（ランク）に応じた態度の使い分け」と「添付ファイルの長期記憶」を組み合わせ、人間以上の記憶力と気配りを実現します。この記事では、ティア別接客の設計方法と、ファイル記憶機能の活用シナリオを解説します。
1. 顧客ティア（Tier）による「接客態度」の自動変化
すべてのお客様に同じ対応をすることが、必ずしも正解ではありません。Socrates は、CRM に登録された顧客ティア（Tier）を参照し、AI の振る舞いを自動で最適化します。ティアは管理者が手動で設定するほか、AI の自動タグ付けを参考にして変更できます。
- 👑VIP 会員 (Tier 3)：
執事のように丁寧で、最上級の敬語を使用します。「◯◯様、いつもありがとうございます」と名前を呼び、特別感を演出します。回答の詳細度を上げ、優先的なサポートを提案するよう設定できます。 - 🤝通常会員 (Tier 2)：
親しみやすく、頼れるパートナーとして振る舞います。敬語は崩さず、しかし固すぎないトーンで、用件をスムーズに解決します。 - 🌱ライト会員 (Tier 1)：
丁寧かつ簡潔に対応します。過度なセールスより、的確な情報提供を優先し、信頼を積み重ねます。
Deep Logic Prompt でティア別振る舞いを設定する
ティア別の振る舞いは Deep Logic Prompt で定義します。詳細な接客指示に以下のようなルールを書くことで、ログイン中の顧客のティアに応じて AI が自動で態度を切り替えます。
▼ Deep Logic Prompt 設定例（コピペ用）
# 顧客ティア（Tier）による振る舞い設定
[Tier 3 (VIP)]
- 最高級の「執事」として振る舞ってください。
- 語尾は「〜でございます」「〜いたします」を徹底。
- 決して否定せず、お客様の要望を最優先に行動してください。
- 文頭には必ず「{{CUSTOMER_NAME}}様、」と添えてください。
[Tier 2 (通常会員)]
- 親しみやすい「専属アドバイザー」として振る舞ってください。
- 敬語は崩さず、しかし固すぎないトーンで接してください。
- 質問に対しては、解決策を端的に提示することを優先します。
[Tier 1 (ライト会員)]
- 礼儀正しい「店舗スタッフ」として振る舞ってください。
- 余計な雑談は控えて、質問されたことに正確かつ簡潔に答えてください。
- 上位プランへのメリットを聞かれた場合のみ、案内を行ってください。ティアごとの質問回数上限も管理画面から設定できます。VIP は無制限・通常会員は 1 日 30 回・ライトは 1 日 10 回、のような設定で運用コストをコントロールしながら、VIP 体験の希少性を保てます。
2. 添付ファイルは「ログ保持期間」ずっと覚えています
CRM モードでチャット送信された画像や PDF 資料は、その場限りの使い捨てではありません。プランごとのログ保持期間内、AI はそのファイルの中身を「あなたとの共有知識」として記憶し続けます。
「以前アップロードした成分表について教えて」
といった質問にも、AI は過去のファイルを即座に参照して回答します。何度も同じ資料を送らせるストレスをお客様に与えることはありません。ファイルを送信すると通常の 2 倍（2 クレジット）が消費される点を運用コストに含めておきます。
3. 画像やグラフ情報のナレッジ登録
「チラシの画像」や「売上グラフ」のような視覚的なデータも、Socrates ではそのままナレッジとして登録可能です。ファイルをアップロードする際、AI がその内容（グラフの数値推移、チラシに記載された商品名、図解の内容）を自動的にテキスト情報へと変換し、システムに蓄積します。
OCR で読み取った内容は管理画面から編集して精度を補正できます。手書きのメモや複雑な配置のチラシでも、解像度の高い鮮明な画像をアップロードすることで読み取り精度が上がります。
運用設計のポイント
- ① ティア設定は「接客の差」が感じられる粒度で
Tier 1 と Tier 3 で同じような応答では差別化が機能しません。VIP には名前呼び + 敬語、Tier 1 には簡潔対応、という明確な差を Deep Logic Prompt に書きます。 - ② ティアの昇格条件を社内で決める
「累計購入 3 回でティア 2 に昇格」「月額プランに入ったら VIP」など、ティア変更の基準を明文化します。AI の自動タグを参考に、管理画面から手動でティアを変更します。 - ③ ファイル添付の目的をお客様に伝える
添付資料が今後の対話で参照されることをお客様に事前に伝えることが誠実です。不要になったファイルの削除依頼に対応できる社内手順も決めておきます。
よくある質問
Q1. ティアは自動で変わりますか？
ティアの変更は管理者が手動で行います。AI の自動タグ（「VIP」「商機」など）を参考に、管理画面の顧客詳細からティアを変更できます。自動昇格の仕組みは標準では持ちません。
Q2. ティアごとの質問回数の上限は変えられますか？
はい。ティアごとに 1 日あたりの利用回数上限を設定できます。VIP は上限なし・一般は制限あり、という使い分けで接客の差とコスト管理を両立できます。
Q3. 添付ファイルの内容が他のお客様に見られることはありますか？
テナント単位・顧客単位でデータが分離されているため、他のお客様の添付ファイルが参照されることはありません。Supabase の行レベルセキュリティ（RLS）で保護されています。
Q4. ティア別の接客に AI への指示文以外の設定は必要ですか？
Deep Logic Promptの設定だけで対応できます。ティアの判定は CRM のデータを AI が自動参照するため、追加の技術設定は不要です。
Q5. ファイルの削除はいつできますか？
管理画面から随時削除できます。削除後はシステムから完全に除去され、AI の参照対象からも外れます。お客様からの削除依頼に対応できる体制を社内で準備しておくことを推奨します。
「自分のことを覚えていてくれる」。
その信頼感が、長期的な顧客関係を支える鍵となります。
Socrates のティア機能と長期記憶で、パーソナライズされた接客体験を設計しましょう。
導入前に決めておきたいこと
記憶するAIを活用するときの中心課題は、何でも覚えさせることではなく、次回の相談に役立つ情報だけを残し、踏み込みすぎない対応を設計することです。
前回の相談テーマや希望条件は次の案内に役立ちますが、必要のない個人情報を記憶させる必要はありません。記憶する情報・使う場面・消す条件を先に決めます。 重要なのは、機能を有効にすることではなく、誰がどの情報を更新し、どの相談を人へ渡すかを運用として決めることです。
最初に整理するチェック項目
- ✅ AIに任せる相談と、担当者が判断する相談を分ける
- ✅ 回答の根拠になる情報と、その更新担当を決める
- ✅ お客様が次に取る行動を、各会話の最後に一つ用意する
- ✅ 誤回答・未解決・有人引き継ぎを確認する方法を決める
小さく始める実装手順
最初からすべてのケースを自動化する必要はありません。対象を絞り、設定した内容が実際の会話で機能するかを確認してから範囲を広げます。
- 1. 再訪時の案内に役立つ情報と、扱わない情報を定義する
実際の設定では、担当者が判断できる言葉に置き換え、設定後にテスト質問で確認します。 - 2. ティアや顧客区分ごとに、記憶を使う場面を分ける
実際の設定では、担当者が判断できる言葉に置き換え、設定後にテスト質問で確認します。 - 3. 会話の冒頭で履歴を断定せず、確認しながら自然に参照する
実際の設定では、担当者が判断できる言葉に置き換え、設定後にテスト質問で確認します。 - 4. 誤った情報や古い希望条件を修正する運用を用意する
実際の設定では、担当者が判断できる言葉に置き換え、設定後にテスト質問で確認します。
テストでは、理想的な質問だけでなく、情報が足りない質問・言い換え・複数の要望が混ざった質問も使います。回答できない場合に、無理に答えず確認質問や有人対応へ切り替えられることまでが導入の完了条件です。
運用で見るべき指標
記事のテーマに関係する成果だけでなく、会話の品質も一緒に確認します。最低限、会話数、目的の回答まで進んだ割合、未解決になった質問、有人引き継ぎの件数を同じ期間で見てください。
数字が悪いときは、いきなりAIの性格やプロンプト全体を変えず、どの質問・どの案内・どのリンクで止まったかを一つずつ確認します。原因が情報不足ならナレッジを、導線の問題なら質問順序を、判断が必要な相談なら引き継ぎ条件を修正します。
失敗しやすいパターンと直し方
AIが過去の会話を参照するときに、古い情報を現在の事実として断定すると信頼を損ねます。以前の相談内容を確認する言い方を接客指示に含めてください。
もう一つの失敗は、設定した人だけが内容を理解し、現場の担当者が修正できない状態です。変更した理由・対象範囲・確認したテスト質問を短く記録し、更新担当が同じ手順で見直せるようにします。
反対に、すべてを有人対応へ戻す必要もありません。AIが安定して答えられる範囲を残し、判断が必要な境界だけを人へ渡すことで、品質と効率の両方を調整できます。
よくある質問
Q1. 最初からすべての問い合わせをAIに任せるべきですか？
いいえ。頻度が高く、回答の根拠が明確な相談から始めます。個別判断や契約に関わる相談は、必要な確認事項を示して担当者へ引き継ぐ設計が安全です。
Q2. 設定を変更したら、何を確認すればよいですか？
代表的な質問、情報が不足した質問、回答できない質問の3種類でテストします。回答内容だけでなく、次のリンクや有人対応への切り替えが意図どおりかも確認してください。
Q3. 既存のナレッジはそのまま使えますか？
そのまま登録するのではなく、古い情報・重複・条件付きの説明を整理してから使います。回答の正本と更新担当を決めておくと、後から修正しやすくなります。
Q4. AIで対応できない相談はどうすればよいですか？
対応できないことを明確に伝え、担当者へ渡すために必要な情報と相談方法を案内します。曖昧な回答を続けるより、引き継ぎ条件を明示する方が信頼を保ちやすくなります。
関連ガイド
- パーソナライズ接客の実践ガイド：今回のテーマと一緒に確認しておきたい関連ガイドです。
- ティア別の対応設計：今回のテーマと一緒に確認しておきたい関連ガイドです。
- 顧客管理と履歴活用：今回のテーマと一緒に確認しておきたい関連ガイドです。
判断に迷ったときの優先順位
運用中に「AIで答えるか、人へ渡すか」を迷った場合は、まず安全性と正確性を確認し、次にお客様が今必要としている情報を考え、最後に自動化による効率を検討します。効率を優先して誤案内を残すと、後から修正するコストが大きくなるためです。
- 事実確認が必要な内容や個別判断は、根拠を確認できなければ担当者へ渡す
- 回答できる内容でも、条件によって結論が変わる場合は確認質問を先に置く
- 同じ質問が繰り返される場合は、回答を増やす前にナレッジの正本を見直す
- 成果が下がったときは、会話数だけでなく未解決と離脱の位置を確認する
担当者へ引き継ぐ情報テンプレート
有人対応へ渡すときは、会話全文をそのまま送るのではなく、次の情報を短く整理すると担当者がすぐ対応できます。項目は業務に合わせて減らして構いませんが、何を相談し、どこまで確認し、次に何を望んでいるかは残します。
- 相談の目的：お客様が解決したいこと
- 現在の状況：利用中のサービス、検討段階、発生している問題
- 確認済みの情報：AIが案内した内容と、お客様の回答
- 未確認の事項：担当者が追加で確認する必要がある点
- 次の希望：電話、メール、予約、資料送付などの希望する連絡方法
公開後7日間の見直し
公開直後は、成果が出たかだけでなく、想定外の質問がどこで発生したかを確認します。1日目は自分で代表質問を試し、3日目は未解決ログを分類し、7日目に回答・導線・引き継ぎ条件のいずれを直すかを決めます。変更した箇所とテスト結果を記録しておけば、次の更新で同じ原因を調べ直さずに済みます。
- 代表質問と境界ケースを実際の画面で確認する
- 未解決・離脱・有人引き継ぎの会話を原因別に分ける
- 最も影響の大きい1箇所だけを修正する
- 修正前と同じ質問で再テストする
- 変更日・変更理由・確認者を運用記録に残す
導入判断のための確認質問
記憶するAIを活用するときの中心課題は、何でも覚えさせることではなく、次回の相談に役立つ情報だけを残し、踏み込みすぎない対応を設計することです。この方針を実際の業務へ取り入れるか判断するときは、機能の多さではなく、今ある問い合わせのどこを改善したいのかを先に確認します。目的が曖昧なまま設定を増やすと、導入後に成果を測れず、回答の修正も場当たり的になりやすいためです。
担当者間で合意しておく質問
- この仕組みで、最初に減らしたい作業や解消したい不安は何か
- お客様が自分で解決できる範囲と、専門家の判断が必要な範囲はどこか
- 回答の正しさを確認できる資料や画面はどれか
- 情報が古くなったとき、誰が、どの頻度で更新するか
- AIから担当者へ渡すとき、担当者が最初に知るべき情報は何か
- 公開後に改善の優先順位を決める人は誰か
現場で使う運用メモ
設定を公開した後は、回答の内容だけでなく、その回答がどのページや会話の入口から始まったかも記録します。同じ質問でも、初回訪問者と既存のお客様では必要な説明が変わることがあります。入口、質問、回答、次の行動を一組で残すと、どの部分を直すべきかをチームで共有しやすくなります。
また、改善のために個人情報を必要以上に保存しないことも重要です。分析に必要な項目だけを定め、閲覧できる担当者と保管期間を決めます。不要な情報を集めない設計は、運用負担を下げるだけでなく、お客様へ説明するときの分かりやすさにもつながります。
更新時には「何を変えたか」だけでなく、「なぜ変えたか」「どの質問で確認したか」「変更後に何を観察するか」を短く残します。将来、数値が変化したときに原因を追跡でき、別の担当者へ引き継ぐ場合も判断の背景が失われません。
改善前後を比べる方法
改善の効果を確認するときは、変更前と変更後で対象期間や質問の条件をそろえます。会話数が違うだけで良し悪しを判断せず、目的の回答へ進んだ割合、未解決になった割合、担当者へ渡った割合を同じ単位で比較してください。短期間の結果だけで結論を出さず、想定外の質問が増えていないかも確認します。
- 改善したい会話の種類と、観察する期間を決める
- 変更前の代表的な質問と指標を記録する
- 一度に変更する要素を一つに絞る
- 変更後に同じ質問と境界ケースで確認する
- 結果と次の仮説を記録し、次回の改善につなげる
数字が上がっても、回答の分かりにくさや引き継ぎの遅れが増えていれば、品質が改善したとはいえません。お客様が次の行動へ進めたか、担当者が状況を理解して対応できたかまでを確認して、記事で紹介する手順を自社の運用へ合わせて調整してください。