2026年8月の振り返り：AI支出を明細化、CloudFlowが真のマルチクラウドへ、Kubernetesにガードレール

AIの実際のコストを把握する

どの新しい連携でもパターンは同じです。アカウントを接続すると、そのプロバイダーにとって重要なディメンション付きでコストがCloud Analyticsに表示され、予算、アラート、配分、異常検知にすぐ使えます。

• OpenRouter。 モデル別・ホスティングプロバイダー別の請求コストを表示。レイテンシーや価格の都合で1つのワークロードを3つのプロバイダーに振り分けている場合でも、コストがどのルートに流れたのかを確認できるようになりました。
• xAI。 Grok APIのコストをモデル別、使用タイプ別、APIキー別に把握。APIキーのディメンションは多くのチームが求めていたものです。支出をサービスに紐付ける手がかりになるからです。
• Fireworks AI。 モデル別、デプロイメントタイプ別、GPU別のコストと使用量。予算設定とアトリビューションにも対応します。専用デプロイメントとサーバーレスを並べて確認できます。
• SnowflakeとDatabricks、より深いアトリビューション。 GenAI Intelligenceで、個々のSnowflakeクエリからDatabricksのワークロードまで、誰がどのAI製品にいくら使っているかを表示。共有ウェアハウスでも、チーム単位の答えが得られます。
• Anthropicの支出レポート、手動変換は不要に。 DataHubのスキーマテンプレートがプロバイダーネイティブのCSVファイルを直接取り込みます。Anthropicコンソールからエクスポートしてアップロードするだけで完了です。
• セルフホスティングの疑問に、データで答える。 compute.doit.comが「オープンモデルをセルフホストすべきか、トークン課金を続けるべきか」という判断を3つの方法でシミュレーションできるようになりました。デプロイメントのサイジング、既存ハードウェアの価値評価、またはAnthropicやOpenAIの請求書を貼り付けて、同等性能のオープンモデルに置き換え可能な部分の判定を得る方法です。その裏側にあるすべて — 日次で収集されるGPU価格、vLLMスループットベンチマーク、クローズドからオープンへの等価マップ — は、llms.txtエントリーポイントを備えた無料・キー不要のREST APIとしても提供されており、エージェントが4回のGETリクエストで同じ分析を実行できます。

CloudFlow：対応クラウドと制御フローを拡充

CloudFlowの役割は、FinOpsのランブックを自動化に変えることです。8月は、到達できる範囲と判断できる範囲の両方が広がりました。

• Oracle Cloud対応。 AWS、Google Cloud、Azureで実行しているのと同じフローが、Oracle Cloudでも動作するようになりました。
• Azure対応（アーリープレビュー）。 他のクラウドと並んで、Azureのアクションとトリガーが利用可能になりました。
• OpenAIとAnthropicのAdmin API。 LLMプロバイダー向けの支出ガードレール、APIキーの管理、使用状況レポートをフローノードとして提供。古いキーを定期的にローテーションしたり、1日の支出がしきい値を超えたら担当者に通知したりできます。
• Switchノード。 フィールドの値に基づいて、各結果を適切なパスにルーティング。多分岐の判断のためにBranchノードを積み重ねる必要はなくなりました。
• 並列パスノード。 フローを独立したパスに分割し、無関係なタスクが1つのシーケンスを共有しないようにできます。1つのパスで障害が起きても、他のパスは動き続けます。
• DatastoreでSQLを実行。 フロー内でPostgreSQLを使い、Datastoreテーブルのクエリ、整形、メンテナンスが可能に。結合、集計、クリーンアップジョブを、どこにもエクスポートせずに実行できます。
• メールトリガー。 公開済みのフローごとに専用のメールアドレスを持たせられます。そのアドレスにメールを送ると、フローが実行されます。メールを送れるものなら何でも組み込めます。つまり、事実上あらゆるものと連携できるということです。
• フローのエクスポートとインポート（プレビュー）。 2つのAPI操作と対応するCLIコマンドで、サブフローを含むフローを、認証情報やテナント状態を含まない1つのJSONバンドルにシリアライズし、別のテナントにドラフトフローとしてインポートできます。一度構築してステージングから本番へ昇格させたり、動作するフローを別のチームに引き渡したりできます。

