金融系のシステム開発で見積もりが3倍開くとき、その差は技術力ではなく「どの基準に合わせて作るか」の前提差です。 同じ機能一覧を渡しても、A社は一般的なWebシステムとして見積もり、B社は金融機関の委託先監査に耐える体制込みで見積もる。金額だけを並べれば当然A社が安く見えますが、納品後に取引先の金融機関から体制確認を求められた瞬間、その差は追加費用として跳ね返ります。
本記事は、金融機関向けのシステムを受注したい事業会社、金融機関と直接取引する業務システムを作る中堅企業、そしてフィンテック系の新規事業を立ち上げる経営者に向けて、発注側が基準の要求水準を自分で決められるようになることを目的に整理します。開発会社選びの一般論はITベンダーとは（種類・SIerとの違い・選び方）、契約形態は受託開発とは何かで扱っています。
目次
- 結論：先に決めるのは「どこまで合わせるか」
- なぜ金融系は見積もりが開くのか
- FISC安全対策基準とは何か
- 外部委託先管理という壁
- 「金融に強い」の中身を確かめる
- 開発会社への質問10項目
- 見積もりの読み方
- よくある失敗
- 発注前チェックリスト
- よくある質問（FAQ）
- 発注先の選定で迷ったら
<a id="conclusion"></a>
結論：先に決めるのは「どこまで合わせるか」
金融系システムの発注で最初に決めるべきは、開発会社ではありません。自社のシステムが、どの基準にどこまで合わせる必要があるのかです。ここが決まらないまま相見積もりを取ると、各社が異なる前提で金額を作るため、比較そのものが成立しません。
判断の起点になるのは、次の3つの問いです。
- このシステムは、金融機関の業務や顧客資産に直接触れるのか（勘定系に近いのか、周辺業務なのか）
- 取引先の金融機関から、委託先としての体制確認を受ける立場になるのか（なるなら、いつ、誰が）
- 扱うデータは何か（口座情報、取引履歴、与信情報、単なる氏名・連絡先）
1と2に「はい」が付くほど、求められる水準は上がり、費用は増えます。逆に、金融機関の社内で使うが顧客資産には触れない業務システムであれば、一般的な業務システムと同等の水準で足りる場合もあります。「金融だから最高水準」ではなく、対象と役割で決めるのが、費用を無駄にしない考え方です。
<a id="why"></a>
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
なぜ金融系は見積もりが開くのか
一般的な業務システムと比べて、金融系で追加的に発生しやすいコストは次の領域です。
横にスクロールして確認できます
| 領域 | 追加で発生すること |
|---|---|
| 設計・文書 | 基準への対応状況を示す文書、根拠の記録。開発者向けではなく監査向けの成果物 |
| 権限管理 | 職務分離、作業者と承認者の分離、特権IDの管理と記録 |
| ログ・証跡 | 誰が何をしたかを長期間保存し、後から追跡できる状態にする |
| 障害対応 | 復旧目標時間の設定、手順の整備、訓練 |
| 事業継続 | 災害・広域障害時の継続計画とバックアップ拠点 |
| 委託先管理 | 再委託の可否、再委託先の管理、監査受入 |
| テスト | 本番データを使わない検証環境の分離、データの匿名化 |
これらは機能一覧に現れません。だから「同じ機能なのになぜ高いのか」という会話が生まれます。見積もりの差の正体は、この見えない列の有無です。
とくにテスト環境の分離とデータの扱いは、実際の事故に直結する領域です。検証環境に本番データを持ち込み、そこが手薄で侵入された、という構図の事故は金融機関でも繰り返し起きています。「テスト環境だから」という理由で保護水準を落とす設計が見積もりに含まれていないか、発注側からも確認する価値があります。
<a id="fisc"></a>
FISC安全対策基準とは何か
金融系のシステム開発で必ず名前が出るのが、公益財団法人 金融情報システムセンター（FISC）が発行する**「金融機関等コンピュータシステムの安全対策基準・解説書」**です。金融機関等が情報システムを開発・導入・運用するにあたって必要と考えられる安全対策を、基準として示し、事例を交えて解説したものです。
押さえるべき事実は2つあります。
第一に、これは法令ではありません。 業界の実務基準であり、遵守が法的に強制されるものではありません。ただし金融機関の実務では事実上の参照基準として広く用いられており、金融機関が委託先を評価する際の物差しになることがあります。「法律ではないから関係ない」という理解は、取引の現場では通用しません。
第二に、改訂され続けています。 FISCは第14版を2026年3月25日に公表しており、この版ではAI・生成AIに関するガイドラインやレポートの内容を安全対策基準へ反映したこと、金融庁が2024年11月に公表した耐量子計算機暗号（PQC）に関する検討会報告書の内容（移行の留意点や対応時期など）を反映したこと、システム障害事例や各種ガイドラインの分析結果を反映したことが公表内容として示されています。第13版では経済安全保障推進法に関する改訂が反映されていました。
発注者にとっての実務的な意味は、「FISC準拠」という言葉だけでは何も確定しないということです。どの版の、どの項目に、どのレベルで対応するのかを決めなければ、見積もりの前提になりません。基準そのものは有償の刊行物であり、FISCの公式サイトから入手できます。自社が委託先の立場で求められる可能性があるなら、該当範囲を確認しておく価値があります。
あわせて、金融機関側に適用される金融庁の法令・指針等も、委託先である開発会社の作業に影響します。金融機関が監督上求められることが、契約を通じて委託先に流れてくる構造になっているためです。
<a id="outsourcing"></a>
外部委託先管理という壁
金融機関がシステム開発を外部に委託する場合、その金融機関には委託先を適切に管理する責任が残ります。委託したから責任も移る、とはなりません。この構造が、開発会社と発注側の双方に具体的な負担として現れます。
実務上、次のようなことが求められる場面があります。
- 委託先の選定理由と評価結果の記録
- 委託先における情報管理体制の確認（書面調査、必要に応じて訪問確認）
- 再委託の可否と、再委託先の把握
- 委託業務の品質・進捗のモニタリング
- 委託先で問題が発生したときの報告経路
- 契約終了時のデータ返還・消去の確認
このうち、発注前に最も揉めやすいのが再委託です。開発会社が一部の工程を協力会社に出すことは一般的ですが、金融系では「誰が実際に作業するのか」の可視化が求められる場合があります。見積もりが安い会社ほど再委託比率が高いこともあり、安さの理由が再委託にある場合、後から体制確認で問題になるという順序で表面化します。
したがって発注側の実務としては、価格の比較と同時に「この金額でどこまで自社の要員が担当するのか」を確認しておく必要があります。ここは金融系に限らない論点でもありますが、金融系では確認を求められる立場になる可能性がある分、重みが違います。
<a id="strength"></a>
「金融に強い」の中身を確かめる
提案書に「金融機関向けの豊富な実績」と書かれていたとき、その中身は会社によってまったく異なります。次の3つのどれなのかを分けて聞いてください。
タイプ1：勘定系・基幹に近い領域の経験。 口座や取引そのものを扱う領域。求められる水準は最も高く、経験のある人材は限られます。
タイプ2：周辺業務システムの経験。 顧客管理、申込受付、書類管理、営業支援など。金融機関の社内で使うが、資産に直接触れない領域。多くの中堅企業の案件はここに入ります。
タイプ3：金融機関を顧客に持っているだけ。 ウェブサイト制作やパンフレット、社内向けの一般的なツールを納めた実績。基準対応の経験は含まれない可能性があります。
この3つは「金融の実績」という同じ言葉で語られます。 自社の案件がタイプ2なのにタイプ1の会社に頼めば過剰投資になり、タイプ1なのにタイプ3の会社に頼めば体制確認で行き詰まります。実績の説明を受けたら、「その案件では、委託先としての体制確認を受けましたか」と聞くのが最も速い判別方法です。受けた経験があるかどうかで、話が具体になるか抽象のままかが分かれます。
<a id="questions"></a>
開発会社への質問10項目
商談でそのまま使える形にしています。
- 「弊社の案件は、御社の実績のどの類型に近いですか。勘定系に近いのか、周辺業務なのか」
- 「委託先として、金融機関から体制の確認や監査を受けた経験はありますか。直近ではいつですか」
- 「FISC安全対策基準について、どの版を参照していますか。今回はどの範囲に対応する前提の見積もりですか」
- 「この見積もりに、監査向けの文書作成の工数は含まれていますか」
- 「再委託は発生しますか。発生する場合、どの工程を、どの会社に出しますか」
- 「開発・テスト環境で、本番データを使う想定はありますか。使わない場合、テストデータはどう用意しますか」
- 「特権ID（管理者権限）の管理方法と、作業記録の保存期間を教えてください」
- 「障害が起きたときの連絡経路と、復旧目標時間はどう設定する想定ですか」
- 「契約終了時、預けたデータの返還と消去はどのように証明いただけますか」
- 「今回の要件で、御社として最もリスクが高いと考える箇所はどこですか」
10番は品質を測る質問です。リスクを具体的に名指しできる相手のほうが、実際に経験しています。 「特にありません」「問題なく対応可能です」という回答は、自信の表明ではなく検討していないことの表明である場合があります。
<a id="estimate"></a>
見積もりの読み方
金融系の見積もりを比較するときの観点は次の通りです。
- 前提とする基準の版と範囲が明記されているか。 「FISC準拠」の4文字だけで終わっていないか
- 監査・体制確認への対応工数が独立して計上されているか。 開発工数に溶けていないか
- テスト環境の構築とデータ準備が別項目になっているか
- 再委託の有無と範囲が書かれているか
- 保守・運用フェーズの体制（連絡経路と対応時間帯）が明記されているか
これらが書かれていない見積もりは、安いのではなく、その作業を含んでいない可能性があります。比較の前提を揃える一般的な考え方はシステム開発の費用・見積もりガイド、工程用語の読み解きはシステム開発工程の略語・用語集を参照してください。
<a id="failure"></a>
よくある失敗
- 「金融だから最高水準で」と丸ごと要求する。 対象と役割を切り分けないまま最高水準を要求し、必要のない領域まで費用が膨らむ。
- 基準の版と範囲を決めずに相見積もりを取る。 各社が違う前提で見積もり、金額差の理由が説明できない。
- 再委託の構造を確認しないまま安い会社を選ぶ。 後の体制確認で、実際の作業者が把握できていないことが判明する。
- 監査向け文書の工数を見込んでいない。 開発は終わったのに、体制確認に出す資料がなく、追加費用と時間が発生する。
- テスト環境に本番データを持ち込む前提で設計している。 検証環境の保護が手薄なまま個人情報を置き、事故時の被害が拡大する。
- 契約終了時のデータ返還・消去を決めていない。 乗り換えのタイミングで、預けたデータの所在が確認できない。
<a id="checklist"></a>
発注前チェックリスト
- 自社システムが勘定系に近いのか周辺業務なのかを切り分けた
- 取引先金融機関から体制確認を受ける立場になるかを確認した
- 扱うデータの種類（口座・取引・与信・一般個人情報）を特定した
- 参照する基準の版と対応範囲を自社として決めた
- 見積もり依頼時に、その前提を全社に同じ条件で提示した
- 監査向け文書の作成工数が見積もりに含まれるか確認した
- 再委託の有無と範囲を確認した
- テスト環境で本番データを使わない方針を確認した
- 特権IDの管理と作業記録の方法を確認した
- 障害時の連絡経路と復旧目標を決めた
- 契約終了時のデータ返還・消去の証明方法を契約に入れた
- 開発会社の実績がどの類型かを確認した
<a id="faq"></a>
よくある質問（FAQ）
Q. FISC安全対策基準は必ず守らなければならないのですか。 A. 法令ではないため、遵守が法的に強制されるものではありません。ただし金融機関の実務では参照基準として広く用いられており、委託先の評価に使われることがあります。自社が委託先の立場になるなら、「守る義務があるか」より「取引先から確認されたときに答えられるか」で考えるほうが実務的です。
Q. 金融機関向けではなく、金融機関を顧客に持つ事業会社のシステムです。関係ありますか。 A. 金融機関から業務を受託し、その業務に金融機関の顧客データが含まれるなら、委託先管理の対象になり得ます。関係の有無は「金融機関向けか」ではなく「金融機関の業務・データに触れるか」で決まります。
Q. 見積もりが3倍違います。高いほうが正しいのですか。 A. 必ずしもそうではありません。高いほうが過剰な水準を前提にしている可能性も、安いほうが必要な作業を含んでいない可能性も、どちらもあります。前提を揃えて再提出してもらうのが唯一の判別方法です。
Q. 開発会社に「FISCに準拠しています」と言われました。それで十分ですか。 A. 不十分です。どの版の、どの項目に、どのレベルで対応するのかを確認してください。基準は改訂され続けており（第14版は2026年3月25日公表）、参照している版が古い場合もあります。
Q. 中堅の開発会社でも金融系の案件は受けられますか。 A. 領域によります。周辺業務システムであれば、体制と文書化の準備ができていれば十分に対応可能な範囲です。逆に勘定系に近い領域は、経験と要員の確保が難易度の中心になります。自社の案件がどちらかを先に判定することが、無駄な相見積もりを減らします。
Q. 生成AIを金融系の業務に組み込みたいのですが、注意点はありますか。 A. FISC第14版ではAI・生成AIに関する内容が安全対策基準に反映されています。加えて、入力データの取り扱い、出力の検証、記録の保存といった論点が、通常のシステム以上に問われます。導入可否そのものから整理したい場合はAI導入可否アセスメントの枠組みが使えます。
Q. 相見積もりの前に、自社だけで準備できることはありますか。 A. あります。扱うデータの棚卸し、体制確認を受ける可能性の有無、必要な保存期間の確認、社内の決裁者の特定。この4つは開発会社がいなくても進められ、進めておくと見積もりの精度が上がります。
<a id="cta"></a>
発注先の選定で迷ったら
金融系のシステム開発では、発注側が要求水準を決められるかどうかが、費用と品質の両方を左右します。決められなければ、開発会社の提案する水準がそのまま前提になります。それが過剰でも過少でも、負担するのは発注した側です。
そして要求水準の決定は、技術判断ではありません。自社のシステムが金融機関の業務のどこに位置するのか、誰から何を問われる立場になるのか——この整理は事業側にしかできません。
GXOは特定パッケージの販売元ではないため、「この案件にこの水準は過剰ではないか」「この見積もりは何を含んでいないのか」を発注側の立場で点検できます。
- 受け取った見積もりの前提が妥当か見てほしい → 見積もりセカンドオピニオン
- どの会社に頼むかの判断軸から整理したい → システム開発会社の比較・選定
- 要件と要求水準そのものを整理したい → 要件定義・業務フロー整理の相談
- 体制・運用面のセキュリティから相談したい → セキュリティ運用伴走
- 開発そのものを相談したい → DX・システム開発
「金融だから高い」で止まらず、何にいくらかかっているのかを分解する。その作業から、ご一緒します。
参考（一次ソース）
- FISC「金融機関等コンピュータシステムの安全対策基準・解説書」第14版の公表について（2026年3月25日）（一次・発行団体公式）
- 公益財団法人 金融情報システムセンター（FISC）（一次・発行団体公式）
- 金融庁「法令・指針等」（一次・監督官庁）
- 金融庁「金融分野におけるサイバーセキュリティ対策について」（一次・監督官庁）
- IPA「情報システム・モデル取引・契約書」（一次・公的機関。委託契約の考え方）
※FISCの安全対策基準および金融庁の指針類は改訂されます。本記事は発注側が要求水準を決めるための論点整理であり、個別案件における基準の適用範囲や遵守状況の判定を行うものではありません。自社が委託先としてどこまで求められるかは、取引先金融機関および契約書の記載をもってご確認ください。
