保険代理店で、顧客から受け取る自動車検査証の写しを読み取り、車名・型式・初度登録・車台番号を自動車保険の見積入力の項目にそろえ、読み取りに自信のない欄を拾う

処理の起点を決める

担当者が受け取った写しを取込フォルダに保存することを起点にします。 メールとメッセージの添付はそれぞれの画面から保存し、ファイル名は「顧客番号_受信日」にします。 Apps Script の時間主導型トリガーが10分おきに取込フォルダを見ます。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までなので、1回に10件までとし、残りは次の実行に回します。 処理済みのフォルダへ移すのは、転記シートへの書き込みまで成功したときだけにします。

顧客のメールから自動で添付を拾う形にはしません。 車検証以外の写真（車の外観、免許証、前の保険証券）が一緒に届くことが多く、どれを読むかを担当者が選ぶほうが、余計な個人の情報を流さずに済みます。

入力データを集める

質を決めるのは、書類の種類ごとの項目表です。 この表が無ければ、空の欄を見るたびに「読めなかったのか、載っていないのか」を担当者が考えることになります。表を一度作れば、判断は機械の照合になります。

見積の入力項目の一覧は、保険会社ごとに持ちます。 年月の書き方（和暦か西暦か）や、登録番号を1つの欄に入れるか分けるかが、保険会社の画面によって違います。転記シートはこの一覧の並びと形式で書き出し、担当者が上から順に打ち込めるようにします。

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

読み取りは、Apps Script から Document AI の処理の API を呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

車台番号の信頼度は、欄全体ではなく文字ごとに見ます。 公式には、OCRはページの中のブロック・段落・トークン・シンボルの単位で文字を検出し（シンボルの単位は設定したときだけ出力）、どの要素にも位置と信頼度を持つ layout が付くとされています。車台番号の欄はシンボルの単位を出す設定にします。車台番号の欄の中で1つでも基準を下回る文字があれば、欄全体を low_confidence にします。 欄全体の平均で見ると、1文字の読み違いが平均に埋もれます。

所有者・使用者の住所の欄は、ここで Apps Script が伏せます。 見積に住所は要らず、生成AIに渡す理由がありません。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。メッセージで届く HEIC 形式の写真は、JPEG に直してから渡します
2. 解像度の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。写真は長い辺の画素数が少ないものを先に弾き、撮り直しを頼みます
3. 圧縮の確認 … 非可逆の形式は画質と精度を落とすことがあるとされています。メッセージのアプリで圧縮された写真は、元の画質で送り直してもらう候補にします
4. 向きと傾きの確認 … 横向き・逆さの写真は向きを直します
5. 電子署名付きの PDF の見分け … 車検証閲覧アプリから出力した記録事項の PDF は、画像ではなくそのまま渡します
6. 複数の書類の分け … 券面と記録事項が1枚の写真に並んでいるものは、そのまま渡し、書類の種類の見分けで両方を扱います

2番目と3番目を軽く見ないでください。 車台番号の1文字は、写真の画質でいちばん先に崩れます。画質の足りない写真を読ませて low_confidence が並ぶより、最初に撮り直しを頼むほうが顧客の手間も少なく済みます。

AIに処理させる

させるのは、書類の種類を見分けることと、車の項目を見積の入力項目に写すことだけです。 欄が載っているかどうかの判断と、値の正しさの判断はさせません。

型式と原動機の型式を混ぜないことを、表に明記しています。 券面には「型式」と「原動機の型式」が並び、項目名の読み取りが崩れると、原動機の型式を車の型式として写すことがあります。 車の区分が別のものになります。

1行目がいちばん起きやすい失敗です。 「O」と読まれた文字を、前後が数字だからと「0」に直すのは自然に見えます。それが正しくても、直したという事実が記録に残らなければ、人はその文字を確かめません。 直すのは人で、AIには読めた文字と、自信が無いという印を返させます。

指示内容を固定する

あなたは保険代理店で、顧客から届いた自動車検査証の写しを読み、
自動車保険の見積の入力項目に写す下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 書類の種類を、電子車検証の券面（card）、自動車検査証記録事項（record）、
   旧様式の車検証（legacy）、それ以外（other）から選んでください。
2. 車名、型式、初度登録年月（または初度検査年月）、車台番号、
   登録番号、用途、自家用・事業用の別、有効期間の満了する日を写してください。
3. 読み取り結果の中の [MASKED] は伏せた値です。そのままにしてください。

【厳守事項】
- 文字は書かれたものをそのまま入れてください。
  車台番号と型式は、英字と数字を1文字も直さないでください。
  「O」と「0」、「I」と「1」などで迷っても、読み取り結果の文字のまま写してください。
