Google Cloudの8月発表：AIエージェントを支える「データベース運用」と「常時稼働ランタイム」

Google Cloudが2026年8月に発表した2つの新機能は、AIエージェント基盤で繰り返し問題になってきた2つの領域をそれぞれ狙っています。ひとつは、専門知識が必要になりやすいデータベースの構築・監視・障害対応。もうひとつは、リクエストが途切れてもプロセスを維持したい長時間稼働エージェントの実行環境です。231

発表されたのは、Gemini Cloud Assistと連携する Database Operations Agents と、専用の単一ランタイムを提供するプレビュー版の Cloud Run instances です。両者は置き換え関係ではなく、データ層と実行層を分担する補完的な機能といえます。

2つの新機能が解決する問題

Database Operations Agentsは、データベースのライフサイクル管理を自然言語で支援します。データベースの選定、プロビジョニング、監視、原因調査、保守までを、Gemini Cloud Assistを通じた対話型のワークフローにまとめるものです。23

一方のCloud Run instancesは、AIエージェントそのものを動かすための実行環境です。個人向けAIエージェントのように、常時利用できるプロセス、変わらないエンドポイント、長時間の対話を必要とするワークロードを想定しています。1

ここで注意したいのは、実行環境が常時稼働しても、エージェントのデータが自動的に永続化されるわけではない点です。逆に、データベース運用を自動化しても、それだけで常時稼働するエージェントの実行場所が用意されるわけではありません。

データベース運用の手作業を減らす2つのエージェント

Google Cloudは、Agentic Data Cloud戦略の一環として次の2つのエージェントを導入しました。

• Database Onboarding Agent：Day 0の作業を担当。要件に応じたデータベースの選定、セットアップ、構成、初期デプロイを支援します。
• Database Observability Agent：Day 1およびDay 2の運用を担当。監視、トラブルシューティング、継続的な保守を支援します。23

従来は、プロビジョニング用スクリプト、構成手順、監視クエリ、診断フローなどを担当者が個別に組み立てる必要がありました。これを自然言語によるガイド付き操作へ移行することで、データベース管理者、開発者、SRE、DevOpsチームの反復作業を減らすことが期待されています。

対応するデータベースサービス

Onboarding Agentは、Google Cloudのマネージドデータベースサービスである AlloyDB、Bigtable、Cloud SQL、Spanner に対応すると説明されています。29

ただし、機能がすべてのユーザーに一般提供されているわけではありません。Googleの発表では、オンボーディングとオブザーバビリティの機能はプレビューとして扱われており、Observability Agentの一部機能は、対象となる顧客やデータベースサービスを限定して提供されています。2934

複数のテレメトリーを組み合わせて原因を調査

Observability Agentの特徴は、単一のメトリクスだけを見るのではなく、複数の運用シグナルを関連付けて調査する点です。Database Insights、Cloud Monitoring、Cloud Logging、Cloud Traceなどの情報を組み合わせ、クエリのホットスポット、レイテンシーの増加、ロック競合、リソース逼迫といった問題の原因を探ります。23

調査後は、疑わしい原因や推奨される変更、その理由、見込まれる影響を説明します。対応する修正については、ユーザーが承認してから実行する仕組みです。Googleが例として挙げている操作には、Cloud SQLのコネクションプーリングの有効化やインデックスの追加があります。2344

本番環境では、この承認ステップが重要になります。データベースの変更は、局所的な性能改善に見えても、コスト、レイテンシー、ロック、アプリケーションの挙動に影響を及ぼす可能性があるためです。自動化を進めながらも、影響の大きい変更には人間の確認を残す設計になっています。

コンソールだけでなくCLIやIDE、MCPにも対応

Database Operations Agentsは、日常のクラウド運用で使われる複数の入口に組み込まれます。Gemini Cloud Assistのチャット、Google Cloudコンソールのデータベース関連ページ、Database Centerのフリートビュー、コマンドライン、IDE、サードパーティー製ツールなどから利用できます。23

また、Database InsightsとDatabase Centerの機能は、MCP（Model Context Protocol）に対応したインターフェースでも利用できます。GoogleのマネージドMCPサーバーを使えば、ユーザーがMCPサーバーのインフラを自分でデプロイしなくても、GeminiなどのMCPクライアントからデータベースやインフラ機能へ接続できます。36

これにより、外部の開発ツールや運用エージェントは、グラフィカルなコンソールに限定されず、標準化されたツールインターフェースを通じて、データベースの一覧、メトリクス、検出された問題などを取得できるようになります。

Cloud Run instancesは「スケール・トゥ・ゼロしない」専用ランタイム

