リフォーム会社の担当が手書きする現地調査シートを読み取り、部屋・寸法・既存の設備・劣化の状況を見積の入力項目にそろえて、測り漏れを現場にいるうちに拾う

処理の起点を決める

Apps Script の時間主導型トリガーで、5分おきに案件のフォルダを確かめます。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻はわずかにずれることがあるとされています。

5分おきにするのは、営業が施主の家にいる間に返事を返すためです。 撮って送ってから返事が届くまでが10分を超えると、営業は返事を待たずに次の現場へ向かいます。 調査の最後に撮って、片づけをしている間に返事が届く間隔にします。

処理が終わった写真には「処理済み」の印を付けます。 印を付けるのはシートへの書き込みが終わったときだけで、印の無い写真の数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、必須の寸法の表です。 何が抜けたら商品を選べないかは、見積の担当の経験の中にしかありません。 表にしておけば、新しく入った営業も同じ基準で測れます。

案件の情報の「調査する部屋」は、部屋のシートの撮り忘れを拾うのに使います。 浴室と洗面を調べる案件で、浴室のシートしか届いていなければ、洗面のシートの撮り忘れとして返します。

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

Apps Script は、新しい写真を Enterprise Document OCR のプロセッサに送ります。オンラインの処理は1回の要求で最大15ページなので、部屋のシートを1枚ずつ送ります。

要求には、2つの設定を付けます。 画質の点数は processOptions.ocrConfig.enableImageQualityScores を、チェック欄の抽出は ocrConfig.premiumFeatures.enableSelectionMarkDetection を有効にします。公式のページでは、画質の分析はOCRの処理と同じくらいの待ち時間が加わるとされています。

Enterprise Document OCR は、キーと値の組を返しません。 「間口」という欄の文字と、その右に書かれた「1600」は、別々の文字として位置付きで返ります。 どの数字がどの欄のものかを位置から決めるのが、次の生成AIの仕事です。

写真はJPEGで撮ります。 Document AI の対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などで、Claude API の画像は JPEG、PNG、GIF、WebP です。どちらの一覧にも HEIC は無いので、社用スマートフォンのカメラの保存形式をJPEGにしておきます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG以外の写真は、変換するか撮り直しを頼みます
2. 画質の確認 … 画質の点数が0.5を下回り、ぶれ・暗さ・反射・切れが理由に挙がっていれば、読み取りを止めて撮り直しを頼みます
3. 大きさの確認 … Claude API に渡す写真は、1枚8000×8000ピクセル以下、APIを直接使うとき1枚10MB（base64エンコード後）以下に縮めます
4. 部屋の種類の決定 … シートの上部の部屋の種類（浴室・キッチンなど）を読み取り結果から決め、必須の寸法の表のどの行を使うかを決めます
5. 撮り忘れの確認 … 案件の「調査する部屋」と、届いたシートの部屋の種類を比べます

2番目を先に行うのは、読めない写真を読み取りに回すと、測り漏れと区別がつかなくなるからです。 「天井高」の欄が読めなかったのか、測っていないのかで、営業にしてもらうことが撮り直しか測り直しかに分かれます。 公式のページでも、画質の分析はスキャンや撮影した文書で最もよく使えるとされています。

AIに処理させる

させるのは、読み取り結果と写真を見て、部屋ごとの寸法・既存の設備・劣化の状況を見積の入力項目に書かれたとおりに写すことです。 測り漏れの判定も、桁の範囲の確認も、Apps Script の規則で行います。

3行目が、AIを使う理由です。 見取り図の中に書き込まれた「1650」が、浴室の間口か奥行かは、図の線と数字の位置関係を見ないと分かりません。 読み取り結果の位置だけでは決めにくいので、写真もあわせて渡し、どの辺に沿って書かれているかを見させます。

1行目が、この題材でいちばん起きやすい失敗です。 「160」を、他の寸法がmmで書かれているからと1600に直すと、たいていは合っています。 ただ、外れたときは入らない大きさの商品で見積が出ます。単位は書かれていなければ空にし、Apps Script がふつうの範囲と照らして、外れたものを営業に聞きます。

指示内容を固定する

あなたはリフォーム会社の見積の担当で、営業が手書きした
現地調査シートの読み取り結果と写真を見て、見積の入力項目に写す立場です。
読み取り結果と写真に書かれていることだけを写してください。

【写す項目】
room_type（浴室／キッチン／トイレ／洗面／居室）、case_no
dimensions：name（欄の名前。書かれたとおり）、value_text（数字）、
unit_text（書かれていれば単位）、source（field／drawing）、
edge（見取り図の中の数字なら、どの辺の長さか）
equipment：maker、model_text、installed_year_text
deterioration：item（ひび／カビ／腐食／水漏れ／きしみ）、
state（checked／unchecked／unclear）、note
memo

