レガシーDBを動かさず、ガバナンスの効いた分析基盤を最短で
基幹と周辺システムからの抽出には専門知識と時間がかかり、分析まで届かない。本番系への負荷と改修は不可。その制約を動かさないまま、出所を説明できる分析基盤を立てる。
業界に共通する課題
レガシーからの抽出が重い
基幹・周辺システムからのデータ抽出に専門知識と時間が必要で、分析が進まない。抽出依頼が数週間待ちになる。
データの出所を説明できない
リネージュ（どこから来た数字か）が追えず、監査・当局対応の負担が大きい。「この数字の根拠は」に即答できない。
リスク・収益レポートが月次
横断集計が手作業のため月次が限界。与信・リスクの判断が遅れ、機会損失と与信劣化の両方を招く。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- 契約管理システム（レガシー）
- 会計システム
- 営業支援システム
- 債権管理
- 監査対応（データの出所）
- 当局報告
- リスク・収益の横断集計
- 個人情報の分離管理
症状：残高は契約管理システム、費用は会計システム、案件の進捗は営業支援システムにあり、顧客コードの体系が3系統で異なる。加えてデータ定義書の更新が止まっており、同じ「残高」でもシステムごとに算入範囲が違う。本番系に負荷をかけられないため抽出は夜間バッチに限られ、横断集計は月次が限界になっている。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
CDCで本番DBに負荷をかけず変更差分のみを複製。本番系は無改修・影響ゼロで接続できます。読み取り専用のため既存の運用に手を入れる必要がありません。
揃える
カタログ管理・スキーマバージョニングで全データの定義・出所・変更履歴を常に説明可能に。v1→v2→v3と差分が自動記録されます。
使う
与信・収益ダッシュボードの日次化、取引データの異常検知・不正検知モデルへのデータ供給。監査・照会対応の工数が半減します。
本番系と分析系を完全に分離します。分析要件の追加や変更はデータ基盤側だけで完結し、基幹には手が入りません。変更のたびに大規模なリグレッションテストを組む必要がなくなります。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
契約管理システムと入金データを契約IDで結合し、区分別に集計しました。あわせて各数値の取得元と時点を添えています。
| 契約区分 | 契約件数 | 残高 | 延滞率 | 前月比 |
|---|---|---|---|---|
| ファイナンスリース | 18,420 | ¥284,100百万 | 0.82% | +0.04pt |
| オペレーティングリース | 6,180 | ¥ 96,400百万 | 0.41% | ▲0.02pt |
| 割賦・ローン | 31,900 | ¥118,700百万 | 1.94% | +0.21pt |
割賦・ローン区分の延滞率が0.21pt上昇しています。業種別に分解すると上昇分の68%が特定2業種に集中。数字の出所は raw.contract v4（契約管理システム・前月末23:40取得）と raw.payment v2 のJOINで、変換定義とスキーマ変更履歴はカタログから出力できます。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.contract_portfolio- 契約番号
contract_id - 顧客コード
customer_id - 契約区分
category - 残高
balance - 延滞日数
delinquency_days - 支店コード
branch_id - 基準日
as_of
raw層に原本と履歴をそのまま保持したうえでmart層に整形するため、「どの数字がどのソースの何時点のものか」を常に遡って説明できます。要件変更にも再整形で追随できます。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 8:30リスク管理
前日基準の与信ポートフォリオと延滞推移をAIに照会（従来は月次）。異常な増加は能動アラートで届く。
- 昼 13:00経営企画
「支店別の収益と資産効率」を会話で取得。役員向け資料の下地が即座に揃う。
- 午後内部監査
照会に対して、数値だけでなく取得元・変換定義・スキーマ変更履歴をセットで提示できる。
- 四半期当局報告
報告数値をカタログのリネージュ付きで出力。説明準備の工数が大幅に減る。
想定効果（仮定に基づく試算イメージ）
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。
3つの使い方のうち、どれを使うか
3つは排他ではありません。Cだけで始めて、あとからBへ広げることもできます。
W3 WMS × AI照会
弊社WMS（W3 sirius / W3 mimosa）のデータをデータレイクに取り込み、MCP経由でAIが直接参照します。SQLの記述もBIツールの操作教育も要りません。聞けば返ってきます。
データレイク蓄積（データ基盤 格納型）このモデルケースの主軸
他社システムのデータ連携サーバー、基幹DB、ECカートなどをCDC（変更差分取得）で接続し、毎日流れてくるデータをraw／mart 2層に溜め込みます。既存システムは無改修です。溜まったデータを、自然言語の指示で分析・加工できる状態にします。
ETL単体（システム直接連携）
データレイクを作らないまま、「抽出→変換→格納」だけのシステム間インターフェースとして使えます。個別IF開発をノーコードのGUI設定に置き換えることで、IF開発費が従来比 1/3〜1/2 になります。ここから始めて、あとからBへ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。