建設現場で手書きされるコンクリートの受入検査の記録を読み取り、配合ごとの規格値に照らして品質管理台帳に載せ、外れと記入漏れを拾う

処理の起点を決める

Google Apps Script の時間主導型トリガーで、15分ごとに現場のフォルダを見に行きます。 公式ページでは、時間主導型トリガーは1分ごとから月1回まで設定でき、実行の時刻はわずかにずれることがあるとされています。インストール型トリガーとして示されているのは、スプレッドシートを開く・編集する・構造を変える、フォームの送信、カレンダーの予定の更新で、ドライブのフォルダにファイルが追加されたことを起点にするものは一覧にありません。 そのため、見に行く形にします。

1日1回の定時実行にはしません。 外れに気づくのが遅いことが、いまの課題の1つだからです。打設の当日中にスキャンされれば、その日のうちに外れが品質管理課に見えるようにします。

拾うのは「処理済み」の印が付いていないファイルだけです。印は、確認待ちのシートへの書き込みが終わったときにだけ付けます。 途中で止まったファイルは、次の15分で拾い直されます。

入力データを集める

質を決めるのは、規格値の表です。 配合計画書はPDFで、指定値は表の形になっていません。最初に、工事ごと・配合ごとに1行の表へ書き出す作業が要ります。 ここをAIに読ませて作る手もありますが、規格値は一度作れば工事の終わりまで使うものなので、人が作って確かめます。

許容差の考え方は、農林水産省の「土木工事施工管理基準の手引き」第5章に整理されています。手引では、受入れ検査を荷卸し地点で、強度、スランプ、空気量及び塩化物含有量について行うとし、スランプの許容差を次のように示しています。

空気量は普通コンクリート・舗装コンクリート・高強度コンクリートで4.5％、軽量コンクリートで5.0％、許容差は±1.5％、塩化物含有量は塩化物イオン量として0.30kg/m³以下（購入者の承認を受けた場合は0.60kg/m³以下）とされています。この手引は JIS A 5308:2009 を引いています。 実際の規格値の表は、工事の特記仕様書と現行の JIS、配合計画書で確かめて作ってください。コンクリート温度は手引の受入れ検査の項目に無いため、工事ごとに仕様書や施工計画書で決めた管理範囲を表に入れます。

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

Apps Script から Document AI の process を REST で呼びます。公式の API リファレンスでは、POST https://documentai.googleapis.com/v1/{name}:process に rawDocument（ファイルの中身と種類）を渡す形で、認可のスコープは https://www.googleapis.com/auth/cloud-platform です。

認可には ScriptApp.getOAuthToken() を使います。 実行するユーザーの OAuth 2.0 のアクセストークンを返すメソッドで、トークンは時間がたつと切れるとされています。Apps Script のプロジェクトを Document AI を有効にした Google Cloud のプロジェクトに結び付け、マニフェストに cloud-platform のスコープを足しておきます。

公式ページでは、text が文書の文字の source of truth で、ほかの要素は textAnchor でその位置を指すとされています。セルの値は textAnchor から全文を切り出して得ます。値をどこから切り出したかを残しておくと、確認のときに画像の位置を示せます。

AIへ渡す前に整形する

1. 書式をそろえる … 記録表の見出しを1段にし、セルの結合をなくします。Form Parser は行や列にまたがるセルの無い単純な表が対象です
2. 上部に工事コードと配合の記号の欄を作る … 手書きの工事名から工事を当てるより、決めたコードを書いてもらうほうが確実です
3. 解像度を確かめる … 公式ページではスキャンは最低200dpiが望ましく、300dpi以上が一般に最もよいとされています。現場のスキャナーの既定を300dpiにします
4. ファイルの大きさとページ数を確かめる … オンライン処理はファイル40MBまで、Form Parser は15ページまでです。超えるものは分けます
5. 1ファイルに複数の打設が入っていないかを見る … 複数枚をまとめてスキャンしたものは、ページで分けます
6. 重複を見る … 同じ工事・同じ打設日・同じ配合のファイルが既にあれば、二重の記録として印を付けます

1番目がいちばん効きます。 生コン工場から渡される用紙は、「スランプ」の下に「指定」「実測」の2段の見出しを持つものが多く、Form Parser の表の前提から外れます。 会社の記録表を1つに決め、見出しは1段、1列に1項目にするだけで、後の対応づけがほとんど要らなくなります。

AIに処理させる

Document AI に読み取りを、Claude API に表の列の対応づけをさせます。 判定はさせません。

Claude API を使うのは、記録表が完全には1つにそろわないからです。 「SL」「スランプ(cm)」「スランプ値」のように見出しの書き方が現場ごとに違い、列の順番も入れ替わります。この揺れを規則で吸収しようとすると、新しい書き方が出るたびに規則が増えます。 見出しの意味を見て列を当てるのは、生成AIに向いた仕事です。

ただし、写すのは文字列のままです。 「4,5」を「4.5」に直す、「45」を「4.5」と推定する、といったことはさせません。読み違いの疑いは、次の段の規則が拾います。

上の2段を先に通すのが、この設計の要です。 範囲外の値を規格値の照合に回すと、「空気量45％」が大きな外れとして出ます。現場に「外れています」と連絡した後で、読み違いだったと分かるのがいちばんの空振りです。

指示内容を固定する

あなたは建設会社の品質管理課で、コンクリートの受入検査の記録表を
台帳の形にそろえる担当です。OCRが返した表を見て、列の対応づけだけをしてください。

