実践ウォークスルー。3年前、私たちは165拠点を横断するDealer Management Systemに Debezium を接続しました — 数TB規模、約69の業務テーブル。System of Recordに触れずに、エンタープライズ・アプリケーションの内側にAIを設置するために、その上に何を構築し、各段階が何を届け、何を学んだか。
ウォークスルーを一枚に。DMSは置き換えませんでした。その上に読み取り専用のAIを設置 — Debeziumがストリーミング、Databricksが推論、Power BIが表示 — ディーラー責任者がすでに作業していたアプリの中で意思決定シグナルを届けた、その姿、です。
本記事の位置づけ。 一つの案件と、それが生んだパターンの、実践ウォークスルー、です。3年前、私たちは Debezium を165拠点を横断するDealer Management Systemに接続しました — 数TB規模、約69の業務テーブル。本記事は、DMSがそれまでの姿のままから、ディーラー責任者がすでに作業していたアプリの中に届く10分間のPower BI更新まで、私たちがどうたどり着いたかを記述します。DMS自体は何も変わりませんでした。私たちは書き戻しませんでした。置き換えませんでした。読み取り専用で、層ごとに、その上にAIを設置しました。
私たちが歩いた道、層ごとに。
Layer 1 — DMS自体、System of Record、変更なし。
Layer 2 — Debezium → Databricks、CDC から読み取り、異常検知とテーブル横断統合を実行するAIインテリジェンス層。
Layer 3 — Power BI を役割フィルターとして、オペレーターがすでに使っているアプリの中でシグナルを表示。
Layer 4 — 選択的なGenAIアシスト(テクニシャン・コ・パイロット・パターン、2024年12月以降稼働)、判断クラスごとに文書化されたAI/非AI境界。四つの層。一つの設置パターン。30以上の案件にわたる6年間の反復、です。
業務にとって何が変わったか。
ディーラー責任者は週次バッチレポートを読むのを止め、1時間以内に容量を再バランスするようになりました。技術者はDMSアプリ画面をスクロールするのを止め、同じ画面で意思決定シグナルを見るようになりました。CDOは新しいダッシュボードを依頼するのを止め、より鋭い問いを問うようになりました。数値は持ちこたえました:FUSO デジタル・サービス・センター拡張で、ジョブカード処理効率 +7,400%、技術者向けページ読み込みレイテンシ −90%、ディーラーとバックオフィス間の連絡遅延 −70%。
何を学んだか。
以来30以上の案件で繰り返し現れた四つの観察:AIはビジネスアプリの内側に設置する、決して並行ではない。System of Recordは聖域 — 読み取り専用、書き戻しなし。役割フィルターが、ほとんどのプロジェクトが失敗する場所(可視性は経営者向けに作られ、オペレーターには決して届かない)。そしてGenAIアシストは最後、最初ではない。
3年前、私たちは165拠点を横断するDealer Management SystemにDebeziumを接続しました。誰も依頼していませんでした。CDOは依頼していませんでした。ディーラー責任者は依頼していませんでした。ワークショップフロアの技術者は依頼していませんでした。運用チームが依頼したのは、ディーラー責任者が最初の10分間Power BI更新で何をしたかを見た後 — そして、それまで稼働してきた週次バッチレポートには二度と戻れないと気づいた後、でした。
案件 — 私たちが歩み入った場所
DMSは稼働していました。何年も稼働してきました。数TBの業務データがその中に住んでいました — 約69の業務テーブルを横断して、サービス記録、部品在庫、お客様履歴、保証請求、ワークショップ・スケジューリング。技術者がサービス・ジョブを記録するために使っていたアプリ画面は、何年も使ってきたのと同じ画面でした。ディーラー責任者が受け取っていたレポートは、DMS自身のレポート層が生成し、週次バッチ・サイクルで届きました。
OEMが私たちに見てもらいたいと依頼したのは、可視性とは無関係でした。お客様接点の8システムを単一のフロントエンドに統合してほしい(中央顧客ポータル — 別の案件、別の記事)、というものでした。それを実施している間、私たちは運用チームに同じ運用上の問題を繰り返し説明することになりました:DMSは何が起きているかを知っているが、それに行動する必要のある誰もが、DMSが知っていることを、行動に間に合うタイミングで見ることができない。 その文を運用チームは三つの異なる会話で三度、私たちに繰り返しました。三度目の後、私たちはフロントエンドの統合を止め、後にディーラー・インテリジェンス・プラットフォームになるものを構築し始めました。
本記事は、私たちが何をしたかを、層ごとに歩きます。Cubastionの設置パターンが普遍的に適用可能だから(そうではない — どのエンタープライズ・アプリケーション・スタックにも独自の癖がある)ではありません。しかし、特定の設置の下にあるパターン — 読み取り専用AIをSystem of Recordの上に、層ごとに、決して書き戻さず、決して置き換えない — は、その後30以上の案件で私たちが繰り返してきた、もの、です。
なぜこれは AI 案件ではなく、Business Applications × AI 案件か
OEMに「リアルタイム可視性プラットフォーム」で歩み入るAIベンダーのほとんどは、自社製品を基盤として記述します — こちらが我々のインテリジェンス層、それを御社のデータに向けてください。これらの案件のほとんどは2年目までに失敗します。AIベンダーがDMSを内側から知らないから、です。DMSのテーブルスキーマ、更新サイクル、レポート層の遺物、ある特定ベンダーの導入で service_record テーブルと parts_inventory テーブルがどう関連するか — これらは、それらのアプリを構築し稼働させてきた人だけが知ること、です。その知識なしには、上のAI層は運用チームが信頼できないシグナルを生み出します。シグナルがDMS自身の運用上の現実と一致しないから、です。
Cubastionの主張 — Business Applications × AI — はこのパターンへの構造的な答え、です。私たちはAIを御社のDMSの並行に設置しません。御社の業務がすでに使っているアプリケーション・エコシステムの内側に、System of Recordの上に読み取り専用で、業務が持続できる特定のスタックで設置します。下のウォークスルーが意味を持つのは、その立ち位置から、です。
DMSが誰にも、行動に間に合うタイミングで伝えられなかったこと
私たちが触れる前、DMSが稼働していた状態についての、三つの運用上の事実。
レポート・サイクルは週次でした。 DMS自身のレポート層は業務データを集約し、週次サイクルでレポートを生成しました。ディーラー責任者は月曜の朝にレポートを受け取り、前週の業務を記述したものを見ました。彼らがそれを見る頃には、取り得た行動 — サービスベイ容量の再バランス、繰り返す品質フラグへのエスカレーション、部品不足の伝播への介入 — は6日遅れていました。レポートは正確でした。意思決定行動には役立たないものでもありました。
可視性は経営フロアに住みました。 CDOはリアルタイム・ダッシュボードを持っていました。データチームが構築し、Tableau に住み、15分ごとに更新されました。CDOは、いつでも、165拠点すべての業務状態を見ることができました。ディーラー責任者は見られませんでした。技術者は見られませんでした。可視性は存在していました — ただ、それが示すほとんどに行動できない役割がアクセスできる、間違った場所に住んでいた、ということ、です。
DMSアプリ画面は昨日を表示していました。 技術者のワークショップ・アプリ — 毎日何時間も使う画面 — は、DMS自身のより遅いサイクルで更新されました。新しいサービス・ジョブを開く頃には、見ているお客様履歴ビューは、前夜にDMSのレポート層が生成したもの、でした。お客様は隣に座っていました;見ていた履歴は12時間前のもの、でした。
DMSは何が起きているかを知っていたが、それに行動する必要のある誰もが、DMSが知っていることを、行動に間に合うタイミングで見ることができなかった。運用チームはその文を三つの異なる会話で三度、私たちに繰り返した。三度目の後、私たちはフロントエンド統合を止め、構築を始めた。
私たちが始めたアーキテクチャ上の問い:DMSを書き換えずに、すでに作業しているアプリ画面を置き換えずに、System of Recordに何かを書き戻さずに、ディーラー責任者、技術者、コンタクトセンター・エージェントに、CDOがすでに持っている同じ運用ビューを、どうやって与えるか?
答えは業務を通じた四段階の歩みになりました。各段階がDMSの上に一つの層を設置しました。どれもDMS自体には触れませんでした。
四段階のウォークスルー — DMSから10分更新へどうたどり着いたか
以下は実際の作業順序、業務が通過した段階として提示しています。第一段階は私たちが業務を見つけた場所。第四段階は私たちが業務を残した場所。下のパターンは、特定のアプリケーション・スタックに合わせた調整を伴って、その後30以上の案件で繰り返されました。
Stage 1 · 私たちが歩み入った場所 週次バッチレポート。SoRとしてのDMS。
DMSは自身のレポートを週次バッチ・サイクルで生成しました。外部のインテリジェンス層なし。ストリーミングなし。ディーラー責任者は月曜の朝に先週のレポートを読みました。まだダッシュボードを誰も構築していなかったから、CDOにはリアルタイム可視性がありませんでした。技術者が使ったアプリ画面はDMS自身の遅い内部サイクルで更新されました。
DMSアプリ画面(レガシー・インターフェース) · DMSレポート・モジュール(バッチ生成の週次レポート) · 外部CDCなし · DMS外のデータウェアハウスなし · AI層なし
なぜこの段階をスキップできなかったか
DMSはSystem of Record、でした。続くすべての段階は、それを機能的に変更されないまま残さなければなりませんでした。最初のタスクはDMSを内側から理解すること — テーブルスキーマ、service_record と parts_inventory と customer_history の関係、内部レポート生成のタイミング、Debeziumが安全に接続できる場所を教えてくれるインデックス・パターン。これらは一般的なものではありません。規律は、AIベンダーのドキュメントを読む前に、DMSを読む、というもの、です。
私たちは Debezium を設置し、DMSの変更ログを読みました。約69の業務テーブルがCDCストリームとして流れ出ました。数TB累積。DMS自身は読まれていることを知りませんでした — Debeziumは変更ログをタップし、アプリケーションをタップしないから、です。書き戻しなし。トランザクション経路への追加負荷なし。ストリーミング・パターンはDebeziumリファレンスでよく文書化されています;作業はどのテーブルをどの頻度でストリームするかを選ぶこと、でした。
Debezium CDC ストリーム · 約69テーブル · 数TB累積 · 下流データ・プレーンへのストリーミング · DMSスキーマへの変更なし · 書き戻し経路なし
この段階が届けたもの、届けなかったもの
Stage 2の終わりには、DMSからほぼリアルタイムでデータが流れ出ていました。まだ誰にも可視性を与えていませんでした。データは下流の Databricks 環境に行きました;オペレーターの視点からは何も変わっていませんでした。これが「セットアップ・タスク」ではなく独立した段階である理由は、後で失敗するほとんどの案件がここですでに漂流したから、です — Debeziumを出荷し、それをリアルタイム可視性と呼びました。違います。それはCDCパイプライン、です。違いがあります。
Stage 3 · AI インテリジェンス層 ストリームの上で Databricks が推論する。
私たちはDebeziumストリームの上に Databricks でインテリジェンス層を構築しました。サービス・スループット・パターンの異常検知 — 過去業務データで訓練された教師なしMLモデル、ディーラー責任者が知りたい逸脱(サービスベイ容量ドリフト、繰り返す品質パターン、異常なエスカレーション密度)をフラグ。テーブル横断統合 — DMS自身のレポート層が週次集約で実行するためにできなかった方法で、サービス記録イベントと部品在庫状態とお客様履歴文脈を結合。部品需要の予測フォーキャスト — 拠点レベルで近期の部品要件を予測する時系列モデル。MLflow によるモデル管理、AI-SDLCパターンに従って文書化されたモデル・ガバナンス。
Databricks インテリジェンス層 · ML 異常検知 · テーブル横断統合 · 時系列フォーキャスト · MLflow によるモデル・ライフサイクル · 下にあるAI-SDLCデリバリー方法論
なぜこれは Splunk スタイルの展開ではないか
SplunkやほかのIT運用監視ツールも、ストリーミング・データの上に座ります。同じアーキテクチャ・コンポーネントではありません。Splunkは監視コンソールにアラートを表示します;このインテリジェンス層は、役割の位置で、オペレーターの作業アプリの内側でシグナルを表示します。Stage 3 でのアーキテクチャの違いは小さい。Stage 4 での違いがすべて、です。ここで止めて、リアルタイム監視と呼ぶこともできました。私たちは止めませんでした — ディーラー責任者がまだ層が生成しているものを見ることができなかったから、です。
Stage 4 · 私たちが業務を残した場所 役割の位置で Power BI · 10分更新 · 作業中のアプリの中で。
私たちはインテリジェンス層の出力を役割に届けました — ディーラー責任者がすでに作業していたアプリの内側に埋め込まれた Power BI を通じて、10分ごとに更新。別のダッシュボードではない。新しいコンソールではない。技術者がジョブを記録するために使っていた同じワークショップ・アプリが、いまや役割フィルター済のビューで意思決定シグナルを運びました。サービスベイ・スループットがディーラー責任者の朝のログインで可視。部品需要フォーキャストが技術者がサービス・オーダーを開くと表示。お客様履歴パターンがコンタクトセンター・エージェントが電話を取るとフラグ。
Power BI をオペレーターの作業アプリに埋め込み · 10分更新 · 役割フィルター済ビュー(ディーラー責任者 · 技術者 · コンタクトセンター・エージェント · サービス・マネジャー) · シグナルが必要なところでチャネル横断のお客様文脈
テクニシャン・コ・パイロット拡張 — Layer 4、AI アシスト
Stage 4が意思決定可視性を届けた後、その上に選択的なGenAIアシストを追加しました — テクニシャン・コ・パイロット・プログラム(TIC、2024年12月以降稼働)。TICパターンは、サービス手順、過去事例、エンジニアリング通報に対するRAGスタイルの取得、です。AI/非AI境界は判断クラスごとに文書化されています — 技術者が診断コールを所有し、AIが取得・提案します。これと隣接プログラムを横断して、9つのGenAI用途が稼働中。AIアシストは、意思決定可視性の後に来る、前ではない。会社初期にその逆を試みました;結果は持ちこたえませんでした。
業務にとって何が変わったか
以下は、開示可能な数値で、作業の運用上の形、です。アーキテクチャ上の変化が構造的な要点 — 数値はアーキテクチャが本番で持ちこたえた証明、です。
Stage 4 が着地した後の業務の姿
- ディーラー責任者は1時間以内に容量を再バランスするようになりました。 週次バッチレポートを読むのを止めていました。朝のログインがいまや10分更新でサービスベイ・スループット、部品需要状態、お客様接点指標を表示。月曜のレポートを待っていた判断が、火曜の午後に起きるようになりました。
- 技術者はすでに使っていたのと同じ画面で意思決定シグナルを見るようになりました。 新しいツールなし。新しいログインなし。ワークショップ・アプリが今や役割フィルター済ビューを運びました。165拠点のFUSO デジタル・サービス・センター拡張で、ページ読み込みレイテンシが90%改善しました。
- ディーラーとバックオフィス間の連絡遅延が70%低下しました。 コンタクトセンター・エージェントが電話を取った時、チャネル横断のお客様履歴文脈が表示されました。お客様は同じ文脈を複数回説明するのを止めました。
- サービスネットワーク全体で資源配分が45%改善しました。 以前は週末を待っていた容量再バランス判断が、今やその日のうちに起きるようになりました。パターンが拠点を横断して繰り返されました。
- DSC拡張でジョブカード処理効率が7,400%増加しました。 基準をアーキテクチャとして伝達(7月Set 2フレームワーク)が、役割の位置での意思決定シグナルと複利で効きました。両者の組み合わせが、いずれか単独ではなく、運用シフトを生みました。
- CDOは新しいダッシュボードを発注するのを止めました。 経営フロアのTableauビューはそのままでした — しかし会話は「次に何を可視化すべきか」から「次にどの判断クラスを役割フィルターが運ぶべきか」へと移りました。
一次的な成果は:ディーラー責任者は1時間以内に容量を再バランスできるようになった。技術者は作業アプリの中で必要なものを見るようになった。お客様は業務が反応するだけでなく予測できることに気づいた。DMSは変わらなかった。
何を学んだか — 繰り返し現れた四つの観察
上の歩みは一つの案件、です。パターンは私たちが繰り返してきたもの、です。以来30以上の案件で四つの観察が現れました。
1 · AIはビジネスアプリの内側に設置する、決して並行ではない。 インテリジェンス層はCDCを通じてDMSから読みます。役割フィルターはオペレーターがすでに作業しているアプリの内側で表示します。AIアシストは別のコンソールではなく、ワークショップ・アプリに住みます。私たちが歩み入ったすべての並行設置は2年目までに失敗しました — オペレーターは、すでに作業している場所に住まないツールを採用しません。
2 · System of Record は聖域。 読み取り専用。書き戻しなし。スキーマ変更なし。DMSが業務を稼働させ、インテリジェンス層がそこから読み、その上にシグナルを表示します。6年間で単一のDMS、ERP、CRMを引き剥がす必要はありませんでした。規律は構造的、です:System of Record は変わらないまま、AI層は上で自身の場所を獲得する。
3 · 役割フィルターが、ほとんどのプロジェクトが失敗する場所。 Stage 3(ストリームの上のインテリジェンス層推論)はアーキテクチャ的に興味深い部分、です。Stage 4(結果を役割に、作業アプリの中で届ける)が運用上より難しい部分、です。私たちが歩み入ったほとんどのエンタープライズAIプロジェクトは、Stage 3に到達し、そこで止まりました。結果は、運用フロアで誰も使わない監視コンソール、です。規律は、Stage 4を歩き続けること — たとえ経営ダッシュボードがすでに完成していても、です。
4 · GenAIアシストは最後に来る。 テクニシャン・コ・パイロット(TIC)拡張は、Stage 4が着地した後に追加しました。役割フィルターがある場所にある前にGenAIアシストを追加すると、技術者が一度尋ねて二度と戻らないチャットボットになります。後に追加すると、技術者が信頼するツールになります — すでに意思決定シグナルを与えている同じビューに住むから、です。AIアシストは最も目に見える層、です;また、最後に設置する層、でもあります。
よくある質問への回答
Dealer Management System の上にリアルタイム・インテリジェンスをどう構築するか?
DebeziumなどのChange Data Captureエンジンを DMS の変更ログに接続し、業務テーブルを下流データ・プレーン(Databricks、Snowflake等)にストリームし、その上にAIインテリジェンス層を構築(異常検知、テーブル横断統合、予測フォーキャスト)し、結果を役割フィルター(Power BI等)を通じて、オペレーターがすでに作業しているアプリに埋め込んで表示します。規律は:読み取り専用、DMSへの書き戻しなし、System of Recordのスキーマは決して変更しない、です。
なぜ Debezium 特定のものを使うのか?
Debeziumは、トランザクション負荷を追加せずにDMSの変更ログをタップします。DMSのアプリ経路は触れられない;データ流通はDMSがすでに自身の複製ニーズで内部使用している変更ログ複製機構を通る、です。これは、トランザクションSystem of Recordからほぼリアルタイム・データを抽出する、最も低い妨害の方法、です。パターンはDebezium固有ではない — 同等のCDCエンジン(Oracle GoldenGate、AWS DMS、IBM CDC)が同じアーキテクチャ形状に従う — がDebeziumドキュメントが最も広く利用可能なリファレンス、です。
AIインテリジェンス層は実際に何をするか?
本案件では三つの作業クラス。業務パターンの異常検知(教師なしML、ディーラー責任者が知りたいサービス・スループットの逸脱をフラグ)。テーブル横断統合(サービス記録イベントと部品在庫状態とお客様履歴文脈を結合 — DMS自身のレポート層がほぼリアルタイムで生成できない種類の結合)。部品需要の予測フォーキャスト(拠点レベルで近期の部品要件を予測する時系列モデル)。すべてDebeziumストリームの上のDatabricksで実行。MLflowによるモデル管理。
役割フィルターとは何か、なぜほとんどのプロジェクトが失敗する場所か?
役割フィルターは、インテリジェンス層の出力を、役割固有の意思決定シグナルに変換し、別の監視コンソールではなく、オペレーターがすでに作業しているアプリに埋め込んで表示するアーキテクチャ・コンポーネント、です。私たちが歩み入ったほとんどのエンタープライズAIプロジェクトはインテリジェンス層段階に到達し、そこで止まり、運用フロアで誰も使わない監視コンソールを生み出しました。役割フィルターはインテリジェンス層より構築が難しい — オペレーターの作業アプリの深い知識を必要とするから、です — そしてそれがまさにAIベンダーが通常欠いている知識、です。
なぜ System of Record は変わらないままか?
三つの理由。第一に — DMSが業務を稼働させる。それを変更することは、事業が依存する運用継続性へのリスクを導入する。第二に — ほとんどのDMSは数十年の運用挙動をスキーマ、インデックス、レポート生成ロジックにエンコードしている。置き換えや変更は二次的失敗を生み、表面化するのに四半期かかる。第三に — インテリジェンス層の仕事はDMSからシグナルを抽出することであり、置き換えることではない。読み取り専用が、AI層が業務に追加のリスクを吸収させずに自身の場所を獲得することを可能にする、アーキテクチャ上の性質、です。
この案件は通常どのくらいかかるか?
上で記述したウォークスルー — Stage 1ベースラインからStage 4運用可視性まで — は、DMSの特定の導入形状と範囲の拠点数に応じて、最初の展開で通常9〜15か月、です。AIアシスト拡張(Layer 4 / TICパターン)は通常、12〜18か月目に続きます。AI-Assisted SDLC方法論で届けます — デリバリー状態への可視性、フェーズごとの明示的な基準、名指しの人間所有者、ライフサイクル横断の監査証跡。約束:確実な納品 × 品質保証 × OEM運営モデルへの適合。
シリーズの記事
- 記事01. 6年間のビジネスアプリケーションの内側でのAI設置 — Kumarのフラッグシップ。
- 記事03. 30以上の案件で繰り返し閉じてきた、業務アプリ層の三つのギャップ。
- 記事04. アンドンは最初のAIインテリジェンス層だった · トヨタが78年早かった理由。
- 記事05. あなたのDMS、CRM、サービスベイ・アプリが教えてくれること。
- 記事06. DMS · ERP · CRM の上にAIを設置する方法 · System of Record に触れずに。
- 記事07. 30以上のエンタープライズ・アプリケーションの内側にAIを設置して学んだこと。
Champion Kit · あなたのアプリのどこにAIが住んでいるか?
次回の90分リーダーシップ会議のための1枚の実践診断。5つの質問が、自社の顧客接点アプリケーションで、AIが現在 並行に · 上にボルト止め · 内側に統合 · まだ存在しない のどれであるかを特定し、どのCubastion案件パターンが適用されるかを推奨します。無料、フォーム不要、直接ダウンロード。
cubastion.com/champion-kit/august-where-does-ai-live
ウォークスルーに当社のチームを部屋に入れたい方へ — Cubastionでは、エンタープライズ・アーキテクト、運用責任者、経営側スポンサーのための構造化された90分セッションを実施しています:現状のDMS/ERP/CRMウォークスルー → 12か月のAI設置パターン → AI-SDLCデリバリー順序。件名を「DMS-to-AI ウォークスルー」として、japan@cubastion.com までご連絡ください。
Cubastion · 2026年8月 · 記事02 / 7 · 実践ウォークスルー
エンタープライズ・アプリケーションの内側のAI · 実践ウォークスルー:DMSからリアルタイム・インテリジェンスへ · 2026年7月〜12月コンテンツ戦略フレームワークに基づく