JWNET 標準EDI 接続テスト — テスト仕様書（Greco 操作ベース・一発合格版）¶

最終更新: 2026-09-19 v1.16（v1.16 = §2.4 の締切を自動（ゲートウェイの deferred・新規送信 16:19:30 / 16:05:30・受信開始 16:58 / 16:57）と操作者が守る範囲（更新系 16:00 = TC-05〜25・照会系 16:30 = TC-01〜04）に区別し、当方の運用締切としての出所（更新系は仕様書の推奨・照会系は当方ルール）と締切後の扱い（新規送信は翌営業日に回す・既送分は受理結果を確認）を明記。v1.15 = コーディネーター。v1.15 = 3201（条件検索）を画面からゲートウェイ送信できるようにした（資格情報の選択はテナント単位で送信名義に依存しないことを 3 層で実測）。TC-04 の送信方法を「手渡しのみ」から「E2E 可・手渡しは保険」へ更新し、Day-1 のサイクルを 7（+ 手渡し 1）→ 8 に改めた。v1.14 = 原本突合 H6 の結果: §1.3「本番で使える機能の上限」を新設（手順書 v1.70 §5 の注記 / 2 次マニフェスト系 6 機能の対象外と、判断が覆ったときは接続テスト枠の申込からやり直しになること）・入力検証 5 種の是正済みを反映（#834 で D62 の区分と基準重量を検査）・nav を章番号順へ・R2 で §1.3 の TEST の扱いを是正（上限は TC-01〜TC-25 の 25 機能・TC-00 は別枠の疎通確認）。v1.13 = #838 R5 レビューの原本所見 N2: 繰越後の件数（Day-3 10・10/8 3・期間 30・「最大 3」）は再送を除く基本件数と限定し、再送は各 1 要求を加算する（1 回再送なら Day-3 11 / 10/8 3 / 期間 31。10/8 で 2001 を 1 回再送すれば 4 要求）。v1.12 = #838 R4 レビューの原本所見 N1: Day-3 の順序を「排出の連鎖（0103 → 0207 → 0403 → 0503 → 3101 → 0605 → 0300 → 0800 → 1200）を先・自己登録番号に依存しない 2001 / 2100 を最後」に変え、E01 の再送で上限 12 を超えるときはまだ送っていない 2001 / 2100（とその再送）だけを 10/8 に回す（10/8 = 朝の 3101 1 + 2 = 3・Day-3 は 10・期間 GW 30）。排出の連鎖は同日に完結させる（自己登録番号は翌日クリア）ので午前に始める。上限 12 は時間から置いた計画値で、締切（command 16:19:30 / scheduler 16:05:30）まで続けてよい。v1.11 = #839（wl-w6nn）の反映: Biware コマンドの終了コードはログ edi-biware-command に残る。runbook E-2.6 の env JWNET_GATEWAY_BIWARE_SEND_REJECT_EXIT_CODES に載せた終了コードだけ 失敗（biware-send-rejected）になり別の要求コードで再生成、既定は空なので第 7 章の表を転記するまでは従来どおり 送信中 → 照合待ち・受信の非 0 は warn のみで再試行継続（§7-3 / §7-5）。v1.10 = #838 レビューの原本所見 O1 / O2: Day-3 が上限（12）を超えるときに翌日へ回すのは自己登録番号に依存しない 2001 / 2100 のまとまり（0605 / 0800 は 0403 / 0503 と同じ日・自己登録番号は翌日クリア）・0207 / 0403 は原本の事前登録予約に限定し、TC-18 の新規予約は同日の 0300 の対象にする（新規予約は朝のまとめ 3101 に含められない）。v1.9 = #838（wl-fz3w）の再計数所見: §6 にサイクル計数の規則を明文化 — 前置の照会は当日朝の 3101 を 1 回送ってまとめる（番号は最大 299・その日の TC が使う番号を全部入れる）、表の「（3101 → 反映）」はその判定画面の反映ボタンを使う意味で別の要求ではない、例外は 0403 受理後の 0605 用 3101 と 1700 前の 3102、「目標」列は合格 TC 数で「サイクル」列を新設（Day-1 7 + 手渡し 1 / Day-2 10 / Day-3 12 = 上限）、TC-09 の文言を整合。v1.8 = #835 R2 レビューの原本所見 2 件: 送信予算の算式は両方式とも外側期限（scheduler 360 秒 / command 最大 420 秒）で数える・TEST の保険経路は「アップロードせず原本目視」（合成応答は 422 にならないことがある）。v1.7 = #835 レビューの原本所見 3 件: 送信予算を claimedAt 起点の全段階（原本保存 + スキャン最大 120 秒 + Biware 送信 300〜420 秒 + R4 RPC 30 秒 ≈ 10 分・画面の警告は 12 分）に改め、§0.1 の「TEST は 422/照合待ち」を「照合待ち + 原本目視（アップロード欄の 422 とは別）」に、§7-5 の「wl-t4ll で追記予定」を復旧手順（手順書 10 章・runbook Phase F 末尾）への参照に。v1.6 = #833 レビューの原本所見 3 件（R-4 の env に RECEIVE_MODE=scheduler・R-3 の配備版を v1.94.0 主 / v1.93.0 分岐・「現行は任意」を #830 済に）+ #829（Day-1 UX）/ #830（入力検証）/ #832（V8 fixture）の反映で「是正前」注記を v1.93.0 限定に。v1.5 = 禹さん裁定（2026-09-16）の反映: B6 は送受信とも command で確定・Q-T1 は A（停止契約を変える・wl-wgwr・v1.94.0）→ §7-5 を新契約で書き直し・§9 リスク 11 を実装中に。v1.4 = codex 統合 QA（アプリ層）の反映: 入力検証の穴と名義保存漏れを是正前の運用注記として各 TC に追記・R-1 の unchecked・§7-4 の 409/500・TC-16 の D62 最小行数。v1.1 = 受信の再要求は駆動方式で意味が違う・TEST は CSV バリデータの対象外。v1.2 = R-3 は E-2.8 の更新リハーサルで PREVIOUS.txt を作ってから E-2.10。v1.3 = codex 統合 QA（搬送層）の反映: §7-5 の「20 分で再起動」を撤回（正常な受信待ちを打ち切る・Q-T1）、受信間隔は完了後の休止、R-3 の受入を「センター不達の正しい分類」に、R-4 の dev 起動 env と sim の運用、command 推奨値の閉局 16:19:30、送信非 0 / 受信非 0 の実際の状態）。対象 = Greco v1.93.0（develop 39255b49・mig270 込み）+ 常駐ゲートウェイ（同版）+ Biware 全銀TCPクライアント（評価版・9/29 再インストール）。期間 = 2026-10-05〜10-18・平日 9:00–17:00・実働 9 営業日**（10/12 は祝日）。

値の扱い: 接続登録番号・枝番・加入者番号・EDI 利用確認キー・事前登録マニフェスト番号・確認コード・パスワード・アクセスキー・PSK は本書に書かない。すべて「設定票③」「接続テスト案内（原本）」「Secret Manager」を参照する。証跡にも値を写さない。

0. 位置づけと使い方¶

文書	役割	本書との関係
準備計画（`docs/superpowers/plans/2026-09-06-jwnet-connection-test-first-pass-plan.md`・リポジトリ内の内部文書でサイトには載せていない）	なぜ・いつ（合否の定義・リスク台帳・V ゲート・日別割付・人間タスク）	本書 §1・§3・§6 の根拠
運用手順書 10 章	Greco 画面の操作（機能別の入力・判定の読み方・リハーサル）	本書 §4・§5 の操作は 10 章に従う。本書は何を・どの順で・何を証跡にを決める
runbook Phase F	VM 側の 1 サイクル・回収・切り分け	本書 §4・§7 の VM 側の操作は Phase F に従う
本書	テストケース（TC）・リハーサル（R）・日別計画・証跡・完了条件	操作者・判定者が当日手元に置く 1 枚

使い方: 期間前は §3（リハーサル R-1〜R-6）を go/no-go ゲートとして消化する。期間中は毎朝 §6 の当日分を開き、各機能について §5 の TC 行 → §4 の共通サイクル → §8 の証跡、の順で進める。異常は §7。

0.1 現時点の品質評価（2026-09-15・v1.93.0 時点）¶

