Googleマップに現れた“謎の文字列” 誰も悪くないのになぜ障害が起きたのか：合理的な判断が引き起こすシステム障害

複雑化する現代のITシステムにおいて、インシデントの真の要因を特定することは困難を極める。「Google Maps」で起きた地名誤表示を例に、単なるエラーやツール不足の裏に潜む機能不全を見抜く手法を解説する。

[TechTargetジャパン]

　大規模化して複雑に絡み合う現代のITシステムにおいて、障害の真の原因を特定し、再発を防ぐことは極めて困難になっている。従来広く用いられてきた根本原因分析（RCA）は、目に見える事象の連鎖を追いかける手法であり、個別のエラーに対処するには有効だ。しかし、企業の安全文化や評価プロセスの形骸化といった、目に見えない構造的な要因を見逃してしまう限界があった。

　「Google Maps」では、米国国勢調査のデータセットを取り込むフローにおいて、一部の都市名が誤って表示されるインシデントが発生した。例えば、米国競馬の一大レースであるケンタッキーダービーに向かう人のケースだ。開催地ケンタッキー州ルイビル（Louisville）には、毎年全米から大勢の観光客が押し寄せる。ダービーに向かう人がGoogle Mapsで「Louisville」と検索した際、「Louisville Jefferson County Metro Government (balance)」という不可解な名称が表示された。日本に例えるなら、「新宿」と検索して「東京都新宿区特別行政区画（残余部分）」といった、やたら長くて事務的な名称が表示されるようなものだ。その結果、エンドユーザーに「これは本当に正しい目的地なのか」という混乱を抱かせることになった。

　事態の発覚後も、即座にデータを切り戻せたわけではない。当初は手作業での修正が試みられ、並行してデータセット全体の自動ロールバックが進行するという複雑な対処を余儀なくされた。

　この問題に対してRCAは「評価ツールの機能不足」や「チェック対象の偏り」が原因だと特定し、評価ツールへのチェックロジック追加や、著名な都市名を必ず評価対象に加えるといった、運用者の注意力や既存プロセスに依存するルールの追加が提案された。しかし、こうした対症療法的なアプローチだけで、今後の再発を防ぎ切れるのだろうか。

　事象の表面的な解決にとどまらず、より深層にある組織的・構造的な課題を浮き彫りにしたのが、システム理論に基づく事故分析手法「CAST」（Causal Analysis based on Systems Theory）だ。事象の連鎖を追うRCAから、システム全体の振る舞いを制御するCASTへ。GoogleのSRE（サイト信頼性エンジニアリング）チームは、このインシデントをどのように深掘りし、システム全体を再設計するに至ったのか。

「誰も怠慢ではない」システム障害

併せて読みたいお薦め記事

システム障害に立ち向かう

• システム障害はなぜ起こる？　よくある3つの原因と“想定外”への備え3選
• 事業損失や信頼ダウンに直結　システムを停止させる「4大原因」とは？

　2026年3月に開催されたカンファレンス「SREcon26 Americas」において、Googleのサイト信頼性エンジニアを務めるルーベン・バロッソ氏が登壇した。バロッソ氏は「The Case of the Misnamed Cities: CAST Analysis of a Google Maps Incident」と題したセッションで、前述のインシデントを題材にCASTの有用性を解説している。

　まず、都市名に「(balance)」という文字列が混入したのは単純なバグではない。米国国勢調査局が、市と郡が統合された地域において、他の自治体に含まれない「残余部分」を示すために用いていた正式なラベルだった。外部データと自社システムの仕様の不一致という構造的な問題が背景にあったのだ。

　CASTは、この事象を単なる原因と結果の線形的な連鎖として捉えるのではなく、システム全体を「コントローラー」と「制御対象プロセス」によるフィードバックループとしてモデル化する。バロッソ氏はこの手法を用いて、各担当チームの「メンタルモデル」（状況に対する認識）と、その認識を形成した「コンテキスト要因」（背景事情）を分析した。

　データセットのインポートチームは、過去の経験から「提供されるデータセットの品質は常に均質だ」というメンタルモデルを抱いていた。加えて、全国規模のデータセットは担当者が全て目視するには巨大過ぎたため、チームメンバーの居住地という身近な基準で4つの州のみを抽出した。その結果、全体を保証できると錯覚し、誤表示を含む6つの州を完全に見逃していた。

　復旧作業に当たったエンジニアが即座にロールバックを決断できなかったことにも、合理的な背景があった。当時、影響範囲がごく一部なのか広範なのかが不透明であり、エンジニアリングチームとインポートチームの間で責任分界点も曖昧だった。手作業での修正と並行して安易に切り戻しすれば、データベースの競合など二次被害を生む可能性も危惧していた。

　CASTは、システム全体を俯瞰（ふかん）することで「動的な運用状況の変化」という構造的な要因を特定した。年々増大するデータセットに対し、従来の目視を前提としたサンプリング評価プロセスが完全に機能不全に陥っていた。

　RCAが「著名な都市名を評価対象に追加する」といった表層的な対症療法を導き出したのに対し、CASTは「ランダムサンプリングから、層化抽出を用いた評価プロセスへの全面的な再設計」といった22個の抜本的な改善計画を導き出した。単に自社のエラーを防ぐだけではなく、社会全体のデータエコシステムを浄化するアプローチへと昇華させている。

　システムがますます複雑になる中、単純なヒューマンエラーやツール不足を責めるだけでは、真の信頼性向上は望めない。CASTのような包括的なフレームワークを用いることで、組織全体の意思決定プロセスやフィードバックループを可視化し、システムを安全な方向に導くための本質的な改善が可能になる。

本稿は、USENIXが2026年4月24日に公開した動画「SREcon26 Americas - The Case of the Misnamed Cities: CAST Analysis of a Google Maps Incident」を基に作成しました。