金融システム開発の外部委託｜規制対応と委託先選定の注意点

金融機関でシステム開発を担当していると、開発リソースの不足を外部委託で補う場面が増えてきます。勘定系周辺の改修、顧客向けWebサービスの構築、社内業務システムの刷新など、自社のエンジニアだけでは抱えきれない案件を外注に切り替える判断は、もはや珍しいものではありません。

ところが、いざ外部委託の方針を経営層やコンプライアンス部門に説明しようとすると、一般企業の発注とは勝手が違うことに気づきます。金融機関の場合、システム開発を外注しても、監督責任や説明責任は委託元である金融機関に残り続けるからです。当局検査やインシデントが起きたとき、「委託先に任せていたので分かりません」では済まされません。

しかも、FISC安全対策基準、金融庁の監督指針、金融分野の個人情報保護ガイドラインといった規制が複層的に絡みます。「これらの規制を満たせる委託先をどう見極めればいいのか」「契約に何を盛り込めば監督責任を果たしたことになるのか」「外注した後、自社には何を残しておくべきなのか」——その判断軸が整理されていないと、社内の合意形成も進みません。

この記事では、金融システム開発の外部委託について、規制対応と発注実務を一本につなげて解説します。委託先選定のチェックポイント、契約に必ず盛り込むべき条項、委託後に自社へ残すモニタリング体制を、そのまま社内説明や委託先評価に使えるチェックリスト形式で整理しました。「外注しても監督責任は自社に残る」という金融特有の構造を軸に、限られた体制でも実行できる優先順位まで踏み込みます。

金融業界のシステム開発を外部委託する際に押さえるべき前提

最初に押さえておきたいのは、金融機関の外部委託が一般企業の外注とは構造的に異なるという点です。この前提を共有しておくと、以降の規制・選定・契約の話が一本の筋として理解しやすくなります。

なぜ金融機関の外部委託は一般企業と異なるのか

一般企業がシステム開発を外注する場合、品質や納期に問題があれば契約に基づいて委託先の責任を問えば足ります。委託先が起こしたトラブルは、基本的に委託先の問題です。

ところが金融機関では事情が異なります。システム開発を外部委託しても、利用者保護や安定したサービス提供に対する責任は、委託元である金融機関が負い続けます。金融庁の監督指針でも、外部委託を行う場合に金融機関自身が委託業務を的確に遂行できる態勢を整えること、委託先を適切に管理することが求められています（金融庁「主要行等向けの総合的な監督指針」）。

つまり、外注は「責任の移転」ではなく「業務の委託」にすぎません。当局検査では委託先の管理状況そのものが評価対象になり、インシデントが発生すれば「委託先をどう選び、どう管理していたか」が問われます。「委託先に任せていた」という説明が通用しないことこそ、金融機関の外部委託における最大の前提です。

外部委託が広がる背景とリスクの所在

それでも金融機関で外部委託が広がっているのは、開発リソースの不足という現実があるからです。フィンテック企業との競争、DXの推進、レガシーシステムの刷新といった課題が同時に押し寄せるなかで、社内のエンジニアだけで対応しきるのは困難です。専門性の高い領域ほど外部の知見に頼らざるを得ません。

ここに、金融機関特有のジレンマがあります。開発リソースを確保するために外部委託を進めたいが、委託すればするほど、自社が直接コントロールできない領域が増え、規制への対応や情報管理のリスクが見えにくくなります。再委託や多段階委託が絡めば、リスクの所在はさらに把握しづらくなります。

このジレンマを解く鍵が、後述する「規制要求を委託先選定・契約・運用体制にどう変換するか」という視点です。リソース確保と監督責任の両立は、感覚的な信頼ではなく、具体的な基準と仕組みによって担保する必要があります。

金融システム開発の外部委託に関わる規制・ガイドライン

委託判断の土台になるのが、金融分野に特有の規制・ガイドラインです。ここでは発注側が「何を満たせば監督責任を果たしたことになるか」を考える出発点として、押さえておくべき3つの軸を整理します。逐条的な解説ではなく、発注側に求められる要点に絞って説明します。

