Tableau CRM データフローとレシピでデータパイプラインを最適化する：データエンジニア向けガイド

執筆者：Salesforce データエンジニア

背景と適用シナリオ

Salesforce のエコシステム内で高度な分析を実現するためのネイティブプラットフォームとして、Tableau CRM（旧称 Einstein Analytics）は、ビジネスインテリジェンス (BI) の世界で極めて重要な役割を果たしています。単なるレポートやダッシュボードツールとは一線を画し、Tableau CRM は大規模なデータセットを処理し、複雑なデータ変換を行い、さらには予測インサイトを提供する能力を持っています。データエンジニアとして、私たちの主な責務は、この強力なプラットフォームに供給されるデータの品質、一貫性、そして適時性を保証することです。結局のところ、分析の価値は、その基盤となるデータの質に直接依存するからです。

ビジネス上の意思決定は、クリーンで、信頼でき、文脈に富んだデータに基づいて行われるべきです。しかし、生データはしばしば不完全で、形式が不統一であり、複数のソースに分散しています。例えば、営業チームは商談データを分析したいかもしれませんが、その商談に関連する取引先責任者の役職や、取引先の業種情報も同時に分析軸として加えたいと考えるでしょう。また、外部のマーケティングシステムから得たリードソース情報と Salesforce のキャンペーンデータを統合し、ROI を算出したいケースもあります。

ここで中心的な役割を果たすのが、Tableau CRM のデータ準備ツールである Dataflow (データフロー) と Recipe (レシピ) です。これらは、Tableau CRM 内で ETL (Extract, Transform, Load - 抽出、変換、読み込み) プロセスを設計・実行するための二大巨頭です。これらのツールを使用することで、以下のようなシナリオに対応できます。

適用シナリオの例：

複数オブジェクトの結合： 取引先オブジェクトと商談オブジェクトを結合し、「年間売上が特定金額以上である業種別の商談成立確率」のような高度な KPI を含むデータセットを作成する。
データのエンリッチ化： Salesforce データを外部データ（例：CSV ファイルでアップロードした人口統計データ）と結合し、顧客プロファイルをより豊かにする。
複雑な計算項目の作成： 標準の数式項目では実現が難しい、複数行にまたがる計算（例：前月比成長率）や複雑な条件分岐ロジックを持つ新しい項目をデータ準備段階で作成する。
データクレンジングと標準化： 住所の表記揺れを統一したり、欠損値をデフォルト値で補完したりするなど、データの品質を向上させる。
予測モデリングのためのデータ準備： Einstein Discovery で使用するために、データを整形し、特徴量エンジニアリング（Feature Engineering）を行う。

データエンジニアとして、これらのツールを深く理解し、ビジネス要件に最適なデータパイプラインを構築することが、価値あるインサイトを導き出すための鍵となります。

原理説明

Tableau CRM のデータ準備レイヤーは、主に Dataflow と Recipe という2つのコンポーネントで構成されています。それぞれに特徴があり、適切なツールを選択することが重要です。

Dataflow (データフロー)

Dataflow は、Tableau CRM の初期から存在する、伝統的なデータ変換ツールです。その実体は、データ変換のロジックを定義した JSON ファイルです。GUI エディタ（データフローエディタ）も提供されていますが、その裏側では常に JSON が生成・編集されています。

Dataflow は、複数の「ノード」を連結させることで処理を定義します。各ノードは特定のタスク（データの抽出、変換、登録など）を実行します。

主要なノードの種類：

sfdcDigest： Salesforce オブジェクトからデータを抽出（Digest）するための最も基本的なノードです。どのオブジェクトから、どの項目を、どのような条件で抽出するかを定義します。
edgemart / sfdcRegister： 変換処理が完了したデータを、Tableau CRM のデータセットとして登録（Register）するためのノードです。sfdcRegister はより新しい推奨ノード名です。
augment： 2つのデータストリームを、指定したキー項目に基づいて結合（Left Join に相当）します。例えば、商談データに取引先の所有者情報（User オブジェクト）を付加する場合に使用します。
computeExpression： SAQL (Salesforce Analytics Query Language) の式を使用して、新しい項目を計算・作成します。複雑な条件分岐やデータ型の変換が可能です。
computeRelative： パーティションと順序を指定し、前の行や次の行の値を参照して新しい項目を計算します。移動平均や累積合計などを算出するのに役立ちます。
filter： 指定した条件に基づいて、データストリームから不要な行を削除します。

Dataflow は非常に強力で柔軟性がありますが、JSON を直接編集する必要がある場面も多く、非技術的なユーザーにとっては学習コストが高いという側面もあります。

