Media > AI活用ユースケース > 購買 > 中古バイクの買取店が査定士の手書きの査定シートを読み取り、車台番号・走行距離・減点の項目を、古物の帳簿の記載事項をそろえた査定の台帳と買取の明細にする

中古バイクの買取店が査定士の手書きの査定シートを読み取り、車台番号・走行距離・減点の項目を、古物の帳簿の記載事項をそろえた査定の台帳と買取の明細にする

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

査定士が手書きした中古バイクの査定シートと車両の書類の写しを読み取り、査定の台帳と買取の明細の下書きにします。車台番号の食い違い、古物の帳簿の記載事項の欠け、減点の合計の計算違いを、その日のうちに店長へ返します。

サマリー
生成AI
ChatGPT/Claude/Gemini
AIサービス
AWS Textract/Azure AI/Google Document AI
連携・自動化
Google Apps Script/Python
対象業界
EC/その他/小売
対象部門
購買
対象業務
データ入力・転記/台帳・マスタ管理
主な課題
人手が足りない/入力作業が多い/確認ミスが多い
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/品質標準化/工数削減
導入難易度
★★☆☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
60h/月
AI導入後
20h/月
想定削減
67%
年間削減
480h
モデル条件による試算値です。実在企業の実績ではありません。

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

導入前(Before)
  1. 査定士が査定シートを書き、買取が決まったら車両の書類の写しと一緒に店のトレーに入れる
  2. 店のスタッフが買取申込書の内容を、店の端末で顧客の記録に入れる
  3. 閉店後、査定シートと書類の写しを本部へ送る(翌日の便で届く)
  4. 本部の事務が、査定シートから車名・車台番号・走行距離・減点・査定額を査定の台帳に打ち直す
  5. 書類の写しの車台番号と、査定シートの車台番号を目で見比べる
  6. 帳簿の行に取引の年月日・品目・特徴・確認の措置の区分を入れ、顧客の記録と結び付ける
  7. 買取の明細を作り、会計の仕組みへ回す
導入後(After)
  1. 人査定士が査定シートを書き、査定額を決める(ここは変えない)
  2. 人買取が決まったら、店のスタッフが査定シートと書類の写しを店の複合機でスキャンし、受付番号の名前で受付フォルダに保存する
  3. 自動毎時0分に Python の処理が動き、新しい査定シートと書類の写しを Document AI で読み取る
  4. 自動査定シートと書類の車台番号・原動機の番号を1文字ずつ比べる
  5. 自動減点の表を足し上げて、書かれた合計と比べる
  6. 自動生成AIが付属品・部品の欄と所見を、帳簿の品目と数量に分ける
  7. 自動受付番号で顧客の記録を引き、帳簿の記載事項がそろっているかを確かめる
  8. 自動査定の台帳と帳簿に下書きの行を足し、買取の明細の下書きを作る
  9. 自動確認の要るものを、店ごとに店長へメールで返す
  10. 人店長が現車か打刻の写真と書類で確かめ、査定士に書き足してもらう
  11. 人本部の事務が下書きの行を確かめて確定し、買取の明細を会計の仕組みへ回す
各工程の詳しい説明を読む
  1. 査定士が査定シートを書き、買取が決まったら車両の書類の写しと一緒に店のトレーに入れる
  2. 店のスタッフが買取申込書の内容を、店の端末で顧客の記録に入れる
  3. 閉店後、査定シートと書類の写しを本部へ送る(翌日の便で届く)
  4. 本部の事務が、査定シートから車名・車台番号・走行距離・減点・査定額を査定の台帳に打ち直す
  5. 書類の写しの車台番号と、査定シートの車台番号を目で見比べる
  6. 帳簿の行に取引の年月日・品目・特徴・確認の措置の区分を入れ、顧客の記録と結び付ける
  7. 買取の明細を作り、会計の仕組みへ回す

(a)打ち直しが追いつかない。 週末に買取が集中し、月曜と火曜に査定シートが100枚以上届きます。 台帳が数日遅れ、店から「先週の車両はもう台帳にあるか」と聞かれても答えられません。

