AIで獣害通報を変える ── 自治体と共創した獣害通報AI管理システム「AIRS」

まずはこちらの動画をご覧ください

1. 背景: 「獣害×AI」の挑戦 ── 社会課題からプロダクトへ

「クマに襲われた」というニュース、最近よく目にしませんか。
環境省の統計によると、2023年度のクマによる人身被害は219件と過去最悪を記録しました。
被害はもはや山間部だけの話ではありません。
住宅地への出没も増え、全国の自治体が対応に追われています。

私たちdx-junkyardモンキーハンターチームが獣害問題に取り組み始めたのは、2023年のことでした。
Tokyo OSS Party 2023というハッカソンで、住民がLINEから獣害を通報できるアプリを開発し、総合優勝を果たしました。
すると、農作物の獣害課題に取り組む奥多摩町の鳥獣被害対策ご担当者から「ぜひ導入したい」とお声がけいただきました。
アイデアを提供した結果、実際に奥多摩町で運用が始まり、その後青梅市や東京都環境局の大島キョン通報アプリにも採用が広がりました。

それから時間が経ち、クマによる獣害が全国的に大きく報道されるようになりました。
この社会的な関心の高まりを受けて、リニューアル版の開発を決意しました。

導入先の2自治体と未導入の1自治体にヒアリングを実施したところ、前身アプリだけでは解決できない「現場の壁」が見えてきました。
電話通報の限界、通報管理の煩雑さ、発生情報の把握と分析の大変さ。
こうした声を受けて、AIの力で課題を根本から解決するリニューアル版獣害報告LINEアプリ「AIRS」の構築に踏み出しました。
これが、AI Agent Hackathon with Google Cloud 第4回への挑戦の原点です。

2. 課題: 自治体が直面する「3つの壁」

自治体の鳥獣被害担当者は、日々どんな問題と向き合っているのでしょうか。
ヒアリングからは多くの課題が浮かび上がりましたが、特に印象的だったのは以下の3つでした。

壁1: 電話通報の限界 ── 時間的制約と聞き取りの属人化

野生動物の出没は時間を選びません。
早朝や夜間の通報にも対応が求められますが、24時間体制を維持するのは困難です。

加えて、ヒアリングで明らかになったのが聞き取り品質の属人化です。
熟練した職員は「いつ、どこで、何が、何をしていたか」を5分程度で的確に聞き出し、電話相手の声の調子からも状況を判断できるといいます。
しかし不慣れな担当者の場合、必要な情報を聞きそびれてしまうことがあります。
ある自治体では、動物が山に逃げたのか街に逃げたのかを確認し忘れ、後から再度電話するケースがあったそうです。

対応できる時間帯にも、聞き取りの質にも、電話通報には構造的な限界がありました。

壁2: 通報管理の煩雑さ

ヒアリングからは、通報の管理にまつわる課題も多く聞こえてきました。

ある自治体では、電話で受けた目撃情報を紙に書き留めてファイリングし、過去の事例はファイルをめくって確認していました。
また別の自治体では、前身アプリで通報が自動的に地図上にピン留めされる仕組みを導入していましたが、住民が誤った位置に投稿したり、不鮮明な画像を送ったりするケースがあり、職員が管理画面から一つ一つ削除する作業が発生していました。

通報手段がアナログでもデジタルでも、情報の品質管理に手間がかかるという点は共通していました。

壁3: 発生情報の把握と分析の困難

「どのエリアで、どの動物が、いつ多く出没しているのか」。
この問いに答えるには、蓄積されたデータの集計と分析が必要です。

前身のLINE通報アプリを導入した自治体へのヒアリングでは、月に1回システムからExcelデータをダウンロードし、「動物ごと」「地区ごと」にフィルターをかけて手動で集計しているとの回答がありました。
「この作業をAIが代行し、自動で結果が出るようになれば業務負担が大幅に減る」という声もあり、アプリでデータが蓄積されていても分析は職員の手作業に頼っている実態が見えてきました。

