スマートリストを使いこなす！Marketo Tips

Marketoの「スマートリスト」は、リードの行動履歴や属性情報をもとに、必要な対象を柔軟に抽出できる機能です。マーケティング施策の対象選定やスコアリング、運用管理など、さまざまな場面で活用されています。

一方で、目的を整理しないままスマートリストを作成すると、意図しない対象が抽出されたり、処理負荷によってパフォーマンスに影響が出たりすることがあります。特に運用期間が長い環境では、スマートリストの増加によって管理が複雑化し、メンテナンス負荷が高まるケースも少なくありません。

この記事では、「そもそもスマートリストとは何か」という基本から、なぜそのように設計するべきなのかという考え方まで整理しながら解説します。そのうえで、実務で活用しやすい具体的な作成手順や、運用時に確認しておきたいチェックポイントも紹介します。

1. そもそもスマートリストとは？

Marketoのスマートリストとは、条件（トリガー／フィルター）を組み合わせて、特定の条件に合致するリードを動的に抽出する機能です。
メール配信の対象選定、スマートキャンペーンの実行条件、レポート分析時の母集団作成など、Marketo運用のさまざまな場面で利用されます。

例えば、

• 「特定のフォームを送信した人」
• 「過去30日以内にWebページを閲覧した人」
• 「業種が製造業で、スコアが一定以上の人」

といった条件を組み合わせることで、必要な対象だけを柔軟に抽出できます。

「リスト」との違い

スマートリストを理解するうえで重要なのが、リスト（静的リスト）との違いです。

リストは、特定時点の対象者を保持する“スナップショット”型のリストです。一方、スマートリストは条件に基づいて常に再評価される“動的リスト”です。

そのため、リードの行動や属性が変化すると、スマートリストの抽出結果もリアルタイムで変化します。

この柔軟性は大きなメリットですが、同時に注意点もあります。
スマートリストは条件を都度評価する仕組みのため、複雑な条件や大量データを扱う場合は評価コストが高くなります。特に、頻繁に参照されるスマートキャンペーンや大規模運用環境では、設計次第でパフォーマンスに影響を与えることがあります。

そのため、「とりあえず条件を追加する」のではなく、

• 本当に必要な条件か
• より軽い条件で代替できないか
• 再利用しやすい構成になっているか

といった観点を持って設計することが重要です。

2. 設計思想

スマートリストを設計する際に重要なのは、「条件を満たすリードを抽出できればよい」という発想だけではありません。
実際の運用では、効率性（速く・安定して動作すること） と 可読性（誰が見ても用途や意図が分かること） を両立させることが重要になります。

特にMarketoは、スマートリストがメール配信やキャンペーン実行、スコアリングなど複数機能の基盤になるため、設計次第で運用負荷やシステム全体の安定性に影響を与えます。

ここでは、実際の現場でスマートリストを作成するときに、どのような順序で考えるべきかを整理します。

① まず「何のためのリストか」を明確にする

最初に確認すべきなのは、このスマートリストの目的です。

例えば、

• 配信対象を抽出したいのか
• 自動化キャンペーンの条件として使いたいのか
• レポート分析用の母集団を作りたいのか

によって、最適な設計は変わります。

配信対象であれば「誤抽出を防ぐこと」が重視されますし、自動化用途であれば「処理速度」や「リアルタイム性」が重要になります。分析用途であれば、多少重くても柔軟性を優先するケースもあります。

目的が曖昧なまま作成すると、後から条件追加が繰り返され、複雑で保守しづらいリストになりやすいため注意が必要です。

② どの程度の頻度で参照されるかを考える

次に、そのスマートリストがどれくらいの頻度で利用されるかを確認します。

例えば、

• 日中に何度も評価されるトリガーキャンペーン
• 定期バッチで週1回だけ利用する抽出
• 大量配信前に一時的に使うリスト

では、求められる設計が異なります。

頻繁に参照されるスマートリストでは、複雑な条件を毎回リアルタイム評価すると負荷が高くなるため、事前にフラグ項目を作成したり、Static Listを経由したりして負荷を分散させる設計が有効です。

一方、低頻度の利用であれば、多少複雑な条件でも柔軟性を優先できる場合があります。

