Google Cloudは2026年8月、AIエージェントの運用で課題になりやすい2つの領域に対応する新機能を発表しました。ひとつは、用途に合うデータベースの選定や、稼働後の監視・障害対応を支援するAIエージェント。もうひとつは、通常のウェブリクエスト処理がない間も稼働し続けられる、永続型のCloud Runランタイムです。

発表されたのは、Gemini Cloud Assistに統合された Database Operations Agents と、プレビュー提供が始まった Cloud Run instances です。データ層とコンピュート層の両方を、AIエージェント向けに適応させる動きといえます。2411

データベースの「導入」と「運用」を2つのエージェントで支援

Database Operations Agentsは、Google Cloudが掲げる Agentic Data Cloud 戦略の一環です。役割は明確に分かれており、Database Onboarding Agentが導入前の Day 0 を、Database Observability Agentが稼働後の Day 1・Day 2 を担当します。2

Database Onboarding Agent：要件整理からデプロイまで

Database Onboarding Agentは、チームが提示したワークロード要件を解釈し、適したマネージドデータベースを推薦したうえで、設定やデプロイを案内します。アプリケーションを本番稼働させる前に必要だった、アーキテクチャ設計やプロビジョニングの判断を減らすことが狙いです。2

対応するサービスは AlloyDB、Bigtable、Cloud SQL、Spanner です。2

開発者やプラットフォーム担当者が「アプリケーションに必要な性能や運用条件」は把握していても、Google Cloud上のどのデータベースが最適かまでは決め切れていない場面で役立つ機能です。

Database Observability Agent：稼働後の監視とトラブルシューティング

Database Observability Agentは、データベースをデプロイした後の運用ライフサイクルを支援します。Google Cloudが示す機能には、データベース群の監視、異常検知、原因分析、トラブルシューティング、最適化、保守が含まれます。224

対応サービスは Cloud SQL、AlloyDB、Spanner、Bigtable、Firestore、Memorystore です。224

単一の監視シグナルだけを見るのではなく、次の情報を関連付けて調査します。2

• Database InsightsおよびDatabase Centerのテレメトリ
• Cloud Monitoringのメトリクス
• Cloud Loggingのログ
• Cloud Traceのトレース
• クエリ情報、インベントリ、課題データ

そのため、単にダッシュボードへアラートを表示するだけでなく、問題の説明、対応策の提案、複数ステップの修復ワークフローまでを支援する設計です。例として、Cloud SQLのコネクションプーリングを有効にする、インデックスを追加するといった対応が挙げられています。2

本番環境に影響する可能性がある変更については、エージェントが検証済みの修正を実行する前に、人間による承認が必要です。調査・修復機能は、一部の顧客を対象としたプレビュー機能として提供されました。224

Geminiチャット、コンソール、CLIやIDEから利用

2つのエージェントは Gemini Cloud Assist に統合され、GeminiチャットやCloud Console内の関連するデータベースページから利用できます。Google Cloudはこの機能について、コマンドラインツール、MCPサーバーおよびツール、サードパーティ製ツール、統合開発環境（IDE）からの利用も説明しています。2

つまり、データベース支援を専用の運用ダッシュボードだけに閉じ込めるのではなく、開発者や運用担当者が普段使っている調査、リソース作成、開発環境のワークフローに組み込める形を目指しています。

Cloud Run instancesは「常駐するAIエージェント」向け

Google Cloudは8月28日、従来の自動スケーリング型Cloud Runサービスとは異なるプリミティブとして、Cloud Run instances をプレビューで発表しました。4

各インスタンスは シングルトン として動作します。常に1つのインスタンスだけを維持し、自動スケーリングは行いません。Google Cloudは、個人向けAIエージェントのような、長時間稼働するステートフルなワークロードを主な用途として位置付けています。4

主な特徴は次のとおりです。4

• 最大 7日間 の連続稼働
• デフォルトで設定される自動再起動ポリシー
• 更新や再起動の前後で変わらない安定したHTTPS URL
• 停止したインスタンスを後から再開できる機能
• リクエスト量に応じて増減するフリートではなく、1つの専用ランタイムを利用

この仕組みは、ユーザーごとの状態、アイデンティティ、バックグラウンド処理を保持するエージェントと相性がよい設計です。一方で、大量の同時アクセスを処理する一般的なステートレスWebエンドポイントには、従来のスケール型サービスのほうが自然な場合があります。

Googleが示した料金例は月5.70ドル

Googleは、共有vCPUとバースト予算を利用し、1 vCPU・メモリ1 GiB の構成を30日間連続稼働させた場合の料金として、5.70ドル を提示しています。4

Googleが強調するメリットは料金だけではありません。専用仮想マシン（VM）を管理する場合に必要となる、VMやOSの保守、ファイアウォール管理、HTTPSエンドポイントの構築などの作業を減らせるとしています。4