3つの壁は連鎖している

これらの課題は独立しているように見えて、実は連鎖しています。
聞き取りの質にばらつきがあるから不正確な情報が管理に流れ込み（壁1→壁2）、情報の修正・削除に手間がかかるから分析に使えるデータが整わず（壁2→壁3）、分析ができないから対策が経験頼みになり、属人化がさらに強まる（壁3→壁1）。
この悪循環を断ち切ることが、AIRSの目指すゴールです。

3. 目的: 「判断の土台を整えるAI」── AIと人間の最適な役割分担

3つの壁に共通する構造

前章で見てきた3つの壁には、共通する構造があります。

聞き取りの質が担当者に依存する。誤った情報の修正・削除に追われる。Excelで手動集計する。いずれも「人間がやらなくてもよい作業に、職員の時間が奪われている」という問題です。

一方で、鳥獣被害対策には「人間にしかできない判断」も多く存在します。ヒアリングからは、現地に赴いて痕跡や動物が執着する要素がないか調査したり、広報車で注意喚起する際のルートを考えたりと、現場でなければできない業務が日常的に発生していることがわかりました。広報車のルートひとつとっても「どこに逃げたかわかれば判断できる」とのことで、現場の状況が事前に整理されていれば「判断の土台」が整います。

AIRSは、この2つの領域を切り分けることから設計を始めました。

「判断の土台を整えるAI」という設計思想

AIRSの設計思想は、AIが職員の判断を代替するのではなく、「判断の土台を整える」ことに徹するというものです。AIが得意な領域はAIに任せ、人間が判断すべき領域は人間に委ねる。前章の悪循環を断ち切るために、この役割分担から設計を始めました。

具体的には、3つの壁それぞれに対応する形で役割を分担しています。

AIが主導する領域:

• 通報受付（LINE） -- 壁1の「聞き取りの属人化」を解消します。AIが対話形式で聞き取り、状況に合わせて質問を変えることで、担当者の経験に依存せず必要な情報を漏れなく収集します。なお、AIを使うのは状況確認など一部に限定し、それ以外はLINEのネイティブUIとシンプルなチャットボットで安定性を確保しています。
• 画像解析・誤報フィルタリング -- 壁2の「情報品質の問題」に対応します。住民が選択した獣種と送信写真の内容が一致するかをAIが検証し、不鮮明な画像や動物が写っていない写真は弾くことで、職員の修正・削除作業を減らします。加えて、対象地域外からの通報を住所の前方一致で弾くジオフィルタリングも導入しています。こちらはAIを使わず、逆ジオコーディングと文字列比較だけで実現しており、AIに頼らなくても枯れた技術でカバーできる部分はそちらを採用する方針です。
• データ分析・傾向把握 -- 壁3の「手動集計」を代替します。GISのレイヤー構造で通報を空間的に可視化したり、統計ダッシュボードでグラフを表示したりと、Excelを開かなくても傾向が視覚的にわかる仕組みを整えました。そのうえで、より複雑な分析にはAIを活用しています。AIはチャットで質問に答えるだけでなく、地図のレイヤーを操作したり周辺施設をマッピングしたりと、画面そのものを動かすAgenticな振る舞いを持たせました。

人間が主導する領域:

• 最終判断 -- 通報内容をもとに対応方針を決めるのは職員です。AIは「罠を仕掛けるべきエリア」や「出没が集中している時間帯」などを提案しますが、決定権は常に人間にあります。
• 現場対応 -- 実際に罠を設置する、パトロールを行う、住民に注意喚起するといった行動は、現場を知る人間が担います。
• 住民コミュニケーション -- 被害に遭った農家への説明や、地域の合意形成は、信頼関係に基づく人間同士のやりとりが欠かせません。

[図: 「判断の土台を整えるAI」の役割分担（AIが主導する領域と人間が主導する領域の対比図）]

なぜ全自動にしないのか

