AS400 EDI・外部連携トラブル確認手順｜取引先・再送・ジョブログを切り分ける

2026.06.11

AS400 / IBM i は、取引先とのEDI、FTP、CSV、外部システム連携で使われることが多くあります。連携トラブルは、AS400側の処理、ファイル転送、文字コード、取引先側の取込、業務締め処理が絡むため、原因を一つに決めつけると時間がかかります。

外部連携で見る順番

確認見るもの判断
作成AS400上の出力ジョブ、スプール、ログ送信前ファイルが作られたか
配置IFS、送信フォルダ、更新時刻正しい場所にあるか
転送FTPログ、送信時刻、リターンコード取引先へ届いたか
形式CSV、固定長、文字コード、改行取込できる形式か
取込取引先結果、外部システムログAS400後の失敗か

AS400側で作成済みでも完了ではない

連携では、AS400側でファイルが作成されていても、FTPで送れていない、文字コードで弾かれた、取引先側で取込エラーになった、ということがあります。作成、配置、送信、受信、取込を分けて確認します。

締め処理との関係を見る

請求締めや出荷確定と外部連携がつながっている場合、再送や再取込の判断を誤ると二重計上や未送信につながります。送信済みデータ、取込済みデータ、締め済み状態を確認してから対応します。

外部連携の関連手順は、目的別に次から確認してください。

再送前に確認する判断表

確認すること見る理由次の判断
AS400側の出力ファイル作成前で止まったのか、送信後の問題かを分けるジョブログ、MSGW、出力先を確認する
相手先の受信状態再送してよいか、二重送信になるかを判断する未受信、受信済み、取込エラーを分ける
データ種別受注、出荷、請求で影響範囲が変わる業務担当者と締め・納品影響を確認する
再送キー対象範囲を曖昧にすると別データまで流れる相手先コード、伝票番号、件数を控える
更新前後の証跡戻しやリランの判断材料になる必要に応じてDSPJRNやバックアップを確認する

「こちらは送っている」を示すために出すもの

疑われた時に出す材料は、システムの作りで変わります。自分の環境ではどれが残るのかを、平常時に確認しておいてください。

転送の方式見るもの確認する内容
FTPFTPのセッション出力接続できたか、転送が成功で終わったか
HULFTなどの転送製品製品側の転送履歴配信・集信の結果と時刻
いずれの場合も転送を実行したジョブのジョブログ正常終了か、エラーで抜けていないか

相手先に「そちらで確認してほしい」と言うためには、最低限これが揃っている必要があります。

  • いつ送ったか（日時。相手先の受信時刻と突き合わせる）
  • 何を送ったか（ファイル名、対象の範囲）
  • どこへ送ったか（接続先。宛先違いはここで分かる）
  • 何件送ったか（件数。届いた件数と比べられる）
  • 結果はどうだったか（正常終了しているか）

送信100件・相手側取込98件という差は、調べる区間を絞る材料です。ただし、件数だけで相手側の責任とは決められません。同一の送信ファイルか、業務キーが一致するか、重複排除・エラー除外・部分受領・再送がないかを双方の記録で照合します。こちらの送信が98件の場合も、抽出条件だけでなく元データ、生成処理、送信結果まで追います。

FTPで転送している場合、ログはどこに残っているか

バッチFTPの記録先は、IBM公式の「単純な例：バッチFTP」で次のように示されています。既存CLからINPUTとOUTPUTの指定を読むための引用であり、そのまま実行する手順ではありません。

PGM
OVRDBF FILE(INPUT)  TOFILE(ITSOLIB1/QCLSRC) MBR(FTPCMDS)
OVRDBF FILE(OUTPUT) TOFILE(ITSOLIB1/QCLSRC) MBR(OUT)
FTP RMTSYS(SYSxxx)
ENDPGM

INPUT にFTPのコマンドを並べたメンバーを割り当て、OUTPUT にFTPのメッセージが書き出されます。つまり、この OUTPUT に指定されたメンバーが転送の記録そのものです。自分の環境でどこに割り当てられているかは、転送を動かしているCLソースを見れば分かります。

ここに落とし穴があります。毎回同じメンバーに上書きしている場合、次の転送が走った時点で前回の記録は消えます。問い合わせが来るのは翌日以降であることが多いので、見に行った時にはもう残っていない、ということが起こります。

日付を付けて残す、一定期間分を保持する、といった作りになっているかを平常時に確認しておいてください。障害の日に確認することではありません。FTPのINPUTやOUTPUTには認証情報や接続先、業務情報が含まれる場合があります。保管先の閲覧権限を制限し、相手先やAIへ共有する際は共有許可を確認したうえで、秘密値と不要な業務情報を除いた最小限の記録だけを渡します。

なお、ILE CLで書く場合は OVRDBF に OVRSCOPE(*CALLLVL) を付ける必要がある点が、IBMのサンプルにも注記されています。活動化グループの扱いで上書き指定の有効範囲が変わるためです。

相手先が原因だった時に多いパターン

  • 相手先のフォーマットが変わっていて、こちらには連絡が来ていなかった
  • こちらは送信できているが、相手先の取り込み処理で落ちている
  • 相手先の受信フォルダーは合っているが、その先の処理が動いていない
  • 相手先の締め時刻を過ぎていて、次回扱いになっていた

いずれの場合も、こちらの転送記録が出せれば切り分けは早く終わります。逆に出せないと、原因が相手先にあっても、こちらの調査から始まります。記録を残す作りにしておくこと自体が、障害対応の時間を決めています。

取引先にデータが届かない時の想定例

取引先から未着連絡があった場合、すぐ再送せず、AS400側の作成、転送、相手側受領のどこまで進んだかを確認します。

確認点確認内容判断
作成対象伝票、送信ファイル、作成時刻、件数、ステータスを確認する送信対象外と作成失敗を分ける
転送FTPや連携ジョブのログ、ファイル名、送信結果、応答を確認する接続成功だけでファイル受領済みと判断しない
相手側受領確認、取込結果、重複判定キー、再送可否を確認する相手と合意せず同じデータを再送しない

再送する場合は、対象キー、前回送信時刻、相手側状態、二重計上防止策を記録します。AS400側の再送完了だけでなく、相手の取込結果まで確認します。

境界の話は、最後まで誰の担当か決まらないまま流れることがあります

相手先のベンダーと自社側で、どちらの担当か決まらないまま止まる案件があります。調べれば相手側の問題だと分かっていても、押し付け合いをしている間に業務は止まったままです。

私が関わった案件では、最終的に基幹側でなんとか対応しました。本来の担当ではありませんが、止めておくよりは早いという判断です。結果としてお客様には恩を売る形になりました。

きれいな話ではありません。ただ、境界が曖昧なまま放置される案件は実際にあり、動ける側が動いた方が、後々の関係も含めて得になる場面があるのは事実です。その代わり、どこまでを引き取ったのかは記録に残しておかないと、次から当然のように回ってきます。

スポンサーリンク