- 今回の構成
- Amazon Quick と Salesforce の接続手順
- Salesforce 商談データを分析できる形に整える（計算フィールド設計）
- ダッシュボード作成（3シート構成）
- 自然言語で Salesforce データに質問する：トピックの設定
- チャットエージェントで自然言語分析｜示唆まで自動生成
- まとめ
- Amazon Quick の導入・活用をご検討の方へ
こんにちは。山科です。
Salesforce を導入している企業で「データは入っているのに、うまく分析・可視化できない」という話をよく聞きます。SFA に蓄積された営業データを活かしたいけれど、標準機能だけでは思うようにいかない、というケースです。
たとえば「今月の受注率を見たい」と思っても、Salesforce の商談データに『受注率』というフィールドは存在しません。
受注・失注はフェーズ名（Closed Won / Closed Lost）の文字列として記録されているため、受注率を出すにはまずフェーズを 0/1 の数値に変換する必要があります。
Salesforce のデータは「蓄積された状態のまま」では分析しにくく、BI ツール側で分析できる形に設計し直す工程が要る、というのがポイントです。
今回はその設計を含め、Salesforce との接続から営業ダッシュボードの構築、自然言語での質問応答（Q&A）まで一通り試してみました。
今回の構成
なお、本記事で使用しているデータは検証用のテストデータです。実際の Salesforce データとは異なります。
Amazon Quick と Salesforce の接続手順
左サイドバーの「データセット」→「データセットを作成」→「データソースを作成」から、接続先として「Salesforce」を選択します。
選択すると Salesforce のログイン画面にリダイレクトされます。ユーザー名とパスワードを入力して認証すると、Amazon Quick に戻り接続が完了します。
接続後は「データソース」として Salesforce が登録されます。
注意：接続用の専用アカウントを用意する
Amazon Quick の UI 上ではユーザー名とパスワードを入力しますが、内部的には AWS が用意した Connected App（QuickSight_IAD_Prod）を経由した OAuth 認証が行われています。Salesforce 側のログイン履歴にも「Remote Access 2.0」として記録されます。自分で Consumer Key / Secret を用意する必要はありません。
個人アカウントで接続した場合、その担当者が退職・異動した際にアカウントが無効化されると Amazon Quick との接続も切れてしまいます。また、誰の認証情報で接続されているかが分かりにくくなるため、管理面でも問題が起きやすいです。
運用を見据えるなら、Amazon Quick 接続専用の Salesforce ユーザーをあらかじめ作成しておくことを推奨します。個人に紐づかないアカウントにすることで、担当者が変わっても接続が維持でき、管理もシンプルになります。
Salesforce 商談データを分析できる形に整える（計算フィールド設計）
接続後は取得するデータを選びます。「レポートまたはオブジェクトを選択します。」のドロップダウンから「オブジェクト」または「レポート」を選択できます。
| オブジェクト | レポート | |
|---|---|---|
| データの状態 | 生データそのまま | Salesforce 側で加工済み |
| 集計・フィルター | Amazon Quick 側で自由に設定 | Salesforce 側の設定に依存 |
| 向いているケース | ダッシュボードをゼロから設計したい場合 | 既存の Salesforce レポートをそのまま使いたい場合 |
今回は「オブジェクト」を選び、商談（Opportunity）を指定しました。計算フィールドを自由に追加したかったため、Amazon Quick 側で柔軟に加工できるオブジェクトの方が適していました。
分析に必要な値は計算フィールドで作成する
Salesforce の商談データには「受注 or 失注」を示す数値フィールドが存在しないため、受注率や月次集計に必要な値は Amazon Quick の計算フィールドとして定義する必要があります。今回は以下の 5 つを追加しました。
| フィールド名 | 用途 |
|---|---|
| is_won | 受注フラグ |
| is_lost | 失注フラグ |
| is_closed | 受注・失注どちらかのクローズ済みフラグ |
| close_month | 月次集計のための年月文字列 |
| loss_reason_label | 失注理由の null を「未入力」として可視化 |
is_won は受注・失注を 0/1 で表現することで、受注率の計算に使えます（平均値が受注率になる）。loss_reason_label は null のままだとグラフに描画されないため、文字列に変換する処理が必要です。null も失注の 1 件として数えたい場合は必須の処理になります。
どの計算フィールドが必要かはダッシュボードの設計によって変わるため、分析したい内容を先に決めてからデータセットを設計するのがスムーズです。
データの同期はリアルタイムではない
Amazon Quick は Salesforce のデータを SPICE（Super-fast, Parallel, In-memory Calculation Engine：インメモリ計算エンジン）に取り込んで使います。そのため、Salesforce 側でデータが更新されても、ダッシュボードには自動で反映されません。
データを最新化する方法は 2 つあります。
- 手動更新
- データセット画面の「今すぐ更新」ボタンで即時反映できます
- スケジュール更新
- 毎時・毎日・毎週・毎月の頻度で自動更新を設定できます
「常に最新のデータを見たい」場合は、スケジュール更新の頻度を運用要件に合わせて設計しておく必要があります。
データセットの共有
作成したデータセットは他のユーザーと共有できます。権限は「所有者」と「表示者」の 2 種類です。
| 権限 | できること |
|---|---|
| 所有者 | 分析・データセットの作成、リフレッシュ、編集、削除、再共有 |
| 表示者 | 分析・データセットの作成のみ。編集・削除・再共有は不可 |
分析を作成するメンバーには「表示者」、データセット自体を管理する担当者には「所有者」を付与する運用が一般的です。
ダッシュボード作成（3シート構成）
分析を作成し、営業ダッシュボードとして以下の 3 シート構成で組みました。
Sheet 1：営業パイプライン概要
KPI（総商談件数・受注件数・失注件数・進行中件数・受注率・平均商談金額）をカード形式で並べ、商談フェーズのファネルと月次商談件数の推移を配置しました。
Sheet 2：失注分析
失注理由の内訳（ドーナツグラフ）、失注理由 × 業界のヒートマップ、失注理由別の月次推移（折れ線グラフ）を配置しました。
グラフの種類によってフィルターの設定が変わり、設定が不足していると意図しない値が集計されるケースがありました。データの特性に合わせた調整が必要です。
Sheet 3：業界別・取引先別分析
業界別受注率（棒グラフ）、取引先別商談金額（横棒グラフ）、リードソース別受注率（棒グラフ）を配置しました。
フィルター設定の落とし穴
フィルターの設定方法にはいくつか種類があり、選び方を間違えると見た目は設定されているように見えても意図した絞り込みができないケースがあります。フィルタータイプの選択は慎重に行う必要があります。
自然言語で Salesforce データに質問する：トピックの設定
Amazon Quick には、データに対して自然言語で質問できる トピック機能があります。
左サイドバーの「トピック」から新規トピックを作成し、先ほど作成したデータセットを追加します。
フィールドの設定が動作精度に直結する
トピックを作成しただけでは日本語での質問はうまく動きません。フィールドごとに「分析対象として含める」設定・日本語のフレンドリ名・シノニム（同義語）の 3 つを整える必要があります。この設定が 1 つでも抜けると、質問に対して正しく反応しないフィールドが出てきます。
また、データセットで作成した計算フィールドはトピックに自動で引き継がれません。「受注率」のような集計値はトピック内で改めて定義する必要があります。
設定が整った状態で「失注理由の一番多いのは？」と入力するとグラフが表示されました。
チャットエージェントで自然言語分析｜示唆まで自動生成
Amazon Quick のチャットエージェント（My Assistant）でも、トピックを経由してデータに質問できます。
トピックとの違いは、チャットエージェントが会話形式で示唆まで自動生成してくれる点です。試しに失注理由について質問したところ、件数の表に加えて以下のコメントが自動生成されました。
最も多い失注理由は「予算」（6件）です。ただし、失注理由が未入力のケースが12件と最多となっており、データの入力漏れが課題として見受けられます。
数値を返すだけでなく、データの課題まで指摘してくれます。
チャットエージェントはトピックの設定が整っていることが前提です。トピックで認識されていないフィールドはチャットエージェントからも参照できないため、トピックの設計が品質に直結します。
まとめ
- Salesforce との接続はログイン認証で完了するが、運用を見据えた接続アカウントの設計が重要
- 受注率など分析に必要な値は Salesforce のフィールドそのままでは存在しないため、データセット設計の段階で計算フィールドとして定義する必要がある
- ダッシュボードはフィルター設定の落とし穴があり、データの特性に合わせた調整が必要
- Q&A・チャットエージェントはトピックの設定品質が動作精度に直結する。設定漏れがあると日本語で質問しても正しく反応しない
Salesforce にデータが蓄積されているなら、BI ツールである Amazon Quick を組み合わせることで、商談データの可視化から自然言語での分析まで実現できます。データはスケジュール更新で定期的に更新する運用が現実的です。
Amazon Quick の導入・活用をご検討の方へ
サーバーワークスでは、Amazon Quick の導入設計から運用定着までを伴走でご支援する「Amazon Quick 活用支援サービス」を提供しています。本記事で扱った Salesforce データの可視化・自然言語分析のほか、業務情報の検索・分析・自動化など、Amazon Quick を活用したデータ活用基盤の構築をワンストップでご相談いただけます。
Amazon Quick 活用支援サービス｜サーバーワークス
