logo
Insight
経営研レポート

金融機関におけるBCP策定のポイントと
富士山噴火への備え

2024.01.05
金融政策コンサルティングユニット長/パートナー
大野博堂
heading-banner2-image

本年1月1日、北陸地方を震源とする新たな大規模震災が発生した。未だ被害の全容は明らかとなっていないものの、直下型地震としては過去最大規模のマグニチュードを記録するなど、調査が進むにつれ、被害は拡大の様相を見せている。被害に遭われた方やご家族のご心労を拝察するとともに心よりお見舞い申し上げたい。

筆者も発災当日、新潟と群馬の県境にある山間地で大きな揺れに見舞われた。下山後に乗車予定の新幹線は運行停止となり、大規模な交通混乱に巻き込まれる中、移動はともかく宿泊施設の確保が出来ない。結果、帰京予定は繰り延べざるを得なかったものの、動き始めたローカル線で高崎まで移動し、レンタカーを確保することで何とか東京まで辿り着いた。

現下の金融機関は、コロナ禍における事業者向けの緊急融資対応がほぼ終息、といったタイミングでありながら、とりわけ被災地を営業地盤とする金融機関の中には営業店の閉鎖を余儀なくされるだけでなく、新たな被災者対応が生じることにもなった。政府からも、地元金融機関には、本人確認が前提ではあるものの、キャッシュカードや預貯金通帳がなくとも預貯金の払い出しを行うよう改めて下命されてもいる。ただし、被災地の金融機関では、行職員自らが被災するなどのほか、公共交通機関が停止したり、道路事情が悪化するなどで、そもそも職場への移動に難を抱えることとなった。つまり、店頭業務に従事する要員の確保自体が課題として認識されたともいえる。

本来、こうした緊急事態において有用とされるのがいわゆるBCP(Business Continuity Plan:事業継続計画)である。BCPはリスク種別ごとに定義され、緊急時における職員の行動をコントロールしたり支援する手引書として位置付けられる。ただし、過去の新潟中越沖地震、新潟中越地震でも課題となったのが、BCPの実効性である。手続きが文書化されていたとしても、有用なものでなければ絵に描いた餅となってしまう。そこで本稿では、金融機関におけるBCP対応の要諦について改めて整理することとしたい。

BCP、IT-BCP、サイバーセキュリティ対策の位置付け

サイバー犯罪を含めた外部、内部からの攻撃や情報搾取への備えは、BCPの構成要であるIT-BCP(CP)対応リスクの一類型として既に整理されているものだ。BCPで対象とするリスクについては、FISCのCP策定ガイドラインや金融検査マニュアルなどで定義されている。ただし、可視化された状態での整理がないために、どこまでをBCPが、何をCPがカバーするリスクなのか、といった部分で様々な解釈が生まれている。

図1はNTTデータ経営研究所で定義したBCP、IT-BCP、さらにはサイバーセキュリティ対策手順の構造である。

(図1:BCPとIT-BCP、サイバーセキュリティ対策手順の位置付け)

content-image

(出典:NTTデータ経営研究所作成)

BCPが有事の際の金融機関全体の行動基準や手順を定めた計画文書および手順書であるのに対し、IT-BCP(もしくはCP)はBCPで想定するリスクのうち主にシステムリスクを対象とした行動手順を定めた手順書として位置付けられる。さらに、サイバー攻撃などへの対応手順は、IT-BCP(CP)で定義する対応手順の一つとして定義されるとの理解だ。

他方、金融機関の対応状況をみると、BCPは存在しているものの、IT-BCP(CP)に該当するものが存在していなかったり、中には「システム復旧マニュアル」で代替している場合もある。これは、いわゆる勘定系の共同センターを利用している中小規模金融機関に特にみられる傾向だ。こうした金融機関にインタビューすると、「既にBCPは存在する」とは回答してくれはするものの、より深く話を聞くと、どうやら「共同センターにおける復旧手順」を指して自行庫のBCPであると誤認しているであろう例のほか、「共同センター側のBCPが自行庫のBCPを代替する」と解釈している極端な例も筆者らのヒアリングでは確認されている。

