JP1で夜間FTP連携を自動化する方法｜421エラー対策と安全な再実行

業務システムのデータを基幹システムへ連携する際、担当者がCSVファイルを作成し、決められた時刻にFTPサーバーへ手動送信する運用では、作業忘れやファイル選択の間違いが発生する可能性があります。また、担当者が不在の場合に連携が遅れる、送信結果を後から追跡しにくいといった課題もあります。

そこで、業務システムから連携対象データを抽出し、CSVなどの連携ファイルを作成して、JP1の夜間ジョブからFTP送信する処理を構築しました。正常時は人の操作を必要とせず、決められた時刻に自動実行します。一方、エラーが発生した場合は、失敗した工程を特定し、必要なジョブだけを安全に再実行できる構成にしています。

実際の運用では、手元の端末からFTP接続できるにもかかわらず、夜間ジョブでは421エラーが発生する事象も経験しました。調査の結果、JP1実行サーバーの接続元IPアドレスが、FTPサーバー側のホワイトリストへ登録されていないことが原因でした。この経験から、認証情報だけでなく、接続元制限やNAT後のIPアドレスも連携設計時に確認する必要があると分かりました。

本記事では、ファイル作成からFTP送信、受信側の取り込み確認までをどのように分割したか、作成途中のファイルを送信しない仕組み、二重送信や二重取り込みを防ぐ再実行設計、ログと異常通知、本番稼働前のテスト項目を実例に沿って解説します。実際のホスト名、IPアドレス、FTPアカウント、ディレクトリ名などは伏せ、一般的な業務システムと基幹システムの連携として記載します。

今回自動化した夜間ファイル連携

今回自動化したのは、業務システムで管理しているデータを夜間に抽出し、連携ファイルとして基幹システムへ送信する処理です。自動化前は、担当者が対象データを確認してファイルを出力し、FTPクライアントを使って指定ディレクトリへ送信していました。

手動作業では、送信日時が担当者の作業状況に左右されます。さらに、前日分のファイルを誤って送信する、送信先ディレクトリを間違える、処理後のファイルを残したままにするといったリスクもあります。送信後に基幹システムへ取り込まれたかどうかを確認する作業も別途必要でした。

そこで、連携対象の抽出からファイル送信までをJP1の夜間ジョブとして登録しました。指定時刻になると、最初に連携対象データを抽出し、CSV形式のファイルを作成します。その後、ファイルの存在、サイズ、件数などを確認してからFTP送信を実行します。送信後はファイルを退避し、結果確認と異常通知へ進みます。

加えて、処理が途中で失敗した場合に一連のジョブを最初からやり直さなくて済むよう、工程を複数のジョブへ分割しました。たとえば、連携ファイルが正常に作成され、FTP送信だけが失敗した場合は、ファイル作成を再実行せず、送信ジョブから再開できます。

ただし、自動化は「毎晩FTPコマンドを実行する」だけでは完成しません。送信済みファイルを再送しないこと、受信側ですでに取り込まれていないか確認できること、エラー時に担当者が判断できるログを残すことまで含めて設計する必要があります。

夜間連携の全体構成

夜間連携は、業務システム、JP1実行サーバー、FTPサーバー、基幹システムという複数の要素で構成されています。そのため、「連携エラー」という結果だけを見ても、どこで失敗したかは分かりません。調査や再実行を行いやすくするには、処理の流れと各システムの担当範囲を明確にしておく必要があります。

業務システム
  ↓
連携データを抽出
  ↓
CSVなどの連携ファイルを作成
  ↓
ファイル内容を検証
  ↓
JP1のFTP送信ジョブ
  ↓
FTPサーバーへ送信
  ↓
基幹システムがファイルを取得
  ↓
取り込み処理を実行
  ↓
取り込み結果を確認

まず、業務システムから対象期間のデータを抽出します。抽出結果をCSVなどの形式で出力し、件数や必須項目、文字コード、ファイルサイズを確認します。検証を通過したファイルだけを、JP1のFTP送信ジョブへ渡します。

