AIを使ったクエリ作成、どこを任せてどこをやるか？

TL;DR

AIを活用することでクエリを書くこと自体は容易になった
一方で、要件定義や結果の妥当性確認まで丸投げできるわけではない
書くことが容易になった分、データサイエンスの専門性・ドメイン知識・ステークホルダーとの連携といった、よりシニアレベルのスキルが求められると感じている

はじめに

こんにちは、データサイエンティストの平です。

最近はClaude CodeやDevin等のAIツールを活用してデータサイエンティストとしての業務を行っています。しかし、全て丸投げできるかと言われるとそうではありません。AIと相性のいい箇所とそうでない箇所の濃淡はかなりあるというのが体感です。

この記事では、クエリを作成して数字を出すまでのワークフローを4つのステップに分けて、どこをAIに任せてどこを自分でやるべきかを整理しようと思います。

各ステップの概要

クエリを作成して数字を出すまでのワークフローを4ステップに分けると、AIとの相性(個人的な感覚)は以下となります。

ステップ	AIとの相性(個人的な感覚)	よく利用するAIツール
1: 要件定義	△〜○（チャット形式で相談したり、その結果を整理するのには有効）	Claudeチャット
2: データソース調査	△〜◎（社内のデータ基盤がしっかり整理されていたら◎、されていなければ△）	Devin(Claude Codeからのmcpも含む)、Notion AI
3: クエリの実装	◎（ここはほぼ丸投げ。自分で書くより早いしコメントも丁寧）	Claude Code
4: 結果の妥当性確認	△（簡単な確認はできるが、違和感に気づくのは人間の方がうまい）	Claude Code

凡例：

×：AIに任せるとかえって時間がかかる
△：人に足りない観点を補う＝サブでの活用は有効
○：AIメインで活用できるが、レビューは必要
◎ : 人(少なくとも著者)より優秀、積極的にAIに任したい

1：要件定義

まずは、分析で答えを出したい問いを明確にし、そのためのアウトプットを具体化するステップです。統計等の専門性だけでなく、ドメイン知識やそれを意思決定に活かすステークホルダーとの連携といった幅広いスキルが求められます。

このステップのポイントは、相談相手やドキュメントの作成手段としてAIを使うことです。チャット形式で相談しながら要件の不足を補いつつ、その内容をドキュメントとして整理してもらうような使い方です。過去に類似施策がある場合は、そのドキュメントをAIに渡しつつ、新たにやりたいことの差分を伝えてあげると効率的です。

また、統計解析や機械学習では検定力不足やleakageなどありがちなミスはある程度決まっているので、それらの観点で確認してもらうことも有効です。

注意点もあります。AIの意見をそのまま受け入れないことです。特にドメイン知識についてはAIが十分に持っていないことが多いので、最後は責任を持って人間が決める必要があります。

私の失敗例

A/BテストにおけるMDE(Minimum Detectable Effect：最小検出可能効果)はビジネス要件や過去の施策結果から人が決めるべき値ですが、勝手にAIが仮定したまま話が進んでいたことがありました。。

もちろん伝え忘れたのが悪いのですが、大事な前提が意図せず仮定されてしまう可能性があることには注意が必要だと学びました。

A/Bテストのように一般的な手順が決まっているケースではテンプレを使うことも有効ですが、漏れるときは漏れると思います。間をあけて、新鮮な目で読み直すことでAIとの相談中に気づけなかったことに気づくことはよくあります。実際に、MDEの件は翌朝読み直して気づくことができました。

2：データソース調査

要件が定義できたら、そのためのデータソースを調査します。（ここも要件定義の一つな気はしますが、AIとの相性の観点で分けた方が書きやすかったのでそうしています）

コードベースやドキュメントから情報を探し、整理するのはAIが得意です。ただし、事前にデータが整備されているか、過去の集計クエリが正しく共有されているか等でここの精度は大きく異なります。組織としての地力が問われる部分です。

また、AIの調査結果だけで済ませず、実際の生データを直接見ることも大事です。生データを見ることで、データの品質に問題があるなど様々なことに気づくことができます。

3：クエリの実装

要件定義やデータソース調査結果をもとに、実際に集計するクエリを書くステップです。ここはほぼAIにお任せできています。要件定義とテーブル調査の結果を渡して「BigQuery用のクエリを書いて」と指示すれば、だいたいそのまま使えるクエリが出てきます。SQLのコーディングルールやlinterの設定も合わせて渡すと、より精度の高いクエリが得られます。

ここで大事なのは、前のステップで要件とテーブル情報をちゃんと整理しておくことです。AIに渡すインプットの質がそのままクエリの質に直結します。

基本的にAIにお任せできるステップですが、BigQueryのように従量課金制のデータウェアハウスを利用している場合は料金に注意しましょう。私も何回か無駄なコストを発生させてしまったことがあります(ごめんなさい🙇🙇🙇)。

askenではBigQueryを利用しているので、SQLのコーディングルールでdry runをするようにして必ずコストを事前に把握する対策をしています。

4：結果の妥当性確認

最終的なアウトプットに問題がないか確認するステップです。要件から外れていないか、Nullや0など明らかにおかしな値はないかといった確認はAIに任せられますが、違和感への気づきはAIでは難しいです。

違和感の具体例としては、A/Bテストの結果が良すぎることであったり、栄養学的に考えづらい数値であるといったものです。A/Bテストの場合はそこから設計や割り当てのミスが判明することがありますし、栄養学の場合は集計ミスやデータ自体の信頼性が低いといったことが判明することもあります。

以前書いたこちらの記事でも述べているように、A/Bテストの結果への違和感から、クエリ自体のミスだけでなく割り当てや設計が適切でなかったことが判明したことも実際にありました。これらは経験、専門性、ドメイン知識や精神的・時間的な余裕などがないとなかなか気づくことができないケースが多いですが、AIによって他の作業を効率化できるからこそ丁寧に時間を割くべきところだと思います。

ちなみに、問題を見つけた後の調査はAIが役立ちます。クエリのバグやデータの特性を切り分ける手助けをしてくれるので、ここはAIと相性がいいです。

おわりに

「（しかし）人間というものは、ものごとを好きなように解釈して、本来の意味を見失うことがある」。シェイクスピアはシャイロックのセリフを通して私たちに警告する。大量の情報から答えを探し出そうとしている人なら誰でも覚えておくべきアドバイスだ。シグナル（信号）とノイズ（雑音）を区別するのは難しい。データが語るストーリーは、自分が聞きたいと思っているものになることが多く、それはたいていの場合ハッピーエンドである。

上記は『シグナル&ノイズ』という予測に関する名著の一文です。現在は大量のデータに加え、AIによって大量の分析を行えてしまう時代になっています。

大量のデータとAIによる大量のアウトプットというノイズの中からシグナルを拾えることがデータサイエンティストとしての価値になると考えています。