06_idogoar

Mt.Statelite 登る前から、下りるまで。見守り続けるアプリ 滋賀大学 経済学部 石井ゼミ i do goar / 松本 侑己

INTRO 山岳遭難は年間3,000人規模で起きている 2,946 件 3,357 人 300 人 30.4 % 発生件数 遭難者数 死者・行方不明者 原因の1位は「道迷い」 2024年（令和6年）の1年 間 1日あたり9人が山で遭難 している計算 遭難者のおよそ11人に1人 次いで転倒20.0%、滑落 17.2% 出典：警察庁生活安全局「令和6年における山岳遭難の概況等」（2025年6月19日公表） 1

INTRO WHAT THE DATA SAYS 電波は届いている。届いていないのは情報 72.8 % +7.8pt 現場から救助要請ができている 遭難した2,946件のうち72.8%は、携帯電話や無線で救助を要請 できていた。多くの場合、通信そのものは生きている。 単独での遭難は、複数人での遭難に比べ て 死者・行方不明者の割合が7.8% ↑ 64% 死者・行方不明者に占める60歳以上の割合 遭難者全体でも約50%を占める。 321件 最多は長野県 。次いで北海道189件、東京 都・神奈川県が各183件と、都市近郊の低 山も例外ではない。 出典：警察庁生活安全局「令和6年における山岳遭難の概況等」（2025年6月19日公表）、政府広報オンライン 2

INTRO THE GAP 既存の備え方には 抜けがある!! 紙の登山届 提出しても、事故が起きるまで誰も見ていな い GPSトラッカー単体 位置はわかっても、「危険かどうか」までは教えてくれ ない 家族の確認手段 山の状況をリアルタイムで知る家族は登山中に起 こったことことは難しい 状況確認 気象警報、クマの目撃、現地からの一次情報。ルート 周辺の情報は各所に散らばっていて、登山中に自分か ら探しにいくことはできない 3

PHASE 1 アプリ

アプリ Mt.Stateliteが解決すること 自動で監視する 検知した瞬間に伝える 押せなくても助けを呼ぶ 計画を1回登録すれば、入山 中は5分ごとにルート周辺の 気象警報・地震・現地報告・ 危険動物を監視し続ける。 新規のリスクだけをLINEで集 約通知。ルートから100m外 れれば、誰より早く家族/自 分へ通知が届く。 下山予定時刻を過ぎても報告 が無ければ、家族へ自動で連 絡が送信される。 リアルタイムで情報を取得し、遭難を防ぐアプリ！！ 危険を察知し留まる、引き返すことができる 4

アプリ 登録から下山までアプリはこう動く 計画（登山前） 入山中 › ① 計画を登録 登山口とルートを地図 でタップ。都道府県は 自動特定 ② リスクを自動診断 気象警報・地震・危険 動物・現地報告を一括 取得 › › ③ 入山中は自動監視 ④ 検知して即通知 5分ごとに周辺を再チェ ルート逸脱・新着リス ック。雨雲レーダーも クを本人と家族へLINE 表示 下山後 › ⑤ 見守り機能 ワンクリックで今の状 況伝えたりや緊急連絡 先に電話することがで きる › ⑥ 下山完了 5

アプリ PLAN / STE P 1–3 地図をタップして ルートを描く 1 山を検索する 都道府県と山名を入力し「この山を地図で検索」で検 索地図が移動する。 2 スタートピンを置く 1点目のタップが登山口 3 経路点を足していく タップするたびに線が伸びる。「1つ戻す」「登山口からや り直す」で登山ルートを修正できる。 6

アプリ PLAN 具体的な登山計画の登録 → 入山／下山予定時刻 YYYY-MM-DD HH:mm 人数ステッパ 1〜10名 緊急連絡先の名前 家族・同行者 登山ルート 検索し、地図上に書く ルート点が1つ以上あること。下山予定が入山予定より 後であること。この2つを満たすと HikingPlan を生成し て保存し、ホーム画面へ遷移する。 7