層	状態	根拠
要求ファイル生成（25 機能 + TEST）	整った。QA P2 の不正入力 5 種すべてを画面・shared・独立バリデータが拒否する（3 種: 1601 の終了日空欄・単位コードの任意 1 桁・単位のみ数量なしは #830（v1.94.0）。残り 2 種: D62 の区分不整合（EB05041 / EB05052）・基準重量と区分 1 合計の不一致（EB05043・許容 90〜110%）は #834（`wl-l0ip`））。26 機能すべてを画面から生成でき、25 機能の要求原本は独立バリデータ（`scripts/jwnet-edi/validate-request-file.mjs`・25 表）を PASS。HD1 利用区分 `3`・全銀ファイル ID `JW9810FCHKD1` との交差検査（EE01007）を含む	#824（3102 の fixture・D63 表）・#825（TEST を画面から）・S1 25
搬送キュー（Greco → ゲートウェイ）	整った。10 種 + TEST の message_type を DB が受け、3102（D63）も送れる。1 ファイルずつ・前の結果受信後に次	#823（mig270）・proof X1〜X20・S1 39
結果判定（画面）	整った。HR1 → HR2 → 個票 → E01（mig257 のブロック判定）・R31 連鎖（登録系）・R63/R65（3102）・R23（3000）・3101/3201 の運搬報告判定・TEST は `照合待ち` + 受信原本の目視が正（キューの TEST 行に判定ボタンは出ない。アップロード欄の 422 は別物で常に本物）	S1 25(C) 11 原本・API it.each 13 機能
転記の削減	整った。3101 の判定画面から D31（0403/0605/0207）と報告系 11 機能へ番号・区間・収運名義を初期値反映。終了日・数量・担当者は手入力	#826
常駐ゲートウェイ（VM）	未配備（H8 = 9/29）。command / scheduler 両方式を実装済み。Biware 駆動方式（B6）は 2026-09-16 に送受信とも command で確定（インターコム回答 2026-09-15: コマンド実行可・同期・終了コード 0 = 受信書込完了。exe・引数・終了コード表はマニュアル第 7 章から転記済み → runbook E-2.6）。scheduler を選ぶ場合は Biware 側の受信ジョブの定期実行が必須（ゲートウェイは inbox の回収だけで再要求しない）。QA P1（Q-T1）: 受信待ち中の graceful stop（nssm restart）で行が `照合待ち` に確定し再開されない → 裁定 A（`wl-wgwr`・PR #831・v1.94.0）で停止時も `sent` を保ち、回収済み結果を再起動後に再適用する	runbook E-2.3 / E-2.6・`wl-k7io.1.5`
IPsec / 拡張Z手順 / センター	IKE/CHILD 確立済み（9/11）。rekey 跨ぎ・実結果ファイルの形・日次クリアの復元は期間内にしか確かめられない	準備計画 §1・§2

結論: アプリ層は「一発合格」に必要な機能と自動検証を備えた。合否を左右する残りは実機層（B6 の確定と CLI 値・ゲートウェイ配備・rekey）と運用（順序・件数上限・名義・締切）で、§3 のリハーサル 6 本が go の条件になる。

1. 合格判定と完了条件¶

1.1 合格の定義（準備計画 §1 を TC の言葉にしたもの）¶

段	合格側の観測	本書での確認場所
① IPsec	`swanctl --list-sas` が `ESTABLISHED` / `INSTALLED`、TS `10.100.121.0/24 === 210.164.154.24/30`。午前・午後で 1 本ずつ通し rekey を跨ぐ	§4 手順 1・§6 Day-1
② 拡張Z手順	Biware の送信結果が正常（全銀レベル）。TEST（TC-00）の結果ファイルがフォーマット不正のエラーコード付きで返る	TC-00・§7-3
③ 受信	送信 5 分以上後に新規要求で結果ファイルを受信。command 方式: ゲートウェイが Biware の受信コマンドを 60 秒間隔・最大 10 回実行する。scheduler 方式: Biware 側の受信ジョブ（スケジューラ）が定期実行し、ゲートウェイは inbox を 60 秒間隔・最大 10 回回収するだけ（センターへの再要求は起こさない）	§4 手順 5〜6・§9 #1
④ ヘッダ	HR1 `0`（`3` は一部・`1` は全体不受理）、HR2 のエラー件数 `0`。HR1 `3` の受理分は再送しない	§4 手順 7・10 章「判定と E01 の読み方」
⑤ 機能別	25 機能それぞれで E01 の付かない結果を 1 回以上	§5 の各 TC「期待結果」

1.2 完了条件（10/16 までに全部 ✅）¶

[ ] TC-00（TEST）: 結果原本にフォーマット不正のエラーコードが付いている（= ②の証跡）。
[ ] TC-01〜TC-25: 各 1 回以上、HR1 が 0 または 3 で、対象個票に E01 が無い結果を得た（判定記録 JSON と原本の保全先を §8 の台帳に記載）。
[ ] Day-1 の午前と午後で少なくとも 1 本ずつ往復した（rekey 跨ぎ）。
[ ] 全サイクルの要求コード・問合番号・受付日時・結果の要約が §8 の台帳に揃っている。
[ ] 送受信キューに 送信中 / 送信済・結果待ち の残留が無い。照合待ち の行はすべて判定者が原本と JWNET 側で確認済み。
[ ] 様式 EDI-02（接続テスト結果報告書）の下書きが 10/15 までにできている（H10）。

1.3 本番で使える機能の上限（接続テストの範囲）¶

接続テストで使えるようになる機能は、要求ファイルを送ってエラーコードの付かなかった機能だけである（出所: 接続テスト手順書 v1.70 §5 の注記 — 1 回でもエラーコードの付かない要求ファイルが送信されることが、その機能番号が使用できるようになる条件。使用しない機能番号の要求ファイルは送る必要はない）。
したがって本番で使える業務機能の上限は TC-01〜TC-25 の 25 機能である。TC-00（TEST）は別枠の疎通確認で機能番号ではない（TC-00 の合格はフォーマット不正のエラー付き応答を受けること＝§1.2）。§1.2 の完了条件を満たさなかった機能は本番で使えない。
2 次マニフェスト系の 6 機能（0210 / 0211 / 0212 / 0404 / 0607 / 2300）は今回の対象外である。中間処理後の搬出は紙運用にしているためで、2026-08-16 に決めて 2026-09-18 に再確認した判断である（根拠文書は docs/superpowers/specs/2026-08-16-standard-edi-function-scope.md。サイト非公開の内部文書のためリンクは張らない）。
この判断が覆る場合 — すなわち中間処理後の搬出を電子運用へ切り替えるとき — は、対象外にした機能を使えるようにするために接続テスト枠の申込からやり直しになる（様式の再提出を含む）。

2. 前提条件¶

2.1 環境¶

対象	状態	確認
Greco 本番	v1.93.0 以上（mig270 適用済み）	フッタ／リリースタグ。`/collector/settings/jwnet` が開ける
常駐ゲートウェイ	Windows VM（`10.100.121.10`）に v1.94.0 の main commit（9/26 目標）で配備（runbook E-2.2〜E-2.5）。health `200`・`polling-ok`。v1.94.0 が 9/29 に無ければ v1.93.0（`e412958f`）で配備し、§7-5 の旧原則（受信予算内は再起動しない）で運用	R-3（V7）
Biware	9/29 に評価版を再インストール → 通信設定を設定票から再投入（9/8 の投入内容）→ 全銀ファイル名 `JW9810FCHKD1` / `JW9810CCHKR1`・フォルダ outbox / inbox / archive / error	R-2（V5）
駆動方式（B6）	送受信とも command で確定（2026-09-16）。E-2.6 の差分（exe・引数・終了コード）を `AppEnvironmentExtra` に反映して `nssm restart`。第 7 章の値は転記済み・REJECT は R-2 実測まで空。停止予算と nssm console 猶予は runbook E-2.4 / E-2.6 の値（v1.94.0・command は約 2 分）	R-2・R-3
IPsec	strongSwan ルータ VM（`10.100.121.2`・egress `34.84.6.34`）。IKE 8h / CHILD 1h・DPD・NAT-T	§4 手順 1
時刻	生成端末・Windows VM・ルータ VM が NTP で JST 同期（HD1 作成日時はセンターが検査・`EE01009` / `EE01010`）	朝チェック

