---

PowerBuilderの衝撃とパッケージ導入の皮肉

DataWindowが実現していた圧倒的な開発体験

1990 年代後半、データベースと直結する業務アプリ開発において、Sybase（現 Appeon）の PowerBuilder が放っていた輝きは別格でした。当時の Visual Basic（VB6）や初期の Java（AWT / Swing）と比べても、PowerBuilder には他が絶対に真似できない特許技術の切り札 「DataWindow（データウィンドウ）」 があったからです。

普通の言語では、「SQL でデータベースから値を取る処理」「画面のグリッド表や入力欄に流し込む処理」「ユーザーが書き換えた行だけを判定して UPDATE や INSERT 文を組み立てる処理」「そのまま綺麗に印刷する帳票レイアウト」を、全部バラバラに書かなければなりませんでした。

ところが PowerBuilder の DataWindow は、データ取得から画面表示・入力検証・差分更新・帳票印刷までを たった 1 つの部品 に凝縮していました。

• dw_1.Retrieve() の 1 行を呼ぶだけで DB からデータが吸い上げられて美しい一覧画面になり、
• ユーザーが画面上で値を直して dw_1.Update() を呼ぶだけで、変更された列・行（ステータスフラグ）だけを自動検知して最適な SQL を発行してくれる。
• さらに実行中でも Describe() や Modify() を使えば、条件に応じて色やレイアウトを自在に書き換えられる。

現代の Web 開発では、フロントエンド（React 等）とバックエンド API と ORM（DB 接続層）の 3 層に分けて何百行もボイラープレート（定型コード）を書いていますが、「業務データを安全に見せて更新する」という一点において、30 年前の DataWindow はすでにひとつの完成形に到達していたのです。

仮想マシン実行とC言語変換コンパイルの裏側

ちなみに「PowerBuilder で作ったアプリって、裏側ではインタプリタ（逐次通訳）だったの？ それともマシン語だったの？」という疑問もよく話題になります。

実は PowerBuilder は、次の 2 種類のビルド方式 を選べるユニークな設計になっていました。

ビルド方式	出力されるファイルと内部動作	実務でのメリット・特徴
① P-Code 方式（標準・主流）	中間コード（.pbd）を生成し、実行時に PBVM（PowerBuilder 仮想マシン） が解釈して実行	コンパイルが一瞬で終わり、ファイルサイズも軽量。Java や .NET の中間言語と全く同じ先進的なアプローチ。
② マシンコード方式	PowerScript を一度 裏側で「C 言語のソースコード」へ自動変換 し、内蔵の Watcom C++ コンパイラでネイティブ .exe / .dll に変換	ループ計算などは高速化する一方、ビルド時間が非常に長くファイルも肥大化しやすい。

「マシンコードを選んだ方が爆速になるはず！」と思いきや、業務アプリの待ち時間の大半は「DB の応答待ち」か「すでに C/C++ でカリカリに作られた DataWindow エンジンの描画処理」だったため、実務では手軽で安定した P-Code（仮想マシン）方式 が一番愛されていたのも面白い歴史です。

業務をSAPに合わせずアドオン地獄に陥る現場

その後、2000 年代に入ると大企業を中心に「これからは自社開発ではなく、世界標準の業務パッケージ SAP（ERP） を入れよう！」という大ブームが起きました。しかし、ここでも日本の現場ならではの強烈な皮肉が起きます。

SAP の本来の思想は、「世界中のベストプラクティスが詰まった標準パッケージに、会社の業務フローの方を合わせなさい（Fit to Standard）」 というものでした。ところが多くの日本企業は、「うちの伝統的な伝票承認ルールや独自の商習慣は 1 ミリも変えたくない！ パッケージ側を改造して合わせろ！」と発注してしまったのです。

その結果、SAP 専用言語である ABAP（COBOL に似た構文を持つ独自言語） を使って何千本もの追加開発（アドオン・Z プログラム）を継ぎ足す「アドオン地獄」が発生しました。何十億円も払って標準パッケージを買ったのに、中身は独自改造だらけでバージョンアップのたびに大改修が必要になる……という光景は、道具の思想と現場の運用が噛み合わなかった象徴的な出来事でした。

---

お金の計算でCOBOLが今も侮れない数理的理由

二進数の浮動小数点が1円単位で狂う仕組み

