Media > AI活用ユースケース > 物流 > 産業廃棄物・資源の受入れで、トラックスケールの計量票を読み取り、車番・品目・総重量・空車重量を受入の台帳に転記して、マニフェストの数量と照らす

産業廃棄物・資源の受入れで、トラックスケールの計量票を読み取り、車番・品目・総重量・空車重量を受入の台帳に転記して、マニフェストの数量と照らす

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

トラックスケールが印字し、計量の担当が品目や控除を手で書き足した計量票を読み取り、車番・品目・総重量・空車重量を受入の台帳にそろえます。正味重量を計算し直し、同じ搬入のマニフェストの品目・数量との差が大きいものを確認に回します。

サマリー
AIサービス
Azure AI/Google Document AI
連携・自動化
Google Apps Script/Python
対象業界
その他/建設/物流
対象部門
物流
対象業務
データ入力・転記/内容確認・チェック
主な課題
人手が足りない/入力作業が多い/確認ミスが多い
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/判断支援/工数削減
導入難易度
★★☆☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
70h/月
AI導入後
20h/月
想定削減
71%
年間削減
600h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 搬入車両が入場し、計量所の担当が車番と搬入元を計量器に打ち込んで総重量を量る
  2. 荷下ろしの場で、担当が品目を確かめ、異物が混ざっていれば控除の重さを計量票に書く
  3. 車両が出場するときに空車重量を量り、計量器が正味重量を印字した計量票を出す
  4. 産業廃棄物の搬入では、運転者からマニフェストを受け取る
  5. 計量票とマニフェストが昼と夕方に事務所に届く
  6. 事務所の担当が、計量票の車番・搬入元・品目・重量・控除を受入の台帳に入力する
  7. マニフェストの品目と数量を計量票と見比べ、差の大きいものをメモする
  8. メモしたものを計量所の担当と営業に確かめる
導入後(After)
  1. 人計量所の担当がこれまでどおり計量し、計量票に手で書き足す
  2. 人計量票とマニフェストを、計量所の複合機でその場でスキャンする
  3. 自動保存をきっかけに処理が動き、計量票とマニフェストを分け、計量の番号でひも付ける
  4. 自動Google Document AI の Form Parser が、計量票のキーと値のペア、表、手書きの文字を信頼度つきで返す
  5. 自動項目名の辞書で、読み取ったキーを台帳の項目(車番・搬入元・品目・総重量・空車重量・控除)にそろえる
  6. 自動印字の領域と手書きの追記を分け、手書きの追記がある票に印を付ける
  7. 自動正味重量を総重量 - 空車重量 - 控除で計算し直し、印字の正味重量と照らす
  8. 自動車番と搬入元を、取引先と車両の一覧で照らす
  9. 自動マニフェストの品目・数量と照らし、単位が同じなら差の割合を出す
  10. 自動票ごとに `台帳へ` / `追記あり要確認` / `照合要確認` を付けて、確認の一覧に並べる
  11. 人事務所の担当が `追記あり要確認` と `照合要確認` の票だけを画像と並べて確かめる
  12. 人確かめた行を受入の台帳に移す。マニフェストとの差が大きいものは計量所と営業に確かめる
各工程の詳しい説明を読む
  1. 搬入車両が入場し、計量所の担当が車番と搬入元を計量器に打ち込んで総重量を量る
  2. 荷下ろしの場で、担当が品目を確かめ、異物が混ざっていれば控除の重さを計量票に書く
  3. 車両が出場するときに空車重量を量り、計量器が正味重量を印字した計量票を出す
  4. 産業廃棄物の搬入では、運転者からマニフェストを受け取る
  5. 計量票とマニフェストが昼と夕方に事務所に届く
  6. 事務所の担当が、計量票の車番・搬入元・品目・重量・控除を受入の台帳に入力する
  7. マニフェストの品目と数量を計量票と見比べ、差の大きいものをメモする
  8. メモしたものを計量所の担当と営業に確かめる

(a)手書きの追記が台帳に入らない。 印字された正味重量だけを入力し、手で書き足した控除や再計量の重量を入れ忘れることがあります。 控除の分だけ受け入れた重さが多く記録され、買い取りの資源なら支払いの額が、処理の受託なら請求の額が変わります。