システム復旧マニュアルにしても、システムエンジニアしか読み解けないようなコマンドが羅列されたシートしか用意されていないケースもあり、外形的な手順書として整備されていない金融機関もある。ただ、金融機関の多くが基幹システムをアウトソースもしくは共同利用している現状においては、システム対応手順の策定も委託先ベンダーに依存しているケースが多いことだろう。必ずしもそのような対応が誤りだとは言えないまでも、有事に際しては迅速な判断が求められ、判断の拠り所となるマニュアルが必要とされるはずだ。また、手順書などを構造化して整理しておかない限り、更新作業もままならず、さらにはBCP訓練やサイバーセキュリティ演習を実施しようにも難しいだろう。

BCPのあるべき構造

BCPの実装手法としては二つのパターンが存在する。シナリオベースとリソースベースだ(図2)。

シナリオベースとは、リスクごとに、異なる発生事象をパターン化・モデル化し、それぞれを起点に対応手順を紐付けて定義するBCPの策定手法である。リスクごとに異なるシナリオを策定する必要があるものの、初動からの対応手順をパターン化して定義しやすい。ただし、例えば大地震を特定リスクとして取り上げた場合、「どこで起きるのか」といった視点で、リスクの発生ケースを網羅的に捕捉し、対応手順を詳細に分解定義する必要に迫られる。また、リスクごとに手順書を分冊化する必要があるなど、ドキュメントの策定量が増加する傾向がある。

リソースベースでは、「本店」「システムセンター」「電力」など、インフラや特定リソースが利用不可となった場合を起点に、対応手順を定義するBCPの策定手法であり、とかく規格化が志向される英国が音頭を取って浸透してきたモデルである。リスクごとに複雑化する被災パターンを数多く想定する必要がなく、対応手順を定義しやすいのが特徴だ。ただし、「何かが壊れた」「何かの機能が損なわれた」といったリソースに影響が生じた時点から対応手順が定義されることから、本来必要となる情報収集段階などのシーンにおける初動部分の手順定義が漏れる傾向がある。例えば、「地震は発生したが重要な設備は壊れていない」「地震が発生し、重要な設備が使えなくなる寸前」「地震が発生したが、重要な設備が完全に壊れたかどうかわからない」など、リソース自体が直接の影響を受けておらず、その後の判断に迷うケースが考えられるほか、リソースの損壊程度を把握するための事前対応手順が定義されていないケースがみられる。これはパターン化されたシンプルな記述でスマートな形式ではあるものの、実効性を確保する上での対応の難易度が高い手法ともいえる。

(図2:シナリオベースとリソースベースの比較)

content-image

(出典:NTTデータ経営研究所作成)

BCPのドキュメント構造とIT-BCP (CP)との連携

まずは、金融機関全体のBCPのドキュメント構造について解説する。シナリオベースを前提に、BCPのドキュメント構造を示したものが図3である。

(図3:BCPの検討範囲とIT-BCP(CP)との連携イメージ)

content-image

(出典:NTTデータ経営研究所作成)

金融機関全体のBCPのうち、最も上位に位置づけられるのが「BCP共通編」である。共通編では、金融機関として認識する外部環境変化、対象とするリスク、リスク発現時の対応態勢、平時の組織と災害対策本部の関係、といった共通的なことがらを記載することとなる。なお、BCPにはBCM(Business Continuity Management:事業継続マネジメント)の概念をあわせて組み込むことが求められる。BCMは事業継続を実効的なものとするための包括的なフレームワークやマネジメントプロセス全体を指すものだ。そこで、教育計画や演習計画、更新の在り方などについても共通編で記載する。

そのうえで、リスクごとに個別手順書を作成していく。図3では参考として3つのリスクを取り上げている。「大規模震災編」「大規模システム障害編」「パンデミックリスク編」である。例えば、大規模震災が発生した際、共通編は利用せず、個別手順書である大規模震災編のみを参照し、該当する有事対応手順を一つ一つこなしていく、といった利用が考えられる。共通編については、その時点で残置されている課題について整理し、記載することで、今後の対策についてのおおまかなロードマップを記載するべきである。また、金融機関内部での職員教育の教材として利用したり、あるいはBCPの全体像を整理・把握するためのツールとして位置付ければ良い。

