MT5 MT4 SRE AI Forex アルゴ取引

金融システムにおけるオブザーバビリティ（可観測性）の向上 異常検知からプロアクティブな保守へ

序論：複雑性の淵に立つ金融ITインフラストラクチャ

現代の金融業界は、デジタルトランスフォーメーションという不可逆的な潮流の只中にある。オープンバンキングの進展、FinTech企業とのエコシステム形成、そして顧客接点の完全なデジタル化は、金融機関のITシステムに構造的な変革を強いている 1。かつての安定稼働を第一としたモノリシックなシステムは、ビジネスのアジリティを追求する過程で、マイクロサービス、コンテナ、マルチクラウドといった技術要素が複雑に絡み合う、分散アーキテクチャへとその姿を変えつつある 3。大手銀行において、モバイルアプリの利用者数がATMの利用者数を上回るという事実は、この変化がもはや不可逆であることを象徴している 6。

しかし、この技術的進化は、システムの安定運用という観点において新たな、そしてより深刻な課題を突きつけている。アーキテクチャの分散化とコンポーネントの細分化は、障害発生点の数を指数関数的に増加させ、コンポーネント間の依存関係を極めて難解なものにした 3。結果として、従来型の運用監視手法では、システムの健全性を包括的に把握し、障害発生時に迅速な原因特定を行うことが著しく困難になっている。

この構造的複雑性の増大は、単なる技術的な課題に留まるものではない。それは、金融機関の根幹を揺るがしかねないビジネスリスクの増大と直接的に結びついている。金融サービスは、その社会的責務から極めて高い信頼性と可用性が求められる 6。システム障害は、直接的な金銭的損失や機会損失のみならず、顧客の信頼失墜、ブランドイメージの毀損、さらには金融庁をはじめとする規制当局からの厳しいペナルティといった、多岐にわたる事業リスクを引き起こす可能性がある 9。従来の監視ツールは、CPU使用率やメモリ使用量といった個別のコンポーネントの死活監視には長けているが、複雑な依存関係の中で発生する予期せぬ障害、いわゆる「未知の未知（Unknown Unknowns）」の根本原因を究明するには適していない 7。このミスマッチは、障害発生時の平均修復時間（Mean Time To Repair; MTTR）の長期化を招き、結果としてビジネスリスクを増大させるという深刻な因果関係を生み出している。

この根源的な課題に対処するためには、もはや既存の運用手法の延長線上にある改善では不十分であり、運用パラダイムそのものの変革が不可欠である。本レポートの目的は、この変革の中核をなす概念として「オブザーバビリティ（Observability：可観測性）」を定義し、それが如何にして現代金融システムの安定稼働と、競争力維持に不可欠なイノベーションを両立させるかを論じることにある。さらに、オブザーバビリティにAI（人工知能）を組み合わせたAIOpsが、障害対応を事後的な「異常検知」から、障害を未然に防ぐ「プロアクティブな保守」へと昇華させる道筋を、具体的な技術と事例を交えて詳述する。

第1章：監視から可観測性へ：IT運用のパラダイムシフト

ITシステムの運用管理は、その複雑性の増大に伴い、大きな転換点を迎えている。従来の中心的な概念であった「監視（Monitoring）」から、より包括的で深遠なアプローチである「オブザーバビリティ（Observability）」へのパラダイムシフトが、システムの信頼性とビジネスの俊敏性を両立させるための鍵として認識され始めている。

1.1. 監視（Monitoring）の定義と限界：「何が起きたか」を問うリアクティブなアプローチ

伝統的なIT運用における「監視」とは、システムのパフォーマンスやリソース状況に関する既知の指標（メトリクス）を継続的に収集し、事前に定義された閾値と比較する活動を指す 12。例えば、サーバーのCPU使用率が90%を超えた場合や、アプリケーションのレスポンスタイムが500ミリ秒を超えた場合にアラートを発報するといった運用がこれに該当する 10。

このアプローチは、システムの「既知の未知（Known Unknowns）」、すなわち、発生する可能性が予測されており、そのための監視項目が設定されている問題に対処する上で有効である 7。システムの正常性を確認し、明確な障害を検知する上で、監視は依然として不可欠な要素であり続けている 13。

しかし、マイクロサービスやコンテナ技術の普及によりシステムが分散化・複雑化する現代において、この従来型の監視手法はその限界を露呈している。最大の限界は、監視が「何が起きたか」という事象の発生を通知するに留まり、その事象が「なぜ起きたのか」という根本原因に関する洞察を提供できない点にある 10。CPU使用率が急騰したというアラートは受け取れても、その原因が特定のアプリケーションのバグなのか、予期せぬ外部からのアクセス急増なのか、あるいはデータベースのクエリ遅延に起因するのかを特定するには、エンジニアによる膨大なログの手作業での調査や、複数のツールを横断した相関分析が必要となる。これはリアクティブ（事後対応的）なアプローチであり、複雑なシステムにおける問題解決を著しく遅延させる要因となる。

1.2. オブザーバビリティ（Observability）の本質：「なぜ起きたか」を探求するプロアクティブな性質

オブザーバビリティは、制御理論に由来する概念であり、ITの文脈においては「システムの外部から得られる出力（データ）を用いて、その内部状態をどれだけ正確に推測できるかを示す、システム固有の属性または性質」と定義される 7。これは、特定の指標をチェックするという「監視する（Monitoring）」という行動（動詞）とは異なり、システムが「観測可能である（Observable）」という状態（名詞）を指す、より広範な概念である 16。

オブザーバビリティの目的は、監視が対象とする「既知の未知」を超え、これまで予測すらされていなかった未知の問題、すなわち「未知の未知（Unknown Unknowns）」の根本原因を探求し、解明することにある 7。そのために、オブザーバビリティは事前に監視項目を定義することなく、システムから出力されるあらゆるデータを収集し、それらを相互に関連付けて分析する能力を重視する 7。監視が「何が問題か」を示すのに対し、オブザーバビリティは「なぜそれが問題か」を明らかにするための問いを立て、その答えをデータから導き出すプロアクティブなアプローチなのである 12。

重要な点として、オブザーバビリティは監視を不要にするものではなく、むしろ監視を包含する概念である 13。モダンな監視はオブザーバビリティを実現するための重要な構成要素の一つと位置づけられる 13。

1.3. オブザーバビリティを支える三位一体：メトリクス、ログ、トレースの統合的活用