FTP送信に成功した後は、送信元ファイルを処理済みディレクトリへ移動します。ただし、FTPコマンドが正常終了しても、基幹システムへの連携が完了したとは限りません。受信側に携が完了したとは限りません。受信側にファイルが存在すること、さらに基幹システムの取り込み処理が正常終了したことまで確認する必要があります。

また、JP1上のジョブ名、実行サーバー、連携ファイルの保存場所、FTP接続先、基幹システム側の取り込み時刻を一覧化しておくと、障害時の連絡がスムーズになります。記事や手順書へ記載する場合は、実際のホスト名、IPアドレス、アカウント名、パスワード、内部ディレクトリなどを公開しないよう注意します。

JP1ジョブをどの単位に分けるか

一連の夜間連携を1つのスクリプトや1つのジョブへまとめると、正常時の実行は簡単です。しかし、途中で失敗した場合に、どこまで処理が完了しているか分かりにくくなります。また、FTP送信だけをやり直したい場合でも、データ抽出やファイル作成から再実行しなければならないことがあります。

そこで、今回の構成では、データ抽出、ファイル作成、ファイル検証、FTP送信、送信済みファイルの退避、処理結果確認、異常通知を分けました。各ジョブの正常終了を次のジョブの実行条件にすることで、途中の工程で異常が発生した場合は、後続処理を開始しないようにしています。

たとえば、データ抽出ジョブが失敗した場合は、ファイル作成ジョブを実行しません。ファイル検証で0バイトや形式不正が見つかった場合は、FTP送信を止めます。一方、正しいファイルが作成済みでFTP送信だけが失敗した場合は、送信ジョブから再実行できます。

ジョブを細かく分けすぎると管理対象が増えるため、分割の基準は「成果物が確定する工程」と「個別に再実行したい工程」です。データ抽出結果、正式な連携ファイル、送信済み状態、取り込み結果など、後から確認できる区切りでジョブを分けると運用しやすくなります。

連携ファイルを安全に作成する

夜間連携では、FTP送信処理だけでなく、送信するファイルの作り方も重要です。作成途中のファイルをFTPジョブが検知すると、データが途中までしか書き込まれていない状態で送信される可能性があります。

そのため、最初は正式なファイル名ではなく、一時ファイル名で出力します。たとえば、最終的にsales_20260731.csvとして送信する場合は、sales_20260731.csv.tmpのような名称で作成します。すべての書き込みとファイル検証が完了した後に、正式名称へ変更します。

sales_20260731.csv.tmp
  ↓ データ出力
件数・サイズ・形式を検証
  ↓ 正常
sales_20260731.csv へ名称変更
  ↓
FTP送信対象として認識

また、0バイトのファイルやデータ件数が0件のファイルをどう扱うかを事前に決めます。0件でも空の連携ファイルを送る仕様なのか、送信せず正常終了するのか、異常として担当者へ通知するのかは、受信側の仕様によって異なります。判断をスクリプト内へ曖昧に埋め込まず、連携仕様書へ明記します。

ファイル名には、処理日、対象日、システム識別子、必要に応じて連番を付けます。ただし、再実行のたびに新しい時刻を付けると、同じデータが別ファイルとして何度も取り込まれる可能性があります。再実行時に同じファイル名を使うのか、再送用の枝番を付けるのかも設計が必要です。

さらに、文字コード、改行コード、区切り文字、囲み文字、日付形式、数値形式を送受信側で統一します。ファイル作成ジョブが正常終了しても、文字コードや列数が想定と異なれば、基幹システム側の取り込みで失敗します。

FTP送信ジョブを実装する

FTP送信ジョブでは、接続先、接続アカウント、送信元ファイル、送信先ディレクトリ、タイムアウト、終了コード、ログ出力を設定します。どれか1つでも環境ごとに異なる可能性があるため、スクリプトへ直接固定値を書き込むのではなく、設定ファイルやJP1の環境変数などから取得できる構成が管理しやすくなります。

