自動運転の高精度地図は、どこまで情報を減らせるか ― 作り込む派と持たない派の争点は、ゼロにできるか

ロボットアームにカメラを付けて、物を掴ませる実験を毎日やっている。カメラで見て、その場で判断して、掴む。地図もなければ、事前の座標表もない。

その延長で自動運転のドキュメンタリーを見ていて、ひとつ引っかかった。自動運転の車は、走る前に3次元の地図を持っていないといけないのか。もしそうなら、地図がある場所しか走れないことになる。

そこから始めた対話が、地図の維持費、市町村の紙の台帳、兼務ひとりの担当者、そして「機能を削る責任を誰が持つか」という話まで転がっていった。最後にはロボットアームに戻ってきた。その記録をそのまま残す。

対話のあと、出てきた主張を一件ずつ裏取りした。誤っていた箇所、誇張だった箇所も、直す前の発言を消さずに残す。考えが動いた過程のほうが記録として価値があるので。

出発点：3次元マップがある地域しか走れないのか

今の自動運転の技術って事前に3次元マップを入力しておく必要がある？（道路を正確に走るには3次元マップが揃っている地域だけ走れる？という理解で合っていますか？）

— ほぼ合っていますが、「今はもう二派に分かれている」というのが正確なところです。

HDマップ依存派（Waymo、Cruise、日本の高速道路レベル3など）

事前に作った高精度3次元マップに、LiDARで取得した今の点群を照合して自己位置を出す（ローカライゼーション）。だからマップ整備済みエリアしか走れない＝ODD（運行設計領域）がマップの範囲で決まる。Waymoが都市を1つずつ増やしていくのはこれが理由です。信号や車線の意味づけもマップ側に「事前知識」として持たせているので、精度と安全性は高いが、地図の維持更新コストがスケールの壁になる。

マップレス派（Tesla FSD、Wayve など）

カメラ映像から車線・信号・走行可能領域をその場で推論する。近年はEnd-to-End（映像→操作を一気通貫で学習）へ寄っていて、原理的にはマップなしでどこでも走る。ただし「その場の推論を間違えたら終わり」という冗長性の弱さがあり、信頼性の議論が続いています。

中間解

Mobileyeの REM のように、量産車のカメラから薄いマップ情報をクラウドソーシングして自動更新する方式。「作り込んだ地図」ではなく「勝手に育つ地図」で維持コストを下げる狙い。

なので理解の補正としては——

• 商用でレベル4を実際に走らせている領域は、ほぼマップ前提。「マップがある地域だけ」は事実に近い。

• ただし技術としてはマップ非依存が本命視されつつある。マップは「必須」ではなく「安全マージンを買う手段」に位置づけが移動中。

「精度より体験の成立を優先する。精度はあとからお金で解決できる」に照らすと、HDマップ派は逆に「お金で精度を先に買って体験を成立させた」側ですね。visual servoingでカメラだけで完結させようとしている今の方向は、構図としてはマップレス派に近い。

ここで自分のプロジェクトと構図が重なったのが、この対話を続けた理由になった。mechArm 270-Pi にやらせているのは、iPhoneのカメラで赤いブロックを見つけて、その場で関節角を決めて掴む、という動作。事前に「このブロックはここにある」という地図は持っていない。持っていないからこそ、ブロックを動かしても追える。一方で、外したときに参照する正解も持っていない。

マップレス派の弱点は精度ではなく、外したときに戻る場所がないこと

将来的にはマップレスが方向性としては良さそうだけど、安全面でどうしても不安が拭えてはいないという認識かな？

— その認識で合っています。ただ「不安」の正体を分解すると、対立軸はもう少し具体的です。

マップレス側の弱点は「精度」ではなく「保証」

カメラ推論の平均性能はもうHDマップ派に迫っている。問題はテールリスク——逆光、白線が消えた道、工事の変則規制。稀なケースで何が起きるか事前に言えない。HDマップは「ここは制限40、この先に一時停止がある」という事前知識が、推論が外れた時のフォールバックになる。冗長系を地図で買っている。

規制側の要求と噛み合わない

レベル4認可は「ODDをこう定義し、その範囲での安全性をこう証明する」という形式。マップ前提だと範囲が地図の縁で明確に切れるので証明しやすい。「どこでも走れます」は裏返すと「ODDの境界が定義できません」で、これは審査に通しづらい。マップレスの本当の壁は技術より、安全性の説明可能性です。