【台帳の列】
time（時刻）／truck_no（車番）／slump（スランプ）／air（空気量）／
concrete_temp（コンクリート温度）／air_temp（外気温）／
chloride（塩化物量）／specimen_no（供試体番号）

【やること】
1. 表の見出しの文字列を見て、台帳の列に対応づけてください。
   対応づけられない見出しは unmapped に入れてください。
2. 各行の各セルについて、OCRが返した文字列をそのまま value に写してください。
3. 上部の欄から、工事コード、打設日、配合の記号、記録者を写してください。

【厳守事項】
- 値を直さないでください。「4,5」「45」「4.5」はそれぞれ書かれたとおりに写します。
- 小数点が無いように見えても、補って書かないでください。
- 単位を換算しないでください。単位の文字があれば unit に写してください。
- 空欄は value を空文字にしてください。前後の行から埋めないでください。
- 見出しの意味が2通りに取れるときは、どちらかに決めず unmapped に入れてください。
- 規格に合っているか、合格か、外れているかは書かないでください。
- 受入検査の記録表でない書類と判断したら、document_type にその種類を書き、
  ほかの項目を空にしてください。

【OCRの結果（上部の欄と表）】{ocr_result}

「4,5」「45」「4.5」を並べて書いているのは、例を出さないと直してくるからです。 「値を直さない」だけでは、空気量の列に「45」とあれば「4.5の誤読と思われる」と考えて直します。直した値が正しいかどうかではなく、直したという事実が記録から消えることが問題です。

「前後の行から埋めない」も同じ理由です。 運搬車が十数台並ぶと、同じ値が続くことがよくあります。空欄を前の行の値で埋めると、記入漏れという事実が消えます。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 公式ページでは、output_config.format に type: "json_schema" とスキーマを渡し、オブジェクトには additionalProperties: false が必要とされています。

{
  "document_type": "acceptance_record",
  "header": {
    "site_code": "",
    "pour_date": "",
    "mix_code": "",
    "recorder": ""
  },
  "unmapped": [],
  "rows": [
    {
      "row_index": 1,
      "cells": [
        { "column": "slump", "value": "", "unit": "" }
      ]
    }
  ]
}

1つ目の理由は、Apps Script がそのまま列に書き込めることです。 column の値は台帳の列名と同じにしてあり、対応表を引かずに書き込めます。

2つ目は、範囲の確認をスキーマに入れられないことです。 公式ページでは、構造化出力のスキーマで minimum・maximum などの数値の制約は使えないとされています。そもそも値は文字列で写させているので、ありえる範囲の確認は Apps Script の側で行います。 役割の分け方と、製品の制約が一致しています。

3つ目は、unmapped で見出しの揺れが見えることです。 対応づけられなかった見出しが溜まれば、記録表の書式を直す材料になります。

Apps Script はこれに信頼度と判定を足して、確認待ちのシートに1行ずつ書きます。

システムへ連携する

品質管理台帳へは直接書き込みません。 台帳は工事の品質記録として後から提出や説明に使うもので、読み違いが確かめられないまま入ると、後から見分けられません。 確認待ちのシートを間に置き、人が確かめた行だけを反映します。

現場への連絡は out のときだけにします。 読み違いのたびに連絡が飛ぶと、現場はすぐに通知を読まなくなります。

Apps Script の実行時間には上限があり、公式ページでは1回の実行が6分までとされています。15分ごとの1回で処理するファイル数を絞り、残りは次の回に回します。

人が確認する

品質管理課が見るのは、印が ok 以外の行だけです。 ok の行は、工事・打設日ごとの件数を見て流します。

1. recheck を先に見る … 画像のリンクを開き、読み取った値が書かれた値と同じかを確かめます。多くは小数点のかすれで、画像を見れば片づきます
2. missing を見る … 本当に空欄かを画像で確かめます。空欄なら現場に確かめ、試験をしていないのか書き忘れたのかを記録します
3. out を見る … 規格値の表から引いた値が正しいか、配合の記号が合っているかを確かめます。配合の取り違えで外れに見えていることがあります
4. 確かめた行を台帳に反映する … 直した値と、直した理由を残します

3番目を省かないでください。 規格値の表は工事ごと・配合ごとで、記録表の配合の記号が1文字違えば、別の配合の許容差で判定されます。 外れの連絡を現場にする前に、配合が合っているかを確かめます。

目標は、240枚をならして1枚4分です。 印の付く行が1枚に1〜2行という想定で、それより多い月は、記録表の書式かスキャンの設定がずれ始めています。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、記録表の書き方と規格値の表の整備の問題です。 書式を直すほうが、読み取りの精度を上げようとするより効きます。

記録を残す

• 元の記録表の画像と、スキャンした日時・現場
• Document AI が返した JSON の全文
• Claude API の出力（列の対応づけと unmapped）
• 照合に使ったそのときの規格値の表の行
• 行ごとの印と、人が値を直した記録（直す前と後、理由、確かめた人）
• out の連絡を現場に出した日時と、現場からの返事・処置

4つ目で「そのときの規格値」を残すのは、表が後から直るためです。 配合計画書の変更で指定値が変わると、過去の判定がどの値で行われたかが分からなくなります。

5つ目は、品質記録としての説明の材料になります。 台帳の値が記録表の字と違う場合、誰がいつ、なぜそう読んだのかを後から示せるようにしておきます。