設備保全の点検報告書作成・過去履歴検索をAIで下書きする｜人の承認を残す設計

1. 背景と課題
2. 報告書の素材を分解する
3. 過去履歴検索が効く場面と限界
4. AIと人の分担
5. 外に出せない場合の判断軸
6. 失敗パターン
7. AIが適さない場合
8. 進め方
9. よくある質問
10. 関連記事・関連ソリューション

現地は終わっているのに、報告書が終わらない

産業機械や装置のサービス部門、設備保全を請け負う会社では、技術者が一日に複数の現場を回ります。現地での作業は時間が読めても、その後の事務は読めません。夕方に戻ってから、あるいは翌朝に、点検報告書や保守報告書を書く時間が積み上がります。

この負担を「文章を書くのが遅いから」と捉えると、対策はテンプレートの整備に向かいます。しかし実際に時間を取られているのは、多くの場合書き始める前の工程です。

• 現地で撮った写真がスマートフォンに数十枚あり、どれがどの部位のものか思い出しながら選ぶ
• 現地メモが手書きのノートと端末のメモアプリに分かれていて、両方を見返す
• 前回の点検報告書を探す。担当者が違えば、どこに保存されているかも違う
• この設備で過去に同じ症状が出ていたか、不具合履歴を確認する
• 該当部品の交換履歴を調べ、前回いつ交換したかを確かめる

ここで消えている時間は、技術的な判断のための時間ではなく探索の時間です。しかも探索の成否は担当者の記憶に依存するため、担当が変わると同じ設備でも一から調べ直しになります。アフターサービスは継続的な関係の上に成り立つ業務ですが、その関係の記憶が個人の中にしか無い状態は、事業としては脆い形です。

なお、現地で点検結果をどう記録するか、紙とExcelの転記をどう減らすかという記録の入口の話は巡回点検の記録が負担すぎるで扱っています。この記事が扱うのは、記録した後に発生する報告書作成と過去履歴の照会という事務です。

点検報告書は、四種類の素材からできている

報告書作成を工程として扱うために、まず何を集めているのかを分解します。分解すると、集める作業と判断する作業がはっきり分かれます。

この表の上四行と下二行の間に、明確な線があります。上の四つは反復的な収集と検索であり、担当者が変わっても結果は同じであるべき作業です。下の二つは技術者の判断であり、結果が人によって違い得るものです。

自動化の対象にすべきなのは上の四つです。ここを詰めるだけで、書き始めるまでの時間は変わる可能性があります。下の二つに機械の出力を持ち込むと、責任の所在が曖昧になります。

「前にも似たことがあった」を、記憶に頼らず引けるようにする

設備保全の現場で最も価値のある情報のひとつが、同じ設備・似た症状の過去記録です。ベテランの技術者は「この型式でこの音なら、前に見た」と結びつけられますが、その結びつけは個人の中にあります。

過去の点検報告書や不具合履歴が文章として残っていれば、次のような検索は機械的に成立し得ます。

• 同一設備の時系列。機番を軸に、過去の点検・不具合・交換の記録を日付順に並べる。
• 同一型式の横断。同じ型式の他の設備で、同じ部位の不具合が出ていないかを探す。
• 症状での検索。「異音」「振動」「温度上昇」といった記述から、似た表現を含む過去記録を拾う。
• 交換履歴の確認。該当部品を前回いつ交換したか、その後の経過がどう記録されているかを引く。

一方で、限界もはっきりしています。

この差を運用で埋めるのが、候補として出すという設計です。検索結果を答えとして提示すると検証されなくなり、過去の記録に引きずられた誤診につながります。候補と、その根拠になった記録そのものを並べて出す形にしておく必要があります。

集める・探す・下書きするまでがAI、確定と提出は人

点検報告書は、社内の記録であると同時に顧客へ提出する文書です。修理や更新の判断材料になり、後から参照されることもあります。だからこそ、確定と提出は人の行為として残す必要があります。