【厳守事項】
- 数字は書かれたとおりの文字列で写してください。
  単位が書かれていなければ unit_text を空にしてください。
  mmとcmを換算しないでください。桁を足したり削ったりしないでください。
- 欄が空なら value_text を空にし、status を blank にしてください。
  他の寸法や見取り図から推して埋めないでください。
- 読めない桁があれば status を unreadable にしてください。
- 見取り図の中の数字は、写真で図の線を見て、どの辺に沿って
  書かれているかを edge に書いてください。決められなければ
  position_unknown を true にしてください。
- 品番は書かれたとおりに写してください。似た品番に直さないでください。
- 工事ができるか、劣化がどの程度かは書かないでください。
- 調査シートでない写真と判断した場合は、document_type に種類を書いてください。

【読み取り結果】{ocr_result}
【調査シートの写真】（画像として添付）

必須の寸法の表をAIに渡していないことが、このプロンプトのいちばんの工夫です。 表を見せると、「浴室には出入口の幅が要る」と知ったAIが、見取り図のどこかの数字を出入口の幅として写してしまいます。 測り漏れを見つけたいのに、埋められて見えなくなります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（リクエストの output_config.format に type: "json_schema" とスキーマを渡す方式）を使い、形を固定します。

{
  "document_type": "site_survey",
  "room_type": "浴室",
  "case_no": "",
  "dimensions": [
    { "name": "", "value_text": "", "unit_text": "",
      "source": "field | drawing", "edge": "",
      "position_unknown": false, "status": "read | blank | unreadable" }
  ],
  "equipment": [
    { "maker": "", "model_text": "", "installed_year_text": "",
      "status": "read | unreadable" }
  ],
  "deterioration": [
    { "item": "ひび | カビ | 腐食 | 水漏れ | きしみ",
      "state": "checked | unchecked | unclear", "note": "" }
  ],
  "memo": ""
}

1つ目の理由は、必須の寸法の表と機械的に照らせることです。 Apps Script は room_type で表の行を選び、dimensions の name を寸法の名前の読み替えで引き当て、必須なのに無い寸法、blank、unreadable を測り漏れとして返します。

2つ目は、営業に返す理由を規則で持てることです。

missing_dim と room_missing は、まとめて1通のメールで営業に返します。 測り漏れが3つあれば3つを並べ、施主の家にいる間に1回で測り直せるようにします。

Claude の構造化出力のスキーマには、数値の最小値・最大値の制約が使えません。 公式のページでは、minimum・maximum などの数値の制約は対応していないとされています。ふつうの範囲は、スキーマではなく Apps Script の照合で確かめます。 拒否は stop_reason が refusal、出力の上限で切れたときは max_tokens になり、スキーマに合わないことがあるとされています。どちらのときもシートに書かず、check_image で人に回すか呼び直します。

システムへ連携する

見積のシステムには、この構成から書き込みません。 取り込むのは見積の担当で、取り込む前に、印の残っていないことを確かめます。 読み取りの誤りが、そのまま見積の寸法になることはありません。

施主への連絡も、この構成からは送りません。 メールが届くのは社内の営業だけです。

人が確認する

営業が見るのは、現場で届くメールだけです。 撮り直しと測り漏れを、その場で片づけます。

1. 撮り直しのメールが来たら … 明るい場所でシートを撮り直します
2. missing_dim と room_missing が来たら … 施主に断ってもう一度測り、シートに書き足して撮り直します
3. unit_check と unreadable_dim が来たら … 単位と数字をシートに書き直して撮り直します

見積の担当が見るのは、見積入力待ちのシートです。

1. 寸法と単位を流し見る … 印が消えているか、見取り図の数字の辺が合っているかを写真で確かめます
2. 既存の設備を写真と見比べる … equipment_check が残っていれば、設備の写真で品番を確かめます
3. 見積のシステムに取り込む … 取り込んだ日時と担当を残します

目標は、240件をならして1件8分です。 営業が現場で返事を確かめる時間と、見積の担当の流し見を合わせた値です。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、撮り方とシートの書き方の問題です。見取り図の中に寸法を書く癖のある営業には、寸法の欄にも書き写してもらうほうが早く直ります。

記録を残す

• 元の写真と、撮った営業・案件番号・撮った日時
• OCRが返したJSONの全文（画質の点数と理由を含む）と、Claude API の応答の全文
• 照合に使った必須の寸法の表の版
• 付いた印と、営業に送ったメール、撮り直しや測り直しが届いた日時
• 見積の担当が取り込んだ日時と、取り込む前に直した箇所
• 営業ごとの missing_dim と撮り直しの件数

最後の行は、営業の教育の材料になります。 特定の営業だけ同じ寸法を測り漏らすなら、その寸法がなぜ要るかを見積の担当から伝えるほうが、表を見せるより効きます。