公園の遊具を毎月点検するときに撮った写真から、錆・破損・ボルトの緩みの兆し・地面のえぐれの候補を見分けて、点検表の下書きと修繕の優先度を出す

処理の起点を決める

毎晩、その日に保存された写真をまとめて処理します。 時間主導型トリガーを夜に動かし、その日に新しく写真が入った遊具のフォルダを拾います。巡回の担当が夕方に事務所へ戻ってから保存しても、翌朝には点検表の下書きができています。

写真を保存したその場で処理する形にはしません。 理由は2つあります。1つは、AIの答えが現地の判断を急がせる形にしたくないこと。使用を止めるかは現地で決めます。もう1つは、1基の写真が3〜5枚そろってから比べたいことです。途中の枚数で処理すると、地面の写真が無いまま「地面は見えない」と出ます。

1回の実行は6分までです。 1日に40〜50基、1基に1回の呼び出しなら、1基ずつ処理して、時間が足りなければ残りを次の起動に回します。 処理を終えた遊具は、入力表に「処理済み」の印を付けます。印の無い遊具の数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、撮る角度の決まりです。 「ぶらんこの吊り金具の上部を、支柱の横から見上げて撮る」のように、台帳に角度を文で書き、見本の写真を1枚付けます。 角度がそろわないと、前回との比較が成り立ちません。

材質を台帳に持たせるのは、着眼点が変わるためです。 鋼製なら錆と塗装の剥がれ、木製なら腐朽とささくれ、樹脂なら割れと色あせが中心になります。材質に合わせて、AIに渡す着眼点の一覧を切り替えます。

現地の点検の結果は、写真と必ず組にします。 触診でぐらつきがあった遊具は、写真に何も写っていなくても優先度が上がります。 写真だけで優先度を決めると、いちばん危ない「見た目は普通だが揺れる」遊具が低く出ます。

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

Apps Script が、次の順に集めます。

写真のファイル名に、遊具の番号と角度の記号を入れる決まりにします。 例えば P0123-03_A2_20261008.jpg なら、公園123の3番目の遊具の、角度A2です。タブレットのカメラで撮ったあとに名前を付け直すのは手間なので、角度ごとに保存先のフォルダを分ける形でもかまいません。 どちらかに決めて、全班でそろえます。

前回の写真は、同じ角度の記号で引きます。 前回の写真が無い遊具（新設、角度の追加）は、比較なしで今回の状態だけを答えさせ、no_baseline の印を付けます。

AIへ渡す前に整形する

1. 枚数の確認 … 台帳の角度の数と、写真の枚数が合うかを見ます。足りなければ「撮り漏れ」として記録します
2. 写りの確認 … 暗すぎる写真、ぼけた写真、逆光で白く飛んだ写真は、比べずに「撮り直し」とします
3. 向きのそろえ … タブレットの縦横の向きの情報で、写真の向きを正しくします
4. 大きさのそろえ … 長い辺を決めた大きさにそろえます。ボルトの頭が見分けられる大きさを、最初に試して決めます
5. 人が写っている写真の扱い … 子どもや利用者が写っている写真は、撮らない決まりにしたうえで、写り込んだものは比べずに撮り直しにします
6. 着眼点の切り替え … 遊具の種類と材質から、渡す着眼点の一覧を選びます

5番目は、この題材で特に大事です。 公園の遊具には子どもがいます。巡回の担当には、利用者がいるときは撮らずに待つか、その遊具を後回しにするよう決めます。 写り込んだ写真は、AIに送らずに撮り直します。

4番目の大きさは、費用にも効きます。 Gemini API は、縦横とも384ピクセル以下の画像を258トークンで数え、それより大きい画像は768×768の区画に分けて区画ごとに258トークンで数えます。大きすぎる写真は費用を増やすだけで、ボルトの頭が見分けられれば足ります。

AIに処理させる

させるのは、角度ごとに今回と前回の写真を比べ、着眼点ごとに異常の候補があるかと、前回からの変化を答えることだけです。 着眼点は、国土交通省の指針の日常点検の着眼点の例から、写真で見えるものを選んでいます。

loose_sign は「緩んでいる」とは答えさせません。 ボルトが緩んでいるかは、写真では分かりません。分かるのは、緩みに伴って現れやすい見た目（ナットが無い、ずれた跡、錆汁）だけです。 名前に「兆し」と付けているのはそのためで、確かめるのは現地の触診です。

前回からの変化は4つで答えさせます。

指示内容を固定する

あなたは公園の遊具の日常点検で、撮影した写真を見る担当の補助です。
同じ遊具を同じ角度から撮った写真を2枚ずつ渡します。
1枚目は前回の点検、2枚目は今回の点検の写真です。

【この遊具の情報】
遊具の種類：{equipment_type}　材質：{material}
角度ごとに見る部分：{angles}

【着眼点】
- rust ........ 錆、塗装の剥がれ、木材の腐朽の色
- damage ...... ひび、割れ、部材の欠け、手すり子・踏み板などの消失
- loose_sign .. ボルト・ナットの脱落、頭の浮き、座金のずれ、ボルトの周りの錆汁
- ground ...... 着地面やぶらんこの下のえぐれ、基礎の露出、危険物

【finding の選び方】（2枚目について）
- none ........ その着眼点の異常の候補が見当たらない
- found ....... 異常の候補がある
- uncertain ... 影・汚れ・小ささで、候補かどうか決められない
- not_visible . その部分が写っていない
迷ったときに none を選ばないでください。

