[280888]ＥＴＣシステム障害、前日に行ったシステム

( 280892 ) 2025/04/07 03:10:59

Tag for ingestion URL.

0 00

=+=+=+=+=

システムの運用に関わった経験がある方ならお分かりだと思いますが、こうした大規模なシステム改修を行う際は、事前の十分な検証だけでなく、万が一障害が発生した場合の「切り戻し計画」をきちんと準備しておくのが基本中の基本です。

復旧の見通しが全く立っていない状況を考えると、事前の「切り戻し計画」が甘かったか、あるいはそもそも切り戻し作業自体を試みたものの、想定外の問題で行き詰まってしまった可能性が高いと感じます。

ETCという日常的に使われる重要なインフラにおいて、障害発生から18時間以上経過しても復旧できないのは利用者にとって深刻な問題です。トラブルが起こること自体は仕方がないとしても、その後の対応が後手に回ることは落ち度が大きいと思います。

関係者の皆様は大変だと思いますが、早期復旧を行っていただき、原因を究明して今後の再発防止につなげてほしいと思います。

▲6857　▼370

=+=+=+=+=

かつて首都圏のJRで、自動改札のシステムがダウンしたときは、自動改札機を止めて一時的に利用者を素通りさせていたことがある。自分は当時定期券の利用者だったので、運賃には影響がなく、遅れもない状態で通勤できた。

今回も、車の改札システムが故障という点では似た事態で、とりあえず通過してもらうという対応も同じだが、各地で渋滞が発生してしまったのは残念だ。鉄道の駅とは違い、インターチェンジでは、車のドライバーに対応方法を迅速に伝えるのが難しいからなのかもしれない。

システムの故障は、人間が作ったものである以上避けられないときもあるが、今後同じような事態になったときに、もう少しスムーズな解決ができるとよいと思う。

▲207　▼18

=+=+=+=+=

すっかりこの騒動にはまってしまい、入った時は大丈夫だったのに、出られず

散々待たされた結果ゲートで紙を渡されたのですが2日以内にネットから手続きして支払えとのこと。

支払うのは仕方ないにしろ、かなり迷惑を蒙っているのに二日以内ってのがかなり急かされてるなと思いました。

▲5021　▼120

=+=+=+=+=

システムトラブルが連発している。便利さと不便さは紙一重だ。「アナログ」方式も絶対に残すべきであると思う。「均一性」の泣き所であり、「多様性」が命綱となりうるのだ。これ以上の「便利さ」は人類を破滅に追い込むかもしれない。今必要なのは各駅停車でも人間は時間を有効に満喫できると言うことだと思う。人生はそんなに急がなくてもいいはずだ。

▲337　▼111

=+=+=+=+=

24時間稼働させるシステムにて予算や制約が多いのはわかるが、トラブル時への準備と対応が不十分だったと言われても仕方ないと思う。重要インフラにて、今回の課題を検証し、技術的な課題のみでなく、工事のプロセスやトラブル時の対応全体を見直ししてほしい。

▲499　▼42

=+=+=+=+=

深夜割引を「見直し」という名でゴミみたいな制度に改悪しようとした罰としか思えない。

政府のやることと似てるよね、少しでも搾取するためにとにかく複雑な条件をつけようとする。

そしてそれが完全に煮詰まってから開発したんじゃ間に合わないから見切り発車で開発する。

今頃開発に携わった人たちは必死の復旧作業に追われているのだろうけど、開発者を悪者にするんではなく、いい加減な要件やスケジュールで無理に開発させた側もきちんと反省すべき。

▲306　▼18

=+=+=+=+=

ETCのような大規模なシステムを入れ替える場合は、トラブルが発生した場合に直ぐに前のシステムに戻れるようにするとか、トラブルの影響が限定的な範囲にしか及ばないように配慮するとか、全面改訂ではなく徐々に少しづつ新しいシステムに更新していくように進めるとか、色々考えるものだけど時間や費用の削減を優先して短期間での更新を断行すると得てしてこういう結果になる。

NEXCOはシステムの運用を甘く見たのかもしれない。

▲2090　▼133

=+=+=+=+=

今回、システム改修作業に問題があったと認めているので、交通事故、予定変更など、各種のトラブルに巻き込まれた利用者に対して、以下の規定に基づいた賠償を行うべきだと思います。

NEXCO中日本　供用約款

第10条（会社の責任）

高速道路の設置又は管理に瑕疵があったために利用者に損害を生じたときは、会社は、これを賠償する。

▲1505　▼54

=+=+=+=+=

システムを変える時は万が一に備えるものです。

私の勤務先の生産システム入れ替えの時は新旧システムを同時進捗して新システムが問題ないと確証を得られた時点で旧システムを切り離します。

素人の改造じゃないんだから、なぜ切り戻し等の対策を考えなかったのか？何らかの障害で戻せなかったのか？検証が必要です。

▲1178　▼98

=+=+=+=+=

システム改修はハードウェアの場合は改修前の記録を残し、ソフトウェアの場合はバックアップを採取し、万が一の問題が起きた場合はそれを頼りに不具合発生前の状態に差し戻します

時間超過しても復旧できないのは、復元に時間を要するほどの大規模改修か、それをしていない可能性等が考えられます

いずれにせよ、この障害は更に長期化するものと思われます

▲579　▼52

=+=+=+=+=

今日は私も２時間渋滞の中でした。今後システム変更は道路工事と同じと考えて何日も前から予告をすべきだと思います。事前に分かっていれば予定を他の日にするとか遠くない場所ならば下道で行くとかの対処が可能になると思います。

▲685　▼74

=+=+=+=+=

この問題、利用者視点から無責任な意見だけど、本来なら影響区間は無料でゲート解放だと思います。こんなに渋滞を発生させておいて、利用者に後で料金を払って下さいって…じゃ、渋滞分の時間と費用を返してくれと、言いたくなりませんか？

