生成AI・ML基盤

SageMaker Canvasをチームに導入して6ヶ月、正直しんどかった話と意外な発見

「どうせデモ映えするだけ」と思ってたノーコードML、実際に営業チームに展開してみたら良い意味で裏切られた。ハマった罠と使える場面を6ヶ月の実録で。

SageMaker CanvasノーコードMLAWSAutoML生成AI

ビジネスチームがMLモデルを自分で作り始めた日

正直、最初は半信半疑だった。「ノーコードでMLモデルが作れます」という触れ込みを聞いて、「どうせデモ映えするだけで実務じゃ使い物にならないだろう」と思ってた。それが6ヶ月前の自分。

きっかけは、営業企画チームからの依頼だった。「顧客の解約予測をもっと細かくやりたいけど、毎回データサイエンスチームを頼むのが大変で…」という相談を受けて、試しにSageMaker Canvasを触らせてみることにした。結果、モデルを一度も自力で作ったことがない人が、2日でそれなりに動く解約予測モデルを作ってきた。そのときの衝撃は今でも覚えてる。

今回はその後6ヶ月間、実際にチームに展開して運用してわかったことを整理したい。良い面も、ハマった罠も、率直に書く。

SageMaker Canvas 2026年の現在地

2026年時点のCanvasは、2023〜2024年頃のものとは別物に近い。大きく変わったのは主にこの3点だ。

Bedrock統合の深化
Foundation Modelを使った生成AI系タスク（テキスト分類、要約、センチメント分析）が、Canvasのインターフェースからほぼシームレスに使えるようになった。以前はAutoML（tabular系）がメインだったが、今はLLMベースのタスクと組み合わせて使うワークフローが増えている。

MLflow対応の強化
Canvasで作ったモデルのメタデータをMLflow形式で管理できるようになり、SageMaker Pipelinesとの連携が格段にやりやすくなった（SageMaker Pipelines ML CI/CD 2026の記事で書いたパイプラインとの組み合わせが実用的になってきた感じ）。

時系列予測の精度向上
AutoML for Time Seriesが改善されて、在庫予測や需要予測で使える精度になってきた。うちのチームで試したケースだと、Prophet単体よりも良いスコアが出るケースが増えた。

2026年時点のCanvas主要機能比較

機能カテゴリ内容対象ユーザー実用度（主観）
AutoML（表形式）分類・回帰・時系列ビジネスアナリスト★★★★★
Computer Vision画像分類・物体検出一部技術者★★★★☆
NLP（テキスト分類）カスタムデータ学習ビジネスアナリスト★★★★☆
Bedrock FM呼び出しClaude・Titan等ビジネスアナリスト★★★★★
Ready-to-use Models事前学習済みモデルビジネスアナリスト★★★☆☆
MLflow連携実験管理・デプロイデータエンジニア★★★★☆

個人的には、AutoML（表形式）とBedrock連携の組み合わせが今のCanvasの真骨頂だと思っている。Ready-to-use Modelsはまだ微妙で、「用意されてるのはいいけど自分のデータに合わせたいとき途端につらくなる」という感想を持ってる。

精度の推移（うちの解約予測モデルの場合）

週次で再学習させながら24週間回し続けた結果がこれ。最初は「まあこんなもんか」という感じだったけど、じわじわ上がってきた。

xychart-beta
  title "解約予測モデル AUC推移（ビジネスチーム自力運用）"
  x-axis [Week1, Week2, Week3, Week4, Week8, Week12, Week24]
  y-axis "AUC" 0.5 --> 1.0
  line [0.71, 0.74, 0.77, 0.79, 0.82, 0.83, 0.84]

24週時点でAUC 0.84は、以前データサイエンスチームが3週間かけて作ったモデルとほぼ同等の数値だった。これは正直驚いた。ビジネスチームが再学習のたびに「この特徴量も加えてみよう」と試行錯誤を続けた積み重ねが効いたんだと思う。

実際に動かしてみた：セットアップから最初のモデルまで

AWS構成図

実際に構築したCanvas利用環境のアーキテクチャはこんな感じ。

