2025年4月に発生したETCの大規模システム障害
2025年4月、高速道路のETCシステムに大規模障害が発生しました。
この障害により、1都7県17路線106箇所で渋滞が発生し、数多くのドライバーに影響が及びました。
当時は復旧のめどが立たなかったため、「後日後払いを依頼する」という応急措置を取ったようですが、実際に後払い申告があったのは対象者の4％程度のようです。可哀想に。
この障害は何が原因だったのでしょうか。
NEXCOさん「データを消し忘れていました…」
4/22に公式の説明資料が発表されましたので、こちらをみてみます。
以下、一部抜粋。
今回の事象の原因を図から一言でまとめるなら、
「本来消去されるべきデータが消去されず、新しいデータを詰め込んでいたため」
と言えるでしょう。
通常、ETC判定データは「どこに送るか」という宛先情報とセットで送られます。
でも、今回の新しい深夜割引判定システムでは、その宛先データを自動で消す機能が実装されていなかったようです。
結果、送り先の情報がどんどん蓄積されていき、肝心の「このETCカードは使えるかどうか」の 判定データを“侵食” して壊してしまった──これが直接の原因かと思われます。
根本原因は？全部エンジニアのせい？
ただ、上記資料には 「なぜ起きたのか？」 という根本的な背景が明記されていません。
きっと複数の要因があり、「根本悪かったのはこれです！」で片付けられる現象ではないとは思います。
実際のところ、単一の原因で説明できるようなシンプルな話ではないでしょう。
それは、あらゆるシステム障害・インシデントに共通することです。
本記事の目的も「誰が悪いか」を追及することではありません。
ですが、 「もし関係者がもっと“システムのこと”を理解していれば…」
そう思わせる要因が、確かに見え隠れしているように思えます。
ここで言う“システムのこと”とは、単にプログラムやネットワークの話ではなく、
「システムの裏側でデータがどのように扱われているか」 という視点、
つまり データベースの理解 を指します。
アプリもインフラももちろん重要ですが、
その裏で常に動き続ける「データベース」の構造や流れを知っているかどうかで、
システムの理解はまったく違ってきます。
そこでこの記事では、非エンジニアを含むすべての関係者が知っておくべき、
「データベース視点の防げたかもしれないポイント 」
を挙げてみたいと思います。
データベース視点の防げたかもしれないポイント
1. データベース設計の不備
今回の障害では、「宛先データ」と「ETCカードの判定データ」が同じメモリ領域で扱われていました。
つまり、異なる種類のデータを明確に分けずに詰め込んでいた状態です。
その結果、本来重要な判定データが破損し、ETCの誤動作を引き起こしました。
これは、データベース設計における「データの独立性」を無視してしまった典型例です。
適切なデータベース設計であれば、一方のデータが他方を「侵食」するような状況は発生しません。
異なる目的のデータは、しっかりと分けて管理する。
必要なものだけが正しく参照されるように、設計段階での「分離」と「整理」が基本中の基本。
参考
2. データクリーニングの欠如
宛先データは「使い終わったら削除すべき」一時的な情報でした。
しかし今回はその処理が行われず、不要なデータが蓄積し続けたことが障害の原因になりました。
これは、“使いっぱなしの部屋”にゴミが溜まっていくようなもので、いつかは動けなくなって当然です。
もう少しちゃんと言うと、定期的なデータクリーニングやメンテナンスプロセスが確立されていなかった可能性があります。
データベースは時間の経過とともに肥大化・断片化するため、定期的なメンテナンスが必要です。
データは集めっぱなしにせず、不要な情報は定期的に掃除・削除する運用が必要。「あとで困るかも」は、たいてい“すぐ困る”になる。
参考
3. トランザクション管理の不備
処理の途中で異常があっても、システムがそれを感知して中断（ロールバック）せず、壊れたままのデータが次の工程に流れてしまった可能性があります。
これは、「やり直しが効かないレジ」のようなもの。
一度失敗した処理をそのまま進めてしまったため、後工程で混乱が起きました。
データ処理は「全部成功したら確定、失敗したら元に戻す」**という考え方が基本。トランザクションの管理こそ、システム信頼性の柱。
参考
4. キャッシュ管理の問題
処理の高速化のために使われる「キャッシュ」ですが、
前回の宛先情報がキャッシュ上に残ったまま新しいデータと混ざってしまい、誤判定につながった可能性があります。
「前の注文が厨房に残ったまま、次のオーダーが追加された」ような状況です。
「前回の宛先データ」が適切にキャッシュからクリアされないという問題は、データベースのキャッシュ管理の不備を示唆しています。
キャッシュは便利だけど、管理が甘いと混乱の元。
常に最新の状態を保つことが何よりも大切。
使い終わったら消す。
参考資料
5. スケーラビリティの問題
深夜割引の見直しにより、従来よりも多くのデータを処理する必要が生じていたようですが、その増加に耐えられませんでした。
「機能追加＝処理量増加」という認識が足りず、システムが取り扱うトランザクション量の増加に対応できなかった、と言えるかと思われます。
新しい機能を追加するときは、その影響でどれだけデータが増えるかを見積もり、考慮する。
また、システムは拡張前提で作る。
参考
6. エラーハンドリングの不足
異常が起きても、それに即座に気づける仕組みがなかったため、復旧に38時間もかかってしまいました。
「何かおかしいで！」と知らせる“警報システム”がなかった、あるいは機能していなかったわけです。
これはデータベースに限った話ではありませんでが、
もしデータベースエラーが発生した際、適切な検知・対応メカニズムがあれば、小さな問題で済んで可能性があります。
エラーは“静かに壊れる”のが一番危ない。
即座に通知・記録・復旧できる仕組みが、トラブルを防ぐ最後の砦。
参考
7. バックアップとリカバリ戦略の欠如
障害発生後、安定した状態に戻すのに長い時間がかかりました。
これは、すぐに切り替えられるバックアップやリカバリの手順が整っていなかった可能性が高いです。
エラーは起きうるもので、大事なのは起きた時にどうするかです。
システム障害はいつか必ず起こる。
“すぐ戻せる”準備があるかどうかが、被害の大きさを決める。
参考
「エンジニアの仕事じゃん？」で絶対に終わらせるな。
今回のような障害が起きたとき、最も避けたい反応は、
「こういうのってエンジニアの仕事でしょ。私たちには関係ないよね？」
という思考停止です。
この記事で最も強く伝えたいのはこの一点です。
そうやって線を引いてしまうことが、組織にとって最大のリスクになります。
なぜなら、エンジニアが作るシステムも企画や営業が届けるサービスもカスタマーサポートが支える運用も、すべては「お客さまへの価値提供」というゴールに向かっているからです。
確かに、システムの内部構造やコードの修正はエンジニアが担う部分かもしれません。
それでもこのシステムに関する理解がどこかで欠けていたら、そこがほころびになり、全体が止まってしまう。
今回の障害も一見技術的な話ですが、もしかしtら実は全員が少しずつ知っていれば防げた現象かもしれません。
組織全員の 「ちょっとデータベースのこと知っておこう」 という意識・姿勢が、
トラブルを防いだり、サービス改善のヒントになったりする可能性があるのです。
非エンジニアも絶対データベースを知っておいた方がいい
（同じようなことを何度も言いますが、大事なので…）
データベースの知識は、もはやエンジニアだけの専門知識ではありません。
今やあらゆるIT職種に共通するリテラシーになりつつあります。
先日、以下のポストを見て、非常に共感しました。
私自身、所属組織ではエンジニアでない立場ですが、個人開発や資格勉強の中で少しずつSQLやデータベースの基本を学んできました。
コードを完璧に書けるわけではないですが、「この数字はどこから来てる？」「この画面ってどのテーブルを見てる？」といった視点を持てるようになっただけで、仕事の質はぐっと上がりました。
テーブル同士の関係やキーの仕組みがわかるだけでも顧客データの理解が深まったり、エンジニアとの会話がスムーズになったりと、実感できるメリットがたくさんあります。
かつては「データベース？それはエンジニアのもの」という時代もありました。
でも今では、マーケティング、営業、企画、CS、広報…
どんな仕事にも“データ”がつきものです。
例えば、
- この売上って、どこから出てきた数字？
- この画面に出ている情報は、どのテーブルに保存されてるの？
- 集計ミスが起きたけど、どこを直せばいい？
こういった疑問にちゃんと向き合える人は、チームにとってかけがえのない存在になり得ると思います。
「SQLを書ける」必要はありません。
でも、 「この情報はどう構造化されていて、どこに格納されてるのか？」
という視点を持っているかどうかが、仕事の深さを変えていきます。
データベースの基本構造や仕組みを理解しておくことは、現代の“IT社会を生きる力”です。
…と、ここまで書いておいて、この内容をエンジニアコミュニティのQiitaで発信するという
大きなパラドックスを抱えていることに今更気づきました。笑
まあどこかで役に立つと信じています。
エンジニアのみなさんには「エンジニアでもない人がこんなこと言ってるよ！みんなもほれ！」と
上手く使って欲しいです。
まとめ
今回のETC障害は、単なる技術的トラブルではなく、
組織全体がどこまで“システムの構造”を理解していたか？と問いかけてくるような事象だったと思います。
どんなに素晴らしい企業ビジョンやサービスがあっても、その裏で動く仕組み＝データを適切に扱うことができなければ、顧客の信頼を失う結果に繋がりかねません。
ほんの少しの知識と理解があれば、防げたかもしれない。
今だからこそ、技術を“他人事”にしない組織と人が、これからの時代を支えていくと思います。