ATOS, あるいは運行管理システム
ATOS, or train traffic control systems

よく止まるJR東日本

国鉄時代にも、 国鉄の電車は周辺で競合する民鉄に比べるとよく 「止まって」 いた。 これは、 車両の故障発生頻度がはるかに高いなどの技術的な理由が主だったように記憶している。 JR化後多少の変化はあったものの、 現在でも同様な状況が見られる。 例えば、 小田急新宿から御殿場線経由で沼津へ抜ける特急 「あさぎり」 に乗ると、 小田急線内から御殿場線に入ると急に速度が出たように感じる。 新宿付近はともかく松田に近いほうでは小田急線の速度も高いはずだから、 これは小田急線の線路の保守状態がいいために動揺を感じず、 スピード感がないためと考えることができる。

ところが、 JR東日本ではここ5年ほど明らかに様子がおかしい。 ある時期から、 中央線で飛び込み自殺が多くなったという噂が立った。 実際、 乗客からみると 「1週間ダイヤ乱れに遭遇しなければ運がよい」 という程度まで輸送の信頼性が低下した。

いくつかの対策がなされたものの、 その後も状況は大して改善されないまま現在に至っている。 9月3日には、 ついに関東運輸局から同社の社長に宛てて警告が発せられたそうだ。

この間唯一良くなったことといえば、 事故があったときに速やかに近隣民鉄への振り替え輸送の手続きが取られるようになったことだ。 ちなみに、 JRから民鉄への振り替え輸送は頻繁にあるがその逆はあまりない。 「運転協会誌」 の振替輸送関連の座談会で参加している民鉄の人が 「当社がJRに振り替え輸送を依頼することはあまりないので」 という意味のことを言っているのを読んだことがある。

というわけで、 JRのトラブルについては一般の新聞記事も多くなったからそれらを参照されたいが、 そうした報道の中で最近目立つようになったのが ATOS と名付けられた同社の運行管理システムの名称である。

運転整理…失われた経験と「カン」

一般的に、 ある事故や故障の結果、 列車が動かなくなるとか特定の箇所で不通区間が生じるとかした場合、 以下のようにすれば影響をより狭い範囲に食い止めることができる。

1. 不通区間等がある状態で健全な列車が動けない範囲を可能な限り狭くする。
2. 動き出してから通常の状態により早く復するようにする。

さて、 上に掲げた2項目のうち 1. については、 適切な場所で折り返し運転をする、 駅での線路の使用方を変更するなど、 いくつかの手を組み合わせて列車をなるべく広い範囲で 「動かす」 ことを考える。 もうひとつの 2. は事後処理であり、 これまたいくつかの手を組み合わせつつダイヤをなるべく速やかに通常のものに復することを考える。 「運転整理」というのはふつう 2. の事後処理のことだけをいうのかも知れないが、 本来両者は渾然一体であり、 1. での指示がまずければ 2. にも悪い影響があるはずであり、 その逆もまた然りである。 従って、 以下ではこの両者を特に区別せずに「運転整理」と呼ぶ。

この「運転整理」をうまく行うためには、 列車ダイヤをその場の状況に合わせて即座に変更し、 しかもそれを関係するところに間違いなく伝えなければならない。 しかし、 列車と列車が行き違ったり、 追い越し／待避をしたりすることができる場所は限られている。 車両や乗務員のやりくりにも様々な制約がある （車両の例でいえば、 新幹線の「ひかり」号用の車両は「のぞみ」には使えないとか）。 これらをすべて含めきっちり計算した上でダイヤを変更するのは容易ではない。 仮に変更ダイヤができたとしても、 これを関係箇所に間違いなく伝えるよい手段が電話や列車無線などしかないことも多い。