graph TB
  subgraph "AWS Account（MLプラットフォーム）"
    subgraph "SageMaker Domain"
      CANVAS[SageMaker Canvas<br/>ビジネスユーザー向け]
      STUDIO[SageMaker Studio<br/>データサイエンティスト向け]
      MLFLOW[MLflow Tracking Server]
    end

    subgraph "データソース"
      S3RAW[S3 Raw Data Bucket]
      S3PROC[S3 Processed Bucket]
      GLUE[AWS Glue<br/>ETL・カタログ]
      REDSHIFT[Amazon Redshift<br/>DWH]
    end

    subgraph "モデル管理"
      REGISTRY[SageMaker Model Registry]
      ENDPOINT[SageMaker Endpoint<br/>リアルタイム推論]
      BATCH[Batch Transform Job]
    end

    subgraph "ガバナンス・セキュリティ"
      IAM[IAM Role / Permission Boundary]
      SECRETS[Secrets Manager]
      CW[CloudWatch Logs & Metrics]
    end

    subgraph "Bedrock連携"
      BEDROCK[Amazon Bedrock<br/>Claude 3.7 / Titan]
    end
  end

  subgraph "ユーザー"
    BIZ[ビジネスアナリスト]
    DS[データサイエンティスト]
  end

  BIZ -->|ブラウザアクセス| CANVAS
  DS -->|ブラウザアクセス| STUDIO
  CANVAS -->|データインポート| S3RAW
  CANVAS -->|データインポート| REDSHIFT
  GLUE --> S3PROC
  S3RAW --> GLUE
  S3PROC --> CANVAS
  CANVAS -->|モデル登録| REGISTRY
  REGISTRY --> ENDPOINT
  REGISTRY --> BATCH
  CANVAS -->|MLflow記録| MLFLOW
  STUDIO --> MLFLOW
  CANVAS --> BEDROCK
  IAM --> CANVAS
  IAM --> STUDIO
  CW --> CANVAS
  SECRETS --> CANVAS

ポイントはSageMaker Domainを1つにまとめて、CanvasとStudioを同じドメイン内に共存させること。これでモデルレジストリやS3バケットを共有できるし、Canvasで作ったモデルをStudio側でさらにチューニングするフローが自然に組める。最初に別ドメインで立てようとして後悔した経緯があるので、ここは強調しておきたい。

実際のデータインポートからモデル構築まで

Canvasのデータインポートで地味に便利なのが、Redshiftへの直接接続だ。以前はデータをCSVに吐き出してS3に上げて…という手順が必要だったが、今は接続情報を設定すればCanvasから直接クエリできる。

-- Canvas側で設定するクエリ例（解約予測用の特徴量抽出）
SELECT
  customer_id,
  contract_months,
  monthly_charges,
  total_charges,
  num_support_tickets_90d,
  last_login_days_ago,
  product_tier,
  payment_method,
  churn_label  -- ターゲット変数
FROM analytics.customer_features
WHERE snapshot_date = CURRENT_DATE - INTERVAL '1 day'

このクエリをCanvasに貼り付けて「インポート」を押すだけ。データのプレビューができて、欠損値の割合や分布もUIで確認できる。「ターゲット列の選択」→「AutoMLビルド開始」まで、慣れると10分かからない。

モデル構築が終わると、特徴量の重要度がこんな感じで表示される。

特徴量重要度（Canvasのレポートより）
━━━━━━━━━━━━━━━━━━━━━━━━
num_support_tickets_90d    ████████████  0.31
last_login_days_ago        ██████████    0.26
monthly_charges            ███████       0.18
contract_months            █████         0.13
payment_method             ████          0.08
product_tier               ██            0.04
total_charges              █             0.01
━━━━━━━━━━━━━━━━━━━━━━━━

これをビジネスチームに見せると「あー、サポート問い合わせが多い人が解約しやすいのか」「最終ログインが遠い人は危ない」と自分たちで解釈を始める。この「自分で説明できる」という体験が、Canvasの一番の価値だと思う。モデルの中身をデータサイエンティストに聞かないと説明できない状態だと、現場での活用が進まないんだよね。

6ヶ月運用して見えたハマりポイント

正直に書く。良いことばかりじゃない。

ハマり1：コストが予想外に膨らむ

最初の月、Canvas利用料が想定の3倍になった。原因はCanvasの課金モデルが「セッション時間」ベースだったこと。ビジネスチームのメンバーが「モデルビルド中は待てばいい」と思ってブラウザ開きっぱなしにしてたり、トレーニングジョブを複数並行起動しまくってた。