さて、業務システムの世界でもうひとつ「過去の遺物」のように言われながら、銀行や生命保険、官公庁の心臓部でしぶとく生き残ってきたのが COBOL（コボル） です。なぜこれほど長く使われ続けたのかと言えば、単なる惰性ではなく、「お金の 10 進数計算が言語の骨の髄まで標準組み込みされていたから」 です。

C 言語や Java、JavaScript、Python などの一般的な言語で、標準の小数の型（IEEE 754 倍精度浮動小数点：double）を使って 0.1 + 0.2 を計算させると、コンピュータの内部（2 進数）では衝撃的なことが起きます。

人間にとってキリの良い「10 分の 1（0.1）」は、2 進数の分数（1/2, 1/4, 1/8, 1/16… の足し算）では一生かかっても割り切れません。途中で無理やり打ち切って丸めるため、0.1 + 0.2 を計算すると 0.30000000000000004 のような微妙なゴミ誤差が乗ってしまうのです。何千万件もの消費税や利息を計算する基幹システムでこれが起きたら、1 円のズレで大事故になります。

その点、COBOL は最初から PIC S9(9)V99 COMP-3（パック 10 進数）のように、メモリ上に 10 進数の各桁をそのまま格納し、CPU（メインフレーム）の 10 進演算命令と直結して 1 円の狂いもなく高速計算する仕組み を言語仕様のど真ん中に持っていました。

国税システムJava移行とBigDecimalの罠

近年、こうした巨大 COBOL 資産をオープン系（Java など）へ移行する動きが本格化しており、象徴的な例として国税庁の基幹システム刷新（次世代 KSK システム：2026 年 9 月運用開始予定として進められてきた巨大刷新プロジェクト）などでも、COBOL から Java 等への移行が大きな注目を集めています。

もちろん現代の Java でも、標準の double ではなく BigDecimal クラス を使えば、COBOL と同じように正確な 10 進計算を行うことができます。しかし、ここには経験不足のプログラマや AI 自動変換ツールがうっかり踏み抜きやすい 有名な落とし穴 があります。

さらに COBOL の固定長メモリ領域と違い、Java の BigDecimal は計算のたびに新しいオブジェクトをヒープメモリ上に生成するため、数千万件のバッチ処理ではガベージコレクション（不要メモリの回収：GC）の負荷設計まで気を配る必要があります。COBOL からの移行が単純な「単語の置き換え」で済まない理由は、こうした足回りの計算モデルの違いにあるのです。

---

C言語のポインタ嫌悪と現代コンパイラの逆転現象

手動のシフト演算より素直な式が速くなる理由

1980〜90 年代のコンパイラはまだ最適化が素朴だったため、確かに人間が掛け算や割り算をビットシフト（<< / >>）に書き換えると速くなる時代がありました。しかし現代では、その手動チューニングは 「百害あって一利なし」 と言われるようになっています。

理由は 2 つあります。1 つ目は 「負の数でのバグ」 です。たとえば C 言語で -3 / 2 を計算すると結果は -1（ゼロ方向への切り捨て）になりますが、これを手動で右シフト -3 >> 1 に書き換えてしまうと、一般的な 2 の補数表現の算術シフトでは結果が -2（負の無限大方向への丸め）にズレてしまう のです！

2 つ目は 「現代コンパイラの超絶最適化」 です。人間が素直に x / 2 と書いておけば、コンパイラは「符号付き整数だから負の数の補正命令を 1 つ添えて高速シフト命令に変換しよう」と 1 ナノ秒で正確なマシン語に直してくれます。逆に、人間がポインタ演算や手動シフトで複雑怪奇なループを書くと、コンパイラが「どこからどこまでのメモリを触るか保証できない（エイリアシング問題）」と警戒してしまい、CPU が 8 個や 16 個のデータを一発で同時計算する「SIMD 自動ベクトル化」が効かなくなって遅くなる 逆転現象すら起きるのです。

未定義動作の落とし穴と安全な現代言語への進化

さらに恐ろしいのが、C 言語に潜む 「未定義動作（Undefined Behavior：UB）」 です。ポインタの番地計算を 1 つ間違えたり、符号付き整数の桁あふれを起こしたりしたとき、現代の賢すぎるコンパイラは「C 言語のルール上、そんなことは絶対に起きない前提でいいんだな！」と解釈し、安全チェック用の if 文ごと勝手にごっそり削除してしまう ことすらあります。

