Baiduロボタクシーが武漢で大規模フリーズ｜自動運転の安全性リスクと今後の課題

2026年3月31日の夜、中国・武漢市の幹線道路で異様な光景が広がった（武漢市警察の発表は翌4月1日）。Baiduが運営するロボタクシー「Apollo Go」が道路の真ん中で次々と停止し、そのまま動かなくなったのだ。乗客は車内に閉じ込められ、高速道路では立ち往生が発生。少なくとも複数件の追突事故が報告されているが、武漢市警察の発表時点で負傷者は確認されていない。影響を受けた車両は100台を超えるとされ、自動運転の商用展開でも過去最大級のシステム障害となった。

武漢でBaiduのロボタクシー100台超がフリーズした事件の全容

武漢市はBaiduにとって最大のロボタクシー拠点の一つとされ、500台以上のApollo Goが公道を走行していたと報じられている。火曜日の夜、これらの車両が突如として道路上で停止。動けなくなった車両が交差点や車線上に散在し、周囲の交通は混乱に陥った。

TechCrunchやCNBCなどの報道によれば、少なくとも100台のロボタクシーが影響を受けたとされる。報道時点でBaiduは公式な声明を出していない。

乗客の閉じ込めと高速道路での立ち往生

問題の深刻さを際立たせたのは、乗客が車内から出られなくなったケースが報告された点。ロボタクシーは安全上の理由からドアのロック機構が通常のタクシーと異なる場合があり、システムがフリーズした状態では乗客側からの操作が制限される構成も存在する。

高速道路上で停止した車両もあったとされる。時速100km前後で車が行き交う環境で、突然動かなくなった無人車両が車線をふさぐ。後続車にとって極めて危険な状況であることは想像にかたくない。少なくとも複数件の追突事故が報告されているが、警察発表の時点で負傷者は確認されていない。

警察の対応と「システム障害」の発表

武漢市警察は、Apollo Goの停止に関する複数の通報を受けたことを公式に認めた。初期調査の結果、「システム障害（system failure）」が停止の原因だと発表している。

ただし、具体的にどのシステムが、何をきっかけに障害を起こしたのかについては明らかにされていない。「システム障害」という表現はあまりに広範で、ソフトウェアのバグなのか、通信の途絶なのか、あるいはクラウド側のサーバー障害なのか、現時点では切り分けができていない。警察の発表は事実の確認にとどまり、技術的な詳細はBaiduからの説明を待つ形になっている。

日本でも自動運転車両の事故時には道路交通法に基づく報告義務と通報フローが整備されており、自動運転車両の運行を所管する交通行政の枠組みは各国で共通している警察庁 交通局。

なぜ100台が同時に止まったのか：考えられる原因

「システム障害」という公式発表だけでは、技術者でなくとも疑問が残る。個別の車両が1台故障するのと、100台以上が同時に止まるのでは、原因の構造がまるで異なるからだ。

自動運転車両は大きく分けて「車両側の自律制御」と「クラウド側の統合管理」の2層で動いている。個別のセンサー故障であれば影響は1台に限られる。しかし100台規模の同時停止は、共通のインフラ。つまりクラウド側の制御システム、OTA（Over-The-Air）アップデート、あるいは通信ネットワークのいずれかに障害が発生した可能性が高いと整理される。

国際自動車技術者協会（SAE International）の規格J3016は、自動運転のレベル0からレベル5までを定義し、ODD（運行設計領域）の範囲やADS（Automated Driving System）の責務を明示しているSAE J3016 自動運転レベル定義。Apollo Goが該当するとされるレベル4のADSでは、ODD内であれば人間の介入なしに走行を継続できることが前提となるため、クラウド側の障害に対しても車両単体での縮退運転が要求される。

クラウド制御型の弱点：単一障害点リスク

Apollo Goのようなフリート型ロボタクシーは、配車・ルーティング・遠隔監視をクラウドで一元管理するのが一般的な設計とされる。効率の面では合理的だが、そのクラウドが落ちれば全車両に影響が波及するリスクを抱えている。これが「単一障害点（SPOF: Single Point of Failure）」の問題だ。

考えられるシナリオはいくつかある。

1. 配車管理サーバーの障害: 車両がルート指示を受け取れなくなり、次のアクションを決定できずに停止
2. OTAアップデートの不具合: 走行中に配信されたソフトウェア更新がバグを含んでおり、一斉に適用された車両がフリーズ
3. 通信インフラの断絶: 4G/5G回線の基地局障害やネットワーク設定の変更により、車両とクラウド間の通信が途絶