オブザーバビリティというシステムの性質は、具体的には3種類の主要なテレメトリデータ、通称「オブザーバビリティの3つの柱」を統合的に収集・分析することによって実現される 18。

  • メトリクス（Metrics）: システムのパフォーマンスやリソース使用状況を時系列で示す数値データである 21。CPU使用率、メモリ消費量、ネットワークスループット、アプリケーションのエラー率などがこれにあたる。メトリクスは、システム全体の状態を鳥瞰し、「何が」起きたのかを定量的に把握するための基礎となる 18。
  • ログ（Logs）: システム内で発生した個別のイベントに関する、タイムスタンプ付きの不変的な記録である 22。アプリケーションの起動情報、エラーメッセージ、デバッグ情報、ユーザーのアクセス記録などが含まれる。ログは、特定の事象が発生した際の詳細なコンテキストを提供し、「なぜ」その問題が起きたのかを解明するための重要な手がかりとなる 18。
  • トレース（Traces）： 分散システム内を横断する一連のリクエストの経路と処理時間を可視化したものである 22。マイクロサービスアーキテクチャにおいて、ユーザーからのリクエストがどのサービスを経由し、各サービスでどれだけの時間を要したかを追跡する。トレースは、システム全体のどこでパフォーマンスのボトルネックが発生しているのか、すなわち「どこで」問題が起きているのかを特定する上で極めて有効である 18。

オブザーバビリティプラットフォームは、これら3つのデータを単に収集するだけでなく、それらを一つの画面上でシームレスに連携させ、相関分析を可能にする 3。例えば、あるサービスのレイテンシ悪化（メトリクス）を起点に、該当時間帯の関連トレースを特定し、そのトレース内の遅延しているスパンから、原因となっているエラーログへとドリルダウンするといった分析が容易になる 12。

さらに、Elastic社などの先進的なベンダーは、これら3つの柱に加え、第4の柱としてプロファイリング（Profiling）を提唱している 19。プロファイリングは、コードレベルでCPUやメモリがどのように消費されているかを継続的に分析するものであり、パフォーマンス問題の根本原因をより詳細に特定する能力を提供する。

オブザーバビリティの導入は、単なる技術的な問題解決の高速化に留まらない、より高次の組織的価値をもたらす。従来の運用体制では、開発チーム（Dev）、運用チーム（Ops）、セキュリティチーム（Sec）は、それぞれが異なるツールセットを用い、サイロ化されたデータ（ログ、メトリクス、セキュリティイベント）を基に状況を判断していた 24。障害発生時には、各チームが自身の管轄データに基づいた仮説を立てるため、原因特定に時間がかかり、時には責任の押し付け合いに発展することもあった。

しかし、オブザーバビリティプラットフォームは、メトリクス、ログ、トレースといった多様なデータを単一のプラットフォームに統合し、全関係者に対して「信頼できる唯一の情報源（Single Source of Truth）」を提供する 16。これにより、憶測に基づくコミュニケーションは排除され、事実に基づいた効率的な協業（コラボレーション）が促進される 26。実際に、決済サービス大手のJCBの事例では、Datadogで構築したSLO（サービスレベル目標）ダッシュボードをビジネス部門とも共有することで、部門を横断した共通認識の形成に成功している 27。このように、オブザーバビリティは技術部門内のサイロを破壊し、チーム間に「共通言語」を創出する。これは、単なるツール導入を超え、データドリブンな組織文化を醸成し、最終的にはBizDevOpsの実現に貢献する、組織文化の変革を促す触媒となり得るのである。

第2章：金融システムがオブザーバビリティを不可欠とする理由

金融システムは、その社会的な重要性とミッションクリティカルな性質から、他の業界とは一線を画す厳しい要件を課せられている。レガシーシステムの存在、厳格な規制、顧客からの高い期待といった特有の課題を抱える金融業界にとって、オブザーバビリティはもはや選択肢ではなく、事業継続と成長のための必須要件となっている。

2.1. レガシーからの脱却とマイクロサービス化：増大するコンポーネント間の相互作用の可視化

日本の多くの金融機関は、長年にわたり安定稼働してきた巨大なメインフレームベースのレガシーシステムを依然として抱えている 28。これらのシステムは、ビジネス環境の変化に迅速に対応する上での足枷となっており、そのモダナイゼーション、特にマイクロサービスアーキテクチャへの移行が喫緊の経営課題となっている 4。

しかし、この移行プロセスは一直線に進むものではない。多くの場合、既存のモノリシックな勘定系システムと、クラウドネイティブな技術で構築された新しいサービス群が共存する、複雑なハイブリッド環境が長期にわたって継続する。この過渡期において、システムの複雑性は極限まで高まる。新旧システム間のAPI連携、細分化されたマイクロサービス間の動的な依存関係、コンテナ化されたアプリケーションの頻繁なデプロイといった要素が絡み合い、システム全体の挙動を予測することは極めて困難になる。

このような環境では、従来の監視手法は無力である。個々のサーバーやアプリケーションが正常に稼働しているように見えても、サービス間の連携不整合や予期せぬレイテンシの増大が、顧客に影響を及ぼす重大な障害を引き起こす可能性がある。オブザーバビリティは、分散トレースを通じて新旧システムを横断するトランザクションの流れを可視化し、細分化されたサービス間の依存関係を正確に把握する能力を提供する 11。これにより、複雑なハイブリッド環境下で発生するトラブルの根本原因を迅速に特定し、モダナイゼーションのプロセスを安全に推進することが可能になるのである。

2.2. セキュリティとコンプライアンスの徹底：金融庁やFISCの要請に応えるための証跡管理と異常検知

金融業界は、顧客の資産や個人情報といった極めて機微なデータを扱うため、世界で最も厳格なセキュリティとコンプライアンスの規制下にある 29。日本では、金融庁が策定する「金融分野におけるサイバーセキュリティ強化に向けた取組方針」や、公益財団法人金融情報システムセンター（FISC）が発行する「金融機関等コンピュータシステムの安全対策基準」が、金融機関が遵守すべき具体的な指針となっている 9。これらのガイドラインは、情報資産のライフサイクル管理、リスク管理態勢の構築、そしてサイバー攻撃などのインシデント発生時における迅速な対応と報告体制の確立を強く求めている 9。

