工場の設備の銘板を撮った写真から型式・製造番号・製造年・定格を読み取り、設備台帳の欠けと食い違いを埋める

処理の起点を決める

共有フォルダの受付用フォルダにファイルが作成されたことを起点にします。 点検の日は数十枚がまとめて入りますが、1枚ずつ処理します。まとめて夜間に流す形にはしません。 撮った当日のうちに結果が出れば、unreadable の設備をその日のうちに撮り直せます。翌週になると、撮った人は別の現場にいます。

処理が終わった写真は、処理済みのフォルダへ移します。 移すのは結果を確認用リストに書き出せたときだけです。受付用フォルダに残っている枚数が、そのまま未処理の枚数になります。

撮り方の決まりを、トリガーの前提として現場に配ります。

• 銘板の正面から撮る。斜めから撮ると、文字の高さが足りなくなる
• 銘板と管理番号のQRラベルを、1枚の写真に入れる。離れていて入らないときは、QRラベルを先に撮り、続けて銘板を撮る
• 1枚に写す銘板は1つにする。並んだ設備の銘板をまとめて撮らない
• フラッシュを切る。金属の銘板はフラッシュの反射で文字が飛ぶ

入力データを集める

質を決めるのは、下の2つです。 メーカーの書き方の一覧が無ければ、製造番号の先頭2桁が年なのか連番なのかをAIが推測で決めることになります。入れ替えの記録が無ければ、conflict が出たときに「入れ替えたから違う」のか「台帳が誤っている」のかを分けられません。

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

読み取りは、Power Automate の Document Intelligence のコネクタで、写真のファイルの中身を渡して呼びます。指定するのは次の3つです。

項目名を英語のパスカルケースにしているのは、公式ページが複数語の項目名をキャメルケースかパスカルケースで書くよう勧めているからです。 銘板の文字が日本語でも、項目名は英語のまま渡します。

QRコードの値は barcodes から取ります。 種類（kind）と値（value）と位置が返り、信頼度は1で固定とされています。つまり、QRの値に信頼度の数字は当てになりません。値の形（自社の管理番号の桁と接頭辞）で正しく読めたかを確かめます。

入れ替えの記録は、管理番号でその設備の直近の工事を引きます。 直近90日に入れ替えがあれば、conflict に「入れ替えの可能性」という印を付けます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG/JPG、PNG、BMP、TIFF、HEIFであることを確かめます。それ以外（動画、スクリーンショットのPDFなど）は差し戻します
2. サイズの確認 … 有料（S0）レベルで500MBが上限です。スマートフォンの写真で超えることはまず無いので、超えたら誤って動画が入ったと見ます
3. 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります。最新のスマートフォンの最大解像度で撮ると上限を超えることがあるので、長辺を10,000ピクセル以下に縮めます
4. 文字の大きさの目安 … 抽出するテキストの最小高さは、1024×768の画像で12ピクセルです。銘板が写真の端に小さく写っているものは、縮める前に銘板の周りを切り出します
5. QRと銘板の組み合わせ … QRだけの写真と銘板だけの写真が、同じ人が撮った2分以内の連続であれば1組にします。それ以上離れたものは組にしません
6. 重複の検知 … 同じ管理番号の写真が当日に複数あれば、最後の1枚を使い、ほかは参考として残します

3番目を忘れると、画質の良い写真ほど処理に失敗します。 縮めて文字が小さくなりすぎるなら、銘板の部分だけを切り出します。

AIに処理させる

AIに任せるのは、読み取った文字列を台帳の項目の形にそろえることだけです。 読み取り（OCR）は Document Intelligence が行い、比較は規則が行います。生成AIの役割は、その間の「形をそろえる」ところに限ります。

右端の列が、この構成でいちばん大事な区別です。 unreadable は文字は検出されたが値として確定できないもの、null は銘板に書かれていないものです。前者は撮り直し、後者は台帳の空欄のまま（メーカーに照会するかは人が決める）で、扱いがまったく違います。

分ける材料は、Document Intelligence が返した単語ごとの confidence です。 生成AIには単語と信頼度の組を渡し、信頼度がしきい値（最初は0.8）を下回る単語を含む項目は unreadable にするよう指示します。しきい値は、最初の1か月の確認結果を見て決め直します。

1行目がいちばん起きやすい失敗です。 「製造番号は数字のはずだから」と O を 0 に直すと、英字を含むメーカーの製造番号が台帳と食い違うようになります。 文字種の判断は、メーカーの書き方の一覧を使った規則の側に置きます。

指示内容を固定する

あなたは工場の設備保全の担当として、銘板の写真の読み取り結果を
設備台帳の項目の形にそろえる役割です。
読み取り結果に書かれている文字だけを使ってください。推測で埋めないでください。

【そろえる項目】
maker / model / serial / manufacture_year / rated_voltage /
rated_current / rated_output / frequency / phase

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- not_found .. 銘板にその項目が書かれていない
- unreadable . 文字は検出されているが、信頼度が 0.8 未満の単語を含む
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- serial（製造番号）は、読み取った文字列をそのまま入れてください。
  0 と O、1 と I、8 と B、5 と S を互いに置き換えないでください。
  紛らわしい文字の信頼度が 0.8 未満なら status を unreadable にしてください。