現実の落としどころ

たぶん二択にはならない。マップレスで走行能力を作り、Mobileyeの REM のような自動更新の薄い地図を保証レイヤーとして重ねる。地図の役割が「認識の主役」から「事前知識のセーフティネット」へ降格していく、という形が有力です。

visual servoing も同じ構図ですね。カメラだけで閉じるのは「その場で成立させる」設計だけど、失敗した時に戻る場所がない。ロボットアーム側にとっての「薄い地図」に当たるものが何なのかは、いずれ効いてくる論点だと思います。

平均性能ではなくテールリスク、という言い方が刺さった。ブロックを掴む実験でも、100回のうち95回は問題なく掴める。問題は残りの5回で、そこで何が起きているかを説明できるかどうかが、公開できる研究資産になるかどうかの分かれ目になっている。

二派は切磋琢磨しているのではなく、中央へ寄っている

両方の考えがあってお互いの方向から進めて切磋琢磨するって認識か。

— おおむねそうですが、「同じゴールに両側から掘り進むトンネル」というより、片方がもう片方に吸収されつつあるのが実態に近いです。

競争しているのは「どっちが正しいか」ではなく、どこで折り合うか。

• マップレス派は、走れるようになるほど「で、それをどう証明する？」に突き当たり、事前知識を足し始める

• マップ派は、エリアを増やすほど地図の維持費に潰され、認識側の自律性を上げざるを得ない

つまり両者は中央に向かって寄っている。切磋琢磨というより、収束です。

争点として残るのは「地図をどこまで薄くできるか」——ゼロにはならないが、作り込む地図ではなくなる。そこの見極めが各社の賭けどころになっています。

ここが対話の折り返し地点だった。「二派が競っている」という自分の見立てが外れて、「片方に吸収されつつある」に置き換わった。この記事のタイトルはここから出ている。

地図の維持費を誰が払うかは3通りしかない

マップ派は、エリアを増やすほど地図の維持費。確かにこれはずっと付きまとうね。道路は新しくなったり、変わったりするしその都度維持費を誰が負担すんの？みたいな話は付きまとうね。今は狭い範囲でやってるからいいけど。

— そこが本質的にきついのは、変更が予告なしに起きることなんですよね。工事の車線規制、仮設の信号、雪で消える白線。新設道路のような「わかっている変化」より、日々の一時的な変化のほうが厄介で、しかも頻度が桁違いに多い。

負担の話は、たぶん三つの解しかない。

1. 自社で抱える（Waymo型）

専用車両で走り回って更新。都市数が線形に増えるとコストも線形に増える。事業として重い。だからWaymoは「儲かる密度の都市」しか取らない。ODDが技術ではなく採算で決まる。

2. 走ってる車に払わせる（Mobileye REM型）

量産車のカメラが勝手に地図を更新する。台数が増えるほど鮮度が上がる。コストは車両価格に溶かして分散。ただし普及するまで機能しないニワトリタマゴ。

3. 公共インフラにする

道路管理者が地図を維持する。理屈は通る——道路標識を誰が塗り替えるかと同じ話だから。ただ日本で言えば国交省・県・市町村と管理主体が割れていて、全国で足並みを揃えるのは相当遠い。

現実的には2が本命で、3が部分的に混ざる。1はスケールしない、が答えになりつつあります。

指摘した「今は狭い範囲だからいい」がまさにポイントで、狭い範囲では1が成立してしまうから、問題が見えないまま実証が進む。維持費の壁が可視化されるのは、都市数が二桁に乗ってからです。

負担モデルを表にすると、こうなる。

観測はカメラが速い。事前情報は台帳しか持っていない

1は現実的じゃないね。導入時はいいけどどこかで路線変更するだろうね。そうはいっても2だけだときついから3とうまく組み合わせてやるみたいなイメージかな。

— イメージとしてはそうなると思います。ただ2と3は「足りない分を補い合う」というより、役割が違うと捉えたほうが実態に合います。

2が担うのは鮮度と網羅性

毎日走る車が拾うので、変化の検出は速いし漏れが少ない。ただし「観測しただけ」で、正しいかの保証はない。

3が担うのは権威と責任