FISC安全対策基準が外部委託先に求めること

FISC（金融情報システムセンター）が公表する「金融機関等コンピュータシステムの安全対策基準・解説書」は、法律そのものではないものの、金融業界における事実上の標準として広く参照されています。設備・運用・技術の各面にわたる安全対策の基準が体系化されており、外部委託先の管理についても基準項目が設けられています。

最新版は2025年3月に公表された第13版です。第13版では、経済安全保障推進法における特定社会基盤事業者に関する対応や、AI利用における安全対策の基準項目が新設されたほか、2024年10月に金融庁が公表したサイバーセキュリティガイドラインを踏まえた基準項目が追加されています（FISC「金融機関等コンピュータシステムの安全対策基準・解説書（第13版）」）。

発注側の観点では、委託先がFISC安全対策基準に沿った体制を備えているか、自社のシステムに求められる安全対策の水準を委託先がどこまで実装できるかを評価することが、委託判断の基礎になります。基準は改訂が重ねられているため、委託先評価の際には最新版を前提に確認することが重要です。

金融庁の監督指針・ガイドラインが求める委託先管理

金融庁の監督指針は、外部委託にあたって委託先との役割分担・責任、監査権限、再委託手続、サービス水準などを契約で明確に定めることを求めています。特に二段階以上の委託（多段階委託）については、管理業務が複雑化することから、より高度なリスク管理が必要とされています。

さらに、2024年10月に金融庁が公表した「金融分野におけるサイバーセキュリティに関するガイドライン」では、従来の「外部委託先管理」を一歩進めた「サードパーティリスク管理」の考え方が打ち出されました。ここでいうサードパーティには、ベンダーなどの外部委託先だけでなく、クラウドサービス提供事業者やAPI連携先まで含まれます。サプライチェーン全体を考慮したサイバーセキュリティ戦略とサードパーティリスク管理方針の策定、業務プロセス全体を対象とした管理態勢の整備が求められています（金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（令和6年10月））。

このガイドラインでは、サードパーティとの契約やSLAに明記すべき項目の例として、役割分担・責任分界、監査権限、再委託手続、実施すべきセキュリティ対策、インシデント発生時の対応および報告、データの所在・保管・廃棄に関する取決め、契約終了時の取決めなどが挙げられています。これらは、後述する契約条項を設計する際の具体的なチェック項目として使えます。

個人情報保護ガイドラインと委託先監督・再委託の事前承認

金融機関は大量の顧客情報を扱うため、個人情報保護の観点も外部委託判断に欠かせません。個人情報保護委員会と金融庁が公表する「金融分野における個人情報保護に関するガイドライン」および「安全管理措置等についての実務指針」（令和4年4月）は、委託先の監督について一般の事業者より踏み込んだ対応を求めています（金融庁・個人情報保護委員会「金融分野における個人情報保護に関するガイドライン」）。

特に再委託については、委託先が再委託を行おうとする場合、委託元は再委託の相手方・再委託する業務内容・再委託先での個人データの取扱方法などについて、委託先に事前報告または承認手続を求め、定期的に監査を実施するなどして、委託先が再委託先を適切に監督しているかを確認することが望ましいとされています。二段階以上の委託が行われた場合には、委託先が再委託先を十分に監督しているかについても監督する必要があるとされています（個人情報保護委員会・金融庁「金融分野における個人情報保護に関するガイドラインの安全管理措置等についての実務指針」（令和4年4月））。

発注側としては、再委託の可否や、再委託する際の委託元への文書による事前報告・承認を契約に盛り込むことが、個人データ保護の観点からも求められます。再委託先まで視野に入れた監督体制を設計しておくことが、金融機関の委託先管理の要点です。

外部委託先（ベンダー）選定で確認すべきチェックポイント

ここからは、これまで整理した規制要求を、委託先評価の具体的な項目に変換していきます。「実績豊富」「セキュリティ万全」といった抽象的なアピールを鵜呑みにせず、根拠を確認しながら見極めることがポイントです。

