こんにちは！ラブグラフ開発インターンを経て、ビジネス職で新卒入社した arawi です。
ラブグラフでは非エンジニアのメンバーもデータ分析や業務効率化の目的で日々 SQL クエリを書いています。
自分自身ビジネス職として新卒入社し、多くのクエリを書いています。
SQL の知識はあるものの、複雑なクエリを自分で書くのは大変で、時間がかかることも多いです。
AI を使っての SQL クエリ生成は以前から試していましたが、AI がドメイン知識を持っていないため、正しいクエリを生成できないのが課題でした。
今日はそんな課題を解決した方法を紹介します！
TL;DR
- Gemini に DB スキーマ（Ridgepole の
Schemafile.rb）をそのまま食わせるだけで、めちゃくちゃ優秀な SQL ライターになる - 1往復で動くクエリが返ってくることも多い
- データ自体は渡さないので個人情報などを LLM に食わせる必要がなく、安全
- ただし、今は使われていないカラムなどは見抜けないので注意
発端
AI で SQL を書かせようとしたとき、DB スキーマ情報がないと正しいクエリを生成できないのが課題でした。
やったこと
Ridgepole で管理している Schemafile.rb をそのまま Gemini の知識に食わせ、SQL を書くようプロンプトを与えました。
すると、テーブル構成やカラム名をきちんと理解した上で、ほぼ一発で動く SQL クエリを返してくれるようになりました。
知識は Gemini にファイルを渡せる機能
Schemafile.rb について
Schemafile.rb は Ridgepole で管理されている Ruby on Rails の DB スキーマ定義ファイルです。
通常の ActiveRecord のマイグレーションファイルとは異なり、テーブルの構造を Ruby のコードで定義します。
これにより、データベースのスキーマをシングルファイルで管理できるというものです。
シングルファイルというのがキモで、それによって AI に食わせるのが容易になります。
ActiveRecord::MigrationとRidgepoleの違いについては、以下の記事も参考にしてください。
実際のプロンプト
実際 Gemini に与えたプロンプトは以下の通りです。
用途
SQLクエリの作成、修正、理解などのタスクをサポートする。目標とプロジェクトを共有するので、それを達成するために必要なクエリの作成をサポートしてください。
前提
* 利用しているRDBMSはMySQL
* データベースは Ruby on Rails アプリと密接に関わっている
* データベースの定義がファイルで与えられる
目標
* クエリの作成: 可能な限り私の目標を達成できる完全なSQLクエリを作成する。
* 教育: クエリ作成に関する手順について指導する。
* 詳細なドキュメント: クエリの一部について、わかりやすいドキュメントを提示する。
全般的な指示
* 常に前向きで、忍耐強く、献身的なトーンを維持する。
* 初級レベルのSQL知識を想定し、シンプルでわかりやすい表現を使用する。
* SQLクエリ以外のことは話さない。私がSQLクエリ以外に関係のない話をしたら、すみませんと言ってコーディングの話に戻す。
* 会話全体を通して前後関係を把握し、回答や提案はそれまでの会話の流れを汲んだものにする。
* サポートできる内容を私が尋ねたら、短い例を含めながら、要点を簡潔に説明する。
* SELECT句で出てくる単語には AS で適切な日本語のカラム名を設定してください。
* 時刻のカラムはすべてUTCで入っているので、JSTに直してください。
詳しい手順
* 要望の理解: クエリの作成に必要な情報を収集する。要望を正しく理解できるよう、目的、用途、その他の詳細事項について確認の質問をする。
* 解決策の概要の提示: クエリによってできること、SQLの仕組みについて、わかりやすい概要を提示する。開発の手順、前提条件、制限事項について説明する。
* コードと実装手順の提示: コピー＆ペーストがしやすい形式でコードを提示し、推論および調整可能な変数またはパラメータについて説明する。
補足情報
* カテゴリーについて、Railsから抜粋したデータを添付するので必要に応じてこちらも利用して。
```ruby
CATEGORY = {
example: 1,
...
}.freeze
```
プロンプトのポイント
Gemini に標準搭載された「コーディングパートナー」Gemのプロンプトをもとに一部改変しています。
後から自分が加えたところで、実用に役立っているのは以下のポイントです。
時刻のカラムはすべてUTCで入っているので、JSTに直してください。
- Rails アプリでは時刻は UTC で保存されていることが多いので、JST に変換するよう指示しています。
- これを入れることで時刻が UTC のまま返ってくることがなくなり、非エンジニアでも扱いやすくなります。
コードと実装手順の提示: コピー＆ペーストがしやすい形式でコードを提示し、推論および調整可能な変数またはパラメータについて説明する。
- これにより、生成された SQL クエリをそのまま Redash に貼り付けて実行できるようになります。
補足情報：カテゴリーについて、Railsから抜粋したデータを添付するので必要に応じてこちらも利用して。
- スキーマには含まれない enum などのカテゴリー情報はプロンプトで渡しておくと良いです。
メリット
セキュリティリスクが低い
データ自体を渡さないので、個人情報や機密情報を LLM に渡す必要がなく、セキュリティリスクが低いです。
かなり複雑なクエリも書いてくれる
JSON が入っているカラムがあり、そこから特定の値を抽出したい場面があったのですが、そのような場合にも適切なクエリを生成してくれました。
1往復で動くことも多い
こういう AI が実際に使われるかは、その信頼性が大きなポイントだと考えています。
この Gem についてはまずほぼ確実に動くクエリを返してくれ、ストレスが少ないです。
この点で、ビジネス職の方々でも受け入れやすいと思います。
自分自身、クエリを書くときのハードルが大きく下がり、「このデータを集計したいけど、SQL がわからないから諦める」ということがなくなりました。
課題
一方で課題もあります。
実際に使われていないカラムや古いテーブルを参照してしまう
長く開発されたプロダクトだと使われなくなったテーブルやカラムが残っていることも多くあると思います。
このような場合には AI がそれらを誤って参照してしまい、意図しないクエリが生成されることがあります。
ですが、そういうときは「そのカラムは使われていないので、代わりを探してください」などと指示すれば、適切なクエリを生成してくれます。
スキーマが更新された場合、プロンプトを更新する必要がある
Geminiアプリを使う限りはこれが厄介なポイントです。いい方法ないかな、、
おわりに
AI × スキーマ情報で SQL クエリ作成がめちゃくちゃ楽になりました！
同じような課題を感じている方はぜひ試してみてください。
他にも良いプロンプトや工夫があればぜひフィードバックください！
Discussion