アプリ FE ATURE 計画を確定した瞬間に4系統 を一括診断 ルートが通る都道府県を割り出し、警報・現地報告・地震・ 遭難ニュース・危険動物の5系統を並列で取得する。結果は計 画に保存され、ホームの4カテゴリカードになる。 → 気象警報 危険動物 直近72時間。解除済みは除外 直近30日。クマ・イノシシ等の 目撃 現地報告 直近の地震 直近7日のSNS一次情報 直近7日・震度3以上 8

アプリ TRACEABILITY カードから一次情報そのもの へ ホームの4カテゴリカードは、件数と直近の行を出すだけで はなく、行をタップすると、その情報の参照元(SNSの元投 稿やニュース記事)をブラウザで開く。 1 カードを表示。 FASTALERT MCPからの情報を収集し、 オンタイムで気象警報・現地報告・地震・危険動物のカー ドがセクションごとに並べる。 2 行をタップする。 参照元URLを持つ行は、そのまま元の投 稿・記事へ遷移する。 (中にはURLを持たないカードもある) 3 実際のソースを表示。 参照元の情報を見ることで、より詳 しく見ることができる。 → ホーム／4カテゴ リカード 参照元の元 投稿 9

アプリ PLAN OV ERVIE W 危険は地図の上に表示 登録済みの計画には、マップ上に危険動物ピン、現地報 告ピンが表示される。 → 地図＋ルート＋登山スタートピン 危険動物ピン ／ 現地報告ピン 登録情報一覧＋「ルート周辺の状況を見る」 10

アプリ DEV IATION ルートから100m 離れたら 本人と家族に知らせる。 現在地から登録ルート（折れ線）までの最短距離を計算する。緯度経度を km/度に平面近似したうえで、各区間ごとに点と線分の最短距離公式を適 用して、ルートからどれくらい離れているかを把握する。 画面に出るもの 通知 画面にも逸脱バナーと、確認 用のアラートダイアログを表 示 迅速に登録したLINE IDへ、 逸脱距離とルート名を添えて 送信する。 → 11

アプリ ESCALATI ON & SOS 押せないときも 連絡は自動で 送信される。 下山予定カウントダウン 残り時間を30秒ごとに再計算。残り1時間を切ると黄色、超過する と赤に変わり「下山予定時刻超過」の表示になる。 自動エスカレーション 登山計画の下山予定の超過を検知すると、LINEで周りの人にも自動 で伝えることができる。 12

アプリ RECEIVED 実際のLINE通知例： → ロック画面の緊急通知 下山予定時刻を過ぎても報告が無 く、エスカレーションが自動送信 された状態 ルート逸脱通知 ルートから100m以上離れたこと を、逸脱距離つきで緊急連絡先へ 今の状況を伝える 見守り画面のボタンから、ステー タスと現在地リンクを送信 リンクから地図へ タップすればGoogleマップが開 きその座標にピンが立つ 13

アプリ 山に登る人と待つ人。 ソロ・週末登山者 帰りを待つ家族 田中 亮（38） 田中 佳子（38） 都内在住登山歴3年 月1〜2回・日帰り・単独中心 亮の妻・都内在住 登山経験なし / スマホはLINE と電話 登る理由 気持ち 平日は頭が休まらない。山にいる時間だけ、 何も考えなくていい。 趣味は応援したい。でも山の日は一日中 そわそわして、「帰った」の一報が来るまで眠れな い。 装備も体力もそれなり。「まあ大丈夫」 できるのは見送りの「気をつけて」だけ。 14

アプリ Mt.Statelite で2人の一日はこう変わる 場面 今まで Mt.Statelite があると 亮：入山中 稜線で孤立、判断材料なし 入山エリアを5分ごとに自動監視。気象警報・地震・ 危険動物・ルート逸脱を検知したらLINEで即通知 亮：下山が遅れる 圏外で家族に連絡できない 下山予定を過ぎると自動で緊急連絡先へエスカレーシ ョン。本人が操作できなくても伝わる 佳子：待つ間 今どこにいるか分からない LINEで「今どこ？」に自動返信。現在地リンク＋ス テータス＋最終GPS更新時刻 佳子：予定超過 通報すべきか判断できない 超過時に自動通知。ルート名・人数・119/110案内 つき。次の一手が明確 15

