ADR 0020 · JWNET 連携は標準EDI に一本化する（Web-EDI 機能を廃止・自社内 EDI事業者 → 将来 ASP事業者）¶
- 状態: 保留（ADR 0021 が supersede・当面 Web-EDI） ← 採択 (2026-08-07)
- 日付: 2026-08-07
- 関連: ADR 0021 JWNET 連携は当面 Web-EDI で本番運用する（本 ADR を supersede・標準EDI 一本化を保留） /
ADR 0019 JWNET は Web-EDI 機能で行う（本 ADR が supersede する） /
docs/superpowers/specs/2026-07-25-jwnet-gateway-design.md（標準EDI 常駐ゲートウェイの設計・本 ADR で 主経路に格上げ） /docs/superpowers/plans/2026-07-25-jwnet-edi-registration-and-connection-test.md（EDI事業者登録・接続テストの手続き） / QA スイープ 2026-08-06 の標準EDI 現状整理（本 ADR 「帰結」に要約）
背景¶
ADR 0019 は「Web-EDI 機能を Phase 1 の本番方式とし、標準EDI + 常駐ゲートウェイは人の介在をゼロにする Phase 2 に後退させる」と決めた。その判断の決め手は、Web-EDI が 本番到達の外部リードを 10 営業日に短縮し、常駐 VM / IPsec / 固定 IP / 通信パッケージ / 24h 監視といったインフラ投資を不要にする点だった。
しかし運用の実像と事業計画を踏まえ、この trade を反転させる。
- Web-EDI は人手の搬送が残る。要求ファイルを人が JWNET 送受信 BOX へアップロードし、結果ファイルを人がダウンロードして取り込む。日次の報告業務としては手作業が消えない。
- 自社の JWNET 連携は標準EDI の接続テストを前提にしている（＝「JWNET の EDI 連携テストがある」）。Web-EDI には接続テストが無く、この前提と噛み合わない。
- 事業計画が ASP を志向する。まず自社内で EDI事業者登録して標準EDI で自社報告を回し、社内で問題なければ ASP事業者登録してマルチテナント SaaS として提供する。ASP（他社の加入者に代わって報告する）モデルは自動搬送の標準EDI が前提であり、手動の Web-EDI では成立しない。
つまり Web-EDI の利点（速さ・インフラ不要）よりも、自動化と ASP/SaaS への到達可能性を優先する段階に入った。
判断¶
Web-EDI 機能を廃止し、JWNET 連携を標準EDI に一本化する。
- 段階: ① 自社内 EDI事業者として登録し標準EDI で自社報告を本番運用 → ② 社内検証を経て ASP事業者登録しマルチテナント提供。
- ADR 0019 で Phase 2 に後退させていた標準EDI + 常駐ゲートウェイを 主経路に格上げする。
- Web-EDI は標準EDI が接続テストを通過するまで撤去しない。JWNET は方式併用可（報告データはセンターで一元管理）であり、現時点で JWNET に到達できる唯一の実働経路が Web-EDI であるため、初回の標準EDI 本番報告が成功したのちに「非推奨 → 削除」とする。
本 ADR は ADR 0019 を supersede するが、0019 は判断の履歴として残す（rewrite しない）。0019 が挙げた利点（10 営業日・インフラ不要）を手放す判断であることを明記する。
帰結¶
得るもの¶
- 日次報告の人手搬送が消え、自動化できる。
- ASP / SaaS への道が開く（標準EDI は代理送信・多加入者を前提にできる）。
- 標準EDI は共栄が必要とする全機能（運搬終了
1000/ 処分終了1501/ 最終処分終了2001/ 修正・取消 / 照会）に対応する（ADR 0019 §2 の確認事項は方式非依存で有効）。
手放す / 引き受けるコスト¶
- 本番到達の外部リードが 10 営業日 → 数週間〜数ヶ月に戻る（EDI事業者登録の審査 + 接続テスト）。
- インフラ投資が必要: 拡張Z手順 + IPsec を終端する常駐ゲートウェイ（Cloudflare 外の VM）・固定 IP・通信パッケージ・24h 監視。
- 未解決の製品/OS 矛盾を先に解く必要（ADR 0019 の表のとおり）。拡張Z手順の既知製品は日立ソリューションズ（Windows 専用・仮想化サポート外）とキヤノン ITS（価格非公開）で、設計第一候補の Linux GCP VM がどちらでも成立しない。接続仕様書 §3-3(7)1) が公開を約す「ソフトウェアラウタにおける通信実績」を照会票で取得してから VM/OS を確定する（この一手が未実行）。
ソフトウェアの現状（QA スイープ 2026-08-06 の整理）¶
設計の「電文組立と搬送の分離」が実コードで守られており、標準EDI に必要なソフトウェアの約 7〜7.5 割が既にあり、搬送非依存でそのまま流用できる。標準EDI 固有の実装は実質 0%（設計のみ）。
- 「再利用可」 電文組立（
packages/shared/src/jwnet/**・D09/D60/封筒・buildEdiRequestTextは利用区分'1'|'2'|'3'を型で受け済み）/ 結果パーサ（HR1/HR2/R系/E01）/ 照会（3101/3201）/ SHIFT_JIS 層 / 要求コード採番 / submission 状態機械 /jwnet_submission_authz_ok（env リテラルを持たず搬送中立）/ credential 暗号（AES-256-GCM）/ 追記専用の監査ログ。 - 「Web-EDI 固有＝撤去対象」
web-edi.ts（500KB/300件/ファイル名等 Web-EDI 制約）・JwnetWebEdiPageの要求/結果セクション・resolve_web_edi_submitting・request/result-file の HTTP 搬送層。 - 「未実装」 常駐ゲートウェイ（拡張Z手順/IPsec）・EDI事業者登録スキーマ/設定・接続テスト有効化（コードは資格情報ブリッジ ~2 行 + 6 RPC の許可判断・②に依存）・D14 取消（実装済み・未配線）・D61/D62。
自社内 go-live のクリティカルパス¶
① ゲートウェイ製品/OS を JWNET「ソフトウェアラウタ通信実績」照会で確定 → ② EDI事業者登録（審査・数週間〜数ヶ月）→ ③ 接続テスト（コードは即着手可・②が発行するセンター確認コード等に依存）→ ④ D14/D61/D62 配線。律速はコードでなく調達・登録。
ASP事業者（将来・自社内より大きい）¶
delegation は DB にあるが実行経路は未構築。安全性に関わる 3 点を必ず閉じる: (1) request-file の nominee 束縛欠落（wl-2ao · 委任送信が nominee のマニフェストに事業者自身の加入者番号を載せうる）(2) 結果取込の nominee 束縛 + HR2 名義照合（現状 HR2 名義は解析後に破棄）(3) 要求コード台帳を事業者テナント単位 → 加入者単位へ（JWNET の 30 日ルールは加入者/接続にスコープ）。加えて delegation UI/API・有効期限・委任状証跡・事業者単位の登録スキーマ（現モデルは authz が credential_tenant_id = nominee_tenant_id を要求し構造的に ASP 形を禁じている）。
ドキュメント¶
- 本 ADR で ADR 0019 を supersede。
specs/2026-07-25-jwnet-gateway-design.mdとplans/2026-07-25-jwnet-edi-registration-and-connection-test.mdは「Phase 2」表記から主経路へ格上げして更新する（別スライス）。- 運用手順書
09-jwnet-web-edi.md/10-jwnet-integration-test.md（送受信 BOX 前提）は標準EDI 運用へ書き換える（Web-EDI 撤去と同時・接続テスト通過後）。 - AGENTS.md の JWNET 節は Web-EDI 撤去のタイミングで整理する（現時点では Web-EDI が唯一の実働経路のため記述を残す）。
次のアクション（本 ADR の外・別スライスで実施）¶
- JWNET へ「ソフトウェアラウタ通信実績」を照会（VM/OS 確定の前提・調達律速）。
- EDI事業者登録の申請準備（様式・審査リード確認）。
- brainstorming → spec → plan → 実装: 常駐ゲートウェイ（拡張Z手順/IPsec 終端）・接続テスト有効化・D14/D61/D62 配線。標準EDI が本番報告に成功したのち Web-EDI を撤去。