第5章 データコラボレーション / 想定学習時間:30〜40分 / 最終確認:2026年8月

5-2. ゼロコピークローン(仕組み・権限・ストレージ課金)

🎯 この節の学習目標

1. ゼロコピークローンとは:コピーしないコピー

ゼロコピークローン(zero-copy cloning)は、データベース・スキーマ・テーブルなどの「コピー」を、データを物理的に複製せずに作成する機能です。5-1で学んだとおり、Snowflake のデータはイミュータブルなマイクロパーティションとして保存されています。クローンの作成は、同じマイクロパーティション群を指す新しいメタデータを作るだけの操作です。

-- テーブルをクローンする
CREATE TABLE sales_dev.public.orders CLONE sales.public.orders;

-- スキーマ・データベース単位でも同じ構文でクローンできる
CREATE SCHEMA sales_dev.public CLONE sales.public;
CREATE DATABASE sales_dev CLONE sales;

この仕組みから、次の性質が導かれます。

本番データベース salesマイクロパーティション群(物理データ)を保持
CREATE DATABASE sales_dev CLONE sales(メタデータ操作のみ・即時完了)
開発データベース sales_dev作成直後はソースと同じ物理データを参照(追加ストレージ0)
クローン側でUPDATE / INSERTを実行
変更された分だけ新しいマイクロパーティションを作成差分のみ新規ストレージ課金。ソースには一切影響しない

図:ゼロコピークローンの仕組み。物理データを共有し、変更された差分だけが新規ストレージになる

2. クローンできるもの・できないもの

クローンはあらゆるオブジェクトに使えるわけではありません。試験では「何がクローンできて何ができないか」がよく問われます。

クローン可能クローン不可
データベース、スキーマ、テーブル(permanent / transient)、ストリーム、シーケンス、ビュー等を含むスキーマ階層、外部名前付きステージ、ファイルフォーマット、タスク(クローン直後は停止状態)外部テーブル内部名前付きステージ(単体でのクローン)。ただし内部名前付きステージは、DB/スキーマのクローン時に INCLUDE INTERNAL STAGES を指定すれば含められる

注意すべき細かいルールが3つあります。

3. Time Travelとの併用:過去時点のクローン

クローンは 5-1 で学んだ Time Travel と組み合わせられます。AT / BEFORE 句付きの CLONE により、「過去のある時点のテーブル」を新しいテーブルとして即時に作り出せます。誤操作からの復旧手段として最も実用的なパターンです。

💡 具体例:誤更新前の状態を別テーブルとして復元する

-- 1時間前の状態のテーブルをクローンとして作成する
CREATE TABLE orders_restored CLONE orders
  AT(OFFSET => -3600);

-- 誤ったUPDATE文(クエリIDで指定)の直前の状態をクローンする
CREATE TABLE orders_before_update CLONE orders
  BEFORE(STATEMENT => '01b2c3d4-0000-1234-0000-000000000001');

-- 内容を確認したうえで、入れ替える
ALTER TABLE orders RENAME TO orders_broken;
ALTER TABLE orders_before_update RENAME TO orders;

元のテーブルを直接上書きせず、まず過去時点のクローンを作って内容を検証してから入れ替えるのが安全な手順です。指定した時点がソーステーブルの Time Travel 保持期間より前の場合、クローンはエラーになります。

4. 権限とテーブルタイプのルール

クローンにおける権限の扱いには、明確な非対称があります。

対象権限の引き継ぎ
クローンされたオブジェクト自体(例:CLONEで作ったテーブル)ソースの権限を引き継がない。所有者はクローンを実行したロールになり、必要な権限は改めてGRANTする
クローンに含まれる子オブジェクト(例:DBクローン時の配下のスキーマ・テーブル)ソースの子オブジェクトの権限を引き継ぐ

また、クローンを実行するロールには、ソーステーブルに対する SELECT 権限(ステージ等では USAGE)と、作成先スキーマの CREATE TABLE 権限が必要です。

テーブルタイプについては、temporary テーブルを permanent テーブルとしてクローンすることはできません(temporary / transient としてのクローンは可能)。permanent テーブルを transient としてクローンすることはできます。

📝 試験のポイント

「データベースをクローンしたのに、クローン先のDB自体への権限が付いていない」のは仕様どおりです。クローンしたオブジェクト自体は権限を引き継がず、その中の子オブジェクトは引き継ぐ、という対比で覚えましょう。あわせて「外部テーブルはクローン不可」「内部名前付きステージは既定では含まれないが、INCLUDE INTERNAL STAGES 指定で含められる」「temporary → permanent のクローンは不可」も選択肢の定番です。