Canvas自体のセッション料金（2026年時点で約$1.9/時間/ユーザー）に加えて、AutoMLのトレーニングインスタンス費用が乗っかる。使った分だけ請求されるクラウドあるあるだが、GUIツールだと「裏で何が動いてるか」が見えにくいぶん余計に怖い。うちは慌ててCloudWatchでコスト監視を入れて、予算アラートを設定した。

# CloudWatch Budget設定例（Canvasコスト監視）
import boto3

budgets = boto3.client('budgets')

response = budgets.create_budget(
    AccountId='123456789012',
    Budget={
        'BudgetName': 'sagemaker-canvas-monthly',
        'BudgetLimit': {
            'Amount': '50000',  # 50,000円上限
            'Unit': 'JPY'
        },
        'TimeUnit': 'MONTHLY',
        'BudgetType': 'COST',
        'CostFilters': {
            'Service': ['Amazon SageMaker']
        }
    },
    NotificationsWithSubscribers=[
        {
            'Notification': {
                'NotificationType': 'ACTUAL',
                'ComparisonOperator': 'GREATER_THAN',
                'Threshold': 80.0,
                'ThresholdType': 'PERCENTAGE'
            },
            'Subscribers': [
                {'SubscriptionType': 'EMAIL', 'Address': 'ml-team@example.com'}
            ]
        }
    ]
)

データ品質管理2026年版の記事でも触れているが、MLプラットフォームのコスト管理は後回しにすると地獄を見る。Canvasを全社展開する前に、必ずBudgetsアラートを仕込んでおいてほしい。

ハマり2：データ前処理の限界

CanvasのUI上でできるデータ変換は限定的だ。欠損値の補完、型変換、基本的な正規化くらいはできるが、複雑な特徴量エンジニアリング（ウィンドウ集計、ラグ変数の作成など）はCanvasだけでは無理。「ノーコードでなんでもできる」と思い込んで進めると、ここで壁にぶつかる。

うちのチームは結局、Glue + Canvasの組み合わせで運用している。データの前処理・特徴量計算はGlueで行い、整形済みデータをS3に置いてCanvasで読み込む形だ。ビジネスチームはCanvas操作に集中し、データエンジニアが裏でGlueのETLを管理する分業が定着した。

flowchart LR
  A[原始データ<br/>Redshift/S3] --> B[Glue ETL<br/>特徴量エンジニアリング]
  B --> C[S3<br/>整形済みデータ]
  C --> D[SageMaker Canvas<br/>モデル構築・評価]
  D --> E[SageMaker<br/>Model Registry]
  E --> F[推論エンドポイント<br/>or Batch Transform]
  F --> G[ビジネスアプリ<br/>CRM/BI等]

最初はこの分業に抵抗感があったが、むしろ「データを整える人」と「モデルを育てる人」が明確に分かれたことで、お互いの役割が整理された気がしている。

ハマり3：モデルのバージョン管理が属人化する

CanvasはGUIツールなので、「誰がいつどんなデータでモデルを作ったか」が管理しにくい。6ヶ月後に「あのモデルどうなってたっけ？」という問い合わせが来ても、追跡が困難なケースが発生した。Gitのようなバージョン管理に慣れているエンジニアには当たり前の感覚でも、ビジネスチームにとっては「保存した＝完了」になりがちなんだよね。

対策として、Canvas → Model Registry へのモデル登録を必須化して、登録時のコメント欄に「データ期間」「特徴量の変更点」「評価指標」を必ず書くルールにした。地味だけどこれが効いている。MLflowとの連携機能を使うとメタデータの記録がやや楽になるので、今はそちらへ移行中だ。

Bedrock連携で何ができるようになったか

ここが2026年のCanvasの「新しさ」として一番語りたい部分。

テキストデータを含む表形式データの分析タスクで、AutoMLとBedrock FMを組み合わせたワークフローが使えるようになった。例えばこういったシナリオが現実的になってきた。

シナリオ：カスタマーサポートのメール文面 + 数値特徴量で解約リスク予測

  1. Canvasにメール文面テキストと顧客数値データを含むデータセットをインポート
  2. テキスト列に対してBedrock（Claude 3.7 Haiku）でセンチメント分析 + キーワード抽出を実行
  3. その出力を追加特徴量として数値モデルに組み込む
  4. AutoMLで最終モデルを構築

