Snowflake-Labs

Postgres and Iceberg: pg_lake, pg_duckdb and the Postgres lakehouse "Postgres Iceberg" covers four different jobs. You might want to query Iceberg or Parquet files on S3 from Postgres. You might want Postgres to write Iceberg tables. You might want Postgres to be the catalog that other engines use. Or you might want your Postgres data to land in Iceberg for a warehouse to read. Each job has a different tool, and two of the tools people still recommend are no longer maintained. This post sorts them out. I have not run pg_lake or Iceberg in production. What I did run, on my laptop: PyIceberg 0.12.0 with a plain Postgres 16 container as the Iceberg catalog, and the pg_duckdb Docker image (Postgres 18.1) reading the same table. The numbers below come from those runs. Everything else links to its source, checked on 1 October 2026. Postgres and Iceberg: the options at a glance | Option | Job | Licence | Latest release | Status | |---|---|---|---|---| | pg_lake | Write and read Iceberg, Postgres as catalog, COPY to/from S3 | Apache-2.0 | v3.5.3, 2026-09-24 | Active | | pg_duckdb | Read Parquet, CSV, JSON, Iceberg, Delta; fast analytics | MIT | v1.1.1, 2025-12-18 | Active, PG 14 to 18 | | PyIceberg / Iceberg JDBC SQL catalog | Plain Postgres as the catalog only | Apache-2.0 | PyIceberg 0.12.0 | Active | | Snowflake Postgres | Managed Postgres with pg_lake | Commercial | GA 2026-02-24 | Active | | Supabase Analytics Buckets + Supabase ETL | CDC from Postgres into Iceberg on S3 Tables | ETL is Apache-2.0 | — | Public alpha | | Databricks Lakebase | Managed Postgres, sync to the lakehouse | Commercial | GA on AWS 2026-02-03 | Sync is beta, Delta only | | pg_mooncake | "Real-time analytics on Postgres tables" | MIT | v0.1.3 | Dormant: team joined Databricks | | ParadeDB pg_analytics | DuckDB-backed lake queries | PostgreSQL | — | Archived 2025-03-19 | The short version: pg_lake if Postgres should own Iceberg tables, pg_duckdb if Postgres only needs to read the lake, and a managed product if you want someone else to run the plumbing. pg_lake: Postgres that writes Iceberg pg_lake began as Crunchy Data Warehouse. Snowflake bought Crunchy Data in June 2025 and open-sourced the code as pg_lake in November 2025. Per its README, it lets you: - Create and change Iceberg tables from Postgres, inside ordinary transactions. - Query Parquet, CSV, JSON and Iceberg files in object storage. - COPY query results out to S3 as Parquet, CSV or JSON, and back in. CREATE EXTENSION pg_lake CASCADE; CREATE TABLE events (id bigint, ts timestamptz, kind text) USING iceberg; INSERT INTO events VALUES (1, now(), 'view'); COPY (SELECT * FROM events) TO 's3://bucket/exports/events.parquet'; The design has two parts. Postgres runs the pg_lake extensions. A separate process, pgduck_server, runs DuckDB and speaks the Postgres wire protocol locally. pg_lake hands scans and computation to it. You don't query it directly, but you do deploy and size it: it defaults to 80% of system memory, per the README. From the Iceberg tables doc: - Postgres is the catalog. Commits update pg_lake's catalog tables in the same transaction as the data change. An iceberg_tables view lets Spark, PyIceberg and iceberg-rust find the tables through their JDBC or SQL catalogs. - REST catalogs work too. A table can live in an external REST catalog, so other engines see it where they already look. - Compaction is built in. VACUUM merges small files and removes expired ones, and autovacuum runs it every 10 minutes. - Some SQL is not supported on Iceberg tables: MERGE, INSERT ... ON CONFLICT, SELECT ... FOR UPDATE. An update or delete locks the table, so only one runs at a time. - Other engines read, Postgres writes. External tools cannot yet write to tables pg_lake created. Tables attached from a REST catalog are read-only in pg_lake. The managed form is Snowflake Postgres, generally available since 24 February 2026. Since 14 July 2026 a catalog integration lets Snowflake discover those tables and read them as read-only Iceberg tables. I did not run pg_lake for this post. Its Docker setup builds the images locally rather than pulling a ready one, and I chose to test the parts I could run honestly in an afternoon. --- This is the first part. The full post — including the rest of the working details — is on my site: Postgres and Iceberg: pg_lake, pg_duckdb and the Postgres lakehouse

