PoC開発サービス
同じような不具合を以前に直した記憶はあるのに、報告書のファイル名や担当者が分からず探せない。修理履歴の検索をAIで支援するなら、過去の記録を候補として出し、担当者が対象機器との違いを確かめる範囲から試せます。
症状が似ていても、原因が異なることがあります。機種や使用条件が違えば、過去の対応をそのまま適用できないためです。開発前に検索条件と確認画面を決め、探す時間と候補の適切さを測るPoCの進め方を紹介します。
修理履歴の検索AIはどこまで任せるか
最初は、特定の設備群について、作業前に関連する過去の報告書を探す業務に絞ります。担当者が機種や症状を入力し、AIが記録の候補と該当箇所を提示します。故障原因の確定や作業の実施判断は担当者が行います。
MicrosoftのAzure AI Searchには、類似性を使った検索とキーワード検索を組み合わせる仕組みがあります。症状の言い換えを拾いつつ、型番などの条件を確認する構成を検討できます。ただし、自社の修理履歴で必要な記録が見つかるかは別途検証します。
すでに設備番号や報告書番号で目的の記録をすぐ探せる場合は、既存の検索機能を優先します。AIの開発は、症状の書き方が担当者ごとに違う、複数の記録に情報が分かれている、といった探索の負担が残る場合に検討します。
機種と症状の条件はどう分けるか
必ず一致させる条件と、参考として広く探す条件を分けます。型番が異なる記録も表示するなら、同一機種の候補とは別の区分にします。条件が足りないときに、AIが型番や使用環境を推測して埋めない仕様にします。
以下は検索条件の仮例です。特定の設備に対する修理方法や、導入済みの成果を示すものではありません。
| 項目 | 検索時の扱いの仮例 | 担当者が確認する内容 |
|---|---|---|
| 設備番号・機種 | 指定された条件で絞る | 表記違いや機器の更新履歴 |
| 症状 | 言い換えも含めて候補を探す | 発生時の運転状態が近いか |
| 対応内容 | 原文の該当箇所を表示 | 今回も適用できる条件か |
| 対応結果 | 未解決・経過観察を区別 | 解消確認が記録されているか |
原因と症状を同じ欄にしない
報告書に異音が記載されていても、それは観察した症状です。原因が確定した記録と、原因を推測しただけの記録を分けます。対応後の結果が空欄なら、解決済みとして要約しないようにします。
検索画面では、似ている点に加え、機種や使用条件などの違いも確認できるようにします。類似度の数値を、原因が正しい確率や修理の成功率として表示しません。
PoC前に用意する修理記録
報告書の原本、設備台帳、型番の表記対応表を、共有できる範囲で用意します。報告書ごとに識別番号と作成日を付け、訂正版がある場合は旧版との関係を残します。添付写真や別紙を対象にするかも、最初に合意します。
解決した記録だけを集めると、未解決の候補をどう扱うか検証できません。経過観察中の記録、類似の症状でも原因が異なる記録、必要な条件が欠ける記録も含めます。読みにくいスキャンを使う場合は、検索以前に文字が正しく取り出せているか確認します。
設備や取引先の情報を誰が閲覧できるか、外部サービスへ送れる範囲、保存・削除方法を事前に決めます。検証用に名称を置き換えるときは、設備と報告書の対応関係を保ちます。仮データだけで試した段階では、実際の記録での検索精度は未検証とします。
検索結果と原本をどう確認するか
結果には報告書番号、記録日、対象機種、症状の原文、対応結果を並べます。要約だけを読んで判断せず、元の報告書を開ける構成にします。候補の根拠となる記述がない場合は、その項目を不明として残します。
該当なしを返す場面も決める
対象機種の記録がない、閲覧できる資料に情報がない、入力条件が足りない場合は、その状態を表示します。無関係な過去事例を必ず一件返す仕様にはしません。別機種の参考記録を探す場合は、担当者が検索範囲を広げたことを確認できるようにします。
PoCでは検索と原本確認までを対象にし、部品発注や作業指示の自動登録は含めない構成から始めます。現在のマニュアルや社内の作業手順を優先し、過去の記録だけを根拠に作業を決めない運用にします。
成功条件は候補と確認時間で測る
現場の担当者が、実際に探したい質問と、見つかるべき報告書を先に用意します。検索条件の調整に使う質問とは別に、最終確認用の質問を残します。候補が複数ある場合は、どの記録を関連ありと扱うか担当者同士で決めます。
確認するのは、必要な記録を見落とした件数、関係の薄い記録を上位に出した件数、該当なしを適切に返せた件数です。機種や症状の区分ごとにも結果を見ます。検索操作だけでなく、原本を開き、候補の違いを確かめる時間まで含めて従来の方法と比較します。
修理記録に対応結果が残っていない場合や、正しい候補を評価できる担当者がいない場合は、先に記録と確認体制を整えます。履歴の量が少なく一覧で確認できる場合も、検索AIの開発より記録の整理を優先できます。
開発費と運用後の更新
AiPHAのPoC開発は1業務を対象に20万円〜、10日でAIエージェントを納品するサービスです。金額は対象業務と開発範囲に応じて見積もります。対象設備、記録形式、検索画面、原本へのリンク、アクセス制御の範囲を相談時に確認します。
AIサービスの利用料など、別途必要な費用は事前に案内します。記録の追加頻度、訂正版の反映方法、保守や追加開発の範囲と費用も確認してください。全設備への展開や基幹システムとの連携を、最初のPoCに含める前提にはしません。
社内では、新しい報告書を登録する人と、候補の誤りを確認する人を決めます。開発側とは、削除した記録が検索結果から消えること、更新後も従来の検証例で確かめることを合意します。使ったデータの範囲と検証結果を残せる形で成果物を決めます。
探したい事例が分かれば相談できる
対象設備の種類、普段探している質問、現在の記録の保管場所を共有できる範囲で用意してください。探す時間や月の検索回数が分かると、検証対象を絞れます。修理記録の内容を渡す前に、情報の扱いから相談できます。