「DWH弱者の自分」がSnowflake入門シリーズDay3を見て、セキュリティ・ガバナンスとAIの"らしさ"だけまとめてみた

AI その他 コンピュータ 勉強会

前回（Day2のノート）に続いて、Snowflake公式の「お昼休みに学ぶ」Snowflake入門シリーズ、今回はシリーズ最終回の Day3「Snowflakeの基礎技術 – セキュリティ/ガバナンス・AI編」 を受講しました。

Day3は セキュリティ・ガバナンス と AI という、毛色の違う2大テーマが詰め込まれていて、これまた情報量が多めでした。なので今回もこれまでと同じスタンスで、全部はなぞらず 「これは他のDBやAIサービスではこうはならないかな」と感じた"Snowflakeらしい"ところだけ に絞ってノートにしています。

自分はIoT・アプリケーション寄りの人間なので、「データガバナンス」「セマンティックレイヤー」あたりは、もはや何を指している言葉なのかすら分からない、ほとんど謎の呪文みたいな響きでした😅 「ガバナンス…？ 統治…？」「セマンティック…意味…？ で、レイヤーって何の層…？」という、入口で完全に置いていかれた状態からのスタートです。なので今回も、その謎の概念たちを「結局なんの話なの？」「なんでそうするの？」と自分なりに噛み砕いて整理するChallengeをしています。

前提としては、Day2では速さやコストを支える コア技術（マイクロパーティション、ストレージとコンピュートの分離など） が語られていました。Day3はその基盤の上に乗っている 「守り（セキュリティ・ガバナンス）」と「攻め（AI活用）」 の話、という流れになっています。

⚠️ この記事の情報は2026年6月時点のものです。最新情報はSnowflake公式ドキュメントも併せて確認してみてください。

関連

uepon.hatenadiary.com

uepon.hatenadiary.com

1. 守りも攻めも「クラウドサービスレイヤー」の上に乗っている

最初にDay2のアーキテクチャ復習がありました。Snowflakeは大きく3層に分かれていて、

  • ストレージ層 … データを置く場所（実質無制限・自動暗号化）
  • コンピュート層（仮想ウェアハウス） … クエリを処理する計算リソース
  • クラウドサービスレイヤー … 認証・アクセス制御・メタデータ管理・クエリ最適化・トランザクション管理などを束ねる「頭脳」

で、今回の主役である セキュリティとガバナンスは、この一番上のクラウドサービスレイヤーに統合されている という位置づけでした。

ここがアプリ屋的としてはけっこう新鮮で、自分の感覚だと「セキュリティやガバナンスは、後から別ツールを足したり、アプリ側で頑張って実装したりするもの」って印象だったんですよね。でもSnowflakeでは、このレイヤーが フルマネージドで最初から組み込まれている という考え方になっていました。

スライドではこのあたりを Snowflake Horizon という名前で呼んでいて、コンプライアンス・セキュリティ・プライバシー・相互運用性・アクセス制御といった機能が、追加の構成なしで使える、と説明されていました。

自分の今までの感覚 Snowflakeの考え方
セキュリティ／ガバナンスは別ツールやアプリ側で足す プラットフォームに最初から組み込み（Horizon）
設定やプロトコルを自分で整える デフォルトで効いていて、追加構成は基本不要

「ガバナンスは後付け」じゃなくて「土台に内蔵」という発想が、今回ずっと通底していたなと思います。

2. セキュリティは「自分で組む」より「最初から入っている」

統合セキュリティのパートでは、Snowflakeが標準で持っている機能がまとめて紹介されました。アプリ開発で自前で用意しようとすると、それぞれ別ライブラリや別サービスになりがちなものが、最初から揃っているようです。

観点 Snowflakeでできること
利用者認証 多要素認証（MFA）、SSO／フェデレーション認証（Okta・ADFS・SAML 2.0）、キーペア認証など
通信暗号化 クライアントとの通信は常時暗号化（TLS 1.2以上）。各クラウドのプライベート接続（PrivateLink等）も利用可
保管データ暗号化 保存データは常にAES256で暗号化。暗号鍵のローテーションも自動
アクセス管理 すべてのオブジェクト・操作・コンピュートへのアクセスをロールで管理（RBAC）
監査 すべてのログイン・トランザクション・データ転送のログを取得・保管
リカバリ 誤操作などに備えてデータを確実に復旧するオプション（Time Travel／Fail-Safe など）

