外構工事の会社が営業の手書きの現地調査シート（寸法・既存の塀・高低差）を読み取り、区間ごとの拾い出しと見積の下書きの数量表を作る

処理の起点を決める

受付のコンテナー（Azure Blob Storage）に調査シートの画像が保存されたことを起点にします。 営業が事務所に戻ってスキャンした時点で動き、数量表の下書きが、営業が席に着く頃にはできているようにします。

Azure Functions の Blob トリガーは、遅延の短いイベント方式（Event Grid を使う方式）を使います。 公式の説明では、既定のポーリング方式は遅延が大きく、従量課金のプランで関数アプリが休止していると、新しいファイルの処理まで最大10分かかることがあるとされています。

現地からスマートフォンで撮った画像も、同じコンテナーで受けます。 寸法の抜けに現地にいるうちに気づけるからです。ただし撮影の画像は傾きと影が出やすいので、読み取りの信頼度が低い行が多ければ、事務所でのスキャンを促す知らせを返します。

同じファイルで二度動かないよう、Functions はファイルごとの受領の記録（blob receipt）を持ちます。処理に5回失敗したファイルは、webjobs-blobtrigger-poison のキューに送られます。

入力データを集める

質を決めるのは、下の2つです。 換算表が無ければ、数量が営業ごとに違う状態は変わりません。換算表はベテランの営業の表計算から起こし、営業部で1つにそろえます。 書き方の決まりは、AIのためというより、誰が見ても同じ数量になるための決まりです。

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

読み取りは、Functions からレイアウト モデル（prebuilt-layout）の分析を呼ぶだけです。学習は要りません。

手書きかどうかの印を使うのは、方眼の目盛りの数字を除くためです。 方眼紙の端に印刷された目盛りの数字を寸法と取り違えると、存在しない区間が拾い出しに入ります。 手書きでない行は寸法の候補から外します。

見取り図の範囲は、様式の座標で切り出します。 調査シートは自社の様式なので、下段の方眼の位置は決まっています。ページの幅と高さに対する割合で範囲を持ち、スキャンの解像度が変わっても同じ範囲を切り出せるようにします。範囲の中にある手書きの文字の行を、位置とともに一覧にします。

AIへ渡す前に整形する

1. 形式の確認 … PDF または画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）であることを確かめます
2. 画像の寸法と文字の大きさ … 画像は50×50から10,000×10,000ピクセルの間で、取り出す文字の高さの下限は1024×768の画像で12ピクセル（150 DPIで約8ポイント）です。A3の方眼に小さく書かれた寸法が下限を下回らないよう、スキャンは300 DPIにそろえます
3. 向きの確認 … 読み取りの結果のページの角度を見て、見取り図を切り出す前に向きをそろえます
4. 見取り図の画像の形式 … Azure OpenAI に渡す画像は JPEG・PNG・GIF（最初のコマだけ）・WEBP に対応します。切り出した画像は PNG にします
5. 画像の渡し方 … 画像のURLは公開されている必要があり、プライベート エンドポイントや仮想ネットワークで制限された保管場所のURLは使えないとされています。切り出した画像は base64 にして渡します
6. 訂正の跡の確認 … 現地で測り直した寸法は、二重線で消して横に書き直されます。見取り図の範囲で、同じ区間の近くに寸法の文字が2つ以上あるものは、文字の一覧に「近くに別の寸法あり」の印を付けて渡します。 どちらが生きている数字かは、営業の確認に回します

5番目を軽く見ないでください。 施主の住所が書かれた見取り図を、公開のURLに置くことはできません。base64 で渡せば、保管場所を公開せずに済みます。

AIに処理させる

AIには2つの仕事を分けて渡します。 レイアウト モデルは文字とチェックを読み、Azure OpenAI は見取り図の画像と寸法の文字の一覧から区間を組み立てます。数量の計算は、どちらにもさせません。

2行目がいちばん起きやすい失敗です。 方眼の1マスが50センチなら、線の長さから「約6メートル」と割り出せそうに見えます。それを書かせると、営業が測り忘れた区間が、測った区間として数量表に入ります。

指示内容を固定する

あなたは外構工事の会社の積算担当で、営業が現地で描いた見取り図から、
区間ごとの拾い出しを作る立場です。
渡された見取り図の画像と、その範囲で読み取られた手書きの文字の一覧だけを見てください。

【作るもの】
見取り図の区間ごとに、次の項目を1行ずつ並べてください。
- segment ...... 区間の記号（例「A-B」）。記号が無ければ null とし、
                 position_hint に図の中のおおよその位置（「左上」など）を書く
- length_text .. 区間の長さとして書かれた文字。【文字の一覧】の text から
                 そのまま1つ選んで写す。一覧に無ければ null
