OEM本社：アラートは出た。では、誰に送る？｜OEM本社 Connected Service会議｜佐伯（OEM日本本社 Connected Service担当）・大坪（OEM日本本社 マーケティング部 CRM担当）・高木（OEM日本本社 保険連携担当）・渡辺（OEM日本本社 アフターセールス担当）

月曜午前。Connected Serviceチームの定例会議。画面には、車両データ基盤が検知したバッテリー劣化の候補リストと、CRMの配信準備画面が並んでいる。今週の点検案内キャンペーンに、この候補を追加できるかが議題になった。

佐伯（OEM日本本社 コネクテッドサービス部門 担当）：「先週から上がっているバッテリー劣化の候補です。走行距離と充電履歴を見ても、早めに点検を案内した方がよさそうな車両があります。今週のキャンペーンに追加できますか？」

大坪（OEM日本本社 マーケティング部 CRM担当）：「候補リストをCRMに取り込むことはできます。ただ、いきなり配信対象には入れられません。いつものキャンペーン条件に合うか、対象者と連絡先を確認する必要があります」

佐伯：「対象車両はVIN（車両識別番号）で特定できています。CRMにも顧客情報がありますよね。そこをひも付ければ済む話では？」

大坪：「車両と顧客情報はひも付けられます。ただ、そのひも付けが現在の所有者や利用者を正しく表しているとは限りません。名義変更後にアカウント情報の更新が遅れることもありますし、同じ世帯で複数の人が車を使うケースもあります」

佐伯：「今回送りたいのは、故障の断定ではなく点検の案内です。対象者を確認するのに、どこまで時間をかける必要がありますか？」

大坪：「全件を手作業で調べる話ではありません。まず、既存の配信ルールで除外される顧客が反映されているか、車両と顧客のひも付けに問題がないかを確認したいんです。対象リストを作れることと、そのリストをそのまま配信に使えることは違います」

佐伯：「分かりました。では、今回の候補を既存ルールに通して、確認が必要なものだけ切り分けましょう。点検案内の文面も、バッテリーの故障が確定したような書き方にはしないでください」

渡辺（OEM日本本社 アフターセールス部門 担当）：「その文面なら、入庫先も少し気になります。正規ディーラーへの入庫を促すのか、まず点検を勧めるだけにするのか。車両の状態だけで、最寄りの工場まで決め打ちするのは避けたいですね」

佐伯：「今回は、点検を勧めるところまでにしましょう。入庫先の案内は、既存のサービス案内ルールに合わせます」

高木（OEM日本本社 事業企画部 新規事業・パートナーシップ担当）：「少し別の話ですが、その走行データ、保険連携の企画でも使えませんか。走行距離や急加速・急減速などを使って運転傾向を分析したいという話があります。車両データ基盤には、必要な情報がかなり揃っていますよね」

大坪：「データがあるのは分かります。ただ、今回の整備案内の対象リストを、そのまま保険連携に渡すのは別の話です。整備案内と保険では利用目的も提供先も違います。既存の通知設定だけで、保険向けの利用までカバーできているかは確認が必要です」

高木：「なるほど。分析用のデータが取れるかどうかと、保険会社への提供に使えるかどうかは別ですね。保険側で必要な項目と利用条件を整理します」

渡辺：「外部の整備工場も同じです。お客様が独立系の工場に持ち込んだとき、工場から『この故障コードの意味を確認したい』と問い合わせが来ることがあります。車両側の情報を持っていても、工場が必要な診断情報にアクセスできるとは限りません」

佐伯：「それは、今のCRM配信とは別に、診断情報の提供ルールとアクセス手段を確認する必要がありますね。社内で参照できることを、そのまま外部にも提供できるという前提にはしない方がいい」

大坪：「今日の話を整理すると、車両データから候補を抽出するところまでは進んでいます。その先の配信には、既存の顧客情報や連絡ルールとの照合が必要。保険連携には別の利用条件の確認が必要。整備工場への情報提供には、アクセス方法と提供範囲の整理が必要です」