「AIがここまでできるなら、全部任せればいいのでは？」と思われるかもしれません。全自動にしない理由は、大きく2つあります。

1つ目は、住民の生活に直結する判断を含むからです。

野生動物の出没情報は、住民への注意喚起や通学路の安全確認など、日常生活に影響する判断に使われます。AIが「危険度は低い」と判定しても、状況は現場ごとに異なります。どこに罠を仕掛けるか、引き続きパトロールを継続するか、誰にどのタイミングで伝えるかといった判断は、地域の事情を踏まえて人間が行うべきものです。

2つ目は、地域ごとの特殊事情があるからです。

同じイノシシの目撃でも、山間部の農地と住宅地の裏庭では意味が異なります。その土地の地形、農作物の種類、住民の年齢層、過去の被害履歴。こうした文脈を総合的に理解しているのは、現場の職員です。

AIは過去データに基づく統計的な提案はできます。しかし「この裏山は動物の通り道になっているから重点的に見回るべき」「この畑は収穫前だから被害が拡大する前に手を打ちたい」といった判断は、地域に根差した知識がなければできません。

AIの役割は「判断の土台」を整えること

AIRSにおけるAIの本質的な役割は、職員の判断を代替することではありません。判断に必要な情報を整理し、選択肢を提示し、判断の土台を整えることです。AIが出す答えは「正解」ではなく「参考」。最終的にどう動くかは、現場を知る職員が決めます。

AIRSでは、鳥獣被害対策という住民の生活に直結する領域だからこそ、この境界を慎重に定めました。

4. 機能: AIRS ── 獣害通報のエンドツーエンドAI管理

前章で整理した3つの課題に対して、AIRSがどのような機能で応えるのか。
本章では、サービスの機能要件からシステムアーキテクチャ、コア技術の実装詳細までを解説します。

サービスのコンセプト

AIRSは、獣害通報における通報から管理・分析まで一気通貫で自動化し、自治体の通報業務を最適化するシステムです。
従来は、電話で通報を受け付け、紙で取ったメモを頼りに、手作業で状況を分析して、対策を考えるという流れでした。
AIRSを導入することで、職員は手作業から解放され、現場の判断と対応に集中できるようになります。

AIRSの機能の紹介

住民がLINEから通報すると、AIが対話形式で状況を聞き取り、写真の画像解析まで自動で処理します。
管理画面では通報の一元管理からGIS地図・統計グラフによる傾向分析、AIが地図のレイヤー操作や周辺施設のマッピングまで行うAgenticな分析機能を備えています。

機能は自治体ヒアリングで抽出した3つの壁と1対1で対応しています。

課題	機能	概要
電話通報の限界	AIチャット通報（LINE）	24時間LINEで受付。AIが状況に合わせて質問を変え、担当者の経験に依存しない聞き取りを実現。画像解析で誤報も防止
通報管理の煩雑さ	通報管理	通報の編集・削除、正確なデータ管理。近接する通報の自動グループ化と担当者の自動割り当てで対応状況を一元管理
発生情報の把握と分析の困難	AIマップ	GISレイヤーと統計グラフで獣種別に発生場所を可視化。AIが発生傾向を分析し、対策計画の資料作成にも活用

AIチャット通報（LINE）

住民が最も使い慣れたLINEをインターフェースにしています。
電話対応で職員が確認する「何が・いつ・どこで・何をしていたか」を、AIがLINE上で聞き取ります。

各ステップの実際の画面は以下のとおりです。

ステップ	キャプチャ	キャプチャ
🐻 何が(獣種選択 + 写真)
🕐 いつ(日時入力)
📍 どこで(位置情報)
💬 何をしていたか(AI聞き取り)
✅ 確認・送信
🔗 編集リンク送付

なぜこの構成になったか ── ヒアリングで聞いた現場の声

通報フローの構成は、職員へのヒアリングから設計しました。
電話対応では「いつ・どこで・どんな野生動物が・何をしていたか」を住民に確認していることがわかり、この4項目をそのままチャットのステップに落とし込んでいます。

