外国為替システム開発の進め方/やり方/流れや方法/手法/工程/手順

外国為替システム開発は、現状調査と要件定義で業務の範囲を決め、方式と難所を検証してから、テストと移行を進めます。この順に進めると、安全な決済と運用につながります。

対象範囲、開発の流れ、費用相場、見積もりの確認点を順に見ていきます。全体像は外国為替システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・外国為替システム開発の完全ガイド

外国為替システム開発の全体像

外国為替システムの対象を事業会社向け、外為事務、決済・中継基盤の3つに分けた図
対象範囲が広がるほど、接続や統制の要件も増えます。

外国為替システムは、円・米ドル・ユーロなどの取引を業務ルールと決済ネットワークに沿って処理します。

対象は、海外送金の受付から銀行事務、SWIFT・日銀ネットへの接続、勘定系・市場系まで幅があります。そのため、最初に利用者と処理範囲を分けておくと、見積もりと開発計画を具体的に立てやすくなります。

外国為替システムの3つの対象

主な対象は、利用者と業務範囲によって次の3つに分かれます。

  • 事業会社向け:海外送金の依頼・承認と会計消込の効率化。
  • 外為事務:銀行などが送金、外貨預金、為替予約、信用状を扱う業務。
  • 決済・中継基盤:SWIFT、日銀ネット、勘定系、AML基盤との接続。

事業会社向けでは、ERPや会計から支払データを取り込み、承認、銀行連携、状況照会までを扱います。

既存の口座や会計基盤を使える場合は、画面と連携機能を中心に追加開発で対応できます。

外為事務は、受付から審査、承認、決済、会計、顧客通知までを一連で処理します。

中継基盤ほど、接続試験や可用性、監査証跡、BCP要件の要求が増え、開発規模も大きくなります。

主要機能は受付後の処理が中心

受付後の処理では、取引の中身を正しく扱うことに加えて、周辺システムとの接続、監査の記録、マネロン対策まで求められます。受付後の業務では、適用レートを管理し、手動修正や差し戻しの理由を説明できる記録を残します。

  • 取引処理:本人確認と承認、通貨、レート、手数料、約定日・価値日の管理。
  • 周辺連携:顧客、勘定系、会計、照合、レポートとの接続。
  • 監査証跡:操作、電文、審査、承認者、時刻の記録。
  • AML/CFT対応:取引保留、誤検知の確認、承認・拒否と根拠の記録。

金融庁は2026年7月にも、金融犯罪対策の取組と課題を公表しました。

判定の精度に加えて、対策態勢の有効性も継続して検証する必要があります(出典: 金融庁「金融機関におけるマネロン・テロ資金供与・拡散金融対策」、2026年)。

要件の中心となるISO 20022と接続先

画面仕様と並行して、データ形式と接続仕様も早い段階で固めておく必要があります。

  • SWIFT:対象金融機関間の支払指図はISO 20022が前提となる。
  • 国内決済:日銀ネット接続と外国為替円決済の電文の確認。

SWIFTでは2025年11月22日にMTとの共存期間が終了しました(出典: Swift「ISO 20022: A new era for global payments」、2025年)。

日本銀行は、2015年から外国為替円決済などでISO 20022を採用し、2025年11月に改訂しました(出典: 日本銀行「日銀ネット等におけるISO20022に関する取り組み」、2026年確認)。

古いMT電文の変換では、住所や送金人・受取人の情報が欠ける可能性があります。そのため、受付画面やERPから構造化データを集める設計が必要です。

定期的な改訂に備えて、バージョンや変換ルールの差分、接続先ごとのテストデータも保守しておきます。

ポイント

まず、事業会社向け、外為事務、決済・中継基盤のどれに当たるかを決めると、必要な機能と接続先の範囲を絞り込めます。範囲が広がるほど、接続や統制の要件も増えます。

外国為替システム開発の進め方・流れ

現状調査と要件定義、PoCと方式設計、開発・総合テスト・段階リリースへ進む工程図
難所を先に検証してから、対象を区切って導入します。