③ 条件ごとの「重さ」を意識する

スマートリストでは、条件によってシステム負荷が大きく異なります。

特に注意したいのが、

• Contains
• Free-text検索
• 長文フィールドへの条件指定
• 広範囲な行動履歴検索

などです。

これらは便利ですが、評価コストが高くなる傾向があります。

例えば、「会社名に○○を含む」といった曖昧検索を多用すると、対象データ全体への検索負荷が発生しやすくなります。

そのため、

• 事前に正規化した値を保持する
• 判定用フラグを別フィールドで持つ
• 外部システム側で前処理する

といった方法で、できるだけ軽い条件へ置き換えることが推奨されます。

④ 将来の運用・保守まで考える

スマートリストは、一度作って終わりではありません。
運用が続くほど条件追加や修正が発生し、別担当者が引き継ぐケースも増えていきます。

そのため、

• 命名規則を統一する
• 用途をコメントに残す
• 「なぜこの条件なのか」を説明できる状態にする

といった保守性も重要です。

特に大規模環境では、「誰も用途を説明できないスマートリスト」が増えると、削除判断ができなくなり、結果として不要なリストが蓄積していきます。

⑤「常に最新」である必要があるのかを考える

スマートリストは動的に最新状態を維持できることが大きな特徴です。
しかし、すべてのケースでリアルタイム性が必要とは限りません。

例えば、

• 月次レポート用の対象
• 配信前に確定したい対象者
• 承認済みのセグメント

などは、Static Listとして固定化したほうが運用が安定する場合があります。

重要なのは、「常に最新であること」が本当に価値なのかを見極めることです。

スマートリストの役割は、あくまで“条件評価を正確に行うこと”です。
その結果を毎回リアルタイムで変化させるべきか、それとも一定時点で固定化したほうが良いのかを判断することが、実運用では非常に重要になります。

3. 基本方針（設計ルール）

スマートリストを長期的に安定運用するためには、「とりあえず条件を追加する」のではなく、一定の設計ルールを持つことが重要です。
ここでは、実運用で特に効果の高い基本方針を紹介します。

① 目的に合わせた粒度で作る

スマートリストは、用途によって適切な粒度が異なります。

例えば、メール配信で使用する場合は、過剰に細かい条件を積み重ねるよりも、必要最低限の条件で大きくセグメントを切るほうが運用しやすくなります。一方、分析用途では、比較や検証を行いやすくするために、条件を細かく分けて管理するケースもあります。

つまり、

• 配信用途 → シンプルで安定した設計
• 分析用途 → 柔軟性を重視した設計

というように、目的に応じて粒度を調整することが重要です。

② 条件はできるだけ少なくする

スマートリストは、条件が増えるほど複雑化し、可読性やパフォーマンスが低下しやすくなります。

そのため、基本的には、

• 条件数は10個以下
• ネスト構造は2層以内

をひとつの目安にすると管理しやすくなります。

もちろん例外はありますが、「なぜここまで複雑になっているのか」を説明できない状態は避けるべきです。

条件追加を繰り返す前に、

• 不要な条件はないか
• 同じ意味の判定を重複していないか
• フィールド化で簡略化できないか

を確認する習慣を持つと、リストの肥大化を防ぎやすくなります。

③ 頻繁に使う判定はフィールド化する

何度も評価される条件を毎回スマートリスト内で計算すると、処理負荷が高くなる場合があります。

例えば、

• 特定ステータスの判定
• セグメント分類
• 配信可否判定

など、頻繁に利用する条件は、事前にフラグ項目として保持しておくほうが効率的です。

特に、リアルタイム性が不要なケースでは、

1. 定期バッチで条件判定
2. フラグ項目を更新
3. Smart Listではそのフラグのみ参照

という構成にすることで、スマートリスト自体をシンプルかつ高速に保ちやすくなります。

④ 命名規則とDescriptionを徹底する

スマートリストは数が増えるほど、「何のためのリストなのか分からない」という問題が起きやすくなります。

そのため、

• 用途
• 作成日
• 担当者
• 利用中かどうか

などを命名規則やDescriptionに残しておくことが重要です。

例えば、

