Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

保険契約補償範囲、資産、取引について知識を深める

学習の目的

この単元を完了すると、次のことができるようになります。

  • 一般的な保険契約の主な属性を挙げる。
  • 補償範囲の詳細の背後にあるデータモデルについて理解する。
  • 支払情報をモデル化するアプローチを説明する。
  • 保険データモデルで労働者災害補償保険契約をサポートする方法を説明する。

保険契約の基本

保険データモデルでは、保険契約と請求の概要に関連するすべての情報が Salesforce に取り込まれるため、保険契約者の全体像を把握することができます。では、ある保険契約者について、Cumulus がこれを行う様子をみていきましょう。

Cumulus の顧客、Anna Murphy

Anna Murphy は、Cumulus の長年にわたる富裕層の顧客で、同社とは複数のリレーションがあります。最近、Anna は自身のセダンのために Cumulus の自動車保険に加入しました。

自宅の外でバーベキューをしている Anna とその家族

いくつかの契約の属性を次に示します。

特性

保険の種類

自動車保険契約

保険期間

1 年

元の責任開始日

2022 年 1 月 1 日

元の満期日

2022 年 12 月 31 日

保険料

1000 ドル

「Financial Services Cloud のデータモデリング」バッジを獲得している方は、Anna Murphy が個人取引先と保険契約関係者としてモデル化されていることをご存知でしょう。

Note

個人取引先では、特定の取引先項目および取引先責任者項目が 1 つのレコードに結合されて、個人に関する情報が保存されます。個人取引先を使用すると、姓と名など、企業ではなく人に適用される情報を保存できます。

主要なオブジェクト

ですが、Anna の自動車保険契約を表現するために、Justus はどのように保険データモデルを適応させるのでしょうか? Anna の取引先と保険契約の主な詳細は、次のオブジェクトによって取得されます。

情報のフロー図

次の表は、ダイアグラム内の各オブジェクトとそのつながりを示しています。

オブジェクト

説明

取引先

[取引先] オブジェクト (1) は Salesforce の標準オブジェクトです。企業と消費者に対して、複数の取引先種別を使用できます。[取引先] オブジェクトには親子リレーションがあります。つまり、取引先をネストすることができます。法人取引先内にクライアント取引先を設定できるため、これは企業を対象とした場合に便利です。Anna にはクライアント取引先があります。

取引先責任者

取引先に関連する 1 人ずつに 1 つの [取引先責任者] レコード (2) がある必要があります。取引先責任者と取引先には直接的なリレーションがあるため、[取引先責任者] オブジェクトと [取引先] オブジェクトの間には多対多の関係が保持されます。すべての取引先責任者では、それに直接関連する主取引先が識別されます。Anna と Anna の夫である Nigel Murphy のどちらにも、[取引先責任者] レコードが設定されています。

保険契約

[保険契約] (3) は、保険データモデルのルートオブジェクトと考えてください。他のすべてのものがここから発生します。[保険契約] オブジェクトは、商品モデルの特定の設定であり、保険契約者の特性に基づいています。

[保険契約] レコードでは、保険証券番号と種類、被保険者の名前、責任開始日、適用される保険料など、必須情報が取得されます。エージェントは、[保険契約] レコードを使用して、顧客の保険契約と保険会社口座の参照を追跡します。

各保険契約に設定できる取引先は 1 つのみですが、1 つの取引先に複数の取引先責任者と保険契約関係者を設定することができます。保険契約関係者には、所有者、運転者、受取人を指定できます。保険契約関係者については、後で詳しく説明します。

Anna は生命保険、自動車保険、住宅所有者保険に加入していますが、この例では自動車保険契約を中心に説明します。

保険契約補償範囲

Zeynep は、最初に Anna に自動車保険を販売した有能な営業エージェントです。今、Zeynep は Anna の保険契約の詳細を Salesforce の保険データモデルに対応付けるために、Cumulus のコンサルタントである Justus Pardo に連絡を取っています。

保険データモデルはさまざまな用途に対応できるため、 個人の主要なライフイベントのレコードと詳細を追加するために更新することができます。保険データモデルで Anna のようなデータのクラスターを整理することで、Cumulus は一貫性のある方法で効率的に作業できるようになります。

以下に、すべての情報と相互のつながりがどのように展開されているのかを視覚的に示します。

情報のフロー図

次の表は、データモデルですべての情報がどのように整理されているかを示しています。

オブジェクト

説明

商品

商品モデルは、[商品] オブジェクト (1) としてデータモデルに接続します。商品モデルは、会社が販売する商品の構造的な定義です。この例では、商品モデルは Cumulus Insurance の各種別のブループリントとして機能します。[商品] オブジェクトは、仕様 (スペック) レコードで構成されています。[商品] レコード (スペック種別) は、補償範囲 ([補償範囲スペック])、人 ([被保険者スペック])、物 ([保険対象スペック]) を表します。

多くのデータモデルオブジェクトは、スペックデータを取得するために [商品] オブジェクトに接続します。すべての補償範囲、保険契約資産、関係者のレコードは、対応する商品スペックの種別と関連付けられています。補償範囲のマスターリストを商品モデルに取り込んでから、[保険契約補償範囲] オブジェクトを使用して、特定の保険契約で購入した補償範囲をモデル化することができます。 

保険契約

Anna の自動車保険契約のルートオブジェクトとして、[保険契約] オブジェクト (2) を使用します。この保険契約には、複数の保険契約関係者、保険契約資産、保険契約補償範囲が設定されており、 すべてに重要なリレーションがあります。商品モデルによって、[保険契約] に属性が提供されます。

保険契約補償範囲

