2026年9月1日

データスタックにおけるGenie Ontologyの運用化

Genie Ontologyがデータから高品質な回答を返せるようにするための、データモデリング、メタデータ、セマンティクス、コンテキスト、ガバナンス、および評価の実践的なガイド。

Genie Ontologyは導入初日から機能しますが、最大限の精度を達成できるかどうかは、その土台となるデータ基盤にかかっています。本ガイドでは、データ上にその基盤を構築する方法を解説します。
6つのレイヤーを段階的な成熟度パスとして活用し、データ基盤の改善、メタデータの拡充、重要なビジネスセマンティクスのモデリング、信頼できるアセットのキュレーション、アクセス制御、そして評価と改善を進めてください。
一度にすべてを網羅しようとするのではなく、1つのドメインずつ段階的に展開しましょう。解決されたエンティティ、ドキュメント化されたテーブル、認定されたメトリクス、ガバナンスが適用されたデータセットの1つひとつが回答の精度を向上させ、評価プロセスによってビジネスの進化に合わせたシステムの正確性が維持されます。

セマンティックモデルを超えて：AIエージェント向けの共有ビジネスコンテキストの構築

大規模言語モデル（LLM）は推論の方法を理解していますが、皆様のビジネスについては理解していません。エンタープライズAIに必要なビジネスコンテキストを提供することは、単にデータに接続すること以上の意味を持ちます。エージェントは、定義、関係性、ビジネスルール、信頼できるソース、そして権限も理解する必要があります。Genie Ontologyは、モデル化されたビジネスセマンティクスと、チームがすでに使用しているガバナンス対象のテーブル、クエリ、ダッシュボード、ノートブック、その他のサポートされているアセットから学習したコンテキストを組み合わせることで、そのギャップを埋めます。Genieは、そのコンテキストを信頼性と関連性によってランク付けし、権限を適用して、回答時に最も有用なコンテキストをGenieに提供します。外部エージェントもMCPを通じてGenieのインテリジェンスにアクセスできます。

優れたセマンティックモデルは、信頼できるコアを提供します。セマンティックモデルは意図的に定義されたビジネス概念を捉え、オントロジーはその基盤を拡張して、ビジネスが実際にどのように機能しているかをAIが理解するために必要な、より幅広い関係性、知識、コンテキストを提供します。Databricksの表現では、Unity Catalog SemanticsがMetric Views、Pages、Domainsを組み合わせて、信頼できるビジネス定義を確立します。そしてGenie Ontologyは、既存のアセットから推論されたコンテキストを取り入れることで、そのモデル化されたコアを基盤として構築され、セマンティックモデル単体よりもはるかに幅広いビジネスの理解をエージェントに提供します。

重要なのは、「ヘッド（主要部分）」をモデル化し、Genie Ontologyに「テール（詳細部分）」を推論させることです。Genieは初日から自動的に学習できる内容に基づいて動作し、意図的なキュレーションによって、正確であるべき重要な定義やソースを改善します。

次の6つのレイヤーは、時間をかけて信頼性を高めるための段階的なプラクティスであり、Genieが価値を提供し始めるための前提条件ではありません。

理解を深めるために、各レイヤーを見ていきましょう。

レイヤー0：エージェントに適したデータ基盤を整える

何かを記述またはモデル化する前に、基盤となるデータがエージェントが推論できる形式になっている必要があります。このレイヤーは物理的な基盤に関するものです。クリーンなデータテーブル、適切なスキーマ、そして現実世界のエンティティごとに1つの整合性のあるアイデンティティを指します。論理的なビジネスモデリングは、後ほどレイヤー2で行います。このレイヤーは簡単に見落とされがちですが、後から修正するには多大なコストがかかります。なぜなら、物理的な基盤が壊れていれば、どれほど優れたメタデータやセマンティックモデルであっても補うことはできないからです。

データ基盤を正しく整えるには、主に次の2つの領域に焦点を当てます。