このような制約のもとでうまい運転整理ができるのは、 結局のところ運転指令員の経験と 「カン」 に基づいた適切な指令があってのことである。 日本の鉄道は、 通常時の列車ダイヤの正確さに関しては世界に比類ないレベルを誇るが、 いざ事があったときの運転整理はあまり上手とは言えない。 それでも、 少なくとも従来はもう少しマトモな運転整理が行われていたように思える。 ところが、 問題が起きている首都圏路線における最近のJR東日本のやり方は、 「何かあればまず当該線区の列車を全線にわたり止める」 というものにかわってきてしまった。 複々線化等が進んでいるため、 これをやっても波及する線区をあまり増やさないで済む、 という特殊事情のもとで、 指令員が楽な方法を取ろうとしているようにしか思えなかった。

この背景に、 経営危機に見舞われた国鉄時代末期の採用抑制の影がある、 という話も聞いた。 指令員はダイヤを変更する指令を出すわけだから、 それなりの経験とカンを積んだ人でなければならない （指令員が若造では指令された側の人がいうことを聞いてくれない、 などという話もあるようだが）。 しかし、 現場業務でもありあまり年齢の高い人のやる仕事でもないらしい。 ということで、 社員の世代構成に「断層」が生じているというのである。 このような事情から延々と引き継がれてきた経験と「カン」が失われた、 というのはいかにもありそうな話である。

ATOS類似のシステムは古くからある

運行管理システムというのは一定した定義が難しいが、 列車の位置の確認と追尾、 実績列車ダイヤの記録などのほか、 事故・故障とはいえないレベルの様々な外乱 （例えば、 乗客数の不均一やドアにものが挟まったこと等に伴う停車時間のばらつき） にさらされながら走る列車群がスムーズに動くよう列車相互の関係等を調整したり、 運転整理を行ったりするシステムのことと理解しておけば良さそうだ。 なお、 より広義に列車ダイヤや車両・乗務員運用計画の作成等の運転取り扱い全般を含め 「運転管理」 と呼ぶことがあるようだ。

ATOS に関するJR東日本自身の解説を見ればわかるように、 ATOS を非常に簡単にいうと、 センターにあるコンピュータで列車の運行を制御するものである。 すなわち、 もっとも基本的な部分は鉄道工学の教科書にある列車集中制御装置、 CTC (centralized traffic control) の一種と考えることができる。 列車を制御するといっても、 列車の速度制御等は運転士が行っているから、 地上側のこの種の設備がやることは主として進路の構成 （簡単にいうと分岐器切替え） と、 進行信号を出すタイミングをはかることである。 CTC も、 古いものは数10年前から存在している。

CTCが行うこれらの作業は列車のダイヤがわかっていなければ実行不可能であり、 列車の位置も同時にわかっている必要がある。 一方、 運行管理サイドからも、 列車の位置情報はほしいし、 運行管理における意思決定の結果列車ダイヤが変更されればそれを即座に CTC の制御に反映させたい。 駅の案内情報も、 これにあわせて更新してやれれば便利だろう。 というような発想で、 こうした一連の仕組みを統合したシステムに向かうのは自然の流れといえる。 PRC (programmed route control) などといわれるこの種のシステムも、 一部民鉄で TTC や ARC などという名前でかなり以前から実用化されているし、 新幹線用にも COMTRAC という名称の類似システムが稼働している。 ATOS も基本的には、 こうした先発のシステムと機能的には似たようなものである。

ただ、 この種のシステムが扱う CTC 的な機能以外の 「付加的な」部分は、 時代を追うごとに拡大している。 運転整理を含む運行管理やそれに伴う列車ダイヤ情報のやり取り、 列車の位置情報の管理と追跡、 駅にある旅客案内装置の制御などは、 こうした付加的機能の代表例であるが、 言葉で記述すると同じであっても、 コンピュータの性能向上によりできることは飛躍的に増えてはいる。 最近のものでは、 車両の保守にからむ情報までこのシステムに取り込んで管理しているケースもある。 基本となる運行管理部分でも、 信号による情報以外に、 乗務員に対して 「何秒待て」 等の指示を直接与えるようなシステムも考えられている （このための表示器は head wall timer などと呼ばれるそうだ）。