Snowflake でマルチエージェントを組み立てる：8 つの構成パターンと設計の工夫 ! 著者は Snowflake に所属していますが、本記事は個人の見解であり、所属する組織の公式見解ではありません。 こんにちは。Snowflake で Senior AI/ML Architect, Applied Engineering/Field CTO を務めている澁井（しぶい）です。今回は、Cortex Agents をはじめとする Snowflake の機能を組み合わせて、マルチエージェントシステムを構成する方法を紹介します。 AI エージェントに任せる業務が増えるほど、1 つのエージェントですべてを処理することは難しくなります。プロンプトが長くなり、利用するツールも増え、どの判断が誤っていたのかを追跡しにくくなるためです。この問題に対する選択肢の 1 つが、役割ごとにエージェントを分け、互いに連携させるマルチエージェント構成です。 ただし、エージェントを分ければあらゆる問題が解決するわけではありません。 ルーターが担当を選ぶのか、調整役が複数のエージェントを順に呼ぶのか、それとも並列に動かすのか。誰が実行順を決め、誰が最終結果に責任を持ち、どこに実行記録を残すのか。適切なアーキテクチャは、解きたい課題や運用上の要件によって変わります。 この記事では、Snowflake 上でマルチエージェントシステムを組み立てるための機能と、それらを組み合わせた 8 種類のサンプル構成を紹介します。各サンプルは、構築・実行・削除用のスクリプトとともに Snowflake-Labs の公開リポジトリへまとめています。 公開先： Snowflake マルチエージェント構成パターン集 ! 本記事の内容は 2026 年 10 月時点の Snowflake の機能・仕様に基づいています。Cortex Agents、MCP サーバー、エージェントスキルは今後の機能追加や仕様変更で挙動が変わる可能性があります。最新情報は公式ドキュメントを確認してください。 記事中に登場するプロジェクト、タスク、会議メモ、人名は、すべてサンプル用の架空データです。 1. 題材：タスク管理システムに AI を入れる 一連のサンプルでは、架空のタスク管理システムを共通の題材にしています。プロジェクト、タスク、会議メモのテーブルを用意し、エージェントに次の処理を担当させます。 「このタスクの状況は？」「新しいタスクを登録したい」といった依頼を、適切な担当に振り分ける 会議メモを読んで、新しいタスクの作成や重複タスクのリンクといった変更を提案する 提案を検証し、人間が承認したものだけをデータに反映する 期限超過や担当者不在など、タスクの問題を複数の観点からレビューする たとえば、会議メモからタスクの変更を提案する処理には、「メモから候補を抽出する」「既存タスクとの重複を調べる」「受け入れ条件を作る」「変更案をまとめる」といった工程があります。1 つのエージェントで処理する場合、これらをすべて 1 つのプロンプトへ盛り込むことになります。マルチエージェント構成では、Intake、Dedupe、Criteria という Worker エージェントに工程を分け、それぞれの責任範囲を狭くします。 マルチエージェント構成の設計上の難しさは、役割を分けた後にあります。 各エージェントをどの順序で呼び、結果をどうまとめ、失敗や誤りをどこで受け止めるのか。この違いが、以降で紹介する構成ごとの特徴になります。 2. Snowflake でマルチエージェントを作るための部品 Snowflake に「マルチエージェント」という名前の単一機能があるわけではありません。Cortex Agents、ストアドプロシージャ、タスクグラフなどを組み合わせて構成します。今回のサンプルで使用する主な機能は次のとおりです。 部品 役割 Cortex Agents（CREATE AGENT） 1 つ 1 つのエージェント。指示、モデル、ツールを持つスキーマオブジェクト SNOWFLAKE.CORTEX.DATA_AGENT_RUN SQL やストアドプロシージャからエージェントを呼び出す関数 プロシージャツール（カスタムツール） ストアドプロシージャをエージェントのツールとして登録する仕組み。プロシージャの中で別のエージェントを呼べば「エージェントをツールとして使う」構成になる 所有者権限のストアドプロシージャ プロシージャの所有者の権限で処理を実行する。呼び出し側に直接の権限を渡さずに、決められた操作だけを許可できる Snowflake マネージド MCP サーバー（CREATE MCP SERVER） CORTEX_AGENT_RUN ツールで、エージェントから別のエージェントを MCP 経由で呼ぶ。外部の MCP クライアントとも共用できる エージェントスキル 手順や出力書式をスキルとしてまとめ、エージェントに読み込ませる仕組み タスクグラフ（EXECUTE TASK） 複数のタスクを依存関係でつなぎ、並列実行と集約を行う ストリーム + トリガータスク テーブルの変化を検知して、変化があったときだけ処理を動かす ビューと Cortex Agents のモニタリング 実行記録、提案、承認、監査ログをテーブルに置き、ビューで追跡する。エージェント側の記録はモニタリングで確認する これらを組み合わせることで、エージェントの呼び出し、実行順序の制御、結果の保存を Snowflake 上で完結するように設計できます。 Cortex Agent は Snowflake のオブジェクトとしてロールと権限で管理でき、実行記録や処理結果は SQL で追跡できます。 3. 8 つのサンプル構成 今回公開したリポジトリには、Snowflake の機能を組み合わせて実装できる 8 種類の構成を収録しています。 フォルダ 構成 一言でいうと 01_router_handoff Router / Handoff ルーターが依頼を分類し、専門エージェント 1 つ（または人間）に渡す 02_orchestrator_worker Orchestrator / Worker（コントローラ型） Python コントローラが Worker エージェントを順に呼び、結果を集約する 03_agent_as_tool Orchestrator / Worker（エージェント型） オーケストレーター「エージェント」がプロシージャツール経由で Worker を呼ぶ 04_verifier_human_in_the_loop Verifier + 人間承認 決定論チェック、Verifier エージェント、人間承認を経てから適用する 05_mcp_agent_chaining MCP 経由のエージェント呼び出し マネージド MCP サーバーの CORTEX_AGENT_RUN で別のエージェントを呼ぶ 06_skill_composition スキル / サブスキル構成 エージェントスキルから別のスキルやサブエージェントへ処理を渡す 07_parallel_fanout 並列ファンアウト／ファンイン タスクグラフで 3 つのレビュアーを同時に動かし、決定論的に集約する 08_blackboard ブラックボード／イベント駆動 エージェントは共有の掲示板だけを介して協調し、状態の変化に反応して動く それぞれの用途、仕組み、実装上の工夫、注意点を順に見ていきます。 3.1 01_router_handoff：振り分けて渡す 用途：問い合わせ窓口のように、依頼の内容に応じて担当を選ぶ場面に向いています。1 件の依頼を選ばれた 1 つの担当が最後まで処理します。 構成：ルーター役の Cortex Agent が依頼を分類します。コントローラは分類結果を検証し、状況確認、受付、変更のいずれかを担当する Cortex Agent、または人間へ依頼を引き渡します。 工夫：ルーターの出力はそのまま採用せず、JSON スキーマで定めた契約に照らして検証します。契約に合わない場合や、ルーターが分類できないと判断した場合は、人間へ引き継ぎます。無理に自動処理を続けない経路を用意することが、この構成の安全性を支えます。 注意点：専門エージェントが扱うのは自分に渡された依頼だけです。1 件の依頼を複数の担当に分けて処理する必要がある場合は、02_orchestrator_worker のような分解・集約型の構成が適しています。 3.2 02_orchestrator_worker：コードが調整役になる 用途：会議メモから変更案を作る処理など、工程と実行順序があらかじめ決まっている仕事に向いています。 構成：Python コントローラが、配線テーブルに定義された順序で Intake、Dedupe、Criteria の各 Worker を呼びます。コントローラは各結果を集約し、最終的な変更案を提案テーブルへ書き込みます。 工夫：Worker の実行順序は LLM に任せず、コードで固定します。 各 Worker には担当処理に必要な項目だけを渡し、応答は契約に照らして検証します。各工程の記録を V_RUN_TRACE に 1 行ずつ残すため、処理の流れを後から追跡できます。 注意点：処理手順を変えるには、配線テーブルの変更が必要です。実行時の柔軟さより、順序の保証と再現性を優先する構成です。手順が明確な業務では、まずこの構成を検討するとよいでしょう。 3.3 03_agent_as_tool：エージェントが調整役になる 用途：処理を複数の Worker に分けつつ、呼び出す Worker や実行順序を依頼の内容に応じて変えたい場面に向いています。 構成：Worker の Cortex Agent を呼び出すストアドプロシージャを、カスタムツールとして登録します。オーケストレーター役の Cortex Agent は、状況に応じてこれらのツールを選んで実行します。 工夫：オーケストレーターの最終応答は、コントローラが契約に照らして検証します。 注意点：ツールの選択と呼び出し順序は LLM が決めるため、プロンプトで順序を指示しても保証はされません。 工程の前後関係が結果に影響する業務では、02_orchestrator_worker のようにコードで順序を固定する構成が適しています。 3.4 04_verifier_human_in_the_loop：書き込みの前に必ず止める 用途：エージェントの提案をもとに、業務データを実際に更新する場面に向いています。書き込みや外部システムの操作を伴う場合は、検証と人間の承認を副作用の手前に置くことが重要です。 構成：提案に対して、存在しないタスク ID や不正な値を検出する決定論的チェックを行います。続いて Verifier 役の Cortex Agent がリスクを評価し、最後に人間が承認します。承認済みの提案だけを適用プロシージャが受け付け、処理結果を監査ログへ記録します。 工夫：エージェントの実行ロールには、業務テーブルへの書き込み権限を与えません。書き込みは、所有者権限で動く適用プロシージャに限定します。 承認前の提案は受け付けず、同じ提案を再度適用しても更新が重複しないように実装します。 注意点：人間の承認を挟むため、その場で処理を完了する同期的な用途には向きません。低リスクの変更まで一律に人間へ回すと承認待ちが増えるため、Verifier が自動的に PASS と判断できる範囲と、人間に委ねる範囲を業務ルールとして定める必要があります。 3.5 05_mcp_agent_chaining：MCP 経由で別のエージェントを呼ぶ 用途：別のチームが管理する Cortex Agent を再利用したい場合や、同じ Cortex Agent を Snowflake 外部の MCP クライアントからも利用したい場合に向いています。 構成：子の Cortex Agent を、Snowflake マネージド MCP サーバーの CORTEX_AGENT_RUN ツールとして公開し、親の Cortex Agent から呼び出します。サンプルには、子が別の MCP サーバーを介して孫を呼ぶ 2 ホップ構成と、ストアドプロシージャを介して呼ぶ構成も含めています。 工夫：Cortex Agent の呼び出し口を MCP サーバーに統一することで、Snowflake 内外のクライアントから同じインターフェースを利用できます。また、子の応答を要約して返すプロシージャ経由の構成も用意し、ペイロードの扱いを比較できるようにしています。 注意点：MCP のツール結果には子の応答全体が含まれるため、呼び出しを重ねるほど親が受け取るペイロードは大きくなります。 呼び出し階層はできるだけ浅く保ち、必要に応じて子の応答を要約してから返す設計が適しています。 3.6 06_skill_composition：手順を部品として再利用する 用途：レポートの書式や調査手順など、複数の Cortex Agent で再利用したい処理を部品化する場面に向いています。 構成：ステージに配置した SKILL.md をエージェントスキルとして登録し、スキルから別のスキルやサブエージェントへ処理を委譲します。サンプルでは、スキルを組み合わせる 4 通りの方法を比較できます。 工夫：別のスキルを利用する場合は、親スキルと同じ階層に登録するか、内容を 1 つのスキルへ統合します。コンテキストを分離したい処理は、プロシージャを介して別の Cortex Agent へ委譲します。 注意点：2026 年 10 月時点では、スキルのフォルダ内へ入れ子で配置したサブスキルは読み込まれません。 また、同じ階層に登録したスキルや統合スキルは親と同じコンテキストで動くため、手順を増やすほどコンテキストも大きくなります。 3.7 07_parallel_fanout：独立した観点を同時に調べる 用途：期限、担当、品質など、互いに独立した観点からプロジェクトを調査し、その結果を 1 つのレポートへまとめる場面に向いています。 構成：3 つのレビュアーをタスクグラフの兄弟タスクとして実行し、FINALIZE タスクで結果を集約します。各レビュアーの処理は独立しているため、同時に実行できます。 工夫：DATA_AGENT_RUN を SQL の各行から並列に呼び出すことはできないため、タスクグラフで並列化しています。実行ごとの設定は EXECUTE TASK ... USING CONFIG で渡し、各タスクから SYSTEM$GET_TASK_GRAPH_CONFIG で参照します。タスク間では、RUN_ID をキーにしたテーブルを介して結果を受け渡します。集約は LLM ではなく決定論的な処理で行います。いずれかのレビュアーが失敗しても FINALIZE タスクは実行され、取得できた結果から PARTIAL レポートを作成します。 注意点：前のレビュー結果を次のレビューが必要とするなど、入出力どうしに依存関係がある処理は並列化に向きません。また、実行ロールにはタスクを直接操作する権限を与えず、入力を検証する所有者権限の入口プロシージャだけを公開します。 3.8 08_blackboard：掲示板を介して疎結合に協調する 用途：時間のかかる非同期処理を、処理の担当者を後から追加・変更しながら運用したい場面に向いています。 構成：Cortex Agent 同士は直接やり取りせず、共有の掲示板（ブラックボード）テーブルを介して協調します。会議メモ（NOTE）が投稿されると、それを購読する Worker が処理結果を掲示板へ書き込みます。別の Worker がその結果に反応し、最終的に提案（PROPOSALS）が作成されます。 工夫：項目の読み取りは掲示板の種類ごとに絞ったビューへストリームを作り、そのストリームを条件とするトリガータスクで実現します。タスクは新しい項目が届いたときだけ動くため、待機中のウェアハウス費用は発生しない設計です。各 Worker は、処理済みの項目を受信箱（inbox）テーブルへ記録し、同じ項目を重複して処理しないようにしています。 Worker には 02_orchestrator_worker の Cortex Agent を再利用しています。 注意点：トリガータスクには最小実行間隔があり、既定値は 30 秒（USER_TASK_MINIMUM_TRIGGER_INTERVAL_IN_SECONDS）です。この待ち時間が処理の段階ごとに加わるため、対話的な応答には向きません。また、トリガータスクから呼ぶ処理が例外を返すと、同じデータに対して再実行が続きます。そのため、例外を外へ出さずに記録し、試行回数に上限を設けています。 3.9 どの構成を選ぶか ここまでの特徴を、選択の目安として整理すると次のようになります。 構成を選ぶ際は、最初に「実行順序を LLM に決めさせる必要があるか」を考えると整理しやすくなります。 手順が決まっているなら、コードやタスクグラフで順序を定義したほうが、結果を再現しやすく、誤りの原因も追跡しやすくなります。 4. 設計上の工夫 構成パターンを選ぶだけでは、安全な業務システムにはなりません。ここでは、サンプルに取り入れた工夫と、その理由を説明します。 4.1 エージェントの出力は契約で検証する なぜ必要か：LLM の出力形式は一定ではありません。キーの欠落、想定外の値、JSON の前後に付く説明文などが後段の処理を壊す可能性があります。エラーが発生する箇所も散在するため、原因の特定も難しくなります。 どうしたか：分類、抽出候補、変更案、検証結果ごとに JSON スキーマを用意しました。コントローラは応答を検証してから次へ渡します。不正な応答は記録するか、人間へ引き継ぎます。エージェントの境界で止めるため、原因を特定しやすくなります。 4.2 入力データは「信頼できないデータ」として渡す なぜ必要か：エージェントは、業務データ内の文章を指示と誤認することがあります。たとえば会議メモに「以前の指示を無視せよ」と書かれていれば、従うおそれがあります。これはプロンプトインジェクションの一例となります。自由記述のデータを安全とみなすことは避けたほうが良いでしょう。 どうしたか：業務データを指示から分離し、「信頼できないデータ」として渡します。Cortex Agent には、その中の指示に従わないよう伝えます。変更案の引用文が元の会議メモにあるかも、コードで照合します。 ただし、この対策だけでプロンプトインジェクションを完全には防げません。 そこで、権限設計と人間の承認も組み合わせ、誤判断による書き込みを防ぎます。 4.3 権限は最小限にし、書き込みの入口を 1 つにする なぜ必要か：エージェントの誤りは完全にはなくせません。実行ロールが業務テーブルを自由に更新できると、1 回の誤判断がデータを壊します。誤りを前提に、権限で影響範囲を限定する必要があります。 どうしたか：実行ロール（MULTI_AGENT_PATTERNS_ROLE）には、変更案を記録する最小限の権限だけを与えます。業務テーブルを更新できるのは、所有者権限で動く適用プロシージャだけです。 承認済みの変更案だけを受け付け、検証と監査記録もこの入口に集約します。 4.4 集約は決定論的に、処理は冪等に なぜ必要か：LLM に集約を任せると、同じ入力でも結果が変わります。指摘が集約時に消えたのか、元からなかったのかも判別できません。また、タスクやストリームは同じ処理を再実行することがあります。変更案が重複すると、承認作業とデータの整合性に影響します。 どうしたか：並列ファンアウトの集約と、ブラックボードの変更案作成には LLM を使いません。 統合と重複除去はコードで行い、結果を再現可能にします。各 Worker は処理済みの項目を受信箱（inbox）へ記録し、二重処理を防ぎます。 4.5 実行記録をテーブルに残す なぜ必要か：最終結果だけでは、各エージェントへの入力や誤判断の箇所がわかりません。障害調査や判断の説明には、途中経過の追跡が必要です。 どうしたか：実行記録を V_RUN_TRACE、V_REVIEW_WORKERS、V_BOARD_TIMELINE などのビューにします。入力、所要時間、応答を SQL で追跡でき、Task History とも照合できます。普段のデータ分析と同じ方法で調査できるようにします。 5. なぜ Snowflake で作るのか マルチエージェントシステムを構築できるフレームワークは、Snowflake 以外にもあります。その中で Snowflake を使う主な利点は、データ、権限、オーケストレーション、実行記録を同じ基盤上で扱えることです。 第一に、データの近くで Cortex Agent を動かせます。ツールとしてテーブル、ビュー、ストアドプロシージャを利用できるため、業務データを別の処理基盤へ移すことなく扱えます。 第二に、Snowflake のガバナンスをそのまま適用できます。Cortex Agent もストアドプロシージャもスキーマオブジェクトなので、誰がどの Cortex Agent を実行でき、どのデータへアクセスできるかをロールで管理できます。書き込みの入口を所有者権限のプロシージャに限定する設計も、通常の権限モデルで実現できます。 第三に、処理を連携させる機能がそろっています。タスクグラフで並列実行と集約を行い、ストリームとトリガータスクでデータの変化に反応できます。MCP サーバーを介せば、外部の MCP クライアントとも接続できます。実行記録をテーブルへ残せるため、運用状況の確認や評価も SQL で行えます。 6. 今後 今回のサンプルは、2026 年 10 月時点の Snowflake の機能で実装できる構成に絞っています。今後の機能拡張や発展次第では、次のような拡張を検討できるでしょう。 07_parallel_fanout のタスクグラフに条件付きタスクを加え、条件によって処理を分岐させる、状態機械のような構成に広げる 実行記録を使って、エージェントの応答を継続的に評価する仕組みを加える 調整役を何段にも重ねる階層型の構成や、エージェント同士が直接やり取りする構成を、機能の拡充に合わせて検討する Cortex AgentおよびSnowflakeのAI機能の成長が楽しみです。 7. サンプルを試す 各構成のソースコード、構築スクリプト、詳しい解説は、次のリポジトリで公開しています。 リポジトリ： Snowflake-Labs/sf-samples-jp / multi-agent-patterns 日本語 README：構成の比較、前提条件、構築と後片付けの手順、作成されるオブジェクト 英語 README：日本語 README と同じ内容の英語版 各構成の README：スクリプトの処理内容、SQL の抜粋、設計のポイント、応用方法 実行には、ACCOUNTADMIN ロールを使える Snowflake アカウント、Cortex Agents が使えるリージョン（またはクロスリージョン推論）、Snowflake CLI が必要です。ウェアハウスは XSMALL で、60 秒で自動停止します。試し終わったら scripts/teardown_all.sh --confirm ですべて削除できます。 マルチエージェントシステムは、エージェントを増やすだけで良くなるものではありません。 実行順序を誰が決めるのか、最終結果に誰が責任を持つのか、誤りや不確実性をどこで止めるのかを、構成の中に明示する必要があります。本記事とサンプルが、Snowflake 上でマルチエージェントシステムを設計する際の参考になれば幸いです。 参考資料 Cortex Agents CREATE AGENT DATA_AGENT_RUN (SNOWFLAKE.CORTEX) Cortex Agents のアクセス制御 Snowflake マネージド MCP サーバー CREATE MCP SERVER Agent skills Cortex Agents のモニタリング Snowflake Task グラフ トリガータスク

