2026.01.21
【Automotive Cloud】技術者のための「Vehicle Console」徹底解剖〜データモデル・タイムライン・アラートを“1枚の業務体験”にする設計〜
ポスト
目次
- はじめに：なぜ「車両コンソール（Vehicle Console）」は「画面」以上の意味を持つのか
- 1. 最初に詰まりやすい「データモデル」を、業務の言葉でほどく
- 1-1. 「納入商品（Asset）」は“現物の器” — 車両も部品も入る
- 1-2. 「型」と「個体」を分ける：Vehicle Definition と Vehicle
- 1-3. 実際に環境を確認すると「この関係性」だった —— ここからデータモデル構築へ
- 2. コンポーネント徹底解剖
- 2-1. Timeline：履歴を“1本の線”に圧縮する
- 2-2. Record Alerts：いま注意すべき“信号”だけを前面に
- 2-3. ARC：関係者を Lookup ではなく「関係性」として扱う
- 2-4. OmniStudio（FlexCard）：外部データを“画面に溶かす”
- 3. 実装者向け：最小構成から “壊れない” Vehicle Console を作る手順
- おわりに
当社では、社内の技術力向上の一環として、西日本の拠点メンバーを中心に Salesforce Automotive Cloud の勉強会を実施しています。検証環境での確認や公式ドキュメントの読み合わせを通じて得た知見を、同じようにキャッチアップする方の助けになる形で整理したのが本記事です。
車両コンソール（Vehicle Console）を「画面」ではなく「業務体験」として捉え、設計の勘所を解説します。
車両コンソール（Vehicle Console）を「画面」ではなく「業務体験」として捉え、設計の勘所を解説します。
はじめに：なぜ「車両コンソール（Vehicle Console）」は「画面」以上の意味を持つのか
Salesforce Automotive Cloud を触り始めたとき、多くの人が最初に驚くのは「標準なのに情報量が多い」点です。車両、関係者、部品、履歴、アラート、外部データ…。一見すると “全部盛り” ですが、現場の業務を想像すると、その理由ははっきりします。
・オペレーター／サービス担当は「この車、今なにが起きている？」「誰が関係者？」「過去に何があった？」を 数十秒で判断したい
・営業／ディーラー支援は「この車両に紐づくアップセル余地（互換部品・アクセサリ）」を 会話中に提示したい
・その裏では、テレマティクスや基幹システムなど 外部データが常に動いている
・オペレーター／サービス担当は「この車、今なにが起きている？」「誰が関係者？」「過去に何があった？」を 数十秒で判断したい
・営業／ディーラー支援は「この車両に紐づくアップセル余地（互換部品・アクセサリ）」を 会話中に提示したい
・その裏では、テレマティクスや基幹システムなど 外部データが常に動いている
車両コンソール（Vehicle Console） は、この“判断”と“会話”のために、Salesforce Automotive Cloud の各要素（データモデル／共通コンポーネント／OmniStudio）を束ねた中核 UI として位置付けられています。公式ヘルプでも、車両詳細・関係者・搭載済み／互換の部品やアクセサリなどを車両コンソールで確認できることが明記されています。
▼参考：Helpサイト「AutomotiveCloud」
▼参考：Helpサイト「AutomotiveCloud」
1. 最初に詰まりやすい「データモデル」を、業務の言葉でほどく
ここからが本題です。車両コンソール（Vehicle Console） を“理解できた”状態にするために、最初に越えるべき山はデータモデルです。特に混乱しやすいのが 納入商品（Asset） と 車両（Vehicle） の関係、そして 車両定義（Vehicle Definition） の位置づけです。
1-1. 「納入商品（Asset）」は“現物の器” — 車両も部品も入る
Trailhead では、Salesforce Automotive Cloud における Asset と Vehicle の関係を、非常に分かりやすく整理しています。
・すべての車両（Vehicle）は納入商品（Asset）だが、すべての納入商品が車両ではない
・車両は 納入商品レコードと車両レコードの両方を持ち、部品やアクセサリは 納入商品レコードのみを持つ。
この整理を先に置くと、実務上の捉え方が一気にクリアになります。
・車両（1台）：納入商品（Asset）＝現物としての管理（所有・ライフサイクル・階層） + 車両（Vehicle）＝車両としての属性（VIN 等）
・部品／アクセサリ：納入商品（Asset）のみ
▼参考：Trailhead「Review Asset and Vehicle Records」
・車両（1台）：納入商品（Asset）＝現物としての管理（所有・ライフサイクル・階層） + 車両（Vehicle）＝車両としての属性（VIN 等）
・部品／アクセサリ：納入商品（Asset）のみ
▼参考：Trailhead「Review Asset and Vehicle Records」
1-2. 「型」と「個体」を分ける：Vehicle Definition と Vehicle
自動車業務の要諦は、「同じ車種（型）」が大量に存在し、「個体（1台）」が VIN 等で識別されることです。ここを混ぜると、後工程（保証、整備、交換、リコール、互換部品、テレマティクス）で矛盾が出ます。
・車両定義（Vehicle Definition）：型（カタログスペック、グレード、仕様）
例：モデル年式、ボディスタイル、燃料/バッテリー、トランスミッションなど
・車両（Vehicle）：個体（車両固有の属性）
例：VIN（車台番号）、登録情報、走行距離など
▼参考：開発者ガイド「VehicleDefinition」
▼参考：開発者ガイド「Vehicle」
ここまで押さえると、「Vehicle Console が“車両を探す画面”ではなく、“車両の判断をする画面”」として設計されている理由が見えてきます。判断には必ず、型（Vehicle Definition）と個体（Vehicle）の両方が必要だからです。
・車両定義（Vehicle Definition）：型（カタログスペック、グレード、仕様）
例：モデル年式、ボディスタイル、燃料/バッテリー、トランスミッションなど
・車両（Vehicle）：個体（車両固有の属性）
例：VIN（車台番号）、登録情報、走行距離など
▼参考：開発者ガイド「VehicleDefinition」
▼参考：開発者ガイド「Vehicle」
ここまで押さえると、「Vehicle Console が“車両を探す画面”ではなく、“車両の判断をする画面”」として設計されている理由が見えてきます。判断には必ず、型（Vehicle Definition）と個体（Vehicle）の両方が必要だからです。
1-3. 実際に環境を確認すると「この関係性」だった —— ここからデータモデル構築へ
ここで、いったん “現物” を起点に話を進めます。
実際に Salesforce Automotive Cloud の検証環境を確認すると、オブジェクト間の関係が次のように見えました。
・車両（Vehicle） → 納入商品（Asset）（主従関係）
・納入商品（Asset） → 車両（Vehicle）（参照関係）
・車両（Vehicle） → 取引先（Account）（参照関係）
・車両（Vehicle） → 車両定義（Vehicle Definition）（参照関係）
実際に Salesforce Automotive Cloud の検証環境を確認すると、オブジェクト間の関係が次のように見えました。
・車両（Vehicle） → 納入商品（Asset）（主従関係）
・納入商品（Asset） → 車両（Vehicle）（参照関係）
・車両（Vehicle） → 取引先（Account）（参照関係）
・車両（Vehicle） → 車両定義（Vehicle Definition）（参照関係）
一見すると「Vehicle と Asset が相互に参照している」ようで混乱しがちですが、これは 1-1 の前提（車両は Asset の一種であり、Vehicle 側で車両属性を補完する）を踏まえると自然な見え方です。以降はこの関係性を前提に、データモデルを 責務（どこに何を持つか） で安定化させていきます。
・車両定義（Vehicle Definition）：型（カタログスペック、グレード、仕様）
・納入商品（Asset）：現物の管理（所有・ライフサイクル、部品階層の親子）
・車両（Vehicle）：車両固有の属性（VIN、登録、走行距離など）
この3点がブレなければ、参照方向の違いに引きずられず、後段の「部品階層（Asset階層）」「関係者（ステークホルダー）」「コンソール上の表示設計」まで一貫して組み立てられます。
▼参考：開発者ガイド「Vehicle Specifications Resource Mapping」
・車両定義（Vehicle Definition）：型（カタログスペック、グレード、仕様）
・納入商品（Asset）：現物の管理（所有・ライフサイクル、部品階層の親子）
・車両（Vehicle）：車両固有の属性（VIN、登録、走行距離など）
この3点がブレなければ、参照方向の違いに引きずられず、後段の「部品階層（Asset階層）」「関係者（ステークホルダー）」「コンソール上の表示設計」まで一貫して組み立てられます。
▼参考：開発者ガイド「Vehicle Specifications Resource Mapping」
ここまでの整理が、Vehicle Console 設計を“壊れない”ものにする
ここまでのデータモデルが腹落ちすると、Vehicle Console の見え方も変わります。Vehicle Console は“完成された画面”というより、業務要件に合わせて情報の並べ方やタブ（表示要素）を拡張しながら育てていく前提のコンソールです。
だからこそ、先に責務分離（Vehicle Definition／Asset／Vehicle）を決めておくことが重要になります。この土台が固まっているほど、後から Timeline や Record Alerts、ARC、OmniStudio などを足しても破綻しません。
ここまでのデータモデルが腹落ちすると、Vehicle Console の見え方も変わります。Vehicle Console は“完成された画面”というより、業務要件に合わせて情報の並べ方やタブ（表示要素）を拡張しながら育てていく前提のコンソールです。
だからこそ、先に責務分離（Vehicle Definition／Asset／Vehicle）を決めておくことが重要になります。この土台が固まっているほど、後から Timeline や Record Alerts、ARC、OmniStudio などを足しても破綻しません。
2. コンポーネント徹底解剖
ここからは、Vehicle Console の“育て方”の中核となる主要コンポーネントを、役割ベースで分解します。ポイントは「見た目」ではなく、どの業務の詰まりを解消するための部品か、そして どのデータを前提としているか です。
2-1. Timeline：履歴を“1本の線”に圧縮する
タイムラインは、イベントと活動を時系列に並べて「この車に何があったか」を一目で追える形にします。Salesforce Automotive Cloud では、Vehicle レコードページに Timeline を追加する手順が公式に提供されています。
▼参考：Helpサイト「Automotive Cloud のタイムラインを設定する」
▼参考：Helpサイト「Automotive Cloud で車両レコードにタイムラインを追加する」
▼参考：Helpサイト「Automotive Cloud のタイムラインを設定する」
▼参考：Helpサイト「Automotive Cloud で車両レコードにタイムラインを追加する」
設計のコツは、最初から全部載せないことです。まずは「問い合わせ→作業→完了」などの最短導線（例：Case / Work Order）から始め、運用が回ってから足していくと、現場が信用するタイムラインになります。
2-2. Record Alerts：いま注意すべき“信号”だけを前面に
Record Alerts は「今すぐ対応が必要／近いうちに注意すべき」を画面上に通知として出す仕組みです。Salesforce Automotive Cloud では、外部のテレマティクスやナビゲーションシステムからのアラート表示も想定した説明があります。
▼参考：Helpサイト「Automotive Cloud のレコードアラートを設定する」
▼参考：Helpサイト「Automotive Cloud のレコードアラートを設定する」
ここが“技術的に面白い”ポイントで、外部データをすべて永続化するのではなく、意思決定に必要な信号（閾値超過・期限切れ・未実施など）に絞って提示する設計に寄せられます。
2-3. ARC：関係者を Lookup ではなく「関係性」として扱う
車両に関係するのは、所有者だけではありません。販売店、整備拠点、ドライバー、世帯、金融機関…と関係が増えていきます。そこで Salesforce Automotive Cloud では、関係性を可視化する仕組みとして ARC（Actionable Relationship Center）を提供しています。
▼参考：Helpサイト「Automotive Cloud の Actionable Relationship Center を設定する」
▼参考：Helpサイト「Automotive Cloud の Actionable Relationship Center グラフを設定する」
▼参考：Helpサイト「Automotive Cloud の Actionable Relationship Center を設定する」
▼参考：Helpサイト「Automotive Cloud の Actionable Relationship Center グラフを設定する」
「見た目が派手」になりがちなので、最初は “所有者・ドライバー・販売店・整備拠点” など最小の関係に絞ってグラフ化すると、業務価値が出やすいです。
2-4. OmniStudio（FlexCard）：外部データを“画面に溶かす”
Vehicle Console は拡張前提のため、OmniStudio を使って UI を増築するケースが多くなります。OmniStudio の有効化手順や、Salesforce Automotive Cloud での OmniStudio パッケージに関する説明は公式ヘルプにまとまっています。
▼参考：Helpサイト「Automotive Cloud の機能を有効化する」
▼参考：Helpサイト「Automotive Cloud 向け OmniStudio」
▼参考：Helpサイト「Automotive Cloud の機能を有効化する」
▼参考：Helpサイト「Automotive Cloud 向け OmniStudio」
3. 実装者向け：最小構成から “壊れない” Vehicle Console を作る手順
①車両定義（Vehicle Definition） を作る（型）
▼参考：Helpサイト「Automotive Cloud で車両定義を作成する」
②車両の納入商品（Asset） を作る（現物の管理）
③車両（Vehicle） を作り、納入商品（Asset）と車両定義（Vehicle Definition）に紐付ける
▼参考（関係整理に有用）：開発者ガイド「Vehicle Specifications Resource Mapping」
④タイムライン（Timeline）を Vehicle ページに追加
▼参考：Helpサイト「Automotive Cloud で車両レコードにタイムラインを追加する」
⑤Record Alerts を設計し、Vehicle ページで表示
▼参考：Helpサイト「Automotive Cloud のレコードアラートを設定する」
⑥ARC を最小構成で配置（関係者の迷子を無くす）
▼参考：Helpサイト「Automotive Cloud の Actionable Relationship Center を設定する」
⑦OmniStudio（FlexCard）で必要な外部状態を埋め込む（必要に応じて）
▼参考：Helpサイト「Automotive Cloud の機能を有効化する」
▼参考：Helpサイト「Automotive Cloud で車両定義を作成する」
②車両の納入商品（Asset） を作る（現物の管理）
③車両（Vehicle） を作り、納入商品（Asset）と車両定義（Vehicle Definition）に紐付ける
▼参考（関係整理に有用）：開発者ガイド「Vehicle Specifications Resource Mapping」
④タイムライン（Timeline）を Vehicle ページに追加
▼参考：Helpサイト「Automotive Cloud で車両レコードにタイムラインを追加する」
⑤Record Alerts を設計し、Vehicle ページで表示
▼参考：Helpサイト「Automotive Cloud のレコードアラートを設定する」
⑥ARC を最小構成で配置（関係者の迷子を無くす）
▼参考：Helpサイト「Automotive Cloud の Actionable Relationship Center を設定する」
⑦OmniStudio（FlexCard）で必要な外部状態を埋め込む（必要に応じて）
▼参考：Helpサイト「Automotive Cloud の機能を有効化する」
おわりに
Vehicle Console は、Salesforce Automotive Cloud の「標準画面」というより、業務判断を最短距離にするための設計テンプレートです。
型（Vehicle Definition）と個体（Vehicle）を分け、現物管理（Asset）を軸に据えたうえで、Timeline・Record Alerts・ARC・OmniStudio を“現場の会話”に合わせて足していく。これが、標準機能を活かし切る最短ルートです。
型（Vehicle Definition）と個体（Vehicle）を分け、現物管理（Asset）を軸に据えたうえで、Timeline・Record Alerts・ARC・OmniStudio を“現場の会話”に合わせて足していく。これが、標準機能を活かし切る最短ルートです。
40 件