佐伯：「では、まず今週の点検案内を進めましょう。CRM側で既存ルールとの照合を行い、確認が必要な対象を切り分ける。保険連携と外部工場への診断情報提供は、それぞれ担当を決めて別途確認する。データが揃ったからといって、全部を一度に動かそうとしないことですね」

画面には、位置、走行距離、充電状態、急加速・急減速、故障コード、サービス履歴が表示されていた。車両の異常を検知し、点検候補を抽出するところまでは進んでいる。しかし、顧客への通知、保険会社への提供、外部整備工場での利用には、それぞれ異なる確認事項が残っていた。

データが足りないから止まっていたのではない。データを抽出した後の配信条件、利用目的、共有先、承認手順が、ひと続きの業務として設計されていなかったのだ。

※ このシーンは、業務上の論点を説明するために構成した想定シナリオです。特定の企業・個人・事例を描写したものではありません。

第3回の問い

VINと、その先にいる人｜OEM本社 CRM・Connected Service連携会議｜大坪（OEM日本本社 マーケティング部 CRM担当）・佐伯（OEM日本本社 Connected Service担当）

大坪（OEM日本本社 マーケティング部 CRM担当）：「このVIN、整備案内の対象に上がっています。ただ、CRMで見ると購入時の法人担当者が連絡先になっています。アプリ側の登録者は別の人です。配信リストには、どちらを使えばいいですか？」

佐伯（OEM日本本社 コネクテッドサービス部門 担当）：「車両データ側では、アプリの登録者は確認できます。法人名義で購入された車両で、登録者は社員のAさんですね」

大坪：「Aさんが今もこの車を使っているかは分かりますか？」

佐伯：「そこまでは分かりません。アプリの登録情報はありますが、現在の運転者を確認する情報とは別です」

大坪：「CRMには、購入時の担当者とサービス連絡先が残っています。でも、車両管理を担当している人は別かもしれません。これだと、どの宛先を使うのが正しいのか判断できません」

佐伯：「法人のお客様なら、まず車両管理担当に確認する方法もあります。ただ、今のデータだけでは、その担当者が誰なのかも確定できないですね」

大坪：「そうなんです。宛先が一つ足りないというより、購入時の担当者、現在の管理担当、アプリ登録者が、それぞれ別の役割として管理されていないんです」

佐伯：「しかも、車両が別の社員に引き継がれても、アプリやCRMの情報が同じタイミングで更新されるとは限りません。VINをキーにすれば車両の情報は集められますが、人との関係がいつ変わったかまでは、それだけでは追えません」

大坪：「では、今回の案内はどうしますか。購入時の連絡先にそのまま送るのか、法人の窓口を確認してから送るのか。今ある情報だけでは決められません」

佐伯：「まず、法人向けのサービス連絡先が登録されているか確認しましょう。確認できなければ、既存の運用ルールに沿って宛先を確認する。アプリ登録者を、そのまま現在の運転者として扱うのはやめましょう」

大坪：「分かりました。ただ、今回の一件を解決しても、次の車両で同じことが起きます。車両の引き渡しや担当者変更があったときに、誰が、どの情報を更新するのかも決める必要がありますね」

佐伯：「そうですね。車両データとCRMをつなぐだけでなく、購入者、管理担当者、利用者、サービス連絡先の関係を、変更履歴も含めて追えるようにする。それがないと、毎回、担当者が個別に確認することになります」

画面には、VIN、車両の状態、購入時の法人情報、アプリ登録者、過去のサービス履歴が表示されていた。情報がゼロなのではない。それぞれの情報が、誰のどの役割を示しているのか、そしてその関係が今も有効なのかを、一続きで確認できなかった。

VINに顧客IDをひも付けるだけでは、現在の関係は分からない。必要なのは、誰が、いつからいつまで、どの立場で車両に関係しているのかを管理し、その関係に応じて通知先や利用条件を判断できる仕組みだ。

※ このシーンは、業務上の論点を説明するために構成した想定シナリオです。特定の企業・個人・事例を描写したものではありません。