Recipe (レシピ)

Recipe は、Dataflow の後継として導入された、よりモダンで視覚的なデータ準備ツールです。ユーザーはグラフィカルなインターフェース上で、データのプレビューを見ながら直感的に変換ステップを追加していくことができます。

Recipe は、Dataflow よりもパフォーマンスが最適化された新しいデータ処理エンジン上で実行され、多くの場合、同等の処理をより高速に実行できます。

Recipe の主な特徴と機能：

ビジュアルインターフェース： データ変換の各ステップ（ノード）を視覚的に追加・設定できます。入力、結合、変換、集計、フィルタ、出力といったノードが用意されています。
リアルタイムプレビュー： 変換を追加するたびに、データのサンプルがどのように変化するかをリアルタイムで確認できるため、試行錯誤が容易です。
スマートな提案機能： 列のデータ型や内容に基づいて、日付形式の統一や欠損値の補完といった変換を自動で提案してくれます。
豊富な変換オプション： GUI 上で、列の分割、数式の作成、バケット化（グルーピング）、クラスタリングなど、多岐にわたる変換を容易に実行できます。
Join と Append： 複数のデータソースを結合（Join）したり、縦に連結（Append/Union）したりする操作が Dataflow よりも直感的に行えます。

現在、Salesforce は新規のデータ準備タスクには Recipe の使用を強く推奨しています。Dataflow でしか実現できない一部の高度な変換（例: `computeRelative`）を除き、ほとんどのユースケースは Recipe でカバーできます。

サンプルコード：Dataflow JSON 定義

ここでは、Dataflow の実体である JSON の構造を理解するために、公式ドキュメントに基づいたサンプルコードを示します。この例では、取引先（Account）オブジェクトとユーザー（User）オブジェクトからデータを抽出し、`augment` ノードを使って取引先に所有者（Owner）の名前を結合し、最終的に「Accounts_with_Owner」というデータセットとして登録します。

{
  "Extract_Accounts": {
    "action": "sfdcDigest",
    "parameters": {
      "object": "Account",
      "fields": [
        { "name": "Id" },
        { "name": "Name" },
        { "name": "Industry" },
        { "name": "AnnualRevenue" },
        { "name": "OwnerId" }
      ]
    }
  },
  "Extract_Users": {
    "action": "sfdcDigest",
    "parameters": {
      "object": "User",
      "fields": [
        { "name": "Id" },
        { "name": "Name" }
      ]
    }
  },
  "Augment_Account_with_User": {
    "action": "augment",
    "parameters": {
      "left": "Extract_Accounts",
      "left_key": "OwnerId",
      "right": "Extract_Users",
      "right_key": "Id",
      "right_select": [
        "Name"
      ],
      "relationship": "Owner"
    }
  },
  "Compute_Owner_Name": {
    "action": "computeExpression",
    "parameters": {
      "source": "Augment_Account_with_User",
      "mergeWithSource": true,
      "computedFields": [
        {
          "name": "AccountOwnerName",
          "type": "Text",
          "saqlExpression": "Owner.Name"
        }
      ]
    }
  },
  "Register_Accounts_Dataset": {
    "action": "sfdcRegister",
    "parameters": {
      "alias": "Accounts_with_Owner",
      "name": "Accounts_with_Owner",
      "source": "Compute_Owner_Name"
    }
  }
}

コードの解説：

1-12行目 (`Extract_Accounts`): `sfdcDigest` アクションを使用して、Account オブジェクトから Id, Name, Industry, AnnualRevenue, OwnerId の各項目を抽出するノードを定義しています。
13-22行目 (`Extract_Users`): 同様に、User オブジェクトから所有者情報を取得するために Id と Name を抽出しています。
23-35行目 (`Augment_Account_with_User`): `augment` アクションを使用しています。
- `left`: 左側（ベース）となるデータストリーム（`Extract_Accounts` ノードの結果）を指定します。
- `left_key`: 左側の結合キー（`OwnerId`）を指定します。
- `right`: 右側（付加する情報）のデータストリーム（`Extract_Users` ノードの結果）を指定します。
- `right_key`: 右側の結合キー（`Id`）を指定します。
- `right_select`: 右側のデータストリームからどの項目を持ってくるか（`Name`）を指定します。
- `relationship`: 結合後の項目グループに付ける名前（`Owner`）を定義します。これにより、所有者の名前は `Owner.Name` として参照可能になります。
36-48行目 (`Compute_Owner_Name`): `computeExpression` アクションで新しい項目を作成します。`augment` で結合した `Owner.Name` を `AccountOwnerName` という分かりやすい名前の項目にコピーしています。これは必須ではありませんが、後続の分析で使いやすくするための良い実践です。
49-56行目 (`Register_Accounts_Dataset`): `sfdcRegister` アクションを使用して、これまでの処理結果を `Accounts_with_Owner` という名前のデータセットとして登録します。`source` パラメータで、どのノードの結果を登録するかを指定します（`Compute_Owner_Name`）。