写真ステップに画像解析AIを組み込んだのは、「不鮮明な画像や関係のない画像が送られることがある」という声がきっかけです。送信前にAIが画像を判定し、不適切な写真は再投稿を促すことでデータ品質を担保しています。

途中で2つ存在するループ処理もヒアリングで聞いた現場の声から設計しています。
「住民は黒いものが動いただけでクマと思い込んで通報する傾向がある」という声から、AI解析で獣種が不一致なら再投稿を促すループを設けました。「管轄外の地点にピン打ちされることがある」という声からは、ジオフェンシングで管轄外なら再入力させるループを設けています。

その他、以下のような要望もいただきましたので機能に反映しています。

職員の声	実装した機能
日時入力のステップがないため、通報日時と実際の遭遇時刻が乖離している可能性がある	日時入力ステップの追加
住民側から通報内容を修正したいという問い合わせがあり、現場対応が増えている	送信後に編集ページのリンクをLINEに送付

補足：Agentic Vision採用の背景 ── 職員はどう写真を見ているか
今回は獣種の画像分析にAgentic Visionを採用しました。採用した理由は、このAIモデルが職員と同じ目を持っていたからです。

• 職員はクマかカモシカかを**「耳の形」（丸い＝クマ、尖っている＝カモシカ）と「足・後ろ姿」**で判断しているが、不慣れな職員には難しい
• 住民は「黒いものが動いた」だけでクマと思い込んで通報する傾向がある。実際はカモシカやイノシシであるケースが多い

Agentic Vision（Gemini 3 Flash）は、モデル自身が画像をズーム・クロップしてから判定します。職員が写真を確認して耳や足の細部を確認するプロセスと同じ目線のアルゴリズムであり、この一致が採用の決め手となりました。

通報管理

LINEから届いた通報は、管理画面で一元管理します。

通報管理の肝は、職員が情報の修正・管理をできることであり、AIRSもこの機能を中心に設計しています。
通報内容の編集・削除、位置情報の修正、獣種の変更など、職員が直接通報内容を管理できるようにすることで、データ品質を維持することができます。

ただし、通報件数が増えるほど職員の作業負荷も増加します。
そこで、AIRSのコンセプトである「判断の土台」を意識し、近接通報の自動グループ化、担当者の自動アサイン、統計ダッシュボードによる可視化を組み込みました。
職員が管理作業に追われるのではなく、すぐに状況を判断し対応を進められる環境をつくっています。

通報を受信してから「判断の土台」が整うまで、以下の自動処理が走ります。
これにより、通報を受け取った瞬間から、職員はすでに状況を把握できる状態になります。

各画面の実際のキャプチャは以下のとおりです。

画面	キャプチャ
📊 ダッシュボード ── 獣種別割合や通報の多いエリア一覧を表示
📋 通報一覧 ── ステータスや獣種でフィルタ
📁 通報グループ ── 近接通報がまとまった状態
📝 通報詳細・編集 ── 職員が内容を修正

なぜこの構成になったか ── ヒアリングで聞いた現場の声

現行の業務では「電話で受けた目撃情報を紙に書き留めてファイリングしている。過去の事例はファイルをめくって確認している」とのことでした。
紙ベースの管理をデジタルに置き換えるため、ダッシュボードで獣種別の割合、日別の通報推移、時間帯別の出没傾向、エリアランキングなどをリアルタイムに可視化しています。

また、「誤報や住民からの連絡を受けて情報の修正作業が必要になる」「前身の通報アプリでも、誤投稿や不鮮明画像の削除作業が発生し、デジタル化しても品質管理の手間は残った」という声から、職員が通報内容を直接編集・削除できる機能を整備しました。
通報管理の中心にこの修正・管理機能を据えることで、データ品質を維持できるようにしています。

補足：Spatial Intelligence ── 位置情報を使った自動処理の仕組み

