会話をまたぐ文脈の持ち方

チャット形式のAI機能は、作り始めは単純に見えます。利用者の発言をAIに送り、返答を表示する。それだけです。問題が出るのは、会話が続いたときです。

既存のAI APIには、前回のやり取りを覚えておく機能はありません。毎回の呼び出しは独立しているため、文脈を保つにはこちらが過去のやり取りを毎回送り直すことになります。ここに、費用・速度・品質のすべてが関わってきます。

全部渡す作りが壊れる三つの理由

最も素直な実装は、それまでの会話を全部つなげて毎回送る方法です。動きますが、次の三つで行き詰まります。

費用が伸び続けます。 一往復目は短くても、十往復目には十往復分の履歴が入力に乗ります。入力は送った量に課金されるので、会話の後半ほど一回あたりの単価が上がります。長い会話が常態化するサービスでは、これが費用の大部分を占めます。詳しくはAI利用料が膨らまない設計で扱いました。

応答が遅くなります。 入力が長いほど処理に時間がかかります。会話が進むにつれて返答が遅くなるのは、利用者から見ると原因の分からない劣化です。

いずれ上限に当たります。 AIには一度に扱える量の上限があります。超えた瞬間、それまで動いていた機能が突然失敗します。しかも失敗するのは、そのサービスを最もよく使っている利用者からです。

何を覚えさせるかを決める

対処の出発点は、「履歴をどう圧縮するか」ではなく、次の応答に本当に必要な情報は何かを考えることです。

多くのチャット機能で、実際に必要なのは会話の全文ではありません。必要なのは概ね次の三種類です。

• 役割と方針：どういう立場で答えるか、何を答えてはいけないか。毎回同じ内容なので、短く保ちます。
• 確定した事実：会話の中で分かった利用者の状況。「サービスAの利用者」「東京在住」「先週注文した商品について問い合わせている」など。
• 直近のやり取り：いま話している内容の流れ。数往復あれば足ります。

このうち、確定した事実は会話の文章として持つ必要がありません。項目として記録しておき、次の呼び出しでは箇条書きにして渡せば、同じ効果をはるかに短い入力で得られます。これは自社のデータベースに書く話であり、AIに覚えさせる話ではありません。

覚えておく項目をあらかじめ決める、というのがここでの設計判断です。自由に何でも覚えさせるより、業務上意味のある項目を決めておくほうが、費用も、動作の予測しやすさも、そして削除の管理もしやすくなります。

履歴の扱い方の選択肢

直近のやり取り以外をどう扱うかには、いくつかの方法があります。手間の小さい順に並べます。

多くのサービスでは、上の二つの組み合わせで十分です。直近の数往復＋決められた項目という形が、実装の手間と効果の釣り合いが最もよく取れます。

三つ目の要約は、会話が長く続く前提の機能で有効ですが、要約のたびにAIを呼ぶので費用がかかります。また要約の過程で情報が落ちるため、落ちては困る項目は別に保持しておく必要があります。四つ目は仕組みが大きくなるため、それを必要とする事業上の理由がはっきりしてから検討する領域です。

会話をいつ切るか

見落とされがちですが効果の大きい設計が、会話の区切り方です。

一つの会話がいつまでも続く作りだと、履歴は伸び続けます。一方、業務上は明らかに区切りがあります。問い合わせが解決した、注文が完了した、日付が変わった、といった区切りです。

決めておきたいのは次のあたりです。

• 時間で切る：一定時間操作がなければ、次は新しい会話として始める
• 目的の達成で切る：手続きが完了したら会話を閉じ、新しい話題は新しい会話にする
• 利用者が切れるようにする：「新しい会話を始める」ボタンを置く

三つ目は単純ですが有効です。利用者自身も、前の話を引きずらないほうが意図した答えを得やすいと分かっているため、明示的な選択肢があると使われます。あわせて、会話の切り替えで何が引き継がれ何が消えるかを画面で分かるようにしてください。前の話を覚えていると期待していたのに覚えていない、という体験は不信につながります。期待値の伝え方はAI機能の画面の作り方で扱います。

保存と削除を決める

会話履歴は、自社のデータベースに残ります。ここは費用ではなくリスクの話です。

会話には、利用者が自発的に書いた個人的な情報が混ざります。問い合わせの経緯、体調、家族構成、勤務先。フォームでは絶対に集めないような情報が、会話では自然に入ってきます。したがって、保存の設計は入力の設計と同じ重さで扱う必要があります。

決めておくべきことは次のとおりです。

• 保存する目的：品質改善のためか、利用者が見返すためか。目的のない保存はしない
• 保存期間：期間を決め、過ぎたものは自動で削除する
• 閲覧できる人：社内の誰が会話履歴を見られるか、その記録が残るか
• 利用者による削除：会話を消せる手段と、消したときに何が消えるか

外部のAI APIへ送る側の扱いはAIに渡す前の入力チェックで述べたとおりですが、自社に残る側も同じ方針で整理してください。スタートアップのセキュリティと個人情報保護の考え方が当てはまります。

会話でなくてよいかを疑う

最後に、立ち止まって考えたい点があります。その機能は本当に会話形式である必要があるかです。

チャットの見た目は親しみやすく、企画として通りやすいのですが、利用者から見ると「何を聞けばよいか分からない」「何度も聞き返される」という負担になることがあります。聞き取る項目が決まっているなら、フォームのほうが速く、正確で、安く、そして文脈の設計そのものが不要になります。

会話形式が向くのは、利用者の要望が事前に定型化できない場合、聞き取るべき内容が相手によって変わる場合、そして自然文で書くほうが利用者にとって楽な場合です。この条件に当てはまらないなら、従来の画面設計のほうが結果として満足度が高くなることは珍しくありません。

弊社は既存のAI APIを組み込む開発を行う立場として、この「そもそも会話にすべきか」から検討します。会話にしない判断をご提案することもあり、そのほうが費用も運用も軽く収まります。

AI活用開発やWebシステム開発で、チャット機能の設計を検討されている場合はお問い合わせからご相談ください。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。