金融システム開発の実績・専門性をどう見極めるか

金融システムは、可用性・正確性・セキュリティに対する要求が一般のシステムより格段に高く、業界特有の業務知識も必要です。一般的なWebシステムの開発実績が豊富でも、金融システムの開発に必要な品質基準や規制要求を理解しているとは限りません。

実績を確認する際は、件数の多さだけでなく、次のような点を具体的に確認します。

• 金融機関（同業態であればなお良い）での開発・運用実績があるか
• FISC安全対策基準や金融庁ガイドラインへの対応経験があるか
• 自社が委託したい領域（勘定系周辺・顧客向けサービス・社内業務システム等）に近い案件の経験があるか
• 当局検査や監査に対応した経験、その際の資料提出の実績があるか

「金融分野の実績あり」という表現は、定義が曖昧なまま使われがちです。どの業態の、どの種類のシステムを、どの規制水準で手がけたのかまで踏み込んで確認することで、自社の案件に対する適合度を見極められます。

セキュリティ体制・認証の確認項目（チェックリスト）

セキュリティ体制は、委託先選定の中核です。第三者認証の保有状況は客観的な判断材料になりますが、認証を持っていること自体が目的化しないよう、自社の委託内容に照らして実効性を確認します。以下のチェックリストを社内の委託先評価にそのまま転用できます。

認証の有無だけで判断せず、「認証の対象範囲に自社の委託業務が含まれているか」「実際にどう運用されているか」まで確認することが、形だけのチェックを避ける鍵になります。

再委託・多段階委託のリスクをどう抑えるか

委託先がさらに別の会社へ業務の一部を委託する再委託は、リスクの所在を見えにくくします。前述のとおり、金融機関には再委託先まで含めた監督が求められるため、選定段階で再委託の方針を確認しておく必要があります。

選定時には、次の点を確認します。

• 再委託の有無と、再委託する場合の範囲・相手先の管理方針
• 再委託にあたって委託元へ事前報告・承認を求める運用になっているか
• 委託先が再委託先をどう評価・監督しているか
• 再委託先で個人データを扱う場合の管理方法

再委託を一律に禁止する必要はありませんが、「どこに、どこまで再委託されるのか」を把握できない委託先は、監督責任を果たすうえでリスクが高いと判断できます。再委託の透明性は、委託先の管理レベルを測る重要な指標になります。

委託契約で必ず盛り込むべき条項

委託先を選定したら、監督責任を果たすための仕組みを契約に落とし込みます。契約は、インシデントや当局検査の局面で「発注側が適切に管理していた」ことを示す根拠になります。ここでは金融システム開発の委託契約に盛り込むべき条項を整理します。

責任分界・監査権・報告義務を契約で明確にする

トラブルが起きたときに最も揉めるのが、責任の所在です。あらかじめ役割分担と責任分界を明確にしておくことで、インシデント時の対応がスムーズになり、当局への説明もしやすくなります。金融庁のサイバーセキュリティガイドラインでも、契約やSLAに明記すべき項目として役割分担・責任分界、監査権限、インシデント発生時の対応・報告などが挙げられています。

特に監査権の確保は重要です。委託先の現場を確認できる権利が契約上担保されていなければ、後述する委託後のモニタリングが機能しません。

機密保持・個人データ保護・契約終了時のデータ消去

金融機関の委託では顧客の個人データが関わるため、機密保持と個人データ保護の条項を厚くする必要があります。

• 機密保持（NDA）: 委託業務で知り得た情報の保持義務、目的外利用の禁止
• 個人データの取扱い: 委託の目的の範囲内での利用に限定し、目的外利用を禁止する
• 再委託の事前承認: 再委託の可否と、再委託する場合の委託元への文書による事前報告・承認を定める
• 契約終了時のデータ返却・消去: 契約終了・解除時に、預けたデータや成果物を確実に返却・消去させ、その完了を確認できるようにする

