第1回 和泉市で始まったAI×GISによる樹木管理DX

~AI樹木抽出から現地点検・ダッシュボードまで一体化したPoC実証~

はじめに

近年、公園樹木の老木化や倒木事故への対応が全国の自治体で課題となっています。

一方で、多くの自治体では、

  • 樹木台帳が整備されていない
  • 樹木本数が把握できていない
  • 樹種が分からない
  • 点検結果が紙やExcelで管理されている

など、維持管理の基礎となる情報整備が課題となっています。

今回ご紹介する和泉市でのPoC(実証実験)は、AIによる樹木抽出、GISによる台帳整備、スマートフォンによる現地点検、ダッシュボードによる維持管理を一体化した取り組みです。

「公園樹木が数千本から数万本ある自治体では、すべてを一度に点検することは現実的ではありません。」

本記事では、システムの機能紹介ではなく、自治体業務をどのような考え方でデジタル化したのかという「システム思想」を中心にご紹介します。


PoCの目的

今回のPoCは

AIで樹木を抽出することが目的ではありません。

目的は

AI抽出から台帳整備、現地点検、維持管理までを一つの業務として実現できるか職員が継続運用できる業務フローを構築すること

を検証することでした。

つまり

AI抽出

↓

現地確認

↓

樹木台帳整備

↓

現地点検

↓

ダッシュボード管理

↓

維持管理

という自治体業務全体を対象にしています。


AI樹木抽出

まず航空写真からAIにより公園樹木を抽出しました。

今回のPoCでは

約6万本

の樹木候補を抽出しています。

ここで重要なのは

AIは樹木候補を抽出するだけ

ということです。

危険木をAIが判定しているわけではありません。


AI樹種判定

現地で樹種が分からない場合には、

AI樹種判定アプリを利用することができます。

これにより

専門職員が少ない自治体でも

樹木台帳の整備を効率よく進めることができます。

ただし、

AI樹種判定は、専門知識を置き換えるものではなく、
現場職員の判断を支援するための補助機能です。

最終判断は職員が行います。


点検ロジックの思想

ここが今回のPoCで最も重要な部分です。

AIが危険度を判定するのではありません。

現場で確認した内容を基に、

GIS上で危険度を整理しています。

例えば

  • 幹の揺らぎ
  • 大きな亀裂
  • 根元異常を伴う傾斜
  • キノコ

など、

倒木事故につながる重要な兆候を入力します。

この考え方は、

国土交通省の樹木点検で重視されている

重大な異常を見逃さない

という思想に沿っています。


平均点ではない理由

例えば

19項目のうち18項目が問題なくても、

1項目が重大な異常なら

その樹木は危険木です。

そのため

本システムでは

平均点ではなく、

最も危険な項目を優先

して判定しています。

その結果、

外観評価

A~D

活力度

1~4

総合判定

A~D

が自動で表示されます。

点検ロジックは「AI任せ」ではない

今回構築した樹木点検システムは、AIが危険度を判定しているわけではありません。

AIは航空写真から樹木候補を抽出したり、樹種判定を支援したりする役割を担います。一方、樹木の健全性評価は、現場で職員が確認した結果を基に行います。

例えば、

  • 幹の揺らぎ
  • 樹幹の亀裂
  • 根元の異常を伴う傾斜
  • キノコの発生

など、倒木事故につながる重要な兆候を入力すると、その内容に応じて外観評価(A~D)が自動判定されます。

さらに、樹勢や樹形から活力度を評価し、最終的な総合判定(A~D)を表示します。

これは単純な平均点ではありません。

重大な異常が一つでも確認された場合は、その危険性を優先して判定する仕組みになっています。

この考え方は、国土交通省の樹木点検で重視されている「重大な異常を見逃さない」という考え方と整合するよう設計しています。


長所

① 重大な異常を見逃しにくい

