チャットボットSLAの確認項目｜契約前に見る7点

チャットボットの提案書に高い稼働率が示されていても、営業時間の誤案内がいつ修正されるのか、障害時に誰へ連絡するのかが分からなければ、運用担当者は契約の妥当性を判断できません。契約前に確認すべきなのは、一つの数字ではなく、停止や回答品質の問題を誰が検知し、どのように復旧・改善するかという一連の条件です。

チャットボットのSLA（Service Level Agreement、サービス品質について提供者と利用者が合意する基準）は、期待値の行き違いを防ぐための共通言語です。ただし、SLAという名称の文書だけを探せばよいとは限りません。申込書、利用規約、サポート規定、仕様書、運用手順など、複数の文書に条件が分かれている場合もあります。

稼働率だけを比較せず、対象範囲、除外時間、障害区分、連絡経路、回答品質、改善作業、測定・見直しの7点を、自社業務への影響に照らして確認することが本稿の結論です。製品機能そのものを比較している段階なら、先にチャットボットの選び方を確認し、候補を絞ってから契約条件を読み合わせると進めやすくなります。

チャットボットSLAは稼働率だけの表ではない

SLAは、提供するサービスの範囲、測定方法、目標または保証する水準、未達時の扱いについて合意するものです。似た言葉にSLIとSLOがあります。SLIは稼働時間や初動時間などの実績を測る指標、SLOはその指標について運用上目指す水準です。SLAは当事者間の契約上の合意であるため、社内目標であるSLOのすべてが、そのまま契約上の保証になるわけではありません。

チャットボットでは、システムが応答画面を表示できる「稼働」と、質問に適切に答える「回答品質」を分けて考える必要があります。画面が開いて会話できても、古い営業時間を案内したり、必要な有人窓口へ引き継げなかったりすれば、利用者の問題は解決しません。反対に、回答すべきでない質問への応答を止め、適切な窓口を案内する動作は、単純な回答率だけで評価すると低品質に見える場合があります。

契約上のSLA、提供者が示す仕様、利用者側の運用ルールは、一枚の確認表にまとめると抜け漏れを見つけやすくなります。要件全体を整理する段階では、AIチャットボットの要件定義チェックリストも参照してください。要件定義では機能やセキュリティ、運用体制を整理し、SLAの確認では契約後に検証できるサービス水準と責任分界を詰める、と役割を切り分けます。

契約前に確認する7項目

各項目は「水準が高いか低いか」ではなく、「何が対象で、誰が、いつ、何をするか」を読み取れる状態にします。下表の空欄を契約書だけで埋めようとせず、利用規約、仕様書、サポート規定なども横断してください。口頭で補足された内容については、契約文書に反映されるか、少なくとも双方が参照できる記録として残るかを確認します。

1. 対象範囲を機能名ではなく利用場面まで書く

「チャットボットサービス」とだけ書かれていても、Web上の会話画面、管理画面、回答処理、認証、外部サービス連携のどこまでが対象か判断できません。「自社サイトから会話画面を開ける」「担当者が管理画面へ入れる」「質問に対する回答が生成される」というように、実際の利用場面に分けて確認します。外部サービスの障害がSLAの対象外であっても、利用者への告知や代替手段をどちらが用意するかという運用上の担当は残ります。

2. 稼働率は分母・分子・除外条件を読む

稼働率の数字は、測定期間と除外時間によって意味が変わります。月単位か年単位か、計画メンテナンスを除くか、利用者側の設定不備や通信環境をどう扱うか、停止開始と復旧をどの記録で判定するかを確認します。計画停止については、通知時期、実施時間帯、延期・延長時の連絡まで確認すると、自社の営業や問い合わせ対応への影響を判断できます。

公開されているSLAの具体例として、DialogPlayのサービスレベルアグリーメントでは、適用範囲、提供時間、稼働率、計画停止、サポートなどが項目化されています。数値を自社契約へそのまま流用するのではなく、どのような条件がSLAに明文化され得るかを確認する資料として参照できます。

3. 受付・初動・復旧を別の時刻として扱う

