外国為替システム開発の発注/外注/依頼/委託方法について

外国為替システムの発注では、顧客向け送金受付だけなのか、外為事務・SWIFT・勘定系まで含む決済基盤なのかを切り分け、要件と接続範囲に応じて委託先と契約形態を選ぶことが成功の近道です。

外国送金、為替予約、外貨預金、AML/CFT、ISO 20022対応などを一度に考えると、何をRFPに書き、どの見積を比較すればよいか迷いやすいものです。この記事では、発注形態の選び方から要件整理、RFP、請負・準委任の使い分け、費用相場、委託先選定、見積比較、リリース後の保守までを、発注者が社内稟議とベンダー選定に使える順番で解説します。

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

外国為替システムを発注する前に全体像を整理します

外国為替システムは、円・米ドル・ユーロなどの通貨を扱う受付、審査、決済、会計、照合、顧客通知をつなぐ業務システムです。ただし、同じ「外国為替システム」でも、事業会社の海外送金依頼ツールと、銀行の外為事務・中継・勘定系を含む基幹決済基盤では、必要な品質と予算が大きく異なります。最初に対象範囲を定義しないまま見積を依頼すると、各社の提案条件がそろわず、金額だけで判断する危険があります。

発注前には、利用者と業務範囲を一文で説明できる状態にします。たとえば「海外取引の多い法人が、複数銀行への仕向送金を申請し、社内承認と会計連携までを行うシステム」と、「銀行の外為事務担当者が送金を審査し、AML判定、SWIFT発信、勘定系計上、照合までを24時間運用するシステム」では、同じ送金機能でも設計の前提が違います。前者は銀行APIやERP連携、承認権限、送金状況の可視化が中心です。後者は、接続審査、電文の正規化、可用性、監査証跡、障害時の手動復旧まで含めて発注します。

機能一覧は、画面単位ではなく取引のライフサイクルで作ると抜け漏れを減らせます。具体的には、送金依頼・受取依頼の受付、本人確認、承認、通貨・為替レート・手数料・適用レート・約定日・価値日の管理、仕向送金・被仕向送金、外貨預金振替、為替予約、信用状、AML/CFT・制裁リスト・KYCチェック、SWIFTや銀行APIとの連携、勘定系・ERP・会計との連携、入出金照合、顧客通知、操作履歴、電文履歴、監査レポートを並べます。

さらに、差戻し、組戻し、取消、送達確認の遅延、電文の欠損、重複受信、送信済みか不明な状態、為替レート更新の失敗を業務シナリオに入れます。外国為替システムで重要なのは画面を表示することではなく、決済を安全に完了し、後から誰が何を判断したかを再現できることです。

外国為替システムの発注形態はどれを選ぶべきですか？

発注形態は、既存業務との適合度、独自要件、接続先、将来の制度改定、社内に残したい運用知識で選びます。候補は、外為パッケージや共同利用クラウドの導入、既存サービスへの追加開発、スクラッチ開発、標準基盤と個別開発を組み合わせるハイブリッドです。一般に、標準機能で業務の大部分を満たせるほど短期・低リスクになり、差別化や複雑な既存連携が増えるほど個別開発の比重が高まります。

外為事務、送金ワークフロー、SWIFT連携、STP、照合などの標準業務が中心なら、パッケージや共同利用クラウドが有力です。標準機能を利用することで、ゼロから電文変換や監査ログを設計する工数を抑えやすく、制度改定をサービス側で共通対応できる可能性もあります。一方で、自社の業務を標準に合わせる必要があり、標準外のカスタマイズを積み重ねると、バージョンアップ時の検証負担が増えます。

2025年1月、NTTデータは共同利用型のAnserBizForexについて、外国送金のISO 20022対応を開始し、2025年1月から10月に利用中の全金融機関を対応させる計画を公表しました。共同利用型を評価するときは、標準機能の数だけでなく、対応期限、追加費用、接続試験、個社固有のデータ連携がどこまで含まれるかを確認することが大切です。

海外拠点ごとの業務差、独自のレート・手数料計算、複雑な既存基幹連携、独自の顧客体験などが競争力に直結する場合は、スクラッチ開発を検討します。ただし、独自画面を作ることと、決済の中核をすべて自社実装することは別です。ISO 20022、SWIFT接続、AML判定、HSM、監視、冗長化など、標準サービスや専門基盤を使える領域まで自社で作ると、初期費用だけでなく、制度改定と要員確保の負担が継続します。