同じ地域で短時間に複数の通報が届くことがあります。
たとえば「駅前でサルを見た」という通報が10分間に3件届いた場合、これらは同じ群れに関する通報である可能性が高いです。

AIRSではこの判断をPostGIS（PostgreSQLの空間拡張）で自動化しています。
新規通報が届くと、半径500m以内かつ過去60分以内の既存通報グループを検索し、条件に合えばそのグループに追加、なければ新しいグループを作成します。
担当者の自動アサインも同様の仕組みです。職員はマイページから担当地域を地図上に登録しており、通報地点から最も近い担当地域を持つ職員を空間検索して自動で割り当てます。

これらの閾値（半径・時間窓）は設定テーブルで管理しており、自治体の運用に合わせて調整できます。

AIマップ

通報管理で蓄積されたデータを、職員が自ら分析・活用するための機能がAIマップです。
地図上での空間分析、リアルタイムの統計可視化、そしてAIによる高度な分析の3つを組み合わせることで、対策計画の立案や住民への説明資料の作成を支援します。

機能	概要	キャプチャ
🗺️ 地図分析UI ── GISを踏襲した地図画面で、クラスタ・ヒートマップ・タイムラインの3レイヤーを切り替えて分析	個別の通報確認、密集エリアの俯瞰、時系列の変化の追跡を1つの地図上で実現
📊 リアルタイム統計 ── 地図上のデータをリアルタイムに可視化する統計機能	獣種別割合、通報推移、時間帯別傾向などを地図と連動して表示
💬 AI分析 ── 複雑な分析をAIが実行するチャット機能	自然言語で質問するだけでSQLが自動生成・実行され、結果がテーブルと地図に反映

なぜこの構成になったか ── ヒアリングで聞いた現場の声

自治体職員は通報を受けたら、地図を見ながら状況を確認しているとのことでした。
この作業をデジタル上でも再現できるよう、GISの空間分析機能を組み込んでいます。
空間分析機能は以下を実装しています。

• クラスタレイヤー: 通報を地図上にマーカーで表示し、密集エリアでは自動クラスタリング ── 個別の通報を確認する
• ヒートマップレイヤー: 通報密度をグラデーションで表現 ── 密集エリアを俯瞰する
• タイムラインレイヤー: 時間軸スライダーで出現・消滅をアニメーション ── 時系列の変化を追跡する

また、「月に1回Excelデータをダウンロードし、動物ごと・地区ごとにフィルターをかけて手動集計している」という声もありました。
「この作業をAIが代行し、自動で結果が出るようになれば業務負担が大幅に減る」とのことで、自然言語で質問するだけでSQLが自動生成・実行される分析チャットを実装しています。

補足：生成AIと空間分析の統合

GISは高度な空間分析ができる一方で、画面の項目も多くなり操作が複雑になります。AIが地図の操作も代行することで、操作を完璧に覚えなくても手軽に使えるものにしています。

たとえば「先月のイノシシ通報が多かった地域は？」と質問すると、AIは以下を自動で実行します。

1. 地図のフィルターをイノシシ・先月に切り替え、該当エリアに地図を移動
2. 通報データを集計し、地域別の件数をテーブルで回答
3. 「この地点の近くに小学校はあるか？」と続けて聞けば、周辺の学校や公園を地図上にマーカーで表示

AIは現在の地図の表示状態（どの獣種・ステータスが表示されているか）を認識しているため、画面の操作とAIの分析結果が常に連動します。職員はチャットで質問するだけで、地図のフィルター操作・データの集計・周辺施設の検索をまとめて実行できます。

補助機能

これらを支える補助機能として、以下の機能も実装しています。

