2026.08.29 Webシステム

金融システムの運用とは？24時間365日監視・夜間バッチ運行と委託範囲の決め方

金融システムの運用を委託しようとして見積りを取ると、各社の金額が二倍も三倍も開くことがあります。その主因は、監視だけを想定した社と、夜間バッチの異常時にリランまで踏み込む前提で組んだ社が、同じ「運用保守」という言葉で並んでいる点です。金融の運行は、止められないサービス時間、日次で確実に終わらせる夜間バッチ、そして障害が社外への報告に直結する構造という三点で、一般の業務システムとは条件が違います。この記事では金融特有の運行要件から運用業務を分解し、委託範囲を三段階で切り分ける方法と、内製に残す機能の線引きまでを2026年8月時点で整理します。

まとめ：委託範囲を三段階のどこで切るかで体制も費用も決まる

金融システムの運用とは、稼働中のシステムをサービス時間内で止めずに動かし、夜間の処理を翌朝までに終わらせ、異常が起きたときに定められた手順で復旧と報告を回す一連の営みです。機能を追加したり不具合を直したりする保守とは、責任の重心が違います。運用が守るのは「今日の処理が今日終わること」であり、保守が守るのは「システムが要件に合い続けること」です。

委託の設計は次の順で固めます。第一に、自社の運行カレンダーを書き出して、サービス時間・バッチの窓・締めの日（月末、年度末、給与日）を可視化すること。第二に、委託範囲を「監視と通報まで」「定型復旧とリランまで」「原因調査と暫定対処まで」の三段階のどこで切るかを決めます。第三に、切った線の外側、つまり自社が引き受ける判断と当局対応の体制を先に確保しておくこと。この三つが決まってから見積りを取れば、各社の金額は同じ土俵で比べられます。

逆に、範囲を決めないまま「運用保守一式」で相談を始めると、安い提案は監視だけ、高い提案は二次対応込みという形で並び、どちらが妥当か判断できない状態になります。金額差の正体は品質ではなく範囲であることが大半です。

金融システムの運用が一般の業務システムと別物になる三つの前提

まず、金融の運行が何によって縛られているのかを押さえます。業界横断の要件は金融・公共・流通系のシステム開発における業界特有の考え方にまとめてありますが、稼働後の運用に絞ると、効いてくるのは以下の三点です。

金融システムではサービス時間を止められず夜間バッチが日次で回る

金融のオンラインサービスは、ATM、インターネットバンキング、決済ネットワークとの接続を含めて、ほぼ終日稼働しています。全国銀行データ通信システムが24時間365日の即時振込に対応して以降、「夜間は止まっている」という前提はもう置けません。停止を伴う作業は、限られた計画停止の枠に押し込むことになります。

その一方で、勘定系には日次の締め処理が残っています。当日の取引を確定し、残高を更新し、帳票と外部連携ファイルを作る夜間バッチは、翌朝のオンライン開始までに終わらせる必要があります。ここが金融の運行を難しくする構造です。オンラインを止めないまま、バッチの窓を守る。両立させるために、運用側は処理の依存関係とリカバリ順序を手順として持っておかねばなりません。勘定系そのものの構造は勘定系システムの三層構造と情報系との違いで扱っているため、本記事では運行の側面だけを追います。

金融システムの障害が社外への報告と当局対応に直結する運用上の理由

一般の業務システムなら障害の影響は社内と取引先に閉じますが、金融は違います。顧客サービスに影響が出た障害は、業法と監督指針に基づいて当局へ障害発生等報告書を提出する対象になり、金融庁は受領した報告をもとに復旧状況の確認やヒアリングを行い、真因と再発防止策の報告を求めます。金融庁が公表している「金融機関のシステム障害に関する分析レポート」は、この枠組みで集まった報告を集計したものです。

この構造は運用手順に直接跳ね返ります。障害を検知したとき、運用担当が最初にやるのは復旧作業だけではありません。影響範囲（どのサービスが、何件、いつから）を確定し、社内の報告ラインへ上げ、広報と当局対応の判断ができる人へつなぐところまでが一連の作業になります。時刻の記録精度も問われます。検知時刻、一次報告時刻、影響開始時刻、復旧時刻を後から再構成できるよう、運用ログと対応記録を残す運びが前提です。委託先を選ぶときは、この記録と報告の作法を運用フローに組み込めるかを見ることになります。

FISC安全対策基準が稼働後の運用フェーズの統制にまで及ぶ範囲

金融情報システムセンター（FISC）が発行する「金融機関等コンピュータシステムの安全対策基準・解説書」は、2026年3月に第14版が公表されています（版と時期は同センターの刊行物一覧で確認）。この基準は設備・技術・運用の各面にわたる対策項目を持ち、開発時だけでなく稼働後の運用統制にも踏み込みます。入退室と操作権限の管理、作業記録の保存、外部委託先の管理といった項目が該当します。運用基準を含む基準全体をどこまで自社に当てはめるかはFISC安全対策基準の位置づけと対応範囲の決め方で扱っています。

