[504]

mailto:

旧

新

Geo日記

Geo雑談

内検索

前

主目次

ATCは無実！東急梶ヶ谷駅衝突事故
信号論理（排他制御）の誤りが原因、手動運転でも衝突

　東急梶ヶ谷駅での衝突事故を「ATCの誤動作」と誤解する解説動画も多数投稿されていて誤りが広く信じられそうな勢いである。それは東急の説明「信号の誤設定」とは全く違う。

　解説記事の間違いの原因は、針路開通を示す信号システムのエラーと、それを直に現示する車上信号表示やATC/ATS強制制動動作の区別が付かず混同されていることである。基本である「信号ステータス」が誤っていれば、その信号に従う運転士もATC/ATSも、信号の指示通り間違ってしまう。

信号系の地上装置、車上装置

　信号、ATS/ATC/ATPを「地上装置」と「車上装置」とに分けて考えれば理解しやすい。車上装置は「車上信号部」と、それに制御される「ブレーキ制御部」だから、今回の事故とは無関係である。
「地上装置」は排他制御で進路構成する「信号論理部」と、それを表示して運転士と車上装置に伝える「信号現示部」があり、今回はこの「信号論理部」にエラーがあって、回送列車の位置が転換禁止・固定されるべき条件にあったのにポイントを転換させて進行信号が出てしまい衝突に至った！

　信号のステータスを地上の灯火で伝えるものが「地上信号」であるが、ATC/ATS/ATPでは更に車上に向けて送信する「車上信号」機能を付加して、車上で強制制動動作や停止信号警告を行うものである。
　鉄道の発明以降、様々な事故を繰り返し経験して、その都度、衝突や暴走を防ぐ工夫がされてきたが、今回の東急梶ヶ谷駅衝突事故では、車上装置には異常がなく、地上装置のうち、列車の在線排他制御に誤りがあり、支障限界範囲に回送列車がまだ居るのにポイントのロックを解除して転換させて上り列車の進路を構成したことで進行信号が表示されて衝突に至った。

P3区間（G3-5)がP3支障限界点より内側で終わっていてロックが解けてポイントが転換し進行信号となり衝突に至る

詳細動作は

　今回の事故に影響する閉塞区間は（右図）、３番線入線のポイント区間P3、引き上げ線（5番線）のポイント区間P5が小閉塞区間を構成していて、その排他制御条件は

ポイント区間に列車が居ない場合にのみポイント転換する
→ポイントの支障限界内に車両があれば、ポイント転換を阻止

のが進路構成の基本規則だ。
　すなわち、ポイント区間P3に車両があればポイント転換を禁止していて、ポイントP3が切り替わらければ上りの針路は開通せず進行信号は出ない様に設定されている。
　ところが今回の現場では、ポイント区間を区分する絶縁G3-5の位置が、支障限界票より内側（ポイントP3側）にあって、車両後端がまだ衝突する位置にあってもポイント転換を許容して進行信号を出してしまって衝突に至った。
　本来なら支障限界内を避けて引き上げ線ポイントP5の在線を含んで３番線ポイントP3の排他制御をする必要があったのを10年間見落としてきて今般衝突事故に至ったもの。
　すなわち誤信号ステータスが原因であり、それを単純に現しただけのATC/ATS、車上信号、運転士は事故の原因ではない。
　10年前の改造以前は、3番線入線ポイントP3のロック区間に引き上げ線ポイントP5領域を含めていたので、支障限界外に抜けるまでポイント切替が抑えられて衝突を防いでいたが、その場合に2番線から引き上げ線への進路構成までロックしていたので、本線から3番線への針路が構成されていると、2番線から引上げ線（5番線）への進路構成が出来なくなっていた。
　その改善を目指した改造だったが、2番線から5番線の針路と、3番線から5番線への針路で排他制御すべき範囲が違うことを見落として、支障限界に抵触する3番線からの分岐区間p3のみにしてしまったのだ。
　再発防止には、連動図を駆使する信号屋でなくても分かる論理チェックリストを工夫して、別系統で点検を多重化する必要があるのかもしれない。同じ方法でのチェックでは別人の点検でも同じ思い違い・見落としを重ねる可能性が大きいのだ。

信号設定ミス他の鉄道各社にも　<2>

　東急梶が谷駅衝突事故の原因が、排他制御条件の誤りという論理構成の「偶発エラー」だったことから、東急固有のエラーではなく他の鉄道会社にも同じエラーがきっと有るはず、と思っていたが、事故を承けた全国一斉点検で案の定、同様の論理エラーが何箇所も発見！（See→囲み記事）