(b)書き直した車番を見落とす。 打ち間違えた車番に二重線を引いて手で書き直した票を、印字のまま入力すると、別の搬入元の車両として台帳に入ります。 月末の搬入元ごとの集計で、量の合わない取引先が出ます。

(c)マニフェストとの差を見落とす。 マニフェストの数量は排出事業者が書いたもので、計量した重さとはもともと違います。 単位も、トン、立方メートル、台数とばらばらです。どこまでの差なら普通で、どこからが品目の取り違えかの見当が、担当の経験に頼っています。 1日60台を見比べる中で、大きな差を見落とします。

(d)資源の買い取りでは、その場で支払いの額が決まる。 金属くずや古紙の買い取りでは、計量票の正味と単価から買い取りの額を出します。控除を引き忘れた重さで額を出すと、払いすぎた分を後から取り戻すのは難しく、取引先との関係にも残ります。受入の台帳の重さは、処理の請求と買い取りの支払いの両方の元です。

(e)入力が翌日にずれ込む。 夕方に届く計量票は、その日のうちに入力が終わらず、翌朝の入力と重なります。 当日の受入の量が分からないまま、翌日の受入の調整をすることになります。

  1. 【人】 計量所の担当がこれまでどおり計量し、計量票に手で書き足す
  2. 【人】 計量票とマニフェストを、計量所の複合機でその場でスキャンする
  3. 【自動】 保存をきっかけに処理が動き、計量票とマニフェストを分け、計量の番号でひも付ける
  4. 【自動】 Google Document AI の Form Parser が、計量票のキーと値のペア、表、手書きの文字を信頼度つきで返す
  5. 【自動】 項目名の辞書で、読み取ったキーを台帳の項目(車番・搬入元・品目・総重量・空車重量・控除)にそろえる
  6. 【自動】 印字の領域と手書きの追記を分け、手書きの追記がある票に印を付ける
  7. 【自動】 正味重量を総重量 - 空車重量 - 控除で計算し直し、印字の正味重量と照らす
  8. 【自動】 車番と搬入元を、取引先と車両の一覧で照らす
  9. 【自動】 マニフェストの品目・数量と照らし、単位が同じなら差の割合を出す
  10. 【自動】 票ごとに 台帳へ / 追記あり要確認 / 照合要確認 を付けて、確認の一覧に並べる
  11. 【人】 事務所の担当が 追記あり要確認 と 照合要確認 の票だけを画像と並べて確かめる
  12. 【人】 確かめた行を受入の台帳に移す。マニフェストとの差が大きいものは計量所と営業に確かめる

11番目が、この設計の分かれ目です。 手書きの追記が無く、正味重量の計算も合い、車番も一覧に当たった票は、一覧で流し見て台帳に移します。時間を使うのは、人の手が加わった票と、何かが合わなかった票だけです。

9番目で差の割合を出すのは、単位が同じときだけです。 マニフェストに立方メートルで書かれた数量を、比重を仮定してトンに直すことはしません。直した数字で差を出すと、仮定の比重の誤りが差に見えます。

02今回想定するシステム構成

構成図
計量票(印字:計量番号・日時・総重量・空車重量・正味重量、車番・搬入元
         手書き:品目・異物の控除・荷姿・再計量・書き直し)
マニフェスト(紙。電子マニフェストは照会の画面から書き出す)
   │  計量所の複合機でスキャン(300dpi、PDF)
   ▼【トリガー】Cloud Storage のバケットへの保存
Python(Cloud Run functions)
   ├──▶ 計量票とマニフェストの仕分け、計量番号でのひも付け
   ▼
Google Document AI(Form Parser)
   │   キーと値のペア、表、手書きの文字、信頼度
   ▼
Python ── 項目名の辞書で台帳の項目へ、印字と手書きの分離
   │        正味重量の計算し直し、取引先・車両の一覧との照合
   │        マニフェストの品目・数量との照合
   ▼
判定(台帳へ / 追記あり要確認 / 照合要確認)
   ▼
【受入の担当が要確認の票だけ画像と並べて確認】
   ▼
