自動運転はなぜまだ実装してはいけないのか?モビリティデータ主権とハッキングリスクという2つの理由

自動運転は、技術的にはほぼ実現段階にあります。それでも急いで実装すべきではない理由が2つあります。1つはデータの主権、もう1つは自動運転自体の事故リスクとは別次元にあるハッキングリスクです。

本記事の位置づけ: 本記事は、自動運転の実装ペースについての一つの意見・提言です。 引用する企業動向・予算数値は2026年9月時点の公開報道に基づきますが、状況は今後変化しえます。

技術的にはほぼ可能、というのが前提

まず前提を確認しておきます。自動運転レベル4(特定条件下での完全自動運転)は、 もはや遠い未来の技術ではありません。日本発の自動運転ソフトウェア企業ティアフォーは 2026年7月22日、東京証券取引所グロース市場に上場し、調達額217億円は今年国内で 2番目の規模のIPOとなりました。トヨタ・スズキ・いすゞなど国内主要自動車メーカーが 同社に出資しており、トヨタとティアフォーは2027年度中の実現を目指し、 バッテリーEV「e-Palette」を用いたレベル4自動運転に取り組んでいます。 トヨタは商用車向けレベル4を2030年までに実用化する方針も示しています。

つまり「技術的に自動運転がほぼ可能」という前提自体は、もはや議論の余地がありません。 問題は、それをいつ、どういう条件で実装してよいかという別の論点です。

国交省の予算とリスク回避的な規制姿勢

国土交通省の2026年度(令和8年度)予算概算要求では、レベル4自動運転トラックの 社会実装に3億2700万円が計上されました。物流・自動車局全体の要求額は 762億円(前年度比13.1%増)です。金額としては年々増加していますが、 個別の実証事業への配分という性格が強く、実装を前倒しするための大胆な投資という 規模には見えません。

日本の自動運転関連の規制・予算配分には、実証実験を段階的に積み重ね、 リスクを最小化しながら進めるという、比較的慎重な姿勢が一貫して見られます。 これは日本特有のリスク回避志向とも関係していると考えられますが、 本記事はこの姿勢自体を一方的に否定するものではありません。後述するように、 少なくとも1つの観点(セキュリティ)については、この慎重さには合理性があると考えます。

アメリカ・中国との差、そしてWaymoの日本上陸

商用ロボタクシーサービスは、アメリカではWaymo(Google系列)がすでに複数都市で 展開しており、中国でも複数の事業者が商用運行を行っています。これに対し、 日本の自動車メーカー自身によるレベル4の実用化目標は2027年度〜2030年という タイムラインです。

興味深いことに、この日本の実用化ペースを追い越す形で、当のWaymoが日本市場に 参入しようとしています。2026年9月、Waymoは日本交通・GO(タクシー配車アプリ)との 提携により、2027年に東京でロボタクシーサービスを開始すると発表しました。 GOがタクシー業界との橋渡しを、日本交通が車両運行を担い、まず小規模から始めて 最終的に車両数を100台規模まで拡大する計画です。2025年以降、Waymoの車両は 日本交通のドライバーが手動運転しながら、港区・新宿区・渋谷区・千代田区・中央区・ 品川区・江東区といった東京都内の詳細な3Dマップデータを収集してきました。 なお、トヨタ自身もWaymoとのロボタクシー事業への参画を検討していると報じられています。

つまり日本の自動運転市場では、国内メーカーの自社開発と、海外企業(Waymo)との 提携という2つの流れが並走している状態です。ここで本記事が提起したいのが、 まさにこの構造が抱える懸念、モビリティデータの主権の問題です。

懸念①:モビリティデータの主権リスク

自動運転車・モビリティネットワークが収集するデータ ―― 位置情報、実際の運転挙動データ、 センシングデータ(カメラ・LiDAR・レーダーの生データ)など ―― は、情報としての価値が 極めて高いものです。これらは単なる利用者の個人情報にとどまらず、都市のインフラ配置、 交通パターン、さらには安全保障上重要な地理空間情報を含みうるデータです。

こうしたデータの収集・処理・蓄積を自国で行う技術基盤を持たないまま、海外企業の プラットフォームに依存する形で自動運転を実装した場合、これらの重要データが 国外に蓄積・移転されるリスクを構造的に抱えることになります。この種の懸念は、 自動運転に限らず、経済安全保障の文脈で重要インフラ関連データの取り扱いが 近年繰り返し議論されてきた論点と軌を一にするものです。ティアフォーのような 国産の自動運転ソフトウェア企業が上場し、国内自動車メーカーの出資を受けている ことは、この観点からは重要な意味を持つと考えられます。