こういう時のための保険って、NEXCOは入っていないのかなぁ。これ物流的には、損害賠償を払って欲しいくらいのトラブルでは？とも思います。

24時間稼働しなきゃ行けないシステムって、どういう仕組みでシステム変更しているのか、気になりました。切り替わるタイミングを軸に前後のある程度の時間帯をオーバーラップさせる感じで、記録させて、アップデートされたシステムに変更させるのでしょうか？

とはいえ、今回、元のシステムに速やかに戻せないとすると、リスク対応への不備や見落としがあったんでしょうね。

▲386　▼19

=+=+=+=+=

復旧するまでケチケチせずに全て無料開放するべき。高速道路に乗ったのに降りるまでに数時間かかったとか。

少ない有人ゲートで1台ずつ料金徴収をすればさもありなん。なぜETCの不具合がわかった時点でゲートを開けなかったのか。システムの不具合以上にその後の対応の悪さで有料道路の大混乱を招いた責任は重い。

システム変更では今までにも銀行ATMが使えなくなったりなど各種事例がある。二重三重にチェックを重ね、それでも最悪の事態を予想するものではないのか？

プログラムのバグなのか原因を一刻も早く突き止めてほしい。復旧できないのであれば再度いうが無料開放するべきだ。

▲288　▼26

=+=+=+=+=

そもそも論として、ETCの料金改定は必要だったのですか？

本来は無償化されるはずの高速道路で運用費が赤字でもない限り不要ではないかと。

ついでに言えば、深夜割引の時間帯をもう少し長く設定すれば、渋滞の分散にもつながると思うので金を集めるほうではなく、利便性を向上させる方に力を入れてほしいです。

▲387　▼62

=+=+=+=+=

世の中全体として、システム改造を簡単に考えすぎだと思う。

ソフトの改造だけで済む場合は、特に新たに機器を導入するわけでもなく、見た目には大した変化もないが、膨大な手間とコストを掛けてソフトを改造し、テストを実施する事になる。

一人があるロジックを理解するだけならそんなに難しくは無い。しかし一人で全体をカバーできない規模になると、全体の概略を開発する人と各々個別の開発をする人が階層構造になる。この場合は仕様書を使ってやり取りするが、格段に難易度が高くなる。そして、少しでも齟齬が発生すると、後々大きな問題となる。

確認のためにテスト環境を用意する事になるが、これだって実際の環境を100%再現する事は出来ないだろうから、想定でのテストとせざるをえない。ここにテスト漏れが発生する可能性がある。

無知な政治家が大した効果もないのに、面倒な料金割引制度などを言い出すと、本当に迷惑だと思うね。

▲155　▼9

=+=+=+=+=

これは起きたことが問題なのではなく、こういったことが起きた場合のプランがどれぐらい準備されていたか、それが点検されていたか、ということだと思う。

もちろん、準備はされていたはずだけど、それがなぜ機能しなかったのかも、きちんと点検してほしい。

▲177　▼17

=+=+=+=+=

銀行や証券取引所やネクスコや携帯のシステムトラブルも酷かったけどETCのシステムトラブルは人命にも関わる重大なインシデントだろう。こういうロクな対応も能力もない企業に交通インフラを任せるべきではない。ETCが使えなくなった時のマニュアルはないのでしょうか。ゲートをオープンにして車を一般道に出すか、もしくは無料で使わせれば問題ないと思う。

▲61　▼4

=+=+=+=+=

システム改修する時は、事前通知すべきことと充分な対策した後で行うべきであり、土日かけてするべきでもなく、テストした上で告知して実行すべきでした。

全てETC対応ゲートが多く、通行券対応の一般ゲートが少ない事も渋滞や事故に繋がり、混乱を招いた道路会社の責任は大きいと思います。

ETCが殆ど利用されている高速道路、この様な事態になった時、対応出来るようにすべきと思います。

▲754　▼251

=+=+=+=+=

このようなシステム開発をやった事のある経験者ならわかると思うが、

システム自体を２重化しておき、バックアップ側で先にシステム改修を行い、

試験運用してから本番側と切り替える。

この時、バックアップ側に回ったシステムは旧来のシステムで動いているので

切り替えた後に問題が発生した場合はもう一度システムを切り替えれば

旧システムに戻す事が出来る。

ただし中心にあるデーターベースは簡単に戻す事は出来ないが、

データベースのロールバック機能で切り替え前の状態に戻してから

その後のトランザクションデータから現在の状態を復元する。

切り戻しの手順とシステム障害のバックアップ手順を見直した方が良いね。

ただ、このようなシステムで問題が起こりやすいのは過負荷になった時。

想定外のデータ量が集中してサーバ―が処理しきれなくなる。

事前に想定以上の負荷をかけて試験しておくことが重要です。

▲56　▼25

=+=+=+=+=

予告されていたとはいえ、よりによって多くの人が移動する週末に、ここまで大規模なシステム障害を起こすとは思っていませんでした。

なぜ段階的な実装や十分なテストを行わなかったのか、少しずつ段階的にシステムを更新していけば、ここまでの混乱は避けられたのではないでしょうか。

復旧の見通しは立っていないとのことですが、少しでも早い復旧を願っています。影響を受けたみなさまは、本当にお疲れさまです。

▲118　▼34

=+=+=+=+=

こういうシステムにかかわったことあるのでなんとなく想像つきますが、準備も、異常が起きた時の対策も事前に思いつくものは全部用意して対応していたと思います。特に公共インフラのシステムは「それいる？」って思うくらいの準備と対策を用意して挑んでます(だからこそどうしても工数かかって高くなるんですが・・・それはまた別の話)。それでも、今回は起きてしまったのでしょう。現場にいるエンジニアの皆さん、頑張ってください。

▲20　▼0

=+=+=+=+=

