[新機能] ALTER ACCOUNT SET EDITIONが一般提供になったのでSQLでアカウントのエディションを変更してみた

かわばたです。

2026年5月6日にALTER ACCOUNT SET EDITIONが一般提供（GA）となりました。

これまでアカウントのエディション変更はSnowflakeサポートへの問い合わせが必要でしたが、この機能により組織管理者がSQLコマンドで直接エディションを変更できるようになります。

https://docs.snowflake.com/en/user-guide/organizations-manage-accounts-editions

実際にアップグレード・ダウングレードの両方を試してみたので、手順と確認結果をまとめます。

機能概要

ALTER ACCOUNT SET EDITIONは、ORGADMINロールを持つ組織管理者が、SQLコマンドでSnowflakeアカウントのエディションを変更できる機能です。

構文は以下のとおりです。

ALTER ACCOUNT <アカウント名> SET EDITION = { 'STANDARD' | 'ENTERPRISE' | 'BUSINESS_CRITICAL' }

変更は即座に反映されます。なお、操作対象のアカウントとは別のアカウントからコマンドを実行する必要があります。

制限事項

• 変更対象のアカウントとは異なるアカウントからコマンドを実行する必要があります
• ORGADMINロールが必要です
• ダウングレード時は、対象エディションで利用できない機能（マスキングポリシーなど）を事前に削除する必要があります
• エディション変更を行った同日中にダウングレードすることはできません（翌日以降に実行する必要があります）
• マネージドアカウント・リーダーアカウントでは使用できません（Snowflake Supportへの連絡が必要です）
• VPS EditionへのアップグレードはSnowflake Supportへの連絡が必要です
• DoD・中国のデプロイメントでは利用できません

前提条件

• Snowflake: 同一Organization内に2つ以上のアカウントが必要
• 本機能のステータス: 2026年5月6日にGA
• 必要な権限: ORGADMINロール
• 検証環境: AWSリージョン
• 変更対象アカウントのエディション: Standard（検証開始時点）

事前準備

ORGADMINロールの確認とアカウント一覧の取得

操作元のアカウント（変更対象とは別のアカウント）にログインし、ORGADMINロールを使用してOrganization内のアカウント一覧を確認します。

-- ORGADMINロールに切り替え
USE ROLE ORGADMIN;

-- Organization内のアカウント一覧を確認
SHOW ACCOUNTS;

アカウント一覧が表示されればOKです。

edition列で現在のエディション（ここではSTANDARD）が確認できればOKです。

試してみた

エディションのアップグレード（STANDARD → ENTERPRISE）

操作元アカウントからORGADMINロールで、対象アカウントのエディションをSTANDARDからENTERPRISEに変更します。

USE ROLE ORGADMIN;

-- STANDARDからENTERPRISEにアップグレード
ALTER ACCOUNT <対象アカウント名> SET EDITION = 'ENTERPRISE';

変更後にアカウント情報を確認します。

-- エディションが変更されたことを確認
SHOW ACCOUNTS LIKE '<対象アカウント名>';

edition列がENTERPRISEに変更されていればOKです。
今回の検証では、変更後すぐに SHOW ACCOUNTS の edition 列へ反映されることを確認できました。

Enterprise機能の利用確認（マスキングポリシーの作成）

エディション変更が本当に反映されているかを確認するため、対象アカウントにログインしてEnterprise以上で利用可能なマスキングポリシーを作成してみます。

-- 対象アカウントにログインして実行
USE ROLE SYSADMIN;
USE DATABASE <データベース名>;
USE SCHEMA <スキーマ名>;

-- Enterpriseエディションで利用可能なマスキングポリシーを作成
CREATE OR REPLACE MASKING POLICY test_mask AS (val STRING) RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() IN ('SYSADMIN') THEN val
    ELSE '***MASKED***'
  END;

-- 既存テーブルの列にマスキングポリシーを適用
ALTER TABLE IF EXISTS <テーブル名> MODIFY COLUMN <カラム名> SET MASKING POLICY test_mask;

マスキングポリシーが正常に作成できればOKです。Enterpriseエディションの機能が利用可能であることを確認できました。

同日中のダウングレード制限を確認

ドキュメントに記載のある「エディション変更を行った同日中にはダウングレードできない」という制限を確認します。アップグレードと同日中に、操作元アカウントからダウングレードを試みます。

-- 操作元アカウントから実行（アップグレードと同日に実施）
USE ROLE ORGADMIN;

-- 同日中のダウングレードを試みる
ALTER ACCOUNT <対象アカウント名> SET EDITION = 'STANDARD';

同日中にダウングレードを行おうとするとエラーが返されることを確認します。

想定通り、同日中のダウングレードはできませんでした。

上位エディション機能が残った状態でのダウングレード確認（翌日）

翌日に改めて検証を行います。手順2で作成したマスキングポリシーが残った状態で、ダウングレードを試みます。

-- 翌日以降に操作元アカウントから実行
USE ROLE ORGADMIN;

-- マスキングポリシーが残った状態でSTANDARDへダウングレードを試みる
ALTER ACCOUNT <対象アカウント名> SET EDITION = 'STANDARD';

上位エディションの機能（マスキングポリシー）が残っている状態では、ダウングレードがエラーになることが確認できました。

上位エディション機能を削除してからダウングレード

ダウングレードを成功させるため、対象アカウントで列に適用していたマスキングポリシーを解除し、その後マスキングポリシーを削除してから再度ダウングレードを実行します。

まず、対象アカウントでマスキングポリシーを削除します。

-- 対象アカウントにログインして実行
USE ROLE SYSADMIN;
USE DATABASE <データベース名>;
USE SCHEMA <スキーマ名>;

-- まず列からマスキングポリシーを解除
ALTER TABLE IF EXISTS <テーブル名>
  MODIFY COLUMN <カラム名> UNSET MASKING POLICY;

-- マスキングポリシーを削除
DROP MASKING POLICY test_mask;

続いて、操作元アカウントからダウングレードを実行します。

-- 操作元アカウントから実行
USE ROLE ORGADMIN;

-- STANDARDへダウングレード
ALTER ACCOUNT <対象アカウント名> SET EDITION = 'STANDARD';

変更後にアカウント情報を確認します。

-- エディションが戻っていることを確認
SHOW ACCOUNTS LIKE '<対象アカウント名>';

edition列がSTANDARDに戻っていればOKです。

最後に

ALTER ACCOUNT SET EDITIONを試して、SQLコマンドだけでアカウントのエディション変更ができることを確認できました。

アップグレードは今回の検証環境ではすぐに反映されました。一方、ダウングレードには以下の条件があるため計画的に行う必要があります。

• エディション変更と同日中にはダウングレードできない
• 上位エディション固有の機能（マスキングポリシーなど）を事前に削除する必要がある

マルチアカウント運用をしている組織では、エディション管理のSQL化・自動化にも活用できそうです。気になった方はぜひ試してみてください。

この記事が何かの参考になれば幸いです！