AI と ML の視点: 信頼性

Last reviewed 2026-10-29 UTC

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

急速に進化する AI と ML の環境では、顧客満足度を確保し、ビジネス目標を達成するために、信頼性の高いシステムが不可欠です。予測 ML と生成 AI の両方の固有の需要を満たすには、堅牢で信頼性が高く、適応性に優れた AI システムと ML システムが必要です。開発からデプロイ、継続的な改善に至るまで、MLOps の複雑さに対処するには、信頼性を最優先するアプローチを採用する必要があります。 Google Cloud は、サイト信頼性エンジニアリング（SRE）の原則に沿った、信頼性の高い AI システムと ML システムのための強力な基盤となる、専用の AI インフラストラクチャを提供します。

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

• インフラストラクチャのスケーラビリティと高可用性を確保する
• モジュール式の疎結合アーキテクチャを使用する
• 自動化されたエンドツーエンドの MLOps プラットフォームを構築する
• データとモデルのガバナンスを通じて信頼と管理を維持する
• 包括的なオブザーバビリティと信頼性のプラクティスを実装する

ML インフラストラクチャのスケーラビリティと高可用性を確保する

クラウドで信頼性の高い AI システムと ML システムを実現するには、スケーラブルで高可用性のインフラストラクチャが必要です。これらのシステムには、動的な需要、多様なリソースニーズ、モデルの可用性に対する重要な依存関係があります。スケーラブルなアーキテクチャは、負荷の変動や、データ量や推論リクエストの変動に適応します。高可用性（HA）は、コンポーネント、ゾーン、リージョン レベルでの障害に対する復元力を確保するのに役立ちます。

スケーラブルで高可用性の ML インフラストラクチャを構築するには、次の推奨事項を検討してください。

自動および動的スケーリング機能を実装する

AI と ML のワークロードは動的であり、データの到着率、トレーニングの頻度、推論トラフィックの量に基づいて需要が変動します。自動かつ動的なスケーリングにより、インフラストラクチャ リソースが需要の変動にシームレスに適応します。ワークロードを効果的にスケーリングすることで、ダウンタイムの防止、パフォーマンスの維持、費用の最適化が可能になります。

AI / ML ワークロードを自動スケーリングするには、 Google Cloudで次のプロダクトと機能を使用します。

• データ処理パイプライン: Dataflow でデータ パイプラインを作成します。Dataflow の水平自動スケーリング機能を使用するようにパイプラインを構成します。この機能は、CPU 使用率、パイプラインの並列処理、保留中のデータに基づいてワーカー インスタンスの数を動的に調整します。ジョブの起動時に、パイプライン オプションを使用して自動スケーリング パラメータを構成できます。
• トレーニング ジョブ: Gemini Enterprise Agent Platform のカスタム トレーニングを使用して、トレーニング ジョブのスケーリングを自動化します。マシンタイプ、アクセラレータのタイプと数、ワーカープールの数など、ワーカープールの仕様を定義できます。中断を許容できるジョブや、トレーニング コードでチェックポイントを実装するジョブの場合は、Spot VM を使用してコストを削減できます。
• オンライン推論: オンライン推論には、Agent Platform エンドポイントを使用します。自動スケーリングを有効にするには、レプリカの最小数と最大数を構成します。HA 用に 2 つ以上のレプリカを指定します。Agent Platform は、トラフィックと構成された自動スケーリング指標（CPU 使用率やレプリカ使用率など）に基づいて、レプリカの数を自動的に調整します。
• Google Kubernetes Engine のコンテナ化されたワークロード: ノードレベルと Pod レベルで自動スケーリングを構成します。クラスタ オートスケーラーとノード自動プロビジョニングを構成して、保留中の Pod リソース リクエスト（CPU、メモリ、GPU、Cloud TPU など）に基づいてノード数を調整します。デプロイに HorizontalPodAutoscaler（HPA）を使用して、CPU 使用率やメモリ使用率などの指標に基づいてスケーリング ポリシーを定義します。また、GPU や Cloud TPU の使用率、1 秒あたりの予測リクエスト数など、カスタムの AI 指標と ML 指標に基づいてスケーリングすることもできます。
• サーバーレス コンテナ化サービス: Cloud Run にサービスをデプロイし、コンテナ インスタンスの最小数と最大数を指定して自動スケーリングを構成します。ベスト プラクティスを使用して、アクセラレータ タイプを指定して GPU 対応インスタンスを自動スケーリングします。Cloud Run は、受信リクエストに基づいて、構成された最小限度と最大限度の間でインスタンスを自動的にスケーリングします。リクエストがない場合は、インスタンス数がゼロに効率的にスケーリングされます。Cloud Run の自動リクエスト ドリブン スケーリングを活用して、エージェントをデプロイし、Ollama を使用した量子化モデルや vLLM を使用した LLM 推論などのサードパーティ ワークロードをデプロイできます。

HA とフォールト トレランスを考慮した設計

本番環境グレードの AI ワークロードと ML ワークロードでは、継続的な運用と障害に対する復元力を確保することが重要です。HA とフォールト トレランスを実装するには、 Google Cloudのアーキテクチャに冗長性とレプリケーションを組み込む必要があります。このアプローチにより、個々のコンポーネントの障害がシステム全体の障害につながらないようにできます。

• モデル提供で HA と低レイテンシを実現するには、特にリアルタイム推論モデルと生成 AI モデルの場合、デプロイを複数のロケーションに分散します。
• グローバルな可用性と復元性を確保するには、 Google Cloud リージョンにまたがる複数の Agent Platform エンドポイントにモデルをデプロイするか、グローバル エンドポイントを使用します。
• グローバル ロード バランシングを使用してトラフィックをルーティングする。
• GKE または Compute Engine MIG でのトレーニングの場合は、Xid エラーのモニタリングを実装します。Xid エラーを特定したら、適切な是正措置を講じます。たとえば、GPU をリセットする、Compute Engine インスタンスをリセットする、Google Cloud CLI の report faulty host コマンドを使用してハードウェアの交換をトリガーする、などです。
• Google Resiliency Library を使用するレシピや、Cloud TPU ワークロード用の Pathways を使用した復元力のあるトレーニング ロジックの統合など、フォールト トレラントまたはエラスティックで復元力のあるトレーニング ソリューションを検討します。

Google Cloudの重要な AI コンポーネントと ML コンポーネントに冗長性を実装します。リソースの冗長性を実装できるプロダクトと機能の例を次に示します。

• 複数のゾーンに GKE リージョン クラスタをデプロイします。
• Cloud Storage のマルチリージョン バケットまたはデュアルリージョン バケットを使用して、データセットとチェックポイントのデータ冗長性を確保します。
• Spanner を使用して、グローバルに整合性のある高可用性のメタデータ ストレージを実現します。
• 運用データベース用に Cloud SQL リードレプリカを構成します。
• 検索拡張生成（RAG）用のベクトル データベースが高可用性で、マルチゾーンまたはマルチリージョンであることを確認します。

リソースを事前に管理し、要件を予測する

効果的なリソース管理は、費用、パフォーマンス、信頼性を最適化するために重要です。AI ワークロードと ML ワークロードは動的であり、GPU や Cloud TPU などの特殊なハードウェアに対する需要が高まっています。そのため、プロアクティブなリソース管理を適用し、リソースの可用性を確保することが重要です。