「メモリの生番地（ポインタ）をプログラマの注意力だけで管理するのは、もう人間の限界を超えている」――この長年の反省から生まれたのが、コンパイル時にメモリの所有権と境界を 100% 機械検査してポインタ事故を根絶した現代のシステム言語 Rust（ラスト） なのです。

---

絶滅どころか最前線で戦う古典言語と宇宙機の秘密

スパコンとAIの足回りを支えるFortran

では、C 言語よりさらに古い 1950〜70 年代生まれの古典言語たちは、もう博物館に入ってしまったのでしょうか？ いいえ、特定の極限領域では、現代のどんな流行言語も敵わない現役のエースとして君臨しています。

まず科学技術計算の始祖 Fortran（フォートラン） です。気象庁の数値予報モデルや富岳クラスのスーパーコンピュータ、流体力学シミュレーションの世界では、今も「Modern Fortran（Fortran 90/2008/2018 等）」が第一線の主力です。

なぜ C 言語より速くなりやすいのかと言えば、Fortran は最初から 「巨大な多次元配列の行列計算」に特化しており、C 言語のような自由奔放なポインタの重なり（同じメモリ領域を別の名前で指すこと）が原則起きない言語設計 だからです。そのためコンパイラが安心して限界まで並列化・SIMD 化をかけられます。私たちが Python で AI やデータ分析を動かす定番ライブラリ（NumPy や SciPy）も、実は皮を一枚めくれば、中身の重い行列計算（BLAS / LAPACK）は長年鍛え抜かれた Fortran や C のコードが汗をかいて支えているのです。

また、亀のマーク（タートルグラフィックス）でおなじみの教育用言語 Logo（ロゴ） も消えたわけではなく、その設計思想は世界中の子どもたちが学ぶブロック型言語 Scratch（スクラッチ） や、感染症・渋滞などの複雑系シミュレーション環境 NetLogo にそのまま遺伝子として受け継がれています。

電波越しに宇宙探査機を手術できるForth

そして古典言語の中で最もロマンあふれる生き残り方をしているのが、1960 年代末に電波望遠鏡の制御から生まれたスタック指向言語 Forth（フォース） です。

3 4 +（3 と 4 を積んで足す：逆ポーランド記法）のように極限まで無駄を削ぎ落とした Forth は、OS とコンパイラと対話シェルを全部合わせてもわずか数キロバイト〜数十キロバイト という驚異の軽さを誇ります。そのため、木星探査機「ガリレオ」や、彗星に着陸した欧州の探査機「フィラエ（ロゼッタ計画）」、数々の人工衛星の搭載コンピュータに採用されてきました。

Forth が宇宙で愛された最大の理由は、「何億キロも離れた地球から、微弱な電波で数行のテキストを送るだけで、飛行中の探査機のプログラム（辞書）をその場で書き換える『生体手術』ができたから」 です。メインアンテナが開かないトラブルに見舞われた木星探査機ガリレオも、地球から Forth で書かれた新しい圧縮・制御プログラムを送り込んで書き換えることで、貴重な観測データを地球へ届け切る奇跡を起こしました。

太陽フレアを耐え抜く宇宙用CPUと三重多数決

実は真逆なんです！何百億円もする最新の火星探査車や深宇宙探査機に積まれている CPU は、私たちが 20 年以上前の初代 Power Mac G3 時代に使っていた PowerPC ベース（BAE Systems 製 RAD750 など：クロック約 100〜200MHz、メモリ数百 MB 程度）が長年主力を張ってきました。

なぜ最新の数ナノメートル世代の超高速 CPU や大容量メモリを積めないのかというと、回路の線が細かすぎる現代の民生チップは、宇宙線や太陽フレアの高エネルギー粒子が 1 発かすめただけでビットが反転（0 が 1 に化けるシングルイベント現象：SEU）したり、最悪の場合は過電流（ラッチアップ）でチップが焼き切れたりするから です。

宇宙機が過酷な放射線の嵐を何十年も生き延びるために、ハードとソフトで次のような 3 重の鉄壁防御 が組まれています。

---

まとめ：道具の流行り廃りを超えて残る設計の急所

さまざまな開発言語とハードウェアの歴史を振り返ると、時代が変わっても絶対に揺らがない「適材適所の真理」が浮かび上がってきます。

流行りのフレームワークや AI ツールが毎月のように入れ替わる時代だからこそ、裏側で動く 2 進数と 10 進数の違いや、先人たちが鍛え上げたアーキテクチャの歴史を知っておくと、どんな新しい技術が出てきても本質を見失わずに楽しめますね！