Well-Architected Framework: 金融サービス（FS）の視点

Last reviewed 2026-10-28 UTC

このページは、Well-Architected Framework の FSI の観点のすべてのページを 1 ページビューにまとめたものです。このページは印刷することも、ブラウザの印刷機能を使用して PDF 形式で保存することもできます。

このページには目次がありません。このページのリンクを使用してページ内を移動することはできません。

Google Cloud Well-Architected Framework のこのドキュメントでは、運用、セキュリティ、信頼性、費用、パフォーマンスの目標を達成する金融サービス（FS）アプリケーションを Google Cloud で設計、構築、管理するうえで役立つ原則と推奨事項について説明します。

このドキュメントのターゲット オーディエンスは、 Google Cloudで FS ワークロードの設計、構築、デプロイ、メンテナンスを行う意思決定者、アーキテクト、管理者、デベロッパー、オペレーターです。このガイダンスの対象となる FS 組織の例としては、銀行、決済インフラストラクチャ プレーヤー、保険会社、資本市場オペレーターなどがあります。

FS 組織には、特にアーキテクチャと復元力に関する特別な考慮事項があります。これらの考慮事項は、主に規制、リスク、パフォーマンスの要件によって推進されます。このドキュメントでは、世界中のさまざまな FS のお客様から得られた設計上の考慮事項に基づいて、全体的なガイダンスを提供します。ワークロードが完全にクラウドにある場合でも、ハイブリッドまたはマルチクラウドのデプロイに移行する場合でも、このドキュメントのガイダンスは、規制要件と多様なリスクの観点を満たすように Google Cloud でワークロードを設計するのに役立ちます。このガイダンスは、すべての組織に固有の課題に対応しているわけではありません。これは、金融サービス組織の主要な規制要件の多くに対応する基盤となります。

クラウド ワークロードを設計する際の主な課題は、クラウド デプロイをオンプレミス環境に合わせることです。特に、セキュリティ、信頼性、復元力に対して一貫したアプローチを目指す場合は、この課題が顕著になります。クラウド サービスは、管理オーバーヘッドの削減、費用の最適化、セキュリティの強化、信頼性と復元力の向上を実現するために、アーキテクチャを根本的に見直す機会を提供します。

次のページでは、Well-Architected Framework の各柱の FS ワークロードに固有の原則と推奨事項について説明します。

• FS の視点: 効果的な運用
• フィールド セールスの視点: セキュリティ
• FS の視点: 信頼性
• FS の視点: 費用の最適化
• フィールド セールスの視点: パフォーマンスの最適化

寄稿者

著者:

• Alex Stepney | リード プリンシパル アーキテクト
• Phil Bryan | EMEA FSI リード プリンシパル アーキテクト
• Stathis Onasoglou | EMEA FSI プリンシパル アーキテクト
• Sam Moss | EMEA FinOps プロフェッショナル サービス リード

その他の寄稿者:

• Daniel Lees | クラウド セキュリティ アーキテクト
• Danielle Fisla | 米国 FS ポートフォリオ リード、PSO
• Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
• Gino Pelliccia | プリンシパル アーキテクト
• Henry Cheng | プリンシパル アーキテクト
• John Bacon | パートナー ソリューション アーキテクト
• Jose Andrade | カスタマー エンジニア兼 SRE スペシャリスト
• Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
• Laura Hyatt | カスタマー エンジニア兼 FSI
• Michael Yang | 業界ソリューション AI コンサルティング リード、FSI
• Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト
• Omar Saenz | EMEA パートナー エンジニア、セキュリティ
• Radhika Kanakam | Google Cloud Well-Architected Framework プログラム リード
• Steve McGhee | 信頼性アドボケイト
• Tarun Sharma | プリンシパル アーキテクト
• Yuriy Babenko | FSI 担当カスタマー エンジニア

金融サービスの視点: 効果的な運用

このドキュメント（Google Cloud Well-Architected Framework: 金融サービス（FS）の視点）では、 Google Cloudで堅牢な FS ワークロードを構築、デプロイ、運用するための原則と推奨事項の概要について説明します。これらの推奨事項は、オブザーバビリティ、自動化、スケーラビリティなどの基本的な要素を設定するのに役立ちます。このドキュメントの推奨事項は、Well-Architected Framework のオペレーショナル エクセレンスの柱に沿っています。

Google Cloud の FS ワークロードは、規制が厳しく機密性が高いため、優れた運用が不可欠です。オペレーショナル エクセレンスにより、クラウド ソリューションは進化するニーズに適応し、価値、パフォーマンス、セキュリティ、信頼性の要件を満たすことができます。これらの領域で障害が発生すると、多大な金銭的損失、規制上の罰則、評判の低下につながる可能性があります。

オペレーショナル エクセレンスは、FS ワークロードに次のメリットをもたらします。

• 信頼と評判を維持する: 金融機関は、顧客の信頼に大きく依存しています。業務の中断やセキュリティ侵害は、この信頼を著しく損ない、顧客の離脱を招く可能性があります。オペレーショナル エクセレンスは、これらのリスクを最小限に抑えるのに役立ちます。

• 厳しい規制遵守要件を満たす: 金融サービスは、次のような多数の複雑な規制の対象となります。

  • EU の一般データ保護規則（GDPR）
  • EU デジタル オペレーショナル レジリエンスに関する規制（DORA）
  • カリフォルニア州消費者プライバシー法（CCPA）
  • 業界固有の規制

  規制へのコンプライアンスを実証し、ペナルティを回避するには、堅牢な運用プロセス、モニタリング、インシデント管理が不可欠です。

• ビジネスの継続性と復元力を確保する: 金融市場とサービスは、多くの場合、継続的に運用されます。そのため、高可用性と効果的な障害復旧が最も重要です。オペレーショナル エクセレンスの原則は、復元性に優れたシステムの設計と実装の指針となります。信頼性の柱では、この分野に関するガイダンスをさらに提供しています。

• 機密データを保護する: 金融機関は、機密性の高い顧客データや財務データを大量に扱います。データ侵害を防ぎ、プライバシーを維持するには、強力な運用管理、セキュリティ モニタリング、迅速なインシデント対応が不可欠です。セキュリティの柱では、この分野に関する詳細なガイダンスを提供しています。

• 重要なアプリケーションのパフォーマンスを最適化する: 取引プラットフォームやリアルタイム分析など、多くの金融アプリケーションでは、高パフォーマンスと低レイテンシが求められます。これらのパフォーマンス要件を満たすには、高度に最適化されたコンピューティング、ネットワーキング、ストレージの設計が必要です。パフォーマンス最適化の柱では、この分野に関するガイダンスをさらに提供しています。

• 費用を効果的に管理する: 金融機関は、セキュリティと信頼性に加えて、費用対効果も重視しています。オペレーショナル エクセレンスには、リソース使用率の最適化とクラウド支出の管理に関するプラクティスが含まれます。費用最適化の柱では、この分野に関するガイダンスをさらに提供しています。

このドキュメントのオペレーショナル エクセレンスの推奨事項は、次の基本原則にマッピングされています。

• SLA とそれに対応する SLO / SLI の定義
• インシデント管理プロセスの定義とテスト
• 改善とイノベーションを継続的に行う

SLA とそれに対応する SLO / SLI の定義

多くの FS 組織では、アプリケーションの可用性は通常、目標復旧時間（RTO）と目標復旧時点（RPO）の指標に基づいて分類されます。外部のお客様にサービスを提供するビジネスクリティカルなアプリケーションの場合は、サービスレベル契約（SLA）が定義されることもあります。

SLA には、ユーザー満足度の観点からシステムの動作を表す指標のフレームワークが必要です。サイト信頼性エンジニアリング（SRE）の手法を使用すると、必要なレベルのシステム信頼性を実現できます。指標のフレームワークを作成するには、ユーザーの視点からシステムの健全性を把握するために、主要な数値指標を定義してモニタリングする必要があります。たとえば、レイテンシやエラー率などの指標は、サービスのパフォーマンスを定量化します。これらの指標は、サービスレベル指標（SLI）と呼ばれます。効果的な SLI を開発することは、信頼性を客観的に評価するために必要な元データを提供するため、非常に重要です。

意味のある SLA、SLI、SLO を定義するには、次の推奨事項を考慮してください。

• 重要なサービスごとに SLI を開発して定義します。許容可能なパフォーマンス レベルを定義する目標値を設定します。
• SLI に対応するサービスレベル目標（SLO）を策定して定義します。たとえば、SLO では、リクエストの 99.9% のレイテンシが 200 ミリ秒未満である必要があると規定できます。
• サービスが SLO を満たしていない場合に実施する必要がある内部の是正措置を特定します。たとえば、プラットフォームの復元力を向上させるには、開発リソースを問題の修正に集中させる必要があります。
• 各サービスの SLA 要件を検証し、SLA をサービス ユーザーとの正式な契約として認識します。

サービスレベルの例

次の表に、決済プラットフォームの SLI、SLO、SLA の例を示します。

