自動車整備工場が受付で手書きする整備の依頼書を Azure AI Document Intelligence で読み、車両・依頼内容・預かり日と納車の予定を工程表に転記して、書き漏れと署名の欠けを拾う

処理の起点を決める

フロントが依頼書の1枚目をスキャナーに通し、PDF が Blob Storage の受付のコンテナーに保存されたことを起点にします。 スキャナーの保存先を受付のコンテナーにつながるフォルダにし、1台につき1つの PDFにします。保存されると Azure Functions の処理が動きます。

スキャンするのは、お客様を見送る前です。 受付の脇のスキャナーに通すだけで、フロントの手間は数秒です。読み取りと照合が終わると、受付の画面に確認の一覧が出ます。 署名の欠けや納車の希望の書き漏れがあれば、その場でお客様に聞けます。

処理が終わった PDF は処理済みのコンテナーへ移します。移すのは、読み取りと照合と下書きの作成が終わったときだけにします。 受付のコンテナーに残っている数が、そのまま未処理の数になります。閉店の前には、預かった車の数と処理した依頼書の数を比べ、スキャンの漏れを拾います。

入力データを集める

質を決めるのは、作業の区分の表です。 「車検」に印があれば何時間、「オイル交換」なら何分、リフトが要るか、板金のブースが要るか。この表が無いと、工程表の下書きの行に時間を入れられません。表の時間は工場長の目安で構いません。 下書きを見た工場長が直す前提です。

車両の台帳は、照合のために読むだけです。 前回の走行距離と車検の満了日は、読み取った値が正しいかを確かめる物差しとして使います。

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

読み取りは、Azure Functions から Document Intelligence の REST API でカスタム ニューラル モデルを呼びます。API のバージョンは 2024-11-30（v4.0 の GA）に固定します。 署名の検出も、表・行・セルの信頼度も、このバージョンからとされています。

選択マークの信頼度は、フィールドの信頼度と合わせて見ます。 公式の説明では、選択マークを含むフィールドでは、フィールドの選択と選択マークの信頼度を合わせたものが、全体の確からしさをよく表すとされています。チェック欄の印が薄いと、フィールドの位置は合っていても印の状態の信頼度が下がります。

症状の自由欄は、領域のラベルで取ります。 公式の説明では、ニューラル モデルの領域のラベルは、指定した領域についてのレイアウトの読み取りの結果を使うとされています。自由欄のどこに書かれていても、欄の中の文字をまとめて取れます。

車両の台帳は、整備管理システムの毎晩の書き出しを Python で読みます。照合の順は、登録番号が先、車名が後です。 車名から先に引くと、同じ車名の車が何十台も出ます。

AIへ渡す前に整形する

1. ページの確認 … 1枚目（工場の控え）であることを、様式の見出しの読み取りで確かめます。2枚目・3枚目を誤ってスキャンしたものは、複写の写りが薄いので読み直しを頼みます
2. 解像度の確認 … 取り出す文字の高さの下限は、1024×768の画像で12ピクセル（150dpiで約8ポイントの文字）とされています。複写の1枚目でも筆圧が弱いと細くなるので、300dpiに固定します
3. 画像の寸法とサイズの確認 … 画像は50×50から10,000×10,000ピクセル、ファイルは有料（S0）のレベルで500MBまでとされています
4. 重複の確認 … 同じ登録番号・同じ預かり日の依頼書が既にあれば、上書きせずにフロントに確かめます。 書き直した依頼書を二度スキャンした場合があります
5. 拠点の確認 … スキャナーごとに拠点を決めておき、読み取った依頼書の様式と拠点が合うかを見ます

1番目を省かないでください。 3枚複写の2枚目・3枚目は、1枚目より文字が薄く、読み取りの信頼度がまとまって下がります。 誤ってスキャンされると、確認の一覧が印だらけになります。

AIに処理させる

させるのは、依頼書の決まった項目・チェック欄・自由欄・署名の欄を読み取り、信頼度を返すことだけです。 台帳との照合と空欄の検出は、Python が規則で行います。

Python が行う照合は、次の4つです。

車名の照合を必ず入れてください。 登録番号の一連番号を1桁読み違えると、台帳に別の車が見つかることがあります。そのとき番号だけで照合すると ok になり、第3章の（b）がそのまま起きます。 車名が合うかを二重に見ることで、別の車を開くのを防ぎます。

作業の区分と標準の時間は、チェック欄から表で引きます。 「一般修理」と「板金」は症状によって時間が大きく変わるので、標準の時間を入れず、工場長が決める枠として下書きに出します。

指示内容を固定する

この構成では生成AIを使わないため、プロンプトの代わりにニューラル モデルの学習の指示と、ラベル付けの決まりを示します。

【見本の集め方】
- 2拠点の現行の様式と、旧様式の依頼書を、実際の受付で書かれたものから集める
- 様式の違いごとに、ラベル付けした見本を5枚以上（できれば各20枚程度）
- 署名のフィールドには、署名がある見本を5枚以上含める
- 次のばらつきを入れる
  ・フロント3名それぞれの筆跡
  ・症状の欄が空欄のもの、欄の外まで書き込んだもの
  ・代車の要否・署名の欄が空いているもの
  ・チェック欄を二重線で消して付け直したもの
- スキャンの設定は本番と同じ300dpiにそろえる

【ラベルの決まり】
- フィールドの名前は依頼書の言葉で付ける
  （登録番号、走行距離、預かり日、納車希望、代車、症状、お客様署名）
- 依頼内容の6つのチェック欄は、それぞれ別の選択マークのフィールドにする
- 症状は自由欄の枠を領域として囲む（文字を選んで囲まない）
- お客様署名は、フィールドの種類を署名にし、欄の領域を1つだけ囲む
- 空欄の見本も、空欄のままラベルを付けて学習させる

