AS400 / IBM iのEDIでは、テスト環境と本番環境の分離が甘いと、テストデータを本番へ送る事故が起きます。若手や外部エンジニアが入りやすい現場ほど、環境名だけでなく、送信先、ライブラリ、ファイル名、ジョブ名を明確に分ける必要があります。
分けるべきもの
| 項目 | 確認内容 |
|---|---|
| 送信先 | 取引先コード、FTP先、API先、メール先 |
| ライブラリ | 本番、テスト、検証用の参照先 |
| ファイル名 | 本番ファイルとテストファイルの命名差 |
| ジョブ | 本番送信ジョブとテスト送信ジョブの違い |
| 権限 | 誰が本番送信できるか |
事故を減らす運用
- 本番送信前に環境名と送信先を声出し確認する
- テストデータには本番でありえない識別文字を入れる
- 本番送信ジョブは権限を絞る
- 送信前後のログを残す
- 再送は作業者判断ではなく承認制にする
本番事故を防ぐ観点は、AS400若手・外部エンジニアの本番事故を防ぐチェックリストにもまとめています。
ここまでの要点
AS400 EDIの誤送信を防ぐには、テスト環境と本番環境を画面表示だけでなく、送信先、ライブラリ、ファイル名、ジョブ、権限で分けることが重要です。
環境名だけでなく、相手先・送信経路・データ種別まで分ける
EDIのテスト環境と本番環境を分ける時は、AS400側のライブラリ名やジョブ名だけを見ても不十分です。実際の事故で怖いのは、テストデータを本番の取引先へ送ってしまうことです。環境名、相手先コード、送信先、FTP/回線/中継サーバー、ファイル名、送信フラグ、データ種別を分けて確認します。
若手や外部担当者に作業を任せる時は、「テストだから大丈夫」と言葉で済ませず、送信直前に本番相手先へ流れない証拠を見せてもらう運用にします。EDIは相手先が絡むため、誤送信すると自社内だけで完結しません。物が届かない、二重送信になる、取引先へ訂正連絡が必要になるなど、業務影響が大きくなりやすい領域です。
| 分ける項目 | 確認する理由 | 関連ページ |
|---|---|---|
| テストデータ | 本番取引先へ誤送信しないため | テストデータ本番送信を防ぐチェックリスト |
| 取引先・送信経路 | AS400側で作成済みでも送信完了とは限らないため | EDI・外部連携トラブル確認手順 |
| 再送判断 | 二重送信や未送信を防ぐため | 外部連携データ再送チェックリスト |
| 本番障害時の初動 | 誤送信後の影響範囲と連絡先を先に確認するため | 本番データ復旧の初動判断 |
テストデータが本番送信されない設計例
画面の環境名を変えるだけでは誤送信を防げません。接続先、送信元識別子、制御番号、監視を環境ごとに分けます。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 接続 | テスト用エンドポイントと証明書・資格情報を分離する | 本番資格情報をテストへ置かない |
| データ | テスト相手先、管理番号帯、ファイル名、ヘッダーを識別可能にする | 実在取引先へ送れない条件を入れる |
| 運用 | 送信前承認、送信ログ、相手先確認、再送判断を別手順にする | テスト完了後の設定戻しを確認する |
可能ならテスト環境から本番宛て通信をネットワーク側でも拒否します。アプリケーション設定だけに依存せず、誤送信が一つのミスで成立しない構成にします。
関連するAS400確認ルート
EDIのテスト環境と本番環境の分離は、誤送信を防ぐ最重要ポイントです。相手先が絡むため、送信先、テストデータ、再送ルール、承認を必ず確認します。
EDIで本番誤送信を防ぐ確認
EDIのテストで怖いのは、テストデータを本番相手へ送ること、または本番データをテスト環境で処理してしまうことです。AS400側だけでなく、相手先、通信定義、送信先ディレクトリ、ファイル名規則まで分けて確認します。
| 確認対象 | テスト環境 | 本番環境 |
|---|---|---|
| 送信先 | テスト用ホスト・ディレクトリ | 本番用ホスト・ディレクトリ |
| ファイル名 | TESTや検証日付を含める | 本番運用ルールに従う |
| ジョブ | 手動または検証用スケジュール | 本番ジョブスケジュール |
| 確認者 | 開発・保守担当 | 業務担当と相手先確認 |
送信前に止まる仕組みを作る
本番誤送信を防ぐには、担当者の注意だけに頼らないことが重要です。テスト環境では送信先を物理的に分ける、ファイル名に検証用の識別子を入れる、送信直前に確認ステップを入れるなど、誤操作しても止まる設計にします。