My favorite ways to learn Snowflake hands-on (mostly free): a starter guide I've been working with Snowflake since late 2025, run our data platform at an insurtech, and help out in the Snowflake community. People often ask "where do I start?", so here's my personal shortlist, in the order I'd suggest going through it. All of it is hands-on or at least very practical. 1. Hands-On Essentials workshops (free, self-paced) Start here if you're new to Snowflake or to data work in general. These are online, self-paced workshops with short animated scenarios, real labs in a trial account, and knowledge checks. Your lab work is auto-graded, so you get immediate feedback on whether you actually did it right. No prerequisites, and it costs nothing apart from a free trial account. Overview: snowflake.com 2. Snowflake University / Learn (learn.snowflake.com) This is the official catalog. It has learning tracks (including SnowPro Core prep), self-paced courses and instructor-led training (ILT). - Free on-demand: the "Level Up" series (concepts, architecture, data loading, resource monitoring, Snowpark, Native Apps), FinOps for Snowflake, Cost Governance, Gen AI courses, SnowConvert, and Spark → Snowpark migration. - Paid: Snowflake Foundations on-demand, the SnowPro Core Certification Prep Course, and most ILT courses (Fundamentals 4-day, Administering Snowflake, Data Engineer, Architect, Data Analyst, Snowpark, Native Apps, Performance Tuning and more). My tip: do the free stuff first, then decide if a paid course is worth it for your role. Catalog: learn.snowflake.com New: some courses are now offered in German too (e.g. learn.snowflake.com). Tech people work in English anyway, but I expect this to matter once business users and non-engineers start working with Snowflake's AI features. 3. "Snowflake on Snowflake" webinars Recorded sessions where Snowflake's own teams (IT, Finance, Sales, Marketing, Security, Product) show how they use Snowflake internally. It's less "how do I write a COPY INTO" and more "what does this look like in a real company". Examples: - Saving ~$5M in SaaS spend with AI on Snowflake - Lead scoring with Snowpark, Cortex and the Model Registry - Cloud finance management and cost attribution - Automating SOX / internal controls - Using Snowflake as a security data lake - Account 360 / data enrichment in Salesforce You can filter by department, product area and region. Great for getting ideas for your own use cases: snowflake.com 4. DataCamp's Snowflake courses If you prefer interactive in-browser exercises, DataCamp has a solid Snowflake catalog (built together with Snowflake): - Beginner: Introduction to Snowflake (2h), Snowflake Architecture (3h), Data Manipulation in Snowflake, Data Pipeline Automation (COPY INTO, Snowpipe, streams, tasks), Management, Governance & Collaboration - Intermediate: Snowflake SQL, Data Modeling, Window Functions, Modern Data Engineering, Apache Iceberg, Generative AI in Snowflake, Building AI Agents - Tracks: Snowflake Foundations (~7h), SnowPro Core exam prep (~9h), Associate Data Engineer (~32h), Snowflake AI Fundamentals (~6h) - Newer content also covers Cortex Code (CoCo) You do need basic SQL (sorting, grouping, aggregation, joins) before you start. Their Snowflake hub: datacamp.com 5. Build a Snowflake Docs agent in your own account (about 5 minutes) My favorite "learn by doing" exercise: build an agent that answers questions about Snowflake from the official documentation, with citations. You only need three building blocks: - Snowflake Documentation CKE: a free Cortex Knowledge Extension, i.e. a shared Cortex Search Service, that you install from the Snowflake Marketplace. - Cortex Agents: configured in Snowsight under AI & ML » Agents. - Snowflake Intelligence / Snowflake CoWork: the chat UI where you talk to your agent. Steps: 1. Install the listing. Get "Snowflake Documentation" from the Marketplace and grant imported privileges on the database to the roles that should use it. 2. Create the agent. Create an agent (e.g. snowflake_docs) in any database and schema. Add a Cortex Search tool that points at CKE_SNOWFLAKE_DOCS_SERVICE, set the ID column to SOURCE_URL for clickable citations and the Title column to DOCUMENT_TITLE. Add short column descriptions to improve retrieval. 3. Write the instructions. In the orchestration instructions, tell the agent to answer only when it can cite a reference. 4. Make it visible. If your account uses a Snowflake Intelligence object (check with SHOW SNOWFLAKE INTELLIGENCES;), add the agent with ALTER SNOWFLAKE INTELLIGENCE SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT ADD AGENT <db.schema.agent>;. If not, users automatically see all agents they have access to. 5. Try it. Open Snowflake Intelligence, pick your agent and ask: "How do I create an agent?" In one exercise you touch Marketplace, Cortex Search, Agents and RBAC, and you end up with a docs assistant for everything else you learn. Fun fact: I couldn't find a proper Snowflake doc page for this exact setup, so I asked my own Docs agent. It happily double-checked its own build instructions, so yes, the agent verified the guide for its own creation. Peak recursion. Note: Older guides say agents must live in snowflake_intelligence.agents. Snowflake has deprecated that schema for controlling which agents users see, so use the Snowflake Intelligence object instead. Sources: - Original walkthrough by Chris Cardillo: medium.com - Cortex Knowledge Extensions: docs.snowflake.com - Configure agents and add a Cortex Search tool: docs.snowflake.com - Deploy agents and control visibility in Snowflake Intelligence: docs.snowflake.com 6. Snowflake Guides / Quickstarts (hands-on tutorials) Quickstarts are interactive, step-by-step tutorials and self-serve demos that you follow in your own account. They've since been merged with the old "Solutions Center" into what Snowflake now calls Snowflake Guides, published at snowflake.com. A typical guide walks you through Overview, Prerequisites, What You Will Build, What You Will Learn, What You Learned, Conclusion and Resources, so you know upfront what you need and what you'll end up with. Things I like about them: - Open source: every guide is a markdown file in the public GitHub repo Snowflake-Labs/sfquickstarts (Apache-2.0 license, under site/sfguides/src/), so you can read the source, follow along, or browse the whole collection at once. - Fix it yourself: found a typo or an outdated step? You can open a pull request. Guides are not covered by Snowflake Support, so PRs are the way to report errors. - Contribute your own: fork the repo, copy the markdown template, add your guide and open a PR. Automated checks validate the id, categories and language tag, and the DevRel team reviews it. This is a nice entry point into the community if you've built something worth sharing. - Low friction for learners: guides can be used anonymously and your progress is saved automatically. If you're into ML, the Snowflake docs also have a curated "Getting Started" page for Snowflake ML, with 15 guides sorted into end-to-end examples, model development and MLOps (nine of them are Beginner level), for example Build an End-to-End ML Model in Snowflake, Getting Started with Snowflake Notebooks on Container Runtime or Introduction to Snowflake Feature Store: docs.snowflake.com How I'd combine it 1. Start with the Hands-On Essentials workshops (Data Warehousing first) to get the basics. 2. Build the Docs agent and use it as your study buddy. 3. Follow a few Quickstarts / Guides for the topic you care about most (Snowpark, Notebooks, ML, Cortex...). They're the fastest way to build something real. 4. Watch a few "Snowflake on Snowflake" sessions for real-world context. 5. Use DataCamp or the Level Up courses to go deeper where you need it (SQL, pipelines, Snowpark, AI). 6. If you want a certification, look at the SnowPro Core prep material. Also: Snowflake Expedition (free virtual event) runs November 3–6, with technical tracks if you want live content. What did I miss? Which resources helped you most? Happy to hear your favorites, especially for Cortex / AI topics. P.S. If you want to work towards badges in a structured way, these two landing pages are a good starting point: - achieve.snowflake.com - developerbadges.snowflake.com

CoCoにSnowProの資格勉強向けのSkillあったんだw snowpro-study A comprehensive skill for generating study materials for SnowPro certifications. github.com/Snowflake-Labs/coco-skills/blob/main/s… #SnowflakeDB