実務では、標準化しやすい決済・メッセージ・監査機能をパッケージやクラウドで持ち、顧客ポータル、承認ルール、ERP連携、分析画面などを個別開発するハイブリッドが現実的です。業務ルールとデータをAPIやイベントで分離すれば、将来の銀行追加や電文バージョン変更の影響範囲を抑えられます。RFPでは「標準機能」「設定で対応」「追加開発」「対象外」を機能ごとに明示させると、各社を同じ土俵で比較できます。

外国為替システムの発注・外注はどの順番で進めますか？

発注は、いきなり開発会社へ機能一覧を渡すのではなく、現状調査、構想、RFP、提案評価、契約、要件定義、開発、受入、移行、保守の順に進めます。特に金融業務では、業務部門、経理、法務・コンプライアンス、情報セキュリティ、インフラ、運用担当が別々のリスクを持つため、発注者側の意思決定者と承認ルートを先に決めます。

最初に、現行業務を仕向送金・被仕向送金、国内・海外、個人・法人、通常・例外に分解し、利用者、処理量、締め時刻、接続先、手作業、障害時の対応を可視化します。月間件数だけでなく、ピーク時の件数、1件あたりの金額、同時ログイン数、制裁判定の照会回数、保管年数も収集します。既存の勘定系、顧客情報、会計、ERP、AML、レート配信、SWIFT、日銀ネットとの関係を図にし、残すもの、廃止するもの、移行するものを決めます。

この段階で「今回の発注に含めないもの」も明記します。たとえば、初回リリースは法人向け仕向送金と銀行API連携に限定し、為替予約や信用状は第二期に分ける方法です。範囲を分ける場合でも、将来の拡張に必要な取引ID、顧客ID、承認履歴、会計キーを初期設計に残しておく必要があります。

RFPには、目的、対象業務、利用者、対象通貨、月間・ピーク処理量、取引先・銀行数、希望リリース時期、予算上限の考え方、既存システム、連携方式、データ移行、テスト環境、保守体制を記載します。機能要件では、受付、承認、レート・手数料、送受信、照合、会計、通知、照会、帳票、監査ログを並べ、非機能要件では可用性、RTO・RPO、性能、セキュリティ、監視、バックアップ、障害復旧、データ保持を指定します。

外国為替システム特有の項目として、SWIFTまたは銀行API・ファイル連携、ISO 20022の対象メッセージとバージョン、日銀ネット接続の有無、AML・制裁リストの判定方式、誤検知の人手確認、再送・取消・組戻し、送信済みか不明な場合の扱い、件数・金額照合、コルレス銀行情報を入れます。これらがないRFPは、見積を取れても後から重要要件が追加されやすくなります。

提案の段階では、画面のデモだけでなく、代表的な電文を使ったPoCを依頼します。具体的には、ISO 20022の入力項目を受け取り、相手先の電文へ変換し、制裁判定を通過させ、送達結果を取引履歴へ戻し、同じメッセージを再処理しても二重計上・二重送信にならないことを確認します。PoCの合否条件を先に定めることで、「できます」という営業説明と、実装できる範囲を区別できます。

開発後は、単体・結合・性能・障害復旧・権限・監査・制裁判定・接続先試験を行い、移行リハーサルを複数回実施します。送信済みか不明な取引を含む障害訓練、通信断からの復旧、手動処理への切替、件数と金額の突合、旧新システムの並行稼働までを受入条件に含めます。移行方式は一括切替より、対象通貨や顧客群を分けた段階移行の方がリスクを制御しやすい場合があります。

契約形態は請負と準委任をどう使い分けますか？

契約形態は、成果物と仕様をどこまで確定できるかで選びます。外国為替システムでは、構想・現状分析・要件定義は不確実性が高く、設計・開発・テストは成果物を定義しやすい傾向があります。そのため、全工程を一つの契約に押し込むより、フェーズごとに責任と検収条件を分ける方が、発注者と受託者の認識をそろえやすくなります。

請負契約は、受託者が合意した成果物を完成させ、発注者が検収する形に向いています。基本設計書、詳細設計書、プログラム、テスト仕様書・結果、移行手順書、運用設計書などを成果物として定義し、検収の期限、修正対応、瑕疵対応、仕様変更の手続を明記します。送金処理のように完成条件が重要な領域では、正常系だけでなく、異常系、性能、監査ログ、再送制御まで受入基準に入れます。

準委任契約は、業務を遂行するプロセスや専門知識の提供に対して報酬を支払う形に向いています。現状調査、RFP作成支援、PMO、金融業務に詳しいアーキテクトの支援、ベンダー間調整、制度改定の影響調査など、開始時点で成果物や解決方法を固定しにくい仕事で使いやすい契約です。時間単価や人月単価だけでなく、担当者の役割、稼働時間、会議体、報告書、判断者、品質責任の分担を定義します。

