製品体系・データモデル・案件/プロジェクト概念・AI・業種別活用

2026年7月版

本資料はSalesforceが提供するCRM・エンタープライズプラットフォームについて、製品体系・データアーキテクチャ・案件（Opportunity）/プロジェクト/ケースの中核概念・AIエージェント機能・業種別活用事例を体系的に解説する。Salesforce公開情報・Forrester研究・業界調査（2025〜2026年）に基づく内容であり、CRM戦略立案・システム設計の参照資料として活用されることを目的とする。

第一章　Salesforceの概要と事業

1-1　企業概要

• 社名：Salesforce, Inc.（米国カリフォルニア州サンフランシスコ本社）

• 1999年設立：Marc Benioff（元Oracle）がHawaii州のアパートから「The End of Software（ソフトウェアの終焉）」をスローガンに創業。CRMのSaaS提供を世界に先駆けて実現した先駆者

• 2026年時点の規模：年間売上約370億ドル（約5.6兆円）・世界従業員約73,000名・世界150,000社以上の顧客企業

• 2026年2月時点：Forbes Global 2000に名を連ね、「World's Most Innovative Companies」に12年連続ランクイン（Forbes 2024）

指標	2024年度（FY2024）	2025年度（FY2025）	成長トレンド
年間売上高	約344億ドル	約374億ドル	前年比9%成長
顧客数	150,000社以上	150,000社以上	大企業への深耕が中心
Agentforce案件数（AI）	新製品のためFY24なし	29,000件以上（Q4 FY25のみ）	四半期で急拡大
Agentforce ARR	–	約8億ドル（FY25年間見通し）	FY26は10億ドル超が目標

1-2　製品ブランド体系（2025年リブランディング後）

Salesforceは2025年にAgentforceブランドへの移行を発表し、従来の「〇〇 Cloud」という製品命名体系を「Agentforce for〇〇」形式に再構成した。

旧ブランド名	新ブランド名（2025〜）	主な機能カテゴリ	主なユーザー
Sales Cloud	Agentforce Sales	SFA・商談管理・予測・パートナー管理	営業担当者・営業マネジャー
Service Cloud	Agentforce Service	ケース管理・サポート・フィールドサービス	CSR・サポートチーム・フィールド技術者
Marketing Cloud / Pardot	Agentforce Marketing / Account Engagement	メール・SNS・広告・リードナーチャリング・B2B MA	マーケティング担当・デジタルマーケター
Commerce Cloud	Agentforce Commerce	BtoB/BtoC ECサイト・注文管理・リピート購入	Eコマース担当・マーチャンダイザー
Analytics Cloud / Tableau	Tableau + Salesforce Analytics	BIダッシュボード・セルフサービス分析・AI予測	経営者・事業責任者・データアナリスト
Data Cloud（旧Genie）	Salesforce Data 360	顧客データプラットフォーム（CDP）・IDグラフ・リアルタイムデータ統合	データエンジニア・MAチーム
Einstein AI	Agentforce AI	AIエージェント基盤・Einstein Copilot・予測・推奨	全製品共通基盤
MuleSoft	MuleSoft（変わらず）	API連携・データ統合・iPaaS	統合担当・開発者
Slack	Slack（変わらず）	チームコラボレーション・CRMとの連携	全社員

第二章　Salesforceのデータモデル詳解

2-1　Salesforceデータモデルの基本概念

Salesforceのデータモデルはリレーショナルデータベースの考え方を継承しているが、「プログラミングをしないでビジネス担当者がデータ構造をカスタマイズできる」という設計思想が特徴的である。データモデルを理解することはSalesforceの設計・活用の根幹となる。

オブジェクト（Object）とレコード（Record）

• オブジェクト（Object）：データベースにおける「テーブル」に相当する概念。Salesforce上のすべてのデータはオブジェクトに格納される。例：Account（取引先）・Opportunity（商談）・Contact（取引先責任者）・Case（ケース）

• レコード（Record）：各オブジェクトの個別データ行。例：「A株式会社」という1行のAccountレコード・「プロジェクトXの提案」という1行のOpportunityレコード

• フィールド（Field）：レコードの各属性（列）。名前・電話番号・金額・日付等の情報を格納する。標準フィールド（Salesforceが定義済み）とカスタムフィールド（管理者が追加）がある

標準オブジェクトとカスタムオブジェクト