ビジネス指標	SLI	SLO	SLA
支払い取引の成功	開始されたすべての支払い取引のうち、正常に処理され、確認された取引の割合を定量的に測定したものです。 例: （成功したトランザクションの数 ÷ 有効なトランザクションの総数）× 100。5 分間のローリング ウィンドウで測定されます。	特定の期間にわたって、成功した支払い取引の割合を高く維持するための内部目標。 例: 無効なリクエストと計画メンテナンスを除き、30 日間のローリング ウィンドウで 99.98% の支払いトランザクション成功率を維持します。	支払い取引処理の成功率と速度に関する契約上の保証。 例: サービス提供者は、クライアントが開始した支払いトランザクションの 99.0% が 1 秒以内に正常に処理され、確認されることを保証します。
決済処理のレイテンシ	クライアントによる開始から最終確認まで、支払い取引の処理にかかる平均時間。 例: トランザクション確認の平均応答時間（ミリ秒単位）。5 分間のローリング ウィンドウで測定されます。	支払い取引の処理速度に関する内部目標。 例: 30 日間の移動枠内で、支払い取引の 99.5% が 400 ミリ秒以内に処理されるようにします。	重要な支払い処理の問題を、指定された期間内に解決するという契約上のコミットメント。 例: 決済処理の重大な問題（トランザクションの 1% 以上に影響する停止と定義）の場合、サービス提供者は、問題が報告または検出されてから 2 時間以内に解決することを確約します。
プラットフォームの可用性	コア決済処理 API とユーザー インターフェースが稼働し、クライアントがアクセスできる時間の割合。 例:（合計運用時間 - ダウンタイム）÷ 合計運用時間 × 100（1 分ごとに測定）。	コア決済プラットフォームの稼働時間に関する内部目標。 例: 計画メンテナンスの時間枠を除き、1 か月あたり 99.995% のプラットフォーム可用性を実現する。	決済プラットフォームの最小稼働時間に関する、クライアントに対する正式な法的拘束力のあるコミットメント。これには、コミットメントを達成できなかった場合の結果も含まれます。 例: プラットフォームは、スケジュールされたメンテナンスの時間枠を除き、各暦月で 99.9% 以上の可用性を維持します。可用性が最低レベルを下回った場合、クライアントは 0.1% の低下ごとに月額サービス手数料の 5% のサービス クレジットを受け取ります。

SLI データを使用して、システムが定義された SLO 内にあるかどうかをモニタリングし、SLA が満たされていることを確認します。明確に定義された一連の SLI を使用することで、エンジニアとデベロッパーは次のレベルで FS アプリケーションをモニタリングできます。

• アプリケーションがデプロイされているサービス（Google Kubernetes Engine や Cloud Run など）内で直接。
• ロードバランサなどのインフラストラクチャ コンポーネントによって提供されるログを使用する。

OpenTelemetry は、指標、トレース、ログなど、あらゆる種類のテレメトリーをキャプチャするためのオープンソース標準と一連のテクノロジーを提供します。Google Cloud Managed Service for Prometheus は、Prometheus の指標と運用を大規模に処理するための、フルマネージドでスケーラビリティに優れたバックエンドを提供します。

SLI、SLO、エラー バジェットの詳細については、SRE ハンドブックをご覧ください。

効果的なアラートとモニタリングのダッシュボードとメカニズムを開発するには、Google Cloud Observability ツールと Cloud Monitoring を組み合わせて使用します。セキュリティ固有のモニタリング機能と検出機能については、セキュリティの柱をご覧ください。

インシデント管理プロセスの定義とテスト

明確に定義され、定期的にテストされるインシデント管理プロセスは、 Google Cloudの FS ワークロードの価値、パフォーマンス、セキュリティ、信頼性に直接貢献します。これらのプロセスは、金融機関が厳格な規制要件を満たし、機密データを保護し、ビジネスの継続性を維持し、顧客の信頼を維持するのに役立ちます。

インシデント管理プロセスを定期的にテストすると、次のようなメリットがあります。

• ピーク負荷時のパフォーマンスを維持する: 定期的なパフォーマンス テストと負荷テストにより、金融機関は、クラウドベースのアプリケーションとインフラストラクチャが、パフォーマンスを低下させることなく、ピーク時の取引量、市場の変動、その他の高需要シナリオに対応できることを確認できます。この機能は、シームレスなユーザー エクスペリエンスを維持し、金融市場の需要を満たすために不可欠です。
• 潜在的なボトルネックと制限を特定する: ストレステストでは、システムを限界まで追い込むことで、金融機関は重要なオペレーションに影響を与える前に、潜在的なボトルネックとパフォーマンスの制限を特定できます。このプロアクティブなアプローチにより、金融機関はインフラストラクチャとアプリケーションを調整して、最適なパフォーマンスとスケーラビリティを実現できます。
• 信頼性と復元力を検証する: カオス エンジニアリングや障害のシミュレーションなどの定期的なテストは、金融システムの信頼性と復元力を検証するのに役立ちます。このテストにより、システムが障害から正常に復旧し、高可用性を維持できることが確認されます。これは、ビジネスの継続性に不可欠です。
• 効果的な容量計画を実行する: パフォーマンス テストでは、さまざまな負荷条件でのリソース使用率に関する貴重なデータが得られます。これは、正確な容量計画に不可欠です。金融機関は、このデータを使用して、将来の容量ニーズを事前に予測し、リソースの制約によるパフォーマンスの問題を回避できます。
• 新機能とコード変更を正常にデプロイする: 自動テストを CI / CD パイプラインに統合すると、変更と新しいデプロイが本番環境にリリースされる前に、徹底的に検証されます。このアプローチにより、運用の中断につながる可能性のあるエラーや回帰のリスクが大幅に軽減されます。
• システムの安定性に関する規制要件を満たす: 金融規制では、重要なシステムの安定性と信頼性を確保するために、金融機関に堅牢なテスト手法を求めることがよくあります。定期的なテストは、これらの要件への準拠を実証するのに役立ちます。

インシデント管理プロセスを定義してテストするには、次の推奨事項を検討してください。

明確なインシデント対応手順を確立する

確立されたインシデント対応手順には、次の要素が含まれます。

• インシデント コマンダー、調査担当者、コミュニケーション担当者、テクニカル エキスパートに定義された役割と責任。効果的で調整された対応を確実にします。
• インシデント中に情報が迅速かつ効果的に共有されるように定義された通信プロトコルとエスカレーション パス。
• コミュニケーション、トリアージ、調査、解決の手順を概説するランブックまたはハンドブックに記載されている手順。
• チームが効果的に対応するための知識とスキルを身につけるための定期的なトレーニングと準備。

パフォーマンス テストと負荷テストを定期的に実装する

定期的なパフォーマンス テストと負荷テストにより、クラウドベースのアプリケーションとインフラストラクチャがピーク負荷を処理し、最適なパフォーマンスを維持できるようにします。負荷テストでは、現実的なトラフィック パターンをシミュレートします。ストレステストでは、システムを限界までテストして、潜在的なボトルネックとパフォーマンスの制限を特定します。Cloud Load Balancing などのプロダクトや負荷テストサービスを使用して、実際のトラフィックをシミュレートできます。テスト結果に基づいて、最適なパフォーマンスとスケーラビリティを実現するようにクラウド インフラストラクチャとアプリケーションを調整できます。たとえば、リソース割り当てを調整したり、アプリケーション構成をチューニングしたりできます。

CI / CD パイプライン内のテストを自動化する

自動テストを CI / CD パイプラインに組み込むと、デプロイ前に変更を検証することで、クラウド アプリケーションの品質と信頼性を確保できます。このアプローチにより、エラーや回帰のリスクが大幅に軽減され、より安定した堅牢なソフトウェア システムを構築できます。CI / CD パイプラインには、単体テスト、統合テスト、エンドツーエンド テストなど、さまざまな種類のテストを組み込むことができます。Cloud Build や Cloud Deploy などのプロダクトを使用して、CI / CD パイプラインを作成して管理します。

改善とイノベーションを継続的に行う

クラウド内の金融サービス ワークロードの場合、クラウドへの移行は最初のステップにすぎません。継続的な強化とイノベーションが不可欠な理由は次のとおりです。

• イノベーションを加速する: AI などの新しいテクノロジーを活用してサービスを改善します。
• 費用の削減: 非効率性を排除し、リソースの使用を最適化します。
• アジリティの向上: 市場や規制の変化に迅速に対応します。
• 意思決定を改善する: BigQuery や Looker などのデータ分析プロダクトを使用して、情報に基づいた選択を行います。

継続的な改善とイノベーションを実現するには、次の推奨事項を検討してください。

定期的に事後検証を行う

振り返りは、インシデント対応手順を継続的に改善し、定期的なパフォーマンス テストと負荷テストの結果に基づいてテスト戦略を最適化するために不可欠です。振り返りを効果的に行うには、次のことを行います。

• チームが経験を振り返り、うまくいったことを特定し、改善すべき点を明確にする機会を提供します。
• プロジェクトのマイルストーン、重大なインシデント、重要なテストサイクルの後に、振り返りを行います。チームは成功と失敗の両方から学び、プロセスとプラクティスを継続的に改善できます。
• 開始、停止、継続モデルなどの構造化されたアプローチを使用して、振り返りセッションが生産的で、実用的なステップにつながるようにします。
• 振り返りを使用して、変更管理の自動化をさらに強化して信頼性を向上させ、リスクを軽減できる領域を特定します。

学びの文化を育てる

学習の文化は、Google Cloudにおける新しいテクノロジーの安全な探索を促進します。たとえば、不正行為の検出やパーソナライズされた金融アドバイスなどのサービスを強化する AI や ML の機能などです。学習の文化を促進するには、次のことを行います。

