Snowflake DCM Projectsが一般提供！Preview時との差分を整理してみた
さがらです。
2026年3月、SnowflakeネイティブでSnowflakeオブジェクトを宣言的に管理できる「DCM Projects」がPreviewとして登場しました。
当時は、Jinjaテンプレートを使って同一Snowflakeアカウント内にDEV / PROD環境を構築する検証を行っています。
そして2026年8月7日付のSnowflakeリリースノートで、DCM ProjectsのGeneral Availability（GA）が発表されました。
本記事では、以下を確認します。
- DCM ProjectsのGAで何が変わったのか
- 現時点で管理できるオブジェクトは何か
- GA後もPreviewに留まる機能は何か
- Storage Integrationをはじめ、現在もDCM Projectsでは定義できないものは何か
- 利用時に注意すべき制約は何か
なお、本記事の内容は日本時間2026年8月8日時点の公式ドキュメントに基づいています。
DCM ProjectsのGAと、関連機能のPreviewについて
DCM Projects本体はGAとなりました。
そのため、DEFINEによるSnowflakeオブジェクトの宣言的管理、Jinjaテンプレートによる環境差分の吸収、PLANによる変更レビュー、DEPLOYによる反映という中核ワークフローは、本番利用を前提とした選択肢として検討しやすくなっています。
ただし、DCM ProjectsがGAになったことと、DCM Projectsに関連するすべての構文・オブジェクト・周辺機能がGAになったことは別です。
実際には、データ品質テスト、GitHub Actions連携、PipeやStream、データ保護ポリシー、Tagのアタッチなどには、引き続きPreview機能が残っています。
そのため、導入を判断する際は自分たちが使いたいオブジェクト・構文がGAかPreviewかまで確認する必要があります。
ステータス早見表
| 区分 | ステータス | 主な内容 |
|---|---|---|
| DCM Projectsのコア機能 | GA | DEFINE、Jinja、PLAN、DEPLOY |
| 品質・事前確認 | Preview | TEST、PREVIEW |
| CI/CD連携 | Preview | GitHub Actions for DCM Projects |
| 一部のパイプライン定義 | Preview | DEFINE PIPE、DEFINE STREAM |
| 一部のガバナンス機能 | Preview | DEFINE MASKING POLICY、DEFINE ROW ACCESS POLICY、ATTACH TAG |
| 高度な権限管理 | Preview | Inherited Grants、container-level MANAGE GRANTS |
TEST / PREVIEW、GitHub Actions、DEFINE PIPE、DEFINE STREAM、Masking Policy、Row Access Policy、ATTACH TAG、Inherited Grants、container-level MANAGE GRANTSは、2026年8月8日時点でもPreviewです。
参考：Preview時の検証記事
DCM ProjectsのPreview時、以下のように検証記事を書いていました。
Preview時の記事では、1つのDCM project folderからDEV / PROD環境を展開する構成を試しました。
manifest.ymlにDEV / PRODのtargetを定義- 環境ごとに別のDCM project objectを作成
- JinjaテンプレートでDatabase名やWarehouseサイズを切り替え
PLANで変更内容を確認してからDEPLOY- Database、Schema、Warehouse、Role、Grant、Table、Dynamic Table、Taskなどを管理
この基本的な考え方は、DCM ProjectsがGAとなった現在も変わっていません。
そのため今回の記事では、この基本構成の再検証は行わず、「対応範囲がどこまで広がったか」と「まだDCM Projectsだけでは完結しないものは何か」に焦点を当てます。
Preview時からの主な変更点
差分一覧
| 項目 | Preview時の検証時点 | 現在 |
|---|---|---|
| DCM Projects本体 | Preview | GA |
| 基本フロー | DEFINE → PLAN → DEPLOY |
継続 |
| Jinjaテンプレート | 対応 | 継続 |
| File Format | 非対応として紹介 | 対応 |
| External Stage | 未検証 | 対応 |
| Sequence | 未紹介 | 対応 |
| Share | 未紹介 | 対応 |
| Network Rule / Policy | 未紹介 | 対応 |
| Function / Procedure | 未紹介 | 対応 |
| Alert | 未紹介 | 対応 |
PLAN DELTA |
未紹介 | 機能追加 |
TEST ALL |
記事で紹介 | Previewのまま |
前回の記事との差分として最も分かりやすいのは、File Formatが現在は対応対象になっている点です。
File Format、External Stage、Table、Taskなどを組み合わせることで、データロードに必要なSnowflake側の設定を、より一貫して定義ファイルで管理できるようになりました。
また、Network Rule / Network Policy、Shareも対応対象に含まれています。
DCM Projectsは、単にDatabase・Schema・Tableを作成するための機能ではなく、Snowflake環境の基盤設定、データパイプライン、共有設定、一部のガバナンス設定までをコードとして管理する方向に広がっていると感じます。
また、2026年7月16日にはPLAN DELTAが追加されています。変更した定義とその下流依存のみを高速に確認できる機能で、開発中のイテレーションには便利ですが、Deploy前には通常のフルPLANを実行し、影響範囲全体を確認することが推奨されています。
現在DCM Projectsで定義・管理できるもの一覧
DCM Projectsの定義ファイルでは、以下の3種類のステートメントを扱えます。
- Entity：
DEFINE文でSnowflakeオブジェクトを定義する - Grant：
GRANT文で権限やロール階層を定義する - Attachment：
ATTACH文でDMFやTagなどを対象へ関連付ける
以下は、2026年8月8日時点の公式ドキュメントをもとにした対応一覧です。
Entity：DEFINEできるオブジェクト
基盤・コンテナ・コンピュート
| オブジェクト | ステータス | 補足 |
|---|---|---|
| Database | GA | |
| Schema | GA | |
| Warehouse | GA | |
| Role | GA | Account Role |
| Database Role | GA | Database内に絞ったRole |
| Sequence | GA | |
| Tag | GA | Tagの定義。Viewやテーブル個別カラムへのATTACH TAGは非対応 |
| Share | GA | ShareとShareへのGrantを管理可能 |
データモデル・パイプライン
| オブジェクト | ステータス | 補足 |
|---|---|---|
| Table | GA | 一部の列変更やTag / Policy関連には制約あり |
| View | GA | 列順変更には制約あり |
| Dynamic Table | GA | 変更内容により再初期化・フルリフレッシュが必要。INITIALIZEは変更不可 |
| File Format | GA | Preview時の記事からの明確な拡張点 |
| External Stage | GA | |
| Internal Stage | GA | |
| Task | GA | STARTED / SUSPENDEDの状態管理が可能 |
| Alert | GA | STARTED / SUSPENDEDの状態管理が可能 |
| Pipe | Preview | DEFINE PIPE。作成後はCOMMENT以外変更不可 |
| Stream | Preview | DEFINE STREAM。作成後はCOMMENT以外変更不可 |
Function/Procedure・ポリシー・データ品質
| オブジェクト | ステータス | 補足 |
|---|---|---|
| Function | GA | SQL / Java / JavaScript / Python / Scala |
| Procedure | GA | SQL / Java / JavaScript / Python / Scala |
| Data Metric Function | GA | DEFINE DATA METRIC FUNCTIONでユーザー定義DMFを定義可能 |
| Authentication Policy | GA | ポリシー定義 |
| Network Rule | GA | TYPE / MODEは作成後に変更不可 |
| Network Policy | GA | Policyの割り当てはDCMの対象外 |
| Masking Policy | Preview | ポリシー定義は可能 |
| Row Access Policy | Preview | ポリシー定義は可能 |
DCM Projectsの公式対応一覧では、上記のEntityが定義対象として列挙されています。Pipe、Stream、Masking Policy、Row Access PolicyはPreviewです。また、DEFINE文は対応するSnowflakeオブジェクトのCREATE OR ALTERとして実行されるため、各オブジェクトが持つCREATE OR ALTERの制約をそのまま引き継ぎます。
Grant：管理できる権限
| 機能 | ステータス | 補足 |
|---|---|---|
通常のGRANT |
GA | 権限付与、Role付与 |
GRANT OWNERSHIP |
GA | 既存Grantとの関係に注意 |
| Inherited Grants | Preview | GRANT INHERITED。有効化にALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED'が必要 |
Container-level MANAGE GRANTS |
Preview | Database / Schema単位の権限管理委譲。上記と同じパラメータで有効化 |
| CALLER grants | 非対応 | 現行の対応対象外 |
通常のGRANTとGRANT OWNERSHIPはGAとして利用できます。
一方で、DCM Projectsが管理するのは、DCM Projects経由で定義・デプロイしたGrantです。
手動実行や別ツールで付与したGrantは共存し、DCM Projectsが把握していないGrantを勝手に削除することはありません。
ただし、GRANT OWNERSHIPには既存Grantに関する追加の制約があります。DCM ProjectsではCOPY CURRENT GRANTSとREVOKE CURRENT GRANTSを利用できないため、対象オブジェクトに既存Grantがある場合、既存Grantを含む必要なGrantを同じDCM projectに定義するか、事前にDCM Projects外で取り消す必要があります。対応しない場合、PLANまたはDEPLOYが失敗します。
また、GRANT OWNERSHIPを利用する場合は、後続のDeployでもDCM project ownerが対象オブジェクトを管理できるよう、所有権の移転先RoleをDCM project ownerのRole階層に含めておく必要があります。DCM project ownerが移転先Roleを保持していない場合、PLANまたはDEPLOYはロックアウトを防ぐため、変更を行う前に失敗します。
この仕様の詳細は、以下の公式Docの「OWNERSHIP grants」章もご覧ください。
Attachment：関連付けできるもの
| 機能 | ステータス | 補足 |
|---|---|---|
ATTACH DATA METRIC FUNCTION |
GA | Table / View / Dynamic TableへDMFを関連付け。対象側にDATA_METRIC_SCHEDULEの設定が必要（ViewではTRIGGER_ON_CHANGESは利用不可） |
ATTACH TAG |
Preview | Database、Schema、Table、Dynamic Table、Function、Procedure、Stage、Task、Role、Database Role、Warehouseへ付与可能 |
ViewへのATTACH TAG |
未対応 | Tagの対象からViewは除外 |
テーブル個別カラムへのATTACH TAG |
未対応 | オブジェクト単位のみ |
| Masking Policyのアタッチ | 未対応 | Table / View列への付与はDCM外で実施 |
| Row Access Policyのアタッチ | 未対応 | Table / Viewへの付与はDCM外で実施 |
ここは少し注意が必要です。
TagはDEFINE TAGで定義できますが、TagをTableなどのオブジェクトに付与するATTACH TAGはPreviewです。また、現時点では、Viewやテーブル・View・Dynamic Tableの個別カラムへのタグ付与はサポートされていません。
また、Masking PolicyとRow Access Policyはポリシー自体を定義できても、対象のTableやViewへアタッチする操作はDCM Projectsではまだサポートされていません。
つまり、「ポリシーを作れること」と「ポリシーを実際に適用できること」は別の対応状況です。
ATTACH DATA METRIC FUNCTIONはサポートされています。ATTACH TAGはPreviewであり、Masking PolicyおよびRow Access Policyを対象オブジェクトへアタッチすることは未対応です。
GA後でもDCM Projectsで定義できない代表的なオブジェクト
DCM ProjectsはGAになりましたが、SnowflakeのすべてのオブジェクトをDEFINEで管理できるわけではありません。
公式ドキュメントには、DCM ProjectsがサポートするEntity、Grant、Attachmentが列挙されています。したがって、以下のようにその対応一覧に含まれていないオブジェクトは、2026年8月8日時点ではDCM Projectsの定義対象外として扱う必要があります。
特に、認証・アカウント設定・Snowpark Container Services・Native Appsに関わるオブジェクトは、別のSQLスクリプト、Terraformなどの外部IaC、または管理手順で補完する前提で設計するのがよさそうです。
DCM Projectsの公式ドキュメントは、現在サポートされるEntity、Grant、Attachmentを列挙しています。以下の一覧は、その対応対象に含まれない代表例です。
代表的な未対応オブジェクト
| 分類 | DCM Projectsで定義できない代表例 | 実務上の影響・補完方法 |
|---|---|---|
| 外部ストレージ連携 | Storage Integration | External Stageから参照するIntegrationは、別途作成・管理が必要 |
| 外部サービス・通知連携 | Notification Integration、API Integration、External Access Integration | 通知、外部API呼び出し、外部ネットワークアクセスはDCM外の管理が必要 |
| 認証・ID連携 | Security Integration | SSO、OAuth、SCIMなどの設定は別管理が必要 |
| ユーザー管理 | User | RoleはDCMで管理できるが、Userライフサイクルは別管理 |
| コスト管理 | Resource Monitor | クレジット利用の上限・通知は別のSQLやIaCで管理 |
| テーブル系の一部 | External Table、Iceberg Table、Materialized View、Hybrid Table、Event Table | DEFINE TABLEで管理できる通常Tableとは分けて考える必要がある |
| Snowpark Container Services | Compute Pool、Service、Image Repository | コンテナ実行基盤はDCMとは別のデプロイ経路が必要 |
| Snowflake Native Apps | Application、Application Package、Application Role | Application Roleは公式にも明示的に未対応と記載 |
| 権限付与の一部 | CALLER grants | Grant種別としてサポート対象外 |
| その他のアカウント設定 | Account Parameterなどのアカウントレベル設定 | ALTER ACCOUNTなど、DCM外の管理手段を検討する |
DCM Projectsで定義できるが、DCM Projects外の設定も必要となるオブジェクト
DCM Projectsで多くのオブジェクトを定義できるようになりましたが、実運用上DCM Projects外の設定も必要となるオブジェクトも多くありますので、参考までに記載しておきます。
| 対象 | DCM Projectsでできること | DCM外で必要なこと |
|---|---|---|
| External Stage | Stage定義 | Storage Integrationの作成・クラウド側の権限設定 |
| Pipe | Pipe定義（Preview） | AUTO_INGEST = TRUE時のクラウドイベント通知 |
| Network Policy | Policy定義 | Account / User / Security Integrationへの割り当て |
| Share | ShareおよびGrant定義 | Consumer Accountの追加 |
| Python / Java Function / Procedure | Function / Procedure定義 | IMPORTSで使うファイルのStageへのアップロード |
| Masking Policy | Policy定義（Preview） | Table / View列へのアタッチ |
| Row Access Policy | Policy定義（Preview） | Table / Viewへのアタッチ |
| Tag | Tag定義 | ATTACH TAGはPreview、対象もオブジェクト単位に限定 |
GA後も押さえたい制約・運用上の注意点
DEFINEはCREATE OR ALTERの制約を受ける
DCM ProjectsのDEFINEは、対応するSnowflakeオブジェクトのCREATE OR ALTERとして実行されます。
そのため、DCM Projectsで管理対象になっているオブジェクトであっても、すべての属性を自由に変更できるわけではありません。
特にTableでは以下の変更・設定に制約があります。
- 列順の変更
- 互換性のない列型変更
- Search Optimizationの追加
- Tableや列へのTag・Policy追加
- 仮想列の定義
また、Pipe・Streamは作成後にCOMMENT以外を変更できません。構成を変えたい場合は、実質的にオブジェクトの作り直しが必要になる点に注意が必要です。
Tableでは上記のような変更・設定に制約があり、DEFINEは対応するCREATE OR ALTERの制限を受けます。Pipe・StreamはCOMMENT以外が作成後不変です。
プロジェクトサイズには上限がある
DCM Projectsのプロジェクトサイズには上限があります。
- 1プロジェクトあたり、Entity・Grant・Attachmentが最大10,000件
/sources配下が最大10,000ファイル- ソースファイル群およびレンダリング済み定義ファイル群には、それぞれ10MBのサイズ上限がある
大規模な環境をまとめて1つのDCM projectで管理しようとすると、この上限に抵触する可能性があります。プロジェクトをどの単位で分割するかを検討する際の判断材料にしておくとよさそうです。
DCM Projectsのプロジェクトサイズには、Entity・Grant・Attachmentの合計で最大10,000件、/sources配下で最大10,000ファイル、ソースファイル群・レンダリング済み定義ファイル群それぞれに10MBのサイズ上限があります。
最後に
Snowflake DCM Projectsが、2026年8月7日にGAとなりましたので、Preview時との差分を整理してみました。
File FormatやExternal Stage、Sequence、Shareなど、対応オブジェクトが着実に広がっている一方で、Storage IntegrationやポリシーのAttachのように、GA後も対応対象に含まれないものがあることに注意が必要だと感じました。
いずれにせよSnowflakeのリソースをIaCで管理するには最も手早く簡単な機能となりますので、とても便利な機能であることに間違いはありません。ぜひ活用していきましょう！