このような動きは、 「運行管理」 から、 より広義の「運転管理」 全般を取り込むべくシステムが成長しつつあるということなのだろう。 ただし、 ATOS がどこまでやっているかはつまびらかにしない。 保守関係のデータは恐らくまだ取り込まれていないと思うし、 乗務員へは駅係員からの放送等による指示が唯一の手段であるように見える。

JR東日本のホームページでは、 ATOS のページはカテゴリとしては「新技術」の中に入れられている。 JR東日本としてはご自慢のシステムであるらしい。 いうまでもなく、 従来あるものを集大成し、 しかも規模拡大する、 というためにはいろいろな技術課題があったのだろう、 とは思う。 しかし、 こうしてこのシステムを外野から見ていると、 何がそんなにすごいものか首を傾げてしまうところがある。 その感じ方のギャップは、 鉄道における情報化が極端に遅れていたことから来るものだろう。

決定的に遅れたコンピュータ導入

基本的な列車ダイヤは毎日ほぼ同一だが、 臨時旅客列車・工事用の列車・回送列車等は不定期に設定され、 それに伴う時刻や着発線路の変更は全体の2割に上るそうだ。 そして、 各現場がそれらの1つ1つについて間違いなく把握をしていなければならない。 それができないと、 通常の最終列車の後にもう1本列車があるのを忘れて保守作業員が線路を外しはじめ、 そこに列車が突入して脱線事故を招く、 というような種類の間違いの原因になる。 地上の係員だけでなく、 運転士が信号を読み間違え、 進入すべきでない線路に入ってしまうようなことも起きるかも知れない。

ところが、 信じがたいことにこの種の変更を連絡する手段はつい最近まで 「運転報」 という分厚い印刷物を現場に配ることだったというのだ。 この 「運転報」 には、 変更が行われる全列車についてのすべての情報が網羅されており、 各現場では、 これまた信じがたいことだが、 この分厚い印刷物から自分の職場に関係することを1つ1つ拾い出して確認する、 という作業を毎日行っていたという。

ここまで書けば、 ウェブを手繰ってこのドキュメントに到達された読者の方ならお分かりと思うが、 「運転報」のような前時代的なシステムから、 コンピュータにダイヤを入れてその都度取り出すシステムに変更してしまおう、 というのが IROS の目的である。 恐らくは、 「運転報」の情報を拾い出す作業のかわりに IROS のボタン(?)を押すと、 その日の列車ダイヤに関する情報が、 しかもその職場に関係する部分だけピックアップされて取り出される、 というイメージに変わるのであろう。 それにしても、 ネットワークの複雑さや運転本数の多さが民鉄とは比べ物にならない、 という特殊事情は斟酌すべきであるにしても、 わずか5年ほど前の状況がこんなふうであるというのは、 信じがたい遅れといわざるを得ない。(注1)

(注1)…… 鉄道が特にコンピュータを毛嫌していたというわけではない。 例えば、 MARS の初期のシステムは世界的に見てもまさに黎明期に登場したオンライン・ コンピュータ・ システムとして記念すべきものである。 しかし、 列車の運行に関する部分は、 信号システムという形でシステムが早くから確立していたことの反動から、 このような前近代的なシステムが残ったということなのだろう。

TTC などの PRC を先行して入れた民鉄の一部は、 おそらくこのような状態を早くに脱していたと思う。 後発の ATOS は既存の運行管理システムのいわば「通常進化」版であり、 規模の壮大さを除けば、 革新的と自慢できるような技術はあまり盛り込まれていないように感じる。 そうであれば、 技術の集大成らしく完成度の高いものであってほしいと思う。 それにもかかわらずこのようにトラブルが頻発するのは、 あまりの規模の壮大さゆえ、 といまは解釈しておくことにしたい。