• チームがテストを行い、知識を共有し、継続的に学習することを奨励します。
• 失敗を成長と改善の機会と捉える、誰かのせいにしない文化を採用します。
• チームがリスクを冒して革新的なソリューションを検討できる、心理的に安全な環境を構築します。チームは成功と失敗の両方から学び、より回復力と適応力の高い組織へと成長します。
• インシデント管理プロセスとテスト演習から得られた知識の共有を促進する文化を構築します。

クラウド テクノロジーの最新情報を入手する

継続的な学習は、新しいセキュリティ対策の理解と実装、高度なデータ分析の活用による分析情報の向上、金融サービスに関連する革新的なソリューションの導入に不可欠です。

• 最新の進歩、機能、ベスト プラクティスを常に把握することで、 Google Cloud サービスの可能性を最大限に引き出します。
• 新しい Google Cloud の機能やサービスが導入されたら、プロセスの自動化、セキュリティの強化、アプリケーションのパフォーマンスとスケーラビリティの向上をさらに進める機会を特定します。
• 関連するカンファレンス、ウェブセミナー、トレーニング セッションに参加して、知識を広げ、新しい機能を理解します。
• チームメンバーに Google Cloud 認定資格の取得を促し、クラウドで成功するために必要なスキルを組織が確実に備えられるようにします。

金融サービスの視点: セキュリティ、プライバシー、コンプライアンス

このドキュメント（Google Cloud Well-Architected Framework: 金融サービス（FS）の視点）では、 Google Cloudで金融サービス（FS）ワークロードのセキュリティ、プライバシー、コンプライアンスの要件に対応するための原則と推奨事項の概要について説明します。この推奨事項は、復元力とコンプライアンスに優れたインフラストラクチャの構築、機密データの保護、顧客の信頼の維持、複雑な規制要件への対応、サイバー脅威の効果的な管理に役立ちます。このドキュメントの推奨事項は、Well-Architected Framework のセキュリティの柱に沿っています。

クラウド コンピューティングのセキュリティは、金融サービス機関にとって重要な懸念事項です。金融サービス機関は、顧客の詳細情報や財務記録など、大量の機密データを管理しているため、サイバー犯罪者にとって非常に魅力的です。セキュリティ侵害の結果は、多大な金銭的損失、長期的な評判の低下、多額の規制上の罰金など、非常に深刻です。そのため、FS ワークロードには厳格なセキュリティ管理が必要です。

包括的なセキュリティとコンプライアンスを確保するには、お客様（FS 組織）と Google Cloudの間の責任の共有を理解する必要があります。 Google Cloud は、物理的なセキュリティやネットワーク セキュリティなど、基盤となるインフラストラクチャの保護に責任を負います。お客様は、データとアプリケーションの保護、アクセス制御の構成、セキュリティ サービスの構成と管理を行う責任があります。セキュリティへの取り組みをサポートするため、Google Cloud パートナー エコシステムでは、セキュリティ統合とマネージド サービスを提供しています。

このドキュメントのセキュリティに関する推奨事項は、次の基本原則にマッピングされています。

• 安全性を重視した設計を実装する
• ゼロトラストを実装する
• シフトレフト セキュリティを実装する
• プリエンプティブなサイバー防御を実装する
• AI を安全かつ責任を持って使用し、セキュリティに AI を使用する
• 規制、コンプライアンス、プライバシーのニーズに対応する
• セキュリティ イニシアチブの優先順位付け

安全性を重視した設計を実装する

Payment Card Industry データ セキュリティ基準（PCI DSS）、米国の Gramm-Leach-Bliley Act（GLBA）、さまざまな国の金融データ保護法などの金融規制では、セキュリティを最初からシステムに統合することが義務付けられています。設計によるセキュリティの原則では、開発ライフサイクル全体にセキュリティを統合して、最初から脆弱性を最小限に抑えることが重視されています。

Google Cloudの FS ワークロードにセキュリティ バイ デザインの原則を適用するには、次の推奨事項を検討してください。

• Identity and Access Management（IAM）できめ細かいロールベース アクセス制御（RBAC）を使用して最小権限の原則を適用し、必要な権限のみが付与されるようにします。RBAC の使用は、多くの金融規制における重要な要件です。
• VPC Service Controls を使用して、 Google Cloud 内の機密性の高いサービスとデータの周囲にセキュリティ境界を適用します。セキュリティ境界は、規制で義務付けられているように、機密データとリソースをセグメント化して保護し、データの引き出しや不正アクセスを防止するのに役立ちます。
• Terraform などの Infrastructure as Code（IaC）ツールを使用して、セキュリティ構成をコードとして定義します。このアプローチでは、初期デプロイ フェーズからセキュリティ管理を組み込むため、一貫性と監査可能性を確保できます。
• Cloud Build を使用して、静的アプリケーション セキュリティ テスト（SAST）を CI / CD パイプラインに統合し、アプリケーション コードをスキャンします。自動化されたセキュリティ ゲートを確立して、コンプライアンスに準拠していないコードのデプロイを防ぎます。
• Security Command Center を使用して、セキュリティ分析情報の統合インターフェースを提供します。Security Command Center を使用すると、規制違反につながる可能性のある構成ミスや脅威を継続的にモニタリングし、早期に検出できます。ISO 27001 や NIST 800-53 などの標準の要件を満たすには、ポスチャー管理テンプレートを使用します。
• 本番環境のデプロイで特定された脆弱性の減少と、セキュリティのベスト プラクティスに準拠している IaC デプロイの割合を追跡します。Security Command Center を使用すると、脆弱性とセキュリティ標準へのコンプライアンスに関する情報を検出して表示できます。詳細については、脆弱性の検出結果をご覧ください。

ゼロトラストを実装する

最新の金融規制では、厳格なアクセス制御と継続的な検証の必要性がますます強調されています。これらの要件は、内部と外部の脅威や悪意のある行為者からワークロードを保護することを目的としたゼロトラストの原則を反映しています。ゼロトラストの原則は、すべてのユーザーとデバイスの継続的な検証を提唱しています。これにより、暗黙の信頼が排除され、ラテラル ムーブメントが軽減されます。

ゼロトラストを実装するには、次の推奨事項を考慮してください。

• IAM コントロールと Chrome Enterprise Premium を組み合わせることで、ユーザー ID、デバイスのセキュリティ、ロケーション、その他の要素に基づいてコンテキストアウェア アクセスを有効にします。このアプローチにより、財務データやシステムへのアクセスが許可される前に、継続的な検証が行われます。
• Identity Platform（Workforce Identity 連携を使用する場合は外部 ID プロバイダ）を構成して、安全でスケーラブルな Identity and Access Management を提供します。多要素認証（MFA）や、ゼロトラストの実装と規制遵守の確保に不可欠なその他の制御を設定します。
• すべてのユーザー アカウント（特に機密データやシステムにアクセスできるアカウント）に MFA を実装します。
• ユーザー アクセスとネットワーク アクティビティの包括的なロギングとモニタリングを確立することで、規制遵守に関連する監査と調査をサポートします。
• Private Service Connect を使用して、トラフィックを公共のインターネットに公開することなく、Google Cloud 内のサービスとオンプレミス環境間のプライベートで安全な通信を有効にします。
• VPN トンネルなどのネットワーク ベースのセキュリティ メカニズムに依存するのではなく、Identity-Aware Proxy（IAP）を使用して、きめ細かい ID 制御を実装し、アプリケーション レベルでアクセスを認可します。このアプローチは、環境内でのラテラル ムーブメントを減らすのに役立ちます。

シフトレフト セキュリティを実装する

金融規制当局は、積極的なセキュリティ対策を推奨しています。開発ライフサイクルの早い段階で脆弱性を特定して対処することで、セキュリティ インシデントのリスクと、コンプライアンス違反によるペナルティの可能性を軽減できます。シフトレフト セキュリティの原則は、早期のセキュリティ テストと統合を促進し、修復の費用と複雑さを軽減するのに役立ちます。

シフトレフト セキュリティを実装するには、次の推奨事項を検討してください。

• Cloud Build を使用して、コンテナの脆弱性スキャンや静的コード分析などのセキュリティ スキャン ツールを CI / CD パイプラインに統合することで、開発プロセスの早い段階で自動セキュリティ チェックを実行します。

• Artifact Registry を使用して、脆弱性スキャンが統合されたソフトウェア パッケージとコンテナ イメージの安全な中央リポジトリを提供することで、安全なアーティファクトのみがデプロイされるようにします。仮想リポジトリを使用して、リモート リポジトリよりもプライベート アーティファクトを優先することで、依存関係の混乱攻撃を軽減します。

• Security Command Center の一部である Web Security Scanner を開発パイプラインに統合することで、ウェブ アプリケーションを自動的にスキャンして一般的な脆弱性を検出します。

• ソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）フレームワークを使用して、ソースコード、ビルドプロセス、コードの来歴のセキュリティ チェックを実装します。Binary Authorization などのソリューションを使用して、環境で実行されるワークロードの来歴を適用します。Assured Open Source Software を使用して、ワークロードで検証済みのオープンソース ソフトウェア ライブラリのみが使用されるようにします。

