Decision Agent

自社のデータ資産と業務コンテキストを理解する
意思決定AI Agent

企業のKPI定義とデータ資産、業務コンテキストをもとに、AI Agentが変化の要因と対応の方向性を提案します。

THE SHIFT

AI活用の中心が、質問応答から 意思決定支援へとシフトしています。

AI活用は単純な質問応答にとどまらず、定量データと業務ルールに基づく意思決定支援へと広がっています。 企業の競争力は、組織のKPIを理解し実行可能な意思決定を支援するAI Agentの実力によって左右されるでしょう。

STAGE 1

Document Q&A

文書ベースのAIチャットボット

質問例

「売掛金の回収基準を教えて」

「保険金の例外承認手続きを教えて」

システムの動作

社内規定・マニュアル・FAQを検索し、根拠を引用して回答

RAG

STAGE 2

Data Q&A

構造化データベースのAIチャットボット

質問例

「今月の売上はいくら?」

「担保別の損害率の状況は?」

システムの動作

指標・ディメンションのメタデータを参照 → SQL生成・実行 → 結果を返却

Meta data + Text-to-SQL

STAGE 3

Decision Agent

意思決定支援AI Agent

質問例

「売上改善案を提案して」

「損害率最適化の計画を教えて」

システムの動作

KPI改善案を生成 → 分析結果をアクションに接続 → HITLで実行

Semantic MCP

数字を見せることと
次の一手を提案することは違います。

Decision Agent

KPI変化の要因を分析し、次の一手までを提案する意思決定AI Agentです。
自社の指標定義と業務コンテキストを理解した上で答えます。

Decision Agent

STEP 1

KPI異常検知

指標変化・異常兆候を捕捉

STEP 2

Driver分析

変化要因を定量的に分解

STEP 3

Lever探索

改善策の候補を導出

STEP 4

Action候補の提示

実行候補案を提示・担当者がレビュー

汎用AI
先週、損害率が3ポイント上昇しました。

数字は見せてくれます。
改善のために自分たちが何をすべきかは、
あらためて考える必要があります。

cancel コンテキストのない数値 - 実行不可
Decision Agent
商品Aが損害率上昇の40%を占めています。
病院Bの請求が25%影響しています。
支払いポリシーに関する改善案を2つ提案します。

変化の要因を突き止め、対応の方向性を提案します。

check_circle 原因分析 → 対応方針の提案

企業のデータ資産を活用するSemantic Store

KPI定義、変化要因(Driver)、改善手段(Lever)、アクセス権限をSemantic Storeに格納します。
Decision Agentは定義された意味体系をもとに分析するため、同じ質問には常に同じ答えが返ってきます。

既存のデータ資産
DB/DW 営業、顧客、運用、財務データなど
既存のBI資産 ダッシュボード・チャート・SQL
Metadata テーブル構造、スキーマ、指標
Semantic Store + MCP
KPI定義 Driver (変化要因) Lever (改善手段) アクセス権限
Decision Agent
KPIモニタリング 原因分析 対応方針の提案 Slack・メール通知

正確なSQLは、より長いPromptからではなく、
構造化された意味レイヤーから生まれます。

LLMは質問の意図を解釈し、分析計画を立てます。
実際のSQLは、Semantic MCPが指標定義と権限ルールを反映して生成します。

「自分が担当する補償センターの事故タイプ別請求件数と支払総額を教えて」

AS-IS : Promptベースの SQL生成

-- プロンプトとして渡されるスキーマ
fact_accident, fact_payment, claim_center_nm, payment_amt,
total_payment_amt ...
-- LLMが直接生成するSQL
SELECT accident_type_l1,
COUNT(*) AS claim_count,
SUM(payment_amt) AS total_payment_amt
FROM fact_accident
JOIN fact_payment
  ON fact_accident.accident_id = fact_payment.accident_id
GROUP BY accident_type_l1;
close 「自分が担当する」という権限コンテキストが欠落
close 「支払総額」の公式指標の選択ミス
close 誤ったJOINによる件数の過大集計

TO-BE : Semantic MCPベースの実行

-- LLMが生成するクエリ生成プラン
metrics:    [claim_count, total_payment_amt]
dimensions: [accident_type_l1]
context:    { group: regional_manager,
            claim_center: '東京本部' }
-- Semantic MCPが生成するSQL
SELECT accident_type_l1,
COUNT(DISTINCT claim_id) AS claim_count,
SUM(total_payment_amt) AS total_payment_amt
FROM claims_access_test
WHERE claim_center_nm = '東京本部'
GROUP BY accident_type_l1;
check ユーザーの組織contextを反映
check 公式指標と許可されたディメンションのみを使用
check 権限に基づく行フィルタを自動適用

Semantic MCPについてもっと知りたい方は
ブログで詳しい内容をご確認ください

詳しく見る →

USE CASES

KPIを継続的にチェックし対応が必要な、
あらゆる現場で機能します。

KPI変化の検知 変化要因の分析 (Driver) 改善手段の提案 (Lever) 実行効果
account_balance金融・保険 損害率の上昇 担保・審査方式・
請求パターン
高リスク代理店・
病院群の点検
過剰支払いの削減
headset_micAICC 待ち時間の増加、
SLA未達
コール量・対応種別・熟練度 シフト・ルーティング
調整
待ち時間の短縮、
SLA回復
local_mall流通 欠品率の上昇、過剰在庫 需要変動・発注サイクル・リードタイム 発注量の調整・
店舗間の再配置
欠品の削減、
在庫効率の改善
work公共 苦情の増加、処理の遅延 地域別リスク度・
予算執行率
予算配分・
支援優先順位
苦情の緩和、
政策効果の向上