特に、パスワードをバッチファイルやシェルスクリプトへ平文で直接記載すると、ファイルを参照できる利用者へ認証情報が漏れる可能性があります。利用環境で用意されている資格情報管理機能、アクセス制限された設定領域、認証用の安全な仕組みを利用し、必要最小限の実行ユーザーだけが参照できるようにします。

以下は、実際のFTP製品やコマンドに依存しない処理イメージです。認証情報の取得方法やコマンドは、利用中の環境に合わせて置き換えます。

接続設定を読み込む
送信対象ファイルの存在を確認する
ファイルサイズと送信済み状態を確認する

FTPサーバーへ接続する
指定アカウントで認証する
送信先ディレクトリへ移動する
連携ファイルを送信する
送信結果をログへ記録する
FTP接続を終了する

終了コードをJP1へ返す

正常終了コードは、FTPクライアントの起動に成功したことだけではなく、ログイン、ディレクトリ移動、ファイル転送、切断まで完了したことを確認してから返します。コマンドの途中でエラーが発生したにもかかわらず、最後の処理が成功したことでジョブ全体が正常終了にならないよう注意します。

タイムアウト値も重要です。短すぎると、一時的なネットワーク遅延で異常終了します。一方、無期限に待機すると、接続が停止した状態でジョブネット全体が進まなくなります。通常時の転送時間とファイルサイズを記録し、余裕を持たせた値を設定します。

送信結果をどのように判定するか

JP1のジョブが正常終了しただけでは、基幹システムへの連携が完了したとは限りません。FTPクライアントが正常終了しても、受信側の想定と異なるディレクトリへ送信していたり、基幹システム側の取り込み処理が失敗していたりする可能性があります。

まず、FTPコマンドの終了コードと送信ログを確認します。ログには、接続開始、認証結果、送信先ディレクトリ、対象ファイル名、転送サイズ、完了時刻、FTPサーバーからの応答などを残します。パスワードなどの秘密情報はログへ出力しません。

次に、FTPサーバー側へ対象ファイルが到着しているかを確認します。送信元と受信側で、ファイル名、ファイルサイズ、必要に応じてハッシュ値などを比較できれば、途中で欠損していないことを確認しやすくなります。

最後に、基幹システム側の取り込み結果を確認します。取り込み件数、エラー件数、処理日時、処理済みファイル名などを取得できる場合は、JP1の後続ジョブや監視処理で確認します。受信ファイルが存在していても、形式不正やデータ不備によって取り込みに失敗している場合があります。

つまり、夜間連携の完了条件は、「JP1が正常終了した」ではなく、「正しいファイルが受信され、基幹システムで正常に取り込まれた」とする必要があります。

421エラーが発生した実例

夜間連携の運用開始後、JP1のFTP送信ジョブで421エラーが発生しました。FTPの421エラーは、FTPサーバー側がサービスを利用できない状態として接続を終了した場合などに返されます。ただし、エラーコードだけでは、サービス停止、接続数超過、接続元制限、ファイアウォールなどのどれが原因か特定できません。

最初に、業務システム側で連携ファイルが正常に作成されていることを確認しました。ファイル名、更新日時、サイズに問題はなく、JP1ジョブも予定時刻に起動していました。ログを確認すると、ファイル転送より前のFTP接続段階で421エラーになっていました。

次に、管理者の端末からFTPサーバーへ手動接続したところ、同じアカウントで接続できました。一見すると、FTPサーバーの停止やアカウントの無効化ではないように見えます。しかし、夜間ジョブを再実行すると、引き続き421エラーが発生しました。

そこで、手動接続と夜間実行の違いを整理しました。管理者端末とJP1実行サーバーでは、接続元IPアドレスやネットワーク経路が異なります。調査した結果、FTPサーバー側では接続元IPアドレスをホワイトリストで制限しており、管理者端末側の接続元は許可されていたものの、JP1実行サーバーの接続元は登録されていませんでした。

FTPサーバー側へJP1実行サーバーの接続元IPアドレスを追加した後、実際のジョブ実行環境から接続を確認し、FTP送信ジョブを再実行しました。その結果、ファイルが正常に到着し、基幹システム側の取り込みまで完了しました。