Snowflake の公式ガイドをベースに Snowflake Cortex Agents を日本語で試す手順の紹介 1. 概要 Snowflake の公式ガイド Build a Cortex Agents from Scratch with Snowflake と付属の Notebook をベースに、売上データを分析する Cortex Analyst と、製品ドキュメントを検索する Cortex Search を組み合わせる方法を紹介します。 公式ガイドは英語で書かれていますが、コンテンツの一部を日本語に修正して、日本語での動作を確認します。 Snowflake Cortex Agents の構成 flowchart TD Q[日本語の質問] --> A[Cortex Agent] A --> AN[Cortex Analyst] A --> SE[Cortex Search] AN --> SV[日本語セマンティックビュー] SV --> SA[SALES テーブル] SE --> CS[Search Service] CS --> PD[PRODUCT_DOCS テーブル] 2. 前提条件とライセンス 2.1. 検証環境 Snowflake の Azure 東日本リージョン（AZURE_JAPANEAST）を利用しています。Cortex AI のクロスリージョン推論設定（CORTEX_ENABLED_CROSS_REGION）は ANY_REGION に設定しており、クラウドプロバイダーを問わず、Snowflake がサポートするリージョンで推論リクエストを処理できる構成です。 |REGION|SNOWFLAKE_VERSION| |---|---| |AZURE_JAPANEAST|10.38.100| |key|value|default|level|description|type| |---|---|---|---|---|---| |CORTEX_ENABLED_CROSS_REGION|ANY_REGION|DISABLED|ACCOUNT|Comma separated list of allowed cortex cross regions. Order does not matter.|STRING| !image.png 2.2. 本記事のコードのライセンスと改変内容 本記事の第 3 章に掲載する SQL は、Snowflake-Labs の snowflake-demo-notebooks 内の Notebook を改変したものです。元リポジトリのコードは Apache License 2.0 で提供されています。第 3 章で提示するコードは、元の Notebook から一部を改変しています。本記事の解説文は独自に作成しており、公式ガイドの文章を翻訳・転載したものではありません。 参照した Notebook のコミットは 7ad9d60019c754d7c30a07cf55fcfd71e2623751 です。 - 参照元 Notebook（コミット固定） - 元リポジトリの LICENSE 3. 公式ガイド・Notebook に沿った Cortex Agent の構築 3.1. Notebook のインポートと環境構築 公式 Notebook をダウンロードします。右側にある Download raw file を選択すると、ファイルをダウンロードできます。 - github.com/Snowflake-Labs/snowflake-demo-notebook… !image.png 出所: snowflake-demo-notebooks/Build-a-Cortex-Agent-from-Scratch-with-Snowflake/build-a-cortex-agent-from-scratch-with-snowflake.ipynb at main · Snowflake-Labs/snowflake-demo-notebooks · GitHub Snowsight の Workspace で + Add new -> Upload files を選択し、ダウンロードしたファイルをアップロードします。 !image.png Notebook が表示されることを確認します。 !image.png セル 4 を実行して、データベースなどを作成します。 !image.png セル 6 を下記のように書き換えて、claude-sonnet-5-5 を利用できることを確認します。 -- SELECT SNOWFLAKE.CORTEX.COMPLETE('claude-3-5-sonnet', 'Say hello in one word') AS cortex_test; SELECT SNOWFLAKE.CORTEX.COMPLETE('claude-sonnet-5-5', 'Say hello in one word') AS cortex_test; !image.png 3.2. サンプルデータの作成 公式 Notebook のセルを実行して、テーブルの作成とデータの挿入を実施します。 Sales !image.png Inventory !image.png Product Documentation セル 17 を下記のように書き換えて、content を日本語にします。 INSERT INTO product_docs (product_name, doc_type, content, last_updated) VALUES ('Laptop Pro', 'specifications', 'Laptop Proは、15.6インチの4Kディスプレイ、Intel i9プロセッサ、32GBのRAM、1TBのSSDを搭載しています。バッテリー駆動時間は最大12時間です。Thunderbolt 4ポートとWi-Fi 6Eに対応しています。重量は4.2ポンドです。標準保証期間は3年間で、最大5年間まで延長できます。', '2024-01-01'), ('Laptop Pro', 'troubleshooting', 'よくある問題と対処方法：1) バッテリーの消耗が早い場合は、バックグラウンドで動作しているアプリを確認し、画面の明るさを下げてください。2) 本体が過熱する場合は、通気口がふさがれていないことを確認し、硬く平らな場所で使用してください。3) 動作が遅い場合は、ソフトウェアの更新を確認し、ディスククリーンアップを実行してください。4) Wi-Fiに問題がある場合は、ネットワークドライバーを更新し、ネットワーク設定をリセットしてください。', '2024-01-15'), ('Standing Desk', 'specifications', '高さを記憶できるメモリー機能付きの電動昇降デスクです。高さの調整範囲は28～48インチです。天板のサイズは60×30インチです。最大耐荷重は300ポンドです。安定性を高めるためにデュアルモーターシステムを採用しています。ケーブル管理用トレーと衝突防止センサーを搭載しています。', '2024-01-01'), ('Standing Desk', 'assembly', '組み立て手順：1) 付属のボルトを使用して脚部をフレームに取り付けます。2) モーターのケーブルをコントロールボックスに接続します。3) 天板をフレームに固定します。4) 電源コードを接続します。5) 操作パネルを使用して高さのプリセットを登録します。組み立て時間の目安は約45分です。必要な工具はプラスドライバーです。', '2024-01-10'), ('Office Chair', 'specifications', 'ランバーサポートを備えた人間工学に基づくオフィスチェアです。アームレスト、座面の高さ、リクライニングの反発力を調整できます。背もたれには通気性の高いメッシュ素材を採用しています。座面のサイズは20×19インチです。最大耐荷重は275ポンドです。保証期間はフレームが5年間、張地が2年間です。', '2024-01-01'), ('Office Chair', 'care', 'お手入れ方法：メッシュ部分は中性洗剤と水を使用して清掃してください。キャスターには年に1回潤滑剤を塗布してください。6か月ごとにボルトを点検し、必要に応じて締め直してください。最大耐荷重を超えないようにしてください。湿気の少ない乾燥した環境で保管してください。座面が自然に下がる場合は、ガスシリンダーを交換してください。', '2024-02-01'); !image.png 件数チェック |TABLE_NAME|ROW_COUNT| |---|---| |sales|12| |inventory|6| |product_docs|6| !image.png 3.3. 日本語セマンティックビューの作成 物理テーブル名と列名は元の英語のまま使用し、業務上の論理名を日本語で定義します。 -- Modified 2026-10-19: Japanese logical names and CREATE OR ALTER. CREATE OR ALTER SEMANTIC VIEW CORTEX_AGENTS_LAB.TUTORIAL.SALES_SEMANTIC_VIEW TABLES ( sales AS CORTEX_AGENTS_LAB.TUTORIAL.SALES PRIMARY KEY (sale_id) COMMENT = '小売業の売上明細。1行は1件の販売取引を表す。金額の単位は米ドル。' ) DIMENSIONS ( sales."商品名" AS product_name WITH SYNONYMS = ('製品名', 'product name') COMMENT = '販売した商品の名称。例：Laptop Pro、Standing Desk。', sales."商品カテゴリ" AS category WITH SYNONYMS = ('カテゴリ', '製品カテゴリ') COMMENT = '商品の分類。Electronics は電子機器、Furniture は家具。', sales."地域" AS region WITH SYNONYMS = ('販売地域', '売上地域') COMMENT = '販売地域。North America は北米、Europe は欧州、Asia Pacific はアジア太平洋。', sales."顧客区分" AS customer_segment WITH SYNONYMS = ('顧客セグメント', '顧客種別') COMMENT = 'Enterprise は大企業、SMB は中小企業、Consumer は個人。' ) METRICS ( sales."売上高" AS SUM(total_amount) WITH SYNONYMS = ('売上金額', '売上', 'revenue') COMMENT = '売上金額の合計。単位は米ドル（USD）。', sales."販売数量" AS SUM(quantity) WITH SYNONYMS = ('販売個数', '販売数') COMMENT = '販売した商品の数量の合計。', sales."取引件数" AS COUNT(*) WITH SYNONYMS = ('販売取引数', '明細件数') COMMENT = '売上明細の行数。顧客数や販売数量ではない。' ) COMMENT = '商品、地域、顧客区分ごとに売上高と販売数量を分析する日本語セマンティックビュー。'; !image.png Agent を介さず、セマンティックビューを直接問い合わせます。 !image.png :::note info 従来の SEMANTIC_VIEW() 構文に加えて、セマンティックビューを FROM 句で直接参照し、SELECT、GROUP BY、AGG() などを使ってクエリできるようになりました。 SELECT AGG(total_sales) AS total_sales, AGG(total_quantity) AS total_quantity, region FROM CORTEX_AGENTS_LAB.TUTORIAL.SALES_SEMANTIC_VIEW GROUP BY region ORDER BY total_sales DESC; SELECT AGG(total_sales) AS total_sales, AGG(transaction_count) AS transaction_count, region, category FROM CORTEX_AGENTS_LAB.TUTORIAL.SALES_SEMANTIC_VIEW GROUP BY region, category ORDER BY total_sales DESC; !image.png ::: 3.4. Cortex Search Service の構築 PRODUCT_DOCS.CONTENT を検索対象にします。PRODUCT_NAME と DOC_TYPE は属性として登録し、製品や文書種別で絞り込めるようにします。 !image.png サービスが作成されたら、Agent とは独立して検索します。 SELECT r.value:product_name::STRING AS product_name, r.value:doc_type::STRING AS doc_type, SUBSTRING(r.value:content::STRING, 1, 100) AS content_preview FROM TABLE(FLATTEN( PARSE_JSON( SNOWFLAKE.CORTEX.SEARCH_PREVIEW( 'CORTEX_AGENTS_LAB.TUTORIAL.PRODUCT_SEARCH_SERVICE', '{"query": "ノートパソコンの過熱を解消する方法", "columns": ["content", "product_name", "doc_type"], "limit": 3}' ) )['results'] )) r; |PRODUCT_NAME|DOC_TYPE|CONTENT_PREVIEW| |---|---|---| |Laptop Pro|troubleshooting|よくある問題と対処方法：1) バッテリーの消耗が早い場合は、バックグラウンドで動作しているアプリを確認し、画面の明るさを下げてください。2) 本体が過熱する場合は、通気口がふさがれていないことを確認し| |Office Chair|care|お手入れ方法：メッシュ部分は中性洗剤と水を使用して清掃してください。キャスターには年に1回潤滑剤を塗布してください。6か月ごとにボルトを点検し、必要に応じて締め直してください。最大耐荷重を超えないよう| |Standing Desk|specifications|高さを記憶できるメモリー機能付きの電動昇降デスクです。高さの調整範囲は28～48インチです。天板のサイズは60×30インチです。最大耐荷重は300ポンドです。安定性を高めるためにデュアルモーターシステ| !image.png -- RAG：Cortex Searchから関連情報を取得し、LLMで回答を生成する WITH search_results AS ( SELECT r.value:content::STRING AS content FROM TABLE(FLATTEN( PARSE_JSON( SNOWFLAKE.CORTEX.SEARCH_PREVIEW( 'CORTEX_AGENTS_LAB.TUTORIAL.PRODUCT_SEARCH_SERVICE', '{"query": "ノートパソコンの過熱を解消する方法", "columns": ["content"], "limit": 3}' ) )['results'] )) r ), context AS ( SELECT LISTAGG(content, '\n\n') AS combined_context FROM search_results ) SELECT SNOWFLAKE.CORTEX.COMPLETE( 'claude-sonnet-5-5', CONCAT( 'あなたは製品サポートを担当するアシスタントです。以下に提供されたコンテキストの情報のみを使用して質問に回答してください。', 'コンテキストに回答に必要な情報が十分に含まれていない場合は、その旨を明確に伝えてください。\n\n', 'コンテキスト：\n', combined_context, '\n\n', '質問：ノートパソコンの過熱を解消するにはどうすればよいですか？\n\n', '回答：' ) ) AS rag_answer FROM context; コンテキストには、本体が過熱する場合の対処方法として次の2点が記載されています。 1. **通気口がふさがれていないか確認する** 2. **硬く平らな場所で使用する** ただし、この記載は「本体」についての一般的な内容で、ノートパソコン専用の手順とは明記されていません。ファンの清掃や冷却パッドの使用など、これ以外の具体的な対処法はコンテキストに含まれていません。上記を試しても改善しない場合は、メーカーのサポート窓口にお問い合わせください。 なお、コンテキストの製品説明は電動昇降デスクに関するものです。お使いのノートパソコンに関する情報は含まれていません。 !image.png 3.5. Cortex Agent の作成 初回は、売上の質問を Analyst、製品文書の質問を Search に振り分ける構成を作成します。単一の質問で両方を使う指示は第 5 章で追加します。 CREATE OR REPLACE AGENT CORTEX_AGENTS_LAB.TUTORIAL.TUTORIAL_AGENT COMMENT = '売上分析と製品ドキュメント検索の検証用 Agent' PROFILE = '{"display_name":"小売業データ分析エージェント"}' FROM SPECIFICATION $$ models: orchestration: claude-sonnet-5-5 orchestration: tool_not_accessible: reject budget: seconds: 90 tokens: 16000 instructions: orchestration: >- あなたは小売業の売上データと製品ドキュメントを調べるアシスタントである。 売上高、販売数量、取引件数の質問には Analyst を使用する。 製品仕様、組み立て方法、トラブルへの対処方法の質問には Search を使用する。 製品の名称は元の英語名を維持する。 response: >- 日本語で簡潔に回答する。数値は Analyst の実行結果、製品情報は Search の 検索結果を根拠とする。売上金額の単位は USD とする。 文書から得た情報には利用可能な引用を付ける。 根拠のない情報を補わず、確認できない場合はその旨を明記する。 tools: - tool_spec: type: cortex_analyst_text_to_sql name: Analyst description: 売上高、販売数量、取引件数を商品、地域、顧客区分別に分析する - tool_spec: type: cortex_search name: Search description: 製品仕様、組み立て方法、トラブルへの対処方法を製品文書から検索する tool_resources: Analyst: semantic_view: CORTEX_AGENTS_LAB.TUTORIAL.SALES_SEMANTIC_VIEW execution_environment: type: warehouse warehouse: COMPUTE_WH Search: search_service: CORTEX_AGENTS_LAB.TUTORIAL.PRODUCT_SEARCH_SERVICE max_results: 3 $$; 3.6. Notebook からの動作確認 Python から Agent に質問し、回答を取得します。 まず、構造化データに関する質問の結果です。 import json from snowflake.snowpark.context import get_active_session session = get_active_session() # 構造化データに関する質問をエージェントに送信する result = session.sql(""" SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN( 'CORTEX_AGENTS_LAB.TUTORIAL.TUTORIAL_AGENT', $${"messages": [{"role": "user", "content": [{"type": "text", "text": "地域別の売上金額の合計を教えてください。"}]}]}$$ ) AS resp """).collect() resp = json.loads(result[0]["RESP"]) # レスポンスの各コンテンツを解析して表示する for item in resp.get("content", []): item_type = item.get("type") if item_type == "thinking": print("=== 思考プロセス ===") print(item["thinking"]["text"]) print() elif item_type == "tool_use": print(f"=== ツール呼び出し: {item['tool_use'].get('name', '')} ({item['tool_use'].get('type', '')}) ===") print() elif item_type == "tool_result": tr = item["tool_result"] print(f"=== ツール実行結果: {tr.get('name', '')} ===") content_json = tr.get("content", [{}])[0].get("json", {}) if content_json.get("sql"): print(f"生成されたSQL:\n{content_json['sql']}\n") if content_json.get("sql_explanation"): print(f"SQLの説明: {content_json['sql_explanation']}\n") if content_json.get("result_set", {}).get("data"): meta = content_json["result_set"].get("resultSetMetaData", {}) cols = [col["name"] for col in meta.get("rowType", [])] data = content_json["result_set"]["data"] if cols: print(" | ".join(cols)) print("-" * (len(" | ".join(cols)))) for row in data: print(" | ".join(str(v) for v in row)) print() elif item_type == "text": print("=== 最終回答 ===") print(item["text"]) print() === ツール呼び出し: Analyst (system_agentic_semantic_context) === === ツール実行結果: Analyst === === ツール呼び出し: system_execute_sql (system_execute_sql) === === ツール実行結果: system_execute_sql === 生成されたSQL: WITH __sales AS ( SELECT region, total_amount FROM CORTEX_AGENTS_LAB.TUTORIAL.SALES ) SELECT region, SUM(total_sales) AS total_sales FROM __sales GROUP BY region ORDER BY total_sales DESC NULLS LAST /* Generated by Cortex */; === 最終回答 === Metric は集計式で書く必要がある。 === ツール呼び出し: system_execute_sql (system_execute_sql) === === ツール実行結果: system_execute_sql === 生成されたSQL: WITH __sales AS ( SELECT region, total_amount FROM CORTEX_AGENTS_LAB.TUTORIAL.SALES ) SELECT region, SUM(total_amount) AS total_sales FROM __sales GROUP BY region ORDER BY total_sales DESC NULLS LAST /* Generated by Cortex */; REGION | TOTAL_SALES -------------------- North America | 69497.00 Europe | 51498.60 Asia Pacific | 39999.60 === ツール呼び出し: server_skill (server_skill) === === ツール実行結果: server_skill === === ツール呼び出し: data_to_chart (data_to_chart) === === ツール実行結果: data_to_chart === === 最終回答 === 地域別の売上金額の合計は次のとおりです（単位: USD）。North America が最も高くなりました。 !image.png 続いて、製品ドキュメントに関する質問の結果です。 # 製品ドキュメントに関する質問をエージェントに送信する result = session.sql(""" SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN( 'CORTEX_AGENTS_LAB.TUTORIAL.TUTORIAL_AGENT', $${"messages": [{"role": "user", "content": [{"type": "text", "text": "ノートパソコンの過熱を解消するにはどうすればよいですか？"}]}]}$$ ) AS resp """).collect() resp = json.loads(result[0]["RESP"]) for item in resp.get("content", []): item_type = item.get("type") if item_type == "thinking": print("=== 思考プロセス ===") print(item["thinking"]["text"]) print() elif item_type == "tool_use": print(f"=== ツール呼び出し: {item['tool_use'].get('name', '')} ({item['tool_use'].get('type', '')}) ===") print() elif item_type == "tool_result": tr = item["tool_result"] print(f"=== ツール実行結果: {tr.get('name', '')} (ステータス: {tr.get('status', '')}) ===") print() elif item_type == "text": print("=== 最終回答 ===") print(item["text"]) print() === ツール呼び出し: Search (cortex_search) === === ツール実行結果: Search (ステータス: success) === === 最終回答 === 製品文書によると、本体が過熱する場合は次の2点を確認してください。 - 通気口がふさがれていないことを確認する。 - 硬く平らな場所で使用する。 文書にはこれ以外の対処方法（清掃やサポートへの連絡など）の記載は確認できませんでした。上記を試しても改善しない場合は、メーカーのサポートに問い合わせてください。 !image.png 3.7. （オプション）リソースの削除 公式ガイドには、本手順で作成したリソースを削除する手順が掲載されています。ただし、データベースは削除対象に含まれていないため、別途削除する必要があります。本記事では追加検証を実施するため、リソースを削除しています。 !image.png 4. 追加検証: Snowflake CoWork の利用 4.1. Snowflake CoWork に移動 AI & ML -> Snowflake CoWork を選択します。 !image.png Snowflake CoWork（https://ai.snowflake.com/）に移動することを確認します。 !image.png 4.2. Snowflake CoWork で質問 Snowflake CoWork に移動したら、小売業データ分析エージェント を選択し、地域別の売上高、販売数量、取引件数を売上高の降順で教えてください。 と入力して質問します。 !image.png 回答が表示されることを確認します。 !image.png 4.3. Artifacts 機能の確認 回答の表にある Save を選択します。 !image.png Artifacts を選択します。 !image.png 保存した表が表示されることを確認します。 !image.png グラフも保存できます。 !image.png !image.png 5. 追加検証: Agent Studio の利用 5.1. Agent Studio の表示 Snowsight で AI & ML -> Agents Studio を選択します。 !image.png All agents の 小売業データ分析エージェント（TUTORIAL_AGENT）を選択します。 !image.png 作成した Agent が表示されることを確認します。 !image.png !image.png !image.png !image.png !image.png !image.png 5.2. Preview で動作確認 Preview を選択します。 !image.png Laptop Pro が過熱する場合の対処方法を、製品文書を根拠に教えてください。 と入力して質問します。 !image.png 回答が表示されることを確認します。 !image.png 5.3. Observability で動作確認 Observability を選択します。 !image.png FIRST INPUT が Laptop Pro が過熱する場合の対処方法を、製品文書を根拠に教えてください。 の項目を選択します。 !image.png 処理内容を確認できます。 !image.png :::note info 地域別の売上高、販売数量、取引件数を売上高の降順で教えてください。 のスレッドは、下記のように表示されました。 !image.png ::: 6. 追加検証: SQL による情報取得 6.1. Agent の情報を取得 DESCRIBE AGENT CORTEX_AGENTS_LAB.TUTORIAL.TUTORIAL_AGENT; | 項目 | 値 | | -------------------- | ---------------------------------------------------------------- | | name | TUTORIAL_AGENT | | database_name | CORTEX_AGENTS_LAB | | schema_name | TUTORIAL | | owner | ACCOUNTADMIN | | comment | 売上分析と製品ドキュメント検索の検証用 Agent | | profile | {"display_name":"小売業データ分析エージェント"} | | agent_spec | 下記参照 | | created_on | 2026-10-18 18:49:56.988 -0700 | | default_version_name | LAST | | versions | ["VERSION$1"] | | aliases | {"DEFAULT":"VERSION$1","FIRST":"VERSION$1","LAST":"VERSION$1"} | agent_spec の詳細 | 項目 | 値 | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | models.orchestration | claude-sonnet-5-5 | | orchestration.budget.seconds | 90 | | orchestration.budget.tokens | 16000 | | orchestration.tool_not_accessible | reject | | instructions.response | 日本語で簡潔に回答する。数値は Analyst の実行結果、製品情報は Search の 検索結果を根拠とする。売上金額の単位は USD とする。 文書から得た情報には利用可能な引用を付ける。 根拠のない情報を補わず、確認できない場合はその旨を明記する。 | | instructions.orchestration | あなたは小売業の売上データと製品ドキュメントを調べるアシスタントである。 売上高、販売数量、取引件数の質問には Analyst を使用する。 製品仕様、組み立て方法、トラブルへの対処方法の質問には Search を使用する。 製品の名称は元の英語名を維持する。 | | tools[0].tool_spec.type | cortex_analyst_text_to_sql | | tools[0].tool_spec.name | Analyst | | tools[0].tool_spec.description | 売上高、販売数量、取引件数を商品、地域、顧客区分別に分析する | | tools[1].tool_spec.type | cortex_search | | tools[1].tool_spec.name | Search | | tools[1].tool_spec.description | 製品仕様、組み立て方法、トラブルへの対処方法を製品文書から検索する | | tool_resources.Analyst.semantic_view | CORTEX_AGENTS_LAB.TUTORIAL.SALES_SEMANTIC_VIEW | | tool_resources.Analyst.execution_environment.type | warehouse | | tool_resources.Analyst.execution_environment.warehouse | COMPUTE_WH | | tool_resources.Search.search_service | CORTEX_AGENTS_LAB.TUTORIAL.PRODUCT_SEARCH_SERVICE | | tool_resources.Search.max_results | 3 | DESCRIBE AGENT CORTEX_AGENTS_LAB.TUTORIAL.TUTORIAL_AGENT ->> WITH spec AS ( SELECT PARSE_JSON("agent_spec") AS body FROM $1 ) SELECT body:models:orchestration::STRING AS MODEL, body:instructions:system::STRING AS SYSTEM_PROMPT, body:instructions:orchestration::STRING AS ORCHESTRATION_INSTRUCTIONS, body:instructions:response::STRING AS RESPONSE_INSTRUCTIONS, body:instructions AS ALL_INSTRUCTIONS, body:orchestration AS ORCHESTRATION_SETTINGS, body:tools AS TOOLS, body:tool_resources AS TOOL_RESOURCES FROM spec; | 項目 | 値 | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | MODEL | claude-sonnet-5-5 | | SYSTEM_PROMPT | （空欄） | | ORCHESTRATION_INSTRUCTIONS | あなたは小売業の売上データと製品ドキュメントを調べるアシスタントである。売上高、販売数量、取引件数の質問には Analyst を使用する。製品仕様、組み立て方法、トラブルへの対処方法の質問には Search を使用する。製品の名称は元の英語名を維持する。 | | RESPONSE_INSTRUCTIONS | 日本語で簡潔に回答する。数値は Analyst の実行結果、製品情報は Search の検索結果を根拠とする。売上金額の単位は USD とする。文書から得た情報には利用可能な引用を付ける。根拠のない情報を補わず、確認できない場合はその旨を明記する。 | | ALL_INSTRUCTIONS | 下記参照 | | ORCHESTRATION_SETTINGS | 下記参照 | | TOOLS | 下記参照 | | TOOL_RESOURCES | 下記参照 | ALL_INSTRUCTIONS | 項目 | 値 | | ------------- | ------------------------------------------------------------------------------------------------------------------------------- | | orchestration | あなたは小売業の売上データと製品ドキュメントを調べるアシスタントである。売上高、販売数量、取引件数の質問には Analyst を使用する。製品仕様、組み立て方法、トラブルへの対処方法の質問には Search を使用する。製品の名称は元の英語名を維持する。 | | response | 日本語で簡潔に回答する。数値は Analyst の実行結果、製品情報は Search の検索結果を根拠とする。売上金額の単位は USD とする。文書から得た情報には利用可能な引用を付ける。根拠のない情報を補わず、確認できない場合はその旨を明記する。 | ORCHESTRATION_SETTINGS | 項目 | 値 | | ------------------- | ------ | | budget.seconds | 90 | | budget.tokens | 16000 | | tool_not_accessible | reject | TOOLS | 項目 | 値 | | ------------------------------ | --------------------------------- | | tools[0].tool_spec.name | Analyst | | tools[0].tool_spec.type | cortex_analyst_text_to_sql | | tools[0].tool_spec.description | 売上高、販売数量、取引件数を商品、地域、顧客区分別に分析する | | tools[1].tool_spec.name | Search | | tools[1].tool_spec.type | cortex_search | | tools[1].tool_spec.description | 製品仕様、組み立て方法、トラブルへの対処方法を製品文書から検索する | TOOL_RESOURCES | 項目 | 値 | | --------------------------------------- | ------------------------------------------------- | | Analyst.execution_environment.type | warehouse | | Analyst.execution_environment.warehouse | COMPUTE_WH | | Analyst.semantic_view | CORTEX_AGENTS_LAB.TUTORIAL.SALES_SEMANTIC_VIEW | | Search.max_results | 3 | | Search.search_service | CORTEX_AGENTS_LAB.TUTORIAL.PRODUCT_SEARCH_SERVICE | 6.2. SNOWFLAKE.LOCAL.GET_AI_OBSERVABILITY_EVENTS SELECT * FROM TABLE(SNOWFLAKE.LOCAL.GET_AI_OBSERVABILITY_EVENTS( 'CORTEX_AGENTS_LAB', 'TUTORIAL', 'TUTORIAL_AGENT', 'CORTEX AGENT' )) ORDER BY TIMESTAMP DESC; | 項目 | 値 | | ------------------- | ----------------------- | | TIMESTAMP | 2026-10-19 02:23:51.149 | | START_TIMESTAMP | 2026-10-19 02:23:41.551 | | TRACE | 下記参照 | | RESOURCE_ATTRIBUTES | 下記参照 | | RECORD_TYPE | SPAN | | RECORD | 下記参照 | | RECORD_ATTRIBUTES | 下記参照 | | VALUE | （空欄） | TRACE | 項目 | 値 | | -------- | -------------------------------- | | span_id | a01665e2a3dbaff0 | | trace_id | 4d384235536c41a9c0cdd01d5901211f | RESOURCE_ATTRIBUTES | 項目 | 値 | | ------------------------------- | --------------- | | snow.session.id | 361679196706194 | | snow.session.role.primary.id | 21557772 | | snow.session.role.primary.name | ACCOUNTADMIN | | snow.user.id | 215XXX | | snow.user.name | MANABIANXXXX | RECORD | 項目 | 値 | | ----------- | ------------------ | | kind | SPAN_KIND_INTERNAL | | name | Agent | | status.code | STATUS_CODE_OK | RECORD_ATTRIBUTES | 項目 | 値 | | ------------------------------------------ | ------------------------------------ | | ai.observability.input_id | 870bfc452b4ad11645c12b86cd5d2000 | | ai.observability.record_id | 1de7c36a-1525-44cd-a513-4979532d4c2e | | request_id | 1de7c36a-1525-44cd-a513-4979532d4c2e | | snow.ai.observability.agent.message_id | 5518788645 | | snow.ai.observability.agent.thread_id | 21557844 | | snow.ai.observability.database.id | 5518788085 | | snow.ai.observability.database.name | CORTEX_AGENTS_LAB | | snow.ai.observability.object.id | 21557800 | | snow.ai.observability.object.name | TUTORIAL_AGENT | | snow.ai.observability.object.type | Cortex Agent | | snow.ai.observability.object.version.id | 361679196098598 | | snow.ai.observability.object.version.name | LIVE | | snow.ai.observability.schema.id | 5518789689 | | snow.ai.observability.schema.name | TUTORIAL | | snow.ai.observability.span_kind | 1 | 6.3. SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AGENT_USAGE_HISTORY SELECT START_TIME, END_TIME, DATEDIFF('millisecond', START_TIME, END_TIME) AS DURATION_MS, REQUEST_ID, USER_NAME, AGENT_NAME, TOKENS, TOKEN_CREDITS, TOKENS_GRANULAR, CREDITS_GRANULAR, METADATA FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AGENT_USAGE_HISTORY WHERE AGENT_DATABASE_NAME = 'CORTEX_AGENTS_LAB' AND AGENT_SCHEMA_NAME = 'TUTORIAL' AND AGENT_NAME = 'TUTORIAL_AGENT' ORDER BY START_TIME DESC LIMIT 1; 基本情報 | 項目 | 値 | | ---------------- | ------------------------------------ | | START_TIME | 2026-10-18 19:23:41.551 -0700 | | END_TIME | 2026-10-18 19:23:51.333 -0700 | | DURATION_MS | 9782 | | REQUEST_ID | 1de7c36a-1525-44cd-a513-4979532d4c2e | | USER_NAME | MANABIANXXX | | AGENT_NAME | TUTORIAL_AGENT | | TOKENS | 68682 | | TOKEN_CREDITS | 0.046476170 | | TOKENS_GRANULAR | 下記参照 | | CREDITS_GRANULAR | 下記参照 | | METADATA | 下記参照 | TOKENS_GRANULAR | 項目 | 値 | | ------------------------------- | ------------------------------------ | | request_id | 1de7c36a-1525-44cd-a513-4979532d4c2e | | cortex_agents.model | claude-sonnet-5-5 | | cortex_agents.cache_read_input | 43518 | | cortex_agents.cache_write_input | 24588 | | cortex_agents.input | 10 | | cortex_agents.output | 566 | | start_time | 2026-10-18 19:23:41.551 -0700 | CREDITS_GRANULAR | 項目 | 値 | | ------------------------------- | ------------------------------------ | | request_id | 1de7c36a-1525-44cd-a513-4979532d4c2e | | cortex_agents.model | claude-sonnet-5-5 | | cortex_agents.cache_read_input | 0.00282867 | | cortex_agents.cache_write_input | 0.0399555 | | cortex_agents.input | 0.000013 | | cortex_agents.output | 0.003679 | | start_time | 2026-10-18 19:23:41.551 -0700 | METADATA | 項目 | 値 | | ------------------------ | -------------- | | agent_version_alias | null | | agent_version_id | 25609 | | agent_version_is_default | false | | agent_version_name | LIVE | | ai_functions_credits | null | | inference_region | global | | interaction_interface | agent_admin_ui | | role_id | 3 | | role_name | ACCOUNTADMIN | | sql_query_credits | null | | sql_query_warehouses | null | :::note info CORTEX_AGENT_USAGE_HISTORYビューには、遅延があることに注意してください。 > Latency for the view may be up to 1 hour. 出所: CORTEX_AGENT_USAGE_HISTORY view | Snowflake Documentation > このビューのデータ反映には、最大1時間の遅延が発生する場合があります。 上記の翻訳 ::: 7. 参考資料 7.1. 公式ガイド・サンプルコード - 公式チュートリアル - Build a Cortex Agent from Scratch with Snowflake - GitHub リポジトリ - Snowflake-Labs 公式 Notebook - 元リポジトリの LICENSE（Apache License 2.0） 7.2. オブジェクトの作成・管理 - Semantic View - CREATE SEMANTIC VIEW - Cortex Agent - CREATE AGENT - ALTER AGENT - DESCRIBE AGENT - GET_DDL - Cortex Agent versioning 7.3. エージェントの実行・監視 - エージェントの実行 - DATA_AGENT_RUN - リクエストの監視 - Monitor Cortex Agent requests - 利用状況の確認 - CORTEX_AGENT_USAGE_HISTORY - CORTEX_SEARCH_DAILY_USAGE_HISTORY 7.4. 料金・クレジット消費 - 料金体系 - Snowflake AI pricing - クレジット消費単価 - Snowflake Service Consumption Table