11/13/2025　追記

JR東日本、信号設定ミス２カ所

　JR東日本は7日、東急田園都市線の列車衝突脱線事故を受けた緊急点検で、上越線水上駅（群馬県みなかみ町）と高崎線熊谷駅（埼玉県熊谷市）の在来線計2カ所で、信号の設定ミスが見つかったと発表した。東急では信号ミスが原因だったため、国土交通省の指示で新幹線34駅と在来線865駅を点検していた。

　JR東によると、両駅とも、通常は停車しない線路の分岐器（ポイント）付近に予期せず止まった場合、進入してくる列車と接触する恐れがあった。当該箇所の使用を中止しており、11月中には対策を終える予定。

　京急電鉄も7日、京急川崎駅（川崎市）の1カ所で信号の設定ミスがあったと明らかにした。今後改修を進める。

ＪＲ西日本、信号設定ミス５カ所　東急脱線事故受け緊急点検

神戸新聞　2025/11/5 17:54　 https://www.kobe-np.co.jp/news/zenkoku/compact/202511/0019672156.shtml

　ＪＲ西日本は５日、川崎市の東急田園都市線梶が谷駅で列車同士が衝突、脱線した事故を受け実施した緊急点検で、管内の駅など５カ所に信号の設定ミスが見つかったと発表した。国土交通省の指示を受け、新幹線２５駅と京阪神地域の在来線約２００駅の点検を完了。残る在来線約５００駅の点検を１１月末までに終え、結果を取りまとめる。

　ＪＲ西によると、車両の停車位置によっては接触する恐れがあるのに、近くの別の線路を通る車両に対し停止信号が出ない設定になっていた。

　５カ所は大阪府の大阪環状線天王寺駅、東海道線高槻駅のほか、兵庫県の東海道線芦屋駅、山陽線土山駅、石川県の北陸新幹線白山総合車両所。 (11/07/2025　追記)

　偶発エラーの抑止には、幾つか考え方があり、例えば

数学的問題なら複数の「別解」を求めてそれぞれの結果の一致で検証する
測量計算で、手計算するなら「７桁の対数表」を参照していた時代の、4象限ある角度を総て第１象限（0～90度）に置き換えて、計算表を記して再点検し易くするのが従前の標準的手法。
　しかしパソコン導入の自動測量計算としては、全方向角を「等角写像」計算一発（実質直交座標→極座標→直交座標一括変換）にして、人為的なエラーが入り込まない単純化処理を採用できる。（パソコンには適切だが、手計算したのでは却ってマゴツキ易い）
論理設計では複数種の論理図を作成、比較検討する
鉄道での「連動図」も論理図の一種であり、非信号系人士にも解る別解表記が要るのでは？
実決定者が、内容を良く理解できている体制の構築

　４番目の「実決定権者の理解」は異質、突飛だが、尼崎事故2005/04/25でのＪＲ西日本記者会見映像を見て切実に思った。出席していた安全担当役員が「（尼崎事故防止のキモである）過速度ＡＴＳ機能の存在を知らなかった」と発言するので、それでは全体の最適調整など出来るはずがなかった！現場レベルは当然熟知しているが、上部に改良方針として伝わる道がＪＲ西日本では詰まっていたことになる。後日、安全担当を外れているのは無理もない。
　好対照として、同時季に命令抑圧型労務管理のJR東海は逆に曲線過速度転覆懸念箇所総て全8箇所に過速度ATSを設置済だった訳で、決定権者に必要な情報が伝わっていた。その方針はJR西の信号屋ルートにも相互情報としては伝わって居たはずだがJR西の方針決定者レバルまでは伝わらなかった様だ。 JR西は東中野事故1988/12後の行政指導を受けて10数年ATS-P導入を始めていたしATS-Sｗでの過速度ＡＴＳを17か所設置済なのに、最も危険な条件の尼崎事故現場には設置がなかったのだから、資金不足の問題ではなく、物理的危険度を優先できる解析力・方針が無かった問題だ。