補助機能	概要
システム設定	ジオフェンシング、自動グループ化条件設定、対象獣種の追加・削除など、自治体ごとの運用に合わせた柔軟な設定
職員管理	職員の登録と担当地域ポイントの地図設定。通報時の自動アサインに連動
施設管理	周辺の学校・公園などを検索・登録。AIの地図操作にも連携
CSV一括インポート	大量の過去データを非同期で一括取り込み。取り込み状況をリアルタイム表示
ヘルプチャットボット	管理者・一般利用者それぞれに生成AI搭載のチャットボットで操作案内

システムアーキテクチャ

サービス全体の構成

AIRSは、LINEアプリ・住民専用サイト・職員専用管理サイトの3つで構成されています。

この構成は、前身のLINEアプリの設計を踏襲しています。
前身アプリでは、住民はLINEから通報しMAPページで閲覧、職員は専用の管理画面で確認するという2層構造でした。

AIRSではこれに加えて住民専用の情報修正ページを新設しました。
送信後にLINEに届く編集リンクから自分の通報内容を確認・修正でき、JWTトークンで認証するためログイン不要で安全にアクセスできます。

職員専用管理サイトには、通報管理・AIマップ・ダッシュボード・システム設定など全機能を集約しています。
環境変数で有効化を制御しており、住民には必要な情報だけを見せる設計です。

GCPインフラ構成

上図はAIRSのGCPインフラ全体像です。
同一のNext.jsコードベースから、環境変数ADMIN_MODEの切り替えで2つのCloud Runサービスをデプロイしています。

• airs（ADMIN_MODE=0）: LINE Webhook受信、通報閲覧、地図表示、ヘルプチャットを提供。
• airs-admin（ADMIN_MODE=1）: 通報管理、職員管理、分析AI、ダッシュボードなど全管理機能を提供。

データベースへの接続はVPC内で完結させています。
Cloud RunからServerless VPC Access Connectorを経由し、Cloud SQL Auth Proxyを通じてCloud SQL PostgreSQLにPrivate IPで接続します。
パブリックIPを持たないため、外部からの直接アクセスを遮断しています。

AIRSが利用するGCPサービスは以下のとおりです。

サービス	用途
Cloud Run	アプリケーション実行基盤（2サービス）
Cloud SQL PostgreSQL	通報データの永続化
Cloud Storage	通報写真の保存・配信
Secret Manager	APIキー、DB接続情報、LINEトークンの管理
Artifact Registry	Dockerイメージの管理（airs:latest, airs:admin）

外部APIとして、Google Gemini APIをLINE通報AI・分析AI・ヘルプチャットボットの3箇所で利用しています。
逆ジオコーディングにはYahoo逆ジオコーダーとNominatim（OSM）を、周辺施設の検索にはOverpass API（OSM）を使用しており、Google Maps Platformには依存していません。

AIエージェントによる地図操作

AIマップの補足で紹介した「AIが地図を操作する」仕組みは、Vercel AI SDKのツール呼び出し機能とJotaiによる状態管理で実装しています。
AIには3つのツールを提供しており、質問内容に応じてAI自身がどのツールを使うかを判断します。

ツール	用途	地図への作用
searchReports	通報の検索・フィルタリング	検索条件で地図フィルターを更新。場所指定時は地図も移動
runSql	集計・統計クエリ（GROUP BY, COUNT等）	結果をテーブル表示。地図は更新しない
searchLandmarks	周辺施設検索（Overpass API経由）	結果を地図上にマーカー表示

特徴的なのは、AIが地図の現在の状態を「知っている」点です。
ユーザーが地図上で設定しているフィルター（表示中の獣種やステータス）は、リクエスト時にシステムプロンプトへ変換されてAIに渡されます。

// 地図の現在のフィルター状態をシステムプロンプトに変換
'- 通報ステータス: waiting, completed'
'  → WHERE条件: status IN (waiting, completed)'

これにより、「今地図に表示しているデータを集計して」という文脈依存の質問にも正確に応答できます。

ツールの実行結果は、ストリーミングレスポンス内のカスタムイベント（data-filters、data-landmarks）としてクライアントに送信されます。
クライアント側のフックがイベントを受け取りJotaiの状態を更新することで、地図がリアルタイムに再描画されます。

