Marketing Cloud SQLとは　できること・使い方・注意点までわかりやすく解説

2025.08.07

#使い方 #注意点 #Marketing Cloud #SQL

Salesforce Marketing Cloudでは、SQLを活用することでデータの抽出や加工、セグメント作成などが柔軟に行えます。しかし、SQL Serverなどの一般的な環境と異なる点も多く、つまずきやすいのが実情です。

この記事では、SQL経験者がスムーズにSFMCでのSQL活用に移行できるよう、特徴から活用方法、実装時の注意点までを体系的に解説します。

Marketing CloudのSQLで実現できる3つのこと

SQLには慣れているのに、Marketing Cloudで書いてみたら全然通らない——そんな“あるある”にぶつかった方も多いのではないでしょうか。

ここでは、Marketing CloudでSQLを使うときに、実務でよく登場する3つの活用シーンを紹介します。

データ拡張（DE）間のデータ統合や絞り込み

例えば、「前回のメール開封者の中で、今回のクーポン対象者でもある人を抽出したい」といったケース。こうした条件付きのデータ抽出では、複数のデータ拡張を結合（JOIN）したり、細かく条件分岐させたりと、SQLならではの柔軟な操作が活躍します。
慣れ親しんだSQL Serverと書き方は似ていても、微妙な構文のクセがあるので、最初は違和感を覚えるかもしれません。

セグメント作成や顧客分類の自動化

顧客を条件でグルーピングし、「この人たちはAパターンの配信、それ以外はBパターン」など出し分けるのは、Marketing Cloudの得意技。SQLを使えば、性別・購買履歴・アクセス頻度などを組み合わせて、細かいセグメントを自動で作ることができます。
朝の忙しい時間に手動でリスト更新…なんて手間も、もう不要です。

キャンペーンに応じた一括抽出や加工

「このキャンペーンに該当する人、全部まとめて抽出したい」──そんな時にもSQLは心強い味方です。特に、メール開封データ、アンケートの回答結果、会員ステータスなど、複数の情報を横断的に使う場合には、その本領を発揮します。
あらかじめ条件を定義しておけば、Automation Studioで定期的に実行され、配信準備も自動で完了。マーケターの手を煩わせません。

SQL ServerとMarketing Cloud SQLの違いと注意点

「普段使っているSQL Serverと同じ感じで書いたのに、動かない…」Marketing CloudのSQLを初めて書くと、多くの人がこのギャップに戸惑います。見た目は似ていても、動作のルールはけっこう違う。

ここでは特に注意しておきたいポイントを3つ紹介します。

JOINやサブクエリの制約とパフォーマンス

Marketing CloudのSQLは、複雑なネストや結合に弱い傾向があります。LEFT JOINは使えるものの、サブクエリを多用すると処理時間が跳ね上がったり、予期せぬエラーになったりすることも。
とくに大量データを扱う場合は、できるだけクエリをシンプルに保つことが重要です。
「SQL Serverでは当たり前に書けてた構文が通らない」なんてケースも少なくありません。

日付形式とCST（Central Standard Time）に注意

Marketing Cloudの内部システムでは、すべてCST（米国中部標準時）で動いています。
この影響で「日付の条件が1日ズレる」「想定の期間で絞れない」といったトラブルが発生しやすいです。
見落としがちですが、GETDATE()の結果もCST基準。タイムゾーンを意識しないままだと、思わぬミスにつながるので要注意です。

SQLクエリは最大30分で強制終了される（AutoKill）

知らないうちに落とし穴になるのが、この「30分制限」。Marketing Cloudでは、SQLクエリが30分以上かかると自動で処理が中断される仕組みがあります。
夜間バッチで動かしていたら朝になってもデータが更新されてない…というのはよくある話。
件数が多いDE同士を結合する時などは、事前にテストして処理時間を確認しておくのが安心です。

SQLを使ったデータ抽出・加工のステップ

Marketing CloudでSQLを使うとき、「どこで書いて、どこで実行されるの？」と最初は戸惑うもの。構文の書き方だけでなく、どの画面で何を設定すればいいのかも押さえておく必要があります。

