リスクの可視化を、
更新し続ける仕組みへ。

既存の能力を、金融機関の
レジリエンス対応へまとめ直す。

ServiceNowは2026年10月22日、金融機関向けOperational Resilienceを紹介しました。AIリスクへの対応を、セキュリティ、リスク管理、IT、委託先管理、業務継続と結び付ける内容です。^[1]

ここで押さえたいのは、Operational Resilience自体が今回初めて登場した機能ではないことです。公式リリースノートには2020年からの履歴があります。^[2]今回の記事は、既存の機能群を金融機関の課題に合わせて統合する提案として読むのが適切です。

公式記事の監視カメラは、未申告のAIを発見し、封じ込め、委託先の再評価や業務継続へつなぐ仮想例です。^[1]製品の新規性とともに、なぜ金融機関でこの統合が求められるのか、その制度的背景を見る必要があります。

方向は共通でも、
規制の形と「時計」は異なる。

米国の一部当局や欧州では、インシデントへの対応を具体的な期限と結び付ける制度が整備されています。ただし、オペレジ、サイバー報告、AIガバナンスはそれぞれ異なる制度です。すべてを一つの「AI登録義務」として捉えることはできません。

日本も、重要業務と依存先を把握する方向へ進んでいる

金融庁は2023年4月にオペレジの基本的な考え方を公表し、同年6月に主要行等向け監督指針へ反映しました。重要業務、耐性度、依存関係のマッピング、検証という基本動作が示されています。^[6]

基本的な考え方はディスカッション・ペーパーであり、独立した法律ではありません。一方、現行の主要行等向け監督指針は、問題がある場合の報告徴求や業務改善命令にも言及しています。^[7]一律の導入期限や独立法の罰則がないことを、対応不要と読み替えるべきではありません。他業態の適用は、該当する監督指針等を個別に確認する必要があります。

サイバー報告と、AIガバナンスも分けて見る

日本では2024年10月に金融分野のサイバーセキュリティガイドラインが公表され、基本的な対応事項と対応が望ましい事項が整理されました。^[8]報告も一律の時間数だけで判断できません。例えば金融商品取引業者向け監督指針は、対象となる障害・サイバー事案を認識次第、直ちに当局へ報告する扱いを示しています。^[9]

AIについては、金融庁が2025年3月の第1.0版に続き、2026年3月3日にAIディスカッションペーパー第1.1版を公表しました。利活用とリスク管理を両立させ、官民の対話を通じて実務を形成する姿勢です。^[10]同文書は、一律のAIエージェント登録を義務付ける制度ではありません。ただし、既存の法令や監督上の対応まで免除するものと捉えることも適切ではありません。

依存関係の可視化は、
鮮度を保つ仕組みまで必要になる。

業務がどのシステム・委託先・拠点に依存しているかを把握することは、オペレジの土台です。しかし、調査して図を描いた時点から、システム変更、契約更新、拠点の移転、外部サービスへのAI機能の追加が起こります。

Numberは、この情報を人の記憶や定期的な一斉調査だけで最新に保ち続けることは困難であり、情報の鮮度を保つには、更新を日常業務に組み込む仕組みが必要だと考えています。

例えば、変更管理でシステムの依存関係を更新し、契約変更で委託先と対象業務の関係を見直し、AI利用の申請やサービス変更の確認を管理情報へ反映する。自動連携できる情報と、人の確認が必要な情報を分け、更新責任者と最終確認日を持たせます。

未確認の情報を「安全」と扱わず、更新が止まっている箇所を把握できることも重要です。すべてを自動で発見できる前提に立つと、外部サービスの内部で使われるAIなど、確認しにくい依存先を見落とすおそれがあります。

AIガバナンスは、今から土台を整えたい

日本のAIガバナンスは、対話と利活用促進を重視しながら実務を積み上げる段階にあります。Numberは今後、日本でもAIの用途、データ、依存先、責任者を説明できる管理への要求が高まる可能性が高いと見ています。これは将来の法改正が確定しているという意味ではなく、規制・監督・取引先からの確認の深化を見据えた見解です。

期限や登録制度が定まってから全社の情報を集め始めると、管理の形を揃える作業にも時間がかかります。いま進めるべきなのは、部門にある情報を、継続的に使えるデータと判断基準へ育てることです。

部門内のデータ化から、
全社のリスク管理へ。

日本企業では、部門によって考える「リスク」の意味や評価の物差しが異なるケースがあります。情報を集める作業と、意味を揃える作業の両方が必要です。Numberは、次の順序で進めることを提案します。

1. 部門内のリスク情報をデータ化し、共有できる状態にする

Excelにあるリスク情報を、検索・関連付け・更新・履歴管理できるデータとして整理します。対象業務、事象、原因、影響、既存対策、責任者、根拠、最終確認日を持たせます。共有範囲とアクセス権を決め、同じリスクや依存先を識別できるようにします。最初から全部門に同じ分類を強制せず、各部門の元の表現も残します。

2. 部署間で、リスク概念を翻訳する

IT部門の「重大障害」、業務部門の「重要な取引停止」、管理部門の「顧客影響」が、どのような事象を指すのかを対応付けます。同じ「高リスク」でも、評価期間や影響の範囲が違うことがあります。停止時間、対象顧客数、取引額、情報漏えいなどの観点を整理し、共通部分と専門領域固有の判断を分けます。

3. 全社で使うリスク管理と、更新の運用を組み立てる

翻訳した情報を基に、重要業務、依存関係、耐性度、リスクの責任者、対応手順を結び付けます。同じ事象の二重計上や、単純には合算できない評価を整理し、全社の優先順位を決める基準を設けます。変更・契約・インシデント対応のたびに情報を見直し、訓練で更新漏れや判断の不足を確かめます。

図：Numberによる導入・運用の進め方の提案。製品の標準導入手順を示すものではありません。

ServiceNowの価値を考えるうえでも、こうした情報と業務をどのように結ぶかが重要です。可視化を一度きりの成果物で終わらせず、全社で使い、更新し続けられる仕組みにする。Numberは、そこに日本企業が取り組むべき実務上の課題があると考えています。