加えて、サイバーセキュリティ面では金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」が令和6年10月4日から適用され、令和7年7月に一部改正されています。検知・対応・復旧、そしてサードパーティリスク管理の着眼点が示されており、運用を外部へ委託する場合は委託先の管理態勢まで説明を求められる形になりました。基準の条文を丸暗記する必要はありませんが、「運用手順が第三者に説明できる形で残っているか」という問いは、監査でも当局対応でも同じように飛んできます。

金融システムの運用業務を監視・バッチ・変更管理の実務単位で分解する

前提を押さえたうえで、日々何をしているのかを分解します。業種を問わない運用業務の一覧と保守との一般的な違いはシステム運用の業務範囲と委託判断で整理しているので、ここでは金融の現場で重量が増える部分に絞ります。

金融システムを支える24時間365日の監視項目とオペレーション当番

監視は、リソース（CPU、メモリ、ディスク、回線）、プロセスとサービスの死活、業務指標（取引件数、応答時間、エラー率）、そして外部接続の疎通を見ます。金融で特に見るのは、決済ネットワークや他社システムとの接続状態です。自社が正常でも接続先が落ちれば取引は通りません。

当番の組み方は、有人常駐と、日中有人・夜間オンコールの二通りが基本です。前者は検知から着手までが早い代わりに人数が要ります。後者は費用を抑えられますが、呼び出しから接続までの時間をどう約束するかが論点になります。夜間の一次対応をオンコールで回すなら、呼び出し後の応答時間（たとえば15分以内に接続）と、その時間帯に踏める操作の範囲を、あらかじめ手順として書いておくことです。

夜間バッチの運行管理でジョブ異常時のリラン可否を判断する基準

夜間バッチの運行は、金融の運用でもっとも神経を使う領域です。数百から数千のジョブが依存関係を持って並び、前段が終わらなければ後段が動きません。遅延が積み上がると翌朝のオンライン開始に間に合わなくなるため、運用側は「いま何分遅れているか」ではなく「このまま行くと開始時刻に間に合うか」を見ます。

ジョブが異常終了したときの判断は、次の三種類に分かれます。単純リラン（そのまま再実行してよいもの）、リカバリ後リラン（中間データを削除する、コミット済み分をスキップするなどの前処理が要るもの）、そして業務判断が必要なもの（データ不整合の疑いがあり、業務部門の確認なしに進められないもの）です。この三分類をジョブ単位で事前に定義できていれば、夜間の判断は手順に落ちます。定義がなければ、毎回誰かを起こすことになります。委託範囲を決める作業とは、実質的にこの三分類のどこまでを委託先の判断に委ねるかを決める作業です。

金融システムの本番変更に使える作業枠とリリース手順の統制方法

金融の本番変更は、申請、承認、リハーサル、実施、確認、記録という流れを踏みます。ここで運用側が持つのは、変更の窓（いつなら入れられるか）の管理と、切り戻し手順の妥当性確認です。月末月初、給与日、決算期など、業務上の繁忙とぶつかる日には原則として変更を入れません。年間の運行カレンダーに変更禁止期間を先に置き、そこから逆算してリリース計画を組むのが実務です。

切り戻しについては、「戻せること」と「戻す判断ができること」を分けて確認します。技術的に戻せる仕組みがあっても、深夜に戻す判断を誰が下すのかが決まっていなければ、現場は判断待ちで止まります。判断者と判断基準（この時刻までに復旧の見込みが立たなければ戻す、など）を変更手順書に書き込んでおくことです。

金融システムの運用と保守の境界を作業承認の所在で明確に切り分ける

運用と保守は、契約上ひとまとめにされることが多いものの、作業の性質は異なります。運用は決められた手順を確実に回す仕事で、成果は「何も起きなかった」という形で表れるものです。保守はアプリケーションに手を入れる仕事で、法改正対応、不具合修正、ミドルウェアのバージョン更新などが該当します。

境界が曖昧になりやすいのは、暫定対処の場面です。障害の原因がアプリケーションのバグだと判明したとき、パッチを当てるのは保守の領域ですが、当てるまでの間データを手当てする作業は運用側の担当です。この手当ての範囲（どのテーブルに、誰の承認で、どこまで触れるか）を契約前に決めていないと、障害のたびに責任の押し付け合いが起きます。境界は「システムに手を入れるかどうか」ではなく「その作業の承認をどこで取るか」で引くほうが、現場では機能します。

金融システムの運用委託範囲を契約前に対応レベル別の三段階で切り分ける

