修理報告書を探すたびに、フォルダーの中のPDFを一つずつ開いていませんか。AIで内容を一覧にしても、要約だけでは過去の対応を確かめにくいことがあります。
この記事では、履歴を探すための一覧と、元の報告書へ戻る導線を分けて作った経験を紹介します。組織や取引先が分かる情報は載せず、他の現場にも使える手順に整理しています。
この記事の要点
- 修理履歴は要約文だけでなく、検索項目と元の報告書を結び付けて残します。
- 読めない項目を推測で埋めず、未確認のまま原本へ戻せるようにします。
- 検索画面を作って終わらず、帳票の追加とリンク切れの確認を運用に含めます。
PDFをまとめる目的は、次の確認を早くすること
過去の修理報告書には、症状、確認した場所、交換部品、対応内容などが残っています。しかし、担当者が覚えている言葉と報告書の表現は同じとは限りません。ファイルを開き続ける前に「どの報告書を見ればよいか」を絞れる一覧が必要でした。
実際に行ったのは、PDFから項目を抽出して履歴のExcelを作ることと、その一覧から履歴を探す検索画面の試作です。原本を開き続ける前に、設備や症状から参照先を絞れる形を目指しました。
先に決めるのは、AIへの指示より一覧の列
最初から長い要約を作ると、後で並べ替えたり同じ設備を探したりしにくくなります。まず、記録を区別する管理番号、対象設備、作業時期、症状、実施した対応、確認状態、原本の参照先を列として分けます。社外公開用の資料へ転用する場合は、これらの項目にも識別情報が残る点に注意します。
| 項目 | 残す内容 | 混ぜないもの |
|---|---|---|
| 症状 | 報告書に記載された現象 | 原因だろうという推測 |
| 実施内容 | 点検・交換・調整などの記録 | 実施を確認できない提案 |
| 対応後の状態 | 改善・継続・記載なしなど | 記載がないのに「完了」 |
| 確認状態 | 原本確認済み／要確認 | AIが読めたことと人が確認したこと |
設備名の揺れをそろえる場合も、元の表記と整理後の表記を別に持ちます。似た呼び名だけで別の設備をまとめてしまうと、過去の対応を誤って参照するからです。
コピーして使える修理履歴の列
次は修理履歴の列名のひな型です。社内版では、閲覧権限のある原本へのリンクを付けて使います。
管理番号 設備 時期 症状 実施内容 対応後の状態 確認状態 原本参照
| 架空の記入例 | 内容 |
|---|---|
| 管理番号・設備・時期 | 例001／設備A／対象月 |
| 症状・実施内容 | 異音の記録／点検の実施記録 |
| 対応後・確認状態 | 原本に記載なし／要確認 |
| 原本参照 | 社内で承認した参照先（公開しない） |
「記載なし」を「直った」と補わず、根拠と未確認の点を残します。経験者の説明を記録する方法は日報の活用記事、問い合わせ履歴の使い方はシステム変更履歴の記事で紹介しています。
読み取れない文字は、きれいな文章に直さない
報告書には手書きや不鮮明な箇所がありました。AIの出力は文章として自然でも、部品名や数字が原本と違えば検索の手掛かりを壊します。読めない箇所は「原本確認」とし、入力した推測が確定情報として残らないようにします。
「記載なし」「読み取り困難」「未確認」は別の状態です。空欄をすべて同じ意味にせず、後で誰が何を確かめるかが分かる形にします。対応内容を短く要約するときも、元の文章を確認できる導線を残します。
原本は一覧へ埋め込まず、参照できる構成を試す
原本まで一つのExcelへ抱え込む方法も検討しましたが、ファイルの重さや扱いにくさが問題になりました。そこで、一覧と原本を分け、一覧の行から対象のPDFへ戻る構成を選びました。
ただし、リンクがあるだけでは十分ではありません。ファイルの移動や名前の変更で切れますし、作成者のPCで開けても利用者のPCで開くとは限りません。配布先と同じ配置・権限で、別の利用者が原本へ戻れるかを確かめる必要があります。原本の保存ルールを変えるときは、検索用の一覧も更新対象に含めます。
新しい報告書を、一覧と検索画面へ反映する
履歴の一覧をもとに、対象や症状から探せる画面も試作しました。ここで注意したいのは、Excelを更新したら検索画面も自動で最新になるとは限らないことです。どのデータを読み、いつの情報を表示しているかを明示し、取り込み直す担当と手順を決めます。
最初の動作確認では、検索で結果が出るかだけでなく、該当履歴を漏らしていないか、別の設備が混ざらないか、選んだ原本が正しいかを分けて見ます。検索結果がゼロでも、修理履歴そのものが存在しないとは断定しません。読み取り漏れや対象外の保管資料も考えます。
- 新しい報告書を追加し、重複を確認する担当を決める。
- 整理用一覧と原本の対応を、追加後にも点検する。
- 未確認の項目を残し、現場担当者に確かめてもらう。
- 検索画面へ反映した時点を記録し、古いデータと区別する。
社内の検索と、外へ出す事例は分ける
修理記録には、顧客、担当者、設備の配置、作業場所などが含まれます。社内の検索に必要な情報でも、公開記事に必要とは限りません。画面や原本の画像をそのまま載せず、共有範囲と閲覧権限を決めたうえで取り扱います。AIで処理する前にも、その環境へ原本を渡してよいかを確認します。
資料の整理から始める場合は、総務のAI活用ガイドも参考になります。
よくある質問
- Q修理報告書の一覧に、長い要約だけを残してもよいですか？
- A
検索条件と確認状態が分からなくなるため、設備・時期・症状・実施内容等を列で分けます。要約から元の報告書へ戻れる参照も残します。
- Q修理後の状態が書かれていない場合は、完了扱いにしますか？
- A
しません。「記載なし」と「未確認」を区別し、原本と担当者への確認へ戻します。AIが読みやすい文章へ補完した結果を事実として使わないようにします。
- Q履歴検索の試作で確認すべきことは何ですか？
- A
検索結果の正しさだけでなく、原本リンク、追加帳票の反映、更新日、閲覧権限を確かめます。一覧ができたことだけでは継続運用の完了とはしません。
まとめ
修理履歴は、設備・症状・対応・確認状態を分け、検索結果から原本へ戻れるように整理します。日々の追加でも一覧と原本の対応を点検し、読み取れない項目や参照先が変わった行を、担当者へ戻せる形で残します。
担当者の経験を記録へ変える考え方は、総務の記録をマニュアルやFAQへ変える記事で扱っています。紙の資料から始める場合は、書類をデータ化する前の整理手順も参考になります。
コメント