ある自動車メーカーが、DMSの上にリアルタイムの運用基盤をどう構築したか ── 業務を動かすシステムを、一切乱すことなく
シリーズ:2026年6月 · 業務アプリケーション × AI第03回 / 全07回読了時間 約8分
2024年、ある日本の自動車メーカーの運用部門は、なじみのあるパラドックスに直面していました。
Dealer Management System(DMS)は、これまで以上に多くのデータを生成しています。サービススループット、部品在庫、顧客接点、技術者の作業履歴、保証請求、決済処理 ── [複数の]ディーラー拠点で、一日中、毎日。それにもかかわらず、ディーラーネットワークが「今」どう動いているかという、最も重要な問いに答えられない状態が続いていました。
DMSが故障していたわけではありません。役割を果たしていました ── 正確に、信頼性高く、オペレーショナル・エクセレンスが要求する決定性をもって。問題は、「業務上の知性」がリアルタイムで存在していなかったことです。昨日のスループットレポートは「昨日のこと」を教えてくれます。今日の問い ── 「この時間、稼働率が低い拠点はどこか」── には、答えるシステムが存在しませんでした。
これは、そのギャップをどう埋めたかという事例です。DMSを置き換えたのではありません。DMSの上にインテリジェンス層を加え、ゾーン規律を明示的に設計することで、DMSが今までやってきたことを一切変えずに実現しました。
設計の問い
チームは「これだけのデータをどう使うか」から議論を始めませんでした。より鋭い問いから始めました。
業務が今要求するスピードで判断できなくなっている意思決定は、何か?
「三つのゾーン」の言葉で言えば ── DMSはAI不在ゾーンにしっかりと位置します。取引型・決定論的・監査可能・業務記録の唯一の所有者。必要だったのは、その上にAI主導ゾーン ── 「補助するAI」ではなく「システムそのものが知性のレイヤー」となる層 ── を加えることでした。二つのゾーンの間の境界は、アーキテクチャを構築する前に設計される必要がありました。
アーキテクチャ ── 二つのゾーン、一つの運用像
1. DMSからモダンデータ層へのリアルタイムなデータ流通。Change Data Capture(CDC) ── 具体的にはDebezium ── を導入し、DMSの変更をDatabricksベースのインテリジェンス層にストリームします。約[905 GB]のデータがパイプラインを流れ、約[69]の業務テーブルがデータの基盤を形成しています。DMS側は「読まれていること」を意識しません。
2. インテリジェンス層そのものが、システムである。これがスケールに適用されたAI主導ゾーンです。MLモデルが部品需要を予測し、サービススループットの異常を検知します。生成AIが文脈を伴う説明を提供します。Power BIが[10分]ごとに更新される運用像を提示します。
3. 境界は一方向である。インテリジェンス層は、DMSから「読む」だけです。書き戻しません。注文を生成しません。業務上の意思決定を所有してきたシステムは、引き続きそれを所有します。
なぜゾーン規律が重要か
DMSから知性を引き出そうとする多くの試みは、DMSを賢くしようとして失敗します。DMSが抵抗するからです。DMSは「賢く」設計されていません。「信頼性高く」設計されています。
System of Recordが信頼できるのは、それが決定論的・監査可能・境界が明確だからです。AIは確率的・時に不透明・既定では境界がありません。本番で失敗するのは、AIが間違うからではなく、AIの性質が、システムの目的と本質的に整合しないからです。
「リアルタイムの運用像」が現場でどう見えるか
ダッシュボードを開いたディーラー責任者には、サービスベイのスループットが時間単位で・部品需要予測がSKU別拠点別で・顧客接点指標がほぼリアルタイムで・保証請求パターンが異常時に浮かび上がる ── そういう運用像が見えます。中央運用部門には、ネットワーク全体の像が見えます。これらは、DMSが何をやるかを一切変えずに実現されました。
この先 ── コネクテッド車両の業務データ。同じアーキテクチャパターンは、商用車両がよりソフトウェア定義型(SDV)になるにつれて、ディーラーレベルの信号を超えて車両レベルの信号にも拡張されていきます。リモート診断、OTAによる業務情報、車両自体が生成する業務洞察 ── これらが同じインテリジェンス層に段階的に流入してくる。プラットフォームが「そのために」設計されたからではなく、ゾーン規律がそれらをネイティブに受け入れられるからです。アーキテクチャは再構築されることなく複利的に拡張していきます。
マルチモーダルな信号タイプも、同じアーキテクチャパターンの一部です。技術者の画像解析による車両ビジュアル診断、コンピュータビジョンによる製造検査、コネクテッド車両テレメトリのセンサーフュージョン、サービス対応からの会話的な顧客信号 ── これらが同じインテリジェンス層に、同じゾーン規律で流入します。信号タイプは変わりますが、運用パターンは変わりません。信号が数値・画像・音声ストリーム・センサーパケットのどれであったかは、アーキテクチャ的には「ディテール」です。
成果 ── 質的な観察
このプラットフォームは現在、本番運用[1年以上]を経ています。ディーラー責任者は、業務上の信号を「その日のうちに」行動に移します。以前は週次の反応でした。部品需要予測が、拠点単位からポートフォリオ単位へ移行しました。DMSチームは業務上の混乱を吸収する必要がなかった ── アーキテクチャのゾーン規律がその理由です。
目立つのは、二次的効果です。ディーラー責任者がリアルタイムの運用像を持つと、判断を「より早い時間」「より早い週」「より早い季節」に下し始めます。「反応型」から「先回り型」への運用の移行 ── これが、複利的に効いてくる変化です。
サービススループット改善率、部品在庫効率、顧客接点指標などの具体的な数値は、発行前にクライアントNDAレビューで確認します。
より広い示唆
この自動車メーカーのために構築したものは、製品ではなく、パターンです。取引データを抱えるあらゆる企業 ── DMS、ERP、CRM、製造実行システム ── は、同じゾーン規律を尊重するインテリジェンス層のための「基盤」をすでに持っています。
三つの条件:取引システムがSystem of Recordであり続ける(AI不在ゾーン);リアルタイムデータパイプラインが存在する;インテリジェンス層のスコープが、構築の前に設計される。
ここが、Cubastionの仕事が集中している領域です。私たちは、良いDMS運用・良いERP運用・良いCRM運用がどう見えるかを、内側から知っています。一言で表現すれば、Business Applications × AI。
結びに
2024年、この自動車メーカーが直面していた問いは、「DMSをどう賢くするか」ではありませんでした。問いは、「DMSが提供してきた信頼性を損なわずに、業務速度で運用上の知性を加えるにはどうするか」でした。答えは、アーキテクチャでした。
この自動車メーカーが今手にしている運用像 ── [10分]ごとに、[複数の]ディーラー拠点を横断して更新される ── は、業務を動かすシステムと、業務を説明するシステムの違いをアーキテクチャが尊重した時の、見える化の姿です。
知性が仕事です。DMSが基盤です。その間の境界が、設計です。
プラットフォームのウォークスルーを、AI Native Expo ChibaのCubastionブースでお見せします。皆様のDMSあるいはERPのアーキテクチャ図をお持ちください。
© Cubastion Consulting · 2026年6月 · cubastion.com · cubastion.co.jp
シリーズ:2026年6月 — 業務アプリケーション × AI · 第03回 / 全07回
