電力データに異常が出ても「どのマニュアルの、どのページを見ればいいか」が分からず対応が遅れる——。散在する設備マニュアル・保全履歴・過去の改善メモを、電力データの異常と結びつけて横断検索できないか。RAGという選択肢の前提条件と限界を、現場の手触りで整理します。
電力の見える化を進めると、ある設備の消費電力が普段より高い、あるいは待機中なのに下がらない——といった異常が数字として見えるようになります。ところが現場でよく起きるのは、その先で止まってしまう状況です。「この設備が高いのは分かった。では次に何を確認すればいいのか」。この問いに即答できる人が、たいてい一人か二人の熟練者に限られているのが実情ではないでしょうか。
確認すべき情報は、そこかしこに散らばっています。設備メーカーの分厚いマニュアル（多くは紙かPDF）、保全担当が残した点検・修理の履歴、過去に同じような症状が出たときの改善メモ、さらには担当者の頭の中だけにある「あれはたぶんベアリングかヒーターだ」という勘所。これらが一つの場所に集まっておらず、しかも電力データと結びついていないために、異常を見つけてから確認項目にたどり着くまでに時間がかかります。
この課題が重くなっている背景には、電力価格の上昇と保全人材の不足が同時に進んでいる事情があります。電気代が上がれば、わずかな異常消費や待機電力の垂れ流しも無視できないコストになります。一方で、設備の癖を知り尽くしたベテランは減り、若手や多能工が慣れない設備の異常にも対応せざるを得ない。「熟練者に聞けば分かる」体制は、その熟練者が休みや退職でいなくなった瞬間に機能しなくなります。省エネ法の定期報告やCO2算定といった制度対応の負担も年々増しており、現場は「見える化」の一歩先、つまり原因究明と改善行動の効率化を求められていると考えられます。
「マニュアルと電力データを横断検索したい」という要望を分解すると、いくつか性質の違う問題が混ざっていることが分かります。ここを整理しないまま「AIで検索」と進めると、期待とずれた結果になりがちです。
紙のマニュアルをスキャンしただけのPDFは、画像として保存されているだけで文字として検索できないことが多くあります。保全履歴が手書き台帳やExcelの自由記述欄に散っている場合も同様です。検索の入口以前に、文書が機械で読める状態になっているかが最初の分岐点になります。
従来の全文検索は、入力した単語がそのまま含まれる文書を返します。しかし現場で起きるのは「消費電力が下がらない」という症状から「ヒーターのサーモスタット固着」という原因語にたどり着きたい、といった言い換えを跨ぐ検索です。症状の言葉と原因・対処の言葉が文書内で一致しないと、キーワード検索では引っかかりません。ここが、意味の近さで探す仕組み（ベクトル検索）が候補に挙がる理由です。
マニュアルや履歴は文章ですが、電力データは時系列の数値です。この二つを結びつけるには、「いつ・どの設備で・どんな異常が」という共通の軸（時刻と設備ID、異常の種類）が必要になります。電力側で検知した異常イベントを言葉に翻訳し、それを手がかりに文書を探す、という橋渡しの設計が論点になります。この異常要因の整理そのものについては原単位悪化のAI要因整理の観点も参考になります。
RAG（Retrieval-Augmented Generation：検索拡張生成）は、大規模言語モデルに直接答えさせるのではなく、まず社内の文書群から質問に関連する箇所を検索して取り出し、その取り出した内容を根拠としてLLMに回答を組み立てさせる仕組みです。ポイントは、モデルの内部知識ではなく「自社の実際のマニュアル・履歴」を根拠にする点にあります。汎用のAIが知らない、自社設備固有の型番や過去トラブルにも、文書さえあれば対応しうるのが利点だと考えられます。
ここで期待値を正しく置くことが大切です。RAGに「原因を断定させる」のではなく、「確認すべき項目と、参照すべきマニュアルの該当箇所、過去の類似事例を提示させる」使い方が、現場の実務に合うと考えられます。異常消費が出たときに、たとえば『同じ設備で過去に似た症状が出た記録が2件あります／マニュアルのこの章にこの症状の対処手順があります／確認すべきはA・B・Cの3点です』と当たりをつけてくれるだけでも、熟練者不在時の初動は変わりうるからです。最終判断は必ず人が現物を見て行う——この前提を崩さないことが重要です。
具体的な流れとしては、まず電力監視側で「設備Xの消費電力が基準から逸脱」を検知し、その異常を『設備X／待機時消費が高止まり／発生時刻』といった問い合わせ文に変換します。次にRAGがマニュアル・保全履歴・改善メモの中から関連箇所を検索し、確認項目と根拠文書を添えて提示する。人はその提示を手がかりに現場を確認し、対処と結果を履歴に書き戻す——この書き戻しが次回以降の検索精度を育てます。監視から検索・提示までを工場内で完結させたい場合は、エッジAIによる工場内データ処理のように外部にデータを出さない構成も選択肢になります。
RAGで最もつまずくのは、モデルの選定でも検索アルゴリズムでもなく、元データの整備です。ここが不十分だと、どんなに高性能なモデルを使っても「それらしいが的外れ」な回答が返ってきます。逆に言えば、データ整備に投資すれば、モデルは標準的なもので十分な水準に届きうると考えられます。
まず紙・画像PDFのマニュアルを文字として扱える状態にします。ここで図表や型番表、注意書きが崩れずに読み取れるかが精度を左右します。次に、長い文書をそのまま扱うのではなく、意味のまとまりごとに適切な大きさに分割（チャンク化）します。章や手順の区切りを無視して機械的に切ると、対処手順が途中で分断されて検索に引っかからなくなる、といったことが起きます。設備マニュアルは章・節・手順番号の構造が明確なことが多いので、その構造を活かした分割が有効だと考えられます。
保全履歴は、自由記述のままでも検索対象にはできますが、『設備ID・発生日時・症状・原因・対処・結果』といった項目に構造化しておくと、電力データの異常イベントと時刻・設備IDで突き合わせられるようになります。ここで大事なのは、電力側と文書側で設備の呼び方（設備名・管理番号・ライン名）を統一しておくことです。同じ設備が電力台帳では『圧縮機3号』、保全台帳では『No.3コンプレッサ』と書かれていると、機械は別物と扱ってしまいます。この名寄せは地味ですが、横断検索の成否を分ける作業だと考えます。
設備マニュアルや保全履歴、電力データには、生産の実態が透けて見える情報が含まれます。外部のクラウドLLMに問い合わせを送ることに慎重にならざるを得ない現場も多いはずです。回答検証を伴うRAGの構築は、まず実現可能性を確かめるAI PoC開発として小さく始め、社内完結が必要ならローカルで動かす構成を検討する、という順序が現実的だと考えられます。どこまでを自社内に置くかは、扱う情報の機微さとコストのバランスで決める論点です。
RAGを入れて終わり、にはなりません。むしろ運用に入ってからが本番です。中心にあるのは「回答検証」の仕組みで、これを最初から設計に組み込んでおくことが信頼性を左右すると考えられます。
RAGの回答には、必ず『どのマニュアルの何ページ／どの保全記録を根拠にしたか』を添えて提示させる設計にします。根拠が示されれば、現場担当者は提示された確認項目を鵜呑みにせず、元文書に当たって妥当性を判断できます。逆に根拠を示さず結論だけを返す使い方は、もっともらしい誤り（ハルシネーション）を見抜けず、誤った対処につながりうるため避けたい設計です。
提示された確認項目が的外れだった、あるいは根拠文書が見つからなかった——こうしたケースを記録し、原因を「元データの不足」「名寄せの漏れ」「チャンク分割の問題」などに切り分けて改善に回す運用が重要です。多くの場合、精度が上がらない原因はモデルではなくデータ側にあります。そして、現場が下した実際の対処と結果を保全履歴に書き戻し続けることで、検索対象の文書そのものが充実し、次回以降の提示精度が育っていく——この循環をつくれるかが、定着するかどうかの分かれ目だと考えます。
技術以上に、運用の担い手を決めることが大切です。異常時に検索を使うのは現場のオペレーターや保全担当、文書とデータを整備・更新するのは生産技術や情報システム担当、というように役割を分けておかないと、導入直後は使われても半年後には放置される、という事態になりがちです。小さく始めて、使う人の声を聞きながら育てる前提で設計するのが現実的だと考えられます。
RAGによる横断検索は有望な選択肢ですが、期待だけで進めると必ずどこかでつまずきます。よくある落とし穴を、正直に挙げておきます。
最後に、現実的な進め方を段階で整理します。いきなり全設備・全マニュアルを対象にするのではなく、効果と限界を見極めながら広げるのが堅実だと考えられます。
異常消費がよく起きる、あるいは止まると影響が大きい設備を1〜数台選びます。その設備のマニュアルと過去の保全履歴・改善メモを整備し、実際に起きた異常事例をいくつか使って「RAGが提示する確認項目は、現場の判断に役立ったか」を人が評価します。この検証で、データ整備の手間・回答の当たり具合・運用の担い手を具体的に掴めます。対象設備を絞った検証設計は小規模PoCから始める相談の考え方が参考になります。
検索の有効性が確認できたら、電力監視で検知した異常を起点に検索が自動で走る連携を組みます。ここで異常イベントの言葉への翻訳と、設備IDの名寄せが効いてきます。監視・検知・検索・提示を一連の流れにできると、熟練者不在時の初動支援としての価値が見えてくると考えられます。
効果と運用負荷の見通しが立ったら、対象設備を広げます。同時に、対処結果の書き戻しと文書更新の運用ルールを定着させ、検索対象が育ち続ける状態をつくります。無理に全社一斉展開せず、成果の出た範囲から広げる方が、現場に根づきやすいと考えます。数値効果や適用範囲は現場ごとに大きく異なるため、あくまで自社の現物・実データでの検証を前提に判断することをおすすめします。制度対応（省エネ法の報告やCO2算定など）と絡めて考える場合は、適用範囲や算定方法を所管省庁の最新の公表資料でご確認ください。
RAG（検索拡張生成）は、AIに直接答えさせるのではなく、まず自社の文書群から質問に関連する箇所を検索し、その内容を根拠に回答を組み立てる仕組みです。汎用AIが知らない自社設備固有のマニュアルや過去トラブルにも、文書があれば対応しうる点が違いと考えられます。ただし回答品質は元データの整備状況に強く依存します。
そのままでは難しく、まず文字として扱える状態にする工程（テキスト化）が必要になります。特に画像として保存されたPDFや手書き台帳は、図表や型番が崩れずに読み取れるかが精度を左右します。この整備の手間を見込んだ上で計画することが現実的で、ここを飛ばすと的外れな回答になりやすい点に注意が必要です。
「いつ・どの設備で・どんな異常が」という共通の軸で突き合わせます。具体的には電力側の異常イベントを問い合わせ文に変換し、設備IDと時刻を手がかりに保全履歴やマニュアルを検索します。前提として、電力台帳と保全台帳で設備の呼び方を統一する名寄せ作業が重要になると考えられます。
そのままの断定的な信頼は避けるべきだと考えます。RAGは確認項目や参照箇所の当たりをつける相棒と捉え、必ず根拠（出典文書）を添えて提示させ、人が現物を見て最終判断する運用が安全です。もっともらしい誤り（ハルシネーション）を見抜くためにも、出典の明示と検証の仕組みを最初から組み込むことをおすすめします。
マニュアルや履歴には生産の実態が含まれるため、社内完結を求める場合はローカルで動かす構成が選択肢になります。まず小さく実現可能性を確かめてから広げる進め方が現実的です。省エネ法の報告やCO2算定と絡める場合、適用範囲や算定方法は制度側で定まっているため、所管省庁の最新の公表資料でご確認ください。
RAGによる横断検索は、元データの整備と回答検証の設計で成否が分かれます。まずは対象設備を1〜数台に絞り、実際の異常事例で「提示された確認項目が現場の役に立つか」を現物で確かめるところから。元キーエンス画像処理事業部の現場知見をもつメンバーが、データ整備からご一緒します。
RAG横断検索のPoCについて相談する