電子マニフェストのアプリ開発｜JWNET連携の方式選定と現場入力・再送設計

電子マニフェストを扱うアプリで最初につまずくのは、JWNETに一般的なWeb APIが用意されていない点です。標準EDI機能の接続仕様は全銀協標準プロトコルの拡張Z手順によるファイル交換で、送信した瞬間に登録結果が返る作りではありません。この記事では、三つの方式の選び分け、接続仕様書の件数上限や保管期間が実装にどう跳ね返るか、現場入力でオフラインをどこまで許容できるか、登録失敗をどう分類して再送するかを、一次仕様の記載に沿って整理します。

まとめ｜JWNET連携で先に決める接続方式と結果ファイルの持ち方

最初の分岐は接続方式です。ブラウザで完結するWeb方式、Web方式と同じ環境で送受信ボックスにファイルを置くWeb-EDI機能、自社側にEDIサーバを構えてファイル交換する標準EDI機能の三つがあります。現場アプリを自社で作る要件が出ると候補は標準EDI機能に寄りますが、登録が日次で数十件に収まるならブラウザのスマートフォン版で足りることも珍しくありません。

標準EDI機能を選ぶなら、実装の骨格は三点で決まります。要求ファイルを送ってから結果ファイルを受け取るまでが非同期で、仕様書は送信完了から概ね5分以上の休止を求めている。結果ファイルはセンター側で作成日から2週間しか保管されず、受信済みのものは再受信できません。マニフェスト番号も送信前には自社で採番できず、センターが登録処理の時点で払い出します。ここから、送信台帳を自社に持ち、要求コードで消し込み、結果ファイルを永続化する構造が決まります。

現場のモバイル入力については、JWNET側にオフライン登録の仕組みがない以上、端末にキューを持って復帰後に送るしか手がありません。ただし登録には引渡し日から3日以内という期限があり、土日祝と年末年始は3日に数えない営業日計算が伴います。滞留の監視を経過時間ではなく残り営業日に置き換えて、はじめて運用に載る設計です。

電子マニフェストのアプリがJWNETへ接続する三つの方式と役割

JWNETへのアクセスはWeb方式とEDI方式に分かれ、EDI方式の中がさらに標準EDI機能とWeb-EDI機能に割れます。作るものが変わるため、要件定義の初期に切り分けます。

Web方式のスマートフォン版と現場登録支援機能で足りる運用の見極め

Web方式は、加入者がブラウザからマニフェスト情報の登録・修正・取消と各種終了報告を行う方式です。スマートフォン・タブレット版も専用アプリではなく標準ブラウザからのアクセスで、iOSとAndroidの最新版・画面5インチ以上が動作条件です。あわせて見ておきたいのが現場登録支援機能でしょう。収集運搬業者が事前に仮登録し、回収当日に現場で数量を入力、排出事業者がスマートフォンで内容を確認して暗証番号を入力すると、その場で登録が成立します。注意すべきは責任の所在で、登録を行うのはあくまで排出事業者であり、内容の責任も同様です。収集運搬業者のアプリが暗証番号を預かって代行する設計は取れません。

標準EDI機能とWeb-EDI機能が分かれる条件と送受信の担い手

EDI方式の二つは、ファイルを誰が送るかで分かれます。標準EDI機能では、EDI事業者やASP事業者が自社側にEDIクライアントを持ち、センターのEDIサーバと要求ファイル・結果ファイルをやりとりする形です。一方のWeb-EDI機能は、送受信ボックスに要求ファイルを置き、Web画面へのログイン中に送受信が実行される仕組みで、サーバも通信ソフトも要りません。利用条件としてJava 8の導入と利用申込が案内され、1回あたり最大300件を扱えます。EDIそのものの種類はEDIの仕組みと種類をまとめた記事に譲りますが、JWNETでは「サーバを立てるか、ボックス経由で済ませるか」が実質的な分岐でしょう。

ASP事業者経由と自社EDIサーバ構築で変わる責任分界の置き方