全体は、現状調査と要件定義から始まり、方式選定、設計・開発、テストを経て、移行と運用改善へ進みます。

一度に全機能を稼働させず、安全に切り出せる業務や通貨から段階的に導入します。接続、審査、照合の実績を積み上げながら進めるのが現実的です。

1. 現状調査と要件定義で決める業務の境界

要件定義では、業務量と処理範囲、接続条件、障害時の要件を明らかにします。ここを決めておくと、見積もりを具体化できます。

  • 業務範囲:個人・法人、国・通貨、国内外拠点、仕向・被仕向、通常・例外の区分。
  • 処理量:月間件数、ピーク時間、1件あたりの金額、締切の整理。
  • 接続先:銀行、コルレス銀行、社内外システムの洗い出し。
  • 障害要件:RTO・RPO、稼働時間、同時接続数、ログ保存期間を決める。

特に、「送金受付だけ」にするか、審査・決済・会計まで含めるかは、早い段階で決めておく必要があります。

SWIFT MX、銀行XML・API・ファイル、日銀ネットなどの仕様を確認します。接続先ごとに、必須項目、文字種、桁数を整理します。時刻やエラーコード、再送方法も、同じ単位で決めておきます。

勘定系や顧客情報、会計との連携を確認します。

レートと制裁リストも、接続の確認対象に入れます。

ISO 20022は情報量が増えるため、画面で足りない項目を後から補うと、不備が増えます。

障害時の業務継続手順や権限の分離も要件に含めます。障害から30分以内に受付再開といった達成条件まで書くと見積もりが具体的になります。未送信、送信済み、送信結果不明を区別できる条件も定義します。

2. PoCと方式設計による難所の先行検証

標準機能と独自要件を見比べて、方式と先行検証の範囲を決めます。

  • 標準業務が中心:パッケージや共同利用クラウドの検討。
  • 独自性が重要:差別化部分の個別開発案の検討。
  • 混在する要件:既存基盤と個別機能の組み合わせ。

比較の対象には、SaaS、スクラッチ、既存基盤とのハイブリッドも含めます。

独自のレートや手数料、複雑な承認、勘定系との統合が競争力に関わる場合は、個別開発が適しています。

本開発の前に、ISO 20022変換、AML・制裁判定、API認証をPoCで試します。重複防止や障害時の再送も、同じPoCで確かめます。必須項目の欠落や同じ取引IDの再送、タイムアウト後の照会も、検証の対象です。

制裁リストの誤検知や為替レートの更新失敗など、異常系も試します。

外部サービスの判定結果に加えて、保留・確認・拒否・再審査の記録も確かめます。

同じ依頼の二重決済を防ぐため、取引IDとメッセージIDを分け、冪等性を確保します。

取引の状態は、受付済み、審査中、承認済みに分けます。

送信後は、送信済みと結果受信済みに加えて、結果不明、組戻し中などの状態も設けます。

送信結果が不明なまま即時に再送すると二重送金につながるため、照会と突合を先に行います。そのうえで、担当者の承認を経てから再処理する設計が必要です。

3. 開発・総合テスト・段階リリース

開発から移行、運用準備までを、一連のリリース工程として進めます。

  • 設計・開発:取引データの正規化と状態遷移を先に固める。
  • テスト:正常系に加えて、障害・例外系も接続先を含めて確認する。
  • 移行:リハーサル後の件数、金額、残高の照合。
  • 段階リリース:対象範囲と切り戻し条件を明確にする。

実装する機能は、画面やワークフロー、連携、電文などの単位に分けます。レートやAML、会計、照合、監視も、同じように分けて管理します。

電文バージョンや銀行別マッピングを設定として管理しておくと、制度改定の影響を抑えられます。

単体と結合、総合、性能の各テストに加えて、セキュリティや復旧、接続先も確認します。業務面では、休日や締切、レート未取得、残高不足を想定します。

さらに、名義不一致や制裁判定、電文拒否、切断に加えて、重複受信や組戻し、手動補正も試します。為替レートの更新失敗も、テストケースに含めます。

テストでは、平均処理量に加えて、給与日や市場変動時のピークと監視通知の集中も確認します。