2.2 資格情報と名義¶

collector の管理者（admin）で /collector/settings/jwnet → 「接続テスト」に設定票③の接続登録番号・枝番・加入者番号・EDI 利用確認キーを手入力し configured にする（H7・10/1 まで）。normal / driver は画面も API も拒否される。
送信名義は機能ごとに切り替える（画面の「送信名義」欄・端末内だけに記憶）: No.1 排出（0103/0207/0300/0403/0503/0605/0800/1200/3000/3101/3201）/ No.2 収運（1000/1100/1300/0701/0208）/ No.7 処分報告（1501/1601/1700/1800/0702/0209/3102）/ No.11 報告及び 2 次登録（2001/2100）。確認キーは資格情報のものを共用する（接続テストの加入者は確認キーが共通）。No.7 と No.11 は Greco が別の記憶キーで保存する（v1.94.0・2001/2100 は「報告及び 2 次登録」キーを共有し、処分報告 No.7 の保存値は引き継がれず初回は空欄。v1.93.0 では同じキーだった）。
空欄のままだと資格情報（排出）の加入者番号で送る。3101 を収運・処分の名義で送ると判定表の「自社区間」は資格情報基準で未取得になる（区間は初期値候補か原本 R19 で読む）。
v1.94.0（#829）では「ゲートウェイで送信」の成功時にも名義が端末に保存され、2001/2100 には No.11 の注記が出る。 v1.93.0 の画面では保存はダウンロード成功時だけなので、機能を切り替えるたびに名義欄を目視し、空欄・古い値なら入れ直す。

2.3 体制と連絡¶

役割	主な仕事	連絡
操作者	朝チェック・画面操作・キュー監視・証跡保存	判定者へ即時
判定者	HR1/HR2/個票/E01 の判定・再送可否の決定・照合待ちの切り分け	窓口連絡へ
窓口連絡	JWNET へ照会票メールのみ（電話不可・同日回答の保証なし）。ルータ・Biware の質問は JWNET の対象外（インターコム / 自力）	—
インターコム	Biware の挙動・全銀レベルの結果コード	評価版サポート

連絡先の値は接続テスト案内（原本）を参照。当日体制表は準備計画 §6 の器に書く。

2.4 時間の規則¶

稼働 9:00–17:00（週末・停止日 10/12 を除く。ゲートウェイが自動で送受信しない）。閉局前の新規サイクルはゲートウェイが自動で deferred にする（送信直前に落ちた行は error になり再生成が必要）。
新規送信の締切（自動）: 推奨タイムアウトでは scheduler 16:05:30 / command 16:19:30 以降は始めない。受信の開始は scheduler 16:57 / command 16:58 まで（以降は sent を翌営業日へ持ち越し。runbook E-2.9）。
当方の運用締切（自動ではない・操作者が守る）: 更新系（登録・報告・修正・取消・承認否認 = TC-05〜25）は 16:00 まで（仕様書の「運用停止の 1 時間前」という推奨）、照会系（3000・3101・3102・3201 = TC-01〜04）は 16:30 まで（当方ルール）に送る。センター側の規則ではないが、当方の運用締切として守る。締切を過ぎたら新規送信は翌営業日に回す。既に送った分は実際の受理結果を確認する（時刻だけで不受理と決めつけて再送しない）。command 方式で内側が短くなっても、この規則は変えない。TC-00（TEST）は機能番号ではないので更新系・照会系の区分には当てはまらず、自動の締切（9:00–17:00 と 16:19:30）だけが効く。
1 サイクル ≈ 15〜20 分（初回受信で結果が取れる場合）。空受信が続くと scheduler で送信後最大 34 分（5 分 + 120 秒窓 × 10 回 + 60 秒休止 × 9 回）、command で約 24 分 + コマンド所要。1 日 8〜12 サイクルは上限計画で、実所要は R-2 と Day-1 で測る。

2.5 操作の禁則¶

原本（要求・結果）をエディタで開いて再保存しない（SHIFT_JIS・BOM なし）。C:\jwnet\inbox / received のファイルを消さない・移動しない。
要求コードを手で組み立てない（画面の採番・30 日内一意）。同じ要求コードで再送しない。
受理済みの個票を再送しない（二重報告）。HR1 3 の受理分も同じ。
「再送要求」で受信しない（結果ファイルが取れなくなる）。ゲートウェイは新規要求固定。
C:\jwnet\inbox が空でないときは次を送らない（§7-2）。
秘密値をチャット・スクリーンショット・証跡・照会票に書かない。原本の中身を外部へ送らない。

3. リハーサル（期間前のテストケース R-1〜R-6）¶

各 R は準備計画 §5 の V に対応する。期限を過ぎて未実施なら G2（9/25）/ G3（10/2）は no-go。

ID	V	期限	担当	手順の要点	合格の観測	証跡
R-1	V4	9/25	操作者（dev・admin）	dev の `/collector/settings/jwnet` に設定票③を入力 → 接続テスト画面で 26 機能すべてを「ファイルをダウンロード」で生成（番号・項目は原本の指定値）→ 25 機能の CSV をリポジトリルートで `node scripts/jwnet-edi/validate-request-file.mjs <csv> --env test --file-id JW9810FCHKD1 --json` に通す（TEST の `.txt` は CSV ではないのでバリデータの対象外）→ 合成結果 11 本（10 章「リハーサル」の表）で判定画面を確認 → 3101 → 「0403入力に反映」「{番号}・区間{n}を1000入力に反映」の初期値反映を試す → TEST を選んで `TEST-<要求コード>.txt`（中身 `TEST`・4 byte・改行なし）が落ちることを確認	26 機能とも生成成功・25 機能の CSV がバリデータ全 PASS（`unchecked` は機能別の期待集合と一致: D09/D14/D15/D23/D33/D34/D60/D61/D63 系は 2 項目・D31-01 系（0103/0207/0403/0503/0605）は 4・0208/0209 は 5。内訳は `scripts/jwnet-edi/README.md`・QA Q-A10）・HD1 利用区分 `3`・各ファイル 4,500 KB 以下・TEST は 4 byte・合成結果の判定が 10 章の表どおり・初期値反映で機能/番号/区間/名義が置換される	バリデータ `--json` 出力（値は出ない）・判定記録 JSON・画面の写し（値は隠す）
R-2	V5	9/25（再インストール後 9/29 に再実行）	操作者（Windows VM）	Biware に通信設定を投入 → R-1 の要求ファイル 1 本を `C:\jwnet\outbox` へ置く → 送信ジョブ（センター不達で止まってよい）→ 受信ジョブの「ファイルなし」挙動（scheduler なら受信ジョブの定期実行を Biware 側に設定し、その間隔がゲートウェイの受信窓（既定 120 秒 × 最大 10 回）に収まることを確認）→ B6 が command なら第 7 章のコマンドラインを実行し、終了コードを 0 / 非 0 の両方で記録（送信 exe・受信 exe・引数・「ファイルなし」時の終了コード）→ 終了情報ファイル（制御ファイルと同じフォルダの固定名 `STATUS.BIZ`。同時通信 OFF。実パスは R-2 で確定。`Scope` フォルダに時刻付きで出るのはオンライントレースの`.dat` であり STATUS.BIZ ではない）の 21〜22 桁目（処理結果コード）の読み方を 1 回確認	outbox のファイル名が `JW9810FCHKD1`（R-1 の HD1 利用区分 `3` との交差一致を明記）・受信の「ファイルなし」でジョブが異常終了しない・（command）終了コードが同期で返り exe パスが確定・Status.biz が生成される	Biware ログと Status.biz の写し（認証値マスク）・確定した exe / 引数 / 終了コード表（→ runbook E-2.6）
R-3	V7	9/29	操作者（Windows VM・AI 随伴）	runbook E-2.1〜E-2.5 で v1.94.0 の main commit のゲートウェイを配備（無ければ v1.93.0・§2 参照）→ health `200` → サービス実行アカウントで既知の無害ファイルの Defender スキャン終了コード 0 → 停止猶予（nssm stop/restart で drain 完了マーカーがプロセス終了より前）→ E-2.8 の更新手順を同じ版でもう 1 回実行して `PREVIOUS.txt` を作る（初回配備には切り戻し先が無い・runbook E-2.2）→ E-2.10 の切り戻しを同一シェルで 1 回 → 再び E-2.8 で現行版へ戻す → dev を向けた状態で 1 行を queued → claim → 復号 → スキャン → Biware の起動（command なら実コマンド・scheduler なら outbox 配置）まで進み、センター不達を実装が正しく分類して止まることを見る（`sent` / `received` はここでは要求しない: command + exit-code の非 0 / timeout は `sending` のまま `indeterminate` → 次 cycle で `照合待ち`（`gateway-restarted-during-send`）、scheduler は outbox の移動待ち timeout → 同じ。QA Q-T7）	health の `ipsec-ok` / `edi-ok` / `polling-ok`・スキャン 0・停止猶予 OK・`PREVIOUS.txt` がある状態で切り戻し → health 200 → 現行版へ復帰・exchange 行が `queued → sending`（センター不達の分類が `照合待ち` / `gateway-restarted-during-send` になる・command なら `edi-command-missing` が出ないこと）。`sent` / `received` は R-4 と Day-1 で確認	health JSON・`nssm get` の個別値・ログ抜粋・exchange 行の状態遷移
R-4	V8	9/30	操作者（dev・admin）	dev のゲートウェイは V8 専用の起動 env にする（準備計画 §5 の表・#832）: `JWNET_GATEWAY_BIWARE_SEND_MODE=scheduler`・`JWNET_GATEWAY_BIWARE_RECEIVE_MODE=scheduler`・`SENT_DETECTION=file-moved`・`OUTBOX_FILE_NAME=request-code`（sim は outbox 監視型の模擬で、command のままだと実 Biware コマンドが走る・QA Q-T6）。dev の画面で「ゲートウェイで送信」→ `biware-sim.mjs --fixture <機能の合成結果> --mode ok --once` で模擬搬送（dev 命名では sim が outbox 名から要求コードを推定するので `--request-code` は省略可。fixture はプロセス中固定なので行ごとに `--once` で起動し直す）→ 結果 → 「判定を表示」。4 行: 1000（`OK1000`）・3101（`MIX3101` → 初期値反映まで）・3102（`OK3102`）・TEST（`TESTFMT` + `--keep-request-code` 必須。付けないと HR1 が書き換わり `受信済` になって照合待ちの練習にならない）	通常 3 行が `待機中 → 送信中 → 送信済・結果待ち → 受信済`・判定が HR1/HR2/個票まで出る・3101 の初期値反映が動く・TEST 行は `照合待ち`（`result-correlation-failed`）で判定ボタンが出ない	実行ログ・判定記録 JSON・sim の起動引数（HD2 の値は出さない）
R-5	V6	10/1	全員	§6 のタイムラインを机上で通す → 当日体制表を埋める → IPsec `--list-sas` を rekey 跨ぎ後に再取得 → 本番の接続テスト画面に設定票③が `configured`（H7）	全員が §4 を口頭で追える・SA 確立・本番 `configured`	チェックリスト（本書 §1.2 の空欄版）
R-6	C-2 検証	10/6 朝	操作者	Day-1 で使った番号を 3101 で照会し、事前登録分が日次クリアで復元されているかを記録	復元される → 日別上限は毎日リセット / されない → 2 週間の総試行数が上限（§6 を組み直す）	判定記録 JSON

