通報があったことを知るべきは、
その近くにいる人たちである。

クマの目撃情報は、いま多くの自治体で電話とメール配信に頼っています。住民から役場へ電話が入り、 職員が内容を確認し、防災メールで全域へ流す。この流れには、情報が古くなる時間と、 自分に関係あるか判断できない受け手が残ります。

結果として起きるのは「慣れ」です。関係のない通知が続けば、本当に近いときの通知も同じ重みで扱われます。

クマの出没情報を扱うアプリは、すでにいくつもあります。地図で見られるものも、 近づくと知らせてくれるものもあります。違いは、その通知がいつ、どんな状態で鳴るかです。

「本当にクマだったか自信がない」ためらいは、通報を遅らせます。クマったは誤報を排除せず、 吸収する設計にしています。市民に信頼性スコアは見せません。判断は自治体側で行います。

通報は1件1行で記録し、削除も書き換えもしません。訂正は追記として残します。 地域の防災ログとして、後から経緯を追えるようにするためです。

構想ではありません。市民アプリ、自治体管理画面、API、通知基盤、AWS環境まで実装済みで、 本番環境が稼働しています。以下は現在のコードベースの実数です。

市民アプリ（iOS / Android）、自治体管理画面、API、通知基盤、AWS環境まで実装済みです。 構成の詳細は技術スタック仕様をご覧ください。

市民アプリと対になる、職員向けのWeb管理画面です。通報を地図で受け、内容を確かめ、 通報者に匿名のまま確認し、住民へお知らせを出すところまでを1つの画面でまかないます。 ブラウザだけで使えるので、職員の端末に何かを入れる必要はありません。

自治体ごとに管轄範囲を地図上で登録すると、その範囲に関わる通報だけが各自治体の画面に表示されます。 職員の権限は4段階で、閲覧のみの担当者から、警戒エリアの発令や一斉通知まで行う管理者まで分けられます。

安全情報そのものは自治体に閉じません。市民への警戒通知は、行政界をまたいでも止めません。 クマは境界線を認識しないためです。

クマが出たあと、誰が何をするか。通報を受け、判断し、住民へ知らせ、現場が動く—— クマったは、この流れ全体を考えて作っています。そのうち、 いま制度として動ける主体が自治体でした。だから最初の入口を自治体向けにしています。 自治体向けであること自体が目的ではありません。

プラットフォームとして作っているため、通報を受けて判断する側は、後から替えられます。 体制や制度が変われば、管理する側のシステムはそれに合わせて作り替えられる構造にしてあります。 いまの形が最終形だとは考えていません。

現場で何が起き、誰が動けて、何が足りないのか。それは実際に対応されている方が最もご存知です。 決まったものを納めるのではなく、形そのものからご相談させてください。 そのために、まず動くものをお持ちしました。

いまの警戒通知は、端末の OS が持つ GPS のジオフェンス機能で動いています。ただ、谷筋や林道、 建物の際では測位そのものが揺らぎ、円の出入りを OS が拾えないことがあります。 この弱点は、GPS の精度を上げる方向ではなく、別の検知手段を足す方向で埋めたいと考えています。

その候補がビーコン検知です。登山口、遊歩道の入口、通学路の分岐、圃場の出入口など、 「ここから先は気をつけてほしい」場所に電池式の小さな発信機を置き、端末がそのそばを通ったことだけを受け取ります。 位置を測るのではなく、目印のそばを通ったかどうかだけを見ます。 個人を特定しない、位置をサーバーへ預けないという方針はそのまま引き継ぎます。

ビーコンは GPS ジオフェンスの置き換えではありません。仕組みも、うまくいかない条件も違います。 そのためいまの通知経路とは切り離した将来の実験として扱い、 効果を実地で確かめたうえで採否を判断します。現在のお試し版には入っていません。

まずは無料のPoCで、実際の業務での使い勝手をご確認いただけます。

利用料には、通報・警戒情報の管理、通知機能、システム保守、基本的な運用支援を含む想定です。 標準構成の参考価格として、対象地域・利用規模・支援内容に応じてお見積もりします。 個別開発や機器導入は別途ご相談ください。

PoCの期間・対象範囲は事前に相談して決定します。

iOS・Android のテスト版を配布しています。実際に通報し、警戒エリアに入り、 通知が届くところまでご確認いただけます。管理画面もあわせてご覧いただけます。

導入をご検討の際は、対象地域の管轄範囲を登録したうえで、 実際の運用に近い形での試験導入からご相談ください。