GitHub Copilot Agentを使ってSQL作成を効率化！

 はじめにこんにちは、分析プロデュースグループの平田です！
アナリストとして働いている私が、毎日取り組んでいるSQL作成業務の効率化について、今回はお話しします。

この記事では、「Github Copilot Agent」と「Python」を使って、数百行に及ぶ複雑なSQLを書き上げる業務をどう効率化したのか、その試行錯誤のプロセスと結果、そして今後の改善について語ります。
【まとめ】

✔︎ テーブル情報を事前に用意して、生成AIにSQLを作成してもらう

✔︎ 作成したSQLをPythonで自動実行・チェックする仕組みを実装

✔︎ エラーが発生したら自動で修正してもらい、業務効率をアップ！
 背景：日々のSQL作成業務とその悩み普段、私が直面しているのはこんな課題です…
生成AIとの煩雑なやり取り

生成AIにテーブルの情報やデータ型、日付フォーマットなどを会話の度に何度も説明する必要があり、その都度手間がかかっていました。
膨大なSQLの作成

マーケティングに使うユーザー抽出や分析用データ作成など、何百行ものSQLを書かなければならず、複雑な加工ロジックが散在している。
試行錯誤の繰り返し（ループ）

作成したSQLをコピーして実行、エラーが返るとまたエラーログを渡して修正依頼…この繰り返しがボトルネックに。

自分で修正すると、Github Copilotが作成した最新版と差分が生まれ、次の修正を依頼したときに先祖返りしてしまうことも。
 試行錯誤！生成AIとPythonで自動化フローを構築そこで、こんな流れで業務の効率化に挑戦しました。
 自動化フローの全体像前提情報の登録

各テーブルの構成、データ型、サンプルデータ、サンプルSQL、加工Tipsをそれぞれのpromptファイルにまとめます。
生成AIでSQL生成

全体フローのプロンプト（「テーブル情報をもとにSQLを生成&保存、実行チェック」）を生成AIに渡して、自動でSQLファイルを作成します。
Pythonで実行・チェック

生成されたSQLをPythonスクリプトで実行。エラーがあればエラーログをフィードバックし、自動修正を促す仕組みにしています。
 具体的な取り組みポイント以下は、私が実際に構築したディレクトリ構成とファイル例です：
rules / conversation_rules.prompt.md

基本的な会話のルール。

テーブル情報をもとにSQLを生成&保存、pythonファイルを実行してSQLのが正しいかをチェックすること。また、SQL作成の決まりや会話の好みを記載。
tables / <テーブル名>.prompt.md

テーブルの情報を記載。

サンプルデータを載せることでデータの特徴を判断してもらう。
## テーブル名
users

## 説明
ユーザー情報のテーブル。user_idをキーにorderテーブルと紐付け可能

## sample SQL
```sql
select
  user_id as "顧客ID",
  name as "顧客名",
  address as "住所"
from
  users
```

## sample data
| 顧客ID | 顧客名   | 住所                             |
| ------ | -------- | -------------------------------- |
| 1      | 山田太郎 | 東京都新宿区西新宿        |
| 2      | 佐藤花子 | 大阪府大阪市中央区難波    |
| 3      | 鈴木次郎 | 愛知県名古屋市中区栄       |
sql /

作成されたSQLをファイルで保存してもらう。
utils / query_checker.py

SQL作成後このpythonファイルを実行し、SQLが正しいかをチェック。
 実際のGithub Copilot Agentの回答例実際の動きが確認できる簡単な例をお見せします。
[in] 今月何回メール配信したかをユーザー別に抽出するSQLを作成して！
[out]
まずスキーマ情報を確認してから、メール配信の分析に関する
SQLを作成しましょう。メール配信に関するテーブル情報を探します。

"› Searched for files matching /prompts/tables/**, 14 matches" 

配信履歴に関するスキーマ情報が見つかりました！ 
まずはその内容を確認して、今月の配信回数を抽出するSQLを作成していきましょう。

Read メール配信履歴.prompt.md 

スキーマ情報を確認できました。[メール配信履歴テーブル]というテーブルに格納されているようです。 
今月（2025年4月）のメール配信回数を集計するSQLを作成していきます。 

このテーブルには以下の重要な列があります： 
 • email_id： メルマガID 
 • delivery_timestamp： 配信日時 
 • delivery_status： 配信ステータス 

それでは、今月のメール配信回数を集計するSQLを作成し、ファイルに保存しましょう。 
ファイル名は メール配信集計_今月.sql です。

このSQLでは以下の処理が実行されます： 
 ・ 2025年4月1日から4月30日までの期間に配信されたメールを対象にします。 
 ・ 「配信完了」ステータスのメールのみを集計します。 
 ・ ユーザーごとに、配信回数、成功数、失敗数、および総配信数を集計します。 
 ・ 最後に全体の合計も表示します。

Pythonでクエリを検証してみますか？
検証のため、先ほど作成したSQLを実行してみましょう。  

python3 query_checker.py メール配信集計_今月.sql

SQL検証が完了しました！  クエリは正常に検証され、実行可能と確認されました。  
テスト実行では構文エラーもなく、正しい実行計画が生成されました。
 結果と今後の展望嬉しいことに、一連のプロセスが無事稼働し、SQL作成の自動化に向けた第一歩となりました！

とはいえ、完璧ではありません。今後取り組みたい課題や工夫は…？
 ● 現在の課題レビュー作業の手間

AIが生成したSQLのレビューは、どうしても自分で作成する場合よりミスを見落としがち。

検証する仕組みや、実際にSQLを書かない人でもレビューを完遂できる手法については、いまだ試行錯誤の段階にあり、改善していきたいところです。

また、生成AIの進化によって、これらの課題が解決されることにも期待しています！
意図通りのデータ抽出のチェック

要件定義の不備や、私の頭の中の情報がうまく言葉にできていないケースがあり、意図通りの処理かを自動判定するのは難しい。細かいニュアンスや意図の伝え方がまだまだ課題です。
 ● 次へのチャレンジ件数チェックの自動化

レビュー高度化のファーストステップとして、抽出した件数が意図通りかどうかのチェック機能を実装していきたい。
「秘伝のタレ」とも言えるデータ加工方法の蓄積

使い込むほどに見えてくる効果的なデータ加工テクニックを、プロンプトにどんどん追加していきたい。
分析の自動化への拡張

最終的には、SQLの作成から抽出データの分析まで、ある程度自動で行える体制を目指します！