4. 当日の共通手順（1 サイクル・TC-CYCLE）¶

主経路 = E2E（画面 → ゲートウェイ → Biware → センター → 画面）。保険（手渡し）は 4.2。

4.1 主経路¶

#	誰	操作	期待する観測	外れたら
1	操作者（朝）	NTP 同期確認 → ルータ VM で `sudo swanctl --list-sas` → ゲートウェイ health（`http://<内部 IP>:8787/health`）→ health-watch の `status=ok` → Windows VM で `Test-NetConnection 210.164.154.26 -Port 5020`（PING は任意）	`ESTABLISHED` / `INSTALLED`・health `200`・5020 `TcpTestSucceeded: True`	§7-1
2	操作者（毎回）	`C:\jwnet\inbox` が空であることを確認	空	§7-2（残留）
3	操作者（画面）	接続テスト画面で機能を選ぶ → 送信名義（§2.2）→ 事前登録番号（1 行 1 件・原本の指定）→ 機能別の項目（§5 の TC 行）→ 送り先「ゲートウェイで送信」 → 「要求ファイルを生成」	入力エラーなし・要求コードと SHA-256（先頭 12 桁）の通知・送受信キューに `待機中` の行	入力エラー → 値を直す（推測で埋めない）/ 400・403・409 → §7-4
4	ゲートウェイ	claim → 復号 → 原本保存 → Defender スキャン → Biware 送信	行が `送信中 → 送信済・結果待ち`（30 秒ポーリング）	`失敗` → §7-4
5	ゲートウェイ	5 分以上待ち → 新規要求で受信を最大 10 回（各 receive の完了後に 60 秒休止。command: 受信コマンドを毎回実行／ scheduler: Biware の受信ジョブが定期実行している前提で inbox を最大 120 秒の窓で回収 → 空なら約 180 秒周期）	行が `受信済`	10 回で取れない → `照合待ち`（`receive-timeout`）→ §7-3 / §7-5。予算内は正常な待ち。再起動しない（§7-5）
6	操作者	`受信済` の行で「判定を表示」	HR1 → HR2 → 個票 → E01 の表示	422（未知レコード等）→ 判定者へ・原本で確認
7	判定者	HR1 `0`（全受理）/ `3`（一部）/ `1`（全体不受理）→ HR2 のエラー件数 → 個票の E01	対象個票に E01 なし = その機能は合格	E01 あり → 入力を直して別の要求コードで再送。受理分は再送しない
8	操作者	「判定記録（JSON）を保存」→ §8 の台帳へ記入（要求コード・機能・名義・件数・HR1/HR2・E01・結果原本の保全先・問合番号）	—	—
9	操作者	次の TC へ（inbox が空であることを再確認）	—	—

4.2 保険（手渡し）¶

ゲートウェイが unhealthy・claim が進まない・全銀レベルの切り分けが必要なときの fallback として残す。3201 もゲートウェイで送れるが、手渡しは保険として使える。

送り先「ファイルをダウンロード」で生成（TEST は TEST-<要求コード>.txt）→ 「送信記録（JSON）を保存」。
ウイルスチェック → C:\jwnet\outbox へ原本のまま配置（Biware は全銀ファイル名で送る）。
Biware で送信 → 送信結果ステータス正常を確認（異常は Status.biz の処理結果コードで切り分け・§7-3）。
5 分以上待ち → 新規要求で受信。「ファイルなし」なら 5 分待って再受信。
C:\jwnet\inbox の結果原本を保全 → 接続テスト画面「結果ファイル」で選び 「結果ファイルを判定」（ファイル名 ^[0-9A-Za-z]{9}-[^_]+_[0-9]{14}\.csv$・HR1 の要求コード一致が必要。TEST はアップロードせず、受信原本のエラーコードを目視して記録する（フォーマット不正の応答でも 422 になるとは限らない・合成 fixture TESTFMT は判定を返す））。
以降は 4.1 の 7〜9。

5. 機能別テストケース（TC-00〜TC-25）¶

凡例: 名義 = 資料③の No.（値は原本）。件数 = 事前登録番号の数 = その日の受理試行の上限（原本 H6 突合）。GW = ゲートウェイ送信の可否。「画面入力」は番号以外（必須は生成時の入力エラーが示す）。「期待結果」はすべて HR1 0/3 かつ対象個票に E01 なしが基本で、例外だけ書く。

5.1 疎通・照会（Day-1）¶