種類	定義	例	変更可能範囲
標準オブジェクト （Standard Objects）	Salesforceが事前定義したオブジェクト。CRMの基本概念を表現する	Account・Contact・Lead・Opportunity・Case・Campaign・Task・Event・Product・Pricebook	フィールド追加・レコードタイプ追加は可能。コアロジック・ステータス遷移の変更は不可
カスタムオブジェクト （Custom Objects）	企業の業務固有のデータを格納するために管理者・開発者が作成するオブジェクト	（例）製造業：「設備（Machine__c）」「不良報告（Defect__c）」「見積明細（QuoteLineItem__c）」	オブジェクト定義・フィールド・リレーション・ロジック等をすべて自由に設計可能

2-2　オブジェクト間リレーションシップ

Salesforceにおけるオブジェクト間の関係（リレーションシップ）はデータモデル設計の中核である。3種類の主要リレーションシップを使い分けることで、業務のデータ構造を柔軟にモデリングできる。

（1）ルックアップリレーション（Lookup Relationship）

2つのオブジェクトを参照（ルックアップ）で緩く結合する関係。子レコードは親レコードが削除されても独立して存在し続ける。最も汎用的に使われるリレーションシップ。

• 例：Contact（取引先責任者）と Account（取引先）のリレーション。ContactからAccount を参照するが、Accountを削除してもContactは削除されない

• 特徴：所有権（Owner）が子レコードに独立して存在。集計フィールド（Roll-Up Summary）は使えない。アクセス権限が独立

（2）主従リレーション（Master-Detail Relationship）

親（Master）と子（Detail）が強く依存する親子関係。親レコードが削除されると子レコードが自動的に削除される。レポート集計（Roll-Up Summary）フィールドが使える。

• 例：機会（Opportunity）とその明細（Opportunity Line Item）。Opportunityが削除されるとLine Itemも削除

• 特徴：子レコードは親の所有者・アクセス権を継承。1つのオブジェクトに最大2つの主従リレーション設定可能。集計フィールド（合計・最大・最小・件数）が自動計算可能

（3）多対多リレーション（Many-to-Many via Junction Object）

1つのレコードが複数の別レコードと関係を持つ「多対多」の関係は、ジャンクションオブジェクト（Junction Object）という中間テーブルオブジェクトで実装する。

• 例①：Campaign（キャンペーン）と Contact（顧客）は多対多。1つのキャンペーンに複数顧客・1人の顧客が複数キャンペーンに参加。→ CampaignMember（ジャンクション）が両者を結合

• 例②：Account（取引先）と Opportunity（商談）の担当者チーム。1商談に複数担当者・1担当者が複数商談。→ OpportunityTeamMember（ジャンクション）

• 実装方法：ジャンクションオブジェクトに2つの主従リレーションを設定。それぞれのマスターオブジェクトを指定

Account（取引先）

1以上の商談・ケース・コンタクトを持つ

▶ Opportunity（商談） ▶ Contact（取引先責任者） ▶ Case（ケース） ▶ Activity（活動）

図1：Account（取引先）を中心としたオブジェクトリレーション

2-3　主要標準オブジェクトの詳細

Account（取引先）

Accountはビジネスの取引相手となる「企業・組織」を表すオブジェクトで、Salesforceデータモデルの中心に位置する。営業・サービス・マーケティングのすべてがAccountを軸に関連付けられる。

フィールド分類	主なフィールド	設計上の注意点
識別情報	Account Name（取引先名）・Account Number・Type（顧客区分：Customer/Partner/Prospect等）	Account Nameの名寄せ・重複管理が長期運用上の最重要課題。正規化ルール（法人格表記）を決める
組織情報	Industry（業種）・Annual Revenue（年間売上）・Number of Employees（従業員数）・Ownership（上場区分）	標準ピックリスト値をビジネスに合わせカスタマイズ。レポート分析のグループ軸になる
階層関係	Parent Account（親取引先）→ Account Hierarchy（階層）	グローバル企業の親子・子孫関係を表現。本社→地域統括→子会社の3層構造など
所有権	Owner（Account Owner）	Account Ownerがすべての紐付き商談・ケース・活動の所有権・参照権を持つ。組織設計と直結

Contact（取引先責任者）