準委任だから受託者が品質に責任を負わないという意味ではありません。設計レビュー、課題管理、リスク報告、セキュリティ基準、エスカレーション、情報管理のルールを合意し、請負工程へ引き継げる状態を作ります。発注者側にも、業務判断を遅らせない責任者と、外部委託先を管理する担当者が必要です。

リリース後は、障害対応、監視、バックアップ、脆弱性対応、証明書更新、レート・制裁リストのデータ更新、電文バージョン改訂、接続先試験、問い合わせ対応を継続します。保守契約では、受付時間、重大度ごとの初動時間、復旧目標、代替運用、報告書、再発防止、RTO・RPO、定期訓練を決めます。制度改定による改修を月額に含めるのか、別途見積にするのかも、契約前に確認します。

金融庁の基幹インフラ制度では、指定された事業者が特定重要設備の導入・維持管理などを委託する際、事前届出と審査が求められる場合があります（出典: 金融庁「基幹インフラ制度に関する相談窓口」、2026年確認）。対象となる場合は、受託者だけでなく再委託先、クラウド事業者、国外の運用拠点、データ所在、障害時の連絡体制まで契約とRFPで確認します。

外国為替システムの費用相場と見積の見方を解説します

外国為替システムの公開価格は少なく、費用は取扱通貨、月間件数、接続先、既存システム、可用性、監査、移行、24時間運用の範囲で大きく変わります。以下は2026年時点の一般的な金融・大規模業務システムの相場と、公開事例のスコープから組み立てた推定レンジです。正式な予算化では、同じRFPを複数社へ渡し、工程別人月と継続費をそろえて比較します。

法人向け送金受付・承認・銀行API連携の追加開発は、1,000万〜4,000万円、4〜9か月が目安です。既存の顧客・会計基盤を利用し、接続先を1〜2行、制裁判定を外部サービス連携とする前提です。外為事務パッケージや共同利用クラウドの導入は、2,000万〜1億円、6〜15か月が目安で、初期設定、データ移行、勘定系・SWIFT連携、運用設計を含みます。

SWIFT・ISO 20022対応の外為中継・メッセージ基盤刷新は、5,000万〜3億円、9〜24か月が目安です。MT/MX変換、複数システム連携、STP、照合、例外処理、総合テストまで含めると、画面追加より工数が膨らみます。銀行の外為基盤更改で日銀ネット、勘定系、AML連携、高可用性、BCP、段階移行を含める場合は1億〜10億円、18〜36か月程度を見込みます。海外拠点・複数通貨を含む全面刷新は5億〜30億円超、2〜5年になることもあります。

見積の基礎は、工程別の人月に単価を掛ける積算です。2026年版の一般的な受託開発相場では、人月単価は60万〜200万円程度とされ、スキルや地域で変動します（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月更新）。金融業務に詳しいPM・上級SEは月120万〜200万円、SEは月80万〜150万円、開発者は月50万〜100万円程度を仮置きし、要件定義、設計、開発、テスト、移行、運用設計を別々に積み上げると査定しやすくなります。

初期開発費以外には、SWIFTなどの利用料、制裁リストや為替レートのデータ利用料、クラウド・専用線、HSM・証明書、監視、脆弱性診断、接続試験、24時間保守、制度改定対応が発生します。月額の共同利用料やクラウド費用が100万〜500万円程度になるケースもあるため、初期費用だけで選ばないことが重要です。初期費用の15〜20％を年次保守の仮置きとし、要件未確定・制度対応・データ移行に20〜30％の予備費を置くと、稟議後の追加予算を抑えやすくなります。

見積比較では、初期費用に加えて5年間の保守・ライセンス・データ・インフラ・監査・制度改定・追加接続を合算します。初期費用が安くても、銀行追加のたびに高額な個別改修が必要、電文改定が別料金、夜間障害の対応が限定的、テスト環境が有料という条件なら、総額は上がります。反対に、月額が高くても標準アップデート、監視、接続試験、法令改定の影響調査が含まれるなら、発注者側の運用費を下げられる可能性があります。

各社の見積書には、含むもの・含まないもの、前提条件、オプション、単価、工数、検収条件、変更時の単価、保守の対象外を記載させます。特に「一式」とだけ書かれた費用は、要件追加時の比較基準になりません。SIAも、工程ごとの人月と単価を明示した見積の方が査定しやすいと説明しています。価格の大小ではなく、前提とリスクの開示度を評価します。

RFPと見積比較では何を確認すべきですか？