見える、切り分ける、見逃さない：Cloud Analytics

• トレンド検出を刷新。 「何がトレンドか」の分析が、本当に重要な変化を浮かび上がらせるようになりました。人にもエージェントにも使いやすい設計です。私たち自身のテストでは、新しい検出ロジックは実際の大きな変動を捉えたまま、ノイズを劇的に削減しました。
• 使用量メトリクスによる共有コストの分割。 配分の基準として、DatadogやPrometheusといったオブザーバビリティプラットフォームのデータを使えるようになりました。共有コストは、前四半期には正確だった固定比率ではなく、実際の消費量に従って配分されます。
• 異常のトリアージワークフロー。 すべてのコスト異常に、レビューステータス、コメント、アクティビティ履歴を付与。難しかったのは検出ではなく、誰が確認して何を決めたのかを把握することでした。
• サービス、プロジェクト、リージョンなどによるダッシュボードのフィルタリング。 これまでダッシュボードのフィルタリングはAllocations単位でした。今では、多くのチームが普段から考えている軸そのものでフィルタリングできます。
• ウィジェットをワンステップで複製。 ダッシュボード構築は、たいてい同じテーマのバリエーションです。同じレポートで、期間やグループ化の軸だけが違う。ゼロから作り直す代わりに、複製して調整するだけです。
• 日次・週次予算のクロス期間トレンドチャート。 過去30日間または16週間にわたって、期間ごとの支出を予算と比較して追跡。予算は単月の判定ではなく、トレンドラインになります。
• GrafanaでCloud Intelligence™。 すでに運用しているダッシュボードで、ライブのクラウドコストデータを表示。すべてのCloud Intelligence™のお客様に提供中です。支出を隣にある運用メトリクスと関連付け、レイテンシーと同じ方法でコストにアラートを設定できます。

PerfectScale：より賢い判断でKubernetesを最適化

• CPUランナウェイの疑いを検出。 CPUを繰り返し増やしてもリソース逼迫が解消しない場合、それは需要ではなくワークロード側の問題です。PerfectScaleはそうしたコンテナにフラグを立て、自動化YAMLで設定できるしきい値でそれ以上の増加を一時停止するようになりました。
• フルモードのResourceQuota対応。 クォータで管理されたネームスペース内のワークロードを、クォータ上限までライトサイジングできるようになりました。ガバナンスが気づかないうちに最適化の上限になってしまうことはなくなります。
• 退避できないPod、APIで修正可能に。 退避できないPodはノードのスケールダウンを妨げ、クラスターの伸縮性をひそかに制限します。それらを可視化し、プログラムから修正できるようになりました。
• InfraFitパブリックAPI。 ノード使用率、効率データ、インフラ最適化のインサイトを、自社のツールから利用できます。
• JVMランタイムによるワークロードのフィルタリング。 クラスター内のすべてのJavaワークロードをワンクリックで検出。ラベルは不要です。Javaのメモリ挙動は独自の専門領域であり、それに専用のフィルターが加わりました。
• PerfectScale for CommitmentsでGoogle CloudのフレキシブルCUDに対応。 Compute Engine、GKE、Cloud Runのフレキシブルcommitmentsを対象に、継続的な使用状況分析と段階的な購入プランを提供。承認フロー付きで、または定義したガードレール内で自律的に実行されます。Cloud SQL対応も近日提供予定です。
• ロケールの表記に合わせた数値表示。 小さな改善ですが、1.000を「1」と読み間違えた経験があるなら、なぜこれをリリースしたのか分かるはずです。