社内ITヘルプデスク向け生成AI、回答精度80％超を確認した通信会社の検証

出発点は、社内ナレッジの検索を生成AIでもっと便利にできないか、という社内からの要望でした。ナレッジ検索の仕組みとしては既存のチャットボットがすでに動いていましたが、そのメンテナンスコストが課題として挙げられています。

編集部の見立てでは、困りごとの中心にあったのは「探せないこと」そのものではなく、答えられる状態を保ち続ける手間のほうではないでしょうか。想定問答を人が用意し、社内制度やIT環境が変わるたびに手を入れ直す運用は、担当部署にじわじわと負荷を積み上げていきます。もう一つ見逃せないのは、同社ではすでに全社規模で生成AIの利用が進んでいたという事情です。日常的に生成AIに触れている組織だからこそ、社内文書に基づく回答をどこまで任せてよいのかを、印象ではなく評価結果として持つ必要があった。いきなり実装せず、まず試して精度を確かめるという判断は、そうした土壌から出てきたものと考えられます。

対象を社内ITヘルプデスクという一つの業務に絞り、実装ではなく検証から入った設計が、この取り組みの土台になっています。題材に選ばれたのは、PCの不具合対応やシンクライアントの申請手続きのように、日々発生し、答えが社内文書のどこかに書かれている問い合わせでした。正解の所在がはっきりしている領域であれば、AIの回答が合っているかを人が判定でき、精度という物差しが機能します。範囲を欲張らなかったことが、評価に耐える検証を成り立たせたと見ています。

セキュリティを最優先事項に据えた環境設計も、この検証を前に進めた条件でした。クラウド上の各機能をインターネット経由ではなく仮想ネットワークでつなぐ閉域構成とすることで、社内ドキュメントを持ち込める土台がつくられています。社内ナレッジを扱うRAGでは、回答精度以前に「その文書を置いてよい環境かどうか」が関門になりがちで、そこを先に固めた順序に意味があったのではないでしょうか。

精度の追い込み方も、モデル任せではありません。取り込むデータの前処理、検索手法の選定、データ構造の最適化と、回答の材料側を整える作業が積み重ねられています。加えて、1週間ごとに出力してほしい項目を変えながら検証と評価を繰り返す進め方が採られ、後から浮上したセキュリティ要件や制約に対しても、インフラ構成の変更や機能追加で対処されました。条件を短いサイクルで振りながら回すこのやり方は、何が効いて何が効かないかを切り分ける手段として働いたと考えられます。

検証では、特定の検証方法において、社内ドキュメントをもとにした回答精度が80％を超えました。あわせて、社内のセキュリティ基準を満たす環境で生成AIを試せたこと、生成AI活用の勘所やハルシネーション（AIが事実と異なる情報を答えてしまう現象）への対策を実例とともにつかめたことが、社内に残ったものとして挙げられています。取材時点では評価作業が続いており、得られた知見は報告書にまとめて全社会議で説明される予定です。社内ITヘルプデスクへの適用そのものは、既存チャットボットとの並行運用を通じて見極める段階にあります。