Anna の自動車保険契約には、[車両総合]、[衝突]、[対人補償] の補償範囲が含まれています。車両衝突補償範囲には、損害をカバーする賠償責任限度額が 50,000 ドル、個人免責額が 500 ドルが含まれています。[保険契約補償範囲] レコード (3) には、この情報が保存されています。保険契約、関係者、保険契約資産ごとに、複数の保険契約補償範囲を設定できます。

保険契約資産

現在、Anna の唯一の保険契約資産はセダンですが、最近、仕事でボーナスが支給されたため、自分へのご褒美に新車の SUV を購入することにしました。Anna は Cumulus に新しい車を既存の保険契約の補償対象にしてもらいたいと思っていますが、いくつかの詳細を変更したいとも考えています。つまり、セダンには適用しないものの、SUV には車両総合補償を適用したいということです。Cumulus は [保険契約資産] レコード (4) を追加し、Anna の保険補償範囲を調整します。このレコードには、この保険契約で補償される新しい SUV に関する概要レベルの情報が含まれています。

保険契約参加者

Anna は夫の Nigel を自動車保険契約に含めることを望んでいます。Nigel は週末に Anna のセダンで食料品を買いに行くため、Nigel が間違いなく保険の適用対象になるようにしたいと考えています。Anna と同様に、Nigel は Salesforce の [個人取引先] でモデル化されます。

Justus は、[保険契約関係者] レコード (5) を使用して、運転者として Nigel を Anna の保険契約に関連付けます。保険契約関係者には、所有者、運転者、受取人を指定できます。

生命保険と有価証券

Zeynep は月曜日の朝、ダッシュボードのアラートを参照するためだけに保険エージェントコンソールにログインします。このアラートは、Anna の 30 歳の誕生日が数日後であることを通知するものでした。常に優秀な営業担当である Zeynep は、この機会を Anna への新しい生命保険契約のクロスセルに使用します。Anna は、Zeynep の先を見越した提案を高く評価して、Cumulus の資産担保型の生命保険を購入しました。

次のモデルは、Anna の新しい Cumulus の生命保険契約を表しています。

情報のフロー図

Anna の [保険契約] (1) によって、Anna は死亡保障を得ながら、株式や債券などの有価証券に投資することができます。Anna は US Equity Large Growth の投資ファンドオプションを選択します。これで、新しい投資が Anna の [取引先] (3) と [生命保険契約] (1) に関連付けられた [保有証券] レコード (2) になりました。Anna は 夫の Nigel を保険契約受取人 (4) に指名します。この作業については、Justus の手際の良さに感心してしまいますね。

保険料支払

Anna は生命保険契約の保険料を四半期ごとに Cumulus の主口座から支払いたいと考えています。以下に、Justus が Anna の生命保険契約の金融口座情報をどのようにモデル化しているかを示します。

情報のフロー図

Justus は、カスタムオブジェクトを使用して金融口座を表現しています。こういったオブジェクトには、取引、支払方法、金融口座に関する情報が保持されています。Anna の場合は、生命保険料の引き落とし、Cumulus 口座情報、生命保険料の請求書が含まれます。それでは、このような情報がどのように使用されるか見てみましょう。

オブジェクト

説明

保険契約

[保険契約] オブジェクト (1) は、Anna の生命保険契約請求のためのルートオブジェクトです。Anna の生命保険契約は、請求書、支払方法、金融取引に接続していますが、金融口座には接続していません。 

金融取引

[金融取引] オブジェクト (2) には、Anna の生命保険契約について行われた取引のレコードが含まれています。各取引レコードは、1 つの金融口座と保険契約に固有のものです。取引には、クレジットカードでの請求または口座引き落としを指定できます。 

Policy Payment Method (保険料支払方法)

[Policy Payment Method (保険料支払方法)] (3) では、顧客が支払にどの口座を使用するのかが識別され、金融口座レコードではその口座の情報が保存されます。Anna の Cumulus 口座は、生命保険料を支払うための主要な保険料支払方法です。

金融口座

[Financial Account (金融口座)] レコード (4) には Anna の Cumulus 口座情報が保存されています。

請求書

Anna には、Cumulus 口座と生命保険契約に関する複数の [請求書] レコード (5) があります。各レコードは、口座に対する購入、預入、利息、手数料、請求額の概要です。

雇用主向け保険

Anna の雇用主は、あらゆる災害から発生する費用に備えて、労働者災害補償保険契約に加入しています。労働者災害補償保険契約では、通常、事業所ごとに異なるクラスの従業員が補償対象になります。以下に、Justus がどのように保険契約をモデル化しているかを示します。

情報のフロー図

次の表は、保険データモデルで労働者災害補償保険契約のデータをどのように整理されているかを示しています。

オブジェクト

説明

保険契約

Anna の雇用主には、現在、労働者災害補償保険契約の [Insurance Policy (保険契約)] レコード (1) があります。

保険契約補償範囲

[保険契約補償範囲] オブジェクト (2) には、労働者災害補償保険契約の補償範囲情報が保存されています。保険契約ごとに、複数の保険契約補償範囲を設定できます。1 つの労働者災害補償の [保険契約補償範囲] は、多数の [労働者災害補償クラス] に接続します。

労働者災害補償クラス

労働者災害補償保険契約では、通常、場所ごとに異なるクラスの従業員が補償対象になります。従業員のクラスごとに、独自の [労働者災害補償クラス] レコード (3) があります。

これで、Anna の保険契約データモデルについて学習できました。次の単元に進んで、Cumulus がどのように Cloud Kicks のグループ保険の見積と契約データを整理しているかを学びましょう。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む