建設現場の配筋の写真を配筋図の指定と照らし、黒板の記載と食い違う写真と撮り漏れを配筋検査の前に拾う

処理の起点を決める

15分おきの時間主導型のトリガーで、共有のフォルダを見回ります。 Apps Script には、ドライブにファイルが増えたことを直接受けるインストール型のトリガーがありません。時間主導型のトリガーで前回の見回りの後に増えた写真を拾い、1枚ずつ処理して、処理した写真のIDを一覧に記録します。

1回の実行は6分までです。 検査の前日に数百枚が一度に入っても、1回の実行で処理する枚数を決めておき、残りは次の15分に回します。 トリガーの1日の合計の実行時間は Google Workspace のアカウントで6時間までなので、1日に処理できる枚数の目安を先に見積もります。

もう1つのトリガーは、毎日15時の撮り漏れの確認です。 工程表から翌日に配筋検査がある検査ロットを拾い、撮影計画と届いた写真を突き合わせます。時間主導型のトリガーは指定の時刻から1時間の幅の中で動くので、現場が撮り直せる時間が残るよう、夕方ではなく15時にします。

インストール型のトリガーは作った人のアカウントで動きます。 品質管理部の共用のアカウントで作り、担当者の異動で止まらないようにします。

入力データを集める

質を決めるのは部材リストです。 図面のPDFをそのままAIに渡して「この写真が合っているか」と聞くと、AIが図面のどの行を見たかが毎回変わります。 符号で行を引くのはスクリプトの仕事にし、AIには写真と黒板から読めたものだけを書かせます。

表の値は図面から人が書き写し、別の人が読み合わせます。 ここを誤ると、正しい写真が全部 review に出ます。部材リストの版と、図面の改訂の日も列に持たせます。

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

写真の現場・階・工区は、フォルダの構成から取ります。 工事写真のアプリから書き出すときに、検査ロットごとのフォルダに入れる決まりにします。撮影日時は写真のファイルの情報から取ります。

工事写真のアプリが黒板の記載を項目として書き出せる場合は、そちらを優先します。 書き出された項目があれば、1回目の呼び出しは読み取りではなく、写真に写る黒板と書き出された値が同じかの確かめに変えられます。書き出せない場合だけ、写真の黒板を読みます。

符号で行が引けないときは、そこで止めます。 黒板の符号が部材リストに無い場合、黒板の書き間違いか、部材リストの漏れのどちらかです。どちらかを決めずに review に回します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG などの対応する形式であることを確かめます
2. 作業用の写しを作る … 元の写真はそのまま残し、縮小や回転は写しにだけ行います
3. 大きさの確認 … 写しと指示を合わせて20MBを超えないことを確かめます
4. 向きの確認 … 写しの向きをファイルの情報に合わせます。黒板が横倒しのまま送ると読み違えます
5. 重複の確認 … 同じ符号の同じ項目の写真が複数あれば、すべて残し、確認の一覧では1行にまとめます

2番目を軽く見ないでください。 写真編集は認められていません。AIに送るための加工が元の写真に及ぶと、検査や電子納品に使えない写真になります。 作業用の写しのフォルダを分け、名前の先頭に印を付けます。

AIに処理させる

させるのは2つの段階です。 黒板の読み取りと、写真の中の主筋の本数とスケールの目盛の読み取りです。黒板と部材リストを照らすのは、間に挟むスクリプトです。

1つ目の段階：黒板を読む

2つ目の段階：写真を読む

mismatch と not_visible の区別が、この構成でいちばん大事です。 柱の主筋は4面に並び、1枚の写真では手前の面しかはっきり見えません。「見える本数は8本」とだけ書かせ、奥の面に隠れている可能性があれば not_visible にします。 現場に「本数が違う」と返すのは、はっきり違うと分かるときだけです。

3行目がいちばん起きやすい失敗です。 「柱なので4面とも同じ本数だろう」と見えない面の本数を足すと、黒板と同じ12本が返ってきて、本当に1本足りない柱を見逃します。

指示内容を固定する

あなたは建設会社の品質管理部で、配筋の写真を検査の前に確かめる立場です。
写真に写っているものだけを見て、次の2つを返してください。推測で埋めないでください。

【1. 黒板の記載】
黒板に書かれた次の項目を、書かれた文字のまま写してください。
部位、符号、主筋（径と本数）、帯筋またはあばら筋（径と間隔）、
かぶり厚さの設計値、かぶり厚さの実測値、間隔の実測値
読めない項目は value を空にし、status を unreadable にしてください。
図面や一般的な配筋の値で補わないでください。

【2. 写真の配筋】
- 見える主筋の本数を数え、observed_count に入れてください。
  手前の鉄筋の陰に隠れている可能性がある場合は、見えない分を足さず、
  status を not_visible にしてください。
- スケールや定規が写っている場合は、当たっている箇所の目盛の値を
  scale_reading に読んでください。目盛が読めない場合は空にしてください。
- 写真の大きさや画素から寸法を見込まないでください。目盛だけを読んでください。
- 黒板の本数と見える本数、黒板の実測値と目盛の値を比べ、
  match（同じ）／mismatch（はっきり違う）／not_visible（写真では判断できない）
  のどれかを付けてください。迷ったら not_visible です。
