Snowflake Horizon Catalogとは？機能と設定SQLを解説

Snowflake Horizonは、2025年6月のSnowflake Summitを境に公式資料上の呼称が「Horizon Catalog」へ揃い、2026年6月のSummit 26でさらに役割が広がりました。Snowflake内部のテーブルに閉じたガバナンス機能から、外部カタログのApache Icebergテーブル、そしてAIエージェントのアクセス統制までを1つの層で扱う位置づけです。一方で日本語の解説記事には、2024年時点の呼称や、実行するとエラーになるSQLがそのまま残っているものが少なくありません。この記事ではSnowflake公式ドキュメントで逐語確認した構文だけを使い、Horizon Catalogの位置づけ、データ品質モニタリング、機密データ分類、アクセス制御、Open Catalogとの使い分けまでを実装できる粒度で整理します。

まとめ：Horizon Catalogの要点

Horizon Catalogは、Snowflakeのデータウェアハウス本体とは別レイヤーの「カタログ兼ガバナンス層」です。Snowflakeにおけるデータカタログの実体はこの層にあたります。公式ドキュメントは「the agentic catalog for all your data, whether it is inside or outside of Snowflake」と定義し、2026年6月2日のプレスリリースは「Snowflake Horizon Catalog serves as the universal AI catalog for enterprise data.」と述べており、いずれもSnowflakeの外にあるデータを対象に含めます。

導入判断で先に押さえるべき点は2つあります。品質モニタリングとデータ保護ポリシーはEnterprise Edition以上の機能であること、そしてApache Icebergの相互運用を新規に始めるならOpen CatalogではなくHorizon Catalog側を選ぶことです。後者は公式ドキュメントが明示している運用上の分岐で、後述します。

Horizon Catalogの定義とSnowflake本体との切り分け

Horizon Catalogを「Snowflakeそのもの」と説明している解説を見かけますが、これは誤りです。仮想ウェアハウスによるクエリ実行やストレージはSnowflakeプラットフォーム本体の役割で、Horizon Catalogが担うのはその上に載るメタデータ管理・検出・統制です。公式ドキュメントのナビゲーション階層も「Snowflake Horizon Catalog > Data Governance > Data protection policies」という並びになっており、ガバナンス機能群の総称として使われています。

呼称が「Snowflake Horizon」から変わった経緯

Snowflakeが2025年6月3日にサンフランシスコで出したプレスリリースは「Snowflake introduces enhanced interoperability and new AI-powered security and governance in Snowflake Horizon Catalog, including the Copilot for Horizon Catalog and AI-led monitoring.」と記載しています。同リリースでは、任意のIceberg RESTカタログが管理するApache IcebergオブジェクトをHorizon Catalogと自動同期するカタログリンクドデータベース、およびSQLの知識なしにガバナンス上の疑問へ答えるCopilot for Horizon Catalogが挙げられました。

役割はその1年後にもう一段広がりました。2026年6月2日のSummit 26に合わせたプレスリリースは、Horizon Catalogを「the universal AI catalog for enterprise data」と定義し直しています。同リリースで一般提供に入ったのが、人・ツール・AIエージェントが同じ業務文脈を共有するためのHorizon Contextと、エージェントがデータへ触れる前に検証済みのIDを与えるAgent Identityです。SQLを書かずに共通のビジネスロジックを定義するSemantic Studioはプライベートプレビュー段階と案内されています。

呼称の変更はドキュメント側にも及んでいます。行アクセスポリシーやマスキングポリシーの解説ページは、いずれもSnowflake Horizon Catalogを親階層とするパンくずの下に置かれました。旧称で書かれた資料を参照する際は、Catalog付きの現行名に読み替えたうえで、機能の範囲がSnowflake外部のデータとエージェントの振る舞いにまで広がっている点に注意してください。

本体側の機能と混同しやすい境界

ロールベースのアクセス制御（GRANT／REVOKE）はSnowflakeの基盤機能で、Horizon Catalogが追加したものではありません。Horizon Catalog側の価値は、その基盤の上でタグ・分類・ポリシーを一貫して適用し、どのデータが機密でどこから来たかを追跡できる状態にする点にあります。「Horizonを入れる」という表現も実態に合いません。Snowflakeアカウントに含まれる機能群であり、個別に契約して導入する製品ではないからです。

