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

外国為替システム開発は、送金画面を作るだけではなく、受付から本人確認、レート・手数料計算、制裁チェック、決済電文、会計、照合、障害復旧までを安全に一つの業務フローとして設計することが基本です。

銀行や資金移動業者の企画担当者、海外取引の多い企業の情シス・経理担当者に向けて、外国為替システムの全体像、開発の進め方、2026年時点の費用相場、見積もりで確認すべきポイントを解説します。SWIFT、ISO 20022、日銀ネット、AML/CFTなど、後から変更しにくい論点も開発初期から整理します。

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

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

外国為替システムとは、円・米ドル・ユーロなどの通貨をまたぐ取引を、業務ルールと決済ネットワークに沿って処理するシステムです。ただし、個人・法人向けの海外送金受付から、銀行の外為事務、SWIFT接続、日銀ネット接続、勘定系・市場系まで、対象範囲には大きな違いがあります。最初に対象利用者と処理範囲を切り分けることが、正しい見積もりと開発計画につながります。

1つ目は、事業会社が利用する海外送金依頼・承認システムです。ERPや会計システムから支払データを取り込み、複数人の承認、送金先・目的の確認、銀行APIやファイル連携、送金状況の照会、会計消込までを効率化します。既存の銀行口座や会計基盤を活用できる場合は、画面と連携機能を中心に追加開発できます。

2つ目は、銀行・信用金庫・資金移動業者などの外為事務システムです。仕向送金、被仕向送金、外貨預金振替、為替予約、信用状などを受付から審査、承認、決済、会計、顧客通知まで処理します。3つ目は、SWIFTや日銀ネット、勘定系、AML基盤などをつなぐ決済・中継基盤です。後者ほど接続試験、可用性、監査証跡、BCPの要件が増え、開発規模も大きくなります。

必要な機能は、送金依頼・受取依頼の受付、本人確認、承認ワークフロー、通貨・レート・手数料・適用レート・約定日・価値日の管理です。加えて、顧客情報、勘定系、会計、手数料計算、照合、レポートとの連携も必要です。業務担当者が手動で修正した内容や差し戻しの理由を後から説明できるように、操作履歴、電文履歴、審査結果、承認者、時刻を監査証跡として残します。

特に重要なのは、AML/CFTや制裁リストのチェックを単なる外部API呼び出しで終わらせないことです。ヒットした取引を保留し、誤検知を担当者が確認し、承認または拒否し、その根拠を記録するまでを業務フローとして設計します。金融庁は2026年7月にも金融犯罪対策の取組と課題を公表しており、判定精度だけでなく態勢の有効性を継続的に検証する考え方が重要です（出典: 金融庁「金融機関におけるマネロン・テロ資金供与・拡散金融対策」、2026年）。

外国為替システムでは、画面仕様よりもデータと接続の仕様が成否を左右します。SWIFTのクロスボーダー決済では、2025年11月22日にMTとISO 20022の共存期間が終了し、対象となる金融機関間の支払指図はISO 20022を前提に処理されます（出典: Swift「ISO 20022: A new era for global payments」、2025年）。古いMT電文を変換するだけでは、住所や送金人・受取人の情報が欠落する可能性があるため、受付画面やERPから構造化データを収集する必要があります。

国内の決済では日銀ネットとの接続や、外国為替円決済に関する電文も確認します。日本銀行は2015年から外国為替円決済などでISO 20022電文を採用し、2025年11月には国際的なガイドラインに沿った改訂を実施しています。今後も電文が定期的に改訂される可能性があるため、バージョン管理、変換ルールの差分管理、接続先ごとのテストデータを保守対象として設計します（出典: 日本銀行「日銀ネット等におけるISO20022に関する取り組み」、2026年確認）。

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

外国為替システム開発は、現状調査、要件定義、方式選定、設計・開発、テスト、移行、運用改善の順で進めます。最初から全機能を一括稼働させるのではなく、送金受付や特定通貨など安全に切り出せる範囲から段階導入し、接続・審査・照合の実績を積み上げる方法が現実的です。

最初に、誰がどの国へ、どの通貨で、どのチャネルから送金するのかを整理します。対象業務を個人・法人、仕向・被仕向、国内拠点・海外拠点、通常処理・例外処理に分け、月間件数、ピーク時間、1件あたりの金額、処理締切、取引先銀行、コルレス銀行を一覧化します。ここで「顧客向け送金受付だけ」なのか「銀行内部の審査・決済・会計まで」なのかを決めることが重要です。

