はじめに
こんにちは！STS技術チームです。
普段はSnowflakeの運用・保守を担当し、お客様のデータ活用を支援しています。
皆さんは、ご自身の組織で自社データの利用状況を細部まで把握できていますか？
データの民主化が進む一方で、現場では次のような運用上の課題が増えています。
- 影響調査： テーブルを削除したいが、どこで参照されているか不明で作業できない
- 追跡困難： ビューや UDF を経由した間接アクセスまで把握できない
- 監査対応： 過去の証跡が必要だが、その保持期間が足りない
これらを解決する有力な機能が、ACCESS_HISTORY（アクセス履歴）です。
ACCESS_HISTORY により「いつ・誰が・どのオブジェクト／列に」アクセスしたかを追跡でき、監査・影響範囲調査や、不審な利用の兆候把握のための証跡として活用できます。
本記事では、ACCESS_HISTORY の基本とSnowflake のストレージ機能を組み合わせて「1年超の長期保持」を自動化する手順を実践的に解説します。実際に使えるクエリ例と自動化スクリプトも掲載しますので、運用フローへの組み込みに役立ててください。
本記事でわかること
- アクセス履歴とは何か、何ができるのか
- ACCESS_HISTORY ビューのクエリ方法と実際の使用例
- データを1年以上保持するための実装方法
概要
アクセス履歴とは、ユーザーのクエリによるデータの読み取り操作と、INSERT、UPDATE、DELETE、およびCOPYコマンドなどのデータ書き込み操作を追跡する機能です。
この履歴は ACCESS_HISTORY ビューから照会でき、コンプライアンス監査の支援や、よくアクセスされるテーブルやカラムの把握に役立ちます。
ユーザーのアクセス履歴は、ACCOUNT_USAGE および ORGANIZATION_USAGE スキーマの ACCESS_HISTORY ビューをクエリすることで確認できます。
主要な機能
ACCESS_HISTORYビューの各レコードには、SQLステートメントごとに以下の情報が含まれます。
- 直接・間接的にアクセスされたソース列 – クエリのデータ元となる基礎テーブル
- 投影列 – SELECT文で指定されるなど、クエリ結果としてユーザーに表示される列
- フィルタ列 – WHERE句などで使用される、結果を決定するために使用されるが投影されない列
アカウントレベルと組織レベル
管理者は、アカウントのACCOUNT_USAGEスキーマのACCESS_HISTORYビューをクエリすることでアカウントレベルでアクセス履歴を監視できます。ACCOUNT_USAGE.ACCESS_HISTORYビューの使用にビュー維持のための追加コストはかかりません。
ORGANIZATION_USAGEスキーマのACCESS_HISTORYビューは、組織内のすべてのアカウントのアクセス履歴を単一のビューに集約し、組織レベルのアクセス履歴を提供します。
活用方法とユースケース
データ検出
- 未使用のデータを検出し、アーカイブまたは削除の判断材料とする
機密データの移動追跡
- 外部クラウドストレージ（例：Amazon S3 バケット）と Snowflake のターゲットテーブル間のデータ移動（双方向）を追跡する
- Snowflake テーブル間の内部データ移動を追跡する
- 機密データの移動を追跡後、マスキングポリシーや行アクセスポリシーを適用してデータを保護。さらにアクセス制御設定を更新し、ステージへのアクセスを強化する。あわせてテーブルやタグを設定し、機密データを含むステージ・テーブル・列のコンプライアンス要件を追跡できるようにする
データ検証
- レポート、ダッシュボード、チャート、グラフなどのデータ可視化成果物について、データを元のソースまで追跡することで、その正確性と整合性を検証する
コンプライアンス監査
- GDPR や CCPA などのコンプライアンス規制に対応するため、テーブルまたはステージで書き込み操作を実行した Snowflake ユーザーを特定し、その操作がいつ発生したかを特定する
全体的なデータガバナンスを強化する
- ACCESS_HISTORY ビューは、アクセスされたデータ、データアクセスが行われた時刻、さらにデータがソースオブジェクトからターゲットオブジェクトへどのように移動したかを、統一的に把握できる
制限事項
対応エディション
- Snowflake Enterprise Edition（またはそれ以上）
リリース状況
- GA（Generally Available：一般提供）
制限
ビューの待機時間は最大3時間。
データの保持期間は1年（365日）
ACCESS_HISTORY ビューは、以下の種類のアクセスについてはログに記録しない。
- Snowflake が提供するテーブル関数、ACCOUNT_USAGE ビュー、ORGANIZATION_USAGE ビューへのアクセス
- RESULT_SCAN による過去のクエリ結果の取得
- シーケンスに対する通常利用（新しい値の生成など）。※DDL 操作が実行された場合のみ記録される
- ベーステーブルと直接オブジェクトの間に存在する中間ビューへのアクセス
例：View_A → View_B → View_C → Base_Table の場合、View_A に対するクエリは View_A と Base_Table に記録され、View_B と View_C には記録されない - ストリーム更新のための操作
- レプリケーションに起因するデータ移動
- 失敗したクエリ（※QUERY_HISTORY ビューには記録されるが、ACCESS_HISTORY ビューには記録されない）
データを1年以上保持するための実装方法
ACCESS_HISTORY ビューのデータは、デフォルトでは1年間のみ保持されます。
しかし、以下の方法によりACCESS_HISTORY ビューのデータを定期的に独自テーブルへ保存（自動化）することで、1年以上の保持を実現できます。
前提条件
- Snowflakeの ACCOUNTADMIN ロールが必要
事前準備
使用するロール、データベース、スキーマ、ウェアハウスを作成します。
作成したロールは SYSADMIN ロールに継承させ、現在のユーザーに割り当てます。
また、以下のスクリプトに従って必要な権限を付与します。
-- USERADMIN ロールでロールを作成
USE ROLE USERADMIN;
CREATE ROLE IF NOT EXISTS KENSHO_ROLE;
-- SYSADMIN ロールでウェアハウスを作成
USE ROLE SYSADMIN;
CREATE WAREHOUSE IF NOT EXISTS KENSHO_WH;
-- KENSHO_ROLE ロールにDB作成権限を付与 ※アカウント管理者に依頼してください
USE ROLE ACCOUNTADMIN;
GRANT CREATE DATABASE ON ACCOUNT TO ROLE KENSHO_ROLE;
-- SYSADMIN ロールに KENSHO_ROLE ロールを継承
USE ROLE SECURITYADMIN;
GRANT ROLE KENSHO_ROLE TO ROLE SYSADMIN;
-- KENSHO_ROLE ロールにウェアハウス使用権限を付与
GRANT USAGE ON WAREHOUSE KENSHO_WH TO ROLE KENSHO_ROLE;
-- KENSHO_ROLE ロールに GOVERNANCE_VIEWER ロールを継承
GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE KENSHO_ROLE;
-- ログインユーザーに KENSHO_ROLE ロールを付与
SET MY_USER = CURRENT_USER();
GRANT ROLE KENSHO_ROLE TO USER IDENTIFIER($MY_USER);
-- 実行ロールを切り替え
USE ROLE KENSHO_ROLE;
-- データベースを作成
CREATE DATABASE IF NOT EXISTS KENSHO_DB;
USE DATABASE KENSHO_DB;
-- スキーマを作成
CREATE SCHEMA IF NOT EXISTS KENSHO_SCH;
USE SCHEMA KENSHO_SCH;① データを保存する蓄積用の独自テーブルを作成します
WHERE 1=0 により、実際のデータは1件も取得されず、空のテーブルが作成されます。
CREATE TABLE IF NOT EXISTS KENSHO_DB.KENSHO_SCH.ACCESS_HISTORY_ARCHIVE
AS SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY WHERE 1=0;② ACCESS_HISTORYビューの最新データだけを追加します
もしそのテーブルが空なら、 ‘2026-01-01’ 以降のデータを追加します。（※ここで取得する日付は例）
INSERT INTO KENSHO_DB.KENSHO_SCH.ACCESS_HISTORY_ARCHIVE
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY
WHERE QUERY_START_TIME > COALESCE(
(SELECT MAX(QUERY_START_TIME) FROM KENSHO_DB.KENSHO_SCH.ACCESS_HISTORY_ARCHIVE),
'2026-01-01'
);
③ Snowflakeの Task を使って自動化（スケジュール実行）します
CREATE OR REPLACE TASK KENSHO_DB.KENSHO_SCH.ARCHIVE_ACCESS_HISTORY_TASK
WAREHOUSE = KENSHO_WH
SCHEDULE = 'USING CRON 0 15 * * * Asia/Tokyo'
AS
INSERT INTO KENSHO_DB.KENSHO_SCH.ACCESS_HISTORY_ARCHIVE
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY
WHERE QUERY_START_TIME > COALESCE(
(SELECT MAX(QUERY_START_TIME) FROM KENSHO_DB.KENSHO_SCH.ACCESS_HISTORY_ARCHIVE),
'2026-01-01'
);④ EXECUTE TASK 権限をロールに付与します（これがないとタスクが実行されません）
USE ROLE ACCOUNTADMIN;
GRANT EXECUTE TASK ON ACCOUNT TO ROLE KENSHO_ROLE;⑤ タスクの実行を有効化します
USE ROLE KENSHO_ROLE;
ALTER TASK KENSHO_DB.KENSHO_SCH.ARCHIVE_ACCESS_HISTORY_TASK RESUME;
これにより、ACCESS_HISTORY ビューのデータを定期的に独自テーブルへ自動的に保存することができます。
⑥ 下記SQLでタスクが実行されているかを確認することができます（例：過去7日分）
SELECT *
FROM TABLE(INFORMATION_SCHEMA.TASK_HISTORY(
TASK_NAME = 'KENSHO_DB.KENSHO_SCH.ARCHIVE_ACCESS_HISTORY_TASK',
SCHEDULED_TIME_RANGE_START => DATEADD('DAY', -7, CURRENT_TIMESTAMP())
))
ORDER BY COMPLETED_TIME DESC;以下の内容が確認可能です：
- 実行結果（成功/失敗）
- タスクの実行スケジュール実行
- 実行されるSQL
⑦ ⑥と同様のSQLでタスクが実行されたことを確認します
⑧ 下記SQLで最新のデータが入っているか確認することができます（※LIMIT 100 は任意）
SELECT *
FROM KENSHO_DB.KENSHO_SCH.ACCESS_HISTORY_ARCHIVE
ORDER BY QUERY_START_TIME ASC
LIMIT 100;
⑨ タスクの実行を無効化します
ALTER TASK KENSHO_DB.KENSHO_SCH.ARCHIVE_ACCESS_HISTORY_TASK SUSPEND;
まとめ
本記事では、Snowflake のアクセス履歴機能について基本概念から1年以上のデータ保持を実現する自動化方法まで詳しく解説しました。
- アクセス履歴機能により、データの利用状況を詳細に把握できること
- ACCESS_HISTORYビューを使用して、過去1年間のアクセス履歴を確認できること
- タスクを使用して定期的にアーカイブテーブルへ蓄積することで、データの長期保存が可能になること
- 適切な権限設定と定期実行により、継続的なデータガバナンスが実現できること
これらの機能を組み合わせることで、コンプライアンス要件への対応やデータ利用の透明性向上に役立ちます。
ぜひ皆さんの環境でも、アクセス履歴機能を活用したデータガバナンス強化に取り組んでみてください。
「分かる」だけではなく「話せる」、STSだからこそ届けられる情報
コメント