月間10万ユーザー規模のコスト試算 実現性 前提: MAU 100,000人 、平均 月に１回登山で使用するものとして試算 月額費用(円) 合計 約 ¥7,760,000 / 月 外部api AWS実行基盤 (Lambda+DynamoDB+S3) LINE Messaging (通知配信) MCP呼び出し (¥1/回) 0 1000000 2000000 3000000 4000000 5000000 ・MCP / AI（450万円 / 月）: 1山行あたり30回の状況判 定（月間450万回・単価1円）悪天候時の頻繁な問い合 わせや個別文脈の確認をカバーする設定 ・ LINE Messaging API（270万円 / 月）: 1山行あたり6〜 8回の個別Push通知（月間90万〜120万通） ・ AWS（約45万円 / 月）: Cognito 、WAF Bot Control、 GuardDuty、KMS暗号化、秒単位復元など ・外部気象API（約11万円 / 月）: OpenWeatherMapおよ びRainViewerの生データ取得費（15分キャッシュ適 用） 16

実現性 電力消費 1時間で6%消費 最低輝度での常時画面オン 6% 約16 時間 8〜10 時間 1時間あたりの消費 満充電からの連続稼働 一般的な日帰り登山 iPhone17実機・最低輝度／アプリ起動・画面 画面を常時オンにし続けた場合の試算値 余裕を持って収まる 常時オン／1時間の連続計測 Xcodeでの評価では High ただしその約半分は画面表示——「地図を見続ける 」という使い方そのものの電力で、アプリ固有の計 算負荷ではない。 Display 48.7% Location 24.9% Network 11.5% ／ Overhead 11.5% CPU 3.4% ／ GPU 0% 17

まとめ まとめ まとめ｜課題と、Mt.Statelite の解決 登山者と家族が抱える課題 Mt.Statelite の解決 山の異変（気象警報・地震・危険動物）に気づく手段が、 本人の五感しかない → 入山エリアを5分ごとに自動監視し、新着リスクを本人へ LINEで即通知 圏外では、危険の判断材料も「遅れの連絡」も届かない → 一次情報API×通知設計で、圏外の山でも“気づき”を届ける （差分取得・キャッシュ・LINE集約） 家族は「無事を祈る」しかなく、通報の判断材料が「山名 」だけ → 現在地・状況をLINEで自動返信。下山予定超過は 119/110案内つきで自動エスカレーション 紙の登山届・GPS単体・地図アプリでは、これらが埋まら ない → 「計画を地図で登録 → 自動監視 → 検知したらLINE」を1 つのアプリで完結 18

APPENDIX: アプリの補足と分析

アプリの補足

INTEGRATIONS 4つの外部サービス FASTALERT MCP OpenWeatherMap RainViewer LINE Messaging API 気象警報・SNS一次 情報・地震・危険動 物・遭難ニュースの 提供。 現在の天気と１時間 刻みの天気予報を GPSの情報から取得 降水レーダーを表示 降水レーダタイルを 地図の最背面に重ね る。 登山者への通知とそ の家族への状況共有 送信のみ担当。 自分・家族のLINE ID を登録 19

NOTIF ICATIONS LINEの通知シナリオ シナリオ トリガー 宛先 内容 周辺リスクアラート 新規の警報・地震・現地報告・危険動物 を検知 本人 検知したカテゴリを1通に集約（連投防止） ルート逸脱 現在地がルートから100m以上逸脱 緊急連絡先 逸脱距離とルート名 SOS SOSボタン押下（確認ダイアログ後） 緊急連絡先 119/110の案内付き緊急通知 エスカレーション 下山予定時刻の超過を検知 緊急連絡先 119/110の案内付き緊急通知 家族への状況共有 見守り画面の「今の状況を伝える」 緊急連絡先 ステータス・下山予定・最終GPS更新＋ 現在地の地図リンク 送信前に userId を正規表現で検査し、形式が違えば送信せず警告ログのみ。送信失敗も例外を投げず、アプリ本体は止めない。 20

