公園樹・街路樹の巡回で撮った写真から、枯れ枝・ぶら下がり枝・幹の空洞・キノコ・傾きなど倒木と落枝の兆候の候補を拾い、樹木医の診断と剪定に回す順番をつける

処理の起点を決める

写真が地区のフォルダに入ったことを起点にします。 Make の Watch Files in a Folder が新しい写真を拾い、シナリオが動きます。巡回は昼間に行われ、写真はその日の夕方までにまとまって入るので、シナリオの実行の間隔は1時間ごとで足ります。

1本の木の写真がそろってから処理します。 決まりは「全体1枚＋根元1枚、気になる部分は寄りを足す」です。ファイル名を「樹木の番号_撮影日_全体／根元／寄り」とし、同じ樹木の番号の全体と根元がそろった木から処理します。根元の写真が無い木は、「根元の写真が無い」として下書きに出します。

地区の巡回を終えた日を、巡回の担当が報告します。 その翌日に、台帳で重点にした木のうち、写真が1枚も入っていない木を一覧にします。撮り漏れは、点検の漏れです。点検の結果より先に、この一覧を職員に見せます。

台風や大雨の後の臨時の巡回でも、同じフォルダに入れれば同じ流れで動きます。 臨時の巡回の写真は、ファイル名に「臨時」の印を付け、順番の案を通常の巡回より先に並べます。

入力データを集める

質を決めるのは、樹木台帳の「区域の種類」です。 国の公園の樹木の指針は、エントランス、園路沿い、広場、利用者の多い施設の周り、道路や民家に接している外周を、安全確保の重要度の高い区域として重点化することを挙げています。同じ枯れ枝でも、園路の真上と樹林の奥では急ぎ方が違います。 台帳にこの区分が無いと、順番が決まりません。

樹種は、AIに渡します。 街路樹のガイドラインには、画像を使う技術の留意点として対象の樹種が限られることが挙げられています。樹種を渡しておくと、落葉期に葉が無いことを「枯れている」と答える誤りを減らせます。 一方、前回の記録はAIに渡しません。前回「キノコあり」と渡せば、今回も見つけようとして、無いものを答えることがあります。

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

Make のシナリオが、次の順に集めます。

AIに渡すのは、写真と樹種と撮影の月だけです。 撮影の月を渡すのは、落葉期か展葉期かで見えるものが変わるからです。国の公園の樹木の指針は、展葉期には枯損枝を見つけやすく、落葉期には幹や枝の空洞や腐朽を見つけやすいとしています。

写真は Download a File で取り出したものを base64 にして、Make an API call の本文に入れます。 1本あたり2〜3枚なので、リクエスト全体20MBの上限には通常届きません。本文の response_format に後で示す出力形式のスキーマを入れ、API キーは Make の接続の側に持たせて、シナリオの本文には書きません。

位置と区域は、AIに渡しません。 区域の重要度はシナリオが規則で使うもので、AIに「園路沿い」と渡すと、兆候を大きめに答えやすくなります。 写真の判定と区域の重みを分け、合わせるのはシナリオです。

AIへ渡す前に整形する

1. 枚数と名前の確認 … 全体と根元がそろい、樹木の番号が台帳にあるかを見ます
2. 向きの補正 … 写真の向きの情報で、横倒しの写真を正しくします
3. 写りの確認 … 逆光で樹冠が黒くつぶれた写真、ぶれた写真は「撮り直し」とします
4. 人の写り込みの確認 … 公園の利用者が写っている写真は、AIに送らず撮り直しにします
5. 大きさの調整 … 長辺が大きすぎる写真は縮めます。寄りの写真は、キノコや亀裂が潰れない大きさを残します
6. 前回の答えの取り出し … 同じ木の前回の答えを、変化の判定のために取り出しておきます

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

3番目の逆光は、樹冠を見上げて撮ると必ず起きます。 枯れ枝は、空を背景にした黒い枝として写ると見分けにくくなります。撮る向きを太陽を背にする向きに決め、樹冠は少し離れて撮る決まりにします。

AIに処理させる

させるのは、着眼点ごとに、次の答えを返すことだけです。

found と uncertain のときは、写真の番号と box_2d を返させます。 職員は印の付いた位置を見るだけで済みます。

4行目がいちばん起きやすい失敗です。 キノコの写真を見せると、AIは種類の名前を挙げます。腐朽力の強い種類と挙げれば順番が跳ね上がり、弱い種類と挙げれば下がります。 どちらも写真だけでは確かめられません。キノコは「ある」までにし、種類は樹木医が見ます。

指示内容を固定する

あなたは、公園樹・街路樹の巡回で撮った写真から、点検の着眼点ごとに見えるものを書き出す立場です。
同じ木の写真を複数枚渡します。1枚目は木の全体、2枚目は根元、3枚目以降は気になる部分に寄った写真です。
写真に見えるものだけを答えてください。

【この木の情報】樹種：{species} 撮影の月：{month}

【着眼点】
deadwood（枯れ枝）、hanging_branch（ぶら下がり枝）、lean（不自然な傾斜、根元の地面の盛り上がりや亀裂）、
cavity（幹の開口空洞）、fungus（キノコ）、crack（幹の亀裂、樹皮の欠損）、
support_damage（支柱・保護板の食い込み）、root_conflict（根上り、舗装や構造物への干渉）

【着眼点ごとに答えること】
- status：found / none / not_visible / uncertain
- found と uncertain のときは、photo_no と box_2d と、見えたものを短く note に
迷ったときに none を選ばないでください。

