外部に委託した試験・分析の報告書を読み取って、社内の試験データに取り込む

処理の起点を決める

受信フォルダにPDFが置かれたときを起点にします。委託先からのメールを受信ルールで専用のフォルダへ振り分け、添付ファイルを保管先へ保存した時点で処理が始まります。Power Automate の「ファイルが作成されたとき」に相当する起動です。

共有の受信用アドレスを先に作ってください。 担当者個人のアドレスに届き続ける限り、この仕組みは動きません。委託先へ送付先の変更を依頼するのが、実装より先の作業です。 郵送で届く分は、受け取った人がスキャンして同じフォルダに置きます。

もう1つの起点として、試験依頼を起票したときを置きます。依頼番号と想定の納期を先に作り、納期を過ぎても報告書が届かない依頼を毎週まとめて知らせます。 届いていない依頼と、取り込まれていない報告書は、どちらも「記録が無い」状態です。二度発注は、この2つから生まれます。

入力データを集める

単位換算表がこの構成の要です。 「MPa」「N/mm2」「kgf/mm2」「ppm」「mg/kg」「質量%」「wt%」「℃」「℉」のように、同じ量の違う書き方を全部並べ、標準単位と係数を書きます。 温度はオフセットが要るため列を分けます。換算表に無い単位は、換算せずに人へ回します。 推測で換算する作りにすると、一度の間違いが全件に広がります。

試験方法の別名表は、委託先ごとに列を持たせます。 同じ引張試験が、公的機関では規格番号で、民間の受託会社では「引張強度測定」と書かれます。最初から全部は埋まりません。 無い呼び名が出たら、人が確認して追記します。

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

原本の保存： 受信したPDFを、まず読み取り専用で保管先に置きます。この原本は以後、誰も書き換えません。 ファイル名ではなく、報告書番号と委託先とハッシュ値で管理します。

読み取り： 保存したPDFをレイアウトモデルに渡します。ページ数の多い報告書では、pages クエリパラメーターで特定のページ番号やページ範囲を指定できます。約款や社印のページを外して、測定値のあるページだけを渡せます。

返ってくるJSONから、tables（行数・列数、各セルの rowIndex columnIndex columnSpan、kind が columnHeader かどうか）、paragraphs（テキストと pageHeader などの役割）、selectionMarks（選択状態と信頼度）、styles（isHandwritten と信頼度）、words（単語ごとの confidence）を取り出します。単語ごとの信頼度を必ず持ち帰ってください。 後で「この測定値は人が見るべきか」を決める材料になります。

委託先ごとの様式を学習させる場合： 件数の多い委託先には、カスタム抽出モデルを作れます。同じ様式の例が5つあれば始められると公式に書かれています。 様式が固定の委託先向けのカスタムテンプレート（トレーニング1〜5分）と、同じ情報でページ構成が変わる委託先向けのカスタムニューラル（構造化・半構造化・非構造化に対応、30分から12時間）の2種類があり、まずニューラルを試すよう書かれています。 ニューラルでは、バリエーションごとに少なくとも5つのラベル付きサンプルを加えることが勧められています。 委託先が複数なら、カスタム分類モデルで先に様式を振り分け、それぞれの抽出モデルへ回せます。

ただし、最初からカスタムモデルを作らないでください。 レイアウトモデルと生成AIの組み合わせで足りるかを先に見ます。月に数件の委託先のためにモデルを作っても、割に合いません。

AIへ渡す前に整形する

1. PDFの種別の判定とロックの解除 … テキストが埋め込まれたPDFか、スキャン画像かを見ます。公式にも、可能な場合はテキストベースのPDFを使うとあります。ロックされたPDFは提出前に解除が必要で、ここで止まる件を人へ回す経路を作ります
2. ページの絞り込み … 表紙、目次、約款のページを外します
3. 表の復元 … rowIndex と columnIndex から表を組み直し、columnSpan のあるセルを展開します。複数ページにまたがる表は、分析後にページをまとめて1つの表に後処理します
4. 数値と単位の分解 … 「12.4 MPa」「12.4N/mm²」を、値と単位に正規表現で分けます。全角数字、上付きの2乗、℃ の1文字表記を先にそろえます
5. 信頼度と手書きの印付け … 各フィールドに、その値を構成する単語の信頼度の最小値を持たせ、isHandwritten が真の範囲に重なるものに印を付けます
6. 委託先の特定 … pageHeader pageFooter の役割が付いた段落と、委託先マスタの別名を突き合わせます

4番目で、値と単位を必ずセットのまま持ちます。 ここで換算しません。換算は、項目の割り当てが済んだ後に、換算表を引いて行います。

AIに処理させる

計算処理にさせること：

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

2番目が、表だけを見る仕組みとの差です。 「試験片は23℃・50%RHで48時間調湿した後、試験速度50mm/minで実施した」という1文は、表のどこにも入っていません。この文が落ちると、測定値だけが残って比較に使えなくなります。