(b)車台番号の写し違いに気づかない。 車台番号は英字と数字の並びで、査定士が現車の打刻から写し、事務がそれを台帳に写します。「0」と「O」、「1」と「I」、「8」と「B」の取り違えは、2回写すうちのどこかで起きます。 5番の見比べが省かれた日の取り違えは、販売のときまで見つかりません。

(c)部品の買取の記録が欠ける。 車両の査定シートは丁寧に書かれますが、部品だけの買取は、査定シートの品目の欄が「マフラー等」で終わっていることがあります。 帳簿の品目と数量、特徴として足りるかを、事務が判断できずに店に聞き直します。

(d)打刻の確認の跡が残らない。 査定士は車台番号の打刻部分を見ていますが、見たことがチェック欄に残っていない査定シートがあります。 古物営業法施行規則第14条は、自動二輪車を扱う営業所の管理者に、車台番号打刻部分等の改造等の有無を判定するための知識等を求めています。見たかどうかが記録に無いと、後から確かめられません。

  1. 【人】 査定士が査定シートを書き、査定額を決める(ここは変えない)
  2. 【人】 買取が決まったら、店のスタッフが査定シートと書類の写しを店の複合機でスキャンし、受付番号の名前で受付フォルダに保存する
  3. 【自動】 毎時0分に Python の処理が動き、新しい査定シートと書類の写しを Document AI で読み取る
  4. 【自動】 査定シートと書類の車台番号・原動機の番号を1文字ずつ比べる
  5. 【自動】 減点の表を足し上げて、書かれた合計と比べる
  6. 【自動】 生成AIが付属品・部品の欄と所見を、帳簿の品目と数量に分ける
  7. 【自動】 受付番号で顧客の記録を引き、帳簿の記載事項がそろっているかを確かめる
  8. 【自動】 査定の台帳と帳簿に下書きの行を足し、買取の明細の下書きを作る
  9. 【自動】 確認の要るものを、店ごとに店長へメールで返す
  10. 【人】 店長が現車か打刻の写真と書類で確かめ、査定士に書き足してもらう
  11. 【人】 本部の事務が下書きの行を確かめて確定し、買取の明細を会計の仕組みへ回す

1番目を変えないことが前提です。 査定額と減点は、仕組みの結果を待たずに店頭で決まっています。仕組みは、決まった後の紙を台帳に移し、欠けと食い違いを返すだけです。

10番目を店に置くのは、現車が店にあるうちに確かめるためです。 車台番号の食い違いは、本部の事務が紙を見ても決められません。車両が整備や出品で動く前に、店長が打刻を見直します。

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

構成図
査定シート(手書き) + 車両の書類の写し
   │  店のスタッフが買取の決まった時点でスキャン(受付番号で保存)
   ▼【トリガー】受付フォルダ(毎時0分に処理)
Python(取り込みの処理)
   ├──▶ 受付番号、ページの数、重複の確認
   ▼
Google Document AI(Form Parser)
   │   上の欄・車両の欄(キーと値)、減点の表、打刻の確認(✓/☐)、所見の文字
   ▼
Python ── 車台番号の照合、減点の合計、帳簿の記載事項、顧客の記録との結び付け
   ▼
Claude API(構造化出力)── 付属品・部品の品目と数量への分け方(判断はしない)
   ▼
査定の台帳と帳簿の下書きの行 / 買取の明細の下書き / 店長への確認の一覧
   ▼
【店長が現車と書類で確かめる】 / 【本部の事務が確定する】
役割想定する製品代替候補
OCRGoogle Document AI(Form Parser)Azure AI Document Intelligence(レイアウト モデル)、AWS Textract(英文の書類に限る。日本語の査定シートには使えない)
生成AIClaude API(付属品・部品の品目と数量への分け方。構造化出力)OpenAI API、Gemini API
連携Python(読み取りの呼び出し、顧客の記録との結び付け、メール)Google Apps Script
差異計算Python(車台番号の1文字ずつの照合、減点の合計の計算)Google Apps Script
保管本部のファイルサーバー(査定シートと書類の画像、台帳と帳簿)Google ドライブ