標準EDI機能を使う経路は二つです。自社でEDIシステムを構築する形と、廃棄物管理システムを提供するASP事業者のサービスを使う形があります。どちらでも、接続テストを完了した事業者だけがEDI事業者として接続を認められる点は変わりません。加入者とEDI事業者の紐付けにはEDI利用確認キーが使われます。加入申込の完了時に割り当てられ、加入者自身がJWNETのマイページから確認できる仕組みです。EDI事業者は加入者番号とEDI利用確認キーを受け取り、関連加入者追加画面から申込を行うと、通常15分ほどで手続きが完了します。

標準EDI方式の接続仕様が示す非同期バッチ前提の実装制約と上限

接続仕様書 Ver.2.01（仕様有効期間は2025年10月30日から）が想定しているのは、対話型のAPIではなく日次バッチに近い運用です。ここを取り違えると画面設計から作り直しになります。

全銀協標準プロトコル拡張Z手順という通信前提が招く実装コストの幅

標準EDI機能の通信は、全銀協標準プロトコル（TCP/IP版）の拡張Z手順で行われます。EDI方式でのアクセスは2001年4月に始まっており、当時のファイル転送標準が現在も残る形です。通信区間はIPsecで暗号化し、標準EDI機能のファイル形式はテキスト、電子契約機能はバイナリと使い分けられています。実装側から見ると、HTTPクライアントを書けば済む話ではありません。仕様書自身が送信処理の説明で「お手持ちの拡張Z手順のソフトウエア」を前提としており、手順の自作を想定していない。見積りでは、このミドルウェアの調達費と送受信制御の作り込みを分けて積むのが実態に合います。

要求ファイルと結果ファイルの往復が同期応答にならない設計上の制約

処理は、要求ファイルの作成、送信、センター側の受信と処理、結果ファイルの作成、取得要求、受信の6段構えです。要求ファイルは1ファイルずつしか送れず、複数の同時送信はできません。さらに仕様書は、送信完了から受信処理を始めるまでに概ね5分以上の休止を必ず組み込むよう求めています。取得要求に対して送るべきファイルが無い場合は、ファイル制御文17のファイルなしレスポンスが返り、これがポーリング継続の合図になります。処理順序が保証されるのは単一のEDI接続登録番号についてだけで、番号をまたいだ順序に依存する処理は書けません。

運用で効くのが保管期間です。結果ファイルは作成日から2週間保管され、その間なら未受信のものを受け取れますが、期間を過ぎると削除されます。しかも受信済みの再受信はできず、途中で自社側が落ちて取りこぼすと取り直せない。受信したバイト列をまず永続化し、パースはその後に回す二段構えにしておかないと、障害のたびに手作業の照会が発生します。

1要求ファイル300件という上限と超過時に全件が返される挙動の扱い

1要求ファイルに指定できる明細レコードは300件です。301件以上を載せると、接続情報の直下にエラー情報レコードが付き、エラーコードEE04009とリターンコード1が設定されます。このとき全明細が処理されず、要求レコードの内容がそのまま結果レコードに設定されて返る。部分的に成功する作りではないため、分割は送信前に自社側で行います。カウント方法にも癖があり、数えるのは他のレコードに従属するものを除いた明細の総数で、有害物質情報や収集運搬情報のように親にぶら下がるレコードは含めません。照会側にも別の上限があり、主なものは次のとおりです。

自社基幹への取り込み設計とマニフェスト番号を軸にした突合の作り方

接続が通っても、基幹システム側のデータモデルが仕様に合っていないと運用が破綻します。特に効くのが番号の持ち方と文字の扱いです。

マニフェスト番号の桁数を固定しないテーブル定義と検証ロジックの置き場

マニフェスト番号は10桁の数字に1桁のチェックディジットを付けた11桁です。ところが仕様書は、桁数を増やす可能性があり11桁である保証はない、番号体系も今後変更する場合がある、と明示しています。11桁固定でテーブルを定義すると、仕様変更のたびに移行作業が発生する。可変長で持ち、桁数チェックはアプリケーション層の設定値へ外出しするのが安全側でしょう。採番タイミングも設計に響き、番号が払い出されるのは予約登録またはマニフェスト登録が行われた時点で、送信前に自社で採番することはできません。基幹側の主キーは自社の伝票番号などで持ち、マニフェスト番号は結果ファイルの受領後に埋まる列として扱います。