Cloud Monitoring の GPU や Cloud TPU の使用率やスループット率などの過去のモニタリング データと、Cloud Logging のログに基づいて、容量を計画します。BigQuery またはデータポータルを使用してこのテレメトリー データを分析し、成長または新しいモデルに基づいて GPU の将来の需要を予測します。リソースの使用パターンと傾向を分析することで、重要な専用アクセラレータが必要になるタイミングと場所を予測できます。

• 厳格な負荷テストを通じて、容量の見積もりを検証します。Apache JMeter や LoadView などのツールを使用して、サービングやパイプラインなどの AI サービスと ML サービスのトラフィックをシミュレートします。
• 負荷がかかった状態でのシステムの動作を分析します。
  • 本番環境でワークロードの需要増加を予測して対応するには、リソース要件を事前に特定します。レイテンシ、スループット、エラー、リソース使用率（特に GPU と Cloud TPU の使用率）をモニタリングします。必要に応じてリソース割り当てを増やします。
  • 生成 AI サービングの場合は、高い同時負荷でテストし、アクセラレータの可用性がパフォーマンスを制限するレベルを特定します。
• モデルクエリの継続的なモニタリングを実行し、エージェントのプロアクティブなアラートを設定します。
  • モデルのオブザーバビリティ ダッシュボードを使用して、Monitoring によって収集された指標（モデルの秒間クエリ数（QPS）、トークン スループット、最初のトークンのレイテンシなど）を表示します。

リソースの可用性と取得可能性を最適化する

ワークロードの要件に基づいて適切なコンピューティング リソースを戦略的に選択することで、費用を最適化し、リソースの可用性を確保します。

• 24 時間 365 日の安定した推論や、容量要件が固定または予測可能なトレーニング ワークロードの場合は、VM とアクセラレータに確約利用割引（CUD）を使用します。

• GKE ノードと Compute Engine VM の場合は、Spot VM と Dynamic Workload Scheduler（DWS）の機能を使用します。

  • 評価やテストのワークロードなど、フォールト トレラントなタスクには、Spot VM を使用します。Spot VM はプリエンプトされる可能性がありますが、全体的な費用を削減できます。
  • 需要の高いアクセラレータのプリエンプション リスクを管理するには、DWS を使用して取得可能性を高めます。
    • 最大 7 日間実行するためにハイエンド GPU を必要とする複雑なバッチ トレーニングには、DWS Flex Start モードを使用します。
    • 最大 3 か月間実行される長時間実行ワークロードの場合は、カレンダー モードを使用して特定の GPU（H100 と H200）と Cloud TPU（Trillium）を予約します。

• GKE で AI 推論を最適化するには、Cloud TPU と GPU を動的に使用して、変動する容量とパフォーマンスのニーズに対応する vLLM エンジンを実行します。詳細については、vLLM GPU/TPU の代替可能性をご覧ください。

• アクセラレータを含む複雑なリソースとトポロジのニーズがある高度なシナリオでは、ツールを使用してリソース管理を抽象化します。

  • Cluster Director を使用すると、マルチ GPU トレーニング（A3 Ultra H200 と A4 B200）のコロケーションとスケジューリングを使用して、アクセラレータ グループをデプロイして管理できます。Cluster Director は、GKE クラスタと Slurm クラスタをサポートしています。
  • Gemini Enterprise Agent Platform の Ray は、分散コンピューティング インフラストラクチャを抽象化します。これにより、アプリケーションは VM やコンテナを直接管理することなく、トレーニングとサービング用のリソースをリクエストできます。

受信トラフィックを複数のインスタンスに分散する

需要が変動する AI アプリケーションでは、効果的なロード バランシングが不可欠です。ロード バランシングは、トラフィックを分散し、リソースの使用率を最適化し、HA と低レイテンシを実現して、シームレスなユーザー エクスペリエンスを確保します。

• リソース要件が異なる推論: モデル指標に基づいてロード バランシングを実装します。GKE Inference Gateway を使用すると、モデル対応ルーティングを備えたロードバランサの背後にモデルをデプロイできます。ゲートウェイは、生成 AI や LLM 推論などのコンピューティング負荷の高いタスクに、GPU と Cloud TPU アクセラレータを備えたインスタンスを優先します。モデルのステータスを評価するために、詳細なヘルスチェックを構成します。LLM 指標に vLLM や Triton などのサービング フレームワークを使用し、Google Cloud Managed Service for Prometheus を使用して指標を Monitoring に統合します。
• GPU または Cloud TPU を必要とする推論ワークロード: 重要な AI / ML 推論ワークロードが、ワークロードの要件に適したマシンで一貫して実行されるようにするには、特に GPU と Cloud TPU の可用性が制限されている場合に、GKE カスタム コンピューティング クラスを使用します。自動スケーリングのフォールバック ポリシーを使用して、特定のコンピューティング プロファイルを定義できます。たとえば、予約済みの GPU インスタンスまたは Cloud TPU インスタンスに高い優先度を指定するプロファイルを定義できます。プロファイルには、予約済みリソースが一時的に使用できない場合に、費用対効果の高い Spot VM を使用するフォールバックを含めることができます。
• さまざまなオーケストレーション プラットフォームでの生成 AI: 一元化されたロードバランサを使用します。たとえば、費用と管理の効率化のために、GPU のニーズが低いリクエストを Cloud Run にルーティングし、より複雑で GPU を集中的に使用するタスクを GKE にルーティングできます。サービス間の通信とポリシー管理には、Cloud Service Mesh を使用してサービス メッシュを実装します。Logging と Monitoring を使用して、一貫性のあるロギングとモニタリングを実現します。
• グローバルな負荷分散: 低レイテンシを必要とするグローバル ユーザーからのトラフィックをロードバランスするには、グローバル外部アプリケーション ロードバランサを使用します。最も近いリージョンへの位置情報ルーティングを構成し、フェイルオーバーを実装する。Agent Platform または GKE でリージョン エンドポイント レプリケーションを確立します。静的アセット用に Cloud CDN を構成します。Monitoring を使用して、グローバル トラフィックとレイテンシをモニタリングする。
• きめ細かいトラフィック管理: さまざまなデータ型や複雑さを持つリクエストや、長時間実行されるリクエストには、きめ細かいトラフィック管理を実装します。
  • コンテンツ ベースのルーティングを構成して、URL パスやヘッダーなどの属性に基づいて、リクエストを専用のバックエンドに転送します。たとえば、画像モデルまたは動画モデルの場合は GPU 対応バックエンドに、テキストベースのモデルの場合は CPU 最適化バックエンドにリクエストを転送します。
  • 長時間実行される生成 AI リクエストまたはバッチ ワークロードの場合は、WebSocket または gRPC を使用します。タイムアウトとバッファリングを処理するトラフィック管理を実装します。リクエストのタイムアウトと再試行を構成し、API Gateway または Apigee を使用してレート制限と割り当てを実装します。

モジュール式の疎結合アーキテクチャを使用する

モジュール式の疎結合 AI / ML アーキテクチャでは、複雑なシステムが、明確に定義されたインターフェースを介して相互作用する、より小さな自己完結型のコンポーネントに分割されます。このアーキテクチャにより、モジュールの依存関係が最小限に抑えられ、開発とテストが簡素化され、再現性が向上し、障害を封じ込めることでフォールト トレランスが向上します。モジュラー アプローチは、複雑さの管理、イノベーションの加速、長期的な保守性の確保に不可欠です。

AI / ML ワークロード用にモジュラーで疎結合のアーキテクチャを設計するには、次の推奨事項を検討してください。

小規模な自己完結型のモジュールまたはコンポーネントを実装する

