1年以上ぶり、かなり久しぶりの投稿です！
生成AIの進化のスピード早すぎますね。
この記事もせっかくなので（？）、ほぼ全編AIに作ってもらいました！
Nano Bananaでいい感じの説明画像も作ってもらいました！
おかげで、全体的に「AIみ」全開な文体と画像になっていますがご容赦ください！
（生成AIがつくる記事タイトル、文章中の章タイトルってなぜか生成AIを感じさせますよね。生成AI構文的な情緒を感じられるので、あえてそのまま使っていきます！）
前段のPart1は実際に既に実践している内容で、Part2は生成AIに将来的な展望としてアドバイスもらった内容です。そのためPart2はほぼAIの妄想ですが、できたらいいなぁということで未来へのメモとして残してます。
これ以降、ほぼGeminiが作成してくれたまま掲載しています！
今回は、私たちが現在進行形で取り組んでいる「生成AIを活用したSQL開発」の試行錯誤についてお話しします。
正直に言うと、私たちはまだ「最強のデータ基盤」を完成させたわけではありません。
日々の業務で「AIにもっとうまくSQLを書かせるにはどうすればいいか？」と悩み、試行錯誤してたどり着いた独自の「ハック（工夫）」が、AIとの対話を通じて「次世代のアーキテクチャ」へと昇華されつつある——。
そんな、現在地と未来の構想を包み隠さず共有したいと思います。
【人間が追記】
正直に言うと、私たちはまだ「最強のデータ基盤」を完成させたわけではありません。
正直に言うともなにも、「最強のデータ基盤を完成させました！」なんて言ってないのに…笑
その後に続く文章もなんだか壮大な雰囲気でAIっぽいなぁと思いました。
【Part 1】 現在の実践：AIに文脈を伝えるための「手紙」
私たちが直面していた課題は、一般的な「Text-to-SQL」の限界でした。
AIに「このテーブルで分析して」と頼んでも、業務特有のルール（滞在の定義など）や、Snowflakeのベストプラクティスを無視したコードが返ってくる。毎回プロンプトで指示するのは面倒すぎる。
そこで私たちが始めたのは、「SQLファイル自体に、AIへの手紙（メタデータ）を埋め込む」という、非常にアナログで泥臭いアプローチです。
やっていること：JSONメタデータの埋め込み
すべてのSQLファイルのヘッダーに、以下のようなコメントブロックを書いています。
/*METADATA
{
"file": "visit_analysis_a-city.sql",
"description": "A空港利用者の県内周遊分析。滞在定義は15分ルールを採用。",
"tags": ["滞在解析", "inbound", "airport"],
"inputs": ["raw.gps_logs", "master.mesh_codes"],
"outputs": ["mart.visit_summary"],
"dependencies": ["01_preprocessing.sql"]
}
METADATA*/
-- 以下、実際のSQL
WITH ...
【人間が追記】
非常にアナログで泥臭いアプローチです。
とはありますが、CLAUDE.mdにメタデータの構成、利用目的、SQL自体のガイドラインを設定しているため、このメタデータ埋め込み自体はClaude Codeに指示してアップデートしています。
「クエリを書く（or それ自体もClaudeが作成）→ Claudeにメタデータ更新してもらう」というワークフローです。
VSCodeのClaude Code拡張を利用しているので、そこまで運用負荷はなく、サクッとできます！
作業のたびに更新していくので、複数のSQLの関係性もdependenciesでちゃんと記録できます。
なぜこれをやっているのか？
理由はシンプルで、「AIがファイル単体を見て、全てを理解できるようにするため」です。
- 検索性: AIは日本語の description や tags を見て、過去の膨大なクエリの中から「使えるロジック」を探し出せます。
- ハルシネーション抑制: 「入力と出力はこれを使って」とJSONで明記されているため、AIは勝手なテーブル結合をせず、仕様通りのコードを書くようになります。
私たちはこれを「Vue.jsのSFC（単一ファイルコンポーネント）みたいなものだ」と捉えています。ロジックと仕様を1箇所に凝集させることで、AIにとっての可読性を極限まで高める作戦です。
【人間が追記】
私たちはこれを「Vue.jsのSFC（単一ファイルコンポーネント）みたいなものだ」と捉えています。
とはもともと捉えておらず、AIに聞いたらこれはSFCみたいなものだよと言われました。
AIが勝手に「どやっ！」ってくれました。
目的自体は記載のとおり「検索にヒットする」「AIにとっての可読性を高める」という意図で始めています。人間が検索するときもヒットしやすくて助かります。
【実演】 AIはどうやってコードを書くのか？
このメタデータがあるおかげで、今の私たちの開発現場では、以下のような体験が日常になっています。
Scene 1: 「曖昧な指示」で過去の資産を探す
エンジニアは、具体的なファイル名を覚えておく必要はありません。
👨💻 人間:
「新しい案件で『空港利用者の周遊分析』をやりたいんだけど、参考になる過去のクエリある？ 滞在時間は15分定義で。」
🤖 AI:
「タグ airport 滞在解析 で検索しました。以下のクエリが参考になりそうです。
1. 2024/02_A空港案件/1_周遊分析/1-2_OD分析.sql
2. 2024/03_B空港案件/4_旅程分析.sql
特に2つ目のB空港のクエリは、今回の要件に近い『広域周遊』のロジックを含んでいます。」
AIはファイルの中身（メタデータ）を理解しているため、「ファイル名検索」ではなく「意味検索」で、大量のファイルから最適な「テンプレート」を提案してくれます。
Scene 2: テンプレートにはできない「連鎖」と「カスタマイズ」
ここからが真骨頂です。単に既存のSQLのパラメータ（変数）を変えるだけならストアドプロシージャでも十分ですが、実務では「案件ごとに微妙に異なるロジック」が求められます。
👨💻 人間:
「ありがとう。
次に、この結果を使って『空港到着後にA神社へ直行した人』だけを抽出する後続のクエリを作って。
ただし、A神社の滞在は60分以上に限定したい。」
🤖 AI:
「承知しました。先ほどのクエリ（mart.visit_summary）を入力とする新しいSQLファイルを作成します。
作成ファイル: 02_shrine_direct_access.sql
実装するロジック:
1. 前段で作った mart.visit_summary を入力テーブルとして指定（依存関係を設定）。
2. A神社のポリゴンと結合し、空港到着時刻と比較。
3. 空港→神社の間に他の観光地滞在がないユーザーのみを抽出。
4. 滞在時間フィルタを > 60 分に設定。
以下の内容でファイルを生成しました。メタデータの dependencies も自動でリンクさせています。」
このように、AIは「複数のクエリを連鎖させてパイプラインを構築する」ことや、「直行判定などの複雑なロジックを案件に合わせて即興で実装する」ことができます。
これにより、定型的な分析であれば、ほぼAIとの対話だけでデータパイプライン全体が完成するレベルにまで到達しています。
【人間が追記】
定型的な分析であれば、ほぼAIとの対話だけでデータパイプライン全体が完成するレベルにまで到達しています。
ここまで言い切る自信は流石にありません！
しかし、確実にゼロから考えるよりは圧倒的に早く、ほぼ正しいものが作成されている状態にはあると感じています！
ただし、ここでも重要なのは「コンテクスト」で、冒頭での「◯◯がやりたいんだけど」の指示内容をできるだけ明確にするというのもかなり重要です。
【Part 2】 AIが描いた未来：dbt × AI の完全自動化構想
さて、ここから先の話は、今の私たちがまだ実現できていない「未来の構想」です。
上記の運用について、壁打ち相手のAI（Gemini）に相談したところ、
「そのアプローチは素晴らしいが、もっと自動化できる。dbtと組み合わせれば最強のF1マシンになる」
という、私たちの想像を超えた提案が返ってきました。
以下は、AIが提示してくれたロードマップです。
AIが提案する「Writer / Guardian / Runner」体制
AIは、現在の「JSON埋め込み」を進化させ、以下の3つの役割でパイプラインを組むべきだと提言しています。
① Writer (AI & Human)
- 現状: 人間がAIに指示してSQLを書く。
- 未来: 人間は「やりたいこと」だけを伝え、AIが過去の資産（JSON付きSQL）をテンプレートとして、爆速でドラフトを作成する。
② Guardian (CI/CD)
- 現状: 目視チェック。
- 未来: ここが重要です。AIが書いたコードをそのまま通すのではなく、「SQLパーサー（sqlglot等）」を使った自動検知システムを導入します。
- 「SQLの中身」と「ヘッダーのJSON」に矛盾がないか（使っているテーブルがinputsに書いてあるか）を機械的にチェックし、ミスがあればマージをブロックします。
③ Runner (dbt)
- 現状: 手動実行やスクリプト実行。
- 未来: 信頼できる実行基盤として dbt を採用します。
- ただし、人間が schema.yml を手書きする（YAML地獄）必要はありません。「SQLヘッダーのJSONから、dbtの設定ファイルを自動生成する」のです。
- これにより、私たちは「AIに伝わるSQL」だけを書き、裏側では堅牢なdbtパイプラインが回るという世界が実現します。
【人間が追記】
正直、Gemini提案の未来像の具体的な内容が理解できていません！（現在やっていないことが多いので）
しかし、概念と「さらに発展させていける可能性がありそうだ」というところは理解できたので、今後の資料として活用したいと思います！
まとめ：走りながら考える
私たちが今実践しているのは、「SQLにJSONを埋め込む」という小さな工夫に過ぎません。
しかし、それをAIに見せたことで、「じゃあ次はこうしませんか？」というエンジニアリングの道筋（ロードマップ）が示されました。
- 現在: AIが読みやすいコードを蓄積する（メタデータ埋め込み）。
- 未来: dbt等のモダンスタックと融合させ、完全自動化を目指す。
「車輪の再発明だ」と笑われるかもしれません。しかし、AIという全く新しいドライバーが運転席に座るなら、車体（開発フロー）も新しく作り直す必要があるはずです。
私たちはこの「AIネイティブなデータ開発」の実験を、これからも楽しみながら続けていきます。
【人間が追記】
「車輪の再発明だ」と笑われるかもしれません。しかし、AIという全く新しいドライバーが運転席に座るなら、車体（開発フロー）も新しく作り直す必要があるはずです。
この最後のパンチライン、謎の納得感あって気に入りました笑
この1年で、AIは Copilot（副操縦士）から Pilot（操縦士）になっていますね。
（人間は一体どこへ…??? Control Tower(管制塔）???）