要求コードを送信台帳の識別子に据えて二重登録を防ぐ突合の設計手順

要求ファイルの接続情報レコードには要求コードという項目があり、仕様書はファイルごとにユニークなコードを設定するよう求めています。これを自社の送信台帳の識別子と1対1で対応させると、送信と結果の突合がそのまま成立する。この設計が効くのは二重登録の防止です。ネットワークが切れて送信結果が判然としないとき、同じ内容をもう一度送ってよいかはセンターが受信済みかどうかで決まる。要求コードを固定して処理状況を確認すれば、受信済みなら再送しない、未受信なら同じ要求コードで送り直す、という分岐を機械的に書けます。同じ操作を何度実行しても結果が変わらない性質の作り方は冪等性の担保方法を扱った記事と共通で、JWNET連携では要求コードがその鍵です。

SHIFT_JISと禁則文字の制約から逆算するデータ整形層の置き場所

ファイルはCSV形式で、データ項目をダブルクォーテーションで囲み、文字コードはSHIFT_JIS、有効文字範囲はJIS第一水準と第二水準に限られます。機種依存文字も外字も半角カタカナも使えません。加えて禁則文字が定められ、シングルクォーテーション、パーセント、アンダースコア、カンマ、改行コード、ダブルクォーテーション、不等号は含められない。文字コード8740から889Eの範囲は、送っても黒四角に置き換えられて戻ってきます。問題になるのは、基幹システムのマスタが往々にしてこの制約を満たしていない点です。送信直前に一括変換するのではなく、マスタ登録の時点で入力規則としてかけるか、連携対象データを日次で検査して事前に潰す層を置きます。エラーで返ってきてから直す運用は、3日以内という期限の下では回りません。

現場のモバイル入力を成立させるオフライン考慮と画面状態の設計判断

回収現場は電波が弱い場所も多く、入力してすぐ送れる前提は置けません。かといって無制限に貯め込むこともできない板挟みを、設計で解きます。

3日以内という期限を営業日計算に落とし込む滞留しきい値の決め方

登録と報告の期限は、引渡し日、運搬終了日、処分終了日、最終処分終了日からそれぞれ3日以内です。この3日には土曜日曜、祝日と振替休日、12月29日から1月3日を算入しません。一方でゴールデンウィークとお盆は休日等に当たらないため、通常どおり算入されます。単純な経過時間で警告を出すと、連休前は早すぎ、盆期間は遅すぎる警告になる。実装としては、この算入ルールに沿った営業日カレンダーを持ち、各レコードに期限日時を持たせるのが素直でしょう。端末のキューに残る入力について残り何営業日かを計算し、1営業日を切ったら現場と管理者の双方へ通知するしきい値を置きます。業務側で誰がいつ何を入力するかという運用フローは電子マニフェストの流れと期限管理を整理した記事で扱っています。なお、3日以内という期限そのものの根拠や、一部義務化の対象事業者・JWNETの料金体系は電子マニフェストの仕組みと義務化・費用を整理した記事にまとめています。

端末ローカルのキューに置いてよい情報と置いてはならない情報の線引き

JWNET側にオフライン登録を受け付ける仕組みはありません。圏外の入力を成立させる手段は、端末に一度保存して復帰後に送信するローカルキュー以外にない。ブラウザベースで作るならService Workerとローカルストレージを使う構成になり、その基本的な作り方はPWAの仕組みと採用判断を扱った記事で扱っています。キューに載せる内容は選別が要ります。数量、車両、荷姿といった現場でしか確定しない値は保存対象ですが、認証情報は別です。特に現場登録支援機能を使う運用では、排出事業者が入力する暗証番号を収集運搬業者側の端末に残してはいけません。登録の主体と責任が排出事業者にあるという前提が崩れるためです。

送信済みと登録完了を別物として見せる三段階のステータス表現の設計