ビジネスプロセスを中心に、耐久性のあるゴールドレイヤーをモデル化する。これには、明確な粒度を持つファクトと、再利用可能で適合されたディメンションを特定することが含まれます。スタースキーマやハイブリッドモデルを使用すると、ビジネスロジックをすべての下流テーブルにコピーすることなく、ファクトとディメンションの信頼できる基盤を構築できます。ただし、エージェントが生のディメンションテーブルに対して推論を行うべきだという意味ではありません。エージェントが表示するインターフェースは、より限定されたものであるべきであり、多くの場合そうすべきです。たとえば、1つのドメインの共通ディメンションを事前に結合し、重要なフィールドのみを公開し、粒度を文書化し、メジャーを標準的に定義するMetric Viewや専用のビューなどがこれに該当します。これこそが、レイヤー2で構築するものです。重要なのは、データダンプにエージェントをそのまま放り込むのではなく、適切なモデルの上で消費サーフェスを意図的に形成することです。ワイドテーブル自体が問題なのではありません。粒度が混在し、ビジネス概念が重複し、標準的なメトリクス定義がないワイドテーブルは、推測を招く原因になります。
エンティティをゴールデンレコードに解決する。もし「顧客」が営業部門ではアクティブなアカウントを意味し、サポート部門ではこれまでに存在したすべてのアカウントを意味する場合、エージェントはどちらの定義を信頼すべきか判断できません。また、同じ顧客がシステム間で3つの異なるIDを持っている場合、重複してカウントされる可能性があります。ソース間で同じ現実世界のエンティティを調整し、1人の顧客が1人の顧客として正しく認識されるようにします。

レイヤー1：メタデータの充実

メタデータは、セマンティックレイヤーとコンテキスト抽出の両方がデータを理解するのを助ける記述的な基盤です。テーブル名が fct_rev_daily で、カラム名が rev_amt である場合、エージェントはその意味を推測しなければなりません。同じテーブルに「製品別の返金控除後の日次認識収益」という説明があり、カラムに「USDでの認識収益」というコメントがある場合、エージェントは確かな根拠に基づいて推論できます。優れた説明文を作成することは、最も投資対効果が高く、コストの低い投資の1つであり、Genieだけでなく、すべての下流ツールを改善します。

実行すべき3つの重要なステップは次のとおりです。

Unity Catalogでテーブルの説明とカラムのコメントを追加する。スキーマを知らない新しいアナリストに向けて執筆してください。データが何を表しているか、そのビジネス上の目的は何かを説明し、既知の注意事項を明記します。ダッシュボードやエージェントが実際にクエリを実行する、キュレーションされたビジネス対応のテーブルに労力を集中させると効果的です。
分類と整理のためにタグを適用する。説明文はナラティブな意味を提供し、タグは分類、検出、ガバナンスのための構造化されたシグナルを提供します。これらを使用して、機密性（PII、PHI、PCI）、所有権、ビジネス機能、およびデータ資産全体で一貫して理解する必要があるその他の属性を捉えます。ガバナンスされたタグを使用すると、管理者が承認済みのキーと値のセットを定義できるため、チームごとに分類がばらつくことなく一貫性を維持できます。これらのシグナルは、後でアクセス制御ポリシーやその他のガバナンスコントロールに組み込むこともできます。
量が多く手作業が現実的でない場合は、最初のパスを自動化する。Databricksのソリューションアクセラレータであるdbxmetagenは、大規模言語モデルを使用して説明を生成し、機密データを検出してタグ付けし、分類を提案します。人間が確認して承認するまではUnity Catalogに何も書き込まれないため、判断を置き換えるのではなく、作業を迅速化します。

レイヤー2：セマンティックレイヤーによるビジネスのモデル化

メタデータは個々のテーブルを説明します。セマンティックレイヤーはその上にビジネスロジックを定義するため、最も重要なメトリクスがどこで使用されても同じ意味を持つようになります。レイヤー0が物理的な基盤を確立したのに対し、このレイヤーは論理モデル（メジャー、関係性、ドメイン、用語）を作成します。

重要な4つのステップは次のとおりです。