【学習】
- 学習のモード（buildMode）は neural
- 学習の時間の上限（maxTrainingHours）を決めて実行する
- ニューラル モデルは学習のときに推定の正確さを返さないので、
  学習に使わなかった30枚で正解と突き合わせて評価する

「フィールドの名前は依頼書の言葉で付ける」は、公式の勧めに従ったものです。 公式の説明では、値に関係する名前を付けると取り出しの正確さが上がり、フィールドの名前は文書の言語で付けるのがよいとされています。

「署名のある見本を5枚以上」も公式の説明に沿っています。 署名の検出で正確な結果を得るには、署名にラベルを付けた見本が少なくとも5枚、ばらつきを含めて要るとされています。

最後の3行が、ニューラル モデルを使うときの注意です。 公式の説明では、ニューラル モデルは学習のときに推定の正確さを出さないとされています。学習が終わっても、どのくらい読めるのかは分かりません。評価用の30枚を最初から分けておきます。

判定の基準値は、処理の側の設定として持ちます。 初期値は、登録番号の信頼度の下限0.90、選択マークの下限0.80とし、最初の1か月で、フロントが直した欄の信頼度の分布を見て見直します。

出力形式を固定する

依頼書1枚ごとに、次の形のJSONを作ります。

{
  "order_id": "B2-20261015-0031",
  "branch": "B2",
  "fields": {
    "reg_no": { "value": "", "conf": 0, "check": "ok | low_confidence | not_found | mismatch" },
    "odometer": { "value": "", "conf": 0, "check": "ok | ambiguous | mismatch" },
    "received_at": { "value": "", "conf": 0, "check": "ok | missing" },
    "pickup_request": { "value": "", "conf": 0, "check": "ok | missing" },
    "loaner": { "value": "要 | 不要 | ", "conf": 0, "check": "ok | missing | ambiguous" },
    "signature": { "present": true, "conf": 0, "check": "ok | missing" }
  },
  "work_items": [
    { "item": "車検", "selected": true, "conf": 0, "std_minutes": 0, "pit": "lift" }
  ],
  "symptom_text": "",
  "symptom_conf": 0,
  "notices": ["車検の満了日が30日以内"],
  "needs_review": true
}

1つ目の理由は、項目ごとに check を持てることです。 確認の一覧には ok 以外の欄だけを出せるので、フロントは依頼書の全体を見直さずに済みます。

2つ目は、pickup_request を文字列のまま持つことです。 「夕方」「土曜午前」を日時に直すと、お客様と話した内容とずれます。 工程表の下書きには原文のまま載せ、何時にするかはフロントが確かめます。

3つ目は、notices を check と分けることです。 車検の満了日が近いという案内は、依頼書の誤りではありません。確認の印と混ぜると、フロントが案内を読み飛ばします。

工程表の下書きの行には、登録番号、車名、作業の区分、標準の時間、納車の希望（原文）、代車、症状（原文）を並べ、needs_review が true の行には印を付けます。

システムへ連携する

工程表には「下書き」のシートを分けて置きます。 ピットの枠のシートに直接書き込むと、工場長が組んだ工程を機械が動かすことになります。 下書きの行を工場長が見て、枠に移す形にします。

整備管理システムへは、取り込み用のファイルを渡すところまでにします。 取り込みの機能が無いシステムなら、フロントが確認の一覧を見ながら打ち込みます。 その場合でも、車両の呼び出しと照合が済んでいる分だけ速くなります。

人が確認する

フロントが見るのは、確認の一覧で印の付いた欄だけです。 印の無い依頼書は、件数と登録番号を一覧で流し見ます。

1. 署名と代車の missing を先に見る … お客様がまだ受付にいれば、その場でもらう・聞く。帰った後なら、預かりの連絡の電話で確かめます
2. 登録番号の not_found と mismatch を見る … 依頼書の画像と並べ、正しい番号を確かめます。新規のお客様なら、整備管理システムに新しく登録します
3. 納車の希望の原文を見る … 「夕方」「土曜午前」を、お客様と話した内容に合わせて時刻にします
4. チェック欄の ambiguous と症状の読めない部分を見る … 書いたフロント本人が確かめるのがいちばん速いです
5. 直した内容を記録する … どの欄を、何から何に直したかを残します

工場長が見るのは、工程表の下書きの行です。 作業の区分と標準の時間を見て、ピットの枠に入れるか、時間を直すかを決めます。 「一般修理」と「板金」の行は、症状の原文を見て時間を決めます。

目標は、600台をならして1台1.5分です。 印の付く依頼書が3割前後という想定で、それより多い日は、スキャンした控えの取り違えか、スキャナーの設定を疑います。

例外に対処する

下から4行目は、公式の制限から来ています。 症状を裏面まで書き込むお客様の依頼書は少なくありません。表の欄と裏面を別々に読み、表示のときにつなげます。

記録を残す

• 元の依頼書の PDF と、スキャンした日時・拠点・スキャナー
• Document Intelligence が返した JSON の全文と、使ったモデルの ID と API のバージョン
• 照合の結果（check、notices）と、そのとき参照した車両の台帳の内容
• フロントが直した記録 … どの欄を、何から何に直したか。確かめた人と日時
• 工程表の下書きの行と、工場長が実際に入れた枠と時間
• 納車の希望の原文と、確かめた後の時刻

3つ目で台帳の内容を残すのは、台帳が後から直されるためです。 前回の走行距離が誤っていたと分かって直すと、当時の mismatch の理由が分からなくなります。

最後の行は、お客様との行き違いが起きたときの記録です。 「夕方と言った」「17時と聞いた」のどちらだったかを、依頼書の原文と、フロントが確かめた時刻の両方で残します。