Jevとは？店舗の問い合わせを安全に仕分ける3つの準備
問い合わせ対応をAIに任せたいけれど、誤返信が心配。Jevの特徴を踏まえ、分類を決める、架空の例で試す、迷うものを人に戻すという小さな始め方を紹介します。
この記事でわかること
予約の相談、商品の質問、営業メールが同じ受信箱に届く。読む順番を決めるだけで時間が過ぎ、返事が遅れてしまう。
小さな店舗や会社では、文章を書く前の「これは誰が見るものか」という整理も負担になります。先に結論をお伝えすると、AI活用の入口は自動返信ではなく、問い合わせの仕分けです。
Jevは、あらかじめ決めた選択肢や数値の形式で判定を返すAIです。分類だけを小さく試し、人が確認してから次へ進めるなら、失敗の影響を抑えて使い方を学べます。
この記事の例は導入効果を実測したものではなく、店舗で検証するときの設計例です。すぐに無人対応へ置き換える提案ではありません。
Jevは、問い合わせを指定した分類へ振り分ける用途で検討できます。
二つの方法を比較
TypeSafe AIは9月21日、Jevを待機リストなしで利用できるようになったと発表しました。公式の開発資料では、入力した状況に対して、決めた候補から選ぶChoice、基準に沿って点数を付けるScore、ある条件が成り立つ度合いを返すNoulを案内しています。
たとえば、問い合わせの文章から「予約」「商品」「その他」のどれに近いかを選ぶ仕事です。自由な返信文を作らせるのとは異なり、結果を受け取る側の仕組みで、担当者の一覧へ回すなどの処理を決めます。
Jevを契約すれば店舗のメールが自動で片付く、という完成済みの接客サービスではありません。9月18日のVercel公式記事も、決まった形式の判定を返し、不確かな場合に人の確認へ回す用途を説明しています。
提供範囲が広がったことと、自社で正しく使えることは別です。接続や運用を作る技術担当者と、現場で確認する担当者の両方が必要になります。
これは提供元の発表内容です。利用開始時の接続状況やアカウントごとの条件は、その時点の公式案内で確認してください。
整理の補助と、お客様への約束を切り離します。
受信箱を仕分け棚に置き換えると考えると、役割が分かりやすくなります。棚に入れる場所を間違えても、人が読み直して戻せます。
一方、空き状況を確認せず予約を確定したり、誤った価格を返信したりすると、お客様との約束まで変わってしまいます。そこで最初の検証では、AIは分類候補を表示するだけにします。
返信、予約変更、返金、データ削除はつなぎません。「予約」と判定されても予約が成立したわけではない、とスタッフにも共有します。
教室なら「体験希望」「持ち物の質問」「その他」、物販店なら「在庫」「配送」「その他」のように、実際の担当分けに合わせます。分類を細かく増やすより、誰が読むかを決められる少数の区分から始める方が、間違いの原因も見つけやすくなります。
たとえば「来週の体験を申し込みたい。料金も知りたい」という一通は、予約と料金の両方を含みます。
どちらか一方へ入れるだけでは、質問が取り残されるかもしれません。このような例は確認用の一覧へ置き、人が二つの用件を読み取る設計にします。
分類は内容を省略してよいという許可ではありません。
本番のメールをつなぐ前に、小さな試験表を作ります。
本番接続前のチェック
一つ目は、分類名と意味を一文で書くことです。「予約」は新規予約の相談、「商品」は仕様や在庫の質問と定義します。
同じ文に二つの用件がある場合、情報が足りない場合、どの区分にも合わない場合は、人が確認する扱いにします。二つ目は、架空の問い合わせを10件ほど作ることです。
「土曜に2名で利用できますか」「この商品の色違いはありますか」に加え、「前の件はどうなりましたか」のように文脈が欠ける例も入れます。実在する名前、電話番号、注文番号を使う必要はありません。
三つ目は、人が先に付けた正解候補と、AIの分類を表で比べることです。用件が一つの例だけでなく、複数の相談、誤字、対象外の営業メールも混ぜます。
意見が割れた例はAIの問題と決めつけず、分類ルール自体が曖昧でないかを見直してください。試験表には「例文」「人の分類」「AIの分類」「確認が必要な理由」を残します。
10件は始めるための例であり、品質を保証する件数ではありません。試験に使った文だけで判断せず、別の架空の例でも確かめます。
迷う判定を止める条件と、人が確認する担当を決めておきます。
公式資料では、ChoiceとScoreが返すconfidenceは、候補ごとの確率分布から計算する指標です。たとえば0.9と表示されたから、この店で必ず9割正しいという意味にはできません。
自社の用件でどんな間違いが起きるかを別に確認する必要があります。低い値なら人へ戻す、といったルールは役立ちますが、境目の数値は業務と試験結果に合わせて決めます。
最初の検証では高い値でも全件を人が確認します。苦情、支払い、契約変更など影響が大きい用件は、分類値にかかわらず確認対象にする運用が考えられます。
入力データの扱い、保存期間、利用条件は、使う提供元と契約ごとに確認してください。確認が済むまでは架空データだけで試します。
担当者が不在の場合や接続に失敗した場合は、通常の受信箱で対応を続けられるようにし、問い合わせを失わない手順も必要です。実際に担当者へ通知する段階でも、元の本文を読める状態を保ち、分類だけを見て処理を終えないようにします。
確認用の一覧にたまったままにならないよう、誰がいつ見るかも決めます。新しい仕組みを入れた結果、確認の担当が曖昧になることを避けるためです。
Jev導入の前に、分類と人の確認を分けることが第一歩です。
Jevを使うかどうかを決める前でも、問い合わせの分類名と、判断に迷う例を書き出す作業は役立ちます。曖昧な用件をどこへ戻すかが分かると、スタッフ同士の引き継ぎもしやすくなります。
効果を見るときは分類の正しさだけでなく、確認時間、見落とし、担当者間の再転送も記録します。仕分けが速くても、読み直す手間が増えれば改善とは言えません。
noticaでは、小さな事業者が続けやすい情報整理や問い合わせ導線を一緒に考えています。まず一つ整理するなら、どんな問い合わせが一番多いでしょうか？