Agentforce Financial Services（旧Financial Services Cloud）ってなに？

こんにちは、エンジニアの小林です。

フレクトでは Industry Cloud に力を入れており、本記事では、AFSを使いこなせるエンジニアをさらに増やすためのトレーニング用に作った内容を展開したいと思います。

前提

Salesforceの基礎（主にCRM領域）を理解していることを前提としています。
Agentforce Financial Services （旧 Financial Services Cloud（FSC））は金融業界向け Industry Cloud を指します。
主にAFS Core について記載しています。（以前の管理パッケージ版についてはあまり触れていません）
本稿の目的は、この製品が何を解決するか、どの顧客接点で効くか、主要機能とデータモデル、周辺システムとのアーキテクチャを把握することです。

ざっくり概要

AFSでは金融の顧客接点（営業・サービス・手続き・ポータル）向けに、標準Sales Cloud / Service Cloud だけでは足りない世帯・口座・関係性などの業界データモデルと、リレーション管理・ライフイベント・アクションプラン・ドキュメント追跡といった業務機能をまとめて提供する。
AFSではB2C/B2B の混在や家族・関係者を含む関係性、複数口座・商品の俯瞰が前提になるため、「取引先＋取引先責任者」中心の標準モデルとの差分が大きい。
AFSは基幹システムの置き換えではない。System of Engagement（顧客接点）として、基幹システム（System of Record）のデータを活用し360度ビューを構築する。
AFSの導入・開発においては Person Account・世帯の定義・基幹/勘定系とのデータ連携が成否を左右しやすい。
Agentforce Financial Services と銘打っているが、Agentforceは本製品のイチ機能の位置付けです。

1. 何を解決する製品か（製品コンセプト）

金融機関の顧客接点では、下記が同時に起きやすいです。

やりたいこと：顧客の状況を正しく理解し、適切な案内・提案・フォローをしたい
現実：情報が部門やシステムに分断し、確認事項が多く、手続きが複雑で手戻りが起きる

金融の「顧客」は、個人単体で完結しないことが多いです。

家族・受益者・代理人・顧問・共同名義など関係者が多い
預金・ローン・投資・カードなど口座や商品が複数にまたがる
KYC（Know Your Customer：本人確認・顧客審査）、書類、承認などプロセスが長く、例外も多い

Agentforce Financial Services（AFS）は、これらを 1つの顧客360の土台として扱うための Industry Cloud です。標準の CRM オブジェクトに加え、金融向けの専用オブジェクト・画面テンプレート・業務プロセスの仕組みを追加し、Salesforce 上で関係性・口座・手続きを一貫して管理しやすくします。

2. 標準 Salesforce との違い（ざっくり）

観点	標準（Sales/Service）に近い形	AFS
顧客の単位	取引先・取引先責任者が中心	個人取引先（Person Account）、世帯（Account）が中心になりやすい
関係性	取引先と責任者の関係が主	取引先間・責任者間の多様なロール（家族、金融上の関係など）
商品・契約	商談・契約オブジェクト等	金融口座（Financial Account）、保有（Holding）、業態により保険・ローンなど
業務の型	フロー・タスク等で個別設計	アクションプラン、ドキュメント追跡など業界寄りの定型プロセス

3. どの顧客接点で価値が出るか

単一部署向けツールというより、複数部署をまたいで共通の顧客ビューと業務プロセスを使えるよう想定した構成
RM（リレーションシップマネージャー：顧客担当の営業職）/ プライベートバンカー / 支店窓口：世帯・口座・関係性を踏まえた面談・提案・フォロー
コンタクトセンター：問い合わせ内容と顧客コンテキストをケースに載せ、手続きに接続
バックオフィス / 審査・手続き：書類の要求〜受領〜承認の追跡、タスクの抜け漏れ防止
Experience Cloud（顧客ポータル）：提出状況の確認、依頼、セルフサービス（要件に応じて）

4. 主要ユースケース

4.1 顧客360・世帯アプローチ

世帯メンバー、各個人の口座、関係者（受益者・共同名義など）を一つの画面・構造で扱えるようにし、クロスセルやライフプラン、リスクの俯瞰に使います。

4.2 ライフイベントに基づくフォロー

結婚、出産、住宅購入、退職、相続などのライフイベントを記録し、営業・サービスがタイミングを共有できるようにします。アクションプランと組み合わせると、定型フォローを自動で起こしやすくなります。

4.3 オンボーディング・申請・更新などの定型業務