ただし、この金額や製品の挙動は、Googleがプレビュー段階で示した位置付けです。実際の料金は構成、利用量、リージョン、課金設定などによって変わるため、専用VMとのコスト差を一般化することはできません。43031

また、Googleは顧客企業OffDealのコメントとして、コールドスタートが 88％減少した という結果を紹介しています。これは顧客が報告した数値であり、Googleが保証する一般的な性能や、独立したベンチマークではありません。4

AIエージェント向けインフラという大きな流れ

従来のクラウドアプリケーションでは、ステートレスなリクエスト処理と、永続データを保存するデータベースを分ける構成が一般的でした。しかしAIエージェントは、ユーザーごとの永続的なアイデンティティやエンドポイント、メモリや状態、長時間のバックグラウンド実行、ツールや運用データへのアクセスを必要とすることがあります。

今回の発表は、こうした要件にデータ層とコンピュート層の両側から対応するものです。

1. データベース層の自律性を高める：Onboarding Agentがマネージドデータベースの選定とプロビジョニングを支援し、Observability Agentがデータベース群を監視して障害を調査し、承認済みの修正を実行します。2
2. 永続性を重視したコンピュートの選択肢を加える：Cloud Run instancesが、スケールゼロやリクエスト発生時の起動を前提としない、安定したシングルトン型ランタイムを提供します。4

Google CloudのAgentic Data Cloudは、データ、AIモデル、業務データベースを、エージェントが行動するための一つのシステムとして統合する構想です。11 今回の製品は、その構想を運用面へ広げるものと見られます。

注目すべき点は、運用の自動化を進めながらも、データベース変更のように本番環境へ重大な影響を及ぼし得る操作には人間の承認を残していることです。2

実際に検討する際のポイント

今回の発表は、すべてのAIエージェントを一つのサービスで動かす「万能なエージェント基盤」を示したものではありません。対象となる課題は比較的具体的です。

• データベースの選定、初期構築、フリートの可視化、障害対応が課題なら、Database Operations Agents を検討する
• エージェントに単一で永続的な実行環境とアドレス可能なエンドポイントが必要で、一般的なサーバーレスサービスのスケールゼロモデルに合わないなら、Cloud Run instances を検討する

いずれもプレビューを前提とした機能であるため、本番利用を判断する際は、提供地域、対応構成、権限、料金、そして自動修復が実行できる範囲を確認する必要があります。それでも方向性は明確です。Google CloudはAIエージェントを、より自律的な運用機能と、より長く状態を保持できるインフラの両方を必要とするワークロードとして捉え始めています。

Google Cloudは2026年8月、AIエージェントの運用で課題になりやすい2つの領域に対応する新機能を発表しました。ひとつは、用途に合うデータベースの選定や、稼働後の監視・障害対応を支援するAIエージェント。もうひとつは、通常のウェブリクエスト処理がない間も稼働し続けられる、永続型のCloud Runランタイムです。

発表されたのは、Gemini Cloud Assistに統合された Database Operations Agents と、プレビュー提供が始まった Cloud Run instances です。データ層とコンピュート層の両方を、AIエージェント向けに適応させる動きといえます。2411

データベースの「導入」と「運用」を2つのエージェントで支援

Database Operations Agentsは、Google Cloudが掲げる Agentic Data Cloud 戦略の一環です。役割は明確に分かれており、Database Onboarding Agentが導入前の Day 0 を、Database Observability Agentが稼働後の Day 1・Day 2 を担当します。2

Database Onboarding Agent：要件整理からデプロイまで

Database Onboarding Agentは、チームが提示したワークロード要件を解釈し、適したマネージドデータベースを推薦したうえで、設定やデプロイを案内します。アプリケーションを本番稼働させる前に必要だった、アーキテクチャ設計やプロビジョニングの判断を減らすことが狙いです。2

対応するサービスは AlloyDB、Bigtable、Cloud SQL、Spanner です。2

開発者やプラットフォーム担当者が「アプリケーションに必要な性能や運用条件」は把握していても、Google Cloud上のどのデータベースが最適かまでは決め切れていない場面で役立つ機能です。

Database Observability Agent：稼働後の監視とトラブルシューティング

Database Observability Agentは、データベースをデプロイした後の運用ライフサイクルを支援します。Google Cloudが示す機能には、データベース群の監視、異常検知、原因分析、トラブルシューティング、最適化、保守が含まれます。224

対応サービスは Cloud SQL、AlloyDB、Spanner、Bigtable、Firestore、Memorystore です。224

単一の監視シグナルだけを見るのではなく、次の情報を関連付けて調査します。2

• Database InsightsおよびDatabase Centerのテレメトリ
• Cloud Monitoringのメトリクス
• Cloud Loggingのログ
• Cloud Traceのトレース
• クエリ情報、インベントリ、課題データ

そのため、単にダッシュボードへアラートを表示するだけでなく、問題の説明、対応策の提案、複数ステップの修復ワークフローまでを支援する設計です。例として、Cloud SQLのコネクションプーリングを有効にする、インデックスを追加するといった対応が挙げられています。2

