データへ接続できても、社内で使う言葉の意味は確認が必要
Googleは2026年9月30日、Data Agent Kitの一般提供を発表しました。開発用のAIエージェントからGoogle Cloudのデータ製品へ接続し、テーブルの構造確認やクエリの実行などを行うためのツールです。10月9日付の週報にも紹介されていますが、同日に初めて公開された機能ではありません。
一方、業務用語を解釈する条件は、接続とは別に用意します。2026年10月12日に確認したBigQueryの会話型分析の公式文書では、確認済みの検索・集計処理、用語集、エージェントへの指示、テーブルや列の説明を整えることが推奨されています。Data Agent Kitとは用途の異なる機能ですが、どちらもデータを使うAIを考える参考になります。
以下は、こうした一次資料を踏まえた編集上の準備案です。特定製品の導入手順や、精度の保証ではありません。まず一つの業務と指標に絞り、定義を決める人と実装する人が同じ条件を見られるようにします。
最初の定義票には、名称よりも集計条件を書く
「売上」の列を指定するだけでは、業務の判断に使えるとは限りません。営業管理の出荷額と経理の確定数値など、目的が違う指標には区別できる名前を付けます。部署間の定義を無理に一つへ統合せず、利用目的に対応させましょう。
例えば「出荷基準の管理用売上」を扱うなら、次の欄を業務担当者とデータ担当者で埋めます。会計上の売上認識を定めるものではなく、分析AIへ渡す条件を説明するためのひな形です。未定の欄はAIに推測させず、確認する担当者を残します。
- 目的と責任者：何の判断に使い、定義と期待結果を誰が確認するか。
- 集計対象：どのシステム・表・列を使うか。1行が注文、受注明細、出荷のどれを表すか。
- 期間：注文日・出荷完了日などの基準日、タイムゾーン、開始日と終了日の扱い。
- 金額と除外：税込・税抜、通貨、取消・返品・テストデータをどう扱うか。
- 時点と変更：データが何日時点か、返品等の後日反映で過去月を再集計するか、定義の版と適用開始日。
仮の売上例で、入力と期待する結果を対応させる
ここからは説明用の架空データです。ある会社が、9月の管理用売上を「日本時間の9月中に出荷完了した明細の税抜額から、その明細にひも付く9月中に確定した返品額を引く。取消済みは除く」と決めたとします。データは10月1日9時取得の固定した写しを使い、1行は受注明細1件、返品額は元の明細へ集約済みとします。金額の単位は円、明細の金額は返品を控除する前の税抜額です。
明細Aは9月30日出荷の10,000円で返品なし。明細Bは9月30日に受け付けた6,000円で未出荷。明細Cは9月28日出荷の4,000円で、9月29日に全額返品が確定しています。この3件なら、期待する結果は10,000円です。Bは対象外、Cは4,000円から同額を引いて0円になります。実際の製品を動かした検証結果ではありません。
開発担当者には金額だけでなく、採用した明細、除外した明細と理由、使用した集計条件を返してもらいます。答えが一致しても、誤った対象を足し引きして偶然同額になることがあるためです。担当者が確認した集計処理も保存し、比較用の基準にします。
注文と商品明細を結合すると、注文の合計額が商品数だけ繰り返される場合があります。この例とは別に、一つの注文に複数明細があるデータも加え、どの単位で足すかを確認します。Googleの公式文書も、表同士の結合をAI任せにせず、関連表をまとめたビューを用意する方法を勧めています。ビューは、あらかじめ決めた条件で表を参照する仕組みです。
曖昧な質問では、確認すべき条件も期待結果に含める
試験には、数値が返る質問と、条件の確認が必要な質問の両方を入れます。明確な質問だけで採点すると、利用者が短く尋ねたときに別の定義を選ぶ問題を見落とします。次は先ほどの架空データを使う確認例です。
- 明確な質問：「2026年9月の出荷基準の管理用売上を、定義票v1・10月1日9時のデータで集計して」。期待：10,000円に加え、税抜・返品控除・対象期間・データ時点を示す。
- 曖昧な質問：「先月の売上は？」。期待：注文基準か出荷基準かが未合意なら確認質問を返す。既定の定義を合意済みなら、その名称と対象月を表示して答える。
- 対象外の質問：「この金額を経理の確定売上として使ってよい？」。期待：管理用売上だけでは判断できないと説明し、経理の定義や確定データの確認へ戻す。
- データ不足の質問：「未連携の店舗を含めた全社売上は？」。期待：不足する範囲を伝え、取得できた範囲の金額を全社分と表示しない。
定義とデータの版を残し、変更したら同じ問いで確かめる
評価の記録には、質問文、定義票の版、参照データの時点、比較用の集計処理、期待結果、AIの実際の回答、確認者と判定理由を残します。AIの設定やモデルを変更した場合も識別できるようにします。同じ条件を記録する目的は差を調べられるようにすることで、生成される文章の完全な再現を保証するものではありません。
返品を翌月に控除する運用へ変えた場合などは、定義票と集計処理、期待結果を一緒に見直します。変更前後の定義を混在させず、業務担当者が確認してから利用者へ適用します。Conversational Analytics APIの公式文書にも、試験用と公開用の設定を分けて確認し、前の設定へ戻せるようにする考え方が示されています。
金額だけが合うことを合格にせず、対象行、除外理由、不足時の応答まで照合してください。誤りが定義の不足、元データ、結合処理、質問の解釈のどこで生じたか分かれば、追加で必要な作業を絞れます。
相談には、普段使う集計と「数字がずれる例」を持ち寄る
最初から全社分の用語集を完成させる必要はありません。頻繁に聞かれる問いを一つ選び、普段の帳票、共有可能なサンプル、現在の集計条件、判断に迷う例を用意します。指標の責任者が決まらない場合は、本開発前に定義を整理する作業から相談できます。
関連サービスでAI導入・開発の支援内容を確認し、お問い合わせでは「何の判断に使いたいか」「今は誰がどの帳票で確認しているか」を伝えてください。データ整備、試作、確認作業のうち、どこから始めるかを具体的に相談しやすくなります。
参考資料・出典
本文の情報は執筆時点のものです。仕様や提供条件は、リンク先の公式情報もご確認ください。