いずれのケースでも、車両側に十分な「オフライン時の自律判断能力」が実装されていれば、少なくとも路肩への退避程度は可能だったと推測される。道路の真ん中で完全にフリーズしたという事実は、車両単体のフォールバック機能に課題があることを示唆している。

ローカル推論で冗長化は実現できるか：コンシューマー GPU での参考実測

「車両側にオフライン時の自律判断能力を」 という設計要請は、 計算リソースとして何を要求するのか。 本サイトでは AI ツール検証用に Intel Core i7-14700F + DDR5 96GB + 2TB×2 SSD のホストに、 メイン GPU として RTX 5080 (16GB GDDR7、 TDP 360W)、 サブとして Oculink 接続の RTX 5060 Ti (16GB GDDR7、 TDP 180W) を常設し、 メイン 850W + Oculink 専用 750W の 2 系統独立電源で運用している。 自動運転とは workload が異なるが、 「クラウド断絶時にローカルでどこまで継続判断を出せるか」 という設計問題は LLM 推論パイプラインと構造が重なる。

本サイト常設環境で、 Ollama 経由の Qwen3 系モデルを連続稼働させた際の処理時間実測は以下のとおり。 いずれも単独 GPU 占有時の値で、 投入バッチサイズや前段スコアリングの構成は本サイトのパイプライン上で固定されたもの。

規模感の参考として、 自動運転車載 SoC である NVIDIA DRIVE Orin は最大 254 TOPS、 上位の DRIVE Thor は 1,000 INT8 TOPS（FP4 では 2,000 TFLOPS）と公表されているNVIDIA DRIVE プロダクトページ。 コンシューマー GPU でも、 9B 級の軽量モデルなら 1 秒以内に推論を返せる水準にあることを踏まえると、 「ローカルに退避動作専用の限定モデルを常駐させ、 クラウド断絶時には路肩寄せまでの動作だけは車両単体で完結させる」 という設計は、 計算リソース面では十分に実現可能と整理できる。

逆に言えば、 今回の Apollo Go の事象が「クラウド断絶 → 全停止」 という形で表面化したのは、 ハードウェアの能力不足というより、 ソフトウェア側のフォールバックパスがカバーする状態空間が狭かった可能性のほうが高いと考えられる。 LLM 推論パイプラインで「クラウド API がタイムアウトしたらローカルモデルに退避する」 設計を採るのと同等の発想を、 安全性が桁違いに要求される車載側で実装する難度は高い。 ただし計算資源が制約要因ではないことは、 上記の実測値からも読み取れる。

「止まる」設計は本当に安全か

自動運転のフェイルセーフ設計には「MRC（Minimal Risk Condition）」という考え方がある。異常を検知したら、最小限のリスク状態に移行する設計方針だ。多くの場合、「安全に停止する」ことがMRCとして設定されているとされる。

Minimal Risk Conditionは、ADSが動的運転タスクを継続できなくなった場合に、衝突リスクを許容範囲内に抑えるよう車両を遷移させる状態として定義されている。停止状態の確保だけでなく、停止位置の安全性、後続交通への警告、乗員の脱出可能性までを含む複合的な状態である。

SAE J3016ではMRCを上記のように定義しており、単なる停止ではなく停止位置の安全性まで含めた包括的な要件として整理しているSAE J3016 規格本文。

しかし、今回の事件はその前提に疑問を投げかけた。交差点の中央や高速道路の走行車線で「安全に停止」されても、周囲の車両や歩行者にとっては新たな危険が生まれるだけ。本来のMRCは「路肩に寄せてから停止する」「ハザードランプを点灯して後続車に警告する」「ドアロックを解除して乗客の脱出を可能にする」といった複合的な動作を含むべきと位置付けられている。

500台規模のフリートが同一のクラウドシステムに依存し、かつ車両単体のフォールバックが不十分だったとすれば、設計レベルでの見直しが必要になる。これは単なるバグ修正では解決しない、アーキテクチャ全体の課題と言える。

自動運転タクシーの安全性をめぐる世界の動き

今回の事件は、中国国内だけでなく国際的にも自動運転の安全性議論を再燃させた。自動運転技術をめぐる各国のスタンスは、実はかなり異なっている。

中国の積極展開とBaidu Apollo Goの現在地

中国は自動運転の商用化で世界をリードしている国の一つとされる。政府が技術発展を後押しし、規制面でもテスト走行や商用運行の許可を積極的に出してきた背景がある。

Baiduは現在、世界26都市規模でロボタクシーを展開中と報じられている。海外ではロンドン（UberおよびLyftとそれぞれ提携）やドバイ（Uberと提携）への進出も進めている。武漢だけで500台以上という規模感は、日本の実証実験とは桁が違う。主要事業者の展開状況を整理すると以下のようになる。

