BigQuery で週次の売上・広告レポートを作り、「なぜ数字が動いたか」を手作業で説明している分析担当の方に向けた記事です。2026年9〜10月に追加された AI 関数を、レポートの工程に当てはめて整理しました。読み終わると、どの手作業を SQL に置き換えてよいかを判断できるようになります。
この記事でわかること
- 9〜10月の AI 関連リリース26件の日付と状態
- 週次レポートの7工程のうち、本番で使える機能がそろった工程
- AI.AGG と AI.KEY_DRIVERS の組み込み方
- Preview の機能の扱い方と、コストの注意点
ざっくり言うと：GA は「前と後ろ」、推論の工程はまだ Preview
この2か月の AI 関連リリースを筆者が数えると、26件のうち19件が GA（一般提供、本番利用を想定した正式版）でした。残り7件は Preview（試験提供の段階）です。
ただし GA は、データの取り込み・文章の分類・結果の共有という、レポートの前と後ろの工程に集中していました。「なぜ動いたか」「来週どうなるか」「施策が効いたか」を推し量る工程では、7件のうち GA は AI.KEY_DRIVERS だけです。予測の TimesFM 3.0 と効果検証の AI.CAUSAL_EFFECT は Preview のままです。
なぜ工程ごとに整理するのか
Google Cloud の製品の公開段階の説明によると、Preview の段階の機能はそろっているとは限らず、SLA（サービス水準の保証）や技術サポートの約束もありません。Google が別に示さない限り、テスト環境での利用を想定しています。一方の GA は本番利用の準備ができた段階です。だから毎週の定型レポートに組み込む前に、「どの工程に GA の機能があるか」を押さえておく必要があります。
2026年9〜10月の BigQuery AI 関連リリース一覧
BigQuery のリリースノートから、2026-09-03〜10-27 の AI 関連項目を拾い出しました。数え方は次のとおりです。
- 数えるのは、AI・ML の関数、生成AI関数などで使うモデル、会話型分析、Data Engineering Agent（データの取り込みや変換のパイプラインを AI が作る機能。表では DE Agent と略します）とデータエージェントの項目です。
- そのうち、リリースノートに GA か Preview かが書かれている項目だけを数えます。状態の書かれていないモデルの追加（09-09・09-21・10-02）や、会話型分析の提供地域の追加（10-16）は外しました。
- AI の機能そのものではない項目（Data Transfer Service の MCP サーバー、OBJ.LIST 関数など）も外しました。
- リリースノートの1項目を1件として数えます。AI.AGG 本体（10-13）と、その output_schema（出力の形を指定する引数）の追加（10-14）は2件と数えました。
- 会話型分析（Conversational analytics。BigQuery のデータに自然な文章で質問できる機能）の中での機能追加も1件と数え、表では「（会話型分析）」と書いています。
- Data Studio 側のリリースは件数に含めていません。
図1のとおり、9月は Preview（5件）が GA（3件）より多かったのに対し、10月は GA が16件に増えました。筆者が数えた件数は次のとおりです。
| 月 | GA | Preview | 合計 |
|---|---|---|---|
| 2026年9月 | 3 | 5 | 8 |
| 2026年10月 | 16 | 2 | 18 |
| 合計 | 19 | 7 | 26 |
26件の内訳は次のとおりです。工程の列は、次の章で説明する週次レポートの工程に筆者が当てはめたものです。
| 日付 | 項目 | 状態 | 工程 |
|---|---|---|---|
| 09-03 | バスケット分析（会話型分析） | GA | 集計 |
| 09-08 | AI.PREDICT 対応（会話型分析） | Preview | 予測・異常検知 |
| 09-10 | ML.CORRELATION 対応（会話型分析） | Preview | 要因特定 |
| 09-10 | ML.METRICS | Preview | 予測・異常検知 |
| 09-10 | DE Agent の Graph 連携 | GA | 取り込み |
| 09-10 | AI.CAUSAL_EFFECT | Preview | 効果検証 |
| 09-22 | Agent Registry 経由での Gemini Enterprise への公開 | Preview | 共有 |
| 09-29 | AI.KEY_DRIVERS | GA | 要因特定 |
| 10-01 | グラフとの会話（会話型分析） | GA | 共有 |
| 10-01 | パイプラインのメタデータ補完（DE Agent） | GA | 取り込み |
| 10-05 | gemini-embedding-2 | GA | 分類・要約 |
| 10-06 | AI.CAUSAL_EFFECT の会話型分析対応 | Preview | 効果検証 |
| 10-07 | TimesFM 3.0 | Preview | 予測・異常検知 |
| 10-09 | DE Agent の東京リージョン対応 | GA | 取り込み |
| 10-13 | AI.AGG | GA | 分類・要約 |
| 10-13 | gemini-4-argon（モデル） | GA | 全工程共通 |
| 10-14 | AI.AGG の output_schema 引数 | GA | 分類・要約 |
| 10-14 | 複数プロジェクト・データセットとの会話（会話型分析） | GA | 共有 |
| 10-14 | Gemini Enterprise への公開 | GA | 共有 |
| 10-15 | 回答エクスポート | GA | 共有 |
| 10-21 | AI.CHUNK_DOCUMENT | GA | 分類・要約 |
| 10-22 | AI.TRANSLATE | GA | 分類・要約 |
| 10-26 | 会話ログ保存 | GA | 共有 |
| 10-27 | DE Agent の Google Drive 連携 | GA | 取り込み |
| 10-27 | Connected Sheets での会話型分析 | GA | 共有 |
| 10-27 | AI.COUNT_TOKENS | GA | 全工程共通 |
ML.METRICS は、保存したモデルがなくても、実際の値と予測した値から精度の指標を計算する関数です。予測の良し悪しを確かめる関数なので、予測の工程に入れました。
Gemini Enterprise は Google の企業向けの Gemini 製品です。表の「公開」は、BigQuery で作った会話型分析のエージェントを Gemini Enterprise に載せる機能を指します。
gemini-embedding-2 は 埋め込み（文章などを、意味の近さを比べられる数値の並びに変えること）のモデルで、AI.EMBED や AI.SIMILARITY などの関数で使えます。似たレビュー同士を寄せ集める分類に使えるため、分類・要約の工程に入れました。
週次レポートの7工程と、各工程に対応する機能
典型的な週次レポートは、次の7つの工程で作られています。データを取り込み、SQL で集計し、レビューなどの文章を読んで分類し、数字が動いた理由を探し、来週の見込みを立て、施策の効果を確かめ、最後に関係者へ配ります。
図2は各工程に今回の主な機能を当てはめたもので、実線の枠が GA、点線の枠が Preview です。会話型分析の中での機能追加は図2では省略し、件数を数えた図3にだけ含めています。共有の Agent Registry 経由の公開（Preview）も同様です。
| 工程 | GA | Preview |
|---|---|---|
| 取り込み | 4 | 0 |
| 集計 | 1 | 0 |
| 分類・要約 | 5 | 0 |
| 要因特定 | 1 | 1 |
| 予測・異常検知 | 0 | 3 |
| 効果検証 | 0 | 2 |
| 共有 | 6 | 1 |
どの工程でも使うモデル gemini-4-argon と AI.COUNT_TOKENS（どちらも GA）は表に入れていません。筆者が計算すると、「要因特定・予測・効果検証」の推論にあたる3工程は合計7件で、そのうち GA は1件でした。それ以外の4工程は17件のうち16件が GA で、Preview は共有の1件（Agent Registry 経由の公開）だけです。
このため、文章の分類や配布の手作業は今すぐ置き換えを検討でき、予測と効果検証はまだ試す段階だと考えられます。
分類・要約：AI.AGG で自由記述を SQL で集計する
アンケートの自由記述やレビューは、これまで人が読んで「価格への不満」などに手で振り分けてきたはずです。AI.AGG は、複数行の文章をまとめて AI に読ませ、1つの結果にまとめる 集約関数（SUM のように複数行を1つにまとめる関数）です。2026-10-13 に GA になりました。
AI.AGG のリファレンスによると、入力（INPUT）と指示文（INSTRUCTION）を受け取ります。翌日の10-14に GA になった output_schema 引数で、結果を決まった列の形（STRING・INT64・FLOAT64・BOOL・ARRAY・STRUCT）で受け取れます。
公式の例は GROUP BY と組み合わせて投稿をユーザーごとに要約するものです。週次レポートでは次の形になると考えられます。
-- 形のイメージです。正確な引数の書き方は公式リファレンスの例で確認してください
SELECT
product_category,
AI.AGG(
review_text,
'不満の理由を話題ごとにまとめてください',
output_schema => 'topics ARRAY<STRUCT<name STRING NOT NULL, explanation STRING NOT NULL>>'
) AS review_topics
FROM `project.dataset.weekly_reviews`
WHERE review_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY product_category;output_schema で出力の形を固定すると、結果をそのまま次の集計につなげられます。ただしリファレンスによると、各項目に NOT NULL を付けないと AI が空の値（NULL）を返すことがあり、後ろの集計で件数がずれます。
長い文書は AI.CHUNK_DOCUMENT（10-21 GA。文書を扱いやすい長さに区切る関数）で分け、海外のレビューは AI.TRANSLATE（10-22 GA）で言語をそろえてから渡せます。
要因特定：AI.KEY_DRIVERS で「なぜ数字が動いたか」を出す
「売上減はどの地域・商品のせいか」を探すには、切り口を変えて SQL を何度も書き直す必要がありました。AI.KEY_DRIVERS は、2つの集まり（今週と先週など）の差を、どの切り口の組み合わせ（セグメント、地域×商品のような区切り）が生んだのかを一覧にする関数です。2026-09-29 に GA になりました。
AI.KEY_DRIVERS のリファレンスによると、必須の引数は次の3つです。
| 引数 | 意味 | 週次レポートでの例 |
|---|---|---|
| metric_col | 比べたい指標の列 | 売上金額 |
| dimension_cols | 切り口の列（1〜12列、INT64・BOOL・STRING） | 地域、商品カテゴリ |
| interest_label_col | 注目する集まりか比較する集まりかを表す BOOL 列 | 今週なら TRUE、先週なら FALSE |
2つの集まりは期間でなくてもかまいません。公式リファレンスの例は、新商品かどうかで行を分けています。週次レポートでは、「今週の行か、先週の行か」を表す BOOL 列を普通の SQL で作り、そのクエリをかっこで包んで最初の引数に渡します。
-- 公式リファレンスの構文に沿った例です。テーブル名と列名は自分の環境に合わせてください
SELECT *
FROM AI.KEY_DRIVERS(
(
SELECT
region,
product_category,
sales_amount,
order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AS is_this_week
FROM `project.dataset.orders`
WHERE order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)
),
metric_col => 'sales_amount',
dimension_cols => ['region', 'product_category'],
interest_label_col => 'is_this_week'
);結果には、セグメントごとの注目側の値（metric_interest）、比較側の値（metric_reference）、その差（difference）に加えて、unexpected_difference や contribution（寄与）などの列が返ります。unexpected_difference は、ほかのセグメントの変化率から見込んだ値と実際の値との差で、「予想外の動き」の大きさを表します。差の大きい順に並べれば「要因」欄の下書きになります。
予測と異常検知：TimesFM 3.0 は Preview
TimesFM 3.0 は、過去の数字の並び（時系列）を扱うモデルです。2026-10-07 に Preview として追加され、AI.FORECAST（予測）、AI.EVALUATE（予測の評価）、AI.DETECT_ANOMALIES（いつもと違う値の検知）で使えます。
来週の見込みや異常の検知に向くと考えられますが、複数指標を使う予測の制約や Preview の利用条件は確認できませんでした。
効果検証：AI.CAUSAL_EFFECT は Preview のまま
AI.CAUSAL_EFFECT は、キャンペーンや値下げなどの施策（介入）が時系列の数字にどれだけ影響したかを数値にする関数です。2026-09-10 に Preview になり、10-06 には会話型分析からも Preview で使えるようになりました。
施策前後の数字を並べるだけの比較を置き換える候補になると考えられます。ただし構文や前提条件は今回確認できなかったため、書き方の例は載せていません。
共有：会話型分析と会話ログ保存
配布後の「この地域だけ見たい」に SQL で応えるのも手作業です。会話型分析では共有まわりの機能が6件 GA になりました。そのうち1件は、10-27 に GA になった Connected Sheets（スプレッドシートから BigQuery のデータを扱う機能）での会話型分析です。
図4のように、指標を会話型分析に載せると、閲覧者が自然な文章で追加の質問をできます。10-26 GA の会話ログ保存で、そのやり取りが BigQuery に残ります。よく聞かれる質問を次週の指標に足せば、レポート自体を改善できると考えられます。
指標の定義（売上や CV の計算式）の置き場所も、ツールごとに違います。
| 観点 | BigQuery 会話型分析 | Data Studio 会話型分析 | Snowflake Semantic Studio |
|---|---|---|---|
| GA になった時期（対象） | 製品全体の GA 日は確認できず（会話ログ保存は 10-26 GA） | 2026-07-30（製品全体） | 2026-09-30（製品全体） |
| 最近の追加 | Gemini Enterprise への公開 | BigQuery Graph 接続（10-22） | YAML の直接編集 |
| 定義の版管理 | 確認できず | 確認できず | Git に対応 |
| 質問の記録 | BigQuery に保存 | 確認できず | 確認できず |
出典は BigQuery と Data Studio のリリースノート、Snowflake のお知らせです。Semantic Studio は指標の定義（セマンティックビュー）を作る Snowflake の機能で、YAML（設定を書くための書式）で定義を直接編集でき、Git（変更の履歴を管理する仕組み）で版を管理できます。計算式を Git で履歴管理したいなら Snowflake、質問の記録を分析に使いたいなら BigQuery の会話ログ保存が使えます。
Preview を本番レポートに使ってよいか：判断基準
先に紹介した公式の説明のとおり、Preview は原則としてテスト環境向けで、SLA もありません。そのため筆者は、Preview の機能を定型レポートには使わず、結果を人が確認できる手元の検証に限るのが安全だと考えます。
筆者が日付から計算すると、AI.CAUSAL_EFFECT は2026-10-28時点で Preview になってから48日、TimesFM 3.0 は21日がたっています。GA になる時期は今回確認できなかったため、定型レポートには GA の AI.KEY_DRIVERS と AI.AGG から組み込むのが無理のない順番だと考えられます。
つまずきやすい点
モデル指定：gemini-4-argon は GA、価格の変更は確認できず
生成AI関数のモデル gemini-4-argon は 2026-10-13 に GA になりました。今後の価格変更や BigQuery の料金への反映は、公式情報で確認できませんでした。使う前に公式の料金ページで確かめてください。
コスト：日次のトークン上限を知っておく
生成AI関数は文章を トークン（AI が文章を数える単位）に分けて処理します。費用管理のドキュメントによると、既定の1日あたりの上限は次のとおりです。太平洋時間の0時にリセットされます。
| 範囲 | 入力トークン | 出力トークン |
|---|---|---|
| プロジェクト全体 | 2,000億 | 200億 |
| ユーザー単位 | 1,500億 | 150億 |
全件を毎回読ませると費用がかさむので、WHERE 句で今週分に絞って渡します。
実行する前に、10-27 に GA になった AI.COUNT_TOKENS でトークン数を見積もれます。AI.AGG のリファレンスも、見積もりにこの関数を使うよう案内しています。ただし数えるのは入力のトークンだけで、出力のトークンは含みません。また AI.AGG は文章を小分けにして送るため、実際に送るトークンは元の文章より多くなります。
-- 今週のレビューの入力トークン数を合計して見積もる
SELECT SUM(AI.COUNT_TOKENS(review_text).result) AS input_tokens
FROM `project.dataset.weekly_reviews`
WHERE review_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY);なお、AI.AGG と AI.KEY_DRIVERS がそれぞれ何を単位に課金されるかは、今回確認できませんでした。
AI.KEY_DRIVERS の引数の組み合わせ
AI.KEY_DRIVERS では、件数を絞る top_k と、出現頻度の下限 min_apriori_support を同時に使えません。また min_apriori_support を0にしない限り、指標の値は0以上である必要があります。返品をマイナスの売上で持つテーブルでは、min_apriori_support => 0 を指定します。
まとめ
- 2026年9〜10月の BigQuery AI 関連リリース26件のうち19件が GA で、取り込み・文章の分類要約・共有の工程に集中しています。
- 推論の工程で GA なのは AI.KEY_DRIVERS だけです。予測の TimesFM 3.0 と効果検証の AI.CAUSAL_EFFECT は Preview なので、まずは手元の検証に使うのが安全です。
- 週次レポートには、AI.AGG（output_schema で形を固定）と AI.KEY_DRIVERS から組み込み、AI.COUNT_TOKENS で見積もったうえで WHERE 句で対象を絞ります。