ここでは、実際の作業手順を3つのステップで整理してみましょう。

Data ViewsとDEの構成を理解する

Marketing Cloudでは、顧客情報や配信履歴などのデータが「Data Views」と呼ばれる仮想テーブルに格納されています。
一方、実際に操作するデータは「データ拡張（DE）」と呼ばれるユーザー定義のテーブル。多くのSQLは、このData Viewsからデータを引き出し、DEに書き込むという流れになります。
最初にこの構造をしっかり理解しておくと、クエリ設計がずっと楽になります。

Automation StudioでSQLクエリアクティビティを設定

実際のSQLは、Automation Studio内で「クエリアクティビティ」として登録・実行します。対象のSQLを設定し、出力先のDEを指定しておけば、定期的に自動実行させることも可能です。
たとえば、毎朝7時にセグメントを更新し、そのままメール配信につなげるといった運用も現実的。
1回きりではなく、運用の中にSQLを組み込むことで、Marketing Cloudの価値がぐっと高まります。

検証環境（Query Studioなど）で安全にテスト

本番運用の前に必ずやっておきたいのが、クエリの検証です。
特に初回実行時は、思わぬ構文ミスやデータ欠損が起こることもあるため、Query StudioやTest DEなどを使って安全にテスト
しましょう。Previewで件数が少なくても、実データでは実行時間がかかることもあります。検証の一手間が、後々のトラブル回避につながります。

活用が広がる！おすすめのSQL Tips3選

基本を押さえたら、次は“現場で効く一歩先のテクニック”を身につけたいところ。

SQL経験者ならつまずきやすいポイントを交えながら、実務でよく役立つTipsを3つ紹介します。

NOT IN vs NOT EXISTSの使い分け

似たような動きをするこの2つの構文ですが、Marketing Cloudでは挙動やパフォーマンスに違いが出やすいです。
特にNOT INはNULLを含むと期待通りに動かないため、「除外してるはずなのに全然減らない…」という事態も。そんなときはNOT EXISTSに切り替えるとスムーズにいくことがあります。
挙動の違いを知っておくだけでも、バグの原因を見抜ける場面は増えるはずです。

更新系クエリを安全に使うためのベストプラクティス

Marketing CloudのSQLは、基本的にSELECT文＋出力先DEの上書きという流れですが、これを使って「更新」のような動きも作れます。
たとえば、既存のDEを一度空にしてから新しいデータを流し込むといったやり方。ただし、条件ミスで全件削除→空のデータで上書き、という悲劇も起こりがちです。
バックアップ用のDEを事前に作る、件数確認のログを取るなど、“保険”を用意しておくのが現場の鉄則です。

実行速度を上げるインデックス的工夫とは？

Marketing CloudのDEにはインデックスの概念がなく、パフォーマンス調整が難しいのが実情です。
とはいえ、WHERE句でよく使う列だけを小さなDEに切り出してJOINする、不要な列をSELECTに含めない、といったちょっとした工夫で実行速度が改善されることがあります。
また、件数の多いDEを扱う場合は、1回で全部処理するよりも、複数の条件に分けて分割実行するのも一つの手。地味ですが、効きます。

まとめ

Marketing CloudでSQLを使いこなせるようになると、データ活用の幅が一気に広がります。単なる抽出だけでなく、セグメントの自動更新やキャンペーンごとの加工処理など、業務効率の面でも大きな武器になります。
ただし、SQL Serverや他のRDBMSとまったく同じ感覚で書くと、予期せぬエラーやパフォーマンス問題に直面することも。構文の違い、時間帯の扱い、実行制限など、Marketing Cloud特有の仕様をしっかり押さえておくことが成功のカギです。
実務の“あるある”や現場の工夫を知っていると、トラブルを未然に防げるだけでなく、クエリの質そのものも上がってきます。この記事で紹介した基本とTipsを踏まえ、ぜひ自社の運用に取り入れてみてください。

＜Marketing Cloud＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

弊社はプロセスコンサルティングを行っている会社です。
お気軽にお問い合わせください！
＞＞お問い合わせはこちら