台帳と帳簿は、いま使っているものです。 足すのは「下書き」と「確定」の状態の列と、確認の印の列です。新しく使い始めるのは Document AI の Form Parser と Claude API だけです。

土台は Document AI の Form Parser です。 公式の説明では、Form Parser はキーと値のペア、表、チェックボックスなどの選択の印を取り出し、学習済みで追加の学習はできないとされています。公式のプロセッサ一覧では、日本語(ja)は手書きに対応する言語です。

処理する場所に、日本のリージョンはありません。 対応リージョンは us・eu と、シンガポール(asia-southeast1)などです。査定シートにはお客様の個人の情報を書かない様式にします。 ただし車両の書類の写しには所有者の氏名や住所が載りうるので、国外で処理されることを自社の個人情報の取り扱いの決まりに照らして確かめます。確かめられないうちは書類の写しを読み取りに回さず、車台番号の見比べを人に残します。

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

Step1

処理の起点を決める

毎時0分に、受付フォルダに新しく保存された査定シートと書類の写しをまとめて処理します。 買取は1日を通じて少しずつ決まるので、1日1回にすると、夕方に決まった車両の確認が翌日に回ります。 毎時にすれば、店長は車両が店にあるうちに確認の一覧を受け取れます。

保存は、買取が決まった時点で店のスタッフが行います。閉店後にまとめて本部へ送る運用はやめます。 ファイル名は受付番号と種類(査定/書類)にし、同じ受付番号の2つのファイルを1件として扱います。 書類の写しが30分たっても届かない受付番号は、次の回まで待ってから「書類なし」の印を付けます。

処理が終わったファイルは、日付ごとのフォルダへ移します。移すのは、台帳と帳簿に下書きの行を足すまで成功したときだけです。 受付フォルダに残っているファイルが、そのまま未処理です。

Step2

入力データを集める

データ中身取得元
査定シートの画像受付番号、店舗、査定日、査定士、車名・型式・排気量・年式・色、車台番号、原動機の番号、走行距離、部位ごとの減点と合計、付属品と部品、打刻の確認、所見、査定額受付フォルダ
車両の書類の写し車台番号、型式など書類に載る車両の情報受付フォルダ
読み取り結果キーと値のペア、表の行とセル、チェックの状態、文字の位置Document AI
顧客の記録受付番号、相手方の住所・氏名・職業・年齢、確認の措置の区分と方法店の端末で入れた記録
品目の一覧帳簿に書く品目の名前(車両、マフラー、ホイールなど)と数え方本部が作る表

質を決めるのは、顧客の記録との結び付けです。 帳簿の記載事項のうち、相手方と確認の措置の区分は査定シートに無く、店のスタッフが端末で入れた記録にしかありません。 受付番号で引けなければ、帳簿の行はそろいません。

品目の一覧は、部品の書き方をそろえるために使います。 「マフラー等」のような書き方を、一覧のどの品目に当たり、いくつあるのかに分けます。一覧に無い品目は、新しく足すかを本部が決めます。

顧客の記録は、生成AIにも Document AI にも渡しません。 結び付けは Python の側で受付番号を使って行います。

Step3

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

読み取りは、Python から Document AI の REST の process のメソッドを呼びます。公式の説明では、リクエストの本文の rawDocument に MIME タイプと base64 にした画像を入れて送ります。査定シートと書類の写しは、別々に1回ずつ呼びます。

取るものどこから何に使うか
受付番号・査定日・査定士pages[].formFields顧客の記録を引く、取引の年月日
車名・型式・色・車台番号・原動機の番号・走行距離pages[].formFields台帳と帳簿の特徴、照合
部位ごとの減点pages[].tables[] の bodyRows のセル合計の計算
打刻の確認表の外のチェックボックスのキーと値確認の跡
付属品と部品・所見キーと値、または文書の text の範囲プロンプトに渡す
書類の車台番号書類の写しの pages[].formFields照合

チェック欄は、表の外のものは値が filled_checkbox か unfilled_checkbox で返ります。 公式の説明のとおりで、表の中のチェックボックスは ✓ や ☐ の文字でセルに入ります。打刻の確認は表の外に「確認した」「要確認」の2つの□で置きます。 公式の説明では、チェックボックスのモデルはラジオボタンに対応していません。