【厳守事項】
- 葉や他の木に隠れて見えない部分は not_visible にしてください。見えない部分を none にしないでください。
- この木が危険かどうか、伐るべきか、剪定すべきかを書かないでください。
- 空洞が幹の芯まで達しているかを推測しないでください。見えている開口だけを答えてください。
- キノコの種類の名前を書かないでください。あるかどうかと位置だけを答えてください。
- 落葉期に葉が無いことを、枯れているとして扱わないでください。樹種と撮影の月を参考にしてください。
- 写真に写っている人について、何も書かないでください。

「見えない部分を none にしない」を明記しないと、AIは none を選びます。 写真に枯れ枝が写っていなければ、「枯れ枝なし」と答えるのが自然だからです。葉に隠れた樹冠の上の枯れ枝は、まさに見落としたくない兆候です。 not_visible を用意し、迷ったときにそれを選ばせます。

「落葉期に葉が無いことを枯れとして扱わない」は、冬の巡回のために入れています。 落葉した広葉樹の枝は、写真では枯れ枝とよく似て見えます。

出力形式を固定する

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

{
  "tree_id": "K07-0412",
  "checks": [
    { "item": "deadwood | hanging_branch | lean | cavity | fungus | crack | support_damage | root_conflict",
      "status": "found | none | not_visible | uncertain",
      "photo_no": 1,
      "box_2d": [0, 0, 0, 0],
      "note": "" }
  ],
  "retake_needed": false
}

着眼点と状態を enum にして、決めた値以外を返させません。 Gemini API の構造化出力は、/v1beta/interactions の response_format に mime_type: "application/json" とスキーマを入れて指定し、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 シナリオで、8つの着眼点がすべて返っているか、found に box_2d があるかを確かめ、欠けていれば「確認が要る」にします。

区分は、シナリオが順番の規則の表から決めます。

ぶら下がり枝を区域にかかわらず「至急」にしているのは、わずかな風でも落ちるおそれがあり、速やかに除去するものとされているからです。 規則の中身は、公園緑地課が樹木医と相談して決め、表として持ちます。AIの答えが同じでも、規則を変えれば順番が変わるようにしておきます。

システムへ連携する

点検表には、下書きの列だけに書きます。 確定の列は職員が埋めます。樹木医への依頼や剪定の指示は、職員が確定した区分から出します。 シナリオから作業の指示を直接出すことはしません。

樹木台帳は読み取りだけです。 写真で「支柱が無い」と分かっても、台帳は書き換えません。台帳の直しは、現地を確かめた職員が行います。

人が確認する

すべての木で、職員の確定を通します。 写真を開く木は区分で絞ります。

1. 「至急」を最初に見る … 印の付いた位置を写真で確かめ、必要なら当日のうちに現地の確認と立入防止を手配します
2. 「早め」を見る … 樹木医の診断に回すかを決めます。予算の枠の中で、どの木から診てもらうかをここで決めます
3. 「見えない」をまとめる … 次の季節の巡回で見る木の一覧に入れます
4. 「次回に注意」と「兆候なし」は一覧で確定する … 下書きを流し見て、まとめて確定します

1番目を省かないでください。 「至急」は園路の上の枯れ枝やぶら下がり枝です。写真で確かめた時点で、現地の担当に連絡するまでを1つの手順にします。

目標は、1,200件をならして1本1.5分です。 「兆候なし」の木は一覧で数秒、「至急」「早め」の木は写真を開いて数分かかります。

確定した結果は、受託者にも返します。 職員が「撮り直し」や「見えない」にした木を地区ごとに数え、次の地区の巡回の前に、撮り方で直すところを受託者と確かめます。 受託者の担当が替わっても、撮り方がそろったまま続くようにするためです。

最初の2か月は、経験のある職員がこれまでどおり写真を見て、区分と並べます。 職員が気になると判断した木に、AIが兆候を出していたかを照らします。出していなかった木は、撮り方か着眼点の書き方を直す材料です。

例外に対処する

「未処理」と「見えない」を「兆候なし」に混ぜないでください。 混ぜると、見ていない木が見た木と同じ空欄になり、（d）の問題がそのまま残ります。

記録を残す

• 木ごとの写真と、撮影日、撮った担当
• AIの答え（着眼点ごとの状態・位置・メモ）
• 区分と、そのとき使った順番の規則の版
• 職員が直した区分と、確定した日
• 樹木医の診断の結果と、行った処置（剪定、立入防止、伐採）
• 「見えない」とした着眼点と、次に見る季節

点検表の下書きは、たとえば次の形にします。

【巡回の点検】K07 地区 2026-10-06（担当 ○○）
 K07-0412 ケヤキ 園路沿い   ぶら下がり枝 found（写真1 右上）→ 至急
 K07-0415 サクラ 外周       キノコ found（写真3 根元）前回なし → 早め
 K07-0420 クスノキ 広場     枯れ枝 not_visible（葉で隠れる）→ 見えない：落葉期に見る
 K07-0421 イチョウ 園路沿い すべて none → 兆候なし

国の公園の樹木の指針は、点検票などに写真や判定結果、措置の内容、次回の点検の時期を記録し、樹木の位置を示した図面と合わせることが望ましいとしています。 職員の異動に備えて記録を散逸させないことも重要とされています。この下書きと写真の対応が、そのまま異動の後の引き継ぎの材料になります。