確かに多くのシステムトラブルは、改修やアップデートで発生することが多いです。これはどれだけ検証を行っていても、実際に実行しないと判らない不具合がある為ですが、ただ、一般的には、失敗した場合は中止して即座に前のバージョンに戻すことが多いのですが、戻せなかったという事なんでしょうね。とはいえ、もう少し規模を抑えて、少しずつアップデートしなかったのは、これまで問題が起きてこなかったという事でしょうか。

▲3　▼0

=+=+=+=+=

まぁ変える時期が難しいのはわかる。普通なら深夜に切り替えだけど、深夜はトラックがわんさかくるし、平日でこれが起きると仕事に支障がっていう人が出てくる。じゃあ今回みたいに土日にすると行楽目的でよくわかってない人たちが巻き込まれるからトラブルになった後の対応が面倒そう。電車は動かない深夜という時間でできるけど車は動かない時間なんて存在しないからなー。難しそう。

システムの云々は検証結果からわかるから今はなんとも。ただ、検証にはバックアップもしくは前のシステムに戻せなかった理由まで追求していかないとだね。

▲14　▼2

=+=+=+=+=

同じインフラの電車とかのトラブルは改札開放て感じでなかったかな、今回のあとから支払えは交通渋滞は関係ないものとはいえ原因がゲートトラブルなのでなかなか。徴収のやりかた議論適用とする前にやれる判断はあった気がしますね。

そもそもこのようなミッションクリティカルになるようなものは改修も本番相当の開発環境で試験しているのでないの？また万一の切り戻し計画もあるものでは？内情はわからんがどこが問題で、その要因は、は情報通信業界全体のためにも明確化してほしい。

▲9　▼3

=+=+=+=+=

システム改造によるETCの障害と言う事で、確かに夜中から朝に掛けてそうした作業をされている時に、システム自体に何らかの誤作動が起きてしまったのかと思います。そうした事が起きてしまうのも、やむを得ない所はあるかと思いますが、障害が起きてから18時間もの経過した現在に置いても復旧出来ない事は、お客の立場からすれば、何とかして欲しいと言った事やお怒りや苦情があってもおかしく無いかと思います。いずれにせよ、こうした事を起こさないようにする為と言った事や、復旧をいかに迅速に済ませるかが、課題では無いかと思います。

▲19　▼13

=+=+=+=+=

今朝ETCの件を知らず、八王子で高速に乗る前に一般道で渋滞にはまったので、あきらめて高尾山まで移動しましたが、そこでは渋滞はそれほどでもなかったので比較的早めに料金所に着きましたが、ETCが故障しているとかで券を受け取って、高速からの一般の出口でETCでの清算について確認をするように伝えられました。

出口では、障害圏外だったためか券を渡してETCカードも渡してETCで処理ができました。

▲25　▼6

=+=+=+=+=

皆さんおっしゃるとおり、切り戻し計画策定と本番切替を失敗したらフォールバックが基本中の基本なのですが・・・・もしかするとIT屋さんの悲しき性で、なんとなくここが怪しいからフォールバックするよりも切替後の新システムでのバグの扱いとしてその修正に走ってしまい、どんどん深みにはまり、その間に戻すに戻せない状況になっているんじゃないですかね。フォールバックしていればさほど時間をかけずにできるから利用者側への影響も少なかったと思います。あと個人的には切替タイミングとして翌日は利用の多い土曜深夜にやります？と。いずれにせよ一刻も早い復旧と今回のミスを踏まえてのリリースの在り方をよく検討することです。

▲89　▼28

=+=+=+=+=

銀行ATMシステムの不具合も同じようにソフトウェア更新時に

発生しているということは、プログラムに不具合があったという事ではないでしょうか。システム会社も納期に煽られ途中のミスも

気が付かないほど忙しい状態であったと想像されます。

普通は立ち上げ前にトライアルを繰り返すはずですが、見切り発車

であったのか振り返って欲しいです。

▲10　▼5

=+=+=+=+=

他の方もコメントされてますが、通常は万全に万全を期して改修＆リリースするものですが、最近はエンジニアリングコストも高騰しており、下請け孫請けに丸投げして仕組みもよくわかってないエンジニアが実際の作業をしたのかもしれませんね

ひ孫請けシステム会社くらいになると外国人（主にアジア）も多いですし、問題は顕在化していても解決できないといったところなのかもしれません

技術そのものも広範囲の知識を求められるようになっており、AIを駆使しても求められる最低の知識、経験レベルは年々上がっているように感じます

大手システムインテグレータだと、1ヶ月のエンジニア料金は200万を超えるところも出てきています

システム改修などをとことん値切る会社さんも見かけますが、正直オススメはできません

特に金銭の決済が絡む部分は、実装内容も含めて細かく精査、計画できる人材が必要です

▲99　▼20

=+=+=+=+=

深夜料金変更に伴うシステム変更かぁ。大がかりな変更でもなさそう。でも小規模でもなさそう。そんな中規模程度のリリースって、リスクを過小評価して小規模リリースの手順でやってしまいがちなんだよな。リスクちゃんと見ていたら切り戻しポイントを設定し、データの静止点が明確になっており今頃復旧しているはず。復旧困っているってことは、十分なリリース、切り戻し計画ができていなかっことだと思う。同じような社会的システム見ているので、自戒もこめて。担当者頑張ってほしい。

▲45　▼11

=+=+=+=+=

現在お使いの一部のETC車載器は最長

2030年頃までに使えなくなります。

現行のセキュリティに問題が発生した

場合は、変更時期が早まる可能があります。

お客さまのETC決済情報を、将来にわたり

安全に保護するためセキュリティ規を変更

するそうです。

車載器管理番号19桁の左詰めの数字0から

始まる機種が対象になります。

車載器管理番号の確認皆さんしてください。

▲26　▼16

=+=+=+=+=

