概要
- Google Cloud のエンタープライズ AI 提案は、もはや単なる Gemini モデル呼び出しではない。それは、Gemini Enterprise Agent Platform、Vertex AI の遺産、BigQuery、Agent Search、IAM、Cloud Audit Logs、Cloud Run、Workflows、および容量制御を統制されたワークフローに結合するオペレーティング面である。
- 受け入れ可能な出力が有用な分母である。モデルの回答は単なる一歩に過ぎず、本番の信頼性はデータの鮮度、ツールの権限、評価セット、監査ログ、クォータ設計、コスト管理、例外処理、ロールバックに依存する。
- 公開証拠は Google Cloud の制御の深さと需要を裏付けるが、すべての顧客成果を保証するものではない。Alphabet の提出書類は Google Cloud の大幅な成長とインフラ投資を示す一方、ステータスインシデントやドキュメントは、顧客が依然としてローカルな監督と復旧設計を必要とする理由を示している。
評価すべき出力は、印象的な回答ではなく、受け入れ可能なワークフローである
Google Cloud AI の最も強力なデモは、大規模なコンテキストウィンドウで回答し、データに基づいた要約を行い、エージェントがツールを呼び出し、または開発者が自然言語の要求からデプロイ可能なコードへと素早く移行することである。そのデモは重要だが、それだけではエンタープライズバイヤーが最終的に支払う本番単位ではない。重要な単位は、受け入れ可能な統制ワークフローである。すなわち、企業が保持し、監査し、繰り返すことを望む、モデルに裏付けられた回答、決定、コード変更、データ結果、顧客対応、セキュリティ推奨、または内部アクションである。
その分母は判断を変える。モデルは流暢な回答を数秒で生成できるが、古い企業データを引用したり、誤ったアイデンティティで行動したり、クォータを超過したり、モデル移行後に動作を黙って変更したり、有用な監査記録を残さなかったり、チームが元に戻せない副作用を引き起こしたりすれば、ワークフローに失敗する。受け入れ可能な出力には、要求から使用可能な結果に至るまでに必要なすべての作業が含まれる。データ準備、アクセス設計、検索の調整、評価、人間によるレビュー、例外処理、監視、コスト配分、インシデント対応、移行計画などである。
Google Cloud がこのテストに適しているのは、まさにその公的な提案がもはや単なるモデルエンドポイントよりも広範だからである。Alphabet の 2025 年年次報告書では、Google Cloud はインフラ、プラットフォーム、アプリケーション、その他のクラウドサービスを含み、AI サービスとしてエンタープライズ AI インフラ、Vertex AI、Gemini Enterprise に加えてサイバーセキュリティとデータ分析を提供すると説明されている。同じ提出書類は、Google Cloud が 2025 年に 587 億 500 万ドルの収益を上げ、2026 年第 1 四半期の Form 10-Q では、同四半期の Google Cloud 収益が 200 億 2800 万ドルで、前年比 63% 増と報告している。これはニッチな開発者向け API ではない。これは、顧客に繰り返しの作業を自社のインフラに移行させる大規模なエンタープライズクラウドビジネスである。
その規模が基準を引き上げる。もし Google Cloud が従業員、開発者、データチーム、運用グループが AI 支援の作業を受け入れるシステムになりたいのなら、顧客はフロンティア的な瞬間ではなく、日常的な反復タスクでそれを判断すべきである。アナリストが内部ポリシーに関する根拠のある質問をし、最新で、権限が正しく、レビュー可能な回答を得られるか？開発者エージェントがソース管理、テスト証拠、ロールバックを維持しながらコードを提案できるか？カスタマーサポートやセキュリティのワークフローが、十分なコンテキストとともに推奨事項を適切な人物にルーティングし、受け入れるか拒否できるようにできるか？データチームが、どのデータセット、モデルバージョン、ユーザーリクエストが回答を生成したかを把握できるか？これらは本番の問いである。モデル能力だけでは答えられない。
法的・ブランド的境界は表面的ではない
対象となる企業は Google Cloud であり、Google がインフラ、データ、セキュリティ、コラボレーション、エンタープライズ AI サービスのために運営するクラウド事業である。それを Google 検索、コンシューマー向け Gemini 利用、DeepMind の研究発表、YouTube、Android、あるいはたまたま Google モデルが関与するすべてのパートナーや顧客の成果と同一視してはならない。ここでは Alphabet 自身のセグメント言語が重要である。Google Cloud は Google Cloud Platform と Google Workspace を含み、GCP サービスにはインフラ、プラットフォーム、エンタープライズ AI インフラ、Vertex AI、Gemini Enterprise、サイバーセキュリティ、データ分析が含まれる。これが本記事の運用上の境界である。
この境界は、分析を容易な間違いからも守る。Google は世界クラスのモデル研究を行っているが、Google Cloud を購入する顧客は、すべてのモデルのブレークスルーが安定した受け入れ可能なワークフローになるという直接的な保証を受け取るわけではない。研究の進歩は生の回答を改善し得る。統制されたワークフローは依然としてクラウド製品の表面に依存している。IAM ロール、リージョン可用性、ログのデフォルト、データコネクタ、クォータ、モデルのライフサイクル通知、サポート契約、SLA、課金、変更管理などである。DeepMind モデルの結果と Google Cloud の本番成果は関連しているが、同じ証拠ではない。
境界は逆方向にも作用する。顧客事例で、Replit が Vertex AI 上で Claude を実行したり、Fifth Dimension が Gemini と Claude の推論を Vertex AI 内で一元化したりする場合、その証拠は一部、マネージドなマルチモデルコントロールプレーンとしての Google Cloud に関するものであり、Gemini だけではない。この区別は商業的に重要である。顧客は、Google Cloud を選択することで、Google モデル、パートナーモデル、BigQuery、Cloud Run、クラウドセキュリティ制御を単一のアーキテクチャ内で組み合わせられるからかもしれない。また、それらと同じ制御が出力受容プロセスの一部となるため、スイッチングコストに直面する可能性もある。
だから、製品の問いは「Gemini は優れているか？」ではない。「Google Cloud は、総コストを計算した後もビジネスが出力を繰り返し受け入れるほど、モデルに裏付けられた作業を統制可能にできるか？」である。Gemini の品質は一つの入力に過ぎない。クラウドの制御表面こそが製品である。
Google Cloud は制御面を販売している
Google の最新のドキュメントは、Gemini Enterprise Agent Platformを、エンタープライズグレードのエージェントシステムとモデルベースのソリューションを構築、デプロイ、統制、最適化するための統合プラットフォームとして説明している。ライフサイクル概要では、ライフサイクルを構築、スケール、統制、最適化に分割している。そこでは、ローコードの Studio、コードファーストの Agent Development Kit、Model Garden へのアクセス、マネージドランタイム、セッション管理、Memory Bank、一意のエージェントアイデンティティ、Agent Registry、Agent Gateway、Gen AI 評価、Cloud Observability、Topology が挙げられている。
この一覧は示唆的である。Google Cloud が、エンタープライズ AI が単なる推論ではないことを認識していることを示している。モデルをホストする同じプラットフォームが、誰がまたは何が行動しているのか、どのツールが承認されているのか、どのデータが対象範囲内か、回答が評価されたかどうか、アクションが観察可能かどうか、ランタイムがどのようにデプロイされるのかにも答えなければならない。したがって、有益な比較対象は OpenAI、Anthropic、Microsoft、AWS、あるいはオープンソースモデルだけではない。それは顧客の既存のワークフローである。手動のアナリストプロセス、既存の SaaS ワークフロー、データウェアハウスと BI スタック、チケットキュー、自家製のエージェントフレームワーク、または自動化を減らすというリスクの低い決定である。
公開プラットフォームの構成要素は、本番の問いに自然に対応する。Agent Registryは、承認された AI コンポーネント、MCP サーバ、エンドポイントを一元化し、ツールアクセスがバラバラの実験に散らばらないようにする。Agent Gatewayは、レジストリメタデータ、エージェントアイデンティティ、ポリシー制御を使用しつつ、インタラクションの可観測性テレメトリを生成する。Agent Identityは、SPIFFE に基づく強力に証明されたアイデンティティをエージェントに付与し、ドキュメントには、デフォルトではアイデンティティが複数のワークロードで共有されず、長期間有効なサービスアカウントキーを生成できないと記載されている。
これらの制御が重要なのは、エージェントシステムがチャットボットとは異なる方法で失敗するからである。チャットボットはテキストで間違うことがある。エージェントは、データを読み取り、ツールを呼び出し、チケットを更新し、コードを書き、デプロイをトリガーし、または他のサービスに指示を渡しながら間違う可能性がある。制御面は、提案とアクションの違いを保持しなければならない。また、誤った前提が言語から本番の状態に移行したときに何が起こったかの永続的な痕跡を保つ必要がある。
Google Cloud の利点は、周辺の多くがすでにそのクラウド資産内に存在することである。IAM、Cloud Audit Logs、BigQuery、Cloud Run、Workflows、Cloud Monitoring、VPC Service Controls、課金は、別個の趣味のプロジェクトからのアドオンではない。それらは、AI ワークフローに持ち込むことができる確立されたクラウドプリミティブである。弱点も同じである。顧客が統合ルートを採用すると、受容出力チェーンはクラウドプラットフォームの複雑さ、コストモデル、障害モードを継承する。
データグラウンディングが最初の信頼性の問題である
ほとんどのエンタープライズ AI 作業は、モデルに到達する前に失敗する。データは不完全、古い、過剰な権限、不十分な説明、重複、リージョン制約、あるいは SaaS システムやウェアハウスに散在している。単独では強力なモデルでも、検索システムが昨日のポリシー、古い顧客記録、ユーザーが見るべきでないファイル、あるいは系統なしで意味が変わったテーブルを提供すれば、受け入れられない回答を生成し得る。
Google Cloud はこの問題に対して信頼できる素材を持っている。Agent Search によるグラウンディングは、Gemini が Agent Search を通じて Web サイトやドキュメントデータに接続することを可能にする。このページでは、IAM 権限、AI アプリケーションの有効化、データストアの作成などの前提条件が説明されており、顧客データへのグラウンディングには最大 10 個の Agent Search データソースを使用できるとしている。別のAgent Search 製品ページでは、このサービスをエンタープライズデータ向けのマネージド RAG システムとして位置づけ、引用、リンク、データソース制御、コネクタについて説明している。
これは構築コストの大幅な削減である。チームは、すべての取り込み、OCR、チャンク化、埋め込み、インデックス作成、検索、引用コンポーネントを手作業で組み立てる必要がなくなる。しかし、管理されたグラウンディングは、受け入れ可能な回答が何に対してグラウンディングされるべきかを決定する作業を排除するわけではない。最大データソース数は設計上の制約である。Jira、SharePoint、Salesforce、またはドキュメントストアを読み取るコネクタは、それらのシステムの鮮度、権限、セマンティクスに依存する。公式ポリシーとドラフトポリシーの両方がストアに存在する場合、モデルは、検索層と指示層がそのガバナンスを保持していない限り、どちらが権威あるものかを知ることができないかもしれない。
BigQuery は第二の層を追加する。そのデータガバナンスドキュメントには、Knowledge Catalog、メタデータ発見、データ品質、データプロファイリング、系統、IAM、行レベルおよび列レベルのアクセス制御、VPC Service Controls、監査ログ、マスキング、暗号化、共有制御、クリーンルーム、使用量メトリクスが記述されている。これらは、データチームがウェアハウスコンテキストからモデルに裏付けられた結果を受け入れる前に必要とする種類の制御である。また、それらは労力を追加する。誰かが用語集の用語、所有者、品質ルール、マスキングポリシー、アクセス権限、系統の取り込み、使用量監視を定義しなければならない。この作業は、プライベートなデータガバナンススタックをゼロから構築するより安価かもしれないが、無料ではない。
データガバナンスは、総コストの比較が具体的になる場所でもある。手動のアナリストはドキュメントを見つけるのに何時間も費やすかもしれないが、どのソースが信頼できるかを知っている。クラウドグラウンディングされたエージェントは数秒で回答するかもしれないが、回答が受け入れられるほど安全になるまでに、数週間の権限クリーンアップとデータストアの調整が必要になるかもしれない。問いは、Google Cloud がデータを取得できるかどうかではない。顧客が、通常のビジネス変更の速度で、検索面を正確かつ権限が正しい状態に保てるかどうかである。
プライバシーコミットメントは役立つが、保持と地理は依然として設計が必要
Google Cloud の公的なコミットメントは、エンタープライズバイヤーにとって、コンシューマー AI 利用よりも強力な出発点を提供する。Google Cloud のサービス固有条件には、Google は顧客の許可または指示なく、顧客データを AI/ML モデルのトレーニングやファインチューニングに使用しないと記載されている。Agent Search データガバナンスページも同様に、Agent Search で使用される顧客データは基盤モデルのトレーニングに使用されず、基盤モデルは凍結されており、サービスへの出力を提供するために入力を処理すると述べている。
これは重要である。これは、取締役会レベルの最初の質問の一つに対処する：会社の入力リクエスト、取得したドキュメント、出力が他者のモデルトレーニングデータになっているかどうか。また、Google Cloud エンタープライズ AI を、より制御の少ないコンシューマー利用と区別するのにも役立つ。
しかし、プライバシーに関する一文がガバナンス設計のすべてではない。ゼロデータ保持ドキュメントには、Google が許可なく顧客データをマネージドモデルのトレーニングやファインチューニングに使用しないとしつつ、不正使用監視やグラウンディングモードなど、保持動作が異なる可能性があるシナリオや、顧客が例外を要求したり、別の条件を理解したりする必要がある場合についても説明している。Google 検索とマップによるグラウンディングは独自の保持文言を持つ。これによってプラットフォームが安全でなくなるわけではない。顧客は、有効にする各機能を、公開してもよいと考えるデータクラスと、処理される可能性があるリージョンに対応付ける必要があることを意味する。
リージョンの問題も同様である。グラウンディングドキュメントには、AI アプリケーションがグローバル、EU、US のマルチリージョンで利用可能とある。データローカリティルールの下で活動する企業は、すべての AI 機能、モデル、コネクタ、ログ、サポートパスが同じ地理的特性を持つと仮定できない。データ主権はめったに単一のスイッチではない。モデルの場所、データストアの場所、ログ、サポートアクセス、バックアップ、監視、サードパーティモデル利用、従業員アクセスの連鎖である。
この連鎖は調達を変える。Google Cloud、他のクラウドプロバイダー、既存の SaaS AI 機能、自社環境のオープンソースモデル、または自動化を減らすことの間で選択する企業は、スローガンではなく、データパスの証拠を比較すべきである。Google Cloud には適切な制御プリミティブの多くがある。バイヤーは、選択した機能セットが自社のローカリティ、保持、監査義務に適合することを証明しなければならない。
権限がエージェントを有用にするか危険にするかを決める
回答からアクションへの移行はアイデンティティに依存する。要約しかできないモデルはテキストによって制限される。プライベートデータの読み取り、API の呼び出し、チケットの作成、コードの変更、顧客記録の変更、ワークフローの開始、デプロイのトリガーが可能なモデル支援エージェントには、デモの熱意よりも狭い権限モデルが必要である。
Google Cloud のドキュメントは、顧客にいくつかの有用なプリミティブを提供する。Agent Platform IAM ドキュメントは、アクセスをプロジェクトレベルまたはリソースレベルで管理でき、チームが必要な権限のみにアクセスを制限する必要がある場合はカスタムロールを推奨すると述べている。Agent Identityは、エージェント自体をプリンシパルにし、すべてのアクションを共有サービスアカウントの背後に隠さないようにする。Agent Gatewayは、認可の決定とポリシーの強制にアイデンティティとレジストリメタデータを使用する。
これらの制御は、顧客が規律を持って使用する場合にのみ価値がある。どのプラットフォームでも最も抵抗の少ない道は、パイロット中は広範なアクセスである。すなわち、1 つのサービスアカウント、1 つの寛容なロール、多数のツール、そして後で絞り込むという約束である。それはサンドボックスでは許容されるかもしれないが、受け入れ可能なワークフローにとっては誤ったパターンである。統制されたワークフローには、アクションクラスごとに別々のアイデンティティ、ユーザーまたはタスクに従うデータソース権限、最大許容影響範囲に一致するツールスコープ、エージェント、ユーザー、ターゲットを識別するログが必要である。
設計はまた、読み取り、提案、実行を区別する必要がある。ポリシーを読み取り、応答を草案するエージェントが、自動的にその応答を送信する権限を持つべきではない。コード変更を推奨するエージェントが、自動的にそれをマージすべきではない。顧客の問題を分類するエージェントが、承認ルール、ポスト条件チェック、復旧パスなしに自動的にアカウント記録を変更すべきではない。AI ワークフローの信頼性のポイントは、すべての機械のアクションを防ぐことではない。各アクションの権限を読み取り可能で限定的にすることである。
ここで Google Cloud の統合された資産が役立つ。Cloud IAM、サービスアカウント、リソースレベルのポリシー、VPC Service Controls、監査ログはクラウドセキュリティチームにとってなじみ深い。しかし、ガバナンス対象はシフトした。プリンシパルは今やエージェントかもしれず、データは直接のデータベースクエリではなく検索コンテキストかもしれず、出力はビジネスアクションになるかもしれない。セキュリティチームは、エージェントの権限を本番特権として扱うべきであり、リクエスト作成設定として扱うべきではない。
評価は機能であり、判断の代わりではない
Google Cloud は評価をプラットフォームのストーリーの一部にしたことで称賛に値する。Gen AI 評価サービス概要は、生成 AI モデルおよびモデル移行、リクエスト文言の変更、ファインチューニングなどのユースケースに対して、客観的でデータ駆動型のアセスメントをサポートすると述べている。適応型ルーブリックを、ソフトウェア開発の単体テストと同様に、個々のリクエストに対するカスタマイズされた合格/不合格テストとして説明している。エージェント評価ドキュメントは、この考えをタスクや目標を達成するエージェントの能力に拡張している。
これは正しい方向である。企業は AI 評価を一度限りのベンダーコンテストとして扱うのをやめる必要がある。統制されたワークフローでは、受け入れ可能な出力に対する反復的なテストが必要である。回答は承認されたソースを使用したか、ロールの境界を守ったか、十分な証拠を含めたか、データがない場合は拒否したか、ツール呼び出しを完了したか、危険な下流フォーマットを回避したか、レイテンシとコストの目標内にとどまったか、復旧ルートを保持したか？
しかし、評価ツールは真実のセットを作成しない。顧客は依然として、良い回答とは何かを定義し、代表的なケースを収集し、エッジケースをラベル付けし、合格/不合格のしきい値を決定し、否定的な例を含め、指示注入をテストし、古いデータをテストし、権限の不一致をテストし、ビジネスの変更時にスイートを更新しなければならない。企業が、人間がベンダーリスク要約を受け入れ可能かどうかをどのように判断するかを文書化したことがなければ、モデル評価サービスはポリシー全体を推論できない。組織が標準を提供すれば、テストを運用化できる。
評価コストはまた、野心に応じて増大する。単純な要約フローは、少数の例と手動のスポットチェックで済むかもしれない。コードを書き、データウェアハウスを読み取り、顧客に連絡し、またはコンプライアンス記録を更新する統制されたエージェントは、より深いテストを必要とする。アクション固有のポスト条件、モデルバージョン間のリグレッションチェック、敵対的な指示、コストとレイテンシの予算、不確かなケースに対する人間のレビューが必要である。ワークフローが価値があればあるほど、受け入れ証拠は高価になる。
そのコストは依然として支払う価値があることが多い。評価のない手動レビューはスケーラビリティが低く、ドリフトを見逃す。既存の SaaS ツールは自社のモデル動作を隠すかもしれない。内部スタックは、すべてのコンポーネントがローカルで組み立てられるため、評価の負担をさらに増やす可能性がある。Google Cloud の評価サービスはインフラ作業を削減できる。何が受け入れ可能かを決定する組織的な作業を取り除くわけではない。
監査ログはブラックボックスを記録に変えるが、有効にして読まれる場合に限る
監査可能性は、スタンドアロンのモデル呼び出しに対する Google Cloud の最も明確な利点の一つである。Agent Platform 監査ログには、Google Cloud サービスが、誰が何をどこでいつ行ったかを回答するのに役立つ監査ログを書き込むとある。管理者アクティビティログは無効にできない。システムイベントログは、リソースを変更する自動化された Google Cloud アクションを識別し、同様に無効にできない。データアクセスログにはユーザー提供データの読み取りと書き込みが含まれるが、ドキュメントでは明示的に有効にする必要があるとされている。
データアクセス監査ログの有効化に関する別のページは見落としやすく、極めて重要である。そこには、顧客がモデルエンドポイントの使用に関する監査ログを取得するためにこれらのログを有効にする必要があり、data_accessストリームを表示するには Private Logs Viewer が必要であると書かれている。一般的なCloud Audit Logs 概要では、BigQuery 以外のデータアクセスログはデフォルトで無効になっており、これはログが大きくなる可能性があり、料金が発生する可能性があるためと付け加えている。
これは実際的なガバナンスのトレードオフである。完全なログ記録は証拠を生成するが、コスト、保持に関する質問、アクセス制御の質問、レビュー作業も生成する。チームが適切なログを有効にしないと、どのリクエスト、エンドポイント、データソース、アイデンティティ、ツール呼び出しが受け入れ可能な出力につながったかを再構築できないかもしれない。ルーティングと保持の規律なしにすべてを有効にすると、ほとんど誰も検査しない大量の機密性の高いログを生成する可能性がある。監査可能性はチェックボックスではない。それはデータ製品である。
受け入れ可能な AI ワークフローでは、最小限の記録には、作業を要求したユーザーまたはサービス、エージェントアイデンティティ、モデルとバージョン、検索ソース、ツール呼び出し、権限の決定、評価結果またはレビューステップ、最終的な受け入れ出力、および下流のアクションが含まれるべきである。Google Cloud はこのチェーンのいくつかの部分を文書化しているが、エンドツーエンドの記録は製品の境界を越える。顧客は、Cloud Logging、アプリケーションログ、BigQuery ジョブメタデータ、Agent Gateway テレメトリ、ソース管理記録、チケット履歴、ビジネスシステムの監査証跡を必要とするかもしれない。
商業的な含意は単純である。監査レビューを無視した節約は過大評価である。モデルが草案作成を 20 分節約しても、証拠検査に 10 分かかるなら、受け入れ可能な出力の節約は 20 分ではない。ログ記録が高コストなエラーを一つ防げば、経済性は依然として優れているかもしれない。会計にはレビュー作業を含めなければならない。
バージョンドリフトは信頼性のコストである
AI システムは、従来のエンタープライズワークフローよりも頻繁に変化する。モデルはリタイアし、エンドポイントは非推奨となり、安全性フィルタは変更され、コンテキストウィンドウは拡大し、レイテンシプロファイルは変化し、価格は変わり、パートナーモデルは現れたり消えたりする。Google Cloud のモデルバージョンとライフサイクルのページは、これが実際の運用上の懸念であるため存在する。Gemini および埋め込みモデルのライフサイクル条件を定義し、日付を提供し、アップグレードを推奨し、移行パスを示している。リリースノートは本番更新、機能、既知の問題、非推奨の機能性を文書化する。
運用上の問いは、変化が起こるかどうかではない。受け入れられた作業を壊す前に変化が可視化されるかどうかである。一般的な推論を改善するモデル移行でも、トーン、拒否動作、出力スキーマ、引用スタイル、トークンコスト、ツール呼び出し頻度が変化する可能性がある。グラウンディングの変更は、あるコーパスでは検索を改善し、別のコーパスでは悪化させるかもしれない。安全性フィルタの更新は、正当な内部セキュリティタスクをブロックするかもしれない。非推奨通知は、多忙な四半期中に移行を強制するかもしれない。
Google Cloud はライフサイクル情報と評価ツールを公開することで支援できる。顧客には依然として移行の規律が必要である。受け入れられたすべてのワークフローは、可能な限りピン留めまたは宣言されたモデルパス、リグレッションスイート、代表的なデータセット、変更ウィンドウ、ロールバックまたはフォールバックオプション、リリースノートを監視する所有者を持つべきである。ワークフローが Vertex AI を通じてパートナーモデルを使用する場合、顧客はそのパートナーのモデルライフサイクルと条件にも依存する。マルチモデルの選択は単一モデルへの依存を減らすが、テスト作業を増やす可能性がある。
これが、受け入れ可能な出力の分母が有用である理由の一つである。単一のモデル呼び出しは安価に見えるかもしれない。統制されたワークフローには将来の移行が含まれる。顧客がモデルの変更をテストする余裕がないなら、影響の大きい作業を深く自動化すべきではない。ワークフローが十分に価値があれば、反復的な評価と移行計画が製品の実際のコストの一部となる。
容量とインシデントが信頼性を設計上の選択にする
Google Cloud はエンタープライズ AI を提供するインフラ規模を持つが、顧客は規模を無限の容量と混同すべきではない。Alphabet の 2026 年第 1 四半期の 10-Q は、Google Cloud 関連の残存履行義務が 4,623 億ドルであり、大規模な技術インフラ投資を行っていると報告している。また、2026 年第 1 四半期の資本支出は 357 億ドルであり、Alphabet は 2025 年に対して技術インフラ投資を増やすと予想していたと述べている。この規模は需要とコミットメントを示すシグナルである。また、AI 容量が資本集約的であることも示している。
製品レベルでは、Google Cloud はいくつかの消費と容量の概念を公開している。Provisioned Throughput 概要は、サポートされている生成 AI モデルに対し、モデルとロケーションごとにスループットを予約する固定費の固定期間サブスクリプションについて説明している。リアルタイムの本番アプリ、持続的に高スループットの重要なワークロード、予測可能なユーザーエクスペリエンス、確定的なコストのためにこのオプションを検討することを推奨している。クォータドキュメントには、リージョンとモデルの制限、Agent Runtime クォータ、評価クォータ、バッチ動作がリストされている。Gemini バッチ推論は共有プールを使用し、容量圧力時に作業がキューイングされる可能性があると注意されている。
これらの詳細は調達の些事ではない。それらはワークフローが信頼できるかどうかを形作る。少数の内部スタッフが使用するカスタマーサポートエージェントは、ピーク時の対顧客クレームシステムよりも PayGo の変動に耐えやすい。夜間の評価バッチは、結果が明日必要ならキューイングできるが、1 時間以内のデプロイのゲートとなる場合にはできない。厳格なレイテンシ目標のあるワークフローには、Provisioned Throughput またはフォールバックパスが必要かもしれない。モデル支援の作業は、パイロット中には予測が難しいトークン、検索、ログ記録、レビューのコストを生み出す可能性があるため、確定的なコストは確定的なレイテンシと同じくらい重要かもしれない。
ステータスインシデントも同じことを示している。2026 年 2 月 27 日、Google Cloud はVertex AI Gemini API インシデントを報告し、これは 1 時間 58 分続き、グローバルエンドポイントと米国リージョンに影響した。報告された根本原因は、Gemini モデルをサポートする安全性フィルタリングサービスへの設定変更であり、過負荷エラーが発生。修正にはロールバック、容量追加、検証チェックポイントの強化、アラートの改善が含まれた。2025 年 7 月 18 日には、us-east1 マルチプロダクトインシデントが発生し、ハードウェアワークフロー/コントロールプレーンの問題後、Cloud Run、Cloud Workflows、BigQuery、IAM、Cloud Monitoring、Vertex AI Online Prediction、VPC などの製品に影響した。
これらのインシデントは、Google Cloud が異常に信頼性が低いことを証明するものではない。統制された AI ワークフローが共有サービスに依存していることを証明するものである。モデル API、安全性フィルタ、リージョン、ネットワーク、IAM、監視、オーケストレーション、データプラットフォームである。回復力のあるワークフローは、古いデータルール、再試行ルール、フォールバックモデルまたはキュー、デグレデッドモードメッセージ、緊急作業用の手動ルート、プラットフォーム障害とモデル障害を区別する方法を必要とする。エンドポイントがレート制限されている間も、モデルは能力を発揮できるかもしれない。ワークフローランナーが故障している間も、データは正しいかもしれない。IAM やネットワークパスが損なわれている間も、エージェントは健全かもしれない。
したがって信頼性は、部分的に製品の機能であり、部分的にアーキテクチャの選択である。Google Cloud は SLA と容量オプションを提供する。どのタスクが予約スループット、マルチリージョン設計、手動フォールバック、またはより低い自動化に値するかは、依然として顧客が決定する。
ロールバックは、受け入れられたビジネス状態よりもコンピューティングの方が容易である
Google Cloud には、ソフトウェアインフラ向けの成熟したデプロイ制御がある。Cloud Runでは、チームがトラフィックを分割し、リビジョンを段階的にロールアウトして、以前のリビジョンにロールバックできる。ドキュメントはまた、トラフィックの変更は瞬間的ではなく、移行中は進行中のリクエストが継続すると警告している。Workflowsは、try、retry、例外処理構造をサポートしている。
これらは AI アプリケーションにとって有用な制御である。チームは新しいエージェントサービスを少数のトラフィックにデプロイし、エラーを監視し、動作が悪ければコンテナをロールバックできる。一時的な HTTP 障害を捕捉し、選択した呼び出しを再試行し、例外パスに分岐できる。失敗したワークフローをチケットにルーティングし、アクションが完了したふりをしないようにできる。
しかし、ビジネスのロールバックはインフラのロールバックよりも難しい。エージェントが回答を草案し、人間がそれを送信していなければ、ロールバックは簡単である。草案を破棄すればよい。エージェントが CRM フィールドを更新したり、コンプライアンスフォームを提出したり、ポリシーを変更したり、メッセージを送信したり、返金を承認したり、サポートケースを開いたり、コードをマージしたりした場合、副作用はモデルエンドポイントの外に存在する。Cloud Run のリビジョンをロールバックしても、メッセージが未送信になったり、従来の顧客の理解が回復したりするわけではない。下流のアクションがべき等でなければ、再試行が一時的な障害を悪化させる可能性がある。
ここで、受け入れ可能な出力のテストが厳格になる。すべてのアクションクラスには、ポスト条件と復旧パスが必要である。コード変更のワークフローには、ソース管理の証拠、テスト、デプロイのロールバック、問題の所有権が必要である。データ結果のワークフローには、クエリの系統、データセットのバージョン、データ品質チェック、修正手順が必要である。顧客アクションのワークフローには、承認しきい値と、後で受け入れられた回答が誤りと判明した場合に顧客に通知する方法が必要である。セキュリティまたは運用のワークフローには、人間による上書きと、誤ったブロックを解除するパスが必要である。
Google Cloud は多くの低水準の制御を提供できるが、顧客のビジネスの逆操作を定義することはできない。プラットフォームは顧客が再試行を構築できるようにするが、アクションの再試行が安全かどうかを知ることはできない。プラットフォームはリクエストをログに記録できるが、ワークフローが宛先を確認しない限り、下流システムが意図した状態に到達したことを保証できない。負担は設計に移る。
顧客の事例は採用を示すが、普遍的な答えではない
Google Cloud の顧客事例は、バイヤーが試みているワークフローの種類を示すため、有用な市場シグナルである。それらは独立したベンチマークとして読まれるべきではない。
FletcherTechは、3 週間で Gemini Enterprise をコアデータにデプロイし、3 か月間で 222 人の従業員に 31,778 件の回答を提供し、2,500 時間以上を節約したと報告した。この事例では、データコネクタ、Jira、ServiceNow、SharePoint、カスタム AI アシスタント、およびリソース、アクセス、コストのガバナンスのための専用 Google Cloud プロジェクトが挙げられている。これは受け入れ可能な出力のテーマに近い。価値はアシスタントだけではなく、日常のシステムと制御への統合にある。
Fifth Dimensionは、Vertex AI を使用して、ドキュメントが多い商業用不動産ワークフローのために Gemini と Claude の推論を一元化し、スタックには Cloud SQL、Cloud Storage、Cloud Run、BigQuery が含まれると報告した。この事例では、長時間実行ワークフローと報告された 99.9% の信頼性目標が説明されている。これは、Gemini のみの環境というよりも、マルチモデルワークフロープラットフォームとしての Google Cloud の有用な例である。
Replitは、Vertex AI 上の Claude、Gemini、Cloud Run、Compute Engine、Cloud SQL、BigQuery を使用して、AI によるソフトウェア作成とデプロイをサポートしていると報告した。この事例では、Replit が 3,500 万人以上の開発者と 100,000 以上のアプリケーションを Cloud Run を通じてサポートしていると述べている。ここでも教訓はアーキテクチャにある。エージェントはデプロイ、データ、インフラに接続されている。
限界も同様に重要である。これらの事例は、完全な例外率、誤った受け入れ出力、人間のレビュー時間、ロールバック時間、移行作業、失敗したリクエスト、データクリーンアップのコスト、エンドポイントが劣化したときに何が起こったかを開示していない。それらはプロモーションだから役に立たないわけではない。採用の証拠として読めば有用である。それらは顧客が実際の作業を Google Cloud AI 表面に移行していることを示すが、すべての企業が監督と統合コストの後にコストを節約できることを証明するものではない。
商業的なケースは総作業量の削減にかかっている
Google Cloud の商業的なケースが最も強力なのは、タスクが反復的で、証拠が豊富で、権限が境界づけられており、より良いツールが手作業に勝るほど高価である場合である。良い候補には、承認されたソースに基づいた内部ナレッジ回答、テストとレビュー付きの初稿コード変更、ドキュメントが多いデータ抽出、サポートトリアージ、セキュリティのエンリッチメント、統制された分析、受け入れ可能な出力が外部世界を変更する前にチェックできるワークフロールーティングが含まれる。
タスクがまれで、あいまいで、責任が重く、文書化が不十分で、アクセスできないシステムに散らばっているか、暗黙の人間の判断に依存している場合、ケースは弱くなる。そのような場合でも、モデルは草案作成や調査には役立つかもしれないが、受け入れ可能なワークフローはほとんど人間のままかもしれない。自動化を減らすことは合理的であり得る。月に 2 回しか発生せず、間違った場合に深刻な結果を招くタスクに自律エージェントは必要ない。
代替案のセットは広範である。手作業はプラットフォーム依存性が低いが、人件費が高く、証拠が一貫しない。既存の SaaS AI は、ドメイン統合に優れているが、システム間ガバナンスやモデルの選択が弱い可能性がある。他のクラウド/モデルプロバイダーは、より良いモデル性能やエコシステム適合性を提供するかもしれないが、異なるデータとアイデンティティ統合が必要である。オープンソースはベンダーロックインを減らし、制御を改善する一方で、ホスティング、セキュリティ、評価、運用の作業を増やす。社内スタックはカスタマイズできるが、希少なプラットフォームエンジニアリングを要求する。Google Cloud の売りは、統合された AI、データ、アイデンティティ、デプロイ、ログ記録面が中道のコストを下げるという点である。
スイッチングコストは最初から計算されるべきである。顧客が Google Cloud を中心にデータストア、評価スイート、IAM ロール、Cloud Run サービス、Workflows、BigQuery 系統、監査ルート、ダッシュボード、サポートプロセスを構築すれば、一貫性を得るが、移植性を失う。ライバルモデルは Vertex AI または別のプロバイダーを通じて呼び出せるかもしれないが、受け入れ可能な出力システムはモデル以上のものである。それにはログ、権限、評価器、データ契約、デプロイパターンが含まれる。
それは Google Cloud を避ける理由ではない。それは出口レーンを設計する理由である。評価データセットを移植可能なフォーマットで保存する。可能な限り、ビジネスルールを自由形式の指示の外に置く。モデルアダプタをワークフローロジックから分離する。ソースドキュメントと出力スキーマを追跡する。監査記録を単一のコンソール外で読み取り可能にする。最善の顧客成果はゼロロックインではない。Google Cloud がプロセスを閉じ込めるのではなく、作業を減らすことでワークロードを獲得するほどのモジュール性である。
真剣なバイヤーが問うべきこと
購買の問いは、運用テストとして書かれるべきである。一つの反復タスクについて、受け入れ可能な出力は何か、誰がそれを受け入れるか、どのような証拠が必要か、どのデータが使用され得るか、どのようなアクションが続くか、そしてそれが誤っていた場合に何が起こるか。この声明がプラットフォーム決定に先行すべきである。
特に Google Cloud については、バイヤーは、ワークフローが Gemini Enterprise の従業員向けアシスタントエクスペリエンス、Agent Platform の構築とガバナンス面、Agent Search のグラウンディング、BigQuery ガバナンス、Cloud Run デプロイ、Workflows オーケストレーションのいずれか、またはすべてを必要とするかどうかを問うべきである。タスク定義なしにすべての部品を購入することは、信頼できるワークフローではなく、プラットフォームプログラムを生み出す。少なすぎる購入は、統制できないモデルデモを生み出す。
バイヤーはまた、どのデータアクセスログが有効になるか、誰がそれらを見ることができるか、それらがどこに保持されるか、どのようなレビュープロセスがログを監督に変えるかを問うべきである。どのアクションが人間の承認を必要とし、どれが自動的に実行され得るか、どれが決して委任されるべきでないかを決定すべきである。最初のモデルバージョンが変わる前に、モデル移行計画を規定すべきである。成功したパイロットが多忙な製品になる前に、クォータとスループットルールを定義すべきである。エンドポイントエラーや古い検索のためのフォールバックを作成すべきである。OWASP の LLM リスクリストは、モデル出力をツールに渡すシステムにとって理論的なものではないため、指示注入と安全でない出力処理をテストすべきである。
最後に、バイヤーは人間の分母を見えるままにすべきである。週に何件の受け入れ可能な出力が期待されるか？何件が拒否されるか？レビューにはどれくらい時間がかかるか？エージェントはどのくらいの頻度で明確化を求めるか？受け入れ後に修正が必要な出力はどれくらいか？データ所有者はどのくらいの頻度でコーパスを更新するか？モデル移行とログ記録に何時間のエンジニアリング時間が費やされるか？これらの数値が収集されなければ、組織は生産性ではなく興奮を測定することになる。
Google Cloud は企業に、統制された AI ワークフローのための本格的な制御面を提供する。モデル、データ資産、アイデンティティ機構、デプロイ層、ログ、評価サービス、商業的規模を備えている。未解決のテストは、顧客がそれらの部品を使用して、監督を計算に入れた後、総作業量を削減できるかどうかである。勝者はデモで最も速く回答するプラットフォームではない。受け入れられた出力が、100 回目の通常の実行後も有用で、説明可能で、権限が正しく、回復可能であり続けるプラットフォームである。