減点の表は、セルを結合しない様式にします。 公式の説明では、Form Parser の表の取り出しは行や列をまたぐセルの無い単純な表が対象です。「外装」の見出しで5行をまとめたセルがあれば、部位の名前を各行に書き込む形に直します。

車台番号の欄は、1文字ずつの枠にします。 1文字1枠にすると、査定士の字が詰まらず、何文字目が読めなかったかを枠の位置で示せます。 値の入っていないキーと値のペアは確実には読めないとされているので、車台番号のキーが結果に無いことは「空」として扱います。

Step4

AIへ渡す前に整形する

  1. 受付番号の確認 … ファイル名と査定シートの受付番号が合わなければ、check にします
  2. 2つのファイルのそろいの確認 … 査定と書類の片方しか無ければ、30分待ってから「書類なし」の印を付けます。部品だけの買取は書類が無いので、品目の欄から車両の有無を見て扱いを分けます
  3. ページの数の確認 … 1ファイル1枚を基本にし、書類が両面なら2ページまでとします。公式のプロセッサ一覧では、同期の処理は1回15ページまでです
  4. 文字の正規化 … 車台番号と原動機の番号は、全角を半角に、小文字を大文字にそろえます。ここで「O」を「0」に置き換えるような直しはしません
  5. 走行距離の確認 … 数字として読めない、桁が多すぎる、単位が書かれていないものは check にします
  6. 重複の検知 … 同じ車台番号の買取が直近にあれば、二重の保存か、同じ車両の再度の買取かを check にします

4番目で直しをしないことが大事です。 「O」と「0」の取り違えを規則で直すと、直した結果がたまたま書類と合い、写し違いが消えます。 取り違えの候補は照合のときに印として示すだけにし、どちらが正しいかは店長が打刻で確かめます。

Step5

AIに処理させる

照合と計算は、Python の規則で行います。 生成AIには、付属品・部品の欄と所見を、帳簿の品目と数量に分ける仕事だけを渡します。

規則で見るもの印を付ける条件
車台番号査定シートと書類で1文字でも違う。違う文字が「0/O」「1/I」「8/B」などの組なら、その旨を添える
原動機の番号欄が空、または書類に載っていて食い違う
減点の合計部位ごとの減点を足した値と、書かれた合計が違う
減点の欄部位の行に数字も「なし」も無い
打刻の確認「確認した」「要確認」のどちらにも ✓ が無い、または「要確認」に ✓
走行距離読めない、または前処理で印が付いた
帳簿の記載事項取引の年月日・品目と数量・特徴・相手方・確認の措置の区分のどれかが空
査定額空、または数字として読めない

「要確認」に ✓ があるものは、店長だけでなく、営業所の管理者に回します。 打刻部分の改造等の有無を判定する知識を求められているのは管理者です。不正品の疑いがあるかを決め、警察官に申告するかを決めるのも人です。 古物営業法第15条第3項は、不正品の疑いがあると認めるときは直ちに警察官に申告しなければならないとしています。

生成AIに分けさせること中身
品目品目の一覧のどれに当たるか。当たらなければ unlisted
数量書かれた数。数が書かれていなければ null
特徴メーカー名、型番、色など、書かれている特徴の語
車両との関係車両に付いたまま買い取ったか、部品だけの買取か

部品の特徴は、書かれている語だけを拾わせます。 帳簿の「古物の特徴」として足りるかは、本部の事務が判断します。生成AIに「足りる」「足りない」を言わせると、その判断が帳簿の記録に混ざります。

させないこと理由
査定額や減点の判断査定士が決めている
不正品の疑いの判断管理者が決め、申告も人が行う
車台番号の文字の直し写し違いを消す
書かれていない数量の補完「マフラー等」を1本と決めない
修復歴や改造の判断査定士と店長が現車で決める

4行目が起きやすい失敗です。 「マフラー等」と書かれた部品の買取を、生成AIは1本と読みたがります。数量が書かれていなければ null のまま返させ、店に聞きます。 帳簿に数を書くのは、数えた人の答えです。

Step6

指示内容を固定する

