アマダ、生成AIで社内IT問い合わせを自動化しヘルプデスクの稼働時間を3時間短縮

決め手になったのは、生成AIに検索させるデータを新たに作り直さずに済む方式を選んだ点です。先に検討していた仕組みでは学習用（検索用）のデータを別途用意する必要があり、その工程自体が精度と工数の両方で足かせになっていました。既存のデータやドキュメントをそのまま検索対象にできる方式へ切り替えたことで、準備作業の性格が「新しく作る」から「いま持っているものを整える」へと変わっています。約2週間という短いPoCで採否の見通しを立てられたのも、この前提の違いが効いたと考えられます。

運用の担い手を業務部門側に置けるかどうかを選定の基準に入れた判断も見逃せません。コーディングを前提とする仕組みでは、Q&Aの追加や修正のたびにプログラミングができる人材の手が必要になり、問い合わせ内容の変化に追随しにくくなります。手を入れられる人を増やしておく設計は、公開直後の精度よりも、運用が続くほど差が開いていく部分です。

この事例に固有の工夫として挙げたいのが、閲覧権限の壁を残したまま回答経路だけを開いた設計です。社内IT関連のドキュメントはGoogleドライブ上で閲覧者を絞って管理されていましたが、CTCは生成AIによる検索専用のアカウントを設け、社員の誰もがBenefitterを介して必要な情報にたどり着ける形をとりました。あわせてCTCはBenefitterの仕様そのものを改修し、検索対象にできるドキュメントの形式と数を広げています。本来なら半年規模とされた構築を約2カ月で立ち上げられた背景には、製品の作り手側が仕様に手を入れられる体制があったことが大きいでしょう。