3番目も見落とされやすい部分です。 表に5つの数字が並び、下に1つの数字がある形は珍しくありません。上の5つが個々の測定値で、下が平均値です。 区別せずに取り込むと、平均が6件目の測定値として登録されます。

6番目が、新しい試験方法の受け皿です。 社内の試験データベースに項目の無い試験を委託することがあります。無理に近い項目へ入れさせず、「当てはまらない」として出させます。

指示内容を固定する

あなたは、外部の試験機関から届いた試験報告書を読み取り、
社内の試験データベースの項目に割り当てる担当者です。

【厳守事項】
- 測定値と単位は、報告書に書かれているとおりの文字列で返してください。
  単位の換算をしないでください。「12.4 N/mm2」を「12.4 MPa」に直さないでください。
  値と単位は必ずセットで返し、単位が書かれていない場合は unit_as_written を
  空文字にし、data_gaps に「単位の記載なし」と入れてください。
- 判定（judgement_as_written）は、報告書の判定欄に書かれた文字列を
  そのまま写してください。あなたが合否を判断しないでください。
  判定欄が無い報告書では空文字にしてください。
- 報告書に書かれていない値を推測で埋めないでください。
  書かれていない項目は null にし、data_gaps に項目名を入れてください。
- 各測定値が、個々の測定値か、平均値か、最大値か、最小値かを stat に入れてください。
  判断できない場合は "unknown" にしてください。
- 試験条件は、表の中だけでなく本文の文章からも拾ってください。
  温度、湿度、荷重、試験速度、前処理、試験片の形状と寸法、養生の時間が対象です。
- 各項目について、何ページのどの見出し語から取ったかを
  source_page と source_label に入れてください。
- 社内の項目に当てはまらない試験項目は、無理に近い項目へ入れず、
  unmapped_items にそのままの見出し語と値を入れてください。
- 試験方法は、下の別名表に一致すれば method_code を入れてください。
  一致しなければ method_code を null にし、規格番号は standard_no に入れてください。
  別名表に無い呼び名を、似ているという理由で当てないでください。

【試験方法の別名表】
{method_aliases}

【試料マスタの候補（依頼番号から引いた行）】
{sample_candidates}

【報告書（レイアウト解析の結果。表はHTMLテーブル）】
{report_markdown}

【手書きと判定された範囲】
{handwritten_spans}

「換算をしないでください」の1行は、必ず入れてください。 この指示が無いと、生成AIは親切に単位をそろえて返します。そろえた結果が正しいかどうかを、後から確かめる手段がありません。 書かれたままの文字列で返させれば、原本と1文字ずつ比べられます。

「判定欄が無ければ空文字」も必須です。 これが無いと、測定値を見て「合格」と書いてきます。報告書に書かれていない判定がデータベースに入るのが、この業務でいちばん危ない事故です。 同じく「似ているという理由で当てないでください」は名寄せの事故を防ぎます。「引張試験」と「引裂試験」は1文字違いで、別の試験です。 手書きの範囲を渡すのは、読み違いが起きやすく後から書き足された可能性もある値を、別に扱うためです。

出力形式を固定する

{
  "report_no": "",
  "lab_name_as_written": "",
  "report_date": "",
  "request_no": "",
  "sample": {"name_as_written": "", "sample_code": null, "lot_as_written": ""},
  "tests": [
    {
      "method_as_written": "",
      "standard_no": "",
      "method_code": null,
      "conditions": [
        {"name": "", "value_as_written": "", "unit_as_written": "", "source_page": 0}
      ],
      "results": [
        {
          "item_as_written": "", "value_as_written": "", "unit_as_written": "",
          "stat": "individual | mean | max | min | unknown", "n": null,
          "source_page": 0, "source_label": "",
          "source_kind": "table | text | selection_mark"
        }
      ],
      "judgement_as_written": "",
      "tested_on": "",
      "tester_as_written": "",
      "instrument_as_written": ""
    }
  ],
  "unmapped_items": [],
  "data_gaps": []
}

Claude API では、output_config.format に type: "json_schema" とスキーマを渡すと、応答をスキーマに沿った形に制約できます。stat と source_kind は enum で固定し、オブジェクトには additionalProperties を false に設定します。公式の説明では、文字列の長さの制約（minLength maxLength）、数値の範囲の制約（minimum maximum）、正規表現の pattern はスキーマでは使えません。 値の形の検査は、受け取った後にPythonで行います。

value_as_written を数値型ではなく文字列型にしているのは意図的です。「<0.01」「N.D.」「検出せず」のような、数値でない測定値が実際に返ってくるためで、 数値型にすると欠損になるか、0に丸められます。受け取ったJSONに、機械が次の列を足してから登録します。value_std / unit_std（換算表を引いた標準単位の値と単位）、conversion_factor（使った係数とオフセット）、spec_min / spec_max / in_spec（規格値の範囲と範囲内かどうか）、digit_flag（過去の中央値と比べて10倍・0.1倍に近いか）、ocr_confidence / handwritten、そして review_required（規格値の範囲外・桁の警告・低い信頼度・手書きのいずれかに当たるか） です。

