サービスデスクチャットボットとは？仕組みと選び方

サービスデスクチャットボットとは実際どのようなものか

サービスデスクチャットボットは、サービスデスクの手前に立ち、本来なら人間のエージェントが一件ずつ対応していた質問を処理する会話レイヤーです。誰かが「VPNのパスワードをリセットするには？」や「新しいソフトウェアライセンスは誰が承認するの？」と尋ねると、ボットが答え、解決し、あるいはチケットを起票します。人の手を介さずにです。

ここで混同されがちな二つのものを分けておく価値があります。ヘルプデスク(またはサービスデスク)は記録システムです。キュー、チケット、SLAがここにあります。Jira Service Management、Freshservice、ServiceNowといったツールがここに属します。チャットボットは従業員と対話し、キューに積み上がる前に簡単なチケットを片付けるAIです。通常はどちらかで置き換えるのではなく、すでに運用している社内ヘルプデスクソフトの上にチャットボットを重ねます。

またIT部門とそれ以外という区分もあります。ほとんどのサービスデスクチャットボットは、ITSMという典型的なユースケースであるIT部門から始まります。IT関連の質問は反復的でドキュメント化されているためです。だからこそ中小規模のITチームでも素早く効果が出ます。しかし同じボットは人事、総務、従業員サポートにも活用範囲を広げつつあります。「有給休暇はどう申請する?」は構造的に「ノートパソコンはどう申請する?」と同じ問題だからです。

サービスデスクチャットボットが裏側でどう動いているか

マーケティングの言葉の裏側では、ほぼすべてのサービスデスクチャットボットが同じ4ステップのループを実行しています。これを知っていれば、ツール同士の違いが一目瞭然になります。

1. 人が質問する場所で耳を傾ける。 従業員はSlackやMicrosoft Teams、ポータル、チャットウィジェットに質問を打ち込みます。優れたボットは、従業員がすでに使っているチャットツールの中で応答するため、新しい習慣を覚える必要がありません。
2. 自社のナレッジを検索する。 ボットはナレッジベース、過去のチケット、連携されたドキュメントから関連する答えを検索します。これが検索拡張生成(RAG)であり、自社のConfluenceスペースに根ざしたチャットボットが、学習データから推測するだけの汎用LLMに勝る理由です。
3. 自信度を確認する。 優れたチャットボットは、答える前にどれだけ自信があるかをスコア化します。自信が高ければ答えます。低ければ黙ってエスカレーションします。このステップこそが本質であり、後ほど改めて触れます。
4. 対応するか、引き継ぐか。 リクエストを解決できるなら、質問に答える、設定をリセットする、チケットを起票してタグ付けするなど、その場で対応します。できなければ、コンテキストを添えたきれいなチケットを起票し、適切な担当者に引き継ぎます。

この「検索してから自信度を確認する」というパターンこそ、真の会話型AIを、みんなにチャットボット嫌いを植え付けた旧来のスクリプト型・決定木ボットと分けるものです。旧来のボットは手作業で組んだルールに従っていましたが、現代の会話型AIプラットフォームはドキュメントを読み込んで自ら理解します。

Slack内で動作するeesel AI。従業員はすでにここで助けを求めています。

今実際に解決できること

ここでは誇張よりも正直さが重要です。サービスデスクチャットボットは、あらゆるAI ITヘルプデスクと同じく、ある特定の種類の作業、つまり高ボリューム・低バリエーション・十分にドキュメント化されたリクエストが非常に得意です。判断力を要する場面は得意ではありません。

自然に向いているリクエスト:

• パスワードリセットとアカウントロック解除。多くの組織で最も多いITチケットです。
• アクセス権や払い出しの申請(「経理用ドライブへのアクセスが必要です」)。ボットがワークフローを実行するか、承認へ回すことができます。
• 既存のドキュメントで答えられる使い方の質問。あらゆるサービスデスクキューの大部分を占めます。
• ステータス確認(「ノートパソコンの注文はどこまで進んでいる?」)。ボットがチケットを読み取って報告します。
• その他すべてのトリアージとタグ付け。これにより人間のキューは整理された状態で届きます。これだけの理由でも、チケットトリアージはROIが最も高い出発点の一つです。

依然として人間が担うべきもの: 進行中のインシデント、ポリシー例外が必要なもの、実際に金銭的・セキュリティ的な重みのある承認、そして誰かが苛立っている会話です。これらを処理しようとするチャットボットは、時間を節約する以上の速さで信頼を損ないます。目標は100%の自動化ではなく、定型的な40〜70%を片付け、チームが人間の頭脳を必要とするケースに注意を向けられるようにすることです。

すべてを本当に左右するたった一つの機能: 自信度

先ほど触れると言いました。この記事から一つだけ持ち帰るなら、これにしてください。人々に信頼されるサービスデスクチャットボットと、ミュートされるチャットボットの違いは、自分が知らないことを知っているかどうかです。

