10_GALBO

01|Problem 課題 01｜情報は人に届く でも、人は「行動」には行きついていない Problem01 Problem02 Problem03 防災 × 日常の接点 安全な判断 災害情報 × 行動 防災が 非常時で終わる ☟ 日常に繋がらない × 人の心に届く 伝え方 正しくても動けない 同じ内容でも、判断しやすい伝え方は 人によって違う ☟ 人の心に繋がらない 防災情報が 行動まで届かない ☟ 行動に繋がらない Solution：「日常」と「人」と「行動」を繋ぐこと 情報を「届ける」防災から、行動を「支える」防災へ。 2

02|Concept 施策構想 02｜足りなかった「繋ぐ仕組み」を、つくる 日常理解を、災害時の行動支援へ Concept01 Concept02 Concept03 防災 × 日常の接点 安全な判断 × 災害情報 × 行動 人の心に届く伝え方 ☟ ☟ 日常から、 あなたを知る 安全性は変えず 届き方を変える 今できる1歩にする 解決策 解決策 解決策 日常的利用 個別最適 災害時利用 会話・予定・思い出 家族との関わり 安全性 関わり方構築 FASTALERT 現在地・経路・状況 ☟ 災害情報を、 情報を「届ける」防災から、行動を「支える」防災へ。 3

03|Our Proposal 提案 03｜ What’s AIMO? 日常理解を、災害時の行動支援へ 一律の情報提供では実現しなかった理解され、行動に繋がる防災 Solution｜AIMO 日常：関わり方 ・予定 ・思い出 ・会話 ・家族☞日常であなたを理解 災害時： 利用者ごとに・伝え方 ・情報量 ・行動提案 を個別最適化 情報を「届ける」防災から、行動を「支える」防災へ。 4

04|Analysis 分析 3つの「繋ぐ」を、分析から機能へ 安全な判断 × 人の心に届く伝え方 Analysis01|「日常」から、あなたを理解する 01｜日常と接点構築 図1 日常データの利用者理解精度向上度 会話・予定・思い出・家族との関わり 災害時だけでは得られない文脈を蓄積 81.8% 評 価 指 標 67.2% 日常データ追加 「「理解精度」向上 「理解のズレ」減少 ☞日常利用機能 02｜「いつものあなた」を理解 日々の利用 × 行動 × 関係性から 普段の状態・生活文脈を把握 ☞日常理解機能 03｜「もしも」の支援へ 日常理解 × リアルタイム災害情報 初期診断 結果のみ 全日常 データ追加 → 今の状況に合う行動支援へ ☞災害時個別最適化 04｜日常と災害を分断しない 日常 → 理解 → 災害時支援 → 日常→ 理解を継続・更新 ☞継続的なAIMO Concept01｜日常で育てた「あなたの理解」を、もしもの行動支援へ 情報を「届ける」防災から、行動を「支える」防災へ。 6

04|Analysis 分析 3つの「繋ぐ」を、分析から機能へ 安全な判断 × 人の心に届く伝え方 Analysis02|「関わり方」を、測れる形にする 図2 関わり方の時系列更新グラフ 関 わ り 方 評 価 指 標 同じ人でも、日々 求める関わり方は 変わる 01｜自分視点×相手から視点 ☞関わり方生成診断機能 0.65 0.35 AIMO側の推定 関わり方に追従 利用18日目 02｜場面別回答 → 関わり方 固定的な性格タイプにしない ☞8軸プロフィール機能 03｜傾向×状況で変化 ☞状況別関わり方 調整機能 04｜8軸を「届き方」へ変換：8軸プロフィール×状況 安全判断を変えず、伝え方だけを調整 ☞個別伝達機能 Concept02｜関わり方の変化を捉え、安全は変えず「その人に届く伝え方」へ 情報を「届ける」防災から、行動を「支える」防災へ。 7

04|Analysis 分析 3つの「繋ぐ」を、分析から機能へ 安全な判断 × 人の心に届く伝え方 Analysis03|災害情報を「自分ごと」にする 図3 生活文脈量の比較図 関 連 投 稿 件 数 743件 情報を 「私の生活に必要な範囲」 まで絞る 190件 東京都全部の 災害情報を通知 現在地のみの 災害情報を通知 必要な範囲の 災害情報を通知 01|投稿監査 ☞災害情報読み取り機能 02｜災害状態を生活影響への変換 ☞災害－生活影響辞書 03｜投稿増加/検知遅延 ☞ 災害状態逐次更新 04｜現在地/目的地/経路/家族位置を照合 必要な範囲まで絞り、 ☞ 自分との関係照合機能 Concept03｜災害情報 不要な情報を減らす 「私に関係する状態」へ変換 情報を「届ける」防災から、行動を「支える」防災へ。 8

04|Analysis 分析 3つの「繋ぐ」を、分析から機能へ 安全な行動の作り方 Analysis04|「次に必要な情報」を先回りする 図4 事象遷移図 01｜投稿の変化探知 浸水・冠水 ⇕ 河川増水 ☞災害状態の変化検知機能 偶然より 多く観測 災害事象には 「次の変化」 パターンがある 04｜気象｜道路｜河川｜鉄道｜避難情報 ☞必要情報の選択・再取得機能 02｜事象連鎖 ☞次の 災害状態の変化 予測機能 03｜時間 × 場所 × 事象 次の生活影響推定 ☞次に必要な情報の特定機能 Concept03｜私に関係する状態」の変化 次に必要な情報へ先回り 情報を「届ける」防災から、行動を「支える」防災へ。 9

04|Analysis 分析 3つの「繋ぐ」を、分析から機能へ 安全な行動の作り方 Analysis05|「今できる一行動」を決める 01｜災害状態 × 現在地 × 取得情報 ☞行動候補の生成機能 02｜行動候補 × 災害情報 × 移動条件 → 危険選択肢除外 ☞安全性 チェック機能 04｜1つの行動に絞る→実行 → 状況を再取得 → 変化に応じて再判断 ☞1つの行動の逐次更新機能 03｜安全な候補 ☞1つの行動 決定機能 Concept03｜必要な情報 →「今できる安全な1歩」へ変換・更新 情報を「届ける」防災から、行動を「支える」防災へ。 10

05|Use Case 利用場面 05-01|AIMOの利活用パターン 1人の日常 みんなでAIMO 災害時 予定 通学路 思い出 友達との予定 いつものあなた 趣味 思い出 いつものお迎え担当 価値観 返答 行動履歴 関わり方 継続的に更新 いつもの あなた 返答 数年後 ↓ 子供加入 行動・成長履歴 お迎え最適解 みんなの 記録 価値観 生活パターン 子供が成長後も ずっと使えるAIMO 行動履歴 生活パターン みんなの記録 必要な災害関連情報 今あなたにできる 行動① 更新 次の行動② 情報を「届ける」防災から、行動を「支える」防災へ。 12

05|Use Case 利用場面 05-02|シナリオベースの関わり方診断 自分のAIMOが生成 一人暮らしの 大学生(21歳) 乳幼児（2歳） 乳幼児の1５年後 保護者(30歳) 高校生（17歳） 自発サポート まず 結論を 提示 背中を 押して 安心を 根拠を基に 最適解を 提示 情報を「届ける」防災から、行動を「支える」防災へ。 13

05|Use Case 利用場面 05|Use Case 利用場面 05-03|AIMOとの1日Vlog 1日の流れ AIMO 大学生(１９歳) 診断結果：根拠を基に結論が欲しいタイプ 習慣化 日常を共に過ごす存在へ AIMO との 1日 今日楽しかった～ AIMO の 頭の中 いいね！何したの～？ 今日の 記憶 情報を「届ける」防災から、行動を「支える」防災へ。 日々 更新 14

05|Use Case 利用場面 05-04|AIMOと災害時 豪雨が発生 大学生(19歳) 診断結果：根拠を基に 結論が欲しいタイプ AIMOがFASTALERTを基に情報を取得 安全は変えず、届き方を変える ●FASTALERT ●道路/鉄道情報 大雨・冠水取得 経路候補・迂回運行取得 ●気象情報 短時間予測/危険度 AIMO ●個人利用：個人状況整理（現在地/予定/いつもの道） 安全 経路 AIMO：根拠思考 根拠 いつもの道； 冠水/危険度 高 AIMO：根拠 危険度：高 冠水 結論提示 結論：安全経路の西口から帰宅 ☞安全に帰宅するまで1つずつ指示 情報を「届ける」防災から、行動を「支える」防災へ。 15

05|Use Case 利用場面 母（30歳）乳幼児 未来君（2歳） 診断結果：気持ちを共有して背中を押してほしいタイプ 05-05|AIMOとのチーム利用の1日Vlog AIMO 1日の流れ 思い出構築 チーム 利用 AIMO との 1日 今日の未来くんのお迎え AIMO:背中を押す チーム 利用の AIMO パパAIMOに聞いてみよう！ 初めて歩いた記念日だ！ ママAIMOとパパAIMOが 覚えておくね！ パパAIMO： 帰り遅くなりそう AIMO：気持ち共有 ママ担当に決定！ 今日の 記憶 大忙しで大変だけど気を付けてね！ 情報を「届ける」防災から、行動を「支える」防災へ。 16

母（30歳）乳幼児 未来君（2歳） 診断結果：気持ちを共有して 背中を押してほしいタイプ 05|Use Case 利用場面 05-06|AIMOと災害時 豪雨が発生 AIMOがFASTALERTを基に情報を取得 安全は変えず、届き方を変える ●FASTALERT ●道路/鉄道情報 大雨・冠水取得 経路候補・迂回運行取得 ●気象情報 短時間予測/危険度 AIMO ●個人利用：個人状況整理|●チーム利用：家族との状況整理 安全 経路 AIMO：気持ち共有 いつもの道、冠水！ 冠水怖いよね 安全経路を考える！ 危険度：高 冠水 AIMO：背中を押す 安全経路の西口から帰宅すれば安全だよ！ ☞背中を押して安全に帰宅するまで1つずつ指示 情報を「届ける」防災から、行動を「支える」防災へ。 17

05|Use Case 利用場面 05-07|AIMOと災害時 豪雨が発生 母（30歳）乳幼児（2歳） 診断結果：気持ちを共有して 背中を押してほしいタイプ AIMOがFASTALERTを基に情報を取得 安全は変えず、届き方を変える チーム機能による役割調整 AIMO：気持ち共有 いつもの道、冠水！ お迎え誰にしようか、 一緒に考えよう！ パパAIMO：間に合わない AIMO：背中を押す 気象庁 6時に止む お迎えは、止んでから がいいね！ 家族それぞれの「今」をつなぎ、動く人を決める AIMO同士が状況を共有し、対応の重複や不要な移動を防ぐ 情報を「届ける」防災から、行動を「支える」防災へ。 18