オブザーバビリティは、これらの厳しい要請に応えるための強力な武器となる。システムのあらゆる活動は、ログやトレースとして詳細な証跡を残す。オブザーバビリティプラットフォームは、これらの証跡を一元的に収集・保管し、強力な検索・分析機能を提供する。これにより、規制当局による監査の際には、特定の取引やデータアクセスに関する証跡を迅速に提出することが可能となる。

さらに、セキュリティの観点からもその価値は大きい。すべてのリクエストとデータ変更の証跡を詳細に分析することで、不審な挙動や不正アクセスの兆候を早期に検知できる。例えば、通常とは異なるIPアドレスからの大量のログイン試行や、特権アカウントによる異常なデータアクセスといったインシデントの調査において、詳細なトレース情報は決定的な役割を果たす。DatadogのObservability Pipelinesのようなソリューションは、機密データがインフラから外部に送信される前にマスキングやフィルタリングを行い、データガバナンスやデータ居住権に関する法律への準拠を支援する機能も提供している 32。

2.3. 顧客体験（CX）の向上：デジタルバンキングにおけるパフォーマンスボトルネックの特定と改善

現代の金融サービスにおいて、デジタルチャネルは顧客との主要な接点であり、その体験品質は顧客満足度とビジネスの成否に直結する 6。モバイルバンキングアプリのわずかなレスポンスの遅延や、オンライン取引の途中で発生するエラーは、顧客に多大なストレスを与え、最悪の場合、競合他社への乗り換え（顧客離反）を引き起こす。

オブザーバビリティは、このデジタル顧客体験（CX）を維持・向上させる上で不可欠である。単にサーバーが稼働しているか否かではなく、エンドユーザーが実際に体感しているパフォーマンス（例：画面表示速度、取引完了までの時間、エラー発生率）を正確に測定することが可能になる 12。分散トレースを活用すれば、特定の操作が遅い場合に、その原因がフロントエンドのアプリケーションにあるのか、バックエンドのAPIにあるのか、あるいはデータベースやサードパーティの連携サービスにあるのかを即座に切り分けることができる 33。

この能力により、金融機関はパフォーマンスのボトルネックを迅速に特定し、改善策を講じることができる。結果として、システムのダウンタイムを最小限に抑え、安定したサービスレベルを維持することで、顧客満足度とブランドロイヤルティの向上に貢献するのである 16。

2.4. 高可用性と信頼性の確保：ミッションクリティカルな勘定系・決済システムの安定稼働

銀行の勘定系システムや証券会社の取引システム、クレジットカードの決済システムは、現代社会を支える重要なインフラであり、1秒たりとも停止することは許されない。これらのミッションクリティカルなシステムには、最高レベルの可用性と信頼性が求められる。近年、住信SBIネット銀行がAWSのマルチリージョン構成を活用して災害復旧（DR）体制を強化し、目標復旧時点（RPO）ゼロ秒を実現した事例 8 や、みんなの銀行が国内で初めて勘定系システムにパブリッククラウドを採用し、「東阪両現用」体制を構築した事例 34 など、金融機関は可用性向上のために先進的なアーキテクチャの採用を加速させている。

しかし、こうした高度に分散化されたシステムは、その複雑さゆえに新たな運用上の課題を生み出す。オブザーバビリティは、地理的に分散した複数のデータセンターやクラウドリージョンにまたがるシステム全体の状態をリアルタイムで、かつ統合的に把握するための唯一の手段である。システムの状態を継続的に観測し、異常の兆候を早期に発見することで、リソース不足による障害を未然に防いだり、ハードウェア障害が発生してもサービスへの影響を最小限に抑えたりすることが可能になる 12。これにより、金融機関は厳しいサービスレベル合意（SLA）を達成し、社会インフラとしての責務を果たし続けることができる。

金融機関にとって、オブザーバビリティは単にシステム障害を防ぐ「守り」のIT運用ツールに留まらない。それは、ビジネスの成長とイノベーションを加速させる「攻め」の戦略的基盤としての側面を併せ持つ。FinTech企業の台頭により、金融業界はかつてない厳しい競争環境に置かれている 1。この競争に打ち勝つためには、顧客ニーズの変化にアジャイルに対応し、新しい金融商品を迅速に市場投入する必要がある 2。しかし、システムの信頼性が担保されていなければ、新しい機能のリリースは大きなリスクを伴い、結果としてイノベーションのサイクルは遅滞する。障害発生を恐れるあまり、変更を避ける保守的な文化が醸成されかねない。

オブザーバビリティは、新しいコードを本番環境にデプロイした後のシステムの振る舞いを詳細に可視化し、万が一問題が発生しても迅速に原因を特定・修正できるという「心理的安全性」を開発チームに提供する 12。この信頼性の基盤があるからこそ、チームは自信を持って、より頻繁なデプロイや新しい技術の試行といった挑戦が可能になる。実際に、ソフトバンクの事例では、DevOps基盤にDatadogを導入したことで、商用デプロイに要する時間が従来の2週間から1日へと劇的に短縮されたと報告されている 36。したがって、オブザーバビリティへの投資は、システムの安定稼働（守り）という直接的な効果に加え、開発サイクルの短縮とイノベーションの加速（攻め）という、間接的かつ極めて重要なビジネス価値を生み出すのである。これは、New Relic社が指摘する「市場投入までの時間短縮」と「イノベーションの文化の醸成」に他ならない 16。

第3章：AIOpsによるインテリジェンスの注入

オブザーバビリティがIT運用の新たな基盤であるとすれば、AIOps（AI for IT Operations）は、その基盤の上に構築されるインテリジェンス層である。システムの複雑化とそこから生成されるデータ量の爆発的な増加は、もはや人間の能力だけでは対処しきれないレベルに達している。AIOpsは、この課題に対する決定的な解決策として、IT運用のあり方を根本から変革しようとしている。

3.1. AIOpsの台頭：AIと機械学習がIT運用にもたらす革新

AIOpsとは、AI（人工知能）と機械学習の技術をIT運用に適用し、プロセスの自動化と高度化を図るアプローチを指す 38。クラウドサービスの普及、IoTデバイスの増加、マイクロサービスアーキテクチャの採用などにより、現代のIT環境は急速に複雑化し、従来の手動による運用管理は限界を迎えている 39。この課題を解決する革新的な手法として、AIOpsは多くの企業から注目を集めている。調査会社BCGは、AIOpsをIT運用の未来を形作る重要な技術と位置づけており、McKinsey & Companyも、AIOpsがITシステムの安定性と効率性を大幅に向上させる能力を持つと評価している 40。