個人的に「おっ」と感じたのは暗号化まわりです。保管データはAES256で常時暗号化＋鍵ローテーションが自動、しかも Tri-Secret Secure という、お客様管理の鍵を組み合わせる仕組みまで用意されている。アプリ屋からすると「暗号化を自分で設計しなくていい」というのは地味にありがたい。

あと、信頼性を裏付ける材料として 第三者認証 がずらっと並んでいました。SOC 1/2、PCI-DSS、ISO 27001、FedRAMP…と国際的な認証が多数。日本に関連するところでは、2025年に日本政府のクラウドサービスセキュリティ評価制度「ISMAP」に登録された という話もありました。公共系の案件だとここが効いてくるのかもなあ、と想像しています。

⚠️ これらは「自分でゼロから構築するセキュリティ機能」ではなく 「プラットフォームに標準装備されているもの」 という点です。"何を作るか"ではなく"何が最初から効いているか"のリスト、と読むのが正解のようです。

3. ガバナンスの肝は「保存データを変えずに、見せ方を制御する」

いちばん「DBの常識と違うな」と感じたパートでした。普通、自分の感覚だと「この人にはこの列を見せたくない」と思ったら、

  • 別テーブル／別ビューを作る
  • 値をマスクした状態でコピーを作る

みたいに、データそのものを加工したコピーを別途用意する 方向に行きがちです。でもSnowflakeのガバナンスは、元データはそのまま、クエリが実行された瞬間に「誰が見ているか」で見せ方を変える という発想でした。

3.1 まずは土台のRBAC（ロールベースアクセス制御）

Day2でも軽く出ましたが、改めて。Snowflakeのアクセス制御は オブジェクト → 権限 → ロール → ユーザ という関係で組み立てます。

要素 役割
オブジェクト 操作の対象（テーブル、ビュー、ウェアハウスなど）。単一のロールに所有される
権限 オブジェクトに対する操作（USAGE、SELECT、UPDATE など）
ロール 権限を束ねる入れ物。継承も可能
ユーザ ロールを割り当てられる人

ポイントは 「ユーザに直接権限を与えず、必ずロールを経由する」 こと。ユーザが増えても、ロール設計さえちゃんとしていれば管理がブレない、という考え方ですね。ここはアプリのRBACと同じ感覚だったので、わりとすんなり入りました。

3.2 ダイナミックデータマスキング（動的データマスキング）

RBACがテーブルやビュー単位の「入れる／入れない」だとすると、列の中身を「見せる／隠す」を動的に切り替える のがダイナミックデータマスキングです。

観点 内容
いつマスクする？ クエリ実行時 にマスクを適用（保存データ自体は変更しない）
何で隠す？ 定数値・ハッシュ・カスタム関数で、全マスク／部分マスクが可能
誰に見せる？ ポリシーで明示的に許可したロールだけがマスクを解除できる
管理は？ 1つのポリシーを複数の列に適用できる

例として、電話番号やSSNの列が、許可されたユーザー（Morgan）には 408-123-5534 と見えるけど、許可されていないユーザー（Alex）には ***-***-5534 とマスクされて見える、という図が出ていました。同じテーブルを見ているのに、ロールによって見える中身が違う わけです。

⚠️ 注意点は「デフォルトの挙動」です。ポリシーで明示的に許可しない限り、テーブル／ビューの所有者であっても自動的にマスク解除されるわけではない。「作った本人だから全部見える」とは限らないのは覚えておく必要があります。また、保存データは変わらないので、マスクは"見せ方"の制御であって"データの破壊"ではない という理解も必要です。

3.3 タグベースマスキング

マスキングを列に1つずつ手で貼っていくと、列が増えたときに大変です。そこで オブジェクトタグ と組み合わせるのが タグベースマスキング。

「classification というタグに secret や confidential という値が付いている列には、このマスキングポリシーを自動適用する」という形で、タグを起点に一括でポリシーを効かせられる わけです。新しく secret タグの付いた列が増えても、自動的にマスク対象になる。これは運用がだいぶ楽そうだなと思いました。

3.4 行アクセスポリシー

列方向（マスキング）に対して、行方向で「見せる範囲」を絞る のが行アクセスポリシーです。