FA STA LE RT 「距離」で絞らず、都道府県名で絞る FASTALERT自体に緯度経度＋半径のパラメータは無いため、絞り込みは locations に渡す 地名文字列でしか行えない。そこでルート（線）を都道府県（名前）へ変換する処理を前段 に置いている。 STEP 1 STEP 2 STEP 3 STEP 4 ルートを1km間隔 でサン プリング。ハーバサイン 距離で区間長を積算し、 1kmごとに線形補間して 点を打つ 各サンプル点を Nominatimで 逆ジオコ ーディング し、都道府県 を抽出（1.1秒スリープで 逐次実行） 重複を除いた都道府県の 集合をつくる。南アルプ ス縦走なら山梨・長野・ 静岡の3県になる その一覧を locations と してFASTALERTの各ツー ルへ渡す → → → 21

FE TCH STRATEGY 二段階の取得と、ズラしたキャッシュ ① 計画時 ② 登山中の検索 一括・並列で全部取る 差分だけを取る ルート確定の瞬間に4系統を Promise.allSettled で並列取得。 ホーム画面と計画タブのどちらから開いても自動発火し、二重実 行はモジュールスコープの Set で防止する。 5分間隔で気象警報・地震・現地報告・危険動物・天気をまとめ て再取得。新規分だけをLINEに集約通知する。 登山開始前は30分おきに自動再取得。二重発火は「直近30分以 内に他画面が取得済みか」かを共有して防ぐ。 新しいプランが始まるたび、差分検知のstate（ID集合・カーソ ル・地図ピン）は全リセットされる。 要約の組み立ては関数として切り出してあり、将来的にLLM 要約に差し替えも可能。 22

FE ATURE 5 分ごとにFASTALERTを確認し、新しいものだけを伝える 差分の取り方は2種類 ID差分 — 気象警報・地震 解除や更新があっても同じIDで返り続けるため、「前回まで見た IDの集合」と突き合わせて、見たことがあるかで判定する。 初回検索だけは特別扱い 現地報告は直近7日、危険動物は直近30日をまとめて取得するが 、これは「登山開始時点で既にある情報」として 通知せず、地図 ピンとしてのみ表示 する。開始直後にLINEが鳴り続けるのを避 けるため。 時刻カーソル差分 — 現地報告・危険動物 5分 4分 1通 次々に新規投稿されるため、「前回取得時刻以降」で取る方が自 然で、API呼び出しも軽い。 検索間隔 キャッシュTTL 検知は集約して送 る 取得に失敗した回はカーソルを進めない。進めてしまうと、失敗 した時間帯の情報が二度と取得されず欠落するため。 地図ピンは、カーソルで取得した新規分をID単位で累積していくため あとから見返しても消えずに残り続ける。 23

COM PARISON YAMAP等の見守り機能と、何が違うのか 比較の観点 YAMAP等の既存見守り機能 Mt.Statelite 見守りの仕組み 位置情報を定期送信し、家族がリンクを開いて確認 する「見にいく」設計 危険を検知した瞬間にLINEへ自動でプッシュ通知 する「知らせにいく」設計 伝わる情報の中身 GPS位置情報のみ。危険かどうかの判断は受け取っ た家族に委ねられる 気象警報・地震・現地報告・危険動物の5系統を常 時監視し、危険度を判断して伝える ルート逸脱時 本人の画面にのみ警告。家族には共有されず、意図 的な逸脱時は自分で機能をオフにする必要がある 逸脱を検知すると、逸脱距離とルート名を添えて本 人と緊急連絡先の両方に自動通知 下山予定超過時 自動通知はなく、家族が更新の有無を見て自分から 異変に気づく必要がある 超過を検知した時点で緊急連絡先へ自動でエスカレ ーション通知 一次情報への到達性 共有されるのは位置情報のみで、周辺の警報や目撃 情報などの一次情報にはアクセスできない リスクカードをタップすると、参照元のSNS投稿や 記事にそのまま遷移できる 出典：YAMAPヘルプセンター「みまもり機能」「ルート外れ警告を使うには」（2026年8月時点の公開情報をもとに作成） 24

