はじめに

自社データを AI に繋いで活用しよう、という取り組みが当たり前になってきました。社内の問い合わせに答える RAG チャットボット、受注データをもとにした需要予測モデル、在庫データを使ったオペレーション最適化。こうした取り組みは、製造・流通・小売を問わずかなり広い層に広がっています。

ところで、AI モデルがどれだけ高性能でも、古い・不正確な・欠損のあるデータを与えられれば、AI の答えも信用できないものになります。AI を信じて使えるかどうかは、その手前のデータ基盤を信じられるかどうかと、ほぼ同じ意味なのではないかと思います。

この記事では、IBM i（AS/400）の基幹データを AI で使える状態に整えるために、なぜ CDC（Change Data Capture）が必要なのかを整理してみたいと思います。

基幹に眠る IBM i データを AI で活かすときの壁

IBM i（旧称 AS/400）は、製造業・流通業の基幹システムとして長年現役で稼働し続けているプラットフォームです。処理の信頼性と安定性が高く、「替えられない」というより「替える必要がない」基盤として残り続けています。

そして今、その IBM i に蓄積されたデータをクラウド DWH に集めて、AI や全社的な分析に活用したいというニーズが高まっています。IBM i 側のシステムは変わっていないのに、外からの期待だけが急速に高まっている、という構図です。

ところが、いざ IBM i のデータを DWH やレイクハウスに連携しようとすると、AI に渡すデータの鮮度・整合性の面でいくつかの壁にぶつかります。

コスト・負荷の壁

IBM i との連携を始めるとき、多くの場合は「テーブルを全件取得して、ターゲットに入れ替える」方式から始まります。実装がシンプルで、最初のうちはこれで十分です。しかし、受注テーブルや在庫テーブルは時間とともに大きくなります。最初は 100 万件だったテーブルが、数年後には 1000 万件になっているということもあるでしょう。深夜に始めたバッチが翌朝になっても終わらない、という事態は十分に起こり得ます。

毎晩全件を SELECT するということは、業務で使われている IBM i の DB2 for i に対して、大きなクエリを投げ続けるということでもあります。基幹システムへの負荷をできるだけ抑えたい、本番に影響を出したくない、というのは IBM i を運用するうえで外せない要件です。

転送先のクラウド DWH にもコストが響きます。Snowflake や BigQuery は処理したデータ量に応じて課金されるため、実際には数万件しか変わっていなくても、毎晩 1000 万件分のロードコストがかかります。データが増えるほど時間もコストも増える構造は、長期的に持続しにくくなります。

鮮度の壁

夜間バッチで毎日 1 回取得する運用では、AI が参照するデータは常に「昨日のスナップショット」です。今日の午前中に更新された在庫情報や、今朝キャンセルされた受注は、翌日の夜間バッチが終わるまで AI には届きません。鮮度の低いデータをもとに AI が答え続けると、現場の実態と回答がずれていく一方です。

品質の壁（削除の伝達と文字コード）

全件取得・入れ替え方式では、物理削除されたレコードが問題になります。論理削除（削除フラグ）であれば変更を検知できますが、物理削除されたレコードは取得したデータに存在しないため、ターゲット側に残り続けます。廃番になった商品、退職した社員、キャンセルされた受注、こうした「存在しないはずのデータ」が AI の参照先に混入していれば、AI は誤った前提で推論します。「廃番商品が在庫ありと出た」「退職者の情報が引っかかった」という事態は、AI への信頼を一度で大きく損ないます。

文字コードの問題もあります。IBM i は伝統的に EBCDIC ベースで運用されており、日本語環境では CCSID 5026 や 5035 が使われていることが多くあります。一方、クラウド DWH や AI が前提とするのは UTF-8 です。連携の途中で正しい CCSID 変換が行われないと、半角カナ・外字・特殊記号が文字化けしたり欠損したりします。データそのものは転送できたつもりでも、AI が読むと意味のある文字列になっていない、という事態が起こります。

こういった問題は、「繋げること」に成功した後で初めて顕在化します。最初のうちは気づかず、気づいたときには運用が固まっていて変えにくいというのが、よくあるパターンです。

AI Ready の鍵は CDC（変更データキャプチャ）

これらの問題をまとめて解決する考え方が、CDC（Change Data Capture）です。

CDC とは、データベースに加えられた「変更」だけをキャプチャして転送する仕組みです。全件を取得するのではなく、前回の処理以降に INSERT・UPDATE・DELETE されたレコードだけを検知して送ります。転送するデータ量を大幅に削減でき、本番 DB への負荷も抑えられます。

CDC の実現方式には、大きく三種類あります。

