nOpsは、AWS、Google Cloud Platform、Microsoft Azureにまたがる契約コミットメントを管理する顧客向けに、クラウドコスト分析を改善するため、FinOps AIエージェントのClaraをAmazon Bedrock AgentCore上で再構築した。同社によると、この移行によりFinOpsエージェントの出荷は75 percent速くなり、管理対象のクラウド支出がUSD $4 billionを超える顧客を支援できるようになった。

移行前のClaraは、Kubernetes、Amazon Bedrockのモデル呼び出し、LangChain/LangGraphによるオーケストレーション、Web APIを囲むツールラッパーで動いていた。nOpsは、この構成が初期提供を速めた一方、洞察に至る時間の遅さ、運用負荷の高さ、エージェント回答と分析データの不一致を生んだと説明した。回答が専用のセマンティック分析層ではなく、API出力に依存していたためだ。

新しいアーキテクチャの中心は、実行環境とオーケストレーションを担うAmazon Bedrock AgentCore、管理された分析セマンティクスを提供するDatabricks Lakehouse Metric Views、永続的なアプリケーション状態を保持するDatabricks Lakebaseである。nOpsは、管理型エージェント実行環境、組み込みメモリ、オーケストレーション、任意のフレームワークやモデルを使える点からBedrock AgentCoreを選び、エンジニアがインフラではなくFinOpsのドメインロジックに集中できるようStrands上に構築した。

Claraの対話層は、VercelでホストされたNext.js Webアプリケーションとストリーミング型のServer-Sent Eventsを使う。エージェント実行環境はAmazon Bedrock AgentCore上のDockerコンテナとして動き、ランタイム、メモリ、ガードレール、キュー、ワーカー関数は単一のAWS Cloud Development Kitスタックで定義される。nOpsは、キャンバス操作、クエリ実行、データソース探索、ワークフローのオーケストレーションに直接ツールアクセスを持つ単一のStrandsベースのエージェントを使い、マルチエージェントのルーティング負荷を避けている。

ストリーミングは、Strandsの非同期ストリームとServer-Sent Events出力の間に置かれた独自のマージ層に依存する。ハートビートが長時間のツール実行中も接続を維持し、単語境界を意識したフラッシュが小さなモデル差分を読みやすい塊にまとめる。ウィジェットポーリング用ワーカーは、同じストリームを通じてリアルタイムのキャンバス更新イベントを送る。

ClaraはAgentCoreメモリを、セマンティック事実、ユーザー設定、キャンバス要約という3つの戦略で使う。設定はレイアウト選択、既定の集計、グラフ種類を導き、事実はアカウント構造やコスト配賦の慣行といった組織コンテキストを保存する。キャンバス要約はセッションをまたいで分析の流れを保持する。セッションはキャンバス単位で区切られるため、ブラウザー更新や再接続後もコンテキストが残る。

テナント分離では、エージェント実行前にAmazon Bedrock Guardrailsが生のユーザープロンプトを検査し、テナント間データアクセス方針とプロンプト攻撃検知を適用する。テナントポリシー層は送信ストリームのチャンクとウィジェットイベントもサニタイズし、フロントエンドに届く前に内部識別子を伏せる。

データ層では、Claraは汎用的な製品APIに頼らず、Databricks Lakehouse Metric Viewsを背後に持つDatabricks SQL Warehouseに対してSQLを実行する。True Customer Costの例では、生SQLのMCPアプローチは過去30 daysについてAWSの価格プログラムと契約コミットメントに基づく割引をまたいでビジネスロジックを再計算する必要がある。一方、Metric View MCPアプローチは、true_customer_costのような定義済み指標をaccount_nameと同じ期間で問い合わせる。

サーバーレスPostgreSQL状態層であるDatabricks Lakebaseは、製品オブジェクト、セッション、キャンバス、ウィジェット、クエリまたはチャート仕様を保存する。長時間の分析ワークフローでは、ワークフローワーカー、Amazon DynamoDBのジョブ追跡、Amazon SNSとAmazon SQSの通知、Amazon API Gateway WebSocketプッシュを使い、重い処理をバックグラウンドで動かしながらUIをリアルタイムに更新する。

nOpsは、自己管理のAmazon Elastic Kubernetes Serviceスタックを単一の管理型サービスに置き換えた後、本番投入までの時間が10–12 monthsから4 monthsへ短縮され、75 percent減ったと報告した。共有ランタイムは現在、4–6個の本番対応エージェントを提供している。

nOpsはさらに、Correctnessスコアが81.7 percentとなり、前期比145 percent増、v1のapproximately 65 percentから上昇したと報告した。Helpfulnessスコアは79.4 percentで前期比138 percent増、ツール失敗率は7.49 percentから0.92 percentへ低下した。Customer Success ManagersとSolutions Architectsの手作業による分析時間は75 percent減り、推定2 hoursから30 minutesになった。