道路管理者しか持てないのは、変化の事前情報です。工事の車線規制は、実は起きる前から許認可データとして存在している。誰かが観測して気づくより前に、公式に確定している。ここは2では絶対に埋まらない。

つまり境界は「観測 vs 台帳」。カメラが見つけた変化を、公式データが裏書きする。逆に公式データにあるのに観測されない変化は異常として検出できる。組み合わせると相互検証になるのが本当のうまみで、単なる補完ではないです。

日本の面倒は、その台帳が管理主体ごとにバラバラで、そもそもデジタル化されていない部分が多いこと。技術ではなく制度が律速になる典型ですね。

「2と3を組み合わせる」という自分の見立ても、ここで一度崩れた。補い合うのではなく、担当している情報の種類が違う。カメラは「起きたこと」しか見られない。台帳は「これから起きること」を持っている。工事の許認可データは、工事が始まる前から存在している——この一点が、対話全体で一番の発見だった。

省庁を横断する取りまとめ役より、市町村の入力負担のほうが壁になる

その台帳が管理主体ごとにバラバラで、そもそもデジタル化されていない部分。ここはいろんな省庁や管轄を横断できて動けるようなところが取りまとめていかないとだね。デジタル庁だけでできるかわからんけど。

— デジタル庁は仕様と横串は打てますが、道路データそのものの権限も予算も持っていないので、単独では無理です。実際の本命は国交省側で、素地はすでにあります。

xROAD（道路データプラットフォーム）とPLATEAU（3D都市モデル）。国交省は道路管理の当事者で、しかもデータ整備の予算枠を持っている。デジタル庁が「標準を決める」、国交省が「作って回す」という分担が現実的な形です。

ただ、本当の律速はそこじゃない。

道路延長のうち、約8割は市町村道です。国道は国が持つから整備は進む。県道もまだいい。詰まるのは市町村で、そもそも自前の道路台帳が紙、担当者が兼務ひとり、更新は年1回、という自治体が普通にある。ここに「3次元でデジタル化してAPIで出せ」と言っても、権限の問題ではなく単純に人がいない。

なので取りまとめ役の問題というより、「国が仕様と金と道具を出し、市町村は入力するだけ」まで負担を下げられるかという設計の問題です。号令だけかけると必ず自治体格差になって、結局「デジタル化済みの市町村だけ自動運転が走れる」——最初の話に戻ってしまう。

皮肉ですが、そこまで詰まると「じゃあ台帳を待たずにカメラで見るか」という圧力がまた強まる。マップレス派を後押ししているのは、案外この制度側の遅さかもしれません。

「デジタル庁が取りまとめれば」という自分の発想が、ここで否定された。権限がないという話ではなく、取りまとめても末端に人がいない、という話だった。組織図の上のほうを直しても、入力する手が増えるわけではない。

計測はもう解けている。詰まるのは職員が押す承認のほう

市町村で、そもそも自前の道路台帳が紙、担当者が兼務ひとり、更新は年1回、という自治体が普通にある。この辺をデジタル化するロボットが生まれてきたりするといいんだろうか？

— それ、すでに半分できているのがミソです。詰まっているのは別の場所にある。

計測はもう解けている

MMS（レーザー計測車）は昔からあるし、最近はスマホ映像から路面のひび割れや標識を判定するサービスが実用化していて、市町村への導入も進んでいます。ゴミ収集車や公用車にスマホを載せて走るだけ、というレベルまで来ている。技術としてのハードルは低い。

詰まるのは「台帳にする」ところ

道路台帳は行政の公式記録なので、更新するには誰かが責任を持って確定させる必要がある。カメラが「ここ変わってます」と出力しても、それを台帳に反映するのは職員の行政行為で、ここは自動化できない。兼務ひとりの担当者にとって、データが増えることは仕事が増えることでしかない。

つまりロボットが減らせるのは計測の手間で、詰まっているのは確認と決裁の手間。前者を自動化すると後者が増えるので、下手をすると逆効果になる。

だから効くとしたら「計測するロボット」ではなく、変化検出＋差分提示＋承認一発まで含めた仕組みですね。職員がやるのは「これでいい」を押すだけ、という形まで削れて初めて回る。

ここも精度の問題ではなく体験の成立の問題です。計測精度をいくら上げても、担当者の運用が成立しないと台帳は更新されない。