5. 代表的なユースケース

ユースケース使い方
開発・テスト環境の即時複製本番DBをクローンし、本番と同じデータで開発・テストする。ストレージの二重コストなしに、本番に影響を与えず自由に変更できる
バックアップポイントの作成大規模なデータ変更やリリースの直前にクローンを取り、問題があればクローンから戻す
過去時点の復元Time Travelと組み合わせ、誤操作前の状態を別テーブルとして即時に復元する

従来のデータ基盤では「本番同等のテスト環境」を作るためにデータの物理コピーと長い待ち時間、二重のストレージ費用が必要でした。ゼロコピークローンはこれを数秒・追加コストほぼゼロに変える、Snowflake の代表的な差別化機能の1つです。

✅ この節のまとめ

練習問題

問1. 10TBの本番テーブルをCREATE TABLE ... CLONEでクローンした。作成直後のストレージ課金の説明として正しいものはどれか。

  1. 10TB分のストレージが新たに課金される
  2. ソースの半分(5TB)が課金される
  3. 追加のストレージ課金はほぼ発生せず、以後クローンまたはソースで変更された差分だけが課金される
  4. クローンはストレージを消費しないため、以後どれだけ変更しても課金は増えない
解答と解説を見る

正解:C

クローンはソースと同じマイクロパーティションを参照するメタデータ操作のため、作成時点では追加ストレージがほぼ発生しません。その後どちらかの側でデータが変更されると、変更分の新しいマイクロパーティションが作られ、その差分だけが課金対象になります。AとBは物理コピーが発生するという誤解です。Dは前半は正しいものの、変更後の差分は課金されるため誤りです。

問2. データベースを既定の設定(オプション指定なし)でクローンしたとき、クローンに含まれないものを2つ選べ。

  1. 配下のpermanentテーブル
  2. 配下の外部テーブル
  3. 配下の内部名前付きステージ
  4. 配下のストリーム
解答と解説を見る

正解:BとC

外部テーブルはクローンできないオブジェクトであり、データベースやスキーマをクローンした際も子オブジェクトとしてスキップされます。内部名前付きステージも既定(未指定)ではクローンに含まれませんが、こちらはCLONE文に INCLUDE INTERNAL STAGES を指定すれば含めることができます(ディレクトリテーブルが有効ならファイルもコピーされます)。Aのpermanentテーブルはクローンの中心的な対象です。Dのストリームもクローン可能なオブジェクトに含まれます。なお、テーブル自体はクローンされてもテーブルステージ内のファイルはコピーされない点もあわせて覚えておきましょう。

問3. クローンにおける権限の引き継ぎについて、正しい説明はどれか。

  1. クローンされたオブジェクト自体も子オブジェクトも、すべてソースの権限を引き継ぐ
  2. クローンされたオブジェクト自体はソースの権限を引き継がないが、クローンに含まれる子オブジェクトは引き継ぐ
  3. クローンされたオブジェクト自体はソースの権限を引き継ぐが、子オブジェクトは引き継がない
  4. 権限は一切引き継がれず、すべてのオブジェクトに改めてGRANTが必要になる
解答と解説を見る

正解:B

クローンで作成されたオブジェクト自体(たとえばクローンしたデータベースそのもの)はソースの権限を引き継がず、所有者は実行したロールになります。一方、そのクローンに含まれる子オブジェクト(配下のスキーマやテーブル)はソースの対応するオブジェクトの権限を引き継ぎます。A・C・Dはいずれもこの非対称なルールと矛盾します。

問4. Time Travelとクローンの併用に関する説明として正しいものはどれか。

  1. CREATE TABLE ... CLONE ... AT(OFFSET => -3600)で、1時間前の状態のテーブルを新しいテーブルとして作成できる
  2. クローンはソースの現在の状態からしか作成できない
  3. AT句付きクローンなら、Time Travel保持期間より前の時点も指定できる
  4. temporaryテーブルをpermanentテーブルとしてクローンすれば、Fail-safeが付与される
解答と解説を見る

正解:A

CLONE文にAT / BEFORE句を付けることで、Time Travel保持期間内の任意の時点の状態を新しいオブジェクトとして即時に作成でき、誤操作からの復旧に最も実用的な手段になります。Bは過去時点のクローンが可能である点と矛盾します。Cは誤りで、保持期間より前の時点を指定するとエラーになります。Dはそもそもtemporary → permanentのクローンができないため誤りです。