AS400 / IBM iを長く使い続ける場合、クラウド、Web、API、外部システムとの連携を検討する場面が増えます。ただし、連携は便利な一方で、設計を誤るとデータ不整合、二重送信、文字化け、権限過多、障害時の責任不明につながります。
AS400側の基幹処理は安定していても、周辺連携が弱いと現場の不満は残ります。連携を作る前に、データ責任、文字コード、処理タイミング、再送、監査、戻し方を整理しておくことが重要です。
連携前に確認する項目
| 項目 | 確認内容 | 失敗例 |
|---|---|---|
| データ責任 | AS400が正か、外部システムが正か | どちらを直せばよいか分からない |
| 文字コード | 日本語、半角カナ、外字、桁あふれ | 文字化けや桁ずれが起きる |
| タイミング | リアルタイム、日次、締め後、手動 | 未確定データを送ってしまう |
| 再送 | 失敗時の再送、二重送信防止、履歴 | 同じ注文や売上を二重処理する |
| 権限 | 接続ID、参照範囲、更新範囲 | 必要以上の権限を与える |
| 監査 | 誰が、いつ、何を送ったか | 障害時に追跡できない |
API化だけが正解ではない
AS400連携では、API化が常に正解とは限りません。参照だけならCSV出力やBI連携で十分なことがあります。日次でよい処理をリアルタイム連携にすると、障害時の責任範囲や監視が急に重くなります。
- 参照だけ: CSV、BI、Web照会で足りる場合がある
- 日次更新: バッチ連携の方が管理しやすい場合がある
- 即時反映: APIやメッセージ連携の監視が必要
- 重要更新: 再送、排他、戻し、監査ログが必須
再送設計を先に決める
外部連携で事故になりやすいのは、失敗した時です。送れなかった時に再送するのか、途中まで送った時にどう判定するのか、同じデータを二重送信しない仕組みがあるのかを先に決めます。
再送の考え方は AS400外部インターフェース再送チェックリスト、CSV取込の注意点は AS400 CSV取込エラー確認も参考にしてください。
運用に落とす時の確認
- 異常時に誰へ通知するか
- QSYSOPR、ジョブログ、外部側ログのどこを見るか
- 再送してよい条件と、してはいけない条件
- 締め処理中に連携してよいか
- 保守担当と業務担当の責任分界
- 監査や個人情報の扱い
連携は作って終わりではなく、日々の運用に入ってからが本番です。障害時の初動、再送判断、問い合わせ先、ログ確認手順まで残しておくと、AS400を安全に使い続けやすくなります。
まとめ
AS400をクラウド・API連携する前には、データ責任、文字コード、タイミング、再送、権限、監査、障害時対応を整理してください。周辺連携を丁寧に設計すれば、IBM iの基幹処理を守りながら、現場の利便性を高められます。
周辺改善の優先順位は AS400周辺システム現代化の優先順位、全体方針は AS400長期ロードマップも確認してください。
API連携はつなぐ前に運用を決める
AS400をクラウドや外部サービスとAPI連携する時は、つなぐ技術より先に運用を決めます。再送、二重送信、文字コード、締め後訂正、障害時の切り戻し、相手先への連絡手順が曖昧だと、連携後の方が現場負荷が増えます。
API化やデータ連携は、AS400を残しながら周辺を現代化する有効な手段です。ただし、夜間バッチやEDIと同じく、業務担当者が影響範囲を説明できる状態にしてから進めることが大切です。
クラウド/API連携前のAS400側チェック
クラウド連携は接続方式だけを決めても進みません。AS400側のデータ更新タイミング、文字コード、再送、障害時の戻し方を先に確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| データ境界 | どのPF/LFを、どのタイミングで、誰が正とするか決める | 二重更新や上書きが起きない設計にする |
| 文字コード | CCSID、全角半角、日付、符号付き数値、ゼロ埋めを確認する | CSVやJSON変換後の見た目だけで判断しない |
| 障害対応 | API失敗時の再送、取消、手動補正、監視通知を決める | 連携成功よりも失敗時の運用を先に説明できるようにする |
AS400とクラウドをつなぐ時は、技術方式よりも業務データの責任境界を先に決めると失敗しにくくなります。
関連するAS400実務記事
クラウド・API連携では、通信方式だけでなく、止まった時の切り分け、戻し方、確認コマンドまで設計します。