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

チャットボットと有人チャットの違いは、応答を作成するのがソフトウェアか人かという点です。確認可能な出典があり、回答範囲を限定できるタスクには自動化を選びます。人の判断、権限に基づくアカウントへのアクセス、その範囲を超える操作が必要な依頼には、有人対応を選びます。両者を組み合わせる設計では、自動化が停止した時点で人が責任を引き受けたことを示す証拠が必要です。

執筆：Ai Flowi · 公開日 2026-10-10

以下の比較、ワークシート、会話例は、静的な学習用資料です。応答の責任と要員配置の判断を説明するもので、AI Flowi Workflowにおける有人対応の待ち行列やメッセージ配信を実証するものではありません。

1. 同じ依頼と完了基準で比較する

各経路案に、同じ質問、使用可能な情報、想定する完了状態を与えます。「公開されている返却手順はどこにありますか」という質問なら、該当する出典を提示すれば完了とできる場合があります。「アカウントの返却記録を変更してください」という依頼では、権限のある操作と、その結果の証拠が必要です。自動の受付確認では、後者のタスクは完了しません。

有人チャットにも限界があります。人が対応可能でも、その案件を解決する権限や情報が不足している場合があります。その担当者が判断できるのか、確認できるのか、別の担当者へ回すことしかできないのかを記録します。人が参加したからといって、未解決の状態を消してはいけません。

言語の解釈と対話の文脈については、 会話型AIの解説を参照してください。この判断は、チャットボットの種類をさらに列挙するのではなく、回答の責任を明確にすることから始めます。

2. 責任と対応可否の比較表を使う

タスクごとに比較表を読みます。キーボード利用者は表の領域にフォーカスし、小さい画面では列を横にスクロールできます。

運用計画では、対応可否を別の行で管理します。有人対応時間、タイムゾーン、不在時の扱い、代替対応の責任分担を確認します。ソフトウェアの画面に常時アクセスできても、人が24時間対応する証拠にはなりません。要員配置の根拠が空欄なら、対応体制は未確認のままにします。

3. 経路選択のワークシートをコピーする

依頼の種類ごとに一枚のシートを作ります。一般情報への回答が成功したことを、アカウント変更や苦情対応の根拠として使うのを防げます。このテンプレートは、数値による応答目標を示すものではありません。

依頼の種類と入力例：
許可された回答または操作：
承認済みの出典と適用する改訂版：
必要な出典へのアクセス／アカウント権限：
自動応答の停止条件：
人が判断する役割とエスカレーションの役割：
有人対応時間、タイムゾーン、対応体制の証拠：
時間外の代替手段と確認済みの連絡先：
準備の責任：出典レビュー、アクセスレビュー、要員配置レビュー：
要約の修正と引き継ぎの許可：
受け手が引き受けた証拠：
状態：自動作成した下書き／人が引き受け済み／引き継ぎ未解決：
完了基準と独立した結果の証拠：
観測した失敗、次に責任を持つ役割、レビューの開始条件：

シートを使って、自動化、有人対応、またはその組み合わせを選びます。根拠のない回答をレビューする責任者がいない場合は、手動で確認できる程度に自動化の範囲を絞ります。有人経路の対応体制が確認されていない場合は、すぐに利用できると案内してはいけません。

実装の作業量は別に記録します。出典の準備、必要に応じた認証情報の設定、運用担当者のアクセス、継続的なレビューを含めます。ワークフローの実行、プロバイダーの利用、担当者の作業では、費用の単位が異なります。この概念上の比較は、人件費の基準やプラットフォーム料金との同等性を示すものではありません。

4. 会話例：人が未解決の判断を引き受ける

この架空の会話例は、架空の機材貸出施設を扱っています。根拠カードLIB-Rには、一般的な返却手順は公開されており、アカウントの修正には権限のある窓口レビュー担当者が必要だと記載されています。この例に限り、窓口レビュー担当者が対応可能で、依頼の受領を確認します。これらの文はソフトウェアの出力記録ではありません。

利用者：機材の返却記録を修正してほしいです。
自動作成した下書き：この依頼には、権限のある窓口レビュー担当者が必要です。
要約を準備できます。非公開のアカウント情報は含めないでください。
要約の下書き：機材の返却記録のレビュー依頼。
修正はまだ行われていません。これが引き継ぎたい依頼ですか。
利用者：はい。その要約を窓口レビュー担当者に渡してください。
窓口レビュー担当者：この依頼のレビューを引き受けます。
次に、認められたアカウント確認手順を行います。
アカウントの修正はまだ確認されていません。
サービスの状態：人が引き受け済み。アカウントに関する判断は未解決。