AIの応答と地図の操作が常に連動するこのフィードバックループが、「チャットで聞くだけで地図が動く」体験を実現しています。

技術選択

主要な技術要素について、候補を比較検討したうえで採用技術を決定しています。
ここに書ききれない技術的判断も多数ありますが、特に重要なものを抜粋して紹介します。

選定項目	候補	採用	選定理由
システム構成	モノリシック, マイクロサービス	Next.jsモノリシック	複数サービスを立てるとローカル開発が煩雑になり、インフラ構築も複雑化するため、全機能をNext.js 1アプリに集約
データベース	MySQL, PostgreSQL	PostgreSQL	AI領域でのエコシステムが強く、PostGIS拡張によりGIS空間検索にも対応。開発環境のNeonがPostgreSQLを提供していた点も要因
GIS地図エンジン	Maps JavaScript API, Leaflet	Leaflet	行政系システムでの採用実績が豊富。無料OSSでタイムライン・ヒートマップ等のプラグイン拡張も容易
UIデザインシステム	MUI, shadcn/ui, デジタル庁デザインシステム	デジタル庁デザインシステム	政府公式のデザインシステムであり、自治体職員にとって馴染みのあるUIを提供。アクセシビリティ基準に準拠し、Tailwind CSSプラグインによるデザイントークンの統一で自治体利用に適した画面を構築できる
リバースジオコード	Yahoo!リバースジオコーダーAPI, 国土地理院API, Nominatim	Yahoo!リバースジオコーダー	同一地点で3サービスを比較し、番地レベルまで正確に取得できたのがYahooだった。
周辺施設検索	Google Maps Places API, Overpass API	Overpass API	Google Maps APIは取得データのDB保存が利用規約に抵触すると判断。Overpass API（OpenStreetMap）を採用
画像解析AI	Gemini 3 Flash (通常), Gemini 3 Flash（Agentic Vision）	Agentic Vision	モデル自身がズーム・クロップしてから判定する。職員が耳や足の細部を確認するプロセスと同じ目線で判定可能
インフラ管理	Google Cloud Console、OpenTofu	OpenTofu	IaC方式であり、コーディングAIで高速に実装可能なため採用。自治体向け環境とデモ環境など複数環境を即座に構築できたため作業工数を大幅に短縮できた
開発テスト環境	GCP, Vercel	Vercel	簡単な設定で構築できたため採用。自動デプロイにより、Claude Codeのクラウド環境でAIコーディングしてからPRを作成するだけで動作確認ができる。疲れたときはスマホ片手にAIに指示しながら開発しました。
AIライブラリ	Google AI Client Library, Vercel AI SDK	Vercel AI SDK	フロントエンドでの開発のしやすさと、開発元がNext.jsと同じVercelであるため採用
コーディングAI	Claude Code, Codex CLI	Claude Code + Codex	メインはClaude Code（Opus 4.5）で高精度なコーディング。Max Planの上限到達時はCodexに切り替え。Agent SkillsやAGENTS.mdをシンボリックリンクで共有し、AI設定を共通化することでスイッチングコストを抑制しました。

運用コスト ── 月額1〜2万円で始められるAI管理システム

AIRSはOSSのため導入費用はゼロですが、クラウドの運用コストは発生します。
小規模自治体（月100〜300件の通報）を想定した試算では、Cloud Run・Cloud SQL・Gemini API等を含めて月額約1〜2万円です。
地図エンジンにLeaflet（OSS）、施設検索にOverpass API（OSM）を採用しGoogle Maps Platformに依存しない構成にしたこと、AIモデルにGemini Flashを選んだこと、Cloud Runのゼロスケールで夜間・休日のコストを抑えたことが効いています。
GCPの無料トライアル（$300クレジット）を使えば、初期費用なしで数ヶ月間の実証実験も可能です。