【change の選び方】（1枚目と比べて）
new / worse / same / better のどれか。1枚目が無いときは no_baseline。

【厳守事項】
- loose_sign は見た目の兆しだけを答えてください。ボルトが緩んでいると書かないでください。
- 使用を止めるべきか、修繕すべきか、危険かどうかを書かないでください。
- ぐらつき、きしみ、音について推測しないでください。
- 写真に人が写っていても、人について何も書かないでください。
- found と uncertain のときは、2枚目の中の位置を box_2d で返してください。
- note には、判断の手がかりにした見た目を短く書いてください
  （例：「支柱の根元の塗装が前回より上まで剥がれている」）。

「ボルトが緩んでいると書かない」を明記しないと、AIは書きます。 ナットの周りに錆汁があれば、それらしい説明として「緩みが疑われる」から「緩んでいる」へ言い切りがちです。点検表に「緩み」と残ると、触診で確かめていないのに確かめたように読めます。

「危険かどうかを書かない」も同じ理由です。 AIの文に「危険」とあると、職員はその言葉に引っ張られます。危険の判断は、現地の結果と規則と人で行います。

出力形式を固定する

構造化出力で、遊具ごとに次の形のJSONを受け取ります。

{
  "equipment_id": "P0123-03",
  "angles": [
    {
      "angle_id": "A2",
      "checks": [
        { "item": "rust | damage | loose_sign | ground",
          "finding": "none | found | uncertain | not_visible",
          "change": "new | worse | same | better | no_baseline",
          "box_2d": [0, 0, 0, 0],
          "note": "" }
      ]
    }
  ]
}

finding と change を enum にして、決めた値以外を返させません。 Gemini API の構造化出力では、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 Apps Script で、角度の数が台帳と合うか、none なのに change が worse になっていないかを確かめ、合わないものは uncertain として扱います。

優先度の案は、Apps Script が規則で決めます。

1行目の最初の条件が、写真より現地の結果を上に置く仕組みです。 現地でぐらつきがあれば、写真が何であれ「高」です。

「確認が要る」を「低」より上の扱いにしているのは、見えなかったものを良いほうに倒さないためです。 地面が写っていない遊具を「変化なし」に混ぜると、えぐれが進んでいても誰も気づかないまま翌月になります。 見えなかった着眼点は、撮り直すか、次の巡回で寄って撮る角度を足します。規則の閾値は係で決め、変えたら点検表の欄外に規則の版を残します。

点検表の下書きは、着眼点ごとの文にします。

【P0123-03 ぶらんこ（鋼製・設置1998年）】優先度の案：中
 錆・腐食　：あり（前回より広がる）支柱A2の根元の塗装の剥がれが上へ広がる
 破損・欠損：なし
 緩みの兆し：あり（新たに）吊り金具B1のナットの周りに錆汁
 地面　　　：なし
 現地の点検：ぐらつきなし／異音なし／使用中止なし

システムへ連携する

点検表には「下書き」と「確定」の列を分けます。 Apps Script が書くのは下書きの列だけで、確定の列は職員だけが書きます。 修繕の検討に使うのは確定の列です。

遊具の台帳は読み取りだけです。 写真から遊具の種類が違うように見えても、台帳は書き換えません。台帳を直すのは、現地で確かめた職員です。

人が確認する

すべての遊具で、職員の確定を通します。 ただし、写真を開く遊具は優先度の案で絞ります。

1. 「高」を最初に見る … 写真と note を見て、現地で使用を止めたかを入力表で確かめます。止めていないのに「高」なら、巡回の班に電話して現地を見直してもらいます
2. 「中」を見る … 下書きを直して確定し、修繕の候補に入れます
3. 「確認が要る」を片付ける … 撮り漏れ・撮り直しを、翌月の巡回の前に班へ伝えます
4. 「低」「変化なし」は一覧で確定する … 下書きを流し見て、まとめて確定します

目標は、900基をならして1基2分です。 「変化なし」と「低」は一覧で数十秒、「高」と「中」は写真を開いて数分かかります。「高」「中」が2割前後という想定でならすと2分です。

最初の2か月は、これまでの見比べと並べて動かします。 職員が見つけた異常に、AIが候補を出していたかを1件ずつ照らします。出していなかった異常は、撮る角度か着眼点の書き方を直す材料です。

例外に対処する

「月末までに残れば職員が従来どおり見る」を決めておきます。 機械が処理できなかった遊具が、点検表から抜けたまま月を越すことがいちばん困ります。

記録を残す

• 遊具ごとの今回の写真と、比べた前回の写真の名前
• 着眼点ごとのAIの答え（finding、change、box_2d、note）
• 現地の点検の結果と、使用中止の有無
• 優先度の案と、職員が確定した優先度、直した内容
• 撮り漏れ・撮り直しの記録
• 修繕の実施日と、その後の点検での better の確認

写真は、点検の記録として決めた期間残します。 指針では、点検記録書は安全点検を行った時点の状況と点検の結果を記録し保管するものとされています。写真とAIの答えと職員の確定を組にして残せば、後から「いつから錆が進んでいたか」を遡れます。

職員が直した内容は、着眼点の書き方を直す材料になります。 「木製の遊具の rust を職員が毎回消している」なら、材質ごとの着眼点の一覧を見直します。