試験・測定機器の校正証明書を読み取って、期限切れの機器での測定を止める

処理の起点を決める

受付フォルダに証明書のファイルが登録されたことを起点にします。

事業者からPDFがメールで届く場合は、受付用のメールアドレスを1つ用意し、そこへ転送する運用にします。担当者個人のメールボックスを監視対象にしないでください。 紙で届く証明書は、複合機でスキャンして同じフォルダへ置きます。

Make のシナリオはスケジュールで動かします。既定では15分ごとに実行される設定で、一定間隔・1日1回・平日・週次・月次・日付指定・オンデマンドから選べます。 証明書の受付は随時なので、一定間隔（15分〜1時間）が向いています。シナリオは有効化しないと動かないため、設定後の有効化を忘れないでください。

もう1つ、毎日の期限チェックを別のシナリオとして置きます。こちらは1日1回で構いません。証明書の処理より、こちらのほうが先に効果が出ます。 台帳の日付を見るだけなので、AIも要りません。

入力データを集める

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

校正証明書： PDFをそのまま Gemini API へ渡します。ファイル形式の制限を確認してください。 一部の事業者は画像形式（JPEG）で送ってきます。

機器台帳： ここが、この構成の土台です。次の項目が揃っている必要があります。

「許容範囲」を台帳に持っていない企業が多くあります。 証明書には事業者の判定（合格・不合格）が書かれていますが、それは事業者の基準であって、自社の用途に対する基準とは限りません。 自社で測定に使う範囲での許容値を、機器ごとに決めてください。

使用記録： 期限切れが分かったとき、その期限切れの期間に、その機器を使った測定があったかを調べるために使います。この照合ができると、影響範囲の特定が一瞬で済みます。

AIへ渡す前に整形する

1. ファイル形式の統一 … 画像形式で届いたものをPDFにまとめます。複数ページの紙をスキャンした場合、1機器1ファイルに分けます
2. 複数機器の分割 … 1つの証明書に複数の機器が記載されていることがあります。機器ごとに分けてから処理します
3. 向きの補正 … スキャンした紙は上下逆や横向きのことがあります
4. 社内校正の様式の統一 … 社内で作る証明書は、自社の様式に固定できます。外部の様式より読み取りが安定します
5. 重複の検出 … 同じ証明書が再送されることがあります。「管理番号＋校正日」で既存データと照合します

AIに処理させる

生成AI（Gemini API）にさせること：

計算処理にさせること：

数値の判定はAIにさせません。 「偏差が許容範囲に入っているか」は単純な大小比較です。AIに判断させる理由がなく、検算もできなくなります。

使用制限の判断もさせません。 「この機器は使い続けてよいか」は、測定の用途と、その測定結果をどう使うかで決まります。

指示内容を固定する

あなたは計測機器の管理を支援する担当者です。
下の校正証明書から、機器台帳に記録する項目を抜き出してください。

【厳守事項】
- 証明書に書かれている値をそのまま抜き出してください。
  単位の換算、四捨五入、桁の調整をしないでください。
- 数値は文字列ではなく数値で返してください。
  ただし、符号（＋／－）と小数点以下の桁数は証明書の表記どおりに保ってください。
- 有効期限が明記されていない場合、expiry_date を null にし、
  expiry_stated を false にしてください。
  **校正周期から計算しないでください。計算は後段の処理で行います。**
- 測定点は、証明書の表に記載されている行をすべて抜き出してください。
  行を省略したり、まとめたりしないでください。
- 不確かさの記載がない測定点は uncertainty を null にしてください。
  **推定値を入れないでください。**
- 管理番号は、証明書に印字されている文字列をそのまま返してください。
  ハイフンや空白を勝手に除去しないでください。
  読み取れない文字がある場合、その位置を "?" にし、needs_review に入れてください。
- 合否の判定は、証明書に書かれている表現をそのまま写してください。
  「合格」「適合」「Pass」を統一しないでください。
- 証明書に書かれていない項目を補わないでください。
  メーカーの一般的な仕様や、標準的な校正周期で埋めないでください。
- 機器を使い続けてよいかの判断を書かないでください。

【校正証明書】
{certificate_pdf}

【この証明書の想定される事業者（送信元から推定）】
{vendor_hint}

「有効期限を計算しない」の1行が重要です。 証明書に「校正周期：12か月」とだけ書かれているとき、AIに計算させると、閏年や月末の扱いで誤差が出ます。日付の計算は、機械的な処理で行うほうが確実で、検算もできます。

「行を省略したりまとめたりしない」も必須です。 測定点が20点ある証明書で、AIが「主要な5点」だけを返すと、範囲外の測定点を見落とします。すべての行を出させ、件数を証明書の表と突き合わせてください。

「管理番号のハイフンや空白を除去しない」の指示も効きます。 台帳側の表記と揃えるのは後段の正規化の仕事です。AIに正規化させると、元の表記が失われ、読み取り誤りに気づけなくなります。

社内校正の証明書は、外部のものと分けて扱ってください。 社内で作る証明書は様式を自社で固定できるため、読み取りが安定します。ただし、確認すべき項目が外部のものより1つ増えます。

