森林組合が土場で手書きする原木の検知の野帳を読み取り、樹種・長さ・径級・本数から材積を計算して出荷の台帳に転記し、合計の食い違いと読めない欄を拾う
検知員が土場で手書きする原木の検知の野帳を撮影して読み取り、樹種・長さ・径級ごとの本数を出荷の台帳にそろえます。規格の計算式で材積を出し、野帳の合計との食い違いと読めない欄を拾います。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- Azure AI/Google Document AI
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- その他/製造
- 対象部門
- 生産
- 対象業務
- データ入力・転記/集計・分析
- 主な課題
- 人手が足りない/入力作業が多い/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/対応スピード向上/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 検知員が、土場で丸太の径と長さを測り、野帳のます目に本数を書く
- 検知が終わったら、合計の本数を数えて書く。材積を書く検知員もいる
- 野帳を事務所に持ち帰り、事業課に渡す
- 事業課の担当が、野帳のます目を1つずつ表計算の出荷の台帳に打ち込む
- 材積表を引いて、径級と長さごとの1本の材積に本数を掛け、合計を出す
- 計算した合計の本数・材積を、野帳に書かれた合計と比べる。合わなければ検知員に聞く
- 出荷先ごとの明細を作り、出荷の台帳を締める
- 人検知員が、いまと同じく野帳に書く。本数は数字で書き、合計の本数を右下に書く決まりにする
- 人検知が終わったら、検知員が土場でスマートフォンで野帳のページを撮る
- 自動撮った画像の画質を確かめ、ぼけ・暗さ・欠けがあれば、その場で撮り直しを促す
- 自動OCRが野帳の表と上の欄と読み取りの信頼度を返す
- 自動生成AIが、表の行と列を径級と長さに対応づけ、ます目の本数を文字のまま写す
- 自動本数を決まりで数字にし、径級と長さが規格の単位寸法に合うかを確かめ、材積を規格の計算式で計算する
- 自動計算した合計の本数・材積を、野帳に書かれた合計と比べる
- 自動出荷の台帳の下書きと、確認の要るページの一覧を作る
- 人事業課の担当が、確認の要るます目だけを野帳の画像と並べて直し、合わないページは検知員に確かめる
- 人確認の済んだページを出荷の台帳に確定し、出荷先への明細を作る
各工程の詳しい説明を読む
- 検知員が、土場で丸太の径と長さを測り、野帳のます目に本数を書く
- 検知が終わったら、合計の本数を数えて書く。材積を書く検知員もいる
- 野帳を事務所に持ち帰り、事業課に渡す
- 事業課の担当が、野帳のます目を1つずつ表計算の出荷の台帳に打ち込む
- 材積表を引いて、径級と長さごとの1本の材積に本数を掛け、合計を出す
- 計算した合計の本数・材積を、野帳に書かれた合計と比べる。合わなければ検知員に聞く
- 出荷先ごとの明細を作り、出荷の台帳を締める
(a)打ち直しと材積の計算が明細を待たせる。 野帳が事務所に戻るのは夕方か翌日で、1ページ40前後のます目の打ち込みと、材積表を引く計算に時間がかかります。 出荷先への明細と請求は、そのあとになります。
(b)書き方が検知員ごとに違う。 本数を数字で書く人、「正」の字で書く人、長さの列の並びを自分で書き足す人がいます。ベテランの書き方に慣れた担当者でないと、ます目の読み方を迷います。
(c)合計の食い違いが後で分かる。 計算した本数と野帳の合計が合わないとき、ます目の読み違いなのか、検知員の数え違いなのかを、検知員に聞かないと決められません。 聞くのは翌日以降で、土場の丸太はもう出荷されていることがあります。
(d)材積表の引き違い。 6m以上の丸太は6m未満と計算式が違うため、材積表の別の欄を引く必要があります。 慣れていない担当者が同じ欄を引くと、長い材の材積がずれます。
- 【人】 検知員が、いまと同じく野帳に書く。本数は数字で書き、合計の本数を右下に書く決まりにする
- 【人】 検知が終わったら、検知員が土場でスマートフォンで野帳のページを撮る
- 【自動】 撮った画像の画質を確かめ、ぼけ・暗さ・欠けがあれば、その場で撮り直しを促す
- 【自動】 OCRが野帳の表と上の欄と読み取りの信頼度を返す
- 【自動】 生成AIが、表の行と列を径級と長さに対応づけ、ます目の本数を文字のまま写す
- 【自動】 本数を決まりで数字にし、径級と長さが規格の単位寸法に合うかを確かめ、材積を規格の計算式で計算する
- 【自動】 計算した合計の本数・材積を、野帳に書かれた合計と比べる
- 【自動】 出荷の台帳の下書きと、確認の要るページの一覧を作る
- 【人】 事業課の担当が、確認の要るます目だけを野帳の画像と並べて直し、合わないページは検知員に確かめる
- 【人】 確認の済んだページを出荷の台帳に確定し、出荷先への明細を作る
3番目が、屋外の野帳に固有の工程です。 事務所に戻ってから撮り直しが要ると分かっても、野帳はもう汚れているか、検知員は次の土場にいます。土場にいるうちに画質を確かめ、撮り直しを済ませます。
9番目で、合わないページを検知員に確かめるのは、その日のうちです。 撮影が土場で済んでいるので、丸太がまだ土場にあるうちに数え直せることがあります。
02今回想定するシステム構成
検知の野帳(手書き・樹種と検知ごとに1ページ) │ 土場でスマートフォンで撮影 ▼【トリガー】画像の保存 Google Document AI(Enterprise Document OCR の画質スコア)── ぼけ・暗さ・欠けの確認 │ 基準を下回れば、その場で撮り直しを促す ▼ Google Document AI(Form Parser) │ 表(径級×長さのます目)、上の欄、読み取りの信頼度 ▼ OpenAI API(構造化出力)── 行と列の対応づけ、ます目の本数の書き写し ▼ Python ── 本数の決まり、単位寸法の確認、規格の計算式による材積、合計との照合 ▼ 出荷の台帳の下書き、確認の要るページの一覧 ▼ 【事業課が確認の要るます目を直す】→ 台帳に確定 → 出荷先への明細
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Form Parser) | Azure AI Document Intelligence |
| 画質の確認 | Google Document AI(Enterprise Document OCR の画質スコア) | 撮影アプリの側の確認 |
| 生成AI | OpenAI API(行と列の対応づけ、本数の書き写し) | Claude API、Gemini API |
| 連携 | Python(画像の受け取り、API の呼び出し、台帳の下書きの作成) | Google Apps Script |
| 差異計算 | Python(材積の計算、合計との照合) | Google Apps Script |
材積の計算は、素材の日本農林規格の付属書の標準的な計算式で行います。 規格では、丸太の材積は、長さが6m未満のものは 径(cm)の2乗 × 長さ(m)÷ 10,000、6m以上のものは (径 +(長さの1m未満を切り捨てた値 − 4)÷ 2)の2乗 × 長さ ÷ 10,000 を標準とし、材積の端数は小数第4位を四捨五入する(小数第3位に満たないものは小数第5位を四捨五入する)とされています。この2つの式と端数の扱いを、そのままプログラムに書きます。
径と長さの単位寸法も、規格で決まっています。 丸太の径の単位寸法は、径14cm未満の小の素材は1cm、それ以外は2cmで、単位寸法に満たない端数は切り捨てます。長さの単位寸法は0.2mで、1.9m・2.1m・2.7m・3.3mの区分には別の規定があります。野帳に書かれた径級と長さがこの単位に合うかを確かめると、読み違いの多くが拾えます。 径14cm以上の欄に奇数の径が出てきたら、まず読み違いを疑います。
土台は Document AI の Form Parser です。 公式の説明では、Form Parser はキーと値のペア、表、チェックボックスなどを抽出するとされ、プロセッサ一覧の言語表では日本語(ja)が手書きに対応する言語として示されています。野帳の上の欄はキーと値のペアとして、径級×長さのます目は表として読めます。
処理する場所に、日本のリージョンはありません。 Form Parser と Enterprise Document OCR の対応リージョンは us・eu と、asia-southeast1(シンガポール)などの単一リージョンです。野帳に森林の所有者や施業地の名前が書かれる場合は、国外で処理されることを組合の個人情報の扱いの決まりに照らして確かめます。
03どうやって実装するのか
処理の起点を決める
野帳の画像が、組合のクラウドのフォルダに保存されたことを起点にします。 検知員は、検知が終わったページを土場でそのまま撮り、撮影用のアプリから保存します。電波の届かない土場では、アプリが画像を持っておき、電波の届くところで保存します。
画質の確認は、保存の直後に行い、結果を検知員のスマートフォンに返します。電波の届く土場なら、数十秒で撮り直しの要否が分かります。 電波の届かない土場で撮ったものは、事務所の確認で画質が足りなければ、翌日の朝に検知員に野帳を持ってきてもらって撮り直します。
ファイル名には、撮影の日時と検知員の番号を入れます。土場と樹種は野帳の上の欄から読み取り、その日の出荷の予定と照らします。 処理が終わったものは処理済みのフォルダへ移し、移すのは成功したときだけにします。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 野帳の画像 | 1ページずつの画像、撮影の日時、検知員 | 検知員のスマートフォン |
| 画質の結果 | 画質スコアと、検出された欠点(ぼけ・暗さ・欠けなど) | Google Document AI(Enterprise Document OCR) |
| 読み取りの結果 | テキスト、表(ヘッダの行と本体の行)、上の欄、信頼度 | Google Document AI(Form Parser) |
| 出荷の予定 | 日付、土場、出荷先、トラック、樹種 | 事業課の出荷の予定表 |
| 規格の定め | 材積の計算式、径と長さの単位寸法、端数の扱い | 素材の日本農林規格(プログラムに書く) |
| 野帳の雛形 | 組合で使う雛形ごとの径級の並びと長さの並び | 雛形の一覧 |
質を決めるのは、野帳の雛形です。 雛形の径級と長さの並びが決まっていれば、表の行と列の対応づけは雛形と照らすだけで済みます。検知員が長さの列を自分で書き足した野帳は、雛形に無い列として生成AIに対応づけさせます。
データの取得方法を決める
画質の確認は、Enterprise Document OCR の画質スコアで行います。 公式の説明では、処理の要求の ocrConfig.enableImageQualityScores を有効にすると、ページごとに0から1の画質スコアが返り、スコアが0.5を下回ると、ぼけ(defect_blurry)、暗さ(defect_dark)、薄さ(defect_faint)、文書の欠け(defect_document_cutoff)、映り込み(defect_glare)などの欠点の一覧が返るとされています。この機能は OCR の処理と同じくらいの待ち時間を加えるとされているので、画質の確認だけを先に回し、合格した画像を Form Parser に回します。
読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 画質スコアと欠点 | pages[].imageQualityScores(Enterprise Document OCR) | 撮り直しの要否 |
| 全テキスト | text | ほかの欄が startIndex・endIndex で指す原文 |
| 上の欄 | pages[].formFields(fieldName と fieldValue) | 日付、土場、現場、樹種、検知員、出荷先、合計 |
| 径級×長さのます目 | pages[].tables(headerRows と bodyRows) | 径級ごと・長さごとの本数 |
| 信頼度 | 各要素の layout の信頼度 | 確認の要るます目の印 |
公式の説明では、text が認識されたテキストの唯一の元で、ほかの欄は startIndex と endIndex でその位置を指すとされています。表は headerRows と bodyRows に分かれ、行や列をまたぐセルの無い表だけが対象とされています。ます目は1つずつのセルとして返ってくるので、行の見出し(径級)と列の見出し(長さ)の位置で本数のセルを決めます。
表の見出しの行が読めないこともあります。 長さの列の見出しが汚れていると headerRows が空になるか、本体の行の1行目として返ってきます。その場合は、雛形の並びと照らして生成AIに対応づけさせます。
AIへ渡す前に整形する
- 画質の確認 … 画質スコアと欠点で、撮り直しの要否を決めます
- 画像の向きと傾き … スマートフォンで撮った画像の傾きを、野帳の四隅で補正します
- ファイルの形式 … JPEG か PNG で保存します
- 雛形の判定 … ます目の数と見出しの並びから、どの雛形かを決めます
- 重複の検知 … 同じ日付・同じ土場・同じ樹種・同じ検知員のページが二度入ったら、印を付けて止めます
- 続きのページの検知 … 上の欄に「続き」「2/3」などがあれば、前のページとつなぎます
1番目を、ほかの処理より先に行います。 汚れた野帳をそのまま読むと、ます目の数字が読めないまま合計の照合まで進み、照合で合わないページが増えて、人の確認がかえって増えます。
5番目で、重複を止めるのは意図してのことです。 同じページを2回保存したまま台帳に入れると、出荷の材積が二重に計上されます。 新しい方を使うか、別の検知かは、人が決めます。
AIに処理させる
生成AIにさせるのは2つだけです。 表の行と列を径級と長さに対応づけること、ます目の本数を文字のまま写すことです。
| 見るもの | させること | 判断できないときの扱い |
|---|---|---|
| 表の行の見出し | 各行が何cmの径級かを決める | 決められない行は unknown |
| 表の列の見出し | 各列が何mの長さかを決める | 決められない列は unknown |
| ます目 | 本数を書かれた文字のまま写す。「正」の字も文字のまま | 読めない文字は空にし、unreadable |
| 上の欄 | 日付、土場、現場、樹種、検知員、出荷先、合計の本数、合計の材積を写す | 読めなければ空 |
数える、計算する、照らすはプログラムの側で行います。
| させないこと | 理由 |
|---|---|
| 材積の計算 | 規格の式と端数の扱いはプログラムに書く。計算させると桁や端数がぶれる |
| 「正」の字の本数への変換 | 書きかけの画の読み分けを決まりで行い、読めなければ人に回す |
| 読めない本数の補い | 前後のます目や合計から逆算すると、数え違いが消える |
| 径級や長さの読み替え | 単位寸法に合わない値は、そのまま確認に回す |
| 樹種の推測 | 上の欄に書かれた樹種だけを使う |
3行目がいちばん起きやすい失敗です。 合計の本数が書かれていると、読めないます目を「合計から他を引いた数」で埋めたくなります。埋めた瞬間、合計の照合は必ず合うようになり、検知員の数え違いもます目の読み違いも、両方とも見えなくなります。
指示内容を固定する
あなたは森林組合の事業課で、原木の検知の野帳の読み取り結果を台帳の形にそろえる担当です。
OCRが返した表と上の欄だけを見てください。推測で埋めないでください。
【野帳の雛形】
径級の並び(cm):{diameter_classes}
長さの並び(m):{lengths}
【厳守事項】
- 表の各行が何cmの径級か、各列が何mの長さかを row_map と column_map に書いてください。
雛形に無い行や列は、書かれた見出しの文字を写し、決められなければ unknown にしてください。
- ます目の本数は、書かれた文字のまま写してください。
「正」の字や、書きかけの画(一、T、下、止 のように見えるもの)も、そのまま写してください。
数字に直さないでください。
- 空いているます目は空のまま写してください。0 にしないでください。
- 読めないます目は空にし、unreadable_cells に入れてください。
合計や前後のます目から逆算して埋めないでください。
- 材積を計算しないでください。
- 上の欄の合計の本数と合計の材積は、書かれた文字のまま写してください。
- 樹種は上の欄に書かれたものだけを写してください。推測しないでください。
【OCRの表】{tables}
【上の欄】{form_fields}
「合計から逆算しない」を明記しないと、生成AIは親切に埋めます。 合計の本数は同じページの上の欄にあり、何も言わなければ、読めないます目を「合計に合うように」決めます。禁じるのは、合計を根拠にする判断そのものです。
「書きかけの画もそのまま写す」を明記しているのは、「正」の字の野帳が残るからです。 書きかけの画を生成AIが「3本くらい」と解釈すると、その数が台帳に入ります。写すのは画の形までで、本数にするのはプログラムの決まりです。
出力形式を固定する
次の形のJSONで受け取ります。
{
"page_id": "",
"header": {
"date": "", "landing": "", "site": "", "species": "",
"inspector": "", "buyer": "", "total_count_text": "", "total_volume_text": ""
},
"row_map": [ { "row_index": 0, "diameter_cm": "", "status": "ok | unknown" } ],
"column_map": [ { "column_index": 0, "length_m": "", "status": "ok | unknown" } ],
"cells": [ { "row_index": 0, "column_index": 0, "text": "" } ],
"unreadable_cells": [ { "row_index": 0, "column_index": 0 } ]
}
本数も径も長さも文字列で受けるのは、意図してのことです。 数値の型で受けると、「正」「T」や「6.0」「6m」が、どこかで落ちるか丸められます。文字のまま受け、プログラムで決まりに従って数にします。
OpenAI API の構造化出力は、JSON スキーマに strict: true を付けて使い、すべての項目を required にし、オブジェクトには additionalProperties: false を必ず設定するとされています。 スキーマ全体の項目数は5,000まで、入れ子は10段までとされているので、ます目は行×列の入れ子にせず、cells の平らな配列で受けます。
材積の計算は、次のような形になります(要点だけ)。
from decimal import Decimal, ROUND_HALF_UP
def log_volume(d_cm, l_m):
d, l = Decimal(d_cm), Decimal(l_m)
if l < 6:
v = d * d * l / 10000
else:
l_int = Decimal(int(l)) # 1m未満を切り捨てた長さ
v = (d + (l_int - 4) / 2) ** 2 * l / 10000
q = Decimal("0.001") if v >= Decimal("0.001") else Decimal("0.0001")
return v.quantize(q, rounding=ROUND_HALF_UP) # 小数第4位(または第5位)を四捨五入
1本ごとに端数を処理してから本数を掛けるか、本数を掛けてから処理するかは、出荷先との取り決めを先に確かめます。 どちらで計算したかを、台帳の下書きに書いておきます。
後段の照合は、この出力に対して決まりで行います。
| 照合 | 外れたとき |
|---|---|
| ます目の文字が数字として読める | 「正」の字は完成した字だけを5本として数え、書きかけの画があれば印 |
| 径級が単位寸法に合う(14cm以上は2cm刻み) | 「径級の読み違いの候補」の印 |
| 長さが単位寸法に合う(0.2m刻み、規定の区分を含む) | 「長さの読み違いの候補」の印 |
| 計算した合計の本数が、野帳の合計と合う | 「本数の食い違い」の印。検知員に確かめる |
| 計算した合計の材積が、野帳の合計(書かれていれば)と合う | 「材積の食い違い」の印 |
| 日付・土場・樹種が出荷の予定にある | ページごと印を付ける |
| 読み取りの信頼度が基準を下回るます目がない | ます目に印を付ける |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 撮影用のアプリとフォルダ | フォルダの監視 | 画像の保存を検知し、画質の結果を返す |
| Google Document AI | API呼び出し | 画質スコア、表・上の欄・信頼度を返す |
| OpenAI API | API呼び出し | 行と列の対応づけ、本数の書き写し |
| 出荷の予定表 | 表計算の読み込み | 日付・土場・樹種・出荷先の照合 |
| 出荷の台帳 | 表計算のファイル | 確認の済んだページを書き込む |
| 出荷先への明細 | 雛形への差し込み | 樹種・長さ・径級ごとの本数と材積 |
出荷の台帳へ書き込むのは、人が確かめたページだけです。 合計が合い、確認の要るます目の無いページは、事業課の担当が一覧で流し見て「確定」を押した時点で書き込みます。明細を出荷先に送るのも、人が行います。
人が確認する
人が見るのは、印の付いたページとます目だけです。
- 本数の食い違いを先に見る … 計算した合計と野帳の合計が合わないページを、画像と並べて見ます。ます目の読み違いなら直し、そうでなければ検知員に確かめます
- 読めないます目と「正」の書きかけを確かめる … 画像で本数を数えて直します
- 径級・長さの読み違いの候補を確かめる … 単位寸法に合わない値を、画像で確かめます
- 出荷の予定に無いページを確かめる … 土場や樹種の書き違いか、予定の漏れかを確かめます
- 確定して明細を作る … 出荷先ごとに、樹種・長さ・径級ごとの本数と材積を確かめてから送ります
1番目は、その日のうちに行います。 検知員に確かめるとき、丸太がまだ土場にあれば数え直せます。 翌日以降だと、検知員の記憶に頼るしかありません。
目標は、480ページをならして1ページ2.5分です。 合計が合い印の無いページは一覧で流し見て数十秒、食い違いのあるページは画像を見て検知員に確かめるので数分かかります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 雨や土で野帳が汚れて読めない | 画質の確認で撮り直し。撮り直せなければ人が実物を見る |
| 画質スコアが低いが撮り直せない(電波が無い) | 事務所で確かめ、翌朝に撮り直す |
| 「正」の書きかけの画 | 本数にせず印を付ける。人が数える |
| 表の見出しが読めない | 雛形の並びと照らして対応づけ、unknown は人が決める |
| 単位寸法に合わない径級・長さ | 読み違いの候補として印を付ける。勝手に丸めない |
| 合計の本数が書かれていない | 照合をせず、ページごと人に回す。検知員に合計を書く決まりを伝える |
| 1回の検知が複数ページに続く | 上の欄の「続き」でつなぎ、合計は最後のページと照らす |
| 同じページの重複 | 印を付けて止め、人が決める |
| Document AI が応答しない | フォルダに残し、事業課がいまの手順で打ち込む |
上の3行が大半を占めます。 どれもAIの精度の問題というより、屋外で書く野帳の性質と、書き方の決まりの問題です。 防水の野帳を使う、本数を数字で書く決まりを浸透させるほうが、指示を直すより効きます。
記録を残す
- 野帳の画像と、撮影の日時・検知員・撮り直しの有無
- 画質スコアと欠点の一覧
- OCR が返した
Documentの全文(text、formFields、tables、信頼度) - 生成AIの出力(行と列の対応づけ、ます目の文字)
- 計算した材積と、計算に使った式と端数の扱い(1本ごとか合計か)
- 照合の結果と、人が直したます目の記録
- 出荷先に送った明細と、送った日時
計算に使った式と端数の扱いを残すのは、出荷先との数量の照合に備えるためです。 出荷先が受け入れの検収で別の数字を出したとき、どの式で、どの順で端数を処理したかが分かれば、差の理由をすぐ説明できます。
04実装レベルの3段階
最小構成は、野帳が読めるかを確かめる段階です。 月480ページには使えません。 半自動化で、1ページ8分が4分程度になります。 打ち込みと材積の計算は自動になりますが、合計の突き合わせと、汚れた野帳の読み直しが人の手に残ります。 本格構成で2.5分になり、この段階が本記事の想定です。 差が大きいのは、画質の確認で汚れた画像が土場で撮り直され、合計の照合で人が見るページが絞られるからです。 段階を飛ばさないでください。 半自動化の1か月で、「正」の字で書く検知員と、読めない野帳の多い土場が見えます。書き方の決まりを浸透させてから本格構成に進むほうが、印が減ります。
05工数削減シミュレーション
導入後 480件 × 2.5分 ÷ 60 = 20 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 間伐や主伐で年間を通して丸太を生産し、原木市場や製材工場、合板工場へ出荷している森林組合・素材生産業者。検知員が土場で紙の野帳に樹種・長さ・径級ごとの本数を手書きし、事務所で表計算に打ち直して材積表を引きながら材積を出している場合。打ち直しが出荷の伝票や明細の作成を待たせ、検知員によって野帳の書き方が違う場合。
- 検知を端末や計測の機械で行い、径と長さが自動で記録されている事業者。出荷が月に数台で、打ち直しの手間が小さい場合。なお、径と長さの測り方、等級の格付け、出荷先との数量の確定、森林の所有者への精算の判断は、この構成では代替できません。
07最小構成で試す方法
- 先月の野帳から20ページを選ぶ(汚れたもの、「正」の字で書かれたもの、6m以上の材が多いもの、合計が合わなかったものを入れる)
- その20ページについて、出荷の台帳に打ち込まれた本数と材積を書き出しておく
- 野帳の画像を、手元の生成AIの画面に1ページずつ貼る
- 「この野帳のます目を、径級・長さ・本数の表にしてください。読めないます目は空にしてください。合計から逆算しないでください。材積は計算しないでください」と指示する
- 出てきた表を表計算に貼り、規格の式で材積を計算して、打ち込まれた値と比べる
材積は、最小構成でも表計算の式で計算してください。 生成AIの画面で材積まで出させると、読み取りの誤りと計算の誤りが混ざり、どちらが原因か分からなくなります。
| 出てきた内容 | 判断 |
|---|---|
| 打ち込まれた本数とほぼ同じ表が出た | OCR の API と照合の処理に進む |
| 「正」の書きかけを本数にした | 書きかけは文字のまま写させ、決まりで扱う。構成は有効 |
| 読めないます目を合計から逆算した | 指示と、後段の照合で止められる |
| 読めないページが多い | 撮り方と野帳の扱いが先。 AIの問題ではない |
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 読めないます目を合計から逆算する | 逆算を禁じ、合計の照合で印を付ける |
| 材積を生成AIに計算させる | 規格の式と端数の扱いをプログラムに書く |
| 6m以上の材を6m未満の式で計算する | 長さで式を分け、6m以上は1m未満を切り捨てた長さを使う |
| 「正」の書きかけを本数にする | 文字のまま写させ、完成した字だけを数える |
| 単位寸法に合わない径級を丸めて通す | 丸めずに読み違いの候補として印を付ける |
| 端数の扱いが出荷先と違う | 1本ごとか合計かを出荷先と取り決め、台帳に書く |
| 汚れた画像のまま読んで照合が合わない | 画質の確認を先に回し、土場で撮り直す |
| 同じページを二度計上する | 重複を検知して止める |
| 国外で処理されることを確かめていない | 日本のリージョンは無い。 組合の決まりに照らす |
| 明細を自動で出荷先に送る | 送信は人。確定したページだけを明細にする |
上の2行が、この構成でいちばん重い失敗です。 どちらも、取引の数量がAIの推測で決まる経路です。本数は書かれた文字から、材積は規格の式から出す、と分けて守ります。
6行目は、導入の前に片付けます。 出荷先の検収と組合の台帳で材積が合わないとき、原因の多くは読み取りではなく端数の扱いです。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 検知の日付、土場と施業地、樹種、径級・長さごとの本数と材積、検知員の名前、出荷先です。施業地の名前から森林の所有者が分かる場合があり、出荷先との取引の数量も外に出したくない情報です。
- 処理の場所を確かめる … Form Parser と Enterprise Document OCR の対応リージョンに日本はありません。
us・euかシンガポールなどから選びます。施業地や所有者の情報が国外で処理されることを、組合の決まりに照らして確かめます - 生成AIに渡す範囲を絞る … 生成AIには表と上の欄だけを渡し、出荷の予定表や所有者の情報は渡しません。照合は Python の側で行います
- 数量を確定させない … 本数と材積は、出荷先への請求と所有者への精算につながります。食い違いと読めないます目は、人が画像と検知員への確認で直します
- 測り方を代替しない … 素材の日本農林規格では、丸太の径は最小径を基本とし、最小径と直角な径の差に応じて加える決まりがあります。径と長さを測るのは検知員で、構成は書かれた値を規格の式に当てはめるだけです
- 明細を自動で送らない … 出荷先へは、人が確定した明細だけを送ります
誤りが起きた場合のリスクは、誤った材積で請求や精算をすることと、数え違いが見過ごされることの2つです。前者は規格の式をプログラムに書くことで、後者は逆算の禁止と合計の照合で防ぎます。
10まず何から始めるか
1週目:野帳の雛形と書き方の決まりをそろえる
組合で使う野帳の雛形を、径級と長さの並びが決まったものに1つか2つにそろえます。検知員に、本数は数字で書き、合計の本数を右下に書く決まりを伝えます。出荷先と、材積の端数の扱いを確かめます。
2週目:20ページで試す
先月の野帳から20ページを選び、最小構成で本数の表にさせ、表計算の式で材積を出して、打ち込まれた値と比べます。読めないます目を逆算で埋めていないか、「正」の書きかけを本数にしていないかを最優先で見ます。
3週目:撮り方を決める
撮影用のアプリを用意し、検知員が土場で撮る手順を決めます。画質の確認を回し、どの程度の汚れで撮り直しになるかを見ます。
4週目:Form Parser から台帳の下書きまでをつなぐ
野帳の画像を保存すると Form Parser が動き、本数を出荷の台帳の下書きに書き出し、材積を式で計算するところまで作ります。この時点では照合を入れず、読み取りと計算の結果だけを見ます。
2か月目: 画質の確認、単位寸法の確認、合計との照合、出荷の予定との照合を足し、確認の一覧で印の付いたページだけを見る運用にします。3か月目以降: 明細への差し込みを足し、1ページ8分が何分になったかを実測します。合計の食い違いがその日のうちに検知員に確かめられ、出荷先の検収と組合の台帳の材積がそろうようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Form Parser がキーと値のペア、表、チェックボックスなどを抽出すること。言語の一覧で日本語(ja)が手書きに対応する言語として示されていること(原文の HTML で確認)。Form Parser と Enterprise Document OCR の対応リージョンが us・eu・asia-southeast1 などで、日本のリージョンが無いこと | Google Cloud: Processor list | 2026-10-15 |
| Form Parser が学習済みで追加の学習ができないこと。行や列をまたぐセルの無い表を抽出すること | Google Cloud: Form Parser | 2026-10-15 |
text が唯一の元で、ほかの欄が startIndex・endIndex で指すこと。formFields が fieldName と fieldValue を持つこと。表が headerRows と bodyRows に分かれること | Google Cloud: Handle the processing response | 2026-10-15 |
ocrConfig.enableImageQualityScores で画質スコア(0〜1)が返り、0.5を下回ると defect_blurry・defect_dark・defect_faint・defect_document_cutoff・defect_glare などの欠点が返ること。結果が pages[].imageQualityScores に入ること。OCR の処理と同じくらいの待ち時間が加わること | Google Cloud: Enterprise Document OCR | 2026-10-15 |
構造化出力で strict: true を使い、すべての項目を required にし、オブジェクトに additionalProperties: false を必ず設定すること。スキーマの項目数が5,000まで、入れ子が10段までであること | OpenAI API: Structured model outputs | 2026-10-15 |
| 素材の日本農林規格(JAS 1052:2022)で、丸太の材積の標準的な計算式が長さ6m未満と6m以上で分かれること。材積の端数の扱い。径の単位寸法が小の素材で1cm・それ以外で2cm、長さの単位寸法が0.2m(1.9・2.1・2.7・3.3mの区分の規定を含む)で端数を切り捨てること。丸太の径が最小径を基本とすること(PDFの原文で確認) | 農林水産省: 素材の日本農林規格 | 2026-10-15 |
径と長さの測り方、等級の格付け、出荷先との数量の確定、森林の所有者への精算は、組合の担当者が判断してください。 本記事は、上記の公開情報で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1629)についてのご相談はこちらから。