この「速さ」が安全性とのトレードオフを生んでいる可能性は否定できない。今回100台超が同時フリーズしたことで、「規模の拡大に安全設計が追いついているのか」という問いが突きつけられた格好だ。中国のSNS上でも「無人タクシーに命を預けて大丈夫なのか」という声が広がっていると報じられている。

日本でも国家戦略特区での自動運転実証など、AI技術を公共インフラに組み込む動きは進んでいる。ただし、人命に直結する自動運転と業務効率化AIでは、求められる安全基準の水準が大きく異なる。自動運転の社会実装には、技術の成熟だけでなく、AIが実社会の物理的な動作に組み込まれる際の安全性と倫理を正面から議論する必要がある。

米国Waymo・日本の自動運転との比較

米国ではAlphabet傘下のWaymoがサンフランシスコやフェニックスでロボタクシーを運行しており、実績では中国勢と並ぶ存在とされる。Waymoは独自の安全評価フレームワークを公開しており、人間ドライバー比較での衝突率や受傷事故率を定期的に開示しているが、フリート全体の同時停止事象は報告されていないWaymo Safety Hub。

Waymoのアプローチの特徴は、展開都市を絞って徹底的にマッピングとテストを繰り返す「深く狭く」の戦略。対するBaiduは多都市に広く展開する「広く速く」の戦略とされ、このアプローチの違いがリスク管理の差として表れた可能性がある。

米国側の規制環境では、運輸省道路交通安全局（NHTSA）が自動運転車両のサイバーセキュリティ・冗長設計・事故報告に関するガイドラインを整備し、メーカーの自主的安全評価レポート（VSSA）提出を求めているNHTSA Automated Vehicles for Safety。

日本の状況はどうか。2023年に改正道路交通法が施行され、レベル4（特定条件下での完全自動運転）の公道走行が法的に可能になった。福井県永平寺町での遠隔監視型自動運転サービスが国内初の事例として知られているが、車両数は数台規模にとどまる。商用フリートとしての大規模展開は、まだこれからという段階にある国土交通省 自動運転に関する制度整備。

今回の事件から見える自動運転の本質的な課題

技術的なバグは修正できる。しかし、今回の事件が突きつけた課題は、パッチで解決するような性質のものではない。

「安全に止まる」だけでは足りない理由

自動運転のフェイルセーフ設計において、「異常検知→停止」はもっとも基本的なロジック。だが、それが「安全」であるためには前提条件がある。停止する場所が安全であること、という条件だ。

自動運転車が走行中にシステム異常を起こした場合、理想的な動作は以下の順序になるとされている。

1. 異常を検知し、走行モードを「退避モード」に切り替える
2. 周囲の車両・歩行者の状況をセンサーで確認しながら減速する
3. 路肩や安全な場所まで自律的に移動する
4. ハザードランプを点灯し、完全停止する
5. ドアロックを解除し、乗客に状況を通知する
6. 遠隔オペレーターまたは緊急通報システムに自動接続する

今回の武漢の事例では、少なくともステップ2〜3が機能していなかった可能性が高い。車両が道路の真ん中で停止したという報告がそれを物語っている。クラウドとの通信が途絶した瞬間に、車両側が最低限の退避動作すらできなかったとすれば、これはフェイルセーフの根本的な設計不備と判断せざるをえない。

航空業界では「フェイルオペレーショナル」という設計方針が標準とされる。1つのシステムが故障しても、別のシステムが機能を引き継いで安全に運航を継続するという考え方で、商用航空機の二重・三重の冗長構成はこの原則に基づく。自動運転にも同様の冗長性が必要だという指摘は以前からあり、今回の事件でその主張の正当性が改めて裏付けられた形だ。

大規模運用で浮上するフリート管理の壁

数台の実証実験と500台のフリート運用では、求められるシステム設計がまったく異なる。実証実験フェーズでは1台1台を手厚く監視できるが、数百台規模になると遠隔監視の人員配置、ソフトウェアアップデートの段階的展開（カナリアリリース）、障害時の一斉制御といった「フリート管理」の能力が問われる。

特に重要なのがアップデート戦略。仮にOTAアップデートの不具合が原因だったとすれば、全車両に同時適用するのではなく、まず数台に適用して異常がないことを確認してから段階的に展開する。ソフトウェア業界では一般的な運用が、果たして実行されていたのかという疑問が残る。日本でも経済産業省と国土交通省が連携し、自動走行の社会実装に向けた制度設計を進めている経済産業省 自動走行ビジネス検討会。

