他組織にデータを渡す場面を考えます。従来はファイルを書き出し、置き場に送り、相手が取り込む ── という手順でした。 の構築と、その後の運用が必要です。
は、複製せず参照権限だけを渡す仕組みです。この回は、何ができて何ができないかを整理します。
1. 何が変わるのか
最大の違いは、データが移動しないことです。相手は元のデータを直接参照します。
| 項目 | ファイル連携 | データ共有 |
|---|---|---|
| 鮮度 | 書き出した時点で固定 | 常に最新 |
| 構築の手間 | 書き出し・転送・取り込みが要る | 権限を設定するだけ |
| 保管の重複 | 双方が同じデータを持つ | 元の1つだけ |
| 計算費用の負担 | 取り込む側 | 参照する側 |
| 相手の前提 | ファイルを読めればよい | 同じ基盤が前提 |
1行目が実務上いちばん効きます。ファイル連携では必ず遅延が生じ、しかも「いつ時点のデータか」を管理する必要があります。共有なら、相手が見た瞬間が最新です。
一方、最下行が最大の制約です。相手も同じ基盤を使っていることが基本的な前提になります。使っていない相手に渡す仕組みも用意されていますが、条件が変わるため事前に確認が必要です。
2. 見せる範囲を設計する
表をそのまま共有することは、実務ではあまりありません。見せてよい範囲に絞るためにビューを経由させます。
-- 共有用のスキーマを分ける（本番の表を直接共有しない）CREATE SCHEMA prod.shared_with_partner;
-- 見せる列だけを選び、行も絞ったビューを作るCREATE VIEW prod.shared_with_partner.v_orders ASSELECT order_id, order_date, region, amount -- customer_name, email, phone は含めないFROM prod.analytics.fct_ordersWHERE region = 'KANTO' -- その相手に関係する範囲だけ AND order_date >= '2026-01-01';
-- 共有を作成し、ビューだけを対象にするCREATE SHARE partner_share;GRANT USAGE ON DATABASE prod TO SHARE partner_share;GRANT USAGE ON SCHEMA prod.shared_with_partner TO SHARE partner_share;GRANT SELECT ON VIEW prod.shared_with_partner.v_orders TO SHARE partner_share;要点は、共有専用のスキーマを分けることです。本番の表を直接共有すると、列が1つ追加されただけで、それが相手に見えるという事故が起きます。ビューで明示的に列を列挙しておけば、追加された列は自動的には見えません。これは EP.8 の で「新しい表に自動で権限が付くようにする」と書いたのと逆方向の配慮です。内部には自動で行き渡らせ、外部には明示したものだけを出す。同じ仕組みでも、内向きと外向きで既定を変える必要があります。
ビューの定義で全列を選ぶと、元の表に列が追加された瞬間に共有範囲が広がります。共有用ビューでは必ず列を明示的に列挙してください。これは規約として決めておく価値のある項目です。
-- どの共有に、何を渡しているかを確認するSHOW SHARES;SHOW GRANTS TO SHARE partner_share;
-- 共有用ビューの定義を確認する（列が増えていないか）SELECT get_ddl('view', 'prod.shared_with_partner.v_orders');
-- 共有先が実際に参照しているかを見るSELECT share_name AS 共有, consumer_account_locator AS 参照先, DATE_TRUNC('day', query_date) AS 日付, SUM(jobs_queried) AS 参照回数FROM snowflake.account_usage.data_transfer_historyWHERE query_date >= DATEADD(day, -30, CURRENT_DATE())GROUP BY 1, 2, 3ORDER BY 日付 DESC;渡しているつもりの範囲と、実際に渡っている範囲を突き合わせるのが点検の要点です。特にビューの定義は、変更されていないかを定期的に確認する価値があります。参照回数を見れば、使われていない共有も見つかり、これは外す候補になります。
3. 使いどころ
有効な場面と、そうでない場面があります。判断は相手の環境と、データの性質で決まります。
| 場面 | 向き | 理由 |
|---|---|---|
| グループ会社間での共有 | 非常に向く | 同じ基盤を使っていることが多い |
| 自社内の別環境への連携 | 向く | 複製せずに参照できる |
| 継続的に最新が必要な連携 | 向く | 遅延がない |
| 取引先が別の基盤を使っている | 条件を確認 | 別の仕組みが要る |
| 一度きりの受け渡し | 向かない | ファイルで十分。設定の手間が見合わない |
| 相手が加工して持ちたい | 場合による | 結局取り込むなら利点が減る |
5行目は重要な線引きです。一度きりなら、ファイルで渡すほうが速い。共有の設定と権限管理の手間は、継続的に使うから見合うものです。新しい仕組みがあると、それを使うこと自体が目的になりがちですが、手間が見合うかで判断してください。
4. 費用の負担が変わる
見落とされやすいのが費用の配分です。渡す側は保管を、参照する側は計算を負担します。ファイル連携とは配分が逆転する部分があります。
- 渡す側 — データの保管費用を持つ。相手がいくら参照しても計算費用はかからない
- 参照する側 — 自分の計算資源で参照するため、参照するほど費用がかかる
- 結果として — 相手が重いクエリを流しても、渡した側の費用は増えない
3番目は渡す側にとって安心材料ですが、相手にとっては説明が必要な点です。「共有してもらったが、参照すると自分たちの費用がかかる」という認識を持ってもらわないと、後でもめます。渡すときに費用の配分を明示するのが実務上の作法です。ファイルで受け取っていた頃は、取り込んだ後の費用は自分たちのものとして自然に認識されていました。共有ではその境界が見えにくくなるため、明示しておく価値があります。
共有した先で相手がどう使うかは、渡した側からは見えません。重い使い方をして「遅い」と言われることがあります。渡す時点で、想定する使い方（頻度・粒度）をすり合わせておくと、後の齟齬が減ります。
5. 運用で気をつけること
設定したあとの運用にも、いくつか注意点があります。
- 1共有先の一覧を管理する — 誰に何を渡しているかを把握しておく
- 2元の表の変更が影響する — ビューが参照する列を消すと、相手側で壊れる
- 3終了時に確実に外す — 契約終了後も見えたままにしない
- 4共有用ビューもレビュー対象にする — 列の追加は特に注意
2番目が実務で効きます。共有用ビューは、元の表に対する制約になります。列名を変えたい、型を変えたいというときに、相手側が壊れることを考慮しなければなりません。これは意識していないと気づかない依存関係です。
この構造は 壊れないデータ基盤の作り方 で扱っている、上流の変更で下流が壊れるという話と重なります。外部に見せた形は、勝手に変えられなくなるという点で、共有は暗黙の契約を生みます。
6. 判断の整理
最後に、方式を選ぶときの問いを整理します。
- 1相手は同じ基盤を使っているか — 使っていなければ選択肢が変わる
- 2継続的な連携か、一度きりか — 一度きりならファイルで足りる
- 3最新である必要があるか — 日次で足りるならファイルでもよい
- 4見せる範囲を絞れるか — ビューで表現できる範囲か
- 5費用の配分を合意できるか — 相手側に計算費用が発生する
5つすべてが「共有向き」なら、迷わず共有を選んでよいと思います。1つでも引っかかるなら、従来のファイル連携のほうが総合的に楽なことがあります。新しい仕組みだから使う、という選び方はしないでください。
データが移動しないため、鮮度と保管の重複で有利。ただし相手の環境が前提になる。共有は専用スキーマのビュー経由にし、列を明示的に列挙する（`SELECT *` は事故のもと）。費用は参照する側の負担なので、渡すときに明示する。そして共有した形は暗黙の契約になり、後から変えにくくなります。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。