Snowflake Cortex Code CLIが2026年2月にGA（一般提供）になりました1。自然言語で指示すればSQLが生成され、インストールは1コマンドで完了します。
curl -LsS https://ai.snowflake.com/static/cc-scripts/install.sh | sh「売上データを月別に集計して」と入力すれば、テーブル構造を読み取って適切なSQLが出てきます。dbtプロジェクトのコンテキストも理解してくれるので、「このモデルのテストを追加して」という指示も通ります。
便利です。しかし私は、ここで立ち止まって考えるべきことがあると感じています。 SQLを書く能力そのものの価値が下がったとき、データエンジニアは何をする人になるのか という問いです。
SQLを書く能力の価値が変わった
このツールが成立する前提には、Snowflakeの「データを動かさず計算を動かす」設計思想があります。その背景はSnowflakeが「データを動かさない」設計を選ぶ理由にまとめていますが、ここではその上でエンジニアの役割がどう変わるかに焦点を当てます。
「書く人」から「検証する人」へ
AI登場の前後で、データエンジニアのワークフローは根本的に変わります。
従来は「問い→人間がSQL記述→結果」でした。AI時代は「問い→AIがSQL生成→ 人間が検証 →結果」になります。一見、人間の負担が減ったように見えます。ですが実際には、 検証というステップが新たに加わり、そこには高い専門性が求められます 。
AI生成SQLの落とし穴
もっともらしい誤り
AI生成コードの精度に関する研究では、単純なクエリの正答率は高い一方、複雑なクエリになるほど精度が下がることが示されています2。私たちが現場で実感しているのも、まさに同じことです。
単一テーブルの集計は問題ありません。2テーブルのJOINも、だいたい正しく出てきます。しかし 3テーブル以上のJOINが必要になると、AIは「自信満々に間違える」 ようになります。生成されたSQLは文法的に正しく、実行もできます。結果も返ってきます。しかし、その結果が正しいかどうかは、別の話です。
業務文脈を理解しない
典型的な失敗パターンがあります。
「去年と今年の売上比較を出して」とAIに依頼する。AIはカレンダー年（1月〜12月）で集計するSQLを生成する。しかし、その会社の会計年度は4月始まりだった。結果は正しい形式で返ってきますが、 ビジネス上の意味としては完全に間違っています 。
「解約率を出して」と依頼する。AIはシンプルな割り算のSQLを生成する。しかし、その会社では「無料トライアルからの離脱」と「有料契約の解約」を区別しており、KPIとして見ているのは後者だけだった。AIには、その区別がわかりません。
ミッションクリティカルな場面でのリスク
経営会議に出す数字、投資家向けのレポート、監査対応のデータ。これらを自然言語クエリで生成し、 検証なしに提出するのは危険 です。AI生成SQLを本番運用に組み込む場合、人間による検証プロセスは省略できません。
検証力を鍛える具体的なアプローチ
では、どうすれば「検証する力」を身につけられるのでしょうか。
まず、 AI生成SQLを必ず読む ことです。生成されたSQLのJOIN条件、WHERE句、GROUP BYを目視で確認します。特にJOIN条件は、意図しないクロスジョインやデータの膨張を引き起こしやすい箇所です。
次に、 小さなデータセットで結果を手計算と照合する ことです。10件のサンプルデータで手計算した結果と、AIが生成したクエリの結果が一致するか。ここで差異があれば、ロジックに問題があります。
そして最も重要なのは、 「何を聞くべきか」を設計する力 です。Cortex Code CLIは「どうやって聞くか」を解決してくれます。しかし「何を聞くか」「なぜそれを聞くのか」は、人間にしか決められません。ビジネスの文脈を理解し、適切な問いを立てる能力。これが、AI時代のデータエンジニアの中核スキルになります。
こうした検証を仕組みとして支えるのが、dbtによるテストとレビューです。AIが書いたSQLを人とテストの両方で検証する体制については、dbtとSnowflakeで信頼できるデータ基盤を作るで具体的に書いています。
ツールとしての価値は高い
誤解しないでください。Cortex Code CLIは優れたツールです。
探索的にデータを見るとき、テーブル構造を素早く把握したいとき、dbtモデルのテストコードを生成したいとき。こうした場面では、生産性が明確に上がります。エラーメッセージの説明と修正提案も的確で、「このエラーはNULL値が原因です」のように具体的に教えてくれます。Snowflakeアカウントがなくても使えるスタンドアロン版も用意されています。
ポイントは、 ツールの能力を正しく理解し、適切な場面で使うこと です。探索的分析には積極的に使う。本番運用のクエリには検証プロセスを必ず挟む。この使い分けができるかどうかが、データエンジニアの腕の見せどころになります。
エンジニアの仕事は「問いの設計」になる
SQLを書く時代が終わるわけではありません。しかし、SQLを書くことだけがエンジニアの価値だった時代は、終わります。
AIがコードを生成する時代に求められるのは、「正しい問いを立てる力」「生成された結果を検証する力」「業務文脈をシステムに翻訳する力」の3つです。皮肉なことに、AIが高度になるほど、 人間にはより深い専門性が求められます 。そもそもAIが力を発揮できるようにデータを整える視点は、AI-ready dataという考え方にまとめました。
Cortex Code CLIのようなツールは、エンジニアの仕事を奪うのではなく、仕事の重心を移動させます。手を動かす時間が減る分、頭を使う時間が増える。それは脅威ではなく、この職種の進化だと私は考えています。
Footnotes
-
Snowflake「Cortex Code CLI - General Availability」（2026年2月GA） ↩
-
Liu et al.「Is Your AI-Generated Code Really Correct? A Systematic Evaluation of Large Language Models for Code Generation」NeurIPS 2023。複雑なクエリほどLLMの正答率が低下する傾向を報告。 ↩