データ検出とAIコンテキストを支える機能

Universal Searchが探せる範囲

Snowflakeのデータカタログとしての入口がUniversal Searchです。Snowsightのホーム画面から使う検索機能で、アカウント内のオブジェクトに加えてSnowflake Marketplaceのデータ製品、公式ドキュメント、Community Knowledge Baseの記事を横断します。表記ゆれやスペルミスがあっても結果を返し、公式が挙げる「sales opportunities that are likely to close」のような自然言語の問いかけも受け付けます。

実装上、最も重要な制約は検索対象がメタデータに限られる点です。公式ドキュメントは「Universal Search searches only the object metadata, not the contents of your database objects.」と明記しています。つまりデータベースオブジェクトに格納された値は対象外で、検索されるのはオブジェクト名・コメント・タグです。コメントを空のまま運用しているとヒットしません。表示される結果は実行中のロールと二次ロールの権限に依存するため、同じ検索語でも利用者ごとに結果が変わります。

Cortexによるテーブル説明の自動生成

コメントを人手で埋める負担を下げるのが、Cortexを使った説明の自動生成です。ストアドプロシージャを呼び出すと、テーブルと列の説明文がJSONで返ります。

CALL AI_GENERATE_TABLE_DESC(
  'mydb.sch1.hr_data',
  {
    'describe_columns': true,
    'use_table_data': false
  });

use_table_dataをtrueにすると、メタデータだけでなくサンプルデータも参照して説明を作ります。機微なデータを含むテーブルではfalseのまま運用し、列名とデータ型から生成させる判断が安全です。呼び出しには対象テーブルへのSELECT権限とSNOWFLAKE.CORTEX_USERデータベースロールが必要で、さらにリージョンがCOMPLETE関数の対象LLM（Mistral-7bやLlama 3.1-8bなど）に対応している必要があります。東京リージョンでCortex機能を使う設計をするなら、この対応状況の確認を先に済ませてください。

見落としやすいのは、この呼び出しがコメントを書き込まない点です。公式ドキュメントは「The generated description is not retained by Snowflake until it is saved by the user.」とし、保存するにはALTER TABLE t1 SET COMMENT = 'ai generated description';のようなSQLを別途実行する必要があると明記しています。生成しただけではUniversal Searchの検索対象になりません。棚卸しで数百テーブルを一気に処理するなら、生成と保存をまとめて回すストアドプロシージャを組む前提で見積もってください。なお、5,000列を超えるオブジェクトでは列の説明を生成できません。

依存関係の追跡に使うビュー

ビューやテーブルの参照関係は、ACCOUNT_USAGEスキーマのOBJECT_DEPENDENCIESビューで確認します。

SELECT referenced_database,
       referenced_object_name,
       referencing_object_name,
       dependency_type
FROM snowflake.account_usage.object_dependencies
WHERE referenced_object_name = 'MY_TABLE';

DEPENDENCY_TYPE列にはBY_ID、BY_NAME、BY_NAME_AND_IDのいずれかが入ります。ここで押さえるべき制約が2つ。1つはこのビューの遅延が最大3時間ある点で、直前に作ったビューはまだ反映されていない可能性があります。もう1つは、CTAS・INSERT・MERGEのようにデータをコピーする操作では依存関係の行が作られないことです。

そのデータ移動を追うのがリネージで、SnowsightのUIだけでなくSQLからも取得できます。テーブル関数SNOWFLAKE.CORE.GET_LINEAGEがそれにあたり、Enterprise Edition以上で使えます。

SELECT distance,
       source_object_name,
       target_object_name
FROM TABLE(SNOWFLAKE.CORE.GET_LINEAGE('my_database.sch.table_a', 'TABLE', 'DOWNSTREAM'));

第2引数のオブジェクトドメインにはCOLUMNやTABLEなどを、第3引数の方向にはUPSTREAMかDOWNSTREAMを渡します。参照関係はOBJECT_DEPENDENCIES、データの流れはGET_LINEAGEという役割分担で捉えると、どちらを引くべきか迷いません。

データ品質モニタリングの設定手順

システムDMFの割り当てとスケジュール

データ品質は、データメトリック関数（DMF）をテーブルに紐づけて測ります。NULL件数や行数など、よく使う指標はSNOWFLAKE.COREスキーマにシステムDMFとして用意されているので、自分で定義する必要はありません。

