AIの数値は信頼できるか?企業AIにSemantic MCPが必要な理由

AIの数値は信頼できるか?企業AIにSemantic MCPが必要な理由

AIが答えた数字を信じるには、その数字がどの基準で作成されたかを説明できる必要があります。 企業データの意味、権限、および業務規則を反映するSemantic MCPとDecision Agentが必要な理由です。

このページでは、

AIに「今月の利益率はなぜ下がったのですか?」と尋ねることはもはや難しくありません。

質問を入力すればSQLが生成され、数字が出て、グラフが描かれます。答えが出たように見えます。しかし、その数字をそのまま役員報告資料に載せてよいかと問われると、ためらいが生じます。

業務ルールが反映された信頼できる最新の数字なのか。後で誰かに根拠を問われたときに説明できるか。AIが答えを出すことと、その答えを信じて決定することは別物です。

AIは正しそうな答えを出せるが、責任のある答えは出せないです。

差はAIモデルではなくデータの文脈で生じる

今後、企業が利用するAIモデル間の性能差は徐々に縮まっていくでしょう。OpenAI、Anthropic、Googleのモデルを使おうと、自社ネットワーク内のsLLMを使おうと、企業は必要に応じて複数のモデルを使い分けるようになります。そのとき差を生むのはモデルではなく文脈(Context)です。

AIが自社のデータ、指標、業務のやり方、権限体系、意思決定基準をどれだけ正確に理解しているかが重要になります。

企業データには数字だけがあるわけではありません。数字の裏には基準やルール、例外があります。「売上」というカラムがあるからといって、それがすなわち「我が社が定義する売上」であるとは限りません。

キャンセルを含むのか、税金を除くのか、請求日基準なのか入金日基準なのかはカラム名だけでは分かりません。その意味はたいてい別の場所にあります。誰かの頭の中に、古いレポートに、社内Wikiのどこかに、退職した担当者が残したSQLにあります。AIが企業データを正しく扱うためには、まさにこの隠れた基準を理解する必要があります。

企業が求めているのは参照ではなく判断の根拠だ

Text(NL)-to-SQLは自然言語の質問をSQLに変換する技術です。速く直感的で、デモでは特に印象的です。しかし企業が実際に求めているのは単純な参照ではありません。「今月の売上はいくらか?」ももちろん重要です。

ただし意思決定の場ではすぐに別の質問が続きます。この売上は確定基準か。キャンセルや保留は除外されているか。既存のレポートの基準と合致しているか。同じ質問を繰り返せば同じ答えが出るか。

同じ言葉で異なる数値の図: 03-same-words-different-numbers.png

企業がAIデータ分析に期待するのは数字を速く取り出すことではありません。その数字を会社の基準に沿って解釈し、意思決定の根拠にできるようにすることです。問題は組織や部署ごとに指標定義が異なる点にあります。

マーケティングチームのコンバージョン率とデータチームのコンバージョン率は違うことがあります。あるレポートはアクティブ顧客を直近30日基準で数え、別のレポートは90日基準で数えます。

データが多くてもKPIが改善されない理由

企業にはすでにデータもダッシュボードも豊富にあります。しかし、データが多いからといってKPIが自動的に改善されるわけではありません。

KPIとダッシュボードの限界図: 04-kpi-dashboard-limits.png

第一に、ダッシュボードで質問が途切れる。

ダッシュボードはKPIの現状と推移を示します。しかし「なぜ変化したのか」を掘るには、データを再取得して別途分析を依頼し、誰かが解釈する必要があります。現状は見えても、追加の質問はその場で続きません。

第二に、同じ質問で異なる答えが出る。

部署ごとにKPI定義や業務基準が異なれば、同じ質問でも異なる数字が出ることがあります。売上、コンバージョン率、損害率のように頻繁に使われる指標ほど基準がぶれると分析結果もぶれます。だからこそSemantic MCPのようにKPI定義と業務ルールを一貫した基準で管理する層が必要です。

第三に、数字は示せても改善案は出てこない。

多くのレポートは何が起きたかを示します。しかし何が影響を与えたのか、どこを優先して見るべきか、どのような対策を検討すべきかまでは示せません。

汎用AIも会社の基準、権限、改善手段を知らなければ実行可能な改善候補を出すのは難しいです。この点でDecision AgentがKPI変化の原因を分析し、改善候補を提案します。

ダッシュボードの質問をKPI改善の意思決定に繋げる

企業は最終的にKPIで成果を確認します。しかしKPIを眺めるだけで成果が向上するわけではありません。

重要なのは、ダッシュボードで見つけた変化を分析につなげ、その分析を改善の意思決定につなげることです。

HEARTCOUNTはこのプロセスを二つの方法で支援します。顧客の目的と準備状況に応じて、BI + AI Analyticsで素早く始めることも、Semantic MCP + Decision AgentでKPI改善の意思決定まで拡張することも可能です。

BI + AI と Decision Agent の比較図: 05-bi-ai-vs-decision-agent.png

第一はBI + AI Analyticsです。

企業はすでにBIとダッシュボードでKPIを見ています。したがってAI分析も見慣れない画面でゼロから始める必要はありません。

