国内約2万社
国内IBM i利用企業
日本IBM関係者の公開資料では、世界約15万社、国内約2万社で利用されると説明されています。(参考)
IBM i モダナイゼーション
IBM i（AS/400）
モダナイゼーション
AS400 / COBOL マイグレーションを、現状分析から Java/API/クラウド移行、運用安定化まで支援
QueryPie AIは、COBOL/RPG資産の解析・可視化、 設計書・テストケース生成、DB2 / Oracle分析、 PostgreSQL移行、Linux / OCI / AWS環境への移行まで、 既存業務を止めない段階的な刷新を支援します。
市場背景
AS/400とCOBOL資産は、
今も基幹システムの重要テーマです
AS/400（現在のIBM i）は、IBM Power上で動作する統合型の基幹業務プラットフォームです。
RPG、COBOL、CL、Db2 for i、ジョブ、帳票、5250画面などが業務と深く結びついているため、
単なるサーバー更改ではなく、業務ロジックを理解したうえでの段階的なモダナイゼーションが必要です。
約70%
基幹業務の過半をIBM iで運用
Fortraの2026年調査では、IBM i利用企業の約70%が基幹業務アプリケーションの半数以上をIBM iで運用しています。(参考)
最大12兆円/年
2025年以降の経済損失リスク
経済産業省のDXレポートが示した、レガシーシステムの複雑化・ブラックボックス化に関する警告です。(参考)
1兆3,044億円
2025年ITモダナイゼーション市場
IDCの日本ITモダナイゼーションサービス市場予測を、全体市場の背景として扱います。(参考)
日本企業に残るIBM i（AS/400）やCOBOL/RPGの基幹システムは、 古いから残っているのではありません。受発注、在庫、会計、決済、 給与、顧客管理といった止められない業務を、長期間安定して 支えてきたからこそ、簡単には置き換えられない資産になっています。
一方で、長年の改修で仕様が属人化し、プログラム、テーブル、 ジョブ、帳票、外部連携の関係が見えにくくなると、改修や移行の 影響範囲を判断しにくくなります。経済産業省のDXレポートが 指摘した「2025年の崖」も、レガシーシステムの複雑化と ブラックボックス化を放置するリスクを考えるうえで重要な文脈です。
IBM iは統合型プラットフォーム
OS、Db2 for i、ジョブ管理、セキュリティ、5250画面、RPG/COBOL/CLが 一体で運用されるため、Linux移行やデータベース移行だけでは全体像を説明できません。
データと業務ロジックが近い
Db2 for i、DB2 / Oracle、帳票、バッチ、周辺システム連携まで含めて、 どの業務がどの資産に依存しているかを整理する必要があります。
AI分析の入口が明確
コード説明、仕様書生成、依存関係整理、影響度分析、テスト範囲の抽出は、 段階的な移行判断の前提になります。
刷新が必要な理由
なぜ今、AS400 / COBOL モダナイゼーションが必要なのか
課題は、システムが動かないことではありません。安定して動いているからこそ、変える判断が遅れ、
保守人材、コスト、仕様のブラックボックス化、DX施策との接続が同時に難しくなることです。(参考)
「動いているから触らない」が限界に近づく
長年稼働してきた基幹システムは、業務に深く組み込まれています。 しかし担当者の退職、ベンダー依存、改修履歴の蓄積が進むほど、 触らない判断そのものが将来のリスクになります。(参考)
影響範囲が分からず、改修判断が遅れる
1つの画面や帳票の変更でも、プログラム、ファイル、ジョブ、外部連携、 テスト範囲が連鎖します。見えない依存関係を可視化しなければ、 小さな改修も大きなリスクになります。
クラウド、API、データ活用につながりにくい
既存IBM iを残しながらAPIで外部化するのか、Java化するのか、 PostgreSQLやLinux / OCI / AWSへ移すのか。選択肢を比較するには、 現行資産の構造理解が必要です。(参考)
AI活用
全面再開発ではなく、
まずAIで現行システムを理解する
QueryPie AIは、既存資産をただ置き換えるのではなく、
コード、データベース、ジョブ、帳票、外部連携を読み解き、移行判断に必要な情報へ変換します。
入力情報
既存資産を集める
- COBOL / RPG / CLプログラム
- Db2 for i、DB2 / Oracle、ファイル定義
- ジョブ、帳票、画面、外部連携
分析
AIで構造化する
- 業務ロジックと処理フローの説明
- テーブル、プログラム、バッチの依存関係整理
- 改修・移行時の影響度分析
出力
判断材料に変える
- 現行仕様書、データモデル、移行対象分類
- テストケース、テスト範囲、優先順位
- PoC計画、移行ロードマップ、実装方針
成果物
設計書、影響度、テストケースまで
移行判断に必要な成果物をそろえる
AI分析の目的は、単にコードを説明することではありません。
現行業務を止めずに、どこから着手し、何を残し、何を移すかを判断できる状態を作ることです。
仕様書
現行仕様書の生成
COBOL/RPGプログラムの処理内容、入力、出力、例外処理、業務ルールを読み解き、担当者が確認できる現行仕様として整理します。
依存関係
依存関係と影響度の整理
プログラム、テーブル、ジョブ、帳票、外部連携の関係を可視化し、改修や移行時に影響を受ける範囲を確認します。
データモデル
データベース・データモデル分析
Db2 for i、DB2 / Oracle、ファイル定義、データ項目の関係を整理し、PostgreSQL移行やAPI化の前提を作ります。
テスト
テストケース生成
業務ロジックとデータ整合性を確認するためのテスト観点、正常系・例外系、移行後の比較検証範囲を整理します。
ロードマップ
移行対象の分類
残す機能、外部化する機能、Java化する機能、データベース移行が必要な領域を分け、PoCと段階移行の優先順位を作ります。
知識継承
業務知識の検索・継承
属人化した仕様やベテラン担当者の知識を、検索・確認しやすい形に変換し、新しい担当者のオンボーディングを支援します。
移行設計
Java / PostgreSQL / Linux / クラウドへ、
状況に応じた移行ルートを設計する
最初から全体を置き換えるのではなく、既存IBM iを残す選択肢も含めて、
API化、Java化、データ移行、クラウド移行を段階的に組み合わせます。
現行
IBM i（AS/400）
- RPG / COBOL / CL
- Db2 for i、DB2 / Oracle
- 5250画面、ジョブ、帳票
橋渡し
AI分析とPoC
- 業務影響と移行難易度を評価
- 変換精度とテスト可能性を検証
- 優先順位と実装単位を決定
移行先
次世代アーキテクチャ
- Java / API / クラウド
- PostgreSQL / Linux
- OCI / AWS / オンプレミス併用
APIで外部化
既存IBM iをすぐに置き換えず、必要な機能からAPIで外部システムと接続します。
COBOL/RPGからJavaへ
変換対象を絞り、PoCで精度、例外処理、テスト可能性を確認しながら進めます。(参考)
PostgreSQLへデータ移行
テーブル、ファイル、データ項目、整合性チェックを整理し、段階的に移行します。
Linux / OCI / AWSへ展開
運用、監視、権限、接続方式を含めて、移行後に使い続けられる基盤を設計します。
サービス範囲
現行理解から段階移行まで、
サービス範囲を一つの流れで支援
受発注、在庫、請求、バッチ、帳票、外部連携といった業務単位に沿って現行資産を理解し、
AI分析、PoC、移行設計、実装、並行稼働、運用安定化までつなげます。
01 棚卸し
現行業務と技術資産の棚卸し
受発注、在庫、請求、給与などの業務単位で、COBOL/RPGプログラム、DB2 / Oracle、ジョブ、帳票、ファイル連携を整理し、移行の全体像を把握します。
02 分析
AI分析と影響度整理
コード構造、業務ロジック、データモデル、依存関係、改修時の影響範囲をAIで整理し、仕様書、データモデル、テスト観点として確認できる状態にします。
03 計画
移行対象と残す領域の切り分け
Java化、API化、PostgreSQL移行、クラウド移行に進める領域と、当面IBM i上に残す領域を分け、業務影響と優先度に基づいて段階的なロードマップを作ります。
04 検証
小さく検証するPoC
在庫照会、取引先マスタ、請求状況など、業務影響を抑えやすい範囲から、変換精度、データ整合性、API連携、移行後の運用イメージを検証します。
05 実装
変換・実装と基盤移行
PoCで確認した範囲から、COBOL/RPGのJava化、API連携、PostgreSQL移行、Linux / OCI / AWS環境への展開、周辺システム連携を進めます。
06 安定化
テスト、並行稼働、運用安定化
新旧システムの照合テスト、性能確認、並行稼働、切り戻し、監視、障害対応、運用ドキュメント整備まで、現場が使い続けられる状態を目指します。