「ああ、半角カタカナかぁ。」と、三菱東京UFJ銀行さんの件でニュースを見ていて、そう気がついた。どうも、このブログ、後出しじゃんけんみたいで、MUFJ関係者の皆様も含めて、みなさんに失礼な気がするが、気になることがあるので、書いておきたい。

銀行の口座情報は、ご承知のように半角カタカナのコードページになっている。たとえば、鈴木一郎さんの口座情報は、

1000 3 987 1234567 1 ｽｽﾞｷｲﾁﾛｳ

といった感じである。口座名義は「スズキイチロウ」でも「鈴木一郎」でもない。コンピュータは無論「 1 」と「 0 」しか判断しないので、「ｽｽﾞｷｲﾁﾛｳ」は、別のデータになのだ。

まだ、ダブルバイトが一般化されていないメインフレームの時代、1980年代初頭に、電子化された口座データを作成し、各金融機関と利用者の間でコンピュータを使ったオンライン接続を実現するために、こういった口座情報や付帯情報が作られた。現在でも、日本の銀行の口座システムはメインフレームで稼働している。

これは全銀協標準プロトコル、全銀手順と呼ばれている。ベーシック手順と呼ばれている標準が作られたのはメインフレームの時代なので、コードページは、EBCDICだ。通信制御はBSC手順、アナログの公衆回線では 2400 bps （なんと！）、ISDNなら64 kbps だ。専用のルーターなどもある。この標準が出たのが、1983 年だが、いまだに現役である。また、1997 年には、「新しい」標準として全銀TCP/IP 手順が出ている。これは、PPP（Point to Point Protocol）である。懐かしいでしょう。

いずれにせよ、銀行口座が半角カタカナのコードページである以上、銀行間の接続では、半角カタカナのコードページと考えるのが普通なのだと思う。銀行の人が、こんな事を忘れるはずはない。今回のように、漢字（ダブルバイト）での情報送信は、口座情報以上のさまざまな付帯情報を追加する、将来を見据えた接続を、MUFJの方々は目指されていたのだろう。

銀行のエンジニアの方々も、それをサポートしているベンダーの方々も、私の知る限り、世界のトップレベルだと思う。したがって、テストしてませんでした、とか、想定外でした、という発言は私にとっては、どうも疑問が湧くところだが、こういうのを「げすの勘ぐり」と言うので、ここでは追求しない。

私が懸念していることは、日本の経済基盤である全銀手順や口座情報が 30 年前の技術の上で稼働し続けていることだ。世の中、クラウド・コンピューティングとか騒いでいる中で、新しい半導体や、OS、インフラがどんどん成長していく中で、成長の止まった技術をいつまで使うのか、疑問だ。

しかし同時に、これら古い技術を最新に置き換えることも、経済的に難しいほどに大きな出費となる。何兆円規模の置き換えになるだろう。さらには、現在のインターネットの可用性では、年間 5 分程度止まるが、今のメインフレームでは、技術が成熟（枯れている？言い過ぎ？）ので、何年止まることがない。

一秒たりとも銀行口座は止まってはいけない、というのが、日本国民の合意のようなものであるから、弊社サンの技術を持ってしても、現状では、これに答えることはできない。第一、皆さんの口座データは全て EBCDIC なので、そのすべてをASCIIに変換するのは大事だ。

日本にしかない、この複雑な構造と問題を解決していくことは、容易ではなく、今後のシステム統合や新しいサービス構築で、銀行口座との連携が必要な時は、ずっとこの問題が追いかけてくるのだ。最上流の工程から、常にこの点に留意することが、現在出来うる最良の手段だろう。