　会社の定期異動で専門外の御仁でも部局のトップに就く国鉄型お役所型人事の会社では、門外漢がトップに来ても妥当な点検・判断が行われる体制をどう作るかが問題になる。旧国鉄が、電気局からの重大欠陥ATS-Sの改善要求を20年以上無視して長期に怠ったのがこれに当る。国鉄から運輸省鉄道局に出向した石原氏らが、S41年に全国配備された欠陥ATS-S/-Bを改める運輸省通達として適切な衝突防御機能を定めた「私鉄ATS機能通達（昭和42年鉄運第11号：1967/01）」を布告して、以降私鉄では重大事故発生を抑えて国鉄に戻り電気局長となったが、その優れた安全方針は文系官僚支配の国鉄ではかたくなに不採用のままで事故を重ねてしまい、国鉄民営化1987/04に際しては私鉄ATS通達そのものを廃止して欠陥ATS-Sを存続させている。国鉄が高機能のH-ATS（後の現行ATS-P）を開発、東海道・山陽拠点4駅に設置したのが西明石ブルトレ過速度激突事故1984年を承けた1986年末。主要路線へのATS-P採用決定がJR化1987/04後の東中野事故1988/12を承けた行政指導に依ってだから、私鉄より22年も遅かったのだ。（ATS-PのハードはJR東西＆東海により経年で改良されて何種類もあるが、その制御コードは基本「H-ATS」で、JR各社合意で機能拡張されて信号部は共通である）

　今回の東急梶ヶ谷駅衝突事故について言えば、信号論理エラーを定期配転の腰掛上司でも気付ける体制をどうつくるか！結果をみれば「連動図も読めない奴が上に来るなっ！」では済まない訳で、別口のチェック方法との併用で、常に独立の多重チェックで同一結論になるよう点検されるべきだ。
　最も初歩的な論理図である「フローチャート」作成・登録を義務付けるだけで、プログラム・バグが激減するのは良く知られているが、複雑なものは表記しきれず却って複雑化したりして、信号専門家の使う「連動図」との間を埋める実用的な別系統チェックリストに依る独立多重チェックは出来ないものだろうか？検討の標準作業が定められていれば門外漢の腰掛け上司であっても判断に責任を負えるようになる。

　「標準」を云うときに、鉄道業界は標準の未制定、現場任せで配慮が欠けて、起こさなくて良い事故を起こしている。例を挙げれば、JR四国が大出力高加速度気動車を導入した際に、加速性能に見合った誤出発防止地上子が必要になったのに、点検リストがなく気付かず無設置で放置し、誤出発列車が安全側線の砂利積みに突っ込んだ事故（JR高徳線オレンジタウン駅脱線事故2015/12/31）。過走防止装置の設置基準がなく、違反の処罰には使えるが、安全確保には無効な設置で大事故となった土佐くろしお鉄道宿毛駅特攻事故（2005/03発生、鉄建公団の設計施工で引き渡し）。70km/h制限304Rの曲線に過速度114km/hで突入して転覆脱線し107名の死者500名の負傷者を出した福知山線尼崎事故2005/04など、いずれも過速度防止装置、過走防止装置、誤出発防止装置の設置・構成基準を明文化していたら起こらずに済んだ事故である。事故後に行政指導が出されていて、それは結構だが、本来であれば過速度防止ATSのハード開発時に、一品生産ではない現場利用の量産機器なのだから、その使い方・設置計算の仕方・点検法のマニュアルは添付すべきであり、様々の課題で日常多忙である個々の現場解析のみに任せてはいけないことだった。