次に、接続先とデータ項目を洗い出します。SWIFTのMX、銀行ごとのXML・API・ファイル、日銀ネット、勘定系、顧客情報、会計、為替レート、制裁リストの各インターフェースについて、必須項目、文字種、桁数、時刻、エラーコード、再送方法を確認します。ISO 20022では情報量が増えるため、画面で入力できない項目を後工程で補う設計にすると、手動修正と不備返却が増えやすくなります。

要件定義書には、機能要件だけでなく、RTO・RPO、稼働時間、同時接続数、監査ログの保存期間、権限分離、障害時の業務継続手順も書きます。たとえば「送金依頼を受付できること」ではなく、「障害から30分以内に受付を再開し、未送信・送信済み・送信結果不明を区別できること」まで定義すると、テストと見積もりが具体化します。

方式選定では、パッケージ、共同利用クラウド、SaaS、スクラッチ、既存基盤とのハイブリッドを比較します。標準的な送金ワークフロー、電文生成、SWIFT接続、STP機能を活用できるならパッケージやクラウドが候補です。一方、独自のレート・手数料、海外拠点の複雑な承認、既存勘定系との細かな統合が競争力に直結するなら、差別化部分だけを個別開発する設計が適しています。

本開発の前に、ISO 20022の変換、AML・制裁判定、銀行APIの認証、メッセージの重複防止、障害時の再送を小さなPoCで確認します。PoCでは正常系だけでなく、必須項目の欠落、同じ取引IDの再送、タイムアウト後の結果照会、制裁リストの誤検知、為替レートの更新失敗を試します。外部サービスが「判定結果を返す」ことと、自社業務が「保留・確認・拒否・再審査を記録できる」ことは別なので、両方を検証します。

取引データには、業務上の取引IDとメッセージIDを分けて持たせ、同じ依頼が二度決済されない冪等性を確保します。処理状態も「受付済み」「審査中」「承認済み」「送信済み」「結果受信済み」「送信結果不明」「組戻し中」などに分けます。特に送信結果不明をエラー扱いで即時再送すると二重送金につながるため、相手先への照会、受信電文との突合、担当者の承認を経て再処理する設計が必要です。

設計・開発では、業務画面、ワークフロー、API・ファイル連携、電文変換、レート・手数料、AML・制裁チェック、会計仕訳、照合、監視を分けて実装します。基幹系との連携がある場合は、画面を先に完成させるのではなく、取引データの正規化と状態遷移を先に固めます。仕様変更に備えて、電文バージョンや銀行ごとのマッピングを設定値として管理できる構造にすると、制度改定時の影響を抑えられます。

テストは、単体・結合・総合・性能・セキュリティ・障害復旧・接続先試験に分けます。正常な送金だけでなく、休日・締切時刻、レート未取得、口座残高不足、名義不一致、制裁判定ヒット、電文拒否、ネットワーク切断、同一依頼の再受信、組戻し、手動補正をケース化します。月間件数の平均値だけで性能を測らず、給与振込日や市場変動時のピーク件数、監視通知の集中も含めて確認します。

移行では、過去の顧客情報、送金先、手数料設定、未完了取引、監査ログを対象に、移行ルールと照合方法を決めます。本番切替前に少なくとも1回はリハーサルを行い、移行後の件数・金額・残高・未処理件数が一致することを確認します。段階リリースでは通貨、顧客区分、支店、チャネルなどで範囲を区切り、旧システムとの並行稼働期間と切り戻し条件を明文化します。

2026年は、SwiftのSR 2026試験や11月のMT 101対応、admi.024の受信義務化など、稼働後の標準改訂も見込まれます（出典: Swift「Call-to-action for November 2026」、2026年）。リリース日をゴールにせず、電文改訂を取り込む保守契約、回帰テスト、接続先との試験窓口までを運用計画に含めます。

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

外国為替システム単独の公開価格は限られるため、以下は2026年時点の一般的なシステム開発相場、金融システムの人月、公開事例のスコープから作った目安です。実際の金額は、取扱通貨、月間処理件数、接続先数、既存システムの状態、可用性、監査・規制対応の範囲で大きく変わります。金額だけを比較せず、何を含む見積もりかを確認してください。

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

外為事務パッケージや共同利用クラウドを導入し、初期設定、データ移行、勘定系・SWIFT連携、運用設計まで含める場合は、2,000万〜1億円程度が目安です。SWIFT・ISO 20022の中継基盤を刷新し、MT/MX変換、複数システム連携、STP、照合、例外処理、総合テストまで行う場合は、5,000万〜3億円程度を見込みます。

