AS400 / IBM i の現場では、「古い5250画面をWeb化したい」「外部システムとAPI連携したい」「CSV連携をやめたい」「既存RPGを残したまま周辺だけ新しくしたい」という相談が増えます。Web化やAPI連携は魅力的ですが、現行業務を理解しないまま進めると、本番処理やデータ整合性を壊すことがあります。
AS400連携で最初に決めること
AS400 / IBM i を外部システムやWeb APIと連携するときは、最初に「どの処理を外に出すか」を決めます。既存のRPG/CL、DB2 for i、夜間バッチ、5250画面をすべて置き換えるのではなく、在庫照会、入出荷状況、請求データ、EDI連携など、外部から使わせたい範囲を切り出す方が現実的です。
- 照会系と更新系を分け、更新系は承認・ログ・排他制御を先に決める
- リアルタイム連携と夜間バッチ連携を混ぜない
- 文字コード、日付形式、ゼロ埋め、桁数を連携仕様に明記する
- 障害時にAPI側ログとAS400側ジョブログを突き合わせられるようにする
- 再送、再実行、重複更新の扱いを事前に決める
文字コードやCSV連携は AS400のCCSID・CSV文字化け確認、外部連携の障害切り分けは AS400のEDI・外部インターフェース障害確認、改修前の影響確認は RPG/CL影響調査チェックリスト も合わせて確認してください。
この記事では、AS400のWeb化・API連携を検討する前に整理することを、保守現場の目線でまとめます。ツールや方式を決める前に、業務、データ、ジョブ、エラー時の扱いを先に確認することが大切です。
最初に決めるのは方式ではない
Web化やAPI連携の話になると、すぐに画面、フレームワーク、API方式、クラウド連携の話に進みがちです。しかし最初に見るべきなのは、対象業務とデータの流れです。受注、出荷、在庫、売上、請求、締め処理のどこに関係するのかを確認します。
| 確認項目 | 見る理由 | 関連ページ |
|---|---|---|
| 対象業務 | どの処理をWeb化・連携対象にするか | 販売管理システム保守ガイド |
| 対象データ | どのファイルを読み書きするか | DSPFFD / DSPPFM |
| 既存処理 | RPG/CL、夜間バッチ、帳票、外部連携の影響 | DSPPGMREF影響調査 |
| ファイル連携 | CSV、IFS、FTP、再送、文字コード | IFS入門 |
| 障害時 | 再実行、二重送信、取り消し、ジョブログ | 本番障害の初動対応 |
Web化でよくある落とし穴
- 画面だけ新しくして、裏側の業務ロジックを理解していない
- AS400側の更新タイミングとWeb側の登録タイミングがずれる
- バッチ処理中に外部から更新してしまう
- CSV連携の再送や二重取込のルールがない
- 権限と個人情報の扱いを後回しにする
- エラー時にどちらのシステムで復旧するか決まっていない
API連携で先に決めること
API連携では、どのデータを、いつ、どちらが主として、どの単位で連携するかを決めます。リアルタイム連携が必要なのか、日次バッチで十分なのか、失敗時に再送できるのか、同じ伝票を二重処理しないかが重要です。
| 論点 | 確認すること |
|---|---|
| 主システム | AS400側が正か、外部側が正か |
| 連携タイミング | 即時、定期、夜間、手動再送 |
| エラー処理 | 失敗時の通知、再実行、取り消し、二重防止 |
| データ形式 | CSV、JSON、固定長、文字コード、桁数 |
| 機密情報 | 顧客情報、金額、認証情報、ログ出力 |
リプレースとは分けて考える
Web化やAPI連携は、全面リプレースとは別の選択肢です。AS400を残しながら、周辺の画面や連携だけを新しくする方法もあります。判断に迷う場合は、AS400モダナイゼーション・リプレース判断ガイド を先に確認してください。
API化の前に、既存処理の読み解き方をそろえる
AS400をWeb APIや外部システムと連携する場合、最初からAPI方式だけを決めても失敗しやすいです。既存のRPG/CLがどのファイルを更新しているか、夜間バッチと競合しないか、エラー時にどのジョブログを見るか、再実行してよい処理かを先に整理しておく必要があります。
特に、既存処理を残したまま連携口を増やす場合は、影響調査、権限、文字コード、CSV/IFS（統合ファイルシステム）、監査ログの見方まで現場側と共有しておくと安全です。若手教育や引き継ぎと合わせて進める場合は、AS400学習ロードマップと法人向けAS400 / IBM i Codex研修も入口になります。
AS400連携方式を目的から選ぶ
「AS400をAPI化する」と言っても、既存RPG/CLを外部公開する方法、外部アプリからDB2 for iへ接続する方法、IFSとファイルで受け渡す方法では、確認する場所が違います。方式名から選ばず、対象業務と更新の有無から絞ります。
| 目的 | 方式の例 | 先に確認すること | 主な注意点 |
|---|---|---|---|
| 既存RPG/CLの処理を外部から呼ぶ | IBM i Integrated Web Services | 入出力パラメーター、実行ユーザー、コミット範囲 | 既存処理が対話ジョブやライブラリー・リストを前提にしていないか |
| 外部アプリからデータを参照・更新する | ODBC / JDBC / SQL | SQL権限、ジャーナル、トランザクション、業務ロジック | RPG側の入力チェックや在庫引当を飛び越えないか |
| 定時にまとまったデータを渡す | IFS、CSV、SFTP | CCSID、桁数、ファイル確定条件、再取込防止 | 転送途中の読込み、二重取込、処理済みファイルの残し方 |
| 5250画面の操作性を変える | Web画面やフロントエンドを追加 | 画面裏のRPG/CL、Fキー、セッション、権限 | 見た目だけを変えて既存の業務判断を欠落させないか |
既存ILEプログラムやサービス・プログラムをWebサービスとして公開する選択肢は、IBMのIntegrated Web Services for IBM iでも確認できます。DB接続を使う場合はODBC/JDBC接続の確認ポイント、ファイル連携はIFSの基本も合わせて確認してください。
照会APIと更新APIを同じ設計にしない
在庫照会APIは、参照権限、応答項目、検索条件、負荷を確認すれば小さく始めやすい処理です。一方、受注登録APIは、在庫引当、得意先チェック、締め状態、伝票番号採番、ジャーナル、後続バッチまで影響します。同じ「API」という名前でも、更新系は戻し方まで決まらなければ本番へ出せません。
| 確認 | 照会API | 更新API |
|---|---|---|
| 権限 | 必要なファイルの参照だけに絞る | 対象処理に必要な更新だけに絞る |
| 再試行 | 同じ照会を再実行できる | 受付番号や一意キーで二重登録を防ぐ |
| 障害記録 | 検索条件と応答エラーを残す | 更新前後、ジョブ、受付番号、結果を残す |
| 復旧 | 原因解消後に再照会する | 取消、再送、手動補正の承認手順を決める |
更新APIを設計する時は、API側のエラーだけで判断せず、IBM i側のジョブログとジャーナルで「どこまで更新されたか」を確認できるようにします。本番データや認証情報を外部ログへそのまま出さず、調査に必要な受付番号と処理結果を残します。
影響調査をAIで補助する時の使いどころ
Codexは、RPG/CLの処理概要、更新ファイル、呼び出し関係、テスト観点を整理する補助になります。ただし、API公開範囲、権限、業務影響、外部接続の最終判断は人が行います。機密情報や本番データをマスキングし、調査メモやレビュー観点のたたき台として使うのが安全です。
次に確認するAS400 Web化・連携記事
- AS400のRPGをWeb化する前に確認すること
- AS400 ODBC/JDBC接続の確認ポイント
- AS400の文字化け・CCSID確認ポイント
- AS400モダナイゼーション・リプレース判断ガイド
- RPG/CLソース解析をCodexで整理する手順
API連携は、保守と教育の設計まで含めて考える
AS400 / IBM iをWebや外部システムにつなぐ時は、APIの作り方だけでなく、誰が障害時に切り分けるか、どのログを見るか、既存RPG/CLへの影響を誰が判断するかまで決めておく必要があります。連携先が増えるほど、IBM i側だけでなく、ネットワーク、文字コード、権限、ジョブ、バッチ、相手システムの変更が絡みます。
現場で安全に進めるなら、まずは「既存処理を変えずに読み取りだけ行う範囲」「更新系APIを許可する範囲」「障害時に止めてもよい範囲」を分けます。若手や引き継ぎ担当に教える場合も、API名やURLだけを覚えるのではなく、AS400側のデータ、権限、ジョブログ、影響調査の順番をセットで学ぶと、保守できる連携になります。
まとめ
AS400 / IBM iのAPI連携では、方式を決める前に、対象業務、参照・更新の区分、既存RPG/CL、権限、再送、二重処理防止、ジョブログ、戻し方を整理します。まず照会系から小さく始め、更新系は業務ロジックと復旧手順を含めて設計するのが安全です。既存ソースを題材に調査手順を社内でそろえる場合は、法人向けAS400 / IBM i Codex研修の内容・料金を確認してください。