• 開発ライフサイクルで特定され、修正された脆弱性の数、セキュリティ スキャンに合格したコードデプロイの割合、ソフトウェアの脆弱性によって発生したセキュリティ インシデントの減少を追跡します。 Google Cloud には、さまざまな種類のワークロードでこの追跡に役立つツールが用意されています。たとえば、コンテナ化されたワークロードの場合は、Artifact Registry のコンテナ スキャン機能を使用します。

プリエンプティブなサイバー防御を実装する

金融機関は、巧妙なサイバー攻撃の格好の標的です。規制では、多くの場合、堅牢な脅威インテリジェンスとプロアクティブな防御メカニズムが求められます。プリエンプティブなサイバー防御は、高度な分析と自動化を使用して、プロアクティブな脅威の検出と対応に重点を置いています。

以下の推奨事項を参考にしてください。

• Mandiant の脅威インテリジェンス、インシデント対応、セキュリティ検証サービスを使用して、潜在的な脅威をプロアクティブに特定して軽減します。
• Google Cloud Armor を使用して、ネットワーク エッジでウェブ エクスプロイトや DDoS 攻撃からウェブ アプリケーションと API を保護します。
• Security Command Center を使用して、セキュリティの検出結果と推奨事項を集約して優先順位を付けます。これにより、セキュリティ チームは潜在的なリスクにプロアクティブに対処できます。
• 定期的なセキュリティ シミュレーションとペネトレーション テストを実施して、予防的な防御とインシデント対応計画を検証します。
• セキュリティ インシデントの検出と対応にかかる時間、DDoS 軽減策の効果、防止されたサイバー攻撃の数を測定します。必要な指標とデータは、Google Security Operations SOAR ダッシュボードから取得できます。

AI を安全かつ責任を持って使用し、セキュリティに AI を活用する

AI と ML は、不正行為の検出やアルゴリズム取引などの金融サービスのユースケースでますます使用されるようになっています。規制により、これらのテクノロジーを倫理的、透明、安全に使用することが求められています。AI は、セキュリティ機能の強化にも役立ちます。AI を使用する際の推奨事項は次のとおりです。

• Gemini Enterprise Agent Platform を使用して、安全で管理された環境で ML モデルを開発してデプロイします。モデルの説明可能性や公平性指標などの機能は、責任ある AI に関する懸念に対処するのに役立ちます。
• Google Security Operations のセキュリティ分析と運用機能を活用します。これは、AI と ML を使用して大量のセキュリティ データを分析し、異常を検出して、脅威への対応を自動化します。これらの機能は、全体的なセキュリティ ポスチャーの強化とコンプライアンス モニタリングに役立ちます。
• セキュリティや倫理に関する考慮事項など、AI と ML の開発とデプロイに関する明確なガバナンス ポリシーを確立します。
• セキュア AI フレームワーク（SAIF）の要素に沿って、AI システムのセキュリティとリスクに関する懸念に対処するための実践的なアプローチを提供します。
• AI を活用した不正行為検出システムの精度と有効性、セキュリティ アラートの誤検知の減少、AI を活用したセキュリティ自動化による効率の向上を追跡します。

規制、コンプライアンス、プライバシーのニーズに対応する

金融サービスは、データ所在地要件、特定の監査証跡、データ保護基準など、さまざまな規制の対象となります。機密データを適切に識別、保護、管理するために、金融サービス組織には、堅牢なデータ ガバナンス ポリシーとデータ分類スキームが必要です。規制要件を満たすために、次の推奨事項を検討してください。

• Assured Workloads を使用して、機密性の高い規制対象のワークロードのデータ境界を Google Cloud に設定します。これにより、FedRAMP や CJIS などの政府や業界固有のコンプライアンス要件を満たすことができます。
• Sensitive Data Protection を実装して、財務情報などの機密データを特定、分類、保護します。これにより、GDPR や CCPA などのデータ プライバシー規制に準拠できます。
• Cloud Audit Logs を使用して、管理アクティビティとリソースへのアクセスの詳細を追跡します。これらのログは、多くの金融規制で定められている監査要件を満たすために不可欠です。
• ワークロードとデータに Google Cloud リージョンを選択する場合は、データ所在地に関連する現地の規制を考慮してください。 Google Cloud グローバル インフラストラクチャを使用すると、データ所在地の要件を満たすのに役立つリージョンを選択できます。
• Cloud Key Management Service を使用して、保存中および転送中の機密性の高い財務データの暗号化に使用される鍵を管理します。このような暗号化は、多くのセキュリティとプライバシーに関する規制の基本的な要件です。
• 規制要件に対処するために必要なコントロールを実装します。コントロールが想定どおりに機能することを確認します。外部監査人による管理の検証を再度行い、ワークロードが規制に準拠していることを規制当局に証明します。

セキュリティ イニシアチブに優先順位を付ける

セキュリティ要件の幅広さを考慮すると、金融機関はリスク評価と規制要件に基づくイニシアチブを優先する必要があります。次の段階的なアプローチをおすすめします。

1. 強固なセキュリティ基盤を確立する: Identity and Access Management、ネットワーク セキュリティ、データ保護など、セキュリティのコア領域に重点を置きます。この重点は、堅牢なセキュリティ ポスチャーの構築に役立ち、進化する脅威に対する包括的な防御を確保するのに役立ちます。
2. 重要な規制に対応する: PCI DSS、GDPR、関連する国内法などの重要な規制へのコンプライアンスを優先します。これにより、データ保護が確保され、法的リスクが軽減され、お客様との信頼関係が構築されます。
3. 高度なセキュリティを実装する: ゼロトラスト、AI 駆動のセキュリティ ソリューション、プロアクティブな脅威ハンティングなどの高度なセキュリティ プラクティスを段階的に導入します。

金融サービスの観点: 信頼性

このドキュメント（Google Cloud Well-Architected Framework: 金融サービス（FS）の視点）では、 Google Cloudで信頼性の高い FS ワークロードを設計、デプロイ、運用するための原則と推奨事項の概要について説明します。このドキュメントでは、高度な信頼性プラクティスとオブザーバビリティをアーキテクチャ ブループリントに統合する方法について説明します。このドキュメントの推奨事項は、Well-Architected Framework の信頼性の柱に沿っています。

金融機関にとって、信頼性と復元性に優れたインフラストラクチャは、ビジネス上のニーズであると同時に、規制上の要件でもあります。Google Cloud の FS ワークロードの信頼性を確保するには、潜在的な障害点を理解して軽減し、リソースを冗長にデプロイして、復旧を計画する必要があります。運用上の復元力は、信頼性の結果です。これは、中断を吸収し、適応し、復旧する能力です。運用上のレジリエンスは、金融サービス組織が厳格な規制要件を満たすのに役立ちます。また、お客様に許容できない損害を与えないようにすることもできます。

Google Cloud の信頼性の主要な構成要素は、リージョン、ゾーン、クラウド リソースのさまざまなロケーション スコープ（ゾーン、リージョン、マルチリージョン、グローバル）です。可用性を向上させるには、マネージド サービスの使用、リソースの分散、高可用性パターンの実装、プロセスの自動化を行います。

規制要件

金融サービス機関は、米国の連邦準備制度、EU の欧州銀行監督局、英国の健全性規制機構などの規制機関による厳格な信頼性要件の下で運営されています。世界中の規制当局が、金融の安定と消費者保護に不可欠なオペレーショナル レジリエンスを重視しています。運用上の復元力とは、中断に耐え、効果的に復旧し、重要なサービスを維持する能力です。これには、技術的なリスクとサードパーティへの依存関係を管理するための調和のとれたアプローチが必要です。

ほとんどの法域の規制要件には、次の共通のテーマがあります。

• サイバーセキュリティと技術的なレジリエンス: サイバー脅威に対する防御を強化し、IT システムのレジリエンスを確保します。
• サードパーティのリスク管理: 情報通信技術（ICT）のプロバイダーへのアウトソーシング サービスに関連するリスクを管理します。
• ビジネスの継続性とインシデント対応: サービスの中断時に重要なオペレーションを維持し、効果的に復旧するための堅牢な計画。
• 金融の安定性の保護: 広範な金融システムの健全性と安定性を確保します。

このドキュメントの信頼性に関する推奨事項は、次の基本原則にマッピングされています。

• マルチゾーン デプロイとマルチリージョン デプロイを優先する
• 単一障害点（SPOF）を排除する
• 集計された空き状況を把握して管理する
• 堅牢な DR 戦略を実装する
• マネージド サービスを利用する
• インフラストラクチャのプロビジョニングと復元プロセスを自動化する

マルチゾーン デプロイとマルチリージョン デプロイを優先する

重要な金融サービス アプリケーションの場合は、少なくとも 2 つのリージョンに分散され、各リージョン内の 3 つのゾーンに分散されたマルチリージョン トポロジを使用することをおすすめします。このアプローチは、ゾーンやリージョンの停止に対する復元力にとって重要です。1 つのゾーンまたはリージョンで障害が発生した場合、ほとんどの法域では、2 番目のゾーンに重大な中断が発生する可能性があると見なされるため、規制ではこのアプローチが規定されていることがよくあります。その理由は、1 つのロケーションで障害が発生すると、もう一方のロケーションで非常に大量の追加トラフィックが発生する可能性があるためです。

ゾーンとリージョンの停止に対する復元力を構築するには、次の推奨事項を検討してください。

