計測器の校正の期限を Power Automate で台帳から拾って回収を知らせ、戻った証明書の受入時の値を読み取って合否を台帳に戻す

処理の起点を決める

フローは2本に分けます。月初の拾い出しと、証明書の保存をきっかけにした読み取りです。

月初の拾い出しは、Recurrence のトリガーで毎月1日の朝に動かします。頻度を月、時刻を始業前にし、タイムゾーンを日本に設定します。 既定の UTC のままだと、日本時間の前日の夕方に動き、月をまたぐ計算がずれます。

読み取りは、SharePoint の「When a file is created (properties only)」のトリガーで、証明書を保存するライブラリを見張ります。「When a file is created in a folder」は非推奨になっており、サブフォルダーに置いたファイルでは動きません。 ライブラリの直下に置く運用にし、フォルダーで分けたいときは列（社内／外部、工場）で分けます。

1ファイルに1台分の証明書を置く運用にします。 外部の校正事業者がまとめて1つの PDF にして送ってくる場合は、保存する前に台ごとに分けます。

入力データを集める

質を決めるのは、許容差の表です。 種類と測定範囲ごとに、どの測定点でどれだけの差まで認めるかを社内の規程から表にします。表が無い種類は、フローで合否を出さずに担当者へ回します。

台帳の状態の値をそろえておきます。 「使用中」「校正待ち」「校正中」「使用停止」「廃棄」の5つにし、月初の拾い出しは「廃棄」以外のすべてを対象にします。 「貸出中」のような独自の値があると、絞り込みから落ちます。

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

Get items は既定で全件を取ります。 Filter Query に OData の条件を書き、要る行だけを取ります。翌月末の日付は、utcNow と addDays、formatDateTime の式で作ります。

証明書の中身は、トリガーのあとに Get file content で取ります。 トリガーが返すのはライブラリの列の値だけで、ファイルの中身は含まれません。取った中身を、そのまま Run a prompt の文書の入力に渡します。

AIへ渡す前に整形する

1. 形式を確かめる … 文書の入力に渡せるのは PNG・JPG・JPEG・PDF です。Word や表計算の形で届いた証明書は PDF にしてから保存します
2. 大きさとページ数を確かめる … 渡すファイルは合わせて25MB未満、文書は50ページ未満です。超えるものは台ごとに分けます
3. スキャンの設定をそろえる … 社内の記録票は、決まった解像度でスキャンし、傾きの大きいものは取り直します
4. 管理番号をファイル名に入れる … 保存するときに「管理番号_校正日.pdf」の名前にします。読み取った管理番号と照らすためです
5. 社内か外部かを列で付ける … 書式が違うので、プロンプトへの補足の指示を分けます

4番目を省かないでください。 証明書に印字された機器の番号は、校正事業者が付けた番号や製造番号のことがあり、自社の管理番号と一致しないことがあります。 ファイル名の管理番号を正とし、読み取った番号は照らすために使います。

手書きの記録票は読み違いが起きます。 文書の入力は大きな文書の表の行で不正確になりうるとされており、手書きの数字ではなおさらです。 次の段で「読めない数字は推し量らない」と指示し、フローの側でも読み違いの疑いを拾います。

AIに処理させる

させるのは、証明書から決まった項目を写すことだけです。

2行目がいちばん起きやすい失敗です。 受入時の値の欄が無い証明書を渡すと、調整後の値を受入時の値の欄に入れて返します。その瞬間、確かめたかった不合格が見えなくなります。 受入時の値が無い証明書は、受入時の値が無いという事実のまま担当者に回します。

指示内容を固定する

あなたは品質管理部の計測管理の係で、計測器の校正の証明書または
社内の校正記録票から、決まった項目を写す担当です。
文書に書かれていることだけを写してください。推測で埋めないでください。

【写す項目】
- device_no：証明書に印字された機器の番号
- calibration_date：校正を行った日（YYYY-MM-DD）
- certificate_no：証明書または記録票の番号
- adjusted：調整したと書かれていれば yes、していないと書かれていれば no、
  書かれていなければ unknown
- points：測定点ごとに次を写す
  - nominal：公称値（数字だけ。単位は unit に）
  - as_found：受入時の値（「校正前」「受入時」「As Found」「調整前」の欄）
  - as_left：調整後の値（「校正後」「調整後」「As Left」の欄）
  - unit：単位（mm、μm、N·m など）
  - read_status：ok ／ unreadable ／ not_present

【厳守事項】
- 受入時の値の欄が無い場合は、as_found を空にし、read_status を
  not_present にしてください。調整後の値を受入時の値として写さないでください。
- 読めない数字は空にし、read_status を unreadable にしてください。
  前後の測定点や公称値から推し量って埋めないでください。
- 数字は文書の桁のまま写してください。四捨五入や単位の換算をしないでください。
- 合格か不合格かは書かないでください。
- 「判定」「合否」の欄が文書にあっても、その内容を写さないでください。
- 校正の証明書でない文書と判断した場合は、document_type に種類を書き、
  他の項目は空にしてください。
