生成AI導入で実際に作った6つのアプリと、そこから得た3つの教訓

はじめに

生成AIを業務に導入する際、「どんな使い方ができるのか」という具体的なイメージを持てない企業は多いのではないでしょうか。本記事では、社内で実際に検証・運用したユースケース6例を紹介するとともに、試行錯誤の中で見えてきた設計上の教訓を解説します。

システムのテーブル名と抽出条件を入力すると、SQLクエリを自動生成するツールです。SQL知識のない担当者でも、必要なデータ抽出を自力で行えるようになり、開発担当への問い合わせが大幅に減少しました。

処理名を入力するだけで、その手順をステップ形式で教えてくれるチャットです。引き継ぎや新担当者の立ち上がり支援に活用されています。

RPAツールの操作手順や自動化の実装方法を答えてくれるチャットです。ノウハウを持つ担当者に集中していた問い合わせを分散させることができました。

就業規則・給与・休暇制度など、人事部門への問い合わせをAIが一次対応します。よくある質問への回答を即時に提供し、担当者の対応負荷を軽減しています。

システム操作・ネットワーク設定・機器の使い方など、情報システム部門への問い合わせに対応するチャットです。一次対応をAIが担うことで、担当者がより高度な業務に集中できるようになりました。

クレームの概要・発生日時・対応内容などを入力すると、報告書のフォーマットに沿った文章を自動生成します。記載漏れの防止と、作成時間の短縮に貢献しています。

定例処理手順チャットの初期バージョンでは、どんな入力に対しても「答えを出す」よう設計していました。しかし、AIがナレッジに存在しない処理について、もっともらしいが誤った手順を生成してしまうケースが発生しました。

現場の混乱と信頼低下につながったことを受け、設計方針を転換しました。

変更後の設計：

ナレッジはあっても、AIが内容を噛み砕いて説明しようとすると、解釈のズレや誤りが生じるリスクがあります。「AIが説明する」より「正確なマニュアルに誘導する」方が、業務手順のような正確性が求められる用途では信頼性が高く、結果的に長く使われるアプリになります。

人事チャット・情シスチャットの初期設計では、Q&Aを手作りして充実させる方針を取っていました。しかしこのアプローチには2つの問題がありました。

現在の設計方針：

「AIがすべてを解決する」前提ではなく、「AIと人間が連携する」前提で設計することが、社内問い合わせチャット成功の鍵です。

RAGを使ったアプリ開発において、当初は生成側（G：Generation）のプロンプトの精緻化に多くの時間を費やしていました。しかし、いくらプロンプトを磨いても、検索精度（R：Retrieval）が低ければ「もっともらしい誤った情報」を生成するリスクは解消されません。

優先すべき取り組みの順序：

RとG（Retrieval と Generation）のそれぞれの役割を明確に意識した上で設計に臨むことが、RAGアプリの品質向上における最短経路です。

実際に手を動かして見えてきた共通の教訓は、「AIを過信しない設計」です。

これらを意識した設計が、現場で長く使われるAIアプリの条件です。まずは小さいスコープから始め、試行錯誤を通じて組織に合ったユースケースを育てていくアプローチをお勧めします。

mickeyさん ／製造業の情シス部長として、セキュリティ×AI活用を現場で実践中。経営層・管理職が使える言葉でDX・AI・セキュリティを発信しています。

執筆・登壇・顧問のご依頼はこちら
noteでより詳しい実践ノートを公開中
X（Twitter）でも毎日発信中