Koharu Tech Notes

Next.jsPythonクラウドセキュリティRubyCpp

Article

クラウドAWSAmazon Sagemaker CanvasSnowflakeNo Code Ml
2026-08-27

Snowflake×SageMaker CanvasのノーコードML、接続前の環境準備を整理

AWSが、SnowflakeのデータをAmazon SageMaker Canvasで扱い、Amazon Quickへつなぐ3部構成のノーコードML手順を公開しました。Part 1のSnowflake環境構築を軸に、接続前にそろえるデータ、識別子、権限、コスト設定を整理します。

Share

こはるの読みどころ

ノーコードになるのは主にデータ準備とモデル構築の操作だよ。既存のSnowflake環境で試すなら、SQLを流す前にオブジェクト名と実行ロールを見直しておきたいね。

こはるの読みどころ

2026年8月20日、AWSはSnowflake、Amazon SageMaker Canvas、Amazon QuickをつなぐノーコードMLワークフローの連載を公開しました。Part 1で扱うのはモデル構築ではなく、その前段にあるSnowflake環境の準備です。

『ノーコードなら、データ基盤側の作業もほとんど要らないのでは』と思うかもしれません。ところが、画面操作でモデルを作れることと、どのデータへ誰が接続できるかを設計することは別の話です。

Part 1が何を準備し、既存環境へ持ち込むときに何を変えるべきか。サンプルを動かすところから実運用を考え始めるところまで、境界を順に見ていきます。

ノーコード化されるのはモデル構築で、データ基盤の準備ではない

Amazon SageMaker Canvasは、データの準備、モデルの構築・評価、予測とデプロイを視覚的に進めるサービスです。2021年11月30日の一般提供開始時点からSnowflakeをデータソースとして扱えました。

その後、2023年9月にはSnowflakeから中間ストレージを介さずに取り込む機能とOAuth 2.0接続が追加されました。現在のCanvasは、Snowflakeのテーブルを選び、SQLや結合で取り込み範囲を整えてから、視覚的なデータ準備とモデル構築へ進めます。

つまり、省けるのはアルゴリズム選択や学習コードを手で組み立てる作業の多くです。一方、Snowflakeのウェアハウス、データベース、テーブル、接続用ID、認証情報は先に用意する必要があります。Part 1はこの境界を受け持っています。

Part 1のSQLはCanvas接続前に4つの状態をそろえる

手順ではSnowflakeのSQLワークシートを開き、ACCOUNTADMINロールで次のリソースを作ります。

  • HOL_WHというX-Smallの仮想ウェアハウス
  • FRAUDデータベース
  • FRAUD.PUBLIC.FRAUD_TABLEテーブル
  • 2020年の取引を模した139,538件の合成データ

テーブルには取引日時、金額、加盟店カテゴリ、カード番号、地域、is_fraudラベルなどが入ります。ラベルはSQL内の金額・時間帯・カテゴリ条件と乱数から生成されるため、これは接続と学習フローを試すための教材です。実データに対する精度や不正検知ルールの妥当性を示すものではありません。

投入後は、件数、先頭10行、ラベル別の件数を確認します。ここで見るべきなのは『SQLが成功した』だけではなく、Canvasへ渡したい表が想定したスキーマと分布で作られたかです。

SQL
SELECT COUNT(*) AS total_records FROM FRAUD_TABLE;
SELECT TOP 10 * FROM FRAUD_TABLE;
SELECT is_fraud, COUNT(*) AS count
FROM FRAUD_TABLE
GROUP BY is_fraud;

合成データは実行ごとに乱数結果が変わり得ます。ラベル別件数が固定値になる前提を置かず、実行した環境の結果を記録しておくと、Part 2のモデル評価を読み違えにくくなります。

Snowflakeのアカウント識別子がCanvasとの接点になる

Part 1の最後では、組織名とアカウント名をハイフンで連結した値を取得します。Snowflakeでも、organization_name-account_name形式がクライアントや外部ツール向けの推奨アカウント識別子です。

