地盤調査の会社が手書きのスクリューウエイト貫入試験の記録表を読み取り、測点ごとの集計表と報告書の数表の下書きを作る

処理の起点を決める

1時間ごとに、共有フォルダに入った新しいファイルを処理します。 記録表は、調査員が現場を離れるたびに送られてきます。1時間ごとに読めば、夕方には当日の調査の集計表がそろいます。

ファイル名に案件番号と測点番号を付けることを、送る側の決まりにします。 記録表の見出しにも現場名と測点は書かれていますが、手書きの現場名から案件を引くより、ファイル名の番号で引くほうが確実です。 見出しの読み取りの結果は、ファイル名との食い違いを見つけるために使います。

処理が終わったファイルは処理済みのフォルダへ移し、移すのは読み取り・計算・書き出しがすべて成功したときだけにします。 1棟の5測点がそろった時点で、その棟の集計表を「確認待ち」にします。

入力データを集める

質を決めるのは、様式の定義です。 協力会社の様式で貫入量の列が無い、荷重が kN で書かれている、といった違いを様式ごとに1行で持ちます。これが無いと、読み取れた値を正しい列に置けません。 第3章の（d）の読み替えのばらつきを、ここで1つの決まりにそろえます。

報告書の数表の様式は、丸め方まで書き出します。 1mあたりの半回転数を整数にするか小数1桁にするか、深さを何桁で書くかは会社の決まりです。決まりがスクリプトに入っていないと、人が出した数表と同じ値になりません。

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

読み取りは、学習させたカスタム ニューラル モデルを呼ぶだけです。 学習には、Document Intelligence Studio で記録表の見本にラベルを付けます。

表は「動的な表」として学習させます。 記録表の行の数は、地盤の固さで十数行から数十行まで変わります。公式のページは、行の数が変わる表を含む文書では、学習の見本にも行の数の違う文書を入れるよう勧めています。浅い深さで止まった測点と、深くまで貫入した測点の両方を見本に入れます。

記録表が2ページにわたる場合も、1つの表としてラベルを付けます。 表形式のフィールドは既定でページをまたぐ表に対応しており、1ページで終わる見本と2ページにわたる見本の両方を入れておくのがよいとされています。

学習は、東日本（Japan East）の地域で行えます。 カスタム ニューラル モデルの学習は特定の地域でしか行えず、その一覧に Japan East が含まれています。v4.0 では月10時間の無料の学習時間があり、 学習の料金は実際の時間で、1回の学習は最低30分として計算されます。

AIへ渡す前に整形する

1. 形式の確認 … PDFまたは画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）であることを確かめます
2. 大きさとページ数の確認 … 有料（S0）のレベルで500MB、PDFとTIFFは2,000ページまで（無料のレベルは最初の2ページ）です
3. 画像の寸法と文字の大きさ … 50×50〜10,000×10,000ピクセル、文字の高さは1024×768の画像で12ピクセルが下限です。現場で斜めから撮った記録表は、細い数字がこの下限を割ります
4. ファイル名の確認 … 案件番号と測点番号が決まりどおりかを確かめ、台帳に無い番号は止めます
5. 様式の判定 … 見出しの読み取りから様式を決め、様式の定義の行を選びます
6. 重複の検知 … 同じ案件・同じ測点の記録表が既にあれば、差し替えか二重送信かを人に聞きます

3番目は、撮り方の決まりで防ぎます。 記録表を板の上に置き、真上から1枚ずつ撮る、影が数字に掛からないようにする。協力会社にも同じ撮り方を頼み、撮り方の見本の写真を1枚渡しておきます。

AIに処理させる

読み取りの大半は、学習させたモデルが行います。 生成AIにさせるのは、貫入の状況の手書きの記事を、決まった区分に書き分けることだけです。 数値の列は生成AIに渡しません。

推定の土質は、書かれたとおりに写すだけにします。 生成AIは、半回転数の多さや記事の音の記述から「砂質土だろう」と推せてしまいます。推した土質が数表に載ると、調査員が見ていない判断が報告書に入ります。

数値の列を生成AIに渡さないのは、数値はモデルの読み取りとスクリプトの計算で足りるからです。 生成AIを通すと、桁を直す、それらしい値にそろえる、といった手が入りうるので、数値は読み取った文字のままスクリプトに渡します。

スクリプトで拾う矛盾は次のとおりです。

3行目の扱いがこの題材の細かいところです。 Wsw の値は改正で標準の6段階以外も可とされたので、標準でない値を誤りと決めつけると、正しい記録を差し戻すことになります。印は「確認してほしい」という意味に留めます。

指示内容を固定する

あなたは地盤調査の会社で、SWS試験の記録表の「記事」欄を整理する係です。
渡すのは、1枚の記録表の行ごとの記事欄と推定土質欄の文字（OCR の読み取り結果）です。
書かれていることだけを使ってください。推測で埋めないでください。

【やること】
行ごとに、記事欄の文字を次の区分のどれかに当ててください。
- self_sinking ....... 無回転で沈下した（「自沈」「ストン」「スルスル」など）
- rotating ........... 回転して貫入した
- refusal ............ 打止め、貫入不能、これ以上進まない
- sound_texture ...... 音や感触の記述（「ジャリジャリ」「ガリガリ」「シャリシャリ」など）
- other .............. 上のどれにも当たらない
- blank .............. 記事欄が空欄
1つの記事に複数の内容があれば、当てはまる区分をすべて挙げてください。

