AIチャットボット要件定義のチェックリスト

AIチャットボットの要件定義では、導入したい機能を並べるだけでは不十分です。対象業務と対象外の業務、回答に使える根拠、有人対応へ切り替える条件、運用責任、受入条件まで、確認できる形で定めます。

要件表には「項目」「決める人」「確認する証拠」「完了条件」の4列を設けます。この形式なら、社内で決める事項と、提供会社へ確認する事項を切り分けられます。複数社へ見積もりを依頼する場合も、各社に同じ条件を提示できます。

AIチャットボットの要件定義で最初に決めること

最初に決めるのは、AIチャットボットに担当させる業務と、その業務を完了したとみなす状態です。製品名や機能名から検討を始めると、業務上の必要性を判断できない機能まで要件に混在します。

たとえば「FAQへ回答できること」だけでは、発注や検収の基準になりません。「店舗の営業時間と予約方法について、承認済みの案内資料を根拠に回答する」と記載します。さらに「予約変更と返金判断には回答せず、有人窓口を案内する」と対象外の動作も定めます。

要件表は、次の列で作成します。

列	記載する内容
項目	目的、対象質問、回答根拠、有人切替、権限、運用、受入条件など
決める人	業務責任者、情報管理者、承認者など、最終判断を行う担当者
確認する証拠	回答画面、操作記録、承認記録、テスト結果、更新履歴など
完了条件	何を確認できれば、決定済みまたは合格とするか

一つの要件に複数の解釈が残る場合は、要件を分割します。「安全に回答する」のような抽象的な表現は避けてください。「根拠資料にない質問には推測で答えない」「個別判断が必要な質問では担当窓口を案内する」のように、テストで確認できる動作へ置き換えます。

1. 導入目的を測定できる業務結果へ置き換える

「問い合わせを減らしたい」「顧客対応を効率化したい」という目的だけでは、AIチャットボットの担当範囲を決められません。導入目的は、対象質問、期待する処理、対象外の三つに分けて記載します。

店舗で利用する場合は、「営業時間外に受けた営業時間と予約方法の質問へ案内を返す」を対象業務とします。一方、予約内容の変更や返金可否には個別確認が必要なため、有人対応へ渡すと定めます。この一組を業務結果として記載すれば、公開後に想定した案内ができているかを確認できます。

目的を整理するときは、まず現在の問い合わせ記録から質問の種類を抽出します。次に、定型情報の案内だけで完了できる質問と、本人確認や個別判断が必要な質問を分けます。最後に、AIの回答だけで完了させる業務と、有人対応へつなぐ業務を決めます。

効果目標を置く場合も、根拠のない削減率を設定する必要はありません。「営業時間外にも案内を表示できる」「担当者による確認が必要な質問を区別できる」など、実現したい業務上の状態を先に定義します。件数や対応時間を評価する場合は、現状値を確認してから目標を決めます。

2. 利用者・利用場面・対象範囲と対象外を切り分ける

同じ質問でも、利用者や場面が異なれば必要な回答は変わります。要件表では、利用者、利用場所、対応チャネル、利用時間、対象質問を分けて記載します。

顧客向けと社内向けは、別の利用区分として扱います。顧客向けでは公開可能な情報だけを使用します。社内向けでは、閲覧権限が必要な文書や社内手順を扱う場合があります。二つを同じ要件にまとめると、利用できる資料と権限の境界が曖昧になります。

Webサイト、店舗の案内端末、社内画面など、利用場面も明記します。営業時間内と営業時間外で有人窓口の案内が変わる場合は、それぞれについて期待する動作を定めます。

対象外には、契約の確定、返金可否、本人確認を伴う手続き、医療や法律などの専門判断、根拠資料にない質問を含めます。ただし、対象外の項目を列挙するだけでは運用できません。各項目について「回答を控える」「問い合わせ先を示す」「緊急窓口を案内する」など、その後の動作も決めます。

回答に使う資料と想定質問をまだ収集できていない場合は、AIチャットボット導入前の準備ガイドで、必要な準備物と整理方法を確認できます。対象範囲を決める前に資料の有無を確認しておくと、根拠を用意できない要件を早い段階で切り分けられます。

3. 回答根拠となる資料と更新責任を決める

AIチャットボットが回答に使用できる情報源を一覧にします。Webページ、FAQ、利用規約、料金表、店舗案内、社内文書などを、資料単位で整理してください。

各資料には、利用可否、正本の所在、更新担当者、承認者、更新頻度、反映を確認する方法を記載します。公開期限のあるキャンペーン情報や、改定日が決まっている料金表には、有効期間も付けます。

資料間で内容が異なる場合は、優先する情報源を決めます。たとえば料金表とWebページで金額の記載が異なるなら、どちらを正本として扱うかを業務責任者が判断します。正本を決めないまま設定作業へ進むと、提供会社も回答の正誤を判定できません。