「デジタル化するロボットが生まれれば」という発想が、ここで一番きれいに裏返った。計測を自動化すると、確認すべきデータが増えて、担当者の仕事はむしろ増える。自動化が現場の負担を増やす、という構図が起きる。

自治体ごとのルールに触れない粒度まで、機能を削る

変化検出＋差分提示＋承認一発まで含めた仕組み。この辺は法律や市町村独自の固有ルールみたいなものが絡んで厄介そうだね。

— 厄介なのは確かですが、法律と固有ルールでは詰まり方が違うので分けたほうがいいです。

法律側は、実はそんなに障害じゃない

道路台帳は道路法28条で調製が義務づけられていて、記載事項も省令で決まっている。つまり標準はもともと国が持っている。だから「全国バラバラで統一できない」のは法制度の問題ではなく、実装の問題です。ここは意外と追い風。

厄介なのは固有ルールのほう

図面の様式、決裁の階層、どこまでを軽微な変更として扱うか——このへんは自治体ごとの慣行で、明文化すらされていないことが多い。「うちはこうやってきた」が仕様書に落ちていない。ここが本丸です。

ただ、これは自動化を諦める理由にはならなくて、設計の順番の話になります。判断は絶対に触らない。差分を提示するところまでで止める。「これは軽微か否か」に踏み込んだ瞬間、自治体ごとにカスタムが要って死ぬ。逆に「変わりました、旧と新はこれです」までなら、ルールに依存しないので全国共通で作れる。

要は、システムが自治体のルールを学習するのではなく、ルールに触らない粒度まで機能を削る。工場向けの仕様書を書いていた話と同じ構図ですね。相手の現場の慣行を全部飲み込もうとすると破綻するから、どこまでを規定してどこから先は現場に委ねるかの線引きが設計そのものになる。

機能を削る責任は、発注の時点で誰も持っていない

ルールに触らない粒度まで機能を削る。この辺はデザインの考え持っている人が必要だね。

— そうですね。ただ、ここで要るのは「UIを作る人」ではなく、どこまでを機能にしないかを決められる人です。

エンジニアは「できる」から作ってしまう。自治体側は「うちの事情も入れて」と言う。どちらも悪気なく機能を増やす方向に働くので、削る責任を持つ役割が構造的に空席になる。ここが埋まらないと、判断の自動化まで踏み込んで自治体ごとのカスタムで死ぬ、というルートを辿ります。

しかもこの線引きは、現場の運用が見えていないと引けない。「兼務ひとりの担当者が、どの画面でどこまでやれば仕事が終わるか」から逆算しないと、削る場所を間違える。デザインというより、体験から逆算する設計の話ですね。

ただ現実には、この役割は発注時点の要件定義に入っていないことが多い。仕様が固まった後で呼ばれても、もう削れない。

機能を増やす圧力は両側から働くのに、減らす側には誰も立っていない。この非対称に名前がついていないのが問題だと思った。

UXと名乗ると、画面をきれいにする人として呼ばれる

UXに近い職域なんだろうけどね。

— 近いんですが、たぶんUXという看板を掲げると届かないタイプの仕事だと思います。

UXと言った瞬間、行政側の受け取りは「画面をきれいにする人」になる。予算費目も設計・開発の下請けに入る。つまり、要件が固まった後の工程として認識される。削る判断は要件定義の前にしか効かないのに、呼ばれる順番が構造的にずれている。

同じ中身でも「業務プロセス設計」「運用設計」と名乗ったほうが上流に入れる、というのが実際のところではないでしょうか。職域としては存在するのに、正しい名前で呼ぶと正しい場所に置かれない。名前のねじれが、そのまま空席の理由になっている気がします。

公共にはサービスデザイナーの席がある。民間の受託商流にはない

「業務プロセス設計」「運用設計」もやるデザイナーという立ち位置確立されていたりするもんなの？もしくは正式な呼び名は存在する？

— 正式な呼び名はあります。サービスデザイン（職名としてはサービスデザイナー）です。

UXデザインが利用者から見える画面を扱うのに対し、サービスデザインはバックステージ——職員の業務手順、承認フロー、システム、制度——まで含めて設計対象にする。ツールとして有名なのがサービスブループリントで、フロントの体験とバックの業務を上下に並べて、どこを削ればどこが成立するかを見る図です。まさに今話していた線引きの道具。

立ち位置が確立しているか、は分かれます。