エンドツーエンドの AI / ML システムを、自己完結型の小さなモジュールまたはコンポーネントに分割します。各モジュールまたはコンポーネントは、データの取り込み、特徴変換、モデルのトレーニング、推論の提供、評価などの特定の機能を担当します。モジュラー設計には、AI システムと ML システムにとって、保守性の向上、スケーラビリティの向上、再利用性、柔軟性とアジリティの向上など、いくつかの重要なメリットがあります。

以降のセクションでは、AI システムと ML システムのモジュラー アーキテクチャの設計に使用できる Google Cloud プロダクト、機能、ツールについて説明します。

GKE 上のコンテナ化されたマイクロサービス

きめ細かいオーケストレーションが必要な複雑な AI / ML システムや複雑な生成 AI パイプラインの場合は、GKE を使用してオーケストレートされるマイクロサービスとしてモジュールを実装します。各ステージを個別のマイクロサービスとして Docker コンテナ内にパッケージ化します。これらの異なるステージには、さまざまな形式に合わせたデータの取り込み、特殊なデータの前処理または特徴量エンジニアリング、分散モデル トレーニングまたは大規模な基盤モデルのファインチューニング、評価、サービングが含まれます。

コンテナ化されたマイクロサービスを GKE にデプロイし、CPU とメモリ使用率、または GPU 使用率、ローリング アップデート、YAML マニフェストの再現可能な構成などのカスタム指標に基づいて自動スケーリングを活用します。GKE サービス ディスカバリを使用して、マイクロサービス間の効率的な通信を確保します。非同期パターンの場合は、Pub/Sub などのメッセージ キューを使用します。

GKE でのマイクロサービスのアプローチは、ステージを個別のサービスとして設計できる複雑な RAG アプリケーションなどのタスク向けに、スケーラブルで復元力のあるプラットフォームを構築するのに役立ちます。

サーバーレス イベント ドリブン サービス

サーバーレスの自動スケーリングを活用できるイベント ドリブン タスクの場合は、Cloud Run または Cloud Run functions を使用します。これらのサービスは、前処理などの非同期タスクや、小規模な推論ジョブに最適です。Cloud Storage で作成された新しいデータファイルや Artifact Registry でのモデルの更新などのイベントで Cloud Run functions をトリガーします。コンテナ環境を必要とするウェブフック タスクまたはサービスには、Cloud Run を使用します。

Cloud Run サービスと Cloud Run functions は、急速にスケールアップし、ゼロにスケールダウンできるため、変動するワークロードの費用対効果を確保できます。これらのサービスは、Agent Conversation ワークフローのモジュラー コンポーネントに適しています。Workflows または Application Integration を使用して、コンポーネント シーケンスをオーケストレートできます。

Agent Platform マネージド サービス

Agent Platform サービスはモジュール性をサポートし、AI システムと ML システムの開発とデプロイを簡素化します。これらのサービスはインフラストラクチャの複雑さを抽象化するため、デベロッパーはアプリケーション ロジックに集中できます。

• モジュラー ステップから構築されたワークフローをオーケストレートするには、Gemini Enterprise Agent Platform Pipelines を使用します。
• カスタム AI / ML コードを実行するには、Agent Platform カスタム トレーニングや Agent Platform 予測などのマネージド サービスで実行できる Docker コンテナにコードをパッケージ化します。
• モジュラー特徴量エンジニアリング パイプラインには、Agent Platform Feature Store を使用します。
• モジュラー型の探索とプロトタイピングには、Gemini Enterprise Agent Platform Workbench や Colab Enterprise などのノートブック環境を使用します。コードを再利用可能な関数、クラス、スクリプトに整理します。

エージェント アプリケーション

AI エージェントの場合、Agent Development Kit（ADK）は、ツールや状態などのモジュラー機能を提供します。LangChain、LangGraph、LlamaIndex、Agent Platform などのフレームワーク間の相互運用性を実現するには、ADK を Agent2Agent（A2A）プロトコルと Model Context Protocol（MCP）と組み合わせます。この相互運用性により、さまざまなコンポーネントを使用して Agentic Workflows を構成できます。

エージェントは、Gemini Enterprise Agent Platform の Agent Runtime にデプロイできます。これは、スケーラブルなエージェント デプロイ用に最適化されたマネージド ランタイムです。コンテナ化されたエージェントを実行するには、Cloud Run の自動スケーリング機能を利用できます。

明確に定義されたインターフェースを設計する

堅牢でメンテナンスしやすいソフトウェア システムを構築するには、システムのコンポーネントを疎結合にしてモジュール化することが重要です。このアプローチには、システムの異なる部分間の依存関係を最小限に抑えるという大きなメリットがあります。モジュールが疎結合されている場合、1 つのモジュールの変更が他のモジュールに及ぼす影響は最小限に抑えられます。この分離により、個々のモジュールの独立した更新と開発ワークフローが可能になります。

以降のセクションでは、AI システムと ML システムのモジュール間でシームレスな通信と統合を実現するためのガイダンスを提供します。

プロトコルの選択

• ユニバーサル アクセスを実現するには、HTTP API を使用し、RESTful の原則に準拠して、言語に依存しないデータ交換に JSON を使用します。リソースに対するアクションを表すように API エンドポイントを設計します。
• マイクロサービス間の高パフォーマンスの内部通信には、gRPC とプロトコル バッファ（Protobuf）を使用して、効率的なシリアル化と厳密な型指定を実現します。.proto ファイルを使用して、ModelInput、PredictionResult、ADK ツールデータなどのデータ構造を定義し、言語バインディングを生成します。
• パフォーマンスが重要なユースケースでは、大規模なデータセットや、ライブ テキスト読み上げや動画アプリケーションなどの継続的なフローに gRPC ストリーミングを活用します。GKE に gRPC サービスをデプロイします。

標準化された包括的なドキュメント

選択したインターフェース プロトコルに関係なく、標準化されたドキュメントは重要です。OpenAPI 仕様では、RESTful API について説明しています。OpenAPI を使用して、AI API と ML API（パス、メソッド、パラメータ、JSON スキーマにリンクされたリクエスト / レスポンス形式、セキュリティ）をドキュメント化します。包括的な API ドキュメントは、検出可能性とクライアント統合の向上に役立ちます。API の作成と可視化には、Swagger Editor などの UI ツールを使用します。開発を加速し、一貫性を確保するには、Gemini Code Assist などの AI を活用したコーディング ツールを使用して、クライアント SDK とサーバー スタブを生成します。OpenAPI ドキュメントを CI / CD フローに統合します。

Agent Platform などの Google Cloud マネージド サービスとの連携

開発の生産性を高めるために推奨される Agent Platform SDK の高度な抽象化と、REST API が提供するきめ細かい制御のどちらかを選択します。

• Agent Platform SDK を使用すると、タスクと認証が簡素化されます。Agent Platform を操作する必要がある場合は、SDK を使用します。
• REST API は、特にシステムのレイヤ間で相互運用性が必要な場合に強力な代替手段となります。これは、SDK がない言語のツールや、きめ細かい制御が必要な場合に便利です。

API を使用してモジュールを分離し、実装の詳細を抽象化する

セキュリティ、スケーラビリティ、可視性を確保するには、AI サービスと ML サービスに堅牢な API 管理を実装することが重要です。定義したインターフェースの API 管理を実装するには、次のプロダクトを使用します。

