サービス企画書: どこカメ (Semantic Geo-Locator, Real-time Video Edition)
視覚情報 × オープンデータによる、次世代型・位置特定エンジン
- Version: 2.0 (Video Streaming Model)
- Date: 2025/12/06
- Infrastructure Strategy: Zero-Cost Cloud Prototyping（無料クラウド枠で成立する実装）
1. サービスコンセプト
「かざすだけで、視界がそのまま住所になる」
GPS精度が低下する環境（ビル街・屋内・山間部など）で、
通報者がスマホカメラを周囲に向けるだけで、
AIが映像をリアルタイム（準リアルタイム）に解析し、
数秒〜数十秒以内に「ここです」と言える座標・住所をピンポイントで特定する。
2. 解決する課題 (Pain Points)
GPSの限界
- 高層ビル群・屋内・山間部では、数十〜数百メートルの誤差が平常的に発生する。
- 「現在地を送る」ボタンだけでは、指令員が現場を特定できないケースが残る。
パニック時の伝達困難
- 「山と自販機しかない」「大きな道路のそば」など、
住所・目印が言語化できない状況での口頭説明は、通報者にも指令員にも大きな負担。 - 特に外国人観光客や土地勘のない人は、「今どこにいるか」を説明できない。
- 「山と自販機しかない」「大きな道路のそば」など、
静止画送信の心理的ハードル
- 「写真を撮って送る」という操作は、
緊急時の通報者にとって- 立ち止まる
- 撮影する
- 送信ボタンを押す
というステップが必要で、予想以上に心理的・操作的なハードルが高い。
- 「写真を撮って送る」という操作は、
3. ソリューション概要: リアルタイム・セマンティック解析
3.1 連続スキャニング (Continuous Scanning)
- ユーザーは「動画モード」でカメラを起動し、
そのまま周囲を見渡すだけ。 - システム側は、ブラウザから送られてくる映像ストリームを継続的に受信する。
3.2 準リアルタイム解析 (Quasi-Real-time Analysis)
無料インフラでの運用（Zero-Cost）を前提に、
全フレームではなく「間引きフレーム」を解析対象とするサンプリング方式を採用する。
OCR解析（高頻度 / 約 1.0 秒ごと）
- 電柱番号、店舗看板、ビル名、信号機名、標識など、
画面に映る文字情報を高速に抽出し続ける。 - ユーザー画面には、
- 「検出中：田中歯科…」
- 「検出中：ローソン…」
のように、検出されたテキストが1〜2秒遅延で次々とポップアップ表示される。
- 電柱番号、店舗看板、ビル名、信号機名、標識など、
VLMによる空間推論（低頻度 / 約 5.0 秒ごと、または条件トリガー時）
- Vision-Language Model (VLM) を用いて、
- 「コンビニの向かいにコインパーキング」
- 「右奥にガソリンスタンド、左にドラッグストア」
といったランドマーク間の位置関係を文章として抽出。
- このテキスト化された「風景の構造情報」をもとに、
位置特定ロジック（後述）を発火させる。
- Vision-Language Model (VLM) を用いて、
3.3 複合クエリによる位置特定
抽出されたテキストと空間情報を OpenStreetMap (OSM) へ照合する。
例: 検索ロジックのイメージ
- 「現在地から半径1km以内」かつ
- 「
田中歯科というテキストを持つ POI が存在」し- その 30m 以内に 「
ローソンが存在」する地点
→ この組み合わせ条件を満たす候補地点をスコアリングし、
最も尤度の高い座標を「推定位置」として採用。
4. システム構成とインフラ (Tech Stack)
Hugging Face Spaces を中核に、GPU不要・ゼロコスト運用を実現する構成。
| レイヤー | 役割 | 採用技術・仕様 |
|---|---|---|
| Frontend | 映像入力・UI | - WebRTC (Gradio streaming) によるブラウザ映像ストリーミング - スマホアプリ不要、SMSリンクからブラウザ起動だけで利用開始 |
| Infrastructure | 実行基盤 | - Hugging Face Spaces (Free Tier) - CPU: 2 vCPU / RAM: 16GB 程度 - ランニングコスト: 0円（PoC/小規模運用想定） |
| Edge Logic | フレーム制御 | - Sampling Middleware により、動画全フレームを処理せず、1〜2秒ごとにフレーム抽出 - CPU 負荷・APIコストを制御 |
| OCR Engine | 文字認識 | - PaddleOCR を Hugging Face 上でローカル実行 - 日本語・自然風景の看板文字に強いモデルを採用 |
| AI Brain | 空間理解 | - Gemini 2.5 Flash API (Free Tier) を利用（将来は他VLMへの差し替えも可能） - サンプリングした静止画を入力として、ランドマーク情報・位置関係をテキストとして構造化 |
| Map DB | 地図データ | - OpenStreetMap (Overpass API) - 無料でPOI情報やタグ検索が可能 - 「店舗名＋カテゴリ＋距離条件」による複合クエリで候補地点を絞り込み |
5. ユーザー体験フロー (UX)
アクセス
- 通報者へ SMS などで URL を送信。
- 通報者が URL をタップするとブラウザが起動し、
カメラ使用の許可ダイアログが表示される。
スキャン
- 画面の案内: 「カメラを周囲に向けて、ゆっくり一周してください。」
- 通報者はその場でスマホを回転させるだけでよく、
写真撮影や送信といった操作は一切不要。
フィードバック
- 画面上には、AIが検出した文字情報が1〜2秒程度のラグで順次ポップアップ。
- 例: 「検出中: 〇〇医院」「検出中: 消火栓」「検出中: LAWSON」など。
- これにより通報者に
- 「ちゃんと見てくれている」
- 「今の映像が役に立っている」
という安心感を与える。
- 画面上には、AIが検出した文字情報が1〜2秒程度のラグで順次ポップアップ。
位置特定
- OSM との照合が一定スコア以上になった時点で、
画面に以下のように表示：- 「場所を特定しました：〇〇市〇〇町3丁目 〇〇交差点付近」
- 同時に、この座標・テキスト情報が指令台システムへ送信される想定。
- OSM との照合が一定スコア以上になった時点で、
6. 競合優位性 (Differentiators)
導入・運用コストゼロに近い構成
- Google Maps API 等の従量課金サービスに依存せず、
OSS ＋ 無料枠クラウドで最小構成を実現。 - PoC〜小規模本番までは、自治体予算にほぼ影響を与えない形でスタート可能。
- Google Maps API 等の従量課金サービスに依存せず、
「動画」なのに軽い設計
- 通信は WebRTC による動画ストリーミングだが、
サーバ側の解析は間欠的なサンプリング方式。 - 全フレームを処理するリアルタイム動画解析と比べて、
CPUのみ＋低スペックでも成立する負荷設計。
- 通信は WebRTC による動画ストリーミングだが、
曖昧な状況に強いセマンティック位置特定
- 住所プレートが見えない場合でも、
- コンビニ＋駐車場
- ガソリンスタンド＋大型交差点
といったランドマーク構成・風景の“組み合わせ”から位置を推定。
- 文字情報だけに頼らず、
「風景の構造」×「オープンデータ」の掛け合わせ による位置特定が可能。
- 住所プレートが見えない場合でも、
7. 将来拡張性 (Future Extensions)
PLATEAU (3D都市モデル) との連携
- ビル群の「スカイライン（屋上形状・高さ分布）」を3D都市モデルと照合。
- 文字情報や店舗が乏しいエリアでも、
- 建物の輪郭
- 道路のパターン
- 遠景の山並み
などの幾何学的特徴から方角・位置を推定できるように拡張。
マルチモーダル連携
- 将来的には、音声（環境音・通話内容）も加味し、
- 「踏切の音」「救急車サイレンの反響」「川のせせらぎ」などを手がかりに
空間推論の精度をさらに高める余地がある。
- 「踏切の音」「救急車サイレンの反響」「川のせせらぎ」などを手がかりに
- 将来的には、音声（環境音・通話内容）も加味し、
End of Document