05|Use Case 利用場面 母（45歳）診断結果：気持ちを共有して背中を押してほしいタイプ 未来君(17歳）診断結果：説得力のある理由付きの答えがほしいタイプ 05-08|AIMOと災害時 15年後にまた豪雨が発生!? AIMOがFASTALERTを基に情報を取得 安全は変えず、届き方を変える AIMO：気持ち共有 いつもの道、冠水！ 未来君、大丈夫かな？ 聞いてみよう！ 未来君AIMO：無事だよ！ 安心した！帰宅方法は？ 未来君AIMO：「西口循環線バス」 AIMO：説得力のある 理由付きの答え 東口は冠水！ 気象庁 7時に止む バス情報 7時運転再開 安全経路 西口循環線 西口循環線バスで帰宅 □迎えを呼ぶ AIMO：背中を押す 西口循環線を使って帰宅するって！ 安全にきっと帰ってくるよ！ 安全な帰宅までの次の一手 バス情報 西口循環線7時4分 「守られる子ども」から、「自分で動ける家族」へ 15年の日常理解をつなぎ、それぞれに合った安全な行動を支える 情報を「届ける」防災から、行動を「支える」防災へ。 19

06|Creating Shared Value 事業展開 06|既存の「情報 × 接点」を繋ぎ、日常から防災を広げる 情報も接点もある。足りなかったのは、それらを行動まで「繋ぐ役」 AIMO 既存の災害情報と日常の生活接点を横断し、1人ひとりの今できる一歩へ変換する 「繋ぐ」から始めるから、AIMOは実現できる 情報を「届ける」防災から、行動を「支える」防災へ。 20

07｜DEMO Movie|AIMOが実現する世界 AIMOは、災害時だけではなく、 日常から1人ひとりを理解し、「情報」から「行動」へ変える防災支援を実現する 日常からあなたを知り、災害情報を“今できる安全な一歩”へ変えるAIエージェント 情報を「届ける」防災から、行動を「支える」防災へ。 21

appendix

Concept 日常理解を、災害時の行動支援へ 一律の情報提供では実現しなかった「理解され、行動につながる防災」 災害時だけ利用される防災アプリではなく、 日常から利用者一人ひとりを理解し、 災害時にはその人に最適な伝え方で 「今できる一歩」を届けるAIエージェント 「AIMO」を提案する ■課題探索結果 現在の防災には情報は届い ているのに、 ◼ 避難行動につながらな い ◼ 一律の避難情報では人 によって伝わり方が異 なる ◼ 日常生活を考慮した防 災支援が不足している ■解決すべき課題 「情報不足」ではなく 「一人ひとりに合った伝え 方」である 情報提供 安心して 利用者理解 避難できる社会 AIMO 行動変容 個別最適な コミュニケーション ■課題解決策 AIMOは、 日常の ・関わり方 ・予定 ・思い出 ・会話 ・家族とのつながり を理解し、 災害時には 利 用者ごとに・伝え方 ・情報量 ・通知タイミング ・行動提案 を個別最適化する 23

Background

Background Background1-1 短い時間に非常に強い雨が降る回数が増えている 1.5倍増加 1.8倍増加 背景(近年の気象変化)：短時間豪雨は増加 全国アメダスで観測された 1時間降水量50㎜以上の年間発生回数は、1976年～2025年の期間において10年あたり27.8回増加 この傾向は99％の信頼水準で統計的に有意 1976年～1985年の平均：約226回/年 2016年～2025年の平均：約340回/年(約1.5倍) 80㎜/h以上の発生回数も約1.8倍に増加 出典：https://www.data.jma.go.jp/cpdinfo/extreme/extreme_p.html

• https://www.data.jma.go.jp/cpdinfo/extreme/extreme_p.html

Background Background1-2 豪雨の問題は、「雨が降ること」だけではない 複雑化する災害の現実 奥能登豪雨(2024年9月) 台風10号(2024年8月) 地震から復旧途上にある地域で 記録的な雨を観測 (121㎜/h) 500万人を超える人々に避難に 関する情報が発表 数万人に避難指示、停電、 河川氾濫、土砂災害が同時に発生 航空、鉄道、バス、製造業、 電力供給などに広範な影響が発生 地震復旧工事の関係者も含む 行方不明者の発生 図〇 1時間降水量80㎜以上の年間発生回数 判断は「避難」だけでなく、 帰宅、会社残留、子供の迎え、 家族との役割分担など、 日常の予定や社会的役割を含む 図から読み取れる内容 近年は短時間に道路冠水や河川増水を生じさせる 豪雨の発生機会が明確に増加している。 災害支援には、事前に長時間かけて検討する 仕組みだけでなく、状況変化を検知して 一手ずつ行動を促す仕組みが必要である。 短時間豪雨の増加により、災害の発生頻度だけでなく、生活への影響も複雑化している。 災害時には、単に「雨が降っているか」ではなく、生活への連続的な影響を判断する必要がある 出典：https://www.reuters.com/world/asia-pacific/torrential-rain-japan-floods-quake-stricken-noto-region-2024-09-21/ 出典：https://www.reuters.com/world/asia-pacific/japan-hit-by-heavy-rain-power-outage-typhoon-shanshan-makes-landfall-2024-08-29/

• https://www.reuters.com/world/asia-pacific/torrential-rain-japan-floods-quake-stricken-noto-region-2024-09-21/
• https://www.reuters.com/world/asia-pacific/japan-hit-by-heavy-rain-power-outage-typhoon-shanshan-makes-landfall-2024-08-29/

Background Background1-3 豪雨災害では、判断できる時間が短くなっている 防災情報は既に大量に存在する 災害情報を自分事として捉えにくい 現在の課題は、災害情報がないことではなく、 複数の情報から自分に必要な情報を選ぶことである 地域単位の災害情報だけでは、自分の生活への影響まで判断しにくい 情報を自分の生活条件へ変換する負担が利用者に残されている 災害時には、様々な情報が短時間に大量に発信される 気象情報 自治体情報 河川・ 土砂災害情報 地域単位の情報と、個人の状況にはギャップがある 交通・ インフラ情報 ・気象庁 ・雨雲レーダー ・警報・注意報 ・避難情報 ・避難所解説情報 ・防災行政無線 ・河川氾濫情報 メディア・ ニュース SNS・投稿 企業・ サービス情報 その他の情報 ・テレビ ・ラジオ ・ニュースサイト ・緊急速報 ・X(旧Twitter) ・地域の投稿 ・現地の写真 ・動画 ・運行 ・営業状況 ・学校 ・会社連絡 ・宅配 ・物流情報 ・家族 ・知人からの連絡 ・防災アプリ通知 ・地域コミュニティ ・土砂災害警戒情報 ・鉄道運行情報 ・道路通行止め ・危険度分布 ・ライフライン情報 情報の「量」は十分にあるが、利用者によっては 整理されない「情報の山」になっている 利用者が直面する状況 情報が多すぎて、どれを見ればよいかわからない 情報の意味や重要度を判断するのが難しい 複数の情報を比較・整理する時間的な余裕がない 個人の状況 (ミクロ情報) 地域単位の情報 (マクロ情報) このギャップを 利用者自身が 埋めなければならない ・〇〇市に大雨警報 ・△△川が氾濫警戒 ・避難指示を発令 ・今日の子どもの迎えがある ・通勤経路の橋が冠水しやすい ・家族は高齢で避難が必要かも ・自宅周囲の地形や過去の浸水 利用者の負担：情報を「自分の生活条件」に変換する作業 情報を収集 情報を理解 自分の生活状況と照合 行動を判断 複数の情報源を 探して集める 内容や意味を 読み解く 生活条件に 当てはめて考える 今自分が 取るべき行動を 決める この一連の作業が、災害時の迅速な行動を妨げる要因になっている 利用者一人ひとりに必要な情報を整理し、生活条件と結び付けて「今できる行動」へ変換する支援 27

Background Background1-4 災害情報が増える一方で、「行動への変換」が 課題 になっている 情報を受け取っても、 すぐ行動できるとは限らない 人によって動きやすい伝え方が異なる 情報提示だけではなく、実行可能な行動への変換が必要 必要な安全行動が同じでも、 これを受け入れやすい伝え方は一律ではない 情報と行動の間には、さまざまな壁がある 同じ情報でも、人によって受け取り方が異なる 状況の理解が 追い付かない 選択肢が多くて 判断できない 生活の制約で 動けないことがある 行動の具体性が 不足している 根拠を重視する人 行動後押しして ほしい人 気持ちに寄り添って ほしい人 短く端的に 伝えてほしい人 ・仕事 何が危険で 何をすべきか 分からない… どの情報を 信じればいいの？ ・家族の迎え ・移動手段がない 結局、 「何を」「いつ」 「どこで」やればいいの？ ・時間の余裕がない ・理由やデータが欲しい ・具体的な行動が欲しい ・不安を受け止めてほしい ・共感してほしい ・納得できると聞きやすい ・背中を押してほしい ・比較や検討をしたい ・シンプルな指示が良い ・安心できる言葉が必要 など 必要なのは「情報」ではなく、「行動につながる支援」 情報を受け取る ・長い説明は負担 ・要点だけ知りたい ・結論からほしい 状況を理解する 行動を選ぶ 伝え方を個別に最適化することが、行動につながる鍵 すぐに実行できる 行動へ変換される 理解のしやすさが高まる 行動への心理的ハードルが下がる 利用者の状況に合わせて「今できる一手」を 提示することが重要 信頼感が築かれる 情報を受け入れやすくなる 必要な行動をためらわずに 取れるようになる 一人ひとりの特性や状況に合わせた伝え方の設定が不可欠 「今できる行動」に変換し、一人ひとりに合った伝え方で支援することが必要 28

Background Background2-1 日常利用は、単なる利用促進ではなく、非常時支援の準備である 災害時だけではなく、日常から利用され続ける防災サービスの必要性を示す 日常利用されるサービスの特徴と既存防災アプリの課題を整理し、 平常時の関係構築が災害時の個別支援につながることを示す。 ①既存防災アプリの課題 ②日常利用されるサービスの特徴 ③防災サービスの展開 災害時だけでは 利用が続かない 会話・関係・記憶が 継続利用を生む 日常利用が 災害時支援につながる 日常会話がある 日常から利用者を理解 ・災害時のみ利用される仕組み ・利用者理解が蓄積されない ・平常時の利用価値が不足 気軽にやり取りができる 思い出や記憶が残る 過去のやり取り履歴が蓄積 利用者との関係が深まる 信頼や安心感が生まれる 防災アプリは継続されにくい 利用する理由が日常に存在する 生活習慣・関心・価値観を把握 関係性を継続的に構築 過去のやり取り履歴が蓄積 非常時は理解を活かして支援 信頼や安心感が生まれる 平常時と災害時をつなぐ 防災サービスへ 日常の会話や思い出を通じて利用者を理解し、 その関係性を災害時の個別支援へ活用する仕組みが重要となる。 29

Background Background2-2 一般的な写真には、撮影者やその時の会話が十分に残らない 課題のポイント 写真や動画は「見たもの」中心 撮影者や背景にある会話・感情は残りにくい 思い出の文脈や関係性が失われやすい 現状のイメージ 理想のあり方 会話 被写体は残るが、 背景の関係性は見えにくい 撮影者・関係者 感情・思い 思い出を取り巻く文脈まで残すことで、 より深い理解につながる 思い出は「記憶」だけでなく、「関係性や感情を含めて残す」ことで、 利用者理解の質が高まる 30

Background Background2-3 家族や友人がいても、日常の小さな出来事を継続して共有 できるとは限らない 課題のポイント 日常の小さな出来事は、話す相手が限られる 他愛のないことを話せる機会が少ない 継続的に自分を理解してくれる存在が常に傍にいるとは限らない 現状のイメージ こんなこと 話していいのかな？ 話す機会がなく、 理解が深まらない 理想のあり方 どんなに小さなことも 受け止めてくれる 日常の積み重ねを通して、 自分を理解してくれる存在がいる状態 小さな日常を安心して話せる相手がいることが、継続的な利用と深い理解につながる 31

Background Background2-4 防災行動は、自分一人の判断だけでは完結しない 課題のポイント 防災行動は「自分の安全」だけでは完結しない 守りたい人や家族の状況を考慮する必要がある 周囲との連携や役割調整が欠かせない 現状のイメージ 理想のあり方 おばあちゃんは大丈夫？ 待機する？ 子供と避難するね 避難する？ 避難所を 確認するよ 判断の負担が大きく、 最適な行動を選びにくい 関係性を踏まえた役割分担で、 安全でスムーズな行動につながる 人は関係性の中で安心して判断・行動できる 防災支援には役割分担を含めたサポートが必要である 32

Background Background3-1 一人暮らしが増え、家族も別々の場所で生活している 背景：家族を前提とした支援だけでは対応できない社会へ 災害時には、家族や周囲の人との相談、同行、安否確認、役割分担が安全行動を支える。 しかし、日本の世帯構造は、同居家族を前提とした支援だけでは対応できない方向へ 図〇 日本の一般世帯に占める単独世帯割合の推移と将来推移 2050年には、一般世帯の 約2.3世帯に1世帯が単独世帯 ※44.3％＝約2.3世帯に1世帯 単独世帯が約2,330万世帯へ 一般世帯の中で最大の類型になる見込み 図から読み取れる内容 防災支援を同居家族による声掛けだけに依存することが難しくなり、 平常時から利用者を理解し、災害時に最初の行動を一緒に整理するデジタル上の伴走者が必要 出典：https://www.ipss.go.jp/pp-ajsetai/j/HPRJ2024/hprj2024_gaiyo_20240412.pdf 33

• https://www.ipss.go.jp/pp-ajsetai/j/HPRJ2024/hprj2024_gaiyo_20240412.pdf

Background Background3-2 家族や友人がいても、日常の小さな出来事を継続して共有できるとは限らない ▽単独世帯の増加はすべての一人暮らしが社会的に孤立していることを意味しない ❶情報収集 警報確認や 危険判断を 1人で行う ❷避難行動 ❸家族連絡 移動手段の確保や 持ち物準備も 自分で対応 同居家族でも、 災害時に 同じ場所にいるとは 限らない ▼災害時支援には、次の2つを同時に成立させる必要がある ① 一人でも行動を始められる 個人支援 ・相談できる相手が身近にいない場合でも、 自分で判断し、最初の一手を踏み出せる支援 ・情報の整理、リスクの判断、行動の提示まで 一人ひとりに合わせてサポート ② 家族、学校、園、会社、友人と 協力できるチーム支援 ・複数の人がそれぞれの場所に居ても、 情報共有や役割分担を行い、協力して安全を 確保できる支援 ・予定や状況を踏まえ、最適な連携と行動を調整 単独世帯や生活様式の多様性により、 災害時に家族だけを前提とした支援では対応が難しくなっている 一人でも安全行動を開始できる個人支援と、 離れた場所にいる家族や友人と協力できるチーム支援を両立する仕組みが必要 34

Background Background3-4 警報を受け取ることと、安全行動を始めることは同じではない ①複数の判断過程が存在する (Protective Action Decision Model) 人が、安全行動を開始するまでに、 次のような判断過程が存在する ・危機の認知 ・情報源の信頼 ・本人への影響の確認 ・行動選択肢の評価 社会的手掛かりが ② 行動開始を後押しする 警報に対する反応は、 情報の内容だけでなく、 周囲の人が行動しているか、 家族や知人から連絡があったかといった 社会的手掛かりにも影響される 米国科学・工学・医学アカデミー研究でも、 他者が推奨行動を取っていることを 「自分に危険が及ぶか」 見聞きする社会的手掛かりは、 「どの行動が可能か」 安全行動を開始する可能性を高める 「その行動を実行すると別の問題はないか」 とされている が判断できなければ、行動は開始されにくい 警報が正確であっても、 出典：https://link.springer.com/article/10.1007/s13753-022-00452-z 出典：https://www.nationalacademies.org/read/24935/chapter/ 警報文の構造が ③ 理解と行動に影響する 携帯電話向け緊急警報に関する研究では 短い警報文は迅速な伝達に適する一方、 具体的な場所・危険・行動が不足すると 混乱や不安を生じさせる可能性がある 文字数を増やすだけでなく、受信者が 「誰が、どこで、何を、いつまでにするか」 を理解できる構造が必要 出典：https://pmc.ncbi.nlm.nih.gov/articles/PMC11424238/ 先行研究から整理できる行動開始条件 災害時の行動支援メッセージには、少なくとも以下が必要である 一般的な警報は①～④を伝えることはできる ⑤～⑦は利用者の生活状況を知らなければ提示できない 35

• https://link.springer.com/article/10.1007/s13753-022-00452-z
• https://www.nationalacademies.org/read/24935/chapter/

Background Background3-5 災害情報はリアルタイム化しているが、そのままで個人行動 に利用できない SNS、ニュース投稿、画像、位置情報などのリアルタイムデータは、 公的観測だけでは把握しにくい局所的な異変を早期に発見できる可能性を持つ 災害時ソーシャルメディア研究では、現地から発信される投稿の一部には被害状況、交通障害、 救助要請などの即時性の高い情報が含まれることが確認されている。 出典：https://arxiv.org/abs/1407.7071 災害投稿を収集できれば安全支援が 完成するわけではない リアルタイムデータは、 以下には有効 しかし、以下を判断するには 異変を発見する 投稿内容が正しいか 現地の変化を 補足する 利用者の現在地に 関係するか 追加の照合が必要 この節から示される役割分担 本提案では、情報源の役割を次のように分ける 構成要素 投稿急増を 検出する どの行動 勧めるべきか 主な役割 FASTALERT等の リアルタイムデータ 現場の異変候補を 早期に発見する 気象・河川・交通 自治体情報 危険の程度と 公式性を確信する 予定・習慣・経路 チーム情報 利用者への 影響を判断する AIMO 情報を、その人が 動ける一手へ翻訳する 公的情報や利用者の生活情報との照合が必要 36

• https://arxiv.org/abs/1407.7071

Background Background3-6 「性格」ではなく、「どう関わられると動きやすいか」を見る 災害時にはすべての利用者に同じ文章を送る方法が合理的とは限らない ある利用者は、危険を感じるとすぐに行動できる一方、別の利用者は根拠を理解しなければ動けない 選択肢がある方が動きやすい人も入れば、判断事項が増えると動けなくなり、 一つの行動を明確に示してもらう方が良い人もいる また、不安な気持ちを受け止められてから行動を示されえる方が良い人と、 感情的な説明を省き、短く指示を受けたい人もいる。 選択肢があると 自分で選べて安心 危ないから すぐ動くよ 避難行動に関する実験研究の知見 ・個人のリスク態度や個人差をモデルに含めることで 避難判断の予測性能が改善することが示されている ・集団での意思決定は、個人での意思決定の単純な合計ではなく、 グループ構成や意思決定方法によって変化する 出典：https://arxiv.org/abs/1304.4704 示唆：災害支援システムは単に危険度に応じて通知強度を変えるだけでなく、 利用者ごとに次の要素を調整する必要がある 展開：本提案における「関わり方診断」8軸の必要性に繋がる 37

• https://arxiv.org/abs/1304.4704

Background Background 次の3つの変化として整理できる 第1の変化 第２の変化 第３の変化 災害の時間的切迫が 高まっている 生活と人間関係が 分散している 情報量は増えたが 行動への翻訳が不足 職場 学校 幼稚園 塾 短時間豪雨など、 状況が短時間で変化する 災害の増加 単独世帯が増加し、家族世帯でも 家族は職場、学校、塾など、 複数の場所に分かれている 利用者には、全ての情報を 検討して行動する 災害行動は個人の避難だけでなく 迎え、帰宅、待機、買い物、 安否確認などの協働問題へ 時間がない場合がある 利用者の予定・経路 家族関係に結び付け、 今すぐ実行する一手として 提示する仕組みは十分でない 38

Background 災害情報を一斉に通知するだけではなく、利用者の日常、 予定、経路、大切な人、受け取りやすい関わり方を踏まえ、 その瞬間に実行可能な一つの安全行動へ変換できないか？ 本施策の構成 AIMOが理解し調整すること 平常時から利用者との関係を構築するAIMOと、 リアルタイム災害情報を検知するFASTALERTを 組み合わせる AIMOは、利用者の病気や心理状態を 判断するものではない。 日常の会話や「関わり方診断」を通じて AIMO FASTALERT どの程度詳しく説明してほしいか 選択肢が必要か 背中を押してほしいか 気持ちを受け止めてほしいか 誰と協力したいか を理解し、災害時に伝え方を調整する 展開：災害情報を単なる通知から、利用者が実際に行動完了するまで伴走する支援をへ変える仕組みへ 39

Different Perspectives Background 第1段階 災害はどのように変化しているのか 本提案の災害範囲 1．短い時間に非常に強い雨が降る回数が増えている ◼ 短時間で発生する強い雨が増えている。 ◼ 1時間に50mm以上の雨は、1976〜1985年：約226回/年 → 2016〜2025年：約340回/年となり、約1.5倍に増加した。 ◼ 1時間に80mm以上の非常に強い雨も約1.8倍に増えている。 ◼ この増加は偶然ではなく、長期的な変化として確認されている。 ◼ そのため、災害が起きてから対応するのではなく、危険が高まる前に変化を捉え、早めに行動することが重要 になっている。 2．豪雨の問題は、「雨が降ること」だけではない ◼ 豪雨が起こると、河川の氾濫、土砂災害、道路の冠水、停電、鉄道運休などが発生する。 ◼ これらの影響は同時に起こるだけでなく、時間差で広がることもある。 ◼ その結果、通勤・通学・帰宅・子どもの迎え・家族への連絡など、普段の生活にも影響が出る。 ◼ 災害時には「避難するか」だけでなく、「いつ帰るか」「どの道を使うか」「誰が対応するか」などの判断が 必要になる。 ◼ そのため、防災支援では雨や災害の情報だけでなく、生活への影響まで考えることが重要である。 3．豪雨災害では、判断できる時間が短くなっている ◼ 短時間豪雨では、数時間前まで使えた道路が冠水したり、交通機関が急に止まったりすることがある。 ◼ 災害時は、多くの情報を集めて長時間比較する余裕がない場合がある。 ◼ そのため、一度だけ情報を届けるのではなく、変化する状況を継続して確認することが重要である。 ◼ また、その時点で実行できることを整理し、「今まず何をするか」という一つの行動を示す必要がある。 本提案では、FASTALERTの提供データで検証可能な豪雨災害を中心に、災害情報を生活影響と安全行動へ 変換する仕組みを検討する。 40

Different Perspectives Background 第2段階 情報はあるのに、なぜ行動できないのか AIMOの役割 4．災害時には、多くの情報が同時に届く ◼ 災害時には、気象庁、自治体、交通機関、ニュース、SNS、学校、会社、家族、防災アプリなど、多くの場所から情報が発信される。 ◼ 情報がないことではなく、多くの情報が別々に届き、「自分に必要な情報」や「次に取るべき行動」の判断が難しいことが課題で ある。 ◼ そのため、防災支援には情報を集めるだけでなく、利用者に必要な情報を選び、行動につなげる仕組みが必要である。 5．利用者自身が情報を集め、判断する必要がある ◼ 利用者は複数の情報から必要なものを探し、情報の新しさや信頼性を確認する。 ◼ さらに、自分の予定や移動経路への影響を考え、取るべき行動を判断する必要がある。 ◼ しかし災害時は時間に余裕がないため、この情報収集・整理・判断の負担が行動の遅れにつながる。 6．地域への警報だけでは、自分への影響が分かりにくい ◼ 防災情報は地域単位で発表されるが、利用者が知りたいのは生活への具体的な影響である。 ◼ 「帰宅できるか」「迎えに行けるか」など、自分の状況に関係する判断が必要になる。 ◼ 同じ地域でも、場所によって危険度は異なる。 ◼ そのため、災害情報を現在地、目的地、移動経路、予定、家族の場所と結び付けて判断する必要がある。 7．今いる場所だけでなく、これから行く場所も見る必要がある ◼ 現在地が安全でも、移動経路や目的地が危険になっている可能性がある。 ◼ 家族が別の場所にいる場合は、その場所の状況確認も必要である。 ◼ 現在地だけで判断すると、帰宅経路、学校、家族の場所などの危険を見落とす可能性がある。 ◼ そのため、「今いる場所」と「これから関係する場所」を同時に確認する必要がある。 8．SNSやFASTALERTの情報は、発見には役立つが、そのまま行動には使えない ◼ SNSやFASTALERTは、道路冠水、交通障害、停電などの異変を早く見つけるのに役立つ。 ◼ しかし、投稿だけでは情報が正しいか、現在も続いているか、自分に関係するか判断できない。 ◼ 投稿情報だけで「安全」「避難すべき」と断定することは危険である。 ◼ 気象庁、自治体、河川、交通、道路などの公的情報と確認し、現在地・予定・経路・家族情報と結び付けて判断する必要がある。 避難指示や警戒レベルは自治体・公的機関が発表し、AIMOが変更や取消しを行わない。 AIMOは公的情報を利用者の状況に合わせ、「まず何をするか」を分かりやすく伝える。 危険時は利用者の好みより安全を優先し、個別化するのは説明方法・順番・協力方法である。 41

Different Perspectives Background 第3段階 なぜ情報を受け取っても動けないのか AIMOの循環 10．警報を受け取ることと、安全行動を始めることは別である ◼ 警報を見ただけで、人は自動的に安全行動を始めるわけではない。 ◼ 「自分の場所は危険か」「何をすればよいか」「行動による問題はないか」を判断する必要がある。 ◼ 判断材料が不足すると、行動が遅れたり、やめたりする可能性がある。 ◼ そのため、警報を受け取ってから安全行動を開始するまでを支援する仕組みが必要である。 ◼ PADMは、災害情報を受けてから安全行動を選ぶまでの意思決定の流れを示すモデルである。 11．行動できない理由は、知識不足だけではない ◼ 災害時には、仕事中で情報を確認できない、家族への連絡が必要、移動手段がないなど、行動を妨げる条件がある。 ◼ 選択肢が多すぎることで、逆に判断できなくなる場合もある。 ◼ そのため、「避難してください」と伝えるだけでは不十分である。 ◼ 利用者の状況に合わせて、実際に実行できる行動を示す必要がある。 12．防災情報には「今できる一つの行動」が必要である ◼ 「注意してください」という情報だけでは、利用者は次に何をすればよいか分からない。 ◼ 「家族へ帰宅予定を共有する」「危険な道を避けて移動する」など、具体的な行動まで示す必要がある。 ◼ 一度に多くの指示を出すと、利用者が混乱する可能性がある。 ◼ そのため、まず一つの行動を提示し、完了後に次の行動を示す仕組みが必要である。 行動を示した後の「完了確認」が必要である ◼ 行動を表示するだけでは、利用者が実際に行動したか、安全な状態になったかは分からない。 ◼ 「通知したこと」と「安全に近づいたこと」は同じではない。 ◼ 最初の行動が完了したかを確認し、その時点の状況を再取得する必要がある。 ◼ 状況が変化した場合は、次に必要な行動も変更する必要がある。 ◼ AIMOは、「情報取得→生活への影響確認→一行動提示→完了確認→再取得→次の行動提示」という循環で支援する。 ◼ これにより、単に文章を生成するだけではなく、状況変化に対応しながら安全行動を支援する仕組みとなる。 42

Different Perspectives Background 第4段階 なぜ伝え方の個別化が必要なのか AIMOの個別化 13．同じ安全行動でも、受け取りやすい伝え方は人によって異なる ◼ 短い結論だけを知りたい人、理由やデータを確認したい人、選択肢を比べたい人など、求める伝え方は 異なる。 ◼ 不安な気持ちを受け止めてほしい人や、背中を押してほしい人もいる。 ◼ そのため、全員に同じ文章を送るだけでは、最適な支援にならない場合がある。 14．見るべきなのは「性格」ではなく「動きやすい関わられ方」である ◼ AIMOは、利用者の性格・病気・心理状態を診断するものではない。 ◼ 具体的な場面で、どのような支援が行動につながりやすいかを確認する。 ◼ その結果を、説明量、根拠量、選択肢数、共感表現、協力提案などの調整に利用する。 ◼ 利用者を固定したタイプに分類せず、利用中の反応から更新する。 15．個別化しても、安全な行動そのものは変えない ◼ 利用者が強い指示を好まなくても、危険な状況では安全を優先する。 ◼ 個別化するのは、説明の長さ、根拠の量、提案の順番、共感表現などの伝え方である。 ◼ 危険度、公的な避難情報、禁止行動、安全な行動内容は利用者の好みで変更しない。 ◼ 「安全を最優先し、その範囲で伝え方を合わせる」という設計が必要である。 伝え方は文字だけでなく、利用者の条件にも合わせる 情報の受け取り方は人によって異なるため、音声、文字、画像、読み上げなど複数の方法が必要である。 視覚に障害がある人には音声、聴覚に障害がある人には文字や画像など、状況に応じた配慮が必要である。 高齢者、外国人、障害のある人など、情報を受け取りにくい人への対応も重要である。 AIMOの個別化は、好みだけでなく、文字サイズ、やさしい日本語、音声などの伝達方法にも広げる。 スマートフォン操作が難しい場合は、家族やチームが確認できる仕組みも検討する必要がある。 43

Different Perspectives Background 第5段階 なぜ個人支援だけでなく、関係性の支援が必要なのか AIMOの関係性支援 16．一人暮らしが増え、家族も別々の場所で生活している ◼ 日本では一人暮らし世帯が増加しており、2050年には単独世帯が一般世帯の44.3％になると推計されて いる。 ◼ 家族がいても、普段は学校、仕事、保育園などで別々の場所にいることが多い。 ◼ そのため、災害時に家族が同じ場所にいて、すぐ相談できるとは限らない。 ◼ 災害時には、離れた場所にいる家族や大切な人の状況も考える必要がある。 17．一人暮らしと孤立は同じではない ◼ 一人暮らしでも、家族や友人とのつながりを持つ人は多い。 ◼ 「一人で暮らしている＝孤立している」と決めつけることはできない。 ◼ 問題は、災害が起きた瞬間に、近くで相談や助け合いができる人がいるとは限らないことである。 ◼ そのため、一人でも最初の安全行動を始められ、必要な時には周囲と協力できる仕組みが必要である。 防災行動は、自分一人の判断だけでは完結しない ◼ 災害時には、子どもの迎え、高齢の家族の確認、ペットの避難など、周囲との調整が必要になる。 ◼ 「誰が迎えに行くか」「誰が連絡するか」「誰が避難場所を確認するか」など、役割分担が重要にな る。 ◼ 家族や周囲の人が安全行動を始めたことが、本人の行動を後押しする場合もある。 ◼ そのため、個人への情報提供だけでなく、家族やチーム内での情報共有・役割調整を支援する仕組み が必要である。 44

Different Perspectives Background 第6段階 なぜ平常時から利用する必要があるのか AIMOの日常機能と災害時の支援の対応 18．災害が起きてからでは、その人の生活を十分に理解できない ◼ 災害時だけ使うサービスでは、利用者の予定、よく使う道、家族、生活習慣を十分に把握できない。 ◼ 「詳しく説明してほしい人」「短い指示がよい人」など、受け取りやすい伝え方も災害時に初めて判 断するのは難しい。 ◼ 一人ひとりに合った支援を行うには、平常時から少しずつ利用者理解を更新する必要がある。 19．日常利用は、単なる利用促進ではなく非常時支援の準備である ◼ 日常会話から、予定や困り事を理解できる。 ◼ 予定情報から、帰宅時刻、目的地、送迎などの生活状況を把握できる。 ◼ 思い出から、大切な人や場所を理解する手がかりを得られる。 ◼ 日常の反応から、説明量や関わり方の好みを更新できる。 ◼ これらの日常で得た理解を、災害時の個別支援につなげる。 日常で理解すること 災害時に活用すること 予定・時刻 いつ行動すべきか 現在地・目的地・経路 どこに影響があるか 家族・友人・ペット 誰を確認し、誰と協力するか 関わり方の傾向 どのように伝えるか 日常の反応 提案の強さや情報量 思い出 大切な人や場所の理解 45

Different Perspectives Background 第7段階 会話・思い出・関係性はなぜ必要なのか AIMOの日常機能と災害時の支援の対応 20．人は、守りたい人との関係を考えて安全行動を決める ◼ 災害時には、自分だけでなく、子ども、高齢の家族、友人、ペットなどの安全も考える必要がある。 ◼ そのため、誰を大切にしているか、誰と協力したいかを理解することが重要である。 ◼ 日常から関係性を理解しておくことで、災害時の役割分担や助け合いにつながる。 21．家族や友人がいても、日常の小さな出来事を共有できるとは限らない ◼ 毎日の予定や小さな出来事を、いつでも家族や友人に話せるとは限らない。 ◼ 小さな困り事や変化は、話さずに終わることもある。 ◼ AIMOは人間関係の代わりではなく、本人の許可した範囲で日常を理解する接点となる。 ◼ 会話を通じて、予定、大切なこと、困り事、望む関わり方を少しずつ理解する。 22．一般的な写真だけでは、撮影者やその時の思いは残りにくい ◼ 写真には写っている人や物は残るが、誰が撮ったか、どんな会話をしたかまでは残りにくい。 ◼ 家族写真でも、子どもの姿は残っても、見守っていた人の表情や気持ちは残りにくい。 ◼ AIMOでは、利用者が希望した場合に、撮影者、会話、本人の言葉なども含めて記録する。 23．思い出が安全行動を促す効果は、まだ確認されていない ◼ 思い出を蓄積することで、大切な人や場所への理解が深まる可能性がある。 ◼ しかし、思い出を見せることで必ず安全行動が増えることは、まだ実証されていない。 ◼ 現段階では、思い出機能は「利用者理解」「日常利用」「大切な存在の把握」のための設計仮説である。 ◼ 今後、実利用者による受け入れやすさ、行動意識、安心感、プライバシーへの不安を検証する必要がある。 会話・写真・位置情報には、プライバシー設計が必要である ◼ 会話、写真、予定、位置情報は非常に個人的なデータである。 ◼ 利用者理解を目的としても、すべての情報を自動的に集めることは適切ではない。 ◼ 機能ごとに利用するかを本人が選択できる仕組みが必要である。 ◼ 保存期間、共有相手、削除、利用目的を利用者が確認・変更できるようにする。 ◼ 生の会話や写真を長期間保存せず、必要な特徴だけを利用する方法も検討する。 ◼ プライバシー保護は後から追加するのではなく、設計段階から組み込む必要がある。 46

Background Background 要点整理 ■分析概要 社会課題、FASTALERT提供データ、外部データ、先行研究を統合して分析 ■結果要点 現在の防災情報には次の課題が存在することが分かった ・情報が届いても行動につながらない ・同じ情報でも受け取り方は人によって異なる ・SNSだけでは被害を十分把握できない地域が存在する ・通信障害などにより情報空白地域が発生する ・家族や友人との関係性まで考慮した支援は少ない ■結論 課題は「情報不足」ではなく「 一人ひとりに合わせた伝え方ができていない」ことである 背景分析より、 防災では「何を伝えるか」だけではなく 「誰に、いつ、どのように伝えるか」 まで設計する必要があることが示された 47

Analysis 48

Analysis FASTALERT・災害情報理解 Analysis 1-1 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか FASTALERTには、判断に必要な情報が入っているのか 実証区分 実データ分析 【分析目的】FASTALERTの投稿だけで災害状況を正確に判断できるか確認する 分析概要： 災害別投稿数・Topic数 災害横断データ監査,記述統計,変数充足率分析 ◼ 災害によって投稿規模が大きく異なる ◼ 2026年台風6号は2,756投稿と最も多く、 総投稿の約半数を占める ◼ 投稿数が多いことは、危険度が高いこと と同義ではない ◼ Topic数を見ることで、単なる投稿量だ けでなく、情報のまとまりや話題の多様 性を確認できる 分析対象 ◼ ◼ ◼ ◼ ◼ 2023年台風2号・線状降水帯： 1,074投稿、531 Topic 令和6年奥能登豪雨： 626投稿、359 Topic 2025年台風15号： 1,083投稿、407 Topic 2026年台風6号： 2,756投稿、1,228 Topic 合計：5,539投稿、2,525 Topic 変数充足状況 ◼ FASTALERTには、事象、時刻、位置、 本文、画像など、Event Stateの入力 となる項目が含まれる ◼ 一方で、すべての投稿に正確な位置・画 像・十分な本文がそろうとは限らない ◼ 位置精度が不足する投稿を、経路変更や 避難判断へ直接使うことは危険である 分析手法 ◼ 災害横断データ監査 ◼ 記述統計 ◼ 変数充足率分析 主な変数 ◼ 投稿ID、Topic ID ◼ 投稿時刻、検知時刻 ◼ 都道府県、市区町村、緯度・経度 ◼ 事象分類、投稿本文、画像URL ◼ 欠損有無、位置精度 FASTALERTは基盤として有用だが、変数ごとの精度・欠損管理が必須 ◼ FASTALERTは災害状態を構築する基盤として利用できる ◼ ただし、投稿数だけでは危険度を判断できない ◼ 投稿ごとの欠損・位置精度・情報源を保持したまま利用する必要がある 設計指針 ◼ 投稿を直接通知せず、災害情報へ変換する ◼ 災害情報に事象、時刻、位置、位置精度、画像有無、欠損状態、有効期限を保持する ◼ 位置精度が不足する場合は、経路判断に直接使わず再取得へ回す Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 49

Analysis FASTALERT・災害情報理解 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか Analysis 1-2 災害事象を生活影響へ変換できるか 実証区分： 実データ＋辞書設計 【分析目的】：災害情報を利用者の生活への影響に変換し、その後の情報検索・安全判断に活用できる形へ整理する 分析概要 災害別事象構成ヒートマップ ◼ 同じ豪雨でも、浸水、河川増水、道路冠水、交通 障害、停電、避難情報などの構成比は異なる ◼ 「大雨」という上位ラベルだけでは、必要な安全 行動を決められない ◼ 災害ごとに主要事象が違うため、固定的な一種類 の検索では必要情報を取りこぼす 分析手法 ◼ 災害別事象構成ヒートマッ プ ◼ ルールベース解析 ◼ 災害・生活影響辞書構築 ◼ 公的機関情報との対応づけ 主な変数 ◼ 投稿本文中の災害語、地名、 時刻、行動語、被害語 ◼ 災害事象 ◼ 影響対象 ◼ 生活影響 ◼ 必要な外部情報 ◼ 行動候補 ◼ 禁止表現 ◼ 確信度・有効期限・再取得 条件 災害・生活影響対応辞書(appendix表1) ◼ ◼ ◼ ◼ ◼ 道路冠水は、通勤・通学・送迎・自動車移動へ影響する 河川増水は、河川周辺の移動、避難経路、家族宅への接近へ影響する 停電は、通信、充電、冷暖房、在宅継続へ影響する 避難情報は、対象地区、避難所、経路安全性、家族位置との照合が必要になる 同じ災害事象でも、利用者の予定・場所・移動手段により行動候補が変わる 辞書の内部データ構造(appendix表2) ◼ `event_id`、`trigger_terms`、`life_impact`、`required_context`、`required_tools`、`candidate_action`、`prohibited_output`、`confidence_rule`、 `requery_rule`を保持する ◼ 辞書が単なるキーワード表ではなく、安全制約と再取得条件を含む実装仕様になっている 道路冠水レコード例(appendix表3) ◼ 「冠水」という語を検出しただけでは、道路回避を断定しない ◼ 利用者経路との近接、公的危険度、情報の新しさ、複数情報の一致を確認して候補化する ◼ 水深不明の冠水道路への進入を促さないことを禁止条件として持つ 事象の具体化と「辞書」を活用した行動選択アプローチ ◼ ◼ FASTALERTの事象を、生活影響・外部照会先・行動候補・安全制約へ変換できる 1つの投稿だけで行動を決めず、辞書を通して必要な追加情報を明らかにできる 設計指針 ◼ 災害・生活影響辞書を情報整理に組み込む ■行動候補と同時に、禁止表現、確信度、有効期限、再取得条件を出力する ◼ FASTALERT投稿だけで避難・移動・安全を断定しない Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 50

appendix Analysis 1-2 表1 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか 災害・生活影響対応辞書（一部） 災害事象 想定される生活影響 追加取得する情報 主な行動候補 安全上の注意 道路冠水 通勤・通学・送迎・車 移動が困難 道路規制、交通情報、 代替経路 出発延期、経路変更、 徒歩回避 水深不明なら進入しな い 河川増水 河川沿いの移動危険、 避難経路変更 河川水位、洪水警報、 避難情報 河川沿いを避ける、高 台へ移動 河川近接経路を優先的 に除外 土砂災害 山間部・斜面付近の危 険 土砂災害警戒情報、雨 量 危険区域回避、避難開 始 夜間・豪雨時は早めに 避難 停電 通信・充電・冷暖房・ 生活継続 停電範囲、復旧見込み モバイルバッテリー確 保、家族連絡 エレベータ利用を避け る 避難情報 避難判断が必要 対象区域、避難所、開 設状況 避難開始、家族共有 指定区域か確認する 鉄道運休 通勤・帰宅困難 運行状況、代替交通 在宅勤務、出発延期 無理な移動を避ける 強風 飛来物・転倒危険 風速、交通規制 外出延期、屋内待機 看板・樹木付近を避け る 大雪 路面凍結、交通障害 積雪量、道路情報 チェーン装着、移動延 期 ノーマルタイヤで走行 しない Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 51

appendix Analysis 1-2 表2 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか Hazard–Life Impact Dictionary 内部構造 フィールド名 内容 例 event_id 災害イベントID flood_road_001 trigger_terms 検出キーワード 冠水・浸水・道路水没 hazard_type 災害種別 道路冠水 life_impact 生活への影響 通勤・送迎・帰宅困難 required_context 利用者情報 現在地・目的地・予定・家族位置 required_tools 追加取得する情報 道路規制API・交通情報API candidate_action 推奨行動候補 経路変更・出発延期 prohibited_output 出力禁止条件 「安全です」と断定しない confidence_rule 信頼度判定 公的情報2件以上一致 requery_rule 再取得条件 10分後または新規投稿時 expiry_time 有効期限 30分 priority 優先度 High Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 52

appendix Analysis 1-2 表3 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか 道路冠水レコード例 項目 内容 event_id flood_road_001 trigger_terms 「道路冠水」「道路水没」「車が立ち往生」「道路 が川」 hazard_type 道路冠水 location 東京都渋谷区 ○○交差点 life_impact 通勤・通学・送迎・帰宅への影響 required_context 現在地、目的地、予定経路、利用交通手段 required_tools 道路規制、交通情報、気象情報 candidate_action 北口経由へ変更、出発延期、徒歩回避 prohibited_output 「その道は安全」「そのまま進んでください」と断 定しない confidence_rule FASTALERT＋道路情報＋気象情報が一致した場合 のみ強い提案 requery_rule 新規投稿・10分経過・位置変化時に再取得 expiry_time 30分 Safety Gate 水深不明なら「進入禁止候補」として扱う Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 53

Analysis FASTALERT・災害情報理解 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか Analysis 1-3 多数の投稿を現在の災害状態へ整理できるか 実証区分： 実データ分析 【分析目的】：投稿が集中する時間帯や検知までの速さを分析し、FASTALERTを継続的に状況を更新する情報として使えるか確認する 分析概要 分析手法 ◼ 投稿バースト時系列比較 ◼ 検知遅延の経験累積分布 （ECDF/CDF） 主な変数 ◼ データ期間開始からの経過時間 ◼ 1時間当たり投稿比率 ◼ 投稿から検知までの時間 ◼ 累積検知割合 ◼ 災害イベント 投稿バースト時系列比較 説明変数（横軸）：各データ期間の開始からの経過時間/ 目的変数（縦軸）：全投稿に占める1時間当たり比率 （%）/グループ変数（凡例）：災害イベントの種類 ◼ 投稿は時間全体へ均等に発生せず、災害発生・ 状況悪化時に短時間へ集中する ◼ 利用者が投稿を個別に受け取ると、最も判断が 必要な時間帯に情報過多になる ◼ 情報を投稿単位で見せるのではなく、同一地 域・同一事象へ統合する必要がある FASTALERT検知遅延CDF 説明変数（横軸）：投稿からFASTALERT検知ま での時間（秒）/目的変数（縦軸）：累積割合/グ ループ変数：災害イベント ◼ 多くの投稿は比較的短時間で FASTALERTに検知される ◼ 状況変化を継続的に取得できる可能性 が示される ◼ 一度判断した後も、新規投稿に応じて 状態を更新できる 大量投稿に対する通知設計と状態管理の方向性 ◼ 投稿は短時間に集中するため、個別通知方式は認知負荷を高める ■FASTALERTは、災害情報を継続更新する入力として利用できる 設計指針 ◼ 一定時間内の同一地域・同一事象投稿を一つの災害情報へ統合する ◼ 投稿増加傾向、情報精度、有効期限を保持する ◼ 新規投稿時には通知を増やすのではなく、状態を更新し、必要時のみ次の一手を再計算する Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 54

Analysis FASTALERT・災害情報理解 FASTALERT投稿を、情報精度を保ったまま、利用者に関係する災害状態へ変換できるか Analysis 1-4 災害情報を、その人に関係する情報へ絞れるのか 実証区分： 実データ+設計評価 【分析目的】：投稿の場所を、現在地・目的地・予定・家族の場所と照らし合わせて、本当に必要な情報だけを届けられるか確認する 分析概要 東京都内投稿分布と生活文脈 ◼ 2026年台風6号 /東京都内の投稿/ 緯度・経度が 利用可能な投稿 ◼ 分析対象：743件 ◼ FASTALERT投稿は東京都内へ広く分 布する ◼ 現在地周辺だけでなく、目的地、予定 経路、家族位置付近にも関連投稿が存 在する ◼ 現在地だけを見ると、これから通る場 所や守りたい人の周辺情報を見落とす 生活文脈 設定地点 緯度 経度 現在地 渋谷駅 35.6585 139.7013 目的地 東京駅 35.6752 139.7668 家族位置 代々木駅 35.683061 139.702042 予定経路 渋谷駅―東京駅 — — 通知候補削減比較 ◼ 地域一括通知：743件 ◼ 多文脈照合：198件 ◼ 地域一括比で73.4％削減 ◼ 不要情報を減らしながら、現在地のみで は拾えない目的地・経路・家族位置を保 持できる 分析方法 ◼ 地理空間文脈照合分析・経路近接度分析・通知候補削減比較 比較した方式 判定方法 地域一括通知 東京都内の対象投稿をすべて通知候補とする 現在地のみ 渋谷駅から3km以内の投稿だけを候補とする 多文脈照合 現在地・目的地・家族位置・予定経路のいずれかに近い 投稿を候補とする 使用変数区分 使用変数 FASTALERT側 緯度、経度、災害事象、投稿ID、災害イベ ント 利用者側 現在地、目的地、家族位置、予定移動経路 算出変数 各地点との直線距離、予定経路との最短距 離 出力変数 通知候補／対象外、最も近い生活文脈 ◼ 「今いる場所」だけでなく、「これから向かう場所」と「守りたい人の場所」 を同時に見る必要がある ◼ 多文脈照合により通知候補を大幅に絞れる 設計指針 ◼ 生活との照合に現在地、目的地、経路、家族位置を入力する ◼ 直線距離だけでなく、経路への最短距離を用いる ◼ 位置情報の共有範囲は利用者が設定できるようにする 利用者価値への翻訳 ◼ 技術結果：通知候補73.4％削減 ◼ 利用者価値：不要な情報を減らし、必要な場所の危険へ集中できる Analysis1の到達点：FASTALERTの投稿を事象・発生時刻・位置・生活への影響・情報の確かさ・有効期限を持つ災害状態情報へ変換し、現在地・目的 地・移動経路・家族の場所と照合して、利用者に関係する災害情報を整理する 55

Analysis 状況理解・情報更新 現在のRelevant Event Stateから、次にいつ・何を・どの地域から再取得すべきか判断できるか Analysis 2-1 投稿は独立に発生せず、災害ごとに異なる強さと時間幅で連鎖する 実証区分： 実データ分析 【分析目的】：災害投稿の継続性を定量化し、情報を再取得すべきタイミングを明らかにする。 分析概要 Hawkes過程による自己励起性分析 ◼ 使用データ：FASTALERTから提供された以下の4災害 ◼ 規模：総投稿数：5,539件 総Topic数：2,525件 分析手法 Hawkes過程による自己励起性分析 過去に発生した投稿が、その後の投稿発生率を一時的に高め る構造を表現する時系列モデルである。災害ごとの投稿時刻 を用いて、1件の投稿が平均して何件の後続投稿の発生に関 係するかを表す分岐比 𝑛を推定し、災害間で比較する。 変数 ◼ 入力変数：投稿ID /投稿日時/災害イベント/Topic ID ◼ 推定変数：基礎発生率（外部要因によって独立に発生 する投稿の頻度） /自己励起成分（過去の投稿によって 高まる後続投稿の発生強度 ）/分岐比 𝑛（1件の投稿が 平均して何件の後続投稿に関係するかを表す指標） ◼ 図面の変数： 縦軸→災害イベント 横軸→分岐比 𝑛 分岐比が高いほど、投稿後も関連情報が連続的に増えや すい 投稿連鎖に応じた情報取得が有効 ◼ 4災害すべてで分岐比は0を大きく上回った ◼ 連鎖の強さと平均持続時間は災害ごとに異なる ◼ 分岐比は投稿の連鎖性であり、災害危険度そのものではない 設計指針 ◼ 分岐比を再取得間隔と監視優先度へ利用する ◼ 自己励起性が高い災害へ取得資源を集中する ◼ 分岐比だけで利用者へ警告せず、再取得制御に限定する Analysis2の到達点：災害の継続状況、次に起こる可能性がある事象、影響地域、未知の危険、情報の組み合わせを基に、いつ・何の情 報を・どの地域から確認し直すかを動的に判断する 56

Analysis 状況理解・情報更新 Analysis 2-2 現在のRelevant Event Stateから、次にいつ・何を・どの地域から再取得すべきか判断できるか 偶然より多い事象遷移を、次に確認する情報の選択へ使う 実証区分： 実データ分析 【分析目的】：FASTALERT投稿の時間的な遷移関係を分析し、現在の災害状態から次に発生しやすい災害状態を明らかにする。 分析概要 事象遷移の比較分析 ◼ 使用データ：FASTALERTから提供された以下の4災害 ◼ 規模：総投稿数：5,539件 総Topic数：2,525件 分析手法 ◼ 時間遷移集計：同じ市区町村で、ある災害の発生後2時間以 内に別の災害が起きた流れを集計した。どの災害が、次の どの災害につながりやすいかを確認した ◼ 置換検定：実際の災害発生順と、災害の順番をランダムに 並べ替えた場合を比較した。偶然では説明しにくい災害の つながりだけを抽出した ◼ 事象遷移の比較分析：災害同士の発生の流れを整理し、偶 然（ランダム期待値）より有意に多い変化パターンを確認 した ◼ 変数 ◼ 先行事象：最初に発生した災害事象 ◼ 後続事象：同じ市区町村で2時間以内に発生した次の災害事 象 分析指標 ◼ 観測遷移件数：実際に起きた災害のつながり数 ◼ 期待遷移件数：偶然起こると考えられるつながり数 ◼ z値：偶然との差の大きさ ◼ p値：偶然起きた可能性を示す値 判定基準 ◼ z値が2以上の災害の流れを、偶然ではなく重要な災害状態 の変化として抽出した 縦軸：事象の遷移パターン、横軸： 2時間以内の遷移件数、青棒：観測 件数、橙ダイヤ：ランダム期待値 災害の連鎖を利用した先回り情報取得 ◼ 観測件数とランダム期待値の差を図中に表示した ◼ 多重比較を考慮するためFDR補正後q値を追加した ◼ 遷移は時間順序の関連であり因果ではない 設計指針 ◼ 災害の変化予測は、直接行動を指示するためには使わない ◼ 次に確認すべき情報を選ぶために利用する ◼ 例えば「大雨の後に冠水の可能性が高い」と判断した場合は、道路状況や浸水危険度の情報を先に取得する ◼ 追加情報を取得して災害状態を更新した後、安全な行動を判断する Analysis2の到達点：災害の継続状況、次に起こる可能性がある事象、影響地域、未知の危険、情報の組み合わせを基に、いつ・何の情 報を・どの地域から確認し直すかを動的に判断する 57

Analysis 状況理解・情報更新 現在のRelevant Event Stateから、次にいつ・何を・どの地域から再取得すべきか判断できるか 実証区分： 実データ分析 Analysis 2-3-1 行政区域内でも投稿集中地点と主要な生活影響は異なる 【分析目的】：位置情報を持つ災害投稿の空間分布を分析し、災害情報が集中する地域を抽出することで、優先して情報を取得すべき地域 を明らかにする 分析概要 分析手法：DBSCANによるFASTALERT投稿の空間クラスタ分析：あらかじめクラスタ数を指定せず、位置情報の密度に基づいて、投稿が集中する地域を抽出す る手法である。互いに近接する投稿が一定件数以上存在する場合に同じ空間クラスタとしてまとめ、周辺に十分な投稿がない地点はノイズとして区別し、今回は 半径8km・最小5件の条件で再実行し、局所的な上位クラスタを抽出した 変数：入力データ：FASTALERT投稿（緯度・経度付き投稿）/出力：空間クラスタ 各クラスタで観測された主要事象 災害 主な地域 投稿数 主な事象 2023台風2号 浜松市周辺 144 浸水・冠水 2023台風2号 沼津市周辺 91 浸水・冠水 2023台風2号 熱海市周辺 9 鉄道トラブル 奥能登豪雨 輪島市周辺 169 氾濫 奥能登豪雨 金沢市周辺 91 緊急車両出動 奥能登豪雨 小松市周辺 40 故障車 局所的な災害発生地点を優先した情報取得 ◼ 分析データの可視化：DBSCANで抽出した上位クラスタの空間的な広がり（左図）と、各地域の詳細な投稿数・生活への二次影響率 を明確に示した ◼ 被害の質のパターンの発見：「投稿数（件数）の多さ」と「生活への影響度（二次影響率）」は必ずしも比例しないことが判明した ◼ 件数が多いが、影響率が低い例：2026年台風6号（横浜市）は1344件と突出しているが、二次影響率は76.9%に留まる ◼ 件数は少ないが、影響率が非常に高い例：2024年奥能登豪雨（小松市）は40件と少ないが、二次影響率は85.0%と極めて高い 設計指針 ◼ エリアの絞り込み：行政区域単位ではなく、投稿が集中する「局所的なクラスタ地域」を追う ◼ ユーザー最優先：利用者の現在地・移動経路・家族の場所と重なるクラスタを優先する ◼ 複数指標の併用：件数だけで判断せず、主要事象・二次影響率・公的情報を掛け合わせる Analysis2の到達点：災害の継続状況、次に起こる可能性がある事象、影響地域、未知の危険、情報の組み合わせを基に、いつ・何の情 報を・どの地域から確認し直すかを動的に判断する 58

Analysis 状況理解・情報更新 Analysis 2-3-2 現在のRelevant Event Stateから、次にいつ・何を・どの地域から再取得すべきか判断できるか 実証区分： 実データ分析 未知災害の兆候検知性能は災害によって大きく異なる 【分析目的】：災害単位の交差検証により、未知の災害に対する二次的な生活影響の発生兆候を評価し、再取得開始の設計要件を導出する。 分析概要 ◼ 使用データ：FASTALERTから提供された以下の4災害 ◼ 規模：総投稿数：5,539件 総Topic数：2,525件 ◼ Leave-One-分析手法 ◼ Disaster-Outによる未知災害予測性能評価 変数 ◼ 入力変数： 投稿総数 /一次災害件数/二次生活影響件数/話題数/投 稿量の変化/観測市区町村数/時刻情報 ◼ 目的変数： 次の1時間以内に二次的生活影響が増加したか（増加あ り／なし） 評価指標 ◼ ROC-AUC（増加時間帯の識別性能）/PR-AUC（増加を見逃さ ず検出する性能） 検証方法 ◼ 災害単位の交差検証（4災害から1災害を除外して評価） 未知災害にも対応できる予測性能 ◼ ◼ ◼ 未知災害でも生活影響増加の兆候を一定程度 捉える 災害による性能差が大きく、万能な予測では ない 2026年台風6号では性能が低く、予測だけで行 動を決めるのは危険である 評価対象とした未知災害 ROC-AUC PR-AUC 2023年台風2号 0.743 0.538 2024年奥能登豪雨 0.606 0.497 2025年台風15号 0.804 0.777 2026年台風6号 0.573 0.374 平均 0.682 0.547 設計指針 ◼ 予測結果だけで避難や帰宅などの行動を決定しない ◼ 予測は、災害状態の変化を早期に捉え、追加情報の取得を開始する判断材料として利用する ◼ 災害ごとの性能差を考慮し、最低性能・見逃し率・検知までの時間を継続的に監視する ◼ 予測だけで判断せず、気象・自治体・交通などの追加情報で確認した上で安全行動を提案する Analysis2の到達点：災害の継続状況、次に起こる可能性がある事象、影響地域、未知の危険、情報の組み合わせを基に、いつ・何の情 報を・どの地域から確認し直すかを動的に判断する 59

Analysis 状況理解・情報更新 Analysis 2-3-3 現在のRelevant Event Stateから、次にいつ・何を・どの地域から再取得すべきか判断できるか 地域の広がり・話題の多様性・二次影響履歴が予測へ寄与 実証区分： 実データ分析 【分析目的】：予測モデルの特徴量の重要度を分析し、二次的生活影響の増加予測に寄与する情報を明らかにすることで、優先的に監視す べき変化を設計する 分析概要 ◼ 使用データ：FASTALERTから提供された以下の4災害 ◼ 規模：総投稿数：5,539件 総Topic数：2,525件 分析手法 ◼ 特徴量重要度分析 ◼ 特徴量入替時の性能低下比較 ◼ 分析目的：生活影響増加の予測に寄与する情報を特定 変数 ◼ 入力変数：投稿量、話題数、地域数、生活影響件数、 時間変化など ◼ 目的変数：次の1時間以内の二次的生活影響の増加有無 評価指標 ◼ 各特徴量を入れ替えた際の予測性能低下量を比較 ◼ 解釈：性能低下が大きい特徴ほど、予測への影響が大 きいと判断 量（件数）より質（空間・話題・影響・時間）で災害を捉える ◼ 投稿量に依存せず、空間・話題・影響・時間の4軸で災害進展を予測する ◼ 投稿数だけでなく、観測市区町村数、Topic数、二次生活影響件数、投稿量の時間変化が予測へ寄与する ◼ 「何件あるか」だけでなく、「どこまで広がったか」「何種類の話題があるか」「生活への影響が顕在化したか」が重要である ◼ 単一指標による再取得判断は不十分である 設計指針 ◼ 情報取得の判断は投稿数だけで決めず、発生地域の広がり、話題の種類、生活への影響、時間変化を総合的に確認する ◼ 災害状態の変化を検知した場合は、利用者に関係する地域・事象・外部情報を追加で取得する ◼ 単一の指標ではなく、複数の変化から災害状況の進展を判断し、必要な情報だけを再取得する Analysis2の到達点：災害の継続状況、次に起こる可能性がある事象、影響地域、未知の危険、情報の組み合わせを基に、いつ・何の情 報を・どの地域から確認し直すかを動的に判断する 60

Analysis 状況理解・情報更新 Analysis 2-3-4 現在のRelevant Event Stateから、次にいつ・何を・どの地域から再取得すべきか判断できるか 全情報を入れれば良いわけではなく、地域の広がりが比較的一貫して有用だった 実証区分： 実データ分析 【分析目的】：各情報群が予測性能へ与える影響を評価することで、Tool Routerが組み合わせて監視すべき情報を明らかにする 分析概要 分析手法 ◼ アブレーション分析 分析目的 ◼ 各情報群を一つずつ除外し、予測性能の変 化を比較することで、各情報の必要性を評 価する 比較モデル ◼ 全特徴量モデル /時間情報なし/ 空間情報な し /Topic情報なし /一次災害履歴なし /二次 生活影響履歴なし 手法 ◼ 全特徴量モデルから情報群を一つずつ除外 ◼ 未知災害検証の平均PR-AUC比較 評価指標 ◼ 未知災害検証における平均PR-AUC 単一情報での予測は限界：複数情報の『掛け合わせ』の必要性 ◼ 全情報を網羅する予測の限界：適切な情報選定の必要性 ◼ 時間周期や二次影響などを除外した方が予測精度が向上するケースがある ◼ 「地域の広がり」などの一貫して有用な情報を中心に据える必要がある ◼ すべての情報を一律に組み合わせるのではなく、安定して寄与する情報を選び直す仕組みが必要である 設計指針 ◼ 次に取得すべき情報は、一つの情報だけで判断せず、複数の情報を組み合わせて決定する ◼ 情報取得の優先度は、以下の情報を統合して判断する 時間情報 / 空間情報 / 災害事象・話題情報 / 生活影響情報 ◼ 現在の災害状態をもとに、必要な情報源、確認する地域、再取得するタイミングを動的に決定する ◼ すべての情報を常に取得するのではなく、追加検証で安定して寄与する情報を厳選して先回り取得する仕組みとする Analysis2の到達点：災害の継続状況、次に起こる可能性がある事象、影響地域、未知の危険、情報の組み合わせを基に、いつ・何の情 報を・どの地域から確認し直すかを動的に判断する 61

Analysis 一行動提案 Analysis 3-1 取得した情報を、根拠・時間・場所・確度を確認した上で、安全な一行動へ変換できるか 利用者に必要な根拠を、最新性だけに偏らず取得できるか 実証区分： 実データ+＋設計評価 【分析目的】：最新の投稿を集めるだけでなく利用者の現在地・時刻・目的に必要な根拠を取得できるのか、検索方法によって必要 な根拠の取得精度がどの程度変わるかを比較する 分析概要 評価データ ◼ FASTALERT実データから構築した160件の評価ケース ◼ 災害イベント /評価時刻/市区町村 ◼ 利用者の質問 /利用目的 ◼ 正解となるFASTALERT投稿ID 分析手法 ◼ RAGASフレームワークによる検索品質・回答品質評価 4つの検索方式を比較 ⑴探索なし：災害情報を取得せず一般的な回答 ⑵ 単純最新検索：災害全体から最新5投稿を取得 ⑶ 時空間RAG：同一市区町村 × 直近180分から取得 ⑷本提案 AIMO型RAG：時刻 × 場所 × 利用目的 × 二次影響 × 情報の新しさから検索順位を決定 評価指標 ◼ Context Precision / Context Recall / 時間的妥当性 AIMO型RAGは、検索範囲の拡大ではなく、利用者適合型の根拠選択により性能向上 ◼ 160ケースを用いて、Context Precision・Context Recallを再集計した ◼ AIMO型RAGは、利用者の時刻・場所・目的・二次生活影響を検索条件へ加えることで、必要な根拠を高い割合で取得した ◼ 単純最新検索は新しい投稿を取得しやすい一方、利用者の質問に必要な根拠を取りこぼした ◼ 時空間RAGも高いRecallを示したため、AIMO型RAGの追加価値は「検索範囲を広げること」より「利用目的に合う根拠を上位へ並べるこ と」にある 設計指針 ◼ 情報取得の振り分け機能が、現在地・目的地・利用目的・二次影響をもとに検索条件を決定する ◼ 新しい情報だけでなく、利用者との関連性や情報の有効期限も考慮して情報を選択する ◼ 平均値だけでなく95％信頼区間や災害ごとの結果も示し、評価の信頼性を確認する Analysis3の到達点：取得した災害情報を、根拠・時間・場所・確度・安全性の確認を通じて、不適切な提案を抑えた「利用者が実行可 能な安全な一行動候補」へ変換できる状態を実現した 62

Analysis 一行動提案 取得した情報を、根拠・時間・場所・確度を確認した上で、安全な一行動へ変換できるか 実証区分： 実データ+＋設計評価 Analysis 3-2 取得した根拠から外れずに回答できるのか 【分析目的】取得した情報の範囲内で、利用者の質問に直接答えられるのか、回答の「根拠への忠実さ」と「質問への適合性」を分けて評価する 分析概要 評価対象 ◼ Analysis3-1と同じ160件の評価ケースについて、各検索・回答方式が生成した 回答を比較する 分析手法 ◼ RAGASフレームワークによる生成回答品質評価 4つの比較検索方式 ⑴探索なし：災害情報を取得せず一般的な回答 ⑵ 単純最新検索：災害全体から最新5投稿を取得 ⑶ 時空間RAG：同一市区町村 × 直近180分から取得 ⑷本提案 AIMO型RAG：時刻 × 場所 × 利用目的 × 二次影響 × 情報の新しさか ら検索順位を決定 評価指標 ◼ Faithfulness代理指標：生成回答が取得した根拠から逸脱せず構成されているか ◼ Response Relevancy代理指標：生成回答が、利用者の質問・利用目的に直接対 応しているか 最新情報だけ」の限界を克服：4軸の条件選択で逸脱を抑制 ◼ 最新投稿だけを取得する方法では、回答の根拠への忠実性や利用者の状況への 適合性を十分に確保できない ◼ 時刻・場所・利用目的・二次的な生活影響を考慮して情報を選択することで、 回答に必要な根拠を取得できた ◼ AIMO型RAGでは、評価ケースにおいて根拠からの逸脱を抑え、Faithfulness代 理値は0.500から1.000、Response Relevancy代理値は0.664から0.966へ向上した。 ◼ 災害情報では、情報量を増やすことよりも、利用者に関係する情報を選択し、 その根拠の範囲内で回答することが重要である 検索・回答方式 Faithfulness代理 Response Relevancy代理 検索なし 0.000 0.113 単純最新検索 0.500 0.664 時空間RAG 0.667 0.842 AIMO型RAG 1.000 0.966 設計指針 ◼ 回答が取得した根拠に基づいているか、利用者の現在地・目的・質問に適しているかを確認する ◼ 根拠にない断定や不適切な行動指示が含まれる場合は、そのまま提示せず、追加情報の取得や回答の修正を行う ◼ 安全性を確認した回答のみを利用者へ提示する Analysis3の到達点：取得した災害情報を、根拠・時間・場所・確度・安全性の確認を通じて、不適切な提案を抑えた「利用者が実行可 能な安全な一行動候補」へ変換できる状態を実現した 63

Analysis 一行動提案 取得した情報を、根拠・時間・場所・確度を確認した上で、安全な一行動へ変換できるか Analysis 3-3 防災行動へ実際に使えるか 実証区分： 実データ+＋設計評価 【分析目的】：根拠に正しいだけでなく、現在の利用者が安全に行動できる回答になっているのか、防災行動に必要な4つの独自指標を設定し て評価する 分析概要 評価対象 ◼ FASTALERT実データから構築した160件の評価ケースについて、各検索方式で取得 された情報を評価する ◼ 4つの検索比較方式：検索なし /単純最新検索/時空間RAG/AIMO型RAG 分析手法 ◼ AIMO独自防災指標による情報利用可能性評価 評価指標 ① 時間的妥当性 「いつの情報か」：行動判断に使用する情報が、現在の状況を判断 するために十分新しいか ②空間整合性 「自分に関係する場所か」：取得した情報が、利用者の現在地・目的 地・移動経路と整合しているか ③ 行動明確性 「今、何をすればよいか」：「注意する」だけでなく利用者が今実行 できる行動まで示されているか ④ リスク表現校正 「どこまで断定してよいか」：情報の確度に応じて、「確認され た」「可能性がある」「再確認が必要」等の表現を適切に使い分けているか 情報の新しさより「状況への適合」：AIMO型RAGが実現する確実な 防災行動判断 ◼ 最新情報であることと、安全な行動判断に使えることは一致しない ◼ 単純最新検索は時間的妥当性が高い一方、利用者の場所との整合性が低い 場合があった ◼ AIMO型RAGは、時間・場所・利用目的を考慮して情報を選択し、空間整合 性1.000、行動明確性0.950、リスク表現校正0.940を達成した ◼ 一方で、時間的妥当性は0.918であり、関連性を優先することで一部古い情 報が残る課題が確認された ◼ 防災支援では、最新情報を集めるだけでなく、利用者の状況に適した情報 を選択する仕組みが重要である 方式 時間的妥当性 空間整合性 行動明確性 リスク表現校正 0.000 0.000 0.250 0.350 検索なし 単純最新検索 高 0.995 低 0.436 時空間RAG 0.946 高 1.000 AIMO型RAG 0.918 高 1.000 低 0.550 低 0.780 高 0.950 0.550 0.820 高 0.940 設計指針 ◼ 安全確認機能で「時間・場所・行動・リスク表現」の4条件を確認する ◼ 条件を満たさない場合は、再取得・再検索・追加情報取得・表現調整・断定禁止へ切り替える ◼ 安全確認機能は、回答を評価するだけでなく、提示可能な情報へ制御する役割を持つ Analysis3の到達点：取得した災害情報を、根拠・時間・場所・確度・安全性の確認を通じて、不適切な提案を抑えた「利用者が実行可 能な安全な一行動候補」へ変換できる状態を実現した 64

Analysis 一行動提案 取得した情報を、根拠・時間・場所・確度を確認した上で、安全な一行動へ変換できるか 実証区分： プロトタイプ監査 Analysis 3-4 危険な提案を止められるか 【分析目的】：行動を提案する前に、情報が「今使えるか」「自分の場所に合っているか」「安全な行動につながるか」を確認する仕 組みを作り、その効果を評価する 分析概要 ◼ 各検索・回答方式が取得した情報を行動支援へ変換した際に、危険な 提案がどの程度残るかを評価 比較方式 ◼ 検索なし /単純最新検索/時空間RAG/AIMO型RAG 監査対象 以下のいずれかに該当する提案を危険提案として判定する ◼ 根拠がないにもかかわらず「安全」と断定する /情報の確度が低い状況 で移動/帰宅・避難を断定的に促す /有効期限を超えた古い情報だけで 通行可能と判断する /利用者の現在地・目的地・移動経路と関係しない 情報から行動を提案する/必要な再確認や公的情報との照合を行わずに 行動を提示する ・危険情報が不足しているにもかかわらず「問題な い」と結論付ける 評価指標 ◼ 危険提案率：全評価ケースのうち、監査ルールに該当する危険な行動 提案が生成された割合 ※本評価は設計プロトタイプに対するルールベース監査 探索なし 単純最新検索 時間空間RAG AIMO型RAG 10.0% 6.0% 2.5% 0.8% AIMO型RAGによる危険提案率の劇的低減と、安全を担保する「ガードレール」の重要性 ◼ 検索なしでは根拠不足により危険提案率は10.0％となった ◼ 最新検索では6.0％まで低下したが、場所に合わない情報を使う危険が残った ◼ 時刻・場所を考慮した検索では2.5％まで低下したが、利用目的や情報の確かさを考慮しない断定が残った ◼ AIMO型RAGでは、根拠・時間・場所・行動・表現を確認することで危険提案率を0.8％まで低減した ◼ ただし0％ではなく、検索だけで安全を保証することはできない ◼ 安全な防災支援には、不適切な提案を止める確認・制御の仕組みが必要である 設計指針 ◼ 取得情報をそのまま提示せず、根拠・時間・場所・行動可能性・表現の適切性を確認する ◼ 条件を満たさない情報は、再取得・追加情報取得・表現変更・提示停止へ分岐する ◼ 安全確認機能は、安全を保証するものではなく、危険な提案を防ぐ制御機構として設計する Analysis3の到達点：取得した災害情報を、根拠・時間・場所・確度・安全性の確認を通じて、不適切な提案を抑えた「利用者が実行可 能な安全な一行動候補」へ変換できる状態を実現した 65

Analysis 関わり方診断・個別最適化 Analysis 4-1 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 実証区分： プロトタイプ監査 個別化は必要か 【分析目的】：避難行動につながる伝達要素を分析し、個人に応じた安全行動提示の設計要件を導出する 分析概要 対象データ ◼ 外部文献データ/AIMO設計データ 外部文献の分析観点 ◼ 自分との関連づけ/周囲への影響・社会規 範/状況理解と行動実行/情報の誤解/周囲 からの呼びかけ AIMO設計データ ◼ 関わり方診断資料/伝達方法に関する設計 資料/ 発話・情報提示ルール 抽出する設計要素 ◼ 見守・理由説明・比較提示・行動提示・ 協 力促進 分析手法 ◼ 文献内容分析 分析手順 1.文献から避難意思・情報理解・行動移行に関 係する要素を抽出 2.抽出内容を以下の5つの伝達要素へ分類 →本人・役割への関連づけ /根拠・状況理解 / 明確な一行動 /協力・社会規範 /確度に合った表 現 3.各要素の支持度を整理 →直接支持 /関連 /支持なし 4.得られた要素をAIMOの発話・情報提示方法へ 対応付ける 分析結果として導出するもの ◼ 利用者に応じて調整すべき伝達要素 ◼ 安全行動を促す情報提示方法の設計要件 「一律通知」から「状況個別化」へ ◼ 同じ安全行動でも、本人の役割・周囲との関係・伝え方によって受け取り方や行動への つながり方が異なる ◼ 安全行動につなげるには、本人との関連づけ、根拠や状況理解、具体的な一行動、協力 提案、確度に応じた表現が必要である ◼ そのため、一律通知ではなく、安全な行動内容は変えずに、伝え方を利用者の状況に合 わせて個別化する必要がある 設計指針 ◼ 個別化は安全行動や根拠そのものを変更せず、同じ安全行動を利用者に合わせた伝え方へ変 換する ◼ 本人との関連づけ、理由説明の量、行動提示方法、協力提案、確度に応じた表現を調整し、 行動につながりやすい情報提示を行う ◼ 固定的な性格分類ではなく、災害時の具体的な状況や役割に応じて支援方法を選択する Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 66

Analysis 関わり方診断・個別最適化 Analysis 4-2-1 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 8軸は、AIMOが実際に変えられる関わり方へ対応しているのか 実証区分： 設計評価 【分析目的】：8軸の診断結果を、AIMOが利用者に合わせた具体的な支援方法へ変換し、情報提示の個別化に活用できるかを検証する 分析概要 ◼ 8軸の診断結果を、単なる性格分 類ではなく、AIMOが調整可能な 具体的な支援方法へ変換できる かを検証した ◼ 8軸と支援パラメータの対応関係 を作成し、利用者に応じた情報 提示の個別化が可能かを評価し た 分析対象 支援軸 測定内容 AIMOが 変えるもの 自発 自分で判断し たい程度 提案開始頻 度 見守り 必要になるま で待ってほし い程度 介入頻度 待機時間 気持ち 共感を求める 程度 共感表現諒 整理 情報整理を求 める程度 情報整理粒 度 根拠 理由・出典を 求める程度 根拠提示諒 比較 複数案を比較 したい程度 比較案数 後押し 強く背中を押 してほしい程 度 推奨表現強 度 協力 家族・周囲と 調整したい程 度 協力提案量 分析手法 パラメータ制御行列分析 ◼ 8軸を入力、AIMOが変更する支 援方法を出力とした制御行列分 析を実施した ◼ 8軸を区別して制御できるか、ま た安定して個別化できるかを評 価した 分析対象 入力： 8軸の診断値（自発・見守 り・気持ち・整理・根拠・比較・後 押し・協力） 出力： 提案頻度、介入距離、共感 量、整理量、根拠量、比較案数、後 押し強度、協力提案量 数理安定の8軸制御： 一律通知を脱する「伝え方」の個別化 ◼ 制御行列の階数は8/8、条件数は1.54となり、8軸は互いに区 別可能で安定して制御できることを設計上確認した ◼ 8軸は性格分類ではなく、根拠提示量・比較案数・後押しの強 さ・協力提案量など、AIMOが調整可能な具体的な支援操作 に対応する制御指標として扱えることが分かった 設計指針 ◼ 8軸は性格の分類ではなく、AIMOが利用者に合わせて伝え方を調整するための指標として扱う ◼ 説明量・根拠の示し方・選択肢の数・共感表現・後押しの強さ・協力提案方法などを調整する ◼ ただし、安全な行動内容や危険度の判断は変えず、伝え方のみを個別化する Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 67

Analysis 関わり方診断・個別最適化 Analysis 4-2-2 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 36候補場面から18場面を選ぶ設計 実証区分： 設計シミュレーション 【分析目的】：質問の数を「36問から18問」へ半分に減らしつつ、相手の好みを正しく見抜く精度をキープできるかを検証する 分析概要 測定対象・主要変数・分析手法 ◼ 測定対象：日常場面および災害場面の双方を含めた計36パ ターンのシナリオ。各シナリオにおいて「自分ならどう行 動するか」と「相手にはどう関わってほしいか」を分離し て取得する 主要変数 ◼ 入力データ：上記36シナリオから得られるユーザーの回答 データ ◼ 測定の8軸（支援軸）：自発・見守り・気持ち・整理・根 拠・比較・後押し・協力の各度合い ◼ 分析手法：各候補場面を「どの軸にどの程度の情報を持つ か」の8次元測定ベクトルとして表現。D-optimal実験計画 法に基づき、情報行列 の行列式最大化に「8軸カバレッジ 制約」を組み合わせた組合せ最適化問題を解く 設問36問から18問へ：D-optimalが導く「低負荷×高精度」 ◼ 「削除」から「数理最適化」への転換：診断短縮は単なる 手抜きの間引きではなく、8軸全体の情報を最大限残す「組 合せ最適化問題」として解決可能と実証した ◼ 低負荷と高精度の両立：D-optimal型選択にカバレッジ制約 を課すことで、設問数を36から18へ半減（時間短縮）させ つつ、高いパラメータ識別精度を維持した ◼ 多面的なユーザー欲求のモデル化：「自己行動」と「支援 選好」の分離測定により、固定的な性格分類では捉えない 「場面に応じた動的な関わり方の違い」の特定に成功した 情報効率の比較結果 ■18シナリオに固定した 条件下において、ランダ ム選定（7.501）と比較 し、D-optimal型選定 （8.217）は情報効率が 9.5%明確に向上する 8軸カバレッジの設計結果 ■18場面への削減後も、8つの 支援軸すべてにおいて漏れな く測定機会（肯定回数4〜5 回）が確保され、特定の軸へ の設問集中や測定の偏りがな い。1つの具体場面から「主軸 ＋副軸」の情報を多面的に取 得することで、網羅性と効率 性が両立されている 設計指針 ◼ シナリオベース診断の採用：固定的な性格分類を脱却し、具体場面での「自己行動」と「AIMOへの期待（支援選好）」を分離取得する ◼ 数理最適化による設問厳選：診断短縮を「質問削減」ではなく8軸の情報を最大化する「組合せ最適化問題」として定義する ◼ 制約付きD-optimalの組込み：特定軸への設問集中を防ぐ「8軸カバレッジ制約」を課した選択アルゴリズムをAIMO初期診断に実装する ◼ 情報量と回答負荷の両立：本分析の妥当性に基づき、ユーザーを疲れさせずに高精度な判定を行う「18場面」を設計基準として採用する ◼ 次工程（安定性検証）への連携：取得した18場面の回答を即座に8軸へ変換し、続く「Analysis 4-3（推定の安定性評価）」の検証基盤とする Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 68

Analysis 関わり方診断・個別最適化 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 Analysis 4-2-3 最適化18場面はランダム選択より良いか 実証区分： 設計シミュレーション 【分析目的】：36候補場面からD-optimal型で18場面を選択し、回答負荷を半減した条件下でも8軸の特徴を十分に取得し、ランダム選択 や36場面全回答より高い識別情報を保持できることを比較・検証する 分析概要 検証方法（2条件の比較） ◼ CONDITION A（ランダム選定）：36候補 ➔ ラン ダムに18場面選択 ➔ 情報行列の 𝑙𝑜𝑔𝑑𝑒𝑡 を評価し たCONDITION B（最適化選定）：36候補 ➔ Doptimal型に18場面選択 ➔ 情報行列の 𝑙𝑜𝑔𝑑𝑒𝑡を評 価した 評価基準 ◼ 設問数はどちらも18場面のまま、「選び方（設問 集合の構造）」の違いが情報効率（特定能力に与 える影響を評価。場面選択には「8軸の情報をどれ だけ維持できるか」を基準とした。 主要変数 ◼ 入力変数：36候補場面への回答データ ◼ 選択変数：実際に初期診断で採用する18場面 ◼ 評価対象：18場面で取得できる8軸の情報量（情報 行列 ¥(M = X^T X¥) に基づく体積指標 𝑙𝑜𝑔𝑑𝑒𝑡 ◼ 比較対象：36場面すべてを使用した（設問短縮前 の）場合の8軸情報量 ◼ 出力（診断値）：個別化支援に必要な8軸の診断値 （自発・見守り・気持ち・整理・根拠・比較・後 押し・協力） 設問選択公立の分布比較 ■ランダム18場面の平均𝑙𝑜𝑔𝑑𝑒𝑡は 7.501 なのに対し、D-optimal型18 場面は 8.217 と大幅に高い結果を 記録した ■determinant換算(𝑒 0.716 ≈2.05)で は約2.05倍の情報行列体積となり、 同じ設問数でも最適化によって8 軸の識別能力が劇的に高まること を実証した D09 36候補➔18場面最適化後の8軸カバレッジ（積層棒グラフ） ◼ 設問数を半分（18場面）に減らしても、8つの支援軸すべてにおいて偏りなく十 分な測定機会（肯定回数4〜5回）を確保した。「主軸＋副軸」で多面的に情報を 取り込むことで、質問を増やさずに8軸全体の網羅性を両立した。 質問半減でもプロファイル維持：8軸の情報を最大化する数理モデル ◼ 「間引き」から「構造最適化」へ：診断短縮は単に質問を減らす作業ではなく、設問集合の構 造（重複のない情報取得）を最大化する「組合せ最適化問題」である ◼ 高い網羅性の証明：情報を考慮して選択することで、質問数を半分に減らしても、利用者の特 徴（8軸プロファイル）を失わずに個別化支援へ活用できる情報量を維持可能であった ◼ 最適化の限界と前提：ただし、今回の結果は36候補から18場面を選ぶ条件での有効性を示した ものであり、すべての利用者や目的において「18問」が絶対の最適とは限らない 設計指針 18場面での高精度初期診断：初期診断は18場面で構成し、少ない質問数でも8軸の情報を十分に、かつ情報量が最大になる場面の組み合わせ（Doptimal型選択）を採用する 多面的な制約による偏り防止：各軸を単に同じ数だけ質問するのではなく、情報量だけでなく「8軸カバレッジ」も同時に制約へ入れ、測定の偏りを システム的に防ぐ。 動的な追加確認（決めつけの脱却）：18問の結果だけで利用者を固定的に決めつけず、あくまで理解のための初期情報として使用。利用中の反応や 状況変化に応じて、必要に応じた「追加確認」を動的に行う。 Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 69

Analysis 関わり方診断・個別最適化 Analysis 4-3-1 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 回答の揺らぎに対する推定安定性と信頼性の検証 実証区分： 設計シミュレーション 【分析目的】：18場面の回答から8軸（真値）をどれだけ正確に再現できるかを検証するとともに、回答の揺らぎが推定結果へ与える影響 を評価し、過剰な個人化を防ぐための信頼性区間を明らかにする 分析概要 分析手法 潜在プロファイル回復シミュレーション ＆ Monte Carlo法による誤 差伝播評価 1. 1,500人分の仮想利用者データを用いて、「D-optimal型18場面」 と「ランダム選択18場面」の推定精度をシミュレーション比較 （Ridge回帰を使用）をした 2. 基準となる18場面の回答に回答揺らぎを付与し、多数回反復推 定を行うことで、入力側の不確実性が最終的なプロファイルの 推定幅へどう伝播するかを評価をした 測定対象 8軸推定誤差（RMSE）の分布比較 ランダム18場面の平均RMSEは0.419なのに対し、D-optimal型18場面は 0.329と小さく、回答誤差下でも真の8軸をより正確に再現できる 対象：合成ペルソナ（1,500人）、D-optimal型18場面、ランダム選択18場面 （250組）、大学生例の基準プロファイル 主要変数 入力・選択変数：合成ペルソナが持つ8軸の真値、採用する18場面への回答 データ 評価指標 RMSE（全体・軸別）、シミュレーション推定幅（エラーバー） ※RMSEが小さいほど元の8軸を正確に再現できていることを示す 決めつけない防災診断：1点のスコアから「揺らぎ」の測定へ ◼ ◼ ロバスト性の実証：質問数を半分に減らしても、D-optimal型最適化 を行っていれば、ユーザーの回答誤差に負けず、本来の特徴を高精 度に引き出せる 従来型（点推定）の限界：従来の「18問➔根拠重視タイプ」のよう な1点のスコアだけで固定化する手法は不完全であり、「8軸の水 準」と「推定不確実性（揺らぎ幅）」を同時に保持する必要がある ◼ 設問を最適化しても「回答そのもの」の揺らぎは完全には一致 しないが、最適化18場面は各軸で安定したシミュレーション推 定幅（縦のエラーバー）を出力できる ◼ ただし、推定の正確さ（RMSE）や推定幅は「軸ごと（自発・見 守り・気持ち等）」に異なるため、全軸を均一の確かさでは扱 えない 設計指針 ◼ 8軸の推定値と推定不確実性を保持し、AIMOの制御に反映する ◼ 推定の確実性に応じて各軸の影響度を動的に調整し、過剰な個人化を防ぐ ◼ 不確かな特徴は日常利用で継続的に追加観測・更新し、利用とともに推定精度を向上させる Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 70

Analysis 関わり方診断・個別最適化 Analysis 4-3-2 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 実証区分： 設計シミュレーション 利用者の変化へ追随できるか 【分析目的】：利用者の反応に合わせて支援内容を更新する方が適切な支援につながるかを検証し、安全を優先しながら一人ひとりに合った 伝え方を実現する 分析概要 分析手法 利用シナリオ変化追随シミュレーション ＆ ベ イズ逐次更新の評価 ◼ 40日間の利用シナリオを作成し、初回診断 を「固定する方式」と、日々の反応から 「更新する方式（指数平滑更新／状態空間 更新）」をシミュレーション比較した ◼ 新しい観測 𝑦𝑡+1 が得られた際、事後確率 𝑝 𝜃|𝐷1:𝑡+1 ∝ 𝑝 𝑦𝑡+1 |𝜃 𝑝 𝜃|𝐷1:𝑡 に基づき、 利用者のプロファイル（𝜃𝑡 ）を動的に更新 するベイズ逐次更新型の実装妥当性を検証 する 日々の反応から関わり方を更新できるか ◼ 初期診断固定方式：利用者の希望が変 わっても初期値のまま固定され全く対応 できなかった ◼ 日々の反応を取り入れる方式：利用者の 変化に合わせて柔軟に支援方法を更新可 能であることを実証した 利用者理解を固定するか、更新するか ◼ 状態空間更新：変化後わずか「6日」で 新しい状態に追随し、最も早く対応で きる特性を示した ◼ 指数平滑更新：全期間を通して最も推 定誤差（RMSE = 0.070）が小さく、波打 ちの少ない極めて安定した結果となっ た 測定対象 ◼ 対象：40日間の利用シナリオ（18日目に「気 持ち」「後押し」の希望が急変する状況）、 平常時の日常会話、豪雨当日の行動データ 主要変数 ◼ 入力データ：日常会話、選択結果、提案への 反応（詳しい説明を聞いたか／比較案を確認 したか／家族との協力案を選んだか等） ◼ 評価・制御指標：全期間での推定誤差 （RMSE）、変化追随日数、安全上許容され る行動集合（𝐴𝑠𝑎𝑓𝑒 𝑐𝑡 ） 診断の完成から「成長」へ：日常利用で進化する安全最優先の数理 ◼ ◼ 「診断の完成」から「適応型システム」への転換：初回診断をゴールとせず、関係が続く ほど精度が向上する「AIMOの育つプロセス（日常利用➔追加観測➔モデル更新➔支援制 御更新）」の有効性を証明した 個人化より安全を優先する構造：生命・身体への危険度が高い状況では、個人化（好みの 反映）よりも安全制約を最上位に置く数理モデルの必要性を確認した 設計指針 ◼ 長期的な関わり方の特徴と、その日の状態を分けて管理する ■その日の予定・反応・緊急度を支援内容に反映する ◼ 一回の反応で急変させず、複数回の観測をもとに少しずつ更新する ■安全を最優先とし、安全な範囲で一人ひとりに合った支援を行う ◼ 利用者が診断結果や関わり方を確認・修正できるようにする Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 71

Analysis 関わり方診断・個別最適化 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 実証区分： 設計シミュレーション Analysis 4-3-3 タイプ探索 【分析目的】：8軸の特徴から分かりやすいタイプを作成し、自己理解や初期支援に活用するとともに、回答の揺らぎに対しても安定したタイプ分類 ができるかを検証する 分析概要 クラスタ数とSilhouette Score ◼ 8軸の特徴から似た人をグループ化し、分かりやすい タイプとして活用できるかを検証する ◼ 回答が少し変わっても同じタイプに分類されるかを 確認し、タイプ分類の安定性を評価する ◼ K=2〜8を比較し、設定したデータではK=5が最大 ◼ 実利用者から5タイプが発見されたことを意味しない ◼ タイプ数は実データ取得後に再推定する 分析手法 ◼ クラスタ分析（K-means）でタイプ候補を探索する ◼ Silhouette Scoreで適切なタイプ数を比較する ◼ Monte Carloシミュレーションで回答の揺らぎに対す る分類の安定性を評価する 手順 5群×8軸ヒートマップ 1. 2. 3. ◼ 4. 8軸の特徴から似た利用者をグループ化する 最も適切なタイプ数を比較して決定する 各タイプの特徴を整理し、AIMOの支援方法へ反映 する 回答に小さな揺らぎを加え、タイプ分類がどの程度 安定しているかを確認する ◼ タイプ差は単一軸でなく複数軸の組み合わせ として現れる クラスタ中心を、根拠量、比較案数、介入距 離、後押しへ翻訳できる 測定対象 タイプ割当安定率 ◼ シミュレーションデータ（設計検証） ◼ 実証時は実利用者データを用いてタイプ数や分類を 再評価する ◼ 大学生例では、設定した回答摂動下で97.0％が 基準タイプを維持した ◼ これは分類正解率ではなく、入力揺らぎへの安定 性である 主要変数 ◼ 説明変数：8つの関わり方の特徴 ◼ 目的変数：分類されたタイプ ◼ 評価指標：タイプ数の適切さ（Silhouette Score）、 タイプ分類の安定性 型ハメしない5分類：97%ブレない安定性と分かりやすさの両立 ◼ 設定データでは5タイプが最適となったが、実利用時は再推定が必要である ◼ タイプ差は8軸の組み合わせによって表現できた ◼ 回答の揺らぎに対して97.0％が同じタイプを維持し、分類の安定性を確認した ◼ タイプは固定的な分類ではなく、8軸の特徴を分かりやすく伝える手段として 活用する 設計指針 ◼ ◼ ◼ ◼ ◼ ◼ 8軸の特徴は内部判断に利用し、利用者には理解しやすいタイプとして提示する タイプは人を固定するものではなく、適した関わり方を説明する手段として活用する タイプは単一の特徴ではなく、複数の特徴の組み合わせで表現する 境界付近では無理に1つへ分類せず、複数タイプへの当てはまりを考慮する 8軸の連続的な特徴をもとに、タイプ変化による支援の急変を防ぐ 回答の揺らぎに対する安定性を確認し、信頼できる分類を設計する Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 72

Analysis 関わり方診断・個別最適化 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 実証区分： 設計仕様 Analysis 4-3-4 診断値をAIMOへ変換 【分析目的】：8軸の診断結果を、AIMOの話し方・情報量・距離感・見た目などの具体的な支援方法へ変換し、回答の小さな変化に過剰反応せず、 一貫した支援を行う仕組みを検証する 分析概要 ◼ 診断数値をAIMOの「話し方・情報量・距離感・見た目（ビ ジュアル）」へ一貫性を持って変換し、かつ過剰反応を起こさ ない安定した制御ロジックを設計・検証する 分析手法 ◼ シグモイド関数による非線形変換：中央付近の差を敏感に捉え つつ、両極端の値を飽和させて過剰な反応を抑制する ◼ 不感帯判定：前回の設定値との差が一定のしきい値未満であれ ば、設定をあえて更新しない ◼ 指数平滑化：過去のデータ推移を考慮し、時間方向に対して変 化を滑らかに補正する ◼ マルチモーダル潜在空間生成：一元化された支援強度から、発 話（言語）とキャラクター表現（視覚）を同一システムから同 時に生み出す 手順 1. 8軸診断：日常・災害場面の質問から、ユーザーの「関わられ 方の好み」を数値化（0〜100点） 2. 数値の非線形変換：数式（シグモイド、Deadband、平滑化） を通して、0〜1の「内部支援強度（共通パラメータ）」へ変 換する 3. 言葉（発話）への翻訳：支援強度に基づき、「理由の提示 量」「選択肢の提示数」「介入の距離感」などのテキスト生 成ルールを決定する 4. ビジュアルへの翻訳：同じ支援強度から、キャラクターの 「天気モチーフ（薄い雪雲など）」「配色（淡青など）」 「持ち物（小さなレンズなど）」を自動生成する 測定対象 ◼ 検証データ/災害シナリオ 主要変数 ◼ 入力変数：初期診断から得られる8軸の診断スコア（0〜100 点） ◼ 制御変数（内部パラメータ）：非線形変換後の各軸の支援強度 ◼ 環境変数：現在の災害の緊急度・危険度 ◼ 出力変数（言語表現）：AIMOの発話テキスト ◼ 出力変数（視覚表現）：キャラクターの天気モチーフ、UI/UX 画面配色、キャラクターの持ち物・表情 診断値から支援強度への非線形変換 ◼ 0〜100点を0〜1の支援強度へ変換 ◼ 中央付近では差を反映し、極端な値 では飽和する ◼ Deadbandと時間平滑化で、小さな揺 らぎによる頻繁な変更を防ぐ ◼ 薄い雪雲：見守り・静けさ 強く前へ出すぎない関わり方 ◼ 淡い青：落ち着いた距離感 過剰な介入を避ける支援特性 ◼ 小さなレンズ：根拠・情報確認 「なぜ？」を確かめる支援 根拠多め/比較あり介入弱め/自己決定を残す 一貫したAIMO 8軸プロファイル 複数軸の組み合わせ 支援特性 天気モチーフ+色+持ち物 見た目にも分析結果の意味がある 設計指針 ◼ 見た目と発話の「一貫性」を保つ：同じ8軸データからビジュアルと言語（話し方・情報 量）を同時生成し、キャラの印象のズレを防ぐ。 ◼ 「サポートの好み」からキャラを生む：アバターを主観で選ばせるのではなく、ユーザーが 「どう関わってほしいか」のデータからAIMOが自動で誕生する仕組みにする ◼ ユーザーに「見た目の変更権」を残す：システムによる自動生成を決めつけず、ユーザーが 後から自分の手で見た目を自由に変更・微調整できる選択権をUI上に残す Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 73

Analysis 関わり方診断・個別最適化 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 実証区分： 設計シミュレーション Analysis 4-3-5 個別化の効果をどう実証するか 【分析目的】：利用者の希望を尊重しながら、安全を最優先とした支援ができるかを検証する 分析概要 ◼ 利用者の希望を優先する方式と、安全を優先す る方式を比較し、安全と個人化を両立できる制 御方法を評価する 分析対象 ◼ 今後の実利用者実験を想定したシミュレーショ ンデータ 分析手法 ◼ 安全制約付き合成場面シミュレーション（マル チエージェント型行動介入モデル検証） ◼ 手順 1. 災害危険度と利用者特徴を組み合わせた20,000 件のシナリオを作成する 2. 「選好優先」と「安全優先」の2方式でAIの支 援内容を生成する 3. 安全性と利用者への適合度を比較・評価する 方式 安全条件違反率 平均選好適合度 変数 選好だけで制御 50.9% 100.0% 説明変数（入力データ）：利用者要因：8軸プロ ファイル /状況要因：災害危険度 ◼ 操作変数（AIの制御対象）：介入強度、推奨強 度 ◼ 制約条件：安全上必要な最低介入強度 安全制約を先に適用 0.0% 90.8% 測定対象 ◼ 安全条件違反率（安全基準を満たせなかった割 合） ◼ 平均選好適合度（利用者の好みとの一致度） ◼ 安全上書き率（安全のために選好を変更した割 合） 希望（選好）だけで制御した場合 （左側） ◼ 利用者の満足度は最大（1.0）にな るが、半分以上のケース（違反率 約0.51）で安全条件を満たせない場 面が生じる 安全制約を先に適用した場合 （右側） ◼ 大ピンチの際に安全ルールを強制 することで、設定した合成場面に おける危険な違反を「0%」に完全 に抑え込める トレードオフの発生 ◼ ただし、安全強制時は利用者の満 足度（選好適合度）が少し低下 （約0.91）する 「好み」と「安全」の非両立性 ◼ 利用者の希望にただ従うシステム設計は、災害時には致命的な危険を招くため、個人 の好みを反映させる前に「安全制約」を適用する仕組みが不可欠 介入への納得感の必要性 ◼ 安全を優先した結果として選好適合度（満足度）が低下するため、システム側が 「なぜ強く介入したか」を利用者へ納得させるロジックがセットで求められる 設計指針 ◼ 危険度に応じて、安全上必要な行動を最優先で決定する ◼ 安全を満たす範囲で、話し方や情報量、表現方法を個人に合わせて調整する ◼ 安全を優先して支援内容を変更した場合は、その必要性を利用者へ説明する Analysis4の到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 固定するもの 個別化するもの • 危険度 • 言葉の長さ • 禁止行動 • 根拠の詳しさ • 安全な行動候補 • 比較案の数 • 情報の有効期限 • 共感表現 • 安全性確認の基準 • 提案の強さ • 家族・友人への共有提案 74

Analysis 関わり方診断・個別最適化 安全な行動候補・危険度・禁止行動・情報有効期限は変えず、 説明量・根拠量・比較案数・共感表現・後押し・協力提案のみを利用者に合わせる。 Analysis 4-3-5 個別化の効果をどう実証するか 実証区分： 設計シミュレーション 【分析目的】：診断に合った伝え方が、利用者の理解や受け入れやすさを高めるかを公平に検証する 分析概要 ◼ 診断に合った伝え方の効果を、ランダム化比較実験 で客観的に評価する ◼ 実験に必要な参加者数を事前に算出し、信頼できる 実験計画を作成する 分析対象 ◼ 今後の実利用者実験に参加する利用者 ◼ 共通の災害シナリオ 分析手法 ◼ 3条件ランダム化比較実験 ◼ 検出力分析による必要参加者数の算出 手順 1. 参加者を3グループへランダムに割り当てる 2. 3種類の伝え方で支援効果を比較する 3. 理解度や受容率、判断時間などを評価する 4. 必要参加者数を算出し、実験計画を確認する 変数 ◼ 統一条件：災害状況・危険度・根拠情報・推奨行動 ◼ 比較条件：一律の伝え方 /診断に合わない伝え方/ 診 断に合った伝え方 測定対象 ◼ 提案受容率 /判断時間 /理解度・押し付け感・自己決 定感・安心感・再利用意向 個別化効果を検証する実験計画を設計 ◼ 想定する効果が小さいほど、効果を統計的に証明するために必要 な参加者数は大きく増加する。 ◼ 効果量が大きくなるほど必要な参加者数は減少し、中程度以上の 効果であれば現実的な規模で検証できる。 ◼ 効果量0.20では約1,600人が必要である一方、効果量0.40では約400人 で検証可能となり、想定効果によって実験規模が大きく変化する ことが確認された。 ◼ 個別化の効果を信頼性高く評価するためには、効果量に応じて必 要な参加者数を事前に算出し、十分な実験規模を確保することが 重要である。 設計指針 ◼ 安全な行動や根拠はすべての利用者で共通とし、伝え方だけを変えて効果を比較する ◼ 実験で効果が確認できた伝え方だけを、AIMOの支援方法として採用する ◼ 効果が見られない、または押し付け感などの逆効果が確認された伝え方は採用しない ◼ 実験結果をもとに支援方法を改善し、利用者にとって分かりやすく受け入れやすい伝え方へ継続的に更新する 到達点：利用者に合わせた安全で効果的な支援を実現するための個人化設計基盤を確立した 75

Analysis 日常会話・予定・思い出・継続利用 Analysis 5-1 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか 防災アプリを、災害がない日にも使いたいと思える価値は何か 実証区分： 設計シミュレーション 【分析目的】：平常時から利用される防災アプリの中核機能を特定し、プライバシー懸念を踏まえた継続利用可能な機能設計指針を得る 日常価値コンジョイント設計シミュレーション結果 ◼ 家族共有（約1.65）が最も高く、平常時利用を支える主要機能と なった ◼ 日常会話（約1.50）・思い出記録（約1.30）も高く、コミュニケー ション機能の重要性が示された ◼ 防災通知（約1.15）・予定連携（約1.03）は単体での利用価値が低 かった ◼ 防災通知だけでは継続利用につながりにくく、家族共有・日常会 話・思い出記録を組み合わせることが重要である 分析概要 ◼ 防災通知、予定連携、日常会話、思い出記録、 家族共有の5つの機能を属性として設定する ◼ 2つのサービス案から利用したい方を選択させ る「二者選択型コンジョイント設計シミュレー ション」を実施した ◼ 各機能の提供に伴うプライバシーへの負担 （データ負担）も考慮し、機能ごとの価値を評 価した ◼ 内閣府および国土交通省の公的統計を参考に、 日常利用につながる機能構成の背景を検討する 日常機能価値のプライバシー感度分析結果 ◼ プライバシー懸念（データ負担）が高まるほど、すべての日常 機能の価値は低下した。 ◼ 思い出記録は低下幅が最も大きく、懸念が最大になると利用価 値がマイナスに転じた ◼ 防災通知はデータ負担が小さく、プライバシー懸念が高くても 価値を維持した ◼ 便利な機能でも、収集するデータ量が多い場合は不安によって 利用価値が失われる可能性がある ◼ 継続利用には、機能価値だけでなく、保存範囲や共有設定など 利用者が安心できる仕組みが必要である 分析手法 ◼ 二者選択型コンジョイント設計シミュレーショ ン ◼ ロジスティック回帰による部分効用推定 ◼ プライバシー懸念の感度分析 ◼ 公的統計による背景補強 変数 ◼ 説明変数：防災通知、予定連携、日常会話、思 い出記録、家族共有、プライバシー負担 ◼ 目的変数：利用したいサービス案 ◼ 評価指標：各機能の価値、プライバシーを考慮 した価値 日常的な話し相手と孤独感（背景分析）結果 ◼ ◼ 日常的なつながりと安心設計を備えた防災 アプリが、継続利用につながる ◼ 防災通知単体ではなく、家族共有・日常会 話などの日常価値が継続利用を促す ◼ 便利さとプライバシー安心の両立が重要で ある ◼ 日常的なつながりを支える機能には社会的 な需要がある。平常時利用が非常時活用に つながることを確認した ◼ 話し相手がいる人は強い孤独感が低い（2.7〜4.2%） 話し相手がいない人は強い孤独感が高い（24.5〜 34.2%） 日常的なつながりを支える機能には潜在的な需要がある 設計指針 ◼ 日常機能と防災機能を組み合わせる ◼ 利用者が機能・データ範囲を選択できる設計にする ◼ 日常機能が災害時に役立つ価値を明示する ◼ 実利用者による継続利用・安心評価を行う Analysis5の到達点：日常価値とプライバシー保護を両立する、防災アプリの実装指針を確立した 76

Analysis 日常会話・予定・思い出・継続利用 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか Analysis 5-2 被写体だけでなく、撮った人とその時の会話まで残すと、 思い出の価値は高まるのか 実証区分： 設計シミュレーション 【分析目的】：写真に会話や感情情報を加える価値とデータ提供への抵抗を評価し、AIMOの思い出機能としての有効性を検証する 分析概要 ◼ 3種類の思い出記録方法を比較する実験の設計 ◼ 条件A：被写体のみの写真 ◼ 条件B：被写体 ＋ 撮影者 ◼ 条件C：被写体 ＋ 撮影者 ＋ 会話・感情 ◼ 思い出としての主観的価値（完全性や見返し意向など）と、プラ イバシーへの受け入れやすさ（データ提供許容度）を同時に測 定・比較する ◼ 効果を統計的に正しく評価するために、想定される効果量ごとに 必要な実験参加者数（必要標本数）を算出した 分析手法 ◼ 3条件ランダム化比較実験 ◼ 分散分析または順序ロジットモデルによる統計比較 ◼ 多重比較補正 ◼ 検出力分析 変数 ◼ 比較条件（独立変数）：思い出記録条件3種類（被写体のみ / 被 写体＋撮影者 / 被写体＋撮影者＋会話・感情） ◼ 評価項目（目的変数）：思い出の完全性、見返し意向、AIMOへ の愛着、データ提供許容度（および撮影者の存在感、保存意向） ◼ 統一する条件（統制変数）：写真の場面、表示時間、説明文、保 存期間、撮影者と被写体の関係 設計指針 ◼ 内外カメラは常時起動せず、必要時のみ利用する ◼ 撮影前に記録内容を双方が確認できる仕組みにする ◼ AIによる感情推定ではなく、本人の言葉を重視する ◼ 保存期間・共有範囲を利用者が管理できるようにする ◼ 思い出価値と安心感の両方が確認された機能のみ実装する 思い出価値とプライバシー負担を両面評価する検証が必要 ◼ 必要標本数：小効果では1,011人、中効果では519人、大効果で は213〜315人 ◼ 思い出価値の向上と、個人情報提供への抵抗は同時に評価す る必要がある ◼ 今後は「思い出の完全性」と「データ提供許容度」の両面か ら検証する Analysis5の到達点：日常価値とプライバシー保護を両立する、防災アプリの実装指針を確立した 77

Analysis 日常会話・予定・思い出・継続利用 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか Analysis 5-3 初期18問だけより、 日常の反応を加える方が「今の利用者」を理解しやすいのか 実証区分： 設計シミュレーション 【分析目的】：日常データ追加による8軸プロファイル推定精度への影響を評価し、必要最小限のデータで個人理解とプライバシー保護 を両立する設計基準を明らかにする 分析概要 ◼ 4,000人分の仮想（合成）利用者データをシミュレーション 用に作成した ◼ アンケートによる「初期18問のみ」から開始し、日常会話、 予定、思い出、位置・行動のデータを順番に追加した ◼ データが1つ追加されるたびに、8軸の推定精度と最上位軸 の一致率がどう変わるかを比較した ◼ どの日常データが精度向上に役立つかを切り分ける「モダ リティ追加アブレーション分析」として評価した 分析手法 ◼ モンテカルロ設計シミュレーション分析 ◼ モダリティ追加アブレーション（データ追加比較） ◼ 推定誤差（RMSE）比較 ◼ 最上位軸一致率比較 変数 ◼ 入力変数：初期18問、日常会話特徴、予定特徴、思い出特 徴、位置・行動特徴 ◼ 対象（潜在変数）：利用者の真の8軸プロファイル ◼ 評価指標：8軸の推定誤差（RMSE：青棒）、最上位軸一致 率（オレンジ棒） シミュレーションで日常データの追加により、 8軸プロファイル推定精度は向上 ◼ 日常データの追加により、8軸プロファイル推定精度が向上する可 能性をシミュレーションで確認した ◼ 初期18問のみ（RMSE 0.581・一致率62.7%）から、全日常データ統 合時（RMSE 0.242・一致率81.8%）まで改善した ◼ ただし、多くのデータ収集が必ず有効とは限らず、必要なデータを 選択する設計基準が重要である 設計指針 ◼ 初期診断は完成した人物理解ではなく、長期的な特徴を把握するための基準値として利用し、日常データによって段階的に更新する ◼ 音声や写真などの生データは保存・送信せず、端末内で必要な特徴量のみを抽出して利用することで、データ収集量を最小化する ◼ 追加データによる精度向上が確認できない場合は、不要な収集を停止する仕組みを導入する ◼ 位置情報・写真・会話などは機能ごとに利用者が同意を選択でき、不要な情報提供を避けられる設計にする ◼ AIがプロファイルを更新した理由を確認でき、利用者自身が修正・訂正できる透明性を確保する ◼ 長期的に変化しにくい利用者特性（PROFILE）と、その時々の状態（COMPASS）を分離し、適切に管理する Analysis5の到達点：日常価値とプライバシー保護を両立する、防災アプリの実装指針を確立した 78

Analysis 日常会話・予定・思い出・継続利用 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか Analysis 5-4 一番近い人ではなく、本当に安全に動ける人を担当にできるのか 実証区分： 設計シミュレーション 【分析目的】：距離だけでは判断できない災害時の制約を考慮し、安全性・対応可能性・役割を統合した最適な支援者割当の有効性を評 価する 分析概要 各自判断による限界：システム的な調整を行わない各自判断では、同じ対象に複数人 が向かう「重複」や、誰も向かわない「未対応」が多発した ◼ 各メンバーに対して、現在地からの移動時間、 経路危険度、対応可能性、ケア役割を設定する ◼ 「各自判断」「最短距離のみ」「AIMO制約付 き割当」の3つの割り当て方式を比較した ◼ 災害の強度（危険度）を段階的に変化させ、そ れぞれの方式における割当失敗率の推移を感度 分析した 分析手法 ◼ 制約付き割当問題（アルゴリズム評価） ◼ 最小費用割当 ◼ モンテカルロシミュレーション ◼ 災害強度感度分析 変数 ◼ 入力変数：現在地、移動時間、経路危険度、対 応可能性、移動手段、ケア役割、安否確認状態、 承認状態 ◼ 目的変数（評価指標）：重複行動数、未対応率 （青）、危険担当率（オレンジ）、役割決定時 間、割当失敗率 最短距離方式の欠陥 ◼ 距離の近さだけで選ぶ方式では重複は抑 えられるものの、道中の危険や対応不能 な状況が無視されるため、未対応率（約 18%）や危険担当率（約38%）が非常に高 くなった AIMO制約付き割当の優位性 ◼ 安全性と対応可能性を考慮したAIMO方式 では、既存設計条件において未対応率を 0.1%に抑え、危険担当率を0.1%まで排除 することに成功した 災害強度に応じた失敗率の格差 ◼ 災害強度（危険シナリオ）が0.2か ら0.8へ高くなるほど、最短距離方 式（オレンジ線）は割当失敗率が 約20%から約40%近辺へと右肩上 がりに急増した ◼ 一方で、AIMO制約付き割当（青 線）は災害強度が上がっても失敗 率を10%未満の極めて低い水準に 維持し、その差は強度が上がるほ ど顕著となった 設計指針 ◼ 距離だけでなく、経路危険度・対応可能性・移動手段・役割・未確認状態を考慮した割当を行う ◼ AIMOが自動決定するのではなく、候補提示・本人確認・チーム共有の流れで決定する ◼ 災害状況や対応可能性の変化に応じて、役割分担を再計算する ◼ 未対応・重複担当・未確認者を可視化し、チーム全体で状況を把握できるようにする ◼ 位置情報は共有範囲や精度を利用者自身が設定できるようにする Analysis5の到達点：日常価値とプライバシー保護を両立する、防災アプリの実装指針を確立した 79

Analysis 日常会話・予定・思い出・継続利用 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか Analysis 5-5 AIMOの機能を1つずつ外すと、 安全性と使いやすさのどこが悪化するのか 実証区分： 設計シミュレーション 【分析目的】：各機能の除去による性能低下を評価し、AIMOシステムにおける必須機能とMVP実装時の優先順位を明らかにする 分析概要 ◼ すべての機能を搭載した「全機能版」を基準 （ベースライン）とした ◼ 生活文脈、予測、安全ゲート（安全確認）、個別 化、再取得、チーム情報の各要素を一つずつ除去 （アブレーション）した ◼ 各要素を外した場合に、安全性（安全状態到達率 など）、関連性（不要通知率など）、使いやすさ （行動明確性）がどのように悪化するかを比較・ 評価した 分析手法 ◼ 機能除去比較（アブレーション分析） ◼ 構成要素除去比較 ◼ 複数性能指標による多目的評価（性能比較評価） ◼ 変数 ◼ 除去する機能：生活文脈、予測、安全ゲート（安 全確認）、個別化、再取得、チーム情報 ◼ 評価指標：根拠取得率（青）、行動明確性（黄）、 安全状態到達率（緑） ［※その他、危険提案率、 不要通知率］ AIMOの各機能は異なるリスクを防ぐ役割を持ち、 統合することで安全で実行可能な支援につながる ◼ ◼ ◼ ◼ ◼ ◼ 全機能搭載時は、根拠取得率・行動明確性・安全状態到達率が高水準を維持した 生活文脈を除去すると不要通知率が増加し、利用者に必要な情報を絞る役割が確認された 安全確認（安全ゲート）を除去すると危険提案率が増加し、安全確保の役割が確認された 個別化を除去すると行動明確性が低下し、利用者に合わせた伝達の重要性が示された 再取得を除去すると安全状態到達率が低下し、最新情報への更新機能の重要性が示された 各機能は異なる失敗を防ぐ役割を持ち、単独では代替できないことが示された 設計指針 ◼ 最小限製品（MVP）の必須要件：安全判断に直結する根拠・情報の解析機能、安全確認（安全ゲート）、およびデータの再取得 機能は、どれ一つとして削除できない「最低限必要な機能」として必ず残す ◼ 段階的導入と分離管理：個別化機能やチーム機能はリリース後に段階的に追加（アップデート）してもよいが、システムのコア である「安全判断ロジック」とは切り離して独立管理する ◼ 評価基準（KPI）の設定：各機能に対して、本番実装時に達成すべき明確な合格基準（評価基準）を設定する ◼ 除去比較による有効性実証：製品の評価プロセスにおいて、完成版の良さをアピールするだけでなく、「この機能を外すとこれ だけ悪化する」というプロトタイプ評価（除去比較）を提示して有効性を実証する Analysis5の到達点：日常価値とプライバシー保護を両立する、防災アプリの実装指針を確立した 80

Analysis 日常会話・予定・思い出・継続利用 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか Analysis 5-6 AIMOの役立ち方を保ちながら、 保存する個人データを減らせるのか 実証区分： 設計シミュレーション 【分析目的】：データ管理方式による機能価値・プライバシー負担・利用者制御性の違いを評価し、安心して利用できるプライバシー設 計指針を明らかにする 分析概要 ◼ 5種類のデータ管理方針を比較条件として設定した ◼ 「機能効用（縦軸：大きいほど良い）」と「プライバ シー露出（横軸：小さいほど良い）」の2つの指標を 用いた、多目的設計比較（パレート分析）を実施した ◼ 単一の正解順位を出すのではなく、便利さとリスクの トレードオフを2軸平面上で可視化した ◼ 個人情報保護委員会が推奨する「プライバシー・バ イ・デザイン」および「プライバシー影響評価 （PIA）」の考え方を設計原則に反映した 分析手法 ◼ 多目的設計比較（パレート分析） ◼ 効用―リスク平面分析 ◼ Privacy Impact Assessment（PIA）の設計適用 変数 ◼ 比較条件（入力条件）：保存場所、生データ保存の有 無、保存期間、共有範囲（粒度）、設定・削除の可否 ◼ 評価指標：機能効用（縦軸）、プライバシーへのリス ク（横軸：プライバシー露出）、利用者の管理しやす さ 生データを集めるのではなく、端末内処理と特徴量利用により価値と安心 を両立する設計が有効 ◼ 全生データ保存は機能効用が最大だが、プライバシー露出も最大となった ◼ 生データ短期保存は露出を抑えられるものの、依然としてリスクが残った ◼ 端末内処理＋特徴量共有は、高い機能効用（約0.84）と低い露出（約0.32） を両立する最適な候補となった ◼ 必要時のみ許可・日常記憶なしは露出を低減できるが、利用者理解や機能価 値が低下した ◼ 利便性とプライバシー保護の両立には、必要最小限のデータ利用設計が重要 である 設計指針 ◼ 端末内処理を基本とし、外部送信するデータを最小化する ■会話・写真の生データではなく、必要な特徴量のみを利用する ◼ 機能ごとに同意・拒否、保存期間、共有範囲を利用者が設定できるようにする ◼ 位置情報は詳細な現在地ではなく、必要な粒度で共有できるようにする ◼ 機能追加時はプライバシー影響評価（PIA）を実施し、リスクを事前確認する ◼ 災害時も安全確保に必要な情報のみを利用し、不要な個人データ共有を防ぐ Analysis5の到達点：日常価値とプライバシー保護を両立する、防災アプリの実装指針を確立した 81

Analysis 日常会話・予定・思い出・継続利用 日常の会話・予定・思い出・関係性を、継続利用と災害時の個別支援・チーム支援へつなげられるか まとめ 日常の会話・予定・思い出・関係性は、災害時の個別支援とチーム支援を支えるのか 【分析目的】：Analysis 5-1から5-6の多角的な結果を一つの結論へ統合する 分析概要 ◼ コンジョイント分析による日常利用価値の候補（5機能）を比較した ◼ 内外カメラを用いた思い出機能の効果を実証するための実験計画（標本数） を算出した ◼ 日常の反応データが利用者の8軸プロファイル更新へどの程度寄与し得るかア ブレーション評価した ◼ 災害時のチーム役割調整を、距離だけでなく安全性を含めた「制約付き割当 問題」として評価した ◼ システム全体の有効性を検証するため、主要コンポーネントの機能除去（ア ブレーション）実験を行った ◼ 便利さとプライバシーを両立するデータ最小化方針を2軸平面上で多目的評価 した 分析手法 ◼ 二者選択型コンジョイント設計シミュレーション ◼ ランダム化比較実験・検出力分析設計 ◼ モダリティアブレーション分析（データ追加比較） ◼ 制約付き割当・モンテカルロシミュレーション評価 ◼ システムアブレーション分析（機能除去比較） ◼ 多目的設計比較（パレート分析） 変数 ◼ 日常価値：会話、予定、思い出、家族共有、防災通知、プライバシー負担 ◼ 利用者理解：8軸推定誤差（RMSE）、最上位軸一致率、日常特徴モダリティ ◼ チーム支援：移動時間、経路危険度、対応可能性、未対応率、危険担当率、 割当失敗率、重複行動数 ◼ システム成立性：不要通知率、危険提案率、行動明確性、安全状態到達率、 機能効用、プライバシー露出（リスク） 日常価値・安全性・プライバシーを両立する設計指針を確立 ◼ 日常価値（5-1）： 家族共有・日常会話・思い出記録が平常時利用 を促す主要機能である ◼ 利用者理解（5-3）： 日常データ追加により8軸推定精度が向上し、 全データ統合時にRMSE 0.242、一致率81.8%を達成した ◼ チーム調整（5-4）： 距離だけの割当では危険・未対応が発生する が、安全制約付き割当で未対応率0.1%、危険担当率0%を実現した ◼ 機能役割（5-5）： 各機能は不要通知削減・安全確保・個別化・情 報更新など異なる失敗を防ぐ役割を持つ ◼ プライバシー設計（5-6）： 端末内処理＋特徴量共有が、機能価値 とプライバシー保護を両立する設計候補となった ◼ 実証状況（5-2）： 効果は設計シミュレーション段階であり、実利 用者による大規模検証が今後必要である 設計指針 ◼ 日常データは必要範囲のみ利用し、生データではなく特徴量を中心に管理する ◼ 利用者の同意に基づき、保存期間・共有範囲・削除・位置情報粒度を制御できるようにする ◼ 役割調整は距離だけでなく、安全性・対応可能性を考慮して行う ◼ AIは利用者を監視するのではなく、許可された情報から必要な支援だけを行う ◼ 安全行動を最優先とし、個人理解は伝え方や支援調整に限定して活用する ◼ 実利用では、利用率・継続意向・心理的抵抗などを総合評価する 82

Analysis Analysis 要点整理 Analysis1 災害情報を「行動判断に利用できる情報」へ変換する ■分析目的：FASTALERTの実データから、利用者の行動判断に必要な災害状態（Event State）を構築できるかを明らかに する →FASTALERTの投稿を災害事象・生活影響・利用者文脈を含むRelevant Event Stateへ構造化できることを確認した ■AIMOへの転換 この分析より、災害情報抽出/災害・生活影響辞書/利用者状況照合を設計し、AIMOは「投稿」ではなく「利用者に関係 する災害状態」を理解できるようになった Analysis2 次に起こる生活影響を予測する ■分析目的：構造化した災害状態から、時間的・空間的な変化を分析し、 利用者が次に取得すべき情報を予測する →災害は時間とともに変化するため、現在の状況だけではなく 次に必要となる情報を予測する仕組みが必要であることが分かった ■AIMOへの転換 この分析より、情報取得制御/情報再取得機構/状況更新機構/を設計し、 AIMOは利用者に必要な情報を継続的に取得・更新できるようになった Analysis3 災害情報を安全な「一行動」へ変換する ■分析目的：取得した災害情報を基に、安全で実行可能な行動へ変換できるかを検証する →位置・予定・根拠情報を組み合わせることで、 安全性と説明可能性を備えた「今できる一行動」を生成できることを確認した ■AIMOへの転換 この分析より、安全性確認機構/一行動生成/説明生成/再検索機構を設計し、 AIMOは「危険です」と伝えるだけでなく、 「今何をすればよいか」を提案できるようになった 83

Analysis Analysis 要点整理 Analysis4 その人に届く伝え方へ個人化する ■分析目的：同じ行動でも、利用者ごとに受け入れやすい伝え方へ変換できるかを検証する →利用者ごとに情報量・根拠提示・比較提示・後押しの方法を変えることで、受け入れられやすい支援 へ個人化できることを確認した ■ AIMOへの転換 この分析より、関わり方診断/個別最適化/キャラクターごとの話し方/通知内容最適化を設計し、AIMO は同じ避難情報でも利用者に合わせて伝え方を変えられるようになった Analysis5 日常利用を継続し、災害時まで寄り添えるか ■分析目的：日常利用を通して利用者理解を深め、災害時まで継続して利用される仕組みを設計する →日常会話・思い出・予定・家族共有を組み合わせることで、継続利用と災害時の個別最適支援を両立 できることを確認した ■AIMOへの転換 この分析より、日常会話/思い出記録/予定管理/家族共有/キャラクター育成を設計し、AIMOは災害時 だけ使うアプリではなく、日常から利用者を理解するAIエージェントとなった ■結論 Analysis1〜5を通して、災害時の課題は「情報不足」ではなく、「利用者に関係する情報へ変換し、安全 な行動へ変換し、その人に届く方法で伝えること」であることが明らかになった その結果、AIMOは「日常理解を災害時の行動支援へ変換するAIエージェント」として設計された 84

Use Case

Use Case Use Case 1-1 AIMO誕生イメージ ①情報が集まる ②AIMOが生まれる瞬間 ②あなたのそばへ カルテやメモから、あなたの大切な情報を AIMOが受け取っています そっと寄り添う存在として、 AIMOが光の卵から生まれます！ AIMOがあなたの世界にやってきて 一緒に考え、最初の一歩をサポートします あなたのことをもっと知るために いろいろな情報を集めている はじめまして！AIMOだよ あなたのそばに、そっと寄り添うね これから一緒に、必要な時に 一緒に考えていくよ！ 86

Use Case Use Case 1-2 AIMOとは AIMO 日常から利用者を理解し、 災害時には一人ひとりに合った伝え方で 行動を支援するAIエージェント 日常生活でのAIMO 災害時のAIMO 利用者と関係を築き、理解を深める 利用者ごとの最適な支援を提供 会話を重ねる 日常の会話を通じて繋がる リアルタイム情報を取得 FASTALERTや気象情報など 思い出を共有する 大切な出来事を一緒に記録 生活や価値観を理解する 生活リズムや考え方を学習 大切な人や場所を覚える 家族・よく行く場所など 利用者の状況を統合・分析 現在地・予定・家族など AIMO (デジタル生命体) 「今できる一つの行動」を提示 最適な行動を提案 日常から災害時までを一つの体験として設計 既存サービスが「情報提供」や「共有」を目的とするのに対し、AIMOは災害情報を利用者の日常状況に合わせて 解釈し、安全な一行動の提案や家族間の役割分担まで支援する点が特徴である 継続利用と行動支援の両立を目指す、新しい防災支援システム 87

Use Case Use Case 1-3 AIMO利用の流れ AIMOは、日常生活から災害発生時までを一つの体験として設計している 平常時から利用者との関係を継続し、その関係性を基盤として、災害時の行動支援を実施 循環を繰り返すことで、 利用期間が長くなるほど 利用者に適した支援が実現 88

Use Case Use Case 2-1 AIMO生成モックアップ 利用開始 休日に友人と待ち合わせ をしている。 相手から「30分遅れ る」という連絡が来た。 ①自分ならどう行動するか？ ②相手にどう関わってほしいか？ A.待ち合わせ場所で待つ A.まず謝ってほしい B.相手に別の提案をする B.理由を説明してほしい C.他の予定を済ませる C.今後の予定を提案してほしい D.その他 D.その他 AIMOとの出会い はじめまして。 今日から君の毎日に寄り添わせてね。 これから少しずつ、君の大切なもの 教えてもらえたらうれしいな。。 AIMO (デジタル生命体) AIMOは利用者を分析する 存在ではなく、 一緒に生活を始める存在として登場 89

Use Case Use Case 2-2 AIMO日常利用モックアップ 日常利用 AIMOは、毎日何時間も話かけるわけではない。 生活に自然に溶け込む距離で、必要な時にサポートする。 思い出構築 AIMOは、写真だけでなく会話や気持ちまで記録し、 撮られた人だけでなく、撮影した人の思いも残す ある日の思い出シーン 「今日は午後から雨が降るみたい。 折りたたみ傘を持っていこう。」 朝 「今日は少し混んでいるね。 5分早く出ると座れそうだよ。」 母親： 「乗れたね！」 こども： 「できた！」 今日は○○君が頑張った日だけじゃ なくて、お母さんがずっと隣で見 守っていた日でもあるね。 帰宅前 「今日はいい天気だね。 この前話してた公園、お花が見頃みたい。」 休日 この距離感は、関わり方診断に応じて変化する 思い出は、撮られた人だけのものではない 撮影した人の思いも、同時に残す それがAIMOの思い出構築 90

Use Case Use Case 2-3 AIMO災害時チーム利用モックアップ 災害発生時の支援 「次の一手」による段階的支援 必要な情報だけを統合・抽出し、 その人にあった支援を提案 FASTALERT分析から 災害時には情報量が急増し、 認知負荷が高まる 統合する情報 一度に多くの情報は提示しない チーム支援 家族や友人などチームの状況を共有し役 割調整までサポート ・現在地 ・交通機関 ・家族の予定 ・関わり方診断 ・思い出情報 ・よく利用する場所 一つずつ行動を提示することで、 焦らず安全に行動できる 91

Use Case Use Case 2-3 AIMO災害時対応モックアップ 豪雨発生時 台風が接近し、FASTALERTから 通勤経路付近の道路冠水や鉄道遅延を取得 「次の一手」の提示 災害後 AIMOは、一度にたくさん話さない。 まず、一つだけ行動を提示する ① いつもの駅の近くで冠 水しているみたい。今 日は5分早く家を出て、 △△駅から行こう。 帰宅後、AIMOは今日を思い出として整理 今日は大変だったね。 でも早めに出発したか ら、冠水を避けて帰れ たね。 利用者が「向かう」を押す しかし、AIMOはそれらをそのまま通知しない 利用者の日常を思い出し、状況を統合する ② ③ ありがとう。 次は保育園へ行く道を 一緒に確認しよう。 お父さんへ 連絡しておく？ … 一つずつ、行動を提示していく その経験は、次の豪雨の際に、より適切な支援へ反映される 92

Use Case Use Case 3-1 AIMO ペルソナに基づくプロトタイプ実装 本章の目的 前章までは、AIMOの利用開始から平常時の関係構築、豪雨発生時の情報取得、「次の一手」の提示、 家族や周囲との協力調整までを、一連の利用体験として示した。 しかし、同じ豪雨情報が発表された場合でも、利用者が置かれている生活状況によって、必要となる支援は異なる。 同じ豪雨情報でも必要な支援は異なる 支援の受け取り方も人それぞれ 一人暮らしの大学生 理由や根拠を詳しく知ってから 自分で決めたい AIMOの個別最適化 ① 生活文脈 ・家族構成 ・ライフスタイル ・大切にしていること ・日常の行動パターン ・帰宅経路の安全性 複数の情報を整理した上で 具体的な行動を提案してほしい ・避難のタイミング ・自分の安全が中心 × 複数の選択肢を比較しながら 自分に合う方法を選びたい 子供のいる家庭 ・子供の送迎 気持ちに寄り添ってほしい ＝ ② 関わられ方 ・情報量 ・詳しさ ・提示方法 ・選択方法 ・話し方 ・距離感 ・サポートのスタイル ・家族への連絡 ・役割分担を同時に連絡 生活状況によって必要な支援が変化 感情的な表現を抑え、 必要な事実を簡潔に知りたい 同じ情報でも適切な伝え方は異なる 一人ひとりに合わせた 最適な支援を提供 AIMOの個別最適化の違いを具体的に示すため、4つのペルソナを設定する 93

必要な時だけ確かな情報がほしい一人暮らしの大学生 Use Case Use Case 3-2-1 AIMO ペルソナに基づくプロトタイプ実装：必要な時だけ確かな情報がほしい一人暮らしの大学生 基本属性 日常生活の特徴 価値観 ・21歳 ・大学生 ・都市部の大学 ・一人暮らし(賃貸) ・実家を離れて生活 ・飲食店でアルバイト ・平日は授業やバイトで予定が 変動しやすい ・帰宅時間や移動経路が 日によって異なる ・家族とは良好な関係だが、 頻繁には連絡は取らない ・行動は自分で判断したいと考えている ・過度な見守りや行動確認は 負担に感じる ・信用できる情報をもとに 自分で判断したい ・危険情報は発信源・位置・接続時間 現地画像などを確認する ・複数の選択肢を比較して 納得して行動したい ◼ AIMOの関わり方診断に基づく支援設計 診断からわかった特徴 関わり方診断の結果 気持ちの共有が 低い 行動後押が 低い 根拠納が 高い 比較選択が 高い 見守り距が 低い そのため、AIMOは… 必要なときだけつながる適度な距離感で 情報源や複数の選択肢を提示し、自分で判断できるよう支援 指示ではなく判断材料を整理して提供 ✓ 緊急時のみ明確な行動を促し、平常時は自己決定を尊重 94

必要な時だけ確かな情報がほしい一人暮らしの大学生 Use Case Use Case 3-2-2 AIMO ペルソナに基づくプロトタイプ実装：診断を基に生成されたAIMOの日常支援設定 朝（天気や交通状況が通常） 雲：見守りの象徴 午後は少し雨が降りそう。 帰る時間には弱くなっている 予報だから、 折りたたみ傘で足りそうだよ。 アルバイトがある日 今日はいつもの路線が少し遅れてる。 授業のあと直接バイトへ行くなら、 一本早い電車が余裕ありそう。 レンズ：根拠納得の高さ 詳細を見る コンパス：比較選択の高さ 話し方 過剰な感情表現を避ける 遅延理由や代替ルートを展開 ☆離れた場所にいる親しい友人が 必要なことだけを伝えるような距離感 95

Use Case Use Case 3-2-3 必要な時だけ確かな情報がほしい一人暮らしの大学生 AIMO ペルソナに基づくプロトタイプ実装：AIMOの思い出構築における特徴 1.出来事の記録 友人と初めて訪れた 飲食店の写真を保存 2．AIMOとの会話で“思い出”も記録 ここ、前にみんなでいったお店だね。 帰りは△△駅から帰った日だったね。 [従来の記録] 料理の写真のみ そうそう！学園祭の打ち上げの日だった あなた ３．プライバシーと信頼の設計 この記録は、本人の許可範囲内で、 日常的によく訪れる場所や移動傾向の 把握に使用 写真に写った人物の関係性をAIMOが 断定してはいけない 「友人」「恋人」「家族」に等自動で 確定せず、利用者が後から変更できる設計 96

必要な時だけ確かな情報がほしい一人暮らしの大学生 Use Case Use Case 3-2-4 AIMO ペルソナに基づくプロトタイプ実装：豪雨時のAIMOの利用例 １.豪雨発生時の状況 ・授業終了後、アルバイト先に 向かう時間帯に局地的豪雨発生 ・通常経路で冠水投稿が増加 (現地画像・位置情報あり) ・駅構内への雨水流入 鉄道会社, 一部運転見合わせ AIMOが統合する情報 〇利用者の現在地 〇アルバイトの開始時刻 〇通常使用する駅 〇道路冠水の投稿位置 〇投稿時刻 〇現地画像の有無 〇鉄道会社の公式発表 〇代替駅までの距離 〇関わり方診断の結果 ２.AIMOによる最初の声掛け いつもの○○駅前で冠水の投稿が 増えてる。 10分以内の現地写真が3件あって、 鉄道会社も一部運転見合わせを出し てるよ 今の候補は二つあるよ。 ・Aは○○駅へ向かうルート。 近いけど、駅前の冠水範囲を通る 可能性がある。 ・Bは△△駅まで歩くルート。12分長く なるけど、今のところ冠水投稿は確認 されていない。 その上でAIMOは判断を急かさない この利用者は、 行動後押しが低いため 「絶対Bへ行って」 「すぐ行こう」と強く促さない Bルートで行こうと思う あなた 了解。まず大学の西門から出よう。 までの途中で状況が変わったら、 また知らせるね。 本人の判断を尊重しつつ、 危険性が高まった場合には、 根拠と共に提案強度を上げる 97

Use Case Use Case 3-2-5 必要な時だけ確かな情報がほしい一人暮らしの大学生 AIMO ペルソナに基づくプロトタイプ実装：分析結果を反映したAIMOの支援価値 本ペルソナには、第3章の分析で確認した 次の特徴が直接反映される AIMOが提供する価値 投稿の具体性と信頼性に差がある 位置情報・画像・投稿時刻 公式発表との一致を整理し、 根拠納得の高い利用者へ提示 短時間に投稿が増加するバーストが発生 投稿1件のみで断定せず、 同一地点付近の投稿増加と 公式情報を組み合わせて提案 豪雨時には交通障害と道路冠水が連動 気象情報だけでなく、 大学、アルバイト先、駅 代替経路を統合 AIMOは、利用者を動かす主体ではなく、利用者が 納得して動くための判断環境を整える存在として機能 98

Use Case Use Case 3-3-1 情報を整理して行動開始を後押ししてほしい若手会社員 AIMO ペルソナに基づくプロトタイプ実装：情報を整理して行動開始を後押ししてほしい若手会社員 基本属性 日常生活の特徴 価値観 ・28歳 ・業務中はスマートフォンの頻繁な確認が困難 ・情報が整理されていれば素早く判断できる ・選択肢が多すぎると決定を先送りしやすい ・信頼できる情報をもとに自分で判断したい ・会社員 ・様子を見ているうちに移動機会を ・周囲と状況を共有した上で行動したい ・都市部の企業 逃すことがある ・気象情報や交通情報を自分で調べる ・職場まで電車50分 ・仕事に集中している間に状況が変化し、 意識はある 退勤時には複数路線が停止していることが ・複数路線で通勤 ある ◼ AIMOの関わり方診断に基づく支援設計 診断からわかった特徴 関わり方診断の結果 整理サポートが 高い 行動後押しが 高い 協力調整が 比較的高い そのため、AIMOは… 個人に対して 大量の情報を並列に示さない 現状況、判断期限、推奨行動を短く整理 「今のうちにするとよい」と明確に背中を押す支援が有効 周囲に対して 家族への帰宅予定共有、職場への退勤連絡必要に応じた役割調整 99

Use Case Use Case 3-3-2 情報を整理して行動開始を後押ししてほしい若手会社員 AIMO ペルソナに基づくプロトタイプ実装：AIMOの日常支援設定 業務中の通知は原則抑制 緊急性の低い情報は、 昼休みや退勤前になど 確認しやすい時間に 12：15 「午後の予定に関係しそうなのは二つ。 17時ごろから雨が強くなる予報と、 帰りの路線で遅れが出てること。 退勤前にもう一度確認するね。」 17：55 今なら通常ルートで帰れる可能性 が高いよ。30分後は運転見合わせ の範囲が広がるかもしれない。 日常における理解の蓄積 旗：協調調整 今日は会議が長引きそう。 あなた 分かった。会議が終わる時間に 雨と電車をもう一度見ておくね。 手帳：整理サポート ランタン：行動後押し 単なる雑談として終わらせず、 退勤予定時刻と気象リスクの照会へ 100

Use Case Use Case 3-3-3 情報を整理して行動開始を後押ししてほしい若手会社員 AIMO ペルソナに基づくプロトタイプ実装：豪雨時のAIMOの利用例 豪雨発生時の状況 ・台風の接近により 夕方から雨が急激に強まる予報 ・利用者は会議中で 頻繁にスマホを確認できない。 FASTALERTで確認された状況 今、帰る判断に必要なことを3つまとめたよ。 ①最寄り駅の地下通路で浸水投稿が増えている。 ②いつも路線は速度規制中 ③今出れば別の入り口から駅へ入って、 通常に近い経路で帰れる可能性が高い 今日は片付けをあとにして、今出よう。 この10分が大きいと思う。 帰宅する ・職場最寄り駅周辺の地下通路への浸水、 道路上の急激な水位上昇、 タクシー乗り場の混雑に関する投稿の増加 ・利用者が乗り換えに使用する路線では、 一部区間の速度規制が開始 AIMOが照合する情報 ・利用者の退勤予定時刻 ・会議終了の想定時刻 (通常は＋10分程度残る傾向) ・交通情報の変化 (速度規制・運休など) ・過去の移動履歴 まず北側の出口へ向かおう。地下通路は使わないでね。 協力調整を実施 家には『いつもより早く出たけど、迂回して帰る』って 共有しておく？ 承認＋送信内容の確認 安全確保のため退勤します。 移動後に必要な対応を確認します。 101

Use Case Use Case 3-3-4 情報を整理して行動開始を後押ししてほしい若手会社員 AIMO ペルソナに基づくプロトタイプ実装：リアルタイム情報に基づく行動支援 AIMOは、最初の通知で帰宅完了までの全手順を一度に提示しない。 利用者の行動完了とリアルタイム情報の再取得を繰り返し、必要な時に「次の一手」だけを提示する。 リアルタイム情報の変化に応じて再計算 利用者が北側出口へ到着した時点で、 新たなFASTALERT投稿から 別の道路の冠水が確認された場合、 当初の経路へ固執せず、再計算する。 102

Use Case Use Case 3-3-5 情報を整理して行動開始を後押ししてほしい若手会社員 AIMO ペルソナに基づくプロトタイプ実装：分析結果を反映したAIMOの支援価値 本ペルソナは、第3章で確認した情報の時間変化と生活影響の連鎖を反映している。 ① 情報の時間変化と再取得 ② 情報整理と「今の一手」への変換 FASTALERT投稿は、災害発生時点だけでなく、 情報量が多い状況では、そのまま全件を提示する 交通障害や浸水の拡大に伴って増加する。 と利用者の認知負荷が高まる。 AIMOは朝の予報だけで判断せ、 本ペルソナがでは、整理サポートの高さに応じて 退勤時刻の直前にもデータを再取得する。 「需要な三点」と「今の一手」へ変換する。 「情報を知っていること」と「適切な時刻に行動を開始できること」は異なる AIMOの価値 情報を整理する 判断期限を示す 今行うべき一手を 具体化する 理解から実行まの空白を埋める 103

Use Case Use Case 3-4-1 子供の安全と家族の役割調整を必要とする保護者 AIMO ペルソナに基づくプロトタイプ実装：子供の安全と家族の役割調整を必要とする保護者 基本属性 日常生活の特徴 価値観 ・34歳 ・平日は仕事しながら保育施設への送迎や家事 ・女性 ・子供の安全を最優先に考えたい ・送迎担当は曜日で異なり 本人・パートナー・祖父母で調整 ・買い物や夕食準備など家族で役割を分担 ・家族の連携情報共有を大切にしたい ・乳幼児の保護者 (子供1人) ・都市郊外在住 ・不安なときに寄り添ってほしい ・豪雨や交通障害があると役割や経路を短時間で 調節する必要がある ・仕事と育児の両立 ◼ AIMOの関わり方診断に基づく支援設計 診断からわかった特徴 関わり方診断の結果 気持ちの共有が 高い 行動後押しが 高い 協力調整が高い 整理サポートが 高い 見守り距が 高い そのため、AIMOは… 平常時からの頻繁な話かけはしない 必要な情報を短く整理して提案する 家族全体の行動を調整してサポートする 104

Use Case Use Case 3-4-2 子供の安全と家族の役割調整を必要とする保護者 AIMO ペルソナに基づくプロトタイプ実装： AIMOの日常支援設定 光：気持ちの共有 今日の予定 お迎え：お父さん 時間：17時30分 夕方から雨が強くなる予報 (16時以降) 今日はお迎え、お父さんの予定になってる ね。夕方から雨が強くなるみたいだから、 出る時間だけ少し早めに相談しておこうか。 まだ、大丈夫。 雨：感情を受け止め 相手に寄り添う あなた 保育施設周辺の天候が急変 保育園近く、雨が強くなってきたよ。 いつもより、20分早く動けるかだけ、 家族で確認しておくと安心そう。 ランタン：行動後押し リボン：協力調整 手帳：整理サポート 105

Use Case Use Case 3-4-3 子供の安全と家族の役割調整を必要とする保護者 AIMO ペルソナに基づくプロトタイプ実装： AIMOの思い出構築における特徴 1.出来事の記録 2．AIMOとの会話で“気持ち”も思い出に 子供が初めて一人で歩いた瞬間を 保護者がスマホで撮影。 今日は○○ちゃんが初めて一人で歩い た日だね。でも、この写真の外でいち ばんうれしそうに笑っていたのは、 撮っていたあなたかもしれないね。 [従来の記録] 赤ちゃんの様子のみ 本当に嬉しくて、手が震えた。 あなた ３．思い出を可視化して保存 AIMOは、画像だけで判断しない [AIMOの記録] 外カメラ：赤ちゃんの様子 内カメラ：撮影者の様子 出来事：〇〇ちゃんが初めて歩いた日 日付 ：2026/7/14 場所 ：リビング 感情を決めつけない 「嬉しかった？」と確認して、 あなたの言葉を大切に記録 あなたの気持ち 「本当に嬉しくて、手が震えた」 「撮影された人」だけでなく、 この思い出に関わった人 撮影者 ：あなた(ママ) 見守っていた人：お父さん(パパ) 一緒に喜んだ人：おばあちゃん 「撮影した人」「見守った人」 「その場を支えた人」も 思い出の主体になる 106

Use Case Use Case 3-4-4 子供の安全と家族の役割調整を必要とする保護者 AIMO ペルソナに基づくプロトタイプ実装： 豪雨発生時における一連の支援プロセス① １.豪雨発生時の状況 ・平日の夕方、保育施設への お迎え前に豪雨発生 ２.AIMOによる最初の声掛け AIMOが役割案を提示 急にこんな雨だと心配になるよね。 今、迎えに関することだけ確認したよ。 ・通常経路で冠水投稿が増加 (現地画像あり) ・別ルートは渋滞が発生 ・パートナーは40分以上 かかる可能性 ・本人は職場から 20分程度の地点にいる AIMOが統合する情報 〇保育園の位置 〇子供の退園予定時刻 〇家族それぞれの現在地 〇道路冠水の投稿地点 〇現地画像 〇交通状況 〇家族の予定 〇関わり方診断の結果 3.チーム機能による役割調整 移動中 保護者本人 保育施設へ迎えに行く パートナー(お父さん) 今大事なのは３つ！ いつもの道で冠水が確認されている。 自宅付近の状況確認と帰宅準備 祖父母 お父さんは、渋滞を考えると 間に合わない可能性がある。 未確認 確認済み 対応不要、状況共有のみ あなたなら、別の道で20分くらいで 着けそう。 今日はあなたがお迎えに行くのが良さそう。 まず、職場を出よう。 お父さんへの連絡はこっちで文面作るね。 対応中 AIMO 経路の再取得 保育施設周辺の投稿確認 パートナーへのメッセージ案 いつもの道が冠水しているから、 私が別ルートで迎えに行くね。家の近 くの雨と、帰れる時間だけ見ておいて もらえる？ 本人が内容を確認してから共有 分かった！ じゃあ、向かうね。 あなた 未確認の家族がいる場合は、 連絡手段の変更や別の家族による 確認を提案 107

Use Case Use Case 3-4-4 子供の安全と家族の役割調整を必要とする保護者 AIMO ペルソナに基づくプロトタイプ実装： 豪雨発生時における一連の支援プロセス② 4．段階的な「次の一手」でサポート ① 職場を出る 第一の一手。本人が移動を開始。 ② 推奨ルートへ、経路を再取得。 「東側の大通りへ向かおう。 川沿いは避けて」 ③ 途中で再検索/再計算 新しい冠水投稿を取得。 「この先で水が増えている投稿が出た。 右に曲がって、1本内側へ行こう」 ④ 保育施設に到着 「着けたね。お迎え完了を共有して 安全に帰れる道を確認しよう。」 ⑤ 家族へ到着を共有 安全に帰宅するための経路を 確認・共有 ５．思い出と非常時支援の接続 AIMOは、日常の会話や思い出を通じて、 利用者が子供の成長や家族の時間を 大切にしていることを理解する 禁止する表現 「子供のために今すぐ動かないと後悔する」など 恐怖や罪悪感を煽る表現 AIMOのサポート姿勢 大切な存在を守るために必要な、 現実的な行動を落ち着いて提示する ♡ AIMOのメッセージ例 「大切だからこそ、焦らず一つずつ確認しよう。 今は、別の道で迎えに向かうのが 最初の一手だよ。」 108

Use Case Use Case 3-4-5 子供の安全と家族の役割調整を必要とする保護者 AIMO ペルソナに基づくプロトタイプ実装： 本ペルソナが示すAIMOの価値 子育て世帯に必要な支援は、個人の避難経路案内だけでは完結しない。 重要なのは、家族単位での整理！ 「誰が迎えに行くか」 「誰が家を確認するか」 「誰がまだ情報を 見てないか」 AIMOの役割 情報の提供者ではなく、 家族の意思決定と役割分担を支える調整者 として機能する 109

Use Case Use Case 3-5-1 積雪の多い地域で暮らす保護者と高校生の家族 AIMO ペルソナに基づくプロトタイプ実装： 積雪の多い地域で暮らす保護者と高校生の家族 ペルソナ④ 積雪の多い地域で暮らす 冬の大雪や吹雪に加え、融雪期や夏季の大雨でも 様々な災害リスクが生じる環境で生活している。 保護者と高校生の家族 日常的に気象情報を確認する習慣はあるが、 家族全員が同じ方法で支援を受けたいわけではない。 環境の変化 早めの情報、根拠、明確な行動提案、 家族間の役割調整を求める 冬季 大雪・吹雪により、短時間で変化 保護者 道路状況 公共交通 学校の予定 送迎可能性 高校生 過度に管理されたくない、 頻繁な声掛けや強い指示には 反発しやすい 融雪期・夏季 大雨により、以下のリスクが発生 河川増水 道路冠水 斜面災害 など 同じ情報を家族全員へ同じ分で送るのではなく、 共通の状況認識を保ち、 相手ごとに伝え方を変える必要がある 110

Use Case Use Case 3-5-2 積雪の多い地域で暮らす保護者と高校生の家族 AIMO ペルソナに基づくプロトタイプ実装： 利用者特性に応じた関わり方の違い 保護者の関わり方診断 [求める支援] 根拠が明確で比較できる複数案の提示と 家族の役割調整 息子(高校生)の関わり方診断 [求める支援] 短くシンプルな提案と、 自分で決められる余地を残したサポート 111

Use Case Use Case 3-5-3 積雪の多い地域で暮らす保護者と高校生の家族 AIMO ペルソナに基づくプロトタイプ実装： 家族内におけるAIMOの個別最適化支援 保護者の初期AIMO 息子(高校生)の初期AIMO 旗： 家族調整 レンズ： 根拠確認 天秤：比較 ランタン：行動後押し 明日の朝に関係する情報をまとめたよ。 降雪は6時ごろから強まる予報。 バス会社は遅延の可能性を案内してる。 学校から休校連絡はまだ出ていない。 明日の朝、バスが遅れるかも。 起きたら一度だけ予定を確認 しよう。 送る場合とバスを使う場合の二案を見ておく？ 112

Use Case Use Case 3-5-4 積雪の多い地域で暮らす保護者と高校生の家族 AIMO ペルソナに基づくプロトタイプ実装： 豪雨時のAIMOの利用例 保護者のAIMO 状況設定 ・高校生が学校にいる 時間帯に大雨に ・通学路上の道路冠水や 河川増水が発生 ・バス会社は一部区間の 高校生のAIMO 迂回運行を発表 ・学校は通常授業を継続 帰宅方法は、バスと迎えの2つあるよ。 バスは、迂回運行となっており、到着 時間が読みにくい状況だよ。 迎えの場合は、南側の道路で冠水投稿 が確認されている一方、北側では大き な冠水情報は確認されていない。 今日は北側のルートから迎えに来ても らうのが、安全性は高そうだね。 今日は迎えを使う方がよさそう。 北門で待とう。 出る時間決まったら知らせるね。 バスで帰れるよ。 帰れる可能性はあるよ。 ただ、途中の区間で迂回が始まってる。 今日は北門の迎えが早くて安全そうだけど、 どうする？？ 本人が選択できる余地を残しつつ 必要な後押しを行う 113

Use Case Use Case 3-5-5 積雪の多い地域で暮らす保護者と高校生の家族 AIMO ペルソナに基づくプロトタイプ実装： 降雪時のAIMOの拡張利用例 降雪・吹雪の外部データと連携する場合にも、同じ支援構造を利用できる 保護者のAIMO 吹雪が強まる前に迎えに出るなら、 15時30分までがよさそう。 帰りは国道を避けて東側の道を使 う案が安全そうだよ。 降雪量・視界・道路規制 公共交通・学校連絡等を 整理して比較案を提示 高校生のAIMO 今日は迎えに変えよう。 15時40分に正面玄関で待ってて. 必要な行動のみを 端的に提示 この利用例はAIMOの地域拡張性を示す設計例であり、本提案における FASTALERT分析結果から降雪時の検知性能を実証したものではない。 実装時には、道路管理者、自治体、気象機関、公共交通事業者等の降雪関 連データを別途統合し、地域別の検証が必要となる。 114

Use Case Use Case 3-5-6 積雪の多い地域で暮らす保護者と高校生の家族 AIMO ペルソナに基づくプロトタイプ実装： 家族チーム単位の役割調整 家族のチーム画面では、次のように役割整理する。 保護者A 保護者B 担当：移動/迎え 担当：家庭内の調整 自宅周辺の安全確認 下の子の予定・送迎の確認 最適な経路を確認 出発・到着時間を調整 高校生 担当：待機/確認 北門で待機 移動開始時に確認を返す AIMO 担当：情報監視/通知 道路情報の再取得・分析 下経路変更時のみ通知 115

積雪の多い地域で暮らす保護者と高校生の家族 Use Case Use Case 3-5-7 AIMO ペルソナに基づくプロトタイプ実装： 本ペルソナが示すAIMOの価値 AIMOは、家族を一つの均質な利用者として扱わず、 家族全体の協力と個人の自律性を両立させる 家族の違い AIMOの役割 受け取り方が違う 意思決定の方法が違う AIMO 望む距離感が違う 116

Use Case Use Case 3-6 AIMO ペルソナに基づくプロトタイプ実装： 4つのペルソナ比較 ペルソナ 中心的な生活課題 特に重要な診断軸 AIMOの主要な役割 情報提示の特徴 一人暮らし の大学生 自身の移動経路 の安全判断 根拠納得、比較選択、 見守り距離 判断材料の提示 根拠と複数案を示し、 本人へ決定を委ねる 若手会社員 退勤判断と行動 開始の遅れ 整理サポート、行動後押し、 協力調整 情報整理と 開始時刻の提示 重要事項を絞り、 今動く理由と一手を示す 子育て中の 保護者 送迎と家族 の役割調整 気持ち共有、整理サポート、 行動後押し、協力調整 家族単位の 意思決定支援 不安を受け止め、推奨案 と役割を明確化する 共通情報の個別変換 家族ごとに説明量と 提案強度を変える 積雪地域 の家族 地域リスクと家族内 保護者：根拠・比較・協力、 の異なる希望 高校生：距離・後押し AIMOが変化させるべき要素 ・支援を開始する時間 ・通知する頻度 ・情報量 ・根拠の示し方 ・選択肢の数 ・推奨の強さ ・感情表現の量 ・周囲への連絡提案 ・家庭内の役割分担 ・次の一手の細かさ 結論 AIMOの個別最適化は単に文章やキャラクターの色を 変えることではなく、情報取得後の支援生成を 制御する中核機構として機能する。 117

Use Case Use Case 3-7 分析、診断、生活文脈、支援の対応関係 ４つのペルソナを通じて示したAIMOの支援は次の4段階で生成される 利用者への ① 外部情報の理解 ② 影響の判断 取得する情報 ③ 関わり方への変換 ④ 次の一手と再取得 照合する内容 ・道路冠水、河川増水 ・停電、運休、運行止め 等 整理する要素(運用辞書) ・現在地、予定、通常経路 ・よく利用する場所 ・家族の位置、送迎予定 等 関わり方診断に合わせて変換 提示する内容 根拠納得が高い→情報源を提示 直ちに実行できる 一つの行動を提示 整理サポートが高い→要点を絞る 比較選択が高い→複数案を提示 ・位置の具体性、投稿時間 ・現場性、行動への影響 ・根拠、不確実性 等 生活への影響がない場合 不要な通知を抑制 行動後押しが高い→提案を明確に 実行後 気持ち共有が高い 情報を再取得し、 状況変化に応じて →不安を受け止める言葉を加える 次の行動を再計算 この構造により、AIMOは静的な防災マニュアルではなく、 状況と利用者の双方に適応する継続的支援システムとなる 118

Use Case Use Case 3-8 ペルソナ設計から確認できる提案の有効範囲 4つのペルソナから、AIMOは少なくとも3つの利用単位へ対応できることが分かる。 個人単位の支援 ① (一人暮らしの大学生・若手社員) ② 家族チーム単位の支援 複数人の位置 予定 役割 確認状況 等 自身の移動 帰宅 予定変更 等 個人の行動・予定に対応 ③ (子育て世帯) 地域適応型の支援 （積地域の家族） 同じシステム構造 地域固有の気象 交通・生活習慣に適用 家族の情報と役割の統合 地域ごとの環境に適応 注意点 ペルソナの提案の有効性を実証する統計的根拠ではない 分析で得られた知見と設計要件が、具体的な利用場面で矛盾なく機能するか検証するためのもの プロトタイプ評価で測るべき指標 ・推奨行動の理解率 ・安心感 ・行動開始までの時間 ・自己決定感 ・提案の受容率 ・家族内の調整時間 ・情報過多感 ・AIMOへの愛着 ・押し付け感 ・継続利用意向 比較による効果検証 関わり方診断に 適合した表現 適合してない 一律表現 個別化が行動支援に与える効果を検証 119

Use Case Use Case 3-9 施策提案まとめ AIMOは、利用者を理解し、非常時に最適な支援を行い、 安全な日常を取り戻すまで寄り添い続ける「相棒」 ①ペルソナ診断 自分なら/相手ならの 2パターンで診断 ②AIMOの誕生 ③日常で理解する ④非常時に支える ⑤安全な日常へ戻す あなたのことを理解しているから 伝え方を変え得て動きやすくする 安全な日々を続けられるように 次の一手、その次の一手へつなぐ 内外カメラ・写真記録 伝え方を最適化 次の一手を提案 日常の様子や環境を理解 落ち着く言葉、響くタイミング 分かりやすい順番で伝える 今やるべきことを明確にし、 迷わず行動できるようにする 行動を後押し 日常への復帰を支援 あなたが動きやすい形で 最適な“次の一手”を提案 安心して元の生活に戻るための サポートを行う 護りたい存在として 寄り添う 継続的な守り 日常的にあなたを理解する 診断結果を基に 様々な機能 あなただけのAIMOが誕生！ 自分なら 自分がその場面で どう考え、どう動くかを 選択していく 予定・スケジュール 予定やリズムを把握 生活圏の理解 相手なら 家族や友人など、 相手の立場なら どうしてほしいかを選択していく 価値観・行動傾向・情報の受け取り方 大切にしていることなどを理解 あなたのペルソナを診断 よく行く場所や移動ルート を理解 仲良し・関係性の理解 あなただけの相棒 あなたの価値や考え方を理解 いつのも関係性を理解 日常の会話 あなたに合った話し方・関わり方 何気ない会話から気持ちや 考え方を理解 信頼できるパートナーとして寄り添う 関わり方は日々更新 固定せず、あなたに合わせ 関わり方を更新し続ける たくさん“いつも”を学習 AIMOはあなたにとって 大切な存在(相棒) 「AIMOのために動きたい」 と思えるように背中を押す 「自分のため」だけではなく 「AIMOを守りたい」という 気持ちが行動の原動力になる 日常が安全に続くように そっと見守り続ける 振り返りと改善 学んだことを活かし、 次に備えてさらに最適化 日常に戻った後も ずっとあなたのそばで支える 120

Use Case Use Case 3-9 要点整理 AIMO：日常から利用者を理解し、 災害時には1人ひとりに合った伝え方で行動を支援する AIエージェントである 特徴（循環形式） ◼ 関わり方診断による初期理解/日常会話による継続 学習/予定確認/思い出共有/家族との連携/災害時 の個別最適通知 日常利用 ↓ 利用者理解 ↓ 災害時支援 ↓ 安心体験 ↓ 継続利用 （循環形成） AIMO達成目標 ◼ 日常と非常時をつなぎ、人の行動を変え、その成 果を再び社会へ還元すること Persona AIMOは「全員に同じ通知を送るAI」ではない 関わり方診断により ・情報を重視する人 ・背中を押してほしい人 ・気持ちに寄り添ってほしい人 ・家族と協力したい人 関わり方の違いを理解する その結果、同じ災害でも ・伝える内容 ・言葉遣い ・通知タイミング ・家族との連携方法 を利用者ごとに最適化できる ペルソナは「人物像」を作るためではなく、 個別最適な防災支援を設計するための代表例と して設定した 121

Prototype implementation

Prototype implementation Prototype implementation1 FASTALERT実データから「今できる一つの行動」までを一気通貫で実装 AIMOの中核である「災害情報を受け取り、利用者の状況と照合し、安全な行動候補を選び、 その人に合う言葉で伝える」一連の処理をMVPとして実装 現在はFASTALERT実データを入力し、Event Parser、Context Matcher、Tool Router、行動候補生成、Safety Gate、 関わり方8軸による個人化、再照会ルール生成まで実行可能 外部気象・道路・鉄道・避難情報は現段階ではMockデータで接続しており、実APIへの置換を次段階 STEP 1 FASTALERT実データを読み込む 今回のデモ入力： 2025年台風15号 ■事象：浸水・冠水 ■地域：静岡県 ■投稿傾向：増加 架空の災害文を入力したのではなく提供FASTALERT CSVを入力 STEP 2 投稿を判断可能なEvent Stateへ構造化 FASTALERTの投稿群 ▼ AIMO内部では、■Event：浸水・冠水 ■Area：静岡県 ■Trend：増加 ■Topic数 ■直近60分投稿数 として保持 自由記述・投稿列をそのままLLMへ渡さず災害状態を構造化 STEP 3 利用者に関係する災害かを判定 例：大学生A ■現在地：大学 ■目的地：自宅 ■帰宅予定：18:30 ■通常経路：駅南口経由 Route Risk：High ＝「この災害情報は利用者の帰宅判断に関係する」と判定 STEP 4 複数の行動候補生成＋安全性確認 ■候補A：通常経路で駅南口へ向かう NG ■候補B：北口側経由を確認 OK ■候補C：10分待機して再確認 OK ▼ Safety Gate ▼ 北口側経由を確認するを通過 STEP 5 同じ安全判断をその人に届く言葉へ変換 ■大学生Aの関わり方： 根拠 89 | 見守 84 | 比較 78 | 後押 27 実際のMVP出力： 「静岡県で浸水・冠水の投稿が増えてる。 いつもの駅南口経由は避けた方がよさそう。 北口側経由と10分待機の2案があるよ。 今は北口側を確認する方が安全そう。理由も見る？」 ■FASTALERTの「災害情報」を、利用者の「今できる一つの行動」まで変換 FASTALERT実データ入力：実装済 中核判断ロジック：実装済 外部情報：Mock接続 実API接続：次段階 123

Prototype implementation Prototype implementation2 一つの生成AIに判断を任せず、取得・判断・安全確認・個人化を分離 災害支援では、一つのLLMへ「何をすべき？」と直接尋ねる構造では、どの情報を使い、 なぜその行動になり、どこで安全確認されたかを追跡しにくい AIMO：災害理解、文脈照合、情報取得、行動生成、安全確認、個人化を独立したモジュールに分け、 各処理の入出力を記録可能な構造とした 内部では何が動いているか：システム概要 FASTALERT ▼ ① 【何が起きている？】： 事象・地域・時刻・変化 ▼ ②【この人に関係する？】： 現在地・予定・経路 ▼ ③【 何を追加確認する？】： 気象・道路・鉄道・避難場所 ▼ ④【 根拠は何か？】： 必要な情報のみ取得 ▼ ⑤【 何ができる？】： 複数の行動候補を生成 ▼ ⑥ 【危険ではない？】： 危険候補・根拠不足・矛盾を除外 ▼ ⑦ 【この人へどう伝える？】： 8軸で情報量・比較距離感等を調整 ▼ AIMO OUTPUT「今できる一つの行動」 2025年台風15号のFASTALERT実データで、 8モジュールを一気通貫実行 EXECUTION TRACE 2 Context Matcher：PASS affected=True route_risk=high 1 Event Parser：PASS 浸水・冠水／静岡県／増加 4 Retriever：PASS 4種類の根拠を取得 5 Action Planner：PASS 北口側経由を選択 7 Personalization：PASS 根拠多め・比較あり・強く押さない 3 Tool Router：PASS Weather / Road / Rail / Shelter 6 Safety Gate：PASS 安全候補として通過 8 Closed-loop Re-query：PASS 次回再取得ルールを生成 8 / 8 PROCESS COMPLETED この1デモケースについて処理フローが最後まで実行された 今回のデモケースでは、すべてのモジュールが途中停止せず処理され、 「北口側経由を確認する」という行動候補と、大学生の関わり方に適 応したAIMO発話まで出力された 124

Prototype implementation Prototype implementation3 災害事象に応じて、必要な外部情報だけを選択して取得 FASTALERTだけでは「危険がある」ことは分かっても、「今どの経路を使うべきか」までは決められない 毎回すべての外部データを取得するとAPI負荷と応答遅延が増える AIMOは、災害事象と生活文脈から必要な外部情報を選択するTool Routerを用いる 提供FASTALERT分析では、外部情報層との接続可能Topic数が層ごとに異なり、避難場所・地理情報3,692 Topic、鉄道・ 道路2,805 Topic、企業運営2,573 Topic、気象・キキクル1,789 Topic、家族避難支援1,735 Topicとして整理されている 今回のデモ ◼ 入力： 浸水・冠水 ＋帰宅経路に影響 ▼ ◼ Tool Router： Weather ✓ Road ✓ ▼ Rail ✓ Shelter ✓ ◼ 根拠： 南口低地道路の冠水リスク 道路情報 鉄道状況 待機場所候補 ▼ ◼ AIMO： 北口側経由を確認 解釈： ◼ FASTALERT Topicによって必要となる外部情報が異なることが確認されている AIMOでは「全情報を常時取得する」固定パイプラインではなく、イベントに応じて取得先を切り替える構造を採用 ◼ FASTALERT提供データは投稿8,928件、Topic 4,141件を含み、位置・画像・事象等を外部データ接続へ利用できる 125

Prototype implementation Prototype implementation4 「安全判断」は共通、「伝え方」は利用者ごとに変える 関わり方診断は、安全な行動そのものを利用者の好みで変更するためではない。安全候補を決定した後、その行動をど の程度詳しく説明するか、比較を見せるか、強く勧めるか、協力提案を行うかを調整するために利用する。 Safety Gate 生成してから、安全確認して、初めて届ける 「安全判断」は共通、 「伝え方」は利用者ごとに変える AIMOでは行動提案を一つ生成してそのまま利用者へ表示す るのではなく、複数の候補を作成した後、安全性と根拠の十 分性を確認する。危険候補は棄却し、根拠不足時は再検索へ 戻すことで、防災用途に必要なFail-safe構造を持たせる。 大学生A 根拠 89|見守 84|比較 78|後押 27 ▼AIMO生成 【生成AIMO特性】： 根拠多め/比較あり/判断余地を残す ◼ 候補者A 通常経路で駅南口へ向かう/冠水リスクあり BLOCK ■候補者B 北口側経由を確認する/冠水区域を回避できる可能性 PASS AIMO「いつもの駅南口経由は避けた方がよさそう。北 口側経由と10分待機の2案があるよ。今は北口側を確認 する方が安全そう。理由も見る？」 ■候補者 C 10分待機して再確認/情報増加局面で有効 PASS 同条件：危険度/安全候補/根拠 異なる条件：説明量/比較量/距離感/後押し/協力 ■Safety Gate条件 危険地点への誘導？ BLOCK 根拠が不足？ RE-QUERY 公式情報と矛盾？ RE-QUERY / BLOCK 位置共有に同意がない？ BLOCK 社会人B 整理サポート 80|行動後押し 87|協力調整 79 ▼AIMO生成 【生成AIMO特性】：結論を先に/行動を短く提示/ 協力提案 AIMO「今日は南口を避けよう。まず北口側へ移動 して、家族に帰宅経路を共有しよう。」 126

Prototype implementation Prototype implementation5 一度の通知で終わらず、状況変化に応じて「次の一手」を更新 災害情報、交通情報、現在地は数分単位で変化する。そのためAIMOでは最初の行動提案を最終回答とせず、実行後に FASTALERT・外部情報を再取得して状態を更新し、次の行動を再計算するClosed-loop型支援を採用する。 一度の通知で終わらず、 状況変化に応じて「次の一手」を更新 AIMOの中核変換ロジックはMVP実装、 実API・チーム・思い出機能を次段階で接続 災害情報、交通情報、現在地は数分単位で変化する。その ためAIMOでは最初の行動提案を最終回答とせず、実行後 にFASTALERT・外部情報を再取得して状態を更新し、次 の行動を再計算するClosed-loop型支援を採用する。 プロトタイプ段階で最も重要な「FASTALERTから安全な一行動まで」の 中核パイプラインを先に実装した。一方、外部情報はMock、家族チーム 同期や写真・思い出記憶はUI・設計段階であり、予選段階では実装済み 機能と今後実装する機能を明確に区別する。 18:12： FASTALERT：浸水・冠水投稿増加 ■実装済み ✓ FASTALERT CSV入力 ✓ Event Parser ✓ Context Matcher ✓ Tool Router ✓ Action Planner ✓ Safety Gate ✓ 8軸Personalization ✓ Closed-loopルール AIMO：「まず北口側を確認しよう」 18:22：RE-QUERY FASTALERT：道路/鉄道 状況悪化 「駅へ向かわず、今いる場所で待とう」 状況安定 「北口側経由で移動を続けよう」 再取得へ 実装済 • 再取得タイミングの設定 • 悪化時・安定時の次行動ルール生成 次段階 • 実APIから10分後データを自動取得 • 状態変化に応じた完全自動再実行 ■MOCK / 一部実装 △ Weather △ Road △ Rail △ Shelter デモ用Mock JSON ■実装予定 ○ FASTALERT MCP ○ 実外部API ○ チーム同期 ○ 写真・思い出記憶 ○ キャラクター成長 ○ 実端末Push通知 127

Prototype implementation Prototype implementation6 「安全判断」は共通、「伝え方」は利用者ごとに変える 関わり方診断は、安全な行動そのものを利用者の好みで変更するためではない。安全候補を決定した後、その行動をど の程度詳しく説明するか、比較を見せるか、強く勧めるか、協力提案を行うかを調整するために利用する。 工学的性能評価 応答時間 複数データを逐次取得するより、並列取得で応答時間を短縮 ■結果： 逐次処理：Median 2.49秒|P95 3.27秒 並列取得：Median 1.91秒|P95 2.65秒 ■解釈： FASTALERT、気象、交通、生活文脈を順番に取得すると待ち 時間が累積するため、実装では独立取得可能な情報を並列化 し、取得後にEvidence Integratorで統合する方式を採用 障害耐性 一つの情報源が停止しても判断不能にならない冗長構造を採用 ■解釈： 防災用途で「FASTALERTが取得できなければ何も答え られない」という単一点障害を避ける必要 複数の公式・補助情報を組み合わせ、利用可能な根拠 が残る設計 仮定した可用性条件下のMonte Carlo設計評価 128

Prototype implementation Prototype implementation7 総括 関わり方診断は、安全な行動そのものを利用者の好みで変更するためではない。安全候補を決定した後、その行動をど の程度詳しく説明するか、比較を見せるか、強く勧めるか、協力提案を行うかを調整するために利用する。 再取得 「分析できるAIMO」から「実際に動くAIMO」へ 固定ポーリングではなく、イベント駆動＋適応的再照会で応 答性とAPI負荷を両立 FASTALERT実データを入力し、災害状態の構造化、利用者文脈 照合、必要情報の選択、行動候補生成、安全確認、関わり方個 人化、再照会ルール生成までを一気通貫で実行 AIMOの中核価値である「災害情報→今できる一つの行動」の 変換が、概念図だけでなくMVPとして実装可能であることを示 した FASTALERT → Event Parser → Context Matcher → Tool Router → Safety Gate → Personalization → 行動 ■実験(予選資料提出時) 実装予定：FASTALERT MCP 実装予定：実API 一部実装：端末位置 実装予定：家族同期 実装予定： Push通知 検証予定：ユーザ実験 検証予定：安全テスト ■実装：自治体/企業福利厚生/交通・防災サービス ■結果： 固定5分：平均検知遅延 約2.5分 12回/h 固定15分：約7.5分4回/h イベント駆動＋適応型：約0.72分 2.4回/h ■解釈： すべての情報を高頻度で定期取得するのではなく、FASTALERT の投稿増加や危険度上昇をトリガーに再取得頻度を上げることで、 API負荷を抑えながら変化を早く捉える設計とする ◼ AIMO： 「災害情報を表示するアプリ」ではない 日常で知った“いつものあなた”に、非常時の “今できる一歩”を届ける 安全な行動内容は変えない。変えるのは伝え方。 129

Prototype implementation Prototype implementation8 要点整理 ■プロトタイプで検証する体験 関わり方診断・キャラクター誕生・日常会話から、 予定確認・思い出記録・家族共有、 災害通知・チーム支援までを一連の体験として設計 ■目的 機能を並べることではなく、 日常利用を通して利用者理解を深め、 災害時にその理解を行動支援へつなげられることを示す。 ■特徴 AIMOは「日常」と「災害時」を切り離さない。 日常の関わりが、もしもの行動支援につながる一つの体験として設計。 そして下に小さく、 ※実装状況は予選資料提出時点。実装済／Mock・一部実装／実装・検証予定を区別して表記。 130

Creating Shared Value

Creating Shared Value Creating Shared Value 1-1 シミュレーション設計について 目的：AIMOの導入条件を数量化し、3つの視点からシミュレーションを実施 ①事業収支シミュレーション ②モンテカルロシミュレーション 感度分析 ・売上 ・費用 ・営業利益 ・NPV/投資回収期間 ・契約数 ・利用者成長率 ・運用費等の不確実性 ③ 仮想利用者 エージェントシミュレーション ・AIMO型個別支援 ・一律通知との比較 本章で示す数値は、実績値、市場調査から得られた需要予測、実利用者を対象とした因果効果の推定値ではない。 提案の実現可能性を過大に主張せず、どの条件を実証段階で確認すべきかを定量的に示す AIMOが解決する事実上の課題 ー従来の利用者側の負担ー 気象警報 自治体情報 FASTALERT 交通情報 家族からの連絡 今すぐ移動するか 現在地で待機するべきか どの道や駅を避けるべきか 子供の迎えを誰が担当するか 家族へ何を伝えるべきか AIMOが提供する価値 〇情報の統合・整理 〇生活文脈への変換 〇家族調整負荷の軽減 何分後に状況を再確認するべきか 132

Creating Shared Value Creating Shared Value 1-2 AIMOの導入モデルと提案価値 AIMOでは、実際にサービスを利用する人と、導入費用を負担する主体が一致しない 個人課金だけに依存せず、B2B2C型を中心に据える 導入主体 主な利用者 導入全体への価値 利用者への価値 自治体 住民・世帯 防災情報を行動へ接続 地域情報を自分の 生活へ変換 企業 従業員 BCP、早期退勤 安否確認 通勤・家庭を含む 判断支援 保険会社 契約者 予防行動、損害抑制 被害前後の個別支援 交通事業者 乗客 運行情報の活用促進 代替行動の具体化 子育て 支援事業者 子育て世帯 送迎・家族支援の付加価値 家族内の役割調整 個人 本人・家族 ー 思い出、家族共有、 高度個別化 災害時の基本支援を無料または低価格で広く提供しながら、組織契約によって運用費を確保 133

Creating Shared Value Creating Shared Value 1-3 ① 情報の取得 AIMOが提供する5つの価値 ② 生活影響への変換 ③意思決定支援 → FASTALERT、気象 交通、河川、 自治体情報を取得する 「駅前で冠水している」 ↓ 「17時の迎えに使う 経路で冠水を確認」 待機、迂回、早期移動 担当変更等の複数候補を 整理 ④行動開始支援 ⑤平常時からの関係継続 複数の支持を一括提示 すぐに実行できる 「次の一手」を一見提示 会話、思い出、家族機能 天気に応じた生活支援により 平常時にも利用理由を形成 AIMOの差別化は、防災情報の件数ではなく、 情報を生活行動へ変換し、その支援を日常的な関係の中で継続すること 134

Creating Shared Value AIMOの事業モデルと収益構造 Creating Shared Value 1-4 AIMOの収益構造は、次の4本柱で構成する ・自治体向け地域導入 ・個人・家族向けプレミアム機能 ・企業向け福利厚生・BCP支援 ・保険会社交通事業者等へのAPI連携 想定料金の詳細 プラン 仮定料金 主な内容 個人基本 無料 基本診断、災害情報、次の一手 個人プレミアム 月額480円 思い出拡張、複数地域、長期履歴 ファミリー 月額980円 最大5人、送迎・役割調整 企業 一人当たり月額200円 通勤、BCP、安否確認 自治体 年額800万円を基本仮定 地域連携、住民提供、管理画面 API・保険連携 API、契約者向け提供 ※これらは確定価格ではなく、収支構造を評価するための仮定値である。 災害時には広告は表示せず、商業上の契約関係によって推奨経路や支援順位を変更しない 安全性と収益性が衝突した場合は、安全性を優先 135

Creating Shared Value Creating Shared Value 1-5 事業シミュレーションの前提条件 項目 基本仮定 初期投資 4,500万円 初年度自治体契約 2件 自治体年間単価 800万円 初年度企業契約 8社 1社あたり利用者 500人 企業利用料 1人月額200円 初年度有料会員 3,000人 個人利用料 月額480円 初年度API契約 1件 初年度固定費運用費 5,500万円 変動費 月額95円/アクティブ利用者 割引率 ８％ 評価期間 5年間 自治体導入地域の全住民が アクティブ利用者になると 仮定せず、初期段階の 有効利用率を12％とした。 自治体,企業,個人,APIで 異なる成長率を設定し、 固定費も事業拡大に伴い 増加する構造とした 136

Creating Shared Value Creating Shared Value 2-1 図 5年間の収益性シミュレーション 基本シナリオにおける5年間の売上構成と営業利益 シナリオのポイント ・初年度および第2年度は営業赤字となり、 第3年度に営業利益が概ね黒字へ転換した。 ・第4年度以降は、自治体契約・企業契約 個人プレミアム利用者の拡大により 利益が増加した。 ・特に、第4年度から第5年度にかけて、 個人プレミアム売上比率が大きくなる。 ※本図は提案条件に基づく過程シミュレーションであり、実績値・市場予測値・因果効果の推定値ではない。 ただし、個人課金だけに依存するのではなく 自治体・企業契約が事業基盤を支え、 その後に個人利用が拡大する構造である。 [AIMO事業化への方向性] 初めから大量の個人利用者獲得＜自治体実証と企業導入による利用者基盤を形成 個人・家族向けの継続利用へ接続 売上規模だけでなく、初期2年間の赤字を支える資本確保が必要となる 137

Creating Shared Value Creating Shared Value 2-2 事業リスク評価 基本シナリオだけでは、契約獲得や利用者成長が想定通りに進むことを前提としてしまう。 そこで、次の要因を確率的に変動させ、10,000回のモンテカルロシミュレーションを行った。 変動させる要因 図 ・初期投資額/初年度自治体契約数/自治体契約成長率/自治体単価 ・企業契約数/企業契約成長率/有料会員数/有料会員成長率/固定運用費/変動費/アクティブ利用率 ・各事業の利益率 5年NPVのモンテカルロ分布(10,000回) この結果は、AIMOが無条件に 黒字化できることを意味しない。 基本条件下の可能性が過半数を上回る一方 契約獲得や有料会員成長率が 弱い場合には大きな損失が生じ得る。 事業開始時には次の対応が必要となる 中央値(50％) 10パーセントタイル 90パーセントタイル 約2,689万円 約－1億769万円 約2億691万円 ・機能を限定したMVPでの初期投資抑制 ・自治体または企業との実証契約を 先に獲得する ・有料会員の継続率を早期に検証する ・災害時の生成AI利用費を監視する ・契約数が基準を下回る場合の縮小条件 の設計 モンテカルロ分析を入れることにより、単一の楽観シナリオではなく、事業リスクを含めた現実可能性を提示できる 138

Creating Shared Value Creating Shared Value 2-2 各仮定を単独で±20％させた場合に、 5年間のNPVがどの程度変化するかを示したもの 事業リスク評価 図 主要仮定の感度分析 主な示唆 最も大きな影響は「有料会員の成長率」。 固定運用費、自治体契約成長率、と続く順位が見られた 単に、自治体契約数を増やすだけではなく 平常時にも、利用を継続する個人・家族の形成が鍵。 日常会話、思い出、家族チーム、キャラクター育成は、 利用継続率を有料転換率を通じて、事業性に直結する。 固定運用費の影響も大きい。 段階導入(対象地域・機能の限定→拡大)が適切 初年度自治体契約数と初期年度有料会員登録数を変化させ、 5年間のNPVを算出した結果 事業初期の営業戦略(推奨順位) ①自治体・企業との限定実証を獲得する 図 自治体契約数と初年度有料会員数による損益分岐面 自治体契約が多いほど、 必要な有料会員数は少なくて済む 自治体契約が少ないほど、 多くの有料会員が必要 ②実証対象者へAIMOを提供する ③平常時利用と災害時行動を検証する ④家族単位の継続利用へ接続する ⑤地域導入と個人プレミアムを並行拡大 NPV=0になる損益分岐条件 B2G・B2B契約は売上源であると同時に、 利用者獲得経路としても機能する 139

Creating Shared Value Creating Shared Value 2-3 支援効果の検証 エージェントシミュレーションによる行動支援効果 AIMOの事業価値は、売上だけでは判断できない。 自治体・企業・保険会社が導入費を負担するには、 一律通知よりも具体的な行動改善が期待できる必要がある。 図 仮想利用者5,000人による支援方式比較 そこで、緊急度・情報過多傾向・家族調整負荷・自己効力感が 異なる仮想利用者5,000人を生成し、次の2条件を比較した。 〇一律通知条件 〇AIMO型個別支援条件 AIMO条件では、生活影響の整理、関わり方への適合、 次の一手の一件提示、家族役割の明確化が行われると仮定 平均行動開始時間 一律通知の約24.1分からAIMOの約12.8分へ短縮 提案受容率 約37.3％から約65.7％へ上昇 家族確認完了率 約42.2％から約72.4％へ上昇 表〇 指標 一律通知 AIMO 平均行動開始時間(分) 24.1 12.8 提案受容率(％) 37.3 65.7 家族確認完了率(％) 42.2 72.4 本図の意義は、AIMOが将来検証すべき主要評価指標を明確にした点にある 実証実験では、同シナリオで一律通知とAIMOを比較し、行動開始時間、受容率、家族確認率を測定 140

Creating Shared Value Creating Shared Value 2-4 継続利用と投資回収シミュレーション 平常時価値を組み込んだ継続率シミュレーション 防災アプリの事業上の課題として、平常時に利用されにくい点が挙げられる。 必要な時に通知設定が無効化されていたり、アプリが削除されていたりすれば高度な災害分析を実装しても価値を提供できない。 図〇平常時利用と継続率シミュレーション AIMOが平常時提供する利用価値 AIMOでは日常機能によって 離脱率が緩やかになるという仮説を 指数減衰モデルで表現 日常会話 思い出記録 AIMOの お世話 家族予定 天気に応じた 生活支援 AIMOの 成長 実証段階で検証する指標 ・7日継続率 ・30日継続率 ・90日継続率 ・思い出保存率 家族友人との チーム機能 ・会話利用率 ・家族チーム登録率 ・通知設定維持率 ・有料機能への転換率 キャッシュフローと投資回収期間 図〇 累積キャッシュフローと投資回収 基本シナリオでは、初期投資4,500万円を含む累積キャッシュフローは 第4年度まで負のままであり、第5年度に正へ転換した。 AIMOは短期間で大きな利益を得るサービスではなく、 初期実証と利用者基盤形成を経て回収する中期事業として捉える 必要がある 第１年度～第3年度にかけて、次の資金源を組み合わせる 研究助成 自治体 実証事業費 企業との 共同研究 保険会社との シード投資 技術パートナー 実証契約 による開発協力 第３年度で、契約数・利用継続率・行動改善効果が基準を満たさない場合、 機能や地域を拡大せず、収益性の高い導入対象へ集中する判断が必要である。 141

Creating Shared Value Creating Shared Value 2-5 行動変容による社会的価値の可視化 情報調達から社会効果までの構造 災害情報は、利用者へ届いただけでは社会的効果を生まない。情報が理解され、提案が受容され、行動が開始され、 最初の一手が完了し、家族やチームの確認が完了することで初めて生活上の安全へ接続する。 図 情報到達から家族確認までの社会効果パス 一律通知と比較して、 AIMOは特に「提案受容」と「家 族確認完了」の段階で差が生じ る設計となっている。 AIMOの価値が情報到達率でなく、 その後の行動変換率にあること を示している。 自治体や企業へ提出する導入成果も、通知配信数やアプリ起動数だけで評価してはならない。 次の行動指標を中心とする必要がある。 142

Creating Shared Value Creating Shared Value 3-1 社会実装にむけた事業戦略 シミュレーション結果から導く事業戦略 個人課金より先に 組織実証を獲得する ・損益分析から、自治体・企業契約は売上だけではなく 平常時継続を 最重要KPIとする ・感度分析では有料会員成長率の影響が最大であった。 固定運用費を 段階的に増やす 初期利用者の獲得と実証機会を提供する ・初期営業でが、自治体・企業、保険会社を優先する ・思い出/会話/家族機能を施策の周辺要素ではなく、 事業継続性を支える中核機能として評価する ・固定運用費がNPVへ大きく影響したため、初期段階では 対象地域/データ連携先/有人サポート時間を限定する 行動効果を導入価値 として販売する ・自治体・企業への提案では、情報配信機能ではなく、 不確実性を前提に 撤退・縮小条件を設定 ・NPVが正となる確率は約59％であり、成功は保証されてない 行動開始時間、家族確認率、危険経路回避率の改善可能性を 価値として示す。 ・実証結果が基づいて拡大・継続・縮小を判断する ステージゲート方式を採用 143

Creating Shared Value 段階的な社会実装ロードマップ Creating Shared Value 3-2 段階的な社会実証計画 Phase0 Phase1 Phase2 Phase３ 技術実証 小規模利用実験 地域限定実証 企業・保険連携 対象： 対象： ・過去 FASTALERTCSV ・豪雨３シナリオ ・3ペルソナ ・関わり方診断 ・次の一手 ・根拠表示 ・再照会 ・50～100人 ・大学生 ・若手社員 ・子育て世帯 対象： 評価： 主な検証： 実装動作 データから 施策への接続 審査員が理解できる 操作性 ・１自治体 ・500～2,000人 ・豪雨リスクのある地域 主な検証： 早期退勤 通勤経路変更 安否確認時間 家族調整 BCP改善 契約更新意向 Phase４ 一律通知とAIMOの比較 行動開始時間 提案受容率 自己決定権 押し付け感 30日継続率 主な検証： リアルタイムデータ の接続 地域別生活影響 家族確認 運用負荷 1人あたり運用費 複数地域展開 対象： ・都市型豪雨 ・河川地域 ・地下空間 ・積雪地域 ・観光地域 144

Creating Shared Value KPI設計と事業リスク対策 Creating Shared Value 3-3 KPIとステージゲート 領域 KPI例 ステージゲートの例 技術 危険な提案件数、根拠表示率、再照会成功率 行動 行動開始時間、一手完了率、家族確認率 UX 自己決定率、押し付け感、情報過多感 行動開始時間：一律通知より20％以上短縮 継続 30日継続率、通知設定維持率 提案受容率：一律より15ポイント以上改善 事業 1人当たり運用率、契約更新意向、有料転換率 30日継続率：40％以上 安全 公式情報との矛盾、未同意共有、誤誘導件数 自治体・企業の継続導入意向：60％以上 危険な提案：0件 公式情報との重大な矛盾：0件 事業リスクとその対策 単一投稿で危険を断定せず、複数一致、鮮度、公式情報との整合を評価 生成AIには安全性を判断させず、許可済み候補の表現候補の表現生成のみ担当 誤情報・誤誘導 ： 通知疲れ ： 生活に影響しない通知を抑制し、見守り距離の診断、時間帯、予定、 開封傾向に基づいて頻度を調整 個人情報への不安 ： 企業・自治体の管理者へ、個人の詳細位置や思い出を提供しない 災害時のアクセス集中 ： テキスト中心の軽量モード、キャッシュ、自動スケールを使用 収益性と公共性の衝突 ： 端末内処理、分離保存、最小権限、目的別同意、訂正・削除を実装 地域共通の事象分析と個人別影響照合を分離し、共通分析結果を再利用 安全上必要な基本機能は無料 災害時広告を禁止し、商業契約が推奨順位へ影響しない構造とする 145

Creating Shared Value Creating Shared Value 4 審査観点 本章で示した提案の総合評価 第9章で示した内容 データ活用 FASTALERT投稿、気象、交通、施設データ、 生活ログを統合し、事業条件」と利用行動を数値化 高度分析 モンテカルロシミュレーション、感度分析、損益分岐分析 エージェントシミュレーションで効果とリスクを検証 新規性 日常の関係性と行動傾向を「関わり方診断」で捉え、 非常時の意思決定と行動を個別最適化して支援 実現可能性 初期投資、運用費、収益モデルを明示 Phase0～4の段階導入と投資回収計画を提示 継続性 平常時の便利さ・安心の積み上げが、継続率と非常時の信頼につな がる設計と評価指標を提示 事業性 B2G(自治体)・B2B(企業・保険)・B2C(個人)API連携の 複合モデルで多層的な収益を確保 社会的価値 安全性 検証可能性 情報の到達だけでなく「理解→行動開始→行動完了→家族共有」ま でを評価し、被害の最小化と行動の質を向上 複数一致・鮮度・公式情報との整合を確認 プライバシー保護、生成AIの安全な活用で誤誘導を防止 KPI(技術・行動・継続・UX・事業・安全)とステージゲートを明示 し、段階ごとに検証・改善を繰り返す設計 146

Creating Shared Value 本章まとめ Creating Shared Value 5 基本シナリオ(5年間) モンテカルロシミュレーション NPVが正となる割合は 営業利益は第３年度に黒字化 約59％であり、事業成果には 累積キャッシュフローは 第5年度に正へ転換 大きな不確実性が存在 全国規模での一括展開ではなく 5年間のNPVは約2,981万円 段階的な社会実装が適切 エージェントシミュレーション 一律通知と比較して 改善の可能性を確認 感度分析の結果 有料会員成長率 固定運用費 避難行動 開始時間 提案受容率 家族確認 完了率 ※実測効果ではなく 今後の利用実験で 検証すべき仮説 平常時の会話・思い出・家族機能は、 利用継続と収益性を支える中核である AIMOの実現可能性は、次の循環に基づく AIMOは、日常と非常時につなぎ、人の行動を変え、 その成果を再び日常の関係と社会のレジリエンスへ還元する事業 147

Creating Shared Value Creating Shared Value 6 要点整理 ■設計内容 AIMOはB2Cだけではなく ・自治体・企業・保険会社・API連携を組み合わせたB2B2Cモデルとして設計した ■定量シミュレーション 定量シミュレーションでは ・第3年度で営業利益黒字化・第5年度で累積キャッシュフロー黒字化・NPVは約2,981万円 となった一方、 全国一斉導入ではなく、段階的な社会実装が適切であることも確認された 平常時の ・会話・思い出・家族共有が 利用継続と収益性を支える重要な価値であることが示された ■AIMO接続 AIMOは社会課題の解決と持続可能な事業性を両立する防災AIサービスである 148

Summary 149

References 【行政・公的資料】 気象庁（2026）「大雨や猛暑日など（極端現象）のこれまでの変化」 https://www.data.jma.go.jp/cpdinfo/extreme/extreme_p.html 国立社会保障・人口問題研究所（2024）『日本の世帯数の将来推計（全国推計）―令和6（2024）年推計―』 https://www.ipss.go.jp/pp-ajsetai/j/HPRJ2024/hprj2024_gaiyo_20240412.pdf National Academies of Sciences, Engineering, and Medicine. (2018). Emergency Alert and Warning Systems: Current Knowledge and Future Research Directions. Washington, DC: The National Academies Press. https://doi.org/10.17226/24935 https://www.nationalacademies.org/read/24935/chapter/ 【学術論文】 Nogami, T. (2022). Factors Affecting Behaviors that Precede Evacuation at the Onset of a Heavy Rainstorm in Japan. International Journal of Disaster Risk Science, 13, 903–912. https://doi.org/10.1007/s13753-022-00452-z Carlson, E. J., et al. (2024). Do 360-Character Wireless Emergency Alert Messages Work Better than 90-Character Messages? Testing the Risk Communication Consensus. Journal of Contingencies and Crisis Management, 32. https://doi.org/10.1111/1468-5973.12587 https://pmc.ncbi.nlm.nih.gov/articles/PMC11424238/ Imran, M., Castillo, C., Diaz, F., & Vieweg, S. (2015). Processing Social Media Messages in Mass Emergency: A Survey. ACM Computing Surveys, 47(4), Article 67. https://doi.org/10.1145/2771588 https://arxiv.org/abs/1407.7071 Carlson, J. M., Alderson, D. L., Stromberg, S. P., Bassett, D. S., Craparo, E. M., Gutierrez-Villarreal, F., & Otani, T. (2013). Measuring and Modeling Behavioral Decision Dynamics in Collective Evacuation. PLoS ONE, 9(2), e87380. https://doi.org/10.1371/journal.pone.0087380 https://arxiv.org/abs/1304.4704 【報道資料】 Reuters. (2024, September 23). Record rains in Japan's quake-stricken Noto region kill at least one. https://www.reuters.com/world/asia-pacific/torrential-rain-japan-floods-quake-stricken-noto-region-2024-09-21/ Sugiyama, S., & Takenaka, K. (2024, August 29). Typhoon Shanshan pummels Japan; millions told to evacuate. Reuters. https://www.reuters.com/world/asia-pacific/japan-hit-by-heavy-rain-power-outage-typhoon-shanshan-makes-landfall-2024-08-29/ 150

• https://www.data.jma.go.jp/cpdinfo/extreme/extreme_p.html
• https://www.ipss.go.jp/pp-ajsetai/j/HPRJ2024/hprj2024_gaiyo_20240412.pdf
• https://doi.org/10.17226/24935
• https://www.nationalacademies.org/read/24935/chapter/
• https://doi.org/10.1007/s13753-022-00452-z
• https://doi.org/10.1111/1468-5973.12587
• https://pmc.ncbi.nlm.nih.gov/articles/PMC11424238/
• https://doi.org/10.1145/2771588
• https://arxiv.org/abs/1407.7071
• https://doi.org/10.1371/journal.pone.0087380
• https://arxiv.org/abs/1304.4704
• https://www.reuters.com/world/asia-pacific/torrential-rain-japan-floods-quake-stricken-noto-region-2024-09-21/
• https://www.reuters.com/world/asia-pacific/japan-hit-by-heavy-rain-power-outage-typhoon-shanshan-makes-landfall-2024-08-29/

Thank you for your attention. いつものあなたが、 もしものあなたを守る AIMO 日常理解を、災害時の行動支援へ AIMOは、災害時だけではなく、 日常から一人ひとりを理解し、「情報」から「行動」へ変える防災支援を実現する