コンテンツにスキップ

ADR 0024 · JWNET は標準EDI のみ対応する（Web-EDI は本番運用せず・Q3 完了目標）

背景

方式は 0019→0020→0021→0022→0023 と 5 回振れ、0023 で「Web-EDI を本番方式・標準EDI は外部前提が整った時点で go-live ADR を起こす」と着地していた。その後の照会で標準EDI の壁が縮小した: IPsec/NAT の設定値は利用申請後に JWNET から送付され（製品探しではなく設定合わせ）、JWNET 側にクラウド（AWS）構築実績があることが確認済み。機能面でも標準EDI は Web-EDI に対し実質 +10 機能（承認/否認 0701/0702/1200・通知情報照会 3000 等）で、失うのは CSV 登録 1 件のみ（2026-08-08 機能差分調査）。残る未知は EDI クライアント（拡張 Z 手順ソフト）の選定 1 点で、有識者へ照会中。

この状況でユーザーが確定した（2026-08-13）: 「WE-01 は不要。Web-EDI は対応せずに標準EDI のみいきなり対応する方式とする。対応完了は Q3（2026-09〜11）中を目標」。Web-EDI で本番を開始してから標準EDI へ移行する二度手間（運用教育・データ移行・撤去）を払わず、外部ベータ（Y27Q3）の前提となる ASP 展開へ一本道を取る判断である。

判断

JWNET は標準EDI のみ対応する。WE-01（Web-EDI 利用申込）は提出せず、Web-EDI は一度も本番運用しない。対応完了目標は Q3（2026-11-30）。

  • 外部手続き（ユーザー・並走）: 標準EDI 利用申請（EDI 事業者登録含む・9/1 目標）→ JWNET から IPsec 設定情報送付 → 通信環境準備（本命 GCP VM + strongSwan + iptables SNAT・9/30 目標）＋ EDI クライアント選定（有識者回答 8/31 が前提）→ 接続テスト（回避不可・先方日程が Q3 内完了の律速・申請受理後に即予約） → 本番。
  • 開発順序: ①常駐ゲートウェイ設計の改訂（既存 docs/superpowers/specs/2026-07-25-jwnet-gateway-design.md は SUPERSEDED 状態のため本 ADR 前提で改訂） → ②DB を Web-EDI 状態（mig210）から標準EDI へ再転換する forward migration（mig209/205-207 が template・採番は実装時の実測最大+1） → ③常駐ゲートウェイ実装（搬送層のみ。電文組立 packages/shared/src/jwnet/** は搬送中立の純関数で無改修流用） → ④接続テスト配線（利用区分 '3'・センター確認コード） → ⑤D14 取消の配線 + D61/D62。
  • Web-EDI 資産は段階的に撤去する: (1) 本 ADR 採択と同時に Web-EDI の画面導線（nav）を外す（コードは削除しない）。WE-01 を提出しないため資格情報が存在せず、authz は fail-closed で Web-EDI 送信は機械的に不能 — 導線露出だけが混乱要因なので導線のみ塞ぐ。(1.5) 2026-09-09（wl-dlfj）: 旧 Web-EDI 送受信 API 6 本を 410 で閉鎖（POST /jwnet/submissions・/web-edi/request-file・/retry・/resolve・/result-file・/inquiry-result。requireAuth より前の閉鎖ガードで未認証でも 410・handler 本体は残す）。接続テスト（10/5〜）の前に API 側の fallback を機械的に不能にする判断で、コードは残るが到達不能になる。温存は資格情報 2 本・test 2 本・照会 3101/3201 の 2 本（3201 は接続テストページが legacy inquiry-search-file を env='test' で使うため）。(2) 標準EDI の接続テスト通過（実運用開始）後に撤去 PR を出す（#504 の撤去 diff が git 履歴の資産。電文組立・DB 状態機械・authz・暗号・監査は温存し、web-edi.ts と搬送 UI/RPC のみ撤去のスコープ精査済み）。即時全撤去を採らなかったのは、方式が 5 回振れた履歴と、Q3 到達が外部律速（調達・接続テスト）を含むことから、採択時点では標準EDI が実際に疎通するまで fallback 価値が残ると判断したためである（この API 側の fallback 価値は (1.5) の 410 閉鎖で 2026-09-09 に放棄済み。(2) に残るのはコードの物理削除だけ）。
  • Web-EDI 経路依存の既知課題（wl-2ao / wl-jiw / wl-6vy）は、標準EDI の要求/結果束縛でも等価の課題が再出現するため、①の設計改訂で「標準EDI 版として吸収」か「close-with-reason」を個別に決める。

帰結

得るもの

  • 承認/否認（0701/0702/1200）・通知情報照会（3000）等の実質 +10 機能（Web-EDI では構造的に不可能だった承認業務がシステム化できる）。
  • 移行の二度手間を回避: Web-EDI の運用教育・本番データ・撤去コストを払わない。ASP / マルチテナント展開（Y27Q3 外部ベータの前提）へ一本道。
  • 電文組立・DB 状態機械・資格情報暗号・監査ログは搬送層分離設計のおかげで無改修流用（標準EDI 固有で新規に書くのは搬送層のみ）。

手放す / 引き受けるコスト

  • 「今すぐ JWNET に到達できる経路」を放棄する（0023 が Web-EDI を採った最大の理由）。標準EDI が疎通するまで JWNET への電子報告経路は無い（紙運用は返送期限管理 mig216 が担保）。
  • Q3 完了は外部律速に依存: 接続テストの先方日程・EDI クライアント調達（有識者回答待ち）・事業者登録の審査期間。滑った場合は Q4（全工場並行運用）と重なる。
  • migration の往復 cruft がさらに 1 段積む（205-210 の 3 往復 + 再転換 1 回。番号は連番・順序整合は docker proof が担保）。
  • Web-EDI UI が接続テスト通過まで「導線なしの休眠コード」として残る（撤去は段階 2）。

次のアクション

  1. 設計改訂（Claude・即時）: 常駐ゲートウェイ設計を本 ADR 前提で改訂（brainstorming → spec。IPsec 終端 = JWNET 設定送付前提・EDI クライアント選定の分岐を含む）。
  2. 外部手続き（ユーザー・並走）: 標準EDI 利用申請 9/1 → IPsec 環境 9/30 → 接続テスト日程の即予約（Notion 📌 外部手続きに期限つきで登録済み）。
  3. 実装スライス 1（codex・設計確定後）: nav 導線オフ + DB 再転換 migration + ゲートウェイ骨格。以降は設計の分割に従う。
  4. 2026-08-23 ユーザー決定: 送信画面の提供まで collector の JWNET設定 nav 導線を非表示化（ページ・ルート温存・再表示は標準EDI 接続テスト通過後）。