※ 上記の金額はAI（Claude）によるGCP公開価格ベースの概算であり、実際の費用はトラフィック量やAI利用頻度によって変動します。

5. 成果: 自治体での実証と公開デモ

今回のハッカソンでは機能を作って終わりではなく、実際の現場で使ってもらい、フィードバックを得ることができました。
前身アプリを導入いただいた一部の自治体のご担当者にデモを実施し、一般向けにも公開デモ環境を構築しました。

自治体デモ

鳥獣被害対策ご担当者にご協力いただき、実際にデモ機を操作していただきました。
機能面で高い評価を得る一方、データの質に関する重要な指摘もいただいています。

以下に主なフィードバックをまとめます。

機能	評価	担当者の声（要約）
AIチャット通報	好評	質問に答える形式で住民も状況を報告しやすい
通報内容の自動要約	好評	要約があると第三者にも状況が伝わりやすい
画像解析による誤報防止	好評	無関係な写真を弾く仕組みは実用的
キャンセル・修正機能	好評	やり直しができる安心感がある
集計ダッシュボード	好評	即座に集計される点に驚き
タイムライン再生	好評	動物の行動パターンの把握に有用
獣種の絞り込み	好評	特定の動物だけ表示できるのは実務で便利
AI分析（罠の設置提案）	好評	抵抗感なく受け入れられた
獣種の細分化	課題	タヌキ・アライグマ等が「その他」では判別できない
データの質	課題	分析の前提として通報データの正確さが鍵になる

獣種の細分化については、AIRSでは設定画面から対象獣種を柔軟に追加・変更できる設計にしており、すでに対応可能でした。
データの質については、AI分析の精度は入力データに依存するため、通報時の入力品質をいかに高めるかが今後の課題です。

デモページ

今回のAI Agent Hackathon with Google Cloudに合わせて、一般の方にも操作いただけるデモ環境を構築しました。
デモサイトでは、京都府クマ目撃情報（CC BY 4.0）のオープンデータを読み込んで使用しています。実際に触ってお試しください。

• https://airs.demo.dx-junkyard.com/

LINE公式アカウントから実際の通報も体験できます。以下のQRコードを読み取って友だち追加してください。

管理画面のデモを利用されたい方は、[e-mail] までご連絡ください。

6. おわりに: 「現場の声」から次のステージへ

今後の展望

AIRSが取り組んでいるのは、「住民からの通報を受け取り、AIで整理・分析し、対応につなげる」という一連の流れです。
この仕組みは、鳥獣被害に限らず、さまざまな地域課題に応用できます。

たとえば、道路の損傷、不法投棄、公共施設の不具合といった通報にも同じアーキテクチャが転用可能です。
自治体からは「焼却炉の煙の状況なども通報で受けられたら」という例を挙げて「絶対そのほうがいい」と前向きな反応をいただきました。

AIRSはオープンソースとして公開しており、自治体が無償で導入できます。

• https://github.com/dx-junkyard/airs

デモを実施した自治体からは、リニューアル版の導入検討にも前向きな反応をいただいています。

Tokyo OSS Party 2023での総合優勝から始まり、2自治体への導入、ヒアリングを経てリニューアル版AIRSへ。
現場の声を起点にした開発サイクルが、このプロダクトの根幹にあります。
今回のAI Agent Hackathon with Google Cloudへの参加を通じて、AIエージェント技術を活用した新たな機能群を実装できました。

地域の「困った」をAIの力で「対応できる」に変えていくこと。
AIRSはその第一歩を踏み出したところです。

謝辞

dx-junkyard モンキーハンターチームとして開発しました。
最後まで走り抜けることができたのは、チームメンバー全員の圧倒的なコミットメントと協力のおかげです。

ヒアリング・デモにご協力いただいた自治体のご担当者の皆さまに、心より感謝申し上げます。
現場で実際に鳥獣被害対策に取り組まれている方々の生の声が、AIRSの設計と改善を支えています。

※この記事にはGeminiで生成した画像が利用されています。