チャットボットのシナリオ設計：確認と回答不能時の対応、人への安全な引き継ぎ

チャットボットのシナリオ設計では、回答できる場合、確認が必要な場合、根拠が不足する場合、人に判断を委ねる場合に、ボットが何を伝えるかを定めます。利用者の課題を出発点にして、各経路を分かりやすい言葉で書き、それぞれで実際に何が完了するかを定義します。引き継ぎメッセージでは、要約を準備した段階と、受け手が受領を確認した引き継ぎを区別する必要があります。

執筆：Ai Flowi · 公開日

このガイドでは、問い合わせ窓口向けに、コピーして使える会話ツリーと四つの会話例を提供します。対話の基本概念は 会話型AIを、承認済みの回答を取得する方法は ナレッジベースチャットボットのガイドを参照してください。

1. 一つのタスクと、根拠に基づいて答えられる範囲を定める

ワークショップの会場や持ち物の確認など、範囲を限定した問い合わせを選びます。ボットが伝えてよい情報と、人が行うべき判断を書き出します。会場を回答できても、予約の変更が許可されるわけではありません。引き継ぎを案内する表現を使う前に、人によるレビューの依頼先を決めます。

架空の学習用資料： 架空のBirchワークショップには、根拠カードCARD-Bの改訂版Aがあります。承認済みの文章の全文は次のとおりです。 BirchワークショップはCedar室で開催します。ノートを持参してください。予約の変更にはコーディネーターのレビューが必要です。 到着時刻とコーディネーターの対応可否は記載されていません。これらの架空の情報は例だけに使用するもので、Ai Flowiのサービスや実際のイベントを説明するものではありません。

レビュー担当者が表現を照合できるよう、各回答にカードの識別子を添えます。出典が変更されたり確認できなくなったりした場合は、その内容を最新情報として提示するのをやめます。情報の欠落は根拠の不足であり、資料を読めないことはアクセスの失敗です。どちらも正直な回答が必要ですが、レビュー用の資料では区別を残します。

関連情報：カンバセーショナルコマース とは：問い合わせと取引の境界。

2. 問い合わせ用の会話ツリーをコピーする

このツリーは編集上の仕様であり、実行可能な分岐コードではありません。メッセージを調整する前に、出典とレビュー先を記入します。「End」は、この対話の試行が終わることを意味します。元の依頼が解決したことを意味するものではありません。

ENTRY
State the permitted task and ask for the enquiry.
After each enquiry or clarification reply, go to
CHECK REQUEST AND AUTHORITY.

CHECK REQUEST AND AUTHORITY
If the user wants to stop: END without preparing a packet.
If the user requests a person or an action outside scope:
  Go directly to HANDOFF DRAFT, even if an answer is available.
Otherwise: go to CHECK SUBJECT.

CHECK SUBJECT
If the subject is clear: go to CHECK EVIDENCE.
If unclear after the one clarification: go to UNKNOWN.
Otherwise CLARIFY: ask one question needed to choose the answer.
On reply: return to CHECK REQUEST AND AUTHORITY.

CHECK EVIDENCE
If an applicable approved passage answers the enquiry:
  ANSWERED: give that answer and its source reference; end.
Otherwise: go to UNKNOWN.

UNKNOWN
Name the missing, inaccessible or conflicting evidence.
Go to HANDOFF DRAFT to offer a review summary.

HANDOFF DRAFT
Offer a summary; if declined, END without a packet.
If accepted, include the enquiry, known subject, source status
and open decision.
Leave an unknown subject unknown; do not require clarification.
Let the user correct or approve the summary.
Mark it PREPARED: no transfer has occurred.
Only after summary approval and transfer permission may an
authorised person move it to the agreed review destination.
Record acknowledgement separately; then END this attempt.

この演習では、確認の質問を一回行った後、レビューを提案します。これは選択した設計上の上限であり、実測で得られた最適値ではありません。利用者がいつでも対象を修正し、人による対応を求め、やり取りを終了できるようにします。これらを選ぶために、無関係なメニューを通らせてはいけません。

3. 四つの応答状態をテキストの会話例でレビューする

以下は説明のために作成した架空の会話例であり、ボットの出力記録ではありません。話者名と完全な文で意味を伝えるため、吹き出しの色、アイコン、図に依存しません。

回答済み：根拠のある事実だけを伝える

User: Where is Workshop Birch?
Bot: Workshop Birch meets in Room Cedar. Source: CARD-B,
revision A, venue sentence.

会場は根拠で確認できますが、道順、到着時刻、建物への入館方法は提供されていません。親切に見える案内を追加すると、回答が根拠の範囲を超えてしまいます。出典との対応が明確に分かる程度に、回答を短く保ちます。

曖昧：不明な対象を尋ねる

User: What should I bring?
Bot: Which workshop are you asking about?
User: Birch.
Bot: Bring a notebook to Workshop Birch. Source: CARD-B,
revision A, materials sentence.

ワークショップ名を尋ねるのは、それによって参照する出典が決まるためです。電話番号、アカウントの認証情報、詳しい個人の経歴は求めません。対象が既に明確なら、もう一度尋ねても不確実性は解消されず、手間が増えるだけです。

不明：利用できない情報を具体的に伝える

User: What time should I arrive for Workshop Birch?
Bot: CARD-B does not give an arrival time for Workshop Birch.
I can prepare that unanswered question for manual review.
Would you like a summary?

