金融機関のシステム担当者がベンダー選定を進めるとき、多くの場合こんな壁にぶつかります。「FISC安全対策基準や金融庁ガイドラインは読んだ。でも、それをどう委託先の選定基準や契約条項に変換すればいいか分からない。」
規制の条文は「委託先を適切に管理しなければならない」と述べています。しかし「適切に管理した」と当局検査や社内監査の場で説明できる実務的な根拠と手順が手元にない状態では、ベンダーを選び終わっても「本当にこれで大丈夫か」という不安は消えません。
本記事は、規制要件を選定基準・契約条項・運用体制・出口戦略という4つの実務実装に変換する手順を解説します。特に2026年時点での注目論点、サードパーティリスク管理の拡張・再委託先管理・FISC第13版のAI利用基準・出口戦略の事前策定を中心に、他の関連記事では扱いきれない実務深度での解説を目指します。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
前提：なぜ金融機関の外部委託では「規制→実務変換」が難しいのか
監督責任は委託後も発注側に残る構造
一般企業がシステム開発を外注する場合、品質・納期・コストが主な関心事であり、トラブルは基本的に自社と委託先の間の問題として処理されます。
金融機関の場合は構造が根本的に異なります。預金者・投資家・保険契約者の資産と個人情報を預かる社会インフラとして、システムを外部に委託しても監督官庁・顧客への責任は委託元である金融機関に残り続けます。金融庁の監督指針は、外部委託を行う場合でも委託業務を適切に管理・監督する態勢を整えることを明確に求めています（金融庁「中小・地域金融機関向けの総合的な監督指針」）。
「委託したから自社の責任が軽くなる」のではなく、「委託先を適切に管理する責任」が新たに発生すると理解してください。
規制文書から実務への変換ギャップ
規制の条文は「委託先の適切な管理」を求めますが、「何を確認したら適切とみなされるか」は明文化されていません。この変換ギャップが実務担当者を困らせる本質です。
次章以降で、この変換をFISC・金融庁・個人情報保護ガイドラインの3軸それぞれについて実務レベルで解説します。
3つの規制軸と実務への変換ポイント
委託先選定に入る前に、「何を求められているか」を正確に把握します。ここでは逐条解説ではなく、「発注側として何をしなければならないか」に絞って整理します。
FISC安全対策基準（第13版）：委託先管理と新設AI基準
FISC（金融情報システムセンター）の「金融機関等コンピュータシステムの安全対策基準・解説書」は法律ではありませんが、金融機関のシステム安全対策における事実上の標準として機能してきました。2025年3月に公表された第13版では、2024年10月に金融庁が公表したサイバーセキュリティガイドラインを踏まえた項目追加に加え、AIを利用したシステム開発・運用における安全対策の基準項目が新設されています（FISC第13版公表案内）。
実務変換のポイントは2点です。
第一に、「委託先がFISCに準拠しているか」の確認だけでなく、「自社が委託先をFISCの考え方に沿って管理しているか」が問われます。委託先のセキュリティ評価と、継続的なモニタリング体制の整備が必要です。
第二に、AIを活用したシステム開発・改修を外部委託する場合は、第13版で新設されたAI利用安全基準への準拠を委託先選定の評価項目に追加する必要があります。「AIを使うかどうかはベンダーに任せている」では、監督責任を果たせない可能性があります。
金融庁ガイドライン：「外部委託先管理」から「サードパーティリスク管理」への拡張
2024年10月公表の「金融分野におけるサイバーセキュリティに関するガイドライン」（令和6年10月4日版）で最も重要な変化は、管理対象の拡張です。
従来の「外部委託先管理」という枠組みが「サードパーティリスク管理」へと広がり、クラウドサービス提供事業者・API連携先・システム子会社なども管理対象に含まれるようになりました。
さらに、委託先のさらに先にある再委託先（多段階委託）まで含めたリスク評価と管理手続きが求められています。「直接の委託先だけ見ていれば足りる」という発想では、2026年時点の監督責任を果たしたことにはなりません。
実務変換のポイントは、委託先候補に対して「再委託の有無と範囲」「クラウドサービスの利用状況」「API連携先のリスク評価方法」を選定段階で確認し、契約に盛り込むことです。
個人情報保護ガイドライン：再委託の事前承認と継続的監督
金融庁・個人情報保護委員会が定める「金融分野における個人情報保護に関するガイドライン」とその実務指針（令和4年4月版）は、選定段階の評価にとどまらない継続的な監督を求めています。
特に再委託について、委託先が再委託を行う場合に委託元への文書による事前報告または承認手続を契約に盛り込むことが望ましいとされています。委託元が直接または委託先を通じて定期的に監査を実施し、再委託先の管理状況を確認することも想定されています。
3つの規制軸に共通するのは「委託先を選んで終わりではなく、選定・契約・運用・終了の全段階で発注側が能動的に管理することが監督責任の実態」という点です。
委託先選定：規制要件をチェック項目に変換する
ここからは規制要件を具体的な確認項目に変換します。ベンダーの営業資料にある「万全のセキュリティ体制」「豊富な実績」という言葉の裏づけを、実務で使える形で確認します。
金融システム開発の実績・専門性を見極める問い
実績の「有無」でなく「内容」で評価します。次の問いに具体的に答えられるかどうかが判断の分かれ目です。
- どの業態（銀行・証券・保険・フィンテック）で、どのシステム種別（勘定系周辺・顧客向けWeb・基幹業務）を担当したか
- FISC安全対策基準や金融庁ガイドラインを前提とした開発・運用経験があるか（経験ゼロであればその理解度と補完体制を確認する）
- プロジェクト規模・期間・体制が自社案件と近い実績を含むか
- 金融特有の要件（高可用性・トレーサビリティ・監査証跡・規制変更への追随）を理解した提案ができるか
- AIを活用した開発・改修を行う場合、FISC第13版のAI利用安全基準を把握しているか
セキュリティ体制・サードパーティリスク評価のチェックリスト
以下は委託先評価で直接使えるチェックリストです。ヒアリングシートや社内説明の根拠としてそのまま活用してください。
確認項目 | 確認の観点 |
|---|---|
情報セキュリティ認証 | ISMS（ISO/IEC 27001）等の取得状況と、自社委託業務に適用される範囲であることの確認 |
FISC安全対策基準への対応 | 第13版（AI利用基準含む）を前提とした開発・運用体制の有無と、対応状況の説明能力 |
アクセス管理 | 開発・運用要員へのアクセス権限最小化・ログ取得・定期棚卸の実施状況 |
要員のセキュリティ教育 | 定期的な教育・誓約書取得の有無 |
クラウドサービス利用状況 | 委託業務にクラウドを使用する場合の安全性評価・管理体制（サードパーティリスク管理の観点） |
API連携先の管理 | 外部APIとの連携がある場合の連携先リスク評価・モニタリング体制 |
インシデント対応体制 | 検知・報告・復旧プロセスと、発注側への報告ルートの定義 |
インシデント対応実績 | 過去のインシデント経験と、そこから得た改善の具体的な説明 |
再委託の状況 | 再委託の有無・範囲・再委託先へのセキュリティ基準適用状況（下項参照） |
認証の取得は確認の起点にすぎません。ISMSを取得していても適用範囲が自社委託業務を含んでいなければ意味が薄れます。「取得しているか」ではなく「自社案件に適用される範囲で取得・運用されているか」まで確認することが、形式的チェックと実質的評価の分かれ目です。
再委託・多段階委託のリスク評価：選定段階で問うべきこと
2026年時点での最大リスク領域のひとつが再委託です。選定段階で以下を必ず確認します。
- 委託業務の一部または全部を再委託する予定があるか、ある場合はどの範囲か
- 再委託先に対して、委託先と同等のセキュリティ基準を求める仕組みがあるか
- 再委託先の管理状況（アクセス管理・インシデント対応・認証取得）を発注側に開示できるか
- 再委託の発生・変更時に発注側の事前承認を得る運用に同意できるか
- 多段階委託（再委託先がさらに再委託する場合）の管理ポリシーはどうなっているか
再委託を一律禁止する必要はありません。専門性の高い部分を再委託することは合理的な場合もあります。重要なのは、再委託の実態が発注側から見えなくならないこと、そして発注側が承認・把握できる仕組みを契約と運用で担保することです。
委託契約：監督責任を条項に落とし込む
選定した委託先と結ぶ契約が、監督責任を果たせるかどうかの要になります。口頭合意や善意に依存せず、「インシデント時に当局への説明責任を果たせる状態」を契約条項として明文化します。
責任分界・監査権・報告義務・出口戦略を一覧で確認する
条項 | 目的・実務上の要点 |
|---|---|
責任分界の明確化 | どの範囲を委託先が負い、どこから発注側の責任かを線引きする |
セキュリティ基準の遵守義務 | FISC第13版・金融庁ガイドライン・社内基準への準拠を委託先の義務として明記する（AI開発の場合はAI利用安全基準も明記） |
監査権 | 書面監査・実地監査の両方を確保する。監査権がなければ「管理している」と証明できない |
定期報告義務 | 月次・四半期等の定期報告の内容・形式・提出期限を定める |
インシデント即時報告義務 | 検知後の報告タイムライン（例:重大インシデントは24時間以内）と報告様式を定める |
再委託の事前承認 | 再委託の可否・範囲・承認手続き・多段階委託のポリシーを定める |
インシデント対応・損害賠償 | 障害・漏えい発生時の対応手順・費用負担・損害賠償範囲を定める |
出口戦略・契約終了時の移行条項 | 後述。契約段階でなければ確保が難しい最重要条項のひとつ |
監査権は特に重要です。契約に監査権がなければ委託先の実態を確認する手段が失われ、当局検査で「適切に管理していた」と証明できなくなります。
出口戦略の条項：2026年の実務での位置づけ
「出口戦略」は従来の外部委託管理で見落とされがちでしたが、2024年のガイドライン改訂以降、規制当局も重視する論点になっています。
出口戦略とは、委託関係を終了させるとき（委託先の倒産・品質悪化・M&A・サービス終了等）に、業務継続と情報保護を維持しながら移行できるかの計画です。契約段階で定めておかないと、実際に終了が必要になった時点では交渉力が失われています。
契約に盛り込むべき出口戦略の要素は次のとおりです。
- 移行支援義務: 契約終了後の一定期間、委託先が後継業者への引き継ぎを支援する義務
- データ返却・消去: 委託終了時のデータ返却・確実な消去と消去証跡の提供（形式・期限・証跡方法を明記）
- 技術文書の引き継ぎ: ソースコード・設計書・運用手順書・ライセンス情報の移転範囲と方法
- 移行期間の継続サポート: 後継業者が業務を引き受けるまでの暫定的なサポート義務と費用負担
- マルチベンダー化・内製化の前提: 将来的な移行シナリオを想定した技術選定（ベンダーロックインの回避）
出口戦略は「契約が終わったときの話」として後回しにされがちですが、最も交渉力がある契約締結前に確保することが実務上の原則です。
データ保護・機密保持・偽装請負への注意
金融機関が扱う情報の機微性を踏まえ、以下も欠かせません。
- 機密保持（NDA）と個人データの目的外利用禁止
- 委託業務範囲を超えたデータの複製・持ち出し禁止
- アクセスログの取得・保管と発注側への開示義務
- 委託形態（請負・準委任）と、指揮命令の範囲についての明確化
最後の点は偽装請負リスクに直結します。業務委託でありながら発注側が委託先従業員に対して業務の進め方そのものを直接指揮命令していると、実態が労働者派遣とみなされるおそれがあります（偽装請負の判断基準について（浅野総合法律事務所））。契約書で業務委託であること・指揮命令を行わないことを明記し、要員の配置・交代の判断は委託先に委ねることが基本です。金融機関は当局検査の対象でもあるため、契約形態と実態の整合性は特に厳格に保つ必要があります。
運用・モニタリング体制：「監督責任を継続的に果たす」仕組みの整備
契約を結んで開発が始まれば終わり、ではありません。「監督責任は発注側に残る」という構造から、委託期間中に発注側が能動的に担うべき管理があります。限られた体制で対応するには、リスクベースでの優先順位づけが鍵になります。
リスクベースのモニタリング設計
すべての委託先・業務に対して同じ頻度・深さで監査を行うのは非現実的です。影響度とリスクに応じて頻度と深さを変える「リスクベース」の発想が、現実的かつ規制の考え方とも整合します。
リスク区分 | 対象の例 | モニタリング頻度の目安 |
|---|---|---|
高（重点管理） | 顧客個人情報・資産情報に直結するシステム、再委託が絡む業務 | 月次報告 + 四半期書面監査 + 年1回実地監査 |
中 | 社内業務システムの開発・保守 | 四半期報告 + 年1〜2回書面監査 |
低 | 単発のシステム構築（本番環境と隔離） | 完了報告 + 必要に応じた書面確認 |
モニタリングで継続的に確認すべき観点は次のとおりです。
- 開発の進捗と品質が契約・要件どおりに進んでいるか
- セキュリティ基準が継続的に遵守されているか（アクセス管理・ログ・教育の実態）
- 再委託の状況に変更がないか、変更がある場合は事前承認の手続きを経ているか
- サードパーティ（クラウドサービス・API連携先）のリスク状況に変化がないか
- 委託先の経営状況・体制・主要人員にリスクとなる変化がないか
インシデント発生時：発注側の初動と説明責任
万が一インシデントが発生したとき、発注側がどう動くかを平時から定めておくことが、被害拡大と説明責任の不履行を防ぎます。
- 委託先からの報告を受ける窓口と社内エスカレーション経路を事前に定めておく
- 発注側が行う初動（影響範囲の把握・関係部門への共有・対応方針の決定）を整理しておく
- 当局・顧客への報告が必要な事象かを判断する基準と報告プロセスを準備しておく
インシデント対応の最終的な説明責任は発注側にあります。委託先の報告を待つだけの受け身の姿勢では監督責任を果たしたとは言えません。委託先と発注側が連携して動ける体制を平時に整えておくことが、インシデント時の説明責任を果たすための実務的な前提です。
継続的な出口戦略の見直し
出口戦略は契約段階で定めて終わりではありません。以下のタイミングで定期的に見直します。
- 委託先の経営変化（M&A・資本構成の変化・経営危機）が発生したとき
- 委託先のサービス体系や主要人員に大きな変化があったとき
- 技術的な負債が積み上がり移行コストが高くなってきたとき
- 年1回の定期レビュー（モニタリングサイクルに組み込む）
「出口戦略を定めた」で終わらせず、実際に移行できる状態を維持することが継続的な監督責任の一部です。
まとめ：規制要件を実務実装に変換する4ステップ
金融機関のシステム開発を外部委託する際の実務を整理します。
ステップ1：規制を実務要件に変換する
FISC第13版（AI利用安全基準含む）・金融庁サードパーティリスク管理ガイドライン・個人情報保護ガイドラインが「発注側に何を求めているか」を整理し、自社のチェックリストに変換する。
ステップ2：選定段階で実態を確認する
抽象的なアピールではなく、金融システム開発の実績内容・セキュリティ認証の適用範囲・再委託の管理体制・クラウド・API連携のサードパーティリスク評価を具体的な事実で確認する。
ステップ3：契約で監督責任の根拠を確保する
責任分界・監査権・報告義務・再委託の事前承認・データ消去・出口戦略の移行支援条項を契約に盛り込む。特に出口戦略は契約締結前にしか確保できないため、後回しにしない。
ステップ4：運用体制でリスクベース管理を継続する
リスク区分に応じたモニタリング頻度を設計し、インシデント時の初動体制と報告プロセスを平時から整える。出口戦略の実効性を年1回レビューする。
これらは一度に完璧を目指すものではありません。まず自社の委託先評価チェックリストを整え、契約条項を点検し、運用体制を見直すところから始めることで、当局検査やインシデント時に「この基準で選び、こう契約し、こう管理している」と説明できる状態に近づきます。
外部委託は開発リソース不足を解決する有効な手段です。規制対応を負担として捉えるのではなく、選定・契約・運用に組み込む仕組みとして整理できれば、リソース不足と監督責任のジレンマは両立可能な課題になります。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 外部委託先がFISC安全対策基準に準拠していれば、発注側の監督責任は果たせますか？
いいえ、委託先の準拠確認だけでは不十分です。監督責任の中身は「発注側が委託先をFISCの考え方に沿って選定・契約・運用の全段階で能動的に管理しているか」であり、委託先任せにせず自社の管理態勢を示せることが求められます。
- 委託先選定で「金融実績あり」という説明を、どこまで具体的に確認すべきですか？
業態・システム種別・規模が自社案件に近い実績か、FISC基準や金融庁ガイドラインを前提とした開発・運用経験があるかまで確認してください。「実績あり」の一言ではなく、自社案件に適用される範囲での具体的な事実を裏づけとして求めることが重要です。
- 委託契約で最優先に盛り込むべき条項はどれですか？
監査権の明記を最優先してください。監査権がなければ委託先の実態を確認する手段が失われ、当局検査の際に「適切に管理している」と証明できなくなります。あわせて責任分界・報告義務・再委託の事前承認も基本条項として押さえます。
- 契約終了後に委託先に残ったデータは、どう扱えばよいですか？
契約段階でデータの返却・確実な消去を義務づけ、消去の証跡を受け取れるようにしておきます。委託終了後も委託先環境にデータが残ると新たな漏えいリスクになるため、終了時の処理方法を事前に契約で定めておくことが必要です。
- 限られた体制では、委託後のモニタリングを何から優先すべきですか？
顧客の個人情報や資産に直結するシステム、再委託が絡む業務から重点的にモニタリングしてください。すべてを一律に監査するのではなく、影響度に応じて頻度と深さを変える「リスクベース」の発想が、現実的かつ規制の考え方とも整合します。