これが全部Canvas上でポチポチやれる。以前なら「テキストの前処理→感情分析→ベクトル化→モデル結合」という複数ステップのPythonコードが必要だったフローが、GUIで完結する。「え、これコードいらないの？」という顔をしたビジネスメンバーを何人か見てきたが、その反応を見るたびにツールの進化を実感する。

ただし正直まだ検証中の部分もあって、Bedrock呼び出しコストが積み重なるのと、大量データでの処理時間が読みにくい。本番適用は慎重に判断したほうがいいかもしれない。

「使うべき場面」と「使わないほうがいい場面」

6ヶ月やってみて、自分なりに使い所が見えてきた。「Canvasがあればデータサイエンティストはいらない」という話では全くなくて、むしろ適材適所がはっきりした感じだ。

Canvasが効く場面

  • 表形式データの分類・回帰・時系列予測（これは本当に強い）
  • 非技術者が主導するユースケース（マーケター、営業企画、経営企画が自力でモデルを動かしたい）
  • プロトタイプを速攻で作って精度の見込みを確認したい（2時間でPoC完成は普通にある）
  • Bedrock FMを使いたいが、コードは書きたくない

素直にSageMaker Studio + Pythonのほうがいい場面

  • カスタムモデルアーキテクチャが必要（Transformerのファインチューニング等）
  • 複雑な特徴量エンジニアリングが前提
  • モデルの推論を細かくコントロールしたい（後処理、閾値調整等）
  • 大規模データ（数億行以上）の処理
  • 再現性・バージョン管理を厳密に求められる本番システム

皆さんのチームではデータサイエンティストとビジネスチームの分業ってどうしてますか？ Canvas導入前は「MLモデル = データサイエンティストが作るもの」という前提が固定してたんですが、Canvasを入れてからその境界が曖昧になってきた感じがある。これは良い変化だと思っているし、AIエージェント開発で痛い目を見た話でも書いたけど、AIツールが「誰でも使えるもの」になっていくことの恩恵と課題は表裏一体だなと実感してる。

まとめ

6ヶ月の実運用を通じて感じたことを整理すると、「思ったより使える、でも銀の弾丸ではない」というのが正直なところだ。

  1. AutoML（表形式）はビジネス現場で十分実用的
    解約予測・需要予測・異常検知など、典型的なユースケースでは「データサイエンティストが作るモデル」に匹敵する精度が出るケースが増えている。2026年時点のCanvasはだいぶ使える。

  2. Bedrock連携でテキスト+数値のハイブリッド分析が現実的に
    ただしコスト管理と処理時間の見積もりは要注意。プロダクション適用は段階的に。

  3. コスト管理とガバナンスは最初に設計する
    セッション課金+インスタンス費用のダブルパンチは地味に痛い。Budgetsアラートは必須。

  4. Glue等との組み合わせが前提と思ったほうがいい
    Canvas単体で全部やろうとすると前処理の壁に当たる。データエンジニアリング層は別途用意すること。

  5. モデルのバージョン管理ルールを早めに決める
    GUIツールの落とし穴は記録が残りにくいこと。Model RegistryとMLflow連携で追跡可能にしておく。

次のアクション
まだCanvasを試したことがない人は、まず社内の「スプレッドシートで予測してる系」のユースケースを1つ探して、Canvasで置き換えるPoCをやってみてほしい。無料枠と試用クレジットも使えば、お金をほぼかけずに感触が掴める。個人的には「最初の成功体験を非技術者に作らせる」のが導入のコツだと思っている。最初にビジネスメンバーが「自分でモデルを作った」と感じる瞬間を作れれば、あとは勝手に広がっていく。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

生成AI・ML基盤

Bedrockで5モデル実測比較｜Claude・Llama・Mistralを本番で動かして気づいたこと

生成AI・ML基盤

Bedrock Agentsの本番運用で学んだ、マルチステップ設計の地雷｜状態管理とメモリ問題の実装パターン

生成AI・ML基盤

Bedrock Flows を本番で6ヶ月使って見えてきたこと【2026年版】

生成AI・ML基盤

Bedrock Flows本番運用3ヶ月で気づいた、LLMワークフロー自動化の地味だけど痛い落とし穴

生成AI・ML基盤

Bedrock Flows導入で痛感した、ワークフロー自動化の地味だけど重い落とし穴

生成AI・ML基盤

AWS Inferentia2・Trainium コスト効率｜2026年ML推論学習最適化

← 記事一覧に戻る