住民から届く道路・公園の不具合の通報を写真で見分けて、担当課と緊急度を振り分ける

処理の起点を決める

フォームの送信を起点にします。 Apps Script のフォーム送信時のトリガーで1件ずつ動かし、定時にまとめて処理することはしません。まとめると、危険な通報が次の実行まで待たされます。

最初に動くのはAIではなく、危険の確認です。 送信直後に、次の2つを規則だけで見ます。

どちらか1つでも当たれば、担当者へ即時に通知します。 語句の一覧は広めに取ります。空振りの通知は数秒で閉じられますが、見逃しは取り返せません。この通知の後で、同じ通報をAIの処理にも回します。

入力データを集める

質を決めるのは、所管の対応表です。 「市道の舗装は道路管理の課」「公園の中の遊具は公園の課」「国道・県道は市の外へ回付」といった組み合わせを、窓口の担当者が知っている形のまま一覧にします。AIの読み取りがどれほど正しくても、この表が無ければ担当課は決まりません。

この表は一例です。 同じ街路灯でも、市が持つものと自治会が持つものがあるなど、実際の区分は自治体ごとに違います。 窓口の担当者が回付のたびに迷っている組み合わせを、行として足していきます。

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

写真はフォームの添付ファイルとして Google ドライブに入ります。 スクリプトはそのファイルを読み、Gemini API に渡します。写真が3枚で合計が大きいときは Files API に上げ、それ以外はリクエストに直接埋め込みます。

位置は、緯度経度と住所の2通りで届きます。 場所の区分（市道／国道・県道／公園の中／その他）を決めるのは、庁内の地図システムの道路・公園の区域の情報です。この照合をどう組むかは、各自治体の地図システムに応じた個別実装になります。 最初は、対応表に「路線名」「公園名」の列を持たせ、住所の文字列で引く形でも始められます。

直近の通報は、同じスプレッドシートから引きます。 位置が近く、対象物が同じで、状態が未完了のものだけを取り出します。

AIへ渡す前に整形する

1. 写真の有無と形式の確認 … PNG、JPEG、WEBP、HEIC、HEIF 以外は、担当者へ回して形式を確かめます
2. サイズの確認 … 直接埋め込むときはリクエスト全体で20MBまで。超えるときは Files API に上げます
3. 向きの確認 … 公式ページは、画像の向きが正しいかを確かめるよう勧めています。横倒しの写真は、損傷の読み取りを誤らせます
4. 位置の正規化 … 緯度経度は小数の桁をそろえ、住所は町名までを取り出します
5. 説明文の整形 … 電話番号やメールアドレスが書かれていれば、AIに渡す前に伏せます
6. 近くの通報の抽出 … 直近の通報から、同じ町名または近い緯度経度のものを取り出します

5番目は、住民の連絡先をAIに渡さないためです。 通報の中身を判断するのに連絡先は要りません。

写真は、長い辺を決めた大きさまで縮めてから渡すことも検討します。 スマートフォンの写真はそのままだと数MBあり、区画の数に応じてトークンが増えます。ただし、縮めすぎると側溝の蓋のずれや細いひび割れが見えなくなります。 第8章の30件で、縮めた写真でも読み取りが変わらない大きさを確かめてから決めます。

写真が複数あるときは、まとめて1回で渡します。 1枚目が遠景、2枚目が近景という送り方が多く、両方を見て初めて対象物と損傷が分かるからです。

AIに処理させる

させるのは、写真と説明から4つを読み取ることだけです。

危険の程度だけは「迷えば上」にします。 他の項目は迷えば unknown にしますが、危険の程度を unknown にすると、後段の規則で低く扱われる恐れがあるからです。

3行目がいちばん大事です。 写真は一瞬を切り取ったもので、夜の暗さや雨の日の水たまりは写りません。住民の申告より低い緊急度を、AIの判断で付けることは認めません。

指示内容を固定する

あなたは市役所で、住民から届いた道路・公園の不具合の通報を受け付ける立場です。
写真と説明文だけを見て、写っている内容を決まった形で返してください。

【読み取る項目】
1. object_type：写っている対象物を選択肢から1つ選ぶ
2. damage_type：損傷の種類を選択肢から1つ選ぶ
3. danger_level：high / medium / low
   - high …… 車・自転車・歩行者の通行、または遊具の利用に、すぐ危険がある
     （例：車輪が落ちる大きさの穴、道をふさぐ倒木、外れた側溝の蓋、壊れた遊具）
   - medium … すぐの危険はないが、放置すると危険になる
   - low …… 見た目の不具合で、危険はない
4. privacy：人の顔、車のナンバープレートが判別できる状態で写っているか