TC	機能	名義	件数	前提	画面入力	GW	判定の見え方 / 期待結果	注意
TC-00	TEST 疎通確認ファイル	任意	—	①②	なし（機能 TEST を選ぶと番号・項目・名義の欄が消える）	可	行は `照合待ち`（`result-correlation-failed` または `result-parse-failed`）が正。`C:\jwnet\received`（と `artifacts/`）の受信原本にフォーマット不正のエラーコードが付いていることを目視 = 合格条件 ②	画面の「判定を表示」は TEST 行に出ない。v1.94.0（#829）では TEST の照合待ちに「原本のエラーコードを目視して記録すれば完了・再送は不要」が出る。v1.93.0 の画面に出る「再送は新しい要求コードで」は無視する。保険は `.txt` をダウンロードして Biware 直送
TC-01	3101 番号指定照会	対象機能の名義（Day-1 は No.1）	—	TC-00	番号 1〜299	可	番号 × 区間の判定表（自社区間は資格情報基準）+ 「0403入力に反映」/「0605入力に反映」 + 報告系 11 機能への「{番号}・区間{n}を{機能}入力に反映」。R33/R35/R19 に E01 なし	E2E 主経路の初回はこれ。以後の報告・登録の起点
TC-02	3000 通知情報照会	No.1	—	①②	照会通知情報（1/2）・通知情報ステータス（1/2/3）・通知日 FROM = TO = 当日	可	R23 エコー行ごとに受理 / 不受理。R24 明細は表示しない	FROM は最大 1 か月前まで
TC-03	3102 再資源化等情報の照会	No.7	—	mig270（v1.93.0）	番号 1〜299	可	R63 エコー + R65 個票（+ 従属 R62）に E01 なし	1700（TC-15）の入力根拠。v1.93.0 未満では GW 送信が 400 になる
TC-04	3201 条件検索（運搬未報告）	なし（欄が出ない）	—	①②	抽出日区分（1〜4）・開始日・終了日（3 か月以内）	可	自社区間の運搬報告判定 + E01。R34 個票表示なし。返却 3,100 件 / CA 打切りは表示	E2E で 1 回通せば合格証跡（保険は手渡し 4.2）

5.2 収集運搬（No.2・Day-1〜2）¶

TC	機能	名義	件数	前提	画面入力	GW	判定 / 期待	注意
TC-05	1000 運搬終了報告	No.2	3	TC-01（区間の確認）	区間番号・運搬終了日・運搬担当者（必須）+ 運搬量/単位・有価物量/単位・車両番号・報告担当者・備考	可	R09 個票に E01 なし	3101 の判定画面から「…を1000入力に反映」で番号・区間・収運名義が入る。終了日等は手入力。単位コードは 1=t 2=m³ 3=kg 4=リットル 5=個・台のみ（有価物に 5 は不可）。数量と単位は両方入れるか両方空（#830 で画面の select と shared・独立バリデータが検査する。v1.93.0 の画面は未検査）
TC-06	1300 運搬終了報告の取消	No.2	3	TC-05 が受理済みの番号	区間番号	可	R14 に E01 なし	反映ボタンで区間・名義が入る
TC-07	0701 承認・否認（収運）	No.2	6	承認待ちの番号（原本指定）	区間番号・承認/否認（1/2）	可	R15 に E01 なし	反映ボタンで区間・名義が入る
TC-08	1100 運搬終了報告の修正	No.2	3	TC-05 受理済み	TC-05 と同じ項目（修正値）	可	R09 に E01 なし	Day-2
TC-09	0208 予約情報の修正（収運）	No.2	3	予約番号（原本指定）	D31-02 の予約修正項目（朝のまとめ 3101 の判定画面から「0403入力に反映」→ 機能を 0208 に切替。別の 3101 は送らない）	可	R31 連鎖の個票に E01 なし（画面で受理 / 不受理が出る）	名義は収運

5.3 処分（No.7 / No.11・Day-2〜3）¶

TC	機能	名義	件数	前提	画面入力	GW	判定 / 期待	注意
TC-10	1501 処分終了報告	No.7	3	TC-01	処分終了日・処分担当者・報告区分（1 中間 / 2 最終）+ 廃棄物受入日・受入量/単位・換算後重量（単位 3=kg）・運搬担当者・車両・報告担当者・備考。中間処理は D62 0 件・最終処分は 1 件以上（D62 の区分は 1）	可	R60（+ 従属 R62）に E01 なし	反映ボタンで番号が入る（区間・名義は入らない = 処分の記憶名義のまま）。基準重量（換算後重量）= 区分 1 の D62 処分量合計（許容 90〜110%・#834 で画面・shared・独立バリデータが検査）。受入量の単位は 1〜5 のみ
TC-11	1800 処分終了報告の取消	No.7	6	TC-10 受理済み	なし（番号のみ）	可	R14 に E01 なし	—
TC-12	0702 承認・否認（処分）	No.7	12	承認待ちの番号	承認/否認（1/2）	可	R15 に E01 なし	区間番号なし
TC-13	0209 予約情報の修正（処分）	No.7	3	予約番号	D31-03 の予約修正項目	可	R31 連鎖に E01 なし	名義は処分報告（原本の指定）
TC-14	1601 処分終了報告の修正	No.7	6	TC-10 受理済み	TC-10 と同じ（処分終了日は必須。#830 で画面も必須化。v1.93.0 の画面では任意扱いだったので原本から必ず入力）+ D62 は中間 → 最終へ変更するときだけ（中間のまま D62 を付けない・#834 で画面・shared・独立バリデータが拒否）	可	R60 に E01 なし	基準重量は区分 1 合計（TC-10 と同じ注意）
TC-15	1700 再資源化情報の修正	No.7	2	TC-03（3102 の結果）	換算後重量・単位 + D62 1 件以上（3102 の R65 を基に）	可	R60 + R62 に E01 なし	失敗は 1 回まで。入力を判定者と二人で確認してから生成。基準重量 = 区分 1 合計（90〜110%）を電卓で確認
TC-16	2001 最終処分終了報告	No.11	3	TC-01	換算後重量・単位 + D62 は区分 1 と区分 2 以上を各 1 行以上（実効最小 2 行）・少なくとも 1 行に最終処分終了報告フラグ 1 と終了日	可	R61 + R62 に E01 なし	名義欄を原本で目視（No.7 と取り違えない。#829 で画面注記と No.11 の別記憶キー）。3101 からの反映は番号のみ・D62 は手入力。基準重量 = 区分 1 合計。Day-3 は排出の連鎖の後（最後）に送る（上限に当たれば翌日へ回せる唯一のまとまり・§6）
TC-17	2100 最終処分終了報告の取消	No.11	3	TC-16 受理済み	なし（番号のみ・区間なし）	可	R14 に E01 なし	—

5.4 排出（No.1・Day-3。第 1 週の後半に前倒し）¶

依存順: 0103 → 0208 / 0209 / 0207（相互は任意順）→ 0403。0403 で本登録した予約は 0300 の対象にできない → 0300 は別の予約を対象にする。0605 / 0800 は本登録（0403 / 0503）の後。0103 / 0503 で自分が登録した番号は同日中に使う（翌日クリア）。 12 サイクル案では 0207 / 0403 は原本の事前登録予約を使い、TC-18 の新規予約は同日の 0300 の対象にする。0605 / 0800 も 0403 / 0503 と同じ日に送る（翌日に回すのは 2001 / 2100・§6）。

TC	機能	名義	件数	前提	画面入力	GW	判定 / 期待	注意
TC-18	0103 予約情報の登録	No.1	新規	—	D31-01 の登録項目（番号欄なし・区間 0〜5）	可	R31（番号はセンター採番値）に E01 なし	採番された予約番号を台帳に控える（当日限り）
TC-19	0207 予約情報の修正（排出）	No.1	5	原本の事前登録予約番号（朝のまとめ 3101 に含める。TC-18 の新規予約は朝の照会に入らないので使わない）	3101 → 「0403入力に反映」→ 機能を 0207 に明示選択・予約修正許可は必須	可	R31 連鎖に E01 なし	0403 の前に送る
TC-20	0403 マニフェスト情報の登録（予約から本登録）	No.1	5	TC-01・（TC-19）	3101 → 「0403入力に反映」→ 未写像項目（引渡し日・排出事業場・担当者・分類・数量・単位・数量確定者・荷姿・処分業者・運搬先加入者・事業場番号 …）を原本の指定値で埋める・区間 1〜5	可	R31 連鎖の個票に E01 なし（画面で受理 / 不受理が出る）。E01 の有無は原本でも確認	本登録した予約番号はそのまま番号になる
TC-21	0503 マニフェスト情報の登録（新規）	No.1	新規	—	D31-01 の登録項目（番号欄なし・区間 1〜5）	可	R31（センター採番）に E01 なし	登録番号は当日中のみ有効
TC-22	0605 マニフェスト情報の修正	No.1	20	TC-20 / TC-21 受理済み	3101 → 「0605入力に反映」（本登録済みの番号）→ 修正項目	可	R31 連鎖に E01 なし	収運は追加のみ・処分業者情報は同一
TC-23	0300 予約情報の取消	No.1	5	本登録に使わない予約（= TC-18 で採番した新規予約・同日限り）	なし（番号のみ）	可	R14 に E01 なし	—
TC-24	0800 マニフェスト情報の取消	No.1	20	TC-20 / TC-21 受理済み	なし（番号のみ）	可	R14 に E01 なし	—
TC-25	1200 承認・否認（排出）	No.1	20	承認待ちの番号	承認/否認（1/2）	可	R15 に E01 なし	区間番号なし

