Snowflake Workspace の基本操作を試してみた
2025.08.24はじめに
2025年6月に Snowflake Workspace がパブリックプレビューとなっています。
本機能について、しっかりと触ることはできていなかったので、基本操作や Workspace 特有の機能を試しつつ、その内容を記事としました。
注意点として、本機能は執筆時点（2025年8月24日）でプレビューです。また、検証内容も執筆時点のものである点にご注意ください。
前提条件
前提として Workspace を利用するために、以下を確認します。
- 対象のユーザーでパーソナルデータベースを利用可能か
- セカンダリ ロールを明示的にブロックするセッション ポリシーが有効化されていないか
パーソナルデータベースの利用
Workspace を利用するには対象のユーザーでパーソナルデータベースを使用できる必要があります。パーソナルデータベースは Workspace の保存領域として使用されます。
このためには、アカウントまたはユーザーで設定できる ENABLE_PERSONAL_DATABASE パラメータを有効化します。
試しにパーソナルデータベースを無効にします。
ALTER ACCOUNT SET ENABLE_PERSONAL_DATABASE = FALSE;
この状態で Workspace にアクセスすると下図の表示となります。
セカンダリ ロールの有効化
セカンダリ ロールはセッションポリシーで無効化することができます。
CREATE SESSION POLICY block_secondary_roles
ALLOWED_SECONDARY_ROLES = (); --空とすることでセカンダリロールを許可しない
--アカウントでセカンダリロールを無効化
ALTER ACCOUNT SET SESSION POLICY policies_db.session_policies.block_secondary_roles;
ドキュメントにあるように、セカンダリ ロールを明示的にブロックするセッション ポリシーがある場合も Workspace が機能しません。
Workspace の作成
Workspace は Snowsight の「Projects > Workspaces」より操作できます。
下図の赤枠の部分より新規の Workspace を作成できます。
「New」からは Snowflake 上で各種ファイルを保持する Workspace を作成できます。「From Git repository」からは Git リポジトリ上でファイルを管理する Workspace を作成できます。
画面構成などは公式ドキュメントにまとまっていますので、こちらをご参照ください。
また、Workspace ではこれまでも利用できたワークシートを開き編集、SQL の実行も可能です。ただし、この際、以下に記載があるようにコンテキストが同期されない点や、同時に開いて編集すると、変更が失われる可能性がある点には注意が必要です。
Git 統合
Workspace は Git リポジトリと統合できます。
これにより Workspace のファイルを Git リポジトリのブランチと同期させることが可能になります。より具体的には、予めリモートリポジトリを作成しておくことで、Workspace からリポジトリに対する各種 Git 操作を行えます。
Workspace から以下のような基本的な Git 操作が可能です。
- ブランチの切り替え、新しいブランチの作成、リモートブランチの取得
- 最新の変更のプル
- 更新内容のコミットとプッシュ
- コンフリクトの解決
これまでの Snowflake でも Git リポジトリとの連携は可能でしたが、Workspace では Snowflake 側からの変更（コミット、プッシュなど）も直接行えます。 これは Notebook の機能と同様です。
また、Workspace 特有の機能として、パブリックなネットワークを使用できる場合、リポジトリへの接続時にアクセストークンの代わりに OAuth2 認証を利用できます。特に各個人の開発時の認証に使える方式です。
OAuth2 認証による Workspace の作成
以降で、OAuth2 認証による Workspace を作成してみます。
前提として、Snowflake 側で API 統合オブジェクトの作成が必要です。
CREATE OR REPLACE API INTEGRATION my_git_api_integration
API_PROVIDER = git_https_api
API_ALLOWED_PREFIXES = ('https://github.com/ユーザー名/')
API_USER_AUTHENTICATION = (TYPE = SNOWFLAKE_GITHUB_APP)
ENABLED = TRUE;
リモートリポジトリ作成後、Workspace 上の「From Git repository」を選択します。
次の画面で、Snowflake の Workspace と統合したい Git リポジトリの HTTPS URL を記入します。統合オブジェクトには、事前に作成したものを指定し、認証方法として「OAuth2」を選択します。
GitHub の認証画面に遷移します。GitHub にサインイン済みの場合は、そのまま次のステップへ進みます。
Snowflake が GitHub アカウントに対して、リポジトリへのアクセスを許可するよう求めます。ここで「Authorize snowflakedb」をクリックし Snowflake の GitHub App をインストールします。
サインイン ステータスが更新されるので「Create」をクリックします。
すると、ここでは下図のエラーとなりました。
この時点では Snowflake がリポジトリへのアクセス権限を持っていないためでした。図中の「Check Github configuration」をクリックすると、Snowflake の GitHub App 設定画面に直接遷移します。
ここでは下図のように指定のリポジトリのみアクセスを許可するように設定し「Install」をクリックしました。
この設定は、GitHub 側の設定画面からも後で確認、編集が可能です。
上記の設定後、Workspace を作成できました。
基本操作
Git を使った基本操作を試してみます。
- ブランチ作成
Changesタブからブランチ名をクリックし「＋New」よりブランチを作成できます。
現在のブランチもChangesタブに表示されます。
Github 側にも追加されています。
- プッシュ
ファイルを編集後Pushをクリックすると、コミットメッセージを入力できます。メッセージを追加後プッシュできます。
Github 側で確認すると、 Snowflake 上のユーザー名での編集を確認できます。
この点はドキュメントに記載があります。デフォルトでは、Snowflake 上のユーザー名・メールアドレスの情報が使用されます。
プッシュ後は、Github 側でプルリクエストを作成し main ブランチにマージします。
その後、Workspace から main ブランチに切り替えPullをクリックすると Workspace の main ブランチでも反映を確認できます。
クレデンシャルを編集
上述の通り、デフォルトでは Snowflake 上のユーザー名・メールアドレスの情報が使用されます。変更する際はChanges タブ内の三点リーダーをクリックし「Edit Credentials」を押下します。
下図の表示になるので、ここでは Github 側で登録しているユーザー名・メールアドレスに変更しました。
この状態でもう一度プッシュしてみました。
すると下図のように Github 上のユーザーでの変更となっていました。
異なるユーザーで同じリポジトリから Workspace を作成
Workspace そのものは共有できません。異なるユーザーで編集したい場合は、各ユーザーで上記のような Git 統合による Workspace を作成します。
この際、使用する API 統合などの使用権限も必要です。
同様に Github にサインインします。
サインイン後、同じリポジトリを使用する Workspace として作成できます。
この際、検証用に追加したユーザーはメールアドレスを設定していなかったため、ブランチを追加しようとすると下図のエラー（メールアドレスが必要）となりました。
先の手順でクレデンシャルを編集し、Github 上のメールアドレスを追加しました。
※ここでは Github 上の同じユーザーのメールアドレスを指定
クレデンシャルでメールアドレスを指定後、Workspace からもブランチの作成～プッシュまで問題なく行えました。
Github 側でみるとメールアドレスのみでユーザーが識別されているようでした。
考慮事項
Workspace で Git 関連の基本操作は行えますが、例えば以下のような Snowflake CLI で行える操作を直接 Workspace から行うのは難しいと感じました。
- Python ファイルによる UDFやストアドプロシージャの実行・デプロイ
- jinja 記法を使用する SQL ファイルの実行
- Workspace でワークシートを開き EXECUTE IMMEDIATE FROM でファイル単位での実行はできるので、リポジトリステージを作成した上で、各開発者が変更をブランチにプッシュ後、リポジトリステージを更新し Workspace から開発環境用の変数を指定しオブジェクトをデプロイするような動作は可能です
- ただし、記事執筆時は常にリポジトリステージの更新動作を挟まないと EXECUTE IMMEDIATE FROM の実行がうまくいかないなど、やや動作が不安定でした
上記の作業は、ローカルの VSCode 等で開発環境を用意し、Snowflake CLI 等を使えばもっとスムーズにできるので、現状はこちらを使う形でもよいのかなと思いました。
dbt Projects
Workspace で使用できる特徴的な機能として dbt Projects on Snowflake があります。本機能については以下の記事で詳しく紹介されていますので、ぜひこちらをご覧ください。
テーブルやビューは dbt によりコードを Git で管理しつつ、環境分離も容易に実現できます。
Copilot inline
Workspace でのみ使用できる機能として Copilot inline があります。
日本語にも対応しており、SQL コード内から直接 Snowflake Copilot を呼び出せます。これにより、自然言語の質問から SQL クエリの生成や既存の SQL の修正を行うことも可能です。SQL 修正する場合、提案された変更を承認すると、赤で強調表示された行は削除され、緑で強調表示された行は追加されます。
執筆時点では国内リージョンのアカウントでは使用できませんが、クロスリージョン推論を有効化することで国内のアカウントでも使用可能です。
さいごに
Snowflake の Workspace の基本操作を試してみました。
Snowflake 上のユーザーを作成すれば、容易に開発環境を用意できる点は便利な機能と思います。各種コードを Git で管理したい際も使用できます。また、Workspace 専用の機能として、OAuth2 による認証や Copilot inline などの機能も使用できます。
Workspace 単体で変数等を使用した環境分離などはまだ煩雑な印象のため、特に dbt Projects でテーブルやビューなどのデータパイプライン開発を進めるために使える機能と思いました。
こちらの内容が何かの参考になれば幸いです。
参考