• API Gateway: 外部に公開され、管理される API の場合、API Gateway は一元化された安全なエントリ ポイントを提供します。予測、トレーニング、Data API などのサーバーレス バックエンド サービスへのアクセスを簡素化します。API Gateway は、アクセス ポイントの統合、API 契約の適用、API キーや OAuth 2.0 などのセキュリティ機能の管理に役立ちます。バックエンドを過負荷から保護し、信頼性を確保するには、API Gateway でレート制限と使用量割り当てを実装します。
• Cloud Endpoints: GKE と Cloud Run での API の開発とデプロイを効率化するには、Endpoints を使用します。Endpoints は、API キーを生成するためのデベロッパー向けのソリューションを提供します。また、API 呼び出しの統合モニタリングとトレースを提供し、OpenAPI 仕様の生成を自動化します。これにより、ドキュメントとクライアントの統合が簡素化されます。Endpoints を使用して、トレーニングのトリガーや特徴ストアの管理など、内部または制御された AI API と ML API へのアクセスを管理できます。
• Apigee: エンタープライズ規模の AI と ML、特に高度な生成 AI API 向けに、Apigee は高度で包括的な API 管理を提供します。Apigee は、脅威対策や OAuth 2.0 などの高度なセキュリティ、キャッシュ保存、割り当て、メディエーションなどのトラフィック管理、分析に使用します。Apigee を使用すると、API の使用パターン、パフォーマンス、エンゲージメントに関する詳細な分析情報を取得できます。これは、生成 AI API の使用状況を把握するうえで重要です。

グレースフル デグラデーションを計画する

本番環境の AI システムと ML システムでは、他のシステムと同様に、コンポーネントの障害は避けられません。グレースフル デグラデーションにより、パフォーマンスが低下する可能性はありますが、重要な機能は引き続き動作します。このアプローチにより、完全な停止を防ぎ、全体的な可用性を向上させることができます。グレースフル デグラデーションは、レイテンシに敏感な推論、分散トレーニング、生成 AI に不可欠です。

以降のセクションでは、グレースフル デグラデーションを計画して実装するために使用する手法について説明します。

障害の分離

• 分散アーキテクチャで障害のあるコンポーネントを分離するには、Java の Resilience4j や Python の CircuitBreaker などのレジリエンス ライブラリを使用して、サーキット ブレーカー パターンを実装します。
• カスケード障害を防ぐには、エラー率やレイテンシなどの AI / ML ワークロード指標に基づいてしきい値を構成し、よりシンプルなモデルやキャッシュに保存されたデータなどのフォールバックを定義します。

コンポーネントの冗長性

重要なコンポーネントには、冗長性と自動フェイルオーバーを実装します。たとえば、GKE マルチゾーン クラスタまたはリージョン クラスタを使用し、異なるリージョンに Cloud Run サービスを冗長的にデプロイします。異常なインスタンスが検出されたときに正常なインスタンスにトラフィックを転送するには、Cloud Load Balancing を使用します。

Cloud Storage のマルチリージョン バケットを使用してデータの冗長性を確保する。分散トレーニングの場合は、障害後に再開できるように非同期チェックポイント処理を実装します。復元力と柔軟性に優れたトレーニングには、Pathways を使用します。

プロアクティブなモニタリング

グレースフル デグラデーションは、障害発生時にシステムの可用性を確保するのに役立ちますが、継続的なヘルスチェックと包括的なモニタリングのためのプロアクティブな対策も実装する必要があります。レイテンシ、スループット、GPU 使用率など、AI と ML に固有の指標を収集します。また、Monitoring と Gemini Enterprise Agent Platform の Model Monitoring を使用して、モデルやデータドリフトなどのモデル パフォーマンスの低下指標を収集します。

ヘルスチェックにより、障害のあるノードの交換、容量の追加、更新されたデータを使用するパイプラインの継続的な再トレーニングやファインチューニングの自動トリガーが必要になる場合があります。このプロアクティブなアプローチは、精度ベースの劣化とシステムレベルのグレースフル デグラデーションの両方を防ぎ、全体的な信頼性を高めるのに役立ちます。

SRE プラクティス

システムの健全性をモニタリングするには、SRE プラクティスを採用してサービスレベル目標（SLO）を実装することを検討してください。エラー バジェットの損失とバーンレートに関するアラートは、システムの信頼性の問題の早期指標となります。SRE プラクティスの詳細については、Google SRE ブックをご覧ください。

自動化されたエンドツーエンドの MLOps プラットフォームを構築する

Google Cloudで堅牢、スケーラブル、信頼性の高い AI / ML システムを構築するには、モデル開発ライフサイクルに自動化されたエンドツーエンドの MLOps プラットフォームが必要です。開発ライフサイクルには、初期データ処理、継続的なモデル トレーニング、デプロイ、本番環境でのモニタリングが含まれます。 Google Cloudでこれらのステージを自動化することで、再現可能なプロセスを確立し、手作業によるトイルを削減し、エラーを最小限に抑え、イノベーションのペースを加速できます。

自動化された MLOps プラットフォームは、アプリケーションの本番環境レベルの信頼性を確立するために不可欠です。自動化により、モデルの品質を確保し、再現性を保証し、AI と ML アーティファクトの継続的インテグレーションとデリバリーを実現できます。

自動化されたエンドツーエンドの MLOps プラットフォームを構築するには、次の推奨事項を検討してください。

モデル開発ライフサイクルを自動化する

自動化された MLOps プラットフォームの中核となる要素は、AI と ML のワークフロー全体を、データの準備と検証からモデルのトレーニング、評価、デプロイ、モニタリングに至るまで、一連の接続された自動化されたステップとしてオーケストレートすることです。

• Agent Platform Pipelines を中央オーケストレーターとして使用します。
  • データ処理、トレーニング、評価、デプロイ用のモジュラー コンポーネントを使用して、エンドツーエンドのワークフローを定義します。
  • スケジュールや、新しいデータやコードの変更などのトリガーを使用して、パイプラインの実行を自動化します。
  • パイプライン実行ごとに自動パラメータ化とバージョニングを実装し、変更履歴を作成する。
  • 組み込みのロギングとトレースを使用してパイプラインの進行状況とリソース使用量をモニタリングし、Monitoring アラートと統合します。
• Kubeflow Pipelines（KFP）SDK または TensorFlow Extended SDK を使用して、ML パイプラインをプログラムで定義します。詳細については、Agent Platform Pipelines のインターフェースをご覧ください。
• Dataflow、Agent Platform のカスタム トレーニング、Gemini Enterprise Agent Platform の Model Registry、Agent Platform エンドポイントなどの Google Cloud サービスを使用して、オペレーションをオーケストレートします。
• 生成 AI ワークフローの場合、プロンプト管理、バッチ推論、人間参加型（HITL）評価、ADK コンポーネントの調整の手順をオーケストレートします。

Infrastructure as Code の管理

Infrastructure as Code（IaC）は、AI システムと ML システムのインフラストラクチャを管理し、再現可能でスケーラブル、かつ保守可能なデプロイを実現するために不可欠です。AI システムと ML システムのインフラストラクチャのニーズは、動的で複雑です。多くの場合、システムには GPU や Cloud TPU などの特殊なハードウェアが必要です。IaC は、一貫性を確保し、ロールバックを可能にし、デプロイを繰り返し可能にすることで、手動のインフラストラクチャ管理のリスクを軽減するのに役立ちます。

インフラストラクチャ リソースをコードとして効果的に管理するには、次の手法を使用します。

リソース プロビジョニングの自動化