5.5 共通の合格条件と再送規則¶

1 TC の合格 = その機能で E01 の付かない結果を 1 回。E01 が付いたら判定者が原因（EN 必須 / ED 形式 / EB 業務 / EE EDI 固有 / EF・EM ファイル / CA・CB 件数 / FC・FD サイズ / ES センター）を確定し、入力を直して別の要求コードで再送。
同一機能の再送は当日の件数上限（列「件数」）を超えない。上限に達したら翌営業日（日次クリアの復元は R-6 で確認）。
HR1 3 の受理分・HR2 エラー件数 0 のブロックの受理個票は再送しない。

6. 日別計画（9 営業日）¶

Day-1 の主経路の初回は 3101。午前・午後に最低 1 本ずつ通し rekey を跨ぐ。1 日 12 サイクルを上限に（§2.4 の締切 scheduler 16:05:30 / command 16:19:30）、inbox を空にしてから次を送る。

サイクルの数え方（v1.9）: 1 サイクル = ゲートウェイで送る要求 1 件（3201 もゲートウェイで送れば 1 サイクルに数える。手渡しで送った分は別に数える）。前置の照会は当日朝の 3101 を 1 回送ってまとめる（番号は最大 299・その日の TC が使う番号を全部入れる。Day-2 は R-6 がこの 1 回を兼ねる）。表の「（反映）」はその判定画面の反映ボタンを使うという意味で、別の要求ではない。例外は 2 つ: 0605 は 0403 の受理後に 3101 をもう 1 回（本登録済みの番号で「0605入力に反映」）、1700 の前は 3102 を 1 回（中間 / 最終の状態を原本で確かめる）。まとめ照会の名義は No.1（R19 は全区間が返り、報告系の反映は区間を R19 から読む・§9 No.10）。[仮説] No.1 名義の 3101 で当日の全対象番号が引けることは Day-1 の TC-01 で確かめ、引けない番号があればその名義で 3101 を 1 回足す（+1 サイクル・上限内）。Day-3 は 12 で上限に当たる。順序は排出の連鎖を先に、自己登録番号に依存しない 2001 / 2100 を最後に置く（繰越の対象を送る前に判断できるようにする）。E01 の再送で 12 を超えるときは、まだ送っていない 2001 / 2100（とその再送）だけを 10/8 に回す（再送を除く基本件数: 10/8 = 朝に 2001 用の 3101 を 1 回 + 2001 + 2100 = 3 サイクル・Day-3 は 10・期間の GW 合計は 31。再送は各 1 要求を加算する: 連鎖の中で 1 回再送すれば Day-3 は 11・期間は 32、10/8 で 2001 を 1 回再送すれば 10/8 は 4）。排出の連鎖（0103 → 0207 → 0403 → 0503 → 3101 → 0605 → 0300 → 0800 → 1200）は同日に完結させる（自己登録した番号は翌日クリアされる・§5.4）ので午前に始め、連鎖の中の再送で 12 を超えるときは閉局の締切（command 16:19:30 / scheduler 16:05:30）まで続けてよい（12 は時間から置いた計画値で JWNET の上限ではない）。0207 / 0403 に使う予約番号は原本の事前登録予約（朝のまとめ照会に含める）。TC-18 で採番した新規予約は朝の照会に入らないので、同日の 0300（取消）の対象に使う。

日	内容（順序）	目標（合格 TC 数）	サイクル（GW 要求数）
10/5(月) Day-1	朝チェック → TC-00 TEST（画面から・照合待ちが正・原本の E01 を目視）→ TC-01 3101（No.1・当日の 1000 の対象番号と 0207/0403 用の番号をまとめて照会）→ TC-02 3000（from = to = 当日）→ TC-03 3102（No.7）→ TC-05 1000（TC-01 の判定画面から反映）→ TC-06 1300 → TC-07 0701 → TC-04 3201 は E2E で 1 回（保険は手渡し。時間があれば）	8	8
10/6(火) Day-2	朝: R-6 = 3101 を 1 回（Day-1 の番号の復元記録 + 当日の 1100 / 0208 / 1501 / 0209 / 1601 の対象番号をまとめて照会）→ TC-08 1100（反映）→ TC-09 0208（「0403入力に反映」→ 機能を 0208 に切替）→ TC-10 1501（反映）→ TC-11 1800 → TC-12 0702 → TC-13 0209 → TC-14 1601 → 3102 を 1 回（1700 対象の中間 / 最終を原本で確認）→ TC-15 1700（慎重に・2 件のみ）	8	10（R-6 1 + TC 8 + 3102 1）
10/7(水) Day-3	朝: 3101 を 1 回（0207 / 0403 に使う原本の事前登録予約番号と 2001 の対象番号をまとめて照会）→ 排出の連鎖（午前に始める・同日に完結）: TC-18 0103（新規予約 = 同日の 0300 の対象）→ TC-19 0207（「0403入力に反映」→ 機能を 0207 に明示選択）→ TC-20 0403（「0403入力に反映」）→ TC-21 0503 → 3101 をもう 1 回（本登録済みの番号）→ TC-22 0605（「0605入力に反映」）→ TC-23 0300 → TC-24 0800 → TC-25 1200 → 最後に TC-16 2001（No.11・反映は番号のみ）→ TC-17 2100	10	12（3101 2 + TC 10 = 上限。再送で超えるなら、まだ送っていない 2001 / 2100 を 10/8 へ）
10/8(木)・10/9(金)	第 1 週の E01 修正と再送（Day-3 から 2001 / 2100 を回したときは朝に 3101 を 1 回足す = 再送なしで 3 サイクル・再送は各 1 要求を加算）。E2E 主経路で未通過の機能を通す。EDI-02 の下書き開始	予備	予備
10/13(火)〜10/16(金)	予備（再送・再確認）。10/15 までに 25 機能の E01 なし→ 10/16 に EDI-02 の提出準備（H10）	予備	予備

各日の終わりに §8 の台帳を更新し、翌日の TC の前提（受理済み番号・承認待ち番号・件数の残り）を判定者が確認する。

7. 異常時の手順¶

7-1 朝チェックが通らない¶

観測	見る場所	対処
`--list-sas` が `ESTABLISHED` でない	strongSwan runbook §9（54 分付近 / 7h12m 付近の切断は rekey）	ルータ VM で再確立。期間前の Q4 回答どおり期間前も接続試行は可
health `503`	`code`（runbook E-2.5 の表）: `ipsec-health-error` / `edi-health-error` / `edi-command-missing` / `polling-*`	表の対処。`edi-command-missing` は B6 の exe パス（E-2.6）
5020 が `False`	ルータ VM 経由のルート・FW	strongSwan runbook §8

7-2 `C:\jwnet\inbox` に残留がある / `edi-receive-partial` / `edi-receive-drain-incomplete`¶

次の要求を送らない。runbook Phase F の回収手順（原本を動かさず、コピーを判定・HR1 の要求コードを照合・判定者へ）。

7-3 全銀レベル（拡張Z手順）の失敗¶

