保全AIの回答をどう検証するか｜根拠・抜け漏れ・現場判断を分けて確かめる

保全AIの回答に出典が付いていれば、そのまま業務に使えるのだろうか。資料に書かれた温度を正しく引用していても、対象設備が違ったり、「原因は未確定」という条件を落としたりすれば、保全判断は変わってしまう。

回答の品質を担保するには、文章の自然さや一つの精度スコアだけでは足りない。根拠に沿っているか、必要な情報が残っているか、今の設備に適用できるかを分けて確かめる必要がある。本稿では、RAG評価と保全向け故障診断の研究を手掛かりに、実務での確認方法を整理する。

1. 「原文どおり」と「保全判断に使える」は別の条件

RAGは、社内の報告書やマニュアルなどから関連する情報を検索し、その情報を使ってAIに回答を生成させる仕組みである。ただし、検索された資料が旧版なら、AIが忠実に要約しても、現在の業務には合わないことがある。

たとえば、マニュアルに記された締付条件を正しく引用していても、異なる型式の機器に適用したら誤りになる。過去の故障報告に「シールを交換した」とあっても、今回の異音が同じ原因だとは限らない。資料への忠実さと、対象への適用の妥当性は別々に見る必要がある。

この表は保全業務への適用を考えるための整理である。NISTの生成AI向け文書も、実際の利用に近い条件で評価すること、出力の出典を確認すること、狭い試験結果を広く一般化しないことを勧めている。[1]

2. 回答を一つの文章として採点せず、主張ごとに分ける

「だいたい合っている」という評価では、短い一文に混ざった重大な誤りを見逃しやすい。以下は、確認の仕方を示す架空の例である。

原文： A工場・P-001。8月20日の点検で軸受温度82℃、軸受付近から異音。原因は未確定。再測定を推奨。

AIの回答例： P-001は軸受損傷により82℃まで上昇しているため、次回停止時に軸受を交換する。

設備番号と温度は合っている。しかし、原因、変化の表現、対応方法には原文にない判断が含まれている。

この場合は、工場・設備・測定日、温度、異音、原因未確定、再測定の推奨を残した要約が出発点になる。一般的な原因候補を補うなら、今回確認された事実と混ぜず、仮説として示す。資料のどの箇所が、どの主張を支えているかまでたどることが重要である。

RAGCheckerは、回答と正解例を個々の主張に分解し、正しい主張、誤った主張、欠けている主張を評価する枠組みを提案している。[2] 保全報告のように、一つの回答に設備情報・所見・原因・推奨対応が混在する場面では、この考え方が役立つ。

3. RAGを入れたかより、どの業務で正しく使えるかを見る

保全業務でも、報告書の要約、故障コードの選択、類似事例の検索、対応案の作成は別の課題である。文章として読みやすい回答が、登録すべき故障コードとして正しいとは限らない。

PHM Societyの2025年の研究では、地上車両の技術マニュアルを使い、自由な文章での故障推薦と、既定の故障コードを選ぶ課題を分けて評価した。後者では、検索のみの方法が複数のLLM・RAG構成を上回った。ただし、マニュアルから生成した300件の合成観測データによる限定的な実験であり、実際の工場での性能や現在のAI製品全体を示す結果ではない。[3]

ここから得られるのは「RAGが不要」という結論ではなく、何を任せるかによって比較すべき方法と正解が変わるという示唆である。設備番号の特定は台帳との一致、要約は事実と留保の保持、原因候補の整理は根拠と仮説の区別、記録作成は保存先と内容の一致で確かめる。

自社で導入を評価するときも、現在の検索や担当者の確認方法を比較対象に置く。回答生成によって探す手間が減ったとしても、修正や確認の負担が増えていれば、業務全体では改善していない可能性がある。

4. 間違いを「検索・読み取り・生成」のどこで直すか

回答だけを直しても、同じ誤りが起きる原因は残る。原因を分けると、プロンプトを変えるべきか、資料や検索の仕組みを直すべきかが見えやすくなる。

必要な資料が検索できていない場合。 最新版が登録されているか、工場・設備・型式で対象を絞れているかを確認する。同じ「P-001」が複数拠点にあるなら、設備番号だけの検索では不十分である。AIが見た資料の一覧を残すと、回答から検索過程へ戻って調べられる。

資料は見つかったが、読み取れていない場合。 PDFから抽出した文章と、元の表を見比べる。数値と列見出し、単位、注記が離れると、「どの条件の値か」が失われる。測定値だけでなく、測定位置や運転状態も一組として扱えているかが確認対象になる。

資料を読めたが、回答で取り違えた場合。 別の設備の情報を混ぜた、否定や留保を落とした、資料にない原因を追加した、といった違いを記録する。資料を増やせば必ず解消するとは限らない。必要な根拠を選び、対象との対応を保つ仕組みを見直す。

