JWNET連携を自社サービスに組み込むには ーASP・SaaS事業者が押さえておきたい課題とEDI製品の選び方コラム：EDI資料室

産業廃棄物の電子マニフェストシステムである「JWNET」は、排出事業者、収集運搬業者、処分業者をつなぐ仕組みとして利用されています。
産業廃棄物処理業者向けの業務システムやクラウドサービスを提供するASP・SaaS事業者にとって、JWNETとの連携機能は、サービスの利便性を高めるうえで検討対象となる機能の一つです。自社サービスで管理している契約、収集運搬、処分などの情報をJWNET連携に活用することで、マニフェスト登録や各種報告に関する入力・確認作業の効率化が期待できます。
一方、JWNETとのEDI方式による接続には、一般的なWeb API連携とは異なる通信方式への対応が必要です。また、サービス利用企業や通信量の増加、制度改正への継続的な対応など、サービス提供後の運用まで見据えて構成を検討しなければなりません。

本稿では、ASP・SaaS事業者がJWNET連携機能を自社サービスへ組み込む際に直面しやすい課題と、システム規模に応じたEDI製品の選び方をご紹介します。

JWNETでは、Web画面から情報を登録する方法に加え、業務システムとデータを連携するEDI方式が提供されています。^※
ASP・SaaS事業者がEDI方式に対応することで、自社サービス上で管理している契約、収集運搬、処分などの情報をJWNETへ連携し、登録結果や各種報告を自社サービスへ取り込む仕組みを構築できます。
これにより、サービス利用者は複数のシステムへ同じ情報を入力する作業を減らせるほか、入力間違いや登録漏れの防止も期待できます。JWNET連携機能は、産廃業界向けサービスにおける利便性や競争力を高める重要な機能の一つといえます。

JWNETとのEDI方式による接続では、通常のWeb APIとは異なる通信要件を考慮する必要があります。
サービスの業務機能は自社で開発できても、通信制御まで独自に実装すると、プロトコルの調査、設計、開発、接続試験に相応の工数がかかります。通信障害時の再送や処理結果の確認、夜間・早朝の自動運転なども含め、安定運用を前提とした設計が必要です。
そのため、通信部分には既存のEDI製品を利用し、自社は産廃業務に関する機能やユーザー体験の向上に開発リソースを集中する方法が選択肢になります。

サービス開始時点では少数の利用企業を想定していても、事業の拡大に伴い、接続先や通信量が増える可能性があります。
多数の利用企業からデータを受け付ける場合は、同時接続数、処理性能、スケジュール制御、障害発生時の影響範囲などを考慮しなければなりません。小規模な構成でスタートする場合でも、将来的な利用企業数やデータ量を想定し、拡張可能な仕組みにしておくことが重要です。

JWNET連携は、接続できれば完了というものではありません。運用開始後には、通信状況の監視、エラー発生時の再処理、ログ確認、OSやミドルウエアの更新などが発生します。
ASP・SaaS事業者には、個々の利用企業に代わって安定したサービスを提供する責任があります。障害の検知方法や復旧手順、担当者への通知、再送の判断などをあらかじめ整理し、特定の技術者だけに依存しない運用体制を構築する必要があります。

2025年4月に公布された廃棄物処理法施行規則の改正により、2027年4月から、処分業者は最終処分終了の報告にあわせて、処分方法、処分方法ごとの処分量、処分後の産業廃棄物または再生される物の種類・量などを報告することが義務付けられます。追加項目は2027年3月末まで任意項目ですが、2027年4月から入力が必須になります。^※
ASP・SaaS事業者には、自社サービスを利用する処分業者が新たな報告を行えるよう、画面、データ項目、業務ロジック、JWNET連携処理などへの対応が求められます。
制度改正のたびに通信部分を含めて個別開発するのではなく、業務機能と通信機能の役割を分けておくことで、変更箇所を明確にし、継続的な改修を進めやすくなります。

JWNET連携に適した製品は、利用企業数、通信量、必要な運用管理機能、自社サービスへの組み込み方によって異なります。

自社サービスにJWNETとの通信機能を組み込みたいASP・SaaS事業者に適した製品です。
全銀TCP／IP手順の拡張仕様である拡張Z手順に対応し、AIXおよびLinux環境で利用できます。最大レコード長を65,379バイトまで独自拡張しているほか、同時接続セッション数に応じた製品が用意されています。コマンド形式の運用機能やユーティリティをユーザープログラムから起動できるため、自社サービスのバックエンド処理への組み込みや、無人運転の構成にも活用できます。
また、JWNETの標準EDI機能では、全銀協標準プロトコル（TCP／IP版）拡張Z手順が利用されています。^※
既存の業務機能や管理画面は自社で開発し、JWNETとの通信機能だけを利用したい場合に検討しやすい構成です。

JWNET連携に加えて、複数の通信プロトコルを利用するEDIサーバーを構築したいASP・SaaS事業者に適しています。
全銀TCP／IP手順のほか、ebMSv2、JX、AS2、FTP、SFTPなどから必要な機能を選択でき、WindowsおよびLinuxに対応しています。最大32回線まで同時接続でき、Webブラウザーから設定、状況照会、ログ閲覧などを行えます。また、APIを介した通信実行指示や設定情報の編集にも対応しています。
JWNETだけでなく、利用企業の基幹システムや外部サービスとの連携を段階的に追加したい場合に適した選択肢です。

多数の利用企業を抱え、大規模なJWNET連携基盤を構築するASP・SaaS事業者に適したエンタープライズモデルです。
最大128同時接続まで拡張でき、全銀協標準通信プロトコルに対応しています。各種フォーマット・文字コード変換、ジョブスケジュール、ブラウザーによる運用管理、APIやCUIを利用した上位アプリケーションとの連携など、EDIに必要な機能を備えています。
多数の利用企業からの通信を集約する場合や、大量のマニフェストデータを安定的に処理する場合、通信、変換、スケジュール、監視を統合的に管理したい場合に適しています。

JWNET連携は、産廃業界向けサービスの付加価値を高め、入力・確認作業などの業務負荷を軽減する有効な機能です。一方で、通信仕様への対応だけでなく、利用企業の増加、無人運転、障害対応、制度改正への追従まで考慮した設計が求められます。
通信機能を自社サービスへ組み込む場合は「全銀TCP通信プログラム」、複数プロトコルを扱う標準的なEDIサーバーを構築する場合は「EDI-Master B2B Standard」、多数の接続や大量データを扱う大規模基盤には「EDI-Master B2B Enterprise」が選択肢となります。
キヤノンITソリューションズでは、利用企業数、通信量、稼働環境、自動運転の方法、将来的なサービス拡張などを確認したうえで、ASP・SaaS事業者の要件に適したJWNET連携構成をご提案します。

JWNET連携機能の新規開発や既存サービスへの組み込み、Linux環境での構築、大規模な接続基盤の整備をご検討中のASP・SaaS事業者は、ぜひご相談ください。構成検討から製品選定、接続試験、導入後のサポートまで、お客さまのサービス規模と提供方針に応じて支援します。