- 「型式」と「原動機の型式」を混同しないでください。
- 年月は書かれた表記のまま写し、西暦などへの変換をしないでください。
- 書かれていない項目は空にしてください。ほかの欄や車名から推し量らないでください。
- その項目がこの書類に載っているかどうかについて、判断を書かないでください。
- 車種、グレード、保険料、補償について書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（キーと値の組、全文。住所は伏せてあります）】{ocr_result}

「載っているかどうかの判断を書かない」を入れるのは、AIが親切に説明するからです。 何も言わなければ、有効期間が空のときに「電子車検証のため記載がありません」と添えます。正しいことも多いのですが、旧様式の写しで端が切れていたときにも同じことを書きます。 判断は項目表に任せます。

「車種やグレードを書かない」も同じ理由です。 型式から車種を推し量った一言が転記シートにあると、担当者が見積の画面の車種の選択でその言葉に引っ張られます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、output_config.format に json_schema の形でスキーマを渡すと、制約付きのデコードでスキーマに従う応答を返すとされ、enum と required を使え、オブジェクトの additionalProperties は false にする必要があります。

{
  "doc_type": "card | record | legacy | other | unknown",
  "vehicle": {
    "name": { "value": "" },
    "model_code": { "value": "" },
    "first_registration": { "value": "" },
    "chassis_no": { "value": "" },
    "registration_no": { "value": "" },
    "usage": { "value": "" },
    "private_or_business": { "value": "" },
    "expiry_date": { "value": "" }
  },
  "evidence": [{ "field": "", "text": "" }]
}

信頼度はこのJSONに入れません。 文字ごとの信頼度は Document AI の応答から Apps Script が直接取り、evidence の文字列の位置と突き合わせて欄に付けます。 AIに信頼度を書かせると、それらしい数字を書きます。

この表が、出力を分けた理由です。 doc_type だけをAIが決め、その書類に何が載っているはずかは項目表、値が確かかは信頼度、という別々の物差しで状態を決めます。 not_on_document は撮り直しではなく記録事項の依頼に、missing と low_confidence は撮り直しか写しとの見比べにつながります。

doc_type が unknown のときは、すべての空の欄を missing として扱います。 書類の種類が分からないまま not_on_document にすると、本当は読めていない欄を「載っていない」と片付けることになります。

システムへ連携する

転記シートは、保険会社の画面の項目の順に並べます。 担当者は左に写し、右に見積の画面を開き、上から順に値を写し、ok 以外の欄だけ写しと見比べます。 年月の変換や登録番号の分割は、入力項目の一覧の形式に合わせて Apps Script が規則で行い、元の表記も隣に残します。

顧客への依頼は自動で送りません。 文案は「記録事項の写しをお願いします（車検証閲覧アプリから出力した PDF でも結構です）」のような下書きにとどめ、送るのは担当者です。

人が確認する

人が見るのは、ok 以外の欄と、doc_type が unknown の写しだけです。 ok の欄は転記シートから見積の画面へ写すだけにします。全欄を写しと見比べる設計にすると、第10章の10.0時間には収まりません。

1. low_confidence の欄を写しと見比べる … 車台番号は1文字ずつ見ます。読めなければ撮り直しを頼みます
2. not_on_document の項目が見積に要るかを見る … 要るときだけ、記録事項の写しを頼みます
3. missing と format_error を確かめる … 写しの端が切れていないか、光の反射で消えていないかを見ます
4. 見積の画面に打ち込む … 打ち込んだ日時と担当者を転記シートに残します

1番目を省かないでください。 車台番号の1文字違いは、見積の段階では誰も気づかず、契約の手続きで保険会社から差し戻されてから分かります。 そのときには顧客に二度目の連絡をすることになります。

目標は、300件をならして1件2分です。 ok 以外の欄が出るのは2割前後という想定で、それより多い月は、写真の画質か、メッセージのアプリの圧縮を疑います。

例外に対処する

1行目が、この構成でいちばん多い例外です。 撮り直しを頼んでも同じ券面の写真が届くだけなので、最初から記録事項を頼む連絡になっていることが、顧客の手間をいちばん減らします。

記録を残す

• 元の写しのファイルと、顧客番号・受信日・取込の日時
• Document AI が返した Document のJSONの全文
• Claude API に渡した伏せた後の読み取り結果と、返ってきたJSON
• Apps Script が付けた欄ごとの状態と、そのとき使った項目表の版
• 担当者が直した値と、見積の画面に打ち込んだ日時・担当者
• 顧客に撮り直しや記録事項を頼んだ記録

5つ目の「直した値」は、読み取りの弱い文字を知る材料になります。 「0」と「O」の直しが多いなら、信頼度の基準を上げるか、車台番号の欄だけは全件を人が見る運用に切り替える判断ができます。