BCPの策定に際して留意すべき形式性と実効性の観点

BCP策定に際しては、何を定義すべきか、といった観点での形式性と、文言としては定義されているものの、果たしてその手順で有事の際の有意な対応が採れるのか、といった観点での実効性が求められている。

(図4:BCPの形式性と実効性のチェック項目)

content-image

一般的には、内閣府のBCP策定ガイドラインやFISCのコンティンジェンシープラン策定のための手引書などを参照し、記載項目に漏れがないよう留意する。特に実効性の観点での対応では、他者事例や過去の震災など実際のインシデントを通じて得られた知見を踏まえ、5w1hを意識した手順を策定する必要がある。なお、実際の某金融機関におけるBCPの記載例と、当局における具体的な指摘ポイントを図4として例示している。当該金融機関ではBCPにおいて「システムセンターの被災状況により、本店に災害対策本部を設置する。災害対策本部は、被災状況を確認し、対象システムが通常通りに動作しているかの確認、および対象業務の続行が不可能となるおそれがあると判断した場合、BCPの発動を決定する」と記載していた。ところが、後に金融当局から次のような指摘を受けている。例えば、「対象システムの正常動作の維持および対象業務の続行が不可能となるおそれがあると判断」するのが誰なのかが不明であり、緊急時対応への着手が遅延することが懸念される」といったものだ。これらの指摘からも、より具体的な手順の必要性が理解出来ることだろう。

非常時優先業務には要員参集が欠かせないが・・・

今回の能登半島地震も含め、これまで発生した大規模震災では、交通機関の麻痺や道路事情の悪化など、非常時に参集要員が拠点まで辿り着かない、といった例が確認されている。平日の日中帯なら参集の必要はなく、そのまま非常時優先業務へのスムースな移行が可能とはなるものの、世の中のBCPの多くで夜間や休祭日における発災を想定したプランが用意されていない。これはサイバーセキュリティ対策にも同じことが言える。金融庁が昨年から預金取扱金融機関を対象に実施しているサイバーセキュリティ・セルフアセスメントをみると、例えば、夜間に大規模なサイバー攻撃を受けたとしても、拠点に参集出来ない場合を想定した有意な対応手順が定義されていない例が多分にみられることが判明している。つまり、初動着手の遅延が生じ、ひいては金融機関の事業継続に影響を与えるばかりでなく、顧客への影響を拡大させてしまう可能性が否めない。

こうしたケースを念頭に、代表的なリスクへの対処方針を検討するうえでは、要員参集の可否や容易性を念頭に、リスク事象発生パターンを、平日の日中帯、夜間、休祭日、といったように峻別のうえ、現実的な要員参集の手法を定義しておく必要がある。また、どうしても要員参集自体が困難になりそうだ、という場合には、あらかじめ重要拠点の周囲に緊急時対応を担う最低限の要員を住まわせ、まずは初動対応にあたってもらう、という方策が考えられる。こうした考えは、政府や東京都庁では従来より実装されてきた半ば当たり前の発想ではあるものの、なかなか民金企業には浸透してこなかったものでもある。とりわけ重要な機能を担う金融機関の本店では、最低限の要員を徒歩圏に居住させるための宿泊設備や機能の確保を検討する必要があるだろう。

BCPの想定リスクとして富士山噴火にも今から備えが必要

このところ、我が国では各地で火山活動が活発化している。そもそも、東日本大震災以降、国内外の研究者から国内における火山噴火リスクが増大する可能性がある点について警鐘が鳴らされてきており、政府や東京都でも富士山噴火による被災想定や対応計画を定期的にアップデートしている。

国内に存在する火山は数多いものの、人口が集中する首都圏に最も脅威を与えるのは富士山だろう。富士山の最後の噴火は1707年にまで遡る。この時、当時の江戸で4~5センチの火山灰の降灰が記録されている。

これまでに政府が公表している富士山噴火時の降灰シミュレーションの結果は次のようなものだ。

  •  静岡県御殿場市付近では1時間に1センチから2センチ程度の灰が降り続き、最終的に降灰量は1メートル20センチに達する
  •  神奈川県横浜市では1時間に1ミリから2ミリ程度の灰が断続的に降り、最終的に10センチ程度に達する
  •  東京都新宿区では、噴火直後には降灰は見込まれない。ただし、噴火から13日目以降に1時間に最大1ミリの降灰が見込まれ、最終的に1.3センチほどに達する

