はじめに
前編では、ADK（Agent Development Kit）で「自然検索からのコンバージョン分析・施策提案エージェント」を作り、BigQuery Agent Analyticsプラグインを仕込むところまでをやりました。
後編は本題の「エージェント分析」です。エージェントと会話すると、その行動ログはすべて agent_events テーブルに流れ込んでいます。誰が・何を質問し、エージェントが裏でどんなSQLを書き、何トークン消費したのか。5つの切り口で分析した結果を、発見と一緒に紹介します（分析に使ったSQLの詳細は、本記事では割愛します）。
① 利用状況サマリ — 誰が・いつ・どれだけ
agent カラムがあるので、エージェントを複数運用しても、エージェント別の利用状況が一発で集計できます。「せっかく作ったのに使われていない」「特定の人しか使っていない」といった課題は、まずこの集計で見えてきます。
なお user_id が「user」となっているのは開発用UIをローカルホストで動かしている（で、自分だけが利用している）からで、本番ではフロントエンド側で実ユーザーIDを渡す設計にします。
② 質問一覧 — 何を聞かれているか
ユーザーがエージェントに投入した質問文がそのまま取れます。私のログには「直近90日のIMPRESSIONの合計を折れ線グラフで見せて」→「週ごとでお願いします。」→「2900以上あった次の週が1900に届かない。さらに詳しく分析してください。」という流れが残っていました。単純なデータ取得から掘り下げ分析へ、会話が深まっていく様子が見えます。
質問文が取れるということは、「事実確認ばかりで、分析にはあまり使われていない」といった利用の質を判定できるということです。件数が溜まれば、BigQueryのAI.GENERATE関数で質問を自動分類する、といった活用方法が考えられます。また、利用者のリテラシーがボトルネックとなって会話分析が浸透していないのであれば、ユーザー研修を行うことが実効性のある対策になることもあるでしょう。
③ 実行されたSQLと所要時間
「さらに詳しく分析して」という質問の裏で、エージェントがCTE付きのSQLを自分で書き、クエリ別→URL別と切り口を変えて連続で調査していた痕跡が残っていました。エージェントの回答の根拠となったSQLを、事後に取り出して検算できる。これは運用上、かなり安心感があります。
④ セッションの解剖 — 1つの会話を時系列で再構成
エージェントと人間の間の会話が内部的に発生したイベントとして分解されて、時系列で追えます。ユーザーの質問を受け、LLMに問い合わせ、ツール（SQL実行）を起動し、結果を受けてまたLLMが考え、応答する——ユーザーから見れば1往復の会話の裏で回っている、エージェントの内部の動きが丸見えです。私の環境では、4往復のチャットで、以下のイベントが記録されていました。
そしてここに、この記事のハイライトが写っていました。グラフツールを追加する前のセッションに、こんなLLM応答が記録されていたのです。
申し訳ありません、私は直接グラフを生成する機能は持っておりません。
今は自分自身で課題を発見したのですが、本番運用になれば、ログからこうした課題を発見できます。
また、改善後のセッションで、「グラフを描いて」のようなプロンプトが投入されたのか、グラフ描画ツールの実行が記録されたのかといった課題発見→改善→効果確認のサイクルについても確認できることになります。
⑤ トークンコストとレイテンシ
私の場合、LLM呼び出し9回で入力13.3万トークン、出力4,454トークンでした。入力が出力の約30倍。これは、手順・ビュー定義・検証済みクエリといったリッチな文脈を毎回モデルに送っているコストです。とはいえgemini-2.5-flashの料金なら、この日の全会話でも数円程度。「文脈を盛ってもコストはこの程度」というのは、安心材料だと思います。
改善サイクルは、もう一周した
実はこの検証中に、もうひとつ改善を回しています。グラフに「None」という項目が突出して表示されたのです。原因はSearch Consoleの仕様で、匿名化された検索クエリがNULLとして記録されているためでした。そこでエージェントの手順に1行追加しました。
queryがNULLの行は匿名化されたクエリです。クエリ別の分析では除外し、除外した旨を回答に添えてください。
ADK版のエージェントの文脈はコード（テキスト）なので、こうした改善が1行の編集で済み、Gitで履歴も残せます。利用ログから課題を見つけ、文脈を強化し、その効果をまたログで確認する。エージェントを「育てる」とは、このループを回し続けることなのだと思います。
まとめ
データ分析の世界では昔から「計測できないものは改善できない」と言われてきました。AIエージェントも同じです。
エージェントを導入すること自体は、これからどんどん簡単になります。差がつくのは導入した後、育てられるかどうか。ADKで作ったエージェントは、行動ログが丸ごとBigQueryに溜まるので、課題の発見も、改善の効果検証も、使い慣れたSQLでできます。
BigQueryの周辺には、エージェントで分析する仕組みだけでなく、エージェントを育てるためのデータ基盤まで揃っていることが分かりました。
7月15日のa2iのセミナーでは、「今後、データや文脈を整備し、全社で会話分析を利用できるようにすることが、これからのマーケティング部の仕事になるかもしれない」と言いました。それに加え、「エージェントを最適化し、全社のエージェント利用を効率化する」という仕事もデータマーケターの仕事の範疇に入ってくるように思います。
データ分析に携わってきた人間にとって、これはとても筋の良い土俵だと感じました。