• ロケーション スコープが広いリソースを優先します。可能であれば、ゾーンリソースではなくリージョン リソースを使用し、リージョン リソースではなくマルチリージョン リソースまたはグローバル リソースを使用します。このアプローチにより、バックアップを使用してオペレーションを復元する必要がなくなります。
• 各リージョンで、2 つではなく 3 つのゾーンを活用します。フェイルオーバーを処理するには、見積もりよりも 3 分の 1 以上多く容量をオーバープロビジョニングします。
• 次のようなアクティブ / アクティブ デプロイを実装して、手動復元手順を最小限に抑えます。
  • Spanner などの分散データベースは、リージョン間で組み込みの冗長性と同期を提供します。
  • Cloud SQL の HA 機能は、ゾーン間でリードレプリカを使用する、アクティブ / アクティブに近いトポロジを提供します。リージョン間の目標復旧時点（RPO）は 0 に近くなります。
• Cloud DNS を使用してリージョン間でユーザー トラフィックを分散し、各リージョンにリージョン ロードバランサをデプロイします。要件と重要度によっては、グローバル ロードバランサも検討できます。詳細については、マルチリージョン デプロイでのグローバル ロード バランシングの利点とリスクをご覧ください。
• データを保存するには、Spanner や Cloud Storage などのマルチリージョン サービスを使用します。

単一障害点を排除する

リソースを異なるロケーションに分散し、冗長リソースを使用して、単一障害点（SPOF）がアプリケーション スタック全体に影響しないようにします。

SPOF を回避するには、次の推奨事項を考慮してください。

• 単一のアプリケーション サーバーまたはデータベースのみをデプロイすることは避けてください。
• マネージド インスタンス グループ（MIG）を使用して、障害が発生した VM が自動的に再作成されるようにします。
• ロード バランシングを実装して、利用可能なリソースにトラフィックを均等に分散します。
• Cloud SQL などのデータベースに HA 構成を使用する。
• 同期レプリケーションでリージョン永続ディスクを使用して、データの可用性を向上させます。

詳細については、 Google Cloudのワークロードに適した信頼性の高いインフラストラクチャを設計するをご覧ください。

集計された空き状況を把握して管理する

システムの全体的な可用性（総可用性）は、システムの各階層またはコンポーネントの可用性に影響されます。アプリケーション スタックの階層数は、スタックの総可用性とは逆の関係です。集計の可用性を管理する際の推奨事項は次のとおりです。

• tier1_availability × tier2_availability × tierN_availability の式を使用して、多層スタックの総可用性を計算します。

  次の図は、4 つのサービスで構成される多層システムの集計可用性の計算を示しています。

  

  上の図では、各階層のサービスは 99.9% の可用性を提供しますが、システムの総可用性は 99.6%（0.999 × 0.999 × 0.999 × 0.999）と低くなります。一般に、多層スタックの総可用性は、可用性が最も低い階層の可用性よりも低くなります。

• 可能な場合は、チェーンではなく同時読み込みを選択します。並列化されたサービスでは、エンドツーエンドの可用性は個々のサービスの可用性よりも高くなります。

  次の図は、チェーン化と並列化のアプローチを使用してデプロイされた 2 つのサービス A と B を示しています。

  

  上記の例では、どちらのサービスも SLA が 99% であるため、実装方法に応じて次のような集計可用性が得られます。

  • チェーン化されたサービスの合計可用性は 98%（.99 × .99）にすぎません。
  • 並列化されたサービスでは、各サービスが独立して実行され、個々のサービスが他のサービスの可用性の影響を受けないため、合計可用性が 99.99% と高くなります。集約された並列サービスの式は 1 -（1 - A）×（1 - B） です。

• アプリケーション スタックの全体的な稼働時間の要件を満たすために、稼働時間の SLA を備えた Google Cloud サービスを選択します。

• アーキテクチャを設計する際は、可用性、運用の複雑さ、レイテンシ、費用のトレードオフを考慮してください。可用性のナインの数を増やすと、一般的に費用は高くなりますが、規制要件を満たすことができます。

  たとえば、99.9% の可用性（スリーナイン）は、24 時間で 86 秒のダウンタイムが発生する可能性があることを意味します。これに対し、99%（2 つの 9）は、同じ期間に 864 秒のダウンタイムが発生することを意味します。これは、3 つの 9 の可用性よりも 10 倍長いダウンタイムです。

  重要な金融サービスの場合、アーキテクチャのオプションが制限されることがあります。ただし、可用性の要件を特定し、可用性を正確に計算することが重要です。このような評価を行うことで、設計上の決定がアーキテクチャと予算に与える影響を評価できます。

堅牢な DR 戦略を実装する

ゾーンやリージョンの停止など、さまざまな障害シナリオに対して明確に定義された計画を作成します。明確に定義された障害復旧（DR）戦略により、中断から復旧し、影響を最小限に抑えて通常業務を再開できます。

DR と高可用性（HA）は異なるコンセプトです。クラウド デプロイでは、一般に、DR はマルチリージョン デプロイに適用され、HA はリージョン デプロイに適用されます。これらのデプロイ アーキタイプは、さまざまなレプリケーション メカニズムをサポートしています。

• HA: 多くのマネージド サービスでは、デフォルトで単一リージョン内のゾーン間で同期レプリケーションが提供されます。このようなサービスは、目標復旧時間（RTO）と目標復旧時点（RPO）がゼロまたはゼロに近い値をサポートします。このサポートにより、SPOF のないアクティブ / アクティブ デプロイ トポロジを作成できます。
• DR: 2 つ以上のリージョンにデプロイされているワークロードで、マルチリージョン サービスまたはグローバル サービスを使用しない場合は、レプリケーション戦略を定義する必要があります。レプリケーション戦略は通常、非同期です。このようなレプリケーションが重要なアプリケーションの RTO と RPO にどのように影響するかを慎重に評価します。フェイルオーバーに必要な手動または半自動のオペレーションを特定します。

金融機関の場合、フェイルオーバー リージョンの選択は、データ主権とデータ所在地に関する規制によって制限されることがあります。2 つのリージョンにまたがるアクティブ / アクティブ トポロジが必要な場合は、特にデータのレプリケーションが重要な場合は、Spanner や Cloud Storage などのマネージド マルチリージョン サービスを選択することをおすすめします。

以下の推奨事項を参考にしてください。

• データにマネージド マルチリージョン ストレージ サービスを使用する。
• 永続ディスク内のデータのスナップショットを作成し、マルチリージョン ロケーションに保存します。
• リージョン リソースまたはゾーンリソースを使用する場合は、他のリージョンへのデータ レプリケーションを設定します。
• DR 計画を定期的にテストして、計画が有効であることを確認します。
• RTO と RPO、およびそれらと、お住まいの地域の金融規制で定められている影響許容度との相関関係を把握してください。

詳細については、クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。

マネージド サービスを活用する

可能な場合は、マネージド サービスを使用して、バックアップ、HA、スケーラビリティの組み込み機能を利用します。マネージド サービスを使用する際の推奨事項は次のとおりです。

• Google Cloudでマネージド サービスを使用する。SLA に基づく HA を提供します。また、組み込みのバックアップ メカニズムと復元力機能も備えています。
• データ マネジメントには、Cloud SQL、Cloud Storage、Spanner などのサービスを検討してください。
• コンピューティングとアプリケーションのホスティングには、Compute Engine マネージド インスタンス グループ（MIG）と Google Kubernetes Engine（GKE）クラスタを検討してください。リージョン MIG と GKE リージョン クラスタは、ゾーンの停止に対する復元力を備えています。
• リージョンの停止に対する復元力を高めるには、マネージド マルチリージョン サービスを使用します。
• 独自の特性を持つサービスの撤退計画の必要性を特定し、必要な計画を定義します。FCA、PRA、EBA などの金融規制当局は、クラウド プロバイダとの関係が終了した場合に、データ取得と運用の継続性のための戦略と緊急時対応計画を策定することを企業に求めています。企業は、クラウド契約を締結する前に、移行の実現可能性を評価する必要があります。また、業務を中断することなくプロバイダを変更できる能力を維持する必要があります。
• 選択したサービスが、CSV、Parquet、Avro などのオープン形式へのデータのエクスポートをサポートしていることを確認します。サービスがオープン テクノロジーに基づいているかどうかを確認します。たとえば、GKE が Open Container Initiative（OCI）形式をサポートしているか、Managed Service for Apache Airflow をサポートしているかを確認します。

インフラストラクチャのプロビジョニングと復旧のプロセスを自動化する

自動化は、人的ミスを最小限に抑え、インシデントへの対応に必要な時間とリソースを削減するのに役立ちます。自動化を使用すると、障害からの復旧を迅速化し、より一貫した結果を得ることができます。リソースのプロビジョニングと復元を自動化するには、次の推奨事項を検討してください。

• Terraform などの Infrastructure as Code（IaC）ツールを使用して、人的ミスを最小限に抑える。
• フェイルオーバー プロセスを自動化することで、手動による介入を減らします。自動レスポンスを使用すると、障害の影響を軽減することもできます。たとえば、Eventarc または Workflows を使用して、監査ログで確認された問題に対応する是正措置を自動的にトリガーできます。
• 自動スケーリングを使用して、フェイルオーバー中にクラウド リソースの容量を増やします。
• プラットフォーム エンジニアリングを採用することで、サービス デプロイ中にクラウド トポロジ全体で規制要件のポリシーとガードレールを自動的に適用します。