• SL_Mail_Target_Webinar_202605
• SL_Scoring_MQL_Check
• Archive_2025_UsedForCampaign

のように、役割が分かる名前にしておくと、後から見返した際の判断がしやすくなります。

また、Descriptionには「なぜこの条件なのか」を簡潔に残しておくと、引き継ぎ時の負担を大きく減らせます。

⑤ 実行時間を定期的に確認する

スマートリストは、作成時点では問題なくても、データ量や運用規模の増加によって徐々に重くなることがあります。

そのため、

• 実行時間
• キャンペーン待機時間
• バッチ処理の遅延

などを定期的に確認し、一定の閾値を超えた場合はレビューする運用をおすすめします。

特に大規模環境では、「以前は問題なかった設計」が将来的にボトルネックになるケースも少なくありません。

重要なのは、スマートリストを“作って終わり”にしないことです。
継続的に見直しながら、シンプルで維持しやすい状態を保つことが、安定運用につながります。

（スクショ推奨箇所：Smart List画面のDescription欄、条件一覧の全体画面）

4. スマートリストの見直しポイント

ここからは、既存のスマートリストを見直す際に使える具体的な改善手順を紹介します。
ポイントは、感覚で「重そう」と判断するのではなく、目的・実行時間・抽出件数を確認しながら、ボトルネックを特定していくことです。

① 目的と利用頻度を確認する

まず、対象のスマートリストが何のために使われているのかを確認します。

確認すべき項目は、主に次のとおりです。

• 配信用か
• 自動化用か
• 分析用か
• 日中に頻繁に参照されるか
• 定期バッチで使われるだけか
• 他のキャンペーンから参照されているか

確認した内容は、スマートリストのDescriptionに記載しておきます。

例えば、

用途：ウェビナー配信対象抽出
利用頻度：月2回、配信前に手動実行
担当：Marketing Ops
最終確認日：2026/05/12

のように残しておくと、後から別の担当者が見ても判断しやすくなります。

② 重い条件を特定する

次に、スマートリスト内で処理負荷が高い条件を特定します。

実務上は、条件を1つずつ外して実行し、実行時間の変化を見る方法が分かりやすいです。

手順は次のとおりです。

1. 現在のスマートリストを複製する
2. 複製したスマートリストでベースラインの実行時間と抽出件数を記録する
3. 条件を1つずつ外して実行する
4. Program実行履歴などで実行時間を確認する
5. 実行時間が大きく変化した条件をボトルネック候補として記録する

このとき、抽出件数もあわせて確認することが重要です。
実行時間だけが短くなっても、抽出対象が大きく変わってしまっては意味がありません。

記事内では、Program実行履歴の実行時間表示のスクリーンショットを入れると、読者が自分の環境で確認しやすくなります。

③ 重い条件はフラグ化する

処理負荷が高い条件が見つかった場合は、スマートリスト内で毎回評価するのではなく、別フィールドに判定結果を持たせる設計を検討します。

例えば、問い合わせ本文に含まれるキーワードで対象を判定している場合、本文に対して都度キーワード検索を行うと負荷が高くなりやすくなります。

このような場合は、バックエンド処理や外部連携側であらかじめ分類し、Marketo上では topic_tag のような判定用フィールドを参照する形にします。

例：

• 改善前：問い合わせ本文に「価格」「見積」「料金」を含む
• 改善後：topic_tag = pricing

このように、スマートリストでは単純なフィールド条件だけを評価する形にすると、条件の可読性も高まり、処理負荷も抑えやすくなります。

④ OR条件の多用は分割して管理する

複数の条件をORで大量につなげているスマートリストは、読みづらく、保守もしづらくなります。

この場合は、条件ごとにスマートリストを分割し、それぞれの結果をStatic Listに保存したうえで、最後に結合する方法が有効です。

例えば、A／B／Cのいずれかに該当するリードを抽出したい場合は、次のように分けます。

1. 条件Aに該当するリードをSmart List Aで抽出
2. 条件Bに該当するリードをSmart List Bで抽出
3. 条件Cに該当するリードをSmart List Cで抽出
4. それぞれの結果をStatic List A／B／Cに保存
5. 最終的な対象リストでは Member of Static List で結合する