ALTER TABLE t
  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT
    ON (c1);

ALTER TABLE hr.tables.empl_info SET
  DATA_METRIC_SCHEDULE = 'USING CRON 0 8 * * MON,TUE,WED,THU,FRI UTC';

スケジュールを指定しない場合、DMFは1時間に1回実行されます。公式例にある'5 MINUTE'のような分単位の指定、上のようなCRON式のほか、'TRIGGER_ON_CHANGES'を指定してテーブルの変更をトリガーに実行する形も選べます。日次バッチで入るテーブルに毎時のチェックをかけるのは無駄なので、ロード完了時刻の直後を狙ったCRON式か、TRIGGER_ON_CHANGESに寄せる設計を勧めます。

合否条件の宣言と結果の確認

測るだけでなく合否を宣言したい場合は、テーブル定義にEXPECTATION句を付けます。

CREATE OR REPLACE TABLE orders (
  order_id    NUMBER,
  customer_id NUMBER
)
WITH DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT
  ON (customer_id)
  EXPECTATION no_null_customers ( VALUE = 0 ),
     SNOWFLAKE.CORE.DUPLICATE_COUNT
  ON (order_id)
  EXPECTATION no_duplicate_orders ( VALUE = 0 );

実行結果はイベントテーブルに蓄積され、DATA_QUALITY_MONITORING_RESULTSビュー（イベントテーブルを平坦化したもの）または同名のテーブル関数から参照します。3つの参照方法はアクセス制御要件が別々で、テーブル関数を呼べるアプリケーションロールがイベントテーブルへのクエリまで許すとは限りません。監視ダッシュボードを作る前に、閲覧させたい相手がどの経路で読めるのかを決めてください。なお、データ品質モニタリングはEnterprise Edition以上の機能です。

機密データの分類とアクセス制御

分類プロファイルによる自動分類

機密データの自動分類は、まず分類プロファイルを作り、それをデータベースやスキーマに割り当てる流れです。

CREATE OR REPLACE SNOWFLAKE.DATA_PRIVACY.CLASSIFICATION_PROFILE
  my_classification_profile(
    {
      'minimum_object_age_for_classification_days': 0,
      'snowflake_semantic_categories':
        [
          {'category': 'NAME'},
          {'category': 'NATIONAL_IDENTIFIER'}
        ]
    });

ALTER DATABASE my_db
  SET CLASSIFICATION_PROFILE = 'governance_db.classify_sch.my_profile';

プロファイルにはタグマップを含められるので、たとえばNAMEとNATIONAL_IDENTIFIERに該当した列へは「Highly Confidential」、EMAILに該当した列へは「Confidential」といったタグ値を自動で付与できます。パスポート番号や納税者番号のように国ごとに書式が違うカテゴリでは、country_codesで対象国を絞ります。

費用の把握も設定と同時に済ませておくのが実務的です。自動分類はサーバーレスのクレジットを消費し、使用量はACCOUNT_USAGE.METERING_HISTORYでservice_typeが’SENSITIVE_DATA_CLASSIFICATION’の行として計上されます。実行ロールにはEXECUTE AUTO CLASSIFICATION権限とSNOWFLAKE.CLASSIFICATION_ADMINデータベースロール、そしてアカウントに対するAPPLY TAG権限（GRANT APPLY TAG ON ACCOUNT TO ROLE data_engineer;）が必要です。

マスキングポリシーと行アクセスポリシー

列単位で見せ方を変えるのがマスキングポリシー、行単位で見せる範囲を絞るのが行アクセスポリシーです。どちらもポリシーを作ってから対象へ適用する2段階で、いずれもEnterprise Edition以上が必要です。

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number
  SET MASKING POLICY employee_ssn_mask;

CREATE OR REPLACE ROW ACCESS POLICY rap_it
AS (empl_id varchar) RETURNS BOOLEAN ->
  'it_admin' = current_role();

ALTER TABLE t1 ADD ROW ACCESS POLICY rap_it ON (empl_id);

ポリシーを更新するときに列から外す必要はありません。ALTER MASKING POLICYで定義を書き換えている間も、列は保護されたままです。別のポリシーに差し替える場合は、UNSETとSETの2文に分けるとその間だけ列が無防備になるため、ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;のようにFORCEで一度に置き換えます。どのオブジェクトにポリシーが当たっているかを棚卸しするには、INFORMATION_SCHEMA.POLICY_REFERENCESテーブル関数を使います。