conversion_factor を必ず残してください。 どの行がどの係数で換算されたかが分かれば、換算表を直したときに遡って直せます。換算後の値だけを残すと、間違いに気づいた時点で全件を報告書から読み直すことになります。

システムへ連携する

社内の試験データベースへ、次の3つの単位で登録します。

「書かれたままの値と単位」の列を必ず持ってください。 不具合の調査で報告書と突き合わせるとき、標準単位の値しか無いと原本と一致しません。取り込みは「下書き」の状態で入ります。 確定していない行も検索の結果に出ますが、「未確認」と表示されます。確定していないことが見えるほうが、データベースに存在しないよりはるかに安全です。 依頼番号で依頼台帳と結び付け、依頼番号を書かない委託先の分は、試料名と試験方法と発行日から候補を挙げて人が選びます。紐付かない報告書を放置すると、それが埋もれる報告書になります。

検索は、二度発注を止めるために作ります。 試験を依頼する画面で試料コードと試験方法コードを入れると、過去の同じ組み合わせの結果と、まだ結果の届いていない依頼の両方が、試験条件つきで出るようにします。条件が違えば再測定が必要ですが、それを判断できるのは条件が記録されているからです。 原本PDFへのリンクは、報告書単位ではなく試験結果の1行ごとに、ページ番号まで持たせます。

人が確認する

全件を人が確認します。ただし、見る範囲を絞ります。

フィールド信頼度は、予測が正しいことの推定確率を0から1までの値で示します。公式の説明では、0.95という値は20回中19回は予測が正しい可能性が高いことを示すとされ、「正確性が非常に重要なシナリオでは、信頼度を使って、予測を自動的に受け入れるか、人間によるレビューのためにフラグを付けるかを決めることができる」と書かれています。 試験の測定値は、まさにそのシナリオです。

確認の優先順位を4つに分けます。

• 必ず人が見る … 信頼度が基準を下回る値、手書きと判定された値、桁の警告が出た値、規格値の範囲を外れた値、判定が不合格の件
• 並べて見る … 同じ試験方法の測定項目をまとめ、標準単位の値を一覧で見る。桁の違う値は並べると目で分かります
• 別名表に追記する … method_code が null の試験方法、委託先マスタに無い委託先
• 人が決める … unmapped_items の試験項目を、新しい項目として足すか参考記録にするか

信頼度の読み方に注意が要ります。 公式には、読み取り結果の信頼度と、キーと値の抽出結果の信頼度は別のもので、読み取り結果の信頼度は抽出結果の信頼度に影響しないため、両方を確認する必要があると書かれています。カスタムモデルではテーブル・行・セルの信頼度が返り、まずテーブル全体を見て、次に行、最後にセルへ降りる順序が勧められています。 結合セルは信頼度が低く出ることが期待されると明記されているため、表が崩れた箇所はこの値で拾えます。

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

• 原本PDFの該当ページと、取り込んだ値を左右に並べて表示する
• 警告の付いた値だけを上に集める
• 同じ試料の過去の測定値を、その場に一緒に出す
• 人が直した箇所を色で残し、誰がいつ直したかを記録する
• 「書かれたままの値」と「換算後の値」を隣り合わせで出す

最後の1つが、単位の事故を止める最後の砦です。 「12.4 N/mm2」と「12.4 MPa」、あるいは「1.27 kgf/mm2」と「12.4 MPa」が隣に並んでいれば、換算表が正しいことがその場で分かります。換算後の値しか見えない画面では、確かめようがありません。

例外に対処する

記録を残す

この記録は、単位の事故と二度発注を後から追うための材料になります。

• 原本PDFとそのハッシュ値、受信日、委託先、報告書番号
• 読み取りの生の結果（表、段落、選択マーク、手書き判定、単語ごとの信頼度）
• 生成AIが返したJSONそのもの（換算前、書かれたままの値と単位）
• 換算に使った係数とオフセット、換算前後の値
• 警告の内容（信頼度、桁、規格値の範囲、手書き）と、人がどう判断したか
• 人が直した項目と、直す前の値（誰がいつ直したか）
• 別名表・換算表に追記した内容と、その日付
• 検索で過去の結果が見つかり、発注を取りやめた件数

「人が直した項目と、直す前の値」を必ず残してください。 どの委託先のどの項目でよく直されているかが分かります。特定の委託先の特定の項目で修正が続くなら、その委託先にだけカスタムモデルを作るか、報告書の様式を相談する根拠になります。

そして、発注を取りやめた件数が出てくるまでは、二度発注が止まったかどうかを誰も言えません。