ContactはAccountに紐付く「個人」を表すオブジェクト。Accountが企業、ContactがそのAccount内の窓口となる個人（キーパーソン）に相当する。1つのAccountに複数のContactが紐付く（1対多）。

• 主なフィールド：First/Last Name・Title（役職）・Department（部署）・Email・Phone・Reports To（上司のContact）・Account Name（親Account参照）

• 設計ポイント：「Reports To」フィールドを活用するとContact間の組織図（上司・部下関係）を表現できる。B2Bでは購買決定者・技術担当・経営者といった関与者を複数Contact登録して商談に関連付ける「Contact Role」設定が重要

Lead（リード）

Leadは「見込み客」を表すオブジェクトで、まだ取引先として登録する前の段階の問い合わせ・展示会名刺・Webフォーム入力等を格納する。見込みの質（商談化可能性）が確認された時点でリード変換（Lead Conversion）を行い、Account・Contact・Opportunityの3レコードに変換される。

Lead （見込み客）

▶

資格確認 （Qualification）

▶

Lead Conversion （リード変換）

▶

Account +Contact +Opportunity

▶

商談クローズ （Deal）

図2：Lead から Opportunity へのコンバージョンフロー

• 変換前：Lead単体のレコード。Account・Contactとは連携なし。マーケティングが管理

• 変換条件の判断：BANT基準（Budget予算・Authority決裁権限・Need必要性・Timeline導入時期）等を満たした段階で変換。変換基準はビジネスに合わせてカスタム設計

• 変換時の3オブジェクト生成：既存AccountがあればマッチングしてContactのみ新規作成、なければAccount/Contact/Opportunityをすべて新規生成

⚠ LeadとContactは「同一人物」を指す場合も別オブジェクトとして存在する。Lead変換前の活動（メール・コール）はOpportunityに紐付かないため、変換タイミングの設計が商談履歴の完全性に影響する。

2-4　案件・商談の概念：Opportunity（商談）オブジェクト

Opportunity（商談）はSalesforceの営業管理における中心概念であり、「1件の売上を生む可能性のある特定案件」を表すオブジェクトである。パイプライン管理・売上予測・営業マネジメントのすべてがOpportunityを中心に構成される。

商談ステージ（Opportunity Stage）の設計

商談ステージは営業プロセスの現在地を示す最重要フィールドである。標準値として「Prospecting→Qualification→Needs Analysis→Value Proposition→Id. Decision Makers→Perception Analysis→Proposal/Price Quote→Negotiation/Review→Closed Won→Closed Lost」が用意されているが、実際の導入では自社営業プロセスに合わせてカスタマイズする。

商談ステージ設計要素	内容	設計上のポイント
ステージ名	営業プロセスの各ステップを表す名称	自社のメソドロジー（MEDDIC/SPIN/チャレンジャーセール等）に合わせて命名。他部門（SE・PM）との合意も必要
確度（Probability）	そのステージでの受注確率（%）。デフォルト値を設定しておきレポートで重み付け集計	組織全体でこの確率の意味を統一。主観的な「感覚値」でなく、過去実績に基づく統計的確率にすることで予測精度が上がる
必須フィールド（Entry Criteria）	次ステージに進む前に必須入力すべきフィールドを設定。例：Qualificationへ進む前に「予算」「決裁者名」の入力を義務付け	Validation Ruleで強制するか、ガイドを示すにとどめるかはチーム文化に合わせる
クローズ予定日 （Close Date）	受注または失注が確定する見込み日	毎週・毎月のパイプラインレビューで確認。「永遠に先延ばし」案件の管理ルール設計が重要
金額（Amount）	受注した場合の売上見込み額	SaaS：ARR（年間経常収益）で記録。製品販売：受注時の1回売上。計算方法を統一してレポートの比較可能性を確保

OpportunityとActivity（活動）の連携

• Task（ToDo）：メール送信・電話・書類提出等の単発タスクをOpportunityに紐付けて記録。担当者の「やること」リストとして機能

• Event（行事）：商談に関連する打合せ・デモ・プレゼンを時間枠付きで記録。カレンダーとの同期（Google Calendar/Outlook連携）

• Activity Timeline：OpportunityレコードのTimelineビューで、商談に紐付くすべての活動（通話・メール・打合せ・メモ）が時系列で表示される

関連オブジェクト：Quote（見積）・Opportunity Line Item（商品明細）