あなたは中古バイクの買取店の本部で、仕入の記録を整える補助です。
査定シートの「付属品・部品」欄と「所見」欄の文を、帳簿の品目と数量に分けてください。
渡すのは OCR が読み取った欄の文字と、品目の一覧だけです。

【品目の一覧】{item_list}

【出力の決まり】
- 1つの品目ごとに1件にしてください。
- item には品目の一覧の名前をそのまま入れてください。
  当たるものが無ければ "unlisted" とし、原文を evidence に写してください。
- quantity には書かれた数だけを入れてください。数が書かれていなければ null です。
  「等」「一式」「セット」と書かれていても、数を決めないでください。
- features には、メーカー名・型番・色など、書かれている語だけを入れてください。
- attached は、車両に付いたまま買い取ったと書かれていれば true、
  部品だけの買取と書かれていれば false、どちらとも書かれていなければ null です。

【厳守事項】
- 査定額、減点、修復歴、改造について判断しないでください。
- 盗品や不正品の疑いについて、何も書かないでください。
- 車台番号や型番の文字を直さないでください。読めない文字は「?」のまま残してください。
- 書かれていないことを補わないでください。
- evidence には、根拠にした原文の部分をそのまま写してください。

【付属品・部品】{parts_text}
【所見】{remarks}

「盗品や不正品の疑いについて、何も書かない」を明記しないと、所見の「打刻やや不鮮明」に「要注意」と添えます。 その一言が帳簿の下書きに入ると、疑いの判断を仕組みがしたことになります。判断の根拠は、管理者が現車を見た記録だけに置きます。

構造化出力で、答えの形を固定します。 公式の説明では、Claude API の構造化出力は output_config.format に type: "json_schema" でスキーマを渡し、オブジェクトには additionalProperties: false が要ります。quantity は整数か null にします。数値の範囲の制約には対応していないので、数量の妥当さは Python の側で見ます。

Step7

出力形式を固定する

{
  "items": [
    { "item": "マフラー", "quantity": null, "features": ["社外品", "ステンレス"],
      "attached": false, "evidence": "マフラー等 社外 ステン" },
    { "item": "unlisted", "quantity": 1, "features": [],
      "attached": true, "evidence": "リアキャリア1" }
  ]
}

Python は、この JSON と照合・計算の結果を合わせて、査定の台帳と帳簿に下書きの行を足し、買取の明細の下書きを作ります。

帳簿・台帳の列入る値出どころ
取引の年月日査定日読み取り
品目と数量車両、または部品の品目と数読み取り+プロンプト
特徴車名・型式・色・車台番号・原動機の番号、部品の特徴の語読み取り+プロンプト
相手方・確認の措置の区分顧客の記録の値顧客の記録
走行距離・減点・査定額書かれた値をそのまま読み取り
確認の印印の理由Python
状態下書き/保留/確定本部の事務・管理者

買取の明細の下書きには、査定額を書かれたとおりに入れます。 明細の金額を仕組みが計算し直すことはしません。減点の合計に印が付いているものは、明細の下書きを作らずに止めます。

Step8

システムへ連携する

つなぎ先方式内容
受付フォルダPython が毎時0分に読む査定シートと書類の写しを集める
Document AIREST の process読み取り
顧客の記録受付番号での読み取り相手方と確認の措置の区分
Claude APIREST品目と数量への分け方
査定の台帳・帳簿ファイルへの行の追加(下書き)取引ごとに1行
店長・管理者メール店ごとの確認の一覧
会計の仕組み既存の取り込み確定した買取の明細だけを回す

会計の仕組みへは、本部の事務が確定したものだけを回します。 下書きの行のまま回すと、車台番号の食い違いが残った車両の支払が確定します。 状態の列が「確定」になった行だけを取り込みの対象にします。

顧客の記録は読むだけにします。 相手方の情報が欠けていても、仕組みは書き足しません。店のスタッフが端末で直し、次の回の処理で結び付け直します。

Step9

人が確認する