これらは過去の代表的なシミュレーション結果を参考掲記したものだが、天候や風向きなどによっても当然に状況は大きく変わる。ただし、東京都ではかねて、富士山噴火時に都内で1センチの降灰が観測された場合、火山灰の除去に4日程度を要すると公表してきた。鹿児島のように、火山灰があたかも生活ゴミのように取り扱われ、日々ゴミ収集車によって回収されるような環境であればともかく、都内で1センチの降灰があっただけでも大混乱だ。なお、最近政府では、富士山噴火時の降灰の処分方法として、海洋投棄を行う方針であると示している。ただし、火山灰は水を含むとセメントのように固まり、そのままでは水に流れず溶けこまない。火山灰を洗い落とそうと水をかけても「雪にようには融けず」、かえって処理に難渋するため、住民生活は混乱に陥ることが予想される。海洋投棄の場合も、周辺環境を大きく変容させたり思わぬ影響を与えるであろうことは想像に難くない。こうしたケースを念頭に、自行庫周辺に降り積もった火山灰の処置について、BCPの中でも定義しておくことが望ましい。大切なのは、水への親和性の低さを念頭に、いたずらに水で洗い流そうとしないことを行職員に浸透させることだろう。

火山噴火時には「内燃機関」は全て機能停止に陥る

また、自家用車、タクシー、バス、航空機といった外気吸入路にフィルターを有する内燃機関の多くが運行停止を余儀なくされ、物流や人の移動に甚大な影響を与えることが予想されている。鉄道についても、1ミリ程度の降灰で運行が出来なくなるとも言われており、そもそも通勤自体が困難になるだろう。なお、日々、桜島の噴火による降灰に見舞われている鹿児島では、鉄道には降灰対策が施されており、ちょっとやそっとの降灰であっても運行が可能だ。ただし、これは特別の対策が車両やレールに施されているからこそであることを忘れてはならない(九州新幹線も降灰対策がなされている)。九州以外の国内各地では、ほぼ降灰対策などなされていないのが実態なのだ。

BCPに定義する火山噴火時の参集方法としても、降灰による影響を念頭に、内燃機関が使えないことを前提に、より現実的な参集ルート、参集対象者などを想定しておく必要があるだろう。特に留意すべきは現送手法と現金確保の手段だ。現金輸送車の運行に支障が生じることに加え、外部電源の供給が途絶えてATMによる出金が停止を余儀なくされる可能性がある。他方、営業店には現金の払い戻しを求めて顧客が殺到する可能性が否めない。これらを念頭に、どの時点で現金ポジションを厚めに確保するか、といった具体的な方策を用意しておかねばならない。

火力発電所の機能麻痺が想定され、営業店のシャッターも開かない

5センチの降灰などタカが知れている、といって馬鹿には出来ない。なにしろ、火力発電所の多くでは、2センチから4センチ程度の降灰で機能停止に陥るとされているのだ。現在我が国で主流となっているガスタービンによる火力発電では、電気の絶縁のために用いる碍子に積もった灰でスパーク現象が生じることが懸念されるほか、空気取り入れ口のフィルターが火山灰によって目詰まりを起こしたり、タービンに取り込まれた火山灰がガラス化して内部に固着するなどし、発電能力を低下させることが懸念されている。

外部電力の供給が閉ざされた段階で、金融機関の本店や営業店は次善の策として自家発電装置の稼働に頼らざるを得ない。例えば、かつて北海道胆振東部地震では、営業店や本店に参集したら電動シャッターが機能せず、どうしても開閉が出来なかった、との報告が相次いだ。本来は、非通電時における主導でのシャッター開閉の手法が用意されているのだが、こうしたマニュアルが行職員に浸透していなかったことが原因とされる。また「自家発電装置があるから問題ない」としていた営業店であっても、実は通電エリアが特定のエリアに限定されていた、といった事例が相次ぎ、思うように非常時優先業務を履行出来なかったという声も多く確認されている。