銀行の外為基盤更改で、日銀ネット、勘定系、AML、BCP、監査、接続試験、段階移行まで含める場合は、1億〜10億円程度が目安になります。複数国・複数通貨のフルスクラッチや基幹決済刷新では、5億〜30億円を超えるケースもあります。これらは公開された一律料金ではなく、個別要件から算出する推定レンジです。

開発費には、企画・要件定義、基本設計、詳細設計、実装、移行、テスト、プロジェクト管理が含まれます。一般的なシステム開発の人月単価は60万〜200万円程度とされますが、外国為替では金融業務、決済、セキュリティ、接続先の知識を持つ人材が必要です（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。要件定義や総合テストの人月を削ると、後から障害対応や手戻りでコストが増えるため、工程ごとの工数で比較します。

接続費には、SWIFTや銀行API、為替レート、制裁リスト、専用線、証明書、HSM、クラウド、バックアップ、監視の初期設定と利用料が含まれます。継続費には、クラウド・ライセンス、データ利用料、24時間監視、脆弱性診断、保守、制度改定、障害時の緊急対応が含まれます。外為システムでは、初期開発費の15〜20％程度を年次保守の仮置きにし、要件未確定や移行には20〜30％程度の予備費を置くと、稟議後の不足を抑えやすくなります。

公開事例は金額を示していないことが多いものの、費用の範囲を推定する材料になります。たとえばNTTデータは、共同利用型インターネットバンキングサービスAnserBizForexで2025年1月からISO 20022対応を提供し、2025年10月までに利用中の金融機関への対応を進めました（出典: NTTデータ「AnserBizForexにてISO20022対応を実施」、2025年）。共同利用型は標準化の効果を活かせる一方、顧客ごとの接続・移行・設定が費用になります。

日鉄ソリューションズは、ソニー銀行の個人向け海外送金業務で、2025年10月にCrossMeetzを本番稼働させました。顧客受付、ワークフロー、決済電文の生成・発信をSTPでつなぎ、ISO 20022に対応した事例です（出典: 日鉄ソリューションズ「ソニー銀行の個人向け海外送金業務にCrossMeetzを導入」、2025年12月）。このような事例と自社の接続数、既存基盤、テスト範囲を照合して、単純な画面開発ではなく連携・移行・運用を含めて予算化します。

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

外国為替システムの見積もりは、「システム一式」の金額だけでは妥当性を判断できません。業務範囲、接続先、データ項目、非機能要件、テスト、移行、保守を同じ前提で比較できるRFPを作り、複数社から工程別・役割別の見積もりを取得します。

RFPには、対象となる送金・受取・外貨預金・為替予約などの業務、利用者区分、通貨、国、月間件数、ピーク件数、処理締切、承認権限を記載します。次に、SWIFT、日銀ネット、銀行API、XML・ファイル、ERP、勘定系、AML・制裁リスト、レート配信の接続先を一覧化します。ISO 20022の対象メッセージ、現在のMTや独自フォーマット、変換責任、欠損時の補完方法も明記します。

非機能要件では、24時間運用の有無、可用性、RTO・RPO、ピーク性能、暗号化、認証、権限分離、ログ保存、監視、バックアップ、災害対策を定義します。取引の再送や組戻し、送信結果不明、手動補正、照合差異のような例外処理も、正常系と同じ重要度で書いてください。記録すべき項目と保存期間が曖昧なままだと、後から監査対応の追加開発が発生します。

金融機関に該当する場合は、基幹インフラ制度の確認も必要です。金融庁は、指定された特定社会基盤事業者が特定重要設備の導入や重要維持管理を委託する際、事前届出と審査を求める制度を案内しています。対象範囲や手続きは事業者と設備の実態で変わるため、法務・コンプライアンス・情報セキュリティ・調達部門をRFP段階から参加させます（出典: 金融庁「基幹インフラ制度に関する相談窓口」、2026年確認）。

提案書を比較するときは、要件定義、設計、開発、テスト、移行、教育、運用設計を工程別に並べます。パッケージやクラウドの場合は、標準機能、追加設定、個別開発、バージョンアップ時の制約を分けます。SWIFTや銀行API、AML・制裁サービス、為替レート、クラウドの利用料は、初期費用と月額・年額を分けて5年間の総保有コストで比較します。

責任分界では、電文の妥当性確認、制裁判定、送信結果の取得、二重送金防止、障害時の連絡、再送判断、データ復旧、制度改定対応を誰が担うかを確認します。外部サービスが停止したときの代替運用、証明書の期限切れ、接続先の仕様変更、再委託先の変更も質問します。最安の提案ではなく、障害時に誰が何分以内に判断し、どの記録を残すかまで答えられる提案を選ぶことが安全性につながります。