ここ最近クラウドを経由したりなんなりと色々複雑になり過ぎている知らないところでどこかが変更されたら影響をうけるそれを知らずにシステム点変更したらうまくいかなかった等々より良くしようと複雑化しているけれど機械製品と一緒でシンプルな構造のものは壊れにくいし直しやすいそして長年信頼して使うことができる

▲4　▼1

=+=+=+=+=

関係者の皆様は大変だと思いますが、早期復旧を行っていただき、原因を究明して今後の再発防止につなげてほしいと思います

▲1　▼0

=+=+=+=+=

今回のＥＴＣ障害は、前日に実施されたシステム改修と時期的に重なっていることから、当該改修が一因となっている可能性を否定できません。現在、改修に伴うシステムコードや設定変更の影響範囲を精査しており、原因の特定と復旧作業を最優先で進めております。改修プロセスの事前検証体制やリスク評価手順についても、今回の事案を受けて再検討する方針です。

▲1　▼5

=+=+=+=+=

システム障害、大変だったと思います。不手際があった部分は今後しっかり見直してほしいですが、現場にいた人たちは本当に冷や汗ものだったはず。

自分もシステムを管理する立場なので、ああいうときの緊張感や焦りは痛いほど分かります。

頭が真っ白になり、動悸が凄くなり、パニックになったことあります。

関わった方々、本当にお疲れさまでした。

▲21　▼23

=+=+=+=+=

戻しテストしたかとか言うけど、システムは戻せても車はゲートに入っちゃったんだから戻せないし。生産ラインとは違って厄介だよね。止めればいい訳でもなし。普通のITと比べて簡単に行かないよね。

復帰までの間の入場、退場トランの扱い、精算データとの整合と判断をどうするか？整理が難しそうだ。

どこまで事前にケース設計してあったか？対応されてる方々お疲れさまです。

▲16　▼4

=+=+=+=+=

高速道路は単なるNEXCOの金儲けの手段ではなく、日本の物流や人の移動を支える重要な社会交通インフラである。なので、ETCシステムのトラブルが発生した時点で、NEXCOが社会システムを支える役割を担っている立場であることを優先させ、速やかに料金所ゲートを全面開放すれば、大規模な混乱や渋滞は防げただろう。システム障害が渋滞を発生させたというより、実際は、大トラブルが発生したにもかかわらず、NEXCOが社会システムを円滑に機能させる使命よりも、自分たちの金儲けの方を優先させ、現代の高速道路の課金システムの中心であるETCがダウンしてしているにもかかわらず、何とか利用者からカネをとってやろうと料金徴収に固執して車両のスムーズな通行を許さなかったことが問題を大きくした。災害や大規模なシステムトラブルは今後も発生しうる。国はそのような場合は社会的使命の方を優先させるよう明確に指導すべきだ。

▲209　▼14

=+=+=+=+=

現場で復旧に当たられている皆さんお疲れ様です。

該当エリアのドライバーの皆さんも不便でしょうが、

渋滞による追突事故も起きているようです。気をつけて。

思ったのですが、こうしたトラブルが発生した日は、

一時的に無料で下りていただく措置で、渋滞を緩和できた気もします。

NEXCO各社との費用調整は国土交通省の取りまとめで。

▲2　▼0

=+=+=+=+=

インフラシステムなんだからディザスター対応はやっておかないとダメなこと

冗長化、問題発生時の切り戻し、どうしてもダメな時のアナログ対応の運用方法、これくらいの計画は立てないと安定システムの入れ替えはやっちゃダメ

今回は深夜価格対応のことだから、テストをやりまくっての対応だったはずなのに、なんでこういうことが起きるのか

原因作ったシステム会社かメーカーは原因究明と対応策をちゃんと報告してほしい。

▲4　▼1

=+=+=+=+=

24時間365日稼働の基幹システムなら「もどす」なんてなかなか出来ることじゃないですね。

ただ、今回問題が起きたのはETCゲートのシステムのようで、メーカーや世代によるものなのかいくつかのパターンがあるようですね。

記者会見の一部を見ましたが、問題の起きたＥＴＣゲートは出られなくても、理屈では問題の起きていないゲートに行けば問題なく出ることはできるといっています。

高速道路のシステムは全くわからず書いていますが、発生するトランザクションを管理する基幹システムは今回関係ないでしょう。「出」の際に「入」の情報を参照し、料金計算を行うところで問題が発生し、料金計算が行えなかったことからゲートが開かなかったのではないかと予想します。

不正な方法で高速道路を利用し、ETCゲートを出ようとしたのと同じ状態かと。

ゲートに関わるシステムなら戻すことも考えられると思います。

▲4　▼1

=+=+=+=+=

システムエンジニアの検証が甘かったとしか言えないが、料金に関わることだと本番一発勝負しかできないのでしょうけど、検証用のETC仮想料金所みたいな施設は無いのかもしれない

たぶん旧料金と新料金の割引で4/1からの新と3/31までの旧の料金の複雑な料金体系と割引システムの剥離でほんの些細なプログラムミスなんだろうけど、システムエンジニアの腕の見せ所ですね

▲14　▼12

=+=+=+=+=

私も、この影響を受けました。

朝乗る時はOK

出る時に、係員に促されゲートスルーしたが、ETCエラー音発生

用事が済んで、同じICから乗った時は一般レーンのみ

東京料金所では、あとから支払いするのが面倒くさいので、一般レーンで往復分申告して処理してもらいました。

次乗る時に、エラーでゲート開かないかも。と思ったら、先に申告して払った方が良いと感じた。

▲28　▼3

=+=+=+=+=

本来高速道路は速達料金を支払うことで、一般道利用では決して到着できない短時間で目的地に到着することができる優れたインフラ。

JRだって2時間以上列車が遅延すれば速達料金である特急料金は払い戻しになるのだから、今回の様に100%事業者側に原因があるケースでここまで遅延損失を生じさせたのであれば、料金を請求するべきではないのは明白。

