契約・査定・代理店データを統合し、チャネル収益を可視化する
契約、保全、支払、代理店管理が商品ごとに縦割りになっている。横に並べる手段がない。商品系統ごとの権限を維持したまま、経営層だけが横断ビューを持つ形にする。
業界に共通する課題
商品系統ごとにシステムが分断
契約・保全・支払・代理店管理が商品ごとに縦割りで、横断分析ができない。同じ代理店の全商品の実績を集めるだけで各部門への依頼が必要。
代理店×商品別の収益性が不明
チャネル別の獲得コストと損害率を突合できず、代理店評価が感覚頼み。「売ってくれる代理店」と「儲かる代理店」の区別がつかない。
不正請求の検知が後手
支払査定データの分析が手作業で、不審な請求パターンの発見が遅れる。発見は事後の抜き取り監査に依存している。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- 自動車保険 契約システム
- 火災保険 契約システム
- 傷害保険 契約システム
- 支払査定システム
- 代理店×商品別の収益
- 獲得コストと損害率の突合
- 支払パターンの異常検知
- 募集人単位の実績
症状：契約と保険料は商品系統ごとの3システムに分かれ、支払は査定システムにある。代理店を横断して集計しようとすると、代理店コードが商品系統ごとに別採番であることに突き当たる。名称も「〇〇保険サービス（株）」と「株式会社〇〇保険サービス」のように表記が揺れており、同一代理店が別行として並ぶ。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
契約・保全・支払・代理店の各システムをCDCで接続。マルチテナント構造（テナント→グループ→レイヤー→データセットの4階層）で部門ごとに分離管理します。
揃える
契約者・代理店マスタを名寄せ・標準化し、収入保険料と支払・経費を同一粒度で統合。表記ゆれの突合ルールをETLのTransformで定義します。
使う
代理店×商品別の収益ダッシュボード、支払パターンの異常検知、AIへの照会で即席分析。代理店評価が定量的な根拠を持ちます。
横断分析と権限分離は、両立します。マルチテナント分離により、商品系統ごとのアクセス権限を維持したまま、経営層だけが横断ビューを持てます。見せてよい範囲の設計は、運用ルールではなくプラットフォーム側で担保されます。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
商品系統ごとに別採番だった代理店コードを名寄せし、収入保険料と支払・経費を同一粒度で集計しました。
| 代理店 | 収入保険料 | 損害率 | 事業費率 | 合算 |
|---|---|---|---|---|
| 代理店 H社 | ¥184,000千 | 78.2% | 24.1% | 102.3% |
| 代理店 J社 | ¥ 96,400千 | 69.4% | 26.8% | 96.2% |
| 代理店 K社 | ¥241,000千 | 61.8% | 22.4% | 84.2% |
代理店H社は合算102.3%で赤字です。商品別に分解すると、赤字の主因は自動車保険の特定車種構成（損害率91.4%）。① 引受基準の見直し協議、② 火災・傷害の構成比を高める推進策、の2案を提示します。あわせて支払査定で同一修理工場に集中する請求パターン（過去6ヶ月で通常比3.2倍）を検知しました。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.agency_performance- 代理店コード
agency_id - 保険種目
product_line - 収入保険料
premium - 支払保険金
claims_paid - 損害率
loss_ratio - 事業費率
expense_ratio - 基準日
as_of
代理店名の表記ゆれを名寄せし、商品系統をまたいだ代理店評価を1本のデータセットに。部門ごとのアクセス権限はテナント階層で担保されます。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 9:00営業推進
担当代理店の当月実績と収益性をAIに照会。訪問前に「何を推進すべきか」が数字で分かる。
- 昼 13:00損害サービス
支払パターンの異常検知アラートを確認。調査優先度付きのリストが届く。
- 夕 17: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へ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。