【Databricks】Genie Ontologyを整備してGenie Oneの回答精度がどう変わるか試してみた
データ事業本部のueharaです。
今回は、DatabricksのGenie Ontologyを整備することで、Genie Oneの回答がどのように変わるかを検証してみたいと思います。
はじめに
生成AIを用いて自然言語でデータ分析を行う際、「生成されたSQLの文法は正しいのに、社内の業務ルールに照らすと集計結果が間違っている」という事象がよく起こります。
例えば一口に「売上を教えて」と言っても、キャンセル注文や社内テスト注文を除外する必要があるか、割引や返品金額を差し引くかといった定義は企業ごとに異なります。
また、「ロイヤル顧客」や「品質アラート基準」のような社内で定められた言葉の定義やしきい値は、テーブルのカラム名やデータ型だけをAIに読ませても判断できません。
こうした課題を解決する仕組みが Genie Ontology です。
Genie Ontologyは、Unity Catalog上のデータアセットや業務知識を統合し、ビジネスユーザー向けの対話画面である「Genie One」や開発者向けアシスタントである「Genie Code」に共通の文脈を提供するレイヤーです。
Genie Ontologyは以下の2種類の知識で構成されます。
- Modeled knowledge：Metric Views（メトリクスビュー）、Domains（ドメイン）、Pages（用語定義ページ）、Certification（認定・非推奨タグ）、キュレーション済みGenie Agentsなど、人間が明示的に定義・管理する知識
- Learned knowledge：過去のSQLクエリ履歴やダッシュボードなど、ワークスペースの利用状況から自動的に抽出される知識
両者の定義が衝突した場合は、人間が明示的に定義した「Modeled knowledge」や認定（Certified）されたアセットが優先される仕様となっています。
検証シナリオとデータの準備
今回は架空のEC事業データ（ontology_poc.ec_analytics）を題材に、Genie Ontologyの整備前（Before）と整備後（After）で同じ3つの質問を投げ、回答がどう変化するかを確認します。
違いが分かりやすくなるよう、テストデータには以下の要素を含めています。
sales_summary_legacy：旧システムの売上サマリテーブル。revenueという分かりやすいカラム名を持つが、キャンセルやテスト注文が混在した誤った数値（2026年10月合計：1,500,000円）が入っている。fact_orders/fact_returns：現行の正規受注テーブルと返品テーブル。受注テーブルには出荷完了（COMPLETED）以外にキャンセル（CANCELLED）や未出荷（PENDING）、社内テスト注文（is_internal_test = true）が含まれており、総額（gross_amount）から割引（discount_amount）と返金額（refund_amount）を差し引いた金額（2026年10月合計：885,000円）を本来の「純売上」とする。dim_customers/dim_products：顧客マスタと商品マスタ。顧客C003（鈴木花子）は累計純売上が335,000円と大きいものの、返品率が30.0%と高いデータにしている。
上記のデータ作成のため、まずはSQLエディタ（Serverless SQL Warehouse）で以下のSQLを実行し、カタログと各テーブルを作成します。
※この時点では、あえてテーブルコメントや主キー・外部キー制約、認定タグなどは付与していません。
テストデータ準備用SQL
-- 1. 検証用カタログとスキーマの作成
CREATE CATALOG IF NOT EXISTS ontology_poc;
CREATE SCHEMA IF NOT EXISTS ontology_poc.ec_analytics;
USE CATALOG ontology_poc;
USE SCHEMA ec_analytics;
-- 2. 旧システムの売上サマリ（キャンセルやテスト注文込みの誤データ）
CREATE OR REPLACE TABLE sales_summary_legacy (
sale_month DATE,
category STRING,
revenue DECIMAL(12, 0)
);
INSERT INTO sales_summary_legacy VALUES
(DATE '2026-09-01', 'Electronics', 900000),
(DATE '2026-09-01', 'Apparel', 500000),
(DATE '2026-10-01', 'Electronics', 950000),
(DATE '2026-10-01', 'Apparel', 550000);
-- 3. 顧客マスタ
CREATE OR REPLACE TABLE dim_customers (
customer_id STRING NOT NULL,
customer_name STRING,
segment STRING,
region STRING,
joined_date DATE
);
INSERT INTO dim_customers VALUES
('C001', '山田商事株式会社', 'Enterprise', 'Kanto', DATE '2025-04-01'),
('C002', '関西テック株式会社', 'SMB', 'Kansai', DATE '2025-06-15'),
('C003', '鈴木花子', 'Consumer', 'Kanto', DATE '2025-09-10'),
('C004', '西日本ホーム株式会社', 'Enterprise', 'Kansai', DATE '2026-01-20'),
('C005', '佐藤健太', 'Consumer', 'Kansai', DATE '2026-08-05'),
('C999', 'QA検証用アカウント', 'Internal', 'Kanto', DATE '2025-01-01');
-- 4. 商品マスタ
CREATE OR REPLACE TABLE dim_products (
product_id STRING NOT NULL,
product_name STRING,
category STRING,
unit_price DECIMAL(12, 0)
);
INSERT INTO dim_products VALUES
('P01', '4Kモニター Pro', 'Electronics', 50000),
('P02', 'ワイヤレスイヤホン X', 'Electronics', 40000),
('P03', 'メリノウールニット', 'Apparel', 10000),
('P04', 'スマート空気清浄機', 'Home', 15000);
-- 5. 現行の正規受注ファクトテーブル（キャンセル、未出荷、社内テスト注文が混在）
CREATE OR REPLACE TABLE fact_orders (
order_id STRING NOT NULL,
customer_id STRING,
product_id STRING,
order_date DATE,
order_status STRING,
is_internal_test BOOLEAN,
quantity INT,
gross_amount DECIMAL(12, 0),
discount_amount DECIMAL(12, 0)
);
INSERT INTO fact_orders VALUES
-- 2026年9月分（正常完了）
('O-0901', 'C001', 'P01', DATE '2026-09-10', 'COMPLETED', false, 8, 400000, 40000),
('O-0902', 'C002', 'P02', DATE '2026-09-15', 'COMPLETED', false, 10, 400000, 20000),
('O-0903', 'C003', 'P03', DATE '2026-09-20', 'COMPLETED', false, 30, 300000, 0),
('O-0904', 'C004', 'P04', DATE '2026-09-25', 'COMPLETED', false, 5, 75000, 5000),
-- 2026年10月分（正常完了）
('O-1001', 'C001', 'P01', DATE '2026-10-05', 'COMPLETED', false, 10, 500000, 50000),
('O-1002', 'C002', 'P02', DATE '2026-10-10', 'COMPLETED', false, 5, 200000, 0),
('O-1003', 'C003', 'P03', DATE '2026-10-12', 'COMPLETED', false, 20, 200000, 20000),
('O-1004', 'C004', 'P04', DATE '2026-10-18', 'COMPLETED', false, 10, 150000, 10000),
-- 2026年10月分（除外対象のレコード：キャンセル、社内テスト、未出荷）
('O-1005', 'C002', 'P01', DATE '2026-10-20', 'CANCELLED', false, 6, 300000, 0),
('O-1006', 'C999', 'P01', DATE '2026-10-22', 'COMPLETED', true, 10, 500000, 0),
('O-1007', 'C005', 'P03', DATE '2026-10-28', 'PENDING', false, 10, 100000, 0);
-- 6. 現行の正規返品ファクトテーブル
CREATE OR REPLACE TABLE fact_returns (
return_id STRING NOT NULL,
order_id STRING NOT NULL,
return_date DATE,
returned_qty INT,
refund_amount DECIMAL(12, 0),
return_reason STRING
);
INSERT INTO fact_returns VALUES
('R-0901', 'O-0903', DATE '2026-09-27', 10, 100000, 'SIZE_MISMATCH'),
('R-1001', 'O-1002', DATE '2026-10-16', 1, 40000, 'DEFECTIVE'),
('R-1002', 'O-1003', DATE '2026-10-19', 5, 45000, 'SIZE_MISMATCH');
実行が完了したら、カタログ上で ontology_poc カタログと ec_analytics スキーマが作成できていることを確認します。
整備前（Before）の挙動確認
まずはGenie Ontologyを整備していない状態で、Genie Oneがどのような回答を返すかを確認します。
画面右上のアプリスイッチャーから『Genie One』を開きます。
Genie Oneのホーム画面が表示されたら、中央の入力欄から3つの質問を順番に投げてみます。
質問1：2026年10月の売上合計とカテゴリ別内訳
1つ目は、月次売上とカテゴリ別内訳を聞く質問です。
ec_analytics スキーマのデータを使って、2026年10月の売上合計とカテゴリ別内訳を教えて
売上合計は ¥1,950,000 という結果が返ってきました。
これは fact_orders.gross_amount をそのまま単純合計した値であり、キャンセル注文（30万円）や社内テスト注文（50万円）、さらに割引額や返品による返金額の控除が一切反映されていません（本来の純売上は ¥885,000）。
質問2：ロイヤル顧客（VIP顧客）の一覧と売上・返品率
2つ目は、社内で定義している「ロイヤル顧客」の抽出です。
今回は後ほど、「累計純売上が30万円以上、かつ累計商品返品率が10%未満」という社内基準を設定する想定としています（正解は C001 山田商事 と C002 関西テック の2社）。
当社のロイヤル顧客（VIP顧客）に該当する顧客一覧と、それぞれの売上・返品率を出して
一見すると2社が抽出されており正しそうに見えますが、中身を見ると dim_customers.segment = 'Enterprise' の顧客がそのままロイヤル顧客であると推測されてしまっています。
その結果、SMBセグメントながら純売上が54万円ある C002 関西テック が漏れ、逆に売上が基準未満の C004 西日本ホーム が抽出されました。
集計されている売上金額も、割引控除前のグロス金額（90万円、22.5万円）になっています。
質問3：返品率アラートが出ている要改善カテゴリ
3つ目は、社内の品質アラート基準に照らした要改善カテゴリの特定です。
今回は後ほど、「電化製品・生活家電は商品返品率5%以上、衣料品は試着によるサイズ交換があるため30%以上でアラート」というカテゴリ別基準を設定する想定としています。
2026年10月時点で、社内基準に照らして返品率アラートが出ている要改善カテゴリはどれ？
社内の基準が登録されていないため、AIが独自に「一律10%」という基準を置いて Apparel を要改善カテゴリと判定しました。
加えて、返品率の計算も数量ベースではなく金額ベース（キャンセル・テスト注文込み）になっているため、Electronics の返品率が 2.67% と低く算出されています。
Genie Ontology（Modeled knowledge）の構築
ここから、Unity Catalogのセマンティクス機能を用いてGenie Ontologyを構築していきます。
1. 主キー・外部キー制約と認定ステータス（Certified / Deprecated）の設定
まず、テーブル間の結合関係を表す主キー・外部キー制約（RELY）とコメントを設定し、さらにシステム管理タグである system.certification_status を使って旧テーブルを deprecated（非推奨）、正規テーブル群を certified（認定）に設定します。
USE CATALOG ontology_poc;
USE SCHEMA ec_analytics;
-- 1. 主キー・外部キー制約の宣言
ALTER TABLE dim_customers ADD CONSTRAINT pk_dim_customers PRIMARY KEY (customer_id) RELY;
ALTER TABLE dim_products ADD CONSTRAINT pk_dim_products PRIMARY KEY (product_id) RELY;
ALTER TABLE fact_orders ADD CONSTRAINT pk_fact_orders PRIMARY KEY (order_id) RELY;
ALTER TABLE fact_returns ADD CONSTRAINT pk_fact_returns PRIMARY KEY (return_id) RELY;
ALTER TABLE fact_orders ADD CONSTRAINT fk_orders_customer
FOREIGN KEY (customer_id) REFERENCES dim_customers(customer_id) RELY;
ALTER TABLE fact_orders ADD CONSTRAINT fk_orders_product
FOREIGN KEY (product_id) REFERENCES dim_products(product_id) RELY;
ALTER TABLE fact_returns ADD CONSTRAINT fk_returns_order
FOREIGN KEY (order_id) REFERENCES fact_orders(order_id) RELY;
-- 2. テーブルコメントの付与
COMMENT ON TABLE sales_summary_legacy IS '【旧仕様・利用禁止】2026年以前の旧システム集計テーブル。キャンセル・テスト注文・返品前金額が混在しているため参照不可。';
COMMENT ON TABLE fact_orders IS 'EC事業の正規受注明細テーブル。公式売上の算出時は COMPLETED かつ is_internal_test = false に絞り、割引と fact_returns の返金額を控除すること。';
COMMENT ON TABLE fact_returns IS 'EC事業の正規返品テーブル。order_id で fact_orders と結合する。';
-- 3. Certification / Deprecation タグの付与
SET TAG ON TABLE ontology_poc.ec_analytics.sales_summary_legacy `system.certification_status` = `deprecated`;
SET TAG ON TABLE ontology_poc.ec_analytics.fact_orders `system.certification_status` = `certified`;
SET TAG ON TABLE ontology_poc.ec_analytics.fact_returns `system.certification_status` = `certified`;
SET TAG ON TABLE ontology_poc.ec_analytics.dim_customers `system.certification_status` = `certified`;
SET TAG ON TABLE ontology_poc.ec_analytics.dim_products `system.certification_status` = `certified`;
Catalog Explorerで sales_summary_legacy を開くと、説明文とあわせて右側のTags欄に Deprecated が付与されていることを確認できます。
2. Metric Viewの作成
次に、売上や商品返品率の計算式を一元管理するため、Metric View（mv_ec_kpis）を作成します。
通常のSQLビューでは GROUP BY の粒度（月別やカテゴリ別など）が固定されてしまいますが、Metric Viewでは集計軸（fields）と集計指標（measures）を分離してYAMLで定義するため、1つのビューで任意の切り口の集計に対応できます。
また、YAML仕様バージョン 1.1 では display_name や synonyms（類義語）を設定できるため、「売上」「実質売上」といった表記ゆれも吸収できます。
CREATE OR REPLACE VIEW ontology_poc.ec_analytics.mv_ec_kpis
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
comment: 'EC事業の公式KPIメトリクスビュー。売上（純売上）・販売数量・返品数量・商品返品率を管理する公式ソース。'
source: ontology_poc.ec_analytics.fact_orders
filter: source.order_status = 'COMPLETED' AND source.is_internal_test = false
joins:
- name: customer
source: ontology_poc.ec_analytics.dim_customers
on: source.customer_id = customer.customer_id
rely:
at_most_one_match: true
- name: product
source: ontology_poc.ec_analytics.dim_products
on: source.product_id = product.product_id
rely:
at_most_one_match: true
- name: returns
source: ontology_poc.ec_analytics.fact_returns
on: source.order_id = returns.order_id
rely:
at_most_one_match: true
fields:
- name: order_month
expr: DATE_TRUNC('MONTH', source.order_date)
display_name: '売上月'
comment: '注文日の月単位丸め'
synonyms: ['月', '対象月', '販売月', 'month']
- name: order_date
expr: source.order_date
display_name: '注文日'
- name: customer_id
expr: source.customer_id
display_name: '顧客ID'
- name: customer_name
expr: customer.customer_name
display_name: '顧客名'
synonyms: ['顧客', '取引先', '会員名']
- name: customer_segment
expr: customer.segment
display_name: '顧客セグメント'
synonyms: ['セグメント', '顧客区分']
- name: region
expr: customer.region
display_name: '地域'
synonyms: ['エリア', 'リージョン']
- name: product_category
expr: product.category
display_name: '商品カテゴリ'
synonyms: ['カテゴリ', '部門', 'category']
- name: product_name
expr: product.product_name
display_name: '商品名'
measures:
- name: net_revenue
expr: SUM(source.gross_amount) - SUM(source.discount_amount) - COALESCE(SUM(returns.refund_amount), 0)
display_name: '純売上（公式売上）'
comment: '当社の公式な「売上」指標。出荷完了かつ社内テストを除き、総額から割引額と返金額を差し引いた実質売上（円）。単なる「売上」と聞かれた場合は必ずこの指標を使う。'
synonyms: ['売上', '売上高', '実質売上', '純売上高', 'Net Revenue', 'revenue']
- name: gross_sales
expr: SUM(source.gross_amount)
display_name: 'グロス売上（割引・返品控除前）'
comment: '割引や返品を差し引く前の注文総額（参考指標）'
synonyms: ['グロス売上', '総売上', 'Gross Sales']
- name: units_sold
expr: SUM(source.quantity)
display_name: '販売数量'
comment: '出荷完了した商品の合計販売個数'
synonyms: ['販売個数', '出荷数量']
- name: returned_units
expr: COALESCE(SUM(returns.returned_qty), 0)
display_name: '返品数量'
comment: '返品された商品の合計個数'
- name: return_rate
expr: COALESCE(SUM(returns.returned_qty), 0) / CAST(SUM(source.quantity) AS DOUBLE)
display_name: '商品返品率'
comment: '返品数量 ÷ 販売数量 で算出する公式の商品返品率（0.15 = 15%）'
synonyms: ['返品率', 'Return Rate']
- name: completed_order_count
expr: COUNT(source.order_id)
display_name: '有効注文件数'
comment: '出荷完了かつ社内テスト除外後の有効注文件数'
$$;
-- Metric ViewにもCertifiedタグを付与
SET TAG ON VIEW ontology_poc.ec_analytics.mv_ec_kpis `system.certification_status` = `certified`;
※返品が発生していない注文では returns.refund_amount が NULL になるため、引き算の式では COALESCE(SUM(returns.refund_amount), 0) として結果が NULL にならないようにしています。
作成された mv_ec_kpis をCatalog Explorerで確認すると、MeasuresやFields、共通フィルタ条件、そして Certified タグが反映されています。
念のため、SQLエディタから MEASURE() 関数を用いて2026年10月のカテゴリ別集計と、顧客別の累計集計を確認しておきます。
▼ 2026年10月のカテゴリ別集計（合計 885,000円）
▼ 顧客別の累計集計（C003 鈴木花子 は純売上が335,000円だが返品率が30%）
3. Domainの作成とアセットの紐付け
続いて、関連するデータアセットや後述のPagesを業務領域ごとに束ねる Domain を作成します。
左側のメニューから『Discover』を開き、画面右上の『Create』 → 『Create domain』を選択します。
ドメインは内部的にGoverned Tag（管理タグ）をベースに管理されており、タグキーそのものがドメイン名になります。
今回は New tag に ec_commerce を指定し、SubtitleとDescriptionを入力して『Create』をクリックします。
作成直後は Draft 状態でアセットが空になっているため、画面中央の『+ Add to domain』をクリックします。
『Catalog』タブから ontology_poc > ec_analytics に進み、非推奨の sales_summary_legacy を除く5つのアセット（dim_customers、dim_products、fact_orders、fact_returns、mv_ec_kpis）を選択して『Add to domain』をクリックします。
アセットが追加されたら、画面右上の『Publish』ボタンを押してドメインを公開状態にします。
4. Pagesによる社内用語・判定基準の定義
ドメインを公開すると、そのドメイン配下にビジネス用語や社内ルールを明文化する Pages を作成できるようになります。
Discover画面右上の『Create』 → 『Create page』を選択します。
1つ目のPageとして、『ロイヤル顧客』の判定基準を作成します。
Domainに ec_commerce、Synonymsに VIP顧客 などの類義語を設定し、本文には「累計の純売上が300,000円以上、かつ累計の商品返品率が10%未満」という複合条件やRelated assetsを設定して『Publish』します。
2つ目のPageとして、『返品率アラート基準』を作成します。
こちらには全カテゴリ一律ではなく、「Electronics・Home は商品返品率5%以上でアラート（初期不良ロット混入の疑いのため即時検品対象）」、「Apparel は商品返品率30%以上でアラート（試着に伴うサイズ交換が一定数発生するため30%未満は正常範囲）」というカテゴリ別のしきい値を記載して『Publish』します。
※作成したPageは公開（Publish）しないと他のユーザーのGenie One会話から参照されないためご注意下さい（公開後、各Pageのメニューから Certified も付与しています）。
公開が完了すると、ec_commerce ドメインの『Pages』セクションに2つの用語定義が表示されます。
5. Genie Agentの作成と認定
最後に、Genie Oneから呼び出される領域特化エージェントとして Genie Agent（旧Genie Space）を1つ作成します。
左側のメニューから『Genie Agents』を開き、右上の『+ New』をクリックします。
データソースの選択画面（『Connect your data』）が表示されるので、先ほど作成したMetric Viewである mv_ec_kpis のみを選択し、『Create manually』をクリックします。
※生テーブルや旧テーブルをまとめて接続するのではなく、KPI定義を固めた認定済みMetric Viewに絞って接続することで回答のブレを防ぎます。
エージェント画面が開いたら、『Configure』からタイトル（EC事業 公式KPIアナリスト）と説明文を設定し、『Instructions』タブに最小限の指示を記載します。
個別のしきい値（30万円や10%など）はエージェント側のプロンプトには書かず、「Genie OntologyのPages定義に従うこと」とだけ指定しています。
最後に、画面右上の三点リーダー（⋮）から『Assign certification』を選択します。
『Certified』を選択して『Save』をクリックします。
これでGenie Ontologyの構築は完了です。
整備後（After）の挙動確認
再びGenie Oneを開き、整備前（Before）と同じ内容の3つの質問を投げて結果を比較してみます。
質問1：2026年10月の売上合計とカテゴリ別内訳
2026年10月のEC事業の売上合計と、商品カテゴリ別の内訳を教えて
整備前は ¥1,950,000 と回答していたのに対し、整備後は ¥885,000（Electronics: ¥610,000、Home: ¥140,000、Apparel: ¥135,000）と期待通りの純売上が返ってきました。
回答の末尾でも、公式KPIメトリクスビュー（mv_ec_kpis）の純売上（net_revenue）を使用した旨が明記されています。
質問2：ロイヤル顧客（VIP顧客）の一覧と売上・返品率
続いてロイヤル顧客の抽出です。
今回は除外理由もきちんと把握しているか確認するため、他顧客が外れた理由もあわせて聞いてみます。
当社のロイヤル顧客（VIP顧客）に該当する顧客一覧と、それぞれの累計売上・返品率を出して。なぜ他の売上上位顧客が外れているかも説明して
まず思考プロセス（『Thought process』）を展開すると、最初に Searching Genie Ontology for "ロイヤル顧客 VIP顧客 定義 基準 条件" が実行され、その検索結果を踏まえて EC事業 公式KPIアナリスト エージェントへ問い合わせが行われていることが分かります。
出力されたグラフとテーブルを確認すると、整備前に漏れていた C002 関西テック株式会社（¥540,000）と C001 山田商事株式会社（¥810,000）の2社が正確に抽出されました。
さらに回答後半の解説を見ると、売上第3位の 鈴木花子（累計売上 ¥335,000）について「売上基準（30万円以上）は満たしていますが、返品率が30.0%で基準の10%未満を大きく上回っているため除外」、売上第4位の 西日本ホーム株式会社（¥210,000）について「売上基準の30万円に達していないため対象外」と正確に説明されています。
回答下部には Genie Ontology (1) として、参照元のPage『ロイヤル顧客』へのリンクも表示されました。
質問3：返品率アラートが出ている要改善カテゴリ
最後に、返品率アラート基準に基づく要改善カテゴリの判定です。
2026年10月時点で、社内基準に照らして返品率アラートが出ている要改善カテゴリはどれ？
こちらも興味深い結果になりました。
まず数値面とPage参照については、回答下部に Genie Ontology (1) > 返品率アラート基準 が引用されており、数量ベースの正しい返品率（Apparel: 25.0%、Electronics: 6.7%、Home: 0.0%）が算出されています。
そして整備前にはAIの仮置き基準（10%）で要改善と判定されていた Apparel（25.0%）が、今回は衣料品の基準（30%以上）に照らして「正常範囲」へと正しく判定が変わりました。
一方で注目すべきなのが Electronics（6.7% = 15個販売中1個返品）に対するAIの判断です。
AIは「アラート基準：5%以上」を認識して技術的には基準を超えていると述べつつも、Pageの括弧書きに記載していた 「（初期不良ロット混入の疑いのため即時検品対象）」 という背景説明まで読み取り、「販売数量15個に対して返品1個ではロット混入の疑いを示す水準ではなく統計的な有意性は低いため、要改善ではなく要注意にとどまる」と踏み込んだ解釈を行いました。
定性的な背景まで含めて柔軟に評価してくれる点は頼もしい反面、もし実運用において「母数が何件であっても5%を超えたら例外なくアラート対象として抽出したい」という厳格な運用を行う場合は、Pageの定義文に「販売数量や返品個数の多寡にかかわらず、しきい値以上の場合は機械的に要改善アラートと判定する」と明記しておくのが良さそうです。
最後に
今回は、DatabricksのGenie Ontologyを整備してGenie Oneの回答精度がどう変わるかを検証してみました。
整備前後の変化を整理すると以下の通りです。
| 検証項目 | 整備前（Before） | 整備後（After） |
|---|---|---|
| 10月の売上合計 | ¥1,950,000（キャンセルやテスト注文、返品未控除の総額） | ¥885,000（mv_ec_kpis の純売上を自動選択） |
| ロイヤル顧客の抽出 | Enterprise セグメントと推測し対象外の顧客を誤抽出 |
Page『ロイヤル顧客』を引用し、売上・返品率の2条件で2社を正確に抽出 |
| 返品率アラート判定 | 独自に10%基準を仮置きし Apparel を要改善と判定 |
Page『返品率アラート基準』のカテゴリ別基準を引用し、Apparel を正常と判定 |
Genie Agentごとのプロンプトに業務ルールを毎回書き込む運用と異なり、Unity Catalog側のMetric ViewsやPagesとして定義しておくことで、Genie OneだけでなくSQLエディタ上のGenie Codeなどからも同じ定義を再利用できる点が大きなメリットだと感じました。
参考になりましたら幸いです。