行政周辺では、かなり制度化されている。英国GDSがservice designerを正式職種として置き、その影響で日本のデジタル庁もサービスデザイン系の職を採用枠として持っている。経産省・IPAのデジタルスキル標準にも人材類型として載っています。つまり公共の文脈でだけ、名前と席が用意されている。

一方、日本の民間、特に受託の現場では確立していません。サービスデザインを掲げているのは大手コンサルのデザイン部門か一部の専業ファーム程度で、Web制作の商流に「サービスデザイナー」という発注枠はほぼ存在しない。名前はあるのに、値付けと発注の型がない。

なので、さっきの「名前のねじれ」は正確に言うと——UXでは届かないが、サービスデザインなら届く場所が公共側にはある。ただしそこは、今いる商流とは別の入口です。

対話のあとに裏取りした結果

ここまでの対話で出た主張を、一件ずつ一次情報に当たって確認した。判定と根拠を全量で載せる。会話の中で誤っていた箇所・誇張だった箇所は、直す前の発言を消さずにそのまま上に残してある。

判定サマリ

1. HDマップ依存とローカライゼーション

正確だった点。Waymo・Cruise・ホンダ Traffic Jam Pilot がHDマップを前提とし、LiDAR点群やGNSSを事前地図と照合してローカライゼーションする点は事実。ホンダは公式に「高精度GNSS情報を地図ユニット（MPU）から受信した高精度地図・車両センサー情報と統合して車両位置を決定」と説明している。ODDが地図範囲で制約される点、信号・車線の意味づけを地図側に事前知識として持たせる点も正しい。

要修正だった点。「HDマップ整備済みエリアしか走れない」はやや強い。技術文献では、HDマップは安全性・信頼性を高めるための冗長情報であり、地図がなくてもセンサーのみで走行すること自体は原理的に可能だという指摘がある。実運用上ODDを地図範囲に限定しているのは事実だが、「地図がないと物理的に一切動けない」わけではない。「Waymoが都市を1つずつ増やすのは地図制約が理由」も、主要因の一つとしては妥当だが、運用・許認可・オペレーション体制の整備も同等に大きい。

End-to-End化について。Waymoは2024年10月30日にEMMA（End-to-End Multimodal Model、Google Gemini基盤／arXiv:2410.23262）を発表したが、これは研究段階であり、商用スタックがマップレス化したわけではない。EMMA論文自体が「LiDARやレーダーを取り込まない」「処理できる画像フレーム数が少ない」「計算コストが高い」といった限界を明記している。Mobileye CTOのShai Shalev-Shwartzはこうした純粋なend-to-end手法を大きなリスクだと批判し、AuroraのSterling Andersonも解決策ではないとコメントしている。業界内でも評価は割れている。

Cruiseについて。2024年12月10日にGMがCruiseのロボタクシー開発への資金停止を発表（SEC提出のForm 8-K／10-Kで確認）、事業を実質停止しCruiseをGM本体に統合した。GMは2016年の買収以降Cruiseに100億ドル超を投資していた。対話中の「Cruise」を現役として挙げていたのは、時点として誤り。

2. マップレス派

Tesla FSDがHDマップに依存せずカメラ映像から推論する方針は、Tesla公式X（2023年10月）で明言されている。Wayveも「AV2.0」でHDマップ不要・end-to-endを掲げ、公式に明記している。Wayveは2024年5月6日にSeries Cで10.5億ドルを調達し、SoftBank Group主導、NVIDIA・Microsoftも参加。

要注意。「原理的にマップ不要」は各社のマーケティング表現に近い。Forbesの評者Brad Templetonは「Teslaは地図を使わず、どこでも走ろうとするが下手にやっている」と批判している。マップレスが平均性能・テールリスク面で万全という含意は持たせるべきでない。

なお中国では地図なし自動運転がすでに実用化しており、ファーウェイなどがHDマップ不要のシステムを実装、理想汽車は全車種に導入している。大都市以外の測量を認めない政府規制への対応として、低コストで汎用性の高いシステムの開発が進んだ、という経緯がある。制度が技術の形を決めた例として、この対話の主題そのものだった。

3. Mobileye REM

