外国為替システムは決済の正確性と監査可能性を支える仕組みで、送金受付・外為事務・決済基盤に分けて考えると整理しやすくなります。
扱う業務の範囲によって、必要な機能や運用、開発の難易度は大きく変わります。対象範囲を先に決めると、種類・進め方・費用の見方がそろいます。
▼関連記事一覧
・外国為替システム開発の進め方
・外国為替システム開発でおすすめの開発会社6選と選び方
・外国為替システム開発の見積相場・費用
・外国為替システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
外国為替システムの概要
外国為替システムは、円・米ドル・ユーロなどの通貨をまたぐ取引を受け付け、審査・決済・記録するシステムです。対象の範囲によって難易度は大きく変わるため、最初に利用者・業務・接続先を区切っておくことが大切です。
3つの業務範囲による分け方
業務範囲は、利用者と処理する取引、接続先で整理できます。顧客向けの受付や企業向けの業務では、利用者や接続先に応じて必要な機能を整理します。担う業務も必要な運用も異なるため、3つの範囲に分けて考えます。
- 送金受付：顧客からの依頼を受け、銀行へ送る役割を担います。
- 外為事務：金融機関の外国為替取引を事務面から処理する。
- 決済基盤：銀行間電文や決済網をつなぐ基盤。
送金受付では、送金先や通貨、金額、依頼人情報を入力し、承認を経て銀行APIやファイル連携で送信します。なお、既存の顧客管理や会計、ERPを使える場合は、受付の範囲を限定できます。
外為事務では、仕向・被仕向送金や外貨預金振替、為替予約を扱います。さらに、貿易書類や勘定系仕訳、手数料計算まで含みます。照合や差戻しも、外為事務の業務です。
決済基盤では、SWIFTのISO 20022電文や国内決済網、コルレス銀行、監視基盤をつなぎます。そのうえで、24時間運用と障害復旧も設計します。
画面開発だけでは完結しない理由
取引の実態を正しく把握するには、画面に出る表示とは別に、送金の状態と記録を分けて管理する必要があります。
- 送金状況：銀行の受信、相手先の受付、着金、手動照会を区別して把握する。
- 追跡記録：取引ID・メッセージIDや処理状態、更新者、更新時刻の保存。
送信結果と各状態を分けておかないと、障害時の再送で二重送金が起こり得ます。そこで、保存した情報から一件ごとの経緯を再現できるようにしておきます。
また、通貨や国によって、必須項目や休日、締め時刻は異なります。手数料や受取人情報の形式も、国や通貨ごとに違います。
BISの「2025 Triennial Central Bank Survey」では、2025年4月の世界の外国為替取引高は1日平均9.6兆ドルでした。これは2022年比で28％の増加です（出典：BIS、2025年）。取引量が大きいため、性能だけでなく、正確性・証跡・規制対応も同時に満たす設計が必要です。
外国為替システムの種類と主要機能
種類は、利用者や機能名だけでなく、取引の責任範囲で分けて捉えます。受付・審査・決済・会計・照合のうち、どこまでを担うかを先に決めておくと、候補を比べる基準がそろいます。
顧客向け送金受付・企業向け業務システム
顧客・企業向けのシステムでは、受付の方法や業務条件、接続方式、送金後の状態を整理しておく必要があります。
- 受付：個人・法人がWeb画面や専用画面から依頼し、本人確認と権限確認を経て金融機関へ送ります。
- 法人業務：複数人承認、送金限度額、部門別権限、取引先マスタ、請求書照合、ERP仕訳連携が要になります。
- 海外拠点：拠点ごとの通貨・言語・締め時刻を、共通の取引モデルに整理する。
- 接続方式：銀行API、ホスト接続、CSV、SFTPの違いを吸収する役割。
- 状態遷移：送金依頼、承認、送信、受付、着金、取消、返金、照会の流れ。
状態遷移は画面設計の前に定めておくと、結果と着金状況を利用者に分かりやすく伝えられます。
外為事務・決済基盤システム
外為事務と決済基盤は扱う業務が違うため、機能と運用を分けて考えます。
- 外為事務：仕向・被仕向送金、外貨預金、為替予約、貿易金融、手数料、為替レート、価値日、勘定系連携。
- 決済基盤：SWIFTのISO 20022メッセージ、金融機関間接続、国内決済網、制裁審査、監視、バックアップ。
外為事務では、例外の確認や差戻しも多いため、安全に処理できる画面と権限が必要です。
Swiftでは2025年11月22日にクロスボーダー決済のMTとISO 20022の共存期間が終了し、決済指図でISO 20022が標準になりました（出典：Swift、2025年）。ただし、2026年以降も例外・照会やキャンセルの電文対応は続くため、改訂に対応できる構造が必要です。
共通して必要になる主要機能
共通機能は取引の受付から記録までをつなぐため、必要な機能と例外への対策をあわせて設計します。
- 取引管理：依頼、本人確認、承認、送金先の管理。
- 決済処理：通貨・レート・手数料、電文、接続の処理。
- 統制と記録：AML/CFT、会計、照合、通知、監査証跡を担う機能。
冪等性で重複送信を防ぎ、タイムアウト時の再確認や休日・時限の管理、メンテナンス中の受付制御も行います。さらに、送信結果不明や項目不足、制裁判定保留、会計連携失敗を、それぞれ状態として扱います。
取引単位の状態管理と件数・金額・残高の突合を組み合わせると、担当者が異常を見つけやすくなります。
外国為替システム開発の進め方
開発では、取引を安全に完了させ、障害時にも状態と証跡を再現できるようにすることが目標になります。
そのため、現状調査から段階移行までを一つの計画として組み立てます。計画には、業務と法務の担当者を早い段階から加えます。コンプライアンスや情報セキュリティ、運用の担当者も、同じ段階から加わります。
要件定義で決める項目
要件定義では、対象業務を仕向・被仕向と個人・法人で分けたうえで、国内・海外、通常・例外の別も整理します。
業務条件は、取引量と時間、業務ルール、接続先の3つの面から定めます。
- 取引量と時間：通貨、月間・ピーク件数、受付時間、締め時刻、処理期限。
- 業務ルール：承認権限、手数料、レート、帳票、顧客通知。
- 接続先：銀行、SWIFT、日銀ネット、AML・制裁判定、レート配信、顧客管理、勘定系、会計、分析。
電文は、項目と文字種、必須条件を中心に確かめます。桁数やエラーコード、送達確認も対象に含めます。また、未確定の項目は仮置きせず、決定期限と責任者を記録しておきます。
設計・PoC・開発での検証項目
設計では、取引IDとメッセージIDの関係や状態遷移を定めます。冪等性キーや再送・取消のルールも、ここで決めておきます。
ISO 20022への変換で項目が足りない場合は、補完するのか、送信を止めるのか、手動確認に回すのかを決めます。
AML・制裁判定では、ヒットしたときの保留から、誤検知の解除、エスカレーション、記録保存までを設計します。不確実な機能は、本開発の前に小さなPoCで検証します。
- 電文変換や制裁判定、銀行API、性能、障害復旧を検証する。
- 復旧時間、重複防止、ログ追跡、担当者の操作を成功条件とする。
全機能を最初から作り込まず、異常時の確認も先に行うことで、本開発での手戻りを抑えられます。
テスト・移行・リリースの段階
テストは、単体、結合、総合、性能、セキュリティ、接続先試験の段階に分けて実施します。送金の処理に加えて、障害や例外もシナリオに含めます。
- 送金・電文：タイムアウト、電文不備、重複依頼、取消、返金。
- 審査・連携：レート欠損、制裁ヒット、会計連携失敗。
- 受入テスト：現場担当者が実際の手順で処理できるかの確認。
- 運用条件：休日、時限超過。
移行で扱うのは、顧客や取引先、レートの情報です。未決済の取引や過去の証跡も、移行の対象に含まれます。
移行の手順は、抽出から承認までを定めておき、切替前に複数回リハーサルします。
件数や金額、残高、状態などの一致を確認します。重要な業務では、並行稼働や段階リリースを採用し、切戻しの条件と連絡体制もあらかじめ決めておきます。
▶ 詳細はこちら：外国為替システム開発の進め方
外国為替システムの費用相場とコストの内訳
費用は、機能数と接続先、取引量で決まります。さらに、可用性と規制対応に加え、移行対象と保守範囲も費用を左右する要素です。ここに示す金額は、2026年時点の一般的な業務システム相場と、金融・決済案件のスコープをもとにした推定です。
外国為替システム単独の公開価格表は少ないため、予算化の際は、前提をそろえた複数社の見積が必要です。
スコープ別の初期費用と期間の目安
法人向け受付から複数国・複数通貨の刷新まで、スコープ別に初期費用と開発期間を比べます。
- 法人向け受付：1,000万〜4,000万円、4〜9か月。
- パッケージ・共同クラウド：2,000万〜1億円、6〜15か月。
- 中継・メッセージ基盤の刷新：5,000万〜3億円。
- 銀行の外為基盤更改：1億〜10億円。
- 複数国・複数通貨の全面刷新：5億〜30億円超になる可能性。
法人向け受付の目安は、既存の顧客・会計基盤に追加開発する場合を想定しています。その際は、1〜2行と接続し、制裁判定には外部サービスを使う前提です。対象の通貨と業務も絞ります。
パッケージ・共同利用クラウドの金額には、初期設定やデータ移行、勘定系・メッセージ連携、運用設計が含まれます。ただし、月額100万〜500万円程度の利用料が、別途かかる場合があります。
2026年の一般的なシステム開発では、人月単価60万〜200万円程度という公開相場があります（出典：2026年版システム開発費用相場の公開調査、2026年）。
金融に詳しいPMや上級SE、24時間運用の設計者、セキュリティ専門家を含めるほど、単価と工数は上がります。そのため、総額に加えて、役割別の人月も確認します。
初期費用以外に発生するランニングコスト
運用費は、基盤とデータ、外部サービスに保守を加えて把握します。
- 基盤・安全対策：クラウド、専用線、監視、バックアップ、証明書、HSM、脆弱性診断。
- データ・ネットワーク：制裁リスト、為替レート、メッセージ網の利用料。
- 外部サービス：取引量に応じた料金、照会・再判定、障害時の緊急対応。
保守費は、初期開発費の年15〜20％を仮置きする方法があります。ただし、保守費は24時間365日対応を含むかどうかで変わり、制度改定や電文更新、接続先追加を含むかも金額を左右します。
要件が固まっていない部分、データ移行、制度対応には、20〜30％程度の予備費を置くと、稟議後の追加要求に対応しやすくなります。
初期費用だけでなく、3年または5年の総保有コストで比較します。
▶ 詳細はこちら：外国為替システム開発の見積相場・費用
外国為替システムの開発会社・サービスの選び方
会社やサービスは、知名度や価格だけでなく、自社の業務範囲と接続条件への適合性で選びます。顧客向け受付、外為事務、決済中継では、必要な経験が異なります。
RFPには、取引件数と通貨、接続先を明記します。可用性や規制、移行時期も、あわせて書き込みます。
外国為替・決済業務の経験
提案先には、担当経験のある業務を確認します。仕向・被仕向送金や外貨預金、為替予約の業務に加えて、手数料と価値日の扱いも対象です。AML/CFTや照合、会計連携の経験も確かめます。
導入業種や取扱通貨、月間件数については、守秘義務に配慮した範囲で説明を求めます。接続方式や稼働後の保守範囲も、説明を求める項目に入れます。実績は、ロゴや件数に加えて、担った業務の内容で見ます。
障害時の再送や電文不備、制裁ヒットへの対応を尋ねます。移行や制度改定への対応も、確認の対象にします。提案段階では、現場や業務設計、技術、運用の責任者が参加するかも確かめます。
技術・運用・契約の責任分界
技術・運用・契約の条件ごとに、提案各社の責任範囲を照合します。
- 技術：ISO 20022更新、MT変換、API・ファイル・専用線、冗長化、RTO・RPO、監視、ログ、権限。
- 運用：24時間監視、一次切り分け、手動復旧、障害訓練、問い合わせ窓口、保守時間、制度改定時の体制。
- 契約：請負・準委任の範囲、変更単価、データ所有権、ログ保存、再委託、クラウド所在、終了時返却、SLA。
日本銀行は、日銀ネットの外国為替円決済などで2015年からISO 20022電文を採用し、2025年11月に2019年版へ改訂しました。そのうえで、国際ガイドラインの年次改訂を踏まえ、今後の対応を検討する方針です（出典：日本銀行、2026年確認）。
提案書では、電文更新の費用と試験方法を確認します。契約では、ログ保存期間やSLA違反時の扱いも明確にしておきます。
価格・機能・継続性の3つの観点で作る比較表
比較表では、費用と業務への適合性を並べて見ることで、判断の材料をそろえられます。
- 価格：初期・月額費用、5年TCO、移行費。
- 機能：通貨、接続先、標準機能、個別開発、監査証跡。
- 継続性：テスト環境、保守時間、制度改定の費用負担。
不要な機能が増えて複雑になると、運用費や障害リスクが高まる場合があります。また、最終候補には匿名化した実データを使い、送金依頼から照合・会計連携までのデモを依頼して、自社の業務に合うかを確かめます。
正常系の処理だけでなく、制裁保留や送信結果不明の扱いも実演してもらいます。銀行エラーや電文バージョン不一致の扱いも、実演の対象に含めます。
▶ 詳細はこちら：外国為替システム開発でおすすめの開発会社6選と選び方
外国為替システムの発注・外注・委託方法
発注時には、システム仕様と業務・契約上の責任をそろえておきます。そのうえで、社内に外為業務を理解する責任者を置きます。業務・IT・リスク管理の各部門の判断も、一つの意思決定ルートにまとめます。
RFPに入れるべき確認項目
RFPには、業務と利用者、通貨、件数とピークを記載します。処理時限や接続先、電文、API・ファイル方式も盛り込みます。統制や運用の条件も、あわせて明記します。
- 業務・統制：AML/CFT、制裁、承認、会計、照合、監査、ログ。
- 障害・移行：RTO・RPO、再送・取消、移行範囲。
- 拡張：将来の通貨・接続先追加、ISO 20022改訂。
見積では、前提と対象外、工数を分けて示してもらいます。第三者サービスやライセンス費は、別に分けてもらいます。テストと移行、保守、制度改定費も、項目ごとに分けます。
「一式」の見積は、成果物と完了条件を確認します。レビュー回数や受入条件も、あわせて確かめます。
請負・準委任とプロジェクト管理の使い分け
工程の確定度に応じて契約を選び、管理体制と責任者を明確にします。
契約形態を選んだうえで、成果物と意思決定の責任者を明確にしておくことが、安全性を支えます。
- 請負：成果物が固まった設計、開発、テストの工程が候補。
- 準委任：現状調査、要件定義、PoC、移行計画など、検討しながら進める工程。
- 進行管理：課題・リスク・変更・欠陥・意思決定を台帳で追う。
接続先の仕様や法令・ガイドラインの変更、移行データの不備を、早期に検知します。担当者不足や再委託先の遅延も、見落とさないよう追います。
週次会議では、進捗率に加えて、未解決の例外件数を確認します。総合テストの合格率や移行照合の差異も、同じ会議で見ます。
外注時に見落としやすいリスク
外注先に業務知識を任せきりにすると、現場の例外処理や手作業の判断が仕様から抜けることがあります。そこで、業務フローそのものは自社で押さえ、正常系・例外系・障害系を分けて受入条件を作ります。
- 業務確認：自社で例外処理を確かめ、正常・例外・障害系の受入条件を定める。
- 責任分界：複数社間の電文・ID・ログ・監視の担当と、障害時の連絡先。
- 委託先管理：データ所在、権限、暗号鍵、バックアップ、脆弱性、退去時消去、再委託先の変更通知。
基幹インフラ制度では、重要設備の導入や維持管理などの委託が、事前審査の対象となる場合があります。対象かどうかは、事業者と設備の実態で判断されます（出典：経済産業省、2024年以降の制度案内）。
法務・コンプライアンス・情報セキュリティの担当者は、RFPの段階から参加させます。
▶ 詳細はこちら：外国為替システム開発の発注・外注・委託方法
規制・セキュリティ・運用で押さえるべきポイント
外国為替システムは、決済の正確性と金融犯罪対策を両立させる役割を担います。ただし、法令・ガイドラインの範囲は、業態や業務、接続方式によって変わります。
発注側は、一般的な機能一覧を見るだけでなく、自社の法務・リスク管理部門と要件を照らして確認します。
AML/CFT・KYC・制裁スクリーニングの設計
受付から記録保管まで、審査情報と人による確認をつないで設計します。
- 審査情報：本人確認、取引目的、送金人・受取人、制裁照合、取引監視、疑わしい取引の記録。
- 人による確認：自動判定後に誤検知を確認し、保留を解除する。理由、参照リスト、担当者、承認時刻も記録します。
金融庁は2026年3月にAML/CFTガイドラインとFAQを改訂し、金融機関の態勢維持・高度化を促しています（出典：金融庁、2026年）。
導入時の確認に加えて、運用要件にはルールやモデル、リストの更新と、検知精度の検証を含めます。教育や内部監査も、同じ要件に入れます。
可用性・障害復旧・監査証跡の一体設計
可用性要件では、稼働時間や許容停止時間、RTO、RPOを決めます。ピーク処理量やメンテナンス窓も、あわせて定めます。障害を想定した復旧手順も、あらかじめ作っておきます。
- 通信・基盤：通信断、データベース障害、外部サービス停止。
- 運用・監視：証明書切れ、時刻ずれ、監視通知の欠落。
送信済みかどうか不明な取引は、自動で再送しないことが大切です。外部状態の照会や取引ID・メッセージIDの照合を行い、担当者の承認を経てから再処理します。
操作・電文・判定・会計連携のログを関連付け、一定期間後も一件の取引を追跡できるようにします。
稼働後に見るべき指標
稼働後は、処理の流れ、保留と照合、復旧と誤検知の3つの面で、運用が設計どおりかを指標で確かめます。
- 処理の状況：処理件数、STP率、例外率、未処理キューと問い合わせ。
- 保留と照合：制裁保留の時間、送信結果不明の件数、照合差異。
- 復旧と誤検知：復旧時間、誤検知率。
処理時間が短くても、例外が隠れている可能性があります。そのため、自動化率と、人が確認する取引の品質を併せて評価します。
制度改定や接続先の追加では、テスト環境やデータ変換、手順書の更新が必要です。教育や監視ルールの更新も欠かせません。標準データモデルや設定管理、回帰テスト、リリース承認も整えます。
よくある質問（FAQ）
企画段階では判断しにくい疑問を、対象範囲や費用、既存システムとの接続などの観点から取り上げます。
外国為替システムと外国送金システムは何が違いますか？
外国送金システムは、主に送金依頼の受付・承認・送信・状況確認を指します。一方で、外国為替システムは、外為事務や為替予約、外貨預金に加えて、決済や会計、AML/CFTまで含む広い概念です。
呼び方は企業や金融機関によって異なるため、名称よりも、対象業務と接続範囲を定義して比べます。
パッケージ・クラウド・スクラッチはどれが適していますか？
標準的な外為事務やメッセージ連携を早く導入したい場合は、パッケージや共同利用クラウドが候補になります。一方で、独自のレートや手数料、複雑な海外拠点、固有の基幹連携を重視する場合は、スクラッチや個別開発が候補です。
後者では、制度改定と保守を長く担う体制が必要です。また、標準基盤に差別化部分を個別開発し、APIやイベントで連携する方式も、比較対象になります。
外国為替システム開発は最低いくらから始められますか？
既存の顧客・会計基盤を使い、通貨と接続先を絞った送金受付の追加開発なら、初期費用1,000万〜4,000万円程度が目安です。
費用は、本人確認や制裁判定、銀行接続の範囲に応じて変わります。監査やテスト、移行、運用の範囲も、費用を左右します。また、安い機能を先に作る場合でも、二重送金防止と障害復旧は最低限含めます。
ISO 20022対応は一度実施すれば終わりますか？
一度の移行で終わるとは限りません。Swiftの標準化や国内決済網の仕様は更新されるため、日本銀行も国際ガイドラインの年次改訂を踏まえて対応を検討する方針を示しています。
電文定義や変換ルール、テストデータを運用資産として管理します。回帰テストやリリース手順も整えて、改訂を継続的に取り込みます。
開発前に最初に決めるべきことは何ですか？
最初に決めるのは対象範囲で、顧客向け受付、外為事務、銀行間決済基盤のどれを扱うかを定めます。そのうえで対象通貨や件数、接続先を整理し、既存システムや規制、監査の条件、稼働時間も確認します。その後で業務フローとRFPを作ると、過不足の少ない見積につなげられます。
まとめ
外国為替システムは、送金受付、外為事務、銀行間決済を、電文・審査・会計・照合・監査までつなぐ基幹業務システムです。
開発では、取引状態や冪等性、例外処理を設計します。接続先や可用性、AML/CFTへの対応も、そこに含めます。制度改定や障害復旧への備えも必要です。
費用は、限定した送金受付の1,000万〜4,000万円程度から、大規模な決済基盤の数億円超まで幅があります。比べるときは、3年または5年のTCOで見ます。
TCOには、移行やテスト、データ利用料も含めます。クラウドや保守、制度改定の費用もあわせて入れます。
開発会社やサービスは、業務実績やISO 20022対応を、RFPとデモで確認します。接続・運用体制や再委託、障害時の責任分界も、同じ方法で確かめます。
最初に、顧客向け受付、外為事務、決済基盤に範囲を分けます。そのうえで、対象通貨や件数、接続先を整理します。既存システムや処理時限、規制要件も加えます。
その情報をもとにPoCと複数社見積を行えば、過大なスクラッチ開発や、将来の制度改定に対応できない構成を避けやすくなります。
▼関連記事一覧
・外国為替システム開発の進め方
・外国為替システム開発でおすすめの開発会社6選と選び方
・外国為替システム開発の見積相場・費用
・外国為替システム開発の発注・外注・委託方法
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。