更新時の作業も要件に含めます。担当者が正本を更新し、承認者が内容を確認したうえで、AIチャットボットへの反映後に想定質問で回答を再確認する流れを定めます。更新作業の完了条件は、資料の差し替えではなく、利用者に表示される回答の確認までとします。

個人情報、社外秘情報、公開前情報など、回答に使用してはいけない情報も指定します。法務やセキュリティに関わる事項は、AIチャットボットの設定だけで確認を終えず、社内の所管担当者による確認を要件に含めます。

4. 回答できない質問と有人切替の条件を定義する

有人切替は「分からないときに担当者へ渡す」と書くだけでは要件になりません。切替条件、切替先、受付時間、引き継ぐ情報、受付時間外の案内を一組で定義します。

切替条件には、本人確認が必要な手続き、個別の契約変更、返金判断、苦情、緊急性のある相談、根拠資料に存在しない質問を含めます。同じ質問を繰り返しても解決しない場合や、利用者が担当者との対話を希望した場合の扱いも決めます。

担当者へ渡す情報は、利用者が入力した質問、直前までの案内内容、選択された問い合わせ分類など、対応に必要な範囲を指定します。個人情報を取得する場合は、取得目的、取得項目、保存方法、閲覧できる担当者を別途確認します。

営業時間外に有人対応を開始できない場合は、受付可能な時間と連絡方法を表示します。緊急性のある相談については、通常の問い合わせフォームとは別の窓口を案内する必要があるかも確認します。

責任分界をさらに具体化するときは、AIチャットボットの有人切替を設計する方法を参照できます。対象質問だけでなく、引継ぎ情報と担当範囲まで整理することが重要です。

5. 管理権限と公開承認の流れを設計する

管理画面を利用する人を一括して「担当者」と扱わないことが重要です。管理者、回答内容の編集者、承認者、閲覧のみの担当者に分け、それぞれに許可する操作を定めます。

管理者は権限設定、編集者は回答資料や案内内容の変更、承認者は変更内容の確認と公開判断を担当します。閲覧者には会話状況やテスト結果の確認だけを許可するなど、権限を業務上必要な範囲に絞ります。

料金、規約、契約条件などの重要情報を変更するときは、編集者と承認者を分ける必要があるか確認します。承認記録には、変更対象、変更理由、確認者、公開日を残します。

異動や退職に伴う権限削除も要件に含めます。誰が削除を依頼し、誰が実施し、どの記録をもって完了とするかを決めます。共有アカウントでは操作した人を確認しにくいため、利用者を識別できる管理方法が必要かを仕様書に記載します。

提供会社へ確認するときは、希望する権限分担を提示したうえで、対応可能な範囲と制約を回答してもらいます。特定の権限機能が利用できると推測したまま、要件を確定しないようにしてください。

6. 公開後の運用、変更管理、停止条件を決める

公開後の運用要件では、何を確認し、誰が修正し、誰が再公開を承認するかを定めます。確認対象には、未回答、誤解を招く回答、古い情報の利用、対象外質問への回答、有人切替の失敗を含めます。

問題を見つけたら、最初に影響範囲を確認します。特定の質問だけに影響するのか、同じ資料を使う複数の回答に影響するのかを切り分けます。その後、回答または資料を修正し、承認と再試験を行います。

変更管理表には、発見日時、対象質問、表示された回答、利用すべき根拠、原因、修正内容、承認者、再試験結果を記録します。修正作業を行った事実だけでなく、利用者に表示される回答が直ったことを証拠として残します。

重大な誤案内や更新不能が発生した場合に備え、停止条件も決めます。たとえば料金改定後も旧料金を案内する場合は、該当する回答を停止します。影響範囲を切り分けられない場合は、公開全体を停止する必要があるかを業務責任者が判断します。再開は、修正、承認、再試験が完了した後に行います。

障害時の連絡先、発注者と提供会社の担当範囲、連絡時に必要な情報も確認します。対応時間や復旧条件が契約書や提供条件と整合しているか、発注前に確認してください。

7. AIチャットボットの受入テスト項目と合否基準を作る

AIチャットボットの受入テストでは、実際の業務で起こる質問と操作を使って合否を判定します。単一の精度数値だけでは、対象外質問への応答や有人切替の成否まで確認できません。

テスト表には、テスト番号、質問または操作、前提条件、期待結果、確認者、確認する証拠、合否、修正内容、再試験結果の欄を設けます。

質問テストには、標準的な想定質問に加えて言い換えを含めます。「領収書を再発行したい」と「領収証をもう一度ほしい」のように、同じ意図を異なる表現で確認します。誤字や情報不足を含む質問についても、AIが不足する条件を勝手に補わず、利用者へ確認を求めるか、適切な窓口を案内できるかを確認します。

対象外質問では、推測で答えないことを確認します。根拠資料に存在しない質問を入力し、案内できないことを伝えるか、有人窓口を提示することを期待結果とします。苦情や緊急性のある相談では、通常の質問とは異なる案内が必要かも確認します。

