こんにちは！メインフレームの底知れぬパワーと、そこに眠るPL/I（ピーエルワン）という少し古風だけど奥深い言語の世界へようこそ。
JavaやCOBOLといったモダン、あるいはビジネスでよく使われる言語の経験がある方にとって、突然目の前に現れるPL/Iのソースコードは、まるで古代文字のように見えてしまうかもしれません。「なんだこの変数宣言は！？」と、冷や汗をかいた方もいらっしゃるのではないでしょうか。
でも、どうぞご安心ください。今回は、マイグレーション現場でエンジニアたちの夜を幾度となく奪ってきた「PL/Iの `FIXED DEC`（固定小数点数）と、Javaの `BigDecimal` の間に潜む、精度と丸め誤差の罠」について、優しく、そして徹底的に紐解いていきますよ。
—
1. まずは心を落ち着かせましょう：PL/Iには「本当の意味での予約語」がない？
Javaなら `int` や `class`、COBOLなら `PICTURE` や `VALUE` といった、絶対に変数名に使えない「予約語」がありますよね。
ところが、PL/Iの最もユニーク（そして少し厄介）なところは、言語仕様上の「予約語（Reserved Words）」が存在しないという点なんです。
どういうことかと言いますと、PL/Iのコンパイラは、文脈（コンテキスト）を見て「あ、ここで使われている `IF` は変数名じゃなくて条件分岐の命令だな」と空気を読んで判断してくれます。極端な話、以下のようなコードだって（やらない方が身のためですが）コンパイルエラーにはなりません。
DECLARE IF FIXED(5) ; / 「IF」という名前の数値変数を作ることも理論上は可能 /
初学者のうちは、「どこまでが命令で、どこからが自分で決めた名前なのか分からない！」と混乱してしまいますよね。でも、大原則として「大文字で書かれたキーワード的なものは、その場の文脈で判断されているんだな」と気楽に構えていて大丈夫です。怖くないですよ、一つずつルールを紐解いていきましょう。
—
2. 諸悪の根源（？）：`FIXED DECIMAL` の独特なデータ宣言
さて、今回の本題であるデータ型の話に入りましょう。
金融系や基幹システムの金額計算などで、PL/Iではお馴染みのこいつが登場します。
DECLARE WK-KINGAKU FIXED DECIMAL(9, 2);
JavaやC言語しか触ったことがないと、「なんだこれ？」って思いますよね。
この `FIXED DECIMAL(9, 2)` というのは、一体どういう意味なのでしょうか？
イメージしやすいように、「そろばん」や「マス目ノート」を思い浮かべてみてください。
- `9`（精度 / Precision）：小数点以下も含めて、全部で何桁の数字を収める箱（マス目）を用意するかを表します。
- `2`（スケール / Scale）：そのうち、小数点より下に何桁を割り当てるかを表します。
つまり、`FIXED DECIMAL(9, 2)` と宣言した場合、全体で9桁分のスペースがあり、そのうち下2桁が小数部、残りの7桁（9 – 2 = 7）が整数部になります。
メモリ上では、これらが「ゾーン10進数」や「パック10進数」という、人間が電卓を叩く感覚に非常に近い形で、1バイトに2桁の数字をギュッと詰め込む形式で保持されます。浮動小数点数（`FLOAT`）のように「0.1を足したらなぜか 0.100000001 になっちゃった！」という誤差が理論上起きない、お金の計算の強い味方なのです。
—
3. Javaへのマイグレーション：なぜ「桁あふれ」や「丸め誤差」が起きるのか？
メインフレーム上のPL/Iで元気に動いていたこの `FIXED DECIMAL(9, 2)` のデータを、Javaに移行して `java.math.BigDecimal` で受け取る際、ここに大きな落とし穴があります。
Javaの `BigDecimal` は非常に高機能で素晴らしいクラスですが、PL/Iの「厳格な桁数・小数点の縛り」を自動的には引き継いでくれません。
罠その1：勝手にスケールが変わる恐怖
PL/Iからデータを抽出してJava側で以下のように受け取ったとします。
// PL/Iの FIXED DEC(9, 2) のデータを単に文字列や数値としてJavaに渡した場合
BigDecimal wkKingaku = new BigDecimal(“12345.6”);
// この場合、Java側のスケールは自動的に「1」になってしまうことがある！
もし、この `wkKingaku` に対して後続の処理で割り算を行ったり、別の小数点以下4桁のデータと足し算をしたりすると、Javaの内部で勝手に有効桁数やスケールが拡張・変更され、「あれ？ メインフレームとJavaで計算結果の端数の丸め方が違うぞ？」という不一致が発生します。
罠その2：桁あふれ（Overflow）の黙殺と爆発
PL/Iでは、もし計算結果が定義された桁数（例：整数部7桁）を超えた場合、コンパイラや実行時環境が検知して `SIZE` 条件（割り込み）を発生させ、異常終了するか適切なハンドリングを行うことができます。
しかし、Javaの `BigDecimal` はメモリが許す限り無限に桁数を増やせてしまいます。
PL/I側では「最大9桁（整数7桁、小数2桁）」と厳しく管理されていたはずのデータが、Javaに移行した途端に無制限に膨れ上がり、データベース（RDB）に書き込む土壇場になって「カラムの定義長（例: DECIMAL(9,2))` を超えています」というSQLエラー（ORA-01438など）でバッチが盛大に爆発する……というのは、マイグレーション現場メンバの悪夢あるあるトップクラスです。
—
4. 対策：Java側でPL/Iの「制約」を完璧に再現する
では、この恐ろしいデータ型の不一致から身を守るにはどうすればよいのでしょうか？
答えは簡単です。「Java側でも、PL/Iの箱のサイズと丸めのルールを強制する」のです。
実務のマイグレーションコードで使える、具体的なJavaのスニペットを見てみましょう。
実装例：PL/Iの `FIXED DEC(9, 2)` をJavaで厳密にエミュレートする
import java.math.BigDecimal;
import java.math.MathContext;
import java.math.RoundingMode;
public class PliDecimalEmulator {
// PL/Iの FIXED DECIMAL(9, 2) の制約を表現するMathContextとScale
private static final int PLI_PRECISION = 9;
private static final int PLI_SCALE = 2;
// 割り算や演算時の丸めモード（PL/Iやビジネス計算では「四捨五入」HALF_UP が一般的）
private static final RoundingMode PLI_ROUNDING_MODE = RoundingMode.HALF_UP;
/
- PL/Iから渡された生データ（文字列など）を、PL/Iの定義通りに安全にパースする
/
public static BigDecimal parsePliFixedDecimal(String rawValue) {
if (rawValue == null || rawValue.trim().isEmpty()) {
return BigDecimal.ZERO.setScale(PLI_SCALE);
}
BigDecimal value = new BigDecimal(rawValue.trim());
// 1. スケール（小数点以下の桁数）を強制的に合わせる
value = value.setScale(PLI_SCALE, PLI_ROUNDING_MODE);
// 2. 整数部の桁数あふれチェック（全体精度 – スケール = 整数部最大桁数）
int maxIntegerDigits = PLI_PRECISION – PLI_SCALE; // 9 – 2 = 7桁
int currentIntegerDigits = value.precision() – value.scale();
if (currentIntegerDigits > maxIntegerDigits) {
// PL/IのSIZE異常に相当するエラーを検知
throw new ArithmeticException(“PL/Iデータ移行エラー: 整数部が桁あふれを起こしました。”
+ ” 許容最大整数桁=” + maxIntegerDigits + “, 実際の値=” + value);
}
return value;
}
public static void main(String[] args) {
// テストケース1: 正常系
BigDecimal amount1 = parsePliFixedDecimal(“1234567.89”);
System.out.println(“正常パース結果: ” + amount1);
// テストケース2: 小数点以下の丸めが必要なケース (PL/IのDEC(9,2)に合わせる)
// 元データが “123.456” だった場合、四捨五入されて “123.46” になる
BigDecimal amount2 = parsePliFixedDecimal(“123.456”);
System.out.println(“丸め処理後の結果: ” + amount2);
// テストケース3: 桁あふれ検知テスト (整数部が7桁を超える)
try {
parsePliFixedDecimal(“12345678.90”); // 整数部が8桁
} catch (ArithmeticException e) {
System.out.println(“想定通りのエラー捕捉: ” + e.getMessage());
}
}
}
ポイント解説
1. `setScale(PLI_SCALE, RoundingMode.HALF_UP)` を必ず通すことで、PL/I側が持っていた小数点以下の精度を強制的に一致させ、予期せぬ丸め誤差の発生を防ぎます。
2. 独自に 桁あふれバリデーション を挟むことで、「Javaだから無限に数字が入っちゃったよ……」というDBインサート時の悲劇を事前に防ぎ、メインフレームと同等の堅牢性を担保できます。
—
5. おわりに
レガシーシステムからオープン系・クラウド環境へのマイグレーションは、単なる「言語の翻訳作業」ではありません。それは、何十年もかけて培われたメインフレーム独自の「データの思想」を、新しい世界へと丁寧に移植する作業です。
PL/Iの `FIXED DEC` が持つ厳格な桁数管理の思想も、こうして裏側のメカニズムを紐解いてしまえば、怖くも何ともありませんよね。むしろ、お金を扱うシステムにおいては、これほど信頼できる頼もしい相棒もいません。
Javaへの移行現場で「あれ、なんか数字が合わないぞ？」と悩んだときは、ぜひこの記事で紹介した「箱のサイズ（精度とスケール）」と「丸めのルール」を思い出してみてください。
あなたのレガシー移行の旅が、スムーズで実りあるものになりますように。それではまた、次の現場でお会いしましょう！