観測	見る場所	対処
行が `送信中` のまま送信予算を超えた（command + exit-code の送信非 0 / timeout は `失敗` にならず `送信中` のまま `indeterminate` → 次のサイクルで自動的に `照合待ち`（`gateway-restarted-during-send`）。outbox は空になるが送信済みかは未確定・QA Q-T2。v1.94.0（#839）: 終了コードは `edi-biware-command` ログに残り、runbook E-2.6 の `JWNET_GATEWAY_BIWARE_SEND_REJECT_EXIT_CODES` に載せた終了コードだけは「未送信が確定」として `失敗`（`biware-send-rejected`）になる。既定は空なので R-2 実測までは全部この経路）/ Biware 送信結果が異常	Biware 終了情報ファイル（制御ファイルと同じフォルダの固定名 `STATUS.BIZ`。同時通信 OFF。`Scope` フォルダの時刻付きはトレースの `.dat`）（固定長 128 桁・21〜22 桁目 = 制御電文の処理結果コード・エラーは `1/2-XX-23` `1/2-XX-33` 形・マニュアル「プログラミング」6-3 / 6.5.3・「クライアントアプリケーション」5.2）	処理結果コードから確認コード・パスワード・アクセスキー・ファイル名（`JW9810FCHKD1`）の設定票との食い違いを疑う。全銀レベルの失敗は JWNET の EDI 処理状況照会に載らない。直して別の要求コードで再生成
「該当ファイルなし」が続く	ゲートウェイは最大 10 回まで再試行（command は受信コマンドを再実行・受信コマンドの終了コードは現状 0 でも非 0 でも同じ扱いで inbox を回収する（`wl-w6nn` で記録と分類を追加）・scheduler は Biware の受信ジョブが動いていないと新しい受信は起きない → Biware のジョブ設定と実行ログを先に見る）→ 10 回で `照合待ち`（`receive-timeout`）	EDI 処理状況照会（接続登録番号で検索）の 4 分岐: 待機中 / 処理中 / 処理完了（→ Biware の受信ログ・Status.biz）/ 該当の要求ファイルがない（= 送信失敗）
command 方式でコマンドが上限（`COMMAND_TIMEOUT_MS`）を超えた	送信は `indeterminate`（`submitting` 維持・自動再送なし）・受信は `照合待ち`（`receive-failed`）	判定者が JWNET 側を確認してから再生成の可否を決める
Biware コマンドの終了コードが 0 以外	`edi-biware-command` ログ → runbook E-2.6 の段切り分け	1001–1027 は全銀エクスプローラ側エラー（通信の前後は個別説明・STATUS.BIZ・センター側記録で確認） / 負値は準備中（3-XX-XX）/ 正値は開始後異常（符号化規則で X-XX-XX に戻す）。0 以外を一律「送信失敗」にしない
1 回の受信で複数の結果ファイルが返る	STATUS.BIZ の通信ファイル番号（本文の構成から 23–28 バイト目）	正常（複数ファイル転送）。1 ファイルごとに §4.1 の 6〜8 で判定する

7-4 画面・API のエラー¶

観測	意味	対処
入力エラーの列挙	チェックディジット・必須・日付・数量・SHIFT_JIS バイト長	原本の値で直す。推測で補わない
400	要求の形（例: 300 件超・D63 の集合外・入力不正）	文言を読んで直す（22023 の文言は英語で透過）
403	自社テナント / 管理者 / 資格情報	admin か・`configured` かを確認
409（生成）	資格情報未設定	`/collector/settings/jwnet` で `configured` に
409（生成・要求コード重複 23505）	同じ要求コードが 30 日内に使われた（採番の競合）	もう一度「要求ファイルを生成」（新しい要求コード）
409（取り下げ）	`待機中` 以外の行は取り下げられない	一覧を更新して状態を確認
422（結果ファイルの判定・アップロード欄）	未知レコード・HR1 欠落・ファイル名（要求コード）不一致	原本を直さず保全し、ファイル名・HR1 の要求コード・時刻を判定者へ（#829 で補助文が付く）。キューの TEST 行には判定ボタンが出ないので 422 は起きない。アップロード欄の 422 は要求フォームの選択と無関係に本物（TEST を選んだままでも正常扱いにならない・#829）
500	想定外。採番は 1 つ消費されている	v1.94.0（#829）は「要求コード `は採番済みです。判定者へ知らせ、再送は別の要求コードで」を表示（コピー可）。v1.93.0 の画面は汎用文言なので要求コードは API（Workers）のログで確認。再送は別コードで`
`失敗`（`request-decrypt-failed`）	KEK が Worker と不一致	E-2.3（Secret Manager の KEK を再確認）
`失敗`（`virus-check-failed` / `virus-scanner-not-configured`）	Defender 実行不可	E-2.3 のスキャナ設定・サービスアカウント
`失敗`（`closing-window-before-send`）	閉局前	翌営業日に再生成（`sent` の中断は自動再開）

7-5 送受信キューが進まない（QA Q-T1・裁定 A = `wl-wgwr` で停止契約を変更・v1.94.0）¶

原則: 受信予算の内側は「正常な待ち」。 v1.94.0 以降のゲートウェイは graceful stop（nssm stop / nssm restart）を受けても 送信済・結果待ち（sent）の行を 照合待ち にせず、再起動後に R7 が受信を再開する（残り試行は送信時刻から再計算・最低 1 回）。command 方式では受信コマンドの実行中に停止要求が来てもコマンド完了を待ってから止まり、回収済みの結果は再起動後に先に取り込む（停止予算と nssm console 猶予は runbook E-2.4/E-2.6 の値・約 2 分）。v1.93.0 以前のゲートウェイ（H8 で v1.94.0 が入らなかった場合）は停止で行が 照合待ち（receive-timeout）に確定して戻らないので、受信予算の内側では再起動しない。

観測	判断	対処
`送信中` が送信予算（claimedAt 起点・原本保存 + Defender スキャン最大 120 秒 + Biware 送信の外側期限（scheduler 360 秒 = 内側 300 + 安定待ち 2 + 余裕 / command は E-2.6 の方式別で最大 420 秒）+ R4 RPC 30 秒 ≈ 10 分。画面の警告は 12 分）を超えて続く	送信の結果が不明（`indeterminate`）。次のサイクルで自動的に `照合待ち`（`gateway-restarted-during-send`）になる（再起動は不要・次回以降の R7 在庫確認で到達する）。予算内は正常な送信中（スキャン + 送信の合計が数分かかるのは正常）。v1.94.0（#839）では終了コードが `edi-biware-command` ログに残り、E-2.6 の REJECT 表に載せたコードだけ `失敗`（`biware-send-rejected`）になる（既定は空）	再起動不要。health（`edi-ok` か・`polling-*`）と Biware の Status.biz で送信が届いたかを判定者が確認 → 届いていなければ別の要求コードで再生成
`送信済・結果待ち` が受信予算内（送信後 scheduler 34 分 / command 約 24 分 + コマンド所要）	正常	待つ。`C:\jwnet\inbox` と gateway ログの受信試行（回数）を見るだけ
`送信済・結果待ち` が受信予算を超えても変わらない	loop が止まっている疑い	health の `polling-stale` / `polling-cycle-failed` / `polling-not-started` を確認 → `nssm status` が止まっていれば `nssm start`。動いているのに進まないなら v1.94.0 以降は `nssm restart` してよい（行は `sent` のまま再開される。受信コマンド実行中なら完了待ちで停止に約 2 分かかる）。v1.93.0 以前は restart で行が `照合待ち` になるので判定者へ
`照合待ち`（`receive-timeout` / `result-correlation-failed` / `result-parse-failed` / `gateway-restarted-during-send` …）	人の確認が必要	runbook Phase F の回収手順（原本の保全 → id → 要求コード → HR1 照合 → EDI 処理状況照会の 4 分岐）→ 判定者。照合待ちの行の復旧（後着原本の判定用コピーの命名戻し・手動受信前のゲートウェイ停止と排他・残留の保管・再開条件）は手順書 10 章「照合待ちの復旧と次のサイクルへの戻し方」と runbook Phase F 末尾の小節。自動再送はしない

同テナントの新規送信は 送信中 / 送信済・結果待ち の行がある間は進まない（1 ファイルずつの規則）。照合待ち は阻止しない。

7-6 E01 の読み方（要約）¶

EN 必須 / ED 形式 / EB 業務条件 / EE EDI 固有（EE01006 接続登録番号・EE01007 利用区分 3 とファイル ID・EE01009/10 作成日時・EE02009 HD2 件数・EE04006 番号範囲差・EE04009 300 件）/ EF EM ファイル・項目 / CA CB 件数超過（照会） / FC FD 結果サイズ超過 / ES センター（人手確認）。詳細は 10 章「判定と E01 の読み方」。

8. 記録・証跡¶

8.1 サイクルごとに残すもの（要求コードで束ねる）¶

