外国送金のISO 20022移行で“想定外”が続出　期限内移行を完遂したJSOLの真価：プロジェクトの裏側をEDIスペシャリストが語る

2025年11月、EDIなどで使われる外国送金のデータフォーマットが国際規格「ISO 20022」準拠に完全移行した。多くの企業が対応に追われたが、仕様書にない“隠れ仕様”の判明やテスト期間の不足など、想定外の事態が相次いだ。混乱を極めたプロジェクトで、JSOLはどう難局を乗り越えて期限内の移行を完遂させたのか。

PR／ITmedia

» 2026年03月26日 10時00分公開

　Swift（国際銀行間通信協会）による旧フォーマット（MTフォーマット）の廃止と、国際規格ISO 20022への完全移行は外国送金業務の転換点となった。期限は2025年11月に設定され、金融機関のみならずグローバルに送金をする一般企業にとっても避けては通れない課題となった。

　この移行は単なるシステムのバージョンアップとは異なる。外国送金の共通言語が、タグ付きテキスト形式のMTフォーマットから、複雑な階層構造を持つXML形式に置き換わるためだ。通信手順やデータ形式も一変することから、影響は広範囲に及ぶ。ITmedia エンタープライズでは2025年にも、JSOLの有識者への取材を通じて、企業が検討すべきポイントや対応方法を紹介した（記事はこちら）。

　この規格変更の裏側には、各行固有の仕様差やタイトな検証期間といった高い障壁が潜んでいた。移行プロジェクトで何が起きていたのか。JSOLはこれらの難題にいかに対処し、期限内の移行を完遂させたのか。本記事では、ISO 20022移行という複雑で時間的制約がある規格変更の舞台裏を取材した。

旧フォーマットの限界と移行の必然性

JSOLの香坂真人氏（カスタマーエクスペリエンス事業本部上席プロフェッショナル ITアーキテクト）

　大規模な刷新が求められた背景には、従来の送金データ形式の構造的な限界があった。JSOLのEDIスペシャリスト、香坂真人氏は次のように指摘する。

　「Swiftはこれまでタグ付きテキスト形式のMTフォーマットでやりとりをしてきましたが、この形式には幾つかの問題がありました。その一つがデータ量不足です。送金目的や住所などの情報を十分に盛り込めませんでした」

　情報不足は、近年厳格化するマネーロンダリング対策やテロ資金供与対策で深刻な課題となる。旧フォーマットでは、制裁対象者の照合時に無関係な取引まで「疑わしい」と判定する誤検知が避けられない。その結果、金融機関は膨大なアラートを確認するという非効率的な作業が発生していた。一方ISO 20022は、詳細なデータを構造化して保持できる。これによって送金の透明性が増し、確認作業を自動化できる。

企業の送金依頼フォーマットもISO 20022準拠になる（提供：JSOL）《クリックで拡大》

通信手順とデータ形式の刷新　国内企業に求められたシステム対応

　この移行に伴って「全銀手順」による通信や固定長の「全銀フォーマット」を使ってファームバンキングで送金依頼をしていた企業は、通信プロトコルを「JX手順」に、データ形式をXMLベースのISO 20022フォーマットに変更しなければならない。通信手段まで変える理由を香坂氏は次のように説明する。

　「ISO 20022への移行にあたっては、データ形式の変更だけでなく、通信手順の見直しも必要になりました。ISO 20022はXMLによる階層型メッセージを採用しているため、固定長レコードやEDIFACTなどのセグメント型メッセージを前提としてきた全銀手順では取り扱いが難しく、ZEDIで採用されているJX手順への移行が進められました」

通信手順もJX手順への変更が求められる（提供：JSOL）《クリックで拡大》

　基幹システムが出力する送金依頼データをNTTデータのファームバンキングサービス「AnserDATAPORT」などを経由して銀行に送信する際、ISO 20022に準拠した「PAIN.001」に変換する必要がある。データ構造が異なるため、単純な変換では済まない。

　この対応でJSOLは重要な役割を担った。ISO 20022への移行は、対応期限が設けられた規格変更であり、対応が間に合わなければ外国送金業務そのものに支障を来す可能性があった。そのため、既存の業務フローや取引を維持したまま、確実に新フォーマットへ移行できる支援が求められていた。

仕様書にない“隠れ仕様”の判明で進捗が停滞

　JSOLが支援したプロジェクトでは、フィージビリティスタディ（実現可能性調査）や銀行仕様の机上確認といった準備フェーズは計画通りに進んだ。しかし、実装・テストフェーズに入り、データを流すと、仕様書にはない受付条件やチェックが次々と表面化した。銀行から提示された仕様書は標準的な記述にとどまっており、実際の挙動は銀行ごとに異なっていた。

　「為替予約の仕様は、やってみて初めて分かることが多くありました。件数の上限が銀行ごとに違うだけでなく、上限を超えたときの対応方法も銀行ごとに異なっていました」

　為替予約は外国送金における重要な要素だが、その扱いには銀行ごとの独自性が残っている。標準仕様では、件数上限や例外時の挙動までは十分に定義されておらず、こうした差異は実装・テストフェーズで実データを流して初めて顕在化する。机上の検討だけでは捉えきれない点が、プロジェクトの大きな課題となった。

テスト期間が足りない　極限状態での品質確保

　もう一つの課題がスケジュール面だ。多くの企業が同時期にテスト工程に進んだことで、銀行との接続テストを巡る調整には制約が生じた。10月から約1カ月の予備期間を確保していたものの、仕様差への対応に想定以上の時間を要し、十分なテスト期間を確保できないケースもあった。

　「本来であれば1カ月かけるテストを、より短い期間で完了させなければなりませんでした。金融システムに求められる品質は妥協できません。限られた時間で、いかに効率良く、手戻りなく進められるか。私たちの真価が問われる局面でした」

