AI.AGG() は何が新しいのか
これまで BigQuery は、個別の行に対して AI 処理を施す関数（例えば ML.PREDICT()）は豊富でした。しかし、ログファイルやカスタマーレビュー、チャットメッセージといった非構造化データを大量に分析し、全体的な傾向や重要なパターンを抽出する場面では、別のアプローチが必要でした。
AI.AGG() により、自然言語による指示を SQL クエリの 1 行に組み込むだけで、数百万行の非構造化データを自動集約できます。
これにより開発者は以下のような質問を、複雑なデータ前処理なしに直接データベース側で実行できるようになります。
- ネガティブなプロダクトレビューの中で、最頻出する 3 つの機能要望は何か
- ユーザーが最も多く遭遇しているエラーは何で、どう調査を始めるべきか
- 自動エージェントが顧客対応に失敗している具体的なシナリオはどれか
参考記事（Conversational Analytics in BigQuery brings trusted agentic reasoning to everyone）では、BigQuery の Conversational Analytics が自然言語でデータ分析を行う仕組みが一般提供されたことが報じられており、AI.AGG() はその分析基盤の中核機能として位置付けられているようです。
システムログ分析での実践例
Google Cloud 自体が AI.AGG() の開発過程で活用した例が、システムログ解析です。
Apache Spark のログデータを用いたデモでは、一見すると「正常に動作している」ように見えるログメッセージの中に隠れた非効率性や潜在的な問題（メモリスラッシング、クロックドリフト、ブロードキャストボトルネック）を検出しました。
重要なのは、AI.AGG() の実装ではプロンプトの設計が重要という点です。以下の工夫が含まれています。
- モデルに「すべてが正常」と判断してよいと明示的に許可（ハルシネーション防止）
- 特定の異常パターンを狩る指示を明確化
- 結果として、誤検知を最小化しながら本質的な診断情報を浮き彫りにする
スクリプト実行の観点から見ると、このログ分析は Claude Code を使った LLM 統合にも応用できそうです。単なる正規表現マッチングや統計的フィルタリングでは見落とす、文脈を踏まえた異常検知が SQL レベルで実現されるイメージが強いです。
非構造化テキストと画像データの一括カテゴリ抽出
Google が公開している架空のペットショップ「cymbal_pets」のデータセットを例に、AI.AGG() の多様性が示されています。
| 処理対象 | 従来の方法 | AI.AGG() での実現 |
|---|---|---|
| 商品名・説明テキスト | 手動分類またはルールベース抽出 | 自然言語指示で未知のカテゴリを自動発見 |
| 商品画像 | 別途画像認識モデルが必要 | マルチモーダル対応で画像も含めて分析 |
| 分析パイプライン化 | 複数ステップのコード実装 | SQL クエリ 1 つで完結 |
単一の SQL クエリで、テキスト・画像の両方を入力としながら、カテゴリ自動発見から集約までが実現できる—これは従来の ETL パイプラインと比べて開発効率が劇的に向上します。
初期段階の発見用クエリではプレーンテキストの結果が返されますが、本格的なデータパイプライン化には、その出力をさらに後続の処理に渡せる構造化フォーマット（JSON など）へ変換する工夫が必要になるでしょう。
他の BigQuery AI 機能との組み合わせで広がる可能性
AI.AGG() が強力な理由は、既存の BigQuery AI 関数生態系と組み合わせやすい設計にあります。参考記事（Scaling Network Analysis for Fraud Prevention with BigQuery Graph）で紹介された BigQuery Graph（グラフ分析）と組み合わせれば、例えば詐欺ネットワークの検出をテキストデータの集約と同時に実行できる可能性も考えられます。
- AI.AGG() で大量のトランザクションログからパターンを抽出
- その結果を BigQuery Graph に入力して関係図を構築
- 不正ネットワークの構造を可視化
このような複合分析が一つの SQL クエリセット内で完結することで、GCP 上でのデータ分析基盤はさらに堅牢かつ柔軟になっていくと感じます。
価格体系や実行時間への影響については、プレビュー段階では未定の可能性が高いため、一般提供開始時のドキュメントを確認する必要があります。GCP を主軸に使っている開発者の方にとっては、これまで Python やコンテナで別途実装していたテキスト集約処理をネイティブに移行できる選択肢として検討の価値が十分あります。