非同期方式である以上、送信した時点では登録が成立していません。画面上のステータスを二値で持つと、現場は「送ったのに番号が出ない」と混乱する。端末に保存済み、センターへ送信済み、登録完了でマニフェスト番号を受領、の三段階に分けて表示するのが実務に合います。三段階目に進むのは結果ファイルを受け取ってからです。取得は5分以上の休止を挟んだ後で、要求ファイルの実行時間も概ね5分とされるため、現場の体感では十数分の遅れが出ます。この待ち時間を隠さず「センターで処理中」と表示すると問い合わせが減る。エラーで戻った場合も、現場で直せるものと事務所側の対応が要るものを区別して見せると、現場が判断に迷いません。

登録失敗時の再送とエラー監視を運用で回すためのエラー分類と設計手順

失敗の原因を一括りにすると、再送してはいけないものまで再送してしまいます。層で分けるのが出発点です。

通信層とファイル層と業務層に分けたエラーの一次切り分け基準の作り方

エラーは三層に分かれます。通信層は拡張Z手順のソフトウェアが返す送信結果ステータスで、異常ならセンターは要求ファイルを受信できておらず、処理も実行されていません。ファイル層は、件数超過のEE04009のようにファイルの形式や構造に起因するもので、リターンコードとエラーコードで判別する。業務層は加入者区分や委託契約、期限に関わるもので、データを直さない限り何度送っても同じ結果になります。再送してよいのは、原則として通信層の失敗だけです。ファイル層は自社側の生成ロジックの不具合であることが多く、修正リリースが要る。業務層は現場や事務所への差し戻しで、自動リトライで解決する種類ではありません。この三分類を、送信台帳のステータスとしてそのまま持たせます。

送信成功後に結果が取れない状態で再送を止める判定と待機の間隔の決め方

難しいのは、送信は成功したが結果ファイルが取れない状態です。安易に再送すると二重登録になる。取るべき手順は、要求コードを条件にEDI処理状況を確認し、受け付けられているかを見ることです。受付済みであれば再送せず、結果ファイルの取得を続けます。処理完了の表示が結果ファイルの作成完了であって送信完了ではない点にも注意が要る。送信完了から5分以上の休止が求められ、要求ファイルの実行時間も概ね5分とされ、加入者情報や照会機能の数によって伸びます。一般的な指数バックオフとリトライ予算の考え方はそのまま使えますが、初回待機を秒単位で置く設定は合いません。分単位を起点にし、上限回数ではなく期限までの残り営業日で打ち切る設計にすると、3日ルールと整合します。

処理状況の照会画面に頼らず未受領を検知する監視対象と警告水準の決め方

EDI処理状況の確認はWebページを介する機能で、機械的に叩ける口として案内されているわけではありません。Web-EDI機能の処理状況照会も、最新100件の表示や受付日を最大7日で指定する検索といった画面前提の作りです。したがって監視の主役は自社側の送信台帳になる。指標は三つに絞れます。未受領のまま滞留している要求コードの件数と最長経過時間、業務層エラーで差し戻したまま再送されていないレコードの件数、期限まで1営業日を切ったレコードの件数です。いずれも絶対値ではなく、期限との距離で警告水準を決める。誰がいつ気付いて誰が動くかという受け皿の設計はインシデント管理と監視・オンコールの実装を扱った記事の枠組みを当てはめられます。

自社でEDI接続を実装する場合とASPに寄せる場合の採用条件と見送り場面

ここまでの制約を踏まえると、自社実装が見合う条件はかなり絞られます。結論を先に置くと、件数と独自要件の二つが揃ったときだけです。

自社でEDI接続を実装する判断が立つ四条件と見積りが膨らむ箇所

自社で作る判断が立つのは、次の条件が重なる場合です。第一に、登録件数が多く1要求ファイル300件の上限が現実の制約として効く規模であること。第二に、廃棄物の発生データが既に基幹側にあり、二重入力を止める効果を金額で説明できること。第三に、収集運搬業者と処分業者を兼ねるなどして複数の加入者番号を一括で処理したいこと。第四に、現場の入力画面に自社固有の要件があり、標準のブラウザ画面では業務が回らないことです。見積りで膨らみやすいのは、拡張Z手順のミドルウェア調達と送受信制御、結果ファイルの永続化と突合、SHIFT_JISと禁則文字に合わせたデータ整形層、そして接続テストになる。接続テストは完了しなければ本番接続を認められない関門で、クリティカルパスになりやすい工程です。基幹システムと外部システムをつなぐ設計の進め方はAPI開発・システム連携の支援で扱う領域と重なるため、要件の切り分け段階から相談していただく形も取れます。

