Google、AI コスト管理を Gemini Enterprise のフロントドア機能に

Google Cloud は、Gemini Enterprise 向けに新しい請求の柔軟性とコスト管理ツールを追加し、AI 支出の管理をチームの構築およびエージェントの運用に近づけました。

エージェントのワークロードは従来の SaaS シートのように動作しないため、この変更は重要です。コーディング エージェント、サポート エージェント、またはワークフロー エージェントは、複数のモデルを呼び出し、ツールを繰り返し呼び出し、ユーザー、プロジェクト、環境全体でさまざまな使用状況を生成できます。そのため、事後的にコストを説明することが難しくなります。 Google は現在、この問題を標準のクラウド請求エクスポートに完全に任せるのではなく、Gemini Enterprise とその開発者エコシステム内の製品表面として扱っています。

Google Cloud によると、Gemini Enterprise サブスクリプションに含まれる開発者ツールの割り当ては、Google Cloud プロジェクト レベルでプールされるようになりました。同社はまた、Gemini Enterprise および Android Studio の Google Antigravity を含む、Gemini Enterprise および開発者ツール全体のエージェント ワークロードに対する課金の柔軟性の拡張についても説明しています。これとは別に、Google Cloud ドキュメントでは、Gemini API や Vertex AI からの支出を含む Gemini の使用状況を分析し、API キーごとに AI 支出を分類できる AI Cost Summary Agent について説明しています。

何が変わったのか

最も具体的な運用上の変更は、Gemini Enterprise サブスクリプションに関連付けられた開発者ツール クォータのプロジェクト レベルのプールです。組織は、個々のユーザーが個別の割り当てを消費することだけを考えるのではなく、含まれる割り当てをプロジェクト レベルで管理できます。エンジニアリング チームにとって、これは AI の作業が製品、環境、チーム、アプリケーション、または顧客対応のワークフローごとに実際に編成される方法に近いものです。

AI Cost Summary エージェントは、もう 1 つの注目すべき部分です。 Google は、Gemini API と Vertex AI にわたる Gemini の使用状況と AI 支出を分析するためのツールであると説明しています。ドキュメントには、API キーごとに支出を分類できると記載されており、これは最新の AI システムにとって重要なレベルの帰属です。 API キーは多くの場合、サービス、内部ツール、実験、テナント、またはエージェントのワークフローにマップされます。料金が値上がりしたとき、役に立つ質問が単に「どのモデルが高かったですか?」ということになることはほとんどありません。それは、「どのワークロード、キー、アプリ、またはチームが変更を引き起こしたか?」

この区別は、エージェントのワークロードにとって特に重要です。単一のユーザー要求により、計画、取得、ツール呼び出し、推論ステップ、コード実行、またはフォローアップ モデル呼び出しがトリガーされる場合があります。帰属が不明な場合、財務チームは請求書を参照し、エンジニアリング チームはログを参照し、何が起こったのかについての明確な共有ビューがどちらの側にもありません。

これがエージェント プラットフォームにとって重要な理由

AI 請求は競争力のある機能になりつつあります。 API 導入の最初の波では、モデルへのアクセスとベンチマークのパフォーマンスが購入の会話の大半を占めていました。使用が本番環境に移行するにつれて、予算、請求書、帰属、キャッシュの会計処理、プロジェクトの制限、異常検出、プロバイダーの比較など、未解決の問題はより日常的でより高価なものになりました。

Google の動きは、ハイパースケール プラットフォームが購入者が AI 製品内でこれらの制御を直接要求することを期待していることを示しています。 Gemini Enterprise は、単にモデルを使用する場所として位置づけられているわけではありません。モデルを大規模に使用することによる運用上の影響を管理する場所としての役割がますます高まっています。

これにより、市場の残りの部分に対する期待が変わります。クラウドネイティブ AI スイートがプロジェクトと API キーごとに支出を説明できるのであれば、マルチモデルのプラットフォームとゲートウェイはプロバイダー全体で少なくとも同等のことを行うことが期待されるでしょう。 OpenAI、Anthropic、Google、AWS がホストするモデル、および 1 つのアプリケーション スタックを通じてオープンウェイト デプロイメントを実行しているチームは、1 つのクラウドの FinOps レイヤーだけに依存することはできません。資産全体にわたる使用状況、モデルの選択、コストを正規化したビューが必要です。

