AIオペレーター（ボイスボット）の導入検討で、最初に話題になるのはたいてい「どんなシナリオを作ればいいか」「プロンプトをどう書けばいいか」です。生成AIの登場でAIオペレーターの応答品質は劇的に上がり、作ること自体のハードルは大きく下がりました。だからこそ、まずプロンプトを書いてみよう、となりやすい。

しかし、私たちが導入の現場で見てきた失敗の多くは、プロンプトの巧拙が原因ではありません。「うまくいかない時に、AIオペレーターがどう振る舞うか」が誰とも合意されないまま作り始めてしまったこと。原因はほぼここに集約されます。

この記事では、KARAKURI voice agentのプロダクトマネージャー・川端が提唱し、実際の導入プロジェクトで運用している体験設計書という方法論を解説します。

シナリオを作り込むほど、例外に弱くなる

従来型のボイスボット構築は、シナリオの網羅を目指す発想でした。

想定される用件を洗い出し、分岐ツリーを描き、それぞれに応答文を割り当てる。用件が10種類あれば10本のシナリオを書く。丁寧に見えるアプローチです。

ところが人の電話は、想定の外側から掛かってきます。途中で言い直す。用件が2つある。そもそも何に困っているのか本人も整理できていない。シナリオを増やして網羅しようとするほど分岐は複雑になり、メンテナンスは重くなり、それでも例外は残り続けます。

この認識は、すでに業界共通のものになりつつあります。

米国のDecagonは、分岐ツリーを「現実のあいまいな問い合わせの前では崩壊する構造」と位置づけ、人間のオペレーターがSOP（標準業務手順書）を頼りに動くように、AIエージェントにも自然言語で書かれた手順書が必要だとしてAOP（Agent Operating Procedures）を提唱しています。

分岐を網羅するのではなく、業務のロジックを自然言語で記述し、AIに解釈させる。世界のトッププレイヤーが同じ結論にたどり着いています。

いまのAIオペレーターは、この「網羅」から解放されています。発話をそのままナレッジ検索に渡し、結果をもとに音声向けの応答を組み立てる。シナリオの分岐ツリーはもう要りません。ではAIオペレーターの構築において、人が設計すべきものは何も残っていないのでしょうか。

そうではない、というのが私たちの立場です。設計の対象が変わっただけです。

品質は「うまくいかない時の振る舞い」で決まる

理想的にうまくいった通話——挨拶、用件のヒアリング、ナレッジ検索、回答、解決確認、終話——は、いまのAIなら比較的すんなり実現できます。デモで見せられるのもこの部分です。

差がつくのはその外側です。無音が続いたら何回聞き返すか。ナレッジでヒットしなかったらどうするか。クレームや感情的な発話が来たら検索スコアに関わらず人につなぐか。閉じ込めや故障のような緊急用件は最初から有人に振るか。「人に代わってほしい」と言われたら即座に応じるか。

これらはプロンプトの書き方の問題ではなく、業務としてどう振る舞うべきかの意思決定です。しかもその多くは、ベンダーが勝手に決められるものではなく、導入企業の現場と合意しなければ決まりません。

エスカレーションを早めに倒せばボット完結率は下がり、遅めに倒せば顧客を待たせるリスクが上がる。どちらに倒すかはトレードオフの選択であり、技術の問題ではないからです。

うまくいく通話はAIが担保する。うまくいかない通話をどう扱うかは人が決める。この意思決定を導入前に文書化し、顧客と合意するための道具が体験設計書です。

体験設計書とは何か

体験設計書は、AIオペレーターの仕様書ではありません。電話の向こうの顧客に、通話開始から終話までどんな体験をしてほしいかを定義する、顧客の体験の設計書です。

目的、前提となる運用環境、全体フロー、成功フロー、エスカレーション設計、異常系・例外対応、KPI、トーン＆マナー、そして未合意の残論点。この9章で構成されますが、中心にあるのは常に「顧客にどういう形でAIオペレーターを活用してもらいたいか」という問いです。

生成AIの進化で、シナリオ通りに動くことを保証する価値は下がり続けています。

実はこの発想には先例があります。コールセンターのなかには、オペレーターにトークスクリプトだけを渡すのではなく、「こういうふうに振る舞ってほしい」「こういうふうに案内してほしい」という文章を併せて渡すセンターがあります。体験設計書は、その文化をAIに引き継いだものです。

作る順番には型があります。