分析

OVERVIEW 分析 ② ① FastAlert MCP 概 要 提供元・検知の仕組み・データソ ース・配信カテゴリを押さえる ③ CSVデータ 分析 → → 5件の災害イベント・8,928投稿を 基礎集計・時系列・地理・Topic粒 度で分析 MCP実挙動 分析 実機で計測したレイテンシと、ド キュメントから読めない落とし穴 25

① FASTALERT MCP概要 AIとビッグデータで リス クを検知する情報基盤 約60 秒 提供元 検知から配信まで 株式会社JX通信社（2008年設立）。「記者ゼロ人の通信社」を AI解析に24時間の有人監視を組み合わせて実現している 標榜している。 導入実績と配信カテゴリ データソース X（Twitter）・各種SNS・NewsDigest（利用者600万人超） 自治体15団体が導入（東京都・熊本県・京都市・港区・杉並区 等）。配信カテゴリは計13種（自然災害・火災・ライフライン ・通信/システム障害 等） 出典：JX通信社プレスリリース／防災DXサービスマップ「AIビッグデータリスクセンサ FASTALERT」 26

② CSVデータ分析｜対象データの概要 5件の災害イベント、計8,928投稿を分析 災害イベント 種別 期間 行数 Topic数 主な対象地域 令和6年能登半島地震 地震 2024/1/1〜1/3（約2日） 3,389 1,616 石川県・新潟県・富山県 令和6年奥能登豪雨 豪雨 2024/9/20〜9/30（約10日 626 ） 359 石川県 2023年台風2号 台風・線状降水帯 2023/6/2〜6/3（約2日） 1,074 531 静岡県 2025年台風15号 台風 2025/9/4〜9/6（約3日） 1,083 407 静岡県 1,228 東京・神奈川・全国規模・静岡 ・和歌山 2026年台風6号 台風 2026/6/1〜6/4（約4日） 2,756 計画書記載の数値（行数・Topic数・kind内訳・事象トップ10・都道府県）は、CSV原本の再集計と完全一致（誤差なし）を確認。 27

② CSVデータ分析｜基礎集計 情報源はTwitterが87〜98%、 公式フィードが速報性を補 完 地震・奥能登豪雨 公式情報（mk_mode：消防等）が約10%と比較的高 い 台風6号（2026） 消防出動情報（fire_dispatch）が約13%を占める 全イベント共通でTwitterが87〜98%を占める。情報 源の内訳は、後述の検知ラグの差にも直結する。 28

② CSVデータ分析｜時系列分析 検知ラグは中央値20〜60秒。 情報源で最大100倍の差 Twitter：中央値11〜60秒 AI解析による実質リアルタイム検知の実力値 公式フィード：ほぼ0秒 消防出動情報等はAPI直接取り込みのため「検知」の 概念がほぼない Instagram：26〜49分 件数は少ないが大幅に遅い。速報性の根拠にするのは 危険 29

② CSVデータ分析｜時系列分析（深掘り） 検知が遅いのは「投稿量」ではなく 「地震カテゴリ」 当初仮説 投稿が多い時間帯ほど検知が遅れる（システム負荷） 実際 投稿密度が低い時間帯でも、地震カテゴリだけラグが 150〜350秒と高止まり 統計的裏付け 生存時間分析（Kaplan-Meier／Cox回帰）でも統計的 に確定的な差（p<10⁻⁴⁸） 示唆 地震速報を売りにするなら、他カテゴリより長めのタイム アウト設計が必要 30

② CSVデータ分析｜時系列分析（深掘り） 「投稿が多いと詰まる」仮説を、 時間軸の分解で検証 疑問 1 密度と経過時間は同じものを見ているのでは？（発災直 後は密度も高いだけでは） 疑問 2 地震カテゴリの投稿が混ざっているだけでは？（地震は 元々ラグが長い） 疑問 3 投稿本文の複雑さ・連投が原因では？ → 文字数・連投 率とも無相関で棄却 結論 本震後0〜2時間だけの一時的な「立ち上がり効果」と、地 震カテゴリ特有の持続的な分類コストという2段階のメカ ニズム 31