接続元制限を設計時に確認する

421エラーの経験から、接続試験ではアカウントとパスワードだけでなく、実際のジョブ実行サーバーから通信できるかを確認する必要があると分かりました。管理者端末から接続できても、夜間ジョブと同じ条件で接続できるとは限りません。

FTPサーバー側で接続元IPアドレスを制限している場合は、本番環境と検証環境の接続元をそれぞれ登録します。サーバー内で確認できるIPアドレスではなく、NATやファイアウォールを通過した後にFTPサーバーから見えるIPアドレスを確認することが重要です。

また、サーバー更改やクラウド移行、ネットワーク構成変更によって、接続元IPアドレスが変わる場合があります。ジョブ定義、接続先、アカウントを移行しても、FTPサーバー側のホワイトリストが旧環境のままであれば、新しい実行サーバーから接続できません。

ファイアウォールについては、FTPの制御接続だけでなく、利用する転送方式に応じた通信が許可されているか確認します。ネットワークやセキュリティの設定は環境ごとの差が大きいため、送信側、ネットワーク、受信側の担当者で接続条件を共有します。

さらに、新規に連携方式を選べる場合は、認証情報や転送データの保護を考慮し、SFTPやFTPSなどの利用を検討します。ただし、既存の受信側がFTPだけに対応している場合もあるため、単純に方式を変更するのではなく、送受信側の対応状況、運用手順、監視方法を含めて判断します。

安全に再実行できる仕組みを作る

夜間ジョブでエラーが発生した場合、原因を修正して同じジョブを再実行すればよいとは限りません。ジョブが異常終了していても、ファイルがすでに送信されていたり、基幹システム側で取り込みが始まっていたりする可能性があるためです。

まず、どの工程まで完了しているかを確認します。連携ファイルが正しく作成済みで、FTP接続前に失敗したことが明確であれば、FTP送信ジョブから再実行できます。一方、送信後の応答受信で失敗した場合は、ファイルが受信側へ届いている可能性があります。

再実行前には、受信側に同名ファイルが存在しないか、処理済みディレクトリへ移動していないか、基幹システムで取り込み済みになっていないかを確認します。同じデータを再送した場合に、受信側が重複を排除するのか、二重登録するのかも把握しておく必要があります。

二重送信を防ぐ方法として、送信管理テーブルや処理履歴へ、処理日、ファイル名、対象件数、送信日時、受信確認日時、取り込み結果を記録する方法があります。再実行時は、同じ処理キーがすでに正常完了していないかを確認します。

また、同じファイルを再送するときは、単純に新しい時刻を付けた別名ファイルを作らないよう注意します。受信側がファイル名で重複を判定している場合、別名にすると同じデータが再び取り込まれる可能性があります。再送方法は受信側の仕様と合わせて決めます。

異常時の通知とログを整備する

夜間処理は担当者が操作していない時間帯に実行されるため、翌朝まで異常に気付けない可能性があります。そのため、JP1の異常終了だけでなく、ファイル未作成、0バイト、FTP接続失敗、送信失敗、受信未確認、取り込み失敗など、工程ごとに通知条件を設定します。

通知には、担当者が最初の判断を行える情報を含めます。ジョブ名だけでは、どの連携ファイルが失敗したか分からない場合があります。実行日時、対象日、ファイル名、ファイルサイズ、終了コード、エラーの発生工程、ログの保存場所、再実行の可否などを記載すると確認しやすくなります。

一方で、パスワード、秘密鍵、内部接続情報などをメールやチャットへ出力しないようにします。IPアドレスやホスト名についても、必要な担当者だけが参照できる運用経路で共有します。

ログは、正常時にも最低限の情報を残します。異常時だけログを出力すると、通常時との違いを比較できません。通常のファイルサイズ、転送時間、対象件数、接続元、終了コードを記録しておくと、処理時間の増加やファイル件数の急変にも気付きやすくなります。