AIエージェント経由の閲覧を止める条件分岐

ここが2024年時点の解説には存在しなかった論点です。Snowflake内でエージェントが動く前提が加わったため、「人間が自分の権限で見るのは許すが、エージェントの実行コンテキストからは見せない」という制御が必要になりました。Agent Identityと呼ばれる一連の機能がこれを担い、2026年6月に一般提供へ入っています。マスキングポリシーの本体でSYS_CONTEXTを評価すると、判定を表現できます。

CREATE OR REPLACE MASKING POLICY email_agent_mask AS (val STRING) RETURNS STRING ->
  CASE
    WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN = TRUE THEN '********'
    WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
    ELSE '********'
  END;

同じ判定は行アクセスポリシーのほか、射影・集計・結合の各ポリシーでも使えます。行アクセスポリシーならエージェントが有効なときにFALSEを返し、行ごと隠せます。

エージェントに社内データを触らせる計画があるなら、ロール設計だけで足りると考えるべきではありません。ユーザーの代理で動く委任型エージェントはセッションの主体が人間のままなので、ロールを絞る発想では業務に必要な権限とエージェントへ渡したくない権限が同じロールに同居してしまいます。ポリシー本体での分岐は、その同居を前提に人とエージェントを区別する標準的な手段です。権限そのものに上限をかけたい場合は、エージェントセッションの実効権限をユーザーのロールとの積集合に絞るRestricted Session Scopes（プライベートプレビュー）を併用する設計になります。

Trust Centerによるセキュリティ態勢の点検

Trust Centerは、コンプライアンス認証の情報を閲覧するポータルではありません。Snowflakeアカウントをスキャナの推奨事項に照らして評価し、リスクがあれば発見事項（finding）を生成する仕組みです。問題がなければ発見事項は作られないため、一覧が空であること自体が結果になります。

USE ROLE ACCOUNTADMIN;

CREATE ROLE trust_center_admin_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_ADMIN TO ROLE trust_center_admin_role;

CREATE ROLE trust_center_viewer_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_VIEWER TO ROLE trust_center_viewer_role;

GRANT ROLE trust_center_admin_role TO USER example_admin_user;

点検観点と発見事項の読み方

公式が挙げる代表的な用途は、パスワード認証を使う人間ユーザーへの多要素認証の強制状況、権限過多のロールの洗い出し、ACCOUNTADMINとSECURITYADMINの保有者数の抑制、90日間ログインのないユーザーの検出です。棚卸しの観点がそのまま並んでいるので、四半期ごとの点検項目として流用できます。リーダーアカウントはTrust Centerの対象外である点だけ、事前に把握しておいてください。

発見事項は画面で追うだけでなく、SNOWFLAKE.ACCOUNT_USAGE.TRUST_CENTER_FINDINGSビューからSQLで取得できます。重大度や状態を条件に抽出できるので、監査資料の作成やチケット起票の自動化に載せる場合はこちらを使ってください。

IcebergとOpen Catalogの使い分け

新規構成でOpen Catalogを選べない理由

Apache Icebergを絡めた構成を検討しているなら、ここが2024年の解説記事と最も結論が変わる部分です。Snowflake Open Catalogは、Apache Polaris向けのマネージドサービスとして提供されているIceberg RESTカタログで、旧称のPolaris Catalogで記憶している方も多いはずです。

しかし現在の公式ドキュメントは、Open Catalogの概要ページ冒頭で「New customers should use Snowflake Horizon Catalog for Apache Iceberg™ tables and multi-engine interoperability with Iceberg.」と案内し、続けて「Customers who haven’t previously created a Snowflake Open Catalog account can’t sign up for their first Open Catalog account.」と記しています。つまりOpen Catalogアカウントを作ったことがない組織は、もう最初の1つを作れません。既存利用者は継続利用と追加アカウントの作成ができます。

カタログリンクドデータベースで外部カタログと同期する構成