金融サービスの視点: 費用の最適化

Google Cloud Well-Architected Framework: 金融サービス（FS）の視点のこのドキュメントでは、 Google Cloudで FS ワークロードの費用を最適化するための原則と推奨事項の概要について説明します。このドキュメントの推奨事項は、Well-Architected Framework の費用最適化の柱に沿っています。

金融サービス ワークロードの費用を最適化するには、次の基本的な要素が必要です。

• 無駄なリソース使用と価値を生み出すリソース使用を特定する能力。
• 財務上の説明責任を果たす文化が定着している。

費用を最適化するには、組織全体の費用要因とリソースのニーズを包括的に把握する必要があります。一部の大規模な組織（特にクラウド導入の初期段階にある組織）では、多くの場合、1 つのチームが多数のドメインにわたる費用の最適化を担当します。このアプローチは、効率性向上に寄与する価値の高い機会を特定するのに最適なのは中心チームであることを前提としています。

一元化されたアプローチは、クラウド導入の初期段階や、重要でないワークロードでは、ある程度の成功を収める可能性があります。ただし、1 つのチームが組織全体で費用の最適化を推進することはできません。リソースの使用量や規制の監視レベルが増加すると、一元化されたアプローチは持続可能ではなくなります。一元化されたチームは、特に多数の金融商品やサービスを扱う場合に、スケーラビリティの課題に直面します。プロダクトとサービスを所有するプロジェクト チームは、外部チームによる変更に抵抗する可能性があります。

費用を効果的に最適化するには、費用関連のデータを可視化し、ワークロードに近いエンジニアやその他のクラウド ユーザーが費用を最適化するための行動を起こすように促す必要があります。組織の観点から見ると、費用最適化の課題は、最適化が必要な領域を特定し、それらの領域を担当するエンジニアを特定して、必要な最適化アクションを実行するよう説得することです。このドキュメントでは、この課題に対処するための推奨事項について説明します。

このドキュメントの費用最適化の推奨事項は、次の基本原則にマッピングされています。

• Google Cloud ツールを使用して無駄を特定する
• 支出データを分析して拡充することで価値を特定する
• 費用を割り当てて説明責任を果たす
• 説明責任を推進し、エンジニアに実践を促す
• 費用ではなく、価値と TCO に焦点を当てる

Google Cloud ツールを使用して無駄を特定する

Google Cloud には、無駄を特定するのに役立つプロダクト、ツール、機能がいくつか用意されています。以下の推奨事項を参考にしてください。

自動化と AI を使用して、最適化すべき対象を体系的に特定する

Active Assist は、マイクロサービス用の Cloud Run、データ分析用の BigQuery、コア アプリケーション用の Compute Engine、リレーショナル データベース用の Cloud SQL などのサービス全体でインテリジェントな推奨事項を提供します。Active Assist の推奨事項は、構成なしで無料で提供されます。推奨事項は、アイドル状態のリソースと使用率の低いコミットメントを特定するのに役立ちます。

統合されたインターフェースで FinOps のモニタリングと制御を一元化

Cloud Billing レポートと FinOps ハブを使用すると、包括的な費用モニタリングを実装できます。この包括的なビューは、財務監査人と社内のファイナンス チームがクラウド支出を追跡し、財務状況を評価し、さまざまなビジネス ユニットやコストセンターにわたる FinOps の成熟度を評価し、一貫した財務ナラティブを提供するために不可欠です。

費用データを分析して拡充することで価値を特定する

Active Assist は、明らかな無駄を特定するのに効果的です。ただし、価値を特定することは、特にワークロードが不適切なプロダクトにある場合や、ワークロードがビジネス価値と明確に一致していない場合に、より困難になる可能性があります。金融サービス ワークロードの場合、ビジネス価値はコスト削減にとどまりません。この価値には、リスク軽減、規制遵守、競争上の優位性の獲得が含まれます。

クラウドの費用と価値を総合的に把握するには、複数のレベルで完全に理解する必要があります。つまり、費用がどこから発生しているか、費用がどのビジネス機能を推進しているか、問題のワークロードをリファクタリングまたは最適化する技術的な実現可能性を把握する必要があります。

次の図は、データ、情報、知識、知恵（DIKW）ピラミッドと Google Cloud ツールを適用して、クラウドの費用と価値を包括的に把握する方法を示しています。

上の図は、DIKW アプローチを使用して、未加工のクラウド支出データを、ビジネス価値を促進する実用的な分析情報と意思決定に変換する方法を示しています。

• データ: このレイヤでは、クラウド リソースの使用状況と費用データの未加工の未処理ストリームを収集します。FinOps の一元管理チームは、Cloud Billing の請求書、請求データのエクスポート、Cloud Monitoring などのツールを使用して、詳細なデータを取得します。たとえば、app1-test-vmA という名前の VM が us-central1 リージョンで 730 時間実行され、70 米ドルの費用が発生したというデータポイントがあります。
• 情報: このレイヤでは、中央の FinOps チームが Cloud Billing 請求レポートや FinOps ハブなどのツールを使用して、元データを構造化し、「どのようなカテゴリのリソースに費用が費やされているか」などの質問に答えることができます。たとえば、米国の 2 つのリージョンでマシンタイプ n4-standard-2 の VM に合計 1,050 米ドルが費やされたことがわかります。
• ナレッジ: このレイヤでは、中央の FinOps チームが、誰がどのような目的でお金を使ったかに関する適切なビジネス コンテキストで情報を拡充します。タグ付け、ラベル付け、リソース階層、請求先アカウント、カスタム Looker ダッシュボードなどのメカニズムを使用します。たとえば、米国の app1 テストチームが、ストレステストの一環として 7 月の第 2 週に 650 米ドルを費やしたと判断できます。
• 知恵: このレイヤでは、プロダクト チームとアプリケーション チームが、コンテキスト化された知識を使用して、クラウド支出のビジネス価値を評価し、情報に基づいた戦略的な意思決定を行います。チームは、次のような質問に答えることができます。
  • データ分析パイプラインに費やした 5,000 米ドルは、ビジネス価値を生み出しているでしょうか。
  • パフォーマンスを低下させることなく、パイプラインをより効率的に再設計できるか？

クラウドの費用データを分析する際は、次の推奨事項を検討してください。

Google Cloudから提供された費用データを分析する

まず、BigQuery にエクスポートされた詳細な Cloud Billing データと、Monitoring ログで利用可能なデータから始めます。実用的な分析情報を引き出して意思決定を行うには、このデータを構造化し、ビジネス コンテキストで拡充する必要があります。

利用可能なツールを使用してデータを可視化する

BigQuery Export に加えて、データポータルなどのツールを使用して、カスタム レポートで組み込みの Google Cloud ダッシュボードを拡張します。ファイナンス チームは、財務指標、法令上の報告要件、ビジネス ユニットの収益性に対してクラウド支出をコンテキスト化するカスタム ダッシュボードを構築できます。これにより、経営幹部のステークホルダーによる分析と意思決定に、明確な財務上の説明を提供できます。

費用を割り当てて説明責任を推進する

クラウド支出の要因を把握したら、誰が、なぜ支出しているのかを特定する必要があります。このレベルの理解には、ビジネスに関連するメタデータをクラウド リソースに付加する、堅牢な費用配分の実践が必要です。たとえば、特定のチームが Banking-AppDev チームで使用されている場合、team=banking_appdev などのタグをリソースに適用して、そのチームがそのリソースで発生する費用を追跡できます。理想的には、クラウド費用の 100% を支出元に割り当てる必要があります。実際には、100% の費用配分をサポートするメタデータ構造を構築することは複雑な作業であるため、最初は低い目標から始めることをおすすめします。

費用配分をサポートするメタデータ戦略を策定するには、次の推奨事項を考慮してください。

• 有効性: タグがビジネス関連の重要業績評価指標（KPI）と規制要件の特定に役立つことを確認します。この関連付けは、内部チャージバック、法令上の報告、クラウド支出とビジネス ユニットの目標の整合に不可欠です。たとえば、次のタグは、支出チーム、そのリージョン、作業対象のプロダクトを明確に識別します。team=banking_appdev、region=emea、product=frontend。
• 自動化: 高いレベルのタグ付けコンプライアンスを達成するには、自動化によってタグ付けを適用します。手動タグ付けはエラーや不整合が発生しやすく、監査可能性と財務の正確性が最優先される FS 環境では許容されません。自動タグ付けにより、リソースの作成時にリソースが正しく分類されます。
• シンプルさ: シンプルで相関関係のない要素を測定します。FS 環境は複雑です。このような環境で費用配分ルールを簡単に理解して適用できるようにするには、ルールをできるだけシンプルにする必要があります。非常に特殊な（エッジ）ケースのルールを過剰に設計しないでください。複雑なルールは、運用チームの混乱や抵抗を招く可能性があります。

タグを使用して割り当て戦略を定義したら、戦略を実装する粒度を決定する必要があります。必要な粒度は、ビジネスニーズによって異なります。たとえば、組織によっては、プロダクト レベルで費用を追跡する必要がある場合や、各コストセンターの費用データが必要な場合、環境（開発、ステージング、本番環境）ごとに費用データが必要な場合があります。

組織に適したレベルの費用配分の粒度を実現するには、次のアプローチを検討してください。