3.2. オブザーバビリティデータを燃料とするAIOpsエンジン：膨大なテレメトリデータからの洞察抽出

AIOpsがその能力を最大限に発揮するためには、高品質で網羅的なデータが不可欠である。ここで決定的な役割を果たすのが、オブザーバビリティによって収集された膨大かつ多様なテレメトリデータ（メトリクス、ログ、トレース）である。AIOpsは、これらのデータをいわば「燃料」として機能する 41。

AIOpsプラットフォームは、オブザーバビリティツールからストリーミングされるデータをリアルタイムで取り込み、機械学習アルゴリズムを用いて分析する 38。これにより、複数のシステムやコンポーネントを横断するデータの中から、人間では到底見過ごしてしまうような微細な相関関係や異常のパターンを自動的に検出することが可能になる 42。オブザーバビリティが「観測」のためのデータを提供し、AIOpsがそのデータから「洞察」を抽出するという、両者は補完的な関係にある。

3.3. Gartnerが示すAIOpsの主要機能：イベント相関分析、異常検知、根本原因分析の自動化

IT分野の有力な調査会社であるGartnerは、AIOpsプラットフォームが備えるべき主要な機能とユースケースを明確に定義している 38。Gartnerによれば、AIOpsプラットフォームは、ソースやベンダーを問わず複数のソースからデータを取り込み、リアルタイム分析と履歴分析を実行し、機械学習を活用して、そのインサイトに基づいたアクションを起動する能力を持つべきであるとされる 38。

これにより、具体的には以下のような高度な運用が実現される。

  • インテリジェントなアラートノイズ削減: 現代のシステムでは、単一の根本原因が連鎖的に多数のアラートを発生させることが多い。AIOpsは、イベント間の相関関係やトポロジー情報を分析し、関連するアラートを自動的にグループ化（相関付け）することで、運用チームが対処すべきインシデントの数を大幅に削減する 42。
  • 動的な異常検知: 機械学習モデルを用いてシステムの正常な振る舞いを学習し、そこからの逸脱をリアルタイムで検知する。これにより、静的な閾値ベースの監視では見逃してしまうような、緩やかだが異常な変化や、これまで経験したことのないパターンの問題を早期に発見できる 39。
  • 根本原因分析の自動化: 障害が発生した際、関連するメトリクスの変化、ログメッセージ、トレース情報を自動的に分析し、問題の根本原因となっている可能性が最も高いコンポーネントや変更点を特定する 39。これにより、エンジニアが「ウォー・ルーム」に集まって長時間かけて行っていた原因調査のプロセスを劇的に短縮する。

Gartnerは「AIOpsを含まないIT運用の未来はない」と断言しており 44、AIOpsが今後のIT運用における標準的なアプローチになることを示唆している。

3.4. 主要ベンダーが提供するAIOpsソリューションの概観

市場の需要の高まりを受け、主要なオブザーバビリティベンダーは、自社のプラットフォームに高度なAIOps機能を積極的に統合している。

  • Datadog: AIを活用したアラート、インサイト、根本原因分析機能を提供し、DevとOpsの両方がオブザーバビリティを実践することを支援する 45。
  • New Relic: AIによる問題の自動予測や、オブザーバビリティデータをビジネスインパクトに結びつけるインテリジェントなインサイトを提供し、システムの長期的な改善を支援する 24。
  • Dynatrace: Davis AIと名付けられた独自のAIエンジンを中核に据え、フルスタックの自動監視と根本原因の特定を実現する 46。
  • Splunk: IT Service Intelligence (ITSI) を通じて、機械学習を用いた予測分析や異常検知機能を提供し、サービス全体の健全性を可視化する 47。
  • IBM: IBM Cloud Pak for Watson AIOpsを提供し、ドメインに依存しない汎用的なAIOpsプラットフォームとしてGartnerからも評価されている 44。

これらのベンダーは、GartnerのMagic QuadrantやMarket Guideといったレポートで継続的に評価されており、金融機関が自社のニーズに合ったソリューションを選定する上での重要な指標となっている 44。

AIOpsの導入は、単なる運用効率化に留まらない、より本質的な組織変革をもたらすポテンシャルを秘めている。従来のIT運用チームは、日々発生するアラートへの対応や定型的なメンテナンス作業に大半の時間を費やしており、ビジネスの観点からはコストセンターとして認識されがちであった 41。AIOpsは、これらの反復的で時間のかかるタスク、例えばアラートのトリアージや根本原因の初期調査などを自動化する 39。これにより、高度なスキルを持つエンジニアは、障害対応という受け身の業務から解放され、システムのパフォーマンス最適化、将来の需要予測に基づくキャパシティプランニング、新技術の導入検証といった、より付加価値の高い戦略的な業務に集中できるようになる 38。

解放されたエンジニアリングリソースは、ビジネスの成長に直接貢献する活動へと振り向けることができる。例えば、オブザーバビリティデータとAIOpsを用いて、「特定のマーケティングキャンペーン実施時に、コンバージョン率が想定よりも低い」というビジネス上の課題を分析し、その原因が「キャンペーンによるアクセス集中時の決済APIのレイテンシ増大」であることを特定し、具体的な改善策を講じるといったことが可能になる。これは、IT運用が直接的にビジネス成果（収益）の向上に貢献する好例である 16。したがって、AIOpsはIT部門の役割を、コストセンターとしての「システム管理者」から、ビジネス価値創出を能動的に牽引するプロフィットセンターとしての「戦略的イネーブラー」へと昇華させる力を持つ、変革的なテクノロジーなのである。

第4章：プロアクティブな保守の実現：障害予兆検知と自律的運用

オブザーバビリティとAIOpsの融合がもたらす最終的な到達点、それはIT運用のあり方を根本から覆す「プロアクティブな保守」の実現である。これは、障害が発生してから対応するリアクティブな運用モデルから脱却し、障害の発生そのものを未然に防ぐ、あるいはサービスへの影響が顕在化する前に自律的に対処する、未来志向の運用パラダイムを意味する。

4.1. 障害予兆検知のメカニズム：正常状態からの逸脱をAIが捉える