口座開設、ローン申請、契約更新など、手順が決まっている業務をアクションプラン（テンプレート＋タスク）で標準化します。担当者が変わっても同じ品質で進めやすくなります。

4.4 書類・コンプライアンス寄りのプロセス

本人確認、収入証明、住所証明など、必要書類のチェックリストとステータスをドキュメント追跡で管理し、差戻しや再依頼を減らします。承認プロセスやポータル連携と組み合わせる構成も一般的です。

5. 主要機能

5.1 リレーション管理（Relationship）

顧客同士・関係者同士のつながりをロール付きで管理します。家族関係に限らず、顧問・受益者・連帯保証人など金融で必要な関係性を表現できます。

取引先と取引先の関係（Account–Account Relationship ）
取引先責任者同士の関係（Contact–Contact Relationship ）

世帯への積み上げ集計（Rollup）と合わせて、世帯単位の資産・負債の把握に使われます。

Actionable Relationship Center（ARC）：リレーションシップネットワークを視覚的に表示するコンポーネントです。世帯、グループ、商談、ケース、金融口座、ローン、保険契約などを一画面で俯瞰でき、図の中から直接アクション（ケース作成、商談作成、Flow起動等）を実行できます。ドラッグ＆ドロップエディタで複数のARCグラフを作成可能です。

5.2 ライフイベント（Life Event）& ビジネスマイルストーン

人生の節目（結婚、出産、住宅購入など）をオブジェクトとして記録し、営業機会やサービス介入の起点にします。記録したイベントをトリガーとしてワークフローやアクションプランを起動できます。

5.3 アクションプラン（Action Plan）

あらかじめ用意したアクションプラン・テンプレートをもとに、実行用のアクションプランとタスクが自動生成されます。各タスクに期日・リマインダー・担当者を設定でき、タスク間の依存関係や任意タスクの設定も可能です。ドキュメントチェックリストをテンプレートに含めることもできます。フロー・Apexトリガーからの起動や、ライフイベントとの連携も想定された使い方です。

5.4 ドキュメント追跡（Document Tracking）

ドキュメントタイプとチェックリストアイテムで、必要書類の状態（未要求・要求済・受領・承認・却下など）を追跡します。Files（ContentDocument）と組み合わせて実ファイルを紐づけます。

5.5 Interaction Summaries（インタラクションサマリー）

従来の活動（Event/Task）を拡張した、構造化されたミーティング記録です。主な特徴は、参加者の管理、アクションアイテムの追跡、メモへの機密レベル設定などです。Compliant Data Sharingと連携することで、特定の会話内容を限られた関係者のみに共有するといった金融特有のプライバシー要件に対応できます。

5.6 Compliant Data Sharing（コンプライアント・データ共有）

標準の共有モデル（ロール階層、共有ルール等）を上書きせずに、参加者ロール（Participant Role）で細粒度のアクセス制御を追加します。Financial Deal、Interaction Summaryなど、AFS固有のオブジェクトにも対応します。

5.7 Leads & Referrals（リード・紹介管理）

部門をまたいだ紹介ビジネスを管理します。内部紹介（既存クライアントからの紹介）と外部紹介（弁護士、CPA（公認会計士）等の提携専門家からの紹介）を区別して管理でき、Intelligent Need-Based Referralsにより顧客の関心やニーズに基づく自動ルーティングが可能です。

5.8 金融口座・世帯・ウェルス寄りの機能（業態により）

Financial Account / Financial Holding：口座種別、残高、投資内訳など
Household：世帯サマリー、メンバー、関連口座の俯瞰
Financial Goal：目標金額・期限に沿ったゴール管理（ウェルス文脈）
Financial Deal Management：Opportunityを拡張した金融向けディール管理。Compliant Data Sharing対応
Interest Tags：顧客のニーズ・関心事項をタグで記録
Alerts API：トランザクションデータをSalesforceに格納せず外部参照し、注目すべきイベント時にアラートを自動生成
ライセンス・製品ラインにより保険、住宅ローン（Mortgage）などの機能セットが分かれる場合があります

5.9 Action Launcher

Service Edition向けのコンポーネント。サービス担当者がOmniScript、Screen Flow、Autolaunched Flow等をすばやく検索・実行できるランチャーです。

6. データモデル

AFSは標準の取引先・取引先責任者に加え、金融業界向けの専用オブジェクトを多数提供しています。ざっくりした階層イメージは世帯 → 個人 → 金融口座 → 保有銘柄です。

6.1 主要なオブジェクト（概要）