② CSVデータ分析｜時系列分析 「初報」のタイミングも、 投稿と同じペースで立ち上がって いた 能登半島地震 新規Topic 1,616件のうち50%が本震+23時間で到達 投稿と連動している 投稿の累積カーブとほぼ同じ順序・形状で、「話題が生ま れるペース」と「投稿が積み上がるペース」は概ね連動 台風6号 新規Topic 1,228件のうち50%が+56時間で到達（広域・ 長時間型の台風は緩やか） ただし例外もある 奥能登豪雨・台風6号は新規Topicの累積がやや後ろ倒し。 最初の話題が長く投稿を集め続け、新しい被害箇所の発生 が追いつくのに遅れる構図 32

② CSVデータ分析｜地理的分析 位置情報は平均6割が欠損、 高精度は全体の1割程度 範囲（精度） 0m（ピンポイント） 位置情報ありに占める構成比 2.9% 50m 15.3% 100m 18.4% 300m 37.6% 500m 16.7% 1,000m 9.1% 50m以下の高精度は位置情報ありのうち18.2%（全体の約7.5%）にとどまる。300m〜1,000m精度が位置情報ありの4分の1を占め、ルート沿いの絞り込みには 数百m単位のバッファが必要。 33

② CSVデータ分析｜地理的分析 「点」の事象は位置が付き、 「面」の事象は付きにくい 付きやすい（76〜91%） 多重事故・雨漏り・故障車・火災・横転事故・事故・交 通事故・救助要請 「現場で目撃して撮影・投稿」する点的な事象 付きにくい（0〜3%） 暴風・断水・システム障害・停電・地震情報・航空関連 トラブル 等 「広域・面的に発生する」事象 34

② CSVデータ分析｜地理的分析 投稿数の多さは、被害の大きさと一致しない イベント 市区町村トップ3（件数） 能登半島地震(2024) 新潟市440／金沢市417／輪島市154 奥能登豪雨(2024) 輪島市214／金沢市65／珠洲市65 台風2号(2023) 浜松市202／静岡市155／沼津市150 台風15号(2025) 静岡市192／牧之原市129／吉田町68 台風6号(2026) 横浜市471／東京都(区不明)157／川崎市123 能登半島地震は新潟市・金沢市が輪島市を上回るが、これは「新潟市消防局」発の公式投稿や人口密集地（金沢市）のSNS利用者数の厚みによるもの 投稿数の多さ＝被害の大きさではない（輪島市は投稿数こそ少ないが被害は最も甚大）。台風15号は竜巻被害地の牧之原市が2位で、こちらは実態と よく一致する例。 35

② CSVデータ分析｜災害種別間の比較 台風6号CSVに「台風と無関係なIT障害」が混入 システム障害 207件 都道府県内訳の99%が「全国規模」。大半が台風と無関係な一般ITサービスの障害だった。 混入していた具体例 Amazon Prime Video ／ ChatGPT ／ Claude ／ Instagram ／ メルカリ ／ Shopify ／ pixiv ／ じゃらん 等 FastAlertは「通信・システム障害速報」を独立配信カテゴリとして公式に持つ（2021年プレスリリースで裏付け済み）。CSVは「地 域×期間」で機械的に抽出される仕様であり、データ不備ではなく仕様である。 山岳アプリへの示唆 地域×期間だけのクエリでは無関係な情報が混ざる。事象カテゴリでの絞り込みが必須。 36