UBIスコアの問い合わせ：記録はある。でも、評価の理由は誰が説明する？｜OEM本社 保険連携・顧客対応会議｜高木（OEM日本本社 保険連携担当）・大坪（OEM日本本社 マーケティング部 CRM担当）・渡辺（OEM日本本社 アフターセールス担当）

高木（OEM日本本社 事業企画部 新規事業・パートナーシップ担当）：「提携先の保険会社から確認依頼が来ています。うちのコネクテッドサービスを利用しているお客様から、更新時の保険料について問い合わせがあったそうです。保険会社の説明では、前回より運転スコアが下がっているとのことです」

大坪（OEM日本本社 マーケティング部 CRM担当）：「お客様は、何が問題だと言っているんですか？」

高木：「急減速の評価に納得できないそうです。本人の説明では、集計期間中に前の車が急に減速したため、追突を避ける操作をしたことが何度かあったと。危険な運転をしたつもりはないのに、スコアが下がったのはおかしい、という話です」

渡辺（OEM日本本社 アフターセールス部門 担当）：「車両側には、そのときの記録が残っているんですか？」

高木：「テレマティクス側に、急減速として検知されたイベントの日時と関連データはあります。ただ、前の車がどう動いたか、なぜその操作をしたのかまでは、今ある記録だけで確認できるとは限りません」

大坪：「では、記録があるからといって、本人の説明が正しいか間違っているかを、こちらで判断できるわけではないですね」

高木：「そうです。もう一つ問題があります。保険会社からはイベントの確認を求められていますが、スコアの算定方法や、今回の更新保険料にどの程度影響したのかまでは、こちらでは把握していません」

渡辺：「それなら、OEM側で説明できるのは、まず何が記録されていたか、というところまでですね。スコアがなぜ下がったのか、保険料がなぜ上がったのかは、保険会社側の評価方法も確認しないと答えられない」

大坪：「お客様から見れば、車のデータを取っているのも、スコアを付けているのも、保険料に反映しているのも、ひと続きに見えるでしょうね。問い合わせ先をたらい回しにされたら、納得できないと思います」

高木：「保険会社には、まず該当するイベントと記録の確認を依頼しましょう。そのうえで、スコアの算定にどう反映されたか、再評価の対象になるかは、保険会社に確認してもらう必要があります」

渡辺：「もしセンサーの記録自体に誤りがあれば、データを管理する側で調査できる。でも、記録は正しいのに評価の仕方が適切でないという話なら、別の判断が必要です。その境界を曖昧にしたままでは、どちらも『うちの担当ではない』となりかねません」

大坪：「それと、そもそも誰の運転として評価したのかも確認が必要です。家族で車を共有していたり、別の人が運転していたりすれば、車両に記録されたイベントを契約者本人の運転として扱ってよいのか、という問題もあります」

高木：「分かりました。今回の問い合わせでは、記録の確認、運転者の識別、スコアへの反映、保険料への影響を分けて確認します。保険会社にも、顧客への説明と再評価を誰が担当するのか、回答を求めます」

大坪：「次から同じ問い合わせが来ても困らないように、契約前の説明も見直したいですね。何を記録するのかだけでなく、そのデータがどのように評価され、何に影響しうるのか。異議があるとき、どこに申し出ればよいのかも含めてです」

高木：「そうですね。データを集める仕組みだけでなく、評価に納得できないときに、記録を確認し、必要なら判断を見直せる仕組みまで用意しなければいけません」

走行イベントの記録は残っていた。しかし、記録された急減速がどのような状況で起きたのか、誰の運転だったのか、それがスコアや保険料にどう反映されたのかは、同じシステムの中で一続きに説明できる状態ではなかった。

走行データを記録する責任と、そのデータを評価する責任、そして評価を契約条件に反映する責任は同じではない。顧客が異議を申し立てたとき、記録の確認から評価の再検討までを誰が担うのか。その道筋がなければ、個別化された保険料は、顧客から見れば理由の分からない評価になってしまう。

※ このシーンは、業務上の論点を説明するために構成した想定シナリオです。特定の企業・個人・事例を描写したものではありません。