ASP事業者への委譲とWeb-EDI機能で止める判断が成り立つ場面

逆にASP事業者のサービスへ寄せるほうが合理的なのは、加入者番号が一つで、登録が日次で数十件にとどまり、拡張Z手順の運用を担える要員が社内にいない場合です。ASP事業者は既に接続テストを完了しているため、加入者番号とEDI利用確認キーを渡して関連加入者の追加を申し込めば、短時間で始められます。自社に残るのは、基幹システムからASPへデータを渡す部分だけになる。もう一段手前で止める選択もあります。1回あたり300件まで扱えるWeb-EDI機能なら、サーバも通信ソフトも不要で、Web方式と同じパソコン環境のまま一括登録ができる。ただしJava 8の導入が前提として案内されている点は、社内の端末管理ポリシーと突き合わせて確認します。

接続方式を作り込まずに見送るべき規模感と機能ごとの向き不向きの確認

見送りの判断は、義務化の対象かどうかとは切り離して考えます。2020年4月1日から、前々年度の特別管理産業廃棄物（PCB廃棄物を除く）の発生量が年間50トン以上の事業場を設置する排出事業者は電子マニフェストの使用が義務付けられていますが、義務の対象であることと自社開発が必要であることは別問題です。義務を満たすだけならWeb方式で成立する。機能ごとの向き不向きもあります。電子契約の保管・検索・閲覧機能は1要求ファイル1件と定められており、大量処理には向きません。契約書の一括移行のような使い方を前提に設計すると、想定した時間で終わらない事態になる。扱う機能ごとに件数上限を確認してから、バッチの設計に入るのが順序です。

よくある質問

電子マニフェストを現場で使うのに専用アプリのインストールは必要ですか？

JWNETが提供するスマートフォン・タブレット版は、機種に搭載された標準ブラウザからアクセスする形で案内されており、専用アプリの配布は前提になっていません。自社で独自の入力画面を作る場合に限って、ブラウザベースかネイティブかという選択が発生します。

JWNETにはREST APIやWebhookのような仕組みが用意されていますか？

標準EDI機能の接続は全銀協標準プロトコル（TCP/IP版）の拡張Z手順によるファイル交換で、いわゆるRESTのエンドポイントを叩く方式ではありません。結果の通知も、センターから送りつけられるのではなく、自社側から取得要求を出して受け取る形です。HTTPベースのAPIを想定した設計は前提から合いません。

同じ要求ファイルを二度送ってしまうと二重登録になりますか？

センターが受信して処理を終えている場合、同じ内容を再度送れば別の登録として処理される可能性があります。送信結果が判然としないときは、要求コードを条件にEDI処理状況を照会し、受付の有無を確かめてから判断してください。通信層で失敗していた場合はセンターが受信しておらず、同じ要求コードのまま送り直せます。

結果ファイルを受け取り損ねた場合はもう一度取得できますか？

結果ファイルはセンターで作成日から2週間保管され、期間内なら未受信のものを受け取れます。ただし受信済みの再受信はできません。取りこぼすと復旧できないため、受信したファイルをまず保存してから解析する手順にします。

圏外の現場でもマニフェストの登録操作を進められますか？

JWNET側にオフライン登録の仕組みはないため、そのままでは登録できません。自社アプリで端末にローカルキューを持ち、通信が回復した時点で送信する構成になります。その際、引渡し日から3日以内という期限を踏まえ、滞留を残り営業日で監視する設計にします。

関連記事

• EDIとは？電子データ交換の仕組み・種類と2024年問題後の移行判断を解説：EDIそのものの種類と移行の考え方。
• 冪等性とは？読み方・意味からAPI・IaCでの担保方法まで解説：二重登録を防ぐ識別子の設計。
• リトライパターンとは？指数バックオフ・ジッター・リトライ予算の実装判断：再送間隔と打ち切りの決め方。
• PWAとは？Service Workerの仕組みとネイティブアプリとの使い分け・採用判断：オフライン入力の実装手段。
• インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装：未受領を検知した後の受け皿。