現場の定点写真から工事の進捗を読み取って、予定とのずれを早く見つける

処理の起点を決める

撮影位置IDの付いたフォルダに、その現場の写真がすべてそろったことを起点にします。 1枚ごとに動かすと差分カードがばらばらの時刻に出るため、現場単位でまとめ、撮影日の翌朝に1回動かします。月末の一括処理にはしません。 まとめて回すと、この構成の目的である「早く気づく」が消えます。処理が終わった写真は処理済みフォルダへ移し、移すのは成功時だけにします。

入力データを集める

質を決めるのは、作業名の対応表です。 これが無ければ、生成AIは工程表に無い「それらしい名前」を書きます。次の形で、工期に出てくる作業をすべて並べます。

基準写真は、撮影位置ごとに1枚ずつ持ちます。 画角がずれたかどうかは、前回の写真とではなく基準写真と比べて判定します。前回と比べると、少しずつずれていったときに気づけません。

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

写真の対応付けは、フォルダ名で行います。 画像の中身から「同じ場所か」を当てさせません。現場コード / 撮影位置ID / 撮影日 の3階層にしておけば、前回の写真は同じ撮影位置IDの1つ前として決まります。 Azure AI Vision の呼び出しは、Analyze Image の features クエリパラメーターに欲しい機能を並べるだけです。

タグには、境界ボックスで位置を特定できない語も含まれます。 公式には、タグ機能には屋内などの文脈上の用語も含まれるとされ、タグ付けの分類と物体検出の分類との間に正式な関係は存在しないとも書かれています。両方に同じ名前が出る前提で組まないでください。

AIへ渡す前に整形する

1. 形式とサイズの確認 … 入力は JPEG、PNG、GIF、BMP、WEBP、ICO、TIFF、MPO のいずれかで、20メガバイト未満である必要があります
2. 寸法の確認 … 50×50ピクセルより大きく、16,000×16,000ピクセル未満である必要があります
3. 画角ずれの判定 … 基準写真と今回の写真で、動かない構造物（柱、擁壁、電柱、既存建物）の境界ボックスの位置を比べます。ずれが決めた割合を超えたら「比較不能」にして先へ進めません
4. 人物領域の塗りつぶし … peopleResult が返した境界ボックスを塗ります。信頼度の低いものも含めて広めに塗ります
5. 明るさの記録 … 補正はしません。撮影時刻と天候を条件として持ち回り、判定の側で扱います
6. 生成AIへ渡すサイズへの縮小 … 長辺を2,000ピクセル以下に落とします。生成AI側は画像を28×28ピクセルの区画に分けて数えるため、大きいまま渡すと費用と待ち時間が増えます
7. 前回写真の特定 … 同じ撮影位置IDの直近の処理済み画像を選びます。無ければ初回として扱います

3番目を省かないでください。 画角がずれた写真を渡すと、生成AIは律儀に「違い」を書きます。それは工事の進捗ではなく、立ち位置の違いです。 判定させずに撮り直しへ回すほうが速く終わります。5番目で補正をしないのも同じで、明るさをそろえると、元の写真で暗くて見えていなかった部分が「見えるようになった」ように出ます。

AIに処理させる

させるのは、2枚の写真を見て「違って見える箇所」を日本語で書くことと、対応表の中から作業名の候補を選ぶことだけです。

「見え方だけの違い」を別の欄にすることが、この構成の肝です。 曇りの日の写真は全体が暗く、養生シートが張られた翌日は外観がまるごと変わります。同じ欄に入れると、変化の一覧が見え方の話で埋まります。 迷ったら見え方の側へ寄せるのも意図した偏りで、変化として出たものは人が確かめるため、見落としは次回の撮影で拾えます。

指示内容を固定する

あなたは建設現場の工事管理を担当する立場です。
同じ場所・同じ画角で撮った2枚の写真を見比べて、違って見える箇所を書き出してください。

Image 1: 前回の写真（撮影日 {prev_date}、天候 {prev_weather}、時刻帯 {prev_time}）
Image 2: 今回の写真（撮影日 {curr_date}、天候 {curr_weather}、時刻帯 {curr_time}）

【書き出すもの】
1. changes … 工事が進んだ結果として違って見える箇所
2. appearance_only … 見え方だけが違う箇所
3. task_candidates … 下の対応表の作業名のうち、今回の写真の状態に当たるもの

【対応表】{task_mapping}

【厳守事項】
- 出来高の率、進み具合の割合、金額を書かないでください。
  「およそ6割」「半分ほど終わっている」も書かないでください。
- 遅れている理由、早く進んだ理由を書かないでください。
  書くのは「前回と違って見える」という事実までです。
