![[レポート]Snowflakeで実現するデータAIガバナンス AIエージェントガバナンス・データ持ち出し防止・ランサムウェア対策等 #SWTTokyo26](https://images.ctfassets.net/ct0aopd36mqt/4kFYCMTvi9ucEtpiAfvm01/b605f81aa314b1fdbc86f8fee275fb43/eyecatch_snowflakeworldtourtokyo2026.webp?w=3840&fm=webp)
[レポート]Snowflakeで実現するデータAIガバナンス AIエージェントガバナンス・データ持ち出し防止・ランサムウェア対策等 #SWTTokyo26
AIの普及により、組織が管理すべきデータの範囲とリスクは急速に拡大しています。
本セッションでは、Snowflakeが提供するデータセキュリティとAIガバナンスのベストプラクティスや最新機能を解説
前半では、現実の攻撃シナリオに基づいたデータ持ち出し攻撃プロセス解説、データ移動ポリシーやトラストセンターを活用した高度な防止策を紹介します
後半では、Snowflake Horizon Catalogを軸に、150以上の分類項目による機密データの自動検出・タグベースマスキング・ABAC・アクセス履歴監査といったデータガバナンス機能
ガバナンス自動化・AIエージェントのアイデンティティ管理・プロンプトインジェクション防御・Cortex AIガードレールなど、AIワークロードを安全に運用するためのガバナンスフレームワークを紹介します
※SNOWFLAKE WORLD TOUR 2026 イベントサイトより抜粋
2026.09.14
かわばたです。
2026年9月10日～2026年9月11日に、「SNOWFLAKE WORLD TOUR 2026 - TOKYO」が開催されました。
本記事はセッション
【Snowflakeで実現するデータAIガバナンス AIエージェントガバナンス・データ持ち出し防止・ランサムウェア対策等】
のレポートブログとなります。
【追記】
Snowflake Community Awards の「RISING COMMUNITY LEADER OF THE YEAR」部門・APJ枠のファイナリストに選ばれました。
詳細は下記よりご確認ください。
登壇者
- 柳瀬 雅也 氏
- Snowflake ソリューションエンジニアリング統括本部 プリンシパルセキュリティアーキテクト
AI時代のガバナンス課題とSnowflake Horizon Catalog
- AI はもう業務と切り離せない。一方で「AI エージェントにどう言うことを聞かせるか」「どう安全にデータを使わせるか」が心配事になっている
- ChatGPT 登場以降、AI はチャットボットからエージェントへ進化した
- 質問に答えるだけでなく、行動を起こし、外部や機密データにアクセスし、自ら決定する
- Snowflake の調査では、ほとんどのお客様がガバナンスとコンプライアンスを課題視している
- Snowflake Horizon Catalog は、Snowflake上のデータ、AI、セキュリティに関するガバナンス機能を統合的に提供する基盤
- データの分類、タグ付け、アクセス制御、監査、AIエージェントに対する制御などを組み合わせ、データ利用に対するガバナンスを実現
- Horizon Catalog の3つの柱
- 発見: どんなデータがあるかを把握し、個人情報かどうかを分類してタグを付ける
- 保護: タグだけでは守れないので、データに合わせたポリシーを設定する
- 信頼: 誰がどうデータを使ったかのアクセス監査に加え、データ品質とリネージも重要（Garbage in, garbage out）
Governance for Data
自動分類とカスタム分類
- 自動分類は GA 済みで、多くのお客様が利用している
- 氏名・メールアドレス・給与などを、1つ1つ手で見ることなく自動的に分類する
- 製造番号や社員番号など企業固有の機密データは、正規表現を使ったカスタム分類で対応する
タグベースマスキング
-
分類しただけでは防御できない。タグにマスキングポリシーを付け、そのタグを複数のテーブルに付ける
- テーブルごとにポリシーを書かずに、一括でマスキングできる
-
3〜4年前から提供されており、多くのお客様に使われている
-
テーブルにタグを付けておけば、後から追加されたカラムも自動的に保護される。抜け漏れがなくなる点が大きなメリット
-
ABACによる属性ベースのアクセス管理
AIによる機密データ保護
- 分類を AI の力でより精緻に行う新機能。パブリックプレビューで利用できる
- 組み込みのルールベース分類では、日本語の住所などカバーできない項目がある
- AI モードを有効にすると、AI が「これは住所」と判定してくれる
デモ：分類からマスキングまで
- 名前・メールアドレス・給与・電話番号・日本語の住所を含むテーブルを、まず標準の分類にかける
- 名前・メールアドレス・給与などは分類され、あらかじめタグに付けたマスキングポリシーで一般ロールにはマスクされる
- 日本語の住所だけは分類されず、マスクもされない
- 分類プロファイルで AI モードを有効にして再分類すると、住所カラムも検出され、PII タグが付く
- ACCOUNTADMIN では生データが見え、一般ユーザーに切り替えると住所もマスクされた
- 日本語の住所も、AI モードとタグベースマスキングの組み合わせで保護できた
参考に過去私の検証した記事を掲載します。
Governance for AI
IS_AGENT_ACTIVATEDでポリシーを出し分ける
- GA 済みの機能。ポリシーの中に「エージェントなら〜、人間なら〜」という条件式を書ける
IS_AGENT_ACTIVATEDは、現在の実行コンテキストでAIエージェントがアクティブかどうかを判定するコンテキスト関数- エージェントがアクティブな場合と、それ以外の場合で、マスキングポリシーや行アクセスポリシーなどを出し分けられる
- 同じ権限でも、エージェントならマスクする、行を返さない、といった制御ができる
- 公式ドキュメントでは
SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')で参照する
デモ：同じ権限でもエージェント経由だけマスキングする
- 左は Snowsight で人間が SQL を実行、右は Snowflake CoCo に同じクエリを投げる。
IS_AGENT_ACTIVATEDは左が FALSE、右が TRUE。同じ権限でも、経路によって値が変わるのが肝- ポリシー変更前は、人間とエージェントの両方に生データが見える
- マスキングポリシーを「TRUE なら AGENT BLOCKED という文字列を返す」に変更。INTEGER 型のポリシーも同様に変更
- 再実行すると、人間には生データが見え、エージェントにはマスクされた値だけが返った
- 行アクセスポリシーなど他のポリシーにも同じ条件を組み込める
参考に過去私の検証した記事を掲載します。
機密データ保護用Cortex AIガードレール
- 既存の Cortex AI Guardrails は、プロンプトインジェクションやジェイルブレイクなど AI への攻撃を防ぐ
- 開発中の機能は、AI の出力に機密データが含まれていたらガードする「出力側」の保護
- まだプライベートプレビューにも至っていない段階とのこと
データ持ち出し防止
持ち出し防止機能の全体像
- 人が外部へ持ち出すケースだけでなく、エージェントがデータを外へ持ち出そうとするケースにも使える
- Snowflake には持ち出し防止の機能が複数ある
- 今回の主役である Data Movement Policies（2026年8月に GA）
- 送信先を制限する外部アクセス制御
- データの行き先を検出する Trust Center のスキャナー
- ABAC
- これらを組み合わせて、どう使うかを検討してほしいとのこと
仕組み：行数で制御するルールをタグ経由で適用
- 設定はマスキングポリシーとほぼ同じで、条件式を書く。違いは「データ量（行数）」で制御できる点
- 100 行までは見えるが 101 行以上は見えない、外部に送れない、といった制御ができる
- 作り方は、ルールを定義 → ポリシーを作成 → タグに付与 → タグをテーブルに付与、の流れ
デモ：5つのパターン
参考に過去私の検証した記事を掲載します。
ランサムウェア・不正操作対策
2つのアプローチ
- 外部からの攻撃だけでなく、内部やエージェントによる破壊的な操作を防ぐために、承認フローを挟む
- Backup: ACCOUNTADMIN でも削除・変更できないスナップショットを取れる。
- Multi-party Approval（MPA）: 承認者の承認がなければ、ACCOUNTADMIN でも他ユーザーへの GRANT ができない
- 正式リリース済み（公式ドキュメントでは 2026年8月に GA）
Multi-party Approvalの承認フロー
- デモのポリシーは3つのルールを持つ。MPA 自体の変更、MFA の無効化、特権ロールの付与をそれぞれ保護する
- 承認者と必要承認数（デモでは 1。既定値は 2）を YAML で定義する
- ポリシーは
ALTER ACCOUNT SETでアカウントに適用し、YAML の内容や適用状況を確認できる - 保護対象の操作を実行するとブロックされ、リクエスト ID が発行される
- 理由を添えて申請し、承認者が承認して初めて実行できる
デモ：承認と拒否
- ACCOUNTADMIN を別ユーザーに GRANT しようとするとブロックされ、リクエスト ID が表示される
- メッセージは「Blocked by Multi-party Approval」で、リクエストするよう促される
- リクエスト ID を申請用の関数に渡して理由を登録する。状態は Snowsight のメニューからも確認でき、取り消しもできる
- 承認者側の Snowsight では「リクエストと承認」に承認待ちが表示される。内容を確認して承認すると、同じ GRANT が実行できた
- GRANT と REVOKE は別の操作なので、それぞれリクエストが必要
- 拒否のケースでは、MPA の無効化を試みてブロックされ、申請したが承認者が妥当性なしとして拒否。再実行しても承認がないため失敗した
- 権限があっても承認なしでは実行できないため、エージェントが勝手にロールを付与するような操作も防げる
参考に過去私の検証した記事を掲載します。
セッションのまとめ
- データの発見と保護が最も重要。テーブルにどんな情報があり、どう保護すべきかを、運用負担を下げながら実行できる
- AI によるガバナンス: 自動分類の AI モードでより精緻に分類できる
- Snowflake CoCo に「マスキングポリシーのないテーブルはどれか」と聞くこともできる。SQL を書かずにガバナンスを強化できる
- AI のためのガバナンス: AI に何かをさせるのは強力だが「やらせすぎない」ことが重要
- エージェントには見せない、持ち出させない、勝手に GRANT させない、という条件をポリシーに書いて、安全に AI の利用を進めてほしい
セッションでは語られなかった新機能
Restricted Session Scope
AI エージェントがユーザーの代わりに操作する間だけ、使える権限に上限(privilege ceiling)を設ける仕組みです。RBAC は変更せず、権限を追加することもありません。
AIガバナンスの中核を担う機能と思いますので是非チェックしてください。
参考に過去私の検証した記事を掲載します。
関連ドキュメント
セッションで紹介された機能の公式ドキュメントはこちらです。
所感
SNOWFLAKE WORLD TOUR TOKYO 2026 Day2 のセッション「Snowflakeで実現するデータ・AIガバナンス」に参加しました。マスキング（見せ方）、Data Movement Policies（持ち出し）、Multi-party Approval（操作）という多層防御を扱うセッションでした。これらが「AI のためのガバナンス」という1本のストーリーで整理されていました。
個人的にAI周りのガバナンス機能は検証していたので、「そうだよね」と頷く箇所が多くSnowflake社と同じ考えを持てており良かったです。
この記事が何かの参考になれば幸いです！
