【第5回】オントロジーの上にMCPを組み込むとAIが変わる

「Coupangの売上を教えて」

この質問をCSVと一緒にChatGPTに投げたことがあれば、結果がいかに不安定かご存じでしょう。あるときはWingの売上だけ、あるときはRocket Growthまで合算し、またあるときはEZAdminのOMS基準で答えます。同じ質問なのに、毎回違う数字が返ってきます。

RAG（検索拡張生成）を組み込んでドキュメントを入れても同じです。「経営管理ダッシュボードの貢献利益率と、商品別成果の実貢献利益率は分母が異なる」という文脈をドキュメントに書いておいても、AIが質問の時点でそれを引き出して使うかどうかは運次第です。

このシリーズで扱ってきた問題 — 商品名の衝突（第2回）、在庫と出荷の乖離（第3回）、広告費の配分（第4回）— をAIが正しく扱うには、データの上に構造化された関係の定義（オントロジー）があり、AIがその関係にツールとしてアクセスできなければなりません。

そのツールがMCP（Model Context Protocol）です。

RAGだけではうまくいかない理由

ドキュメントベースのアプローチの限界

コマースデータの文脈をドキュメントにまとめて、RAGに入れたとしましょう。

ドキュメント1：「純売上 = 決済合計 - Cafe24返金 - Naver Pay返金」
ドキュメント2：「商品別成果の分母は決済金額（返金差し引き前）」
ドキュメント3：「Sabangnetのデータは整合性が低い場合がある」
ドキュメント4：「CoupangにはWing/RG/サプライヤーハブの3種類がある」

どれだけ丁寧にドキュメントを書いても、3つの問題が残ります。

1. 検索の失敗：「Anmod Proの収益性」と質問したとき、RAGが「ドキュメント1」を取ってくる保証はありません。意味的には関連していても、キーワードが違うからです。

2. 文脈を組み合わせられない：Anmod Proの貢献利益を求めるには、ドキュメント1（純売上の計算）＋第4回の広告費配分ロジック＋第2回の商品マッピングが同時に必要です。RAGは通常Top-Kのドキュメントしか取ってこないため、この3つがすべてTop-Kに入る確率は低くなります。

3. リアルタイムデータにアクセスできない：ドキュメントには「純売上 = こうである」という定義しかなく、実際の数字はありません。「今月のAnmod Proの純売上」に答えるには、DBを照会する必要があります。

必要なもの：定義＋データ＋実行

MCPがすること

MCPは、AIが外部ツールを呼び出せるようにするプロトコルです。私たちは4つのMCPサーバーを運用しています。

ポイントは、AIが質問を受けると自らDBを照会することです。CSVをアップロードするのではなく、質問に合ったクエリを生成して実行します。

オントロジーがMCPを賢くするプロセス

例：「Coupangの売上を教えて」

オントロジーなしでMCPだけがある場合：

AIはTrinoにクエリを投げますが、どのテーブルを照会すべきかわかりません。

-- AIが生成するクエリ（不確実）
SELECT SUM(payment_amount) FROM orders WHERE channel = 'coupang'
-- Wingだけ？ RGも含む？ サプライヤーハブは？ EZAdmin基準？

答えは5通りあり得て、しかも毎回変わります。

オントロジー＋MCPの場合：

オントロジーに「Coupangの売上」の定義があります。

概念：Coupangの売上
  基準ソース：[COUPANG_ADMIN_WING, COUPANG_ADMIN_RG, COUPANG_SUPPLIER_HUB]
  集計方法：3種類を合算、重複を除外
  指標：決済金額（発生した返金／キャンセルを除く）
  注意：EZAdminのデータと重複する可能性あり、チャネルAPI基準を使用

AIはこの定義を参照し、正確なクエリを生成します。

SELECT SUM(payment_amount)
FROM (
  SELECT payment_amount FROM coupang_wing_orders WHERE ...
  UNION ALL
  SELECT payment_amount FROM coupang_rg_orders WHERE ...
  UNION ALL
  SELECT payment_amount FROM coupang_supplier_orders WHERE ...
)

