四層設置パターン。System of Record の上にリードオンリーで乗るAI。各層に特定のスタック名。6年間、30件超の案件、ゼロのDMS / ERP / CRM 入替。本稿は8月シリーズ全体の建築リファレンスです。
私たちが歩いて入る問題。 私たちが歩いて入るエンタープライズAIプロジェクトの大半には、一つの定義的特徴があります — 誰かが、ビジネスアプリの内側にではなく、並走する形でAIを設置しようとしている。並走パターンは、ダッシュボードの上のダッシュボード、運用レバレッジを伴わない統合コスト、そして — 作業の場所に住まないために — ワークショップ床の技術者が信頼できないAI能力を生みます。本稿は、その反対の方法です。
四層設置パターン。 第1層 — ビジネスアプリ基盤(DMS、ERP、CRM、顧客データ・プラットフォーム、コンタクトセンター・アプリ、ワークショップ・アプリ · System of Record)。第2層 — AIインテリジェンス層(Debezium → Databricks · 異常検知ML · モデル・ガバナンスのMLflow)。第3層 — 役割フィルター / 意思決定可視性ビュー(オペレーター画面の中に表出するPower BI)。第4層 — AI補助下の人間意思決定者(技術者・ディーラー店長・エージェント · RAG / GenAI / TIC パターン · 文書化されたAI/非AI境界)。
建築的コミットメント。 System of Record の上にリードオンリー。第2層は第1層を継続的に読み、書き戻さない。第3層は第1層がすでに提供するアプリ画面の中に表出する。第4層が行動し、AIが補助する。6年間と30件超の案件を経て、私たちはDMS、ERP、CRMを一台も入れ替えていません。
本稿の使い方。 設置の建築仕様として本稿を使ってください。既存アプリを第1層に対応付け。AI技術を第2層に対応付け。オペレーターの画面を第3層に対応付け。ガバナンス境界を第4層に対応付け。多くの案件は一層ずつギャップを閉じます — パターンは各層を、下の層に触れずに設置することを許します。
私たちが歩いて入るエンタープライズAIプロジェクトの大半には、一つの定義的特徴があります — 誰かが、ビジネスアプリの内側にではなく、並走する形でAIを設置しようとしている。本稿は、その反対の方法です — System of Record の上にリードオンリーで乗るAIを、層ごとに、スタックごとに — そして6年間、DMS、ERP、CRMを一台も入れ替えずに済んでいる理由です。
リードオンリー · 書き戻しなし · SoRはそのまま
System of Record の上に設置とは、AIインテリジェンス層がビジネスアプリのデータベース(またはCDCストリーム)を継続的に読むが、決して書き戻さないことを意味します。SoRは運用状態についての権威ある源泉のまま。第2層の出力 — 異常スコア、予測、検索結果 — はAIインテリジェンス層自身に保持され、SoRには保持されません。第3層は第2層から読み、オペレーターの画面にシグナルを表出する;オペレーターの行動は依然として、AI層経由ではなく、アプリ自身の書込経路を通じてSoRに記録されます。
この建築的コミットメントが、同じDMS、ERP、CRMが本番に6年間留まりつつ、その上のAIインテリジェンス層が能力を蓄積することを可能にします。何も置き換えられない。何もフォークされない。何も書き直されない。運用がアプリ・スタックにすでに行った投資は、稼ぎ続けます。
「リアルタイム・ダッシュボード」が誤った建築目標である理由
「リアルタイム・ダッシュボード」はマーケティング向けの用語。「意思決定可視性」は運用上意味のある用語。両者は同じではありません。多くのベンダーが提供するリアルタイム・ダッシュボードは、データウェアハウスから読み出し、状態を表示する並走サーフェスです。レイテンシは良い。役割でのシグナルは違う。オペレーターは自分が作業する画面の中ではシグナルを見ない。ダッシュボードはデモを勝ち取り、運用を失う。
四層設置パターンが目指すのは、リアルタイム・ダッシュボードではなく、意思決定可視性です。違いは建築上のもの — 各層はビジネスアプリ(第1層)またはAI能力(第2〜4層)のいずれかに対応し、層は、シグナルが基盤からAIインテリジェンス層を経てオペレーターの画面に届くように — オペレーターがすでにいるアプリの中で — 接続されています。対比は以下のとおり。
四つの層 · 一つずつ
第1層ビジネスアプリ基盤 · System of Record
第1層はSystem of Recordです。運用がすでに走らせている顧客接点ビジネスアプリ・スタック — DMS、ERP、CRM、顧客データ・プラットフォーム、コンタクトセンター・アプリ、ワークショップ・アプリ、保証管理システム。ここで状態が生まれ、ここでオペレーターが作業し、ここにトランザクション記録が住みます。
第1層における建築的コミットメントが、残りのパターンを機能させます — 第1層は置き換えない。6年間の案件、30件超の顧客接点モダナイゼーション・プログラム、ゼロのSoR撤去。2026年にディーラー店長が開くDMSは、多くの案件で2020年に開いていた同じDMS。変わったのは、その上のすべてです。
担うもの
運用状態、顧客履歴、トランザクション記録、アプリ固有のビジネスロジック。運用が依拠するすべてに対する権威ある源泉。
触れる場所
データベース読込経路(CDC)。スキーマは変更しない。書き戻さない。アプリのトランザクション経路には介在しない。
Cubastion 実証アンカー · 第1層
Hyundai ICDB · 統合顧客データベース — 私たちが実装した最も明示的な第1層仕事。六つの分断されたビジネスアプリを単一の基盤に統合する一方で、ソースアプリのいずれも書き直さない。統合は第1層に住む;再構成可能性は組み込まれている;ソースアプリは以前と完全に同じように動き続ける。
第2層AIインテリジェンス層 · 第1層の上にリードオンリー
第2層はAIが住む場所です。第1層から継続的に読み — 典型的にDebeziumがアプリのデータベースに対してChange-Data-Captureで走り — 変更ストリームをDatabricksベースのインテリジェンス層に供給し、そこでMLがシグナルを生みます — 部品不足パターン向けの異常検知、在庫リバランス・パターン向けの需要予測、上申密度パターン向けの分類、サービス手順パターン向けの検索拡張生成。MLflowがモデルのバージョン管理と血統を統治し、生成されるすべてのシグナルが再構成可能であることを保証します。
第2層における建築的コミットメントが、残りのパターンを安全にします — 第2層は読むが、書かない。AIの出力 — スコア、予測、検索結果、分類 — はAIインテリジェンス層自身の保管庫に保持され、第1層には保持されません。SoRのトランザクション整合性は第2層のモデル信頼性から独立しています。漂流するモデルは下のアプリを破壊しません。
スタック
CDC のための Debezium · インテリジェンス層のための Databricks · 異常検知・需要予測・分類・突合のための ML · モデル・ガバナンスの MLflow · 第4層がGenAI補助を要する場所のRAG検索コンポーネント。
規律
SoRの上にリードオンリー。モデルはバージョン管理と血統追跡。生成されるすべてのシグナルは入力状態に再構成可能。すべてのモデル改善は統治され追跡可能。
Cubastion 実証アンカー · 第2層
165支店DMSの上のDealer Intelligence — 第2層設置の代表例。DebeziumがDMSデータベースを継続的に読み、Databricksが部品不足異常検知のためのMLおよび在庫フィードに対する予測需要を伴うインテリジェンス層を生み、MLflowがモデルを統治。DMS自身はAIインテリジェンス層が読んでいることを知らない。運用は知っている。
第3層役割フィルター · オペレーター画面での意思決定可視性ビュー
第3層は、第2層のシグナルを、オペレーターが対処すべきものに、対処すべき瞬間に、すでにいる画面の中で変換します。仕組みは、既存のアプリ・ビューの中に埋め込まれたPower BIコンポーネント — DMSのワークショップ画面、CRMの接触レコード、ディーラー運営の予約ボード、エージェントの案件フォーム。シグナルはオペレーターの既存ツールに入る;オペレーターはそれを見るために別のダッシュボードに移動しない。
第3層における建築的コミットメントが、残りのパターンを導入可能にします — 第3層はオペレーターの画面の中に表出する。ディーラー店長は新しいツールを開かない。技術者はワークショップ・アプリと分析ダッシュボードを切り替えない。エージェントはサイドパネルを参照しない。シグナルは、役割キャリブレーションされた形で、オペレーターがすでに見ていたビューの中に — 行動選択肢を併せて — 現れます。
表出するもの
第2層のシグナルを役割固有の意思決定支援に変換したもの — アラート、ランク付き行動、予測伝播、事前計算済みリバランス選択肢。シグナルはトレーサビリティのためソース帰属と第2層モデル・バージョンを担う。
住む場所
既存のアプリUIサーフェスに埋め込まれる。Power BIコンポーネントはDMS/CRM/予約/ワークショップ・ビュー内にレンダリング。オペレーターの既存画面、役割でフィルター。
第4層人間意思決定者 · AI補助 · 文書化された境界
第4層は人間です。ワークショップ床の技術者。運営オフィスのディーラー店長。コンタクトセンターのエージェント。第2層 / 第3層のスタックは決定しない;表出する。第4層が行動する。行動が — 検索されたサービス手順、GenAIで要約された顧客履歴メモ、推奨される上申経路など — AI生成コンテンツを含む場合、AIが補助し、人間が決定する。AIの提案と人間の行動の境界は、すべての対話について文書化されます。
第4層における建築的コミットメントが、残りのパターンを統治可能にします — AI/非AI境界は文書化される。すべての第4層対話は、どの出力がAI生成だったか、どのモデル・バージョンがそれを生んだか、どの検索結果が貢献したか、人間がどの行動を取ったかを記録します。10月のガバナンス記事はこれを特に取り上げます — 同じ第4層記録が、稟議式アカウンタビリティ、METI準拠、J-SOX証拠、APPI処理を扱いやすくするものです。
パターン
文脈のためのRAG検索 + GenAI要約 · 人間の決定 · 文書化された境界。TIC(Technician Co-Pilot)パターンがワークショップ床における代表的な第4層展開。
ガバナンス
すべてのAI補助下の決定が、モデル・バージョン、検索ソース、信頼度スコア、人間の行動とともに記録される。監査証跡は事後ではなく設計時に第4層に組み込まれる。
Technician Co-Pilot(TIC) — ワークショップ・アプリの上の代表的な第4層設置。サービス手順ストアに対するRAG検索;関連公報と過去事案のGenAI要約;技術者が適用・フラグ・上申のいずれを取るかを決定。すべての対話が保証証跡と品質レビューのために記録される。「AIがこれを検索した」と「技術者がそれを決定した」の境界は、すべてのジョブチケットで文書化される。
既存アプリの上に設置し、置き換えない理由
このパターンにおける最も重要な建築選択は、私たちがしないことです。SoRを移行しない。DMSを書き直さない。CRMを置き換えない。ERPを新しいプラットフォームに統合しない。運用がすでに走らせている顧客接点アプリ・スタックは、第1層では変わらず動き続け、その上のすべての層が12ヶ月、18ヶ月、24ヶ月にわたって能力を蓄積します。
これが、本パターンに従う顧客接点モダナイゼーション・プログラムが減価ではなく複利化する建築的理由です。第1層への投資 — 多くの場合、運用のIT支出における最大の単一項目 — は稼ぎ続ける。第2〜4層への投資 — 通常は第1層コストの一部 — がその上に運用レバレッジを加える。何も再構築されない;再構築コストは、単純に、プログラム経済から取り除かれる。
これがまた、「プラットフォーム移行」が決して買い手フレンドリーになり得ない仕方で、本アーキテクチャが買い手フレンドリーである理由でもあります。CDOは取締役会に対して数年単位のSoR入替を防衛する必要がない。CIOは調達とベンダー切替を交渉する必要がない。CEOは切替のためのダウンタイムを承認する必要がない。四層設置は一層ずつ順序付け可能です — 第1層(多くの場合すでに存在)、続いて一つのアプリに対する第2層、続いて一つの役割に対する第3層、続いて一つの意思決定クラスに対する第4層 — そして、各ステップは次のステップが承認されることを必要とせずに、前のステップを複利化します。
「並走パターンの建築コストは、SoR投資が孤立化することです。SoRの上に設置することの建築上の利点は、SoR投資が複利化することです。6年経って、それが稼ぐプログラムと稼がないプログラムの差です。」
買い手の問い · この設置は意思決定可視性を加速するか、ダッシュボード爆発を増幅するか
私たちが遭遇するすべての顧客接点モダナイゼーション提案は、一つの問いで分類できます — この構築は意思決定可視性を加速するのか、それともダッシュボード爆発を増幅するのか? 四層設置パターンは前者への建築的回答です。並走パターンは、提供するベンダーがほぼ誰であれ、後者への建築的回答です。
提案をパターンに対して評価するために、買い手は層ごとに一つ、四つの問いを発することができます。提案は SoR(第1層)に触れるか? Yes ならば、建築は設置ではなく移行。提案のAIは SoR に書き戻すか(第2層)? Yes ならば、建築は AI 信頼性をトランザクション整合性に結合させた。提案はオペレーターの既存画面にシグナルを表出するか(第3層)? No ならば、建築は並走ダッシュボード。提案はすべての対話で AI/非AI 境界を文書化するか(第4層)? No ならば、プログラムは10月のガバナンス枠組みで監査不能。
四つの問い、買い手側の建築診断。8月のChampion Kitの五問はこの診断にキャリブレーションされており、Kitの後に行う診断会話は層ごとの設置順序の会話です。
第4層の人間意思決定者は、ガバナンスが住む場所
10月シリーズ — Human-Guided Enterprise AI Operations — は第4層を特に取り上げます。本稿が建築レベルで記述した同じ文書化されたAI/非AI境界が、稟議互換のアカウンタビリティ、METI ガイダンス整合、J-SOX 証拠証跡、APPI個人データ処理の基盤となります。本稿の建築が10月のガバナンス枠組みを扱いやすくするものです — ここで第4層に境界が組み込まれていなければ、10月のガバナンス仕事は強制すべき監査証跡を持ちません。
アーキテクトから設置パターンについてよくいただく問い
System of Record を乱さずに、DMS、ERP、CRMの上にAIをどう設置するのか?
CDC によるリードオンリー。典型的にはDebeziumをアプリのデータベースにChange-Data-Captureモードで接続し、変更をDatabricksベースのインテリジェンス層(第2層)にストリーミングします。アプリのトランザクション経路は触れない — Debeziumはデータベースの変更ログを読み、ライブのトランザクション・テーブルを読まない。SoRは以前と完全に同じように走り続けます。6年間の設置、書込経路に触れたSoRはゼロ。
CDCを接続できないベンダーロックされたデータベース上のアプリの場合は?
大半のエンタープライズDMS、ERP、CRMプラットフォームは、ネイティブCDC、ベンダー支援イベント・ストリーム、またはDebeziumに代替できるスケジュール抽出パターンを露出します。アプリが真に閉じている場合、第2層は適切な頻度でアプリ自身のAPIを通じて読みます — レイテンシはやや高くなりますが、建築パターンは同じ。30件超の案件で7種類の商用DMSプラットフォームの上に第2層を成功裏に設置してきました — 商用SoRがパターンの機能を妨げた例はありません。
これは Snowflake や Databricks 単独のようなリアルタイム・データプラットフォームと何が違うのか?
データプラットフォーム単独は報告機能の基盤 — 本アーキテクチャでは第1層のデータウェアハウス相当であって、第2層ではありません。AIインテリジェンス層(本パターンの第2層)はデータプラットフォームの上に乗り、役割で意思決定シグナルを生みます。Cubastionの設置はDatabricksを第2層のエンジンとして使います — 第2層の代替としてではなく。建築的区別が、「すでにデータプラットフォームを持っている」が設置パターンの代替にならない理由です。
AIがSoRに書き戻すことはあるか?
ありません。建築的コミットメントとして、第2層の出力は第2層自身の保管庫に保持され;オペレーターの行動 — 第4層で取られる — はAI層経由ではなく、アプリの既存書込経路を通じてSoRに記録されます。この分離が、モデル・バージョンが変わり、モデルが漂流し、モデルが置き換えられても、下のアプリのトランザクション整合性に決して触れないことを可能にします。
実際のプログラムで四層設置をどう順序付けるか?
典型的には:第1層はすでに存在(既存のDMS / ERP / CRM)。第2層は最初に一つのアプリに対して設置 — 通常はDMS、部品不足伝播(第5回シグナル02)向け。第3層はディーラー店長ビュー内に最初に表出;他の役割が続く。第4層は最も簡単なAI/非AI境界 — ワークショップ・アプリの上のTechnician Co-Pilotパターン — から始まり、拡張する。多くのプログラムは6〜9ヶ月で二つのアプリにわたって四層すべてに到達する;追加アプリへの拡張はその後、四半期に一アプリのペースで走ります。
四層全体のガバナンス姿勢は?
第1層のガバナンスはSoRがすでに持つもの(典型的に成熟、監査対応済み)。第2層はMLflowによるモデル血統で統治。第3層はPower BIの行レベル・セキュリティとアプリの既存役割モデルで統治。第4層はAI/非AI境界がすべての対話で文書化される場所 — 10月のガバナンス記事の基盤。四層は能力を積み重ねるのと同じ仕方でガバナンスを積み重ねる:各層が追加し、どれも次の層が承認されることを必要としない。
他の8月の記事とどう繋がるのか?
本稿はシリーズ全体の建築リファレンスです。第2回は第2層を深く歩く(DMSからリアルタイム・インテリジェンス)。第3回の三つのギャップは第2層・第3層・第1層の不在に対応。第4回は1948年のアンドン(第2層+第3層+第4層)から2026年パターンまでの建築的系譜を追う。第5回は五つのシグナルを特定の第2層技術に対応付け。第7回はパターン全体に対するKumarの経営的締めくくり。
2026年8月のChampion Kit · 5問 · 1ページ
Kitの五問のうち二問は設置パターンに特にキャリブレーションされています — AIインテリジェンス層は貴社の顧客接点ビジネスアプリの上に設置されているか、それともそれらに並走しているか? · 五つの主要シグナルそれぞれについて、AIインテリジェンス層はどこに接続されているか? Kitは層ごとのギャップとそれを閉じる設置順序を特定します。
2026年8月シリーズの連作
- 第1回: 6年間のビジネスアプリケーションの内側 — 実践者フラッグシップ。本稿のアーキテクチャは「内側 vs 並走」主張の下の技術的証拠。
- 第2回: DMSからリアルタイム・インテリジェンスへ — 最深ウォークスルー。165支店の数TB DMSの上での第2層本番設置。
- 第3回: 業務アプリ層の三つのギャップ — 診断。三つのギャップは第3層(役割フィルター)、第2層(レイテンシ)、第1層(基盤)の不在に対応。
- 第4回: アンドンは最初のAIインテリジェンス層だった — 系譜。四層設置パターンは本番仕様でのアンドン翻訳表。
- 第5回: 五つのシグナル × 五つのアプリ — 五つのシグナルそれぞれは、特定の第1層アプリの上に設置された特定の第2層技術。
- 10月第1回(予告): Human-Guided Enterprise AI Operations — 第4層を特にガバナンス基盤として取り上げる。
これが8月シリーズ全体の建築リファレンスです。四つの層、各層にスタック名、下の層に触れずに各層を設置可能。DMSは残る。ERPは残る。CRMは残る。AIインテリジェンス層は上に乗る — リードオンリー — Power BIがオペレーターの既存画面の中でシグナルを表出し、人間意思決定者が文書化されたAI/非AI境界とともに第4層で行動する。6年間、30件超の案件、ゼロのSystem of Record入替。パターンが設置そのものです。Cubastion Consulting · 2026年8月 · 第6回(全7回)