過去の不具合・対策を根拠付きで探す｜製造業向けAIナレッジ検索の開発例

対象：金属加工メーカーの品質保証・生産技術部門を想定カテゴリ：AI・Webシステム

工場ごとに保存した不具合報告書や是正処置報告書を横断検索し、類似する過去事例を原本付きで確認するシステムの開発例です。品質担当者が今回の調査項目を考えるための情報を提供する構成を紹介します。

プロジェクト概要

この仮想事例では、品質担当者が似た不具合を調べる際、工場ごとの共有フォルダや異なる様式の報告書を探している状況を想定しています。同じ症状でも書き方が違い、品番が変わると似た加工や材料の事例にたどり着きにくい、という課題です。実際に納品・導入した顧客事例ではありません。

最初は1工場・1製品群の報告書に対象を絞ります。どの資料があり、材質、工程、症状、原因、対策がどう記録されているかを確認し、過去の問い合わせで必要だった事例を評価に使う計画です。すべての資料を一度に取り込むより、役立つ検索と原本に沿った要約ができるかを先に検証します。

例えば「アルミ部品の穴径が、連続加工すると規格の上限を超える」と入力します。システムは関連する報告書を提示し、担当者は当時の発生条件、確定した原因、実施した対策、検査結果を確認します。

原本へのリンクを残し、要約だけでは分からない前提を品質担当者が確かめる流れです。

たとえば、連続加工で寸法が変化する現象を入力し、関連する報告書を見つけた場面です。担当者は、当時の材質、設備、加工工程、発生タイミングを今回の条件と比較します。

原因が同じとは限らないため、過去の報告書で何が確定し、どの対策を実施し、結果がどうだったかを分けて確認します。必要な条件が報告書に書かれていなければ、その点も比較できない情報として扱います。

システムが示すのは調査の材料です。品質担当者が原本を参照し、今回の設備や材料の違いを踏まえて確認項目を選ぶ流れを想定しています。

過去に似た現象があっても、今回の原因が同じとは限りません。システムは原本にある発生条件、確定した原因、実施した対策を分け、資料にない情報は補わない設計にします。品質担当者が設備や材質の違いを確認し、次に調べる項目を選ぶための情報を提供します。

検証後に対象を広げる場合も、検索できたことと要約が正しいことを別々に評価します。必要な事例が出ないときは検索対象と抽出情報を見直し、根拠があいまいな要約は原本との対応を調べる計画です。検索と要約の評価を分け、現場で使える範囲を確かめながら改善する計画です。

原本に記載のない原因や対策は補わず、調査中の仮説と確定した原因を区別します。検索結果は今回の原因を決定するものではなく、確認すべき条件や過去の対策を調べるための情報です。

構成案では、顧客管理下のAWS環境でLLMと検索基盤を運用します。GPU付きEC2上のコンテナでLLMを動かし、文書取込・検索APIを分けることで、外部の生成AI APIへ文書を送信しない運用を想定しています。

保存された資料を取り込むこと、検索できる情報を作ること、関連資料を探すこと、結果を要約することは異なる処理です。どの資料が検索対象になっているかを運用側が確認できることも必要になります。

設計例では共有フォルダからの定期取込を入口にし、更新と取込失敗を管理画面で確認する構成を想定しています。原本の変更が検索へ反映されているかを、資料単位で確かめられることを検討します。

閲覧権限も検索と要約の両方へ関わります。担当者が参照できる資料を対象にして、検索結果と要約に出る情報の範囲を合わせる設計です。回答の見やすさだけでなく、対象資料と根拠を管理することを重視します。

想定する支援範囲は、業務整理・要件定義、文書・検索・権限設計、画面とAPIの開発、AWS環境構築、検証、リリース対応、追加開発、運用保守です。実施済みの担当工程を示すものではありません。

最初は1工場・1製品群の報告書に限定し、必要な事例が検索できるか、要約が原本と一致するか、担当者自身で調査を進められるかを評価します。図面の自動理解や画像からの不良判定まで一度に広げない計画です。

本記事は企画用の仮想事例です。実際の顧客への納品、検証完了、本番運用や効果測定の実績は示していません。

対象業務と必要な機能を整理するところからご相談いただけます。既存システムとの関係も含めて、開発範囲を検討します。