プロアクティブな保守の核心技術は、AIと機械学習を活用した障害予兆検知である。このアプローチは、従来の静的な閾値監視とは根本的に異なる。まず、AIOpsプラットフォームは、オブザーバビリティを通じて収集された平常時の膨大な時系列データ（メトリクス、ログの発生パターンなど）を機械学習アルゴリズムに与え、システムの「正常な振る舞い」を多角的に学習したモデルを構築する 52。

一度この正常モデルが確立されると、システムはリアルタイムで収集されるデータとモデルの予測値を常に比較し続ける。そして、実際の観測値がこの正常モデルから統計的に有意に逸脱し始めた場合、それを障害の「予兆」として検知する 50。例えば、メモリ使用率が閾値には達していないものの、過去のパターンにはない緩やかな増加傾向を示している場合や、特定のエラーログの発生頻度がわずかに上昇している場合など、人間が気づきにくい、あるいは気づいたとしても判断に迷うような微細な変化を捉えることが可能になる。KDDIの事例では、この「予測×検知」のアプローチにより、通信インフラの障害対応を前倒しすることに成功している 53。

4.2. サイレント障害の克服：先進技術の適用

運用現場において最も厄介な問題の一つが、明確なエラーログやアラートを発することなく、システムのパフォーマンスが徐々に劣化していく「サイレント障害」である。メモリリークやリソースの競合などが原因で発生することが多く、顧客からのクレームで初めて問題が発覚するケースも少なくない。

このような検知が困難な問題に対し、先進的な技術が開発されている。その一例が、NECが開発した「インバリアント分析技術」である 54。この技術は、システム内の複数のセンサーデータ間に存在する、平常時には常に成り立つべき普遍的な関係性（インバリアント）に着目する。例えば、「サーバーAのCPU使用率が上がれば、サーバーBの処理件数も比例して増える」といった関係性を自動で学習する。そして、この関係性が崩れた場合、たとえ個々のセンサー値が正常範囲内であっても、それをシステムの異常な状態、すなわちサイレント障害の兆候として検出する。これにより、従来の監視手法では見逃されていた問題をプロアクティブに発見することが可能になる。

4.3. 自己修復（Self-Healing）への道筋：自動化された修復ワークフローの実行

AIOpsの能力は、予兆の検知や原因の特定に留まらない。その真価は、特定された問題に対して、人間の介在なしに修復アクションを自動的に実行する「自己修復（Self-Healing）」の領域で発揮される 43。

AIOpsプラットフォームは、検知した異常のパターンと、事前に定義された修復手順（Runbook）を連携させることができる。例えば、「特定のアプリケーションコンテナでメモリリークの予兆を検知した場合、ロードバランサーからそのコンテナを自動的に切り離し、安全に再起動した上で、再度サービスに組み込む」といった一連のワークフローを自動実行する。あるいは、「データベースのクエリ遅延が検知された場合、関連するインシデントチケットを自動起票し、担当チームに通知すると同時に、パフォーマンスに影響を与えているクエリの実行計画を分析したレポートを添付する」といった、より高度な自動化も可能である。

このような自動化された修復ワークフローは、サービスへの影響を未然に防ぐ、あるいは影響時間を最小限に抑える上で絶大な効果を発揮し、24時間365日の安定稼働が求められる金融システムにとって不可欠な能力となりつつある。

4.4. 運用体制の変革：「火消し型」から「予防型」へのシフトがもたらすビジネス価値

オブザーバビリティとAIOpsの導入は、IT運用チームの役割と文化を根底から変革する。従来の運用は、障害発生の通報を受けてから対応を開始する、リアクティブな「火消し型」の体制であった 55。このモデルでは、エンジニアは常に緊急対応に追われ、疲弊し、根本的な問題解決や将来に向けた改善活動に時間を割くことが困難であった。

プロアクティブな保守モデルへの移行は、この状況を打開する 57。障害の発生を未然に防ぐ「予防型」の体制へとシフトすることで、システムのダウンタイムは劇的に削減され、可用性は向上する 12。これにより、ビジネス機会の損失を防ぎ、顧客満足度を高めることができる。さらに、定常的な障害対応業務から解放されたエンジニアは、システムのパフォーマンスチューニングやアーキテクチャの改善といった、より創造的で付加価値の高い業務に集中できるようになり、従業員の満足度と定着率の向上にも繋がる 41。みずほ銀行の事例では、IBM Instanaの導入が、運用体制を「火消し型」から「予防型」へとシフトする後押しになったと報告されている 56。

このプロアクティブな保守体制の実現は、金融機関における「リスク許容度」の考え方にも影響を及ぼす可能性がある。金融機関のIT戦略は、伝統的にリスク回避が最優先されてきた。新しい技術の導入は、未知の障害リスクを伴うため、極めて慎重な判断が求められてきた。しかし、システムの異常を早期に、あるいは発生前に検知し、自動的に対処する能力が備わることで、システム全体の「レジリエンス（回復力・弾力性）」は飛躍的に向上する。未知のリスクが顕在化しても、ビジネスに深刻な影響を与える前に対処できるという信頼性が醸成されるのである。この高められたレジリエンスは、経営層やITリーダーが、これまでリスクが高いと判断されてきたような、より先進的で競争力のあるシステムアーキテクチャやデジタルサービスを迅速に展開する際の心理的な障壁を下げ、ビジネスの変革スピードを加速させる戦略的なドライバーとして機能するであろう。

第5章：先進金融機関におけるオブザーバビリティ実践事例

理論から実践へ。本章では、国内外の先進的な金融機関が、オブザーバビリティとAIOpsをどのように活用し、具体的なビジネス成果へと結びつけているのかを、詳細な事例を通じて分析する。これらの事例は、オブザーバビリティへの投資が、システムの安定化に留まらず、開発の加速、顧客体験の向上、そして最終的にはビジネスの成長に直接貢献することを示している。

以下の表は、本章で取り上げる主要な事例の概要をまとめたものである。各金融機関が直面した課題に対し、どのテクノロジーを用いて、どのような成果を上げたかを一覧することで、オブザーバビリティ導入の具体的な効果を俯瞰的に理解することができる。

