点検報告書は、PDFができても完成ではなかった。赤字メモから帳票を作って分かった確認の仕事

設備点検の結果を報告書にまとめる担当者には、現場で書き込んだ赤字をExcelへ転記し、提出する書式に整える仕事があります。AiWiLLは、この読み取りと帳票づくりをAIで進める支援をしました。

元の点検メモと書式を渡し、項目と書き込み先を対応させれば、AIで読み取った値を使って帳票の下書きを作れます。最初に見ていたのは「文字を読めるか」でしたが、実際の帳票まで作ると、その後にも確認する仕事が残りました。

値は取れているのに、総括表へ正しく出ていない。前の点検で使った丸印や数値が残る。読み取った内容が合っていても、入れる行がずれれば、別の項目の説明になります。

AiWiLLで行ったのは、業務フローの聞き取り、点検メモから帳票を作るデモ、Excel・PDF・解読レポートを残すキットの整備です。今回はその過程を振り返ります。提出済みや現場定着までを確認した報告ではありません。

まず、今の報告書がどこで作られているかを聞いた

最初の打ち合わせでは、業務システムの中で回っている仕事と、その外でExcelを使っている仕事を分けて確認しました。

点検の管理に使う台帳があっても、提出する報告書のレイアウトまで同じシステムで再現できるとは限りません。そこで、複雑な帳票は外で作り、必要な形で台帳へ戻す方向を整理しました。この時点で決まったのは設計の方向です。台帳への自動格納が完成した、という意味ではありません。

次のデモでは、点検メモのPDFから情報を読み取り、報告書へ反映する流れを見ました。そこで分かったのは、データを取り出せることと、帳票を正しく埋められることは別だという点です。総括表への反映や、良・不良の表記に修正が必要でした。

検証中には、処理を同時に実行するとタイムアウトする問題も出ました。そこで、当面は一件ずつ処理する運用にしました。

毎回、不要な設備のシートを消すのも手間です。初回に物件ごとの初期シートを作り、次回はその土台を使う方針を決めました。早く回すために処理を増やす前に、一件が通る条件を固める。その順番にしたのです。

ただし、前のものを使うほど、前回の値を持ち越す危険が増えます。後の帳票キットには、物件名や日付、前の物件の文字が残っていないかを調べる検証を入れました。

この検証にも限界があります。物件名を探して見つからなかったからといって、型番や数値まで正しいとは言えません。同じ値が残っていても、それが今回も正しい値なのか、更新漏れなのかは、元のメモと突き合わせる必要があります。

残った手順書には、内容欄が一行ずれた失敗も記録されています。見た目が似ている帳票でも、項目の行数や結合セルの位置が違うためです。

修正したのは、AIへの「正確に」というお願いだけではありません。テンプレートの行ごとに、項目名と書き込むセルの対応を出し、それを見てから値を入れる手順にしました。

読み取る工程、帳票へ入れる工程、PDFで見える状態を確かめる工程を分ける。どこで間違ったか分かるようにしておけば、全部を作り直す以外の直し方ができます。

完成フォルダには、Excelと結合PDFだけでなく、赤字をどう読んだかを示す解読レポートも残っています。

このレポートには、前回から変更した箇所、読み取りに自信がない箇所、手で転記する必要がある別紙を分けて載せました。元のメモで点検者や立会者の記載が食い違う例、必要な票のデータがそろわない例もありました。

そこをAIが都合よく埋めれば、見た目は完成に近づきます。でも、確認する人は何が未確定なのか分からなくなります。「要確認」を残すのは、仕事を人へ返すためです。

実際の解読レポートには、要確認を残しながら暫定の値で生成した箇所もあります。この出力を、そのまま提出できる完成品とは扱っていません。今回の記事化でも、原本照合と修正が済んだ証拠までは確認できていません。

同じように帳票を作るなら、ファイルが存在することに加えて、次を確認します。以下は今回の記録をもとに編集した確認表です。

AIに帳票を作らせる仕事では、「作る」と「提出できる」を分けておく必要がありました。確認箇所まで具体的に残せれば、人は空白から作る作業と、正否を判断する作業を分けられます。どれだけ時間が減ったかは、確認と修正にかかった時間も含めて、次に測る項目です。

報告書の作成、見積りの下書き、問い合わせ返信、社内資料の整理。いま困っている仕事を一つ選び、必要な資料と、人が確認する範囲から整理します。

先に現在地を見たい人は、AIに任せる準備度の診断もあります。