② CSVデータ分析｜Topicの粒度分析 投稿数の多さ＝重大な事象、とは限らない イベント 能登半島地震 (2024) Topic平均 最大 単独投稿比率 台風6号「関東地方で停電」308件 2.10 55 74.3% 関東広域の大規模停電1件に投稿が集中した外れ値。2位以下は Chatworkシステム障害56件、東京駅の鉄道トラブル54件 奥能登豪雨(2024) 1.74 19 71.3% 全イベント共通で7割前後が単独投稿 台風2号(2023) 2.02 64 76.1% 緊急車両出動・交通事故・ガス漏れ等の「個別現場に限定される事 象」は目撃者が限られ埋もれやすい 台風15号(2025) 2.66 67 65.1% 設計への示唆 通知ロジックは「投稿数」でなく「事象カテゴリの重大性」を軸に 台風6号(2026) 2.24 308 76.6% すべき。緊急性の高い一次情報が投稿数で埋もれるリスクがある。 37

② CSVデータ分析｜投稿本文のテキストマイニング 構造化タグには現れない情報が、 自由記述には眠っている 能登半島地震：「津波」150件 「実家」149件 頻出語15位以内。大津波警報が発表されたにもかかわらず、 現地からの一次報告だけでなく、「実家が心配」という遠隔地 事象カテゴリに「津波」という分類は存在しない。 からの言及も相当数を占める。 台風2号：河川名が上位語 台風6号：細かい地名情報 「巴川」38件・「天竜川」27件など具体的な河川名 ― 河川単 「横浜」339件・「川崎」119件・「横須賀」74件など、市区 位の危険度把握に使える情報。 町村タグより粒度の細かい地名。 事象カテゴリだけでなく、投稿本文のキーワード検索を補完的に使う設計が有効だと分かった。 38

③ FastAlert MCP実挙動分析｜レイテンシ topicsのレイテンシは limitとcategoriesで変わる limit 30→100 で11倍 0.28秒 → 3.13秒 categoriesを外すと5.5倍 0.28秒 → 1.54秒。「無指定だと市街地系に埋もれる」現象 と表裏一体 locationsの拡大は影響が限定的 1県→5県・全国に広げても、categories指定があれば0.72〜 0.95秒 分かったこと 実装上は「limitを絞る」「categoriesを必ず指定する」の2点 がレイテンシ対策として効く 13.2秒という一発の外れ値より、この再現可能なパラメータ依存性の方が実装への示唆が大きい。 39

③ FastAlert MCP実挙動分析｜実機で見つかった落とし穴 categories必須。「直近30日」ラベルは 実は数時間で打ち切 られていた 都道府県だけで絞る と 市街地系xxに埋も れる 山岳都道府県29県全体でもわずか5.5時間・100件で上限に到達。内訳は「緊急車両出動」46%が最多で 「直近30日」ラベル の罠 limit=100固定のクエリを30日分として扱っていたが、実際には投稿密度が高く、無指定版で実質5.5時 修正した内容 分かったこと 、山岳特有の投稿は数件のみ。→ categories＝気象・災害の指定が必須。 間、categories指定版でも実質24時間で上限に到達していた。 beforeカーソルで23ページ分ページネーションし、正しい30日分（n=2,256件）を再取得して修正した total_hits／has_moreを見ずに、limit件数を「期間の目安」にしてはいけない。 40

③ FastAlert MCP実挙動分析 山岳アプリに直結 facility_hazard_matchで 登山ルートの地形リスクを即時判 定 地点 座標 判定結果 白山 御前峰（山頂） 36.1550, 136.7714 地すべり危険箇所：該当 富士山 剣ヶ峰（山頂） 35.3608, 138.7275 該当するハザード区域なし 富士山 富士宮口5合目付近 35.2100, 138.7378 土石流危険渓流：該当 東京駅（対照・市街地） 35.6812, 139.7671 洪水浸水想定区域・高潮浸水想定区域 同じ富士山でも山頂（岩場）と5合目付近（斜面・渓流）で判定が異なり、地形に即した判定が確認できた。 41