店長は、毎時届く店ごとの一覧のうち、自分の店の分だけを見ます。

  1. 「要確認」の打刻と車台番号の食い違いを先に見る … 車両が店にあるうちに打刻を見直し、「要確認」は管理者に回します
  2. 減点の合計の違いを見る … 査定士に、足し違いか書き違いかを確かめてもらいます。査定額を変えるかは査定士と店長が決めます
  3. 部品の数量と品目の空きを見る … 査定士に数を書き足してもらいます
  4. 帳簿の記載事項の空きを見る … 顧客の記録の入れ忘れを、店のスタッフが直します

管理者に回ったものは、別の一覧で追います。 「要確認」の車両は、管理者が打刻部分を見て結果を書くまで、台帳の状態を「保留」にし、整備や出品に回しません。 管理者が見た日時と所見は、査定シートとは別の記録に残します。

書き足しは、査定シートに直接書いてスキャンし直します。 書き足した日と人を余白に書いてもらい、元の査定シートの画像も残します。 後から書いたことが分かる形にします。

本部の事務は、印の消えた下書きの行を確かめて確定します。 印の付かなかった行は一覧で流し見て、車台番号の行だけは画像と並べて目で見ます。 照合が合っていても、査定シートと書類の両方が同じ誤りをしていることはありうるからです。

目標は、600件をならして1件2分です。 店長の一覧に載るものが2割前後という想定で、それより多い月は、査定シートの様式か、書類のスキャンの濃さを見直します。

Step10

例外に対処する

起きること対応
書類の写しが届かない30分待って「書類なし」。部品だけの買取でなければ店に聞く
車台番号が1文字だけ読めない「?」のまま照合し、check。店長が打刻で確かめる
書類と査定シートで型式が違う書き違いか、別の車両の書類。台帳に入れずに check
「要確認」に ✓管理者へ回す。不正品の疑いの判断と申告は人が行う
受付番号で顧客の記録が引けない入れ忘れか番号の読み違い。店のスタッフが確かめる
同じ車台番号の買取が直近にある二重の保存か、再度の買取か。本部が確かめる
部品の品目が一覧に無いunlisted のまま。本部が一覧に足すかを決める
買取の後に取り消した店長が取消の印を付け、帳簿の下書きを止める
Document AI が応答しない受付フォルダに残し、次の回で再び読む

2行目の「1文字だけ読めない」を、照合の合った文字で埋めないでください。 読めない1文字を書類の文字で埋めると、必ず照合が合います。 それでは照合をした意味が無くなります。

8行目の取消も、帳簿の下書きから消さずに残します。 買い取らなかった車両は古物を受け取っていないので帳簿の記載は要りませんが、取消の印の付いた行が残っていれば、査定シートが1枚多い理由を後から説明できます。 消してしまうと、スキャンされた査定シートの画像だけが行き場を失います。

Step11

記録を残す

  • 査定シートと書類の写しの画像と、スキャンした日時・店舗・スキャンした人
  • Document AI が返した JSON の全文と、使ったプロセッサの版
  • 照合と計算の結果、生成AIの品目の分け方、そのとき参照した品目の一覧
  • 人が直した記録 … どの値を、誰が、何から何に、なぜ直したか
  • 店長と管理者が打刻を確かめた記録と、その判断
  • 下書きから確定にした人と日時

帳簿は3年間の保存が要ります。 古物営業法第18条は、帳簿等を最終の記載をした日から3年間営業所に備え付けるか、電磁的方法による記録を3年間、直ちに書面に表示できるようにして保存することを求めています。台帳と帳簿の行から、元の査定シートの画像と直した記録まで、3年間たどれるようにします。

04実装レベルの3段階

最小構成:画像を手でAIの画面に貼り、車台番号の照合と部品の分け方をさせる / 1件ごとの照合
半自動化:上記+Form Parser の API で読み、顧客の記録と結び付け、台帳と帳簿に下書きの行を足し、店長へ確認の一覧を送る / 取り込み、照合、帳簿の記載事項の確かめ、明細の下書き
本格構成:上記+査定士がタブレットで査定シートの写真を撮り、店頭で照合の結果を見てから買取を確定する / 照合を買取の確定の前に移す

