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(管制塔）???）