チャットボットを付けると、メーターが一つ増える

訪問者が一行打つたびにメーターが回る

画面にチャット欄を一つ置くと、訪問者が文字を入れるたびにその欄は外にある言語モデルへ要求を送る。要求一回ごとに値が付く。ここまでは大半が知って始める。ずれ始めるのは、その値が質問の数に比例しないという点だ。

モデルは前のやり取りを覚えていない。会話が続いているように見えるのは、そこまでのやり取りを毎回まるごと積み直して送っているからだ。だから十回目の質問は、打った文字数が一回目と同じでもメーターには大きく刻まれる。一回の要求に載るのは三つある。訪問者が打った文、モデルに役割と禁止事項を指示しておく自分たちの文の束(システムプロンプトと呼ぶ)、そしてモデルが返した答え。

費用を下げる余地も、だから機能一覧ではなく会話の設計の側にある。一つの会話を何往復まで続けさせるか、古いやり取りをどこで切り捨てるか、毎回同じまま出ていく指示文をキャッシュで節約するか。この判断が範囲の文書に無いと、後で請求書のほうから知らされる。

「自社の内容を知っているチャットボット」に付いてくるもの

相談はたいていこの一文で届く。モデルは自社を知らないので、質問が来るたびに自社の資料から該当箇所を探して一緒に渡す仕掛けを別に作る。資料を集め、断片に切り、検索できるように索引を作り、質問ごとに合う断片を選んで添える作業が、全部この仕掛けの中にある。見積もりが分かれるのは資料の状態だ。整ったウェブページや文書から取ってくるのと、スキャンしたPDFや部署ごとに書式の違う表から取ってくるのは、同じ作業ではない。

この仕掛けは一度作って終わりでもない。価格や規定が変わるたびに索引を作り直す必要があり、作り直さなければボットは先月の内容を自信たっぷりに答える。誰が資料を更新して何日で反映されるかを決めていないと、誤答の半分はここから出る。

変な答えをもらった客は教えてくれない

チャットボットは知らないことも文にして答える。値が無ければ空けておく代わりに、それらしいもので埋める。だから付ける前に決めるのは正答率の目標ではなく、対処の手順だ。会話の記録が残るのか、残るなら誰がいつそれを読むのか。

記録がなければ壊れていること自体が分からない。客は変な答えをもらっても言ってこない。窓を閉じて出ていく。

境界も一緒に引いておく。返金できるのか、いつ届くのか、いくらなのか。守れなければもめる話は、チャット欄で答えさせずに人へ渡す。人に渡るボタンとそのボタンが出る条件を最初に一緒に作っておくと、後で謝罪文を書く回数が減る。

表示の一行は開発ではなく確認事項だ

EUの利用者を受けるサービスなら、EU AI法の透明性義務が2026年8月2日から適用される。AIとやり取りしていることを利用者に知らせ、生成物にはそれが生成されたものだと示す義務だ。日付の出どころは欧州委員会が公開している施行の時間表にある。自分の市場に別の規定が加わっていることもあるので、公開した後ではなく前に確かめておく。文言一行なので作る費用はほとんど付かない。どの画面のどこにどう書くかを、作り終えた後ではなく画面を描く段で決めておくほうがいい。

モデルが変わる日、コードは無事だ

外部サービスの連携は、相手が仕様を変えれば目に見えて壊れる。言語モデルはそう教えてくれない。呼び出し方はそのままで、答えの性格が動く。新しい版に乗り換えれば同じ質問に別の言い回しが返り、古い版を抱えていればいつか終了予告が付く。コードは一行も直していないのに、答えを検収し直す日が来る。だから代表的な質問を二十件ほど、望む答えと一緒に書いておいて、モデルに手を入れるたびにその二十件を回し直す。この一覧が無いと、判断の根拠が「なんとなくおかしい」しか残らない。仕様そのものが壊れる側の話は連携は一度成功してからが範囲になるに書いた。

どこまで聞かせるかから一緒に決めます

付けるかどうかをまだ決めていない段階でも相談になります。Weple のAI機能開発は、何を聞かせるか、どこで人に渡すかを先に描いて、その図の上で作る値段と毎月出ていく分を分けて書き出します。よく届く質問の一覧や案内文書があればそこから始め、無ければ問い合わせのメールボックスを一緒に見るところから始めます。作業の単位は料金案内に書いてあります。最初の会話でこちらが先に数えるのは、質問の件数ではなく一つの会話が何往復するかです。