契約終了時のデータ消去は見落とされがちですが、委託先の環境に顧客データが残り続けると、契約終了後も情報漏えいのリスクを抱えることになります。消去の方法と完了確認の手順まで契約で定めておくことが望ましいといえます。

なお、これらの契約条項は委託する業務の内容やリスクによって過不足が生じます。契約条項を網羅的に点検したい場合は、「フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド」のような、チェックリスト形式で条項を確認できる実務資料が役立ちます。

委託形態（請負/準委任）と指揮命令・偽装請負への注意

システム開発の委託では、契約形態を「請負」とするか「準委任」とするかで、責任の所在や指示の仕方が変わります。成果物の完成に責任を負わせる場合は請負、業務の遂行そのものを委託する場合は準委任が一般的です。1つのプロジェクトで開発フェーズと運用・保守フェーズの両方がある場合は、それぞれの業務ごとに契約を分けて締結する方法もあります。

ここで注意したいのが偽装請負のリスクです。偽装請負とは、形式的には請負や準委任の契約でありながら、実態として発注側が委託先の要員に直接の指揮命令を行っている状態を指し、違法と判断される可能性があります（東京労働局「偽装請負について」）。

ポイントは「指揮命令」と「指示」の区別です。業務の進め方そのものに細かく干渉したり、要員の作業時間や交代を発注側が指定したりすると、指揮命令とみなされやすくなります。一方、成果や結果に対する要望を伝えるにとどまるのであれば、適正な範囲の指示と整理できます。誰がどの作業を担当するか、いつ交代させるかといった判断は、本来委託先が行うべきものです。

委託先の要員と直接やり取りする機会が多い金融システム開発では、この線引きが曖昧になりがちです。委託形態に応じて、コミュニケーションの取り方や指示の出し方をあらかじめ社内で整理しておくことが、偽装請負のリスクを避けるうえで有効です。

委託後に自社へ残す管理・モニタリング体制

契約を締結すれば監督責任を果たせるわけではありません。「監督責任は自社に残る」という軸の帰結として、委託期間中から委託後にかけて、発注側が継続的に担うべき管理があります。ここでは限られた体制でも実行できる優先順位を示します。

定期モニタリング・監査で確認すること

委託先に任せきりにせず、定期的に状況を確認することが監督責任の実質です。契約で確保した監査権・報告義務を実際に行使し、次のような点を継続的に確認します。

• 進捗・品質が契約どおりに保たれているか
• セキュリティ要件が運用面でも守られているか（アクセス管理・ログ管理の状況など）
• 委託先からの定期報告の内容に問題がないか
• 再委託が行われている場合、その管理が適切か

すべてを高頻度で実施するのは現実的でないため、委託業務のリスクに応じてモニタリングの頻度と深さを調整します。顧客データを扱う領域や障害が事業に直結する領域は手厚く、影響の小さい領域は報告ベースで確認するといったメリハリが、限られた体制での運用には欠かせません。

インシデント発生時に発注側が担う初動と報告

委託先で障害や情報漏えいが起きたとき、発注側である金融機関にも初動と報告の責任が生じます。「委託先が対応中だから」と待つのではなく、自社としての初動体制を事前に決めておくことが重要です。

• 委託先からの第一報を受ける窓口と、社内へのエスカレーション経路を明確にしておく
• 顧客影響の有無を早期に把握し、必要に応じて当局・顧客への報告を判断する
• 契約で定めた報告フローが機能するか、平時から確認しておく

インシデント時に当局や顧客への報告義務を負うのは委託先ではなく金融機関自身です。初動の遅れがそのまま監督責任の問題につながるため、報告フローと判断基準を平時から整理しておくことが、いざというときの差になります。

委託先の状況変化（経営・再委託・人員）の把握

委託開始時に問題がなくても、委託先の状況は時間とともに変化します。監督責任を継続的に果たすには、契約後の変化を把握する仕組みも必要です。

• 経営状況の変化: 委託先の経営が不安定になれば、サービス継続や情報管理に影響が及ぶ可能性があります
• 再委託の変更: 新たな再委託が発生していないか、再委託先が変わっていないかを確認します
• 体制・人員の変化: 主要な要員の交代や体制の縮小が、品質やセキュリティに影響していないかを確認します

