緊急時情報統合ダッシュボード

キャッチコピー案

ターゲット像と痛み

30代会社員・佐藤さん。熊本地震で被災。スマートフォンは持っているがバッテリーは残り20%。自宅が倒壊し、避難所か友人宅か決めあぐねている。通信は細い3G/LTE。Xは情報が多すぎて何が本当か分からない状態。『近くにバッテリー充電できる場所はないか』『募金はどこにすればいいか』という切実な情報ニーズがある。

• Xやニュースサイトは情報量が多すぎて、本当に必要な支援施設の場所が見つからず、スマートフォンのバッテリーを無駄に消費してしまう。
• 複数の企業やNPOが支援を表明しているが、どこの募金が信頼できるのか、どの無料Wi-Fiが使えるのか、公式情報が分散していて確認に時間がかかる。
• 通信が不安定な中で、重いWebサイトを読み込むのに数分待つ。近くの支援施設の位置情報を知るのに、複数のアプリやサイトを切り替えなければならない。

なぜ今(AI時代)か

AIコーディング時代だからこそ、リアルタイム情報統合ロジック・位置情報マッチング・公式データベース管理を短期開発で実装可能。従来なら大規模システムが必要だった『複数情報源の信頼度判定・フィルタリング・マッピング』をClaude/Cursorで数週間で構築できる。また、次の大規模災害は必ず来る(統計的確実性)。その時に『すぐに立ち上げられるスタンバイシステム』として自治体や支援団体に求められる。平時の準備こそが、有事の価値を最大化する。

MVPスコープ

• 公式支援情報データベース(募金・Wi-Fi・充電・交通)の管理画面。自治体職員が手動で情報を登録・更新できるシンプルなCRUD機能。初期は熊本地震のデータを手入力で用意。
• ユーザーの位置情報(GPS/手動入力)から、半径5km以内の支援施設を地図上に表示。施設名・住所・電話・営業状況をカードで表示。通信が不安定でも動作する軽量UI。
• 公式情報フィード(自治体HP・Yahoo!募金・KDDI公式など)をRSS/APIで自動取得し、SNS投稿は除外して時系列表示。デマ判定は管理者が手動でフラグ。

• ユーザーが『この施設は今も開いているか』を確認報告できるクラウドソーシング機能(チェックイン)。管理者が情報の鮮度を可視化。
• 支援施設の混雑度を簡易表示(混雑・通常・空き)。ユーザーの報告数で自動集計。

• AI自動デマ判定・言語処理 — 精度が必要だが、個人開発では責任が大きすぎる。管理者による手動フラグが安全。自動化は有料版以降。
• SNS連携(投稿の自動取得・分析) — Twitter/X APIの利用制限が厳しく、ノイズ除外ロジックが複雑。初期は『Xは使わない』を前提に設計。

マネタイズ(3案)

技術スタック(推奨)

FRONTEND

Next.js 14(App Router) + TypeScript。Leaflet.js or Google Maps API(地図表示)。Tailwind CSS(軽量UI)。PWA対応で、オフライン時も基本情報表示可能。

BACKEND

Node.js(Express) or Python(FastAPI)。RSS/API取得のスケジューラー(node-cron)。管理画面のCRUD API。

DATABASE

PostgreSQL(本体) + Redis(キャッシュ・リアルタイム更新)。地理情報クエリのため PostGIS 拡張を検討。

HOSTING

Vercel(フロント) + Railway or Render(バック)。初期は無料枠で、月1-2万円程度でスケール可能。

KEY APIS

Google Maps API(地図・ジオコーディング) - 月額50-100ドル程度 自治体・Yahoo!募金のRSS/公開API KDDI・Ankerなどの支援情報API(なければスクレイピング) Geolocation API(ブラウザ標準)

MONTHLY

初期段階: 2-3万円/月(Vercel無料枠+Railway $7+Google Maps $50-100+ドメイン)。ユーザー増加時: 5-8万円/月。

リスクと対策

類似サービス・差別化

初期ユーザー獲得プラン

個人開発向き度

【スコア3の理由】技術的には個人開発で実装可能(Next.js + PostgreSQL)だが、運用面での課題が大きい。①複数の公式情報ソース(自治体・企業)との継続的なAPI連携・仕様変更対応、②被災時のトラフィック急増対応、③情報検証・管理の人的負荷が増加する。特に『災害時に即座に起動する』という特性上、平時のメンテナンスと被災時の24時間運用体制が必須。個人では難しく、最低でも2-3人チーム推奨。ただしMVP段階なら1人で3-4週間で構築可能。