半自動化で、1件6分が2分になります。この段階が本記事の想定です。 打ち直しと見比べが無くなり、本部の事務は印の消えた行を確定するだけになります。 本格構成は、照合を買取の前に移します。 車台番号の食い違いが買取の前に分かれば、その場でお客様と書類を確かめられます。 ただし店頭の流れを変えるので、店のスタッフの操作が増えます。半自動化の一覧で食い違いが月に何件出るかを見てから決めます。

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

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

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

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

AI活用について相談する

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

向いている
  1. 数店舗で中古の自動二輪車・原動機付自転車と部品を店頭で買い取り、査定士が紙の査定シートに書いたものを本部の事務が査定の台帳と古物の帳簿に打ち直している買取店。車台番号の写し違いや、帳簿の記載事項の欠けに後から気づくことがある場合。マフラーやホイールなど部品だけの買取も多く、金額の小さい取引の記録がそろっていない場合。バイクの販売店が下取りで同じ記録を作る場合にも同じ業務がある。
向いていない
  1. 査定士がすでにタブレットの査定の画面に入力し、台帳と帳簿が自動で作られている店。買取が月に数台で、打ち直しが負担になっていない場合。なお、査定額の決定、修復歴や改造の判断、不正品の疑いの判断と警察への申告は、この構成では代替できません。

07最小構成で試す方法

  1. 先月の買取から30件を選ぶ(車台番号の写し違いが見つかったものと、部品だけの買取を入れる)
  2. その30件について、当時どこで誤りに気づいたかを本部の事務に聞く
  3. 査定シートと書類の写しの画像を、手元のAIサービスの画面に1件ずつ貼り付ける
  4. 「2つの画像の車台番号を1文字ずつ書き出し、違う文字を示してください。文字を直さないでください。付属品と部品を品目と数量に分け、数が書かれていなければ空にしてください」と指示する
  5. 出てきた結果を、当時の台帳と突き合わせる

30件は必ずやってください。 組む前に、「手書きの車台番号を1文字ずつ読めるか」を確かめます。

出てきた内容判断
当時の写し違いが食い違いとして出たForm Parser と台帳の連携に進む
読めない文字を書類の文字で埋めた指示の書き方で直る。構成は有効
車台番号の欄の文字がつぶれて読めない様式が先。 1文字1枠の欄に直す

3行目は失敗ではありません。 査定士の字の問題ではなく、狭い欄に17文字前後を詰めて書かせている様式の問題です。

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

問題対策
「O」と「0」を規則で直す直さない。 候補を示すだけにし、打刻で確かめる
読めない1文字を書類の文字で埋める「?」のまま照合する
「マフラー等」を1本として帳簿に入れる数量は書かれた数だけ。無ければ店に聞く
生成AIが「要注意」を書く不正品の疑いに触れることを禁じる
減点の表の行がずれる結合したセルをやめ、部位の名前を各行に書く
打刻の確認の欄が丸を付ける形ラジオボタンは読めない。□の2つの欄にする
受付番号が付いていない顧客の記録と結び付かない。スキャンの手順に入れる
下書きの行が会計に回る確定した行だけを回す
書類の写しの国外での処理を確かめていない確かめるまで書類を読み取りに回さない

上の4行が、この構成の失敗のほとんどです。 どれも、仕組みが「それらしく埋める」ことで記録の欠けや食い違いが消える形をしています。帳簿は3年間残る記録で、埋めた値はそのまま残ります。

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

この構成で扱うデータ: 車両の情報(車台番号、原動機の番号、走行距離)、査定の結果と金額、車両の書類の写し、そして顧客の記録の相手方の情報です。

  1. お客様の個人の情報を読み取りに回さない様式にする … 査定シートには受付番号だけを書き、相手方の情報は店の端末で入れた記録から Python の側で結び付けます
  2. 書類の写しの国外での処理を確かめる … Form Parser の対応リージョンに日本はありません。書類の写しには所有者の氏名や住所が載りうるので、確かめるまでは読み取りに回しません
  3. 不正品の疑いの判断を仕組みに置かない … 古物営業法第15条第3項の申告は、疑いがあると認めた人が行うものです。仕組みは「要確認」の印を管理者に届けるだけにします
  4. 帳簿の記録を直したら跡を残す … 下書きから確定まで、誰が何を直したかを残し、3年間たどれるようにします
  5. 生成AIには部品の欄と所見の文字だけを渡す … 車台番号も相手方の情報も渡しません