移行の対象は、顧客情報や送金先、手数料のほか、未完了取引と監査ログです。切替の前に、少なくとも1回リハーサルを行います。

移行は、通貨や顧客区分、支店、チャネルで範囲を区切って進めます。そのうえで、旧システムとの並行稼働期間と切り戻し条件も明確にします。

2026年は、SwiftのSR 2026試験や11月のMT 101対応、admi.024受信義務化が見込まれます(出典: Swift「Call-to-action for November 2026」、2026年)。

保守契約、回帰テスト、接続先との試験窓口も、運用計画に含めます。

ポイント

要件定義で業務の境界を決め、PoCで難所を確かめたうえで、一部の業務や通貨から段階的に導入できるかが、進め方の目安になります。

外国為替システム開発の費用相場とコストの内訳

見積もりの費用を開発費、接続費、継続費の3区分に整理した図
初期開発から稼働後まで、費用の範囲を分けて確認できます。

外国為替システム単体の公開価格は限られるため、ここに示す金額は、2026年時点の相場や人月、公開事例から推定した目安です。

金額は、取扱通貨や月間件数、接続先数によって左右されます。既存環境や可用性、監査・規制の範囲も、金額を動かす要因です。見積もりに含まれる作業を確かめたうえで、金額を比べてください。

開発スコープ別の費用目安

対象範囲ごとの推定費用は、次のように幅があります。

  • 法人向け受付・承認:1,000万〜4,000万円程度。
  • 外為事務パッケージ等:2,000万〜1億円程度。
  • SWIFT中継基盤刷新:5,000万〜3億円程度。
  • 銀行外為基盤更改:1億〜10億円程度。
  • 複数国の全面刷新:5億〜30億円超。

法人向け受付・承認の金額は、受付・承認・銀行API連携を既存基盤へ追加する場合の目安です。前提は、1〜2行との接続、顧客・会計基盤の再利用、制裁判定サービスとの連携です。画面数や権限、ERP側の改修が増えると、費用は上振れします。

パッケージや共同利用クラウドの金額は、初期設定、移行、勘定系・SWIFT連携、運用設計までを含む目安です。

中継基盤刷新では、MT/MX変換や複数連携、STPを想定します。さらに、照合、例外処理、総合テストも含めます。

銀行基盤更改には、日銀ネットや勘定系、AML、BCPが含まれます。監査や接続試験、段階移行も、同じ範囲に入ります。複数国・複数通貨のフルスクラッチや基幹決済刷新は、5億〜30億円を超える場合があります。

いずれも、個別要件から算出した推定レンジです。

開発費・接続費・継続費の内訳

見積もりは、初期開発に加えて外部接続と稼働後の費用を分けて比べます。

  • 開発費:企画、要件定義、設計、実装、移行、テスト、管理。
  • 接続費:SWIFT、API、レート、制裁情報、専用線、証明書、HSM。
  • 継続費:クラウド、データ、24時間監視、診断、保守、改定、緊急対応。

開発費の設計項目には、基本設計と詳細設計が含まれます。一般的な人月単価は60万〜200万円程度です(出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月)。

外為の開発では、金融業務、決済、セキュリティ、接続先に詳しい人材が必要になります。

要件定義や総合テストを削ると、かえって障害対応や手戻りの費用が増えます。そのため、工程ごとの工数で比べ、接続や運用に伴う初期設定と利用料も含めて考えます。

年次保守は初期開発費の15〜20%、要件未確定や移行の予備費は20〜30%を、仮の見積もりとして置けます。この予備費は、稟議後の費用不足を抑えるための目安です。

公開事例から見る費用の考え方

公開事例は、金額が非公開でも、必要な機能と費用の範囲を考える材料になります。

  • AnserBizForex:共同利用型サービスでのISO 20022対応。
  • CrossMeetz:受付から決済電文までをSTPで連携。

NTTデータは、共同利用型インターネットバンキングのAnserBizForexで、2025年1月からISO 20022対応を提供しました。2025年10月までに、利用中の金融機関への対応を進めました(出典: NTTデータ「AnserBizForexにてISO20022対応を実施」、2025年)。