REMは量産車のカメラからクラウドソーシングで地図を自動生成・更新する方式で、約10kb/kmの低帯域でデータを収集する点は公式資料通り（Mobileye 2016年1月6日CESプレスリリース／SEC EDGAR提出）。初期からGM・VWと提携、BMW・HEREとも提携。2020年時点で世界4,000万台規模の車両からデータ収集との報道。日本については、Mobileye公式ブログが「ボタン一つで日本全国を24時間で地図化」「約25,000kmをカバーし、地図全体はわずか400MB」と公表している。

4. レベル4認可とODD

日本のレベル4は「特定自動運行」として2023年4月1日施行の改正道路交通法で解禁。車両は道路運送車両法に基づき国交省（地方運輸局）が「走行環境条件（＝ODD）」を付与して認可し、運行は都道府県公安委員会の許可（道交法75条の12第1項）を要する、という二段階構造は正確。国内初の許可は2023年5月、福井県永平寺町の約2km区間。

「地図前提のほうがODD境界が明確で証明しやすい」は、制度がODDの明確な定義を要求する以上、論理的に妥当な整理。ただしこれは解釈であり、規制当局が「地図前提を優遇する」と明文で述べているわけではない。

5. 維持コストの3類型

3類型の整理は実態を捉えており妥当。ダイナミックマップ基盤（2023年2月から「ダイナミックマッププラットフォーム」に改称、2025年3月東証グロース上場）は、国のSIPを起点にオールジャパン体制で2016年設立。日産ProPILOT2.0・ホンダSENSING Eliteに採用。高速道路・自動車専用道路の約3.1万km（2020年度3万1,777km）〜約3.3万kmを整備済み。2021年に一般道拡張計画（2023年度約8万km、2024年度約13万km）を発表。自社でMMSを走らせて計測・図化する自社負担型である点も裏取りできた。北米150万km、欧州25.5万km、韓国2万kmもグローバルに整備。

コストの実数値も出てきた。中国の業界団体によると、高精度地図の1kmあたりの作製コストは1000元（約2万円）程度で、カーナビ用地図に比べて100倍ほど高い。国内の自動車専用道路を対象にした高精度地図の価格は車1台あたり2万〜3万円とされる（アイサンテクノロジーは2025年をめどにこれを10分の1以下にする目標を掲げていた）。

6. 道路法28条と市町村道の割合

道路法28条は「道路管理者はその管理する道路の台帳（道路台帳）を調製し、これを保管しなければならない」「記載事項その他調製・保管に関し必要な事項は国土交通省令で定める」と規定。記載事項・様式は道路法施行規則4条の2で全国統一的に規定され、縮尺1/1000以上、閲覧拒否不可（28条3項）。「標準は国が持っている」という理解は妥当。

市町村道の割合は「約8割」ではなく約84%だった。道路統計年報2024（令和5年3月31日時点）で、日本の道路総実延長 約123.1万km（総延長 約128.5万km）のうち、市町村道の実延長は約103.6万km＝約84.1%。内訳は高速自動車国道 約0.92万km、一般国道 約5.6万km、都道府県道 約13.0万km。対話中の「約8割」は控えめな言い方だった。

市町村の担当者不足も裏取りできた。国交省資料では技術系職員がいない市町村が約3割（450/1,291、平成29年）、維持管理担当が5人以下の市町村が多い。総務省データでは土木系技術職員がいない自治体は町の36%・村の76%。土木学会アンケートでは「すでに不足し困っている」が約6割。

ただし道路台帳の全国電子化率を示す公式統計は特定できなかった。「紙の台帳が普通にある」は個別自治体のデジタル化事例（小野市が昭和60年から紙ベースで整備し、平成23年度にシステム導入／東京都建設局が電子化を進行中）から推測される状態であって、全国の定量的な把握ではない。ここは断定を避けるべきだった。

7. xROAD・PLATEAU・計測のデジタル化

xROADは国交省道路局の道路DX施策の総称。道路データプラットフォーム（2025年5月12日一般公開）は主に直轄国道中心（交通量は全国約2,600箇所の直轄国道の機械観測値、ETC2.0平均旅行速度は幅員5.5m以上の道路約20万km）。市町村道までは基本的に対象外。対話中の「直轄国道中心」は正確。

PLATEAUは国交省の3D都市モデルプロジェクト（2020年開始）。建物中心のCityGML形式で、道路・鉄道・河川も含むが、自動運転向けのcm級HDマップとは目的・精度が異なる別物。2021年度に56都市をオープンデータ化、2025年度末に約300都市、将来500都市へ拡大予定。