▲62　▼4

=+=+=+=+=

切り戻ししたくても簡単に出来ないような部分をイジったのかな？

このトラブり方だとETCって典型的な中央集中管理型のシステムなのね。

料金所単位で独立した形態にして疎結合で全体と繋がるようなシステム設計にしていたらもっと被害が小さくて済んだかもな。

確かに切り戻し計画も大切だけど、そもそもトラブった際に被害を最小化できるように考慮して設計しなきゃダメだよね。

▲5　▼5

=+=+=+=+=

携帯電話会社や鉄道会社や銀行で、システム改修直後にトラブルが発生した。

このとからもNEXCO中日本は事前に検証すべきところを怠ったのかそれとも想定外の出来事だったのかは分からないが、明日からトラックなど物流が動き出す。

今夜中に解消しないと大変なことになる。

早く復旧してほしいね。

▲3　▼1

=+=+=+=+=

要は今までのシステムから新しいシステムに入れ替えたんだと思うけど、そりゃ今までのシステム管理をしていた世代が多く抜け、そのシステムを読めない人が残ったらシステムを０から作る訳だし、何かしらの障害(ただのバグ)が起きるのは当然だよね。

普通の会社なら、そのシステムを後輩に伝えていくものだが、現在の日本社会は年齢で切っちゃうから、いきなりシステムを読める人が居なくなる。

結果こういう事象が起きる訳だ。銀行のATMも同じさね。

▲34　▼13

=+=+=+=+=

日曜日の重大障害、現場のエンジニアには同情するけど、やっぱりリスク管理のレベルが落ちてるよね。

24時間365日稼働し続け、常に大量のトランザクションが処理され続けるシステム、システム更新時にひとたび重大障害が発生したらそう簡単には切り戻せない。

コストカット、短納期を追うよりも、もっと大事なことがあることを思い出してほしいです。

これは現場よりも計画側、経営側の問題ですね。

▲22　▼2

=+=+=+=+=

システム障害は仕方ないとしても対応が悪かったです。

国立府中インターに入るのに1時間かかり、開けているゲートはひとつだけで、窓口の方は後日支払いの通知と封筒を渡すだけでした。

こんな状況でも支払いはさせたいんだなと思いつつ、この書面と封筒を渡すだけならもっと人員を増やせなかったのかなと感じましたね。

12:00頃、再度国立府中インターに入る事になりましたか、その時はゲートはフリーになり、足止め無し渋滞無しで本線に入れるようになりましたが、今さら遅いわ

▲59　▼8

=+=+=+=+=

飛行機でも発生していますが、2025年の崖と言われるエンジニアの不足によりこの様な事態は今後ますます増えてくると思われます。適切なシステム投資により、切り戻し可能な構成でシステムを作れる組織づくりが必要です。

▲8　▼1

=+=+=+=+=

ロールバックがどうだとか、事前検証がどうだとか、御託を並べてますが、24時間365日切れ目なく稼働し、ものすごいトランザクションを捌くシステムの切り替えをやったことがある人だけが語ってほしいものです。

高速道路なんて切り替えのために利用を止められるものではないですし、切り替えてからしばらくしてからトラブルが発生しての切り戻し、しかも既に大量のトランザクションを捌いたあとなので、うまく切り戻しできたのでしょうか。切り戻し中も高速道路は止まりません。泣きたくなりますよ。

多大な不便をかけたが、死人が出るような問題ではない。納期と複雑な計算への変更と現行ロジック残しつつの切り替えをしなければいけないし、上層部はシステムの都合なんて考えずにサービスの変更を決めて宣言してしまうし…インフラを支えているすべてのエンジニアに幸あれ…

▲44　▼38

=+=+=+=+=

システムトラブル起きたら無料で降りれるようにすればいいのに。

システムトラブルが原因なのに、高速に入ったは良いが出られないって問題になってんだし、出口を無料にすれば少なくとも利用者には迷惑かけないで済むと思うんだがな。

そりゃ、収入が減るってもあるだろけど、交通事故とかと違って自分達のトラブルで渋滞になったんだし。その挙句に料金は後日に振り込めって用紙を渡すんだから余計に混雑するでしょ。

閉鎖したと思って無料開放してれば、トラブルもだし不満も減るだろうに。

▲162　▼7

=+=+=+=+=

この会社の「入札情報公開システム」の詳細を見てみたところ、(株)日立システムズが運営しているようです。今回のシステム改修に（株）日立システムズが関わっているのかどう分かりませんが、お粗末としか言いようがありません。実際にシステム改修に関わっていた事業者も記者会見に同席されていたのでしょうかね？

　一般的なシステム改修の場合、利用者の少ない時間帯で作業をするものですが、計画策定や事業者選択を含めて問題があったということでしょう。

▲36　▼18

=+=+=+=+=

今は時間帯で割引要否を判断しているから、そこまで複雑な仕組みではないと思うが、変更後は、時間内の利用と距離の問題が絡み合い、難しい仕様になっているんだろうな。

お上の考えた複雑な仕様に巻き込まれて、SEの皆さんも大変だと思います。

これを機に、分かりやすく全国一律現行より3割引にして、無駄なシステム変更にコストをかけずにしたらどう？

▲6　▼1

=+=+=+=+=

NEXCOは高速道路インフラを国民に提供する義務がある。

料金を徴収することは義務ではない。

ETCが故障したなら、ゲートを無料開放し、交通網の提供を優先させるべき。

料金徴収に拘り交通マヒを起こしたNEXCOは社会的責任を果たしていない。

次から同様のことがあった場合は、ゲートを開放するマニュアルを作られたい。

▲5　▼1

=+=+=+=+=

原因はなんであれ

可能性としてはシステム障害は起こりうるものだ。

問題は、やむなく起こったものならば

