【ITニュース解説】I Built a Banking System That Talks COBOL… and My Boss Didn't Notice

ニュース記事の内容は、銀行の基幹システムを現代の技術と連携させるための画期的なアプローチについて解説している。具体的には、古くから使われているCOBOL言語で構築されたバッチ処理システムを、最新のウェブ技術であるReactやREST APIからオンデマンドで利用可能にする方法が示されている。

まず、銀行のシステムが抱える問題点から見ていこう。多くの金融機関では、COBOLと呼ばれる非常に古いプログラミング言語で書かれた基幹システムが今も稼働している。この記事の例では、ワイヤー転送（資金送金）のコアとなる処理が、夜間特定の時間に実行されるCOBOLのバッチジョブとして運用されていた。このジョブは、メインフレームと呼ばれる大型コンピューター上で動作し、VSAMというファイルからデータを読み込み、CICSというトランザクション管理システムを介して処理を行い、最終的にJESというシステムで400ページにも及ぶレポートを印刷するというものだった。

しかし、現代のFinTech（金融とテクノロジーを融合したサービス）のフロントエンドから、この送金処理を必要な時にいつでも（オンデマンドで）実行したいという新しい要件が生まれた。この要件を満たすためには、既存のCOBOLバッチジョブをRESTエンドポイントとして外部に公開する必要がある。だが、ここで大きな課題が立ちはだかる。それは、「システムを停止させることなく」「JCL（ジョブ制御言語）を変更することなく」「予算ゼロで」これを実現しなければならないという厳しい制約だった。通常、このようなレガシーシステムの現代化（モダナイゼーション）は、何年もの期間と数千万ドルの費用を要し、システムの大規模な停止を伴うのが一般的である。

この困難な課題に対し、著者は「40行のC言語コードとUnixのデーモン化」という巧妙なトリックで解決策を見出した。まず、重要な概念の一つが「デーモン」である。UnixやLinuxなどのシステムでは、プログラムをバックグラウンドで動かし続ける仕組みがあり、これをデーモンと呼ぶ。通常のプログラムは、コマンドを実行したターミナル（操作画面）を閉じると同時に終了してしまう。これは、プログラムがターミナルの「子プロセス」として動いているためで、親であるターミナルが終了すると子も一緒に終了する、というUnixの基本的なルールによるものだ。

しかし、デーモンはそうではない。デーモンは「ダブルフォーク」と呼ばれる特殊な手順を踏むことで、親プロセスから完全に切り離され、システムが起動している限り独立して動作し続ける「不死身」のプロセスとなる。具体的には、まず一度fork()（プロセスを複製するシステムコール）を実行して親プロセスを終了させ、次にsetsid()（新しいセッションを作成するシステムコール）で新しいセッションに移行し、さらにもう一度fork()を実行して親プロセスを終了させる。この二重のプロセス分離により、デーモンはターミナルの終了やSSHセッションの切断に影響されることなく、バックグラウンドで安定して動き続けることができる。これは、24時間365日稼働が求められるサービスにとって不可欠な仕組みである。

著者が開発した40行のC言語コードは、このデーモンとして動作する。このコードの役割は、メインフレーム上で動くCOBOLバッチジョブを、外部からの指示で実行させるための「橋渡し役」である。コードは、tsocmdというコマンドを使って、特定のJCLファイルをメインフレームに「サブミット」（実行指示）する。JCLはメインフレームにおけるプログラムの実行手順を記述したもので、これにより既存のCOBOLコードやその実行環境に一切変更を加えることなく、外部からジョブをトリガーすることが可能になる。サブミットされたジョブの実行結果は、このC言語コードを通じて取得され、呼び出し元に返される仕組みだ。このC言語コードは共有ライブラリ（libpolycall-cobol.so）としてコンパイルされ、所定の場所に配置された。これにより、root権限も不要で、レガシーコードの再コンパイルも、メインフレームへの新しいポートの追加も一切なしで連携が実現した。

さらに、著者はこのC言語のブリッジを、Go、Python、Java、Node.js、Luaといった現代の多様なプログラミング言語から利用できるように「ポリグロット」（多言語対応）な環境を構築した。これにより、一つのビルドプロセスで、COBOLブリッジを含む様々な言語用のライブラリが生成され、すべてが同じC言語のドライバデーモンに登録される。結果として、一つのデーモンプロセスで、複数の言語からの要求をメインフレームのCOBOLジョブにルーティングできる柔軟なシステムが完成した。

このシステムが完成した後、著者は上司に対してデモンストレーションを行った。ウェブブラウザから特定のURLにアクセスし、メインフレームのJCLファイルをドラッグ＆ドロップでアップロードし、「Submit」ボタンをクリックするだけで、メインフレーム上で実際に運用されている送金処理ジョブがリアルタイムで実行され、その結果がブラウザに表示された。上司は、これが本物の生産環境のジョブであることを認識し、著者が既存の処理手順に一切手を加えていないことに驚きと困惑を示したという。このデモンストレーションは、既存システムに影響を与えることなく、いかに迅速かつ低コストで新しい要件を満たせるかを示す強力な証拠となった。

このアプローチが持つ意味は非常に大きい。従来のモダナイゼーションが大規模な書き換えを伴い、多大なコストとリスク、そしてシステム停止期間を必要としたのに対し、この方法は「サイドカー（並走する仕組み）」のように、レガシーシステムはそのまま稼働させつつ、新しい機能やインターフェースを独立して追加できる。新しい機能はGoやReactなどの最新技術で開発でき、万が一問題が発生しても、ブリッジサービスを停止するだけで簡単に元の状態に戻せるため、リスクが極めて低い。また、デーモンとして動作するブリッジは、ターミナルやSSHセッションが切断されても自動的に動き続けるため、監視（ベビーシッティング）の必要がなく、安定した運用が可能である。

著者はこの経験から、Unixシステムにおける真のサービスのあり方について教訓を得たと述べている。「ラップトップを閉じたらサービスが死んでしまうようなら、それはサービスではなく、ただのシェルの子に過ぎない」と。ダブルフォークを行い、標準出力をリダイレクトし、PIDファイル（プロセスのIDを記録するファイル）を書き出す。これらがデーモンが独立して稼働するための基本的な作法であり、決して「悪魔の魔法」などではなく、適切にプロセスを管理するための技術なのだ。

今後の展望として、著者はドラッグ＆ドロップのインターフェースをGraphQLミューテーションに置き換え、より型安全な方法で送金処理をトリガーできるようにする計画を明かしている。また、libpolycall自体も、アタッチモード（ターミナルに接続された状態）でのポーリングではなく、より洗練された--detachオプションに対応させることで、サービスとしての成熟度を高めていくという。メインフレームの運用チームには「単なるテストを実行しているだけ」と伝えつつ、著者はレガシーシステムをまるでサーバーレス関数のように扱えるようなプロジェクトを進めている。この経験は、いかに古いシステムが未だに世界を動かしており、それらをいかに現代の技術と結びつけるかという課題に対する重要な示唆を与えている。