Snowflakeは2026年9月4日、移行支援エージェントのSnowflake AIM Agent for Data Warehousesで、SASからの移行をプレビュー公開した[1]。SASのコード資産の評価、SASプログラムからSnowflake SQLへの変換、SAS独自のデータセットファイル（.sas7bdat）のテーブルへの取り込みを、自然言語の指示で進められる[2]。ただし、SQL ServerやAmazon Redshiftからの移行で使える文法ベースの変換、データ移行後の検証フレームワーク、テストフレームワークは、SASでは現時点で使えない[2][3]。SASの変換はAIだけが担う。
SASの計算結果を監査や当局対応の説明に使ってきた企業にとって、移行の費用はコードの書き換えと、書き換え後も同じ結果が出ることの確認に分かれる。今回のプレビューが軽くするのは主に前者で、後者の多くは利用者側に残る。SASの年次更新を続けるか移行するかを見積もるには、この二つを分けて数える必要がある。
予備知識
- SAS: SAS Institute製の統計解析・データ分析ソフトウェア。独自のSAS言語でデータ処理や集計を書く。
- .sas7bdat: SASが使うデータセットのファイル形式。Snowflakeで扱うには、テーブルへの取り込みが要る。
- Snowflake CoCo（Cortex Code）: Snowflakeに組み込まれたAIのコーディングエージェント。SAS移行を担うAIM Agent for Data Warehousesは、このCLI版に同梱されている[3]。
- 文法ベース（決定論的）の変換: 構文の規則に沿ってコードを置き換える方式。同じ入力からは同じ出力が得られる。AIによる変換と対比される。
Snowflakeの導入と操作、権限管理とガバナンス、ETLやBIとの連携を章立てで扱う（2024年3月刊）。AIMやSAS移行機能より前に出た本なので、移行先となるSnowflakeの基本を押さえる用途に向く。
何が発表されたか——SAS移行に対応したAIM Agent
リリースノートとSAS移行のドキュメントによると、SAS移行はSnowflake AIM Agent for Data Warehousesの一機能として提供される[1][2]。ドキュメントが挙げる対応範囲は次の三つだ[2]。
- 評価: SASのコード全体を解析し、複雑度、量、プログラム間の依存関係をまとめたレポートを出す
- コード変換: SASプログラムをSnowflake SQLに変換する。変換後のロジックが想定どおりに動くかを確かめる検証ステップが付く
- データセットの取り込み: .sas7bdatファイルをSnowflakeのテーブルに読み込む
操作はエージェントへの自然言語の指示で行う。エージェントは対象がSASプログラムかSASデータセットかを判別し、次の手順を案内する[2]。
プレビューの区分はOpenで、すべてのアカウントが対象になっている[2]。自社のSASコードの一部を対象に、変換の出来を自社で評価できる段階にある。一般提供（GA）の時期は公表されていない。
データ移行の要件定義から設計、テスト、リハーサル、本番移行までを章立てで扱う（2017年刊）。SASに限らない一般のシステム導入を前提にした本で、移行前後の突合やリハーサルの段取りを自社で組むときの材料になる。
Snowflake AIMとは何か
Snowflake AIMは、Snowflakeが2026年6月に発表した移行・モダナイゼーションのためのAIプラットフォームだ。発表ブログによれば、SnowConvert AI、Snowpark Migration Accelerator、Datometryという既存の3製品の機能をまとめ、その上に構築した[4]。
経路は二つある。一つはモダナイズで、データベース、ETLパイプライン、Apache Sparkのワークロード、API、ストアドプロシージャ、レポーティング資産、BI基盤を対象に、評価、コード変換、依存関係の分析、テスト、検証、移行を自動化する[4]。もう一つは仮想化で、既存のワークロードをSQLの大幅な書き換えなしにSnowflake上で動かす。仮想化の対象は、発表時点でTeradataだ[4]。
発表時点の図の対応ソースに、SASは入っていない。SASは2026年9月、データウェアハウス移行を担うAIM Agent for Data Warehousesの移行元として加わった[2][3]。
数百人規模の情報システム部門でSnowflake（クラウド型データウェアハウスサービス）の運用とコスト管理を担うFinOps担当者にとって、月次のクレジット消費予算が読めなくなる変更が今年すでに恒久適用されている。Snowflakeは動作[…]
他の移行元と何が違うか——変換はAIのみ、突合は自前
AIM Agent for Data Warehousesは、SQL ServerやAmazon Redshiftからの移行では、SnowConvertが文法ベースで変換したコードを出発点にし、残った問題をAIが補正する[3]。移行後は、スキーマ・指標・行（任意）を移行元と比べるデータ検証と、移行元の出力を基準に関数やプロシージャを試す両側テストが動く[3]。SAS移行のドキュメントは、これらがSASでは現時点で含まれないと明記している[2]。
| 機能 | SQL Server・Amazon Redshift | SAS（プレビュー） |
|---|---|---|
| コード変換 | SnowConvertの文法ベース変換のあと、AIが残課題を補正[3] | AIのみ。文法ベースの変換はない[2] |
| 変換後の確認 | 移行元の出力を基準にした両側テスト[3] | 変換時の検証ステップのみ。テストフレームワークとは連携しない[2] |
| データの移行と突合 | 行のコピーと行数の自動照合、スキーマ・指標・行の比較[3] | .sas7bdatの取り込みのみ。データ移行・検証フレームワークとは連携しない[2] |
| Power BIレポートの向け替え | 対応[3] | 対応しない[2] |
Snowflakeは発表ブログで、文法ベースの変換を土台にすることで一貫性と再現性が得られると説明している[4]。SASではこの土台がなく、変換結果の妥当性は移行前後の出力を突き合わせて示すことになる。その突合を支えるフレームワークも、SASでは使えない。移行の見積もりには、突合の設計と実行の工数を自社側の費用として積む必要がある。
Snowflakeでマネージド型データウェアハウス（DWH）を運用し、内部監査でSLA遵守状況の説明を求められるデータ基盤担当者が本稿の対象読者だ。数百〜数千人規模の情報システム部門で、保守運用をSIerに委託し、障害時の一次対応をベンダ[…]
なぜ今SAS移行が問われるのか——ライセンス構造という背景
SASのWebストアのFAQは、オンラインで買える入門パッケージのSAS Analytics ProとSAS Visual Data Discoveryについて、ライセンスは年単位で、2年目以降の料金はその時点の初年度料金のおよそ28%と説明している[5]。これはWebストアで販売する2製品の条件で、企業向けの個別契約の条件は公開情報では確認できなかった。数千人規模の企業契約に28%をそのまま当てはめることはできない。
それでも、年単位のライセンスである以上、更新のたびに、払い続ける費用と移行にかかる費用を比べる機会が来る。AIによる変換が使えるようになると、移行費用のうちコードの書き換え部分は小さく見積もれる可能性がある。一方で、前節の突合の工数は変わらない。更新料と比べるべき移行費用は、変換、突合、並行運用の合計になる。
移行を判断する上でのアーキ選択肢
判断の軸は三つある。第一に、SASコードのうちAI変換で扱える範囲。評価レポートの複雑度と依存関係が、その見積もりの材料になる。第二に、移行期間中にSASとSnowflakeを並行運用するコスト。第三に、監査での説明実績を移行後も維持できるか。SASではテストと検証の仕組みを自前で用意するため、第三の軸の比重が他の移行元より大きくなる。
| 選択肢 | 向いているケース | 留意点 |
|---|---|---|
| SASのライセンス維持 | 変更頻度が低く、監査実績が確立している基盤 | 年次の更新料が固定費として続く |
| 段階移行（優先度の高い処理から） | SASコードの量が多く、リスクを分散したい場合 | 並行運用期間のコストと運用負荷が発生する |
| AI支援による一括移行 | 移行対象の範囲が明確で、期限（契約更新時期など）が迫っている場合 | SASではテスト・検証フレームワークが使えず、突合の仕組みを自前で用意する[2] |
日本の金融・保険会社が試す前に確認すること
金融機関であれば金融商品取引法や銀行法に基づく内部統制、保険会社であれば保険業法に基づく規制対応の中で、SASでの計算過程を監査上の説明に使ってきた企業では、移行後にその説明を作り直すことになる。SAS移行には突合の仕組みが用意されていないため、作り直しは自社の作業になる。
もう一つの確認事項は、AIの推論をどこで処理させるかだ。SAS移行はCoCo上で動き、CoCoのCLIはcross-region inference（推論をアカウントのリージョン以外でも処理する設定）を有効にしたアカウントで使える[3][6]。設定はアカウント単位のパラメーターCORTEX_ENABLED_CROSS_REGIONで、変更できるのはACCOUNTADMINロールだけだ[7]。処理先のリージョンにデータは保存されず、プロンプトと応答が処理の間だけ送られる[7]。SASのコードをAIに読ませる以上、そのコードが送られる範囲をこの設定で決めることになる。
日本向けには、推論を東京・大阪のAWSリージョン内で処理するAWS_JPが用意されている[8]。未設定のアカウントに同じクラウド内の既定値を入れる変更（2026_06 bundleのBCR-2376）は、リージョンと業種で扱いが分かれる[9]。
| アカウント | BCR-2376で入る既定値 | 未設定のアカウントでCoCo（SAS移行）を使うには |
|---|---|---|
| AWS 東京（ap-northeast-1）・大阪（ap-northeast-3） | AWS_JP（推論は東京・大阪で処理） | この既定値のまま使える |
| Azure 東日本（japaneast） | 変更なし | CORTEX_ENABLED_CROSS_REGIONの設定が必要 |
| 金融・医療・政府系などのアカウント | この変更の対象外 | CORTEX_ENABLED_CROSS_REGIONの設定が必要 |
ただし、2026年3月9日以降に作成した新しい組織のアカウントは、未設定でもANY_REGIONが既定になり、推論は日本国外や他のクラウドでも処理されうる[7][8]。
既定値の反映は週単位で順次行われるため、自社アカウントの値は SHOW PARAMETERS LIKE 'CORTEX_ENABLED_CROSS_REGION' IN ACCOUNT で確かめるのが確実だ[7][9]。また、AWS_JPの範囲で使えるモデルは限られる。Cortex AI Functionsの対応表では、AWS_JPで使えるClaudeモデルはSonnet 4.6、Sonnet 4.5、Haiku 4.5と旧版扱いのClaude Sonnet 4で、Opus系、Sonnet 5、OpenAI系のモデルは含まれない[10]。国内で処理を完結させるか、使えるモデルの幅を取るかは、情報管理の担当と決める事項になる。
まとめ
SASからSnowflakeへの移行プレビューは、SASプログラムの評価と変換をAIに任せる道を開いたが、移行前後の結果を突き合わせる仕組みは含んでいない。変換の工数が下がっても、監査で説明するための突合の工数は残る。
次の行動は三つある。自社のSASコードで評価レポートを出し、変換対象の量と依存関係をつかむこと。監査の説明に使っている計算処理を数本選び、SAS側とSnowflake側の出力を突き合わせる手順を試作して、その工数を測ること。金融機関のアカウントなら、試す前にCORTEX_ENABLED_CROSS_REGIONをどの値にするかを情報管理の担当と決めること。突合の工数が見えれば、SASの更新料と比べる移行費用の欄が埋まる。
よくある質問（FAQ）
Q. SAS to Snowflakeマイグレーションはすでに本番で使えますか。
A. 2026年9月時点ではプレビューで、一般提供の時期は公表されていない[1][2]。
Q. SASのコードはすべて自動変換できますか。
A. 変換はAIのみで行われ、文法ベースの変換は含まれない[2]。どのSASの構文やプロシージャまで変換できるかは、ドキュメントでは示されていない。変換時の検証ステップはあるが、テストフレームワークやデータ移行・検証フレームワークとは連携しないため、移行前後の出力の突合は利用者側で設計する[2]。
Q. 東京・大阪リージョンのアカウントで使えますか。
A. プレビューはすべてのアカウントが対象だが、動かすにはCoCoが使える状態、つまりcross-region inferenceの有効化が前提になる[2][6]。AWSの東京・大阪では、推論を国内の2リージョンで処理するAWS_JPを選べる[8]。金融業のアカウント（2026年3月9日以降に作成した新しい組織のアカウントを除く）は既定値の自動設定の対象外で、未設定ならACCOUNTADMINによる設定が要る[7][9]。