また、保険と責任の問題も避けて通れない。乗客が閉じ込められた場合の責任は誰にあるのか。事故が発生した場合の過失はBaiduなのか、通信キャリアなのか、それとも規制を認可した当局なのか。技術の進歩に法整備が追いついていない状況は、中国に限った話ではなく、日本を含む各国共通の課題とされる。

自動運転車のフリート運用は、1台の車を作る技術とは別の「システムズエンジニアリング」の領域。ここでの設計判断が甘ければ、今回のような大規模障害は繰り返し起きる可能性がある。

まとめ：自動運転の未来はこの失敗から何を学ぶか

今回のBaidu Apollo Goの大規模フリーズは、自動運転技術が「動く」だけでは不十分であることを端的に示した事件だった。

重要なポイントを整理する。

• 事実: 武漢市で100台超のロボタクシーが同時にフリーズし、乗客の閉じ込めや交通事故が発生
• 原因: 警察は「システム障害」と発表。クラウド制御型アーキテクチャの単一障害点が疑われる
• 設計の課題: 「安全に止まる」フェイルセーフが、停止場所によってはむしろ危険を生むというパラドックス
• 計算資源の観点: 本サイトのコンシューマー GPU 実測 (9B 級モデルで 1 秒以内) からも、車載側で退避動作専用の限定モデルを常駐させる設計は計算資源面では実現可能と整理できる
• 運用の課題: 500台規模のフリート管理には、実証実験とは異なる次元のシステム設計が必要
• 規制の課題: 技術の展開速度に安全基準と法整備が追いついていない

自動運転は社会に浸透していく方向性の技術であり、その流れ自体は止まらないと見られる。だからこそ、今回のような障害事例から具体的な教訓を引き出し、設計と規制の両面で改善に活かすことが求められている。

日本で自動運転タクシーが本格的に普及するのはまだ先の話だが、そのとき安心して乗れる環境が整うかどうかは、今まさに世界各地で起きている失敗とその対応から決まっていく。技術の進歩と並行して、「何が起きたら、どう止まるのか」という問いを設計段階で詰めることが、社会実装の前提となる。

関連する実測・解説記事

• Perplexityとは？AI検索エンジンの使い方・特徴・料金を初心者向けに解説
• 自宅で人型ロボットを訓練するギグワーカーたち：AI開発を支える「見えない労働」の実態
• Suno v5.5の新機能を解説｜Voices・My Taste・Custom Modelsで変わるAI音楽生成

よくある質問（FAQ）

Q: Apollo Goとは何ですか？
A: Baiduが開発・運営するロボタクシー（自動運転タクシー）サービスの名称。中国を中心に世界26都市規模で展開されていると報じられており、武漢市には500台以上が配備されていたとされる。アプリで配車を依頼すると、運転手のいない車両が迎えに来る仕組み。

Q: 今回の事件でけが人は出ましたか？
A: 武漢市警察の発表時点では、負傷者は確認されていない。ただし、少なくとも複数件の追突事故が発生したと報じられている。乗客が車内に閉じ込められたケースや、高速道路上での立ち往生も報告されており、人的被害がなかったのは幸運だったと言える。

Q: 日本でも自動運転タクシーに乗れますか？
A: 2023年の改正道路交通法施行により、レベル4の自動運転が法的に認められた。福井県永平寺町で国内初の遠隔監視型自動運転サービスが運行されているほか、東京都心部やお台場エリアでも実証実験が行われている。ただし、武漢のような数百台規模の商用サービスは国内にはまだ存在せず、本格的な普及には数年単位の時間が必要と見られる。

Q: 車載側にローカル推論を載せるのに、どの程度の GPU 性能が必要ですか？
A: 本サイトのコンシューマー GPU 環境では、 RTX 5080 (16GB) に 9B 級モデルを載せた場合 1 件あたり 0.8 秒程度で推論が完了している。 自動運転車載 SoC の NVIDIA DRIVE Orin は 254 TOPS、 DRIVE Thor は 1,000 INT8 TOPS（FP4 では 2,000 TFLOPS）と公表されており、 軽量な退避動作専用モデルを車両単体で常駐させる構成は、 計算資源面では十分に成立する水準と整理できる。 障壁はハードウェアより、 ソフトウェア側のフォールバックパス実装の網羅性にあると考えられる。

本記事は AIツール図鑑 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。

参考資料

• NVIDIA DRIVE 製品情報 — 車載 SoC の TOPS 値 (Orin 254 TOPS / Thor 1,000 INT8 TOPS（FP4 では 2,000 TFLOPS）) の出典