AIチャットボットの設計思想：使える範囲・会話の修復・人への引き継ぎ

2026年10月8日に、Microsoft HAX Design Library、W3CのStatus Messages、Keyboard、Error Identificationを再読しました。チャットボットは自然な返答だけでなく、能力と限界の説明、訂正・終了・引き継ぎを操作可能にします。非同期の回答や障害はフォーカスを奪わず状態として通知し、入口から終了までキーボードで操作でき、入力エラーは項目と修正方法を明示します。案内表示と実際の受付・解決は別の指標にします。

チャットボットの回答が自然でも、利用者が用件を片付けられなければ、使いやすいサポートにはなりません。困ったときに聞き直せること、扱えない用件は適切な窓口へ進めること、途中でやめられることも会話の一部です。

設計の出発点は、利用者がいつ、何を知りたくて、どこで迷っているかです。公開FAQを案内する小さな例を使い、入口から終了までの会話、状態と履歴、効果測定をつなげて考えます。カバーは、一般案内と担当窓口をつなぐ考え方を表した生成イラストです。

30秒で要点

• 入口で「AIであること」「使える範囲」「できないこと」「担当窓口」を示す。
• 未理解、無入力、システム障害を分ける。聞き直しを繰り返すだけの袋小路を作らない。
• 回答の表示、窓口の案内、実際の受付、確認済みの解決は別々に測る。
• 購入履歴を集める前に、確定した用件と短いセッションだけで案内できないかを考える。

1. 利用者の用件から、使える範囲を決める

最初に、想定する用件を三つに分けます。質問が多いことだけで、自動回答に向くとは限りません。根拠資料と更新責任者があり、間違えたときの影響を許容できるかを確認します。

表が収まらない場合は、横にスクロールできます

この分け方は設計の例です。自社で既に安全に実装した機能があれば範囲は変わりますが、AIが文章を生成できることを業務権限へ読み替えません。

Microsoft HAXの指針は、能力と誤り得ることの説明、訂正、終了、不確実な場合の範囲縮小を挙げています。入口の案内に加えて、間違えた後の体験も設計するための参考になります。

入口の文言は、短く具体的にする

架空の通販サポートなら、「何でもお答えします」より、次のように対象を示せます。有人窓口の時間は、実際の運用に合わせて表示します。

AIによる一般案内です。営業時間と配送条件を確認できます。注文ごとの状況や返金は担当窓口へご相談ください。途中でも窓口へ移れます。

初めから長い注意書きを読ませるのではなく、必要な条件を用件に合わせて示します。利用者が訂正した用件を反映し、同じ情報を何度も入力させないようにします。

2. 入口から終了まで、会話を一つの流れとして設計する

次の会話は設計用の架空例です。実際の会社の対応時間、回答、受付結果ではありません。公開資料で答えられる用件と、本人確認が必要な用件を分けています。

1. 入口：AIの一般案内であること、対象、担当窓口を示す。
2. 利用者：「配送について知りたい」
3. 確認：「一般の配送条件ですか、注文した商品の状況ですか？」
4. 一般条件：適用地域と資料の日付を確かめ、説明と参照先を示す。
5. 個別注文：チャットへ注文情報を要求せず、本人確認済み窓口を案内。
6. 回答後：「この案内で用件は解決しましたか？」と確認する。
7. 未解決：担当窓口へ進むか、用件を言い直すかを選べる。
8. 終了：何が済み、何が残ったかを伝え、チャットを閉じられる。

曖昧なときは、同じ質問を繰り返すより、考えられる用件を短い選択肢で示します。選択肢に該当しない場合の自由入力や窓口も残します。特に急いでいる人には、関連商品の提案を増やすより、次に進む操作を明確にします。

引き継ぎの「案内」と「受付」を区別する

窓口リンクを表示しただけでは、問い合わせが届いたとは限りません。受付処理があるなら、利用者に確認を求める内容、送信する情報、受付番号、返答の見込み、重複送信や失敗時の扱いを決めます。

担当者に渡す要約は、確認済みの用件、未解決の点、参照した資料に絞ります。AIが推測した顧客属性や、必要のない会話全文を、事実として引き継ぎません。

3. 未理解・無入力・障害を分けて修復する

表が収まらない場合は、横にスクロールできます

Dialogflow CXのhandler仕様も、入力不一致、無入力、webhookの障害やtimeoutを別のイベントとして扱います。製品が違っても、利用者の未理解とシステム側の失敗を分けて設計する視点は参考になります。

「必ず3回聞き直す」という共通ルールはありません。この記事の例は、最初の失敗を含めて連続した未理解3回で窓口を案内します。利用者が希望した場合や扱えない用件では、回数を待ちません。復旧の見込みが分からないのに「しばらくお待ちください」だけを出し続けない設計にします。

4. コンテキストは、用件・状態・期限を分けて持つ

直近の用件を覚えることと、購入履歴を収集することは別です。公開FAQの案内なら、確定した用件、現在の状態、連続した未理解の回数だけでも会話をつなげられます。別の利用者や、期限が切れたセッションの用件を引き継がないようにします。

次は、元のセッション型の考え方を、型と状態遷移まで完結させたTypeScript教材です。topicは外側で確定した用件を表すイベントです。自然言語の分類、回答の根拠確認、ネットワーク入力の検証、認証、保存、有人受付は含みません。answerは一般案内へ進める状態で、問題が解決したという意味ではありません。

type Phase = "ready" | "clarify" | "answer" | "handoff" | "closed";
type Topic = "hours" | "shipping";
type ChatEvent =
  | { type: "topic"; topic: Topic }
  | { type: "unknown" | "no-input" | "failure" | "human" }
  | { type: "resolved" | "dismiss" | "restart" };

