AS/400のデータを他のシステムやクラウドに連携したいが、対応しているツールが見つからない」「メインフレームのデータ連携で独自の問題が発生している」——こうした悩みを抱えるシステム担当者は少なくありません。
AS/400（現：IBM i）は、製造業・流通業・金融業を中心に、今も多くの企業の基幹システムとして現役で稼働しています。しかし、その独自アーキテクチャゆえに、データ連携・レプリケーションは一般的なRDBMSとは異なる課題を抱えています。
本記事では、AS/400・メインフレーム環境のデータ連携に特有の課題を整理し、レプリケーションツールの選定ポイントと、クラウド移行への実践的なアプローチを解説します。
この記事で分かること
- AS/400（IBM i）環境でデータ連携が難しい理由
- RRN（相対レコード番号）問題とその現実的な対処法
- レプリケーションツール選定の5つのポイント
- AS/400からクラウドへの段階的な移行パターン
1. AS/400（IBM i）環境でのデータ連携が難しい理由
今もなぜAS/400が使われ続けるのか
AS/400（現在の正式名称：IBM Power Systems + IBM i）は、1988年にIBMが発表したミニコンピューターです。30年以上経った今も、製造・流通・金融分野を中心に国内の多くの企業で基幹システムとして稼働しています。
その理由は明確です。高い信頼性・安定性に加え、「動いているものは触らない」という企業の判断です。業務ロジックがDB2/400と密結合しており、移行コスト・リスクが膨大なため、結果的に長期間使い続けることになります。
データ連携を困難にする3つの特性
AS/400のデータ連携が難しい背景には、以下の技術的な特性があります。
- 独自のデータベース構造（DB2 for i）
AS/400はDB2 for i（旧称：DB2/400）という独自のリレーショナルデータベースを搭載しています。標準的なSQL操作は可能ですが、物理ファイル（PF）・論理ファイル（LF）という独自の概念を持ち、一般的なRDBMSとはアーキテクチャが異なります。
- 文字コード（EBCDIC）の問題
AS/400はEBCDIC（拡張2進化10進コード）という文字コードを使用しています。一方、現代のシステムはUTF-8やShift-JISが主流です。データ連携の際には文字コード変換が必要となり、特殊文字や日本語の扱いで問題が発生するケースがあります。
- ジャーナル機能を使ったCDCの特殊性
AS/400ではデータ変更の記録に「ジャーナル」という独自の仕組みを使います。CDCツールはこのジャーナルを読み取ることで差分データを取得しますが、ジャーナルの設定・管理方法が一般的なトランザクションログと異なるため、ツール側のAS/400専用対応が必要となります。
2. 知っておくべき「RRN問題」：AS/400特有の制約
AS/400のデータ連携で最も注意が必要なのが「RRN（相対レコード番号）問題」です。これはAS/400に固有の制約であり、レプリケーションツールを選定する際に必ず確認すべきポイントです。
RRNとは何か
RRN（Relative Record Number：相対レコード番号）は、AS/400がファイル内のレコードを物理的な位置で識別するための番号です。一般的なRDBMSの主キーとは異なり、テーブルの論理的な値ではなく、ファイル上の物理的な格納位置に基づいて割り振られます。多くのCDCツールは、ソースDBのレコードを一意に識別するためにこのRRNを使用してデータを追跡します。
再編成処理（RGZPFM）でRRNが変化する問題
AS/400では、削除済みレコードの領域を物理的に回収するために「RGZPFM（Reorganize Physical File Member）」という再編成コマンドを定期的に実行します。
【重要な制約事項】
RGZPFMを実行すると、ファイル内のレコードが物理的に再配置され、すべてのレコードのRRNが変化します。主要なレプリケーションツール（Qlik Replicate・Oracle GoldenGate・AWS DMSなど）はいずれも、このRRN変化に自動的に追従する機能を持っていません。再編成後に自動的に連携を継続できるツールは現時点では存在せず、リロード（初期ロードの再実行）による対応が現実的な解決策となります。
現実的な対応策：リロード運用の設計
RRN問題への対応として、多くの企業が採用しているのが「再編成処理のスケジュール管理とリロード運用の組み合わせ」です。
- 再編成処理のタイミング管理：RGZPFMを実行するタイミングをデータ連携の停止時間帯（深夜・休日）に合わせてスケジューリングします。
- リロード手順の自動化：再編成後のリロード（初期ロードの再実行）をスクリプト化・自動化し、復旧時間を最小化します。
- 監視アラートの設定：連携エラーを即座に検知し、担当者に通知する仕組みを整備します。
この制約を正しく理解した上で運用設計を行うことが、AS/400データ連携を安定稼働させる鍵となります。
3. AS/400からのクラウド移行パターン
AS/400を全面的に刷新するのではなく、段階的にクラウド連携・移行を進めるアプローチが現実的です。代表的な3つのパターンを紹介します。
パターン①：段階移行（周辺システムから先にクラウド化）
AS/400の基幹機能はそのまま残しながら、データを周辺のクラウドシステムに連携する方法です。AS/400本体には手を加えず、AS/400のデータをクラウドDWH（Redshift / BigQuery / Snowflake）にリアルタイム連携してBIツール・分析基盤で活用します。AS/400のリプレイス計画がまだない企業、あるいは分析・レポーティングの高度化が目的の場合に有効です。
パターン②：ハイブリッド構成（AS/400を維持しながら新システムと並行稼働）
AS/400と新しいクラウドシステムを並行稼働させ、データを同期するパターンです。新システムへの段階的な業務移行期間中のデータ整合性を確保しながら、移行完了後にAS/400を停止します。基幹システムの完全移行を計画しているが、一度に切り替えるリスクを回避したい場合に適しています。
パターン③：完全移行（AS/400の業務をクラウドへ完全移管）
AS/400上のすべての業務・データをクラウドに移行し、AS/400を廃止するパターンです。最もリスクが高い反面、長期的なコスト削減効果が最大となります。初期ロードでAS/400の全データをクラウドDBに移行し、並行稼働期間中はCDCで差分を同期。十分な検証後にカットオーバーを実施します。
3つのパターンはいずれもCDC対応のレプリケーションツールで実現可能です。ただし、②ハイブリッド構成・③完全移行は並行稼働中の継続的なCDC同期が求められるため、ツールの精度・安定性がプロジェクト成否に直結します。次章では、自社の移行パターンに合わせたツール選定のポイントを解説します。
4. AS/400環境でのレプリケーションツール選定ポイント
AS/400のデータ連携ツールを選定する際は、一般的なRDBMS向けツールとは異なる観点でチェックが必要です。以下の5つのポイントを確認してください。
選定ポイント①：IBM i（AS/400）への公式対応
最も重要なのは、ツールがIBM i（AS/400）をサポートソースとして公式に対応しているかどうかです。「対応している」と謳っていても、サポートしているDB2 for iのバージョンや機能範囲が限定的なケースがあります。PoC（概念実証）で実際の環境での動作を確認することを推奨します。
選定ポイント②：ジャーナルベースCDCの対応
AS/400からリアルタイムで差分データを取得するためには、AS/400のジャーナル機能を使ったCDCが必要です。ツールがジャーナルベースのCDCに対応しているかを確認します。対応していない場合は、タイムスタンプベースやトリガーベースになりますが、これらはパフォーマンス影響や取得精度に課題があります。
選定ポイント③：RRN問題への対応方針
前章で解説したRRN問題について、ベンダーがどのような対応方針を持っているかを確認します。「自動追従できる」という説明をするベンダーがいれば、具体的な仕組みを詳しく確認してください。現実的には、リロード運用での対応が標準的な解となります。
選定ポイント④：クラウド移行先への対応範囲
AS/400のデータを最終的にどこに連携・移行するかも重要な選定基準です。AWS（RDS/Redshift）・Azure（SQL Database/Synapse）・GCP（Cloud SQL/BigQuery）など、目標とする移行先に対応しているかを確認します。
選定ポイント⑤：日本語サポート・導入支援体制
AS/400環境のデータ連携は、設定・運用において専門的なノウハウが求められます。日本語での技術サポートが受けられるか、初期導入時の支援体制が整っているかは、長期運用の安定性に直結します。
| 確認項目 | チェック内容 |
| IBM i公式対応 | 対応バージョン・サポート範囲を確認。PoC実施を推奨 |
| ジャーナルベースCDC | AS/400ジャーナルからの差分取得に対応しているか |
| RRN問題の対応方針 | RGZPFM後のリロード運用設計をサポートしているか |
| クラウド移行先対応 | 目標クラウド・DBへの連携が可能か |
| 日本語サポート | 技術サポート・導入支援が日本語で受けられるか |
5. 運用設計のポイント
AS/400データ連携を安定稼働させるためには、ツールの選定と同等に重要なのが運用設計です。本番稼働後を見据えて、以下の3点を事前に設計しておくことを推奨します。
再編成処理のスケジュール管理とリロードタイミングの設計
2章で解説したRRN問題への対応として、RGZPFMの実行スケジュールとリロードのタイミングを事前に設計します。
- RGZPFMの実行タイミング：業務部門と合意の上、データ連携を停止できる時間帯（深夜・休日）にスケジューリングします。再編成が必要なファイル・頻度を洗い出し、運用カレンダーに組み込んでおきます。
- リロード手順の整備：再編成後に必要な初期ロード再実行（リロード）の手順をスクリプト化・自動化し、復旧時間を最小化します。手動対応が残る場合は、担当者・連絡フロー・作業手順書を整備しておきます。
- リロード所要時間の把握：テーブルごとのデータ量・リロード所要時間を事前に計測し、業務への影響時間を見積もっておくことが重要です。
監視・アラート設定（連携遅延・エラー検知）
AS/400のデータ連携は、ジャーナル容量不足・RGZPFM後の連携停止など、固有の障害パターンがあります。これらを早期に検知するための監視設定を構築します。
- 連携遅延アラート：ソースとターゲット間のラグが閾値（例：5分以上）を超えた場合に即時通知。特にリアルタイム性が求められる連携では重要です。
- エラー検知アラート：接続断・認証エラー・レプリケーションタスクの停止を検知し、担当者にメール・Slackなどで通知します。
- ジャーナル容量監視：AS/400のジャーナルレシーバーが容量逼迫するとCDCが停止するリスクがあります。容量使用率の閾値アラートを設定し、事前にクリーンアップを実施します。
AS/400固有の障害パターンと対応手順
AS/400のデータ連携では、一般的なRDBMSとは異なる障害パターンが発生します。代表的なケースと対応手順を事前に整理しておくことで、本番障害時の復旧時間を短縮できます。
RGZPFM実行後の連携停止：最も発生頻度が高い障害パターンです。再編成処理でRRNが変化したことによる連携エラーです。対応手順：レプリケーションタスクを停止 → 対象テーブルのリロードを実行 → 連携再開。手順書とスクリプトを整備しておき、担当者が迷わず対応できる状態にします。
ジャーナルレシーバー切り替えによる連携エラー：ジャーナルレシーバーが切り替わった際に、CDCツールが追従できずエラーになるケースがあります。対応手順：ジャーナルレシーバーの切り替え設定を確認 → 必要に応じてツール側の設定を更新。定期的な切り替えが発生する環境では、自動追従の設定を事前に確認します。
EBCDIC変換エラー：文字コード変換で想定外の文字が含まれた際に発生します。対応手順：エラーレコードを特定 → 変換マッピングを修正 → 対象レコードを再処理。PoC段階で実際の業務データを使った変換テストを十分に実施し、本番稼働後の発生を最小化します。
6. 選定ポイントを踏まえたQlik Replicateの強み
AS/400（IBM i）環境のデータ連携・クラウド移行において、Qlik Replicateは以下の点で多くの企業に採用されています。
- IBM i（AS/400）への公式対応：DB2 for iのジャーナルベースCDCに正式対応。AS/400からのリアルタイムデータ取得を実現します。
- 150以上のDB・クラウドへの接続：移行先として主要なクラウドDWH（Redshift / BigQuery / Snowflake）やRDB（Oracle / PostgreSQL / MySQL等）に対応。AS/400から目的のクラウド環境へ直接連携できます。
- エージェントレス設計：AS/400サーバーへの追加エージェントなしに接続できるため、レガシー環境への影響を最小化します。
- リロード運用のサポート：RRN問題への対応として、RGZPFMの実行後に必要なリロード操作の設計・運用をサポートする知見と支援体制を提供します。
まとめ
AS/400・メインフレーム環境のデータ連携で押さえておくべきポイントを整理します。
- AS/400は独自のアーキテクチャ（DB2 for i・EBCDIC・ジャーナル）を持ち、一般的なRDBMS向けツールがそのままでは使えないケースがある
- RRN（相対レコード番号）問題はAS/400固有の制約。再編成処理（RGZPFM）後のリロード運用を前提とした設計が必要
- クラウド移行は段階移行・ハイブリッド構成・完全移行の3パターンから選択。特にハイブリッド構成・完全移行では並行稼働中の高精度CDCの安定稼働がプロジェクト成否に直結する
- ツール選定では「IBM i公式対応」「ジャーナルベースCDC」「RRN問題への対応方針」「クラウド移行先対応」「日本語サポート」の5点を確認する
- 再編成処理のスケジュール管理・監視アラート設定・障害パターンへの対応手順を事前に整備することが、安定運用の鍵となる
インサイトテクノロジーでは、Qlik Replicateを活用したAS/400・メインフレーム環境のデータ連携・クラウド移行を数多く支援しています。「自社環境でQlik Replicateが動くか確認したい」「RRN問題への具体的な対応方法を相談したい」といったAS/400特有の課題についてのご相談は、お気軽にどうぞ。
▼ Qlik Replicateの資料をダウンロード
https://www.insight-tec.com/download/document_0006
▼ Qlikが提供するリアルタイムデータ連携について詳しく見る
https://www.insight-tec.com/products/qlik-data-integration-platform
▼ AS/400・メインフレームのデータ連携をまず相談する
https://www.insight-tec.com/products/qlik-data-integration-platform/#f
