Google AQuAとは？本番AI診断の費用と条件

Google AQuAとは？

AQuAはGoogleのAgent Development Kit（ADK）で作ったエージェントの外側で動く「品質担当」のエージェントだ。利用者への応答経路には入らず、BigQueryやCloud Traceなどへ保存された本番会話を読み、問題のあるセッションを評価する。

一般的なアプリ監視は、応答時間、HTTPエラー、CPU使用率といったシステムの異常を捉える。一方、AIエージェントではシステムが正常でも、指示を取り違える、誤ったツールを選ぶ、根拠のない回答を返すといった意味上の失敗が起こる。AQuAは、この層を調べるための道具である。Googleは2026年10月8日に初版を公開し、10月26日のv0.2.0で複数の観測対象、調査スケジュール、Cloud Traceとの接続などを拡張した。[1][2]

見るもの	通常のシステム監視	AQuA
主な対象	稼働率、遅延、例外、資源使用量	会話、ツール呼び出し、評価目標
問題の単位	アラートやメトリクス	重複をまとめたinsight
実行タイミング	常時または閾値超過時	定期、デプロイ後、手動
結果	異常の通知	失敗会話、原因分析、修正案
自動修正	製品ごとに異なる	ソースを参照して提案するが、勝手に変更しない

v0.2.0で導入条件が具体化した

v0.2.0のREADMEでは、Python 3.11〜3.13、agents-cli 1.10以降、Terraform、組織に属するGoogle Cloudプロジェクト、Application Default Credentialsが前提とされる。ダッシュボードはCloud RunとIdentity-Aware Proxyで保護できるが、組織を持たない環境ではIAPを無効にしてプロキシ経由で開く構成になる。[3]

導入時はAQuAをエージェント本体と同じプロジェクトへ追加し、インフラとエンジンをデプロイする。v0.2.0では、Cloud Traceの_TraceバケットからBigQueryのリンク済みデータセットを作る経路が標準になった。既存のログシンクを読む場合はcloud_loggingも選べる。必要な権限にはObservability EditorやBigQueryメタデータの閲覧権限が含まれるため、開発者が個人で試す軽量なローカルライブラリとは性格が違う。

失敗を「件数」ではなく原因でまとめる

AQuAの中心は、会話を評価した結果をinsightへまとめる仕組みだ。同じ原因から起きた失敗を毎回別の警告にせず、NEW、RECURRING、RESOLVEDの状態と発生履歴で追う。14日間見つからなかった問題は、既定では解決済みとして扱われる。[4]

Googleが初版公開時に示した例では、32セッション、1,583スパンを調べ、42件の指摘を9クラスターに整理した。その後、検証担当のモデルが3件を退け、6件を確定した。修正後は、ある失敗が15件から2件、別の失敗が7件から0件へ減り、チェックを通過したセッションは5件から13件へ増えた。これはAQuAの動きを説明する社内例であり、第三者ベンチマークではない。[1]

この区別は重要だ。AQuAが示すのは「モデルの正答率」そのものではなく、設定した評価目標と観測した会話に対する診断結果である。業務に合わない評価基準を置けば、誤検知を減らしても利用者の困りごとは減らない。

費用はモデル料金だけでは決まらない

Googleの公開例では、32セッションの一連の分析に3.76ドル、1セッション当たり約0.12ドルかかった。別の96セッションのスイープは0.70ドルで、個別の原因分析は0.33〜2.47ドルだった。サンプル数、会話の長さ、使うモデル、再調査の回数で費用は変わるため、この数字を定価として扱うことはできない。[1]

実運用では次の費用を分けて見積もる必要がある。

• AQuAが評価と原因分析に使うモデル料金
• テレメトリを保存・検索するBigQuery、Cloud Trace、Cloud Loggingの費用
• Cloud Run、Cloud SQL、Cloud Storageなど診断基盤の運用費
• 誤検知の確認と、修正案をレビューする担当者の時間

AIエージェントの実行基盤そのものの費用や休止方法は、TechCreateの「Infinityとは？AIエージェントを休止する実行基盤」でも整理している。AQuAは実行基盤を置き換えるものではなく、その上で起きた意味上の失敗を調べる役割だ。

導入前に決める3つの基準

1. 何を失敗とするか

「役に立たない回答」のような広い基準では、評価者によって結果が揺れる。予約変更なら、顧客の希望日時、空き枠、キャンセル規定を正しく照合できたかというように、業務結果へ分解する。

2. どの会話を調べるか

AQuAはランダムサンプリングを使えるが、低頻度で重大な事故がサンプルから漏れる可能性がある。高額決済、個人情報の表示、外部送信などは、通常会話とは別の対象として抽出する必要がある。

3. 誰が修正を承認するか

原因分析とコード修正案は、実行環境や業務規則を完全に再現したものではない。AQuAはソースのスナップショットを参照できるが、提案を自動で本番へ反映しない。外部操作を伴うAIの承認境界は「AIエージェントが勝手に送信しない設計」も参考になる。

AQuAが向くチーム、向かないチーム

AQuAが向くのは、ADKやagents-cliを使い、すでにGoogle Cloudへ会話のテレメトリを保存しているチームだ。会話量が増え、障害票を一件ずつ読むより、再発原因をまとめて追う必要が出た段階で価値が出る。

反対に、会話ログを保存できない業務、評価基準がまだ決まっていないPoC、Google Cloud以外へ観測基盤を統一している環境では、導入の前提が重い。まず少数の失敗例から人が評価表を作り、どのデータを残せるかを決める方が先になる。

まとめ

• Google AQuAは、稼働監視では捉えにくいAIエージェントの意味上の失敗を、原因ごとのinsightとして追うオープンソースの診断ツールだ。
• v0.2.0で複数の観測対象やCloud Trace接続が整った一方、Google Cloud、BigQuery、権限設計を含む導入基盤が必要になる。
• 導入判断では、公開例の改善率や費用を一般化せず、自社の失敗定義、重大会話の抽出、修正承認の手順を先に固定することが重要だ。

出典・参考

1. Google for Developers Blog「The Outer Loop: An Ambient Quality Agent that diagnoses your production agent」2026年10月8日
2. Google / adk-recipes「feat(ambient-quality-agent): release v0.2.0」2026年10月26日
3. Google / adk-recipes「Ambient Quality Agent README v0.2.0」
4. Google / adk-recipes「agents-cli-aqua SKILL.md v0.2.0」