• Quote（見積）：OpportunityからQuoteを作成し、価格・数量・割引・条件を記載した見積書をPDF出力。CPQ（Configure Price Quote）製品との連携でより複雑な製品構成・価格計算を実現

• Opportunity Line Item（商品明細）：OpportunityにProduct（製品）を紐付ける。Price Book（価格表）から価格を引用し、Opportunity Amountに自動集計

2-5　ケース管理の概念：Case（ケース）オブジェクト

Case（ケース）はService Cloud（Agentforce Service）の中心オブジェクトであり、「顧客からの問い合わせ・クレーム・サポートリクエスト」を1件ずつ管理する。Opportunityが「売上を生む案件」を管理するのに対して、Caseは「発生した問題を解決する案件」を管理する。

Caseのライフサイクル

問い合わせ受付 （Web/Email/電話）

▶

自動ケース作成 （Omni-Channel）

▶

担当者アサイン （スキルベース）

▶

調査・対応 （ナレッジ活用）

▶

ケースクローズ （解決・顧客確認）

図3：Case（ケース）のライフサイクル

• 受付チャネル：Web-to-Case（Webフォーム）・Email-to-Case（メール自動変換）・電話（CTI連携）・SNSダイレクトメッセージ・チャット

• Omni-Channel Routing：担当者のスキル・空き状況・言語対応力に基づいてケースを自動振り分け。スキルベースルーティングで「製品知識を持つ担当者」に適切なケースが届く

• ナレッジ連携：CaseにKnowledge Article（ナレッジ記事）を紐付けて参照・活用。AIがケース内容から関連記事を自動サジェスト（Einstein Knowledge Base）

• エスカレーション：未解決のまま経過時間が閾値を超えるとマネジャーに自動エスカレーション（Escalation Rules）

• SLA管理（Entitlement）：顧客契約（サポートプラン）に応じた対応時間目標（SLA）をEntitlementオブジェクトで管理。SLA違反リスクを事前アラート

2-6　プロジェクト管理の概念：Salesforceにおけるプロジェクト

Salesforce標準機能には「汎用的なプロジェクト管理オブジェクト」は存在しないが、業種・用途に応じて複数のアプローチが存在する。Salesforceでプロジェクトを管理する4つの主要パターンを解説する。

パターン①：Opportunity→プロジェクト移行（受注案件の実行管理）

製造業・SIer・コンサルティング業等では「受注した商談（Opportunity）を実行プロジェクトに移行する」という業務フローが多い。SalesforceではOpportunityがWon（受注）になった後、カスタムオブジェクト「Project__c（プロジェクト）」を自動作成してOpportunityに紐付けるパターンが一般的である。

• 実装例：OpportunityのClosed Won時にフローまたはApex TriggerがProject__cレコードを自動作成。Project__cにはプロジェクトコード・開始日・終了日・PL（プロジェクトリーダー）・予算等のフィールドを設計

• Project__c ← Milestone__c（マイルストーン）← Task__c（タスク）という1対多の階層でWBS的な進捗管理が実現可能

パターン②：Salesforce Maps＋プロジェクトカスタムオブジェクト

フィールドサービス（保守・施工・点検等）ではSalesforce Mapsや独立したフィールドサービスプロジェクト管理の仕組みをカスタムオブジェクトで構築するケースが多い。

パターン③：AppExchange製品の活用（TaskRay / Ganttic / Inspire Planner等）

Salesforce AppExchange（アプリケーションマーケットプレイス）にはGanttチャート・タスク管理・工数トラッキングを提供するプロジェクト管理アプリが多数公開されている。コードなしでSalesforceに統合でき、独自開発より実装が速い。代表製品：TaskRay・Inspire Planner・Ganttic。

パターン④：Industry Cloudのプロジェクト概念

• Manufacturing Cloud：受注生産（Make-to-Order）における「受注案件（Account Forecast）」と製造オーダーの連携管理。案件受注量とキャパシティを照合するRun Rate Agreement機能

• Salesforce for Construction：建設プロジェクトの工程・予算・サブコン管理に特化したデータモデル

• Professional Services Cloud：コンサルティング・SIプロジェクトの工数・リソース・マイルストーン管理

2-7　RecordTypeとPageLayout：データ見せ方の設計

Record Type（レコードタイプ）