障害対応について「迅速に対応」と書かれていても、担当者が連絡を受け付けた時点、調査を始めた時点、暫定的に利用できるようになった時点、原因を解消した時点は同じではありません。重大障害と軽微障害の定義を確認したうえで、それぞれの受付、初動、暫定復旧、恒久対応を分けて記録します。示された時間が運用上の目標なのか、契約上合意する水準なのかも確認が必要です。

公的な発注仕様の例では、佐賀県の情報発信AI導入・運用委託業務仕様書（PDF）が、稼働率に加えて、障害区分ごとの復旧目安、月次報告、改善提案を扱っています。個別契約の推奨値を示す資料ではありませんが、障害対応と運用報告を合わせて確認する際の参考になります。

4. 連絡経路は平常時と緊急時に分ける

通常の問い合わせ窓口が平日の日中に限られる場合、営業時間外の停止を誰がいつ発見し、どこへ連絡するかが問題になります。監視通知の有無、利用者側の連絡先、連絡時に必要な契約IDや画面記録、受付確認の方法を整理してください。緊急窓口が用意されていない契約でも、自社サイトに代替の問い合わせ先を掲示する条件と担当者は決められます。金曜の営業時間後にすべての利用者が会話画面を開けなくなった場面を想定すると、時間外の連絡手順に空欄がないか確認しやすくなります。

5. 停止と回答品質の劣化を分けて記録する

営業時間を誤って答える、対象外の契約条件を断定する、担当者へ切り替わらないといった問題は、サーバー停止と同じ測定方法では把握できません。回答品質については、問題の報告先、影響する質問への回答を止められるか、正しい根拠を誰が提示するか、修正と確認を誰が担当するか、再テスト後に利用者へどう案内するかを確認します。

回答不能率や正答率を使う場合は、分母、判定者、標本の選び方を決めます。件数だけを追うと、契約や安全に関わる質問への回答を適切に止めた会話まで失敗に数える可能性があります。数値と会話例を合わせて確認し、「回答してはいけない場面で止められたか」も品質基準に含めてください。

6. ナレッジ更新と有人引継ぎの責任分界を決める

回答の正本を用意するのは利用者側、システムへ反映するのは提供者側という分担でも、資料の形式、受付期限、確認方法が不明なら更新作業が止まります。変更情報を誰が承認し、誰が登録し、反映後の回答を誰が確認するかを一連の流れとして決めます。誤回答の原因が古い資料にあるのか、登録作業にあるのか、回答処理にあるのかを切り分けられる記録も必要です。

有人引継ぎでは、切替条件だけでなく、受け手の受付時間と引き継ぐ情報もそろえます。有人担当が不在の時間帯に「担当者へおつなぎします」と表示しても、利用者の期待と実際の対応がずれます。不在時には受付完了と次回の確認時期を案内するなど、代替フローを決めてください。有人対応を含む設計は、チャットボットの有人切替設計で具体化できます。外部の実務例としては、チャットボットと有人切替を一体で扱うガイドも、ボットと人の対応基準をつなぐ観点を示しています。

7. 測定・報告・未達時の扱いまで確認する

測定項目が決まっていても、提供者だけがデータを保有し、利用者が確認できなければ改善や契約見直しに使えません。報告頻度、障害一覧、測定根拠、問い合わせ対応履歴、品質問題、改善状況を確認する担当者を決めます。未達時は補償の有無だけでなく、原因報告、再発防止、見直し協議、契約変更や終了の手続も関連文書で確認してください。

運用保守契約の作業範囲や契約形態を整理する資料として、運用保守契約の選び方を参照できます。SLI・SLO・SLAの違い、除外条件、報告方法の整理には、システム保守SLAの決め方も参考になります。いずれも一般的な確認材料であり、自社契約の解釈や結論を代替するものではありません。

必要な水準を業務影響から決める

SLAの数字を厳しくすれば、必ず良い契約になるわけではありません。必要な体制や費用、実現可能性との釣り合いがあるため、先に停止や誤回答が自社業務へ与える影響を整理します。同じ障害でも、営業時間外の一般FAQが一時停止する場合と、申込期限の直前に重要な手続きを誤案内する場合では、求める連絡や復旧の条件が異なります。

まず、問い合わせを「情報提供」「申込・予約」「契約・個別判断」「緊急性あり」などに分類し、停止、誤回答、引継ぎ遅延が起きた場合の影響を高・中・低で仮置きします。次に、代替窓口の有無と、現場が対応できる時間帯を記入します。この順序で整理すれば、他社の数値を流用せず、自社に必要な連絡や復旧の条件を具体的に質問できます。