平均点方式ではなく、最も悪い項目を優先して判定するため、

  • 大きな亀裂
  • 根元異常を伴う傾斜
  • 大きな揺らぎ

などが1項目でもあればD判定になります。

倒木事故防止という目的には非常に適しています。


② 点検者による判定のばらつきを抑えられる

「何となく危険そう」ではなく、

項目ごとに

  • あり・なし
  • 小・中・大
  • 4段階

で入力するため、

点検経験が少ない職員でも一定の基準で評価できます。


③ 現場入力が速い

自由記述が少なく、

選択式中心なので、

スマートフォンでも短時間で入力できます。


④ GISとの相性が良い

判定が

A~D

で統一されるため、

ダッシュボードで

  • A何本
  • B何本
  • C何本
  • D何本

を即座に集計できます。


⑤ 国土交通省の点検思想に近い

危険兆候を重点的に確認し、

重大な異常を優先して判定する考え方は、

国交省の樹木点検指針とも整合しています。


⑥ AIとの連携が容易

AIは

  • 樹木抽出
  • 樹種判定

を担当し、

危険度判定は人が行うため、

役割分担が明確です。


⑦ 維持管理へそのまま利用できる

今回構築した

  • Survey123
  • ダッシュボード

と連携することで、

点検から維持管理まで一連の流れになります。


短所

① 危険項目1つでDになる

安全側の設計ですが、

実際には

他は健全なのにD

となる場合があります。

現場では再確認が必要です。


② 任意入力項目が多い

PoCでは現場負担軽減を優先したため、

入力漏れがあっても

A判定になる可能性があります。

本格運用では

必須項目の整理が必要です。


③ 樹種特性を考慮していない

例えば

  • サクラ
  • ケヤキ
  • マツ

では

危険性の現れ方が異なります。

現状は共通基準です。


④ 周辺環境を判定に反映していない

同じDでも

  • 公園の奥
  • 通学路
  • 幹線道路沿い

では優先度が違います。

これは更新優先度など別の指標で補完できます。


⑤ 内部腐朽は判断できない

外観点検なので、

内部腐朽までは分かりません。

必要に応じて

  • 精密診断
  • 樹木医

につなげる必要があります。


⑥ 点検者の技量に左右される

例えば

「小さな亀裂」

「大きな亀裂」

かは、

ある程度経験が必要です。

写真付きマニュアルなどで教育が必要です。


⑦ リスクを数値化していない

A~Dは分かりやすい反面、

例えば

危険度 87点

のような詳細評価はできません。

ただし自治体の日常点検では、

A~D程度の分類の方が運用しやすいという利点もあります。


特徴

このロジックは研究用の精密診断モデルではなく、自治体の日常点検モデルです。

優れている点は、

  • 重大な異常を見逃さない「安全側」の判定
  • 現場で短時間に入力できる操作性
  • GIS・ダッシュボードと組み合わせて維持管理までつながる運用性

です。

一方で、今後本格運用へ発展させるのであれば、

  • 樹種ごとの判定補正
  • 利用状況(通学路・公園利用者数など)を加味した優先度評価
  • 必須項目の整理
  • AIによる写真診断や過去点検履歴との比較

などを追加することで、さらに実用性の高いシステムへ発展させることができます。

現時点の課題(PoC)

今回のPoCでは、現場負担を考慮して多くの点検項目を任意入力としています。

そのため、本格運用では点検基準や委託仕様に応じて、必須項目の設定や判定ルールの調整を行うことも可能です。


ダッシュボード

PoCでは

管理者向けダッシュボードも構築しました。

本ダッシュボードは単なる集計画面ではありません。

AI抽出から現地確認、樹木台帳整備、現地点検、維持管理までの進捗を一元的に把握し、管理者が現場の状況をリアルタイムに確認するための運用画面として構築しています。

AI候補の確認状況はゲージで把握でき、最新点検一覧から対象樹木を選択すると、ポップアップに最新点検結果を表示し、そのままSurvey123による編集画面へ移行できます。

