データエンジニアの皆さん、Snowflakeでの開発作業、もっと快適にしませんか?
SnowflakeのWeb UI(Snowsight)は非常に優秀ですが、複雑なパイプラインやアプリケーション開発を行う際、SQLの作成、Gitでのバージョン管理、そしてデプロイ作業を一つの統合された環境で完結させたいと思うはずです。
そこで活躍するのが Snowflake CLI (Command Line Interface) と VS Code (Visual Studio Code) の組み合わせです。本記事では、この最強のコンビを設定する方法と、その絶大なメリットを解説します。
1. なぜVS CodeでCLIを使うべきか? 3つのメリット
VS Code内でSnowflake CLIを使う最大の利点は、開発ワークフローの「分断」をなくし、「統合」することにあります。
メリット ① 統一された環境での開発・デバッグ
- コーディングの快適性: VS Codeの強力なシンタックスハイライトやコード補完機能(拡張機能による)を活かし、SQLやSnowpark(Pythonなど)のコードを快適に記述できます。
- Git連携のシームレス化: コードの作成、変更、コミット、プッシュといったバージョン管理(Git)の作業を、ターミナルやサイドバーを使ってVS Code内ですべて完結できます。
メリット ② CLIによる高速な管理と操作
Web UIを開くことなく、VS Codeの統合ターミナルから直接コマンドを実行し、以下の作業を迅速に行えます。
- デプロイ作業の効率化: 開発した Snowpark や Streamlit アプリケーションのコードを、CLIを通じてSnowflake環境にパッケージ化し、コマンド一つでデプロイできます。
- オブジェクト管理: データベース、テーブル、ビューといったオブジェクトの DDL(作成・変更・削除) コマンドを、スクリプト化して実行できます。
- データ転送の簡素化: ローカルファイルとSnowflakeステージ間で、データのアップロードやダウンロードを簡単かつ迅速に実行できます。
メリット ③ dbtプロジェクトの完全統合
dbt (data build tool) を利用したデータ変換パイプラインを構築している場合、この連携は必須級です。
- 全ライフサイクルの管理: dbt の実行(
dbt run)、テスト(dbt test)、ドキュメント生成といったコマンドをVS Codeのターミナルから直接実行し、データ変換のライフサイクル全体を一元管理できます。
2. Snowflake CLIをVS Codeで使えるようにする手順
設定は非常にシンプルです。主要な手順は「CLIのインストール」と「接続プロファイルの作成」の2ステップです。
ステップ 1: Snowflake CLIのインストール
まず、ご自身のPCのコマンドライン環境にSnowflake CLIをインストールします。Pythonのパッケージ管理ツールであるpipを使用するのが最も一般的です。
pip install snowflake-cli
インストール後、sf --version などと入力してバージョンが表示されれば成功です。
ステップ 2: VS Codeで接続プロファイルを設定
次に、VS Codeを起動し、Snowflakeアカウントへの接続情報を設定します。これは、VS Codeの統合ターミナル内で行います。
① ターミナルの起動
VS Codeのメニューから 「ターミナル」→「新しいターミナル」 を選択し、統合ターミナルを起動します。
② 接続プロファイルの追加
以下のコマンドを実行し、Snowflakeアカウントの接続プロファイルを作成します。
Bash
sf connection add
コマンドを実行すると、VS Codeのターミナル内で、接続名、アカウント識別子、認証方法(パスワード、SSO、キーペアなど)の入力を求められます。指示に従って情報を入力してください。
【設定例】
- プロファイル名:
dev_account - アカウント識別子:
xxxxxx.ap-northeast-1 - 認証方法:
password
ステップ 3: 接続のテストと利用開始
設定が完了したら、簡単なコマンドで接続を確認しましょう。
Bash
sf connection list # 設定したプロファイルを確認
sf sql execute -c dev_account -q "SELECT CURRENT_VERSION()"
上記コマンドの -c の後に、ステップ2で設定したプロファイル名(例: dev_account)を指定することで、その設定を使ってクエリが実行されます。
接続情報は config.toml (または CLIのプロファイル設定) で一元管理し、snowflake.yml ではその接続プロファイル名を参照するのが最も効率的で推奨される方法です。
これにより、アカウント情報が変わっても snowflake.yml のプロジェクトファイルに手を加える必要がなくなります。
💻 接続情報の管理:CLIプロファイルとプロジェクト設定の分離
1. config.toml / CLIプロファイル の役割(接続の一元管理)
config.toml は、Snowflake CLIのグローバルな設定ファイルであり、通常はユーザーのホームディレクトリ(~/.snowflake/config.toml)に保存されます。
このファイルに、異なる環境やアカウントへの接続情報(アカウント識別子、ユーザー名、認証方法、ウェアハウス、ロールなど)を「プロファイル」として複数登録します。
ご質問の通り、config.toml と snowflake.yml の使い分け、特に複数アカウントを扱う際の管理方法について、非常に重要なポイントです。
結論から言うと、接続情報は config.toml (または CLIのプロファイル設定) で一元管理し、snowflake.yml ではその接続プロファイル名を参照するのが最も効率的で推奨される方法です。
これにより、アカウント情報が変わっても snowflake.yml のプロジェクトファイルに手を加える必要がなくなります。
💻 接続情報の管理:CLIプロファイルとプロジェクト設定の分離
1. config.toml / CLIプロファイル の役割(接続の一元管理)
config.toml は、Snowflake CLIのグローバルな設定ファイルであり、通常はユーザーのホームディレクトリ(~/.snowflake/config.toml)に保存されます。
このファイルに、異なる環境やアカウントへの接続情報(アカウント識別子、ユーザー名、認証方法、ウェアハウス、ロールなど)を**「プロファイル」**として複数登録します。
| 設定ファイル | 役割 | 変更の必要性 |
config.toml | アカウント接続情報の定義と一元管理 | アカウント情報(パスワード、ロールなど)が変更されたときのみ修正。 |
【メリット】
- アカウント情報の分離: 接続情報がプロジェクトコードから切り離されるため、セキュリティが向上し、Gitなどで誤って機密情報をコミットするリスクが減ります。
- 切り替えの容易さ: 異なるアカウントへ接続したい場合、
config.tomlを直接修正するのではなく、単に使用するプロファイル名を変えるだけで済みます。
2. snowflake.yml の役割(プロジェクトの定義と参照)
snowflake.yml は、プロジェクト固有の設定を定義するファイルです。接続情報そのものではなく、どの接続プロファイルを使うかを指定します。
| 設定ファイル | 役割 | 変更の必要性 |
snowflake.yml | デプロイ対象の定義と、使用するプロファイル名の指定 | プロジェクトの構成やデプロイ先データベース/スキーマが変わったときに修正。 |