Google Cloudで IaC を効果的に管理するには、Terraform を使用して AI / ML インフラストラクチャ リソースを定義してプロビジョニングします。インフラストラクチャには、次のようなリソースが含まれる場合があります。

• ノードプールで構成された GKE クラスタ。ノードプールは、ワークロードの要件に基づいて最適化できます。たとえば、トレーニングに A100、H100、H200、B200 GPU を使用し、推論に L4 GPU を使用できます。
• モデル提供用に構成され、マシンタイプとスケーリング ポリシーが定義されている Agent Platform エンドポイント。
• データとアーティファクト用の Cloud Storage バケット。

構成テンプレートを使用する

Terraform 構成をモジュラー テンプレートとして整理します。AI リソースと ML リソースのプロビジョニングを高速化するには、Cluster Toolkit を使用します。このツールキットには、ブループリントの例が用意されています。これは、Google がキュレートした Terraform テンプレートで、Slurm または GKE で、すぐに使用できる HPC、AI、ML クラスタをデプロイするために使用できます。Terraform コードをカスタマイズして、バージョン管理システムで管理できます。リソースのプロビジョニングと更新のワークフローを自動化するには、Cloud Build を使用してコードを CI / CD パイプラインに統合します。

構成変更を自動化する

インフラストラクチャをプロビジョニングしたら、進行中の構成変更を宣言的に管理します。

• Kubernetes 中心型の環境では、Config Connector を使用して Google Cloudリソースを Kubernetes オブジェクトとして管理します。
• YAML マニフェストを使用して、データセット、モデル、エンドポイント、Cloud SQL インスタンス、Pub/Sub トピック、Cloud Storage バケットなどの Agent Platform リソースを定義して管理します。
• マニフェストを GKE クラスタにデプロイして、アプリケーションとインフラストラクチャの構成を統合します。
• CI / CD パイプラインを使用して構成の更新を自動化し、テンプレートを使用して環境の違いを処理します。
• IaC を使用して、Identity and Access Management（IAM）ポリシーとサービス アカウントの構成を実装する。

CI / CD と統合する

• Cloud Build や Infrastructure Manager などのツールを使用して IaC を CI / CD パイプラインに統合し、 Google Cloud インフラストラクチャ リソースのライフサイクルを自動化します。
• コード commit での自動更新のトリガーを定義する。
• パイプライン内で自動テストと検証を実装します。たとえば、Terraform の validate コマンドと plan コマンドを自動的に実行するスクリプトを作成できます。
• 構成をアーティファクトとして保存し、バージョニングを有効にする。
• 開発、ステージング、本番環境などの個別の環境を、バージョン管理で個別の構成で定義し、環境のプロモーションを自動化します。

モデルの動作を検証する

モデルの精度と関連性を長期にわたって維持するには、MLOps プラットフォーム内でトレーニングと評価のプロセスを自動化します。この自動化と厳格な検証により、モデルが本番環境にデプロイされる前に、関連するデータで想定どおりに動作することを確認できます。

• 継続的なトレーニング パイプラインを設定します。これは、新しいデータやデータドリフトなどのモニタリング シグナルによってトリガーされるか、スケジュールに従って実行されます。
  • ハイパーパラメータ チューニング トライアルや大規模なモデルの分散トレーニング構成など、自動トレーニング ジョブを管理するには、Agent Platform カスタム トレーニングを使用します。
  • 基盤モデルのファインチューニングでは、ファインチューニング プロセスを自動化し、ジョブをパイプラインに統合します。
• 自動モデル バージョニングを実装し、トレーニングが正常に実行されるたびに、トレーニング済みモデル アーティファクトを安全に保存します。アーティファクトは Cloud Storage に保存することも、Model Registry に登録することもできます。
• 評価指標を定義し、最小精度、最大エラー率、最小 F1 スコアなどの明確なしきい値を設定します。
  • モデルがしきい値を満たしていることを確認して、評価を自動的にパスし、デプロイを検討できるようにします。
  • Agent Platform のモデル評価などのサービスを使用して、評価を自動化します。
  • 評価には、生成された出力の品質、事実の正確性、安全属性、指定されたスタイルや形式への準拠に固有の指標が含まれていることを確認します。
• 各トレーニングと評価の実行のパラメータ、コード バージョン、データセット バージョン、結果を自動的にログに記録して追跡するには、Gemini Enterprise Agent Platform の Experiments を使用します。このアプローチでは、比較、デバッグ、再現性に役立つ履歴が提供されます。
• ハイパーパラメータ チューニングを最適化し、定義した目標に基づいて最適なモデル構成の検索を自動化するには、Agent Platform Vizier を使用します。
• トレーニング指標を可視化し、開発中にデバッグするには、Agent Platform TensorBoard を使用します。

AI / ML パイプラインの入力と出力を検証する

AI システムと ML システムの信頼性と完全性を確保するには、データがシステムに入力され、パイプラインを移動するときにデータを検証する必要があります。また、コンポーネントの境界で入力と出力を検証する必要があります。すべての入出力（元データ、処理済みデータ、構成、引数、ファイル）を堅牢に検証することで、予期しない動作を防ぎ、MLOps ライフサイクル全体でモデルの品質を維持できます。このプロアクティブなアプローチを MLOps プラットフォームに統合すると、エラーがシステム全体に伝播する前に検出され、時間とリソースを節約できます。

AI パイプラインと ML パイプラインの入力と出力を効果的に検証するには、次の手法を使用します。

データ検証を自動化する

• TensorFlow Data Validation（TFDV）を使用して、データの取り込みパイプラインと前処理パイプラインに自動データ検証を実装します。
  • 大規模な SQL ベースのデータ品質チェックには、BigQuery などのスケーラブルな処理サービスを活用します。
  • ストリーミング データまたはバッチデータに対して複雑なプログラムによる検証を行うには、Dataflow を使用します。
• TFDV 機能を使用して、経時的なデータ分布をモニタリングします。
  • Monitoring と統合されたツールを使用して、データドリフトを検出する傾向を可視化します。データパターンが大幅に変化したときに、モデルの再トレーニング パイプラインを自動的にトリガーできます。
• 検証結果と指標を BigQuery に保存して分析と履歴追跡を行い、検証アーティファクトを Cloud Storage にアーカイブします。

パイプライン構成と入力データを検証する

不適切な設定によるパイプラインの失敗や予期しない動作を防ぐには、すべてのパイプライン構成とコマンドライン引数に厳格な検証を実装します。

• Python の jsonschema などのスキーマ検証ライブラリを使用して、YAML や JSON などの構成ファイルに明確なスキーマを定義します。パイプラインの実行が開始される前とコンポーネントが実行される前に、これらのスキーマに対して構成オブジェクトを検証します。
• argparse などの引数解析ライブラリを使用して、すべてのコマンドライン引数とパイプライン パラメータに入力検証を実装します。検証では、正しいデータ型、有効な値、必須の引数を確認する必要があります。
• Agent Platform Pipelines 内で、組み込みのコンポーネント入力検証機能を使用して、コンポーネント パラメータの想定される型とプロパティを定義します。
• パイプライン実行の再現性を確保し、監査証跡を維持するには、検証済みのバージョニングされた構成ファイルを Cloud Storage または Artifact Registry に保存します。

入力ファイルと出力ファイルを検証する

データセット、モデル アーティファクト、評価レポートなどの入力ファイルと出力ファイルの整合性と形式の正確性を検証します。

