コンテンツにスキップ

ADR 0019 · JWNET 連携は Web-EDI 機能で行う（標準EDI + 常駐ゲートウェイは Phase 2）

  • 状態: ADR 0020 により supersede（2026-08-07） — Web-EDI を廃止し標準EDI へ一本化。以下は当時の判断の記録として残す。
  • 日付: 2026-07-25
  • 関連: ADR 0015 品質ゲート / docs/superpowers/specs/2026-07-25-jwnet-webedi-first-decision.md（方式選定の正典・数値表） / docs/superpowers/specs/2026-07-25-jwnet-gateway-design.md（Phase 2 の設計） / docs/superpowers/plans/2026-07-25-jwnet-edi-registration-and-connection-test.md（Phase 2 の登録手続き）

背景

JWNET へ電子マニフェストの終了報告を機械的に送るため、当初は 標準EDI機能を前提に設計していた。 標準EDI は 拡張Z手順（全銀協標準通信プロトコル TCP/IP 版）+ IPsec の非同期ファイル伝送で、 REST/WebAPI/Webhook を持たない。したがって Cloudflare Workers 単体では終端できず、 常駐・ステートフルなゲートウェイ（Cloudflare 外の VM）が必須になる。

この前提のもとでの本番到達コストは大きかった。

  • EDI事業者登録の審査に数週間〜数ヶ月
  • 接続テストが必須（2週間・19:00–23:00 の枠）（※ 接続テストの実際の運用時間は平日 9:00–17:00。19:00–23:00 は電子契約機能の時間の取り違えで誤り・2026-09-03 に EDI 仕様書 3-12 で訂正）
  • 通信パッケージ・IPsec ルータ・固定 IP・ISP 契約・24時間常駐 VM とその監視

判断

Web-EDI 機能を Phase 1 として採択し、これを本番運用の方式とする。 標準EDI + 常駐ゲートウェイは、人の介在をゼロにする自動化のための Phase 2 に後退させ、 本番到達の前提条件から外す。

決定的だったのは、接続仕様書 Ver.2.01 の一次情報で次が確認できたことである。

  1. 要求／結果ファイルのレイアウトが標準EDI と同一（§1-5「標準ＥＤＩ機能に準拠したファイルの送受信」）。 HD1/HD2 も共通で、利用区分 "1" は標準EDI・電子契約・Web-EDI の本番を指す（§5-3）。 → 既に実装した D09 / D60 ビルダー・R電文パーサ・SHIFT_JIS 層がそのまま使える。
  2. 共栄が必要な機能がすべて使える（§2(3)）。運搬終了報告 1000・処分終了報告 1501・ 最終処分終了報告 2001・修正／取消・照会が Web-EDI の対応機能に含まれる。
  3. 接続テストが存在しない。運用時間表（§3-2）には標準EDI と電子契約の接続テスト行はあるが Web-EDI の行が無い。検証は 3か月使えるデモシステムで行う。
  4. サーバも通信ソフトも要らない。JWNET 公式ページが「既存のEDI方式と違い、サーバーや通信ソフトも 不要」と明記し、導入容易性を Web-EDI=○ / EDI方式=× としている。
  5. 申込が軽い。様式 WE-01 の押印・郵送に対し、センターの審査は 約10営業日で 利用証・登録番号・デモ情報が交付される（利用細則 第4条）。

さらに、Phase 2 の通信モジュールを実地調査した結果、当初想定していた構成に無理があることも判明した。

製品 拡張Z手順 OS 価格 仮想環境
日立ソリューションズ 全銀協手順通信プログラム TCP/IP対応版 対応（32,768byte） Windows のみ 一次局 58,000円 + 保守 12,000円/年 動作保障範囲外
キヤノンITソリューションズ 全銀TCP通信プログラム 対応（拡張仕様） AIX / Linux 非公開 記載なし

gateway 設計が第一候補としていた「GCP Compute VM（Linux）」は、日立製品では選べない （Windows 専用かつ仮想環境が保障外）。Phase 2 に進む場合は、接続仕様書 §3-3(7)1) が公開を約している 「ソフトウェアラウタにおける通信実績」を照会票で取得してから VM/OS を確定する必要がある。

帰結

得たもの

  • 本番到達の外部リードが「数週間〜数ヶ月」から 10営業日になった。
  • インフラ投資（常駐 VM・IPsec ルータ・固定 IP・通信パッケージ・24h 監視）が不要になった。
  • 接続テストという合否ゲートが消え、デモシステムでの検証に置き換わった。
  • 電文層のコードが一切無駄にならなかった。

引き受けたもの

  • 1バッチあたり2回の人手介在（生成したファイルを送受信BOX へ置く／届いた結果ファイルを取り込む）。
  • 報告作業用の Windows PC + Java 8 が必要（送受信BOX は Java Web Start が作るフォルダ）。 オラクル Java は有償サブスクリプションだが、Eclipse Temurin + IcedTea-Web で無償運用できる。
  • 標準EDI より制約が厳しい: 1ファイル 500KB / 300明細、本番は 平日 6:00–23:00。
  • 結果ファイルは作成日から2週間しか保管されず、受信済みの再受信もできない。取りこぼすと 受理状態を照会で確認する必要がある（照会は未実装）。

設計上の含意

  • 方式は併用可（§1-5(3)。マニフェスト情報はセンターのDBで一元管理される）。したがって Phase 2 へ進むときも Phase 1 を捨てる必要はなく、搬送層だけを差し替える。 この差し替え可能性を保つため、電文組立（純関数）と搬送を分離したままにする。
  • 利用区分 '3'（接続テスト）は Web-EDI 経路に持ち込まない。DB・shared・API のすべてで Web-EDI の環境は demo / prod に限る。
  • Phase 2 のゲートウェイも、result fields を DEFINER RPC 経由で書く（直接 service_role DML に しない）。これは mig162 で error_message を server-owned にした際に確定した。

不変条件の全量は AGENTS.md の「JWNET Web-EDI（不変条件ラチェット・mig160/161/162）」節にある。 運用手順は 操作手順書 09 を参照。

検討したが採らなかった案

  • 標準EDI を先に通す: 本番到達が数ヶ月遅れ、インフラ投資も先行する。同じファイル仕様なので 先に Web-EDI で運用を立ち上げても手戻りが無い。
  • ASP 事業者のサービスを利用する: 自社名義の単一加入者運用に対して依存と費用が過大。
  • Web 方式（画面手入力）のまま: 二重入力が残り、waste-link から報告する意味が失われる。
  • 送受信BOX の自動化を Phase 1 に含める: フォルダ監視スクリプトで無人化できるが、 報告作業 PC への常駐プロセス追加は運用主体が共栄側になる。まず人が回せる形で立ち上げる。