- model（型式）も文字列をそのまま入れてください。
  ハイフン・スラッシュ・空白を足したり消したりしないでください。
- manufacture_year は西暦4桁にしてください。和暦は西暦に直し、
  raw にもとの書き方を残してください。
  下2桁だけ、または年と月の区別がつかない場合は ambiguous にしてください。
- 製造番号や型式から製造年を推測しないでください。
- 定格は数値と単位に分けてください。HP（馬力）は kW に換算せず、
  単位を HP のまま入れてください。
- 銘板に書かれていない項目は、型式や他の項目から補わず not_found にしてください。
- 台帳の値と一致しているかどうかは書かないでください。
- evidence には、根拠にした文字列を読み取り結果からそのまま写してください。
- 写真が銘板でない（点検表、設備の全景など）と判断したら、
  項目を埋めず image_type にその種類を書いてください。

【メーカー名の一覧】{maker_list}
【このメーカーの書き方】{maker_rule}
【読み取り結果（単語と信頼度）】{ocr_words}
【問い合わせ項目の結果】{query_fields}

「台帳の値と一致しているかどうかは書かない」を入れているのは、台帳の値をプロンプトに渡さないためでもあります。 台帳の値を見せると、読みにくい文字を台帳に寄せて読みます。AIには銘板の側だけを見せ、比較は後で規則が行います。

製造番号の置き換えの禁止は、文字の組を具体的に書きます。 「置き換えないでください」だけでは、よく似た字形を「明らかな誤読」として直してきます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、JSONスキーマに従わせます。

{
  "photo_id": "",
  "image_type": "nameplate",
  "asset_no": "",
  "items": [
    { "field": "serial", "status": "ok | not_found | unreadable | ambiguous",
      "value": "", "raw": "", "min_confidence": 0, "evidence": "" }
  ]
}

items には9項目を並べます。field は maker ／ model ／ serial ／ manufacture_year ／ rated_voltage ／ rated_current ／ rated_output ／ frequency ／ phase です。

構造化出力を使う1つ目の理由は、項目の抜けを形で防げることです。 Azure OpenAI の構造化出力では、すべての項目を required に入れる必要があり、任意の項目は null との組み合わせで表すとされています。銘板に無い項目も not_found として必ず1行出るので、「AIが書き忘れた」と「銘板に無い」が混ざりません。

2つ目は、比較の規則をフローの側に置けることです。 フローは items を台帳の列と突き合わせ、次の表で判定を付けます。

比較は文字列の完全一致です。 全角と半角だけは先にそろえ、ハイフンの有無は別の文字列として扱います。

システムへ連携する

設備台帳には書き込みません。 フローが書き込むのは確認用リストだけで、台帳の更新は人が確認用リストから行います。 書き込みを自動にすると、読み違いがそのまま台帳に入り、後から誰も疑わなくなります。

確認用リストの列は、写真へのリンク、管理番号、設備名、項目、判定、読み取った値、raw、台帳の値、evidence、最小の信頼度、入れ替えの印、確認者、確認結果です。1写真の9項目を9行に分けず、1写真1行にまとめ、判定の列は項目ごとに持たせます。 確認する人は写真単位で見るからです。

Azure OpenAI の呼び出しは、Power Automate の HTTP のアクションで v1 のエンドポイントを呼ぶ構成を想定します。 HTTPのアクションを使えるかは、自社の Power Automate のライセンスの区分で確かめてください。

人が確認する

人が開くのは、fill・conflict・unreadable を含む写真だけです。 すべて match の写真は、件数と設備名を一覧で流し見ます。

1. unreadable を先に見る … 撮り直しで解決するかを決めます。撮った当日のうちに撮り直しを頼めば、現場に行くのは1回で済みます
2. conflict の理由を確かめる … 入れ替えの印があれば、工事の記録と照らします。印が無ければ、写真で該当箇所を見て、台帳と写真のどちらが正しいかを決めます
3. fill を台帳に反映する … 製造番号と型式は写真で1文字ずつ見ます。製造年と定格は raw を見て直し方が合っていれば反映します
4. 判定を覆したら記録する … どの項目を、どちらに変えたかを残します

2番目を省かないでください。 conflict には、入れ替え後の未更新、台帳の誤り、写真の読み違いの3つが混ざります。決めずに上書きすると、3つ目で正しい台帳が壊れます。

目標は、240枚をならして1枚3分です。

例外に対処する

上の4行が大半を占めます。 どれもAIの問題ではなく、撮り方とラベルの貼り方の問題です。 撮り方の決まりが定着するほど、unreadable と「設備不明」は減ります。

記録を残す

• 元の写真と、撮影日時・撮った人・経路
• Document Intelligence が返したJSONの全文（文字・信頼度・バーコード・問い合わせ項目）
• Azure OpenAI に渡した入力と、返ってきたJSON
• 判定（fill・match・conflict・unreadable）と、そのとき比べた台帳の値
• 人が台帳に反映した値と、反映した人・日時
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 設備ごと・撮った人ごとの unreadable の発生率

4つ目で「そのとき比べた台帳の値」を残すのは、台帳が後から変わるためです。 別の担当が同じ行を直した後では、当時の conflict が何と食い違っていたのかが分からなくなります。