要対応樹木(C・D)についても一覧から対象樹木を選択できるため、危険木の優先管理にも活用できます。

図 樹木台帳・点検ダッシュボードのイメージ

ダッシュボードでは

  • AI候補数
  • 台帳整備数
  • 点検数
  • A~D件数
  • 要対応樹木(C・D)

をリアルタイムに確認できます。

さらに

最新点検結果や写真、

Survey123による編集画面とも連携しています。

つまり

単なる地図ではなく

維持管理システム

として利用できます。

AI候補確認状況

左上のゲージは、

AIが抽出した約6万本の樹木候補に対し、

現在どこまで

  • 現地確認
  • 台帳登録
  • 点検

が進んでいるかを示しています。

つまり

AIの精度を見るためではなく、

AI候補をどこまで現場確認できたかという進捗管理として利用しています。

リレーションテーブルの点検結果をArcadeで可視化

今回のダッシュボードでは、樹木台帳と点検結果をリレーションで管理しています。

一方、ダッシュボードで表示したい情報は親レイヤ(樹木台帳)だけではなく、子テーブル(点検結果)に保存されています。

例えば、

  • 最新点検日時
  • 外観評価
  • 活力度
  • 総合判定
  • 更新優先度
  • クビアカ被害状況

などは点検結果テーブルに保存されています。

そこで今回は、Arcade式を活用してリレーション先の最新点検情報を取得し、ポップアップやリスト、ダッシュボード上へ表示しています。

これにより、樹木台帳を選択するだけで、最新の点検結果をリアルタイムに確認できる仕組みを実現しました。

さらに、点検結果一覧や要対応樹木一覧もArcadeを活用することで、リレーションテーブル上の情報を管理者が一目で把握できるよう工夫しています。

ArcGIS Dashboardでは、リレーション先テーブルの情報をそのまま一覧表示することは容易ではありません。

今回はArcade式を利用することで、点検結果テーブルから最新点検情報のみを取得し、ポップアップやリスト、管理画面へリアルタイム表示しています。

これにより、樹木台帳を選択するだけで最新点検結果を確認でき、管理者は親レイヤと子テーブルを意識することなく利用できます。


今回のPoCで見えてきたこと

今回の実証で確認できたことは、

AIだけでは樹木管理は完成しないということです。

一方で

AIを入口として

GIS

Survey123

ダッシュボード

を組み合わせることで、

樹木管理業務全体をデジタル化できることが確認できました。


おわりに

今回のPoCでは、AIによる樹木抽出から樹木台帳整備、現地点検、ダッシュボードによる維持管理まで、一連の業務フローを実証しました。

重要なのは、AIを導入することではなく、自治体職員が日常業務の中で継続して運用できる仕組みを構築することです。

和泉市では、現地確認・点検・維持管理を一つの流れとして実証することで、公園樹木管理の新しい運用モデルを確認することができました。

本PoCは、和泉市職員および管理公社の皆様と現場確認を繰り返しながら、操作方法やダッシュボード構成を改善し、実運用を見据えて構築しました。机上で設計したシステムではなく、現場の意見を反映しながら完成度を高めたことが、本実証の大きな成果と考えています。

本記事が、多くの公園樹木を管理している自治体にとって、樹木管理DXを検討する際の参考事例となれば幸いです。

第2回予告

次回は、和泉市での現地実証を通じて見えてきた運用上の課題と、その解決方法をご紹介します。

AIやGISを導入するだけでは現場では運用できません。実際の現地作業では、位置修正、樹木の確認方法、点検入力、ダッシュボード運用など、さまざまな課題が明らかになりました。

本記事では、それらの課題に対してどのように改善を重ね、実際の業務で使える仕組みへ発展させていったのかを、PoCならではの実例を交えてご紹介します。

関連記事

樹木管理システムとは|AI・ArcGISによる樹木点検DXと履歴管理

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です