コンテンツにスキップ

ADR 0021 · JWNET 連携は当面 Web-EDI で本番運用する（標準EDI 一本化を保留）

背景

ADR 0020 は「Web-EDI を廃止し標準EDI に一本化する（自社内 EDI事業者 → 将来 ASP事業者）」と決め、標準EDI go-live A（2 層クレデンシャル + 複数加入者要求ファイル組立・mig205-207）と Web-EDI 撤去（#504）を develop に投入した。

しかしその後の調達・技術調査で、標準EDI の本番到達が想定より重いことが具体化した。0020 が「別スライスで実施」とした前提が、いずれも短期に解けない。

  1. 本番到達が調達律速。拡張Z手順の通信パッケージ調達 + EDI事業者登録の審査（数週間〜数ヶ月）+ 接続テストが直列に乗る。コードはほぼ揃っているが、律速はコードでない。
  2. 最大の技術争点が IPsec。全銀TCP 通信製品を 13 本調査したが、どれも IPsec を製品側で持たず全て SSL/TLS。JWNET は IPsec を要件とするため、IPsec は通信ソフトと別レイヤ（strongSwan / VPN ルータ / Cloud VPN）で用意する必要が高い。クラウド前提の当社構成では、ここがソフト選定より重い未解決争点として残る（JWNET への通信実績照会が未実行）。
  3. 拡張Z手順を明示する製品が限られる。キヤノン ITS / 日立ソリューションズ / DAL の 3 社のみで、日立は Windows 専用 + 仮想化サポート外のためクラウド Linux 前提では落ちる。第一候補の構成が確定していない。
  4. JWNET は方式併用可（報告データはセンターで一元管理）で、いま JWNET に到達できる唯一の実働経路が Web-EDI。Web-EDI のコードは本番（v1.68.0）に温存されており、WE-01「Web-EDI 機能利用申込書」（外部リード ~10 営業日）+ 資格情報設定 + demo 検証で本番運用に入れる。

つまり、標準EDI の「自動化と ASP 到達」という利点は依然魅力的だが、当面の本番到達性を優先する段階に戻す。標準EDI を捨てるのではなく、調達・IPsec・登録が整うまで保留する。

判断

当面は Web-EDI 機能で JWNET 連携を本番運用する。標準EDI 一本化は保留し、前提（IPsec 終端・通信パッケージ/OS 確定・EDI事業者登録）が整い次第あらためて判断する。

  • 本番方式 = Web-EDI。WE-01 申込 → 資格情報設定 → demo 検証 → 本番。搬送は HTTPS + 送受信 BOX（接続テスト不要）。
  • develop を Web-EDI 状態へ戻す。標準EDI go-live A のコード（#505）と Web-EDI 撤去（#504）を revert し、JWNET コードを本番（v1.68.0）と同一の Web-EDI 実装へ復帰させる。
  • DB は forward migration で逆転。mig205-207 は dev Supabase に適用済みで un-apply できないため削除せず、mig208 で DB 効果を逆転する（jwnet_credentials 復元・jwnet_edi_operators/jwnet_edi_subscribers drop・jwnet_submission_authz_ok 等を本番版へ復元）。dev も prod も forward のみで整合する。
  • 標準EDI の成果は git 履歴に保全（#504/#505・mig205-207）。標準EDI 再開時に参照・復元できる。ADR 0020 の現状整理（電文組立/DB/authz が約 7 割搬送非依存で流用可）は引き続き有効。

本 ADR は ADR 0020 を supersede するが、0020 は判断の履歴として残す（rewrite しない）。0020 が挙げた標準EDI の利点（自動搬送・ASP 到達）を当面手放す判断であることを明記する。

帰結

得るもの

  • 本番到達が速い（WE-01 ~10 営業日）。EDI事業者登録の審査・接続テストを待たない。
  • インフラ投資が不要（常駐 VM / IPsec 機器 / 固定 IP / 通信パッケージ / 24h 監視を持たない）。IPsec 争点を今解かなくてよい。
  • 既存コードがそのまま動く。Web-EDI 実装は本番（v1.68.0）に温存されており、develop も本 ADR で同一状態へ復帰する。

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

  • 日次報告の搬送が人手のまま。要求ファイルを人が送受信 BOX へアップロードし、結果ファイルを人がダウンロードして取り込む。
  • ASP / SaaS 化は当面保留。他社加入者の代理送信（ASP）は自動搬送の標準EDI が前提で、手動の Web-EDI では成立しない。ASP は標準EDI 再開後の課題とする。
  • 標準EDI 再開時に再投資が要る。mig205-207 を mig208 で一度逆転するため、再開時はあらためて DB とコードを立て直す（成果は git 履歴に保全済みで設計はやり直さない）。

ソフトウェアの現状

  • Web-EDI: web-edi.ts（500KB/300件/ファイル名制約）・JwnetWebEdiPage（要求/結果セクション）・JwnetInquiryPanel・jwnet-web-edi.ts・request/result-file の HTTP 搬送層・jwnet_credentials（テナント×env の資格情報・AES-256-GCM）— いずれも本番と develop の双方で稼働する。
  • 標準EDI（保留・git 履歴に保全）: 2 層クレデンシャル（jwnet_edi_operators/jwnet_edi_subscribers）・複数加入者要求ファイル組立・失効 RPC（mig205-207・#505）と搬送中立化した電文層（#504）。再開時に #504/#505 を土台に戻す。
  • 電文組立・結果パーサ・照会・SHIFT_JIS・要求コード採番・submission 状態機械は搬送非依存で、Web-EDI / 標準EDI のどちらでも共通に使える（この分離が「再開しても設計をやり直さない」担保）。

次のアクション

  1. Web-EDI 本番運用（ユーザー・外部手続き）: WE-01「Web-EDI 機能利用申込書」提出（~10 営業日）→ EDI利用確認キー等の資格情報を設定 → demo 検証 → 本番報告。
  2. develop の Web-EDI 復帰（本 ADR と同一スライス）: #504/#505 の revert + mig208（DB 逆転）+ 全 docker proof / verify。
  3. 標準EDI 再開の判断材料（保持）: IPsec 争点・JWNET 通信実績照会・全銀TCP 通信パッケージのベンダー見積は、再開判断の前提として保持する（scratchpad の照会/問い合わせドラフト・メモリ [[jwnet-pivot-webedi-to-standard-edi]]）。標準EDI を再開するときは本 ADR を supersede する新 ADR を起こす。