受入の台帳へ(確かめた行だけ)
役割想定する製品代替候補
OCRGoogle Document AI(Form Parser)Azure AI Document Intelligence(レイアウト モデル)
連携Python(Cloud Run functions。保存を起点に読み取りを呼び、項目の対応づけと照合をして一覧に書き出す)Google Apps Script
差異計算Python(正味重量の計算し直しと、マニフェストの数量との差)Google Apps Script
保管Cloud Storage(計量票・マニフェストの画像と読み取り結果)社内のファイルサーバー

生成AIは使いません。 計量票の項目は、どの票でも「総重量」「空車重量」「正味」「車番」と決まっています。項目名の対応づけは辞書で足り、重さは計算で確かめられます。 文章を作る機能が要る場面がありません。

受入の台帳は新しく足すものではありません。 この構成は確認の一覧と、台帳に貼れる形の書き出しまでを作り、台帳へ移すのは担当が確かめてからです。

土台は Document AI の Form Parser です。 公式のプロセッサ一覧では、OCR のテキストに加えて、キーと値のペア(項目とチェックボックス)、表、汎用のエンティティを取り出すとされ、汎用のエンティティには数量(quantity)や日時(date_time)が含まれます。計量票の「総重量 12,340 kg」のような印字は、キーと値のペアとして取れます。

日本語の手書きにも対応しています。 プロセッサ一覧の Form Parser の言語の表では、日本語(ja)に手書き入力に対応の印が付いています。品目の書き直しや控除の手書きを読めるかは、ここで決まります。

Form Parser は学習済みで、追加の学習はできません。 公式ページでは、事前トレーニング済みでアップトレーニングできないとされ、ラテン文字以外の言語ではキーと値のペアの品質が下がる場合があるとも書かれています。だから読み取った値を計算と一覧で確かめる設計にします。

処理する場所に、日本のリージョンはありません。 プロセッサ一覧では、Form Parser の対応地域は us、eu のほか、asia-southeast1(シンガポール)や asia-south1 などの単一の地域で、日本は含まれていません。 計量票には取引先の名前と車番が載るので、国外で処理されることを社内の決まりと取引先との契約に照らして確かめます。

03どうやって実装するのか

Step1

処理の起点を決める

計量所で計量票とマニフェストをスキャンし、Cloud Storage のバケットに保存したことを起点にします。 これまでは昼と夕方に紙を事務所へ運んでいましたが、計量所でその場でスキャンすれば、出場から数分で読み取りが終わります。 当日の受入の量が、その日のうちに台帳に入ります。

スキャンは1台分ずつにします。計量票1枚と、その搬入のマニフェストを続けてスキャンし、1つのPDFにします。計量の番号が仕分けの鍵になるので、計量票を先頭にします。

処理が終わったファイルは処理済みの場所へ移し、移すのは成功したときだけにします。 残っているファイルが、そのまま未処理の数です。

Step2

入力データを集める

データ中身取得元
計量票のPDF印字と手書きが混ざった計量票の画像計量所のスキャン
マニフェストのPDF紙のマニフェストの画像(その搬入の分)計量所のスキャン
読み取り結果キーと値のペア、表、手書きの文字、それぞれの信頼度Google Document AI(Form Parser)
項目名の辞書計量票とマニフェストの項目名の言い方と、台帳の項目の対応自社で用意する表
取引先と車両の一覧搬入元、車番、ふだん運ぶ品目受入の台帳の取引先の表
品目の辞書「木くず」「ミンチ」「混廃」などの書き方と、台帳の品目コード自社で用意する表
電子マニフェストの書き出し交付番号、品目、数量と単位、排出事業者電子マニフェストの照会の画面からの書き出し

質を決めるのは、2つの辞書です。 計量票の項目名は計量器の機種で決まりますが、品目の手書きは担当ごとに言い方が違います。 「ミンチ」と書く人と「混合廃棄物」と書く人がいて、辞書が無いと同じ品目が別々に集計されます。

取引先と車両の一覧は、車番の書き直しを見つけるために持ちます。 印字の車番がその搬入元の車両の一覧に無く、手書きの車番が一覧にあれば、打ち間違えを書き直した票だと分かります。

Step3

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

読み取りは、Python から Form Parser のプロセッサにPDFを送るだけです。1台分のPDFは計量票とマニフェストで数ページなので、オンライン(同期)の要求で足ります。 プロセッサ一覧では、オンライン・同期の要求の上限は15ページで、画像なしのモードを有効にすると30ページまでとされています。