金融機関名導入した主要プラットフォーム主な課題導入後の主要な成果引用元
株式会社ジェーシービーDatadogクラウドネイティブ基盤の監視、インシデント対応の迅速化MTTD短縮、夜間オンコール対応の効率化、部門横断でのSLO共有27
みずほ銀行IBM Instanaインターネットバンキングのパフォーマンス問題、原因特定に時間を要すインシデント対応時間を65%以上削減、レポート作成時間を50%以上削減56
SBI新生銀行New Relicコンテナ基盤（API-Hub）の複雑な構造の監視問題確認作業が数時間から数秒に短縮、顧客体験向上のための可視化58
WeLab BankDynatrace潜在的な問題の早期発見、根本原因分析の長時間化根本原因分析の時間を数時間から数分に短縮46
楽天証券Splunk多種多様な膨大なログの収集・分析、セキュリティログ分析基盤の構築障害原因の特定時間短縮、セキュリティ監視・解析能力の強化59
住信SBIネット銀行(AWSネイティブ)インターネットバンキングの可用性向上、DR（災害復旧）体制の構築マルチリージョン構成によるDR自動切替、RPOゼロ秒を実現8

5.1. 決済システムにおける安定稼働とDevOps加速

クレジットカード大手の株式会社ジェーシービー（JCB）は、ビジネスのスピード向上を目的として、Google Cloud上にKubernetesを核としたクラウドネイティブな新システム基盤「JDEP」を構築した。この全く新しい環境のモニタリング基盤としてDatadogを採用。導入の決め手は、豊富なインテグレーションによる導入の容易さと、単一プラットフォームで管理ポイントを減らせる運用効率の高さであった。導入後、インシデントの自動検知とAPM（Application Performance Management）の連携により、初動対応が大幅に改善され、平均検出時間（MTTD）の短縮を実現した。特に夜間のオンコール対応と初動調査が迅速化され、SREチームの負担軽減に大きく貢献している 27。

また、ソフトバンク株式会社は、アジャイル開発とDevOps環境の構築において、コンテナ環境に対応した監視ツールとしてDatadogを選定した。導入により、それまで3ヶ月を要していた開発版のリリースが1週間に、2週間かかっていた商用デプロイが1日へと大幅に短縮された。APMを活用することで、開発段階でAPIの処理性能を即座に確認し、ボトルネックを早期に発見できるようになった。この事例は、オブザーバビリティが運用監視だけでなく、開発サイクルそのものを加速させ、DevOpsの文化を成熟させる上で極めて有効であることを示している 36。

5.2. デジタルバンキングの可用性向上とインシデント対応の高速化

みずほ銀行は、インターネットバンキングのレジリエンス強化という課題に対し、IBM Instana Observabilityを導入した。導入前は、パフォーマンス低下が発生した際に、どこで何が問題になっているのかを把握するのに時間を要していた。Instanaの導入により、システム全体の状況がリアルタイムで可視化され、インシデント対応時間は65%以上、関連するレポート作成時間は50%以上という劇的な削減を達成した。この成果は、同行の運用体制を事後対応の「火消し型」から予防的な「予防型」へとシフトさせる大きな後押しとなっている 56。

SBI新生銀行は、AWS基盤上に構築したコンテナベースのAPI基盤「API-Hub」のオブザーバビリティ確保のためにNew Relicを採用した。複雑な構造を持つAPI-Hubの性能監視やログ監視、コンテナの状態可視化を容易に実現。従来は相当の工数と時間を要していた問題確認作業が、導入後は数秒で完了できるようになった。これにより、顧客向けシステムの安定性を高め、顧客体験の向上に繋げる道筋を確立した 58。

香港のデジタルバンクであるWeLab Bankは、DynatraceのAIエンジン「Davis」を活用している。Davis AIは、システムの潜在的な問題を誤警報なしに早期検出するためのインサイトを提供し、根本原因分析にかかる時間を従来の数時間からわずか数分へと短縮することに成功した。この事例は、AIOpsがインシデント対応の速度を桁違いに向上させることを明確に示している 46。

5.3. 証券取引システムのパフォーマンス改善とセキュリティ強化

楽天証券は、1日に2兆円を超える株式取引を処理する巨大システムの安定運用というミッションを担っている。同社は、多種多様かつ膨大な量のログを収集・分析し、障害原因の特定やセキュリティインシデントの調査を行うための基盤としてSplunkを導入した。これにより、障害発生時の原因調査時間が短縮されただけでなく、セキュリティログ分析基盤の早期構築とTCO（総所有コスト）の削減を実現した。金融取引の最前線において、パフォーマンスの維持とセキュリティの確保という二つの至上命題を達成する上で、オブザーバビリティがいかに不可欠であるかを示す好例である 59。

5.4. 導入から得られる投資対効果（ROI）とビジネスインパクト

オブザーバビリティへの投資は、単なるITコストではなく、明確なビジネスリターンを生み出す戦略的投資である。Splunkが実施した調査によれば、金融サービス業界におけるオブザーバビリティソリューションへの投資は、年間の投資利益率（ROI）が平均で2.5倍にのぼると報告されている 25。

さらに、その効果はIT部門内に留まらない。同調査では、回答者の65%がオブザーバビリティの実践が「収益にプラスの影響を与えている」と回答し、74%が「従業員の生産性にプラスの影響を与えている」と報告している 51。これは、システムのダウンタイム削減やチームの効率化が、優れた顧客体験の創出を通じて、直接的・間接的にビジネスの成長に貢献していることを示唆している。オブザーバビリティは、もはや技術的な課題解決のためのツールではなく、データドリブンな意思決定を支援し、デジタルビジネスを勝ち抜くための戦略的必須要件なのである 16。

結論：オブザーバビリティが拓く、次世代金融システムの未来

本レポートで論じてきたように、金融システムの複雑性が指数関数的に増大し続ける現代において、オブザーバビリティはもはや技術的な選択肢の一つではなく、ビジネスの継続性と成長を支えるための戦略的必須要件である 16。オープンバンキング、FinTechとの連携、そしてデジタルチャネルへの全面的な移行という不可逆的な変化の波は、ITシステムの安定運用に対する要求をかつてないレベルにまで高めている。この要求に応えるためには、従来のリアクティブな監視から、オブザーバビリティに基づくプロアクティブな運用へとパラダイムを転換することが不可欠である。

この移行は、単にシステムの信頼性を向上させ、MTTR（平均修復時間）を短縮するだけに留まらない。それは、開発、運用、セキュリティ、さらにはビジネス部門までもが、統一されたデータという「共通言語」の上で協業することを可能にし、組織全体のサイロを破壊する。データドリブンな意思決定が組織文化として根付くことで、金融機関は顧客ニーズの変化に対してより迅速かつ的確に対応し、継続的なイノベーションを加速させることができる 1。