請負契約は成果物と納期を合意しやすい一方、要件変更が多い初期段階では追加費用が発生しやすくなります。準委任契約は業務や技術の不確実性に対応しやすい一方、発注側が優先順位と受入基準を管理する必要があります。現状調査・要件定義は準委任、仕様を固めた開発や移行は請負など、工程ごとに契約の特徴を使い分ける方法もあります。

発注側には、業務部門とIT部門をつなぐプロジェクト責任者が必要です。業務担当者だけでは電文や非機能要件が抜け、IT担当者だけでは例外処理や審査判断が抜けるため、外為事務、コンプライアンス、経理、情シス、運用を横断した意思決定体制を作ります。受入テストではベンダーが作った正常系ケースを受け取るだけでなく、自社の休日、締切、承認、障害、組戻しを含む業務シナリオを発注側で用意します。

保守契約には、障害対応の受付時間、重大度別の一次回答・復旧目標、制度改定の対応範囲、電文バージョンアップ、脆弱性修正、テスト環境、データ復旧、再委託先の変更通知を盛り込みます。運用開始後も月次で未処理、差戻し、手動補正、照合差異、制裁判定の誤検知、再送件数を確認し、開発時の想定と実績の差を改善します。

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

外国為替システムの相談では、「外国送金システムとの違い」「クラウド利用の可否」「開発期間と費用」に関する質問が多くなります。ここでは、企画段階で判断しやすいように、結論を先に回答します。

外国送金システムは、海外への送金依頼や送金結果の処理に焦点を当てたシステムです。外国為替システムは、送金に加えて外貨預金、為替予約、信用状、銀行間決済、レート・手数料、AML/CFT、SWIFT・日銀ネット、勘定系・会計まで含む広い概念です。自社が必要とする範囲を先に定義すると、過剰な基幹刷新を避けられます。

クラウドで開発できますが、利用できるかどうかはクラウドという名前ではなく、データ所在、暗号化、冗長化、接続方式、障害時の責任分界、再委託先、監査への説明可能性で判断します。外為事務の標準機能を共同利用クラウドで使い、独自の顧客画面やERP連携をAPIで追加する構成は候補になります。銀行の基幹決済に関わる場合は、基幹インフラ制度や社内のクラウド利用基準を確認してから採用します。

法人向け送金受付・承認・銀行API連携の追加開発なら4〜9か月、外為事務パッケージや共同利用クラウドの導入なら6〜15か月、SWIFT・ISO 20022対応の中継基盤刷新なら9〜24か月が目安です。日銀ネット、勘定系、AML、BCP、複数拠点、段階移行を含む銀行の外為基盤更改では18〜36か月以上を見込みます。接続先の試験日程、移行リハーサル、並行稼働を短縮しすぎると、本番後のリスクが高くなります。

まず、対象業務、利用者、通貨、国、月間件数、接続先、既存システム、処理締切、監査・セキュリティ要件を一枚に整理します。完成した要件定義書がなくても、現状の業務フロー、困っている例外処理、将来増やしたい接続先が分かれば、初期相談は可能です。複数社に同じ資料を渡し、工程別の費用、期間、前提条件、保守・制度改定の責任分界を比較すると、見積もりの精度を高められます。

まとめ

外国為替システム開発では、最初に事業会社向け送金受付、金融機関の外為事務、決済・中継基盤のどこまでを対象にするかを決めます。そのうえで、業務フロー、ISO 20022や銀行ごとの電文、SWIFT・日銀ネット・勘定系・AMLとの接続、監査証跡、障害復旧を一つの要件として整理します。

重要なのは、画面を予定どおり完成させることだけではありません。受付した取引がどの状態にあるかを追跡でき、送信結果が不明なときに二重送金を防ぎ、制裁判定や承認の根拠を後から説明でき、障害から安全に復旧できることが本当の完成条件です。PoCではISO 20022変換、AML・制裁判定、冪等性、再送・組戻しを先に検証します。

費用は、受付・API連携の1,000万〜4,000万円程度から、銀行の外為基盤更改の1億〜10億円程度、複数国の全面刷新の5億〜30億円超まで幅があります。初期費用だけでなく、接続料、データ利用料、クラウド、保守、制度改定、監査、移行、予備費を含めた5年TCOで比較してください。まずは自社の業務フローと接続先を整理し、工程別見積もりと責任分界を提示できる開発会社へ相談することが、実現可能な計画への近道です。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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