スライドの例だと、売上テーブルに対して「EUのロールを持つ人にはEUの行だけ」「北米のロールを持つ人には北米の行だけ」を返すという制御をしていました。元テーブルは1つのまま、ロールに応じて返ってくる行が変わる。

これも嬉しいのは 「地域ごとに別テーブルを作らなくていい」 こと。データを1か所に統合したまま、ユーザーの属性で動的にアクセス範囲を変えられる＝データのサイロ化を防げる、という説明でした。

3.5 集計ポリシー（Aggregation Policy）

初めて見る概念です。「個別のレコードは見せたくないけど、集計値（平均や合計）は見せたい」 という、プライバシー配慮のシーンで効く機能です。

ポリシーで グループの最小サイズ（MIN_GROUP_SIZE） を決めておくと、

  • 対象カラムを直接 SELECT で見ようとすると見られない
  • 一定人数以上（例：5件以上）のグループでの集計（AVG など）なら結果を返す
  • グループが最小サイズ未満だと、個人が特定されかねないので NULL を返す

という挙動になります。スライドの例だと、ANALYSTロールは個票は見られないけど country で GROUP BY した平均年齢は見られる、ADMINロールは制約なし、という感じ。

統計データの公開で「セルの人数が少なすぎると個人が特定される」問題ってありますよね。あれを クエリエンジン側のポリシーで自動的に防いでくれる のは賢いなと思いました。

3.6 そのほかのガバナンス機能（ざっくり）

長くなったので詳細は省きますが、"らしいな"と思ったものを箇条書きで。

  • データ分類（Classification） … テーブルの列を分析して、機密性の高い個人情報（PII）を組み込みの機械学習で特定し、推奨タグを提示してくれる。タグ付けの出発点を自動化できる
  • オブジェクトタグ … 機密データの追跡だけでなく、コスト可視化（どのリソースがどれだけ使ったか）にも使える
  • データリネージ／オブジェクト依存関係 … どのデータがどこから来て、どこで使われているかを可視化
  • アクセス履歴 … 誰がどのオブジェクトにアクセスしたかを追跡
  • 匿名化／ノイズ付与 … 年齢を [36-40] のような幅にしたり、名前を伏せたりして、分析に使える形のまま個人特定を防ぐ

ここで効いてくるのが、Day2でも出た マイクロパーティション のメタデータ管理だなと感じました。どこに何があるかをプラットフォームが把握しているからこそ、こういう細やかな制御が後付けの作り込みなしで成立しているんだなと。

4. データの「すぐ隣」でAIが動く

後半は一気にAIの話になりました。テーマは 「誰もが自然言語でインサイトを引き出せる世界」。

全体像のスライドは情報が多かったので、自分なりに「データが入ってきてから使われるまで」の流れで整理しました。

段階 やること 登場する機能（例）
① 取り込み 各種データソースからデータを取り込む Snowflake Openflow
② 処理 構造化／非構造化データを段階的に整える（Bronze → Silver → Gold） Cortex AI関数
③ 活用 自然言語で検索・分析する Cortex Search、Cortex Analyst
④ インターフェース 業務ユーザーが使うAI体験 Snowflake Intelligence

自分が「ここがSnowflakeらしいな」と思ったのは、AIが"データの外"ではなく"データのすぐ隣"で動く という点でした。

普通だと、AIに分析させようと思ったら「データをどこかにエクスポート → 外部のAIサービスに渡す」という流れになりがちですよね。でもSnowflakeは、ガバナンスの効いたデータのすぐ横でAI機能が動く ので、機密データを外に持ち出さずに済む。第3章でやったマスキングや行アクセスポリシーが、AI経由のアクセスにもそのまま効く、という設計でした（公式ドキュメントでも、ガバナンスはクエリエンジン層で実行され、人間でもBIツールでもAIエージェントでも同じように適用されると説明されています）。

そして利用者を2タイプに分けていたのも分かりやすかったです。

  • エンジニア向け … Cortex Code（AIコーディングエージェント）
  • ビジネスユーザー向け … Snowflake Intelligence（自然言語で対話するアプリ）

5. セマンティックレイヤー

正直、ここがDay3で一番「なるほど！」となった部分でした。

「自然言語でデータを分析できます」と言われても、AIはテーブルの列が何を意味しているかを知らない んですよね。例がすごく分かりやすくて、