Cloud Run instancesは、Cloud Run上で動く専用のシングルトンランタイムです。一般的なCloud Runサービスとは異なり、1つのインスタンスだけを実行し、自動スケールを行わず、スケール・トゥ・ゼロにもなりません。Googleはプレビュー版として、個人向けAIエージェントなど、長時間稼働する単一ユーザー向けワークロードを主な用途に位置付けています。1

主な仕様は次の通りです。

• 最大7日間、連続して実行できる
• デフォルトで自動再起動ポリシーが設定される
• 必要がないときは停止し、後から再開できる
• 更新や再起動の前後でも変わらないHTTPS URLが各インスタンスに割り当てられる1

リクエスト駆動型のサーバーレス環境では、アクセスがないとコンテナが停止し、次のリクエストでコールドスタートが発生することがあります。Cloud Run instancesは、こうした制約を次のように緩和します。

• スケール・トゥ・ゼロによる中断がない：リクエストの合間もプロセスを維持できます。
• シングルトン実行：オートスケーリングで複数コピーに増えるのではなく、専用の1コピーとして動きます。
• 安定したアドレス：更新や再起動でHTTPSエンドポイントが変わりません。
• VMより管理負担が小さい：ゲストOS、ファイアウォール、HTTPSエンドポイントなどを自分で運用せずに、持続的なプロセスモデルを利用できます。1

Googleはこれを、対象を選んだワークロードにとって、常時稼働VMの代替となり得る選択肢として説明しています。VMや、通常のオートスケール型Cloud Runサービスを全面的に置き換えるものではありません。

料金とコールドスタートのトレードオフ

Googleによると、共有vCPU 1基とメモリ1GiBのCloud Run instanceを連続稼働させた場合、料金は30日あたり 5.70ドル です。たまに発生する計算負荷の急増にはバースト予算を利用でき、すべてのピークに合わせて常時大きなリソースを確保する必要を抑えられます。1

常時稼働によってコールドスタートへの影響も小さくできます。初期ユーザーの1社は、長時間稼働するエージェントでコールドスタートが88％減少したと報告しています。ただし、これは個別の顧客事例であり、すべてのワークロードに当てはまる性能保証ではありません。1

また、5.70ドルという金額は特定構成の例です。実際の請求額には、利用するリソース、ネットワーク、ストレージ、関連サービスなどの費用が加わる可能性があります。

「常時稼働」と「永続メモリ」は別物

Cloud Run instanceがプロセスを維持できるからといって、メモリ上だけに置いたデータが、再起動、停止、ランタイムの期限切れ後も残るとは限りません。

Googleのアーキテクチャガイダンスでも、インメモリのセッション状態と外部状態管理は区別されています。インメモリ方式では、アプリケーションが再起動すると会話履歴が失われます。信頼性や拡張性が必要な本番システムでは、外部の状態管理を使うことが推奨されています。19

実運用のエージェントであれば、セッション、ワークフローの進捗、再開に必要な情報などをデータベースや別の永続ストレージへ保存する設計が必要です。Googleの長時間稼働エージェント向けガイダンスでは、本番環境でのセッション保存先としてCloud SQLなど、データベースを利用する構成が示されています。21

つまり、Cloud Run instancesが提供する「stateful（ステートフル）」とは、一定期間プロセスを維持する 実行モデル を指します。インスタンスの寿命を超えて文脈や未完了の作業を保持したい場合、永続ストレージが不要になるわけではありません。

Google Cloudが狙うエージェント基盤の全体像

今回の発表を組み合わせると、Google CloudはAIエージェントの実行とデータ運用の両面を整備しようとしていることが分かります。

1. エージェントを動かす：Cloud Run instancesで、専用の長時間稼働プロセスと安定したエンドポイントを用意する。1
2. データ層を運用する：Database Operations Agentsで、プロビジョニング、可観測性、原因調査、承認済みの修正作業を自動化する。23
3. ツールを環境横断で接続する：MCP連携により、IDE、CLI、外部ツール、別のエージェントからデータベース機能を呼び出せるようにする。36
4. リスクの高い操作には人を関与させる：Observability Agentは変更を提案できますが、対応する修正の実行には承認を求める。23

この方向性は、エンジニアリング上の判断を完全になくす「全自動のインフラ」を意味しません。むしろ、運用上の定型作業を減らしながら、アーキテクチャ、権限、永続状態、そして本番変更のガバナンスは開発・運用チームが担うという構図です。

個人アシスタント、非同期ワークフロー、複数ターンの対話型エージェントを構築するチームにとって、Cloud Run instancesは実行の継続性を補います。そのエージェントが依存するデータベースを管理するチームにとっては、Database Operations Agentsが構成、状態把握、障害対応の手作業を減らします。Google Cloudは、自然言語、テレメトリー、標準化されたツール接続を通じて、計算資源とデータ運用の双方をエージェントから扱いやすくする方向へ進んでいます。