手書き帳票と設計データを生成AIで検索、IHI機械システムの段階的な検証

要素技術を複数のステップに分けて検証する進め方が、この取り組みの骨格になっています。まずAmazon Kendraだけで検索精度を確かめ、次に検索結果をもとにAmazon Bedrockが回答を作る小さなアプリでRAG（社内の資料を検索してAIの回答に使う仕組み）の有用性を確かめ、そのうえでGenUを用いたユースケースサイトの構築へ進む、という順序が敷かれました。いきなり完成形を目指さず、確かめたい論点を一段ずつ切り分けたことで、業務に合うかどうかの判断を各段階で下せる状態が生まれています。開始時に現場での使い方をていねいに聞き取り、想定するユースケースからテスト手法を先に組み立てていたことも、検証の焦点を保つうえで効いたのではないでしょうか。

検索の対象そのものを作り替えた点も、要因のひとつです。手書きの帳票はAmazon Bedrockで文字をデジタル化して検索できるデータへ統合し、読み取りミスを抑えるためのトレーニングが重ねられています。さらに資料のフォルダごとにタグを付与し、探すための手がかりを検索エンジン側だけでなくデータ側にも持たせました。AI検索の精度はモデルの賢さよりも渡すデータの整い方に左右されるため、この順番には理があります。

現場担当者が自分でアプリを組み立てられる余地を残した設計も特徴的です。ノーコードでユースケースを追加できるGenUの機能をRAG機能搭載型にカスタマイズしたことで、新しい使い道を思いついた人が、そのたびに開発側へ依頼を出さずに形にできます。帳票が保管されたBoxとの自動連携も同じ向きにあり、資料をどこかへ移し替える手間を挟まずに検索対象へ載る流れが作られました。提案から検証、構築までを担ったアイレットが、運用の入り口を現場側へ開いておく形をとった点は、構築して終わりにしないための判断だと読めます。