Snowflake DCM Projectsとは？ 宣言型で環境を管理する <!-- タイトル: Snowflake DCM Projectsとは？ 宣言型で環境を管理する タグ: Snowflake DCMProjects IaC 公開先: qiita.com 検証日（実機）: 2026-10-18（アカウント名・識別子は書かない） 作成: ドラフトv4+手修正 仕様: 20261019_Snowflake_DCM_02_記事仕様v4.md（正本。v1→v2→v3→v4の順に重ね、v4を優先） メモ: - H1は4つ（はじめに／概要／クイックスタート／まとめ）。H2は各章の中だけ。H3は内容が分かれるH2にだけ付ける（定型にしない）。 - 3章の見出しは日本語の簡潔なタイトル＋直後の「> Quickstart: ...」の引用（3-11のみ独自）。 - CLIは各節で <details> に折りたたむ。CLIは実機未実施。公式のコマンドのみ。 - 「つまずき」ラベルは、節の末尾に置く。型は2つだけ: 「再現できなかった」「公式の記載は X ですが、実行したら Y でした」。原因は推測しない。 - アカウント名・識別子は、画像も本文もすべてマスクする。 - コードの出典: Snowflake-Labs/snowflake-dcm-projects （Apache-2.0）。実機の版は、2026-10-07時点の main（Quickstarts/get-started-snowflake-dcm-projects） --> :::note info DCM Projects は、公式 Quickstart（2026-10-16 更新）で「generally available」とされています。ただし、Project assets、DEFINE STREAMLIT、DEFINE CODE BUNDLE など一部の機能はパブリックプレビューです（2026-10-17 時点）。 - 公式 Quickstart - 公式ドキュメント（英語） ::: 1. はじめに 1-1. 要約 Snowflake の DCM Projects を、公式 Quickstart「Get Started with Snowflake DCM Projects」に沿って動かしました。 DCM Projects を一言で言うと、手順を書く代わりに、あるべき状態を書く 仕組みです。 - 概要では、DCM Projects の考え方を整理します。Snowflake のオブジェクトを「あるべき状態」として SQL で宣言し、差分は Snowflake が計算します。利用者は、PLAN で内容を確認してから DEPLOY します。 - クイックスタートでは、Quickstart の流れに沿って、次の内容を解説します。Snowsight（GUI）と Snowflake CLI は、並べて示します。 - Workspace の作成 - PLAN と DEPLOY - 変更と再デプロイ - 管理対象とデプロイ履歴の確認 - 後片付け - Quickstart にはない独自検証として、「手で変えた環境を PLAN がどう見せるか」を確認します。管理対象を手で変えると、PLAN で検出され、DEPLOY で定義の状態に戻りました。定義にないオブジェクトは、PLAN に出ませんでした。 - Quickstart の本文と、実行時に使った GitHub のコードには、違いがありました。再現できなかった点や、数値が違った点は、各節の「つまずき」にまとめています。 手順だけ見たい方は「3. クイックスタート」からどうぞ。 2. 概要 2-1. DCM Projectsとは DCM（Database Change Management）Projects は、Snowflake のオブジェクトをコードとして管理する機能です。 データベース、スキーマ、テーブル、ウェアハウス、ロール、権限などの定義ファイルを、Git などでバージョン管理しながら、環境に適用します。定義ファイルには、手順ではなく、オブジェクトの あるべき状態 を書きます。すると、Snowflake がその状態にするための変更を判断し、適用します。 ポイント - 定義は DEFINE 文（SQL）で書きます。 - 反映は PLAN → DEPLOY の順です。PLAN は、実際に変更する前に、作成・変更・削除されるオブジェクトを示すドライランです。公式ドキュメントでは、この流れは、インフラをコードで管理するツールで一般的なワークフローと説明されています。 - 環境ごとの違い（DEV／PROD など）は、manifest と Jinja のテンプレート変数で切り替えます。 - Snowsight の Workspaces、Snowflake CLI、SQL、Cortex Code などから操作できます。 !image1.png 図の出典: Snowflake DCM Projects 2-2. DCM Projects があると何がうれしいか Snowflake の環境を、CREATE、ALTER、GRANT を順番に流して作ることがあります。構築した直後はきれいでも、運用の中で、少しずつ崩れていくことがあります。 - 急ぎの対応で、手で列を追加したり、権限を付けたりする - 知らないうちに、権限が足されている - 「本来あるべき状態」と今の状態の差を、人が調べ、コマンドを打って戻す 最後の作業は手間がかかり、見落としも出ます。 DCM Projects があると、以下のようなことが実現できます。 - あるべき状態だけを書けばよい: 差分は Snowflake が計算します。現在の状態に応じた ALTER を、自分で考える必要はありません。 - 実行前に何が起きるかが分かる: PLAN で、作成・変更・削除される予定を確認できます。 - 履歴が残る: デプロイに alias を付けると、あとから「どのデプロイで何が変わったか」が分かります。 - 環境ごとの違いを設定に集められる: 同じ定義ファイルから、DEV と PROD を作り分けられます。 - 同じ内容なら、何度デプロイしても結果は変わらない: 同じ内容を再デプロイしても、2回目は何も起きません。 2-3. 構成要素 DCM Projects は、次の要素でできています。 - DCM プロジェクトオブジェクト: Snowflake 上のスキーマレベルのオブジェクトです。PLAN や DEPLOY などのコマンドを実行する場所で、実行したデプロイの記録を持ちます。ターゲット環境ごとに1つ必要です。 - manifest.yml: デプロイ先（ターゲット）、アセット、環境ごとのテンプレート変数を書きます。 - 定義ファイル: sources/definitions/ 配下の SQL です。DEFINE 文でオブジェクトを書きます。 - マクロ: sources/macros/ 配下の Jinja マクロです。 この記事で使った Quickstart のサンプルは、次の構成です。 DCM_Projects_Get_Started/ ├── manifest.yml └── sources/ ├── definitions/ └── macros/ 2-4. 命令型と宣言型 命令型と宣言型の違いを整理します。 - スクリプトは命令型です。CREATE TABLE を2回実行すると、失敗するか、元のものを壊します。 - 「変更7を適用して、次に変更8を適用」のように、変更を順に並べる方式があります。この方式では、どこまで実行したかを記録する台帳が必要です。 - DCM Projects は、経路ではなく目的地を書きます。ファイルが常に最新のあるべき状態を表すので、その台帳は要りません。 | | 命令型（手順を書く） | 宣言型（状態を書く） | |---|---|---| | 書くこと | 「ALTER TABLE で列を追加する」 | 「このテーブルには、この列がある」 | | どこまで実行済みか | 人が管理する（台帳など） | 管理しない。Snowflake が現在の状態と比べる | | 実行順序 | 人が決める | 定義の場所や順序に関係なく、Snowflake が並べる | | 定義から消したもの | 残り続ける | 消すと、削除の対象になる（例: リストからチームを消すと、PLAN に DROP が出る） | 出典: Get Started with Snowflake DCM Projects 2-5. CREATE OR ALTER DEFINE は、CREATE OR ALTER として実行されます。CREATE OR REPLACE ではありません。 CREATE OR ALTER は、次のように動きます。 - 存在しなければ、定義どおりに作成します。 - 存在すれば、定義の状態になるように変更します。 - すでに定義と一致していれば、何も変更しません。 同じ文を何度実行しても、結果は変わりません。置き換えではなく、その場で変更します。 DCM Projects では、これに加えて次のように動きます。 - 定義ファイルの中の DEFINE の順序や場所は、結果に影響しません。Snowflake がすべての文を集めて並べるので、依存関係や順序を人が扱う必要はありません。 - テンプレートのリストから項目（チーム）を消すと、そのオブジェクトが DROP の対象になります。 ただし、CREATE OR ALTER にはオブジェクトごとの制限があります。 - オブジェクト名や列名の変更、列の並べ替えはできません。名前を変えると、削除と追加として扱われます。 - ALTER が対応していない変更（互換性のないデータ型への変更など）は、できません。 - ガバナンス（タグやポリシー）の変更には対応していません。 - テーブルでは、途中で失敗したときに、一部の変更だけが反映される場合があります（原子性は保証されません）。 - タスクは、変更の前に停止が必要です。 すべての変更に対応しているわけではないので、DEPLOY の前に PLAN で「何が起きるか」を確認します。 出典: CREATE OR ALTER <object>（SQL リファレンス） 3. クイックスタート 公式の Quickstart に沿って進めます。 3-0. 前提 > Quickstart: Overview / Prerequisites / What You'll Need / What You'll Build 前提知識 - Snowflake の基本（データベース、スキーマ、テーブル、ロール） - SQL の知識 必要なもの - ACCOUNTADMIN を使える Snowflake アカウント - Snowflake CLI（CLI で進める場合のみ） この Quickstart で作られるもの フードトラックの分析パイプラインです。 - ランディングテーブル3つ - ダイナミックテーブル Quickstart にあるものの、本記事では取り扱っていません。 - セマンティックビュー（詳細は 3-9. サンプルデータ） - Streamlit ダッシュボード（詳細は 3-10. Streamlitアプリ） 操作方法 DCM Projects は、Snowsight、Snowflake CLI、SQL、Cortex Code で管理できます。この記事では、手順ごとに、Snowsight（Workspaces）の操作を示し、同等の CLI コマンドを折りたたみで添えます。作業環境に合う方を選んでください。 筆者が実行したのは、Snowsight の操作です。CLI のコマンドは、公式のものをそのまま載せています。動作確認はしていません。 公式と実行時のコードの違い 公式 Quickstart（2026-10-16 更新）と、実行時に使った GitHub のコード（2026-10-07 時点の main）には違いがありました。実行する際に注意が必要な点は各節の「つまずき」にまとめています。 3-1. Workspaceの作成 > Quickstart: Create a Workspace from Git サンプルの DCM プロジェクトが入った GitHub リポジトリから、Snowsight の Workspace を作ります。 Workspaceを作る Snowsight 1. Snowsight で Projects > Workspaces を開く 2. Create (+) から Git repository を選ぶ 3. リポジトリ URL に https://github.com/snowflake-labs/snowflake-dcm-projects を入力する 4. GitHub 用の API Integration を選ぶ（なければ作成する） 5. Public repository を選ぶ !image2.png !image3.png CLI: この手順は Snowsight のみです（ローカルでのクローンは扱いません）。 2つのディレクトリ Workspace ができたら、Quickstarts/get-started-snowflake-dcm-projects を開きます。2つのディレクトリがあります。 - DCM_Projects_Get_Started/: DCM プロジェクト本体です。manifest、定義ファイル7つ、マクロ1つが入っています。 - scripts/: 手順の途中で、ワークシートとして実行する SQL です。プロジェクトの外にあるので、PLAN には拾われません。 !image4.png | ファイル | 実行するタイミング | |---|---| | scripts/01_pre_deploy.sql | 最初の PLAN の前に1回 | | scripts/02_post_deploy.sql | 最初の DEPLOY が成功した後 | | scripts/03_cleanup.sql | 片付けるとき | 3-2. 事前準備 > Quickstart: Prerequisites and Setup scripts/01_pre_deploy.sql を、上から順に実行します。 Snowsight 1. scripts/01_pre_deploy.sql をワークシートで開く 2. 上から順に実行する 3. 最後のクエリの結果からアカウント識別子account_identifierを控える（次で使います） 4. ブラウザを更新する !image5.png <details><summary>CLI</summary> snow sql -f scripts/01_pre_deploy.sql </details> このスクリプトは、次のことを行います。 - DCM_DEVELOPER ロールを作り、自分に付与します。 - DCM_DEVELOPER に、アカウントレベルの権限をまとめて付与します。 - DCM_DEVELOPER に、データ品質に関する権限を付与します。 - DCM プロジェクトオブジェクトを作り、アカウント識別子とユーザー名を表示します。 アカウントレベルの権限は、プロジェクト自身が自分に付与できません。そのため、最初の PLAN の前に、このスクリプトで付与しておきます。 -- DCM プロジェクトオブジェクトを作る CREATE OR REPLACE DCM PROJECT dcm_demo.projects.dcm_project_dev COMMENT = 'for testing DCM Projects Quickstarts'; 全文は、次の折りたたみに載せます。出典: 01_pre_deploy.sql（GitHub） <details><summary>01_pre_deploy.sql（全文）</summary> /*============================================================================= 01_pre_deploy.sql — Run BEFORE the first DCM Plan & Deploy Creates the DCM Developer role, grants, optional warehouse, and the DCM Project object that the manifest references. =============================================================================*/ ---------------------------------------------------------------------- -- 1. Create a DCM Developer Role ---------------------------------------------------------------------- USE ROLE ACCOUNTADMIN; CREATE ROLE IF NOT EXISTS dcm_developer; SET user_name = (SELECT CURRENT_USER()); GRANT ROLE dcm_developer TO USER IDENTIFIER($user_name); ---------------------------------------------------------------------- -- 2. Grant Infrastructure Privileges ---------------------------------------------------------------------- GRANT CREATE WAREHOUSE ON ACCOUNT TO ROLE dcm_developer; GRANT CREATE ROLE ON ACCOUNT TO ROLE dcm_developer; GRANT CREATE DATABASE ON ACCOUNT TO ROLE dcm_developer; GRANT EXECUTE MANAGED TASK ON ACCOUNT TO ROLE dcm_developer; GRANT EXECUTE TASK ON ACCOUNT TO ROLE dcm_developer; GRANT MANAGE GRANTS ON ACCOUNT TO ROLE dcm_developer; ---------------------------------------------------------------------- -- 3. Grant Data Quality Privileges ---------------------------------------------------------------------- GRANT APPLICATION ROLE SNOWFLAKE.DATA_QUALITY_MONITORING_VIEWER TO ROLE dcm_developer; GRANT EXECUTE DATA METRIC FUNCTION ON ACCOUNT TO ROLE dcm_developer; ---------------------------------------------------------------------- -- 4. Create the DCM Project Object ---------------------------------------------------------------------- USE ROLE dcm_developer; CREATE DATABASE IF NOT EXISTS dcm_demo; CREATE SCHEMA IF NOT EXISTS dcm_demo.projects; CREATE OR REPLACE DCM PROJECT dcm_demo.projects.dcm_project_dev COMMENT = 'for testing DCM Projects Quickstarts'; ---------------------------------------------------------------------- -- 6. Get your account identifier and username -- (use these values to update manifest.yml) ---------------------------------------------------------------------- SELECT CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME() AS account_identifier, CURRENT_USER() AS user_name; </details> DCM プロジェクトそのものも、Snowflake のオブジェクトです。 ブラウザを更新しないと、作った DCM プロジェクトが、Workspace のプロジェクト選択に出ません。 つまずき 公式の記載では、このスクリプトで、アカウントレベルの継承付与（inherited grants）を有効にします。実行したスクリプトには、その行がありませんでした。継承付与に関するつまずきは、次の「3-4. PLANとDEPLOY」にまとめています。 3-3. プロジェクトの構成 > Quickstart: Anatomy of a DCM Project プロジェクトは、manifest と、sources/ 配下の定義ファイルでできています。manifest が制御の入口で、定義ファイルがあるべき状態です。 manifest.ymlの書き換え やること 1. DCM_Projects_Get_Started/manifest.yml を開く 2. DCM_DEV の account_identifier（MYORG-MY_DEV_ACCOUNT）を、「3-2. 事前準備」で表示された自分のアカウント識別子に書き換える !image6.png manifest.ymlの読み方 DCM_Projects_Get_Started/manifest.yml には、targets と templating のセクションがあります。実行した版の抜粋を示します。 manifest_version: 2 type: DCM_PROJECT default_target: DCM_DEV targets: DCM_DEV: account_identifier: MYORG-MY_DEV_ACCOUNT project_name: DCM_DEMO.PROJECTS.DCM_PROJECT_DEV project_owner: DCM_DEVELOPER templating_config: DEV templating: defaults: user: "GITHUB_ACTIONS_SERVICE_USER" wh_size: "X-SMALL" configurations: DEV: env_suffix: "_DEV" user: "INSERT_YOUR_USER" project_owner_role: "DCM_DEVELOPER" teams: - name: "DEV_TEAM_1" data_retention_days: 1 needs_sandbox_schema: true 出典: snowflake-dcm-projects（GitHub）の manifest.yml の抜粋（DCM_STAGE、DCM_PROD_US、DCM_PROD_EU、STAGE、PROD は省略） 読みどころ - targets: デプロイ先です。どのアカウントの、どの DCM プロジェクトオブジェクトに、どの設定（templating_config）でデプロイするかを指定します。実行した版には、DCM_DEV のほかに、DCM_STAGE、DCM_PROD_US、DCM_PROD_EU もあります。この記事では DCM_DEV だけを使います。 - templating: 環境ごとの値です。defaults は共通の値で、configurations が上書きします。 - env_suffix: 1つの定義ファイルから、DEV では DCM_DEMO_1_DEV、PROD では DCM_DEMO_1 が作られます。 定義ファイルの読み方 定義ファイルは、CREATE の代わりに DEFINE を使います。manifest が制御する値は、Jinja で差し込みます。例として、sources/definitions/analytics.sql の先頭を示します。 define schema DCM_DEMO_1{{env_suffix}}.ANALYTICS; define dynamic table DCM_DEMO_1{{env_suffix}}.ANALYTICS.ENRICHED_ORDER_DETAILS warehouse = DCM_DEMO_1_WH{{env_suffix}} target_lag = 'DOWNSTREAM' initialize = 'ON_SCHEDULE' data_metric_schedule = 'TRIGGER_ON_CHANGES' as select ... 出典: 同じリポジトリの sources/definitions/analytics.sql（select 以下は省略） 実行した版の定義ファイルは、次の7つです。 - raw.sql: データベース、スキーマ、ランディングテーブル - ingest.sql: ステージ、取り込み用のテーブルとタスク - access.sql: ウェアハウス、読み取りロール、権限 - analytics.sql: ダイナミックテーブル、関数 - serve.sql: ビュー - expectations.sql: データ品質（データメトリクス関数） - jinja_demo.sql: テンプレートで作るチーム用オブジェクト 3-4. PLANとDEPLOY > Quickstart: First Plan and Deploy 必ず、先に PLAN します。PLAN は、テンプレートを展開して SQL にします。そして、アカウントの現在の状態と比べ、何をするかを報告します。この時点では、何も作られません。 PLANを実行する Snowsight 1. Workspace の下のパネルにある、最初のタブ（DCM のコントロールパネル）を開く（GUI 上の場所が分かりづらく、今後変わる可能性もあります） 2. プロジェクト get-started-snowflake-dcm-projects/DCM_Projects_Get_Started を選ぶ 3. ターゲットが DCM_DEV で、DCM_PROJECT_DEV と DEV の設定を指していることを確認する 4. Plan の右の再生ボタンを押す DCM のコントロールパネル !image7.png PLANの選択と実行 !image8.png PLANの結果 !image8_1.png <details><summary>CLI</summary> snow dcm plan --target DCM_DEV --save-output </details> つまずき - 公式の記載は 18 件（17 create、1 alter、0 drop）ですが、実行したら 35 件の作成と 1 件の変更でした。 - 最初の PLAN が、次のエラーで失敗しました。 Error during DCM PLAN of DCM Project DCM_DEMO.PROJECTS.DCM_PROJECT_DEV: Execution failed after completing [45/58] statement executions in file sources/definitions/access.sql on line 20 at position 1: Unsupported feature 'INHERITED'. - 継承付与（FEATURE_RBAC_INHERITED_GRANTS と grant INHERITED SELECT）は、パブリックプレビューの機能で、アカウントレベルのオプトインが必要です。 - アカウントでオプトインすれば動くと考えられますが、今回は確認していません。access.sql の grant INHERITED SELECT の3行をコメントアウトして進めました。 - コメントアウトしたため、読み取りロール DCM_DEMO_1_DEV_READ には、この3行によるテーブル、ダイナミックテーブル、ビューへの SELECT が付与されません。 !image8_2.png 変更セットの読み方 - ALTER が1件あるのは、DCM_DEVELOPER ロールが、新しく作られるオブジェクトの所有権を得るためです。最初のデプロイでは、必ずこの1件が出ます。ずれ（drift）ではなく、直すものもありません。 - エンティティは、SQL の1行ではありません。DCM が所有し、以後のデプロイのたびに調整する対象を指します。 --save-output を付けると、展開後の SQL と plan_result.json が out/ に出力されます。Snowsight でも、同じ内容が out フォルダに出ます。plan_result.json の changes[] に、エンティティごとの変更が入っています。 DEPLOYする PLAN の内容が想定どおりなら、DEPLOY します。 Snowsight 1. コントロールパネルの操作を Deploy に切り替える 2. デプロイの alias を入れる（例: initial-deployment） 3. 実行する !image9.png !image9_1.png <details><summary>CLI</summary> snow dcm deploy --target DCM_DEV --alias initial-deployment </details> デプロイ結果を後から確認する - alias は、このデプロイにつけるラベルです。コミットメッセージのように、デプロイ履歴に残ります。 - デプロイ履歴はカタログエクスプローラーで確認することができます。 !image9_2.png 3-5. 変更の反映 > Quickstart: Change It and Redeploy ここでは、宣言型の動きを確認します。3つの変更を行います。 3つの変更 やること 1. sources/definitions/analytics.sql: ダイナミックテーブル MENU_ITEM_POPULARITY の target_lag を、'1 day' から '30 minutes' にする ```sql -- target_lag = '1 day' target_lag = '30 minutes' ``` 2. manifest.yml の DEV の設定: ウェアハウスのサイズを SMALL にする ```yaml wh_size: "SMALL" ``` 3. manifest.yml の DEV の teams に、DEV_TEAM_2 を追加する ```yaml - name: "DEV_TEAM_2" data_retention_days: 3 ``` 3つのうち2つは、manifest の変更です。YAML の数行で、新しいオブジェクトがまとめて作られます。 !image10.png 変更分だけ見る方法を試す（delta） Snowsight: Plan Mode で Delta を選びます。 !image10_1.png <details><summary>CLI</summary> snow dcm plan --delta --target DCM_DEV </details> --delta は、変更した定義だけを評価します。DCM の外で行われた変更（ずれ）は検出できません。 デプロイの前には、必ず通常（full）の PLAN を実行します。 通常のPLANを実行する Snowsight: 1. Plan Mode で通常の Plan を選び、実行します。 2. 書き換えた内容が変更セットで確認できます。 - DEV_TEAM_2: ロール 3 つ、スキーマ DEV_TEAM_2、テーブル PRODUCTS が「作成」として出ます。 - wh_size: DCM_DEMO_1_WH_DEV が「変更」として出て、Warehouse Size が X-Small から Small に変わります。 - TARGET_LAG: MENU_ITEM_POPULARITY が「変更」として出て、Seconds が 86400 から 1800 に変わります。 - DCM_DEVELOPER: 「変更」として出ます。新しく作られるオブジェクトの所有権を得るためです（「3-4. PLANとDEPLOY」と同じ）。 !image11.png <details><summary>CLI</summary> snow dcm plan --target DCM_DEV --save-output </details> デプロイする alias lag-wh-and-team2 で DEPLOY します。 Snowsight: コントロールパネルで Deploy に切り替え、alias を入れて実行します。 !image11_1.png <details><summary>CLI</summary> snow dcm deploy --target DCM_DEV --alias lag-wh-and-team2 </details> 変更せずにもう一度デプロイする 次に、何も変えずに、alias no-op-proof でもう一度デプロイを試してみます。 <details><summary>CLI</summary> snow dcm deploy --target DCM_DEV --alias no-op-proof </details> 結果は「検出された変更はありません」とプランに表示され、デプロイしても何も起きません。 !image12.png DEFINE は、CREATE OR REPLACE ではなく CREATE OR ALTER として実行されます。2回目は、あるべき状態と現在の状態を比べて、同じだと分かった時点で止まります。ダイナミックテーブルも作り直されず、テーブルのデータも消えません。 これが、「状態を宣言する」ことと「スクリプトを実行する」ことの違いです。 つまずき - 公式の記載では、ENRICHED_ORDER_DETAILS の TARGET_LAG を '1 hour' から '30 minutes' に変えます。GitHub のコードの ENRICHED_ORDER_DETAILS は target_lag = 'DOWNSTREAM' で、CHANGE STEP のコメントもありませんでした。今回は、代わりに MENU_ITEM_POPULARITY の target_lag を、'1 day' から '30 minutes' に変えました。 - 公式の記載は 6 件（3 create、3 alter、0 drop）ですが、実行したら 5 件の作成と 3 件の変更でした。 3-6. 管理対象と履歴 > Quickstart: Inspect What the Project Manages DEPLOY したあとに、何が管理されているか、いつ何が変わったかを確認できます。 確認には、SQL の SHOW 文と、カタログエクスプローラーの画面を使います。CLI で進める場合も、SHOW 文は SQL として実行します。 管理対象の一覧 プロジェクトが管理しているエンティティが、種類と名前つきで一覧に出ます。SQLもしくはカタログエクスプローラーの画面で確認できます。 SQL SHOW ENTITIES IN DCM PROJECT dcm_demo.projects.dcm_project_dev; カタログエクスプローラー !image13.png 結果は 39件 でした。この一覧にあるものは、デプロイのたびに調整されます。一覧にないものは、同じデータベースにあっても、DCM からは見えません。PUBLIC スキーマと DCM_DEVELOPER ロールは、一覧にありません。 作成した件数の合計（35件＋5件＝40件）と1件違うのは、PUBLIC スキーマが、作成の件数には入りますが、管理対象の一覧には入らないためです（Quickstart の説明に基づきます）。 DCM プロジェクトオブジェクトも、データベース側にオブジェクトとして作られています。管理対象の情報は、そこに保存されます。 デプロイ履歴 ここまでの DEPLOY が、alias つきで履歴に出ます。no-op-proof は何も変えていませんが、履歴には残っています。 SQL SHOW DEPLOYMENTS IN DCM PROJECT dcm_demo.projects.dcm_project_dev; カタログエクスプローラー !image14.png この2つの確認で、「この環境には何があり、どのデプロイで何が変わったのか」が分かります。定義ファイルを読む必要はありません。複数のプロジェクトが同じアカウントにあるときは、自分のプロジェクトのオブジェクトを見分けるためにも使えます。 3-7. Jinjaテンプレート > Quickstart: Templating and Per-Environment Config manifest が値を渡し、定義ファイルがそれを使います。この関係を確認します。sources/definitions/jinja_demo.sql には、Jinja の3つの使い方があります。 - manifest の teams リストをループする - 辞書の値（data_retention_days）を、オブジェクトのプロパティに差し込む - マクロを呼び出して、チーム用のロールを作る {% for team in teams %} {% set team_name = team.name | upper %} define schema DCM_DEMO_1{{env_suffix}}.{{team_name}} comment = 'using JINJA dictionary values' data_retention_time_in_days = {{ team.data_retention_days }}; {{ create_team_roles(team_name) }} ... {% endfor %} 出典: snowflake-dcm-projects（GitHub）の sources/definitions/jinja_demo.sql（抜粋）と、マクロ sources/macros/grants_macro.sql。マクロは、チーム用のロール3つ（_OWNER、_DEVELOPER、_USAGE）と、その付与を作ります。manifest のチームの数は、DEV と PROD で違います。 Jinja は、Snowflake が SQL を解釈する前に展開されます。 そのため、SQL のコメント（--）の中に書いた {{ ... }} も評価されます。コメントアウトしたつもりの行で、PLAN が失敗することがあります。説明の文章に Jinja の記号を書くときは、Jinja のコメント {# ... #} を使います（Quickstart の記載です。実機では確認していません）。 展開後の SQL は、PLAN のあとに out/rendered/ で確認できます。 !image15.png 3-8. ATTACHとGRANT > Quickstart: Beyond DEFINE: ATTACH and GRANT DEFINE はオブジェクトを宣言します。残りの2つは次のとおりです。 - ATTACH: 2つのオブジェクトの関係を宣言します。例として、タグを定義して、テーブルに付けます。 - GRANT: Snowflake 標準の GRANT 構文そのままです。付与はロールに属し、独立した管理対象ではないので、PLAN には ALTER ROLE として出ます。 この記事では、詳しくは触れません。 3-9. サンプルデータ > Quickstart: Seed Data and Query つまずき この節は、再現できませんでした。理由: Quickstart の本文と、実行時に使った GitHub のコードが違っていたためです。 Quickstart の本文は、セマンティックビュー ORDER_ANALYTICS を問い合わせます。実行時に使ったコードにはその定義がなく、クエリがエラーになりました。 実行時に使った scripts/02_post_deploy.sql: 02_post_deploy.sql（GitHub） 3-10. Streamlitアプリ > Quickstart: The App That Reads It Quickstart のこの節（The App That Reads It）は、今回は扱いません。 この節は、Streamlit アプリをプロジェクトに同梱する内容です。Project assets、DEFINE STREAMLIT、DEFINE CODE BUNDLE（いずれもパブリックプレビュー）を使います。 3-11. 独自検証：手動変更とPLAN > Quickstartにはない、筆者の独自検証です 「3-5. 変更の反映」では、DCM の定義ファイルを変えて再デプロイしました（DCM の中の変更）。 ここでは、DCM の外から手で変えた環境を、PLAN が見つけるかを確かめます。 「3-5. 変更の反映」で触れた「--delta は DCM の外の変更を検出できない」の、裏側にあたる検証です。 検証は2つです。どちらも、SQL を先に実行してから、通常（full）の PLAN と DEPLOY を1回ずつ行いました。 | | 対象 | 手動の操作 | |---|---|---| | 検証A | 管理対象（定義にある）: ウェアハウス | サイズを MEDIUM に変更 | | 検証B | 管理対象外（定義にない）: セマンティックビュー | 管理スキーマ SERVE の中に作成 | 手動で変更する ワークシートで、次の SQL を実行しました。dcm_developer ロールを使っています。 -- 検証A: 管理対象を手で変える（定義の wh_size は SMALL） ALTER WAREHOUSE DCM_DEMO_1_WH_DEV SET WAREHOUSE_SIZE = 'MEDIUM'; -- 検証B: 管理対象外を手で作る（serve.sql には定義がない） CREATE OR REPLACE SEMANTIC VIEW DCM_DEMO_1_DEV.SERVE.ORDERS_SEMANTIC_VIEW TABLES ( ORDERS AS DCM_DEMO_1_DEV.ANALYTICS.ENRICHED_ORDER_DETAILS ) DIMENSIONS ( ORDERS.ITEM_CATEGORY AS ORDERS.ITEM_CATEGORY ) METRICS ( ORDERS.TOTAL_REVENUE AS SUM(ORDERS.LINE_ITEM_REVENUE) ) COMMENT = '手動で作成（DCM の管理対象外）'; 定義ファイル（serve.sql、manifest.yml）は、変えていません。 !image16.png PLANで確認する 定義ファイルは変えずに、通常（full）の PLAN を実行しました。結果は次のとおりです。 - 検証A: ウェアハウスの Warehouse Size が、Medium から Small への変更として出ました。 - 検証B: セマンティックビューは、PLAN に出ませんでした。SERVE スキーマは DCM が管理していますが、このビューは定義にありません。 !image16_1.png 公式ドキュメントには、PLAN が「前回のデプロイで定義されたエンティティの現在の状態」と、定義を比べる、という趣旨の説明があります。定義にないビューが PLAN に出なかったことは、この説明と合っています。 DEPLOYで戻す alias manual-change-test で DEPLOY しました。結果は次のとおりです。 - 検証A: ウェアハウスのサイズは Small に戻りました。履歴の Changes は 1 Altered です。 - 検証B: セマンティックビューは、DEPLOY のあとも残っていました。 手で変えた管理対象は、DEPLOY で定義の状態に戻りました。定義にないもの（セマンティックビュー）は、PLAN に出ず、DEPLOY でも変更されず、残ったままでした。 3-12. 後片付け > Quickstart: Detach and Clean Up 後片付けの2つの方法 - PURGE: プロジェクトが管理するオブジェクトとデータを、すべて削除します。 - Detach（切り離し）: PURGE せずに、DROP DCM PROJECT だけを実行します。プロジェクトとデプロイ履歴は消えます。オブジェクト、権限、アタッチメントは、管理されない普通のオブジェクトとして残ります。 この記事では、Quickstart のとおり、PURGE で片付けます。 PURGEで片付ける Snowsight: scripts/03_cleanup.sql をワークシートで開き、実行します。 <details><summary>CLI</summary> snow sql -f scripts/03_cleanup.sql </details> 実行したスクリプトの中身は、次のとおりです。 USE ROLE dcm_developer; EXECUTE DCM PROJECT dcm_demo.projects.dcm_project_dev PURGE; DROP DCM PROJECT IF EXISTS dcm_demo.projects.dcm_project_dev; DROP SCHEMA IF EXISTS dcm_demo.projects; DROP DATABASE IF EXISTS dcm_demo; USE ROLE ACCOUNTADMIN; DROP ROLE IF EXISTS dcm_developer; PURGE は元に戻せません。 プロジェクトが管理するオブジェクトと、そのデータを削除します。対象は、データベース、スキーマ、テーブル、ダイナミックテーブル、ウェアハウス、ロールなどです。権限は取り消され、アタッチメントは外れます。 DROP DATABASE と DROP ROLE も、元に戻せません。ほかの用途で dcm_demo や dcm_developer を使っている場合は、実行しないでください。 実行後、カタログエクスプローラーとウェアハウスの一覧で、DCM_DEMO のデータベースと DCM_DEMO_1_WH_DEV ウェアハウスが消えていることを確認しました。 つまずき 公式の記載では、dcm_demo.projects スキーマ、dcm_demo データベース、dcm_developer ロールは、他の Quickstart と共有されているため、スクリプトでコメントアウトされています。実行したスクリプトではコメントアウトされておらず、これらも削除されました。 4. まとめ 覚えておくことは、3点です。 - 経路ではなく、目的地を書く。 DEFINE は CREATE OR ALTER として実行されるので、変更がなければ何も起きません。ただしオブジェクトごとの制限があり、一部の機能はパブリックプレビューです。 - PLAN で差分を見てから、DEPLOY する。 実際に何が変わるかは、PLAN で確かめます。 - DCM が守るのは、定義した範囲だけ。 手で変えた管理対象は、PLAN で差分として見え、DEPLOY で戻ります。定義にないものは、PLAN に出ません。 参考 - Get Started with Snowflake DCM Projects（公式 Quickstart） - Snowflake-Labs/snowflake-dcm-projects（GitHub） - Snowflake DCM Projects（公式ドキュメント） - Snowflake DCM Projects（公式ドキュメント 日本語） - CREATE OR ALTER <object>（SQL リファレンス）

SnowflakeのAI関数とPythonを使って日本語ドキュメント（契約書や約款のPDF）を構造的に読み取るハンズオンとテックブログを公開しました。 github.com/Snowflake-Labs/sf-samples-jp/tree/main… zenn.dev 契約書や約款のように構造を持つドキュメント（「章・条・節・項」や、2段組レイアウト、表やダイアグラム等）はOCRで日本語テキストだけを読んでも文章構造が失われ、正確にテキスト読み取りできないことがあります。 このブログでは（私個人が作った）合成データの契約書や約款を使って、PDFから構造を維持したJSONとしてドキュメントを読み取る手法を紹介しています。

The agent is available on Github: Snowflake-Labs/data-eng-bench And full article on Snowflake Engineering Blog: snowflake.com

ご参加ありがとうございました！ 本日のデモで使った SQL の変更が他に影響があるか検知する plugin はこちらになります。 github.com/Snowflake-Labs/swt-tokyo-2026-coco/tre… t.co

Snowflake-Labs/zero-to-snowflake-ja しょーさん謹製！日本語化したzero to snowflake #雪かき部