懸念②:ハッキングリスクは、自動運転の事故リスクとは別次元にある

ここが本記事の核心的な主張です。自動運転の安全性については、「AIの判断ミスによる事故」 の議論がもっぱら注目されがちですが、IoT・通信・トラッキング機能を搭載した 自動運転車およびモビリティネットワークには、これとは全く別の、悪意ある第三者による ハッキングという事故リスクが存在します。この2つは、発生メカニズムも対策方法も 根本的に異なる、別々に評価すべきリスクです。

ハッキングリスクの現実性は、すでに実証されています。2015年、セキュリティ研究者の Charlie MillerとChris Valasekは、Jeep Cherokeeの車載インフォテインメントシステム (UConnect)の携帯回線経由の脆弱性を突き、走行中の車両のステアリング・ブレーキ・ 変速機を遠隔から操作可能であることを実証しました。この発見を受け、 Fiat Chrysler(当時)は140万台のリコールを実施しています。この事例は、 「複雑なソフトウェアと通信機能を持つ車両は、単一の脆弱性から車両制御全体が 乗っ取られうる」ことを示した、業界にとって象徴的な出来事です。

現行の国際規制であるUNECE(国連欧州経済委員会)のWP.29 R155(サイバーセキュリティ 管理システム、CSMS)・R156(ソフトウェア更新管理システム、SUMS)は、2022年7月から EU・英国・日本・韓国で新型車に適用され、2024年7月からは同市場で生産される 全車種に適用が拡大されています。国土交通省もこれを型式指定制度に組み込んでいます。

R155/R156の限界について: ただし、これらの規制が要求しているのは 「サイバーセキュリティを管理する体制(プロセス)を持つこと」であり、 「OSI参照モデルの7層、あるいはTCP/IPモデルの4層すべてにおいて脆弱性が 存在しないことを技術的に保証すること」ではありません。管理体制が存在することと、 実際に脆弱性が十分に排除されていることは、別の問題です。

本記事の立場は、こうした管理プロセスの整備だけでは不十分であり、 安全性に関わる中核ソフトウェア(特に、車両制御・通信スタックの根幹部分) については、テストや監査だけでなく形式手法による検証(formal verification) ―― プログラムが特定の性質(例えば「この入力範囲では意図しない状態遷移が発生しない」)を 数学的に満たすことを証明する手法 ―― を必須とすべきだ、というものです。 もちろん、複雑な実システム全体について「あらゆる脆弱性が存在しない」ことを 完全に証明することは、現実的には極めて困難です。しかし、少なくとも 安全性に直結する境界(通信の受け口、権限の境界、アクチュエータへの制御経路)については、 検証可能な範囲を明確にした上で、可能な限り数学的な保証に近づける努力が必要だと考えます。

重要なのは、この形式検証・セキュリティ検証の完了を、自動運転そのものの 実用化条件とは別建てで、明示的な前提条件として設定すべきだという点です。 AIの判断能力がどれだけ向上しても、ハッキングによる事故のリスクはそれとは独立に 残り続けます。この2つのリスクを混同したまま「自動運転は十分安全になった」と 判断してしまうことこそが、本記事が最も懸念する事態です。

まとめ

  • 自動運転レベル4は技術的にはほぼ実現段階にあり、ティアフォーの上場(2026年7月、調達額217億円)やトヨタの2027〜2030年の実用化目標がそれを裏付けている
  • 国交省の2026年度予算は自動運転関連費目を増額しているが、実証を段階的に積み重ねる慎重な姿勢が続いている
  • Waymoは2027年に日本交通・GOと組んで東京でロボタクシーを開始する計画で、国内メーカーの実用化ペースと並走する形になっている
  • 懸念①: モビリティデータ(位置情報・運転データ・センシングデータ)を自国で扱う基盤なしに実装を進めると、重要データが国外に流出する構造的リスクがある
  • 懸念②: ハッキングによる事故リスクは、自動運転自体の判断ミスによる事故リスクとは別次元の問題であり、2015年のJeep Cherokeeハッキング事例がその現実性を示している
  • 現行のUNECE R155/R156はセキュリティ管理体制(プロセス)を要求するが、技術的な脆弱性の排除そのものを保証するものではなく、安全性に直結する部分には形式検証が必要である

関連記事

デュアルユース技術と技術者倫理、協調的な脆弱性開示の実例について考察しています。

デュアルユース技術と技術者倫理を読む