逃げる先を、あなたの代わりに決める。
災害が起きたら、AI ナビゲーター「セナヴィ」が避難先を選んで道案内し、家族に安否を届けます。動けないときは、通報を家族に代わって頼めます。
座標は、AI に一度も渡しません。
| ふだん | 災害の日 | 判断の記録 | 家族の安否 |
|---|---|---|---|
 |
 |
 |
 |
| 雨雲レーダーと 周辺の避難所 |
避難先と理由3点 （30秒で自動承認） |
AIに渡した入力・ モデル名・コスト |
確認中→避難中→到着 を自動で送る |
ふだんは、雨雲レーダーと位置共有のアプリです。
出かける前に雨を確かめ、友だちと待ち合わせ、家族が帰ったのを知る。災害の日だけ開くアプリは、その日も開かれません。だから、ふだん開く理由の方を本体にしました。
AI HACK 2026 #2「業務を自律化するAIエージェント」応募作品。コードは全部公開しています → https://github.com/akiba-eda/hinamichi
本アプリは試作です。 実際の災害での利用を想定しておらず、避難の判断は自治体の避難指示とご自身の状況を優先してください。
審査基準への回答
| 審査基準 | ヒナミチの答え | 記事の節 |
|---|---|---|
| ④ 自律性 | 監視から到着判定・家族への連絡まで、人が押すボタンは 0 回 | 自律性：人が操作しない範囲 |
| ① セキュリティ | 座標・氏名・連絡先を LLM に一度も渡さない。送信前に機械的に検査する | AIに何を渡していないか |
| ② コストパフォーマンス | 2段構えで 1件 $0.011。外部データは全て無料・カード登録不要 | OrcaRouterの使い方 |
| ③ 信頼性・堅牢性 | LLM が落ちても安全ルールだけで選定して案内を続ける。テスト 75 / 49 件 | フォールバック設計 |
| ⑤ アイデア・独創性 | 災害用機能の平時流用ではなく、逆。ふだん開くアプリの仕組みがそのまま効く | まず、ふだん使えるアプリにする |
LLM の呼び出しは全て OrcaRouter 経由です。複数プロバイダを1つのAPIで扱えるゲートウェイで、ルーティング・フォールバック・コスト照合を任せています。うまくいった話だけでなく、実装してから外した機能についても書きました。
何を作ったか
災害が起きてから、あなたが何もしなくても、避難先が決まって家族に安否が届くアプリです。
AIナビゲーターの「セナヴィ」が、気象庁の速報を掴むところから、あなたに関係があるかの判定、避難先の選定、道案内、家族への連絡までを進めます。
誰のために作ったか
土地勘のない場所で被災した人を最初に思い浮かべました。
旅行先でも出張先でも、大雨警報が鳴った瞬間に「近くのどの小学校が浸水想定の外で、標高が高くて、川を渡らずに行けるか」を調べられる人はいません。地元でも同じです。私もハザードマップを見たことはありますが、いざその場で即答はできません。
もうひとつは、家族に連絡する余裕がない人です。
避難の最中は、逃げることに専念したいはずです。それなのに実際には、片手で歩きながら家族に「いま避難してる」「無事」と打つことになります。返信が来なければ心配で足が止まります。
ここを自動にすれば、逃げることだけに集中できます。ヒナミチは安否（確認中 → 避難中 → 到着）を家族へ自動で送ります。連絡のために立ち止まらなくていいようにするのが目的です。
そして、動けなくなったときのために、通報を家族へ代わりに頼める仕組みを用意しました。
まず、ふだん使えるアプリにする
防災アプリの最大の問題は、その日まで一度も開かれないことだと考えました。インストールした日に1回開いて、次に開くのは災害の日。そのときにはログインの仕方も忘れています。
なので「災害用の機能を平時にも流用する」ではなく、順番を逆にしました。ふだん開く理由がある方を本体にして、その仕組みが災害時にもそのまま効くようにしています。
セナヴィに聞く
「今日の天気は？」「ここは安全？」と聞くと、その場で調べて答えます。AIナビゲーターと名乗る以上、一方的に喋るだけでは足りないと考えました。
出かける前に、雨が降るか見る
ホームを開くと、セナヴィが今の空模様を一言で言います。気象庁の高解像度降水ナウキャストから、0〜60分の降水を読んでいます。
あと15分で雨だよ。傘、持った？
空が青いワン！1時間は降らないよ
地図のボタンひとつで、いま降っている雨をそのまま重ねられます。観測時刻付きです。
友だちと待ち合わせる
友だちを選んで落ち合う場所を決めると、メンバー全員の地図に同じ旗が立ちます。バナーには自分と各メンバーの徒歩分が並ぶので、「あと何分で着く？」を聞かずに済みます（相手の分が出るのは、位置を共有してくれている相手だけです）。
友だちの位置は相手ごとの許可制で、許可してくれた人だけ地図に出ます。アイコン付きのピンで、最後に受け取った位置と電池残量が分かります。
家族が帰ったのを知る
プロフィールによく行く場所（自宅・職場・学校）を登録しておくと、出入りしたときに家族へ通知が飛びます。登録は住所検索か「いまいる場所を使う」で、着いたとみなす半径も選べます（既定150m）。
お母さんが自宅に着きました
判定は端末ではなくサーバーでやっています。画面を開いていない・寝ている間の到着こそ知りたいからです。
同じ仕組みが、災害の日に何になるか
| ふだん | 災害の日 |
|---|---|
| セナヴィに「今日雨降る？」と聞く | セナヴィが避難先を決める（同じエージェント） |
| 自宅に着いたら家族に通知 | 避難所に着いたら家族に通知（同じジオフェンス） |
| 待ち合わせ場所に旗を立てる | 避難先で合流（同じ合流機能、色と文言だけ変わる） |
| 雨雲レーダーを見る | 豪雨警報時のハザード判断（同じタイル） |
| スタンプで「向かってる」 | スタンプで「無事」「助けて」（同じ場所にある） |
普段からスタンプを送り合っているから、いざというとき同じボタンを押せます。「災害時だけ出てくるUI」は、災害時に使えません。
使用例
ふだん：雨が降る前に知る
ホームを開くと、セナヴィが空模様を一言で言います。気象庁の高解像度降水ナウキャストを、現在地の1ピクセルだけ読んだ結果です。
{"nowMmh":0,"maxMmh":0,"startsInMin":null,"stopsInMin":null,"cloudPct":100}
→ セナヴィ「曇ってるけど、1時間は降らないよ」
雨が近づくとこうなります。
{"nowMmh":0,"maxMmh":3,"startsInMin":5,"cloudPct":80}
→ セナヴィ「あと5分で雨だよ。傘、持った？」
startsInMin はレーダーで見えているエコーの移動から出しています。数値予報モデルではなく実観測の外挿なので、分単位の「あと何分」に答えられます。
ふだんのホーム。セナヴィが空模様を一言で言う
ふだん：セナヴィに聞く
吹き出しをタップすると、聞けることが4つ出ます。
- 今日の天気は？
- ここは安全？
- 近くの避難場所は？
- いま雨降ってる？
「今日の天気は？」の答えはこうです。
千葉県浦安市は、今日の18時からは100%雨が降る予報だよ。
自由入力にはしていません。最初は自由入力でしたが、「来週の天気は？」「電車動いてる？」が来ると、LLMは手元に無い情報を推測で埋めようとします。プロンプトに「分からないと言え」と書いても、防災アプリが一度でも推測で答えたら、災害の日に信用できなくなります。
なので聞けることを絞りました。「分からない」と言わせるより、聞かれない方が確実です。 答えには、何を見て言ったか（出典と観測時刻）を機械的に付けます。
「今日は雨？」に答えるために、先に材料を足した
レーダー（降水ナウキャスト）は0〜60分しか見ていないので、そのままでは「今日」に答えられません。嘘をつくか、毎回「1時間先までしか分からない」と言うかの二択になります。
なので府県予報から今日・明日の天気文と、6時間ごとの降水確率を引く関数を足しました。
{"areaName":"千葉県浦安市",
"today":{"text":"雨所により雷を伴い非常に激しく降る","pops":[{"from":"18:00","pct":100}]},
"tomorrow":{"text":"くもり時々晴れ所により明け方まで雨で雷を伴う"}}
機能を足すより先に、答えられる範囲を広げる方が順番として正しいと思います。
ここでも座標は渡していない
4つのどれも、LLM には緯度経度を渡しません。サーバーは座標を持っていますが、地名・天気・避難場所までの徒歩分という「答え」に変換してから渡します。災害時の判断経路と同じ assertNoCoordinates() が、ここも守っています。
一次判定と同じ安いモデル（gemini-2.5-flash-lite）で、1問 $0.00005・2〜3秒です。
ふだん：待ち合わせる
友だちの詳細から「合流する」を押すと、誰と・どこでを決めるシートが出ます。相手は複数選べて、落ち合う場所は近くの避難場所・自分の避難先・相手のいる場所から選びます。
決めるとメンバー全員の地図に同じ旗が立ち、バナーに全員の徒歩分が並びます。
待ち合わせ中
浦安公園
あなた 徒歩 8分 (約617m)
ゆうた 徒歩 7分 / お母さん 徒歩 12分 / さくら 徒歩 15分
地図から任意の地点を立てられるようにはしていません。災害時に浸水想定の中を選べてしまい、避難先を安全ルールで検算している意味が無くなるからです。
友だちのピンはアイコン付きで、最後に受け取った位置・区市町村・電池残量が見えます。位置は相手ごとの許可制で、既定では共有しません。
見守りリスト。安否は自動で届き、現在地は許可した相手にだけ届く
災害の日：避難先が決まる
実際に動いたログです。2026年9月21日、関東に大雨警報が出ていた日のものです。
災害 : 大雨警報
選んだ先 : 県立行徳高校 (徒歩21分 / 標高3.2m)
理由 : 浸水想定なし / 標高3.2mで高い / 混雑6%で少ない
検算 : llm+rules
コスト : $0.013266 (LLM 3回)
経路 : OpenRouteService / 45点 / 1650m
このとき、より近い候補（徒歩13分）がありましたが選ばれていません。浸水想定区域内だったためです。大雨では「近さより高さ」を優先するようプロンプトと検算ルールの両方に入れてあります。
画面ではこう出ます。こちらは別の日に地震で発火させたときのものです。
理由が3点出る。ボタンの「(21)」は、押さなくても案内が始まるまでの残り秒数
そしてこの画面は、押さなくても30秒で次に進みます。
アーキテクチャ
Flutter (iOS/Android)
│
├─ Firestore を直接購読（アラート・安否・やりとり・位置）
│
└─ Vercel Functions ── OrcaRouter ── 各LLMプロバイダ
│
├─ 気象庁 防災情報XML（警報）
├─ 気象庁 降水ナウキャスト（雨雲）
├─ P2P地震情報（地震）
├─ 国土地理院（避難場所・標高・逆ジオ・地図）
├─ ハザードマップポータル（浸水・津波・土砂）
└─ OpenRouteService（徒歩経路）
Vercel Hobby は1デプロイ12関数までなので、全エンドポイントを api/[...path].ts 1本に束ねて lib/routes/ へ振り分けています。URLは変わりません。
外部データは気象庁・国土地理院を含めてすべて無料・カード登録不要です。
自律性：人が操作しない範囲
テーマが「業務の自律化」なので、ここを厚くしました。
cron-job.org（2分ごと）
└→ GET /api/watch/disasters
└→ 気象庁の防災情報XMLフィードを読む
└→ 新しい警報だけを alerts に書く
├ 気象警報 → 対象市区町村のトピックにだけ通知
└ 地震 → 全国へ送り、関係あるかはエージェントが判定
└→ セナヴィ起動
├ 一次判定：この災害はあなたに関係あるか
├ 避難場所を8件集め、ハザード・標高・混雑・道のりを付ける
├ 災害種別に合う候補を選ぶ
└ 安全ルールで検算する
└→ 提案を出し、30秒さわらなければ端末が自動で承認
├ 行き先が満員 → 自動で選び直し
├ 100m圏内 → 自動で到着判定
└ 家族へ「確認中 → 避難中 → 到着」を自動送信
実際のログにこう残ります。
[approval] 30秒応答がなかったため自動でナビを開始しました
押さなくても進みます。災害のさなかに画面を見て判断できるとは限りません。
30秒のカウントは端末が持っています。サーバー側で待つ設計にすると、圏外やアプリ終了と「本人が操作しなかった」が区別できないからです。サーバーは誰が承認したのかを via: "user" | "timeout" | "geofence" として記録します。押されなかったことも、状態のひとつです。
地震を全国に配信しているのも意図的です。市区町村で絞るには、誰がどこにいるかをサーバーが知っている必要があります。それをやらないと決めたので、配信は広く投げて、関連性の判定をエージェント側に寄せました。
どのモデルがいくらで何を答えたかが全部残る
AIに何を渡していないか
ここが設計の芯です。
避難場所の候補は仮名A〜Hに置き換えて渡します。 実際に送っているJSONがこれです（項目は一部省略）。
{
"disaster": {"type":"heavy_rain","title":"大雨警報","severity":0.6},
"user": {"areaName":"千葉県市川市","hazardHere":{"flood":"0.5〜3m","tsunamiZone":true}},
"candidatesPreview": [
{"id":"A","walkMin":13,"direction":"南","elevationM":1.2,"flood":"0.5〜3m","crowdPct":0},
{"id":"D","walkMin":21,"direction":"北東","elevationM":3.2,"flood":"浸水想定なし","crowdPct":6}
]
}
座標・氏名・連絡先・端末IDは含まれません。仮名と実体の対応表はサーバーのメモリ内だけに置いて、応答を受け取った時点で捨てます。
送信内容をそのままアプリ内で開ける。地名とハザードだけで、座標が無いことが読み取れる
「気をつける」では、いつか誰かが混ぜます。 なので送信前に機械的に検査して、混入していたら例外で止めています。
export function assertNoCoordinates(payload: unknown): void {
const s = JSON.stringify(payload);
if (/\b(1[2-4][0-9]|[2-4][0-9])\.\d{3,}\b/.test(s)) throw new Error("coordinate-like number in LLM payload");
if (/"(lat|lng|latitude|longitude)"/i.test(s)) throw new Error("coordinate key in LLM payload");
assertNoEmergencyPii(payload);
}
渡す理由のある個人情報は、置き場所ごと分ける
本人が動けなくなったとき、家族に「代わりに通報してほしい」と頼める機能を入れました。これには本名と住所が要ります。
119番や自治体には繋がりません。 家族・友人に「代わりに通報してほしい」と
伝えるだけの機能です。繋がると誤解されると、通報したつもりで誰にも届いていない
状態を作ってしまうので、アプリの画面でも同じ断りを出しています。
そこでコレクションごと分けました。
| 置き場所 | 中身 | AIに渡るか |
|---|---|---|
users/{uid} |
ニックネーム・アイコン | 渡る |
emergency/{uid} |
本名・住所・年齢・電話 | 渡らない |
同じドキュメントに置かなかったのは、近くにあると事故が起きるからです。「プロフィールを読んでプロンプトに入れる」コードは、いつか誰かが書きます。物理的に別の場所にして、取りに行かないと触れないようにしました。
受け取る側にも段階を作っています。通知に載るのはニックネームと市区町村だけ。ロック画面に住所を出すわけにいきません。相手が「確認する」を押して初めて読み出し、依頼を閉じると読めなくなります。
サーバーが位置を持たなくて済む設計にする
警報を「その土地の人にだけ」届けたいのですが、そのために全員の位置をサーバーに置くのは筋が悪い。
なので端末が自分の市区町村コードでFCMトピックを購読し、サーバーは警報の対象市区町村のトピックへ送る形にしました。サーバーは誰がどこにいるかを知らないまま、その土地の人にだけ鳴らせます。
OrcaRouterの使い方
2段構えでコストを削る
Named Router を2本立てました。実測値です（2026-09-22、地震1件）。
| 段 | Router | 実際に選ばれたモデル | コスト |
|---|---|---|---|
| 一次判定「関係あるか」 | hina-triage |
google/gemini-2.5-flash-lite |
$0.000034 |
| 避難先の判断 | hina-decide |
anthropic/claude-sonnet-5 |
$0.010814 |
関係ない災害は一次判定で止まるので、高いモデルは動きません。日本では地震が頻繁に起きますが、そのほとんどは自分に関係ありません。全件を高いモデルに通すと、実運用では桁が変わります。
判断が終わった時点で、インラインの usage.cost_usd を合計して記録します。
[cost] 今回のAIコスト: $0.0108(LLM 3 回)
インシデントを閉じるときに GET /v1/generation?id={X-Orca-Request-Id} で確定値を照合し直し、食い違えば確定値を正として上書きします。
ゲートウェイ側にも同じ検査を置く
アプリ側で assertNoCoordinates() を通していますが、そのコードにバグがあったら通ってしまいます。同じことを OrcaRouter の Guardrail にも置きました。
| ルール | ステージ | 動作 | 狙い |
|---|---|---|---|
正規表現 \b\d{2,3}\.\d{4,}\b
|
入力 | ブロック | 座標をゲートウェイでも止める |
PII検出 credit_card iban bitcoin_address
|
入力 | ブロック | 災害の混乱に乗じた詐欺 |
| キーワード拒否リスト（プロンプトインジェクション） | 入力 | フラグ（記録のみ） | 気づけるようにする |
本番のキーで実際に叩いた結果です。
OK カード番号 status=400 ブロック
OK 座標 status=400 ブロック
OK エージェントの実ペイロード status=200 通過
OK 家族への連絡(電話番号入り) status=200 通過
OK 普通の安否連絡 status=200 通過
下3つが通ることの方が大事でした。 止めてはいけないものを止めると、避難の案内そのものが動かなくなります。
設計で迷ったのは2点です。
電話番号とメールは対象にしませんでした。 伏せると承認カードから「連絡先は090-…」が家族に送れなくなります。家族は互いの連絡先を既に知っているので、守る価値より実害が勝ちます。このアプリが守ると言っているのは居場所であって、連絡先ではありません。
プロンプトインジェクションはブロックではなくフラグにしました。 誤検知した瞬間に誰かの避難案内が止まります。記録を取り逃すより、人の避難を止める方が危険です。
渡した分も、ゲートウェイには残らない
OrcaRouter は Zero Data Retention が既定です。設定項目ではなく、そもそも保存しません。
Requests are routed to the destination provider in memory and discarded as soon as the response comes back.
ただし但し書きが要ります。上流のプロバイダ（OpenAI / Anthropic / Google）の保持は別問題です。OrcaRouter が保証するのは自社サーバー上の話で、上流には各社のポリシーが適用されます。
なので「渡さない」と「残らない」は別々に手当てが要ります。上流に対しては渡す内容を絞ることでしか担保できません。仮名A〜Hはそのための設計です。
渡さない → 仮名A〜H・座標の機械検査・緊急時情報の分離 （アプリ側）
止める → 座標とカード番号をブロック （ゲートウェイ）
気づく → プロンプトインジェクションをフラグ （ゲートウェイ）
残さない → Zero Data Retention（既定） （ゲートウェイ）
フォールバックはチェーンで持つ
ORCA_FALLBACK_TRIAGE / ORCA_FALLBACK_DECIDE にモデルIDをカンマ区切りで並べておき、Named Router が落ちたら順に降ります。
レスポンスヘッダ X-Orca-Fallback-Level で何段目が応えたか分かるので、AgentLog に残しています。
フォールバック設計：落ちても案内を止めない
避難の案内が途中で止まるのは、最初から動かないより悪い。なので全ての外部依存に落ちどころを用意しました。
| 落ちたもの | どうするか |
|---|---|
| LLM（遅い・不正な答え） |
安全ルールだけで選定して案内を続ける（validatedBy: 'fallback'） |
| OrcaRouterの第一候補 | フォールバックチェーンで次のモデルへ |
| 経路API | 直線距離 + 80m/分の目安に切り替え |
| 多地点距離API | 直線距離のまま並べる |
| 地図タイルの配信元 | 5枚失敗したら別の配信元へ逃げる |
| 圏外 | 位置を端末に溜めて、繋がったら古い順に送る |
| 逆ジオ・標高・混雑 | 取れなかった項目だけ落として、判断は続ける |
LLMの答えをそのまま使っていません。 validator.ts が浸水・津波・土砂・満員・距離を全部当て直し、危険な候補を選んでいたら覆します。人の命に関わる判断をLLMに丸投げしないためです。ログには llm+rules（AIの答えが検算を通った）か fallback（ルールだけで選んだ）が残ります。
詰まったところ
気象庁の警報JSONが4ヶ月止まっていた
公式ドキュメントに記載のあるエンドポイントでも、動いているとは限りません。
HTTP 200 が返るので、エラーとしては一切現れませんでした。
一番効いたバグです。豪雨の警報が一度も発火しませんでした。
原因は、参照していた jma.go.jp/bosai/warning/data/warning/*.json の更新が止まっていたこと。
warning/map.json last-modified: Thu, 28 May 2026 ← 4ヶ月前
warning/120000.json last-modified: Thu, 28 May 2026 ← 同上
forecast/120000.json last-modified: Mon, 21 Sep 2026 ← 今日（生きている）
quake/list.json last-modified: Mon, 21 Sep 2026 ← 今日（生きている）
地震と予報は生きているのに、警報だけが5月で凍っていました。中身も濃霧注意報のまま。HTTPは200を返すので、エラーとしては一切現れません。
「データが取れている」と「データが正しい」は別でした。公式の防災情報XMLフィード（data.jma.go.jp/developer/xml/feed/extra.xml）に移して解決しました。こちらは生きています。
移行にあたって、フィードが「更新された文書へのリンク一覧」である性質を使いました。前回見た文書は引き直さないので、全国57の府県予報区があっても1回のポーリングで引くのは平常時0〜数件で済みます。
iOSのNLTaggerは日本語の人名を取れない
自由文から個人情報を端末側で落とそうとして、NLTagger の nameType（人名・地名の固有表現抽出）を試しました。結果はこうです。
文: 田中太郎さんと一緒に浦安市の東小学校にいます
検出: (なし)
日本語では機能しませんでした。一方 NSDataDetector は住所・電話・メールを拾えます。
文: 母は東京都千代田区丸の内1-9-1の自宅にいます
検出: 東京都千代田区丸の内1-9-1
ただしこれは実装してから外しました。
守れるのが「ハイフン付きの住所」までで、「千代田区丸の内1丁目9番1号」のような漢数字混じりは取れません。穴のある保証を掲げるより、掲げない方が強いと判断しました。
前述の「緊急時情報をコレクションごと分ける」方が、検出の当たり外れに依存しない分だけ確実です。
prompt_refは存在しない名前でも200を返す
OrcaRouter の Prompts（プロンプトをレジストリに登録して、デプロイなしで差し替える機能）を使おうとして気づきました。登録されていない名前を指定しても 400 になりません。
$ curl ... -d '{"prompt_ref":{"name":"zzz-does-not-exist"},...}'
200
注入が効いたときだけ X-Orca-Prompt ヘッダが付き、効かなければ何も起きずに素通りします。
問題は、こちらの実装が「prompt_ref を使うときはローカルのシステムプロンプトを送らない」形だったことです。登録名を一文字打ち間違えると、セナヴィが素のLLMとして動きます。 誰も気づきません。
命に関わる判断をさせているので、指示が消える方の事故は許容できない。システムプロンプトは常に自前でも送るようにしました。注入が効いた場合は同じ趣旨の指示が二重になるだけで害はありません。
降水ナウキャストのタイルはz=10が上限
雨雲レーダーを地図に重ねるとき、z=11以上を要求すると334バイトの空タイルがHTTP 200で返ります。
エラーにならないので、拡大した瞬間に雨雲だけ消える挙動になります。maxNativeZoom: 10 を指定して、z10のタイルを引き伸ばす形にしました。
徒歩の距離が直線だった
候補カードの「徒歩◯分」は直線距離÷80m/分で出していたのに、地図に描く線だけが実際の経路でした。数字と線の長さが食い違います。
さらに悪いことに、南行徳・浦安は川と運河で分断されていて、迂回率が候補ごとに1.22〜1.66倍とばらつきます。一律の係数で補正しても順位は直りません。直線では近いのに橋を回ると遠い候補を、AIがそのまま選んでしまう。
OpenRouteServiceの matrix API で候補の実距離を1回にまとめて取り、並べ替えるようにしました。
現時点の制約
- 避難場所の混雑率は、このアプリ内の誘導数から出した推定です。 実際の受け入れ状況ではありません。国土地理院の避難場所データに収容人数が含まれていないため、一律300人と仮定しています
- 通報は119番や自治体に繋がりません。 家族・友人に「代わりに通報してほしい」と伝えるだけです
- 避難先の判断に20秒ほどかかります（
claude-sonnet-5の応答が23秒だった回があります）。一次判定は2秒以内なので、「関係あるか」は即答できます - 氏名は端末側で検出できません（前述）
- iOSシミュレータにはAPNsが無いためプッシュが届きません。Firestoreの購読でローカル通知に落としています
- 合流の徒歩分は、相手の最終位置からの直線を80m/分で概算しています。 経路APIを人数分は叩きません。位置を共有してくれていない相手の分は出しません（分からないものを埋めない）
- よく行く場所の到着通知は、位置がサーバーに届いた時に判定します。 「現在地をフレンドに共有」がオフの間は位置を測らないので、出入りも検出しません（電池を削らないための元栓）
おわりに
「AIに何をさせるか」と同じくらい、**「AIに何を渡さないか」**を考える時間が長いハッカソンでした。
避難先の判断にLLMは要ります。ハザード・標高・混雑・距離・災害種別を突き合わせて理由を言語化するのは、ルールだけでは書ききれません。
けれど、そのためにあなたが今どこにいるかを外部のモデル提供者に渡す必要は無い。仮名A〜Hと特徴だけで足りました。
OrcaRouterは、この「渡すもの・渡さないもの」をアプリのコードから切り離せるのが良かったです。Guardrailはゲートウェイ側のキーに紐づくので、アプリを再デプロイせずにポリシーを変えられます。
リンク
- リポジトリ: https://github.com/akiba-eda/hinamichi
- 設計書: リポジトリ内
docs/ヒナミチ_設計書_v1.md
#AIHACK #OrcaRouter