ここからが本題です。金融システムの運用委託は、次の三段階のどこで切るかで、体制も費用も契約の形も変わります。

段階1：監視と一次通報だけを委託する場合の適用条件と対応範囲

委託先は監視ツールのアラートを受け、あらかじめ定めた連絡先へ通報します。システムへの操作は行いません。夜間も人が見ている状態を作れるため、検知の遅れは防げます。

この段階が向くのは、システムに触れる作業を自社の要員で回せる体制がすでにあり、夜間の「見張り」だけが不足しているケースです。逆に、通報を受けた後に動ける人が自社にいなければ、深夜に電話が鳴るだけで復旧は進みません。段階1を選ぶ条件は、通報先の要員が自宅から接続できる環境（回線、端末、権限）を持っていることに尽きます。この条件を満たさないまま段階1で契約すると、費用は抑えられても復旧時間は縮まりません。

段階2：定型復旧とリランまで委託する場合の手順整備と更新責任

手順書に書かれた範囲で、委託先が実際にシステムを操作します。プロセスの再起動、ジョブの単純リラン、ディスク領域の解放、待機系への切り替えといった作業が対象です。金融で段階2を成立させる鍵は、前述したジョブの三分類が定義されていることです。「この異常コードならリラン可、このコードは要連絡」という粒度まで落ちていれば、委託先は迷わず動けます。

段階2でよくつまずくのは、手順書の陳腐化です。システム変更のたびに手順書を更新する担当を決めておかないと、半年後には現物と合わない手順が残ります。手順書の更新責任を委託先に持たせるか、自社に残すかは契約時に明示しておく事項です。実務では、委託先が起案し自社が承認する形が回りやすいでしょう。

段階3：原因調査と暫定対処まで委託する場合の人材要件と権限範囲

ログ解析、原因の切り分け、暫定対処の立案と実施までを委託します。アプリケーションの内部構造を理解している要員が必要になるため、開発を担った会社か、引き継ぎに時間をかけた会社でなければ機能しません。

段階3を選ぶ際の判断軸は、費用ではなく人材です。金融の業務知識とシステム構造の両方を理解した要員を自社で維持できるなら、段階2で足ります。維持が難しい、あるいは要員が一人に集中していて属人化しているなら、段階3へ寄せて委託先に厚みを作らせるほうが、事業継続の面では堅くなります。ただし段階3でも、当局への報告と顧客対応の判断は委託できません。後述する内製の三機能に該当するためです。

金融システム運用の体制人数と委託費用の目安を勤務形態から見積もる

費用の見当をつけるには、まず必要な人数を積み上げます。24時間365日を有人で埋める場合、一つの席を常時埋めるには交代要員を含めて5名前後が要ります。1日3交代で年間を通すと、休暇と教育の時間を含めて概ねその規模になるためです。二人体制の常時監視なら10名規模、夜間だけオンコールに落とせば必要人数は大きく下がります。

委託段階	作業範囲	体制の目安
段階1	監視と通報	共有監視センター
段階2	定型復旧とリラン	専任1〜3名＋夜間当番
段階3	原因調査と暫定対処	専任3名以上＋開発要員

金額は対象システムの規模、監視対象の台数、サービス時間、そして委託先が共有センターを使えるかどうかで大きく動きます。共有型の監視サービスなら月額数十万円台から組める一方、金融固有の手順を持つ専任体制を敷けば月額数百万円の水準になります。見積りを比べるときは総額ではなく、段階と体制と応答時間の三点を揃えたうえで単価を見てください。比較を成立させる手順は運用保守会社の相見積りを比較できる形に揃える方法で詳しく扱っています。

金融システム運用で内製に残す機能と外注へ寄せる判断条件を整理する

ここからは判断の話です。金融システムの運用をどこまで外に出せるのかについて、条件を付けて言い切ります。

金融システム運用で内製に残す判断権限・当局対応・業務知識の三機能

第一に、サービスを止める判断とサービスを戻す判断です。「このまま運転を続けるか、縮退させるか、停止するか」の決定は顧客と事業に直結するため、委託先に委ねる性質のものではありません。委託先ができるのは、判断材料を短時間で揃えて上げることまでです。

第二に、当局と顧客への説明責任です。障害発生等報告書の内容、公表の要否とタイミング、再発防止策の約束は、金融機関自身が負います。委託先の作業ミスが原因であっても、対外的な責任の所在は変わりません。したがって、社内に報告文書を書ける人が必要です。

第三に、業務の意味を理解している人材です。「このテーブルのこの値がずれると、翌日の何に響くか」を判断できる人がいなくなると、委託先から上がってきた選択肢の妥当性を評価できなくなります。運用を全面的に外へ出した組織が数年後に困るのは、費用ではなくこの評価能力の喪失です。人数は多くなくてかまいませんが、ゼロにはできません。

