東急田園都市線で，2025/10/5の夜遅く，普通列車と回送列車が衝突事故を起こした。原因は，ATC（列車自動制御装置）のプログラムミスと発表された（東急田園都市線の衝突事故はなぜ起きた？原因は10年前の「まさかのミス」だった | News&Analysis | ダイヤモンド・オンライン 2025/10/10）。
筆者もスクリプトレベルでいろいろな処理プログラムを作るが，残念ながら理詰めで作るわけではないので，うまく処理できないことが多く，正しい処理に至るまでにも何度も失敗を繰り返す。多くの場合，正しい処理中にも例外事例が発生し，処理が止まったり，あるいは暴走したりする。本来なら，エラーとなる事例も予測してエラー処理プロセスを入れるべきなのだが，自分で使うだけのプログラムなのでエラーが出るたびに止めて例外処理を加えるなどの修正を「後から」加えている。
絶対に危険な状況を作ってはならない交通機関の安全プログラムについては，例外事例の可能性をなるべく多く出し尽くして設計をすべきなのだが，すべての例外を想定するのは困難とはいえ，やはり常に注意して修正を加え続ける必要がある。
今回の事故事例でも，おそらく1m前後の停止位置の設定ミスで，赤信号を出すはずが出なかったと考えられる。たとえば車両の長さやセンサーの取り付け位置などのわずかな差によって，想定外の結果となってしまうのかもしれない。新型車両などの場合も，完全対応できているのかどうか，チェックを繰り返すしかない。
クルマのエンジン制御をマイクロコンピュータで行うことは，当初は非常に心配された。万一，制御できなくなった場合はどうするのか，という意見が多く，導入には慎重だった。いまではエンジン制御どころか，運転そのものも自動制御しようという開発が盛んに行われている。エンジン制御の場合は，基本的には燃焼しなくなり，クルマは暴走することなく停止でき，事故につながるこては少ない。しかし，自動運転で本当に止まれるのか懸念も多い，しかも，そこに同乗しているドライバーの意志が優先されて，そこで電子制御側のリミッターが外れて暴走するようなことも考えられる。
モノづくりの中でも，ハードウエアは世の中に送り出した時点で劣化が始まり，ある時点で故障や破損のリスクが高まるため，定期的なメンテナンスと適切な部品交換・修理が必要である。鉄道やクルマにおけるこうしたハードウエア点検は義務づけられている。
一方，ソフトウエアは出荷時にバグがあったとしても，途中でバージョンアップや入れ替えをして内容を更新することが比較的簡単に実現できる。もちろん可能性の問題だが，バグを抱えたまま出荷されることも珍しくはない。今回の事故も，緊急時の想定漏れが原因だと思われる。
さらに厄介なのが，ソフトの交換時にシステムストップという大きな支障をもたらす危険性もあるということである。これまでも，銀行システムの不具合で取り引きが数日間できなくなった例もある。また，外部からの侵入や，ウイルスの影響でシステムが止まってしまうケースも増えている。
つい先日，筆者の身近で起きたことだが，あす社内システムにちょっとした機能を加えてはどうかとシステム部の人に依頼したところ，翌日にはその機能が追加されていた。最近流行りのノーコードプログラムなので簡単に実現できたのかと思ったのだが，実はノーコードでは実現できない内容だったため，追加プログラムを書いたのだという。そしてなんと，そのプログラムは生成AIにプログラミングをさせ，数ヵ所修正しただけで動いたというのである。プログラムを見せてもらったところ，数十行はあると思われる本格的なプログラムだった。いくら達人でも，これを一発で作成できるとは思えない。
「ChatGPTでプログラミング」はアリ--記号１文字の間違いでバグになるような世界こそ，コンピュータにやらせよう - jeyseni's diary (2023/4/12)と書いたとおりのことが，すでに現実には行われているようである。おそらく，どんなスクリプトでもプログラムでも，生成できるようになっている可能性がある。過去のプログラムのチェックやメンテナンス，追加修正などに生成AIを使うことも考えた方がいいかもしれない。
ただ，中身を解読できなければ意味がない。プログラマーは，プログラミングの知識そのものには磨きを掛ける必要がある。日々進化する技術を取り込んで，プログラムもそしてプログラマー自身も進化していく必要がある。
すでに，少し考え方の曲がった人たちが生成AIを「悪用」している。生成AIにどうやって「理性」や「倫理」，そして「まともな知性」を組み込むか，あるいはその逆に「悪魔」を組み込むかどうかについては，生成AI開発企業の手に委ねられている。そんな状況が世界的に広がっていることが，人類および地球の滅亡につながらないか，懸念している。
