実証実験3か月で正答率5割から8割へ、電子デバイス企業の社内ナレッジ検索AI

マニュアルを見れば解決できる質問まで開発者本人に直接寄せられ、その対応に人手が取られていた。加賀FEIが生成AIに目を向けた出発点は、この状態でした。そこに、技術者の高齢化や離職で技術の受け渡しが細っていく懸念と、生成AIを使いたいが具体的な進め方が見えないという迷いが重なります。

編集部の見立てでは、ここで効いていたのは問い合わせの件数そのものではなく、答えが社内の資料に存在しているのに「詳しい人に聞いたほうが早い」という状態が固定化してしまっていたことです。資料が読まれないのは現場の怠慢ではなく、専門的な情報のどこに答えがあるかを探す手間が、担当者に尋ねる手間を上回っていたからでしょう。だとすれば必要だったのは、マニュアルを読ませる働きかけではなく、探す行為そのものを肩代わりする仕組みだったと考えられます。

AIが認識しやすい形にデータを組み替えるという判断が、この検証の土台になっています。もともと社内の情報は煩雑なXML構造で保持されていましたが、これをJSON形式へ変換し、可読性を高めたうえでAIに渡す設計へ切り替えました。RAG（社内の文書を検索してAIの回答に使う仕組み）は、探し出した文書をそのままAIに読ませる構造であるため、モデル側の調整よりも渡すデータの形が回答の質を左右します。プロンプトの工夫に手を伸ばす前にデータ構造そのものへ立ち返った順序が、後の伸びしろを作ったのではないでしょうか。

短い期間に版を重ねる進め方も、この取り組みを支えた要素です。技術製品の専門情報を扱う以上、事実と異なる内容をもっともらしく答えてしまうハルシネーションは業務に直結する障害となるため、定期的な打ち合わせで検証と改良を繰り返し、3か月でバージョンは8まで進みました。途中で登場した Gemini 2.0 への切り替えが転機になっている点も見逃せません。基盤モデルを固定せず、外部の進歩をそのつど取り込める余地を残しておいたことが、データ側の作り替えとかみ合ったと言えます。

検証の出口を最終報告書ではなく報告会に置いた設計は、技術面とは別の意味で重要でした。役員層とプロジェクト外のメンバーに向けて、複数の視点をまとめた資料で成果を共有する場が用意され、その資料は報告会の後も業務で使われています。PoCを技術検証だけで閉じず、社内の理解を作る工程まで含めて組み立てたことが、次の展開を引き寄せた要因と見ています。

データを入れただけの段階では5割ほどだった正答率は、改良を重ねた結果8割ほどまで上がり、担当者が信頼して使えると判断できる実用レベルの精度に到達しました。手応えは組織にも及び、2025年4月には社内横断のワーキンググループ形式で生成AIの専門部署が発足。ソリューション推進部が事務局を担い、業務アプリの運用を内製化する目標のもと、4部門でそれぞれの製品に合わせたチャットボットを立ち上げる動きが進んでいます。