関係性を宣言する。エージェントは質問に答えるためにテーブルを結合しますが、テーブルの接続方法を推測しなければならない場合、誤って推測することがあります。Unity Catalogで主キーと外部キーを宣言することで、エージェントにテーブル間の関係性を伝えることができるため、独自のパスを捏造することなく正しく結合できます。これらの制約は強制されるものではなく情報提供を目的としているため、ガバナンスプロセスによって正確性を維持する必要がありますが、これらを宣言することは結合エラーを減らす最も直接的な方法の1つです。関係性は、メトリクス自体と同様にモデルの重要な一部です。
Metric Viewsを使用してセマンティックモデルを構築する。Metric Viewは、メジャー（総収益などの集計値）とディメンション（地域や月などのスライス方法）を、ガバナンスされたコードとして一度だけ定義するUnity Catalogオブジェクトです。集計はあらかじめ固定されるのではなくクエリ実行時に解決されるため、Metric Viewをクエリする利用者は、同じガバナンスされた定義を使用することになります。これは、エージェントが誤った定義を選択する原因となる曖昧さを排除するため、正確性を確保する上で最も重要なステップの1つです。まず、重要なKPIをMetric Viewsとして定義します。これらは、収益、アクティブ顧客数、コアコンプライアンス指標など、絶対に誤りがあってはならない数値です。
メトリクスにエージェント向けのメタデータを追加する。Metric Viewsには表示名や類義語を設定できるため、「売上」のような自然言語を適切なメジャー、通貨や日付のフォーマットパターン、サンプルクエリにマッピングできます。このメタデータはGenie Ontologyに流れるため、メトリクスをモデル化するために行う作業によって、エージェントがそれを正しく見つけて使用することも容易になります。
整理とドキュメント化。Unity Catalogのドメインとサブドメインは、アセットをビジネスに沿ったコレクションにグループ化し、コンテキストのスコープを維持します。これにより、Genieはデータ資産全体を検索するのではなく、関連するビジネス領域内のアセットに探索を集中できるため、Genieの速度と精度が向上します。Unity Catalogのページは、ビジネスユーザーやエージェントが推論に使用する、共通のビジネス用語、概念、定義をキャプチャします。各ページには、その概念に関連付けられた信頼できるアセットがリストされているため、オントロジーが質問から用語を解決する際、データ資産全体を検索して推測するのではなく、どのテーブル、Metric Views、クエリを利用すべきかをすでに把握しています。オーナーによるレビューがこれらの定義の信頼性を維持します。これらは人間が定義しレビューしたものであるため、オントロジーが競合を解決する必要がある場合、推論されたコンテキストよりも高い権限を持ちます。

Genie Codeによるセマンティックモデリングの自動化

もちろん、セマンティックモデリングのプロセスは完全に手動で行う必要はありません。自然言語の指示を使用してMetric Viewsを作成および維持するために、Genie Codeを活用できます。Genie Codeのプロンプトで、ソーステーブル、結合、フィールド、メジャー、フィルターを説明すると、保存前にレビューできるYAMLが生成されます。また、Genie Codeの /importBI スキルを使用してTableauまたはPower BIのセマンティックモデルをインポートすることもできます。これによりMetric Viewが構築され、再利用、ガバナンス、リネージ、検出可能性のためにUnity Catalogに昇格させることができます。

Genie Codeはページのドラフトを作成することもできます。ページエディターでドメインを選択し、関連するファイル、リンク、Unity Catalogアセット、またはMCPに接続されたコンテンツを添付すると、Genie Codeが構造化フィールドとリッチテキストのページ本文をドラフトします。ドラフトをレビューし、適切なソースと関連アセットを追加して、保存または公開します。複数の概念については、ページのバルクインポートを使用します。Genie Codeは、ドキュメントやソースから提案されたページを抽出して重複を排除し、競合、重複、信頼性の低い用語をレビュー用にフラグ付けし、承認されたページをその後の編集と公開のためのドラフトとして作成します。

レイヤー3：コンテキストが豊富なアセットのキュレーション