私たちが支援するあるサポートリーダーは、この考え方全体を一文にまとめました。

「AIが100%の質問に答えられるようになることは決してありません。私が必要としているのは、自信を持って対応できるチケットだけを処理し、それ以外のすべてには手を出さないAIです。」

あるDTCサプリメントブランドのオペレーションリーダー、eeselの営業商談より

それに尽きます。それが購入基準です。すべてに自動で答えようとするチャットボットは、十分な頻度で間違え、従業員はやがてどの回答も信じなくなります。そして一度信頼を失えば、サポートは改善どころか悪化します。自信のあるときだけ話し、残りをきれいにエスカレーションするチャットボットは、静かに「正しい」という評判を築き、それが導入の広がりを後押しします。

だからこそ、先ほど触れた社内ITチームは、派手な数字を追いかける代わりに、あえて15%のdeflectionから意図的にスタートしました。ボットには自信のあることだけを任せ、精度が保たれることを確認してから、範囲を55%へと広げていきました。「遅くても信頼できる」は、常に「速いが間違っている」に勝ります。

選ぶときに見るべきポイント

ほとんどのサービスデスクチャットボットはデモの段階では良く見えます。違いが表れるのは3週目です。これまで多くの導入を見てきたうえで、実際に重視するポイントを挙げます。

すでに使っているものと接続できるか。 チャットボットは自社のナレッジを読み取り、サービスデスクに書き戻せなければなりません。Jira Service Management、Freshservice、ServiceNowを使っているなら、その連携が本当に双方向であり、読み取り専用のウィジェットではないことを確認してください。SlackとTeams、ナレッジソース、そしてチケッティングシステムについても同様です。

本番稼働前にテストできるか。 これは多くの購入者が省略し、後で後悔するポイントです。実際に従業員がボットと話す前に、自社の過去のチケットに対してボットを走らせ、実際にどう答えていたかを正確に確認したいはずです。eeselでは、すべての導入をまず顧客の過去数千件のチケットに対してシミュレーションします。自信ありげに聞こえるボットが静かに間違った回答をするのを見てきたからです。シミュレーションは、それを本番環境ではなくスプレッドシート上で捉える方法です。

適用範囲をコントロールできるか。 「パスワードリセットとアクセス申請だけを自動で回答し、それ以外はすべて人間に任せる」と指示でき、ボットがそれを守れることが望ましいです。自信度のしきい値、チケット種別による除外、トピックごとのルールが、範囲を絞って始め、安全に拡張することを可能にします。

料金は予測可能か。 既存のITSMツールの座席課金は、チームが成長するほど高額になり、メッセージ単位の課金モデルはフォローアップのやり取りにペナルティを課します。すでに考える単位であるチケット単位で課金される従量制が、最も予測しやすいものです。

ここに、そもそもチャットボットを導入するだけのボリュームがあるかを確認できる簡単な計算ツールがあります。実際の数字を入力してみてください:

サービスデスクチャットボットがまだ苦手なこと

限界について正直であることは、誠実であると同時に有益でもあります。サービスデスクチャットボットは、その背後にあるナレッジの質を超えることはできません。ドキュメントが古かったり、5つのツールに散らばっていたり、想定と違う読み手向けに書かれていたりすれば、ボットはそのギャップをすべて引き継ぎます。何かを展開する前に、ナレッジベースを整理することが、たいてい最もレバレッジの高い施策です。

また、壊れたプロセスを直すこともできません。払い出しに3つの承認と2つのシステムが必要なら、チャットボットはそれを素早く引き継ぐことはできても、承認そのものをなくすことはできません。そして本物のインシデントを扱えるチャットボットは存在せず、それは常に人間が判断すべきことです。

自前で作りたいという誘惑は、特にエンジニアを抱えるチームにとって現実的なものです。しかし、たいていの場合、あるeeselの顧客が行き着いた場所に落ち着きます。

「自分たちでLLMアプリケーションを書こうと思えばできましたが、そこに時間を投資したくありませんでした。私たちがメンテナンスしなくていいものが欲しかったのです。」

Karel、GENERAL BYTES

週末プロトタイプを作るのは簡単ですが、検索精度、自信度スコアリング、連携、そして継続的なメンテナンスこそが、四半期をまるごと食いつぶす部分です。

eeselを試す

すでに使っているものと連携できるサービスデスクチャットボットを探しているなら、eesel AIはまさにそのために作られています。Jira Service Management、Freshservice、Slack、Teams、そしてナレッジソースに接続し、従業員がすでに質問している場所でIT関連・社内の質問に答えます。

最も重要な2点はこうです。従業員と話す前に自社の過去のチケットに対してボットをシミュレーションできるため、事前に精度とdeflectionを把握できます。そして自信度のしきい値とトピックごとのルールで適用範囲をコントロールできるため、信頼できる範囲だけを任せられます。160のアクティブアカウント全体で、これまでに183,000件を超える実際の会話を処理しており、自社データで無料で試すことができます。