【厳守事項】
- 記事欄の原文を original にそのまま写してください。言い換えないでください。
- 推定土質欄は、書かれた文字を soil_as_written にそのまま写してください。
  記事の内容や数値から土質を推さないでください。空欄なら空のままにしてください。
- 記事に深さが書かれていれば（例「1.25mでストン」）、その文字を depth_in_note に写してください。
  表の深さの列と食い違っていても、どちらかに直さないでください。
- 荷重・半回転数・深さの数値を作ったり直したりしないでください。
- 地盤の良し悪し、自沈層が問題かどうか、改良が要るかを書かないでください。
- 区分に迷ったら other にして、理由を reason に短く書いてください。

【この会社の記事の言い換えの一覧】{note_dictionary}
【行ごとの記事欄と推定土質欄】{rows}

「土質を推さない」をはっきり書かないと、推します。 「ジャリジャリ」とあれば礫混じりと書き足すのは自然な流れで、それが調査員の見立てとして数表に載ってしまいます。 原文の写しと区分だけを返させます。

「自沈層が問題かどうかを書かない」も同じです。 区分の self_sinking は、記録に「無回転で沈下」と書かれているという事実だけを表します。どの深さの自沈がどれほど重いかは、技術者が判断します。

出力形式を固定する

次の形の JSON で受け取ります。 Claude API の構造化出力で、output_config.format に type: "json_schema" と schema を渡します。

{
  "survey_point": { "case_no": "", "point_no": "", "form_type": "" },
  "rows": [
    {
      "row_index": 0,
      "original": "ストン",
      "categories": ["self_sinking"],
      "soil_as_written": "",
      "depth_in_note": "",
      "reason": ""
    }
  ]
}

1つ目の理由は、行の番号で読み取りの結果とつなげられることです。 row_index はモデルが返した表の行の番号と同じにし、スクリプトは数値の行と記事の行を番号で合わせます。 生成AIに数値を渡さなくても、同じ行の記録として扱えます。

2つ目は、スキーマの制約に頼りすぎない設計にしてあることです。 公式のページによると、Claude の構造化出力では object に additionalProperties: false を付け、数値の minimum・maximum や文字列の minLength・maxLength はスキーマとしては送れません（SDK の変換で説明文に移されます）。配列の minItems は 0 と 1 だけです。値の範囲の確かめは、すべてスクリプトの側で行います。

3つ目は、categories を配列にして、1つの記事に複数の内容を持たせられることです。 「ジャリジャリ、1.50mで打止め」のような記事を、sound_texture と refusal の両方として残せます。

スクリプトが作る集計表の1行は、次の形です。

システムへ連携する

報告書のファイルには書き込みません。 下書きは報告書の数表と同じ列の並びのファイルで出し、貼り付けるのは担当です。 報告書は依頼元へ出す書類で、数字1つの誤りが基礎の仕様の判断に関わるためです。

案件の台帳も読むだけです。 測点の数が台帳と合わない（5測点の案件に4枚しか届かない）ときは、その棟の集計表を「確認待ち」にせず、足りない測点を担当に知らせます。

人が確認する

報告書の担当が開くのは、印の付いた行と、印の付いた行を含む測点だけです。

1. depth_order と load_rotation_mismatch を先に見る … 記録表の画像を開き、読み取りの誤りか現場の書き間違いかを決めます。現場の書き間違いなら、調査員に確かめてから直します
2. low_confidence のセルを見る … かすれた数字、桁の点の位置を画像と見比べます
3. nsw_mismatch と wsw_nonstandard を見る … 計算の値と記録の値のどちらが正しいかを決めます
4. 直したら記録する … どの行の、どの値を、何から何へ、誰の確認で直したかを残します

印の付かない行は、測点ごとの深さと換算半回転数の折れ線を流し見るだけにします。 5測点の折れ線を並べると、1測点だけ形が違うものが目に付きます。 地盤の違いか記録の誤りかを、そこで画像に戻って確かめます。

品質の確認の担当は、数表の下書きと記録表を、印の付いた行を中心に見比べます。 全行の見比べは、導入から2か月ほど続けて、印の付かない行に誤りが無いことを確かめてからやめます。

目標は、600枚をならして1枚3分です。 印の付く測点が3割前後という想定です。それより多い月は、撮り方が崩れているか、新しい協力会社の様式が見本に入っていません。

例外に対処する

3行目が、運用で最も手間のかかる例外です。 協力会社が様式を変えると、そこから先の記録表の信頼度がまとめて下がります。新しい様式の記録表を5枚集めたら学習し直すことを、協力会社との決まりにしておきます。学習の回数には、3.x の版では月20回までという上限があったことも頭に置いておきます。

記録を残す

• 元の記録表の画像・PDF と、受け取った日時・送った人
• 読み取りの結果の JSON の全文（表・行・セルの信頼度を含む）と、そのとき使ったモデルの ID
• 生成AIの書き分けの結果と、そのとき使った言い換えの一覧の版
• 集計表・数表の下書きと、付いた印
• 人が直した記録 … どの行の、どの値を、何から何へ、誰の確認で直したか
• 依頼元へ出した報告書の版と、その元になった集計表の版

モデルの ID を残すのは、学習し直すと同じ記録表でも結果が変わるためです。 どのモデルで読んだかが残っていないと、後で報告書の数字を問われたときに、なぜその値になったかを説明できません。

最後の行は、報告書を出したあとの問い合わせに備えるものです。 依頼元から数値の確認を求められたとき、記録表・読み取り・直した記録・報告書の版を1本の線でたどれるようにしておきます。