顧客文脈の注入 — 購入履歴と過去対応をAIに渡す

はじめに

AIに問い合わせの返信下書きを作らせるとき、多くの人はプロンプト（指示文）の工夫に力を注ぎます。もちろん大事なのですが、実際に下書きの品質を左右するのは、それ以上にAIに何を見せるか——つまり顧客文脈の注入です。

「先日購入した商品が届かない」という問い合わせに、AIが「ご注文内容を確認いたします」としか書けなければ意味がありません。何を、いつ買ったのかをAIが知っていて初めて、具体的な返信が書けます。

この記事では、返信下書きシステムがどんな情報をどう集め、プロンプトに組み込んでいるのかを解説します。

文脈がないと下書きは的外れになる

「一般論」しか書けないAI

問い合わせ文だけをAIに渡すと、返信はどうしても一般論になります。「配送状況はマイページからご確認いただけます」のような、間違ってはいないが役に立たない文章です。顧客は具体的な自分の注文について聞いているのに、テンプレートを返されている感覚を持ってしまいます。

これは人間のオペレーターでも同じで、顧客情報を見ずに返信することはありません。AIにも同じ材料を渡す必要があるんです。

「調べる時間」こそが対応のボトルネック

問い合わせ対応の時間の大半は、文章を書く時間ではなく調べる時間です。この顧客は誰で、何を買って、過去に何を問い合わせたか。この調査をAIに肩代わりさせることが、下書き生成の本当の価値だと考えています。

だからこそ、文脈収集は「あると便利」ではなく「これがなければ始まらない」中核機能です。

注入する情報の全体像

何を集めてプロンプトに渡すか

購入履歴と受注情報

まず取得するのが、EC受注管理システムからの購入履歴です。問い合わせをしてきた顧客のメールアドレスをキーに、直近の注文、購入商品、配送先住所、注文ステータスなどを引き出します。

「先日の注文」と書かれていても、システムが直近の注文を把握していれば、どの注文を指すかを高い確度で推測できます。AIはこれを踏まえて「〇月〇日にご注文いただいた△△の件ですね」と具体的に書き出せるようになります。

過去チケットのやり取り

同じ顧客が過去にどんな問い合わせをしたかも重要な文脈です。HubSpotから過去チケットの履歴を取得し、直近のやり取りをプロンプトに含めます。

これにより「前回サイズ交換をご案内した件」のような、継続性のある対応ができます。毎回ゼロから対応するのではなく、関係の積み重ねを踏まえた返信になるわけです。

商品名の照合

問い合わせ文中の商品名は、顧客の言葉なので表記が揺れます。略称だったり、色やサイズが省略されていたり。これをそのままAIに渡すと、存在しない商品を前提に返信してしまう恐れがあります。

そこで、問い合わせ文から商品名らしき部分を抽出し、商品マスタと照合してから渡します。正式名称や仕様に紐づけることで、下書きの正確性が上がります。

注入設計で気をつけていること

情報は「多ければ良い」ではない

文脈が大事だからといって、全データを丸ごと渡せばよいわけではありません。関係の薄い情報が混ざると、AIがそちらに引っ張られてノイズになります。トークン消費も増え、コストと速度に響きます。

そこで、問い合わせの内容に応じて「直近の注文だけ」「関連しそうな過去チケットだけ」と、渡す情報を絞る設計にしています。人間が対応するときに見る範囲と、だいたい同じ感覚です。

構造化して渡す

集めた情報は、ただ羅列するのではなく「購入履歴」「過去対応」「商品情報」とセクション分けして渡します。AIにとって情報の役割が明確になり、混同が減ります。どこまでが確定情報で、どこからが推測なのかも区別できるようにしています。

個人情報の扱い

顧客の住所や連絡先を扱う以上、取り扱いには注意が必要です。プロンプトに含める情報は下書き生成に必要な範囲に限定し、生成された下書きも社内のチケットノートに留まります。外部に不用意に流れない設計にすることが前提です。

まとめ

的外れな下書きを防ぐ鍵は、プロンプトの言い回しよりも顧客文脈の注入にあります。

• 購入履歴・過去チケット・商品照合という3つの文脈で下書きが具体的になる
• 対応の時間を食う「調べる作業」をAIに肩代わりさせるのが本質的な価値
• 情報は絞って構造化して渡し、個人情報の残り先まで設計する

集めた文脈をどう活かすかは、問い合わせの「意図」によって変わります。次は問い合わせ意図の分類で、意図別に回答の型を出し分ける仕組みを見ていきましょう。全体像はハブ記事で解説しています。