- 天候、時間帯、明るさ、影の向き、養生シート、仮囲い、仮設足場、仮設の照明、
  資材の仮置きによる見え方の違いは、changes ではなく appearance_only に
  入れてください。判断に迷うものも appearance_only に入れてください。
- task_candidates は、対応表に書かれた作業名の中からだけ選んでください。
  当てはまるものが無ければ空の配列にし、新しい作業名を作らないでください。
- 面積、本数、長さ、高さを数値で書かないでください。
  「鉄筋が格子状に組まれている」のように、状態の言葉で書いてください。
- 写真が暗い、雨で濡れている、対象が隠れている、画角が合っていないと
  判断した場合は、比較をせずに unjudgeable を true にし、
  unjudgeable_reason に理由を選んでください。
- 人物について何も書かないでください。人数も、作業の様子も書かないでください。
- description には、位置（左寄り、奥、上部など）と状態を書いてください。

「出来高の率を書かない」を1行で済ませないでください。 割合を禁じるだけだと「おおむね半分」と書きます。言い換えの形まで禁じて、はじめて止まります。 対応表を埋め込むのも同じで、「たぶん躯体工事」では工程表と突き合わせられません。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力を使い、output_config.format に json_schema として渡します。

{
  "site_id": "",
  "viewpoint_id": "",
  "captured_at": "",
  "comparable": true,
  "unjudgeable": false,
  "unjudgeable_reason": "none",
  "changes": [
    { "area": "", "description": "", "region_confidence": 0 }
  ],
  "appearance_only": [
    { "area": "", "description": "" }
  ],
  "task_candidates": [
    { "task_name": "", "basis": "" }
  ],
  "note_draft": ""
}

unjudgeable_reason は none ／ dark ／ rain ／ occluded ／ angle_shift ／ people_left から選ばせます。理由の欄はここだけで、遅れの理由を書く欄はどこにもありません。

構造化出力を使う理由は、後段が計算だからです。 工程表との突き合わせも差分カードの組み立ても、値が入っている前提で動きます。スキーマに沿った出力が保証され、スキーマ違反による再試行が要らなくなるとされています。

ただし、スキーマに書けることには制限があります。 enum は文字列・数値・真偽値・null に限られ、minimum や maximum といった数値の制約、minLength などの文字列の制約、pattern は使えません。 オブジェクトには additionalProperties を false で指定します。「率を書かせない」はスキーマでは縛れないので、欄を作らないことと指示文の両方で止めます。 なお、スキーマを最初に使うときは文法の組み立てで遅くなり、その文法は24時間キャッシュされるとされています。

埋める主体は4つに分かれます。 changes・appearance_only・task_candidates は生成AI、comparable と region_confidence は前処理とAzure側の返り値、予定との一致・不一致はPythonの計算、進捗の判断と所見は人です。

システムへ連携する

工程表には書き込みません。 予定を動かすのは工程を組み直す作業で、この構成の仕事ではありません。書き込みを足すと、判定の誤りがそのまま工程表に残ります。 発注者へ提出する書類の経路にもつなぎません。

人が確認する

差分カードは、現場代理人と所長の2段で見ます。

1. 現場代理人が、変化の記述と作業名の候補を確かめる … その現場を見ている人なので、記述が実際と合っているかがすぐ分かります
2. 比較不能のものを撮り直す … 理由が angle_shift なら、撮影位置の目印から見直します
3. 所長が進捗を判断する … 実際に遅れているのか、写っていないだけなのかを決めます
4. 所見を確定する … note_draft を直して確定します。出来高の入力は従来どおり人が行います

1番目を所長が兼ねないでください。 20現場を横に見る人が1枚ずつ記述を確かめると、第10章の14分には収まりません。「変化と出たが実際は変わっていなかった」が特定の撮影位置に偏るなら、画角か対応表に原因があります。

例外に対処する

上から4行までで、比較不能の大半を占めます。 どれもAIの精度ではなく、撮り方と現場の状況の問題です。

記録を残す

• 元の写真と、撮影日時・天候・時刻帯・撮影位置ID
• 人物を塗りつぶした後の画像（生成AIへ実際に渡したもの）
• Azure AI Vision が返したJSONの全文（tagsResult、objectsResult、peopleResult、denseCaptionsResult）
• 生成AIが返したJSONと、そのとき参照した工程表の版と対応表の版
• 予定との照合の結果（一致／不一致／判定不能）と、人が判定を覆した記録
• 撮影位置ごとの比較不能率と、その理由の内訳

工程表の版を残すのが、後から効いてきます。 工程表は組み替えられるため、当時どの予定と突き合わせたのかが残っていないと、過去の「予定と違う」の意味が分からなくなります。 比較不能率は、撮影の標準化が進んだかどうかの物差しです。