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

2026.06.11

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

外部連携で見る順番

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

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

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

締め処理との関係を見る

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

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

Codexで連携フローを整理する

Codexには、匿名化した連携フロー、ファイル形式、発生時刻、確認済みログだけを渡すと、どこで止まったかを整理しやすくなります。取引先名や実データは入れず、再送判断は人が行います。

EDIは相手先が絡むため、技術確認と業務影響を分ける

EDI障害は、AS400側のジョブが正常終了しているだけでは完了と言えません。相手先が受信したか、取込できたか、出荷・納品・請求締めに影響するかを同時に見ます。ここを分けずに再送すると、二重送信、未送信、相手先処理の停止につながります。

  • AS400側でファイルが作成済みかを見る
  • 送信先、送信日時、件数、キー項目を残す
  • 相手先が未受信、受信済み、取込エラーのどれかを分ける
  • 再送してよいデータか、締め後に触るデータかを業務担当者と確認する
  • 本番データを直す場合は、更新前データと承認を残す

再送前に確認する判断表

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

取引先へ確認する前にそろえる情報

EDI障害では、相手先へ問い合わせる前にAS400側で分かる情報をそろえておくと、再送してよいか、相手先側で止まっているかを早く切り分けられます。

情報見る場所目的
送信日時・件数ジョブログ、送信ログ、出力ファイル相手先の受信件数と照合する
キー項目伝票番号、相手先コード、ファイル名対象データを絞る
処理状態未作成、作成済み、送信済み、取込済み再送か取込確認かを分ける
業務影響出荷、請求、締め、納品急ぐべきか、止めるべきか判断する

EDI障害で先に読む記事

障害の入口がどこかで、次に見る記事を変えます。テストデータ、本番再送、相手先連絡、MSGW（メッセージ応答待ち）、ジョブログ、更新前後の確認を分けて読むと、復旧判断がぶれにくくなります。

現場メモ：相手が悪くても、まず基幹側が疑われる

EDIのトラブルでよくあるのが、相手先が原因でも基幹側が疑われるという構図です。これは誰かが意地悪をしているわけではありません。手元にあって、すぐ見に行けるのが基幹だからです。相手先のシステムは見られないので、消去法でこちらから調べることになります。

だから、疑われること自体は避けられません。大事なのは「こちらは正しく送っている」を短時間で示せる状態にしておくことです。ここで手間取ると、原因の切り分けが始まる前に時間だけが過ぎます。

何を出すかは、そのシステムの作りによります。FTPで転送しているならFTPのログ、HULFTのような転送製品を使っているならその製品の転送履歴、あるいは転送を実行したジョブのジョブログを提示します。

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

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

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

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

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

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

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

バッチでFTPを流している場合、IBM公式のサンプルは次の形になっています。

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ソースを見れば分かります。

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

日付を付けて残す、一定期間分を保持する、といった作りになっているかを平常時に確認しておいてください。障害の日に確認することではありません。

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

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

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

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

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

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

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

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

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

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

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

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

スポンサーリンク