AS400をクラウド・API連携する前の確認リスト|IBM i周辺連携の失敗を防ぐ

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長期ロードマップも確認してください。