RFPと提案書を比較するときは、価格、機能、実績、体制、リスク、将来費用を同じ評価表に入れます。ベンダーごとに「含む・含まない」の境界が違うと、安い提案が単に重要機能を除外しているだけということがあります。発注者が求めるのは最安値ではなく、決済品質を維持しながら予算と納期の不確実性を管理できる提案です。

RFPには、対象業務と対象外業務、業務フロー、取扱通貨、件数、ピーク、画面・帳票、権限、承認ルール、レート・手数料、顧客通知、会計仕訳、照合キー、データ移行、接続先を記載します。非機能では、可用性、性能、監視、バックアップ、災害対策、RTO・RPO、暗号化、脆弱性診断、ログ保管、アクセス制御、障害時の手動復旧、24時間連絡を指定します。

加えて、SWIFT・ISO 20022・日銀ネット、AML/CFT、制裁リスト、KYC、外為法、基幹インフラ制度への対応責任を明確にします。日本銀行は、2025年11月に日銀ネットで利用するISO 20022電文を2019年バージョンへ改訂し、今後は電文が短期間で定期的に改訂される可能性を踏まえ、試験短縮や情報提供の早期化を進めています（出典: 日本銀行「日銀ネット等におけるISO20022に関する取り組み」、2026年確認）。このため、RFPに「初回対応」だけでなく、バージョン改訂を吸収する運用体制まで書く必要があります。

提案書を受け取ったら、まず前提条件を横並びにします。接続先は何行か、通貨は何種類か、既存の認証・顧客・会計基盤を使うのか、データ移行件数は何件か、テストデータを誰が作るのか、接続先試験の調整を誰が担うのかを確認します。次に、要件定義書、画面仕様、API仕様、電文マッピング、テスト計画、移行計画、運用手順、教育資料が成果物に含まれるかを見ます。

金額の差が大きい項目は、作業量の差か、責任範囲の差かを質問します。たとえば、A社はAMLエンジンとの連携を含み、B社は別途ライセンス扱いかもしれません。A社は総合テストを含み、B社は接続先試験を発注者に委ねているかもしれません。回答は口頭で終わらせず、見積前提一覧と契約書・提案書へ反映します。

発注前に質問したいのは、機能の可否だけではありません。障害時に送信済みか不明な取引を誰が判定するか、再送を誰が承認するか、重複送信をどう防ぐか、件数・金額の照合をどのシステムで行うか、AMLの誤検知を誰が処理するか、電文改訂の影響調査とテストを誰が負担するかを確認します。ここが曖昧な提案は、稼働後に発注者の運用負担が膨らむ可能性があります。

契約書には、再委託先の開示、データ所在、アクセス権、脆弱性対応、監査権、インシデント報告、サービス終了時のデータ返却、移行支援、秘密保持、知的財産、SLA違反時の扱いを記載します。金融システムは一社だけで完結しないことが多いため、元請け、アプリベンダー、クラウド、外部判定サービス、接続事業者の責任分界を一枚の図にしておくと、障害時の連絡先と判断者が明確になります。

外国為替システムの委託先はどう選びますか？

委託先は、知名度や提示価格だけでなく、対象業務と接続範囲に合う経験を持つかで選びます。銀行向け基幹決済、金融機関向け外為事務、事業会社向け送金依頼では、必要な実績が異なります。RFPの候補には複数のタイプを含め、標準サービスに強い会社、上流・刷新に強い会社、クラウド基盤やセキュリティに強い会社を比較すると、選択肢の偏りを防げます。

実績確認では、「金融案件があります」ではなく、どの業務を、どの規模で、どの接続先と、どの運用体制で担当したかを聞きます。SWIFT接続、ISO 20022の電文マッピング、日銀ネット、AML・制裁判定、勘定系連携、24時間監視、移行リハーサル、障害訓練の経験を、案件名を開示できる範囲で確認します。可能なら、同じような業務を使う顧客から、稼働後の制度改定や障害対応の評価も聞きます。

2025年11月22日、Swiftのクロスボーダー決済ではMTとISO 20022の共存期間が終了し、対象となる金融機関間の支払指図はISO 20022を前提とする運用へ移りました（出典: Swift「ISO 20022 for Financial Institutions」、2025年）。2026年は移行完了後のデータ品質、住所構造化、例外処理、バージョン更新が焦点になります。過去の移行対応だけでなく、次の改訂を継続的に吸収できるチームかを見ます。

事業会社が法人向け送金依頼とERP連携を追加するなら、金融業務とAPI連携に詳しい開発会社を選び、銀行が外為基盤を更改するなら、接続審査、可用性、監査、BCP、マルチベンダー調整まで見られる体制を選びます。発注者側に金融業務の知識が足りない場合は、開発会社だけでなく、業務整理・RFP・PMOを支援できる会社を上流に置く方法もあります。