2行目が要点です。 社内校正に使った標準器の校正が切れていれば、その標準器で校正した機器の記録も根拠を失います。標準器を起点に、影響する機器を一覧で出せる形にしてください。

【厳守事項（社内校正の証明書に追加）】
- 校正に使用した標準器の管理番号を reference_standards に必ず入れてください。
  記載がない場合は missing_fields に「使用標準器」を入れてください。
- 標準器の校正期限が証明書に書かれている場合、それも抜き出してください。
  書かれていない場合、null にしてください。**台帳から補わないでください。**

標準器の期限との突合は、計算処理で行います。「校正日の時点で、使用した標準器の校正が有効だったか」を機械で判定できます。 ここが自動で見えると、審査での説明が楽になります。

出力形式を固定する

{
  "certificate_id": "",
  "instrument": {
    "control_number_raw": "",
    "model": "",
    "serial_number": "",
    "manufacturer": ""
  },
  "calibration_date": "",
  "expiry_date": "",
  "expiry_stated": false,
  "cycle_stated_months": 0,
  "issued_date": "",
  "vendor_name": "",
  "calibration_site": "",
  "conditions": { "temperature": "", "humidity": "" },
  "reference_standards": [],
  "measurement_points": [
    {
      "point_label": "",
      "nominal_value": 0,
      "measured_value": 0,
      "deviation": 0,
      "uncertainty": 0,
      "unit": ""
    }
  ],
  "point_count_in_document": 0,
  "vendor_judgment_raw": "",
  "missing_fields": [],
  "needs_review": []
}

Gemini API でJSONを返させる場合、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡します。スキーマは Pydantic や Zod、生のJSONスキーマで定義でき、SDKとREST APIのいずれからも使えます。

point_count_in_document を必ず返させてください。 抽出された measurement_points の数と、この値が一致するかを機械で検算します。一致しなければ、行の取りこぼしがあるということです。

control_number_raw を「raw」として持つことにも意味があります。 台帳との照合は正規化した値で行いますが、照合に失敗したとき、元の表記を見れば原因（ハイフンの有無、全角半角、読み取り誤り）が分かります。

システムへ連携する

抽出結果と台帳から、確認リストをスプレッドシートに作ります。

台帳の更新は、人が確定してから行います。 特に管理番号の照合が「候補あり」の場合、別の機器の台帳を更新してしまう危険があります。

証明書の保存は、管理番号でたどれる形にしてください。 ファイル名を「管理番号_校正日.pdf」にするか、フォルダを管理番号で切ります。審査で「この機器の証明書を」と言われたとき、すぐ出せることが目的です。

期限の通知は、別のスケジュールで動かします。 毎日、台帳の次回期限を見て、60日前・30日前・7日前に該当する機器を管理部署へ通知します。期限が切れた機器は、毎日通知し続けてください。

人が確認する

全件、担当者が台帳の更新を確定します。自動更新はしません。

理由は、間違った機器の台帳を更新すると、2つの機器の記録が同時に壊れるためです。更新された側は誤った期限になり、本来更新されるべき側は期限切れのまま残ります。どちらも気づくのは次の校正のときです。

確認の深さを分けます。

• 管理番号の照合が「不一致」または「候補あり」のもの … 全件、人が特定する
• 測定点の数が一致しないもの … 取りこぼしがある。原本と突き合わせる
• 範囲外の測定点があるもの … 使用制限の判断が要る
• expiry_stated が false のもの … 周期からの計算が正しいかを確認する
• needs_review に項目があるもの … 読み取れなかった箇所を原本で確認する
• 上記に当たらないもの … 抽出結果の要点だけ見て確定する

確認を速くするための設計が効きます。

• 管理番号の読み取り値と台帳の値を並べて表示する
• 証明書のPDFを、確認画面の横に開けるようにする
• 測定点の数の不一致に色を付ける
• 前回の校正値と今回の値を並べて表示する（偏差の変化が見える）
• 期限の出所（記載／計算）を明示する

4つ目が効きます。 偏差が回を追って大きくなっている機器は、許容範囲内であっても劣化が進んでいます。次の校正を待たずに点検する判断ができます。

例外に対処する

記録を残す

この記録は、審査や顧客監査で提示する資料そのものになります。

• 校正証明書の原本（管理番号でたどれる場所）
• 抽出結果（生のJSON）
• 台帳の更新前後の値
• 人が修正した項目と、その理由
• 期限の出所（証明書に記載／周期から計算）
• 期限切れが発生した場合、その期間と、使用記録の照合結果
• 使用制限をかけた機器と、その判断の根拠

「期限の出所」を残すことが効きます。 証明書に期限が書かれていない機器は、自社の周期の設定に依存します。周期の設定を変えたとき、どの機器の期限が動くかが分かります。

期限切れの記録は、消さずに残してください。 「過去に期限切れが発生したが、その期間に測定は行われていなかった」という記録が、審査での説明になります。隠すより、検出して手当てした記録があるほうが説明できます。