修理できない｜OEM本社 アフターセールス／Connected Service｜渡辺（OEM日本本社 アフターセールス担当）・佐伯（OEM日本本社 Connected Service担当）

渡辺（OEM日本本社 アフターセールス部門 担当）：「例の車、工場からまた連絡が来ました。故障コードは読めた。でも、次の診断手順に進めないそうです」

佐伯（OEM日本本社 コネクテッドサービス部門 担当）：「セキュアゲートウェイのところですか？」

渡辺：「そうです。いつもそのお客様の車を見ている独立系の工場です。お客様は、なぜそこで直せないのかと」

佐伯：「車両情報の提供と、認証が必要な機能へのアクセスは別です。今回の作業で、どの認証が必要になっているか確認します」

渡辺：「確認するのはいいんですが、工場には今日中に返事をしないといけません。認証の手続きで進められるのか、それとも別の工場へ案内する必要があるのか。そこまで分かりますか」

佐伯：「まず、車両の型式とソフトウェアの状態、使っている診断ツール、止まっている操作を確認します。認証が通っていないのか、ツール側が対応していないのかで、次の手が違います」

渡辺：「では、工場に確認する項目を送ってください。こちらからも、必要なアクセスをどうすれば確保できるか調べます。ただ、『情報は提供しています』という回答だけでは、お客様への説明になりません」

佐伯：「分かりました。今回の作業に必要なアクセス条件と、利用できる手続きを整理します。セキュリティ上の制限があるなら、何が理由で、どこまでできるのかも確認します」

渡辺：「お願いします。お客様が知りたいのは、制度上情報が公開されているかどうかだけではありません。自分の車を、選んだ工場で直せるのかどうかです」

整備情報は提供されていても、現場で必要な診断機能まで使えるとは限らない。問題が起きたとき、情報提供の窓口、認証の手続き、診断ツールの対応状況が別々に管理されていれば、誰もすぐに答えられない。

修理・保守情報へのアクセス権（RMI）は、情報を公開するだけの問題ではなく、必要な診断・修理にたどり着けるアクセス経路を、安全性と両立させて設計する問題になった。

※ このシーンは、業務上の論点を説明するために構成した想定シナリオです。特定の企業・個人・事例を描写したものではありません。

Capability → Permission → Authority → Accountability

AI／Agentごとに、読めるデータ、利用できる目的、実行できるアクション、必要な承認、保存する証跡、停止条件を定める。AIがデータを理解できることは、企業としてそのデータを利用・共有・確約できることを意味しない。これはDX365LIFEが「Authority Binding（承認権限の明示）」と呼ぶ設計の問題です。

走行データを持つことは、利用してよいことではない。

Purpose（何のために）× Permission（誰が許可したか）× Authority（誰が決めるか）× Accountability（誰が説明するか）— この4つが揃ってはじめて、走行データは「利用できるデータ」になります。どれか一つが欠けたとき、AIがデータを読めても、企業としてそのデータを動かすことはできません。※ この分析枠組みはDX365LIFEの編集概念です。

今回の問い（Q10〜Q15）と回答

第3回の結論

走行データを、どちらか一方が一律に所有し自由に利用できるものとして扱うだけでは、実務上の問題は解けない。境界線はデータの「所在」ではなく、目的・許可・権限・説明責任の4軸によって引かれる。

Purpose × Permission × Authority × Accountability
＋ Relationship View（関係性ビュー）
＋ Evidence Return Loop（証跡返還ループ）

車両を見えるようにするだけでは、人は見えない。人を見えるようにするだけでは、関係は分からない。関係を理解できても、利用権限があるとは限らない。利用できても、価値が顧客へ戻らなければ信頼は続かない。

走行データを巡る問いは、「誰が持つか」ではなく「誰が何の目的で、誰の許可を得て、誰の権限のもとで、誰が説明責任を持って使うか」を設計する問いだ。

Technosoft Automotive Days 2026 — 参加申込受付中（2026年12月9〜11日）

Technosoft Automotive Solution（DMS、NSC Systems・CRM・Agentic AI）の導入事例、TSAD2025セッション録画もあわせてご覧いただけます。→ 詳細・お申し込みはこちら