世帯：取引先の Household レコードタイプで世帯を表現し、メンバーの資産を集約する起点
個人（Person Account）：個々の顧客。取引先＋取引先責任者が統合された標準の Person Account
個人間リレーション：Contact 同士の関係を表すオブジェクトで、配偶者・受益者・顧問など金融で必要なロールを定義
取引先間リレーション：Account 同士の関係（法人グループ、親会社・子会社など）
金融口座（Financial Account）：預金・投資・ローン・保険などをレコードタイプで区別する金融専用オブジェクト
保有銘柄（Financial Holding）：投資口座内の個別資産（株式、債券、投資信託等）
残高履歴（Financial Account Balance）：口座残高を日付ごとに子レコードとして保持
積み上げ集計：各口座の残高が世帯レベルに集計され、世帯全体の資産状況を俯瞰できる
標準オブジェクトの商談（Opportunity）、ケース（Case）、リード（Lead）も、口座開設・手続き・問い合わせなどで併用されます。AFSのデータモデルはこれらを置き換えるのではなく、金融特有の階層を追加する形です。
データモデルの全体像（ER図）は公式ヘルプを参照してください：Salesforce Help

6.2 既存組織で管理パッケージがある場合の注意

新規導入では AFS Core（ネイティブ）が前提なので、本稿のデータモデルはそのまま読めます。ただし、過去に管理パッケージ版 AFS を導入済みの組織に入る場合は注意が必要です。金融口座の所有者モデル（ルックアップ vs ジャンクションオブジェクト）、残高の持ち方（単一項目 vs 履歴保持の子オブジェクト）など、データ構造に差がある箇所があります。
Object Manager 上で同じラベルのオブジェクトが標準（ネイティブ）とカスタム（FinServ__ 付き）で二重に見えることもあります。既存組織を触る際は、どちらのモデルで動いているかをスキーマビルダーで確認してから着手してください。

6.3 業種別データモデル

コアデータモデルに加えて、業種ごとに専用のデータモデルがあります。
保険データモデル：保険契約、補償範囲、クレーム、見積、グループ契約、募集人管理
住宅ローンデータモデル：ローン申請〜審査〜実行のプロセス
KYCデータモデル：Discovery Frameworkと組み合わせた規制準拠のオンボーディング

7. システムアーキテクチャ ── AFSと周辺システムの全体像

AFSは System of Engagement（顧客接点のシステム）として位置づけられ、既存の基幹システム群（System of Record）と連携して顧客の360度ビューを構築します。

7.1 全体構成パターン例

7.2 設計原則: CRMのスコープを明確にする

AFSは基幹システムの置き換えではない。勘定系やカストディアンが「台帳の正」であり続けます。AFSはそこから必要なデータを取得・表示して顧客対応に使う「顧客接点の器」です。この原則から導かれる設計判断は2つあります。 ※カストディアンとは：主に機関投資家や外国投資家に代わって、株式や債券などの有価証券の「保管・管理」を専門に行う金融機関（主に信託銀行や銀行）のことです

① どのデータをAFSに格納し、何を外部参照にとどめるか

AFS（Salesforce）に格納するもの	外部参照（格納しない）が一般的
顧客マスター（氏名、連絡先等）	取引明細（トランザクション）
世帯構造・リレーションシップ	大量の過去取引履歴
金融口座のサマリー情報	リアルタイム時価・相場情報
ライフイベント・活動履歴	会計仕訳・経理データ
ケース・商談・アクションプラン	-

取引明細はData 360経由での Zero Copy や、Alerts APIで注目イベントだけを通知する構成が一般的です。 ② データの流れの方向

基幹→AFS（片方向）が基本：口座残高・ポジション情報の反映など
AFS→基幹（書き戻し）が必要なケースもある：住所変更、新規口座開設申請など
双方向の場合はマスタの正と競合時のルールを明確にしておく

7.3 業種別の典型的な連携パターン

リテールバンキング

コアバンキング（勘定系）との連携が最重要です。

顧客マスター同期：コアバンキング→（MuleSoft）→AFS。逆方向の住所変更等も必要に応じて実装
金融口座・残高同期：口座情報とサマリー残高をAFSに連携し、全口座を一画面で確認可能に
トランザクションデータ：Data 360経由で仮想参照。注目イベントはAlerts APIで通知
ローンオリジネーション：nCinoやBlend等とAFSを連携し、申請→承認→記帳（Book-to-Core）を管理

ウェルスマネジメント

カストディアンとの連携が中心です。

