AIエージェントあるいはRAGでサービスデスクを代替できるか？──詰まる理由と現実解

「問い合わせ一次対応・サービスデスクをAIで置き換えたい」という相談は、もはや一般的な発想と言ってよいのではないだろうか？実際、やりたいこと自体は明快である。待ち時間を減らし、オペレータ負荷を下げ、人員を減らし、対応品質を平準化したい。この目的に異論はない。

よくある失敗はその手段として「とりあえずRAGに全部食わせる」が選ばれやすいことである。私自身、過去ログ・組織内Wiki・チャット履歴をまとめて投入する構成を検証したが、得られたのは期待した効率化ではなく、一見それらしく見えるゴミ回答の量産だった。

結論は明確である。一部代替は可能だが、ナレッジ運用を設計しないSD代替は高確率で失敗する。そして失敗原因の大半はモデル選定ミスではない。入力データの質と、運用責任の設計不足である。

サービスデスク領域では、回答の正しさと監査可能性が同時に求められる。この2つを両立するには、最終的に「承認済みで組織として正しい公式ナレッジ」に着地するしかない。

先に結論

過去ログを丸ごと投入しても、品質が低ければゴミを高速検索し、ゴミのような回答を返すだけである。
組織内情報を全投入しても、公式と非公式の境界が曖昧なら、組織としての公式なコンテキストやルールを前提とせず、誤答を正当化する装置になる。
一般論だけで回答する構成は、組織のルールに反して現場で使えない。
現実解は、KCS（Knowledge-Centered Service）ループをAIアシストで回し、参照元の品質と責任者を明確化することである。
承認済みの公式ナレッジを参照できないAIは、サービスデスク本番では運用に耐えない。

なぜ「とりあえず全部入れる」が失敗するのか

1. 過去の対応ログは、そもそも知識ではない

多くの問い合わせログは、現場でチケットを閉じるために書かれている。それ自体は業務として正しいが、再利用可能な知識としては不十分なことが多い。

前提情報が欠落している（利用端末、権限、接続経路、環境差分）。
チケット完了を目的にしており、極端な話「対応完了」で終わっていたりする。再利用を意図していない。
省略語と口語が混在し、担当者の暗黙知に依存している。
根本原因と暫定回避策が分離されていない。

この状態のログをRAGに投入すると、検索は成功したとしても回答はまともにならない。人間が読んでも曖昧だったり意味不明だったりする文書を、AIがもっともらしく補完してありもしない妄想の回答が出来上がってしまうからである。「答えが速い」のに「解決しない」という、厄介な状態になるのだ。プロンプトが悪いのかと思って一生懸命チューニングしようとしてもおそらく徒労に終わる。少なくとも私はそうなった。

2. 組織内情報の全投入は「公式の希釈」を起こす

「組織内Wiki全部」「ファイルサーバ全部」「チャットログ全部」を読ませる構成は、見た目だけは網羅的である。しかし実態としては、信頼度の異なる情報を同じ検索面に並べる行為に近い。

典型的には以下が起きる。

公式手順（承認済み）と個人メモ（未承認）が同列で検索される
廃止済み手順が残存し、最新手順と競合する
一時対応のノウハウが恒久手順として誤引用される
記事の更新日時は新しいが中身は古い、という逆転が起きる

RAGは「文書を見つける」のは得意である。だが「その文書が組織として正しいか」を保証する仕組みは、別途運用で作らなければならない。

3. 組織ルールを知らない一般論は、正しくても使えない

公式ナレッジが不十分なAIがよく返すのは、技術的には正しいが運用的に実行不能な回答である。

ローカル管理者権限の付与
セキュリティ設定の一時緩和
個人判断での外部クラウド利用
部門横断データへの直接アクセス

AIが一般解を返しても、組織ルールに反していれば実行不能である。この瞬間、サービスデスクAIはルール違反を正当化する装置にすらなりかねない。業務課題の解決装置には成りえない。

現場で起きる失敗例

失敗例1: VPN接続障害で誤誘導

症状: 「在宅からVPN接続できない」
AI回答: 「OSのネットワーク設定を初期化し、再起動してください」
実際: 原因は認証基盤側の証明書失効であり、利用者側で解決不能

なぜ起きたか。過去ログに「個人端末の一時不調」が多数含まれており、AIがそこへ引っ張られたためである。さらに「サービス側障害の切り分け」手順が公式ナレッジとして弱く、上位候補に上がらなかった。加えて、そもそも「NW設定をユーザが勝手にリセットしてよいのか」という組織コンテキストが回答に織り込まれていない。

失敗例2: ソフトウェア申請で規定違反を提案

症状: 「分析ツールを使いたい」
AI回答: 「試用版を各自でダウンロードして利用開始」
実際: 組織では調達・ライセンス管理・持ち込み審査が必須

なぜ起きたか。社外一般記事と個人メモを参照し、公式の調達フロー文書が埋もれたためである。「できること」と「やってよいこと」を分離できていない典型例である。