線引きの基準は精度ではなく取り返しがつくかどうかです。検索が的外れでも担当者が捨てれば済みますが、誤った所見が記載された報告書を提出すると、顧客の判断に影響したうえで訂正することになります。

どこに承認を挟むかという設計の一般論はAIエージェントに任せる範囲と人の承認ポイントの設計で、AIと人の引き継ぎやエスカレーションの運用はAIと人の引き継ぎ運用で扱っています。

報告書・履歴・写真を社外に出せないとき、何を比べるか

点検報告書には顧客名、設備の型式と機番、設置場所、構成、価格に関わる情報が含まれます。写真には顧客の建屋や製造ラインが写り込みます。「これを外部のサービスに送ってよいのか」という問いは、この業務では自然に出てきます。

この問いは、どの仕組みを選ぶかという話に飛ぶ前に、何をどこまで出せないと定義しているのかを確認するところから始めるのが実務的です。次の観点を順に見ていくと、選択肢が絞れます。

1. データの区分。顧客名や機番のように顧客が特定できるもの、写真、価格に関わるもの、社内の判断過程。どれが社外に出せないのかを区分ごとに定義します。全部が同じ扱いとは限りません。
2. 参照できる範囲。誰がどの顧客の記録を見られるかを、人の権限として定義します。仕組みに広い権限を持たせず、担当者の権限の範囲でしか参照できない向きで設計する方が安全です。
3. 参照の記録。誰が何をいつ参照したかが残るか。後から経緯を説明できるかどうかは、この記録の有無で決まります。
4. 保存期間と削除。下書きや中間データがどこにどれだけ残るか、契約上の保存義務と、逆に消すべき期限をどう扱うか。
5. 運用の担い手。更新や障害対応を誰がやるのか。社内に閉じた構成ほど、運用の負担は自社側に寄ります。

そのうえで、構成の選択肢を比べます。

注意しておきたいのは、構成の選択で決まるのはデータの流れであって、安全そのものではないということです。社内に閉じていても、権限が広ければ見えてはいけない記録が見えます。構成の選択は、権限・参照記録・保存期間・運用の設計と一緒に決めて初めて意味を持ちます。

閉域・オンプレミスという条件でAIをどう位置づけるかという論点はバーティカルAI×セキュリティで、情シス専任がいない環境での運用の担い方はオンプレAIの運用で扱っています。

報告書作成の効率化でつまずきやすい四つのパターン

この領域は、下書きの品質より運用の設計で止まることが多いのが特徴です。

• 下書きが整いすぎて検証されなくなる。文章として自然な報告書が出てくると、事実の確認が甘くなります。根拠にした現地メモ・写真・過去記録を必ず並べて提示し、確認する対象を明示する必要があります。
• 過去記録が検索できる形で残っていない。報告書がPDFの画像として保管されていて中身を引けない、命名規則が担当者ごとに違う、といった状態では検索が成立しません。ここはAI以前に片づける準備工程です。
• 技術者に新しい入力を増やしてしまう。「後で検索しやすいように」とタグ付けや分類の入力を求めると、現地の負担が増えて続きません。既に書かれているもの・撮られているものを集める方向から始める方が定着します。
• 所見や修理要否まで下書きさせてしまう。ここは技術者の判断領域です。過去の表現を参考として示すのは有用ですが、判断そのものを下書きの形で提示すると、確認が追認に変わります。

帳票アプリ・Excel・定型OCR・RPAで足りる条件

次のいずれかに当てはまる場合、AIより先に検討すべき手段があると考えられます。

実務では組み合わせるのが妥当な場合が多くあります。定型の点検項目は帳票アプリで記録し、過去の紙の報告書はOCRで取り込んで検索できる状態にし、ファイルの配置はRPAに任せ、自由記述の所見と写真、履歴の横断検索だけをAIが担うという分担です。全部をAIに寄せる必要はありません。

