問い合わせ工数7割削減、太陽光発電の保守部門が使う社内RAGチャット

起点になったのは、出来合いのサービスを買うのではなく、AWSが公開するオープンソースのGenUを土台に据えた構成の選び方です。GenUはAmazon Bedrockと連携し、RAG（社内データを検索して生成AIの回答に使う仕組み）チャットやドキュメント要約を短期間で組み立てられるフレームワークで、ここを出発点にしたことで、コストを抑えながら自社仕様に踏み込む余地が残りました。内製という方針を曲げずに技術的な難所だけを外部の力で越える、という進め方と噛み合った選択だったといえます。

より示唆に富むのは、AIの側をいじる前に、参照される文書の構造そのものを作り替えたアプローチです。地域特例を含む社内規定は従来PDFの表形式で書かれており、生成AIが条件を正確に判断しづらい形になっていたため、表からリスト形式やJSON形式へ改め、特例ルールを明示的に書き下しました。RAGは検索で拾えた断片しか判断材料にできないため、セル同士の関係が失われる形式のままでは、規定が正しくても読み違いが起きます。もっともらしい誤答を出力側で抑え込もうとするより、入力の作り方を正す。この順序の付け替えが、実運用に耐える精度を引き寄せた要因ではないでしょうか。

三つ目は、更新に耐える形でカスタマイズを設計し、その改修方法まで引き渡した進め方です。GenUは頻繁にバージョンアップされ、Amazon Bedrockの機能更新に伴ってバックエンド処理が大きく変わることもあるため、手を入れた箇所がアップデートの影響を受けにくいよう設計されました。部門・用途ごとにナレッジデータが増える将来を見越し、画面パスに応じて複数のナレッジベースを切り替えられる方法をフロントエンド・バックエンド双方の改修手順ごと共有した点も、引き渡し後を織り込んだ設計思想の表れです。プロジェクト途中でAmazon Auroraのベクトル機能に技術的制約が判明した際、コスト・パフォーマンス・アップデート追従性を並べてAmazon OpenSearch ServerlessとBedrock Knowledge Basesの組み合わせを提案し直した判断も、同じ考え方の延長線上にあります。