Legacy Notebook の共有ワークスペースへの移行を試してみる #SnowflakeDB
はじめに
Snowflakeでは、2026年6月に既存の Notebook（Legacy Notebook）が今後廃止されることが発表されました。今後は「Notebooks in Workspaces」への移行が必要となっています。
本記事では、この移行のうち、Legacy Notebook を共有ワークスペース（Shared Workspace）へ移行し、複数ユーザーで参照できるようにするまでの手順を試した内容をまとめてみます。
背景と概要
2026年6月に既存の Legacy Notebook の廃止が発表されました。今後は「Notebooks in Workspaces」への移行が必要となります。これに関する廃止のタイムラインとして執筆時点では以下のように予定されています。
| 時期 | 内容 |
|---|---|
| 2026年9月1日 | 新規作成の停止。既存のものは引き続き実行・編集可能 |
| 2026年11月 | 全機能停止。実行・編集が不可になり、関連する Snowflake Task やカスタムパイプラインも動作しなくなる |
移行先の「Notebooks in Workspaces」では、Jupyter 互換性・Cortex AI 統合・Git 連携・管理された CPU/GPU インフラなどが利用可能です。
移行ツールを使用することで既存のノートブックを Workspaces へ移動できます。猶予が必要な場合は、アカウントチームへ最大90日間の延長を申請することも可能とのことです。
基本的な移行手順等は以下にまとまっています。
Legacy Notebook は通常、個人用のワークスペースに移行できるほか、これまで通り複数のユーザーからのアクセスを担保するために、チームで共有する共有ワークスペースへ移行することも可能です。共有ワークスペースへ移行すると、ロールベースのアクセス制御によって、他のユーザーにも Notebook を参照・編集させることができるようになります。
前提：Notebook サービス
前提として、Workspaces 上の Notebook は「Notebookサービス」という実行環境で動作します。Legacy Notebook をワークスペースに移行すると.ipynb形式のファイルとして保存されますが、このファイル自体は実行環境を持たないため、以下の準備をして初めて実行できるようになります。
1. コンピュートプールの作成
Notebookサービスの実行基盤となるコンピュートプールを作成します。
CREATE COMPUTE POOL NOTEBOOK_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_SUSPEND_SECS = 3600 -- 1時間
AUTO_RESUME = TRUE;
コンピュートプールはALLOWED_SPCS_WORKLOAD_TYPESパラメータで「NOTEBOOK」ワークロードを許可している必要があります（デフォルトはALLのため通常は追加設定不要ですが、管理者側で制限している場合は確認が必要です）。
実行するユーザーには、対象のコンピュートプールへのUSAGE権限も必要です。
GRANT USAGE ON COMPUTE POOL <コンピュートプール> TO ROLE <role>;
2. Notebookサービスの作成
.ipynbファイルを開き、「Connect」から以下を指定してユーザー専用の Notebook サービスを作成します。
- コンピュートタイプ
- Pythonバージョン
- Runtimeバージョン
- 使用するコンピュートプール
- アイドルタイムアウト（未設定時はデフォルト24時間）
- 外部アクセス統合（プリインストール以外のパッケージを
pypi.orgから取得する場合に必要） - サービス名（任意の名称）
Notebook サービスはユーザーごとの環境（パーソナルDB）に作成されるため、共有ワークスペースを参照できるユーザーであっても、各自でこのサービスを用意（または既存のものを選択）する必要があります。
アカウントの Notebook サービスは以下から確認できます。
SHOW SERVICES OF TYPE NOTEBOOK IN ACCOUNT;
前提条件
検証環境
以下の内容で検証を行います。
- Legacy Notebook を共有ワークスペースに移行する
- Legacy Notebook の設定
- 権限：
yasuhara_devロールで作成（所有者） - ランタイム：ウェアハウスランタイム
- 権限：
- 移行先に関する権限
yasuhara_dev（移行・編集用）yasuhara_dev_read（参照用）
共有ワークスペースを作成
Legacy Notebook の移行先となる共有ワークスペースを作成します。共有ワークスペースはスキーマ配下のオブジェクトとなるため、この格納先となるデータベース・スキーマもあわせて作成します。
あわせて、既存の Legacy Notebook の所有者ロールで共有ワークスペースにNotebookを作成できるように、共有ワークスペースに対するWRITE権限をLegacy Notebookの所有者ロールに付与することで、引き続きこのロールで移行後のNotebookを編集できるようにしました。
-- 共有ワークスペース用のDB/スキーマを準備（SYSADMIN）
USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS yasuhara_shared_ws_db;
CREATE SCHEMA IF NOT EXISTS yasuhara_shared_ws_db.notebooks;
-- 共有ワークスペース自体はSYSADMINで作成
CREATE WORKSPACE yasuhara_shared_ws_db.notebooks.SHARED_NOTEBOOKS_WS;
-- 共有ワークスペースへの編集（WRITE）権限を付与
GRANT USAGE ON DATABASE yasuhara_shared_ws_db TO ROLE yasuhara_dev;
GRANT USAGE ON SCHEMA yasuhara_shared_ws_db.notebooks TO ROLE yasuhara_dev;
GRANT WRITE ON WORKSPACE yasuhara_shared_ws_db.notebooks.SHARED_NOTEBOOKS_WS TO ROLE yasuhara_dev;
その他、共有ワークスペースでの操作については以下をご参照ください。
Legacy Notebookを共有ワークスペースへ移行する
まずは、移行対象となるウェアハウスランタイムのシンプルな Legacy Notebook をyasuhara_devロールで用意しました。
Legacy Notebook もスキーマ配下のオブジェクトなので、何らかのデータベース・スキーマ配下に作成します。
Legacy Notebook の一覧画面から「Migrate now」をクリックします。
対象の Notebook にチェックを選択した状態で「Migrate」をクリックします。
移行先として、先の手順で作成した共有ワークスペースを指定し「Migrate」をクリックします。
移行が開始されます。
移行が完了すると、対象の共有ワークスペースに自動的に遷移します。
ノートブックがワークスペースに移行すると、「Migrated Notebooks」フォルダ内の移行の日付とタイムスタンプで命名されたフォルダに配置されます。
Notebook の実行
ワークスペースへ移行した Notebook は、そのままの形では実行できません。事前にコンピュートプールの作成と、ユーザーごとに Notebook サービスの作成が必要です。
コンピュートプールの作成
コンピュートプールは Notebook サービスの実行基盤となります。アカウントに対するCREATE COMPUTE POOL権限のあるユーザーでコンピュートプールを作成します。
ここでは、以下の内容で作成しました。
CREATE COMPUTE POOL NOTEBOOK_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_SUSPEND_SECS = 300
AUTO_RESUME = TRUE;
作成したコンピュートプールに対して、Notebook を実行する各ユーザー（ロール）は Usage 権限が必要です。
-- コンピュートプールの権限（実行ユーザー全員に必要）
GRANT USAGE ON COMPUTE POOL <コンピュートプール> TO ROLE yasuhara_dev;
ポイントとして、各ノートブックサービスは1人のユーザーにスコープされ、選択されたコンピューティングプール上の1つのノードを占有します。
そのため、コンピュートプール定義の MAX_NODES は最大同時実行ユーザー数に合わせて設定するのが望ましいです。
参考までに、ノード数はアカウント全体・インスタンスファミリーごとに制限があります。
- アカウントごとのコンピューティングプールノード数の制限：コンピューティングプールの数に関係なく）750
- インスタンスファミリーごとに許可されるノード数：各インスタンスファミリーの「Node limit」列
Notebook サービスの作成
Notebook の実行には、各ユーザーで「Notebook サービス」の作成が必要です。
対象の Notebook を開いた状態で「Connect」から自分の Notebook サービスを作成、または作成済みのサービスがあれば、そこから選択できます。下図のように「Connected」となれば Notebook の各セルを実行できます。
共有ワークスペースでの複数ユーザー参照
続いて、移行後の Notebook を他のユーザーから参照するまでの手順を試してみます。今回は共有ワークスペースに移行したため、この操作（複数ユーザーからの参照）が可能です。
別ユーザーへの参照権限の付与
ここでは、Notebook の編集はできない参照権限のみを与える設定とします。対象のワークスペースに対する読み取り専用の権限（READ）を付与するロールを作成し、別のユーザーに割り当てます。
-- 参照専用ロールの作成（SYSADMIN）とユーザーへの付与
CREATE ROLE IF NOT EXISTS yasuhara_dev_read;
GRANT ROLE yasuhara_dev_read TO USER <user>;
-- WSが置かれているDB/スキーマへのUSAGE権限
GRANT USAGE ON DATABASE yasuhara_shared_ws_db TO ROLE yasuhara_dev_read;
GRANT USAGE ON SCHEMA yasuhara_shared_ws_db.notebooks TO ROLE yasuhara_dev_read;
-- 作成したワークスペースへの参照権限（READ権限）をyasuhara_dev_readへ付与
GRANT READ ON WORKSPACE yasuhara_shared_ws_db.notebooks.SHARED_NOTEBOOKS_WS TO ROLE yasuhara_dev_read;
-- コンピュートプールの権限（実行ユーザー全員に必要）
GRANT USAGE ON COMPUTE POOL NOTEBOOK_POOL TO ROLE yasuhara_dev_read;
上記の権限を付与することで、対象ユーザーからも共有ワークスペース上の Notebook が見えるようになります。
コンピュートプールの使用権限を与えたので、Notebook サービスの作成も可能です。
自身の Notebook サービス作成後セルを実行できます。このユーザーは参照権限のみなので編集はできません。
スケジュールされたNotebookの移行
Legacy Notebook はスケジュール実行できたので、この移行も試してみます。
ポイントとして、ワークスペース内の Notebook をスケジュール実行するには、Notebook Project Object (NPO) というスキーマレベルのオブジェクトが追加で必要となります。その他は既存の Notebook と同様で Snowflake タスクに関する権限を使用します。
タスクに関する権限に加えて、指定のスキーマに対するCREATE NOTEBOOK PROJECT権限を事前に付与しておきます。
ここでは以下のように権限を付与しました。
後述する手順で GUI で移行後のスケジュール設定を行いましたが、この際、既存の Notebook 作成先スキーマに移行後のタスクや NPO が作成されたので、既存の Notebook 作成先に NPO 作成権限を付与しています。
GRANT CREATE NOTEBOOK PROJECT ON SCHEMA "YASUHARA_TEST_DB"."NOTEBOOKS" TO ROLE YASUHARA_DEV;
はじめに、スケジュール済みの Legacy Notebook を作成しておきます。
この Legacy Notebook をワークスペースに移行します。
移行後は、下図の「Reschedule tasks」や右上のスケジュールアイコンをクリックすることで、GUI から再スケジュールの設定を行えます。
下図の画面が表示されるので、「Reschedule tasks」をクリックします。権限が不足する場合、ここでエラーが表示されます。
再スケジュールの設定後は、再度スケジュールアイコンをクリックし「Deploy changes」をクリックします。
設定後、元々の Notebook があったデータベース・スキーマ配下に移行後のタスクと NPO が作成されていました。
※testは 既存の Notebook の定期実行タスク
タスクの定義は以下のようになっていました。コンピュートプールなどは既存のユーザー設定が使われているので、タスク用に設定する場合は SQL 等で定義する方が良い考えです。
create or replace task YASUHARA_TEST_DB.NOTEBOOKS."YASUHARA_TEST_SCHEDULED_NB_test_F69B56BB"
warehouse=X_SMALL_WH
schedule='USING CRON 1 * * * * Asia/Tokyo'
as EXECUTE NOTEBOOK PROJECT "YASUHARA_TEST_DB"."NOTEBOOKS"."NOTEBOOK_PROJECT_0BBBE068"
MAIN_FILE = 'Migrated Notebooks/2026-07-08_00-49-25/YASUHARA_TEST_SCHEDULED_NB/YASUHARA_TEST_SCHEDULED_NB.ipynb'
COMPUTE_POOL = "NOTEBOOK_POOL"
RUNTIME = 'V2.7-CPU-PY3.12'
QUERY_WAREHOUSE = "X_SMALL_WH";
Legacy Notebook との違い
ここでは共有ワークスペースへの移行に焦点を当てましたが、移行にあたり Legacy Notebook との違いによる動作確認も必要です。
例えば、ワークスペース内の Notebook は Streamlit による可視化がサポートされていない点やセルの参照方式が従来と異なる点などがあげられます。
移行後、Notebook 上部が下図の表示となるので、CoCo（旧Cortex Code）で自動修正も可能です。
代表的な違いは以下に記載があるので、あわせてご参照ください。
課金について
ワークスペース上の Notebook はコンテナランタイムで動作するので、サービスとプールが別レイヤーで動いています。自動停止の考え方も従来のウェアハウスとは異なるのでご注意ください。
こちらの詳細は以下をご参照ください。
さいごに
Legacy Notebook を共有ワークスペースへ移行し、異なるユーザーから参照するまでの手順を試してみました。Notebook の実行自体はユーザーごとの Notebook サービス・コンピュートプール権限に依存する点は移行前に押さえておく必要があると感じました。
こちらの内容がどなたかの参考になれば幸いです。