- JSON の前後に説明やマークダウンを付けないでください。

【文書の種類】{source_type}（internal：社内の記録票、external：外部の証明書）
【文書】{certificate}

「判定の欄を写さない」を書くのは、証明書の判定が自社の許容差と違うことがあるからです。 外部の証明書の「合格」は、校正事業者が使った基準での判定です。自社の許容差がそれより狭ければ、証明書が合格でも自社では不合格です。 写させると、担当者がその欄を見て合格にしてしまいます。

最後の行は、JSON が作れないときに案内されている指示です。 JSON の前後に説明が付くと、フローの後段で項目を取り出せなくなります。

出力形式を固定する

プロンプトの出力を JSON にし、次の形を例として保存します。

{
  "document_type": "calibration_certificate",
  "device_no": "",
  "calibration_date": "2026-10-08",
  "certificate_no": "",
  "adjusted": "yes | no | unknown",
  "points": [
    { "nominal": "25.000", "as_found": "25.004", "as_left": "25.001",
      "unit": "mm", "read_status": "ok | unreadable | not_present" }
  ]
}

形は「Custom」にして保存します。 既定の「Auto detected」は試すたびに形が変わり、保存したときの形が実行のときに使われます。 フローの後段が項目の名前に頼るので、形を固定します。なお、キーの無い配列（["25.004", "25.001"] のような形）は定義できないので、測定点は必ずキーを持つ物の配列にします。

数値を文字列で受けるのは、桁を守るためです。 「25.000」を数値にすると「25」になり、証明書の有効桁が分からなくなります。 比べるときに、フローの float の式で数値に変えます。

フローの比べ算は、測定点ごとに次の順で行います。

式には絶対値を返す関数が無いので、上と下の境界を別々に比べます。 差を取って正負で場合分けするより、境界で比べるほうが式が短くなります。

読み違いの疑いも、ここで拾います。 受入時の値が公称値から許容差の10倍以上離れていれば、計測器の故障より読み違いの可能性が高いので needs_human にします。 何倍を境にするかは、係で決めて表に持たせます。

システムへ連携する

回収の一覧は、Create HTML table でメールの本文に入れます。 職場ごとに Filter array で行を分け、表にして送ります。メールの本文を HTML として送る設定にします。

台帳の更新は、校正結果のリストで承認されたものだけです。 校正結果のリストの「承認」の列が変わったことをきっかけに、別のフローが台帳の校正日・次回の期限・状態を更新します。次回の期限は、校正日に台帳の周期を足して式で出します。

この別のフローは、SharePoint の「When an item is created or modified」のトリガーで動かします。このトリガーは列が変わるたびに動くので、最初の条件で「承認」の列が「承認済み」で、かつ「台帳に反映済み」の列が空のものだけを先へ進めます。 反映が終わったら「台帳に反映済み」に日時を入れます。これを入れないと、担当者が備考を直しただけで台帳がもう一度書き換わります。

合否が fail のものは、台帳の状態を「使用停止」にします。 調整して合格になった計測器でも、製品の確認が終わるまでは「使用停止」のままにし、品質保証の担当が確認を終えたことを記録してから「使用中」に戻します。 戻すのは人の操作です。

人が確認する

担当者は校正結果のリストを開き、次の順で確かめます。

1. needs_human を先に見る … 読めなかった数字、受入時の値の欄が無い証明書、読み違いの疑い。証明書を開いて値を入れ直します
2. fail を見る … 受入時の値と許容差の表を、証明書と見比べます。不合格が確かなら承認し、製品の確認の依頼が起票されます
3. pass を流し見る … 管理番号・校正日・測定点の数が証明書と合っているかを一覧で見て承認します
4. 覆したら記録する … 合否を変えたときは、理由をリストの列に残します

2番目の不合格は、担当者が必ず証明書で確かめます。 不合格を起票すると、品質保証の担当が過去の検査の記録をさかのぼる仕事が始まります。誤った不合格でも、その仕事は始まってしまいます。

目標は、210点をならして1点4分です。 pass は一覧で数十秒、fail と needs_human は証明書を開いて数分という想定です。

例外に対処する

下から3行目と2行目が、第3章の（a）への答えです。 拾い出しの一覧を送って終わりにせず、戻っていないものを期限の前に追いかけ、過ぎたら使用を止めます。 期限切れの計測器を現場に残さないのは、読み取りの自動化よりこちらです。

記録を残す

• 証明書・記録票のファイルと、保存した日時・保存した人
• プロンプトが返した JSON の全文
• 測定点ごとの比べ算の結果と、そのとき使った許容差の表の行
• 承認した人・日時、合否を覆した記録と理由
• 製品の確認の依頼を起票した日時と、品質保証の担当
• 月初の拾い出しの一覧と、期限までに戻らなかったもの

3つ目で「そのときの許容差」を残すのは、表が後から変わるためです。 許容差を狭めたあとに過去の判定を見直すときに、当時どの値で比べたかが残っていないと、合格だった理由を説明できません。