Curtis 応対品質 — ゲスト体験の尺度と改善ループ

2026-08-06 / 3AI照会(ChatGPT・Gemini・Grok)を統合して設計 → 実装 → 2周実測済み

「判定が正しいか」ではなく「その方は助かったか」を数える物差しを新設しました。ご指定の3軸(問題解消/ラグジュアリー水準のホスピタリティ/感情の軌跡)を 0-4 の段階尺度に落とし、22人のロールプレイを採点 → 弱点2つを特定 → 修正 → 再測定、まで今日のうちに1周半回しています。

01 | 尺度(体験審査役)

既存の「欠陥監査」(枠の突破・作り話を見る守りの検品)とは別レイヤーとして立てました。守りの検品に体験の点数を混ぜると両方濁るためです。

何を測るか4点0点
解決度
0-4
解決した or「次の一歩」が決まって終わったか。人への引き継ぎは減点しない。減点するのは行き止まりだけ解決/引き継ぎでも「誰が・何を・いつ頃・その間どうするか」まで明確「できません」「朝までお待ちください」で閉じ、代わりの道が無い
ホスピタリティ
0-4
敬語の量ではなく、先回り・個別化・「こちらでお預かりする」所有感・品位ある温度背後の意図を汲む/質問最小/断るときも代替の道が中心突き放し・責任回避・ゲストを疑う
感情の軌跡
0-4
ネガ起点の会話のみ。AIの文面が優しいかではなく、ゲスト側の発話が実際にどう変わったか沈静化し感謝・安心・協力へ転じた「話が通じない」「責任者を出して」へ悪化
行き止まり
フラグ
会話の終わり方が「解決/次の一歩が確定/人が動いていると伝わり会話も開いている」のどれでもない=🔴。北極星第3段の達成指標そのもの。目標は全会話0件
判定ノイズへの備え(Gemini案を採用・全部実装済み): ①スコアの前に会話からの引用を強制(先にスコアを書かせると根拠を捏造する) ②引用が会話に実在するか・行き止まりとスコアが矛盾しないかを機械で検査し、落ちたら1度だけ引き直す ③成績として追うのは平均ではなく行き止まり件数・ワーストケース件数(相手役の即興でブレない指標だけ) ④この採点基準を Curtis 本体のプロンプトへ移植しない(判定に好かれる文面への過学習=慇懃無礼な無個性AIを防ぐ)。

02 | 改善ループの回し方

①ロールプレイ実測(22人)→ ②欠陥監査+体験採点 → ③低評価の指摘を1件ずつ現物と突き合わせ(判定役の誤りを本物と混ぜない)→ ④本物だけ直す → ⑤検証108本+再測定。今日この輪を2周回しました。

node scripts/line_concierge/eval/simulate.mjs → node scripts/line_concierge/eval/experience.mjs

03 | 今日の実測 — 見つけて直した2つ

弱点1: 連絡先ブロックの完全同一繰り返し(壁)

締め出しの会話で「一斉にお知らせ+番号+夜間早朝を問わず」の同一ブロックが3〜4通連続していました。2度目の提示から前置きを畳み、お知らせを継続形に変更(番号自体は命綱なので毎回置く)。

弱点2: 緊急の会話の途中で、別ルールに当たると調べもせず定型文(行き止まり)

締め出された会員様が2通目で「施設名わかりません。予約確認のメールが見れない」→「予約」の語で1層目が発火し、SoTを一度も引かずに定型文で終了していました。「一度立った緊急は会話の間降ろさない」を assist 判定に配線し、緊急中はどのルールに当たっても先に調べてから人へ渡すようにしました(本番でも実測確認済み)。

Before: ご予約の件、承りました。担当者へ一斉にお知らせいたしました。(→ 朝まで放置)
After(本番実測): 施設名が分からないと、キーボックスの位置・番号は施設ごとに異なるためご案内できません。ご予約の際のアプリ・SMS・LINEの過去のご案内などで、施設名の手がかりをご確認いただけますでしょうか。分かり次第、鍵の開示番号を含めてご案内いたします。

採点の推移(同じ9人の難関ペルソナ)

会話改善前改善後
渋谷と京都を間違えた会員様解決1・接遇1・🔴行き止まり解決4・接遇3・感情4
酔って番号を忘れた会員様解決2・接遇2・🔴解決4・接遇3・感情4(「入れた入れた〜」で終了)
締め出し(施設名不明)解決0・接遇1解決0のまま(下記「残る課題」)

※ 相手役が即興のため点は周ごとに揺れます。安定して見てよいのは行き止まり件数と機械検査(今回も機械の重大指摘は全周0)。判定役が挙げた critical 3件は現物と突き合わせた結果3件とも判定役の誤りでした(例:「正しくは2320」→ 館山の正本は9133でCurtisが正しい)。

04 | 残る課題 — コードでは解けない1点

「番号でも開かない・電話も出ない」の末端で、Curtis に打つ手が構造的にありません。凍えている会員様に対し、現状の最終手段は「担当者へ重ねてお知らせ」だけ — しかし一斉通知の Slack チャンネル(SLACK_CONCIERGE_CHANNEL)が未設定のため、このお知らせは実体を伴っていません。ここが埋まらない限り、最悪ケースの行き止まりは尺度をどれだけ磨いても消えません。現地駆けつけ(近隣スタッフ・警備会社)の運用を定義するかどうかも、あわせて Otake さん判断の領域です。

05 | 多AIの使い分け