失敗例3: 同じ質問で回答が毎回変わる

症状: 「メール転送設定の手順は？」
AI回答: 日によって異なる
実際: 古い運用手順ページと新手順ページが共存

なぜ起きたか。「有効版」を示すメタデータ（有効開始日、廃止日、承認者）が無く、検索順位で回答が揺れたためである。個人メールやチャットの断片が混ざると、非公式説明が偶然上位に出る確率も上がる。

ではどうするか：KCSループをAIアシストで回す

現実解は、KCSをAIで置き換えることではない。 KCSをAIで加速することである。

KCSとは何か

KCS（Knowledge-Centered Service）は、問い合わせ対応の現場で生まれた知識を、その場で記録し、再利用し、改善し続ける運用思想である。重要なのは「解決した後で文書を書く」ではなく、解決行為そのものに知識更新を埋め込む点である。 RAG時代にKCSが再評価される理由は単純で、検索先の品質が回答品質をほぼ決めるからである。

小話：古い話だが効く

KCSは1992年に始まった考え方で、AIよりはるかに古い。それでも現在有効なのは、現場の課題が本質的に変わっていないからである。

ログはあるが読めない
文書はあるが公式がわからない
更新されず腐る

生成AIを入れると、この3つは消えるどころか増幅しやすい。だからこそ、派手な新機能より先に、地味だが壊れにくいKCSの型へ戻る意味がある。

KCS運用の最小構成

Capture: 問い合わせ対応時に、症状・原因・対処・適用条件を構造化して記録
Structure: テンプレート化し、環境条件・対象範囲・禁止事項を必須項目にする
Reuse: 次回問い合わせで参照し、回答と根拠URLをセットで提示
Improve: 実運用の差分を反映し、曖昧語や古い手順を継続修正

実運用ループ：AI回答を公式ナレッジで育てる

現場では、次のループで徐々に適用範囲を広げるのが現実的である。

ユーザがまずAIに問い合わせる
AIで解決しなければサービスデスク（SD）へエスカレーションする
SDの対応記録をAIに読ませるのに適したテンプレートでナレッジ化する
レビューを通過した承認済みの公式ナレッジだけをAIの参照データソースに追加する
同種問い合わせでAIの一次回答率と正答率が上がる

このループの要点は「量」よりは「承認」あるいは公式回答に使えるナレッジの蓄積である。「記録された情報」ではなく「承認された情報」だけをAIのデータソースにする。ここを崩すと、回答範囲は広がっても正しさは広がらない。

AIに任せられる領域

類似問い合わせのクラスタリング
下書き回答の生成（根拠付き）
欠落項目の指摘（「対象OSが不明」「権限前提が未記載」など）
重複ナレッジの統合候補提示

人間が責任を持つべき領域

公式/非公式の判定
手順の承認と廃止判断
例外対応の許可
ナレッジの有効期限管理

ここをAI任せにしようとしてもまともな受け答えをするAIにはならない。

実務上のポイント

以下は実務上留意すべき観点である。

ナレッジ運用側

誰がいつどのような公式ナレッジを作成し公開するのかを定義し、作成と品質担保のスキームを決める。
誰がそのナレッジを閲覧できるのかを定義し、アクセスコントロールを決める。

AI側

回答には必ず根拠を示すよう、プロンプトで明示的に指示する。
非公式・非承認ソースを回答生成で使用させない。

改善運用

AIの誤答を収集する手段を決定し、改善のためのナレッジ作成を通常業務に組み込む。

この3点は抽象論に見えるが、実装するときに差が出る。「誰が責任を持つか」を先に決めたチームは改善が速く、決めないチームは同じ誤答を繰り返す。

「代替できるか？」への答え

サービスデスクをAIエージェントで100%代替できるか、と問われれば現時点の答えは「できない」である。ただし、問い合わせ種別を分解し、ナレッジ責任を明確化した運用を組めば、 一次回答・定型案内・標準手順の提示は十分に代替可能である。

つまり論点は、AIの賢さそのものではない。

どの知識を公式として採用するか
誰が品質を保証するか
間違ったときに誰が止めるか

この3点を設計できる組織だけが、AIエージェントを「チャットが速いだけの道具」から「業務の戦力」に変えられる。逆に言えば、承認済み公式ナレッジの運用を持たない組織は、どれだけ高性能なモデルを使ってもサービスデスク品質を作れない。

まとめ

「ログを全部入れれば賢くなる」は幻想である。サービスデスクAIが詰まる本当の理由は、知識の量ではなく知識の統治不在にある。

今やるべきことは、壮大な全自動化ではない。 KCSループをAIアシストで回し、公式ナレッジを育てる地味な運用である。

この地味さを受け入れた組織から順に、回答品質は目に見えて変わる。サービスデスクでAIを使うなら、最優先は常に同じである。 承認済みで組織として正しい公式ナレッジを、継続的に育てること。