種別	出所	保存先・形
送信記録 JSON（手渡しのみ）/ 生成の通知（要求コード・SHA-256 先頭 12 桁）	画面	`<日付>/<要求コード>/`
判定記録 JSON	画面「判定記録（JSON）を保存」	同上
結果原本	`C:\jwnet\received`（ゲートウェイ）/ `C:\jwnet\inbox`（手渡し）	VM 内で原本のまま保全・持ち出さない。台帳にはファイル名と SHA-256 だけ
要求原本	Biware の `archive`（送信済み退避）	同上（DB には `request_sha256` / `request_byte_length` が残る）
Biware の応答	Status.biz（21〜22 桁目）・ログ	認証値をマスクした写し
ゲートウェイ	exchange 行の状態遷移・events（sha256・transport id・エラーコード）・ログ抜粋	ログ抜粋
JWNET 側	EDI 処理状況照会の問合番号・受付日時・処理状態	台帳
CONFIG.BIZ[117] の設定値	VM（Biware の構成ファイル）	確定値 '1'。H8 で設定し R-2 再実行時に反映を確認

8.2 台帳（1 行 = 1 サイクル）¶

日付 / 要求コード / TC / 機能 / 名義 No. / 番号の件数 / 送信時刻 / 受信時刻 / HR1 / HR2 エラー件数 / E01（コード・件数）/ 合否 / 結果原本ファイル名 / 問合番号 / 備考

8.3 含めないもの¶

PSK・確認コード・パスワード・アクセスキー・EDI 利用確認キー・加入者番号・事前登録番号・通信 payload・原本の中身。

9. リスクと未確定事項（go/no-go に影響）¶

#	事項	影響	対処・期限
1	~~B6 = Biware 駆動方式の裁定と command 用の値~~ → 解消（2026-09-20）。裁定（9/16・`command`）→ 手順書 5 冊の提供（9/20）→ runbook E-2.6 / E-2.3 へ実値（exe・引数・戻り値 27 行・符号化規則・STATUS.BIZ）の 3 段階が完了	—	残るのは `31` の R-2 実測のみ: 「ファイルなし」の終了コード `31` は第 7 章の表に行が無く符号化規則からの導出なので、R-2（9/25・再インストール後 9/29 再実行）で実測して確定する。実測が `31` でなければ `_RECEIVE_NOFILE_EXIT_CODES` を直す。原文どおりの代替判別は STATUS.BIZ の処理結果コード `17`（runbook E-2.6「「ファイルなし」の識別」）。Phase D の文書（登録名・再インストール・証跡所在・`[117]='1'` 確定）は本 PR で反映済み
1b	`CONFIG.BIZ[117]`（ファイル破棄基準）が既定 `0` のまま	複数ファイル受信の途中で `0-00-31` 以外の中断エラーが起きると、正常受信済みの分も全部破棄される（全銀協の規定どおり）。センターは受信済み結果を再受信できないので回復不能。当該試行の結果証跡を失い合否確認できない。再試験の可否は残日程・データ条件で判断	確定値 `1`。H8（9/29 の配備）で設定し R-2 再実行時に反映を確認。（終了回答電文を正常送信したとき以外は破棄 = 1 ファイルごとに正常受信分が残る・Biware 独自の拡張）。規定から外れる選択なので確定の記録を残す。根拠は runbook E-2.6「複数ファイル転送と CONFIG.BIZ の設定」
2	ゲートウェイ未配備（H8 9/29）・Biware 再インストール後の設定再投入ミス	期間直前で発覚すると修正時間がない	R-2（再実行）・R-3 の受入条件（health / スキャン 0 / 停止猶予 / 切り戻し）を満たすまで go しない
3	IPsec rekey 跨ぎ（CHILD 1h / IKE 8h）	1 日目に通って 2 日目に落ちる	Day-1 の午前・午後に各 1 本。R-5 で `--list-sas` を rekey 後に再取得
4	事前登録分の日次クリア復元が仮説	復元されないと 1700（2 件）等は総試行数が上限	R-6（10/6 朝）で確定し §6 を組み直す
5	1700 の試行が 2 件しかない	1 回の E01 で残り 1 回	TC-03 の R65 を判定者と二人で写す。TC-15 は Day-2 の最後に置き、前提が揃わなければ Day-3 へ
6	送受信キューの詰まりが画面に見えない（`wl-t4ll`）	テナントの送信が止まる	§7-5 の手順を当日体制で共有。表示は 10/2 までに入れるか判断
7	docs の不整合（`wl-e7zj`: Day-1 の初回 3201・D31 判定の記述・TEST の注記）	操作者が古い記述で迷う	本書が当日の正典。docs は 10/2 までに訂正
8	実結果ファイルの列順が仕様と違う可能性	判定が 422 で止まる	原本で E01 を確認し合否は判定者が決める。期間中に受信原本（秘密除去）を fixture へ落とす
9	要求ファイルのサイズ（4,500 KB 超は処理されず・5,200 KB 超は結果ファイルが作られない）	「送信正常なのに結果が来ない」	生成時に画面のサイズ表示を見る（接続テストの件数では通常数 KB）
10	3101 を収運・処分名義で送ると自社区間が未取得	区間番号を判定表から読めない	反映ボタン（区間は R19 全区間から）か原本 R19 で読む
11	停止契約: 受信待ち中の graceful stop で行が `照合待ち` に確定し再開されない（QA Q-T1）	「詰まった？」と再起動した 1 回で行を失う	裁定 A（2026-09-16）→ `wl-wgwr`・PR #831（停止時も `sent` を保つ・R7 再開・command は受信コマンド完了待ち・停止予算検証・回収済み結果の永続記録と再開時の再適用（R2）・v1.94.0 9/26 → H8）。v1.94.0 が H8 に入らなければ §7-5 の旧原則（予算内は再起動しない）で運用
12	Biware コマンドの終了コードが記録・分類されない（QA Q-T2/Q-T3）	送信拒否と送信不明、ファイルなしと認証失敗を運用者が区別できない	`wl-w6nn`（ログ追加・B6 の終了コード表の後に分類）
13	V8 の sim は監視型で command と両立しない・3102/TEST の結果 fixture が無い（QA Q-T6）	R-4 で 4 本通せない	#832 で解消（dev 起動 env 表・`--once`・`--keep-request-code`・`OK3102` / `TESTFMT`）
14	入力検証の穴 5 種（1601 終了日・単位コード・数量/単位の対・D62 の区分・基準重量と区分 1 合計）があった（QA Q-A1〜A5）	センターで E01 → 再送 1 回を浪費（1700 は 2 件しかない）	5 種すべて是正済み（3 種は #830・D62 の区分と基準重量は #834）。各 TC の注意欄どおり原本の指定値を二人で確認
15	ゲートウェイ送信では名義が保存されない・No.11 注記なし・TEST 行に再送案内・500 の要求コードが見えない（QA Q-A6〜A9）	誤名義送信・二重報告・追跡不能	#829 で是正済み（v1.94.0）。v1.93.0 の画面で運用する場合だけ §2.2 の注意（機能切替ごとに名義欄を目視）

10. 参照¶

準備計画 docs/superpowers/plans/2026-09-06-jwnet-connection-test-first-pass-plan.md（§1 合否・§2 リスク・§5 V ゲート・§6 運用・§7 人間タスク）
運用手順書 10 章 docs/operations-manual/10-jwnet-integration-test.md
runbook docs/runbooks/jwnet-edi-gcp-biware.md（Phase E-2 配備・E-2.6 駆動方式・E-2.9 運用の注意・Phase F）
実装設計 docs/superpowers/specs/2026-09-10-jwnet-connection-test-e2e-gateway-design.md（mig269 の状態遷移）
独立バリデータ scripts/jwnet-edi/README.md
EDI 仕様書（公開版）第 4 章 / 第 5 章 / 第 6 章 Ver.2.01（JWNET サイト）。第 3 章の推奨フロー（送信 → 5 分以上休止 → 新規要求で受信）と §3-2 運用時間
インターコム B6 回答（2026-09-15）: コマンド実行可・同期・終了コード 0 = 受信書込完了・受信タイムアウト設定不可・「ファイルなし」再試行は標準機能なし・終了情報ファイル Scope\yyyyMMdd-hhmmss-fff-Status.biz 21〜22 桁目
※ 現行の案内は E-2.6 の固定名 STATUS.BIZ（同時通信 OFF）。ここは当時の回答の記録