スマホ映像＋AIによる路面性状把握は、アーバンエックステクノロジーズ「RoadManager」が代表例。スマホを車に載せて走らせるだけで画像から損傷を自動検知し、ダッシュボードで作業指示書を出力する。全国50以上の自治体・各国道事務所で採用（2025年6月末時点）、東京都・神奈川県などでも本格導入。ドライブレコーダー活用（一般車両約8万台）も。ゼンリンが2025年7月1日付で同社株式の80%を取得し連結子会社化。米子市（山陰酸素工業）との道路パトロールDX実証など、公用車・パトロール車にスマホを載せる運用は実在する。

「計測は自動化できるが、道路台帳への反映は行政行為で自動化できない」という論点は妥当。道路台帳は道路法上の法定台帳であり、調製は道路管理者の義務。区域変更等の告示に基づき調製される行政行為である。

8. サービスデザインの職域

英国GDSのGovernment Digital and Data Profession Capability Framework（旧DDaT Profession Capability Framework、2023年12月に改称）に service designer が正式職種として6レベル（associateからhead of service designまで）で定義されている。「Service designers design the end-to-end journey of a service」と明記。

デジタル庁は「サービスデザイナー」を中途採用枠として実際に募集しており（求人ID G_02, G_04等）、サービスデザインユニットを設置。「制度やシステムの課題」「業務オペレーション」まで設計対象とすると明記。求人票には「カスタマージャーニーマップやサービスブループリントの作成」が業務として書かれている。

IPAのDX推進スキル標準（DSS-P）の「デザイナー」類型に「サービスデザイナー」ロールが明記されている（2022年12月公開、ver1.2は2024年7月、ver2.0は2026年4月）。

「日本の民間・Web受託商流に発注枠がほぼ存在しない」は、裏取りできなかった。求人数などの定量データが見つからず、断定は保留する。実態として、大手コンサル（アクセンチュア、デロイト等）はデザイン部門を持ちサービスデザイン職の求人は存在する。転職エージェントの記事には「サービスデザイナーは企業によって求められる役割が大きく異なる職種です。UI/UXデザイナーの延長線上を求めているのか、ビジネスモデルの変革を求めているのか、求人票の文字面だけで実際の担当範囲や社内での影響力を見極めるのは非常に困難」とある。名前はあるが中身が定まっていない、という状態のほうが実態に近いかもしれない。

掴んでいるアームにも、外したときに戻る場所がない

対話が最後に戻ってきたのは、自分のロボットアームの話だった。

mechArm 270-Pi は、iPhoneのカメラでブロックを見て、その場で関節角を決めて掴む。地図は持っていない。マップレス派と同じ設計になっている。ブロックを動かしても追えるのは、事前の座標を持っていないからだ。

同時に、外したときに戻る場所もない。カメラが赤いブロックを見失ったとき、参照する正解がどこにもない。これは自動運転のマップレス派が抱えている問題とまったく同じ構造で、平均性能ではなくテールリスクの話になる。

いま取り組んでいる受け渡し動作では、この問題がもっと直接的に出る。人の手が可動域に入ってくるので、外したときの結果が違う。だから受け渡しの設計では、カメラで見ずに決めた動きをそのまま出す（開ループ）区間を作って、安全は人が確認する二つのインターロックで担保している。カメラを信じきらない設計を、意識的に選んでいる。

これは自動運転が地図に対してやっていることと同じだ。認識の主役にはしないが、外したときに戻る場所として置いておく。「地図をゼロにはできないが、作り込む地図でもなくなる」——アームにとっての薄い地図が何なのかは、まだ言葉になっていない。FKテーブルなのか、補正記憶なのか、人のインターロックなのか。

そしてもうひとつ持ち帰ったのが、削る話だった。

Pixels to Motors の唯一の主指標は「再現可能な環境数」で、判定条件の3番目に「自分以外の環境で再現された記録が1件以上ある」と書いてある。これは動くコードを作ることではなく、他人が引き受けられる形にすることを測っている。

道路台帳がデジタル化されないのは、計測精度が足りないからではなかった。確定させる人の手が空いていないからだった。同じことが自分の研究資産にも起きうる。動いても、他人が引き受けられる粒度まで削れていなければ、環境の数は増えない。

精度より体験の成立を優先する、と言うときの体験の側には、常に人がいる。