取るものどこから何に使うか
キーと値のペア各ページの formFields(項目名と値、信頼度)総重量・空車重量・正味・車番・搬入元
チェックボックスformFields のうち値の種類が選択のもの荷姿や「再計量あり」のチェック
表各ページの tablesマニフェストの品目と数量の欄
汎用のエンティティ数量・日時計量の日時と重さの裏付け
手書きの文字文字の領域ごとの手書きの判定と信頼度印字と手書きの分離

チェックボックスは、項目名との結び付きを確かめます。 公式ページでは、チェックボックスは最も近い文字を項目名にしたキーと値のペアとして取り出され、valueType でオンかオフかが示されるとされています。一方で、ラジオボタンには対応せず、検出したチェックボックスの一部には対応するキーが無い場合があるとも書かれています。キーが無いチェックは位置で判断せず、照合要確認 にします。

応答の中では、キーと値のペアはページごとの formFields に、表は tables に入ります。 応答の扱いの公式ページでは、チェックボックスがオンなら formFields の fieldValue の valueType が filled_checkbox、オフなら unfilled_checkbox になるとされています。「再計量あり」のチェックは、この値だけで判定します。 印字の文字の濃さや、チェックの近くの手書きから推し量りません。

電子マニフェストの分は、照会の画面から1日分を書き出して読みます。 紙のマニフェストとちがい、OCRを通しません。取り方は利用している環境によるので、書き出しの形を最初に決めます。

Step4

AIへ渡す前に整形する

  1. 計量票とマニフェストを分ける … 先頭のページを計量票、続くページをマニフェストとして分け、計量の番号でひも付けます
  2. 向きと傾きを確かめる … 計量票は細長い紙のことが多く、横向きにスキャンされがちです。向きを直してから送ります
  3. 解像度を確かめる … 感熱紙の印字は薄くなりやすいので、300dpiでスキャンします
  4. TIFF の形式を確かめる … 公式ページの制限事項では、TIFF の古い JPEG 圧縮には対応していないとされています。PDF でスキャンします
  5. ページ数を確かめる … 1台分が15ページを超えることはまずありませんが、まとめてスキャンされたものは1台ずつに分けます
  6. 二重のスキャンを見つける … 同じ計量の番号の票が直近にあれば、二重に処理しません

3番目を軽く見ないでください。 計量票の多くは感熱紙で、日に当たったり時間がたったりすると印字が薄くなります。 計量所でその場でスキャンするのは、事務所に運ぶあいだに薄くならないうちに読むためでもあります。

Step5

AIに処理させる

Form Parser にさせるのは、計量票とマニフェストに書かれていることを、項目名と値の組にすることだけです。 そのあとの対応づけ、計算、照合は、すべてプログラムが規則で行います。

見るもの判定の仕方合わないときの扱い
総重量・空車重量・正味(印字)3つとも数値として読めるか1つでも読めなければ 照合要確認
正味重量の計算総重量 - 空車重量 - 控除 が印字の正味と合うか合わなければ 照合要確認。どちらが正しいかは人が見る
控除・再計量(手書き)手書きの数字があるか、信頼度が十分かあれば 追記あり要確認
車番・搬入元取引先と車両の一覧に当たるか、書き直しがあるか書き直しがあれば 追記あり要確認
品目品目の辞書に当たるか当たらなければ 照合要確認
マニフェストとの照合品目が同じか、単位が同じなら数量の差の割合品目が違う、差が設定の割合を超える、で 照合要確認

2行目が、この構成でいちばん効く確かめです。 3つの数字のうち1つを読み違えれば、計算が合わなくなります。読み取りの信頼度に頼らなくても、計算で読み違えを見つけられます。 計量票ならではの強みです。

ただし、控除を手で書き足した票は、計算が合わないのが普通です。 印字の正味は控除を引く前の値だからです。控除がある票は、控除を引いた値を台帳の正味とし、追記あり要確認 で人に見せます。

させないこと理由
正味重量や控除の推定重さは計算か人の確認で決める
立方メートル・台数からトンへの換算仮定の比重の誤りが差に見える
マニフェストの記載の誤りの判断排出事業者に確かめることで、受入の担当が判断する
品目の言い換えの確定辞書に無い品目は人が決め、辞書に足す
再計量の要否の判断計量所の担当が決める