顧客に多大な迷惑をかけている渋滞という問題解決に対して

仮に当日の通行料は度外視してでも

何故、全てのゲートを解放するなどの思い切った解決策が

即断できなかったのか???

多くの顧客に迷惑をかけてまで、自分たちの利益を最優先に

守ろうとする行為が許せない。

▲2　▼0

=+=+=+=+=

リリースマネージメントとして、ロールバックしても利用者に影響ゼロなら、リリース成功かつ要再リリースとして扱う場合と、ロールバックは即リリース失敗と判定する2パターンの管理方法がある。

ロールバックを失敗と判定すると、どうせ失敗だからと影響回避の細部が雑になる。

このケースはわからないが、大規模障害を起こすシステムは根本的に冗長化が足りない。

▲7　▼5

=+=+=+=+=

高速道路を使うことはあまり無いが、確か、自分の記憶では、発足時、つまり１９７０年頃ですが、将来的に全面的に無料化するという政策だった気がします。

それが、いつなのかは分からいが、こういうトラブルが起きたときは、その間無料にし、フリーウェイ化するべきだと思う。

東北の震災時に首都圏で真っ先に動いたのが丸ノ内線。

その時は、無料開放でした。

▲7　▼1

=+=+=+=+=

CRWDと同じことになってしまいましたね。

システム更新作業での不具合は、多くの方々に迷惑がかかります。

でも、テスト段階で問題がなかったのかな？

実際問題、結合時に予期せぬことも大いに発生することもあるので、システム更新って大変だなぁって思います。

▲5　▼1

=+=+=+=+=

ETCでの通行履歴がシステム的に追えない（既に通行した事のログ、証跡が残らない）状況が発生していて、その料金の計算も出来ないという、最低最悪の事態。

全銀ネットとかであった「一時的に処理が出来ず滞留するが、後で整合性はとれる」のと大きく異なるケース。

聞いた事がない。

該当区間をETC車載器搭載車が通行する場合は「料金を徴収しない」と宣言すべき。

▲6　▼1

=+=+=+=+=

そもそもシステムに問題が有り料金を支払う側に迷惑をかけているのに料金を徴収しようとしている事はありえない。フリーパスにしてシステム復旧まで無料にするべきだと思う！例えば映画を観に行って映画館の都合で予定時間に放映出来ないのに通常の料金を徴収している！または買い物に来ている客に商品を提供出来て無いのに料金だけ支払わせているような物！対価を満たしていないのに料金だけ求めているのは常識で考えても理解出来ない！有料道路に高い料金を支払って乗るのはそれだけのコストパフォーマンスを求めてるのにそれを提供出来ないのに支払いだけを求めるのはどう考えてもおかしい！料金を支払う対価が出来て無いのに何故料金だけは徴収しようとしてるのか普通に考えればわかるはず！

▲10　▼0

=+=+=+=+=

神奈川6区の古川なおき衆議院議員が「期でもある国土交通省の高見大臣政務官に連絡したところ、開放するとのご連絡をいただきました。」などとまるで自分の手柄かのようにポストしていたが、同期だろうと一連の対応のまずさ、責任追及などもしっかりやってほしいですね。

▲1　▼0

=+=+=+=+=

ＥＴＣシステムも機械だから故障する事は有る。

但し、ＥＴＣの故障で渋滞を起こした場合の損失は高速道路が払うべき。

上空からの写真を見れば誰でも分かる。一番良い方法は、「ＥＴＣが故障した時はゲートをフリー（無料）にするという事」だ。

法律で作ったら良いと思う。これくらい普段渋滞を我慢しているドライバーへの気遣いだ。

▲1　▼0

=+=+=+=+=

ETCのゲート部分のシステム保守(端末だけなのかは分からん)をやってるトコは知ってて、かつ、その仕事を名古屋でしないか!?と誘われたこともあるんだが、運用やシステム開発・改変・改修をそこがしてるか迄は知らんのだが、やってたらエライことにそこはなってるんだろうなと思う。しかし、バックアップなんて事もシステム変更・改修などのソフト対応なんかテストしてから運用してると思うんだが、ここまで復旧のめどすらたたんことなんかあるんか!?と不思議に思う。それと今回の事故と思われる状況で発生した損害は個人も企業・団体もあるはずだが、どんな賠償責任を施行するんかな!?個別に対応するにしても損害を被った側がその損害の証明とかしないとアカンのだろうかね。今後同じような状況に陥った場合のユーザー対応くらいは表明して欲しいなと思う。

▲0　▼0

=+=+=+=+=

前日の4/5土曜日にシステム入替して4/6の日変後すぐシステムダウンしたらしいけど、どこのシステム会社に委託してたんでしょうか。自社で独自にシステム更改できるほどの専門部署を持っているとは考えられないので、銀行等ではNTTデータ、日立システム、富士通、IBMなどですが、どこなんでしょうか。

そこがいい加減な作業をしたという事だと思います。

他の方も書いていますが、大きなシステム更改する場合は現用システムと待機システムに分けて事前に試験環境でテストを繰り返して問題ないと判断してから更改作業に入ります。それでも予期せね重大なトラブルが発生した場合はフォールバック判定会議を開いて切替や切り戻しを判断して、最悪の場合は前世代のシステムに戻すのが常識です。切り戻しにこれほどの時間がかかるのは異常です。もしかしたら切り戻しのための前世代のシステム情報を保存してなかったのかも分かりません。

▲5　▼1

=+=+=+=+=

ファームウエアの更新でもしていたら基板交換だろう。でも、その基盤が古い型で製造終了、在庫なしであれば丸ごと交換かな。IT技術者とか言っているが素人同然で経験も足りない人が多いですからね。テスト不十分でしかないだろう。稼働出来るものと出来ないものがあるのですから、基盤の型が違うのに全てのハードでテストをしてないんでしょう。これが日本のITの現状じゃないの。