Model Gate および同様の OpenAI 互換ゲートウェイの場合、実際の接続は直接です。統合請求と AI 使用状況分析は、もはやバックオフィスの利便性ではありません。これらは、開発者やビジネス オーナーが、どのモデルを利用可能にするか、どのチームが使用できるか、また、ワークロードのコストが高くなりすぎて設計どおりに実行できない場合を決定するために使用するコントロール プレーンの一部です。

誰が影響を受けますか

Gemini API または Vertex AI を使用するエンタープライズ開発者が最も直接的な対象者です。複数の API キー、サービス アカウント、環境、または内部エージェントを持つチームは、新しいツールを採用し、プロジェクトを適切に編成していると仮定すると、Gemini 関連の支出がどこから来ているかについてより適切なシグナルを得ることができるはずです。

財務チームと調達チームも影響を受けます。 AI のコストは、従業員数だけでなく、タスクの量やエージェントの動作によって使用量が変動するため、予測が難しい場合があります。プロジェクト レベルの割り当てプールと API キー レベルのレポートにより、内部チャージバック、予算レビュー、更新計画の手動スプレッドシート作業への依存度が低くなります。

AI 機能を構築する製品チームは、マージンという別の懸念事項を抱えています。顧客対応エージェントがプレミアム モデルを頻繁に使用する場合、またはバックグラウンド ワークフローの再試行が過剰な場合、コストがその機能に伴う収益を静かに超える可能性があります。アトリビューションを改善することで、チームは構造的な損失になる前にそれらのパターンを捉えることができます。

代理店、再販業者、マネージド サービス プロバイダーも注意を払う必要があります。顧客は、AI 機能が機能するかどうかだけでなく、その使用方法を管理できるかどうかを尋ねることが増えています。マルチモデル API 上にサービスを構築しているパートナー向けに、顧客、プロジェクト、API キー、モデルごとのコスト レポートがオファーの一部になります。

Google のアプローチの限界

未解決の問題は、これらのツールが実際に AI の総支出をどの程度削減するかということです。 AI の「ステッカー ショック」の回避に関する Google のメッセージは理解できますが、節約できるかどうかは、チームが予算を設定するか、異常に対処するか、モデルの選択を変更するか、非効率なエージェントを修正するか、ワークフローを再設計するかなど、顧客の行動に依存します。可視性は必要ですが、それは最適化とは異なります。

ロックインの問題もあります。ネイティブのクラウドコストツールは自社のエコシステム内では便利ですが、多くの企業は意図的に AI ワークロードをプロバイダー間で分散させています。 Gemini 固有または Google Cloud 中心のビューでは、他の場所で OpenAI 互換エンドポイントを呼び出したり、リージョン ルーティングに Bedrock を使用したり、オープンウェイト モデルをプライベートで実行したりするアプリケーションのコスト全体を説明できない可能性があります。

ここでもゲートウェイが価値を付加できるのです。クラウド プロバイダーは、独自のサービスの豊富な詳細を公開できます。ゲートウェイは、モデルプロバイダー、API キー、チーム、アプリ、顧客全体での使用量と請求を正規化できます。クラウド ベンダーが AI FinOps を可視化すればするほど、より多くの購入者が、使用するすべてのモデルにわたって同じ可視性を求めるようになります。

開発者が今すべきこと

Gemini Enterprise を使用しているチームは、プロジェクトと API キーがどのように構成されているかを確認する必要があります。キーがあまりにも多くのアプリや環境で共有されている場合、API キーレベルの支出レポートの有用性は低くなります。クリーン アトリビューションは、本番環境を開発環境から、顧客向けサービスを実験環境から分離し、高リスクのエージェントを通常のインタラクティブな使用環境から分離することから始まります。

開発者は、コスト データをエンジニアリング シグナルとして扱う必要もあります。モデルの支出が急増すると、非効率なプロンプト、暴走エージェント ループ、予期しない再試行、過剰なコンテキスト ウィンドウ、またはタスクに適合しなくなったモデルの選択が明らかになる場合があります。コストの遵守可能性は、損害が発生した後の毎月の請求書レビューではなく、遅延、エラー率、品質評価に属します。

Google の発表は、単なる請求に関する更新ではありません。これは、AI インフラストラクチャにおける広範な変化を反映しています。エージェントがより自律的になり、API の使用がより多様になるにつれて、支出を説明し制御する能力がコア プラットフォーム要件になりつつあります。