金融機関の勘定系システムが格納されているシステムセンターでは、外部電力がダウンした段階で、自家発電装置に切り替わることだろう。ただし、同様に外気取り込み部のフィルターの性能問題が存在する限り、自家発電装置も設計通りの稼働時間を確保出来ない可能性もある。自家発電装置が機能しなければ、非常時優先業務をこなそうにもサーバーどころかパソコンすら立ち上がらず、スマホを充電することも不可能だ。こうした課題への現実的な対応は、最低限必要なエリア、例えば拠点ごとに立ち上がる非常時参集エリアに限定してでも、小型発電機を備え置くことだ。最近は家庭用ガスカセットで稼働する小型タイプの発電機も普及しており、以前に比べればコスト的にも安価なものとなっている。外部電力が復旧するまでの間の繋ぎとしてでも、このような代替手段となる発電機能を確保しておくことが望ましい。

システムセンターの対策は十分か?

現在、システムセンターで主流の自家発電装置は、船舶系のディーゼルエンジンや航空機のターボファンエンジンである。最近の当局からの指導もあり、多くのシステムセンターでは72時間連続稼働を目指して発電機能が充実してきた。ただし、古いビル等に架設されるターボファンエンジンなどでは、連続24時間以上の稼働はそもそも設計思想にないといわれている。これは、オイル全量の定期的な交換が運転に必須とされているためだ。つまり、24時間ごとに一旦停止したうえで、オイル交換を行わねばならない。そこで、一般的には連続運転72時間を実現するためには、2系統のエンジンを平行運転することで、連続運転を可能としている。金融機関の重要システムを格納する国内のシステムセンターでは、幸いなことに、災害などにより72時間ギリギリまでの運転を余儀なくされた例はないものの、燃油等の不足により運転可能時間は左右されてしまう。そもそも72時間の運転を可能とするだけの燃料備蓄を国内全てのシステムセンターが実現出来ているとは思えない。これは、燃料が不足した段階で給油を想定したタンク設計となっているためだ。もちろん、都市部のシステムセンターなどは、規制や条例などの制約で無制限に備蓄を行うこともできない。さらに、給油は石油卸会社などがタンクローリーで運搬することとなるが、大規模震災、とりわけ道路事情に影響を与えるような災害発生時には、タンクローリー自体が現地に到着できない恐れがある。今回の能登半島地震においても、道路事情が悪化したことから、被災地周辺では大部分のガソリンスタンドが影響を受け、営業継続を断念せざるを得なかったようだ。

なお、東日本大震災においては、当時東北地方に配置されていた600台以上ものタンクローリーのうち、被災を免れたものは100台程度であった。そのうえ、道路陥没などにより計画通り運行出来た例は少なかったのだ。企業では、災害時を見越して燃料の「優先供給契約」を石油卸会社などとの間で締結する例が多いのだが、実際の災害時には、タンクローリーそのものが現地に辿り着けないことを念頭においた対策を施す必要がある。

バックアップシステムへの切り替え基準や判断の手順化を急げ

金融機関の一部では、富士山周辺で火山活動が活発化してきた段階で、基幹系システムの一部を、遠隔地に設置しているバックアップシステムに切替えるための事前準備体制を発動させることを検討している。ただし、実際には、インシデント発生前にシステムをバックアップセンターに切り替えることを判断できる金融機関は少ないだろう。なぜなら、金融機関のシステムの全てが「フルバックアップ」状態にあるわけではなく、バックアップシステムに切り替えた段階で「切り戻し」が困難になるためだ。こうした制約を意識したうえで、「フルバックアップ」だけでなく、「バックアップシステムへの切り替え基準」の定義や切り替えにかかる「判断」の手順化を早急に講ずる必要があることは言うまでもない。

本稿に関するご質問・お問い合わせは、下記の担当者までお願いいたします。

NTTデータ経営研究所

金融政策コンサルティングユニット

ユニット長/パートナー

大野 博堂

E-mail :onoh@nttdata-strategy.com

Tel:03-5213-4115

TOPInsight経営研レポート金融機関におけるBCP策定のポイントと 富士山噴火への備え