ユーザー「今期の売り上げは？」 AI「…COL1 と COL2 ？ どれが売上？ そもそも"今期"って？」

という状態。COL1、COL2 みたいな素っ気ない列名のテーブルを渡されても、AIには「今期＝2月〜翌1月」「売上＝TABLE5のCOL2」みたいな ビジネス上の意味 が分からない。

そこを埋めるのが セマンティックレイヤー（セマンティックビュー） でした。これは AIにデータの意味を教えるための情報を書いておく層 です。

セマンティックレイヤーに書くこと 例
参照するテーブル／ビューの場所 TABLE5（どのDB・スキーマか）
列の名前・説明・類義語 COL2 ＝ 売上、売り上げデータ、収入
ビジネス上の定義 「今期」＝ 2月〜翌1月

これを用意しておくと、AIは「"今期"は2月〜1月のことね」「"売上"は TABLE5.COL2 を見ればいいのね」と 正しくデータにたどり着くことができる。スライドでも「セマンティックレイヤーがあると、データが複雑になっても回答の正確性が保たれる」というグラフが出ていました。

アプリ屋的に言い換えると、「AIに渡す前に、業務用語とDBスキーマの対応表（辞書）を作っておく」 という作業に近いなと感じました。

「AIの精度は、モデルの賢さだけじゃなくて"データの意味をどれだけ教えられるか"で決まる」というのは、RAGを触ったことがある身としてもすごく納得感がありました。

6. Cortex AI関数はSQLから呼べるAI

更に"らしいな"と思ったのが Cortex AI関数 です。これは AIの処理をSQLの関数として呼べる もので、特に非構造化データ（テキスト・画像・音声・ドキュメント）の処理に効きます。

「AIを使うために別のPython環境やAPIを叩く」のではなく、いつものSQLの延長で SELECT AI_SUMMARIZE_AGG(...) みたいに書ける という感覚です。一部抜粋するとこんな顔ぶれでした。

関数名 できること
AI_COMPLETE プロンプトで汎用タスクを実行する汎用LLM
AI_CLASSIFY 指定したラベルに分類（マルチラベル対応）
AI_FILTER 入力に対して True / False を判定
AI_AGG グループのインサイトを出力する集計関数
AI_SENTIMENT 入力データの感情分類（アスペクト単位も可）
AI_TRANSCRIBE 音声のテキスト化・話者識別
AI_PARSE_DOCUMENT ドキュメントからテキスト抽出（OCR／レイアウト）
AI_EXTRACT プロンプトに従ってデータを抽出
AI_EMBED データのベクトル化
AI_SIMILARITY 2つの入力のコサイン類似度を出力

AI_EMBED でベクトル化して AI_SIMILARITY で類似度を出す、なんていうのは、まさにRAGや類似検索の部品ですよね。これがSQLの世界で完結するのは、データを動かさずに済むという意味でも理にかなっているなと思いました。

7. Snowflake Intelligence と Cortex Agents の仕組み

ビジネスユーザー向けの入り口が Snowflake Intelligenceで、Snowflakeとビジネスデータについて対話型のAI体験ができ、すぐ使えるアプリという位置づけです。ここでも嬉しいのは Snowflakeのガバナンスとアクセス制御がそのまま統合されている ことです。

裏側で動いているのが Cortex Agents で、ざっくりこんな流れでした。

  1. ユーザーがプロンプトを入力
  2. AIエージェントが推論し、どのツールを使うか を選ぶ
    • 構造化データの質問 → Cortex Analyst（自然言語をText-to-SQLで分析）
    • 非構造化データの質問 → Cortex Search（ドキュメントなどから意図を汲んで検索）
    • そのほかカスタムツールや組み込みツール（グラフ生成など）
  3. 取得した結果をもとに応答を生成

興味深いのは リフレクション という考え方で、エージェントが「質問に正確に答えるための情報を全部取れたか？」を自分でチェックして、足りなければツールを使い直す、といったループを回すようです。単にLLMに丸投げするのではなく、Snowflakeの製品・機能（Cortex Analyst／Search／セマンティックビュー）を道具として束ねている のがポイントだなと感じました。

まとめ