また、自動リトライを実装する場合は、すべてのエラーを無条件に再試行しないようにします。一時的な通信エラーには再試行が有効ですが、認証失敗、ホワイトリスト未登録、ファイル形式不正などは、繰り返しても解消しません。エラー種別ごとに、自動再試行、手動確認、処理中止を分けます。

本番稼働前にテストしたこと

夜間連携は、正常に送信できることだけを確認して本番へ移行すると、障害時に安全な復旧ができません。そこで、本番稼働前には正常系に加えて、接続失敗、ファイル不備、再実行、重複防止などの異常系を確認しました。

正常系では、予定時刻にJP1ジョブが起動し、連携ファイルが正しい名称と内容で作成されることを確認します。その後、FTPサーバーへ送信され、基幹システムで想定件数が取り込まれることまで確認します。

接続試験では、FTPサーバー停止、認証情報の誤り、ホワイトリスト未登録を再現し、JP1が異常終了になること、後続ジョブが開始されないこと、必要なログと通知が出力されることを確認します。特に、管理者端末ではなくJP1実行サーバーから接続する試験が重要です。

ファイル関連では、ファイル未作成、0バイト、列数不正、文字コード不正、同名ファイルありを確認します。異常なファイルがFTP送信されず、処理が適切に停止することを確認します。

再実行試験では、FTP送信前の失敗、送信後の応答途切れ、受信済み、取り込み済みなど、異なる状態を用意します。そして、必要なジョブだけを再実行できること、同じデータが二重に取り込まれないことを確認します。

テスト結果は、実施日時、実行ジョブ、使用ファイル、想定結果、実際の結果、ログの保存場所を記録します。421エラーで確認したホワイトリスト未登録の事象もテスト項目へ追加し、サーバー更改時に同じ問題を繰り返さないようにしました。

まとめ

JP1で夜間FTP連携を自動化する場合は、FTPコマンドを定刻実行するだけでなく、連携ファイルの作成、検証、送信、退避、受信確認、基幹システムへの取り込み確認までを一連の処理として設計する必要があります。

今回の構成では、データ抽出、ファイル作成、FTP送信、結果確認などを工程ごとのジョブへ分けました。これにより、途中で処理が失敗した場合でも、正常に完了した工程をやり直さず、必要な箇所から再実行できます。

連携ファイルは、作成中に送信されないよう一時ファイルとして出力し、件数、サイズ、文字コード、列数などを検証した後に正式名称へ変更します。0件や0バイトの扱い、再実行時のファイル名、同名ファイルの上書きルールも事前に決めておくことが重要です。

FTP送信では、接続先やアカウントだけでなく、タイムアウト、終了コード、ログ出力、認証情報の管理方法を設計します。JP1が正常終了しても連携完了とは限らないため、受信側のファイル到着と基幹システムの取り込み結果まで確認します。

実際に発生した421エラーでは、手動接続は成功しましたが、夜間ジョブだけが接続に失敗しました。原因は、JP1実行サーバーの接続元IPアドレスがFTPサーバー側のホワイトリストへ登録されていなかったことです。この経験から、接続試験は実際の実行サーバーとネットワーク経路で行い、NAT後のIPアドレスやファイアウォールも確認する必要があると分かりました。

また、障害復旧後に無条件で再実行すると、二重送信や二重取り込みが発生する可能性があります。再実行前に、送信元ファイル、受信側のファイル、基幹システムの処理済み状態を確認し、どのジョブから再開するかを判断します。

異常時には、ジョブ名、対象ファイル、終了コード、エラー工程、再実行の要否をログと通知へ記録します。正常時の件数や処理時間も残しておくことで、通常時との差を比較しやすくなります。

夜間連携を安定して運用するには、正常に動く自動処理だけでなく、異常を検知し、安全に停止し、重複を起こさず再実行できる仕組みが必要です。421エラーのような実際の障害をテスト項目と移行チェックへ反映することで、サーバー更改やネットワーク変更後も継続して運用しやすい連携基盤を構築できます。