④ インサイトへの接続 アプリへの示唆：用途ごとにツールを使い分ける 用途 使うツール 理由 登山ルート沿いの地形リスク把握 facility_hazard_match 投稿密度に依存せず面で判定、クォータ消費なし 危険動物（クマ等）の目撃情報 topics（その他→危険動物で絞込） 地震発生・余震状況の把握 earthquakes 気象警報・注意報の把握 weather_warnings 気象庁発表そのものを取得、SNS投稿の有無に依存しない 現地の速報的な状況把握 topics（categoriesで絞込） リアルタイム性は最も高いが、絞り込みが必須 地形ハザードマップでは判定できず、目撃情報でしか拾え ない notable_earthquakesで本震を自動特定、一次情報として 正確 42

④ 分析結果 × 本編設計｜対応関係 分析の発見は、本編の設計にこう効いた 分析での発見 本編での設計への反映 山岳都道府県だけで絞り込むと市街地系の投稿に埋もれ、 FASTALERT呼び出し時にcategories＝気象・災害を必須指 わずか5.5時間で取得上限に到達する 定し、5系統を並列取得する設計に反映 位置情報は平均6割が欠損し、50m以下の高精度は全体の約 ルート逸脱の通知しきい値を100mに設定し、位置精度のば 7.5%にとどまる らつきを吸収するバッファを確保 地震カテゴリの検知ラグは投稿密度と無関係に150〜350秒 5分間隔のポーリングと、ID差分・時刻カーソル差分による で高止まりする 新着判定を採用 投稿数の多さは事象の重大性と一致せず、単独投稿のTopic 通知ロジックは件数でなくカテゴリ単位で集約し、新規分 が全イベント共通で7割前後を占める だけをLINEへ送る設計に反映 facility_hazard_matchを使うと、同じ山でも山頂と中腹 現行版では未実装。ルート上の地点ごとに地形リスクを判 で地形リスクの判定が異なる 定する機能拡張の候補として整理 状態 反映済み 反映済み 反映済み 反映済み 今後の検討 分析で得た知見の多くは、categories指定・100mの逸脱しきい値・5分間隔のポーリング・カテゴリ軸の通知設計として、すでに本編の機能に反映されて いる。地形リスクの個別判定は、次の拡張候補として整理した。 43

参考文献 1. 気象庁 地震調査委員会／地震本部「令和６年能登半島地震についてー地震活動の評価 をまとめましたー」 https://www.jishin.go.jp/resource/column/column_24spr_p02/ 2. 内閣府「令和7年版防災白書」特集第1章第1節 https://www.bousai.go.jp/kaigirep/hakusho/r07/honbun/t1_1s_01_00.html 3. 石川県「令和6年（2024年）奥能登豪雨に関する情報」 https://www.pref.ishikawa.lg.jp/saigai/20240921ooame.html 4. 日本気象株式会社「お天気データサイエンス：2023年6月2日の台風第2号に伴う線状 降水帯の事例解析」 https://ods.n-kishou.co.jp/tech/blog/detail/6586 5. 株式会社レスキューナウ「台風15号通過時に何が起きたか」 https://www.rescuenow.co.jp/blog/column_20250909_typhoon2025_15 6. 株式会社ウェザーニューズ「歴代最強の竜巻と大雨をもたらした2025年台風15号につ いて」 https://jp.weathernews.com/blog/article-2025091902/ 7. 気象庁「台風第６号の今後の見通しについて」（2026年5月31日発表） https://www.jma.go.jp/jma/press/2605/31a/typhoon_yokoku.html 8. 株式会社ウェザーニューズ「2026年6月、日本に大雨をもたらした台風6号（チャン ミー）」 https://jp.weathernews.com/blog/article-2026061601/ 44

• https://www.jishin.go.jp/resource/column/column_24spr_p02/
• https://www.bousai.go.jp/kaigirep/hakusho/r07/honbun/t1_1s_01_00.html
• https://www.pref.ishikawa.lg.jp/saigai/20240921ooame.html
• https://ods.n-kishou.co.jp/tech/blog/detail/6586
• https://www.rescuenow.co.jp/blog/column_20250909_typhoon2025_15
• https://jp.weathernews.com/blog/article-2025091902/
• https://www.jma.go.jp/jma/press/2605/31a/typhoon_yokoku.html
• https://jp.weathernews.com/blog/article-2026061601/