これらの変化は、定期報告やモニタリングの機会を使って把握します。委託先の状況変化に早く気づくことが、リスクが顕在化する前の対応につながり、結果として監督責任を果たすことにもなります。

よくある質問（FAQ）

Q. FISC安全対策基準は法的義務ですか？

FISC安全対策基準は法律そのものではなく、FISC（金融情報システムセンター）が公表する自主基準です。ただし金融業界では事実上の標準として広く参照されており、金融庁の監督や当局検査の場面でも実質的な目安となっています。委託先評価でも、この基準への対応状況が判断材料になります。

Q. 委託先が再委託する場合、発注側の承認は必要ですか？

金融分野の個人情報保護ガイドラインの実務指針では、委託先が再委託を行おうとする場合、委託元が再委託の相手方や業務内容などについて事前報告または承認手続を求めることが望ましいとされています。再委託の可否や事前報告・承認を契約に盛り込み、再委託先まで含めて監督できる体制にしておくことが推奨されます。

Q. 業務委託で開発を依頼すると偽装請負になりますか？

業務委託（請負・準委任）であること自体は問題ありません。偽装請負になるのは、形式は業務委託でも、実態として発注側が委託先の要員に直接の指揮命令を行っている場合です。成果や結果への要望を伝える「指示」にとどめ、要員の作業管理や交代の判断は委託先に委ねることが、適正な業務委託を保つポイントです。

Q. 小規模な金融機関やフィンテックでも同じ水準の委託先管理が必要ですか？

求められる管理の考え方は規模を問わず共通ですが、実施の水準は委託業務のリスクに応じて調整できます。顧客データや基幹業務に関わる委託は手厚く、影響の小さい領域は報告ベースにするなど、リスクに見合ったメリハリをつけることで、限られた体制でも実効性のある管理が可能です。

Q. クラウドサービスを使う委託先を選んでも問題ありませんか？

クラウド利用そのものが問題になるわけではありません。FISC安全対策基準もクラウド利用を前提とした項目を整備しており、金融庁のサイバーセキュリティガイドラインもクラウドサービス提供事業者をサードパーティ管理の対象に含めています。委託先がクラウドの安全性評価や責任分界をどう管理しているかを確認したうえで判断することが重要です。

まとめ｜監督責任を果たせる外部委託にするために

金融システム開発の外部委託で一貫して押さえるべきなのは、「外注しても監督責任は自社に残る」という構造です。開発リソースを外部に求めても、利用者保護や当局への説明責任は委託元の金融機関が負い続けます。この前提を起点に、規制から選定、契約、運用までを一本の流れとして設計することが、監督責任を果たす近道です。

本記事で整理した流れを振り返ると、次のようになります。

• FISC安全対策基準・金融庁の監督指針およびサイバーセキュリティガイドライン・個人情報保護ガイドラインが、発注側に求める要点を押さえる
• 規制要求を委託先選定のチェック項目（実績・専門性、セキュリティ体制・認証、再委託管理）に変換して見極める
• 責任分界・監査権・機密保持・データ消去・委託形態などの必須条項を契約に盛り込む
• 委託後も定期モニタリング・インシデント初動・委託先の状況変化の把握を自社に残す

これらを社内の委託先評価シートや契約点検リスト、運用体制の見直しに落とし込めば、「この基準で委託先を選び、こう管理する」と経営層やコンプライアンス部門に説明できる状態に近づきます。次のアクションとして、まずは自社の委託先評価項目と契約条項が本記事のチェックポイントを満たしているかを点検することをおすすめします。

委託先選定の判断軸や契約条項をさらに具体的に詰めていく際には、「フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド」が役立ちます。偽装請負の境界線、業務委託契約書のNDA必須記載事項、コンプライアンス体制の自己診断チェックリストなどをまとめたこの資料を、外部委託を「監督責任を果たせる委託」に変えるための土台づくりに活用してみてください。