AS/400のデータ移行で気をつけること｜EBCDIC・パック10進数・外字・日付の変換
AS/400（IBM i）からWebシステムやクラウドのデータベースへデータを移すとき、「CSVに書き出せば済む」と考えると、文字化けや金額のずれで苦労することになります。AS/400のデータは、文字コードも数値の持ち方も、一般的なPCやLinuxのサーバーとは違うためです。
この記事では、AS/400のデータ移行でつまずきやすい点を、技術的な内容も含めて解説します。発注を検討している方は、委託先がこれらを理解しているかを確かめる材料としてもお使いください。
- AS/400の文字はEBCDICで、日本語はCCSID（5026・5035・1399など）によって変換の表が違う
- 2バイト文字はシフトコードで囲まれ、項目の長さの計算が変わる。外字は個別の対応表が必要
- 金額や数量はパック10進数・ゾーン10進数で保存されていることが多く、符号の扱いに注意
- 移行の品質は、件数・合計値・サンプルの突き合わせを自動で繰り返すことで担保する
文字コード：EBCDICとCCSID
AS/400では、文字をEBCDICという文字コードで保存しています。一般的なPCやWebで使われるUnicode（UTF-8）やShift_JISとは、文字と数値の対応がまったく違います。さらに、日本語の環境では、どの文字の対応表を使うかをCCSIDという番号で区別しています。
| CCSID | 概要 | 注意点 |
|---|---|---|
| 5026 | 日本語（半角カタカナ優先） | 半角の英小文字が使えない。英小文字が入っているはずの項目は要確認 |
| 5035 | 日本語（英小文字が使える） | 5026と半角カタカナの位置が異なる |
| 1399 | 日本語（Unicodeとの対応を拡張） | 比較的新しい環境で使われる |
ファイルやフィールドごとにCCSIDが違うこともあります。また、CCSIDが65535（変換しない）に設定されたファイルでは、データ転送の際に自動の変換が行われず、文字化けの原因になります。最初に、全ファイルのCCSIDを一覧にすることが大切です。
シフトコードと項目の長さ
EBCDICでは、半角と全角が混ざる項目で、全角の文字の前後にシフトアウト（0x0E）とシフトイン（0x0F）という制御コードが入ります。そのため、AS/400で「20バイト」の項目に入る全角の文字数は、シフトコードの分だけ少なくなります。移行先のデータベースで文字数と桁数をどう定義するかは、この違いを考えて決める必要があります。
外字
人名や地名の旧字体など、標準の文字にない外字を独自に登録している会社は少なくありません。外字は、AS/400の中だけで意味を持つコードのため、変換の表に含まれず、文字化けや欠落の原因になります。外字の一覧を作り、Unicodeの文字に対応づけるか、代わりの文字にするかを、業務の担当者と一緒に決めます。
数値：パック10進数とゾーン10進数
AS/400では、金額や数量を、一般的な整数や小数の形ではなく、10進数の形のまま保存していることが多くあります。
| 形式 | 持ち方 | 例：-123（3桁） |
|---|---|---|
| パック10進数（packed） | 1バイトに数字を2つ詰め、最後の半バイトに符号（C=正、D=負、F=符号なし）を置く | 12 3D（2バイト） |
| ゾーン10進数（zoned） | 1バイトに数字を1つ置き、最後のバイトの上位に符号を置く | F1 F2 D3（3バイト） |
データベースの定義（DDS・SQL）を読めば、項目の桁数と小数点以下の桁数が分かります。CSVで書き出す場合は、IBM iの機能で文字に変換されるため扱いやすくなりますが、プログラムが独自の形式で書いた物理ファイルや、項目の定義と中身が食い違っているデータでは、生のバイト列を読み解く必要があります。
- 符号：負の数が正しく変換されているか（Dの符号の扱い）
- 小数点の位置：定義上の小数点以下の桁数で、値を割り戻しているか
- 不正な値：初期化されていない項目に入った空白（0x40）などを、どう扱うか
日付と時刻
AS/400の古いシステムでは、日付が日付の型ではなく、数値で保存されていることが一般的です。
| 形式の例 | 内容 |
|---|---|
| 8桁の数値（YYYYMMDD） | 20261114 |
| 6桁の数値（YYMMDD） | 261114。世紀の判定のルールが必要 |
| 7桁の数値（CYYMMDD） | 1261114。先頭の1が2000年代を表す |
| 和暦 | 元号を表すコード＋年月日。元号の追加のたびに改修されていることがある |
| 0や99999999 | 「未設定」「無期限」の意味で使われていることがある |
特に、0や99999999のような特別な値は、業務上の意味を確認してから、移行先でNULLにするか、特定の日付にするかを決めます。
移行の品質を担保する検証
- 件数の一致ファイルごとに、移行前と移行後の件数が一致するか
- 合計値の一致金額・数量の項目ごとに、合計値が一致するか（符号や小数点のずれを検出できる）
- 文字の検証変換できなかった文字の件数と一覧、外字の変換結果を確認する
- サンプルの目視確認業務の担当者に、よく知っている取引先や商品のデータを画面で確認してもらう
- 業務の集計の一致月次の売上や在庫など、業務で使う集計が、新旧で一致するか
これらの検証は、手作業ではなくスクリプトで自動化し、本番の移行までに何度も繰り返します。リハーサルのたびに同じ結果が出ることを確かめてから、本番に臨みます。
関連記事新旧システムの突き合わせテスト（並行稼働）の進め方｜計算結果が合わないときの調べ方
よくある質問
- AS/400のデータは、CSVで書き出せば移行できますか？
- IBM iの機能でCSVに書き出すと、多くの項目は文字に変換されて扱いやすくなります。ただし、CCSIDの設定、外字、独自の形式のファイル、日付の形式などは別に確認が必要です。
- 外字はどのくらいの数がありますか？
- 会社によって大きく違います。数個の会社もあれば、数百個登録している会社もあります。最初に一覧を作ることで、対応の工数を見積もれます。
- 移行のリハーサルは何回行いますか？
- 規模によりますが、本番の前に2〜3回のリハーサルを行い、件数・合計値・業務の集計が毎回一致することを確かめるのが一般的です。
まとめ
AS/400のデータ移行では、EBCDICとCCSID、シフトコード、外字、パック10進数・ゾーン10進数、数値で保存された日付の変換に注意が必要です。最初に全ファイルの定義を一覧にし、件数・合計値・業務の集計の突き合わせを自動で繰り返すことで、移行の品質を担保できます。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