金融システム運用を外注へ寄せる三条件と、委託してはいけない場面

外注へ寄せてよい条件は次の三つです。（1）夜間・休日の要員確保が慢性的に困難で、当番が特定の個人に偏っている。（2）運用手順が文書化されており、異常時の分岐が判断可能な粒度まで落ちている。（3）自社に判断権限を持つ担当と、報告文書を書ける担当が確保されている。このうち二つ以上が該当するなら、段階2以上の委託へ寄せる価値があります。特に（1）に該当する状態を放置すると、属人化した要員の離職がそのまま運行リスクになります。

逆に、寄せてはいけない場面もはっきりしています。手順が文書化されておらず、異常時の判断が現場の記憶に依存している状態では、委託しても品質は上がりません。委託先は書かれていないことを実行できないためです。この状態で外に出すと、契約上は委託しているのに実務は自社が回すという二重の負担が生まれます。順序としては、まず手順の棚卸しと文書化を先に行い、そのうえで委託範囲を切ってください。棚卸しを外部の支援で進めてから運用を移管する、という二段構えも現実的な進め方です。

もう一つ、システム更改の直前も寄せどきではありません。1年以内に基盤の更改やクラウド移行が控えているなら、現行環境の運用移管に費やす引き継ぎコストは回収できません。更改後の構成を前提に委託設計を組むほうが、結果として安く付きます。

金融システムの委託先を見極めて契約前に確認する四つの評価項目

委託先を評価するときに見るのは、金融の実績件数そのものよりも、次の四点です。第一に、障害時の記録と報告の様式を持っているか。当局報告に耐える時系列記録を標準の成果物として出せる会社かどうかは、提案書の中の報告サンプルで判別できます。第二に、手順書の更新プロセスを提案に含めているか。第三に、要員の交代時に引き継ぎをどう担保するか。第四に、再委託の有無と、再委託先の管理をどう説明するかです。サードパーティリスク管理の観点から、この点は自社が当局へ説明する対象になります。

契約条件では、応答時間と復旧目標を分けて定義してください。「1時間以内に復旧」という約束は、原因がハードウェア故障か外部接続の障害かで守れる確度が変わるため、現実には応答時間（連絡から着手まで）と、原因類型ごとの目標時間に分けて書くほうが機能します。守れない約束を契約書に載せても、障害時の紛争が増えるだけです。

体制の設計から手順の棚卸し、移管までを一括で相談したい場合は、保守運用・内製化支援のサービスで対応しています。監視だけを任せたい段階から、将来的に自社へ運用を戻す前提の内製化支援まで、範囲を区切って組み立てられます。

よくある質問

運用と保守は分けて発注したほうがよいですか？

同じ会社にまとめるほうが、障害時の切り分けは速くなります。運用と保守を別会社にすると、原因がインフラかアプリかで判断が割れたときに調整の時間が生じるためです。ただし、保守を開発会社が担っていて実績も十分なら、運用だけを別に切り出す形でも支障はありません。その場合は、両社が同じ障害記録を見られる環境を先に用意しておいてください。

24時間365日の体制を自社で組むと何人必要ですか？

一つの席を常時埋める前提で、交代と休暇を織り込むと5名前後が目安です。二人体制なら10名規模になります。ただし人数が揃っても、夜間に判断できる人が同時に確保できていなければ体制としては機能しません。人数の議論と併せて、夜間の判断者をどう回すかを設計してください。

夜間バッチが遅延したとき、委託先はどこまで判断できますか？

契約と手順書に書かれた範囲だけです。実務では、ジョブごとに「単純リラン可」「前処理後リラン可」「要連絡」の三分類を定義し、前二者を委託先の判断に委ねる形が回りやすい構成になります。分類が未定義のジョブは自動的に「要連絡」として扱う運びにしておくと、想定外の操作を防げます。

FISC安全対策基準は外部委託先にも及びますか？

基準は金融機関を対象としていますが、外部委託先の管理は金融機関側の対策項目に含まれます。したがって、委託先が基準の項目に沿った運用をしているかを金融機関が確認し、その確認自体を記録として残す形になります。委託先に「FISC準拠」を求めるだけでは足りず、どの項目をどう満たしているかを説明できる資料を受け取っておくことです。

クラウド移行後も運用の考え方は同じですか？

監視対象と責任分界点は変わりますが、運行カレンダーとバッチの窓を守るという骨格は変わりません。変わるのは、基盤側の障害に対して自社が直接手を出せない範囲が増える点です。その分、クラウド事業者の障害情報をどう受け取り、どの時点で縮退運転へ切り替えるかの判断基準を、手順として先に決めておく必要が生じます。