• Google Cloud のプロジェクト階層を、費用配分の自然な出発点として使用します。プロジェクトは、 Google Cloudでのポリシー適用ポイントを表します。デフォルトでは、Identity and Access Management（IAM）の権限、セキュリティ ポリシー、費用はプロジェクトとフォルダに関連付けられます。Cloud Billing からエクスポートされた費用データを確認すると、費用データに関連付けられているフォルダ階層とプロジェクトを表示できます。Google Cloud リソース階層に、費用に対する組織の説明責任構造が反映されている場合、これがコスト配分を実装する最も簡単な方法です。
• さらに細かく分類するには、タグとラベルを使用します。ラベルを使用すると、請求エクスポートでリソースを柔軟に分類できます。タグとラベルを使用すると、アプリケーションや環境ごとに費用の詳細な内訳を把握できます。

多くの場合、効果的な費用配分を行うには、プロジェクト階層をタグ付けやラベル付けと組み合わせて使用する必要があります。選択した費用配分アプローチに関係なく、堅牢なメタデータ戦略を策定するために、前述の推奨事項（有効性、自動化、シンプルさ）に従ってください。

アカウンタビリティを推進し、エンジニアに実践を促す

クラウド FinOps チームは、組織が費用と価値を意識するように推進する責任を負います。個々のプロダクト チームとエンジニアリング チームは、費用最適化に必要なアクションを実行する必要があります。また、これらのチームは、金融サービス ワークロードの費用動作と、ワークロードが必要なビジネス価値を提供することについても責任を負います。

説明責任を推進し、チームが費用を最適化するよう促すために、次の推奨事項を検討してください。

ガバナンスのための一元化された FinOps チームを設立する

Cloud FinOps のプラクティスは、自然に成長するものではありません。専任の FinOps チームは、次のことを行って FinOps のプラクティスを定義して確立する必要があります。

• 必要なプロセス、ツール、ガイダンスを構築する。
• 必須のタグ付け、予算の確認、最適化プロセスなど、必要なポリシーを作成、伝達、適用します。
• エンジニアリング チームが費用に責任を持つように促す。
• エンジニアリング チームが費用のオーナーシップを担わない場合は介入する。

経営幹部による支援と権限の委任を得る

CTO、CFO、CIO などの上級管理職は、FinOps 文化への組織全体の移行を積極的に推進する必要があります。経営幹部のサポートは、費用の説明責任の優先順位付け、FinOps プログラムへのリソースの割り当て、部門横断的な参加の確保、FinOps 要件の遵守の推進に不可欠です。

費用の最適化についてチームにインセンティブを与える

エンジニアやエンジニアリング チームは、費用の最適化に自発的に取り組まない可能性があります。次のようなインセンティブを実装して、チームと個人の目標を費用対効果に合わせることが重要です。

• 費用最適化によって節約された費用の一部を、最適化を達成したチームに再投資します。
• 費用最適化の取り組みと成功を公に認め、称えます。
• ゲーミフィケーション手法を使用して、費用を効果的に最適化したチームに報酬を与える。
• 効率性指標をパフォーマンス目標に組み込む。

ショーバックとチャージバックの手法を実装する

チームが所有するクラウド リソースと費用を明確に把握できるようにします。チーム内の適切な個人に財務責任を割り当てます。正式なメカニズムを使用して厳格なタグ付けを適用し、共有費用の割り当てに関する透明性の高いルールを実装します。

費用ではなく価値と TCO に焦点を当てる

クラウド ソリューションを評価する際は、長期的な総所有コスト（TCO）を考慮してください。たとえば、アプリケーションのデータベースをセルフホストすることは、Cloud SQL などのマネージド データベース サービスを使用するよりも安価に見えるかもしれません。ただし、長期的な価値と TCO を評価するには、セルフホスト型データベースに関連する隠れた費用を考慮する必要があります。このような費用には、パッチ適用、スケーリング、セキュリティ強化、障害復旧のための専用のエンジニアリング作業が含まれます。これらは、FS ワークロードの重要な要件です。マネージド サービスは、インフラストラクチャの費用を相殺する、はるかに高い長期的な価値を提供します。マネージド サービスは、堅牢なコンプライアンス機能を提供し、信頼性機能を組み込んでおり、運用上のオーバーヘッドを削減するのに役立ちます。

価値と TCO に焦点を当てるために、次の推奨事項を考慮してください。

プロダクト固有の手法とツールを使用してリソースを最適化する

次のような Google Cloudプロダクトが提供する費用最適化ツールと機能を利用します。

• Compute Engine: 自動スケーリング、カスタム マシンタイプ、Spot VM
• Google Kubernetes Engine: クラスタ オートスケーラーとノード自動プロビジョニング
• Cloud Storage: オブジェクトのライフサイクル管理と Autoclass
• BigQuery: 容量ベースの料金と費用最適化の手法
• Google Cloud VMware Engine: 確約利用割引（CUD）、最適化されたストレージ、その他の費用最適化戦略

割引を受ける

Google が提供する割引を利用して、クラウド リソースの課金レートをできるだけ低くします。通常、個々のプロダクト チームとエンジニアリング チームがリソースの最適化を管理します。中央の FinOps チームは、組織全体のリソース要件を把握しているため、請求レートの最適化を担当します。そのため、要件を集約して、コミットメント ベースの割引を最大化できます。

Google Cloud リソースでは、次の種類の割引を利用できます。

• エンタープライズ割引は、組織が Google Cloud の最小合計費用を割引料金で支払うことを確約することに基づいて交渉された割引です。
• リソースベースの CUD は、1 年間または 3 年間にわたって Compute Engine リソースを最小数量使用することを確約することと引き換えに適用されます。リソースベースの CUD は、特定のリージョンにあるリソースに適用されます。ほとんどの Cloud 請求先アカウントでは、 Google Cloud によってリソースベースの CUD の共有が有効になり、そのアカウントに関連付けられているすべてのプロジェクトで CUD が共有されます。
• 費用ベースの CUD は、1 年間または 3 年間にわたって特定のプロダクトに最低限の金額を支払うことのコミットメントと引き換えに適用されます。費用ベースの割引は、請求先アカウント レベルで適用されます。割引は、プロダクトに応じてリージョンまたはグローバルに適用されます。

エンタープライズ割引に加えて CUD を使用すると、大幅な費用削減を実現できます。

CUD に加えて、次の方法を使用して請求レートを削減します。

• フォールト トレラントで柔軟なワークロードには Spot VM を使用します。Spot VM は、通常の VM よりも 80% 以上安価です。
• BigQuery には、オンデマンド料金や、コミットメントと自動スケーリングの要件に基づくエディション ベースの料金など、複数の料金モデルが用意されています。BigQuery リソースを大量に使用する場合は、適切なエディションを選択して、分析ワークロードのスロットあたりの費用を削減します。
• 使用する必要があるサービスで利用可能な Google Cloud リージョンを慎重に評価します。費用目標、レイテンシやコンプライアンス要件などの要因に沿ったリージョンを選択します。費用、サステナビリティ、レイテンシのトレードオフを理解するには、Google Cloud リージョン選択ツールを使用します。

金融サービスの視点: パフォーマンス最適化

Google Cloud Well-Architected Framework: 金融サービス（FS）の視点のこのドキュメントでは、 Google Cloudで FS ワークロードのパフォーマンスを最適化するための原則と推奨事項の概要について説明します。このドキュメントの推奨事項は、Well-Architected Framework のパフォーマンス最適化の柱に沿っています。

金融サービスにおけるパフォーマンスの最適化には長い歴史があります。FS 組織が技術的な課題を克服するのに役立ち、ほぼ常に新しいビジネスモデルの作成を可能にするか、加速させてきました。たとえば、ATM（1967 年に導入）は現金払い出しプロセスを自動化し、銀行がコアビジネスの費用を削減するのに役立ちました。OS カーネルをバイパスしてアプリケーション スレッドをコンピューティング コアに固定するなどの手法により、取引アプリケーションの確定的で低レイテンシな処理を実現しました。レイテンシの短縮により、金融市場でのスプレッドが縮小し、流動性が高まり、安定しました。

クラウドは、パフォーマンスを最適化する新たな機会を生み出します。また、これまで受け入れられてきた最適化パターンの一部にも疑問を投げかけています。具体的には、次のトレードオフはクラウドでより透明性が高く、制御可能です。

• 製品化までの時間と費用のトレードオフ。
• システムレベルのエンドツーエンドのパフォーマンスとノードレベルのパフォーマンス。
• 人材の確保と、テクノロジー関連の意思決定の俊敏性。

たとえば、ハードウェアと IT リソースを特定のスキル要件に適応させることは、クラウドでは簡単なタスクです。GPU プログラミングをサポートするために、GPU ベースの VM を作成できます。クラウドの容量をスケーリングして、リソースを過剰にプロビジョニングすることなく、需要の急増に対応できます。この機能により、非農業部門の給与日や取引量が過去のレベルを大幅に上回る場合など、ワークロードがピーク負荷を処理できるようになります。個々のサーバーのレベルで高度に最適化されたコード（C 言語で高度に微調整されたコードなど）を記述したり、従来のハイ パフォーマンス コンピューティング（HPC）環境用のコードを記述したりする代わりに、適切に設計された Kubernetes ベースの分散システムを使用することで、最適なスケールアウトを実現できます。