本番環境に影響する可能性がある変更については、エージェントが検証済みの修正を実行する前に、人間による承認が必要です。調査・修復機能は、一部の顧客を対象としたプレビュー機能として提供されました。224

Geminiチャット、コンソール、CLIやIDEから利用

2つのエージェントは Gemini Cloud Assist に統合され、GeminiチャットやCloud Console内の関連するデータベースページから利用できます。Google Cloudはこの機能について、コマンドラインツール、MCPサーバーおよびツール、サードパーティ製ツール、統合開発環境（IDE）からの利用も説明しています。2

つまり、データベース支援を専用の運用ダッシュボードだけに閉じ込めるのではなく、開発者や運用担当者が普段使っている調査、リソース作成、開発環境のワークフローに組み込める形を目指しています。

Cloud Run instancesは「常駐するAIエージェント」向け

Google Cloudは8月28日、従来の自動スケーリング型Cloud Runサービスとは異なるプリミティブとして、Cloud Run instances をプレビューで発表しました。4

各インスタンスは シングルトン として動作します。常に1つのインスタンスだけを維持し、自動スケーリングは行いません。Google Cloudは、個人向けAIエージェントのような、長時間稼働するステートフルなワークロードを主な用途として位置付けています。4

主な特徴は次のとおりです。4

• 最大 7日間 の連続稼働
• デフォルトで設定される自動再起動ポリシー
• 更新や再起動の前後で変わらない安定したHTTPS URL
• 停止したインスタンスを後から再開できる機能
• リクエスト量に応じて増減するフリートではなく、1つの専用ランタイムを利用

この仕組みは、ユーザーごとの状態、アイデンティティ、バックグラウンド処理を保持するエージェントと相性がよい設計です。一方で、大量の同時アクセスを処理する一般的なステートレスWebエンドポイントには、従来のスケール型サービスのほうが自然な場合があります。

Googleが示した料金例は月5.70ドル

Googleは、共有vCPUとバースト予算を利用し、1 vCPU・メモリ1 GiB の構成を30日間連続稼働させた場合の料金として、5.70ドル を提示しています。4

Googleが強調するメリットは料金だけではありません。専用仮想マシン（VM）を管理する場合に必要となる、VMやOSの保守、ファイアウォール管理、HTTPSエンドポイントの構築などの作業を減らせるとしています。4

ただし、この金額や製品の挙動は、Googleがプレビュー段階で示した位置付けです。実際の料金は構成、利用量、リージョン、課金設定などによって変わるため、専用VMとのコスト差を一般化することはできません。43031

また、Googleは顧客企業OffDealのコメントとして、コールドスタートが 88％減少した という結果を紹介しています。これは顧客が報告した数値であり、Googleが保証する一般的な性能や、独立したベンチマークではありません。4

AIエージェント向けインフラという大きな流れ

従来のクラウドアプリケーションでは、ステートレスなリクエスト処理と、永続データを保存するデータベースを分ける構成が一般的でした。しかしAIエージェントは、ユーザーごとの永続的なアイデンティティやエンドポイント、メモリや状態、長時間のバックグラウンド実行、ツールや運用データへのアクセスを必要とすることがあります。

今回の発表は、こうした要件にデータ層とコンピュート層の両側から対応するものです。

1. データベース層の自律性を高める：Onboarding Agentがマネージドデータベースの選定とプロビジョニングを支援し、Observability Agentがデータベース群を監視して障害を調査し、承認済みの修正を実行します。2
2. 永続性を重視したコンピュートの選択肢を加える：Cloud Run instancesが、スケールゼロやリクエスト発生時の起動を前提としない、安定したシングルトン型ランタイムを提供します。4

Google CloudのAgentic Data Cloudは、データ、AIモデル、業務データベースを、エージェントが行動するための一つのシステムとして統合する構想です。11 今回の製品は、その構想を運用面へ広げるものと見られます。

注目すべき点は、運用の自動化を進めながらも、データベース変更のように本番環境へ重大な影響を及ぼし得る操作には人間の承認を残していることです。2

実際に検討する際のポイント

今回の発表は、すべてのAIエージェントを一つのサービスで動かす「万能なエージェント基盤」を示したものではありません。対象となる課題は比較的具体的です。

• データベースの選定、初期構築、フリートの可視化、障害対応が課題なら、Database Operations Agents を検討する
• エージェントに単一で永続的な実行環境とアドレス可能なエンドポイントが必要で、一般的なサーバーレスサービスのスケールゼロモデルに合わないなら、Cloud Run instances を検討する

いずれもプレビューを前提とした機能であるため、本番利用を判断する際は、提供地域、対応構成、権限、料金、そして自動修復が実行できる範囲を確認する必要があります。それでも方向性は明確です。Google CloudはAIエージェントを、より自律的な運用機能と、より長く状態を保持できるインフラの両方を必要とするワークロードとして捉え始めています。