依頼を引き受け済みの作業から完了へ移すために必要な証拠は、 サポートチケットのワークフロー を参照してください。

この比較では、予定されているレビュー担当者が、要約を読み、許可されたアカウント画面にアクセスし、別の問い合わせに対応中でもやり取りを続けられるかを確認します。要員配置のリハーサルには架空の依頼を使います。中断や後回しにした作業を記録しますが、その演習を処理能力の主張に変えてはいけません。アカウントのレビューに別の専門担当者が必要なら、その担当者につながる有人経路を選ぶか、確立された後日のレビュー経路を提示します。一般情報を答えるボットを利用可能にしても、不足している専門担当者の対応能力は補えません。

組み合わせたサービスでは、対応を引き継ぐ範囲を定めます。自動応答は会話全体で停止するのか、アカウント修正の話題だけで停止するのかを決めます。後者の場合は、公開された機材の案内を利用可能なままにし、記録変更はレビュー担当者へ回します。利用者がそれらの話題を切り替える場合と、レビュー担当者が勤務終了時に離れる場合をリハーサルします。次のメッセージを誰が受け取るか、対応体制をどう再評価するかを記録し、その追加の調整作業を、すべて人が対応する会話と比較します。

5. 会話例：引き継ぎが未解決のままになる

アカウント修正の依頼と根拠の範囲は同じまま、対応可否だけを変えます。学習用の資料には、現在の要員配置の確認がありません。この例では、要約が準備され、引き継ぎの許可もありますが、配信や引き受けの証拠はありません。

利用者：返却記録を修正するよう、人に依頼してください。
自動作成した下書き：アカウントの修正には窓口レビュー担当者が必要です。
現在、窓口が対応可能かは未確認です。
要約の下書き：返却記録の修正に関するレビュー依頼。
非公開のアカウント情報は含まれていません。この要約を引き継いでもよいですか。
利用者：はい、その要約で正しいです。
サービスの状態：引き継ぎ未解決。
配信の証拠：なし。受け手による引き受け：なし。
表示する状態：要約は準備済みですが、まだレビュー担当者が
引き受けていません。アカウントの記録は変更されていません。

引き継ぎの許可は一つの条件です。配信の成功と、責任を持って引き受けることは、それぞれ別の条件です。実際のサービスに確認済みの代替連絡経路がある場合は、その経路と限界を示します。確立された経路がなければ、待ち行列の順番、到着時刻、後日の対応の約束を捏造せず、不足を明示します。

両方の会話例で、話者名と明示的な状態の文章を使っています。読者は吹き出しの色やアニメーションを解釈しなくても、自動作成した下書き、人による引き受け、未解決の結果を区別できます。例を調整する場合も、これらのラベルを保持します。

6. チャットボットやライブチャットの公開前に境界をどう確認しますか？

• 明確な公開情報の質問： 承認済みの出典を提供し、回答を確認します。アカウント操作が行われたと主張してはいけません。
• 曖昧な非公開情報の依頼： 必要なアカウントの背景情報を取り除きます。経路は未解決の判断を保持し、認められた確認手順につながる必要があります。
• レビュー担当者が対応できない： 対応体制の証拠を取り除きます。どの応答も、人がすぐに対応できる、または常時要員が配置されていると主張してはいけません。
• 引き継ぎの中断： 要約の承認は残し、配信の証拠を取り除きます。下書き作成が完了していても、状態は引き継ぎ未解決のままです。
• 引き受け済みでも未解決： 受け手の受領確認を提供し、操作結果は提供しません。サービスは対応の引き受けを記録できますが、修正の完了を記録することはできません。

観測内容をワークシートとともに保存し、出典、要員配置、アクセスが変わった場合は、該当する事例を再確認します。表現と回答不能時の経路は 会話設計ガイド を参照してください。 サポート応答時間のガイド では、対象となる応答と時間計測を定義しています。このページでは、それらの指標を再計算しません。

7. メッセージ表示と有人サービスを分ける

この比較では、 Chat Output に文書化されている目的は、より限定的です。 Playgroundにチャットメッセージを表示します。 必須の input_value は、Data、JSON、DataFrame、Table、Messageを受け付けます。機能の状況はカタログで文書化済みですが、Ai Flowiによる本番環境でのテストは行われていません。これらのフィールドは、受け手の割り当てや人による引き受けを実証するものではありません。

このワークシートには、アカウント、APIキー、稼働中の連携は不要です。実装を選ぶ際は、既存の手動連絡、無料または有料のホスト型ツール、自社運用の選択肢を、同じ責任の確認基準で評価します。利用者に対応体制や引き継ぎ動作を約束する前に、それらの実際の証拠を求めます。