このチャットボットの回答不能時のメッセージは、不足している情報を明示し、次の具体的な選択肢を示します。質問を言い換えても存在しない情報は得られないため、「もう一度お試しください」という案内は避けます。利用者が要約を受け入れても、その問いは未解決のまま保持します。

有人への引き継ぎ：現在の段階を明示する

User: Please change my Birch booking. I want a person.
Bot: Booking changes require coordinator review under CARD-B.
I can draft your request for you to check. Nothing has been
sent, and coordinator availability has not been confirmed.
User: Yes, prepare it.
Bot: Draft: “Request for coordinator review: change a Birch
booking. The requested change still needs clarification.”
Please correct this summary before manual transfer.

人と話したいという依頼は、直接この経路に進める必要があります。下書きの準備の段階では、まだ予約の識別子は必要ありません。後で確立されたレビュー手順に本人確認が必要となる場合は、その手順を通じて、必要な理由を説明したうえで情報を収集します。

関連情報：チャットボットと有人チャットの違い：応答の責任と引き継ぎ範囲を決める。

関連情報：不動産 チャットボット：物件の問い合わせと引き継ぎ。

4. 手動で引き継ぐ資料を明確にする

この資料を会話ツリーと一緒にコピーします。観察した事実と、レビュー担当者が行うべき判断を分けます。この例は意図的に未完の状態です。利用者は下書き作成には同意していますが、最終的な要約も、その引き継ぎも承認していません。

Packet reference: PRACTICE-B
Subject: Workshop Birch
User request: booking change; human review requested
Source inspected: CARD-B, revision A, change sentence
Supported boundary: coordinator review required
Missing detail: the specific requested change
Drafting choice: user accepted
Summary correction/approval: pending
Transfer permission and destination: not confirmed
Transfer status: prepared only; not sent
Recipient acknowledgement: none recorded
Personal details included: none

運用で対応を引き継ぐ際の制御は、 チャットチャネルのフィールドとワークフローの引き継ぎリファレンスを参照してください。

5. Create Documentでレビュー用の下書きを保存する

機能の状況：文書化済み。 この会話設計を保存するためのCreate Documentはカタログに記載されていますが、この設定についてAi Flowiによる本番環境でのテストは行われていません。

必要な利用権限を持つご自身のアカウントで接続するには Googleの接続設定 を、Create Documentのフィールドには Google Docs連携リファレンス を参照します。プロバイダーの利用料金は別途支払います。この提供済みテキストの下書きには、モデルプロバイダーのAPIキーは不要です。

設定例であり、記録されたテストではありません

title には「Birchの問い合わせ設計 — レビュー用下書き」を、 initial_text には会話ツリー、話者を明示した四つの会話例、PRACTICE-Bの資料を、その順に設定します。 google_accountには、このレビュー用に選択したアカウントを指定します。エクスポートされた options の値は []のため、カタログにはコピーできるアカウント名はありません。

想定する成果物は、提供した会話設計です。 document はJSONを返します。保存した文章では、人を求める分岐が確認の質問よりも先にあること、資料に「要約の修正／承認：確認待ち」と「引き継ぎ状況：準備のみ・未送信」に相当する記述が両方残っていることを確認します。レビュー担当者が、予約変更の依頼を会話例から未解決の判断までたどれ、ドキュメントを配信の受領証と取り違えない状態にします。

6. 対話設計のチャットボットを使う前に失敗をどう確認しますか？

  • 会場を尋ねる：応答はCedar室とその出典を保持し、到着時の案内を捏造してはいけません。
  • ワークショップ名を省く：最初の確認質問では、無関係な個人情報ではなく、不明な対象を尋ねる必要があります。
  • 到着時刻を尋ねる：回答不能時の応答では、会場の情報で代用せず、時刻の情報がないことを明示します。
  • 最初から人による対応を求める：ツリーは、先に回答を試みなくても下書きを準備できるようにします。
  • 「Birchワークショップはどこですか。人に対応してほしいです」と尋ねます。会場は回答できますが、最初の行き先はHANDOFF DRAFT（引き継ぎ用下書き）でなければなりません。ボットの会場回答で終了せず、要約に会場についての質問を記録します。
  • 「どのワークショップですか」と聞かれた後に、「代わりに人に対応してほしいです」と答えます。依頼の確認に戻り、下書き作成を提案します。前提条件としてワークショップ名を再度尋ねてはいけません。
  • 要約を断る、または修正する：対応する選択が行われるまで、資料に承認や引き継ぎを記録してはいけません。

すべての経路を声に出して読み、キーボード操作とテキストだけでレビューします。試行ごとに、進んだ分岐と理由を記録します。人による対応の依頼、対象外の操作、対象の不明、根拠の欠落を区別します。同じ問い合わせについて二人のレビュー担当者が異なる分岐を選ぶ場合は、実装前にルールを明確にします。これにより、丁寧な表現だけでは隠れてしまう優先順位の誤りを見つけられます。

この設計を、無人での予約変更、慎重な扱いを要する判断、回答期限を約束する用途に使ってはいけません。ドキュメントが作成されたか不明な場合は、 ドキュメント作成レシピの失敗と再試行のガイドに従います。この学習用ツリーは、チャネルでの配信、担当者の対応可否、会話の成功率の基準を確認するものではありません。