オントロジーの推論部分は、ダッシュボード、ノートブック、SQLクエリ、Genie Agents、ドキュメントなど、チームがすでに作成しているアセットから学習します。データ資産が豊富で信頼性が高いほど、推論されたコンテキストはより有用になります。レイヤー3は、それらのアセットを学習する価値のあるものにすることについて説明します。

重要な4つのステップは次のとおりです。

十分に活用され、充実したアセットベースを構築する。十分にドキュメント化され、広く使用されているダッシュボード、クエリ、Genie Agentsが多数存在するワークスペースは、まばらなワークスペースよりも、オントロジーが学習するための材料を多く提供します。これらのアセットが使用され改善されるにつれて、コンテキスト抽出に利用できるシグナルがより豊富になります。
アセットのコンテキストを豊富にする。アセットが豊富であるほど、オントロジーはそこからより多くのことを学習できます。定義、例、指示を使用してGenie Agentを強化すると、エージェントのパフォーマンスが向上するだけでなく、データ資産全体で抽出およびランク付けするためのより強力なコンテキストをGenie Ontologyに提供できます。他のアセットについても同様に行います。ノートブックをMarkdownセルでドキュメント化し、保存されたSQLクエリにコメントを追加し、AI/BIダッシュボードに説明や注釈を追加します。これらを組み合わせることで、Genie Ontologyが利用する豊富なロングテールビジネス知識が提供されます。
信頼するアセットを認定する。認定は、Metric Views、Genie Agents、ノートブックなどのデータおよびAIアセットを検証済みかつ承認済みとしてマークし、どのソースが信頼できるかを判断するための強力なシグナルとして機能します。認定され、広く使用されているアセットは、検証されていないアセットよりも高い権限を持つため、信頼できるアセットを認定することは、競合が発生したときにどのコンテキストが優先されるかに直接影響します。古くなったアセットを非推奨にすることも、もう一方の重要な側面です。これにより、ユーザーとエージェントの両方が、サポートされなくなったコンテンツから遠ざけられます。
機密データを分類し、品質を監視する。データ分類は機密データを特定してタグ付けし、一貫したガバナンスを可能にします。また、データ品質の監視は、データに依存するユーザーやエージェントに影響が及ぶ前に、ドリフトや異常を検出します。どちらも、オントロジーに供給されるアセットの信頼性を確保するのに役立ちます。

レイヤー4：ガバナンスレイヤーの構築

ガバナンスは、Genieの回答を安全で信頼できるものにする要素です。権限によってGenie Ontologyが取得できるコンテキストが決まるため、2人のユーザーが同じ質問をしても、それぞれが表示を許可されている内容に基づいて異なる回答を受け取ることがあります。

3つの具体的な領域におけるガバナンスを見てみましょう。

Unity Catalogのアクセス制御から始める。Unity Catalogの権限モデルが基盤となります。これにより、カタログ、スキーマ、テーブル、その他のワークスペースアセットへのアクセスが制御され、Genie Ontologyはそれらの権限を尊重します。Genieは、質問した人が表示を許可されているコンテンツのみを使用するため、ユーザーによって同じ質問でも異なる回答が生成されることがあります。個人ではなくグループを通じてアクセスを管理することで、規模が拡大しても権限の維持が容易になります。
データが必要とする場所にきめ細かな制御を追加する。機密データの場合、行レベルのセキュリティによってユーザーが表示できる行が制限され、列マスクによって機密性の高い値が隠されます。どちらもクエリ実行時に適用されます。属性ベースのアクセス制御を使用すると、管理されたタグからこれらの保護を推進できるため、機密性タグに関連付けられたポリシーは、テーブルごとに定義するのではなく、そのタグが表示されるすべての場所に適用されます。これにより、大規模なデータ資産全体で、行レベルおよび列レベルの保護を一貫して適用するためのスケーラブルな方法が提供されます。
AIレイヤーを管理する。Unity AI Gatewayは、モデルへのアクセス、レート制限、ペイロードログ、AIワークロードのコスト制御を管理するための中心的な場所を管理者に提供するほか、モデルに送信される内容に対する安全性や機密データの制御も提供します。これは、利用の拡大に伴うエージェントの動作と支出を管理するためのコントロールポイントです。