interface ChatSession {
  phase: Phase;
  topic: Topic | null;
  consecutiveMisses: number;
  lastActivityMs: number;
}

const MAX_MISSES = 3;                  // この教材の運用値
const SESSION_TTL_MS = 30 * 60 * 1000; // この教材の無操作期限

function nextSession(
  state: ChatSession, event: ChatEvent, nowMs: number
): ChatSession {
  if (!Number.isSafeInteger(nowMs) || nowMs < 0 ||
      !Number.isSafeInteger(state.lastActivityMs) ||
      state.lastActivityMs < 0 || nowMs < state.lastActivityMs ||
      !Number.isSafeInteger(state.consecutiveMisses) ||
      state.consecutiveMisses < 0 || state.consecutiveMisses > MAX_MISSES) {
    throw new RangeError("時刻または未理解回数を確認してください");
  }
  const ready: ChatSession = {
    phase: "ready", topic: null, consecutiveMisses: 0,
    lastActivityMs: nowMs
  };
  if (event.type === "restart") return ready;
  if (state.phase === "closed") return { ...state };
  if (nowMs - state.lastActivityMs >= SESSION_TTL_MS) {
    return { ...ready, phase: "closed" };
  }
  if (event.type === "dismiss") return { ...ready, phase: "closed" };
  const active = event.type === "no-input"
    ? { ...state } : { ...state, lastActivityMs: nowMs };
  if (event.type === "human" || event.type === "failure") {
    return { ...active, phase: "handoff" }; // 窓口案内。送信は行わない
  }
  if (state.phase === "handoff") return active;
  if (event.type === "topic") {
    return { ...active, phase: "answer", topic: event.topic,
      consecutiveMisses: 0 };
  }
  if (event.type === "unknown") {
    const misses = Math.min(state.consecutiveMisses + 1, MAX_MISSES);
    return { ...active, topic: null, consecutiveMisses: misses,
      phase: misses >= MAX_MISSES ? "handoff" : "clarify" };
  }
  if (event.type === "resolved" && state.phase === "answer") {
    return { ...ready, phase: "closed" };
  }
  return active; // 無入力は未理解へ加算しない
}

const initial: ChatSession = {
  phase: "ready", topic: null, consecutiveMisses: 0, lastActivityMs: 0
};
const first = nextSession(initial, { type: "unknown" }, 100);
const second = nextSession(first, { type: "unknown" }, 200);
const third = nextSession(second, { type: "unknown" }, 300);
console.log(first.phase, second.phase, third.phase);
// clarify clarify handoff

窓口の案内後は勝手に自動回答へ戻さず、再開操作で状態を初期化します。期限が切れたら、画面側でも終了理由と再開方法を示します。無入力と無操作期限は別で、無入力を連続した未理解へ数えません。

個人化が必要な場合に追加する判断

• 公開の用件だけで足りるか。購入履歴を使う必要があるか。
• 参照してよい本人の範囲と、利用目的を確認できるか。
• 外部サービスへの送信先、保持、削除、アクセス権を管理できるか。
• 利用者が個人化を止めたり、記憶された用件を訂正したりできるか。

HAXの記憶と制御の指針は、短期のやり取りを踏まえることと、利用者の制御を両方挙げています。Microsoftのエージェント設計の土台も、プライバシーや透明性を含めて体験全体を扱っています。これらは、履歴を無制限に集めてよいという意味ではありません。

5. 心理的な配慮と、実際の操作を一緒に確かめる

困っている人には、共感の言葉に加えて具体的な進み方が必要です。根拠のない「多くの人が解決した」という社会的証明や、急がせる文言で窓口への移動を妨げません。利用者を説得してチャットへ留めるより、用件と選択を尊重します。

表が収まらない場合は、横にスクロールできます

WCAG 2.2のキーボード操作（2.1.1）、入力エラーの識別（3.3.1）、状態メッセージ（4.1.3）を確認観点にできます。例えば回答待ちや受付失敗を、フォーカスを奪わずに支援技術へ伝える方法を設計します。

属性を付けただけでは、実際の読み上げや操作は分かりません。文字の拡大、モバイル、キーボード、支援技術で会話の入口から終了まで確かめます。基準を一部確認したことを、サイト全体の適合宣言にはしません。

6. 解決・引き継ぎ・満足度の分母を固定する

表が収まらない場合は、横にスクロールできます

0件の期間は、0%の成功率とせず「対象なし」と記録します。引き継ぎ率が低くても、窓口を見つけられず離脱しているなら改善ではありません。少ない回答者の満足度だけで、全利用者の満足を判断しません。

会話フローをA/Bで比べるなら、利用者の割り当て、主要指標、観測期間、誤案内などの保護指標を先に決めます。導入前後の比較や、開始時期を分けるコホート分析も役立ちますが、利用者・季節・流入元・質問の難しさが変わると、差を設計だけの効果とは言えません。

7. 公開FAQから試し、失敗の経路も確認する

1. 更新責任者がいる公開FAQを選び、対象と期限を確認する。
2. 入口・回答・聞き直し・窓口・終了の文言を用件ごとに用意する。
3. 正解できる質問だけでなく、曖昧な質問、対象外、障害、再開を試す。
4. 利用者の操作と、担当者側の受付・要約・負荷を併せて見る。
5. 同じ定義で解決・誤案内・再問い合わせを観測してから範囲を広げる。

相談時には、よくある用件、案内できる公開資料、担当窓口と受付時間、困っている指標を持ち寄ると、具体的な設計へ進めます。実装の教材はAIチャットボット導入ガイド、役割分担はAIと人間の協働、全体像はAI・LLM完全ガイドも参照してください。