操作テストでは、権限ごとの閲覧、編集、承認、公開を確認します。許可された操作だけでなく、閲覧者が編集できないことも重要なテスト項目です。資料更新後の反映や、停止した回答が表示されないことも確認します。

各ケースの合否は、期待結果と証拠に基づいて判定します。不合格のケースは修正後に再試験し、同じ変更の影響を受ける関連ケースも選び直して確認します。質問設計と評価観点を詳しく整理する場合は、AIチャットボットの回答品質を評価する方法を参照してください。

8. 要件をチャットボット仕様書と見積依頼へ落とし込む

チャットボット仕様書には、目的、利用者、対象範囲、対象外、回答根拠、有人切替、連携条件、権限、運用分担、成果物、受入条件を記載します。要件表の各項目には識別番号を付け、見積回答や受入テストとの対応関係を確認できるようにします。

複数社へ見積もりを依頼するときは、同じ仕様書と回答様式を渡します。提供範囲、発注者側で必要な作業、前提条件、追加費用が発生し得る条件、要件変更時の扱いを分けて回答してもらいます。

たとえば、各社へ同じ対象質問、回答資料、有人切替条件、受入テストを提示します。見積金額だけでなく、どの作業が提供範囲に含まれ、どの作業が発注者側に残るかを比較します。前提条件が異なる見積もりを、金額だけで比べないことが重要です。

成果物については、設定済みの環境だけでなく、要件表、回答根拠の一覧、権限一覧、運用手順、テスト結果、変更記録の様式など、引き継ぎに必要な文書を含めるか確認します。各文書の納品形式と更新方法も指定します。

要件確定後の設定、テスト、公開までの流れは、AIチャットボット導入の工程と期間で確認できます。候補製品や提供会社を比較する段階では、チャットボットの選び方を、業務要件への適合性を確認するための選定軸として利用できます。

発注前に使うAIチャットボット要件定義チェックリスト

次の項目を発注前の会議で確認します。各項目について、内容が決まっているか、決定者がいるか、証拠を確認できるか、完了条件が明確かを点検してください。

• 導入目的が具体的な業務結果で記載されている
• 利用者、利用場面、対応チャネル、利用時間が決まっている
• AIが回答する対象質問が決まっている
• AIが回答しない対象外質問と、その際の動作が決まっている
• 回答に使用できる資料と使用できない資料が分かれている
• 資料ごとの正本、更新担当者、承認者が決まっている
• 資料間で内容が異なる場合の優先順位が決まっている
• 本人確認、契約変更、苦情、緊急時などの有人切替条件が決まっている
• 切替先、受付時間、引継ぎ情報、時間外の案内が決まっている
• 管理者、編集者、承認者、閲覧者の担当範囲が決まっている
• 異動や退職時の権限削除手順が決まっている
• 公開後に確認する問題と確認担当者が決まっている
• 修正、承認、再試験、再公開の手順が決まっている
• 対象回答または公開全体を停止する条件が決まっている
• 再開を承認する人と再開条件が決まっている
• 想定質問、言い換え、対象外質問、誤字、情報不足を受入テストへ含めている
• 有人切替、権限別操作、更新反映を受入テストへ含めている
• 各テストに期待結果、確認者、証拠、合否欄がある
• 不合格時の修正責任と再試験方法が決まっている
• 仕様書に提供範囲と発注者側の作業が分けて記載されている
• 複数社へ同じ見積条件と受入条件を提示できる
• 未決定項目に担当者と決定期限が割り当てられている

未決定の項目は、確定済みの要件に混在させません。「未決定」と明記し、決める人、確認先、期限を設定します。提供会社からの提案を受けて決める項目には、提案してほしい範囲と最終決定者を記載します。

要件定義が完了したと判断する基準

AIチャットボットの要件定義は、対象と対象外、回答根拠、有人切替、権限、運用責任、停止条件、受入テストについて、決定者と確認方法がそろった時点で完了と判断します。

すべての製品機能を先に決める必要はありません。製品名が未定でも、解決したい業務、AIの担当範囲、有人対応との責任分界、受入条件は確定できます。この業務要件を基準にすれば、候補製品や提供会社へ同じ条件で質問できます。

発注前には、要件表の各行を「決定済み」「提案待ち」「対象外」に分類します。「決定済み」には承認者を付けます。「提案待ち」には回答期限と判断基準を付けます。「対象外」には、対象外とした理由を残します。

最後に、受入テストから要件表を逆引きして確認します。要件を確認するテストが存在しない場合は、完了条件が抽象的な可能性があります。反対に、要件に対応しないテスト項目がある場合は、仕様書への記載漏れがないかを確認します。

作成した要件表を導入相談に活用する

要件表を作成した後は、その内容を基に、Socratesで対応可能な範囲、有人対応へ切り替える範囲、導入前に追加確認が必要な事項を整理できます。製品に業務を合わせる前に、目的、回答根拠、運用責任、受入条件を共有したうえでご相談ください。

Socratesの導入について相談する

AIチャットボットの要件定義に関するよくある質問