提案体制では、営業担当ではなく、実際のPM、業務リーダー、アーキテクト、セキュリティ責任者、運用責任者と面談します。誰が要件定義に参加し、誰が設計レビューを行い、誰が夜間障害を受け、誰が再委託先を管理するのかを確認します。提案時のキーパーソンが契約後も継続するか、交代時の引き継ぎルールがあるかも、見積金額と同じくらい重要です。

評価表には、業務適合度、金融・外為の実績、SWIFT・日銀ネット接続、ISO 20022の更新体制、AML・制裁判定、可用性・RTO・RPO、セキュリティ、テスト環境、移行リハーサル、24時間監視、再委託管理、5年TCO、保守SLAを入れます。たとえば価格20点、機能適合25点、実績15点、非機能・セキュリティ15点、体制10点、移行・保守10点、将来費用5点のように、社内のリスクに合わせて配点します。

候補を2〜4社に絞った後は、同じ業務シナリオでデモと質疑を行います。電文を1件入力し、承認、制裁判定、送信、結果受信、照合、例外処理、監査ログ確認までを一連で見せてもらいます。費用が安い会社を選ぶ前に、「このシナリオを誰が、どの環境で、どのテストデータを使って実証したか」を確認すれば、提案書の抽象的な強みを実装可能性へ変換できます。

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

外国為替システムの発注では、一般的な業務システムとは異なる接続・規制・障害対応の疑問が生じます。ここでは、発注前に特に質問されやすい内容を、判断に使える形で回答します。

法人向け送金受付と銀行API連携の追加開発なら1,000万〜4,000万円、パッケージ・共同利用クラウド導入なら2,000万〜1億円、SWIFT・ISO 20022中継基盤の刷新なら5,000万〜3億円が一つの目安です。銀行の外為基盤更改は1億〜10億円、海外拠点を含む全面刷新は5億〜30億円超になる場合があります。いずれも公開価格ではなく、接続数、可用性、移行、保守を含むスコープ別の推定です。

発注はできますが、接続や電文を自社だけで経験していない会社へ中核決済を一括委託する場合は、専門会社との分業やPoCを組み合わせます。発注先には、ISO 20022の項目設計、変換、欠損時の例外処理、送達確認、再送制御、総合テストの担当範囲を具体的に確認します。画面やAPIの開発会社と、SWIFT接続・外為事務の専門会社を分ける場合は、障害時の一次窓口と責任分界を契約で定めます。

要件と成果物を確定しやすい設計・開発・テストは請負、現状調査、要件整理、PMO、専門家支援など不確実性が高い工程は準委任が基本的な考え方です。ただし、契約形態だけで品質が決まるわけではありません。成果物、検収、課題管理、レビュー、変更手続、責任者、保守SLAを明確にし、フェーズごとに適した契約を組み合わせます。

初期費用だけでなく、5年間の保守、クラウド、ライセンス、SWIFT・レート・制裁リストのデータ利用、監視、追加接続、制度改定、監査、移行支援を合算して比較します。見積書の「一式」を工程・人月・単価・前提に分解し、対象外の費用を明示してもらいます。安い提案ほど、テスト、保守、障害訓練、バージョン更新が含まれているかを確認することが重要です。

まとめ

外国為替システムの発注・外注・委託では、最初に「顧客向け受付」「外為事務」「中継・決済基盤」「勘定系を含む全面刷新」のどこまでを作るか決めます。そのうえで、業務フロー、電文、接続先、AML/CFT、会計、照合、可用性、障害復旧、移行をRFPに落とし、標準基盤と個別開発の境界を提案書で比較します。

最初に、現行業務とシステムの全体図を作ります。次に、正常系・例外系・障害時を含む業務要件と、SWIFT・ISO 20022・日銀ネット・AML・会計の接続条件を整理します。最後に、初期費用だけでなく5年TCO、体制、SLA、制度改定、再委託先まで評価できるRFPと採点表を作ります。この3つがそろえば、ベンダーから得る提案の精度が上がり、発注後の追加費用や責任分界の曖昧さを減らせます。

外国為替システムは、リリースした時点で終わるシステムではありません。ISO 20022のデータ品質、電文や接続先の更新、制裁リスト、脆弱性、監査、障害復旧、運用訓練を継続する必要があります。Swiftの移行後も、制度改定と例外処理は残ります。したがって、委託先は「作れる会社」だけでなく、「変化する決済業務を安全に維持できる会社」として、実績、体制、責任分界、5年TCO、保守SLAを総合的に評価することが大切です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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