カストディアンデータフィード：Schwab、Fidelity、Pershing等から口座・ポジション・パフォーマンスデータを連携（夜間バッチが一般的、AFS Coreではリアルタイム対応が強化されている）
ポートフォリオ管理：Orion、Black Diamond、Tamarac、Addepar等との連携
ファイナンシャルプランニング：eMoney、MoneyGuidePro、RightCapital等との連携

保険

保険基幹システム（ポリシー管理、クレーム処理）との連携が中心です。OmniStudio（旧Vlocity）のInsurance機能と組み合わせるケースが多くあります。

7.4 連携設計時の考慮事項

バッチ vs リアルタイム：カストディアンデータや口座残高は夜間バッチが多い一方、顧客マスター変更や重要アラートはリアルタイム/ニアリアルタイムが求められます。Platform Events、Change Data Capture、Kafka等のイベントドリブン手法を検討してください。

データ量とガバナ制限：金融機関のデータ量はSalesforceのガバナ制限に容易に抵触します。Bulk API、非同期処理、Data 360によるオフロードなど、大規模データ向けの設計パターンが不可欠です。

セキュリティ：金融データの連携にはデータの暗号化（転送中・保存時）、アクセス制御、監査ログが必須です。Salesforce Shield（フィールドレベル暗号化、イベントモニタリング）やMuleSoftのセキュリティ機能を組み合わせます。

BIANモデル：AFSの連携APIはBIAN（Banking Industry Architecture Network）の標準データモデルに準拠した設計が可能です。業界標準に沿うことで、将来的なシステム変更時の影響を最小化できます。

8. エディション構成と業種別アプリ

8.1 エディション

Sales Edition：ウェルスマネジメント・資産運用向け。Financial Deal Management、Interaction Summaries、Compliant Data Sharing、支店・プラクティス管理など
Service Edition：リテールバンキング向け。発信者ID確認、タイムライン、監査証跡、Action Launcher、苦情管理など
Sales & Service Edition：両方の機能を統合。複数業務ラインを持つ大規模金融機関向け

8.2 業種別アプリケーション

Wealth Management：クライアントの全体像を一画面で把握、プランニングツール連携、Client Segmentation App
Retail Banking：顧客プロファイル・口座一元表示、KYC/Discovery Framework
Insurance：保険データモデルによる契約・クレーム・見積管理
Mortgage Lending：ローン処理の単一ビュー管理、分析ダッシュボード

9. 導入の勘所

9.1 最初に固めるべきこと

Person Account の有効化判断：元に戻せないため、既存データとの移行・併用を早めに検討する。カストディアン等の連携先がどちらのモデルに対応しているかも確認
世帯の定義：「誰を同一世帯とみなすか」同居/別居、成年子、法人オーナーなど、定義を明確にする
基幹連携のスコープ：CRMに何を載せ、何を載せないかを明確にする（7.2参照）

9.2 よくあるつまずきポイント

データモデルの理解不足：世帯・リレーションシップ・金融口座の3層構造を把握しないまま設計に入ると手戻りが多い
大規模データボリューム（LDV）：世帯単位の積み上げ集計がパフォーマンスのボトルネックになりがち。インデックス設計、SOQLの最適化、非同期処理が必要
共有設計の複雑化：Compliant Data SharingやRelationship-Based Sharingは強力だが、複雑になるとパフォーマンスに影響。早い段階で設計を固める
権限セットライセンスと権限セットの割り当て：AFSでは機能ごとに権限セットが分かれています（例：Financial Services Cloud、Action Plans、Document Checklist、Digital Lending、Digital Insurance、Business Rules Engine など）。利用する機能に対応するPSLをユーザーに割り当てたうえで、適切な権限セットを付与する必要があります。名称や構成はエディション・環境により異なるため、設定の「権限セットライセンス」画面で実際に利用可能なものを確認してください
OmniStudioが必要になる領域：保険商品の設計・見積フローやデジタルレンディング（ローン申請のガイド付きUI）など、一部の機能は OmniStudio（OmniScript / FlexCard / DataRaptor 等）を前提としています。Flow / Apex / LWC とは設計思想が異なる別スキルセットになるため、対象機能を使う場合は体制・見積に早めに反映してください

10. まとめ

Agentforce Financial Services（AFS）は、金融の顧客接点のための Industry Cloud で、世帯・口座・関係性と定型プロセス・書類追跡が核になる
価値は 360度ビュー、世帯単位の提案、手続き品質の均一化に現れやすい
システム全体では System of Engagement として基幹（System of Record）と連携し、MuleSoft / Data 360 が統合レイヤーを担う
導入では Person Account・世帯ルール・データ連携スコープを最初に固めると、後工程が楽になる