共同利用型は標準化の効果を活かせる一方で、顧客ごとの接続・移行・設定が費用になります。

日鉄ソリューションズは、ソニー銀行の個人向け海外送金業務で、2025年10月にCrossMeetzを本番稼働させました。受付、ワークフロー、決済電文の生成・発信をSTPでつなぎ、ISO 20022に対応しました(出典: 日鉄ソリューションズ「ソニー銀行の個人向け海外送金業務にCrossMeetzを導入」、2025年12月)。

接続数や既存基盤、テスト範囲に照らして、連携や移行、運用も予算に含めます。

ポイント

費用は対象範囲によって大きく変わるため、開発費・接続費・継続費を分けて、同じ範囲どうしで比べられるかが目安になります。公開事例は、費用の範囲を考える材料として使えます。

外国為替システムの見積もりを取る際のポイント

見積もりの妥当性を判断するため、同じ前提のRFPを用意し、複数社から工程別・役割別の見積もりを取ります。「システム一式」という金額では、含まれる作業の中身が見えないためです。

RFPに書く業務・電文・接続の前提

RFPでは、業務量と接続、非機能要件、例外処理を具体的に示します。

  • 業務・量:送金、受取、外貨預金、通貨、国、件数、締切、権限。
  • 接続・電文:SWIFT、日銀ネット、API、ERP、ISO 20022、MT。
  • 非機能:24時間運用、可用性、RTO・RPO、ピーク性能、認証、ログ。
  • 例外処理:再送、組戻し、結果不明、手動補正、照合差異。

SWIFTや銀行ごとの形式、変換の責任、欠損時の補完方法も明記します。監視やバックアップ、災害対策、記録項目と保存期間も、要件に含めます。記録の条件が曖昧だと、監査対応の追加開発が発生する可能性があります。

金融機関は、基幹インフラ制度への該当性と手続きも確認します。たとえば、指定事業者が特定重要設備の導入や重要維持管理を委託する際には、事前届出と審査が必要です(出典: 金融庁「基幹インフラ制度に関する相談窓口」、2026年確認)。

対象範囲は事業者と設備によって異なります。そのため、法務やコンプライアンス、情報セキュリティ、調達の担当も検討に加えます。

5年TCOと責任分界による比較

初期金額に加えて、工程、利用料、運用責任を5年間で比べます。

  • 工程別費用:要件定義、開発、テスト、移行、教育、運用設計。
  • サービス費用:初期費用と月額・年額を分けた5年TCO。
  • 責任分界:判定、再送、復旧、制度改定を担う主体。

パッケージやクラウドは、標準機能、追加設定、個別開発、更新の制約に分けて比べます。SWIFTや銀行API、制裁サービス、レート、クラウドの費用も含めます。

電文確認や制裁判定、結果取得の担当を明確にします。二重送金の防止と障害連絡の担当も、決めておきます。

再送の判断やデータ復旧、外部停止時の代替運用、証明書の期限も確認します。接続先や再委託先の仕様変更を誰が扱うかも、あらかじめ質問します。

障害時の判断時間と記録方法まで答えられる提案であれば、安全な運用につながります。

開発と並行して決める契約と運用体制

契約方式、発注側の体制、保守条件は、開発と並行して決めます。

  • 請負契約:成果物と納期を決めやすい一方、変更は追加費用になり得る。
  • 準委任契約:不確実性に対応しやすく、優先順位と受入基準の管理が鍵になる。
  • 工程別契約:調査・要件定義と、開発・移行とで方式を使い分ける。

発注側では責任者を置き、外為事務、コンプライアンス、経理、情シス、運用が横断して判断します。業務側に任せきりだと電文や非機能要件が、IT側に任せきりだと例外や審査判断が抜けやすいため、この横断が欠かせません。

受入テストでは、自社の休日や締切、承認、障害、組戻しを含む業務シナリオを用意します。

保守契約では、受付時間や重大度別の一次回答と復旧目標、制度改定の対応範囲、脆弱性修正を定めます。