• ライブラリを使用して、CSV、Parquet、画像タイプなどのファイル形式を検証します。
• 大きなファイルや重要なアーティファクトの場合は、Cloud Storage のデータ検証と変更検出を使用して、ファイルサイズとチェックサムを検証し、破損や不完全な転送を検出します。
• Cloud Run functions（ファイル アップロード イベントに基づくなど）または Dataflow パイプライン内でファイル検証を実行します。
• 検証結果を BigQuery に保存して、取得と分析を容易にします。

デプロイを自動化し、継続的なモニタリングを実装する

本番環境でのモデルの自動デプロイと継続的なモニタリングにより、信頼性の確保、迅速な更新、問題の迅速な検出が可能になります。これには、モデル バージョンの管理、制御されたデプロイ、CI / CD を使用した自動デプロイ、包括的なモニタリングが含まれます。これらについては、以降のセクションで説明します。

モデル バージョンを管理する

バージョニング ツールを使用して、モデルのイテレーションと関連するアーティファクトを管理します。

• モデルのバージョンとメタデータを追跡し、基盤となるモデル アーティファクトにリンクするには、Model Registry を使用します。
• 明確なバージョニング スキーム（セマンティック バージョニングなど）を実装します。モデル バージョンごとに、トレーニング パラメータ、検証パイプラインの評価指標、データセット バージョンなどの包括的なメタデータを添付します。
• モデルファイル、事前トレーニング済みの重み、サービング コンテナ イメージなどのモデル アーティファクトを Artifact Registry に保存し、バージョニング機能とタグ付け機能を使用します。
• セキュリティとガバナンスの要件を満たすには、Model Registry と Artifact Registry に厳格なアクセス制御ポリシーを定義します。
• バージョンをプログラムで登録して管理し、バージョンを自動化された CI / CD パイプラインに統合するには、Agent Platform SDK または API を使用します。

制御されたデプロイを実行する

サービス提供プラットフォームのトラフィック管理機能を使用して、エンドポイントへのモデル バージョンのデプロイを制御します。

• Agent Platform エンドポイントのトラフィック分割機能を使用して、ローリング デプロイを実装します。
• モデルを GKE にデプロイする場合は、カナリア デプロイなどの高度なトラフィック管理手法を使用します。
  1. 本番環境トラフィックのごく一部を新しいモデル バージョンにルーティングする。
  2. 指標を通じてパフォーマンスとエラー率を継続的にモニタリングします。
  3. モデルが信頼できることを確認する。
  4. すべてのトラフィックにバージョンをロールアウトします。
• AI エージェントの A/B テストを実行する。
  1. 2 つの異なるモデル エージェント バージョンまたはまったく異なるモデルを同じエンドポイントにデプロイします。
  2. デプロイ間でトラフィックを分割します。
  3. ビジネス目標に照らし合わせて結果を分析します。
• モニタリング アラートがトリガーされた場合や、パフォーマンスのしきい値に達しなかった場合に、エンドポイント トラフィックを以前の安定したモデル バージョンに迅速に戻すことができる自動ロールバック メカニズムを実装します。
• Agent Platform SDK または API を使用して、トラフィック分割とデプロイの設定をプログラムで構成します。
• Monitoring を使用して、バージョン間のパフォーマンスとトラフィックを追跡します。
• CI / CD パイプラインを使用してデプロイを自動化する。Cloud Build を使用して、コンテナのビルド、アーティファクトのバージョニング、Agent Platform エンドポイントへのデプロイのトリガーを行うことができます。
• CI / CD パイプラインがバージョンを管理し、Artifact Registry から pull していることを確認します。
• トラフィックを移行する前に、予測の正確性、レイテンシ、スループット、API 関数について、自動エンドポイント テストを実行します。
• すべての構成をバージョン管理に保存する。

継続的なモニタリング

• Agent Platform の Model Monitoring を使用して、パフォーマンスの低下、データドリフト（トレーニングと比較した入力分布の変化）、予測ドリフト（モデル出力の変化）を自動的に検出します。
  • しきい値とアラートを使用してドリフト検出ジョブを構成する。
  • リアルタイムのパフォーマンス（予測レイテンシ、スループット、エラー率）をモニタリングします。
• ビジネス KPI の Monitoring でカスタム指標を定義します。
• Agent Platform の Model Monitoring の結果とカスタム指標を Monitoring と統合して、アラートとダッシュボードを作成します。
• メール、Slack、PagerDuty などの通知チャンネルを構成し、自動修復を構成します。
• 予測ログをデバッグするには、Logging を使用します。
• モニタリングをインシデント管理と統合する。

生成 AI エンドポイントの場合は、有害性や一貫性などの出力特性をモニタリングします。

• 特徴のサービングでドリフトをモニタリングする。
• きめ細かい予測検証を実装する: カスタム ロジックを使用して、想定される範囲と形式に対して出力を検証します。
• 予測分布のシフトをモニタリングする。
• 出力スキーマを検証します。
• 予期しない出力やシフトに対するアラートを構成する。
• Pub/Sub を使用して、リアルタイムの検証イベントを追跡して対応します。

包括的なモニタリングの出力が継続的なトレーニングにフィードバックされるようにします。

データとモデルのガバナンスを通じて信頼と管理を維持する

AI と ML の信頼性は、技術的な稼働時間にとどまりません。これには、信頼性と堅牢なデータおよびモデル ガバナンスが含まれます。AI の出力は、不正確、偏りがある、または古い可能性があります。このような問題は信頼を損ない、害を及ぼす可能性があります。包括的なトレーサビリティ、強力なアクセス制御、自動検証、透明性の高いプラクティスにより、AI の出力が信頼性が高く、倫理基準を満たしていることを確認できます。

データとモデルのガバナンスを通じて信頼と管理を維持するには、次の推奨事項を検討してください。

トレーサビリティのためにデータカタログとモデルカタログを確立する

AI アセットと ML アセットの包括的なトレース、監査、リネージの把握を容易にするため、ライフサイクル全体を通じてデータとモデルのバージョンの堅牢な一元管理されたレコードを維持します。信頼性の高いデータとモデルのカタログは、AI / ML パイプラインで使用および生成されるすべてのアーティファクト（元データソース、処理済みデータセット、トレーニング済みモデル バージョン、デプロイされたエンドポイントなど）の信頼できる唯一の情報源として機能します。

次のプロダクト、ツール、手法を使用して、データアセットのカタログを作成して維持します。

• Knowledge Catalog を使用して、データアセットのエンタープライズ全体のカタログを構築します。データアセットを自動的に検出してインベントリを構築するには、Knowledge Catalog を BigQuery、Cloud Storage、Pub/Sub などのストレージ システムと統合します。
• Cloud Storage のマルチリージョン バケットまたはデュアルリージョン バケットにデータを保存して、データの高可用性と耐久性を確保します。これらのバケットにアップロードしたデータは、少なくとも 2 つの地理的位置に冗長的に保存されます。この冗長性により、リージョン単位のサービス停止に対する復元力が組み込まれ、データの完全性を確保できます。
• 関連するビジネス メタデータ、オーナー権限情報、機密レベル、リネージの詳細を使用して、データセットにタグ付けしてアノテーションを付けます。たとえば、処理済みのデータセットを未加工のソースと、データセットを作成したパイプラインにリンクします。
• Model Registry を使用して、モデル バージョンの中央リポジトリを作成します。トレーニング済みモデルの各バージョンを登録し、関連するメタデータにリンクします。メタデータには次のものが含まれます。
  • トレーニング パラメータ。
  • 検証パイプラインからの評価指標。
  • トレーニングに使用されたデータセットのバージョン。リネージは関連する Knowledge Catalog エントリまで遡ります。
  • データセットを生成したコードのバージョン。
  • 使用されたフレームワークまたは基盤モデルの詳細。