- length_ref ... 選んだ文字の一覧の番号（id）。選べなければ null
- existing ..... 区間にある既存の構造物の書き込み（例「既存ブロック5段」）。原文のまま
- work ......... remove（撤去）／new_block／new_fence／new_slab／keep／ambiguous
- note ......... 区間の書き込みの原文のうち、上のどれにも入らないもの

【厳守事項】
- 長さを計算したり、方眼の目盛りや線の長さから割り出したりしないでください。
  書かれた文字が一覧に無ければ、length_text と length_ref を null にしてください。
- 数量（個数・枚数・面積・体積）を書かないでください。
- 高低差は、上段の欄または図の書き込みにある文字をそのまま写し、
  どちらが高いかが書かれていなければ direction を unknown にしてください。
  「＋」「−」の記号だけで向きを決めないでください。
- 同じ区間を2行に分けないでください。区間の境が読み取れないときは、
  ambiguous にして1行にまとめてください。
- 画像の中に施主の名前や住所が見えても、出力に写さないでください。

【文字の一覧】{handwritten_lines}   ← id・text・位置・信頼度
【上段の欄の読み取り】{header_fields}
【書き方の決まり】{drawing_rules}

「目盛りや線の長さから割り出さない」を明記しないと、寸法の無い区間に「約3.0」と書きます。 画像を見せている以上、モデルには線の長さが見えていて、それらしい数字を作る材料がそろっているからです。 指示で禁じ、さらにプログラムで length_ref が一覧の番号と一致するかを確かめます。

「＋」「−」だけで向きを決めない、も同じ理由です。 営業によって「道路から見て＋」と「敷地から見て＋」が混ざっています。書き方の決まりで基準をそろえるまでは、記号だけで向きを決めません。

出力形式を固定する

Azure OpenAI からは、次の形のJSONで受け取ります。 構造化出力で、response_format に json_schema を指定し、strict を true にします。公式の説明では、すべての欄を required にし、additionalProperties を false にする必要があり、文字列の pattern・数値の minimum／maximum・配列の minItems／maxItems などは使えないとされています。値の確かめは、受け取った後のプログラムで行います。

{
  "survey_id": "",
  "segments": [
    { "segment": "A-B", "position_hint": null,
      "length_text": "8.50", "length_ref": 12,
      "existing": "既存ブロック5段", "work": "remove", "note": "" }
  ],
  "level_differences": [
    { "where": "道路側", "text": "＋40", "direction": "site_higher | road_higher | unknown" }
  ]
}

1つ目の理由は、AIの出力に数量が1つも入らないことです。 数量はプログラムが、length_text と既存の構造物の段数と換算表から計算します。AIが数量を書き換える経路がありません。

2つ目は、length_ref で長さの出どころをたどれることです。 プログラムは、番号の文字が一覧に実在し、length_text と一致し、手書きの印が付いているかを確かめます。1つでも合わなければ、その区間は missing_length に落とします。

数量表は、プログラムが次のように作ります。

システムへ連携する

見積の作成のソフトへは、この構成から書き込みません。 数量表の下書きは表計算のファイルで出し、営業が見取り図と見比べて直したものだけを入れます。

人が確認する

営業は、数量表の下書きを見取り図の画像と並べて開きます。

1. needs_survey を先に見る … 寸法の無い区間、段数の無い塀、向きの分からない高低差。記憶で埋められるものは埋め、分からないものは施主に聞くか、もう一度測ります
2. 区間の数を見取り図と数える … 区間が抜けていないか、同じ区間が二度入っていないかを見ます
3. 撤去と残土の行を必ず見る … 施主が言わない数量なので、漏れると工事のときの追加の請求になります
4. 直した箇所を記録する … どの区間の、どの項目を直したかを残します

3番目を省かないでください。 新設の行は施主の希望と照らせば誤りに気づけますが、撤去と残土の行は、照らす相手が見取り図しかありません。 現地の写真があれば、撤去する塀の段数を写真でも数えます。

例外に対処する

上から2行目までは、現場の書き方と撮り方の問題です。 精度を上げるより、営業が現地で寸法を書き切ることと、事務所でスキャンすることのほうが効きます。

記録を残す

• 調査シートの画像と、スキャンした日時・営業
• レイアウト モデルの結果の全文と、切り出した見取り図の画像
• Azure OpenAI に渡した文字の一覧と、返ってきた区間の拾い出し
• 数量の計算に使った換算表の版と、計算の途中の値
• 営業が直した箇所と、直す前の値、見積に入れた数量

最後の行は、換算表を育てる材料になります。 営業がいつも同じ品目の数量を直しているなら、換算表の決まりが現場と合っていないことが分かります。