　当方「電気屋」は理工学のあらゆる分野と密接な関連を持つ分野だが、個々の専門分野から「電気屋」を見れば「門外漢の聞きかじり」関与になるので、そうした狭義の電気工学ではないJOBに関わるときは特に慎重に複数の異なる解析・設計計算を行って、その結果の一致で正しさを確認したり、協力する専門人士に確認を求めて複数点検で恐々作業することが少なく無い。やや面倒だが、Wチェック、トリプル・チェックが常態化しているのだ。
　たとえばシールド・トンネル掘進の精密測量で、測量士で常識の標準的手計算アルゴリズムの演算プログラムでは10数ページを要した計算式が、「2」項による計算処理の単純化で２ページ弱に収まって、ワーク・メモリー容量の制限・限界を乗り越え、非常な高機能化が果たせたことがある。研究開発とは異なる実用・実務分野では、要求機能さえ満たせば理論的に最良である必要はなく、人為エラー抑止に定型化された専門人士たちの標準作業をなぞるのが穏当で、信頼性の点で確実である従前の枯れた方法の採用が妥当だが、標準作業では不足の条件：メモリー容量不足、演算速度不足になるとか、まだ専門家の確立していないフロンティア領域では、数学的により合理的なアルゴリズムで大幅短縮を図って要求仕様を満たすことになる。
　門外漢が必要性もなく敢えて標準手法にさからっては手痛くしっぺ返しを食う。土木建築業界は特に長幼の序列の厳しい社会で、電子業界のような「経験の逆ピラミッド」≒技術的下克上などあまり存在しない世界なのだから無闇に逆らってはいけない。新方式は厳密な検証が必要で確実性の保証が得にくく、何より常用処理法に馴染んでいる斯界の先人：専門家たちの納得が得難いから採用が躊躇われていたのを、行き詰まり打開に敢えて採用する動機となる。技術的な外様・素人で標準を識らないからこそ半ば遊び半分もあって複線解析をしてB案C案として「写像案」＋「ユーザー定義関数案」を準備していたからメモリー容量制限に当たっても直ぐに切替えることができた。
　もっとも、斯界の専門家優先の思想は鉄道業界も土木建設業界以上に著しく、他分野からの異論を絶対に許さない御仁も少なく無いので、当サイトも「部外者の戯言」として特に目の敵にされる向きもあって困ったものではある。「ATSに速度照査機能は必須だ」という、現在では常識の命題が、永らく「現場を知らない暴論」と否定されてきた過去はあり、尼崎事故など大事故の繰り返しで国鉄JR界の認識が改善されてきたものだ。
　2チャンネルで世論誘導し反対派を集団で潰していた東労組革マル系などは、波動現象だの微分方程式だのの話題にブチ切れて遮断を策したりしたが、いずれ若手に乗り越えられて職場の主力が入れ替わる。もっとも諸セクトも参謀格は左右を問わず学業優秀者が多かったから、東労組の革マル派だけが分からんチンの「其れなりの人」が集団リンチなどの蛮行を含め職場を仕切っていたのかもしれない。
　振り返れば米占領軍命令で禁止され解雇された大量の航空技術者を鉄道に迎えて高速電車開発にあたり新幹線王国を築いて来た車両などの設計現場では移籍当時から常識の知識・技術であり、工業高校、高等専門学校でも演習付きで教えていて、学部の授業でも「一般力学」で学び、通信工学や自動制御論でも重ねて教えている基礎的・一般的な中身。ゼロ戦の設計に従事しフラッター空中分解問題を処理してきた人達を鉄道技研幹部に迎えて高速電車開発が始まったのに、その解析法を認めない感覚に大きなズレがあるのだから否定のままでは必ず下克上となる。いずれ若者側が分からんチンの御爺側を淘汰するだろう。

　かって、プログラム開発で「構造化」が叫ばれて、他者のメンテナンスを寄せ付けない「スパゲティー・プログラム」排除が図られたが、その「構造化」の真意がなかなか理解・徹底できず、「構造化言語」の採用＝BASIC/FORTRAN否定へ脱線しかかったりした。そこにプログラムの構造的記述の必要性を生ずる。プログラム作成から半年も経つと作成者自身が他人同様になりスパゲティー・ラインに悩まされるのだ。人が替わっても楽にメンテできることが望ましい。だから様々な論理表記も普及して、BASIC/FORTRANでの構造化も浸透していった。
　私自身の経験だが、ソフト開発実務を大量にこなす閃き型のスパゲティー・ラインの制作者に、上長である係長がフローチャートなど論理図添付によるメンテナンス性向上を求めたが、納得されず「割り込み動作多種・多発でフローなど作れないっ」と対立が先鋭化してしまった。上司・部下とも真面目で優れた人材。係長氏は多くの新製品開発を手掛け「組合を抜ければ課長にする」という誘いの不当労働行為を「課長になれば自動脱退の組合規約。いい加減な餌には吊られないっ！」と筋を通していた有能な硬骨漢で、部下への指導内容としては至極妥当なもの。業務実績が有っても、他人がメンテできない製品ソフトを残されたのでは技術組織として困るのだ。
　対立のままでは左遷は目に見えていたので、利害が独立の第三者である「階級的労働組合」専従役員であり、後輩御用組合員たちは登録した技術資料の署名を辿って質問に来るなど一目置かれていた私から、「他人がメンテ出来る様、論理図作成の必要性。３月も経つと自分も他人化」と説得してみたのだが、意固地になっていたようで断固受け入れられず、異動を機に設計業務から外されて自主退職して零細のゲーム開発会社に転職していった。一時使用の閃きで済む使い捨て分野なら放置で良いが、技術蓄積となりメンテを要する工業製品作成では妥当な指導内容なのに説得できず残念だった。
「連動表」が信号屋のギルド手形化してしまうと、他方式も採用した複線チェックは否定されてしまいそうだが、今後、どうなりますか！？　　　（11/10/2025追記）

2025/10/31　23:55

[Page Top↑]

旧

新

前