Record Typeは同一オブジェクト内で「異なるビジネスプロセス・ピックリスト値・ページレイアウト」を持つ複数の「型」を定義する機能。例えばOpportunityオブジェクトに「新規顧客提案型」「既存顧客更新型」「パートナー経由型」という3つのRecord Typeを設定し、それぞれ異なる必須フィールド・ステージ値・承認フローを適用できる。

• 使用例：Account Typeが「大手製造業」の場合は製造業向けページレイアウト・ピックリスト値・必須フィールドを表示。「流通業」の場合は流通業向け設定を表示

• ユーザーがレコード新規作成時にRecord Typeを選択→選択したTypeに対応したPageLayoutとプロセスが起動

Page Layout（ページレイアウト）

Page Layoutはレコード詳細画面のフィールド配置・セクション・関連リスト・ボタンの表示設定。Record Typeとのマッピングで「どのユーザーがどのPageLayoutを見るか」を制御する。管理者がドラッグ&ドロップGUIで設計でき、コーディング不要。

第三章　Agentforce AI：インテリジェントCRMの実装

3-1　Agentforceとは

Agentforce（旧Einstein）はSalesforceが提供するAI基盤であり、2024年以降は「AIエージェント」としてエンドユーザーの業務に自律的に介入するアーキテクチャに進化した。単なる予測・推奨にとどまらず、「コンテキストを理解して行動する自律エージェント」として、人間の承認なしに特定タスクを完了する機能を持つ。

3-2　主要AIエージェント機能

エージェント機能	対象製品	できること	実績・ベンチマーク
Einstein Sales Coach （商談コーチング）	Agentforce Sales	商談メール・通話記録をAIが解析し、次のアクション提案・トーク改善ヒント・リスク検知を提供	営業担当者のコーチング時間30%削減（Salesforce TEI）
Einstein Opportunity Scoring （商談スコアリング）	Agentforce Sales	商談の受注確率をAIが動的に算出。「リスクシグナル（会議キャンセル・メール未返信）」を自動検知してアラート	予測精度：人手判断比30〜40%向上
Einstein Forecasting （AI予測）	Agentforce Sales	過去の受注パターン・季節性・担当者のヒストリーをAIが分析して売上予測を自動生成。「楽観・悲観・最頻値」を3シナリオで提示	予測精度96%（AI活用）vs 66%（人手のみ）
Agentforce SDR （自律営業開発エージェント）	Agentforce Sales	AIがWebフォームからのリードに自動返信・資格確認・デモ日程調整まで自律実行。担当者が不在でも24時間対応	Salesforce自社導入事例：SDR業務の35%をAIが自動処理
Agentforce Case Classifier （ケース自動分類）	Agentforce Service	受信ケースをAIがカテゴリ・緊急度・担当部署に自動分類。Omni-Channelへ自動ルーティング	ケース分類工数90%削減（複数顧客事例）
Einstein Article Recommendations （ナレッジ推奨）	Agentforce Service	ケース内容をAIが解析して関連Knowledge Articleを自動サジェスト。担当者のナレッジ検索時間削減	平均処理時間（AHT）25%削減
Einstein Lead Scoring （リードスコアリング）	Agentforce Marketing	リードの購買確率をAIが10点満点でスコアリング。マーケティングチームが高確度リードに集中できる	リードコンバージョン率平均20〜30%向上（Salesforce調査）
Data 360 / Identity Resolution	Data 360	複数ソースの顧客データ（CRM・ECサイト・SNS・IoT）を統合してユニークな顧客IDグラフを構築	顧客データ統合精度95%以上（実装事例）

第四章　主要製品の機能詳細

4-1　Agentforce Sales（旧Sales Cloud）

SFA（営業力自動化）の中核機能

• パイプライン管理：Opportunityステージ別のパイプラインビュー（Kanban・リスト・予測）。商談の滞留検知・アクション推進

• 活動管理：メール・電話・打合せをOpportunityに自動紐付け（Einstein Activity Capture）。CRM入力の手間を削減

• Sales Engagement（旧High Velocity Sales）：メールシーケンス・自動フォローアップ・コールスクリプト・SDRの生産性ツール

• パートナー管理（PRM）：代理店・ディストリビューター向けのパートナーポータル。リード共有・商談登録・報告書提出を代理店がセルフサービスで実施

• Quote/CPQ（Configure Price Quote）：複雑な製品構成・価格計算・割引承認フローを自動化。大規模製品カタログでの見積処理を効率化