第一に、現状を聞く。受電チャネル、営業時間、受電件数、主な用件、平均処理時間。AIオペレーターの話をする前に、いまの電話業務の姿を数字で押さえます。

第二に、成功フローを1本描く。理想的にうまくいった通話を一直線で描き、「AIオペレーターが何をしたら成功か」を明確にします。ここが設計の背骨になります。

第三に、分岐と異常系を足す。ここが最重要です。エスカレーションのタイミングを「早め・中間・後め」の選択肢で示し、どれに倒すかを顧客と議論して決める。無音、誤認識、システム障害といった異常系の挙動も一つずつ定義します。導入プロジェクトで最ももめる部分であり、だからこそ最初に合意すべき部分です。

第四に、数字と禁止事項で締める。ボット完結率や平均対話時間といったKPIで成功の定義を数値化し、誤情報の断定や個人情報の扱いなど、やってはいけないことを明文化します。

もう一つ、この方法論らしい特徴が「残論点」の章です。決まっていないことを空欄で残さず、未合意である事実ごと文書に書く。これはAIオペレーター自身に読ませるための情報ではありません。

顧客、カラクリ、そしてプロンプトを作るAIエージェントの三者が「何がまだ決まっていないか」を共有するための情報です。プロンプトもテストも、そこを未確定のものとして扱えるようになります。設計書は完成品ではなく、合意の現在地を写すスナップショットだという考え方です。

DecagonのAOPと並べると、体験設計書の位置づけはより明確になります。AOPは「AIがどう動くか」を定義する実行レイヤーの手順書であり、返金や本人確認のような重要操作をコードで検証するガードレールを備えています。

体験設計書が扱うのはその一つ手前、「どう動くべきかを、誰と、どこまで合意したか」を残す合意レイヤーです。エスカレーション設計や禁止事項の章は、AOPのガードレールと同じ問題意識を、実装より前の合意の段階で解いているといえます。

手順書がどれだけ精緻でも、その内容が現場と合意されていなければ、リリース後に書き直すことになるからです。

現場ではこう使われている

全国300店舗超を展開する、ある24時間営業の店舗チェーンの導入検討では、夜間の店舗からの受電を対象に体験設計書を作成しました。目指すのは問い合わせの最大7割の自動化です。

この案件で体験設計書が効いたのは、エスカレーション基準の議論でした。

現状の平均通話時間が約90秒と短いため、AIオペレーターが粘るほどかえって効率が落ちる。そこで「検索スコアが低ければ1回目で即転送」から「複数ターン粘る」までの選択肢を文書上に並べ、通話時間の制約とボット完結率のトレードオフとして顧客と一緒に検討する。

クレーム系は初期リリースでは全件エスカレに倒す。緊急用件は最初から有人にする。こうした判断が、開発が始まる前にすべてテーブルに載りました。

体験設計書がなければ、これらは「リリース後に発覚する不具合」として一つずつ表面化していたはずです。文書が先にあることで、同じ論点が「導入前に合意できる設計判断」に変わります。

そして合意された設計書は、そのままプロンプトの仕様書になり、テストケースの基準になり、リリース後の改善では実測値と目標値を突き合わせる台帳になります。

私たちは「合意してから作る」

私たちは、AIオペレーターは「作ってから直す」ものではなく「合意してから作る」ものだと考えています。合意された体験設計書は、実際に使うプロンプトやツールを作るためのインプットとして機能します。

あえてプロンプトとは別の文書で残しているのには、人と合意するため以外にもう一つ理由があります。モデルの変更に対応しやすくするためです。

AIモデルのアップデートに追従するとき、プロンプトからプロンプトへ直接移植すると、行間に埋まっていた意図が抜け落ちるケースがあります。体験の全体が文書として定義されていれば、移植ではなく作り直しができる。

最新モデルの良さを活かしながら、体験設計書に基づいたより良いプロンプトを再生成できます。合意のための文書は、モデルが入れ替わっても劣化しない、体験の原本でもあるのです。

生成AIは、AIオペレーターを作ることを簡単にしました。しかし簡単に作れるようになったからこそ、何も合意しないまま作られたAIオペレーターが現場に増えています。

デモは感動的だったのに、本番で顧客を怒らせる。その差は技術力ではなく、うまくいかない時の振る舞いを事前に決めたかどうかです。

AIに電話を任せる前に、うまくいかない時の振る舞いまで、顧客と文書で合意できているか。AIオペレーターの導入を検討しているすべての企業に、この問いを置きたいと思います。

体験設計書の実物やデモに関心のある方は、お気軽にお問い合わせください。