未来を展望すれば、AIOpsとの融合により、オブザーバビリティはさらなる進化を遂げるであろう。障害の予兆を検知し、根本原因を特定し、そして自己修復する自律的な運用（Autonomous Operations）の実現も、もはや空想の産物ではない。このような高度にレジリエントなシステムは、金融機関がより安全かつ迅速に、革新的なデジタルサービスを社会に提供するための強固な基盤となる。

したがって、金融機関の経営層およびITリーダーは、オブザーバビリティを単なるIT運用ツールとしてではなく、全社的なデジタルトランスフォーメーションを成功に導くための核心的要素として位置づけ、戦略的な投資判断を行うことが強く求められる。この変革の旅路は決して平坦ではないが、その先に待つのは、より強固で、俊敏で、そして顧客から真に信頼される次世代の金融システムの姿である。AI MQL合同会社は、そのAIとデータ分析に関する深い専門知識をもって、この重要な変革を目指す金融機関の戦略的パートナーとなり得る。

引用

  1. 「観る力」が変える金融DX、イノベーションを加速させるオブザーバビリティ – ビジネス+IT,  2025年10月参照  https://www.sbbit.jp/document/sp/22942
  2. 金融機関のDXを支えるリスク管理の新潮流 「オブザーバビリティ（可観測性）」の真髄とは？（New Relic） | ペイメントナビ,  2025年10月参照  https://paymentnavi.com/paymentnews/152022.html
  3. Datadog入門：監視とオブザーバビリティの違いから導入・設定方法まで徹底解説,  2025年10月参照  https://eeengineer.com/datadog-guide-for-beginners/
  4. レガシーシステムのモダナイゼーション ～競争力の確保に向けたプラットフォームの最適化,  2025年10月参照  https://financialservicesblog.accenture.com/modernization-of-legacy-systems-and-optimization-of-platforms-for-securing-competitiveness
  5. マイクロサービスは本当に必要？プログラム解析を活用した投資対効果の評価方法とは | DATA INSIGHT | NTTデータ,  2025年10月参照  https://www.nttdata.com/jp/ja/trends/data-insight/2023/0619/
  6. 金融サービス向けデジタルサービス・プラットフォーム（DSP）の活用が拡がるワケ | IBM,  2025年10月参照  https://www.ibm.com/jp-ja/think/insights/banking-financial-markets-dx-dsp
  7. オブザーバビリティ(可観測性)の概要 – Splunk,  2025年10月参照  https://www.splunk.com/ja_jp/blog/devops/observability.html
  8. AWS 導入事例：住信SBIネット銀行株式会社 様 – マルチリージョン構成による 災対環境の構築で,  2025年10月参照  https://atlax.nri.co.jp/cases/20240201_aws/
  9. 金融分野におけるサイバーセキュリティに関する ガイドライン 令和６年 10 月４日 金融庁,  2025年10月参照  https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf
  10. オブザーバビリティとは｜IT用語辞典 – SCSK,  2025年10月参照  https://www.scsk.jp/sp/itpnavi/glossary/a_line/a_line_o/observability.html
  11. 監視がオブザーバビリティと異なる3つの理由 | Elastic Blog,  2025年10月参照  https://www.elastic.co/jp/blog/monitoring-observability-differences
  12. オブザーバビリティとは？意味や監視との違い、IT運用における必要性を解説 | オージス総研,  2025年10月参照  https://www.ogis-ri.co.jp/column/cloud_arch/c107810.html
  13. オブザーバビリティとは？監視との違い、必要性について解説 – New Relic,  2025年10月参照  https://newrelic.com/jp/blog/best-practices/what-is-observability-difference-from-monitoring
  14. 近年注目の「オブザーバビリティ」とは？「モニタリング」の違いと導入の必要性について解説,  2025年10月参照  https://sre.sproutly.co.jp/column/about-observability/
  15. newrelic.com,  2025年10月参照  https://newrelic.com/jp/blog/best-practices/what-is-observability#:~:text=%E3%82%AA%E3%83%96%E3%82%B6%E3%83%BC%E3%83%90%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3%EF%BC%88%E5%8F%AF%E8%A6%B3%E6%B8%AC%E6%80%A7,%E3%81%AE%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9%E3%82%92%E6%8C%87%E3%81%97%E3%81%BE%E3%81%99%E3%80%82
  16. オブザーバビリティとは：利点とユースケース – New Relic,  2025年10月参照  https://newrelic.com/jp/blog/best-practices/what-is-observability
  17. ビジネスを止めないIT運用 予兆検知で実現する“プロアクティブ監視” – エフサステクノロジーズ,  2025年10月参照  https://www.fsastech.com/ja-jp/offering/surveillance_smp/
  18. 監視からオブザーバビリティへ – Zenn,  2025年10月参照  https://zenn.dev/yuta28/articles/cloud-observability
  19. オブザーバビリティメトリクスの理解：種類、ゴールデンシグナル、ベストプラクティス | Elastic Blog,  2025年10月参照  https://www.elastic.co/jp/blog/observability-metrics
  20. オブザーバビリティとは何？その本質と重要性について解説,  2025年10月参照  https://www.colt.net/ja/resources/what-is-observability/
  21. オブザーバビリティの3つの柱：統合ログ、メトリック、トレース | Elastic Blog,  2025年10月参照  https://www.elastic.co/jp/blog/3-pillars-of-observability
  22. 近年注目のオブザーバビリティとは？導入メリットを分かりやすく解説,  2025年10月参照  https://ent.iij.ad.jp/articles/8888/
  23. AWSにおけるオブザーバビリティのメリットは？課題とツールを紹介 – New Relic,  2025年10月参照  https://newrelic.com/jp/blog/best-practices/benefits-of-observability-in-aws
  24. New Relicオブザーバビリティプラットフォーム,  2025年10月参照  https://newrelic.com/jp/platform
  25. 金融サービス業界のオブザーバビリティの現状 – Splunk,  2025年10月参照  https://www.splunk.com/ja_jp/campaigns/state-of-observability-in-financial-services.html
  26. New Relic – 日立ソリューションズ,  2025年10月参照  https://www.hitachi-solutions.co.jp/newrelic/
  27. 導入事例：株式会社ジェーシービー – Datadog,  2025年10月参照  https://www.datadoghq.com/ja/case-studies/jcb/
  28. 企業向けマイクロサービスのガイドラインが不足している｜その課題克服へ向けたWGの活動テーマと実践 ～TEC-JのWGメンバーを訪ねて – アイマガジン｜i Magazine,  2025年10月参照  https://www.imagazine.co.jp/tec-j-wg002-4/
  29. 金融サービスにおけるセキュリティ (およびコンプライアンス) とは – Red Hat,  2025年10月参照  https://www.redhat.com/ja/topics/security/security-and-compliance-financial-services
  30. 金融業に向けたサイバーセキュリティとコンプライアンスのガイド – JA – Imperva,  2025年10月参照  https://www.imperva.com/ja/resource-library/ebooks/%E9%87%91%E8%9E%8D%E6%A5%AD%E3%81%AB%E5%90%91%E3%81%91%E3%81%9F%E3%82%B5%E3%82%A4%E3%83%90%E3%83%BC%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%A8%E3%82%B3%E3%83%B3%E3%83%97%E3%83%A9/
  31. 金融情報システム センター (FISC) – Microsoft Compliance,  2025年10月参照  https://learn.microsoft.com/ja-jp/compliance/regulatory/offering-fisc-japan
  32. Observability Pipelines（観測データの制御） – Datadog,  2025年10月参照  https://www.datadoghq.com/ja/product/observability-pipelines/
  33. オブザーバビリティプラットフォームサービス New Relic®｜BIPROGY株式会社,  2025年10月参照  https://www.biprogy.com/solution/service/observability_newrelic.html
  34. 株式会社みんなの銀行の導入事例 | Google Cloud Documentation,  2025年10月参照  https://cloud.google.com/customers/minnabank?hl=ja
  35. FinTech（フィンテック）とは？仕組み・最新動向・活用事例を解説 – カオピーズ,  2025年10月参照  https://kaopiz.com/ja-news-fintech-overview-trends/
  36. 導入事例：ソフトバンク株式会社 | Datadog,  2025年10月参照  https://www.datadoghq.com/ja/case-studies/softbank/
  37. オブザーバビリティ（可観測性）入門ガイド – New Relic,  2025年10月参照  https://newrelic.com/jp/resources/ebooks/the-age-of-observability
  38. AIOpsとは？AIOpsの基本 – Splunk,  2025年10月参照  https://www.splunk.com/ja_jp/blog/artificial-intelligence/aiops.html
  39. AIOpsとは？特徴と導入メリットを事例でわかりやすく解説,  2025年10月参照  https://www.colt.net/ja/resources/what-is-aiops/
  40. AIOps とは？運用効率向上とコスト削減を実現する最新技術の全貌 | Magic Moment,  2025年10月参照  https://magicmoment.jp/blog/aiops
  41. AIOpsとは？ – Elastic,  2025年10月参照  https://www.elastic.co/jp/what-is/aiops
  42. Gartner on AIOps : A Complete Guide – Aisera,  2025年10月参照  https://aisera.com/blog/gartner-on-aiops-the-complete-guide/
  43. Cutting through the IT Operations noise: Understanding the AIOps Magic Quadrant – eesel AI,  2025年10月参照  https://www.eesel.ai/blog/aiops-magic-quadrant
  44. Gartner Market Guide for AIOps: Essential Reading for ITOps and SRE | IBM,  2025年10月参照  https://www.ibm.com/think/insights/gartner-market-guide-for-aiops-essential-reading-for-itops-and-sre
  45. 昔ながらの監視ツールから脱却しよう！Datadog APMで学ぶオブザーバビリティ実践法 (3/3),  2025年10月参照  https://codezine.jp/article/detail/17469?p=3
  46. お客様事例 – Dynatrace,  2025年10月参照  https://www.dynatrace.com/ja/customers/
  47. Best AIOps Platforms Reviews 2025 | Gartner Peer Insights,  2025年10月参照  https://www.gartner.com/reviews/market/aiops-platforms
  48. AIOps done right infographic – Dynatrace Resources,  2025年10月参照  https://info.dynatrace.com/global_all_wp_aiops_done_right_infographic_12472_fulfillment_old.html
  49. Broadcom Named a Leader in the Gartner Magic Quadrant for Application Performance Monitoring Suites for Second Consecutive Year,  2025年10月参照  https://www.broadcom.com/company/news/product-releases/52236
  50. AIOpsを活用したシステム運用自動化への挑戦 | NTTデータ | DATA INSIGHT,  2025年10月参照  https://www.nttdata.com/jp/ja/trends/data-insight/2021/1104/
  51. ASCII.jp：Splunkレポート：オブザーバビリティはAI導入、顧客体験、製品イノベーションのビジネスを加速させる触媒に,  2025年10月参照  https://ascii.jp/elem/000/004/336/4336426/
  52. AIを活用した故障予測・異常検知とは？手法や成功に導くポイントを紹介 – NEC,  2025年10月参照  https://jpn.nec.com/solution/dotdata/tips/failure-prediction/index.html
  53. AI異常検知の活用事例17選！不正利用やムダ削減、KPI急変検知など | ニューラルオプト,  2025年10月参照  https://neural-opt.com/anomaly-detection-cases/
  54. インバリアント分析 – BluStellar AI – NEC,  2025年10月参照  https://jpn.nec.com/ai/analyze/invariant.html
  55. Observability（オブザーバビリティ）とは何か？知っておきたい新しいIT運用の考え方 – マクニカ,  2025年10月参照  https://www.macnica.co.jp/business/security/manufacturers/splunk/blog_20230515.html
  56. 株式会社みずほ銀行 – IBM,  2025年10月参照  https://www.ibm.com/jp-ja/case-studies/mizuho-observability
  57. オブザーバビリティを実装 – オペレーショナルエクセレンスの柱 – AWS Documentation,  2025年10月参照  https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/implement-observability.html
  58. 株式会社 SBI 新生銀行 導入事例 – インターネットバンキングサービス – New Relic,  2025年10月参照  https://newrelic.com/sites/default/files/2025-04/newrelic_casestudy_SBI%E6%96%B0%E7%94%9F%E9%8A%80%E8%A1%8C%E6%A7%98.pdf
  59. Splunk – ユーザー事例 – セキュリティ事業 – マクニカ,  2025年10月参照  https://www.macnica.co.jp/business/security/manufacturers/splunk/case/
お問い合わせ

関連記事

TOP