このドキュメントのパフォーマンス最適化の推奨事項は、次の基本原則にマッピングされています。

• テクノロジーのパフォーマンス指標を主要なビジネス指標と整合させる
• 未実証のリスクのためにパフォーマンスを犠牲にすることなく、セキュリティを優先する
• アーキテクチャを再考して、新しい機会と要件に適応する
• 現在と将来のビジネスニーズに対応する、将来を見据えたテクノロジー

テクノロジーのパフォーマンス指標を主要なビジネス指標と整合させる

パフォーマンスの最適化をビジネス価値の成果にマッピングする方法はいくつかあります。たとえば、バイサイドのリサーチデスクでは、リサーチ時間あたりの出力を最適化することや、シャープレシオが高いなど、実績のあるチームのテストを優先することがビジネスの目標になる場合があります。売り手側では、分析を使用してクライアントの関心を追跡し、それに応じて、最も関心の高い調査をサポートする AI モデルのスループットを優先できます。

パフォーマンスの目標をビジネスの重要業績評価指標（KPI）に関連付けることも、パフォーマンス改善の資金を調達するうえで重要です。ビジネス イノベーションと変革のイニシアチブ（change-the-bank の取り組みと呼ばれることもあります）には、異なる予算があり、通常業務（BAU）や run-the-bank のオペレーションと比較すると、リソースへのアクセスレベルが異なる可能性があります。たとえば、 Google Cloud は、G-SIFI のリスク管理チームとテクノロジー チームがフロントオフィスの定量アナリストと協力して、リスク分析計算（XVA など）を数時間または数日ではなく数分で実行するソリューションを開発できるよう支援しました。このソリューションにより、組織は関連するコンプライアンス要件を満たすことができました。また、トレーダーはクライアントとの会話の質を高めることができ、スプレッドの縮小、流動性の強化、費用対効果の高いヘッジを提供できる可能性があります。

パフォーマンス指標をビジネス指標に合わせる場合は、次の推奨事項を考慮してください。

• 各テクノロジー イニシアチブを、収益や利益の増加、コストの削減、リスクの軽減など、関連するビジネスの目標と主要な成果（OKR）に、より効率的または包括的に関連付けます。
• システムレベルでのパフォーマンスの最適化に重点を置きます。従来の「銀行の変革」と「銀行の運営」の分離、フロント オフィスとバック オフィスのサイロ化を超えて、

未実証のリスクのためにパフォーマンスを犠牲にすることなく、セキュリティを優先

金融サービス組織のセキュリティと規制遵守は、間違いなく高い水準でなければなりません。クライアントを失うことを回避し、組織のブランドに修復不可能な損害を与えないようにするには、高い基準を維持することが不可欠です。多くの場合、生成 AI などの技術革新や、Spanner などの独自のマネージド サービスによって、最大の価値がもたらされます。運用リスクが大きすぎる、または規制コンプライアンス体制が不十分であるという誤解から、このようなテクノロジー オプションを自動的に破棄しないでください。

Google Cloud は、G-SIFI と緊密に連携して、マネー ロンダリング対策（AML）に AI ベースのアプローチを、機関が顧客にサービスを提供する管轄区域全体で使用できるようにしています。たとえば、HSBC は、金融犯罪（Fincrime）部門のパフォーマンスを大幅に向上させ、次のような結果を得ました。

• 確認された不審なアクティビティが約 2 ～ 4 倍増加。
• 誤検出を 60% 以上削減し、リスクの高い、対応が必要なアラートのみに調査時間を集中させることで、運用コストを削減します。
• 監査可能で説明可能な出力により、規制遵守をサポートします。

以下の推奨事項を参考にしてください。

• 使用するプロダクトが、事業を展開する管轄区域のセキュリティ、復元性、コンプライアンスの要件を満たしていることを確認します。この目標を達成するには、 Google Cloudのアカウント チーム、リスクチーム、プロダクト チームと連携します。
• AI の説明可能性を活用して、より強力なモデルを作成し、お客様に透明性を提供します。

• ソースの引用、グラウンディング、RAG などの手法を使用して、生成 AI ワークロードの透明性を実現します。

• 説明可能性が不十分な場合は、バリューストリームの意思決定ステップを分離し、AI を使用して意思決定以外のステップのみを自動化します。場合によっては、説明可能な AI では不十分なことや、規制上の懸念（GDPR 第 22 条など）により、プロセスに人間の介入が必要になることがあります。このような場合は、人間のエージェントが意思決定に必要なすべての情報を 1 つのコントロール ペインに表示しますが、データの収集、取り込み、操作、要約のタスクを自動化します。

アーキテクチャを再考して、新しい機会と要件に適応する

クラウドベースの機能で現在のアーキテクチャを拡張すると、大きな価値が得られます。より革新的な成果を達成するには、クラウド ファーストのアプローチを使用して、アーキテクチャを定期的に見直す必要があります。

ワークロードのアーキテクチャを定期的に見直してパフォーマンスをさらに最適化するには、次の推奨事項を検討してください。

オンプレミスの HPC システムとスケジューラの代わりにクラウドベースの代替手段を使用する

高い弾力性、セキュリティ ポスチャーの向上、広範なモニタリングとガバナンス機能を活用するには、クラウドで HPC ワークロードを実行するか、オンプレミス ワークロードをクラウドにバーストします。ただし、投資戦略のシミュレーションや XVA モデリングなど、特定の数値モデリングのユースケースでは、Kubernetes と Kueue を組み合わせることで、より強力なソリューションを実現できる可能性があります。

シミュレーション用にグラフベースのプログラミングに切り替える

モンテカルロ シミュレーションは、Dataflow などのグラフベースの実行システムでより高いパフォーマンスを発揮する可能性があります。たとえば、HSBC は Dataflow を使用して、以前のアプローチと比較して 16 倍高速にリスク計算を実行しています。

クラウドベースの取引所と取引プラットフォームを運営する

Google Cloud のお客様との会話から、市場と取引アプリケーションのパフォーマンス要件に 80/20 のパレートの法則が適用されることがわかります。

• 取引アプリケーションの 80% 以上は、極めて低いレイテンシを必要としません。ただし、クラウドの復元性、セキュリティ、エラスティック機能から大きなメリットを得られます。たとえば、外国為替マルチディーラー プラットフォームである BidFX は、クラウドを使用して新しいプロダクトを迅速にリリースし、リソースを増やすことなく可用性とフットプリントを大幅に向上させています。
• 残りのアプリケーション（20% 未満）では、メッセージの配信に低レイテンシ（1 ミリ秒未満）、決定論、公平性が必要です。従来、これらのシステムは、柔軟性に欠ける高価なコロケーション施設で運用されていました。このカテゴリのアプリケーションでも、エッジまたはクラウド ファースト アプリケーションとして、クラウドでプラットフォームが再構築されることが増えています。

現在および将来のビジネスニーズに対応する、将来を見据えたテクノロジー

歴史的に、多くの金融サービス組織は競争上の優位性を得るために専有技術を構築してきました。たとえば、2000 年代初頭、成功を収めた投資銀行や取引会社は、pub-sub システムやメッセージ ブローカーなどの基盤テクノロジーを独自に実装していました。オープンソース テクノロジーとクラウドの進化に伴い、このようなテクノロジーはコモディティ化し、ビジネス価値の向上をもたらさなくなっています。

テクノロジーを将来にわたって有効に活用するために、次の推奨事項を検討してください。

Data as a Service（DaaS）アプローチを採用して、製品化までの時間を短縮し、費用の透明性を高める

金融サービス組織は、多くの場合、有機的成長と合併および買収（M&A）の組み合わせによって進化します。そのため、組織は異種のテクノロジーを統合する必要があります。また、データ ベンダー、データ ライセンス、統合ポイントなどの重複するリソースを管理する必要もあります。 Google Cloud は、合併後の統合で差別化された価値を創出する機会を提供します。

たとえば、BigQuery Sharingなどのサービスを使用して、分析に対応した Data-as-a-Service（DaaS）プラットフォームを構築できます。このプラットフォームは、市場データと代替ソースからの入力の両方を提供できます。このアプローチにより、冗長なデータ パイプラインを構築する必要がなくなり、より価値の高いイニシアチブに集中できます。さらに、合併または買収された企業は、合併後のデータ ライセンスとインフラストラクチャのニーズを迅速かつ効率的に合理化できます。統合されたビジネスは、レガシー データ資産とオペレーションの適応と統合に労力を費やす代わりに、新しいビジネス チャンスに集中できます。

抽象化レイヤを構築して既存のシステムを分離し、新しいビジネスモデルに対応する

銀行の競争上の優位性は、コア バンキング システムではなく、カスタマー エクスペリエンス レイヤにあります。しかし、レガシー バンキング システムでは、Cobol などの言語で開発され、バンキングのバリュー チェーン全体に統合されたモノリシック アプリケーションがよく使用されています。この統合により、バリュー チェーンのレイヤを分離することが困難になり、このようなシステムのアップグレードやモダナイズはほぼ不可能でした。

この課題に対処するソリューションの一つは、API 管理システムなどの分離レイヤ、または Spanner などのステージング レイヤを使用して、記録簿を複製し、高度な分析と AI を使用してサービスのモダナイゼーションを促進することです。たとえば、Deutsche Bank は、Spanner を使用してレガシー コア バンキング資産を分離し、イノベーションへの取り組みを開始しました。