ハイパーインフレ下の金融システムはどうなってしまうのか
はじめに
ふと、ハイパーインフレ下の社会の金融のITシステムってどうなっちゃうんだ？と思ったので、その弊害についてちょっと考えてみる
少なくとも今の日本で、戦前のドイツ並みのハイパーインフレが起きたら現行の金融システムはひとたまりもないのではなかろうかと思ったりする
現行の金融システムはCOBOLがまだまだ現役
さて、現行の金融システムは銀行の統廃合が進んだことやコンピュータの性能向上等色々な時代の流れもあって、COBOLからジワジワと脱却しつつあるが、それでもなお多くの金融機関ではCOBOLをまだまだ現役で利用している。
COBOLベースの金融システムが構築されて実運用され始めるのは、1960年代ごろの話であるから、実に60年ほどの間、長らく運用されていることになる
人間でいえばもうおじいちゃんの年代に当たる言語を、よくもまあいまだにフル稼働させているのは、はなはだすごいとしか言いようがない
狂ってるでしょ（褒めてる）
COBOLの特徴: 最大長（固定長レコード）
さて、COBOLは現代システムから比べればレガシーすぎる厄介言語の扱いを受けているが、その最大の特徴はデータ保持形式が固定長であることに起因しているだろう
まあ、業務でIT技術を扱っているとついつい忘れがちになるが、そもそもプログラム言語は無限の数値を扱えない。
現代の可変長数を扱える言語も突き詰めていけば有限数ではあるが、そういう話をするとややこしくなるだけなので、ここでは触れないでおく
さて、当たり前ではあるが、有限の数値の範囲内であれこれ計算をさせるためには、誤差を考慮しなければならないケースが存在する
例えば、int32型の桁あふれの問題である。
32ビットで整数を表現する場合、2の32乗の数値が表現可能である
逆に言えば、2の32乗の数値が上限となる
2の32乗の数値とはおおよそ約60億であり、32ビットのデータ表現では100億の数値は扱えないことが分かるだろう
これの何が問題なん？と一部の人は思うかもしれない
しかし、例えば、以下のやらかしシナリオを考えれば、ヤバいやつやんと思っていただけるのではなかろうか
預金システムを作ってみよう!!
あなたは預金システムを作る担当者だとしよう
今は、預金者の預金金額の管理をするテーブルを作る場面である
「よし！銀行の預金口座のシステムを作ろう！」
「あ、カラム定義しなきゃ......int32にしとくか!!」
「動いた！やった～！」
このように、預金データを管理するテーブルを作る際には、データ型を定義しなければならないが、そこで何気なくint32型を使ったとする
あ～～～ぶな…………い、だろうか？
いや、最初は、特に何の問題もなく、預金口座システムは順調に稼働するだろう
普通の一般人は1000万円程度しかお金を預けないからである
上限60億を預金でぶち込む人間は早々いないからだ
しかし、悲劇は突然やってくる
ある日、大口の車メーカーが銀行預金口座を開設するという話をあなたは聞いた
そして、その大口の車メーカーは開設記念に、100億円を預金してくれるそうだ
皆は、大喜びしながら、100億円が入金される日が来た
入金！
どうなったか？
......はい、悲劇ですね......
桁落ちなどが起きて、預金口座残高はヘンテコな数値になっているだろう
分かりやすく100億が入金できずに、60億だけが入金されている状態になっていたとしよう
大口の車メーカーの担当者も銀行もおや？ということになるだろう？
車メーカーからすると100億円を入金したはずなのに、60億に減っていたら、俺の40億どこやったという話になるだろう
悲劇の始まりである……
COBOLの固定長の話（続き）
まあ、上の例は非常に極端な例である
実際、int32型で扱えない数値が入ってきたらエラーが発生して、正常に処理されないなどになるので、本当にこのような銀行があったとしても、この場合は口座を2つ作って2つの口座に50億ずつ分割して入金するような運用で難をしのぐだろう
ただ実際に、金融システムの仕様で数値上限が決まっている部分に引っかかる取引があった時に金額を分割して取引するという事例は銀行取引で存在するらしい
この実際の銀行取引が複雑になるケースは、COBOLの固定長に由来するシステムの制約に起因することが多いのだ
言葉で言っても何を言っているのかわかりにくいだろうから、実際にCOBOLで使われているデータフォーマットを見た方が早い
COBOLはこんな形のデータのやり取りをするのである
ABCDEFGHIJ0123456789さて、抽象的に書いたが実際っぽいデータ形式で見ればこのようなものであろう
_DAIKICCHI0001000000これは、預金残高を扱うCOBOLのプログラミング処理の中で出てくる預金者の残高を扱う処理の中で出てくるデータだと思ってほしい
さて、このデータはダイキっちの預金残高は100万円であることが読み取れるであろう
データの構造としては、前半部10桁が預金者のデータ、後半部10桁をその人間の預金残高とするように定義されているのだ
これは一見わかりやすいデータのフォーマット（持たせ方）に見えるが、実際は問題だらけである
前半部の名前は10桁に制約されるが10文字で済まない人間はどうするのか？10文字からはみ出す部分は切り落とすのか？後半部の金額も10桁の制約だがそれだと99億までの数値しか扱えないが、それを超える数値はどうするのか？名前と違って切り落とすことなど出来ないだろうから、想定外の金額が出てきた時にどう取り扱うかを考え始めると非常に頭が痛い内容になることは容易に想像がつくだろう
さすがにここまで小さい桁数のデータフォーマットを設計することはないと思うが、この桁数定義はシステム開発の最初の方で行うため、結構エイヤっ（システム開発用語で仮決めという意味）で決めてしまうことが多かったりする
そして大抵の場合、想定漏れがよく起きる
例えば、フルネームを保存するときに日本だと普通は姓名しか存在しないから何の気なしに固定長の前半部10桁を姓、後半部10桁を名だとするデータフォーマットのデータ定義をしたとしよう
_____KOSEI_DAIKICCHIこれでフルネームは保存で来たぜと考えるのは詰めが甘い
世の中にはミドルネームを持つ人間が存在したりするのだ
例えば、ネルソンマンデラのフルネームを保存してみよう
ネルソンマンデラさんはミドルネームがある
それは、ロリハラハラ、である
結構驚きのミドルネームだから自分はミドルネームの話をする時にマンデラさんの話を持ってくることが多いのだが、話が脱線するのでそれは一旦おいておこう
ローマ字で書いたらこんな感じである
Nelson Rolihlahla Mandelaさて、まず20桁でフルネームを保存できないということもあるが、ミドルネームが来た時にデータを保存するのってどうしようかとなるだろう
考えたらミドルネームがあるなんて当たり前の国もあるのだから、この状況に出くわしたときは、開発時に想定出来ていなかったシステム設計者の詰めの甘さを呪うしかない
ミドルネームだけではない
皇室には苗字がないというケースだって存在する
実際に、皇族が銀行口座を作ろうとしたときに苗字がなくて口座開設の手続きでてんやわんやするという出来事も昔あったらしい
面白珍事である
エイヤっ（決め打ち）で決めるシステム設計は大抵想定外の事が良く起きるが、何かを決めなければシステム開発は出来ないので、エイヤっで決まった姿が今のCOBOLの金融システムなのである
COBOLシステムのしんどさについては何となく伝わったかもしれない
ただ、通常、システム開発者だってバカではないのだから上記で挙げたような金額の上限はもっともっと高い桁数で設定しているはずである
仮に上限を超えるでかいケースが来たとしても、分割するなどして、それに対応する処理を前もって考えているのが普通である
そしてそれは意外とうまく行っている
じゃなければ、日常的に金融システムが止まっていれば、いたるところで銀行の頭取がテレビの記者会見で頭を下げているのがお茶の間の日常の光景となっているだろう（ただし青い銀行は除く）
日常業務ではコケていない金融システムだが、果たしてハイパーインフレは想定されているのだろうか？
では、ここから本題である
今はうまいこと動いている金融システムであるが、ふとした疑問が起こる
それは、ハイパーインフレが起きたら、さっき言った固定長の上限とか余裕で突破するんじゃね？という話である
どんなに頑張っても想定されてる金額の桁数は京の単位だろう
さて、windowsシステムだったり色々なものは、32ビットじゃ少なすぎると言って、64ビットに移行している流れがあったりする
ということは、64ビットはとりあえず大きい数字だから大丈夫という認識がエンジニア界隈ではなんとなくあるかもしれない
int32型じゃチイせぇからbigint（int64型）を使え！もしくはこちらに合わせに行け！という流れが昨今あるように思える
しかし、64ビット整数の最大値はいくらだろうか？
それは、大体100京の単位である
bigintの最大数は、100京である
10の19乗である
だから、COBOLで言っても大体数値型の最大値は20桁くらいで決めているように思われる
ということは、上限は1000京である
大分大きな数字だ
普段の生活でこの桁数の金額が飛び出てくるなどありえない気がする
しかし、ちょっと待て
ハイパーインフレになったらどうなる？
さて、ハイパーインフレで有名なのはドイツやジンバブエだが、このテーマを語るうえでちょうどいいのが、ハンガリーのハイパーインフレである
ハンガリーで流通した、1垓（10の20乗）ペンゲー紙幣、を例に挙げてみよう
当時、1枚、1垓（10の20乗）の単位だったようである
さて、同じように日本円が大暴落して、1枚、1垓（10の20乗）円の超高額紙幣が誕生したとしよう
もはやこの混乱した状況で銀行がまともに運営できているとは思えないが、超ベリーグッドな奇跡が起きて銀行機能が生きていたと仮定する
では、その1枚1垓（10の20乗）円の超高額紙幣を銀行に持って行って、預けてみよう
銀行のシステム担当者の断末魔が聞こえてきそうだ
ハイパーインフレ状態になると常にシステムの数値上限が突破される
さて、銀行のシステム担当者が断末魔を上げる理由それは、システムが想定外の数値を恒常的に受け取りすぎてダウンしてしまうというところにある
おそらく1枚1垓（10の20乗）円の超高額紙幣を取り扱って、預金残高を増やすなんていうことは全く想定していないことなので、その対応にてんやわんやするだろう
しかし、銀行は預かったものはキチンと管理しなければならないので、そのデータは何らかの形で保存するだろう
一番安直なのは
100000000000000000000という数値をそのまま保存することである
しかし、これは出来たらいいけどな～
出来ねぇよ！ボケ！と言われてしまうやつであろう
もしもインフレになったら......システム担当者が行う対処法について考えてみる！
じゃあ、どうするか、システム担当者の気持ちになって対応策を考えてみよう
案1 通貨単位の変更
幸運なことに、金額を保持するデータフォーマットに通貨単位を記載するカラムがあったとします
例えばこんな感じ
ダイキっち預金の場合は、おしりに円がくっついてるパターンですが、ドルやユーロのパターンもあるでしょう
_DAIKICCHI0001000000__YENこの場合は、新しい通貨単位を作って乗り切るという方法を取ります
1枚1垓（10の20乗）円の超高額紙幣の単位をHyperYENとしてHYENなどと名付けましょう
そうすると、以下のようにデータが保存できると思います
_DAIKICCHI0000000001_HYEN円に変換する場合はHYENに1垓（10の20乗）をかければよいので互いに変換できるようになります
ただ、システムによっては、通貨単位を新しく設定して変換するのは、システムを大規模に改修しないといけないケースがあったりするので、この対応策が取れるのはよっぽど簡単に新しく通貨単位を設定できるシステムだけでしょう
実際はそんなに通貨は頻繁に変わる機会はないですし、なんなら円だけの想定しかしていないシステムも多いと思うのであまり現実的な解にはならないかもしれません
案2 通貨単位のカラムがない場合
上記では、通貨の単位で難を逃れようという案だったが、通貨のカラムもないもはやお手上げ状態の場合もあるだろう
その場合の苦渋の選択は、銀行で独自にデノミするというものになろう
金額の円の通貨単位をある日を境に変更してしまうということです
例えば、
2023/12/31時点までは金額100,000,000,000,000,000（円）で入力していた数値は、2024/01/01時点からは金額100,000（インフレ円）として入力しなおします
要は、2024年時点からは金額に入力する数値を10の12乗で割るということをします。
金額カラムに入力されるデータの定義を変える方法です
2023年までのデータは入ってるデータをそのまま円と読んでいいが、2024年からはそこに入っているデータは実は円ではなく、0の値を12個右からカットした値を入れていることに注意が必要になるのです
これはデータだけ見ていると、突然2024年を境にデータが小さくなったという見え方になるでしょう
そのことがしっかりドキュメントにまとまっていれば、なぜそうなったのかが理解できますが、そのようなシステムの仕様の変更の流れというのは往々にして記載が漏れるので、そのようなシステムを後から引き継ぎにきた人は阿鼻叫喚の嵐に巻き込まれるかもしれません
これは、システム開発における最も悪手中の悪手のワザですが、背に腹は代えられません
このようにして難を逃れる金融機関が出ることが予測されるでしょう
ハイパーインフレもしばらくすれば、デノミが行われると思います
デノミが行われれば、その対応に追われたりしてさらに阿鼻叫喚の地獄が想像されますが、長くなりそうなので、ここでおわりにしましょう
エッセンスも伝わったでしょうし
結論
ハイパーインフレ来たら、金融システム死ぬ
おわりに
まあ、ハイパーインフレが起きると、そもそも社会的な大混乱は間違いないので、金融システムのダウンごときは些末な問題になり果てるのかもしれません。
システム担当者としてもハイパーインフレなんて想定することすら頭にない状態が一番幸せなのかもしれないですね