昇降機の保守会社が点検員の手書きの点検記録表を読み取り、要是正・要観察の項目をビルごとの作業報告書と保守台帳に転記して、前回からの持ち越しを拾う

処理の起点を決める

点検員が記録表を撮って社用のフォルダに保存したことを起点にします。 点検員には会社のスマートフォンが渡されており、スキャンのアプリで撮った PDF を、点検する昇降機の番号のフォルダに保存します。1件ずつ動かし、終わったものは処理済みのフォルダへ移します。 移すのは成功したときだけにし、受け取りのフォルダに残っている数が、そのまま未処理の数になるようにします。

撮るのは点検の当日、現場を出る前です。 現場で撮れば、撮り直しが必要になったときもその場で撮れます。事務所に戻ってからまとめて撮ると、記録表が汚れたり折れたりしていることがあります。

撮り忘れも拾います。 保守台帳の点検の予定と、受け取ったファイルを毎晩突き合わせ、予定日を過ぎても記録表が届いていない昇降機を一覧にして、翌朝に点検員に知らせます。 撮り忘れのまま月末になると、作業報告書がそろいません。

入力データを集める

質を決めるのは、いちばん下の項目の対応表です。 記録表の行と台帳の項目が1対1で結ばれていないと、前回の要観察の項目が今回のどの行かを、機械的に決められません。 記録表の様式を変えるときは、この対応表も同時に直す決まりにします。

修理の記録は、持ち越しの扱いを分けるために要ります。 前回の要是正の項目が今回「良」になっていても、間に修理の記録があれば、それは解消です。修理の記録が無ければ、点検員に理由を聞く必要があります。

データの取得方法を決める

読み取りは、Power Automate から Document Intelligence の REST API でカスタムニューラルモデルを呼びます。記録表は2枚で1件なので、2ページの PDF として1回で読ませます。

信頼度は、表から順に見ます。 公式の説明では、表の読み取りの正確さは、表全体、行、セルの順に上から見ていくことが勧められています。この構成でも、表の信頼度が低ければ記録表ごと担当へ回し、行の信頼度が低ければその行を、セルの信頼度が低ければそのセルだけを確かめる対象にします。

保守台帳からは、昇降機の番号で前回の記録・持ち越し・修理の記録を取ります。 台帳の業務システムに API があればそれを使い、無ければ毎晩の書き出しのファイルを Python で読みます。台帳への書き込みは、担当の確認の後に人の操作で行います。

AIへ渡す前に整形する

1. ページの数と順の確認 … 2ページそろっているか、1ページ目と2ページ目が逆でないかを確かめます。足りなければ点検員に撮り直しを頼みます
2. 文字の大きさの確認 … 抽出する文字の高さの下限は、1024×768の画像で12ピクセルとされています。記録表の計測値の欄は小さいので、スキャンのアプリの解像度を高めに固定します
3. 傾きと影の補正 … スキャンのアプリの補正を使います。補正の前の画像も残します
4. 昇降機の番号の照合 … 読み取った番号と、保存したフォルダの昇降機の番号が一致するかを確かめます。一致しなければ、別の昇降機の記録表を取り違えた可能性があります
5. 重複の確認 … 同じ昇降機・同じ点検日の記録表が既にあれば、上書きせずに担当に確かめます
6. その月の点検項目の確認 … 周期が6か月や1年の項目は、その月に当たる昇降機の記録表にだけ並びます。台帳の点検の予定から、その月に読むはずの行を決めておきます

4番目を省かないでください。 1日に複数のビルを回る点検員は、記録表を取り違えて別のフォルダに保存することがあります。取り違えたまま台帳に入ると、別の昇降機の要是正が消えます。

AIに処理させる

させるのは、記録表の項目ごとに、判定の印・計測値・所見を読み取って信頼度を返すことだけです。 持ち越しの扱いや計測値の差は、Python が台帳と突き合わせて出します。

判定の印が ambiguous のときに、計測値から判定を推し量りません。 例えばブレーキのすき間の値が基準の内側だからといって「良」にはしません。判定は点検員が付けるもので、印が読めないなら点検員に聞きます。

Python が出す持ち越しの扱いは、次の5つです。

4行目の missing_followup が、第3章の（b）への対策です。 前回の要観察の項目が今回の記録表で空欄なら、点検員がその項目を見たかどうかが分かりません。 作業報告書を出す前に、点検員に確かめます。

指示内容を固定する

この構成では生成AIを使わないため、プロンプトの代わりにニューラルモデルの学習の指示と、ラベル付けの決まりを示します。

【見本の集め方】
- 点検記録表の様式ごとに、実際に点検員が書いた記録表を集める
- 1つの様式あたり、ラベル付けした見本を5枚以上（できれば点検員の違う20枚程度）
- 印を2つ付けたもの、消して書き直したもの、空欄の多いものも数枚ずつ入れる
- 機械室で書いた汚れのある記録表、斜めに撮ったものも入れる
- 撮り方は運用と同じスキャンのアプリ、同じ解像度にする

【ラベル付けの決まり】
- 昇降機の番号、点検日、点検員の名前：それぞれ別のフィールド
- 点検項目の表：表のフィールドとし、列を「行の番号」「良」「調整」「要観察」「要是正」
  「計測値」「単位」「所見」にする
- 判定の4つの列は、選択マークとしてラベル付けする
- 計測値は、数字の部分だけ。先頭と末尾の 0、小数点を含めて書かれたとおりに
- 所見は、書かれた文をそのまま。略語（「素切」など）もそのまま
- 点検員の署名：署名のフィールド
- フィールドの名前は記録表の言葉（日本語）でつける