- mismatch または数えた範囲には、位置を box_2d に [ymin, xmin, ymax, xmax] で
  0〜1000 に正規化して入れてください。
- evidence には、判断の根拠にした見た目を短く書いてください。
- 配筋が正しいか、検査に通るかは書かないでください。

【写真の情報】現場:{site} 階:{floor} 工区:{zone} 撮影日時:{taken_at}

「図面や一般的な配筋の値で補わない」を明記しないと、読めない黒板が埋まります。 「D1?」と半分読めた文字を、よくある「D13」として返すことがあります。埋まった値は部材リストと一致してしまい、黒板の不備が消えます。

部材リストの値を指示に入れていないのも意図してのことです。 「設計は12本」と知らせると、AIは12本に寄せて数えます。比べる相手を知らせずに読ませ、照らすのはスクリプトにします。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力では、response_format に mime_type: "application/json" と JSON Schema を渡し、status を enum で限ります。公式の案内では、出力がJSONとして正しくても、値はアプリケーションの側で必ず検証するようにとされています。

{
  "photo_quality": "good | retake",
  "board": {
    "member": { "value": "C1", "status": "ok | unreadable" },
    "main_bar": { "value": "12-D25", "status": "ok | unreadable" },
    "hoop": { "value": "D13@100", "status": "ok | unreadable" },
    "cover_design": { "value": "", "status": "ok | unreadable" },
    "cover_measured": { "value": "", "status": "ok | unreadable" }
  },
  "photo_checks": [
    { "item": "main_bar_count", "observed_count": 8, "scale_reading": "",
      "status": "match | mismatch | not_visible", "evidence": "",
      "box_2d": [0, 0, 0, 0] }
  ]
}

1つ目の理由は、AIが読んだ値と、部材リストとの照合を別の層に置けることです。 board の値をスクリプトが部材リストの行と比べ、spec_check を足します。

2つ目は、スクリプトで検証できることです。 box_2d が0から1000の範囲か、mismatch に box_2d があるか、observed_count が0以上の整数かを確かめます。項目が欠けていれば review にします。 読み飛ばしたまま pass になるのを防ぎます。

3つ目は、集計に使えることです。 現場ごとに retake と黒板の書き間違いの数を数えれば、どの現場の撮り方を直せばよいかが、検査を待たずに分かります。

システムへ連携する

工事写真のアプリと電子納品のデータには書き込みません。 この構成が出すのは、検査の前の確認の結果までです。黒板の書き直しや撮り直しは現場が行い、新しい写真がまたフォルダに入ってきます。

呼び出しの回数は1日の上限の範囲です。 外部への呼び出しは Google Workspace のアカウントで1日100,000回までで、1枚あたり2回の呼び出しなら、月1,200枚は十分に収まります。

人が確認する

品質管理部の担当は、review と retake の行と、撮り漏れの一覧だけを開きます。 確認の一覧の各行には、写真へのリンク、黒板の読み取りの結果、部材リストの行、写真に重ねた枠が並びます。

1. 黒板と部材リストの食い違いを見る … 黒板の書き間違いか、部材リストの写し間違いかを確かめます
2. mismatch の枠を見る … 数えた範囲と目盛の箇所が正しいかを写真で確かめます
3. not_visible を見る … 撮る角度を変えて撮り直してもらうか、検査で見るかを決めます
4. 撮り漏れを返す … 検査ロットの撮り漏れの一覧を、工事主任にまとめて送ります
5. 判定を覆したら記録する … mismatch を match に直したら、その理由を短く残します

1番目で部材リストの側の誤りが見つかったら、すぐに表を直します。 表の誤りは、同じ符号のすべての写真を review に出し続けます。直した日と直した人を、部材リストの列に残します。

pass の写真も、検査ロットごとに数枚を抜き取って見ます。 AIが見逃した食い違いは review の確認だけでは見つからないので、抜き取りが見逃しを知る唯一の手がかりです。

配筋そのものの確認は、検査員と工事監理者が行います。 この構成の確認は、検査に出す写真と黒板の不備を減らすところまでです。

例外に対処する

上から2行目までが大半を占めます。 どちらもAIの問題ではなく、撮り方の決まりの問題です。 黒板を置く位置とスケールを当てる位置を、写真の手本付きで現場に配ると、retake が減ります。

記録を残す

• 元の写真（手を加えないもの）と、作業用の写し
• 指示の全文と、返ってきたJSONの全文
• 照らした部材リストの版と、引いた行
• verdict と、担当者が覆した項目とその理由
• 現場に返した撮り直し・書き直し・撮り漏れと、その日時
• 現場ごとの retake と黒板の書き間違いの数の推移

照らした部材リストの版を残すのは、図面が改訂されるからです。 改訂の前に撮った写真を後から見直すと、どの版で照らしたかが分からなければ、その指摘が正しかったかを判断できません。

覆した理由は、短い選択肢で残します。 「隠れていた」「目盛の読み違い」「部材リストの誤り」「黒板は正しい」の4つ程度にしておくと、月末に数えられます。「部材リストの誤り」が多ければ、表の読み合わせの手順を直します。