3行目を外さないでください。 マニフェストの数量と計量の重さの差が大きいとき、マニフェストの誤りのことも、計量の誤りのことも、荷の取り違えのこともあります。 この構成が出すのは差があるという事実だけで、どれなのかは担当が排出事業者と確かめます。

Step6

指示内容を固定する

この構成では生成AIに指示文を渡しません。読み取りのあとの処理は、項目名の辞書と照合の規則です。 項目名の辞書は、計量票とマニフェストに出てくる言い方と、台帳の項目を1行に1つ対応させます。

# 項目名の辞書(読み取ったキー → 台帳の項目)
総重量, 総重, 入場重量, GROSS        → gross_kg
空車重量, 空車, 出場重量, TARE        → tare_kg
正味重量, 正味, 差引重量, NET         → net_printed_kg
車両番号, 車番, 車輌番号              → vehicle_no
搬入者, 搬入元, 取引先, 業者名         → supplier
異物控除, 控除, 引き                  → deduction_kg
再計量, 再計                          → reweigh_kg

# 照合の規則
- net_calc = gross_kg - tare_kg - deduction_kg(控除が無ければ 0)
- 控除が無い票で net_calc と net_printed_kg が一致しなければ「照合要確認」
- 手書きの領域に数字があれば「追記あり要確認」
- 品目が品目の辞書に無ければ「照合要確認」。近い品目を自動で当てない
- マニフェストの単位が kg または t のときだけ差の割合を出す
  差の割合 = |net_calc - manifest_qty_kg| / net_calc
  品目ごとに決めた割合(例:設定ファイルの tolerance)を超えれば「照合要確認」
- マニフェストの単位が m3・台・個のときは、差を出さず「単位が違う」と記録する

「近い品目を自動で当てない」を規則に書いているのは、意図してのことです。 「木くず」と「木くず(抜根)」は処理の方法も料金も違うことがあり、辞書に無い書き方を近い品目に寄せると、違う品目の料金で請求が出ます。 辞書に無いものは人が決めて、決めたものを辞書に足します。

差の割合の許容は、品目ごとに受入の担当が決めます。 汚泥のように水分で重さが大きく変わる品目と、金属くずのように変わりにくい品目で、同じ割合を使うと、片方は毎回引っかかり、片方はいつも素通りします。

Step7

出力形式を固定する

1台分ごとに、次の形のJSONにまとめ、確認の一覧と台帳の書き出しの元にします。

{
  "weigh_no": "",
  "weighed_at": "",
  "vehicle_no": { "printed": "", "handwritten": "", "master_match": "matched | not_found | corrected" },
  "supplier": "",
  "item": { "written": "", "item_code": "", "dictionary_match": true },
  "weights": {
    "gross_kg": 0, "tare_kg": 0, "net_printed_kg": 0,
    "deduction_kg": 0, "reweigh_kg": null, "net_calc_kg": 0,
    "net_consistent": true
  },
  "handwritten_fields": ["deduction_kg"],
  "manifest": { "type": "paper | electronic | none", "issue_no": "",
                "item": "", "qty": 0, "unit": "kg | t | m3 | 台",
                "diff_ratio": null, "unit_mismatch": false },
  "confidence_min": 0,
  "verdict": "台帳へ | 追記あり要確認 | 照合要確認"
}

1つ目の理由は、printed と handwritten を別に持てることです。 車番も重さも、計量器が出した値と人が書いた値を並べておけば、担当は画像を開く前に、何が書き直されたかを読めます。

2つ目は、net_calc_kg と net_consistent で計算の確かめが残ることです。 台帳に入る正味は net_calc_kg で、印字との一致は net_consistent に記録されます。

3つ目は、unit_mismatch で比べられない搬入を分けられることです。 単位が違うものは差を出さず、差が無いのではなく比べていないことを、一覧の上で区別します。

条件verdict
手書きの追記なし、正味の計算が一致、車番・品目が一覧と辞書に当たる、マニフェストの差が許容内台帳へ
控除・再計量・車番の書き直しなど手書きの追記がある追記あり要確認
正味の計算が合わない、品目が辞書に無い、マニフェストの品目違い・差が許容超え、信頼度が低い照合要確認
Step8