手段の使い分けはAIエージェント・チャットボット・RPAの違いに整理しています。社内文書を検索して答えさせる仕組みの基本的な考え方は社内文書をAIに答えさせる仕組み（RAG）にあります。

1設備群・1様式から始めて広げる順序

この領域は、全設備・全様式を一度に対象にすると準備で止まります。次の順序が現実的だと考えます。

1. 報告書1件あたりの内訳を測る。素材を探す時間、写真を選ぶ時間、書く時間、確認する時間に分けて記録します。ここで負担の中心が分かります。
2. 過去記録が引ける状態かを確認する。保存場所、命名、検索できるかどうか。引けないなら、ここが最初の作業になります。
3. 1設備群に絞って、履歴の検索だけを試す。下書きは作らせず、「この機番の過去がその場で引ける」状態を作ります。
4. 素材の紐づけを足す。現地メモと写真を案件・設備に自動で結びつける工程を追加します。
5. 下書き作成へ広げる。根拠の記録とセットで提示し、確定と提出は人が行う前提を保ちます。
6. 対象を広げる。様式や設備群を段階的に増やします。

この順序の背景にあるのは、下書きの品質を上げることよりも探索の時間を先に削るという考え方です。探索が短くなれば、技術者の時間は判断に戻ります。

よくある質問

点検報告書は帳票アプリのテンプレートでも作れます。AIは要りますか

点検項目が固定で、記入するのがチェックと数値だけなら、帳票アプリやExcelのテンプレートで足ります。むしろその方が安価で、挙動も読めます。AIの出番が出てくるのは、報告書の中身が自由記述の所見と写真の説明で占められていて、しかも過去の点検履歴や不具合履歴を参照しないと書けないときです。ご自身の報告書のうち、定型の欄と自由記述の欄がどれくらいの比率かを数えてみると、どちらの手段が向いているかが分かります。

AIが書いた所見をそのまま顧客へ提出してよいですか

提出すべきではないと考えます。点検報告書は事実の記録であり、同時に顧客の設備投資や修理の判断材料になる文書です。AIが作れるのは、現地メモと写真と過去の記録から組み立てた下書きまでです。書かれている事実が正しいか、所見として妥当か、診断としてその表現でよいかは、現地を見た担当者が確認して確定する範囲です。提出そのものも人の行為として残す設計を推奨します。

過去の類似案件を探させたい。どこまで期待できますか

過去の報告書や不具合履歴、交換履歴が文章として残っていれば、型式・機番・症状・部位などの条件で似た記録を探し、要点を並べて提示することは可能な範囲です。ただし、似ているように見える過去の事案が今回と同じ原因とは限りません。機械が示すのは候補であって診断ではありません。過去の事例を根拠に修理の要否や交換部品を決めるのではなく、担当者が現物と照らして判断する材料として使う位置づけにしておく必要があります。

法定点検の報告書にも使えますか

法令で定められた点検や、資格者による判定が必要な検査については、判定と署名の責任が人にあり、その部分を機械の出力で代替することはできません。関連する過去の記録を集める、様式に沿った下書きを整えるといった補助はあり得ますが、記載内容が要求を満たしているかどうかの確認は人が行う前提です。自社が対象とする法令や様式の要求は、それぞれの規定と所管の指針で確認してください。この記事は法令適合の可否について判断を示すものではありません。

報告書や写真を外部のサービスに出せません。それでも検討できますか

外に出せないという前提から始めるのは自然です。まず、扱う情報を顧客名や設備の構成が分かるもの、写真、価格に関わるものといった区分に分け、どこまでを社外に出せないと定義しているのかを社内の規程で確認します。そのうえで、社内に閉じた構成、閉域に置く構成、社外の仕組みと組み合わせる構成のそれぞれについて、参照できる範囲、参照の記録が残るか、保存期間、更新や障害時の運用を誰が担うかを比べます。構成の選択で決まるのはデータの流れであり、安全そのものが保証されるわけではありません。運用と権限の設計が伴って初めて意味を持ちます。

関連記事・関連ソリューション