この値は、続くCanvasのSnowflake接続でAccount IDとして使います。現在のCanvas接続ドキュメントでは、ユーザー名とパスワード、AWS Secrets ManagerのシークレットARN、OAuthの3方式が案内されています。連載のPart 2はユーザー名とパスワードを使いますが、それが唯一の接続方法というわけではありません。

検証環境ならチュートリアルどおり進める選択もできます。組織の環境では、既存のSSO、シークレット管理、認証情報のローテーション方針に合わせて方式を決めたいところです。OAuthを使う場合はCanvas側の初期設定も必要になるため、Part 1のSQLだけでは準備完了になりません。

既存のSnowflakeでは置換、権限、停止設定を先に見直す

サンプルSQLのCREATE OR REPLACE DATABASE FRAUDは、同名データベースがあれば置き換えます。Snowflakeの仕様では、OR REPLACEは既存データベースをDROPして同名で作り直す操作に相当します。共有環境では専用名へ変えるか、同名オブジェクトがないことを確認してから実行する必要があります。

また、チュートリアルは簡潔さのためACCOUNTADMINを使いますが、SnowflakeはACCOUNTADMINで通常のデータベースオブジェクトを作らず、業務に合うカスタムロールを使うことを推奨しています。Canvas接続用ロールには、少なくとも対象ウェアハウス、データベース、スキーマを利用する権限と、対象テーブルを読む権限が必要です。必要な範囲だけを付与すれば、ノーコード利用者へ管理者権限を渡さずに済みます。

HOL_WHはX-Smallでも、稼働中はSnowflakeクレジットを消費します。CREATE WAREHOUSEの現在の既定値では、10分間操作がなければ自動停止し、クエリが来ると自動再開します。組織のコスト方針に合うかを確認し、検証終了後はウェアハウスとサンプルデータの残し方も決めておきたいですね。

SageMakerドメインとQuick Sightまで含めて一つの経路になる

Snowflakeの準備が終わっても、まだモデルはありません。Canvasを使うにはSageMakerドメインとユーザープロファイルが必要で、現在のセットアップ手順では、アプリを起動する権限とCanvas Core Accessが基本要件です。高度なデータ準備やモデルの直接デプロイには、それぞれ追加の権限設定があります。

連載では、Part 2でSnowflakeへ接続し、Data Wranglerの視覚的な変換を使ってデータを整え、不正検知モデルを構築します。Part 3ではバッチ予測をAmazon S3へ出力し、Quick Sightでダッシュボードにします。

現在の製品体系では、Quick SightはAmazon Quickに含まれるBI機能です。タイトルのAmazon Quickと、ダッシュボードを作るQuick Sightは競合する別経路ではなく、後者が可視化を担う関係だと捉えると分かりやすいですね。

データはSnowflake、Canvasの成果物やバッチ予測はS3、可視化はQuick Sightへと役割が分かれます。ノーコードでも、データがどこへ複製され、どのIAMロールが触れ、学習やエンドポイントにどのコストが生じるかは設計対象のままです。

Part 1の完了は「モデル完成」ではなく「接続契約の準備完了」

冒頭の問いへ戻ると、ノーコードMLはデータ基盤の準備を消すものではありません。Part 1で得られるのは、学習用テーブル、計算用ウェアハウス、接続先を示すアカウント識別子という、Canvasへデータを渡すための契約です。

個人の検証環境なら、オブジェクト名の衝突がないことと自動停止を見てからサンプルを動かせます。共有・本番環境へ広げるなら、専用のカスタムロール、組織に合う認証方式、Canvas用S3ストレージとIAM権限を先に設計するのが実務的です。

ここまで切り分ければ、『ノーコードだから準備不要』でも『基盤が複雑だから試せない』でもありません。SnowflakeとCanvasの境界を小さく安全に作り、合成データで一周させてから実データのガバナンスとモデル評価へ進むのが、このPart 1を活かす進め方です。

出典

Share

Related Articles

カテゴリやタグが近い記事を続けて読めるように並べています。