システムへ連携する

つなぎ先方式内容
Cloud StorageCloud Run functions のトリガースキャンの保存を検知して処理を始める
Google Document AIForm Parser のオンラインの処理の要求キーと値のペア・表・手書きの文字・信頼度を返す
取引先と車両の一覧毎晩の書き出しを読む車番と搬入元の照合
電子マニフェストの書き出し1日分のファイルを読む品目と数量の照合
確認の一覧共有の表への書き出し票ごとの結果と画像へのリンク
受入の台帳確かめた行だけを貼れる形で書き出す台帳へは担当が移す

受入の台帳へは、この構成から書き込みません。 台帳は請求と支払いの元になるので、読み違えた重さが確かめる前に入る経路を作りません。

計量器にも、電子マニフェストにも書き込みません。 電子マニフェストの報告は、これまでどおり担当が画面で行います。

Step9

人が確認する

事務所の担当が開くのは 追記あり要確認 と 照合要確認 の票だけです。 台帳へ の票は、一覧で車番・品目・正味を流し見て、まとめて台帳に移します。

  1. 照合要確認 の正味の不一致を先に見る … 計量票の画像で、3つの数字のどれを読み違えたかを確かめます。印字そのものがかすれていれば、計量所に計量の記録を確かめます
  2. 追記あり要確認 の手書きを見る … 控除・再計量・車番の書き直しを画像で確かめ、値を直します。読めない手書きは、書いた計量所の担当に聞きます
  3. マニフェストとの差を見る … 品目違いや差の大きいものは、計量所の担当と営業に確かめ、必要なら排出事業者に連絡します
  4. 辞書に無い品目を決める … 台帳の品目コードを決め、品目の辞書に足します
  5. 直したら記録する … どの値を、何から何へ直したかを残します

1番目を省かないでください。 正味の計算が合わない票は、読み違えたまま台帳に入れると、請求か支払いの額がそのままずれます。

目標は、1,500件をならして1件0.8分です。 要確認に回るのは2割前後という想定で、それより多い月は、感熱紙の印字の薄さか、品目の辞書の不足を疑います。

Step10

例外に対処する

起きること対応
印字が薄くて重さが読めない照合要確認。計量所で計量の番号から記録を確かめる
チェックにキーが付いていない位置で判断せず 照合要確認
計量票が2枚(再計量)計量の番号でまとめ、後の計量を採るかは担当が決める
マニフェストが無い搬入資源の買い取りなら正常。産業廃棄物なら 照合要確認
マニフェストの単位が m3・台差を出さず unit_mismatch を記録
品目が辞書に無い照合要確認。近い品目に寄せない
車番が一覧に無い新しい車両か打ち間違い。担当が確かめて一覧に足す
Document AI が応答しない時間を置いて再実行。処理済みへ移すのは成功時だけ
同じ計量の番号が二度届く二重に処理しない

上の2行は、感熱紙と票の作りの問題です。 計量所でその場でスキャンし、チェック欄の横に必ず文字を印字する様式に変えるほうが、読み取りの工夫より効きます。

Step11

記録を残す

  • 計量票とマニフェストの画像、スキャンした日時
  • Form Parser が返した結果の全文(キーと値のペア、表、信頼度)
  • 判定の結果(JSONの全体)と、そのとき使った項目名の辞書・品目の辞書・許容の割合の版
  • 人が値を直した記録 … どの値を、何から何へ
  • 台帳へ移した日時と、移した担当
  • マニフェストとの差について、だれに何を確かめたか
  • 品目ごとの差の割合の分布

3つ目で辞書と許容の割合の版を残すのは、後から変えるためです。 許容の割合を見直すと、過去の照合の結果の意味が変わります。 当時の割合が残っていないと、なぜ素通りしたのかを説明できません。

最後の行は、許容の割合を決め直す材料になります。 品目ごとに差の分布を見れば、どこまでが普通の差なのかが、担当の経験ではなく数字で分かります。

04実装レベルの3段階

最小構成:コンソールで計量票を読み、読み取り結果を目で見る / 読み取りが使えるかの確認
半自動化:上記+保存を起点に読み取りを呼び、項目名の辞書で台帳の形に書き出す / 印字の転記
本格構成:上記+正味の計算し直し、印字と手書きの分離、取引先・車両・マニフェストとの照合 / 転記と照合の全体