もちろん、 最新の運行管理システムだからバカにしてはいけない。 最近営団地下鉄が全面的に使用を開始した新しい指令室では、 指令員の指示を待たずともシステムが勝手に時隔制御 （列車と列車の間隔を制御し、 いわゆるダンゴ運転になるのを防ぐ） を行うアルゴリズムが組み込まれている。 世界的にも最先端を行くシステムである。 ATOS の実物は見たことがないが、 恐らくはこのような新しいアイディアはきっちり盛り込まれていることと思う。 列車遅延が数10分にも及ぶような大きなトラブルが続いていると目立たないが、 従来朝ラッシュ時によく見られたような列車運行の10分以内の乱れは、 恐らく ATOS の導入で頻度が相当減ったのではないかと思う。

ATOSが列車を止めてはいけない

このシステムは、 進路制御などコアとなる CTC 部分を除けば、 それ以外の運行管理システム等は実は 「なくてもよい」 システムだということを指摘しておくべきだろう。 すべての係員が当日のダイヤを、 IROS でなのか運転報でなのかはともかく承知していて、 すべての列車が（大きな）トラブルなく運行しており、 進路制御の部分がローカルに壊れていなければ、 こんなシステムがなくても列車はきちんと走る。 列車がこういうシステムに依存せずサービスを継続できるように、 これらのシステムの存在がなければどうにもならない、 というレベルまでシステムを使い込むことを意図的に避け、 従来の鉄道のようなやり方で走っている、 という言い方ができるのではなかろうか。(注2)

(注2)…… 埼京線のPRCは開業当初トラブル続きで、 開業後の何日かは駅で手動に切り替えて運行していたのを覚えているが、 特にラッシュ時など作業が輻輳する状況下では手作業ではうまく行かず、 列車はじりじりと遅れていった、というのを記憶している。 通常時に PRC 前提で運行している線区で PRC が動かなくなれば、 そういうようなことは当然起きるはずなので、 「なくてもよい」とまではいえないのかも知れない。 しかし、 「なければならない」 というのとは大違いである。 ソフト連結のように人間には実現が難しい高度な運行をするのでなければ、 手動にすると列車がスムーズに流れなくなるというのは 原理的には慣れの問題のはずなのである。

以前、 JR東海の新幹線指令室に見学のため学生を引率していったことがあるが、 その席で学生の1人から 「指令員が何もしていない」 とかいう指摘があって先方を慌てさせたことがあった。 なかなか鋭い指摘だが、 何事もなければじっさいするべきこともないわけである。

また、 ふつうはコアの CTC 部分も含めこの種のシステムがなくても安全な運行はできるようになっている。 これは、 列車の安全にかかわる部分は保安システムに任されているからだ。 列車と列車の間隔は短くなりすぎないよう信号システムが管理している。 必要に応じて列車の速度を落としたり列車を止めたりする保安装置 （自動列車制御装置、自動列車停止装置等） もある。 進路を構成するというのがもっとも危険をはらむ仕事だと思われるが、 この部分は「連動装置」が面倒をみている。 こうしたシステムはいずれも、 軌道回路等からローカルに得られる情報を元に危険側動作を抑制する働きがある。 フェールセーフといって、 故障した場合はとにかく列車を止める動作をすることになってもいる。

従来は、 駅に人間がはりついていてローカルに制御を行い、 駅と駅の間の情報のやり取りは比較的疎であった。 現在 ATOS に取り込まれている旅客への情報案内や駅構内の進路制御なども、 センターとのデータ回線ががっちりつながっていなければダメということはなく、 列車ダイヤさえセンターからダウンロードできれば 近隣の軌道回路などからローカルに得られる情報だけで それなりの仕事ができるはずなのである。

ATOS がコケて列車が止まる、 ということは、 保安システムと同じ「フェールセーフ」、 すなわち異常があれば列車を止めてしまう、 という思想をこのシステムにも持ち込んでしまったのかも知れない。 いうまでもなく、 運行に異常が発生したときに運行管理システムがコケていれば、 復旧に時間を要する、 というようなことはあろう。 しかし、 以上のようなことを考えれば、 運行に特に異常がないのに、 ATOS 自体に異常があっただけで列車が止まる、 という設計ではおかしいはずなのだ。

魅力的な鉄道になるためのインフラとしてのATOS

IPASS コンセプトについてはいずれ別なページで詳細を述べようと思うが、 これが目指す鉄道システムとは、 例えばこんなサービスを実現する鉄道である。