▲0　▼1

=+=+=+=+=

中日本だけがトラブルだけど、他のところは本日のシステム改修はしていないのかな？

これだけ酷い渋滞を発生させた原因が会社側のミスなら、無料開放すべきだじゃないのかな、渋滞の解消にも役立つし。

そもそも企業側責任による消費者への保証が、逆の立場であった場合と格差がありすぎるとも思います。

▲77　▼7

=+=+=+=+=

復旧の見通しが立たずってシステム改造前にリストアするなり、バックアップは取っていなかったのでしょうか。

少なくとも改造というか改修しているのなら、普通は取っている物かと思いますが。。

まさか切り戻し手段無く、対応に踏み切ったということは今のご時世ないと思いたいですね。

▲2　▼2

=+=+=+=+=

今回に限らず　銀行ATMの大幅なシステムの改造には大抵このような　障害が発生しうる　大幅なシステムの改造を行う場合　デッドラインは現実的に想定し　障害が発生した場合　最悪　現状に戻す等　想定が甘いのではないかと思う　過去に　似たような事例が何度も発生しているのに　まったくその教訓が生かされていない。

▲36　▼9

=+=+=+=+=

現場で働いている人としては、管理はとでも大事なことを理解していますが、

現場の人の意見も少し聞いてほしい

特に、報告の内容と実際に発生していることが大きな隔たりがあることを認識してほしい

▲14　▼1

=+=+=+=+=

こういうのって事前にテスト環境で試して、エラーとか潰してから本番環境に着手するし、もしトラブルが起きても前の状態に戻せるようバックアップのようなものを取っておくものだと思うんだけど

特にこんな影響の大きいシステムなら尚更慎重に行うべきはずネクスコもだけど、受注したシステム会社の問題が大きいと思う

▲3　▼2

=+=+=+=+=

最近はETC専用に切り替わるICが増えスマートICは始めからETC専用です、システムに不具合が発生すれば大動脈に甚大な影響を及ぼします、人件費抑制は理解しますが併せてシステムメンテナンスには十分な金をかけて対策してもらいたい。マイナンバーカードも不具合が度々発生してますが不具合により迷惑を被るのはいつも利用者です。

▲10　▼1

=+=+=+=+=

0:30頃から出口で発生ということは、

出口の割引計算をしようとしてエラーが発生した可能性が高いと思います。

旧割り引きなら、出入り口を通過した時間を見て、

割引するかしないかを判断するだけでしたが、

新システムだと、22時～5時の間に走った区間を調べて

そこに対して割引を計算しなければならないので、

その辺が怪しい気がします。

走行経路を判断するプログラムが、

新設したセンサーの情報を知らずにエラーになったとか、

新設したセンサーの識別情報が間違っていて、

あり得ないルートになっていたとか、

そんな理由じゃないかな…と思います。

簡単にロールバックできていないところを見ると、

データベースも損傷しているのではないかと。

▲3　▼0

=+=+=+=+=

開発環境：システム開発を行う環境

ステージング環境：本番環境とほぼ同じ状態の環境でシステムの動作や不具合のチェックを行う段階

デプロイ：開発中のシステムを本番環境へ移行して実際に稼働させる

本番移行：開発環境からステージング環境で開発と検証を行い、リリースを行っても問題なければ本番環境（本番機）へ移行する

本番機移行前での検証がすっ飛ばされてたから、手順やリスクが不十分だったか、そもそも検証と本番機との環境差がありすぎたのか

そういった部分をきちんと整理して次に活かして欲しい

▲25　▼44

=+=+=+=+=

エンジニアの腕が悪いとも言えるが、システムの改修にはトラブルがつきものなのも常識ではある。

何処かを改修すれば何処かで不具合が起きる可能性が出てくる。

障害がハッカーの攻撃によるものでなければ、

エンジニアたちがトラブルを想定しきれなかったことが唯一の事実となるだろう。

▲9　▼9

=+=+=+=+=

どうせカレンダーと連動した料金算出プログラムに変えたのだろうが、ソフトウェアだけなら料金算出プログラムを戻すだけだからこれほどの長時間停止はありえない。

あわせて、ハードも刷新したのでは？

予約情報など何もないシステムであることを考えると、ハードも含めてシステムを刷新したか、または

ドラ割などとの精算処理が辻褄合わなくなってしまったか、のどちらかだろう。

予約など無く、入ったインターと出たインターをカレンダーと時刻の割引率にマッチした料金を算出するだけ。

センサーは高精度だろうが、お粗末すぎるな。

いくらかけて刷新したのだろうか。

▲3　▼1

=+=+=+=+=

当然システム切り替えには相当な準備と最悪の事態を考えたはず、最悪の場合はもとに戻すことも準備をしていたとは思うけど、それすら受け付けなかったのか。復帰するまでは無料開放とかの手段を取らないと物流はもちろん経済的損失が大きすぎるんじゃないのか

▲0　▼0

=+=+=+=+=

ランサムとかマルウェアが原因だと、リカバリが難しいけどそうではないんですね。

システムを運用する立場からは明日は我が身。

起こってしまったことは仕方ないので、関係される皆様、いち早い回復にむけて頑張ってください。

▲5　▼10

=+=+=+=+=

値上げで得ようとした利益はこのシステム障害で吹き飛びそうですね。止められないシステムの改修は大変です。切り戻し考慮するならどこかで高速乗り入れ停止させないと。トランザクションがある以上切り戻しは困難になる。システム担当者は悪くないというか懸命に頑張ってるんだと思う。多分運営、経営側がシステム開発に対する理解がなさすぎるのが原因じゃないかな。日本の経営陣のITシステムに関する無関心、無知レベルは致命的に思う。システム担当はヒエラルキー的に言われた環境の中で如何に最善を尽くすかって感じになってしまっているのご現状なんですよね。経営へのインパクト考えたらシステム部門はもっと発言権を持っていいと思う。

