概要
最近、Googleが提供するGemini for BigQueryの「データキャンバス」を試したのですが、SQLを書くことなく自然言語でデータを集計できる手軽さに感嘆しています。
特に、カラム名を正式名称で入力したりせずとも、適当な指示で意図を読み取ってくれる点が素晴らしいです。タイトルの100倍は誇張ではなく、SQLに慣れた人であっても、複雑なクエリであれば本当に100倍の差が生じる可能性もあると思いました。
この記事では、例題を通じて、Gemini in BigQueryの効率性を紹介します。
Gemini for BigQueryとは
Gemini for BigQueryは、生成AIであるGeminiを活用してデータ分析をより簡単に行えるツールです。色々な機能がGCPおよびBigQueryにて用いることができますが、「データキャンバス」ではSQLを使わずに自然言語でのクエリ生成が可能になり、データ分析のハードルが大幅に下がります。
例題用テーブル
例題で参照するテーブルとして下記のようなダミーデータを用意しました（1万行ほど）。
| Site_CV_Date | First_Call_Date | Customer_Result | Operator_Name | Purchased_Product | Store_Location | Price |
|---|---|---|---|---|---|---|
| 2024-10-21 03:13:52 | 2024-10-21 19:55:00 | 伊藤四郎 | 大阪支社 | |||
| 2024-10-18 00:06:29 | 2024-10-18 10:36:00 | 受注 | 吉田八郎 | テープ | 大阪支社 | 1390.0 |
| 2024-10-18 10:09:31 | 失注 | 鈴木一郎 | 東京本社 | |||
| 2024-10-29 17:00:40 | 2024-10-29 19:49:00 | 受注 | 吉田八郎 | ハサミ | 大阪支社 | 4090.0 |
| 2024-10-10 22:17:07 | 失注 | 鈴木一郎 | 大阪支社 |
テーブル説明
顧客対応の履歴データの想定です。
具体的には、顧客がサイトでコンバージョンを行った日時や、その後の初回通話の日時、顧客の成果判定、対応者名、購入した商品、対応店舗の情報を記録しています。
各カラムの役割
| カラム名 | 説明 |
|---|---|
| Site_CV_Date | サイトでのコンバージョンが発生した日時を示します。 |
| First_Call_Date | 初回の通話が行われた日時を示します。 |
| Customer_Result | 顧客の成果判定（受注または失注）を示します。 |
| Operator_Name | 対応したオペレーターの名前を示します。 |
| Purchased_Product | 顧客が購入した商品を示します。 |
| Store_Location | 顧客が対応を受けた店舗の場所を示します。 |
| Price | 販売した商品の価格を示します。 |
実際に自然言語で質問してみよう
ここから以下の例題を通じて、Geminiの便利さを紹介します。
"＋"で、データキャンバスを選択します。
テーブルを選択してクエリを選択します。
（どうやら複数のテーブルを選択できるのでJOINもできそう）
そうするとプロンプト画面に入るのでそこからスタートです！
例題 1: 受注の総額を知りたい
自然言語で「受注の合計金額は？」と入力すると、priceのSUMを出してくれます。
簡単ですが正しそうなSQLですね。少し見難いですが10,562,780円とのこと。
例題 2: 各オペレーター別の受注金額
自然言語で「各オペレーター別の受注金額を一覧で見せて。」と入力しました。
少し見やすくもしてますがこれも問題なさそうですね。
例題 3: 各オペレーター別の対応数と受注数と受注率と受注金額
少し画像が見切れていますが、
各オペレーターの各データを出してもらいました。
ただし、ここではやり直すことが多かったです。
その原因がカラム名に AS 受注金額 というように日本語を使うため、
Illegal input characterが発生していたせいです
これは、プロンプトで矯正することでことなきを得ました。
例題 4: 支社に関する質問
支社にフォーカスして、横軸の質問をしてますが、
危なげなく答えてますね。
なお、「名古屋支社で一番売れた商品は」だと回数にも金額にも捉えられるため、
回答が毎回変わっていました。プロンプトは自然言語で書けばいいですが、
人間を相手にするのと同様に何を調べたいかを明確に述べる必要がありますね。
例題 5: 仮定に関する質問
う〜ん、これはダメっぽいですね。
ちなみに、カラム情報などを伝授したchatGPTであれば、
彼なりの理論をもとにしたクエリを組み立ててくれて、
見事に差を出すことができました。
これはもしかすると、Geminiは現状のテーブル情報からしか内容を読み込んでませんが、
chatGPTはそもそもカラムの値がどのように決められているかも私が教えたことに起因するかもしれません。
どうにか詳細を伝えてあげれば改善するのかも。
結論
複雑な組み立てを必要としないクエリであれば十分以上に実用ベースだと思います。
結果やクエリの保存もできるので応用もできるようです。
複雑な内容の場合は、例題5のようにやる気0のときもありますし、
ほどほどにエラーも吐くので自分で修正する力が問われますね。
私の所感ではまだ、AGI的な万能感はなく、
SQL特化サポートという所感かなぁ。。。
未来の数値予測とかもしてくれるようになれば凄いのですが、
とは言え、十分にビジネスレベルで実用できると思いますし、
効率もかなり上がると思います。
まだ使い始めたばかりなのでもっと面白い使い方を研究していきたいと思います！