これらの制御を組み合わせることで、オントロジーがどのコンテキストを取得でき、どのユーザーがそれを受け取ることができるかが決定されます。権限のないコンテンツは取得に参加しないため、回答に間接的に影響を与えることはありません。

レイヤー5：評価と改善

最初の5つのレイヤーは、Genieが質問に答えるために使用するビジネスコンテキストを構築します。評価と改善のレイヤーは、ビジネスの変化に合わせてそのコンテキストを正確に保ちます。メトリクスが再定義され、テーブルが古くなり、新製品が導入されます。回答の品質を定期的に測定することで、古くなったり誤ったりした回答がユーザーの信頼を損なう前に、オントロジーをいつ適応させる必要があるかを特定できます。

考慮すべき4つの主要な領域があります。

ロールアウト前にエクスペリエンスを検証する。まず、優先ドメインごとに代表的なビジネス質問のセットを用意します。各質問の期待される回答、信頼できるソース、受け入れ基準を定義します。次に、それらの質問をGenie Oneでテストし、ユーザーが依存するMetric Views、ページ、Genie Agents、ダッシュボード、クエリ、その他のソースが適切に機能することを確認します。Genie Agent Benchmarksは、個々のGenie Agentを長期にわたって評価するための組み込みの方法を提供します。チャットモードでは、ベンチマークは検証済みのSQL回答と結果を比較できます。エージェントモードでは、LLMジャッジとオプションの評価基準を使用して応答が評価されます。Genie One、ひいてはGenie Ontology全般について、チームは質問セット、グランドトゥルース（正解データ）、ソース検証、手動レビュープロセス、および受け入れしきい値を定義し、所有する必要があります。回答が失敗した場合は、根本的なソースまたはコンテキストに遡って原因を特定し、修正します。これには、Metric Viewで管理されたメトリクスロジックを定義すること、ページでビジネス定義を明確にすること、Unity Catalogのメタデータを改善すること、アセットを認定または非推奨にすること、あるいはドメイン固有のGenie Agentのキュレーションを洗練させることが含まれます。
回答、使用状況、ソースの品質を監視する。 Genie Ontologyが活用するアセットの監視機能を使用します。Genie Agent Monitorを使用すると、個々のAgentの質問、回答、フィードバック、フラグ付きの回答、使用状況の傾向を可視化できます。Genie Oneでは、ソースの引用により、ユーザーや管理者はどのOntologyソースが回答に寄与したかを確認できます。Query History、監査ログ、課金システムテーブルを使用すると、SQLの実行、イベント、使用状況をさらに詳細に可視化できます。
適切なレイヤーでフィードバックループを閉じる。 ユーザーのフィードバックやレビューリクエストをキャプチャし、回答に責任を持つアセットに問題をルーティングします。修正は、ビジネス上の意味が属する場所で行う必要があります。
- 問題がビジネス定義や類義語である場合は、Page。
- 問題がガバナンスされたメジャー、ディメンション、リレーションシップ、または計算である場合は、Metric View。
- 問題がソースアセットにある場合は、Unity Catalogのメタデータ、権限、認証、または非推奨設定。
- 問題がそのAgentのドメインに特有である場合は、Genie Agentの指示、サンプルのSQL、SQL式、信頼された回答、またはKnowledge Store。Genie Agentには、高評価/低評価、レビューリクエスト、生成されたSQLの検査、指示としての追加、ベンチマークとしての追加など、ユーザーのフィードバックをキャプチャして対応するためのいくつかの組み込み機能があります。
アセット全体のドリフトに注意する。 ドリフトは、ビジネス定義、KPIロジック、テーブルメタデータ、結合、ダッシュボード、ノートブック、パイプライン、Genie Agentの指示、ソースの使用パターンなど、多くの場所で発生する可能性があります。重要な各ドメインのアセットに対して、所有者とレビューの頻度を設定します。ドリフトに対処する際は、すでに構築したモデルを活用します。信頼できる概念にはPages、ガバナンスされたメジャーとディメンションにはMetric Views、組織化とスチュワードシップにはDomainsを使用し、推奨されるものや古くなったものを示すには認証や非推奨設定を使用します。ソーステーブル、ビュー、ダッシュボード、ノートブック、クエリはすべて推論されたコンテキストに反映されるため、最新の状態に保ちます。また、権限を使用して、実験的または廃止されたコンテンツを、それらを表示すべきでないユーザーやエージェントから遠ざけます。Genie Agentについては、データ、指示、例、または信頼されたアセットに大幅な変更を加えた後、ベンチマークスイートを再実行します。