▲3　▼0

=+=+=+=+=

システム改造ってタイトルすごい違和感あるわ。

メーカーが作ったシステムを他の人が変更したら、それは改造行為にほからならいけれども、メーカー自身がアップデートで変更したのは、それは改修でしょうよ。システム改修って名前に変更すべきだと思うが？

まぁ切り戻しが十分じゃなかったのもあると思いますけど、切り戻せないものもあって、それで戻せなかったのかもしれないなぁーって思いますね。

銀行システム考えると致命的に分かりやすいですが、ある時点のデータやシステムを一式とっていても、決済部分の金にあたる部分もデータで、これは切り戻せないんですね。

それでシステムだけ戻すと、新システムで少しの期間に入れたデータが残っていると、改修前システムにしたときに想定外の未知のデータがあるので、戻したも誤作動するか、別のバグ発生になるんです。

だからシステムとデータは一緒に戻すのが鉄則なんです。

▲14　▼2

=+=+=+=+=

日本は銀行等システムのプログラムの改善をすると必ずシステム障害を起こし復旧するのにはかなりの日にちや時間がかかり大変迷惑をかける結果と成りますが日本人はプログラミングには他の国と比べては劣勢で採用するプログラムを慎重に見極めて採用するのが賢明です。今回のシステム障害も同じです。

▲4　▼1

=+=+=+=+=

ETC障害だけで無く、ネクスコ中日本とネクスコ東日本とでは仕事のやる気が違います。

去る大雪による通行止めでも安曇野IC以北(ネクスコ東日本管轄)は素早く除雪をして開通しましたが、安曇野IC以南(ネクスコ中日本管轄)は除雪する気配もなく、それから2日経ってから開通しました。

その時私は長野から名古屋に高速道で向かう途中安曇野ICで強制的に降ろされました。

降ろされる時に本来進むべき道を見たら手付かずの積もったままの道でした。

▲1　▼1

=+=+=+=+=

高速道路って、システムを継ぎ足し継ぎ足しして使ってるから、もうね、何が何だか解らなくなってる部分も有るんだろうな。

それこそ、検証では出てこない、想定外のトラブルが起きたり。

それこそ、１ヶ月くらい無料開放して・その間に全システム、全料金所の機器を再点検したらいいとおもふ。

▲0　▼0

=+=+=+=+=

午前中、小仏トンネルから八王子料金所まで2時間半かかりました。

1台ずつ料金を徴収していました。そりゃ時間がかかるわけです。

午後になって紙（後日支払い）を配るようにしたみたいですが、それを大量に印刷して用意するのも時間がかかったはずです。

渋滞なんかよりも、自分たちが料金を徴収する方を優先させたわけですよ。

▲72　▼3

=+=+=+=+=

深夜割引対応と言うことはソフトウエアの可能性が高い。

何をしようとしていたのか?改造に問題があってシステム全体の停止に至ったと言うことは、改造に何らかの矛盾や無限ループを起こす要因が含まれていた可能性もありそうだ。

データ絡みの無限ループはロジック追ってもなかなかわからないからね。

簡単な改造だと高を括って、アナウンス無しで改造適用した事をあわせて考えるとその線が濃厚か。

あるいは、改造で接続したシステムから誰かが侵入したか。いわゆるサイバー攻撃か。

担当者らは復旧するまでストレス半端ないでしょうけど、開き直って落ち着いて復旧にあたって欲しい。

▲5　▼5

=+=+=+=+=

ETC割引を適用しない場合は現金かクレジットで支払いで、適用したい場合は後ほど送られてくる書類等で支払いするんだっけ？

取り敢えず運送会社とかバス会社は書類等の記入、申請にかかった経費を請求したらいいんじゃないかな。

▲18　▼2

=+=+=+=+=

今は知らんが、昔は公団様に日本の大手上位のシステム会社が、毎年持ち回りでシステム改修をしてました。

ネクスコ中日本、昔の東三管とか東二菅の管轄だったとこだね。

恐らく、今年請け負ってるシステム会社も看板だけだし、団塊世代がいなくなってるので、システム全体を把握できてる人がいないんだろうね。

現場の末端の人たちは一生懸命だと思うよ。

▲4　▼0

=+=+=+=+=

最近の業界体制見れば起きてもおかしくないなと思いました。早速にやらせすぎるからだと思います。どんな影響が発生するのか良く考えてやるべきだと思います。ETC程度だから済むけど、中には取り返しがつかない事もあるからね

▲7　▼4

=+=+=+=+=

ETCの様な大規模システムなのに、ハードやネットワーク異常時に切り替えて運用する、バックアップシステムは用意されていなかったのか？

重要なシステムの改修をする場合、まず本番機で改修システムを稼働させ、不具合発生時には旧システムのバックアップシステムに切り替えて運用する。

本番機での運用で問題がない事が確認できたら、バックアップシステムも新システムに移行して、本番機のバックアップに復帰する。

私は元ＳＥ・PMで公官庁・金融・JR等のシステム開発や改変を多数経験して来たが、

システム改修時のリスク運用計画の策定はしていなかったのか？

▲3　▼6

=+=+=+=+=

今回だけでなく、銀行やインフラなどのシステム障害って

大体直前にシステムの改修や更新を実施して、その直後から

不具合が出ますよね。今回の件もシステム改修したのでは？

と思っていたので、やっぱりかと思いました。

更新を実施する前に、もっと綿密にテストをしないと。

▲33　▼12

=+=+=+=+=

銀行等がシステム改変わ行った直後にシステム障害が発生する事案が相次いである。

大きなシステム改変を行う場合は利用者に予告するよう法律で義務付けるべき。利用者は利用を控える等対策を講ずることが出来る。

▲0　▼0

ＥＴＣシステム障害、前日に行ったシステム改造が関係か…復旧見通し立たず