みちよみ 設計思想
ホワイトペーパー ・ 2026-08-28版。使い方は API wiki を参照してください。
1. 概要
みちよみは、市民が撮影・公開した街路画像(Mapillary)を視覚言語モデル(VLM)で構造化テキスト化し、「道の物理的状態」を座標で検索できるようにしたオープンデータ基盤です。東京都全域(23区・多摩・島しょ)・1,914,490シーンを処理済みで(検索対象1,914,451)、経年変化2,522件は反証裁定を通過したもののみを収録しています。全データはREST APIとMCPで認証不要・read-onlyで配信され、観測データは CC BY 4.0 で利用できます。
設計を貫く方針は一つです。生成の精度そのものよりも、来歴・検証・限界の明示を仕組みとして作り込むこと。生成AIの出力を引用に耐える公共データにするには、これが本質だと考えています。
2. 背景と課題
地図は「道の形」を持っていますが、「道の状態」は持っていません。白線の摩耗、歩道の幅、点字ブロックの有無、見通しを塞ぐもの、そしてそれらの経年変化。道路の大半を占める区市町村道では、こうした状態の把握は現地に行くしかないのが現状です。
素材は既にあります。Mapillaryには市民・事業者が撮影した街路画像が大量に公開されており、VLMはそれを読める水準に達しました。足りないのは、読んだ結果を信頼して引用できる形にする設計です。AIの説明文は流暢ですが、そのままでは事実と解釈の境界、データの由来、「写っていなかったもの」の扱いが曖昧になります。行政の点検優先付けや研究に使うには、この曖昧さを仕組みで解消する必要があります。
また、利用者は人間だけではありません。位置情報を扱うAIエージェントが「この場所はどう見えるか」を引ける基盤があれば、言語化データは対話・案内・分析の素材として広く使われます。そのためAPIは最初からAIエージェントを主要な利用者として設計しています。
3. 設計原則
実装は次の5原則から導いています。
3.1観測・計算・解釈を分離する
1つのシーンは3層に分けたまま配信します。観測された事実(撮影年・座標・方位などの撮影メタ)、決定論的に計算した特徴(進行方位・色解析。同じ入力なら必ず同じ値)、モデルの解釈(VLM言語化)です。3層は別の名前空間に置かれ、互いを上書きしません。
どこまでが事実で、どこからが解釈かを、読む側の注意力ではなくデータ構造で区別できるようにする——これが分離の目的です。監査可能性の前提になると同時に、相互検証の土台にもなります。たとえばVLMの「並木が続く」という記述と機械層の緑視率が一致すれば、記述の確からしさをデータの内部で確認できます。すべての記述は画像IDを介して元写真まで遡れます。
3.2正直性を仕様として実装する
言語化データで最も危険なのは、データが無い場所を「何もない場所」と誤読されることです。これを防ぐため、答えるより先に被覆を申告するcoverageエンドポイントを置き、MCPでは「まず被覆を確認してから中身を引く」という手順自体をツール定義に組み込みました。
- プロンプトは「なし/不明/画角外不明」の区別を強制する。写っていないものを推測で埋めさせない
- 撮影時刻は信用しない。真昼の写真が23時台になっている実例があったため、時間帯はVLMの視覚推定を正とする
- 撮影時刻異常の6シーンは検索対象から隔離し、隔離した事実と件数もAPIで公開する 注記(2026-10-03): release 2026-09-13-r1 では 39 シーン。
利用者向けのルール本体は API wiki「データを読むときの注意」に一本化しています。
正直性を仕様として扱うのは、仕様であれば「守られているか」を自動テストと整合検証で機械的に確認し続けられるからです。
3.3世代 — 生成の来歴を全件に記録する
言語化は生成物であり、モデルが変われば結果も変わります。そこで「どのモデル系列が・どの出力契約で・いつ生成したか」を世代(generation)として全1,914,490シーンに記録しています。
世代は品質の優劣ではなく、由来のラベルです。クラウドVLMによるgen1(77,676シーン)も、自宅GPUのローカルVLMによるgen2(1,836,814シーン。うち39シーンは撮影時刻異常で検索対象外)も配信対象として採用しています。ただし、ローカル世代には複数モデル・推論設定が含まれ、すべての条件間で判定基準が同一と検証されたものではありません。
この設計により、モデルの移行は「昇格」という運用イベントになります。新系列をexperimentalとして併走させ、ゲートに合格したら配信対象へ加える。過去の出力は捨てず、上書きもせず、来歴として保持する。gen1採用シーンにもローカルVLM版の言語化を保持しており、世代間比較に使えます。
3.4「変わった」という主張には反証裁定を課す
経年変化は、言語化の中で最も誤りやすい出力です。視点が数メートルずれたり季節が違ったりするだけで、変わっていないものが変わって見えます。そこで検出と収録の間に裁定を挟んでいます。
手順は次のとおりです。同一道路グループ・方位互換のペアだけを機械的に選び、VLMに二時点の差を記述させます。その後、文脈を分離した別セッションに「反証すること」を目標として再検証させ、反証に耐えた主張(supported)だけをAPIに収録します。現在3,618件。2026年10月に、撮影位置と向きが合う写真の組を選び直して比べ直し(GPT-6.1 Sol)、確かめ役にかけた3,025主張のうち2,963件が残りました。2026年8月版(gpt-5.6-sol)のうち確信度の高い主張(第1パス)は、新しい世代のモデルが同じ写真を見て判定し直し、両方で残った655件だけを収録しています。8月版の収録分2,522件のうち約2割は、この見直しで写真と合わないと分かったため外しました。裁定を通らなかった所見は収録していません。
3.5幾何はVLMに推測させず、決定論で計算する
「北東30mに消火栓」と言えるデータにしたい。しかし画像の中に北は写っていないので、VLMに方角を推測させるべきではありません。
そこで分業します。VLMには画面相対の位置だけを言わせ(「右手前に消火栓」)、進行方位は連続撮影の前後フレーム座標から幾何計算します。これをカメラ方位と合成して絶対8方位へ変換します。計算は決定論で、有効率99.7%です。 注記(2026-10-03): release 2026-09-13-r1 では 99.6%(/v1/meta の travel_bearing)。
同じ考え方で、瞬間のカウント(「歩行者3人」)はプロンプトの段階で書かせず、設備・構造・路面など時間に対して安定な対象だけを記述させています。書かせない項目を決めることが、データの寿命を延ばします。
4. アーキテクチャ
4.1言語化の4層
1枚の画像の説明だけでは、単独フレームでは原理的に解けない問題が残ります。そのため言語化を4層に分けています。
| 層 | 解く問題 |
|---|---|
| L1 点 — 1,914,490シーン | 1枚の物理状態。入力は画像のみで、地名・地図・過去出力など外部知識は一切与えない(独立性の担保) |
| L2 区間 — 連続フレーム約100m | オクルージョンの解消(次のフレームで看板が読める)、動いている物と置かれている物の判別、損傷の広がりの判別 |
| L3 時間 — 同一地点×別年 | 二時点の見え方の差の記述。検出後は反証裁定へ(原則3.4) |
| L4 文脈 — 公的データ結合 | 学校位置・用途地域などの公的データはVLMに見せず、データベース側で空間結合する。「AIが見たもの」と「地図上の事実」の責任分界を保つ |
L1に外部知識を与えないのは重要な決定です。画像だけから書かれた記述だからこそ、後から公的データと突き合わせたときに独立な情報源として機能します。
4.2リリースと配信
データは「作ったら即公開」ではなく、versionedなreleaseに固めてから公開します。素のSQLite→本番同構成のプレビュー→本番の3環境で、同一の96項目整合検証(件数突合・孤児レコード・座標範囲・重複・統計一致)を通してからpublishします。API実装には自動回帰テストがあります。公開後も全応答にrelease ID(snapshot)を同梱し、どの版への問い合わせだったかを後から再現できます。
配信はエッジ実行環境(Cloudflare Workers)+SQLiteベースの分散DB(D1の2シャード)です。 注記(2026-10-03): release 2026-09-13-r1 からは4シャード。認証不要・read-only・レート制限つきで、RESTとMCPが同じDB・同じ品質契約の上で動きます。運用手順には失敗から学んで固定した項目もあります。たとえば「import後は必ずANALYZE」。統計の欠落で位置検索の実行計画が崩れ、応答が数十秒に劣化する事象を実際に経験し、原因を特定して手順書に反映しました。
5. 品質保証と既知の限界
品質保証の柱は4つです。(1)世代の採用ゲート(回帰比較・較正検証)、(2)3環境×96項目の整合検証、(3)APIの自動回帰テスト、(4)経年変化の反証裁定。いずれも自己申告で終わらせず、機械的に再実行できる形にしています。
同時に、次の限界を明示しています。これらは脚注ではなく、API応答・ツール定義・公開文書に常設している契約の一部です。
| 限界 | 含意 |
|---|---|
| 記述は撮影年時点の推定 | 現況・安全性の判定ではない。幅員などの数値は単眼推定で、測量値ではない |
| 裁定は独立検証ではない | 同一モデル系列内の反証優先の再検証。系列に共通する誤差は残り得る |
| 被覆は撮影に依存する | 撮影されていない道はデータに存在しない。そのためcoverageによる被覆申告を先行させる |
| モデル・推論設定による判定差 | Qwen3.6と3.8で歩道の「なし」「画角外不明」の出現率に大きな差があります。処理対象も異なり、原因は未確定です。同一画像での比較評価前に、地域間・年別の単純比較へ使わないでください。 |
| 色系特徴は撮影条件の影響を受ける | 緑視率などは機種・時間帯の色かぶりを含む参考値。集計時は撮影条件で層別する前提 |
6. 運用モデル
みちよみは個人プロジェクトですが、イベント後も継続できる構成を選んでいます。
- 配信: エッジ+サーバレス構成のため、サーバー管理が発生しません。
- 生成: L1の主処理は自宅GPU上のローカルVLMです。初期L1とL2・L3・裁定にはクラウドモデルを使用しています。L2のローカル処理は検証段階です。
- 更新: データの追加はreleaseと世代の仕組みに載せるだけで、増分更新が定常運用になります。
APIを認証不要のまま開けているのは意図的な選択です。人でもAIエージェントでも、登録なしで「座標を投げれば道の状態が返ってくる」場所として使えることを優先しました。守りはレート制限とread-only設計で確保しています。
7. 今後の展望
本書時点の到達点は「東京都全域(23区・多摩・島しょ)・1,914,490シーン・経年変化3,618件」です。ここからの計画を時間軸で示します。
〜2026年8月末
2026年内
② データセットの一括配布。研究・分析用途向けに、Hugging Faceで公開Parquetスナップショットを配布しています(観測データは CC BY 4.0。出典・ライセンス)。APIとは更新時点が異なる場合があります。
③ 時間軸の拡充。同一区間の複数年被覆を活かした「道単位の変化」の可視化と、経年変化収録の対象拡大を進めます。
② 地域の拡張。パイプラインに東京固有の前提はありません。街路画像が公開されている都市であれば、同じ手順で言語化基盤を構築できます。
③ 更新の循環。市民が撮影した画像が言語化されて検索できるようになるまでのリードタイムを縮め、「撮影が増えるほど街の記述が新しくなる」循環の定常化を目指します。あわせて、歩行者向けのリアルタイム音声ガイドなど、ウェアラブル端末での利用形態も検証を進めます。
8. 結び
みちよみが示したいのは、個別の言語化の精度ではなく、生成AIの出力を公共データとして流通させるための設計です。三層分離、仕様化された正直性、来歴としての世代、反証裁定、決定論の分業。いずれも特定のモデルに依存しない、データ基盤側の規律です。
モデルは今後も入れ替わります。入れ替わっても壊れないデータ基盤を先に作ること。それがこのプロジェクトの中心です。