各種のコラム -- ３ー１４８ 北陸新幹線、この先どうなる？？
２０２４年９月２５日
３ー１４８ 北陸新幹線、この先どうなる？？
北陸新幹線の新大阪までの延伸をめぐっては、与党のプロジェクトチームが福井県小浜市を通って京都駅に南下する
「小浜・京都ルート」で建設する方針を決め、来年度中の着工を目指しています。
しかし、建設費について精査を進めていますが、資材や人件費の高騰などからこれまで見込んでいた
２兆１０００億円程度から５兆円近くに膨らむ可能性があり、工期も従来の１５年から３０年近くに大幅に
長期化する可能性があるそうです。
「敦賀・米原ルート」なら、工事費は、１兆円以下で済みそうです。これからしばらくは人口減少社会です。
長期間の多額の投資はもう一度見直してみる価値がありそうです。日本は国債の発行残高のＧＤＰ比が高いといわれます。
しかし、国は通貨発行権をもっているので、発行残高そのものは問題ではないといわれます。
それから、国債について、建設国債はかまわないが、赤字国債はよくないといわれます。
家計であれば、住宅ローンはかまわないが、ギャンブルや飲み代を借金で払うのはよくないと言われます。
これは、住宅に長期間住むことと、返済に必要な収入が得られることが前提になっています。
建設国債はかまわないといわれますが、これは、建設した固定資産が、長期にわたって収益を生むことが大前提です。
固定資産は、減価償却を通じて費用を発生するものであり、資産は、過去の事象の結果として企業が支配し、
かつ、「将来の経済的便益が当該企業に流入すると期待される資源をいう。」という前提が成り立たなくなった時には、
減損損失を計上することになることを十分に考慮する必要があります。団塊の世代が後期高齢者になるなかで、
介護費用をまかなうための赤字国債も計画的に発行されることを前提として必要不可欠とされる一方、
建設国債なら無制限に発行して構わないという考え方は改め、新規の固定資産の建設よりも、既存の水道施設の
耐震化など、保守管理に重点をおいた長期修繕費の支出を中心とする姿勢に改めなければなりません。
「小浜・京都ルート」の建設費が、５兆円かかるとしても、中央リニア新幹線の建設費は、東京〜大阪間では、
１０兆円位になるだろうという人がいます。しかし、一日、５０万人近くの人が利用する東海道新幹線と
一日、３万人位の人が利用する北陸新幹線では、将来の収益性が違います。中央リニア新幹線については、
環境への影響を十分に考慮した上で、建設して、羽田空港と関西地区の空港の発着枠を開放するほうが、
全国的な都市間輸送の発達に寄与すると思います。
「敦賀・米原ルート」で問題となるのは、所要時間が長くなることですが、これは、米原駅で乗り換えではなく、
列車が直通運転できる設備を建設すれば解決します。運転本数が多い東海道新幹線に北陸新幹線の列車が乗り入れる
余裕がないといわれます。しかし、新大阪駅の２４番線か２６番線に到着する、「さくら」は鳥飼車両基地に回送に
なります。これを米原まで運転するのは問題あるのでしょうか。それから、新大阪駅に２７分に到着する新大阪終点の
「ひかり」と３０分に到着する「のぞみ」は、どちらかが、引き上げになりどちらかが鳥飼車両基地に回送になることが
多いですが、３０分に到着する「のぞみ」は、臨時列車として博多まで運転されることが多くあります。
その日は、新大阪から米原まで営業列車を設定することが可能ではないでしょうか。さらに新大阪終点の日は、
姫路まで回送で運転し、１３番線で折り返せば、毎日新大阪から米原まで営業列車を設定することができます。
このようなやり方で、１時間あたり２本営業列車を設定し、米原始発の列車を１本設定すると、ほぼ現在の
北陸新幹線のダイヤと同じ本数になります。
また、国交省は北陸新幹線の東海道新幹線乗り入れは運行管理システムの違いから、技術的に困難と考えているそうですが、
東海道山陽新幹線と九州新幹線は運行管理システムが異なります。東北新幹線と北海道新幹線も運行管理システムが異なります。
東北新幹線は、ＪＲ東日本の「ＣＯＳＭＯＳ（コスモス）」で管理しており、北海道新幹線と青函トンネル内の貨物列車は、
ＪＲ北海道の「ＣＹＧＮＵＳ（シグナス）」で管理しています。ＣＯＳＭＯＳ 運行管理システムは、指令所に設置される
運行管理中央装置と、各駅に設置される駅進路制御装置を広域光ネットワークで接続した駅分散型の自律分散システム
であることが特徴で、東京圏の在来線を管理しているＡＴＯＳの運行管理システムと共通の発想です。
それに対して、ＣＹＧＮＵＳ運行管理システムは、東海道山陽新幹線のＣＯＭＴＲＡＣの運行管理システムと同様の、
運行管理機能、指令業務の支援機能および進路制御機能を指令所に配置した中央集中型のシステムです。
ＣＯＳＭＯＳもＣＹＧＮＵＳも、当日ダイヤの変更が必要になった時に、列車の走行実績とあらかじめ登録された駅間走行時分などの
定数から未来の運行状況を予想し、指令端末上にダイヤスジ形式で表示するダイヤ予想機能を持っていることは共通です。
ＣＯＳＭＯＳのシステムは、東北新幹線など、ＪＲ東日本の新幹線の運行管理を行う、大宮総合指令所が、北陸新幹線の
上越妙高の駅を出発するまで管理し、上越妙高〜糸魚川間の本線から、敦賀までは、ＪＲ西日本金沢総合指令所が管理を
行う、１システム２司令所の構成になっています。ダイヤ予想機能とＪＲ北海道内でダイヤが乱れた時に、北海道新幹線と
青函トンネル内の貨物列車両方の状況をみて、新青森に列車が到着する予測時刻を管理する、統合出発順序機能を使って、
必要な情報を、ＣＯＳＭＯＳのシステムに通知することで、東北新幹線と北海道新幹線の直通運転が成り立っています。
仙石線と東北本線を直通して、仙台〜石巻〜女川を直通する仙石東北ラインの列車は、当初は、仙石線から東北本線に乗り入れる際
一旦停車して、仙台総合司令所に連絡をとっていましたが、仙台総合司令所のシステムのリアルタイム・バーチャル基盤の
上に、東北本線の司令と、仙石線の司令が統合されたことで、一旦停車の必要がなくなりました。
この、リアルタイム・バーチャル基盤上には、非常時には、東北本線の司令にも仙石線の司令にも転用可能な、
訓練用の司令システムも稼働しています。
このように、列車の直通運転を考える時、運行管理システムは重要な役割を果たします。
しかし、運行管理システムの違いから、直通運転は出来ないというのは、物を決定する順番を間違えています。
ＩＴ技術の進歩は早いので、土木施設を建設している間に、新しいシステムを開発すべきです。
新しいシステムの開発・移行が喫緊の課題になっているのが、最近チルド食品の出荷停止でも問題となった、
ＳＡＰ２０２７年問題です。ＳＡＰ２０２５年問題と言われていたのが、２年伸びましたが、
問題の本質は変わっていません。大企業を中心として、会計・経理などのシステムとして、ＳＡＰは広く使われています。
ＳＡＰ社が、従来のシステムに変わって、インメモリーＤＢを装備し、秒速でデーター分析を可能にする
ＳＡＰ Ｓ／４ ＨＡＮＡのシステムに移行すると発表したのが、事の発端です。インメモリーＤＢは高価で、
ＳＡＰ Ｓ／４ ＨＡＮＡはクラウドでの使用が基本になります。
従来のシステムは、セキュリティーのパッチは、２０２７以降も提供されますが、新しい機能の追加はありません。
会計・経理のシステムは、新しいリース会計基準への対応や、営業利益の計算ルールの変更に伴う、
財務諸表の表示形式の変更など、常に新しい機能の追加が必要になります。
現在ＳＡＰを使っている企業の選択肢は、３つです。
従来の（現在の）システムを自分でメインテナンスして、機能の追加を続ける。エレベーターの管理会社が
行っているような方法です。しかし、エレベーターは、同じエレベーターが動いている限り、
システムの機能の追加は必要ないのに対して、会計・経理のシステムは、常に新しい機能の追加が必要になります。
ＡＢＡＰ（ＳＡＰ用のプログラミング言語）をまったく理解しない私はとてもやろうとは思いません。
２番めの方法は、パブリック・クラウドで、マルチ・テナントモードで、ＳＡＰ Ｓ／４ ＨＡＮＡを使う方法です。
ＯＳやミドルウェアーも含めたシステムの更新から、新しい機能の追加まで、すべてＳＡＰ社が行ってくれます。
これを機会に業務手順を、システムテンプレートにあわせた業界のベスト・プラクティスに変更し導入するという
ものですが、それほど簡単ではありません。例えば、ＪＲ貨物であれば、アボイダブル・コストという
貨物列車の走行がなければ発生することのなかったコストのみを旅客鉄道会社に支払うためのコストの計算が
必要になりますが、アボイダブル・コストの内訳はレールの摩耗に伴う交換費用、架線張替えの費用などの項目があり、
さらに、架線張替えの費用などの電路保守費の修繕費用であれば、トロリ線は旅客と貨物のパンタキロの比率、
トロリ線以外は旅客と貨物の列車キロの比率で按分するなど他の会社で使うことはまずないだろうという項目が満載です。
ちなみに 列車キロとは、駅間通過列車回数に駅間キロを乗じたもの、パンタキロは、列車キロ × １列車当たりのパンタグラフの数
で、ＥＨ５００「ＥＣＯ-ＰＯＷＥＲ 金太郎」では、交流区間や、直流区間でも荷物が非常に少ない時に、
パンタグラフをひとつだけ上げて走っている時は、コストが少し安くなります。
さらに線路保守費の計算では、
換算車両キロ ＝ 車両キロ（※） × 積車状態にある車両の総トン数の１０ 分の１ ※車両キロ ＝ 列車キロ × 各列車の編成車両数
などの項目があります。
そして３番めの方法は、プライベート・クラウドで、シングル・テナントモードで、ＳＡＰ Ｓ／４ ＨＡＮＡを使う方法です。
ある程度カストマイズも可能で、少し料金は高くなるが、良いとこどりの方法と言われますが、
やってみるとシステムのハードウェアーがなくなるだけで、ソフトウェアーの構成や保守を自分でやる必要があって、
悪いとこどりになることがよくあります。
そもそも、会計・経理のシステムを、なぜインメモリーＤＢにしなければならないのかが、私は理解できません。
株の高速取引なら、だれが考えてもインメモリーＤＢは、必須です。しかし、会計・経理のデーターを使った
経営分析は、いくら大容量といっても容量に制限のあるインメモリーＤＢに保存されたデーターをつかって
高速で分析するより、１日２日かけても、ほぼ無限の容量ともいえるＳＳＤに保存したＤＢのデーターを
使って分析するほうが有効ではないかと思います。企業間の専用回線をつかって行われていた通信を、
インターネットをつかう方法に変えるなど、課題はたくさんあっても、新しい方法に変更することの意義を
理解している時は、何とかしようと思います。何のためにこんな事をするのだろうと思うのとでは大きな違いがあります。
もし、私が、会計・経理システムの担当者なら八方塞がりですが、
実際は私は現在はシステム管理に関わっていません。実際に会計・経理システムを担当している人の間では、
すでに方向が見えているかもしれません。
ＪＲ貨物をはじめとする多くの鉄道会社では、車軸に車輪をはめる時の圧力が高すぎるという問題が起きています。
圧力が高すぎるという問題が発生していますが、圧力が低すぎるという問題は発生していません。車のタイヤに空気を
入れる時も、そのうちに空気が抜けるので基準値のなかで高いほうにします。それとはまったく関係ないでしょうが、
作業の基準値を決める時、理想の値を決めて、実際にどのようにするかは、作業する人が現場で判断するという、
日本流の基準値の考え方が通用しなくなっています。圧力がいくらからいくらまでなら良いのかを、
車軸も車輪も金属なので、作業時の温度で、圧力が変わるなども考慮して決める必要があります。
さらに、新幹線のような中空の車軸でも問題が発生するのか、圧力が基準値以内なら、車軸の破損や脱線などの
事故は本当に起きないのかを、これを機会に明らかにする必要があります。そして、新幹線で行われている、
走行時の車軸やベアリングの温度の測定や、空気バネの圧力の測定などが、在来線でも有効なのではないかなどを
総合的に検討する必要があります。
最後に、新しいシステムの開発・移行が喫緊の課題になっている、ガバメントクラウドについて考えます。
現在は、各地方自治体に設置した、オンプレミスのシステムで行っている、住民基本台帳の管理などを、
ガバメントクラウド上に設置するというもので、ベンダー・ロックインが無くなり、保守費用が下がり、良いことずくし
という話だったのですが、実態は不明です。パブリック・クラウドで、マルチ・テナントモードだとして、
本当に政令指定都市の横浜市と人口、５，０００人の村が、同じシステムを使うのが効率的なのか、
大きな疑問があります。そして、パブリック・クラウド上の共通のＤＢ内で秒速で処理が完結するのなら、
なぜ、マイナンバーと健康保険証の紐付けに年単位の期間を必要とするのかも不明です。
北陸新幹線なら、素人が見ても、どのくらい工事が進んでいるのか、ある程度わかるのですが、
システム開発の場合、何が起きているのかは何もわかりません。進捗に関する情報公開と透明性の確保が
いっそう重要です。個人の意見ですが、これからクラウドに移行するというのは、「時の利」が無いような気がします。
２０世紀の日本海軍も、日露戦争では、大活躍でしたが、技術的にははるかに進歩したはずの、
太平洋戦争では地の利、時の利を得ることができませんでした。クラウドは、皆がホストの時代が終わり、
これからはＰＣやモバイルの時代だと言っていた時に始まりました。冷静に考えると、ホストのＤＢを
当時のＰＣサーバーで置き換えることには無理がありました。それから２０年経って、クラウドがなくなることは
ありませんが、一区切りの時期のように思います。なぜそう思うかと言うと、ＣＥＯ自らが、偽情報や暴言を載せる
ＳＮＳがあるとか、Ｗｅｂのページを見ていて邪魔な広告が多いという感覚的なものです。
Ｗｅｂの閲覧履歴で、カストマイズした広告を掲示するというのは、登場したときは便利でした。
しかし、最近は、記事が読めなくて邪魔な広告が多く、速攻で消しますが、消したあとで興味があったといっても
再掲示はできません。サイトの管理者は、ページの場所を広告の管理者に場所貸しして、広告の管理者は、
リアルタイムのオークションで、一番高く買う広告を掲示していて、サイトの閲覧記録とは連動していないなどの
事情があります。そういう時代であれば、何がなんでもクラウドだではなく、既存のオンプレミスのシステム
を、フロッピーディスクでデーターを持ち出すのをやめて、セキュリティー対策をして、ネット接続するなど、
個々の事例について、アドバイスやコメントができるだけの能力をデジタル庁が身につけるなど、
複合的な業務の推進を考える価値があります。
地方自治体の人は、具体的に進捗状況や、予算額を把握しているはずなので、もっと積極的に発言する必要があります。
鉄道会社というと保守的というイメージですが、山形新幹線や、「寿命半分・価格半分・重量半分」の通勤電車を
社内の大反対を押し切って実行した人など、まじめそうで型破りなことをする人もいます。
地方自治体にも、意外とまじめそうで型破りなことをする人が居るのではないかと思います。
そして、整備新幹線や、ガバメントクラウドのような公共事業の場合、素人の利用者の、「乗り換えが面倒だった」
とか、「マイナ健康保険証の顔認証が、なかなか認証してくれなかった」「これが駅の改札なら大渋滞が起こる」
などの声が重要です。霞が関の人は、パーフォーマンスで一回だけマイナ健康保険証の読み取りをおこなった、
大臣の意見ではなく、介護施設などを回って、マイナ健康保険証になると何が起きるかを聞き取らなければなりません。