コンサルティング、プロジェクト、サービスの連携で難局を突破

　この難局を打開したのが、JSOLの「コンサルティング」「プロジェクト」「共通基盤サービス」という3組織の連携だ。各プロジェクトで顕在化していた隠れ仕様やトラブルシューティングの知見を、コンサルティングチームが横断的に集約。銀行ごとに異なる特殊仕様やエラーパターンは、「共通ナレッジ」として整理・標準化され、他のプロジェクトにも速やかに共有された。

　「各社が個別に銀行と向き合い、手探りで解を見つけなければならない状況を、当社がナレッジを集約することで一気に前に進めました。コンサルタントが仕様差を整理して共通基盤チームが実装し、運用に反映する。このサイクルを高速で回せたことが大きかったですね」

　ある銀行で発生した課題が、別のプロジェクトでは「事前に織り込まれた前提条件」として扱われるようになり、手戻りは着実に減っていった。

プロジェクトとコンサルティングサービスの密な連携によって仕様を明らかにした（提供：JSOL）《クリックで拡大》

　この連携はテスト工程でも力を発揮した。過去の実績や他社事例を踏まえて送金国、通貨、取引条件といった観点から必要なパターンを洗い出し、コンサルティングチームが「全網羅テストケース」を作成。各社がその中から業務で発生しうるテストケースをピックアップすることで、やみくもに数をこなすのではなく、押さえるべきポイントに集中したテストが可能になった。

　限られた期間で効率と精度を両立させたテストを実施し、無事に移行を成功させた。点で発生していた課題を線でつないで面として解決する。3組織の連携がプロジェクトを再び動かしたのだ。

エラーを可視化して業務担当者の負担を大幅軽減

　運用面での課題解決にも工夫を凝らした。ISO 20022対応で多くの企業が利用したAnserDATAPORTには、1回のデータ伝送に含まれる複数件の送金指示のうち、1件でも不備があれば全件がエラーになるという制約がある。送金件数の多い企業にとって大きなリスクだった。

　こうした状況では、エラーの原因をいかに早く特定し、修正できるかが重要になる。実際の運用では、その初動対応を業務担当者が担っているケースも多い。しかし、XMLの構造やエラーコードの意味が分からなければ原因の特定に時間がかかり、復旧が遅れてしまう。

　そこで香坂氏らは「業務担当者が自力で、すぐに原因を把握できる」環境づくりに着目した。XMLの専門知識がなくても不備がある箇所を直感的に理解できるよう、専用の管理画面を開発。エラー項目を画面で特定して修正を促す仕組みを構築した。

　「AnserDATAPORTのエラーコードを見ても、業務担当者には何が問題なのか分かりません。そこで、エラー箇所を画面にハイライト表示させて『ここが全角になっています』『必須項目が抜けています』と、具体的に示すようにしました。原因が分かればすぐに修正できます」

　エラーを“読む”のではなく“見る”――。業務担当者がその場で対応できる仕組みを整えて迅速な業務復旧を可能にした。

企業のEDI戦略を全方位で支える「伴走型支援」

　JSOL-EDIサービスの役割は、大規模な制度対応の支援だけにとどまらない。日々のEDI運用で担当者が直面するさまざまな課題に寄り添い、「止めない」「迷わせない」「属人化させない」運用を支えることに本質的な価値がある。

　EDIは一度つながれば終わりではない。取引先の要請変更や業界標準の改定、基幹システムの刷新など、運用環境は常に変化する。JSOLは、そうした変化を前提に、企業ごとのEDI戦略を中長期で支える“伴走型”の支援を行っている。

　流通業界では、「流通BMS」対応を軸に、卸やメーカーが抱えるEDI運用の複雑さを吸収してきた。小売業から求められるWeb-EDIへの対応や、出荷データの複雑な連携も、RPAやAPIを活用して現場の手作業や属人対応を減らし、安定した運用に置き換えている。

　改正電子帳簿保存法への対応として提供する「電子取引データ保存サービス」も、単なる制度対応にとどまらない。EDIでやりとりされるデータを長期にわたって安全に保存し、必要なときにすぐに検索・活用できる環境を整える。監査や調査対応の負担を軽減すると同時に、業務改善や経営判断に活用できる基盤として機能する。

　制度対応、業界標準、日々の運用負荷。EDI担当者が一人で抱え込みがちな課題を仕組みと知見で引き受ける。それがJSOL-EDIサービスの「伴走型支援」だ。

EDIからiPaaSへ　企業の持続的な成長を支える

　JSOLが見据えているのは、「つなぐだけのEDI」からの進化だ。SaaSの普及によって多様なアプリケーションやクラウドサービスが広がり、それらをどう連携させてデータをどう活用するかが新たな課題となっている。

　同社は、EDI運用で培ってきた「止まらないシステム」を支える設計思想と運用ノウハウを基盤に、JSOL-EDIを社内外のデータ連携を統合するiPaaS（Integration Platform as a Service）に進化させつつある。既存のオンプレミス環境とクラウドサービスを柔軟につなぎ、分断されがちなデータを横断的に扱える基盤に発展させる狙いだ。

　EDIは、導入して終わりの仕組みではない。ビジネス環境が変化する中で、安定稼働を維持しながら、新たな連携や要件に対応し続けられるかどうかが企業の競争力を左右する。従来型EDIで築いた信頼性を起点に、より広いデータ連携と活用を支えるプラットフォームへ――。JSOLの取り組みはその延長線上にある。

　個別の課題に向き合いながら積み上げてきた知見を、次の時代のデータ流通基盤につなげていく。その進化は、企業の持続的な成長を支えるための基盤づくりそのものだ。