したがって、これから設計する構成でOpen Catalogを前提に置くのは避けてください。Icebergテーブルの複数エンジン相互運用はHorizon Catalog側で組み、外部のIceberg RESTカタログが管理するオブジェクトはカタログリンクドデータベースで同期させる、というのが現時点の既定路線です。この同期はAWS Glueなど任意のIceberg RESTカタログを相手に取れるため、既存のレイクを作り替えずにガバナンスだけをHorizon Catalogへ寄せられます。「Polaris Catalogを使えばよい」と書いてある2024年前後の記事は、そのまま実行できません。

現行Snowflakeに存在しない構文と正しい代替

Horizonの日本語解説には、実行するとエラーになるSQLを載せたものが流通しています。この記事も2024年に公開した旧版では、コード例のほぼ全てが実在しない構文でした。今回の改稿で全面的に差し替えたうえで、頻出する誤りを公式ドキュメントの実在構文と対にして残します。

特に実害が出やすいのがレプリケーションです。「CREATE DATABASE … CLONE」を複製として紹介している記事がありますが、これはゼロコピークローンであってリージョン間の複製ではありません。また「CREATE REPLICATION GROUP … FOR DATABASE」という書き方も通りません。実際の構文はOBJECT_TYPESとALLOWED_ACCOUNTSを必須で取ります。

CREATE REPLICATION GROUP myrg
    OBJECT_TYPES = DATABASES
    ALLOWED_DATABASES = db1
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

CREATE REPLICATION GROUP myrg
    AS REPLICA OF myorg.myaccount1.myrg;

1つ目をソースアカウントで、2つ目をターゲットアカウントで実行します。クローンと複製を取り違えたまま事業継続計画を書くと、リージョン障害時に復旧できない構成が出来上がります。出典が示されていないSQLは、まず公式ドキュメントで構文を引いてから使ってください。

よくある質問

Snowflake HorizonとHorizon Catalogは別物ですか？

別製品ではありません。Snowflakeの公式資料は2025年6月3日のプレスリリース以降、ガバナンスと検出の機能群をSnowflake Horizon Catalogという名称で統一して呼んでいます。2026年6月2日のプレスリリースでは「the universal AI catalog for enterprise data」と定義し直されました。旧名で書かれた資料を読むときは、Catalog付きの現行名に読み替えて差し支えありません。

Horizon Catalogは追加費用がかかりますか？

個別に購入する製品ではなく、Snowflakeアカウントの機能群です。ただしデータ品質モニタリングと、マスキングポリシー・行アクセスポリシーによるデータ保護はEnterprise Edition以上が条件です。機密データの自動分類はサーバーレスのクレジットを消費し、ACCOUNT_USAGE.METERING_HISTORYでservice_typeが’SENSITIVE_DATA_CLASSIFICATION’の行として確認できます。

Polaris Catalogは今も使えますか？

Polaris Catalogはマネージドサービスとして提供される際にSnowflake Open Catalogという名称になりました。既存の利用者は継続して使え、追加アカウントも作成できますが、Open Catalogアカウントを作ったことがない組織は新規にサインアップできません。これから始めるならHorizon Catalog側でIcebergの相互運用を組む前提で設計してください。

Universal Searchでテーブルの中身を検索できますか？

できません。検索対象はオブジェクト名、コメント、タグといったメタデータに限られ、データベースオブジェクトに格納された値は対象外です。ヒット率を上げたい場合は列コメントを埋めることが有効で、その下書きをAI_GENERATE_TABLE_DESCで作れます。ただし生成結果はJSONで返るだけなので、SET COMMENTで保存するまでは検索対象になりません。

データ品質チェックの実行間隔はどこで決まりますか？

テーブルのDATA_METRIC_SCHEDULEパラメータで決まり、未設定なら1時間に1回です。分間隔の指定、CRON式による曜日と時刻の指定、テーブル変更を契機にするTRIGGER_ON_CHANGESから選べます。現在の設定はSHOW PARAMETERS LIKE 'DATA_METRIC_SCHEDULE' IN TABLE hr.tables.empl_info;のようにテーブル名まで指定して確認します。

関連記事

• Snowflake Cortex Agentsとは？CREATE AGENT・REST API・権限設定の実装手順
• Snowflakeの新AI機能「AI_EXTRACT」と「AI_PARSE_DOCUMENT」が日本語に対応
• Snowflake Document AIとは何か？その概要と提供される価値
• Streamlit in Snowflakeとは？料金・課金体系と使い方を徹底解説