最小構成では台数がさばけません。 確かめるための段階です。 半自動化で、1件2.8分が1.6分程度になります。 印字の転記は自動になりますが、手書きの追記の反映とマニフェストとの照合が目で残ります。 本格構成で0.8分になり、この段階が本記事の想定です。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
1,500 件
1件あたり現在時間
2.8 分
1件あたり導入後時間
0.8 分
現在  1,500件 × 2.8分 ÷ 60 = 70 時間/月
導入後 1,500件 × 0.8分 ÷ 60 = 20 時間/月
月間削減時間
50h
削減率
71%
年間削減時間
600h
年間金額換算(時間単価2,200円)
132万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. トラックスケールで搬入車両を計量し、計量器が印字した計量票に担当者が品目や控除を手で書き足している産業廃棄物の処理業者・資源の回収業者。計量器がデータを書き出せない古い機種で、事務所が計量票を見ながら受入の台帳に入力している場合。紙のマニフェストと電子マニフェストが混在し、マニフェストに書かれた数量と計量した重量の差を手で見比べている場合。
向いていない
  1. 計量器と受入の管理のシステムがつながっていて、計量の値が自動で台帳に入っている場合。1日の搬入が数台で、目で見て足りる場合。計量票に手書きの追記をほとんどしない場合。なお、マニフェストの記載の誤りかどうか、計量のやり直しが要るかの判断は受入の担当と排出事業者のあいだで行うもので、この構成では代替できません。

07最小構成で試す方法

  1. 先週の計量票から30台分を選ぶ(控除の手書き、車番の書き直し、印字の薄いものを必ず入れる)
  2. 計量票とマニフェストを300dpiでスキャンする
  3. Google Cloud のコンソールで Form Parser のプロセッサを作り、30台分を1つずつ処理する
  4. 総重量・空車重量・正味が、キーと値のペアとして正しく取れているかを見る
  5. 手書きの控除と品目が、どの程度読めているかを見る

30台分は必ずやってください。 プログラムを書く前に、印字の重さと手書きの追記が読めるのかを確かめます。

出てきた内容判断
印字の3つの重さが読め、手書きもおおむね読める辞書と照合のプログラムに進む
印字は読めるが、手書きの多くが読めない印字の転記だけを自動にし、手書きの追記がある票は全部人に回す
印字が薄くて重さが読めない票が多いスキャンの時期と設定が先。 AIの問題ではない

2行目が出ても、構成は成り立ちます。 時間の多くは、手書きの追記が無い票の転記にかかっているからです。

08実装時につまずきやすいポイント

問題対策
控除の手書きを入れ忘れる手書きの領域に数字があれば必ず人に回す
控除のある票で計算が合わないと騒ぐ印字の正味は控除の前。控除を引いた値を台帳の正味にする
読み違えた重さが台帳に入る正味の計算し直しで止める
辞書に無い品目を近い品目に寄せる寄せない。人が決めて辞書に足す
立方メートルをトンに直して差を出す換算しない。unit_mismatch を記録する
差の許容をすべての品目で同じにする品目ごとに決める
キーの無いチェックを位置で読む照合要確認 にする
感熱紙の印字が薄くなる計量所でその場でスキャンする
国外で処理されることを確かめていない日本のリージョンは無い。 社内の決まりと取引先との契約に照らす
全件を開いて確認してしまう台帳へ は流し見る運用を最初に決める