nOpsは、AWS、Google Cloud Platform、Microsoft Azureにまたがる契約コミットメントを管理する顧客向けに、クラウドコスト分析を改善するため、FinOps AIエージェントのClaraをAmazon Bedrock AgentCore上で再構築した。同社によると、この移行によりFinOpsエージェントの出荷は75 percent速くなり、管理対象のクラウド支出がUSD $4 billionを超える顧客を支援できるようになった。

移行前のClaraは、Kubernetes、Amazon Bedrockのモデル呼び出し、LangChain/LangGraphによるオーケストレーション、Web APIを囲むツールラッパーで動いていた。nOpsは、この構成が初期提供を速めた一方、洞察に至る時間の遅さ、運用負荷の高さ、エージェント回答と分析データの不一致を生んだと説明した。回答が専用のセマンティック分析層ではなく、API出力に依存していたためだ。

新しいアーキテクチャの中心は、実行環境とオーケストレーションを担うAmazon Bedrock AgentCore、管理された分析セマンティクスを提供するDatabricks Lakehouse Metric Views、永続的なアプリケーション状態を保持するDatabricks Lakebaseである。nOpsは、管理型エージェント実行環境、組み込みメモリ、オーケストレーション、任意のフレームワークやモデルを使える点からBedrock AgentCoreを選び、エンジニアがインフラではなくFinOpsのドメインロジックに集中できるようStrands上に構築した。

Claraの対話層は、VercelでホストされたNext.js Webアプリケーションとストリーミング型のServer-Sent Eventsを使う。エージェント実行環境はAmazon Bedrock AgentCore上のDockerコンテナとして動き、ランタイム、メモリ、ガードレール、キュー、ワーカー関数は単一のAWS Cloud Development Kitスタックで定義される。nOpsは、キャンバス操作、クエリ実行、データソース探索、ワークフローのオーケストレーションに直接ツールアクセスを持つ単一のStrandsベースのエージェントを使い、マルチエージェントのルーティング負荷を避けている。

ストリーミングは、Strandsの非同期ストリームとServer-Sent Events出力の間に置かれた独自のマージ層に依存する。ハートビートが長時間のツール実行中も接続を維持し、単語境界を意識したフラッシュが小さなモデル差分を読みやすい塊にまとめる。ウィジェットポーリング用ワーカーは、同じストリームを通じてリアルタイムのキャンバス更新イベントを送る。

ClaraはAgentCoreメモリを、セマンティック事実、ユーザー設定、キャンバス要約という3つの戦略で使う。設定はレイアウト選択、既定の集計、グラフ種類を導き、事実はアカウント構造やコスト配賦の慣行といった組織コンテキストを保存する。キャンバス要約はセッションをまたいで分析の流れを保持する。セッションはキャンバス単位で区切られるため、ブラウザー更新や再接続後もコンテキストが残る。

テナント分離では、エージェント実行前にAmazon Bedrock Guardrailsが生のユーザープロンプトを検査し、テナント間データアクセス方針とプロンプト攻撃検知を適用する。テナントポリシー層は送信ストリームのチャンクとウィジェットイベントもサニタイズし、フロントエンドに届く前に内部識別子を伏せる。

データ層では、Claraは汎用的な製品APIに頼らず、Databricks Lakehouse Metric Viewsを背後に持つDatabricks SQL Warehouseに対してSQLを実行する。True Customer Costの例では、生SQLのMCPアプローチは過去30 daysについてAWSの価格プログラムと契約コミットメントに基づく割引をまたいでビジネスロジックを再計算する必要がある。一方、Metric View MCPアプローチは、true_customer_costのような定義済み指標をaccount_nameと同じ期間で問い合わせる。

サーバーレスPostgreSQL状態層であるDatabricks Lakebaseは、製品オブジェクト、セッション、キャンバス、ウィジェット、クエリまたはチャート仕様を保存する。長時間の分析ワークフローでは、ワークフローワーカー、Amazon DynamoDBのジョブ追跡、Amazon SNSとAmazon SQSの通知、Amazon API Gateway WebSocketプッシュを使い、重い処理をバックグラウンドで動かしながらUIをリアルタイムに更新する。

nOpsは、自己管理のAmazon Elastic Kubernetes Serviceスタックを単一の管理型サービスに置き換えた後、本番投入までの時間が10–12 monthsから4 monthsへ短縮され、75 percent減ったと報告した。共有ランタイムは現在、4–6個の本番対応エージェントを提供している。

nOpsはさらに、Correctnessスコアが81.7 percentとなり、前期比145 percent増、v1のapproximately 65 percentから上昇したと報告した。Helpfulnessスコアは79.4 percentで前期比138 percent増、ツール失敗率は7.49 percentから0.92 percentへ低下した。Customer Success ManagersとSolutions Architectsの手作業による分析時間は75 percent減り、推定2 hoursから30 minutesになった。