評価は、ローンチ前の1回限りの関門ではありません。回答を提供するすべてのアセットにわたって継続的に行う習慣です。Databricksは、ガバナンスされたセマンティックアセット、オントロジーの検索と引用、Agentレベルの評価と監視、システムテーブルのテレメトリを提供します。お客様は、グラウンドトゥルース（正解データ）、所有権、レビュープロセス、そしてGenieの信頼性を維持するための定期的なメンテナンスを担います。

1つのドメインから始めて、徐々に拡大する

重要なポイントは、6つのレイヤーすべてを一度に構築する必要はないということです。本番稼働前にビジネス全体をカバーしようとするべきではありません。現実的なアプローチは、まずGenieを使い始め、価値の高いドメインを1つ選択し、最も重要な定義、ソース、ガバナンス、評価を意図的に強化することです。これは、最初からすべてを完璧にしようとする（海水を沸騰させようとする）のではなく、「学びながら拡大する」アプローチです。

最初のドメインは慎重に選択してください。予測ミーティングや計画サイクルなど、チームがすでに手作業で数値を照合するのに時間を費やしている、繰り返し発生する摩擦の多いワークフローから始めます。これらは、信頼できる回答が最も価値を持ち、何が「正しい」かをすでに把握している場所です。実際には、狭い範囲から始めます。Salesなどの1つのドメインとARRなどの1つのメトリックを選択し、基盤を固めます。重要なメトリックを認証し、重要な用語を定義し、信頼できるアセットを特定し、アクセスを管理し、重要な質問を評価します。その結果を次のドメインの指針とします。

最後のポイントは、思った以上に重要です。これらの実践の目標は、技術的な完全性そのものではありません。信頼、つまりビジネスユーザーが回答を十分に信じて行動を起こせるかどうかです。各レイヤーがその信頼を少しずつ獲得し、評価ループによって、その信頼が単なる主観ではなく、可視化され、実証可能なものになります。

進めるにつれて、2つの相乗効果が生まれます。解決されたすべてのエンティティ、文書化されたアセット、認証されたメトリック、用語集のページの定義、ガバナンスされたデータセットが、信頼できるコアを強化します。そして、すべてのインタラクションからフィードバックが得られ、チームはそれを使用して改善を行うことができます。その結果、時間の経過とともに劣化するのではなく、使えば使うほど向上する、共有されたビジネス理解が構築されます。

Genie Ontologyの運用は、大規模なモデリングプロジェクトではありません。データモデル、メタデータ、ビジネスセマンティクス、エンタープライズコンテキスト、ガバナンス、評価への着実で段階的な投資であり、1つのドメインずつ提供することで、AIにビジネスの真の理解をもたらします。

詳細情報

詳細については、Genie Ontologyの発表ブログをお読みいただき、Genie OneおよびGenie Agentsのウェブページをご覧ください。また、Metric Viewsの詳細については、Unity Catalog Semanticsのウェブページもご覧ください。AIがビジネスの共有された信頼できる理解を活用できるようになると、何が可能になるのか、私たちはまだその端緒を目にしているにすぎません。お客様がGenie Ontologyを使用して、より迅速な意思決定を行い、より大きな自信を持って行動し、新しい働き方を創造されるのを楽しみにしています。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事