誤りが起きた場合のリスクは、車台番号の写し違いを残したまま販売することと、帳簿の記載事項を欠いたまま残すことの2つです。 どちらも、仕組みが埋めずに印を付け、人が現車と顧客の記録で確かめることで防ぎます。

10まず何から始めるか

1週目:様式と受付番号を決める

査定シートの車台番号の欄を1文字1枠に、減点の表を結合の無い形に、打刻の確認を□の2つの欄に直します。お客様の名前と住所を書く欄を査定シートから外し、受付番号を査定シート・書類・顧客の記録で共通にします。

2週目:30件で試す

先月の買取から30件を選び、手元のAIサービスで車台番号の照合と部品の分け方をさせます。読めない文字を埋めていないかを最優先で見ます。

3週目:品目の一覧と、国外での処理の確認

部品の品目の一覧を作ります。あわせて、書類の写しを Form Parser に回してよいかを、自社の個人情報の取り扱いの決まりに照らして確かめます。

4週目:受付フォルダから下書きの行までをつなぐ

Python で受付フォルダを読み、Form Parser を呼び、台帳と帳簿に下書きの行を足すところまで作ります。この時点では店長への一覧を送らず、本部の事務がいまの見比べと並べて結果を見ます。

2か月目: 店長への確認の一覧を1店舗で送り始めます。3か月目以降: 4店舗に広げ、1件6分が何分になったかを実測します。車台番号の食い違いが買取の当日のうちに店で確かめられるようになった時点で、この構成は運用に乗ったと言えます。


11関連ユースケース

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

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

技術仕様確認日:2026-10-27/最終更新:2026-10-27
確認した内容情報源確認日
Form Parser がキーと値のペア・表・チェックボックス・一般的な項目を取り出すこと。日本語(ja)が手書きに対応する言語とされていること。同期の処理が15ページまでであること。対応リージョンが us・eu・asia-southeast1 などで、日本が含まれないことGoogle Cloud: Processor list2026-10-27
Form Parser が学習済みで追加の学習ができないこと。表の取り出しが行や列をまたぐセルの無い単純な表に限られること。チェックボックスのモデルがラジオボタンに対応しないこと。値の入っていないキーと値のペアを確実には読めないことGoogle Cloud: Form Parser2026-10-27
表が bodyRows などで表されること。表の中のチェックボックスが ✓/☐ の文字で返り、表の外のチェックボックスの値が filled_checkbox/unfilled_checkbox になることGoogle Cloud: Handle the processing response2026-10-27
:process に、rawDocument の MIME タイプと base64 の内容を送ることGoogle Cloud: Send a processing request2026-10-27
Claude API の構造化出力が output_config.format に type: "json_schema" で指定すること。オブジェクトに additionalProperties: false が要ること。数値の範囲の制約に対応していないことClaude Platform Docs: Structured outputs2026-10-27
古物を買い受けるときに相手方の真偽を確認する措置をとること、不正品の疑いがあると認めるときは直ちに警察官に申告すること(第15条)。取引の年月日、品目及び数量、特徴、相手方の住所・氏名・職業・年齢、確認の措置の区分を帳簿等に記載すること(第16条)。帳簿等を3年間保存すること(第18条)e-Gov 法令API: 古物営業法2026-10-27
古物の区分に自動二輪車及び原動機付自転車(部分品を含む)があること(第2条)。自動二輪車等を扱う営業所の管理者に車台番号打刻部分等の改造等の有無を判定する知識等が求められること(第14条)。確認を要しない金額が1万円で、自動二輪車・原動機付自転車とその部分品は除かれること(第16条)。自動二輪車等は帳簿の記載を免除されないこと(第18条)e-Gov 法令API: 古物営業法施行規則2026-10-27

相手方の確認の方法、帳簿の様式、不正品の疑いがあるときの扱いは、営業所を管轄する警察署と自社の管理者の判断で確かめてください。 本記事は上の公式の情報で確認できた範囲だけを扱っています。

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

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

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

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