金融サービスにおける視点: 費用の最適化

Last reviewed 2026-10-28 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データ、情報、知識、知恵（DIKW）のピラミッドは、クラウド支出データを使用して意思決定に役立てる方法を示しています。

上の図は、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プロダクトが提供する費用最適化ツールと機能を利用します。

割引を受ける

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 リージョン選択ツールを使用します。
前へ
信頼性
次へ
パフォーマンスの最適化