• モデルを Model Registry にインポートする前に、モデルファイルや事前トレーニング済みの重みなどのモデル アーティファクトを Cloud Storage などのサービスに保存します。サービングまたはカスタム トレーニング ジョブ用のカスタム コンテナ イメージを、Artifact Registry などの安全なリポジトリに保存します。
• データアセットとモデルアセットが作成または変更時にそれぞれのカタログに自動的に登録および更新されるようにするには、MLOps パイプライン内に自動プロセスを実装します。この包括的なカタログ化により、元データから予測までのエンドツーエンドのトレーサビリティが実現し、特定のモデル バージョンや予測につながった入力とプロセスを監査できます。監査機能は、予期しない動作のデバッグ、データ利用ポリシーの遵守、データやモデルの変更による影響の把握に不可欠です。
• 生成 AI と基盤モデルの場合、カタログでは、使用された特定の基盤モデル、ファインチューニング パラメータ、生成された出力の品質と安全性に固有の評価結果に関する詳細も追跡する必要があります。

堅牢なアクセス制御と監査証跡を実装する

AI システムと ML システムの信頼性と制御を維持するには、機密データとモデルを不正アクセスから保護し、すべての変更に対する説明責任を確保することが不可欠です。

• Google Cloudの AI システムと ML システムのすべてのコンポーネントに厳格なアクセス制御を実装し、詳細な監査証跡を維持します。
• AI リソースと ML リソースを操作するユーザー、グループ、サービス アカウントに対して、IAM で詳細な権限を定義します。
• 最小権限の原則を厳格に遵守する。
• 特定のタスクに必要な最小限の権限のみを付与します。たとえば、トレーニング サービス アカウントには、トレーニング データへの読み取りアクセス権とモデル アーティファクトへの書き込みアクセス権が必要ですが、本番環境のサービング エンドポイントへの書き込みアクセス権は必要ない場合があります。

AI / ML システム内のすべての関連アセットとリソースに IAM ポリシーを一貫して適用します。これには、次のものが含まれます。

• 機密データまたはモデル アーティファクトを含む Cloud Storage バケット。
• BigQuery データセット。
• モデル リポジトリ、エンドポイント、パイプライン、Feature Store リソースなどの Agent Platform リソース。
• GKE クラスタや Cloud Run サービスなどのコンピューティング リソース。

監査とログを使用して、アクセス アクティビティをキャプチャ、モニタリング、分析します。

• AI と ML システムで使用されるすべての Google Cloud サービスで Cloud Audit Logs を有効にします。
• API 呼び出し、データアクセス イベント、リソースに加えられた構成変更に関する詳細情報をキャプチャするように監査ログを構成します。ログをモニタリングして、不審なアクティビティ、不正なアクセス試行、重要なデータやモデルアセットの予期しない変更を検出します。
• リアルタイムの分析、アラート、可視化を行うには、監査ログを Logging にストリーミングします。
• 費用対効果の高い長期保存と、遡及的なセキュリティ分析またはコンプライアンス監査を行うには、ログを BigQuery にエクスポートします。
• 一元化されたセキュリティ モニタリングを行うには、監査ログをセキュリティ情報およびイベント管理（SIEM）システムと統合します。アクセス ポリシーと監査証跡を定期的に確認して、ガバナンス要件に沿っていることを確認し、潜在的なポリシー違反を検出します。
• トレーニングや推論用の個人情報（PII）などの機密データを扱うアプリケーションの場合は、パイプライン内またはデータ ストレージで Sensitive Data Protection チェックを使用します。
• 生成 AI とエージェント ソリューションの場合は、監査証跡を使用して、特定のモデルやツールにアクセスしたユーザー、ファインチューニングやプロンプトに使用されたデータ、本番環境エンドポイントに送信されたクエリを追跡します。監査証跡は、説明責任を果たすのに役立ち、データの不正使用やポリシー違反を調査するための重要なデータを提供します。

バイアス、透明性、説明可能性に対処する

信頼できる AI システムと ML システムを構築するには、データとモデルに固有の潜在的なバイアスに対処し、システム動作の透明性を追求して、モデル出力の説明可能性を提供する必要があります。機密性の高いドメインや、生成 AI アプリケーションで通常使用されるような複雑なモデルを使用する場合は、信頼できるシステムを構築することが特に重要です。

• MLOps ライフサイクル全体でバイアスを特定して軽減するための予防的な手法を実装します。
• さまざまなユーザー グループやセンシティブな属性にわたる特徴分布のスキューを検出するツールを使用して、トレーニング データのバイアスを分析します。
• モデルの全体的なパフォーマンスと、事前定義されたデータスライス全体のパフォーマンスを評価します。このような評価は、特定のサブグループに影響するパフォーマンスの不均衡やバイアスを特定するのに役立ちます。

モデルの透明性と説明可能性を確保するには、モデルが特定の予測を行った理由や特定の出力を生成した理由をユーザーとデベロッパーが理解するのに役立つツールを使用します。

• Agent Platform エンドポイントにデプロイされている表形式モデルの場合、予測に最も貢献した入力特徴を示す特徴アトリビューションを生成します。
• TensorBoard と統合された What-If ツールなどのモデルに依存しないツールを使用して、データセットに対するモデルの動作と潜在的なバイアスをインタラクティブに探索します。
• 説明可能性をモニタリング ダッシュボードに統合します。モデルの推論を理解することが信頼や意思決定に重要な状況では、アプリケーション インターフェースを介してエンドユーザーに説明可能性データを直接提供します。
• 生成 AI モデルに使用される LLM などの複雑なモデルの場合は、トレースログなどを使用して、エージェントが実行したプロセスを説明します。このようなモデルでは説明可能性は比較的困難ですが、それでも重要です。
• RAG アプリケーションでは、取得した情報の引用を提供します。プロンプト エンジニアリングなどの手法を使用して、モデルに説明を提供させたり、推論手順を示させたりすることもできます。
• 本番環境で継続的なモニタリングを実装して、新たなバイアスや不公平性を示す可能性のあるモデルの動作や出力の変化を検出します。モデルの制限事項、想定されるユースケース、既知の潜在的なバイアスを、Model Registry のモデルのメタデータの一部として文書化します。

包括的な AI と ML のオブザーバビリティと信頼性のプラクティスを実装する

本番環境で複雑な AI / ML システムを管理するには、包括的なオブザーバビリティが不可欠です。また、複雑な AI システムや ML システムの信頼性を測定するうえでも不可欠です。特に生成 AI は、複雑さ、リソースの消費量、予測不可能な出力の可能性を考慮すると、信頼性の測定が重要になります。包括的なオブザーバビリティには、インフラストラクチャ、アプリケーション コード、データ、モデルの動作をモニタリングして、プロアクティブな問題の検出、診断、対応のための分析情報を取得することが含まれます。このオブザーバビリティは、最終的に高パフォーマンスで信頼性の高いシステムにつながります。包括的なオブザーバビリティを実現するには、次のことを行う必要があります。

• SRE の原則を導入する。
• 信頼性の目標を明確に定義する。
• システムレイヤ全体で指標を追跡する。
• オブザーバビリティの分析情報を使用して、継続的な改善とプロアクティブな管理を行います。

Google Cloudで AI / ML ワークロードの包括的なオブザーバビリティと信頼性のプラクティスを実装するには、次の推奨事項を検討してください。