上の3行が、この構成の失敗のほとんどです。 どれも、印字の値と手書きの値を同じ確からしさで扱うところから出発しています。計算で確かめられる印字と、人にしか確かめられない手書きを分ければ、運用に乗ります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 搬入元の取引先の名称、車番、運転者の名前(マニフェストに書かれる場合)、品目と重さ、マニフェストの交付番号と排出事業者の情報です。

  1. 処理の場所を確かめる … Form Parser の対応地域に日本はありません。us・eu かシンガポールなどから選びます。取引先の情報が国外で処理されることを、社内の決まりと取引先との契約に照らして確かめます
  2. 重さを確かめずに台帳に入れない … 受入の台帳は、処理の請求と資源の支払いの元です。確かめた行だけを担当が移します
  3. マニフェストの判断を代替しない … 法律では、排出事業者が引き渡しと同時に、産業廃棄物の種類と数量などを書いた管理票を交付するとされています。数量は排出事業者が書くもので、計量の重さとの差をどう扱うかは、受入の担当が排出事業者と確かめて決めます
  4. マニフェストの写しの扱いを変えない … 施行規則では、処分を受託した者は処分を終了した日から10日以内に写しを送付するとされています。この構成は受入の記録を速くするだけで、写しの送付や電子マニフェストの報告はこれまでどおり担当が行います
  5. スキャンの画像を原本の代わりにするかを決める … 計量票とマニフェストの紙をいつまで、どこに残すかを、社内の保存の決まりに沿って先に決めます

誤りが起きた場合のリスクは、読み違えた重さで請求や支払いが出ることと、品目を取り違えて違う料金や処理になることの2つです。 前者は正味の計算し直しで、後者は辞書に無い品目を寄せない規則で防ぎます。どちらも設計で防げるので、そこだけは守ります。

10まず何から始めるか

1週目:30台分で読めるかを試す

先週の計量票から30台分を選び、300dpiでスキャンしてコンソールの Form Parser にかけます。印字の3つの重さがキーと値のペアで取れているか、手書きの控除が読めるかを最優先で見ます。

2週目:2つの辞書を作る

計量票とマニフェストの項目名の辞書と、品目の辞書を、受入の担当と計量所の担当と一緒に作ります。 品目の辞書は、搬入の多い品目の書き方から集めます。

3週目:品目ごとの許容の割合を決める

マニフェストの数量と計量の重さの差を、品目ごとにどこまで普通とするかを、受入の担当と決めます。 決めきれない品目は、最初は差を記録するだけにします。

4週目:計量所のスキャンから一覧までをつなぐ

計量所のスキャンの保存を起点に、読み取りから確認の一覧までを作ります。この時点ではマニフェストとの照合をせず、正味の計算し直しと手書きの分離だけを見ます。

2か月目: 取引先と車両の一覧、マニフェストとの照合を足します。3か月目以降: 1件2.8分が何分になったかを実測し、品目ごとの差の分布を見ます。差の分布から許容の割合を決め直し、要確認に回る票が落ち着いた時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-15
確認した内容情報源確認日
Form Parser が OCR のテキストに加えて、キーと値のペア(項目とチェックボックス)、表、汎用のエンティティ(数量・日時など11個)を取り出すこと。言語の表で日本語(ja)に手書き入力に対応の印があること(原文の HTML で確認)。対応地域が us・eu・asia-southeast1・asia-south1 などで日本が無いこと。オンライン・同期の要求の上限が15ページ、画像なしのモードで30ページであることGoogle Cloud: Processor list2026-10-15
Form Parser が事前トレーニング済みでアップトレーニングできないこと。チェックボックスが最も近い文字をキーにしたキーと値のペアとして取り出され、valueType でオン・オフが示されること。ラジオボタンに対応せず、一部のチェックボックスにはキーが無い場合があること。ラテン文字以外の言語ではキーと値のペアの品質が下がる場合があること。TIFF の古い JPEG 圧縮に対応しないことGoogle Cloud: Form Parser2026-10-15
排出事業者が産業廃棄物の運搬・処分を委託するとき、引き渡しと同時に、産業廃棄物の種類及び数量などを記載した管理票を交付しなければならないことe-Gov 法令API: 廃棄物の処理及び清掃に関する法律2026-10-15
ページごとの formFields に名前と値(キーと値のペア)が、tables に表が入ること。チェックボックスの valueType がオンなら filled_checkbox、オフなら unfilled_checkbox であることGoogle Cloud: Handle the processing response2026-10-15
管理票の記載事項(交付年月日・交付番号、荷姿など)。処分受託者が処分を終了した日から10日以内に写しを送付することe-Gov 法令API: 廃棄物の処理及び清掃に関する法律施行規則2026-10-15

マニフェストの数量と計量の重さの差をどう扱うか、品目ごとの許容をどう決めるかは、自社の受入の決まりと排出事業者との取り決めで決めてください。 本記事は公式ページと法令で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1625)についてのご相談はこちらから。

AI活用について相談する
目次