ダッシュボードで生じた質問が自然にAI Analyticsにつながると、実務者はフローを途切れさせずにそのまま分析を続けられます。「今月の売上がなぜ減ったのか」「製品群ごとに利益が大きく落ちたところはどこか」「お問い合わせの不満が特定のタイプで増えたか」「割引率と利益が連動しているか」などの質問をデータチームに差し戻したり別ツールに移したりせず、既存のBIデータセットを元にその場で分析できれば業務フローは大きく変わります。

BI + AI Analyticsは既存のBI資産を活かしてAI分析を素早く始めたいお客様に適しています。

第二はSemantic MCP + Decision Agentです。

Semantic MCPはAIと企業データの間で指標の意味、権限、実行基準を制御する層です。AIがデータベースに直接アクセスして勝手にSQLを作るのを許さず、会社が定義したKPI、計算基準、業務ルール、権限基準、既存BIの文脈の中で分析させます。

Semantic MCP による直接DBアクセス制御図: 06-semantic-mcp-no-direct-db.png

その上でDecision AgentはKPI変化の原因を分析します。どのような原因変数(Driver)が影響を与えたのか、どのような改善手段(Lever)を検討できるのか、どのような実行候補(Action)を考慮すべきかを併せて提案します。

この方式はダッシュボードの問いを単なる分析に留めず、KPI定義と業務ルールを構造化し、変化原因の分析と改善候補提示まで拡張したいお客様に適しています。まとめると、HEARTCOUNTは企業データをKPI改善の意思決定に変換するために二つの出発点を提供します。BI + AI Analyticsは既存のBIデータセットを基に、ダッシュボードで生じた質問をその場で分析します。

Semantic MCP + Decision AgentはKPI定義と業務ルールを反映して変化原因を分析し、改善候補を提示します。

AIが出した数字を信頼するためには

企業AI分析で本当に重要な問いは「AIがSQLを作れるか」ではありません。「そのSQLがどの基準で作られたのか」です。Semantic MCPはまさにその基準を管理します。

分析基準を管理するSemantic MCP

例えば保険会社の損害率はloss_ratioという名前だけでは不十分です。何を指すのか、どのように計算するのか、どの次元で分割して見るのか、誰がどこまで見られるのかを併せて定義して初めて使えるようになります。簡潔に書けば次のような形です。

Semantic MCP の定義図: 07-semantic-mcp-definition.png

こう定義されていれば、誰かが「今月の損害率がなぜ上がったの?」と尋ねてもAIは意味を勝手に推測しません。まずその「損害率」が会社標準の指標であるloss_ratioであることを確認し、定められた計算式と分析次元、権限範囲の中で分析を進めます。そしてどの基準とどのデータでその答えに至ったのかを辿れるように残します。これが単なるText-to-SQLとの違いです。Text-to-SQLは質問をSQLに変えます。Semantic MCPは質問を会社の基準に合った分析に変えます。

Decision Agentはどの基準で改善案を提示するか

Decision Agentは経営判断を代行するシステムではありません。重要な決定と最終の実行は依然として人のレビューと承認に基づきます。

Decision Agentの役割は、人が判断する前に見るべき根拠と改善候補を迅速に整理することです。既存のBIが「先月の売上が目標比で8%未達だった」のように何が起きたかを示すなら、Decision Agentは一歩進んでなぜ起きたのかと何を検討すべきかを結び付けます。ここで重要なのは、改善案が単なるAIの憶測ではないということです。

Decision AgentはKPI改善の業務ルールを含む軽量なOntologyを基に動作します。このOntologyにはKPIがどの原因変数(Driver)と結びつくか、どの改善手段(Lever)を検討できるか、どの条件でどの実行候補(Action)を提案できるかが構造化されています。

Decision Agent の Ontology 図: 08-decision-agent-ontology.png

例えば売上が下がった場合でも単に「プロモーションを強化してください」とは言いません。どの商品群、チャネル、地域、顧客層で変化が大きかったかをまず分析し、その結果を業務ルールとつなげて検討可能な改善候補を提示します。

つまりDecision Agentは、KPI変化検知 → Driver分析 → Lever探索 → Action候補提示の流れで動作します。ただし最終判断と実行は人が行います。AIが決定を代行するのではなく、人がより良い根拠に基づいて判断できるように、業務基準に沿った改善候補を絞り込む。それがDecision Agentの役割です。

自然言語で尋ねることを超えて

企業AIデータ分析の次の段階は単に「自然言語で質問できる」ことではありません。それは既にかなり実現されています。

本当の課題は、AIにデータの裏にあるビジネス上の意味を理解させ、人がより良い決断を自信を持って下せるように支援することです。

そのためには社内に散在する知識、業務のやり方、権限ルールをAIが活用できる文脈として整理する必要があります。AIデータ分析を実験段階から意思決定支援段階に移したいなら、出発点は大掛かりなAI導入ではないかもしれません。まず自社のコアKPIが何か、どの基準で算出するのか、そのKPIを動かす要因は何か、その答えを誰がどの権限で見られるのかを整理することから始めるべきです。

AIが出した数字と主張を信頼するためには、その答えがどの基準から導かれたのかを我々には説明の責任があります。

🤍
HEARTCOUNTデモを依頼する

Semantic MCPとDecision Agentの実際の動作画面が気になる場合はデモをお申し込みください。御社での活用方法を一緒に検討いたします。