従来のカスタマーサポートにあった「待機」と「検索」による不満
昨今のAI活用によるビジネス変革には目を見張るばかりだ。本題に入る前に、まずはAI活用で革新的な顧客体験を提供しているイギリスのIsabel Healthcare社の事例を採りあげよう。
同社はAIを活用した鑑別診断支援ツールを各種提供している。ユーザー（患者）向けには、オンラインで質問に答えることで適切な診療科を案内するアプリがある。ほとんどのユーザーは1分以内でトリアージを完了できて、57％がオンライン予約へ進むなど、素早く適切な受診までの導線を提供している。これにより体調不良を抱えたユーザーに素早く解決へと進むことができる体験を提供し、92％が再利用を希望するなど高い満足度も実現している。
レッドハット社もカスタマーサポートにおける課題解決のために対話型AI「Ask Red Hat」を導入して成果を挙げている。これまでカスタマーサポートでは、顧客は待機と検索の壁に阻まれてフラストレーションがたまり、エンジニアは定型業務と属人化で疲弊してしまうことが課題となっていた。
特に顧客からは「サポートからの折り返しを1時間待つより、すぐに自己解決したい」という切実なニーズが急増していた。しかし製品やバージョンが増え、欲しい情報に即座にたどり着く手段は不足していた。一方、サポートエンジニアは定型的な（単純な）問い合わせ対応に追われて疲弊しており、今後ますます多くのサポートに対応していくためにも自己解決の仕組みが不可欠だった。
同社のアジア太平洋CTOオフィスでチーフアーキテクトを務める駒澤健一郎氏は「これらの課題から顧客とエンジニア双方を解放し、満足度を高めるために『Ask Red Hat』を開発することにしました」と説明する。
Ask Red Hatは親しみのあるチャットボット型UIとなっている。現在の課題や障害の状況を自然言語で入力すると、AIが社内のバックエンドシステムに適切な検索をしたうえで、問題の概要、発生パターン、推奨される解決策に参考情報も含め、情報を整理してユーザーに提示する。こうした情報で顧客が自己解決できることを目指す。
これは従来のデジタル窓口とは大きく違う。従来型はユーザー自ら解決策を検索する自己責任型で、情報は業務プロセスに応じて分かれているため顧客の意図に沿った回答にたどり着くのが難しかった。
一方、Ask Red HatはIFD（インテリジェント フロント ドア）型になっている。IFDでは、すべての顧客は単一の統合インターフェースからアクセスし、適切にパーソナライズされた解決策や自己解決のためのガイダンスを入手できる。
質問に「答える」から「行動する」エージェントへ
駒澤氏は「Ask Red Hatは開発当初から、単に『答える』だけではなく、『行動する』AIにしようというビジョンを掲げていました」と話す。これは顧客からの質問に回答するだけではなく、システムと連携してタスクを実行するAIエージェントを目指すことを意味する。
特徴的な機能には自律的なルート誘導（ルーティング）がある。これは顧客からの意図に応じてセルフサービスを促すのか、別の専門AIエージェントを呼び出すのか、あるいは人間のサポートにつなげるのかといった意思決定をしたうえで、顧客を適切なルートに誘導する。
加えてサポートではナレッジが何よりも重要だ。学習と改善を継続することで、AIエージェントが自ら賢くなり続けるサイクルが備わっている。こうした仕組みを通じて、待ち時間を限りなくゼロにして、サポートケース発生を未然に防ぐなど、人間だけでは成し遂げられなかった圧倒的なスピードとコスト回避でROIの最大化を目指す。
本番運用開始は2025年5月から。約半年後となる同年末時点で、5万以上のユニークユーザーが利用し、45万件以上ものメッセージに対応した。サポートエンジニアへの負荷を軽減しながらも、顧客の解決時間を短縮するなど、レッドハットを導入した本番環境を強力に支える仕組みとなっている。
具体的に「Ask Red Hat」はどのように動いているのか。推論エンジンは、オープンウェイトで自社内に閉じた意思決定を行うためにIBM Graniteアーキテクチャ（IBM Granite-3.x 8B-Instruct）を採用している。駒澤氏は採用理由として、RAG（検索拡張生成）の精度が高いことと、Apache 2.0で商用利用できることの2点を挙げる。現状ではさまざまなモデルをABテストで比較しながら運用しているものの、将来的にはレスポンス最適化と軽量化を狙い、Granite-4.x Smallへ移行する計画で開発を進めている。
もう1つの採用理由となるのがGranite Guardian、ガードレールに特化したモデルだ。単一のLLMでまかなうのではなく、ガードレールはガードレールとして別に管理するアーキテクチャにしている。これによりジェイルブレイク（悪意あるプロンプト）を防御し、AIを本来のタスクに専念させる。RAGパイプライン最適化によりMRR（検索精度指標）が45％向上、常に製品バージョンに適合したドキュメントを正確抽出している。加えて「BYOR（Bring your own risk）」として、プラグインで独自のリスク管理を拡張する機能もある。こうした仕組みで安全性やセキュリティを担保している。
AIサービスの効果を「対応完了件数」と「未然回避件数」で測る
AIサービスにおいていまだに難しい課題となっているのが費用対効果だ。特にカスタマーサポートにおいてKPIをどう設定するかは難しいところ。一般的には対応完了件数で測定しがちだが、レッドハットはユーザーの自己解決支援に着目して新たに未然回避件数でKPIを設けることにした。
きっかけとなったのはあるユーザーからのフィードバックだ。「もし5分で自己解決できるなら、例えば1時間後になるかもしれないサポートからの折り返し電話を待つより、自分で解決したい」。これこそユーザーが切実に願うニーズの1つだからだ。
とはいえ、どう計算するか。サポートケース化を未然に防ぐことで得られた「顧客の満足」と「サポート部門の工数削減」を財務的な「コスト回避」として定量化することにした。計算方法としては、自己解決に至った想定件数とサポートケース1件あたりの算出処理コストの積とする。
実績を見ると、2025年単年で約150万ドル（約2.2億円）。これだけのサポートコストを回避できたことになる。駒澤氏は「これで十分に投資額に見合うと評価されてAsk Red Hatのプロジェクトは継続しています」と話す。
現状では対話型アシスタントだが、今後は行動するAIエージェント（エージェンティックAI）として、統合オーケストレーションレイヤーへと進化する。バックグラウンドの業務システムとの連携、自律的な思考・計画・タスク完結、複雑なプロセスのオーケストレーションができるように開発を進めている。
フロントエンド部分は「Ask Red Hat」が担い、背後にいる3つのエージェントへとルーティングする。背後のエージェントは「Librarian Agent（図書館の司書のようにデータのありかを把握してデータを引き出す）」、「Investigator Agent（調査官のように問題を適切に解決に導く）」、「Generator Agent（YAMLやプログラムなどを生成する）」がある。
さらに今後はマルチベンダーでAIエージェントを連携しようとするPoCが進んでいる。対象となるのが基地局（RAN）の機能をクラウド上で動かす「Ericsson Cloud RAN」だ。ここで障害が起きると、ネットワーク（エリクソン）・ハードウェア（Intel）・Linux（レッドハット）で切り分けが必要になる。そこでアラームやチケットをトリガーにオーケストレーターが起動し、それぞれの会社のAIエージェントがMCPでつながることで、原因やエビデンスなどを提示して早期の問題解決を図る。
最後に、ある意味「AIの脳」といえるナレッジの保守について。駒澤氏は「エージェントが自律的に行動する手足であるためには、脳となるナレッジが常に最新でなくてはなりません。そのためにはデータの品質や鮮度が重要になります」と話す。そのためレッドハットではデータパイプラインを最適化することで、ドキュメントを管理するシステム（docs.redhat.com）に投入されたデータは4分以内にAsk Red Hatで使えるようにナレッジが同期されるようにしている。
いまAIとともに、従業員や顧客が役割を再定義しながら最適な仕事の進め方を模索する時代に来ている。最後に、駒澤氏は「レッドハットでは、属人的なサポートビジネスから、AI活用することで定型的な業務をなるべく人間から引き離して、より高度な問題解決に専念できるようにしています。AIで全てを解決するという発想ではなく、より人間にふさわしい働き方、スキルの生かし方に着目して開発しています」と話し、講演を結んだ。