信頼性の目標とビジネス指標を確立する

AI システムと ML システムが直接影響する重要業績評価指標（KPI）を特定します。KPI には、AI のレコメンデーションの影響を受ける収益、AI システムが予測または軽減した顧客離れ、生成 AI 機能によって促進されるユーザー エンゲージメントとコンバージョン率などが含まれます。

KPI ごとに、KPI に影響する対応する技術的な信頼性指標を定義します。たとえば、KPI が「会話型 AI アシスタントに対する顧客満足度」の場合、対応する信頼性指標には次のものが含まれます。

• ユーザー リクエストの成功率。
• レスポンスのレイテンシ: LLM の最初のトークンまでの時間（TTFT）とトークン ストリーミング。
• 無関係な回答や有害な回答の割合。
• エージェントによるタスクの完了率。

AI と ML のトレーニングの場合、信頼性指標には、モデルの FLOPS 使用率（MFU）、1 秒あたりのイテレーション数、1 秒あたりのトークン数、デバイスあたりのトークン数などがあります。

AI と ML の信頼性を効果的に測定して改善するには、まず、全体的なビジネスの目標に沿った明確な信頼性目標を設定します。ユーザーの視点から AI サービスと ML サービスの信頼性とパフォーマンスの許容レベルを定量化する SLO を定義して、SRE アプローチを採用します。これらの技術的な信頼性指標を特定の SLO ターゲットで定量化します。

SLO ターゲットの例を次に示します。

• API 呼び出しの 99.9% が成功レスポンスを返す必要があります。
• 95 パーセンタイルの推論レイテンシが 300 ミリ秒未満である必要があります。
• TTFT は、リクエストの 99% で 500 ミリ秒未満である必要があります。
• 有害な出力の割合は 0.1% 未満である必要があります。

SLO をビジネスニーズに直接合わせることで、信頼性への取り組みが、ユーザーとビジネスに影響する最も重要なシステム動作に集中するようになります。このアプローチにより、信頼性を測定可能で実用的なエンジニアリング プロパティに変換できます。

インフラストラクチャとアプリケーションのパフォーマンスをモニタリングする

AI システムと ML システムで使用されるすべてのリソースのインフラストラクチャ指標を追跡します。指標には、プロセッサ使用率（CPU、GPU、Cloud TPU）、メモリ使用量、ネットワーク スループットとレイテンシ、ディスク I/O が含まれます。Agent Platform のトレーニングやサービングなどのマネージド環境の指標と、GKE ノードや Cloud Run インスタンスなどのセルフマネージド リソースの指標を追跡します。

AI アプリケーションと ML アプリケーションの 4 つのゴールデン シグナルをモニタリングします。

• レイテンシ: リクエストに応答するまでの時間。
• トラフィック: リクエストまたはワークロードの量。
• エラー率: 失敗したリクエストまたはオペレーションの割合。
• 飽和度: CPU、メモリ、GPU、Cloud TPU アクセラレータなどの重要なリソースの使用率。システムが容量の上限にどのくらい近づいているかを示します。

次の手法を使用してモニタリングを行います。

• Monitoring を使用して、インフラストラクチャとアプリケーションの指標を収集、保存、可視化します。 Google Cloud サービスに事前構築済みのダッシュボードを使用し、ワークロードの特定のパフォーマンス指標とインフラストラクチャの健全性に基づいてカスタマイズされたカスタム ダッシュボードを作成できます。
  • vLLM や NVIDIA Triton Inference Server などの専用のサービング フレームワークから指標を収集し、Google Cloud Managed Service for Prometheus を使用して Monitoring に統合します。
  • カスタム トレーニング、エンドポイント、パフォーマンスに関連する指標と、Agent Platform が Monitoring にエクスポートする指標のダッシュボードを作成し、アラートを構成します。
• Logging を使用して、AI / ML アプリケーションと基盤となるインフラストラクチャから詳細なログを収集します。これらのログは、トラブルシューティングとパフォーマンス分析に不可欠です。イベントとエラーに関するコンテキストを提供します。
• Cloud Trace を使用して、レイテンシの問題を特定し、分散 AI / ML マイクロサービス全体のリクエスト フローを把握します。この機能は、複雑な Agent Conversation のインタラクションや、複数のコンポーネントからなる推論パイプラインをデバッグする際に不可欠です。
• Cloud Profiler を使用して、アプリケーション コードの関数ブロック内のパフォーマンスのボトルネックを特定します。パフォーマンスのボトルネックを特定すると、リソース使用量と実行時間を最適化できます。
• NVIDIA Data Center GPU Manager（DCGM）などのツールを使用して、プロセスごとの詳細な GPU 使用率、プロセスごとのメモリ使用量、温度など、アクセラレータ固有の指標を収集します。

データとモデルのオブザーバビリティを実装する

信頼性の高い生成 AI システムには、堅牢なデータとモデルのオブザーバビリティが必要です。これは、エンドツーエンドのパイプライン モニタリングから始まります。

• Dataflow などのサービスを使用して、データの取り込み率、処理量、変換レイテンシを追跡します。
• Agent Platform Pipelines で管理されているパイプラインなど、MLOps パイプライン内のジョブの成功率と失敗率をモニタリングします。

データ品質の継続的な評価は不可欠です。

• Knowledge Catalog を使用してデータを管理、統制する。
  • グラウンド トゥルースに対して検証するか、外れ値の検出率を追跡して、精度を評価します。
  • データの経過時間と更新頻度に基づいて、SLA に対する鮮度をモニタリングします。
  • null 値の割合と必須フィールドの入力率を追跡して、完全性を評価します。
  • スキーマの遵守と重複のチェックにより、有効性と整合性を確保します。
• Monitoring のアラートと、トレーサビリティのための明確なデータリネージを使用して、異常をプロアクティブに検出します。
• RAG システムの場合は、取得されたコンテキストの関連性と、回答のグラウンディング（ソースへの帰属）を調べます。
• ベクトル データベース クエリのスループットをモニタリングする。

モデルのオブザーバビリティの主な指標には、入出力トークン数や、ハルシネーションやクエリ解決の失敗などのモデル固有のエラー率などがあります。これらの指標を追跡するには、Agent Platform の Model Monitoring を使用します。

• 出力の有害性スコアとユーザー フィードバックの評価を継続的にモニタリングします。
• Gen AI Evaluation Service を使用して、定義された基準に沿ってモデル出力の評価を自動化します。
• 包括的なエラー率指標を使用してデータとコンセプトのドリフトを体系的にモニタリングし、パフォーマンスを維持します。

モデルの指標を追跡するには、TensorBoard または MLflow を使用します。パフォーマンスの問題をトラブルシューティングするための詳細な分析とプロファイリングを行うには、Cloud TPU VM でモデルをプロファイリングするか、NVIDIA Nsight を使用します。

寄稿者

著者:

• Rick（Rugui）Chen | AI インフラストラクチャ フィールド ソリューション アーキテクト
• Stef Ruinard | 生成 AI フィールド ソリューション アーキテクト

その他の寄稿者:

• Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
• Hossein Sarshar | AI インフラストラクチャ フィールド ソリューション アーキテクト
• Jose Andrade | カスタマー エンジニア兼 SRE スペシャリスト
• Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
• Laura Hyatt | カスタマー エンジニア兼 FSI
• Olivier Martin | AI インフラストラクチャ フィールド ソリューション アーキテクト
• Radhika Kanakam | Google Cloud Well-Architected Framework プログラム リード