【受け取った後の決まり（Python 側）】
- 判定の列で選択マークが2つ以上「選択」なら ambiguous
- 計測値のセルの信頼度がしきい値を下回ったら unreadable にし、値を台帳に入れない
- 計測値の文字列に数字・小数点以外が混じったら、数値に直さず unreadable
- 読めなかった判定を、計測値や所見から埋めない

「フィールドの名前は記録表の言葉でつける」は、公式の勧めに沿ったものです。 公式の説明では、フィールドの名前を値に関係する名前にすると精度が上がり、名前は文書の言語にするのがよいとされています。

「消して書き直したものを見本に入れる」のは、ambiguous を学ばせるためです。 現場では、付けた印を二重線で消して別の欄に付け直すことがあります。見本に入っていないと、消した印も「選択」として返されやすくなります。

出力形式を固定する

Python が、読み取り結果と突き合わせの結果を次の形にまとめます。

{
  "sheet_id": "",
  "elevator_no": { "value": "", "confidence": 0.0, "folder_match": true },
  "inspected_on": { "value": "", "confidence": 0.0 },
  "inspector_signed": true,
  "items": [
    {
      "row": 23,
      "item_code": "BRK-01",
      "item_name": "電磁ブレーキ スリップの異常の有無",
      "judgment": "good | adjusted | observe | correct | ambiguous | blank",
      "judgment_confidence": 0.0,
      "measure": { "text": "0.35", "unit": "mm", "confidence": 0.0, "prev_text": "0.30", "diff": "0.05" },
      "note": { "text": "", "confidence": 0.0 },
      "carry": "carry_over | resolved | check_reason | missing_followup | new | none",
      "carry_months": 3
    }
  ],
  "needs_review": ["row:23:judgment"]
}

1つ目の理由は、判定と持ち越しを別の欄に持てることです。 judgment は読み取った印、carry は台帳と突き合わせた扱いです。印を読み違えても、carry がおかしければそこで気づけます。 例えば check_reason が多い月は、印の読み取りか修理の記録の入れ漏れを疑います。

2つ目は、計測値を文字列と前回の値の組で持てることです。 text に書かれたとおりの値、prev_text に前回の値、diff に差が入ります。作業報告書には text をそのまま載せ、差は点検の責任者が見る一覧にだけ出します。

3つ目は、carry_months で長く持ち越している項目が分かることです。 要観察が何か月も続いている項目は、修理の提案を検討する材料になります。 何か月で提案を考えるかは、点検の責任者が決めます。

システムへ連携する

作業報告書は、ビルごとに1つの下書きにまとめます。 1つのビルに複数の昇降機があるときは、全台の記録表がそろってから下書きを作ります。 1台でも撮り忘れがあれば、その旨を下書きの先頭に出します。

標準契約書の仕様書では、作業報告書に点検内容を網羅し、計測値の記載や写真の添付などで、できるだけ具体的な作業結果を書くこととされています。 下書きには計測値の欄を必ず設け、読み取った値をそのまま載せるようにします。

人が確認する

業務課の担当は、全件の下書きを開きます。 ただし、全項目を見るのではなく、印の付いた箇所から見ます。

1. 昇降機の番号の不一致を先に見る … folder_match が false のものは、取り違えの可能性があるので、点検員に確かめます
2. missing_followup と check_reason を見る … 点検員に、前回の持ち越しの項目をどう見たかを確かめます。答えを台帳の備考に残します
3. ambiguous と unreadable を画像で確かめる … 記録表の画像を開き、該当の欄を目で読みます。読めなければ点検員に聞きます
4. new の要是正を見る … 新しく付いた要是正は、修理の手配につながるので、所見と一緒に確かめます
5. 残りは一覧で流し見て確定させる … 印の無い項目は、表の形で流し見ます

点検の責任者は、作業報告書を所有者・管理者に送る前に見ます。 国土交通省の指針は、保守点検業者が保守・点検の結果（不具合情報を含む）を文書等で所有者に報告すること、契約の範囲を超える修理や機能更新が必要と判断したときはその理由を文書等で十分に説明することを挙げています。報告書の中身に責任を持つのは、点検の責任者です。

目標は、450件をならして1件4.4分です。 印の無い記録表は数分で終わり、check_reason があるものは点検員とのやり取りで10分以上かかります。4.4分を大きく超える月は、記録表の書き方か、修理の記録の入れ漏れを疑います。

例外に対処する

最後の行は、この構成の流れの外で扱います。 所見に人身事故や重大な不具合につながる記載があれば、作業報告書の段取りとは別に、すぐに点検の責任者へ知らせます。 指針では人身事故に当たる場合などに所有者が特定行政庁へ報告する流れが示され、標準契約書の仕様書には、受託者が報告書の作成に協力することが挙げられています。

記録を残す

• 記録表の PDF（補正の前と後）と、撮った点検員・撮った日時
• 読み取り結果の全文と、そのときのニューラルモデルの ID
• 突き合わせに使った前回の記録・持ち越し・修理の記録
• 項目ごとの carry と carry_months
• 担当が直した項目と、点検員に確かめた内容
• 所有者・管理者に送った作業報告書と、送った日
• 点検員ごとの ambiguous ・ unreadable の発生率

指針では、所有者は過去の作業報告書などを3年以上保存するものとされています。 保守会社の側でも、送った作業報告書と、その元になった記録表の画像と読み取り結果を同じ期間以上残す決まりにしておくと、問い合わせのときに元をたどれます。

最後の行は、記録表の書き方を直す材料です。 特定の点検員に ambiguous が多いなら、印の付け方か、書き直しのしかたに癖があります。