電文の更新やテスト環境、データ復旧、再委託先の変更については、通知の条件も盛り込みます。

運用開始後は、未処理や差戻し、手動補正、照合差異を月次で確認します。誤検知や再送も、同じ月次の確認に含めます。開発時の想定と実績の差を見て、運用を改善します。

ポイント

同じ前提のRFPに対して、工程別の見積もりと5年TCOの内訳、契約と運用の責任の分け方を示せるかが、比べるうえでの目安になります。

外国為替システム開発でよくある質問

よくある質問には、送金システムとの違い、クラウド利用、期間や費用などがあります。企画段階で判断しやすいよう、各質問に回答します。

外国為替システムと外国送金システムは何が違いますか?

両者は処理範囲が異なるため、対象となる機能を比べて確認します。

  • 外国送金システム:海外送金の依頼と送金結果の処理が中心です。
  • 外国為替システム:外貨預金、為替予約、信用状、銀行間決済も含みます。
  • 対象範囲:レート、手数料、AML/CFT、SWIFT、日銀ネット、勘定系、会計も含み得ます。

必要な範囲を定義しておけば、過剰な基幹刷新を避けられます。

外国為替システムをクラウドで開発できますか?

クラウドでの開発は可能です。ただし、採用の可否は、金融データの管理条件と運用範囲で判断します。

  • 採用条件:データ所在、暗号化、冗長化、接続方式の確認。
  • 運用条件:障害時の責任分界、再委託先、監査説明の整理。
  • 構成案:共同利用クラウドに標準事務を置き、顧客画面やERPをAPI連携する形。
  • 銀行基幹:関連制度と社内基準を確認してから採用。

開発期間はどのくらいかかりますか?

期間の目安は、対象範囲によって4〜36か月以上まで異なります。

  • 法人向け受付・承認・銀行API追加開発:4〜9か月。
  • パッケージ・共同利用クラウド:6〜15か月。
  • 中継基盤刷新:9〜24か月。
  • 銀行外為基盤更改:18〜36か月以上。

銀行基盤更改の期間は、日銀ネットや勘定系、AML、BCPに加えて、複数拠点や段階移行を含む場合の目安です。

接続先の試験や移行リハーサル、並行稼働を短くしすぎると、本番のリスクが高まります。

最初に何を準備して開発会社へ相談すればよいですか?

初回相談に向けて、現状と依頼条件を次の3つの観点でまとめます。

  • 業務情報:対象業務、利用者、通貨、国、件数、締切、接続先のまとめ。
  • 既存環境:既存システム、業務フロー、例外、監査・セキュリティ要件。
  • 相談・比較:将来の接続先を示したうえで、複数社の費用、期間、保守、責任を比べる。

完成した要件定義書がなくても、現状の業務や困っている例外、将来の接続先が分かれば相談できます。同じ資料をもとに複数社を比べると、工程別の費用や期間、前提、保守、制度改定の責任分界がそろって見えます。見積もりの精度も上がります。

まとめ

最初に、事業会社向けの受付、金融機関の外為事務、中継基盤のどこまでを作るかを決めます。そのうえで、業務やISO 20022と銀行電文、接続、監査証跡、障害復旧を一体で要件に含めます。

安全に決済を完了し、再現できる状態

完成の条件は、画面が動くことに加えて、取引状態を追跡し、結果不明のときも二重送金を防げることです。制裁判定や承認の根拠を説明でき、障害から復旧できる状態も必要です。

PoCでは、先にISO 20022変換やAML・制裁判定を検証し、冪等性や再送、組戻しも確かめます。

範囲を定めたRFPと複数社比較

次の費用幅と総保有コストを踏まえて、提案を比べます。

  • 受付・API連携:1,000万〜4,000万円程度です。
  • 銀行基盤更改:1億〜10億円程度です。
  • 複数国の全面刷新:5億〜30億円超となる場合があります。
  • 5年TCO:接続料、データ、クラウド、保守、改定、監査、移行、予備費を含めます。

業務フローと接続先を整理したうえで、工程別の費用と責任分界を示せる開発会社へ相談します。

▼全体ガイドの記事
・外国為替システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。