この構成にすると、各条件の意味が明確になり、どの条件が重いのかも特定しやすくなります。

また、条件を追加・削除する場合も、該当するリストだけを修正すればよいため、運用の安全性が高まります。

⑤頻繁に使うリストは夜間バッチでStatic化する

日中に頻繁に参照されるスマートリストは、毎回リアルタイムで評価するのではなく、夜間バッチでStatic Listに固定化することを検討します。

例えば、毎日参照される配信対象やセグメント判定であれば、夜間に条件評価を行い、その結果をStatic Listへ反映しておきます。
日中のキャンペーンでは、そのStatic Listを参照するだけにすれば、リアルタイム評価の負荷を避けられます。

この方法は、特に以下のようなケースで有効です。

• 対象者の変化が1日単位で問題ない
• 日中に複数キャンペーンから参照される
• 条件が複雑で実行時間が長い
• 配信前に対象を確定させたい

一方で、フォーム送信直後の自動返信メールなど、即時性が必要な処理ではStatic化が向かない場合もあります。
「常に最新である必要があるか」を確認したうえで使い分けることが重要です。

⑥変更前後の効果を検証する

最後に、改善前後の効果を必ず記録します。

確認すべき項目は、主に次のとおりです。

• 平均実行時間
• 最大実行時間
• 抽出件数
• 条件数
• 参照元キャンペーン数
• 変更日
• 変更内容
• 担当者

改善前のベースラインを記録しておくことで、変更後に本当に効果が出たのかを判断できます。

例えば、

改善前：平均実行時間 45秒、抽出件数 12,430件
改善後：平均実行時間 8秒、抽出件数 12,410件
変更内容：問い合わせ本文のContains条件をtopic_tag判定に変更

のように残しておくと、改善効果と抽出結果の差分を確認しやすくなります。

また、この記録は個別のメモで終わらせず、運用ルールや管理台帳に保存しておくことをおすすめします。
後から同じようなスマートリストを作る際の判断材料になり、組織全体の設計品質を高めることにつながります。

（スクショ推奨箇所：Static List作成画面、Smart Campaignでのバッチ更新フロー）

見直しチェックリスト

スマートリストを作成・改善する際は、以下の観点を確認しておくと、パフォーマンス低下や運用負荷の増加を防ぎやすくなります。

• □ 用途をDescriptionに記載したか？
• □ 条件数は10個未満か？ ネストは2層以内か？
• □ Contains やFree-text検索を多用していないか？
• □ 頻出する判定をフラグ化できないか検討したか？
• □ 頻繁に参照されるリストをStatic化できないか？
• □ 変更前後の実行時間を記録したか？

すべてを厳密に守る必要はありませんが、「なぜこの設計にしているのか」を説明できる状態を保つことが重要です。

5. よくある誤解

①「動的だから全部スマートリストで管理すればよい」

これはよくある誤解です。

スマートリストは非常に便利ですが、常にリアルタイム評価が必要とは限りません。
配信対象の固定化や定期レポートなど、更新タイミングが決まっている用途では、リストのほうが安定して運用できる場合があります。

「最新状態であること」が本当に必要かを、まず確認することが重要です。

②「リストが増えると管理が大変」

確かに、運用ルールなしに増やすと管理負荷は高くなります。
ただし、

• 命名規則の統一
• 利用期限の明記
• 定期アーカイブ
• 自動削除ルール

などを整備することで、十分に管理可能です。

むしろ、役割ごとに分離されたStatic Listは、Smart Listを複雑化させないための“運用資産”として機能することもあります。

6. まとめ

スマートリストは、単に「条件を設定する機能」ではありません。
目的・利用頻度・処理コストを考慮しながら設計することで、Marketo全体のパフォーマンスや運用効率に大きな差が生まれます。

特に大規模運用では、

• 条件を増やしすぎない
• 頻出判定をフラグ化する
• 必要に応じてStatic化する
• 実行時間を継続的に確認する

といった基本設計の積み重ねが、安定運用につながります。

まずは現在利用しているスマートリストの中から、実行時間が長いものや複雑になっているものを1つ選び、この記事の手順で改善を試してみてください。