Snowsightは、SnowflakeをブラウザからSQLで操作し、データベースやロール、コストまで管理するためのWebインターフェースです。2026年6月22日からレガシーワークシートとダッシュボードの削除が始まり、SQLの編集画面はWorkspacesへ一本化されました。この記事では、サインインから最初のクエリ実行、移行で変わった点、共有ワークスペースの権限付与、GitHub連携のSQL、ウェアハウスのアイドルコストを出すSQLまでを、実装者が手を動かす順に整理します。
まとめ：2026年のSnowsightはWorkspaces前提で手順を組み直す
旧来の「ワークシートを開いてSQLを書く」手順は、もう通用しません。Snowflakeの廃止告知（BCR-2260）によると、レガシーワークシートの画面は削除され、残っていたワークシートはWorkspacesのファイルへ自動移行されています。Workspacesを無効にして旧画面へ戻す手段もありません。
実務で先に片づけるべきは3点です。共有していたワークシートは利用者ごとのコピーに分かれたため、共有ワークスペースで共同編集の場を作り直すこと。ダッシュボードは閲覧画面が消えたので、Streamlitか外部のBIツールへ移すこと。そしてSQLの資産をGitで管理するかを決めることです。費用を左右するのは画面ではなく、クエリ実行時に選ぶウェアハウスの稼働です。
Snowsightのサインインから最初のクエリ実行までの作業手順
最初に、画面の入口と基本操作を押さえます。
app.snowflake.comへのサインインと対応ブラウザの確認
入口はhttps://app.snowflake.comです。公式のSnowsight入門ページでは、Safari（macOS）、Google Chrome、Microsoft Edge、Mozilla Firefoxの最新3メジャーバージョンが対応ブラウザとされています。
プライベート接続を使う組織は、入口のURLが変わります。app-orgname-account_name.privatelink.snowflakecomputing.comの形式で接続するため、社内向けの手順書やブックマークにはこちらを記載しておくと迷いません。
ナビゲーションメニューの3区分とロール切り替えによる表示範囲への影響
2026年10月時点の日本語ドキュメントでは、左側のメニューが3つに分かれています。「データを扱う」にワークスペース、ノートブック、Streamlit、dbtプロジェクト、インジェスション、変換、AI&ML、モニタリング、Marketplaceが並びます。「Horizon Catalogを詳しく見る」はカタログ、データ共有、ガバナンスとセキュリティの入口です。「アカウントを管理する」にはコンピュートと管理者の設定がまとまっています。
見え方は現在のロールで変わります。ロールの切り替えは左下のユーザーメニューから行い、権限の無いメニューやオブジェクトは表示されません。カタログ側の設計はSnowflake Horizon Catalogとは？機能と設定SQLを解説で扱っています。
Workspacesでロールとウェアハウスを選びSQLを実行する手順
Workspacesの公式ドキュメントに沿うと、実行までの流れは次のとおりです。
- メニューの「ワークスペース」を開き、My Workspaceに
.sqlファイルを作る - エディタ上部でロールとウェアハウスを選ぶ
- データベースとスキーマを選ぶか、テーブル名を完全修飾で書く
- Windowsは
CTRL＋Enter、macOSはcommand＋returnで実行する
最初の1本は、いまどのロールとウェアハウスで動いているかを確かめるクエリにしておくと、権限エラーの切り分けが速くなります。
-- 実行環境の確認（ロール・ウェアハウス・バージョン）
SELECT CURRENT_ROLE(), CURRENT_WAREHOUSE(), CURRENT_DATABASE(), CURRENT_VERSION();
-- 完全修飾名で参照すれば、スキーマ選択に依存しない
SELECT COUNT(*) FROM sales_db.public.orders;Workspacesが扱えるのはSQLファイルとPythonファイルです。旧ワークシートにあったクエリフィルタは、Workspacesではサポートされていません。
旧ワークシートとダッシュボードの廃止日程と移行後に変わった点
移行は1日で切り替わったわけではなく、2025年から段階的に進みました。
2025年9月のGAから2026年9月の完了までの日程の整理
Workspacesは2025年9月11日に一般提供（GA）となりました。既定エディタの切り替えはエディション別の段階ロールアウト（BCR-2117）で進み、Standardのみの組織は2025年9月、Enterprise以下は10月下旬、Business Critical以下は11月、VPSは2026年1月の開始です。
| 日付 | ワークシート | ダッシュボード |
|---|---|---|
| 2026-04-20 | Workspacesが既定・無効化不可 | 新規作成を全アカウントで停止 |
| 2026-06-22 | 旧画面の削除開始・自動移行 | 閲覧・編集画面の削除開始 |
| 2026-09-20 | リーダーアカウントの移行開始 | リーダーアカウントから削除 |
設定面では、USE_WORKSPACES_FOR_SQLに'never'を指定する運用が使えなくなり、ENABLE_PERSONAL_DATABASEでWorkspacesを無効にする経路も4月20日に閉じました。旧画面のURLを貼った社内手順書や自動化は、Workspaces側へ書き換えが要ります。
共有が外れて個人コピーになったワークシートをチームで再共有する手順
移行で最も影響が大きいのは共有の扱いです。共有されていたワークシートは、アクセス権を持つ利用者ごとに1つずつコピーが作られ、共有状態は引き継がれていません。チームで1本のSQLを育てていた場合、移行日を境に各自の手元で別々に編集が進むことになります。
手順としては、まずチームで最新版がどれかを決め、それを後述の共有ワークスペースへ置き直します。各自のコピーは参照用に残すか削除するかを決めておくと、どれが正本か分からない状態を防げます。旧Pythonワークシートはworksheet_name.py.sqlという名前のファイルに変換されました。中身はストアドプロシージャのロジックのまま実行できるため、すぐに書き直す必要はありません。
廃止されたダッシュボードをStreamlitかBIへ移す判断基準
ダッシュボードの一覧画面だけは残されています。一覧からは2つの操作ができます。「Generate Streamlit app」でSnowflake上で動くStreamlitアプリへ変換するか、JSONとしてダウンロードするかです。JSONにはクエリ、フィルタ、名前、所有者と共有先の名前が含まれます。
移す先は、利用者がどこで数字を見ているかで決めると迷いません。閲覧者がSnowflakeのアカウントを持つ社内の分析担当に限られるならStreamlitへの変換が手早く、変換ウィザードは元のダッシュボードのロールとウェアハウスを引き継ぎます。課金や画面の作り方はStreamlit in Snowflakeとは？料金・課金体系と使い方を徹底解説にまとめているので、移行先を検討する際の参照先にしてください。Snowflakeのアカウントを持たない経営層や現場へ配るなら、既存のBIツールへ寄せるほうが配布の手間は小さくなります。
移す順番は管理者向けの画面で決められます。ダッシュボードごとの利用状況を出せるため、直近30日に実行されたものから優先し、使われていないものは移さずに捨てる判断ができます。
旧ノートブックの新規作成停止とコンテナランタイムへの移行前の確認事項
ノートブックも同じ流れにあります。旧ノートブックの移行ガイドによると、2026年9月1日から旧ノートブックの新規作成が止まり、既存分は2026年11月まで動きます。Workspaces側のノートブックはSnowpark Container Services上のコンテナランタイムだけで動き、ウェアハウスでの実行は選べません。パッケージもAnacondaチャネルからSnowflakeのPyPIリポジトリやステージからの読み込みへ変わるため、依存パッケージの洗い出しを11月より前に済ませてください。
共有ワークスペースの権限付与と下書き・公開の運用を設定する手順
共有ワークシートの代わりとして公式が推奨するのが共有ワークスペースです。
CREATE WORKSPACE権限をスキーマへ付与するGRANT文の例
共有ワークスペースの公式ドキュメントでは、作成に必要な権限を2通り示しています。作成先スキーマの所有権を持つか、データベースのUSAGEとスキーマのUSAGE・CREATE WORKSPACEを持つかです。チーム用のスキーマを1つ切り、後者で付与する形が管理しやすいでしょう。
-- 分析チーム用の共有ワークスペースを作れるようにする
GRANT USAGE ON DATABASE analytics_db TO ROLE analyst_team;
GRANT USAGE, CREATE WORKSPACE ON SCHEMA analytics_db.workspaces TO ROLE analyst_team;ワークスペースに対する権限はREAD、WRITE、OWNERSHIPの3段階で、所有できるロールは同時に1つだけです。個人ではなくチームのロールに所有させておくと、担当者の異動で宙に浮くことがありません。
共有ワークスペースで下書きと公開を分けるwiki型の編集と競合時の選択肢
共有ワークスペースの編集は、wikiに近い2段階のモデルです。ファイルを編集すると最初は下書きとして扱われ、ほかのメンバーには見えません。公開して初めて全員に反映されます。
同じファイルを別の人が先に公開していた場合は、上書き、キャンセル、差分の表示から選びます。旧ワークシートのように保存した瞬間に他人の画面が変わる挙動ではないため、本番運用のクエリを置く場所と、試行錯誤用の個人ワークスペースを分けて使うと事故が減ります。
WorkspacesとGitHubを接続するAPI統合とシークレットの作成手順
SQLの資産をレビューや履歴管理に載せるなら、Git連携を設定します。
GitHub AppのOAuthかPATかを選ぶ認証方式ごとの準備
WorkspacesのGit連携ドキュメントが挙げる認証は3種類です。OAuth2、個人アクセストークン（PAT）、認証なしの公開リポジトリで、公開リポジトリではコミットとプッシュができません。GitHubの場合、OAuth2はSnowflakeが用意したGitHub Appを使えるため、トークンの期限切れを管理する手間が減ります。
どの方式でも、API統合の作成にはCREATE API INTEGRATION権限が要ります。多くのアカウントでは管理者ロールに限られるため、開発者だけで設定を完結できない点を前提に段取りを組んでください。
Git接続に使うPAT方式のシークレットとAPI統合を作るSQLの実行例
パブリックネットワーク経由のGit接続ドキュメントの構文に沿うと、PAT方式は次の3段階になります。トークンはシークレットに格納し、SQLファイルに直接書かないでください。
-- 1. PATをシークレットに格納する
CREATE OR REPLACE SECRET integrations_db.git.my_git_secret
TYPE = password
USERNAME = 'github_user'
PASSWORD = 'ghp_xxxxxxxx';
-- 2. 許可するリポジトリの範囲を絞ってAPI統合を作る
CREATE OR REPLACE API INTEGRATION my_git_api_integration
API_PROVIDER = git_https_api
API_ALLOWED_PREFIXES = ('https://github.com/my-account')
ALLOWED_AUTHENTICATION_SECRETS = (integrations_db.git.my_git_secret)
ENABLED = TRUE;
-- 3. 開発者ロールへ使用権限を渡す
GRANT USAGE ON INTEGRATION my_git_api_integration TO ROLE developer;
GRANT USAGE ON SECRET integrations_db.git.my_git_secret TO ROLE developer;API_ALLOWED_PREFIXESは組織やアカウントの単位まで絞ると、無関係なリポジトリへの接続を防げます。GitHub App方式なら、シークレットの代わりにAPI_USER_AUTHENTICATION = (TYPE = SNOWFLAKE_GITHUB_APP)を指定します。
2GB上限と空リポジトリ非対応などGit接続前に確認する制限事項
接続先のリポジトリには制約が2つあります。ブランチを最低1本含む必要があり、空のリポジトリは使えません。サイズは2GBまでで、それを超えるリポジトリは対象外です。データファイルを同じリポジトリに積んでいるなら、SQL用のリポジトリを分けてください。接続後はWorkspaces上でブランチの作成と切り替え、プル、コミット、プッシュ、競合の解消まで行えます。
Snowsightで実行したクエリの消費クレジットをSQLで確認する方法
画面の操作自体ではなく、裏で動くウェアハウスが費用を決めます。
ウェアハウスの稼働時間に課金が乗る構造とクエリ終了後に見落とす費用
Workspacesでクエリを実行するとき、最初に選んだウェアハウスが処理を担います。費用はこのウェアハウスの稼働に対して積み上がるため、誰がどのサイズのウェアハウスを選べるかが、そのままコスト管理の論点になります。スキャン量課金のBigQueryとの構造の違いはBigQueryとSnowflakeの比較：課金モデルの構造差と同時実行で決める選定基準で整理しました。
見落としやすいのが、クエリが終わったあとも停止までのあいだ稼働し続けるアイドル時間です。共有ワークスペースで複数人が大きめのウェアハウスを使い回すと、ここが目立ってきます。
WAREHOUSE_METERING_HISTORYでアイドルコストを出すSQL
WAREHOUSE_METERING_HISTORYビューの公式ドキュメントには、ウェアハウスごとのアイドル分を算出する例が載っています。消費クレジットからクエリに割り当てられた分を引いた残りがアイドルです。
-- 直近10日間のウェアハウス別アイドルコスト（クレジット）
SELECT
(SUM(credits_used_compute) - SUM(credits_attributed_compute_queries)) AS idle_cost,
warehouse_name
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('days', -10, CURRENT_DATE())
AND end_time < CURRENT_DATE()
GROUP BY warehouse_name
ORDER BY idle_cost DESC;ACCOUNT_USAGEスキーマのこのビューは最大180分遅れて反映され、クラウドサービス分の列は最大6時間遅れます。実行直後の数字ではなく、前日までの傾向を見る用途で使ってください。アイドルが大きいウェアハウスは、自動停止までの時間とサイズを見直す候補になります。
Snowsightで完結させる作業と外部ツールへ切り出す作業の判断基準
最後に、どこまでをSnowsightに任せるかの線引きを示します。
Snowsightで足りる場面とIDEやBIへ切り出すべき3場面
アドホックな集計、ロールやウェアハウスの管理、利用状況の確認、少人数でのSQLの共同編集は、Snowsightで完結させて問題ありません。Git連携と共有ワークスペースが揃ったいま、SQLの共同管理のためだけに別のツールを入れる理由は薄れました。SnowsightにはAIコーディング機能も統合されており、位置づけはSnowflake CoCoとは？旧Cortex Codeからの改称・権限境界・課金の二重経路を実装目線で解説で扱っています。
一方、次の3場面ではSnowsightに寄せません。第一に、アカウントを持たない人へ数字を配る場面で、ここはBIツールの領分です。第二に、テストとデプロイを伴う変換パイプラインで、dbtプロジェクトとCI/CDで管理します。第三に、アプリケーションのコードとSQLを同じリポジトリで扱う開発で、手元のIDEとGitのほうが作業が速く済みます。
ワークシートとダッシュボードの移行後に詰まりやすい失敗パターンと事前の回避策
移行後に起きやすい失敗は2つに集約されます。1つは、共有ワークシートの各自コピーを正本と思い込み、別々に直したSQLが本番に混ざるケースです。共有ワークスペースへの置き直しと、旧コピーの扱いの取り決めを同じ日に済ませれば防げます。
もう1つは、ダッシュボードを一律にStreamlitへ変換し、使われていないアプリと稼働するウェアハウスを増やしてしまうケースです。利用状況で直近30日に動いたものだけを選び、残りはJSONで保存して終わりにする判断を先に下してください。
Snowflakeを含むデータ基盤の設計と運用ルールを外部へ相談する目安
Snowsightの操作自体は社内で覚えられます。外部の手を借りる価値があるのは、ロールとウェアハウスの割り当て設計、Git連携を含む開発フロー、ダッシュボードの移行先選びを一度に決める局面です。基盤エンジニアが社内にいない、あるいはBigQueryなど他基盤との併用を整理したい場合は、設計段階から相談したほうが手戻りは小さく済みます。一創ではデータ分析基盤構築・MLOps構築支援として、Snowflakeを含むデータ基盤の設計・構築から運用ルールづくりまでを請け負っています。
よくある質問
Snowsightの利用と移行で挙がりやすい質問をまとめます。
Snowsightの利用自体に料金はかかりますか？
費用の中心は、クエリを処理するウェアハウスの稼働とストレージです。Workspacesで選んだウェアハウスが動いた時間がクレジットとして積み上がるため、画面をどれだけ開いていたかより、どのサイズのウェアハウスで何を実行したかが効きます。消費量はACCOUNT_USAGEスキーマのWAREHOUSE_METERING_HISTORYビューで確認できます。
旧ワークシートに戻すことはできますか？
戻せません。2026年6月22日からレガシーワークシートの画面削除が始まり、残っていたワークシートはWorkspacesのファイルへ自動移行されました。以前はUSE_WORKSPACES_FOR_SQLパラメータで既定のエディタを戻せましたが、'never'の指定はサポート外になっています。リーダーアカウントも2026年9月20日から順次Workspacesへ切り替わりました。
移行したワークシートはどこにありますか？
Workspacesのファイルとして、各利用者のワークスペースに置かれています。共有されていたものは利用者ごとのコピーになり、共有状態は引き継がれていないため、チームで使うSQLは共有ワークスペースへ置き直してください。
Snowsightのダッシュボードはもう使えませんか？
閲覧と編集の画面は削除され、2026年4月20日からは新規作成もできません。ただしダッシュボードの一覧は残っており、そこからJSONとしてダウンロードするか、「Generate Streamlit app」でSnowflake上のStreamlitアプリへ変換できます。社外や非エンジニアへ配る用途なら、外部のBIツールへ移す選択肢もあります。
WorkspacesはGitHub以外のGitサービスとも連携できますか？
API統合のAPI_PROVIDERにgit_https_apiを指定する仕組みのため、GitHubに限らず接続できます。GitHub以外でOAuth2を使う場合は、認可エンドポイントやトークンエンドポイント、クライアントIDなどをAPI統合に直接指定します。PAT方式であればシークレットにトークンを格納する手順は共通です。リポジトリは2GB以内で、ブランチを1本以上含む必要があります。
関連記事
- データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説：Snowflakeが属するDWHの仕組みと製品選びの全体像が分かります
- Snowflake Cortex AIとは？機能一覧・料金・日本リージョンの制約と読み方：Snowsightの「AI&ML」メニューから使う機能の範囲と料金を確認できます
- Streamlit in Snowflakeとは？料金・課金体系と使い方を徹底解説：廃止されたダッシュボードの移行先として課金と作り方を比較できます