例：「Laplace Proの貢献利益が下がった理由を分析して」

この質問ひとつに、シリーズ全体の内容が総動員されます。

1. 商品マッピング（第2回）：「Laplace Pro」に紐づくチャネル別オプション名71件を照会

2. 指標の選択（第2回）：貢献利益 = 決済金額 - 原価 - 広告費 - 手数料 - 配送料 - 販売者負担配送料

3. 広告費の確認（第4回）：4段階のマッチングで配分された広告費をソースBから照会

4. チャネル別比較（第3回）：Cafe24・Coupang・SmartStore別の貢献利益の推移

5. 原因の推論：広告費の増加？ 原価の上昇？ 返金率の増加？ 特定チャネルの問題？

オントロジーがこれらすべての関係を定義しているため、AIは一度の質問で5つのステップを自動で実行します。

「Claude用データ」ダッシュボードが存在する理由

実際、当社のお客様の中にはAIに渡すデータを専用のダッシュボードとして設定しているケースがあります。

ダッシュボード：Claude用データ
ソースA：基礎商品の注文（決済金額、原価、実マージン、配送料など10項目）
ソースB：広告（広告費）
分析単位：日付 × 販売チャネル × 基礎商品名
集計：日次、2026-01-01から

このダッシュボードは人が見るためのものではありません。AIが質問に答えるためのあらかじめ結合されたデータセットを提供するものです。

なぜこれが必要なのか？

• 経営管理ダッシュボードは純売上基準 → AIが「売上」と誤解するおそれがある

• 商品別成果は決済金額基準 → これもまた別の「売上」

• Claude用データは加工前の元データに最も近い形 → AIが必要に応じて自ら集計

CSタグの2階層化がAIの質問解釈を変える

CSデータでも、オントロジーの効果ははっきり表れます。

タグがフラットな場合：

タグ：「AS」「返品」「返金」「配送」
→ AI：「ASは50件です」（ここから何がわかる？）

タグが2階層のツリーの場合：

タグ1：AS/Laplace
タグ2：不良/コントローラー不良、不良/製造不良、不良/充電不良
→ AI：「Laplace AS 50件のうち、コントローラー不良が28件（56%）で最多です。
       前月比15件増加しており、品質問題を確認する必要があります。」

タグに階層構造（オントロジー）があれば、AIは集計 → 比較 → 原因の推論までを一度に行えます。

実践チェックリスト：AXチームのMCP導入ステップ

1. READ-ONLYから始める — AIにはデータの照会だけを許可し、変更はさせない。当社でもTrino MCPはSELECT/SHOW/DESCRIBEのみ許可しています

2. メタデータMCPを先に作る — テーブル一覧、カラムの意味、関係の定義をAIが照会できるようにする

3. 指標辞書を構築する — 「純売上」「決済金額」「貢献利益」の正確な計算式と文脈を構造化する

4. 基準ソースのポリシーをMCPに組み込む — 「Coupangの売上 = Wing＋RG＋サプライヤーハブの合算」をコードレベルで定義する

5. まず人が検証する — AIのクエリ結果をダッシュボードの数字と突き合わせる。不一致があればオントロジーを補強する

まとめ：オントロジー → MCP → AIの順番で

このシリーズで扱った流れを整理すると、次のようになります。

第1回：オントロジーはなぜ必要か（データ関係の定義）
  ↓
第2回：商品名の衝突＋指標の衝突（同じものの異なる名前）
第3回：OMSとチャネルAPIの乖離（同じ注文の異なる数字）
第4回：広告費配分の4段階（クリエイティブ→商品マッチング）
  ↓
第5回（本記事）：MCPでAIがオントロジーを実行

CSVを投げるのはAIに原材料を渡すこと、RAGを組み込むのはレシピ本を横に置くことです。オントロジー＋MCPはキッチンそのものを整えることです。材料がどこにあり、道具がどこにあり、この材料とあの材料がどう関係しているのかをAIが把握したうえで料理させるのです。

コマースのAXチームなら、AIを組み込む前にまずオントロジーを整えてください。それが一番の近道です。

コマースデータをAIに理解させる — シリーズ第5回（完結）