Day3「セキュリティ/ガバナンス・AI編」から、"Snowflakeならでは"だけを抜き出すとこんな感じでしょうか。

  • セキュリティもガバナンスも、後付けではなく クラウドサービスレイヤーに最初から組み込まれている（Horizon）
  • ガバナンスの肝は 「保存データを変えずに、クエリ時に見せ方を制御する」。マスキング・行アクセス・集計ポリシーが代表例
  • タグを起点に一括でポリシーを効かせられる ので、列が増えても運用が破綻しにくい
  • AIは データのすぐ隣で動く。だから機密データを外に出さずに済み、同じガバナンスがAI経由でも効く
  • AIの精度を左右するのは セマンティックレイヤー（AIにデータの意味を教える層）
  • AIの処理は Cortex AI関数としてSQLから呼べる。データを動かさずにAIを使える

ぜんぶ突き詰めると、「データを一か所にまとめたまま、守りも攻めもプラットフォーム側で完結させる」 という思想に集約されるなと感じました。Day2が「データを必要以上に動かさない」だったのに対して、Day3は「動かさないからこそ、守りもAIも一元的に効かせられる」という続きの話だった、と整理しています。

おわりに

3回シリーズを通して受講してみて、最初は用語の壁で「DWHもガバナンスもAIも何もわからん…」状態でしたが😅、Day1の EASY / CONNECTED / TRUSTED という指針が、Day2の技術（マイクロパーティション、分離アーキテクチャ）とDay3の機能（ガバナンス、Cortex）に、ちゃんと一本の線でつながっていたのが見えて、最後にスッキリした感じです。

アプリ／IoT寄りの自分でも、「マスキングやアクセス制御をアプリ側で作り込まなくていい」「AIに渡すデータを外に持ち出さなくていい」あたりは魅力的に見えました。

用語集

用語 説明
クラウドサービスレイヤー 認証・アクセス制御・メタデータ管理・最適化などを束ねるSnowflakeの最上位レイヤー。セキュリティとガバナンスもここに統合
Snowflake Horizon コンプライアンス・セキュリティ・プライバシー・相互運用性・アクセス制御を組み込みで提供するガバナンス機能群
RBAC（ロールベースアクセス制御） ユーザに直接権限を与えず、ロール経由で権限を付与する方式。オブジェクト→権限→ロール→ユーザの関係で管理
ダイナミックデータマスキング 保存データを変えず、クエリ実行時にロールに応じて列の値をマスク／解除する仕組み
タグベースマスキング オブジェクトタグを起点に、特定タグの付いた列へマスキングポリシーを一括適用する仕組み
行アクセスポリシー ロールやユーザー属性に応じて、テーブルから返す行の範囲を動的に絞る仕組み
集計ポリシー（Aggregation Policy） 個別レコードは見せず、最小グループサイズ以上の集計だけを許可するプライバシー保護の仕組み（未満はNULL）
データ分類（Classification） 列を分析して機密情報（PII）を機械学習で特定し、推奨タグを提示する機能
オブジェクトタグ データやリソースに付与するタグ。機密データ追跡やコスト可視化に利用
Tri-Secret Secure お客様管理の鍵を組み合わせて保管データを暗号化する仕組み
ISMAP 日本政府が運営するクラウドサービスのセキュリティ評価制度。Snowflakeは2025年に登録
Snowflake AI Data Cloud データの取り込み・処理・活用・AIサービスまでを一体で提供するSnowflakeの全体像
Snowflake Openflow 各種データソースからデータを取り込む機能
Cortex AI関数 AI処理をSQLの関数として呼べる機能群（AI_COMPLETE、AI_PARSE_DOCUMENT、AI_EMBED など）
Cortex Analyst 自然言語の質問をText-to-SQLで構造化データ分析する機能
Cortex Search 非構造化データやドキュメントから、意図を汲んで高精度に検索する機能
セマンティックレイヤー（セマンティックビュー） テーブル・列の意味やビジネス定義をAIに教える層。AIの分析精度を左右する
Snowflake Intelligence ビジネスユーザー向けの対話型AIアプリ。Snowflakeのガバナンスを統合
Cortex Code エンジニア向けのAIコーディングエージェント
Cortex Agents プロンプトに応じてツールを選び、結果を取得して応答を生成する仕組み（リフレクションでツールを使い直す）
SnowPro Core Snowflakeの技術基礎レベル認定資格（上位資格の前提。100問・115分・合格点750・175米ドル）