【厳守事項】
- 写真で判断できない項目は unknown にしてください。推測で埋めないでください。
- danger_level で迷ったときは、必ず上の段階を選んでください。
- 説明文に危険だと書かれている場合は、写真で危険に見えなくても
  danger_level を low にしないでください。
- 担当課、補修の要否、補修の時期は書かないでください。
- 写真の景色から場所を推測しないでください。
- 説明文に書かれていない事実を書き足さないでください。
- evidence には、判断の根拠にした写真の特徴を短く書いてください。
- 顔またはナンバーが写っていれば、その位置を枠で返してください。
  枠は [ymin, xmin, ymax, xmax] で、0〜1000に正規化した値にしてください。
- 道路・公園の不具合の写真でないと判断した場合は、object_type を
  not_applicable にしてください。

【説明文】{description}
【住民が選んだ危険の設問】{danger_answer}

指示を画像の前に置きます。 公式ページは、画像1枚とテキストを使う場合、テキストの指示を画像の前に置くよう勧めています。

「説明文に危険と書かれていれば low にしない」を明記しないと、写真だけで判断します。 写真が遠く小さな穴にしか見えなければ low を返し、住民が一番伝えたかったことが消えます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "report_id": "",
  "object_type": "pavement | gutter | curve_mirror | street_light | guardrail | playground | tree | sign | other | unknown | not_applicable",
  "damage_type": "hole_crack | lid_shift | misaligned | not_lit | broken | fallen | other | unknown",
  "danger_level": "high | medium | low",
  "evidence": "",
  "privacy": {
    "contains_face": "yes | no | uncertain",
    "contains_plate": "yes | no | uncertain",
    "boxes": [ { "label": "face | plate", "box_2d": [0, 0, 0, 0] } ]
  },
  "damage_box": [0, 0, 0, 0]
}

1つ目の理由は、選択肢（enum）で縛れることです。 構造化出力では文字列に enum を指定できます。対象物が決まった語で返るので、所管の対応表をそのまま引けます。 自由文で返すと「アスファルトの穴」「道路のくぼみ」のように言い方が散り、表と照らせません。

2つ目は、AIが埋める項目と規則が決める項目を分けられることです。 このJSONに担当課の欄はありません。スクリプトが後から department と final_danger を足します。

3つ目は、値を確かめられることです。 公式ページのとおり、構文が正しくても値が正しいとは限りません。box_2d が0〜1000の範囲にあるか、enum の外の値が無いかをスクリプトで確かめ、外れたものは人へ回します。

システムへ連携する

回付のメールは自動で送りません。 スクリプトが作るのは下書きと宛先の候補までです。国道・県道の管理者への回付は市の外への連絡なので、特に人が送ります。

人が確認する

1. 危険の通知を最初に見る … 即時に通知されたものは、AIの結果を待たずに写真を開き、担当課へ電話で連絡するかを決めます
2. 担当課の候補を確かめる … 写真・位置・対象物の読み取りを並べて見て、候補が合っていれば回付します
3. 重複の候補を確かめる … 同じ案件と判断すれば、既存の通報にまとめ、住民には受付済みと連絡します
4. 写り込みの印があるものは、回付の前に扱いを決める … 担当課に渡す写真を加工するか、そのまま庁内で扱うかを決めます
5. 読み取りを直したら記録する … どの項目を、何から何に変えたかを残します

1番目を「AIの結果を見てから」にしないでください。 通知の意味は、AIの処理を待たないことにあります。

確認の画面は、1行に写真の縮小版・対象物・損傷・最終の緊急度・担当課の候補・重複の候補を並べます。 候補が合っていれば行の「回付」を押すだけにし、合っていないものだけ写真を開く形にすると、第10章の5分に収まります。

例外に対処する

7行目を放っておかないでください。 担当課が引けなかった場所は、対応表の穴です。同じ場所が2度出たら、表に1行足します。

記録を残す

• 通報の原文（写真・位置・説明・危険の設問）と受付日時
• Gemini API に渡した指示とJSONの全文、呼び出した日時
• 危険の通知を出したか、何に当たって出したか（設問か語句か）
• 担当課の候補と、人が回付した先。両者が違ったときの記録
• 重複としてまとめた通報の組み合わせ
• 写り込みの印と、写真の扱いをどう決めたか

3つ目は、見逃しを後から調べるためです。 危険な通報に通知が出なかった場合、設問に答えていなかったのか、語句が一覧に無かったのかで直す場所が違います。

Files API に上げた写真は48時間で消えます。 写真の原本は Google ドライブの側に残し、Files API のほうは使い終わったら削除します。

4つ目の「候補と回付先が違ったとき」の記録は、月に1回まとめて読みます。 同じ対象物で同じ取り違えが続くなら選択肢の定義を、同じ場所で続くなら対応表を直します。直す場所が記録から決まるように、違いの理由を一言添えて残します。