長い資料を読み込めることと、その全体を使い切れることも同じではない。2024年の「Lost in the Middle」は、当時のモデルを用いた複数文書の質問応答などで、必要な情報の位置によって性能が変わることを示した。[4] 現在のモデルの低性能を断定する材料ではないが、自社資料の長さや配置を含めて試す理由にはなる。

5. 「正解できる質問」だけを集めない

評価に使う質問は、日常の業務から選ぶ。同時に、実務で判断を間違えやすい条件も含める。以下は、保全向けに確認しておきたい場面である。

• 旧版と新版がある。 最新情報を問われたとき、日付や改訂の扱いを確認できるか。過去時点の質問なら、その時点の資料を使えるか。
• 対象が曖昧である。 工場や型式が不明なまま、似た設備の情報で回答を完成させず、追加確認ができるか。
• 資料に答えがない。 未記載の交換部品や原因を創作せず、不足している情報を説明できるか。
• 資料同士が矛盾する。 都合のよい一方だけを採用せず、食い違う値と出典を示せるか。
• 単位や条件が異なる。 測定方法の違う数値をそのまま比較したり、条件付きの推奨を一律の指示へ変えたりしないか。

一方、何にでも「分からない」と答えれば業務には役立たない。答えがある質問で必要な情報を返せるかと、答えがない質問で無理に補わないかを両方見る。

期待する回答や判断基準は、AIの出力を見る前に担当者が原文から整理する。設定の調整に使う質問と、最後の確認に使う質問も分ける。同じ質問への回答だけを繰り返し直して合格させると、初めての質問での振る舞いを確かめられない。

6. 平均点だけでなく、重大な誤りと確認負担を残す

RAGCheckerでは、回答の正しさや抜け漏れに加え、検索で必要な情報を取得できたか、生成が検索結果に忠実かを分けている。[2] 実務でも、評価の分母をそろえずに「精度○％」を比較することは避けたい。

たとえば「根拠に沿った記述が多い」ことと、「質問に必要な情報がそろっている」ことは別である。短い回答は余計なことを書かずに済む一方、判断に必要な条件を落としているかもしれない。反対に、情報量が多くても、根拠のない原因が一つ混ざれば使いにくい。

保全の確認記録には、正誤だけでなく、次の区別を残すと改善先が明確になる。

別のAIに採点させる方法も補助にはなるが、その評価結果自体を確かめる必要がある。前述の保全向け研究でも、評価エージェントが寛容すぎるという限界が報告された。[3] 人が誤りと判断した回答をAIが合格にしていないか、正解例や根拠の位置と併せて見直す。

7. 回答の品質と、実行してよい権限を分ける

保全報告書の下書きを作れることは、設備の停止判断や作業指示まで自動で任せられることを意味しない。確認結果を踏まえ、対象業務ごとに、人が確認する情報と確定する段階を決める。

AIエージェントが記録を保存するなら、文章の確認に加えて、対象設備、保存先、ステータス、保存された内容を照合する。「下書きを作成した」という返答だけで完了にせず、実際の記録を確かめる。未承認のまま確定や作業指示へ進まないことも、回答の精度とは別の確認項目になる。

運用開始後も、モデル、プロンプト、検索方式、資料の版が変わったら、以前の質問で再確認する。失敗した質問だけでなく、以前は正解できた質問も対象にする。確認済みの業務範囲、残っている誤り、人の確認方法を明確にしたうえで、任せる範囲を広げていく。

導入の全体像は設備保全AIの導入ステップ、資料側の整備は設備保全データの品質管理で扱っている。

参考文献

[1] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024。MEASURE 2.3・2.5を参照。公式本文

[2] Dongyu Ruほか, RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation, NeurIPS 2024, Datasets and Benchmarks Track。筆頭記載著者：Dongyu Ru（共同筆頭）、論文掲載時の所属：Amazon AWS AI。§3の主張単位の評価と各指標を参照。論文本文

[3] Sarah Lukensほか, An Evaluation Framework for Fault Diagnosis Using Technical Manuals in Retrieval-Augmented Large Language Models, Annual Conference of the PHM Society, 17(1), 2025。筆頭著者の論文掲載時の所属：LMI。§3.2の合成データ、§5の課題別比較、§6の評価上の限界を参照。論文・書誌情報

[4] Nelson F. Liuほか, Lost in the Middle: How Language Models Use Long Contexts, TACL 12, 2024, pp.157–173。筆頭著者の論文掲載時の所属：Stanford University。当時の評価モデルによる文脈内の情報位置と性能の関係を参照。論文・書誌情報