4-2　Agentforce Service（旧Service Cloud）

オムニチャネル顧客対応基盤

• Einstein Bots：自然言語処理によるチャットボット。一般的な問い合わせ（FAQ・ステータス確認・予約変更）をAIが自律対応。解決できない場合は人間の担当者にスムーズに引き継ぎ

• フィールドサービス：訪問技術者の派遣管理。AIによる最適スケジューリング・地図ルート最適化・モバイル作業報告

• Messaging：WhatsApp・LINE・WeChat・Facebook Messenger等のSNSメッセージをSalesforce上で統一管理

• Einstein Conversation Mining：大量の過去ケース・チャット履歴をAIが分析し、頻出問題・ナレッジギャップ・ボット化候補を特定

4-3　Salesforce Data 360（旧Data Cloud）

Data 360（旧Genie/Data Cloud）はSalesforceのカスタマーデータプラットフォーム（CDP）であり、複数ソースの顧客データを統合してリアルタイムの顧客理解を実現する基盤製品である。

• データ収集：Webサイト行動・ECサイト購買・CRMデータ・IoTセンサー・外部DMP・MA・コールセンターのすべてのデータソースをリアルタイムで収集

• Identity Resolution（IDグラフ）：同一顧客が異なるチャネルで使うメール・デバイス・Cookie・顧客ID等を統合して1つの顧客プロファイルとして管理（ゴールデンレコード）

• セグメンテーション：リアルタイムセグメント（購買直後のユーザー・60日間未購入のユーザー等）をDragg&Drop GUIで作成。作成したセグメントをMarketing CloudのメールキャンペーンやAdvertising Cloud（有料広告）に即時連携

• Calculated Insights：SQLなしで独自KPI（顧客LTV・購買頻度・チャーンリスクスコア等）を定義してすべての顧客プロファイルに追加計算

第五章　業種別活用事例とROI

5-1　製造業での活用事例

事例1：大手産業機器メーカー（Forrester TEI調査）

Forrester Consulting社がSalesforce委託で実施したTotal Economic Impact調査（2025年）で、製造業における典型的な導入効果が分析されている。インタビュー対象は複数の製造業企業で、コンポジット（合成）企業として年商10億ドル・500人の営業組織を想定したモデルである。

• ROI：354%（3年間・投資回収期間5ヶ月未満）

• 営業生産性向上：Sales Cloudの活動記録自動化により営業担当者1人あたり週2.5時間の管理業務削減。削減分を顧客対話・商談活動に充当

• 受注率向上：Einstein Opportunity Scoringによりリスク商談を早期検知し、マネジャーによる的確な支援が可能に。受注率が平均8%ポイント改善

• 予測精度向上：Einstein Forecastingで月次売上予測の精度が±15%以内に改善（従来±35%）。生産計画・在庫確保の精度向上に間接貢献

事例2：グローバル自動車部品メーカーのパートナー管理改革

欧州に本社を置く大手自動車部品メーカー（年商30億ドル超）が、150社の代理店・ディストリビューターのパートナー管理をSalesforce PRMで改革した。

• 導入前の課題：代理店ごとに異なるシステム・Excelで商談進捗を報告。統合パイプラインビューがなく、重複商談や競合他社への並行提案が発生

• 導入効果：代理店商談のSalesforce登録率100%達成。本社での統合パイプラインビジビリティ確保。二重商談（チャネルコンフリクト）を35%削減

• AIスコアリング：代理店が登録した商談にEinstein Scoringが自動適用。本社営業が注力すべき高確度商談を瞬時に特定可能に

事例3：精密機器メーカーのService Cloud導入

精密計測機器を製造するメーカーが、Service Cloudを導入してフィールドサービスと顧客サポートを統合した。

• 課題：電話・メール・訪問対応が分断。顧客の過去対応履歴が技術者に伝わらない。スペア部品の手配に平均3日かかる

• 導入効果：Einstein Botsが電話問い合わせの42%を自動解決（レベル1対応のAI自動化）。担当者の平均処理時間（AHT）を28%削減。フィールド技術者への情報共有により初回解決率が62%→81%に向上

5-2　金融・保険業での活用

事例：大手生命保険会社の代理店管理・顧客接触最適化

• 課題：10,000人超の保険代理士の活動管理・教育・規制コンプライアンス追跡が煩雑。顧客への接触頻度・次回提案タイミングが属人化