ひとつ目は「クエリベース CDC」です。タイムスタンプや連番カラムを使って、前回処理した以降に更新されたレコードを SELECT で取得する方式です。実装がシンプルで多くのツールが対応していますが、タイムスタンプカラムがないテーブルには使えず、物理削除の検知もできません。

ふたつ目は「トリガーベース CDC」です。DB のトリガー機能を使って変更をキャプチャする方式です。柔軟性はありますが、本番の DB に手を加える必要があり、基幹システムへの変更に慎重なケースでは採用を見送ることも多いです。

三つ目は「ログベース CDC」です。DB が内部的に持つトランザクションログや変更ログを直接読み取る方式です。本番 DB への影響がほぼなく、INSERT・UPDATE・DELETE のすべてを検知できます。現時点でもっとも完全な方式ですが、DB ごとにログの仕組みが異なるため、ツール側での対応が必要で、対応しているツールは限られます。

AI Ready なデータレイヤーを支えるのは、このログベース CDC です。鮮度や削除の反映はトリガーベースでも実現できますが、ログベース CDC のうれしいところは、アプリケーションやテーブル構造に手を加えずに済むことです。トリガーや列追加といったテーブル側の改変を伴わず、変更履歴の仕組み（IBM i ならジャーナル機能）を有効にするだけで、稼働中の業務処理に追加の負荷をほとんどかけずに INSERT・UPDATE・DELETE をすべて拾えます。基幹システムにとっての現実的な落としどころとして、もっともバランスのよい方式です。

CDC の概念や各方式の詳細については、Change Data Capture（CDC）とは？CDC の基本から仕組み、各種手法を完全解説 で詳しく解説しています。CDC をこれから検討される方は、ぜひあわせてご覧ください。

DB2 for i（AS/400）の CDC で AI のためのデータレイヤーを作る

CData Sync は 2025 年 10 月リリースの V25.3 で、DB2 for i（AS/400）の CDC をサポートしました。

IBM i には「ジャーナル機能」という、トランザクションの変更履歴を記録する仕組みが備わっています。これはまさにログベース CDC のための変更ログに相当するものです。CData Sync の CDC は、このジャーナルを活用して変更データをキャプチャします。

コスト・負荷の壁への答え

CData Sync の CDC は、IBM i のジャーナルを常時監視してバックグラウンドで変更データをステージングエリアに蓄積する仕組みです。本番 DB への接続は変更データの読み取り時だけに限定されるため、業務処理への負荷を最小化できます。

クラウド DWH 側のコストも抑えられます。差分データだけを転送するため、テーブルが大きくなっても転送量はほぼ一定です。受注テーブルが 1000 万件あっても、1 日の変更が 1 万件であれば、1 万件分の転送で済みます。データ量が増えるほどコストが膨らむ構造から抜け出せます。

鮮度の壁への答え

ステージングに蓄積された変更データを継続的にターゲットへ反映できるため、夜間バッチの完了を待たずに、変更はニアリアルタイムで AI 基盤に届きます。今朝更新された在庫情報も、今日キャンセルされた受注も、その日のうちに AI の回答に反映できます。

品質の壁への答え

IBM i のジャーナルは DELETE 操作もキャプチャするため、物理削除されたレコードも検知できます。全件取得方式では原理的に不可能だった「削除の伝達」が、CDC では実現できます。廃番商品、退職者情報、キャンセル済み受注、こうしたデータが AI の参照先に混入し続けることを防げます。

文字コードについても、CData Sync の DB2 for i 接続は多くの CCSID に対応しています。EBCDIC ベースのデータをジャーナルから読み取った後、UTF-8 として正しくクラウド DWH に届けられるため、半角カナや外字を含むテキストも文字化けせずに連携されます。

詳細な設定手順については、CData Sync V25.3 で DB2 for i（AS/400）の CDC をサポート をご覧ください。接続の設定からジョブの構成まで、具体的な手順を解説しています。

まとめ

IBM i のデータ活用は、「接続できる」フェーズから、「信じられる鮮度で AI へ渡し続けられる」フェーズへと移ってきています。データの鮮度・削除の反映・本番負荷・コストという課題に直面したとき、次の一手として CDC を選べるかどうかで、AI に渡るデータの信頼性は大きく変わります。

CData Sync の CDC は、IBM i のジャーナル機能を活用して変更データを高精度にキャプチャし、クラウド DWH やデータ基盤に安定して届ける仕組みです。鮮度・整合性・削除の反映が維持されたデータが流れ続けることで、AI は「最新の事実」に基づいて答えられるようになります。IBM i を含む基幹データを AI 活用の土台へ整えていくうえで、力を発揮できる場面は多いのではないでしょうか。

IBM i の連携にご興味ある方は、ぜひ CData Sync のトライアルを試してみてください。

CData Sync 30日間無償トライアル