注意事項

Tableau CRM でデータパイプラインを構築・運用する際には、いくつかの制約や注意点を考慮する必要があります。

権限 (Permissions):
データフローやレシピを作成・編集・実行するには、適切な権限セットが必要です。「Tableau CRM Plus 管理者」や「Tableau CRM Plus ユーザ」の権限セットライセンスに含まれる、「分析データフローの編集」や「レシピの管理」といったシステム権限が必要となります。データソースとなる Salesforce オブジェクトや項目への参照権限も必須です。
API とガバナ制限 (API and Governor Limits):
Tableau CRM は Salesforce プラットフォームの他の部分と同様に、ガバナ制限の影響を受けます。特に注意すべきは以下の点です。
- データ同期 (Data Sync): Salesforce から Tableau CRM へデータを同期する際には、24時間あたりの実行回数や、一度に同期できるオブジェクト数に制限があります。
- データフロー/レシピの制限: 1つのデータフロー/レシピに含めることができるノードの数や、JSON 定義の文字数にも上限があります。複雑すぎるパイプラインは複数のフロー/レシピに分割することを検討すべきです。
- データセットの制限: 1つのデータセットに含めることができる行数（最大100億行などライセンスによる）や列数（最大5,000）に制限があります。
エラー処理とデバッグ (Error Handling and Debugging):
データパイプラインの実行が失敗することは珍しくありません。失敗した場合は、「データマネージャ」の「モニタ」タブを確認します。ジョブのログに、どのノードで、どのような理由でエラーが発生したかの詳細が出力されます。よくあるエラー原因としては、項目名のタイプミス、データ型の不一致（例：テキストと数値を結合しようとする）、結合キーの null 値、Salesforce 側の権限不足などが挙げられます。
パフォーマンス (Performance):
データ量が増えるにつれて、パイプラインの実行時間は長くなります。パフォーマンスを最適化するためには、`sfdcDigest` ノードで不要な項目は最初から除外する、`filter` ノードを可能な限りプロセスの早い段階に配置して処理対象のデータ量を減らす、といった工夫が重要です。また、前述の通り、一般的に Recipe は Dataflow よりもパフォーマンスが高い傾向にあります。

まとめとベストプラクティス

Tableau CRM の Dataflow と Recipe は、Salesforce 環境におけるデータエンジニアリングの中核をなすツールです。これらのツールを使いこなすことで、散在する生データを、ビジネス上の意思決定に直結する価値あるインサイトへと昇華させることができます。

最後に、データエンジニアとしてのベストプラクティスをいくつか挙げます。

Recipe を第一選択肢に (Recipe First): 新規のデータ準備タスクには、その使いやすさ、パフォーマンス、そして Salesforce による継続的な機能強化の観点から、Recipe を優先的に使用することを強く推奨します。
モジュール化と再利用 (Modularization and Reusability): 巨大で複雑な一つのパイプラインを作るのではなく、複数のパイプラインに分割するアプローチを取ります。例えば、よく使う取引先とユーザーの結合データセットを一つの中間レシピで作成しておき、他の複数のレシピがその中間データセットを入力として利用する、といった設計が保守性を高めます。
明確な命名規則 (Clear Naming Conventions): データフロー、レシピ、データセット、そしてその中の項目（特に計算項目）には、一貫性のある分かりやすい命名規則を適用してください。将来の自分自身や他のチームメンバーがパイプラインを理解する助けとなります。
早期フィルタリング (Filter Early): データパイプラインの早い段階で不要なデータを除外することで、後続の処理全体のパフォーマンスが向上します。
ドキュメント化 (Documentation): なぜこの変換ロジックが必要なのか、どのビジネス要件に基づいているのか、といった背景情報をデータフロー/レシピの説明欄や外部ドキュメントに残しておくことが、長期的な運用において非常に重要です。

データエンジニアとして、私たちは単にデータを動かすだけではありません。データの潜在能力を最大限に引き出し、ビジネスがデータドリブンな文化を醸成するための基盤を構築する、という重要な使命を担っています。Tableau CRM のデータ準備ツールは、その使命を達成するための強力な武器となるでしょう。

にゃんこのSalesforce日記

このブログを検索