• 導入：Financial Services Cloud（金融業界特化データモデル）を採用。Household（世帯）オブジェクトで家族単位の資産・保険状況を管理。Einstein Recommendation Engineが次回の保険商品提案内容と最適な接触タイミングを提示

• 効果：代理士1人あたりの管理顧客数が平均23%増加。コンプライアンス記録の自動保存により規制対応工数を40%削減

5-3　小売・消費財での活用

事例：大手食品メーカーの流通チャネル管理

• 課題：スーパー・コンビニ・量販店等の流通バイヤーとの商談をExcelと電話で管理。棚割交渉の進捗・条件が共有されていない。プロモーション費用の実績追跡が困難

• 導入：Consumer Goods Cloud（消費財業界特化モデル）を採用。Retail Execution（棚割・陳列状況のモバイル確認）とField Activity Management（フィールド営業の店舗活動記録）を統合

• 効果：バイヤーとの商談進捗の見える化。プロモーション費用の支出対売上効果の可視化により、費用対効果の高いキャンペーンに予算を集中投資。初年度のプロモーション投資効率が18%向上

第六章　技術アーキテクチャと拡張性

6-1　Salesforce Platformのメタデータ駆動アーキテクチャ

SalesforceはマルチテナントSaaSとして設計されており、全顧客が同一のコードベース・インフラを共有しながら、各テナント（企業）のカスタマイズ内容がメタデータとして分離管理される。これがSalesforceの「アップグレードしてもカスタマイズが消えない」という特徴の根拠である。

開発・カスタマイズの4レイヤー

レイヤー	手段	担当者	例
設定（Configuration）	GUI（管理者画面）	Salesforce管理者（ノーコード）	フィールド追加・ページレイアウト・承認フロー・Flow（Visual）
自動化（Automation）	Flow Builder・Process Builder	Salesforce管理者（ローコード）	商談受注時の自動メール送信・タスク生成・オブジェクト更新
カスタム開発（Development）	Apex（Java系言語）・LWC（Lightning Web Components）	Salesforce開発者（プロコード）	複雑なビジネスロジック・カスタムUI・Batch処理
統合（Integration）	REST/SOAP API・MuleSoft・イベントドリブン（Platform Events）	統合アーキテクト・開発者	外部ERP・SCM・会計システムとのリアルタイム連携

6-2　MuleSoftによる統合アーキテクチャ

MuleSoft（2018年にSalesforceが65億ドルで買収）はAPIベースの統合プラットフォームであり、Salesforceと外部システム（SAP・Oracle・Workday・各種レガシーシステム）を結ぶ統合層として機能する。「Anypoint Platform」上でAPI設計・実装・管理・モニタリングを一元化できる。

• API-led Connectivity：System API（システム直結）→Process API（業務プロセス）→Experience API（UI/アプリ向け）の3層アーキテクチャ。再利用可能なAPIライブラリで統合設計を標準化

• 既製コネクタ（Connectors）：SAP・Workday・Oracle・Salesforce・AWSサービス等への接続コネクタが多数提供。カスタム実装なしで接続可能なシステムが多い

まとめ：Salesforceの「できること」と「できないこと」

区分	内容
✅ できること（強み）	顧客とのすべての接点（営業・CS・マーケ・EC）を1プラットフォームに統合・オブジェクトとフィールドの柔軟な追加（ノーコード）・アジャイルなUIカスタマイズ・AIによる商談スコアリング・売上予測・ケース自動分類・AppExchange 7,000+アプリとのエコシステム活用
⚠ 条件付きで可	カスタムオブジェクトによる業務固有データモデルの設計（設計スキルが必要）・Apex/LWCによる複雑なカスタムロジックの実装（開発リソースが必要）・MuleSoftによる基幹系との統合（ライセンス・実装コストが大きい）
❌ 難しい・注意が必要	在庫管理・製造工程・会計仕訳・生産計画のERPコア業務（SalesforceはCRM。ERP機能はない）・超大量データ（億件オーダー）のリアルタイム処理（SOQL 50,000件/トランザクション等のガバナ制限あり）・オンプレミス展開（Salesforceは完全クラウドSaaS。プライベートクラウドはない）

（本資料はSalesforce公開情報・Forrester Total Economic Impact Study・Gartner調査（2025〜2026年）に基づき作成。）