必要な水準は、提供者だけに課す条件ではありません。利用者側が正本を更新しなければ、回答品質を保てない場面もあります。更新承認者が不在の場合や、有人窓口の担当者が対応できない場合まで含め、双方が実行できる分担になっているかを確認してください。

責任分界を運用フローに落とす

契約書に「双方協議」と書かれていても、障害発生中に協議の順序から考える余裕はありません。検知、受付、影響確認、応急措置、復旧、原因報告、恒久対応、再テストの各段階について、実行者、承認者、連絡先、保存する記録を決めます。

誤回答では、提供者が修正できる技術上の問題と、利用者が更新すべき情報の問題が重なることがあります。「原因が利用者側なら対象外」という整理だけで終わらせず、切り分けに必要なログ、正本の提出方法、調査中の回答停止、再公開の承認者まで確認します。利用者から提供者へ渡す資料の内容や提出期限も、責任分界の一部です。

有人引継ぎについても、システムが通知を送った時点を完了とするのか、担当者が受け付けた時点まで追うのかを区別します。運用時間外には自動受付へ切り替え、対応可能な時間を案内する方法もあります。ただし、実装の可否は製品や契約によって異なるため、利用できることを前提にせず、提供者へ確認してください。

契約前の質問と見直し手順

資料を読んだ後は、曖昧な言葉を具体的な業務場面に置き換えて質問します。「サポートは充実していますか」ではなく、「金曜の営業時間後に全利用者が会話画面を開けなくなった場合、どの窓口へ連絡し、受付と初動はどのように記録されますか」と尋ねます。

回答は「可・不可」だけでなく、根拠となる文書名と該当箇所も記録します。契約書、利用規約、仕様書、サポート規定の記述が食い違う場合は、どの文書が優先されるかを確認してください。担当者の説明を契約上の保証と決めつけず、必要な条件が書面に反映されるかを確認します。

運用開始後は、月次など自社で継続できる周期を定め、稼働実績、障害、品質問題、ナレッジ更新、有人引継ぎを同じ場で確認します。指標設計はチャットボットの効果測定とKPIを参照し、SLAの遵守と業務成果を混同しないようにしてください。SLAを満たしていても問い合わせが解決していない場合は、回答範囲や導線を見直す必要があります。

1. 契約書、申込画面、利用規約、仕様書、サポート規定を集める。
2. 7項目の確認表に、記載箇所と不明点を書き出す。
3. 問い合わせ業務を分類し、停止・誤回答・遅延の影響と代替策を決める。
4. 提供者へ具体的な場面を示して質問し、回答の根拠文書を残す。
5. 法務、情報システム、現場運用、情報管理の担当者で分担を読み合わせる。
6. 開始後の報告日、品質確認日、契約更新前の見直し日を決める。

契約条件の意味や効力、責任、損害に関する判断は、契約文言や個別事情によって変わります。本稿は確認すべき観点を整理するものであり、法的助言ではありません。最終的な契約解釈や修正文案は、自社の法務担当者や弁護士など、関係する専門家へ確認してください。

契約前チェックリスト

• SLAが適用される機能、環境、開始日を特定した
• 稼働率の計算式、測定期間、除外時間を確認した
• 障害区分ごとの受付、初動、暫定復旧、恒久対応を分けた
• 平常時・緊急時・時間外の連絡経路を確認した
• 停止とは別に、誤回答と有人切替失敗の扱いを決めた
• ナレッジの承認、登録、反映確認、再テストの担当を決めた
• 測定根拠、報告頻度、未達時と変更時の手順を確認した
• 重要業務ごとに代替窓口と告知担当を決めた
• 複数文書の優先関係を確認し、専門家の確認を受けた
• 運用開始後と契約更新前の見直し日を設定した

チャットボットSLAの確認は、厳しい数値を並べる作業ではありません。停止、誤回答、引継ぎ遅延が起きたときにも利用者を放置せず、提供者と導入企業が同じ手順で動ける状態を整える作業です。まず重要な問い合わせを一つ選び、7項目のうち、書面で確認できない箇所を洗い出してください。

よくある質問