利用者が川崎市の市街地のどこかに立っていて、 これからどこかに行こうとしている。 彼（彼女）は手持ちの携帯端末を取りだし、 センターに電話をし、 行き先（例えば東京都心・霞が関）を告げる。 センターからは、 約5分後に近隣の電停に電車が来る、 との連絡があり、 通話が切れる。 携帯端末の画面にはその人の現在位置と電停の位置とを含む地図が描かれている。 指示された電停に行くと、 センターからの案内通りの時刻に電車がやってくる。 携帯端末には座席番号が提示され、 この電車が霞が関まで直通することも併せて示されている。 この電車は霞が関まで途中4回程度の停車だけで、 約35分で到着した。

こうしてみれば、 ATOS はこのような夢の鉄道 （高木としてはあまりに現実的で夢っぽい感じがしないくらいだが） に向かう第1のステップ、 これを構成する最低限のインフラのひとつとして位置づけることができる。

それにしても、 一気に IPASS が描く「夢」まで到達せよとはいわないにしても、 1990年代も終わろうかという現時点で導入される ATOS には、 もう少し頑張ってほしい内容がまだまだ多い。

まずは、 当然これまでに記述してきた問題点を解決し、 本来運行管理技術の向上により事故の影響範囲を局限化するシステムが、 列車を止めるなどという本末転倒なことが起きないようにすることだ。 これについては、 9月3日に受けた関東運輸局からの警告に応える形で、 システムの安定性を高めるための改良をすすめているとのことだから、 近々実現するのだろうと期待している。

ただし、 このようなシステムの導入によって完全に経験と 「カン」 が排除できるわけではないことに注意しよう。 運転整理ダイヤの作成は、 紙に印刷されたダイヤ上で鉛筆で作業して作成する形態から、 コンピュータとの対話作業になったが、 これでもまだ経験と「カン」の世界である。 これについてはもう少し高いレベルで自動化することが求められる。 もうひとつ、 運転整理ダイヤの作成には復旧までに要する時間を予測することがぜひ必要だ。 しかも、 この予測精度は高ければ高いほどよい運転整理ダイヤが引けるはずなのである。 これについては当分の間システムに頼ることはできず、 現場で修理等に当たる係員の能力に依存するしかなさそうに思える。

もうひとつ重要な改善点は、 ATOS によっても 「密なデータ通信ネットワーク」 のかやの外に置かれた様々なサブシステムを結合することだろう。 例えば、 駅など地上設備相互間は光ファイバ等で結ばれたようだが、 肝心の運転台と指令員の通信は相変わらず列車無線だけ、 というのはあまりにさびしい。 列車ダイヤの変更は、 走行中の列車にこそ即座に連絡できるシステムを構築すべきではないだろうか。 それによって列車ダイヤの動的な変更の機動性は飛躍的に高まるはずだ。 また、 「みどりの窓口」 で切符の販売に活躍しているシステム MARS は （別会社だから、 ということもあるのかも知れないが） このシステムと無関係となっているようだ。 もちろん、 通勤電車が主たる対象の ATOS では MARS は当面あまり関係ないかも知れないが、 ATOS の対象となるサービスが順次拡大していったときに 果たしてそうあり続けるので良いだろうか。

乗客自身もいまのところ ATOS の「かやの外」である。 しかし、 携帯電話のようなツールも普及してきたことだし、 ATOS が持っている情報をインターネットのウェブ等に流し、 必要に応じて誰でもアクセスできる形にしておけば、 乗客自身がシステムから情報を直接受け取ることができるようになる。 ここまでいけば、 もう IPASS コンセプトとして我々が提案したことのいくつかが実現したことになる。

「コンビニ」や宅配便の隆盛をみれば明らかなように、 鉄道においても情報技術が今後の死命を制することは間違いないと思う。 現在はだいぶ評判が悪い ATOS だが、 そのような戦略的な位置づけを得て今後に向けて飛躍することを祈るばかりだ。