はじめに
2026年8月に更新されたドキュメントで、Unity Catalogセマンティクスの「ページ」がベータ版として公開されています。
ドキュメントを読むと「ページ」「ドメイン」「Genieオントロジー」「Genie One」「Genie Code」と新しい登場人物が一気に出てきて、正直なところ最初は複雑に感じました。ただ、思い切って一言でまとめると、この機能はこう言えます。
会社の用語集をUnity Catalogに置いておくと、Genieがそれを正解として使ってくれる。
実際に架空の社内KPIを1つでっち上げて、ページ登録の前後でGenie Oneの回答がどう変わるかを確かめてみました。途中でハマったポイントも含めて書いていきます。
ページとは
ページは、用語、頭字語、KPIなどのビジネスコンセプトに関する、ガバナンスの効いた信頼できる定義です。イメージとしては「Unity Catalog上のビジネス用語集」で、各ページには以下のフィールドがあります。
| フィールド | 説明 |
|---|---|
| ドメイン | ページが属するドメインまたはサブドメイン |
| 所有者 | ページを担当するユーザー (デフォルトでは作成者) |
| 同義語 | コンセプトの代替名 |
| 説明 | コンセプトの簡単な要約 |
| ページ本文 | リンク、画像、テーブル、@ タグ付けをサポートするリッチテキスト |
| 関連アセット | 親子ページ、依存メトリクス、関連テーブルなどのリスト |
| ソース | ページコンテンツのソースとなるアセットのリスト |
重要なのは、ページがUnity Catalogセマンティクスの一部であり、Genieオントロジーの「人間がモデル化したレイヤー」を形成する、という位置づけです。Genie Oneがページで定義された概念に関する質問に回答する際、自動的に推論されたコンテキストよりもページ内の定義が優先され、回答にはページが引用として表示されます。
従来、Genieスペースごとのインストラクションに書いていたようなビジネス定義を、Unity Catalogレベルで一元化し、人にもGenieにも参照可能な「信頼できるソース」にする機能、と捉えるのが分かりやすいと思います。
ドメイン・タグ・ページの関係
ここが最初に混乱するポイントです。私自身、手を動かした後もしばらく腑に落ちませんでした。
そもそもなぜドメインという仕組みが必要なのでしょうか。カタログ.スキーマという階層は、チーム単位やパイプライン単位といった物理的・技術的な整理軸です。一方「finance関係」のようなビジネス上のまとまりは、この階層と一致しません。財務に関係するテーブルは、営業のスキーマにも経理のスキーマにも散らばっています。物理階層を組み替えずに、この横断的なまとまりを後付けで定義する第二の整理軸、それがドメインです。そして、横断的なまとまりには共通の語彙 (用語やKPIの定義) があるはずで、その語彙を置く場所がページです。用語はスキーマではなくビジネス領域に属するので、ページの置き場所もスキーマではなくドメインになります。
その上で、整理の鍵はドメインへの「所属のさせ方」が2種類あることです。
まず、テーブルなどのアセットは カタログ.スキーマ.テーブル という住所をすでに持っていて、ドメインの中に引っ越しさせることはできません。横断的なまとまりである以上、階層 (フォルダ) では表現できず、「このテーブルは財務ドメインの一員である」という所属は、アセット側に名札を付けることでしか表現できません。Unity Catalogには名札の仕組みとしてガバナンスタグが既にあるので、ドメインはこれを流用しています。新しい所属機構を発明する代わりに、既存のタグ機構に「ディスカバー上のホーム画面」「ページの置き場所」「権限の境界」という役割を上乗せしたのがドメインで、だからドメインの実体はタグポリシーです。ドメイン作成時にタグの選択を求められるのはこのためです。
一方、ページはこの機能のために新しく生まれるオブジェクトです。既存の住所を持たないので、最初から住所そのものを「ドメインの中」にできます。タグは付きません。権限もドメインから継承され、ページ個別の権限付与はできません。
| 対象 | ドメインへの所属方法 |
|---|---|
| アセット (テーブル、ダッシュボード等) | ドメインのタグを付ける (参照による所属) |
| ページ | ドメインの中に直接作成 (包含による所属) |
図にすると次のようになります。
ここまでを踏まえると、ドメインは「アセットを保有する箱」ではありません。ページに対しては本当の箱 (包含) ですが、アセットに対しては「タグが付いたアセットを映すレンズ」です。実際、ドメインのホーム画面をよく見ると domain:finance_domain というフィルター付きのディスカバー検索画面そのものであり、アセット一覧の実体はタグを条件にした検索結果です。テーブルは元のカタログ階層の住所に住んだままなので、ドメインを消してもアセットは消えませんし、タグを複数付ければ1つのアセットが複数ドメインから見える、ということも起こりうるはずです (こちらは未検証です)。
まとめると、ドメインとは「タグで集めたデータのビューと、それを読み解くための用語集をセットにした単位」です。Genieは、ビューに集まったデータについて質問されたとき、同じドメインの用語集 (ページ) を読んで答える。データと語彙が同じ単位でガバナンスされる、というのがこの機能群の設計だと理解しました。
「アセットの所属 = タグ付け」は目で確かめられます。検証の途中でテーブルを「ドメインに追加」した後、カタログエクスプローラーでそのテーブルを開くと、タグ欄にガバナンスタグを示す鍵アイコン付きで finance_domain が現れました。
ドメイン所属という特別な属性が生まれるわけではなく、どこまでも普通のタグです。ということは、タグの既存機能もそのまま使えるはずです。実際に information_schema にクエリしてみると、ドメインに追加したテーブルがそのまま返ってきました。
SELECT * FROM system.information_schema.table_tags WHERE tag_name = 'finance_domain'
tag_name = finance_domain の行として、ドメインに追加したテーブルが取得できます。ドメイン所属テーブルの棚卸しがSQLでできるということです。逆方向、つまりSQLの SET TAGS で一括タグ付けしてドメインに大量投入する方向も動きそうですが、こちらは未検証です。なお、今回はタグが finance_domain : finance とキー : 値の形式で付いていました。流用した既存タグポリシー側に許可値が定義されていたためと見られ、ドメインのタグにも値が付くことがある点は覚えておくと良さそうです。
「ドメインの実体はタグである」という点は、後述するハマりどころにも直結します。
ページ登録前のGenie Oneの挙動
検証用に、実在しない架空の社内KPI「実効稼働粗利率 (EOGM: Effective Operating Gross Margin)」を用意しました。計算式は次の通りです。
EOGM = (売上高 − 変動費 − 稼働調整額) ÷ 売上高
実在する一般用語だとGenieが常識で正解してしまうので、ビフォーアフターを確実に対比させるための造語です。
ページを作る前に、Genie Oneに「EOGMを計算して」と聞いてみます。
「EOGMの定義やそれに対応するデータがこのワークスペース内で見つかりませんでした」と正直に回答し、どのテーブルを使うか、計算式を知っているか、どの業界の文脈か、をユーザーに逆質問してきました。Genie自身が「EOGMはいくつかの意味で使われることがある略語です」と、一般知識では確定できないことを認めています。
ページがない状態では、独自用語の解釈はユーザー任せになる。この状態を覚えておいてください。
ドメインを作成する
すべてのページはドメインに紐付くため、先にドメインを作成します。ディスカバーからドメインの作成ダイアログを開きます。
必須入力は実質的に名前だけです。副題・説明・技術担当者・ビジネス用連絡先は空欄でも作成できますが、説明はGenieオントロジーのコンテキストにもなりうるので、埋めておくに越したことはありません。技術担当者や連絡先は「この用語について誰に聞けばいいか」を示すガバナンス上のフィールドです。
タグポリシーの上限に注意
ここが最初のハマりどころです。「新しいタグ」を選んで作成ボタンを押したところ、次のエラーになりました。
Failed to request /ajax-api/2.1/tag-policies: 400 The maximum number of tag policies allowed is reached for the account.
ドメイン作成 = タグポリシーの新規作成なので、アカウント全体のタグポリシー数が上限に達していると作成できません。ワークスペースではなくアカウントレベルの制限なので、共有環境では他のユーザーが作ったタグポリシーも合算されます。
回避策として、ソースを「既存のタグ」に切り替え、既存のガバナンスタグ finance_domain をドメインに昇格させました。これなら新規タグポリシーを作らないため、上限に引っかかりません。
作成すると、ドメインのホーム画面が開きます。
この画面から分かることが2つあります。
- ドメイン自体にも「下書き / 公開」の状態がある。作成直後は下書きなので、公開しておきます
- ドメイン名はタグ名がそのまま表示名になる。日本語の表示名を付けたい場合は、日本語名の新規タグが必要です
「このドメインにはアセットがありません」と表示されていますが、これは「まだどのアセットにも finance_domain タグが付いていない」という意味です。ドメインへのアセット追加はタグ付けと同義、というのが先ほどの整理の通りです。
ページを作成する
ドメインの「作成」メニューから「Create page」を選ぶと、ページエディターが開きます。ドメインは自動入力されます。
ページは手動で作成するほか、ソース資料からGenie Codeで生成することもできます。既存の用語集ドキュメントがある場合は、Genie Codeペインの「ページの一括インポート」でドキュメントから用語を抽出し、提案されたページセットをレビューして一括で下書き作成する、というフローも用意されています。今回は手動で作成しました。
入力した内容は次の通りです。
- ページ名: 実効稼働粗利率
- 同義語: EOGM、Effective Operating Gross Margin、実効粗利
- 説明: 稼働調整を加味した実効的な粗利率を示す当社独自KPI
- 本文: 定義 (計算式を含む)、ビジネス利用、利用上の注意の3セクション
ページ名は概念の正式名称、略称や英語名は同義語に置く、という整理にしました。利用上の注意には「稼働調整額は月次で経理部門が確定させるため、当月分は速報値である」という一文を入れています。これは後でGenieが細部まで引用するかを確かめるための仕込みです。
関連アセットとソースは必須ではありません。今回は定義の引用を確かめるのが目的なので、テーブルの紐付けなしで進めます。
「公開」を押すと、ページが公開されます。
公開後のページには、エディターでは見えなかった要素が現れます。右上に賛成・反対のリアクション、下部にディスカッション (コメント) 欄。コンシューマーは他人のページにもコメントや編集の提案ができ、所有者が承認・拒否する、というWiki的な運用モデルです。
Genie Oneに聞いてみる
ページを公開した状態で、Genie Oneに「EOGMとは？」と聞いてみます。
今度は逆質問なしで、定義・計算式・ビジネス利用・利用上の注意まで即答しました。ビフォーの「定義が見つかりません」との差は歴然です。
注目したいポイントが3つあります。
文単位のインライン引用
回答の各文の末尾にページアイコンが付いています。回答全体に対する参考文献ではなく、文ごとにソースが紐付く形式です。アイコンにカーソルを乗せると、ページのプレビューカードが表示されます。
カードにはドメイン、所有者、同義語、説明が表示され、「View full page」からページ本体に飛べます。回答から定義の出所まで1クリックで遡れる、という体験です。回答の下部には「Genieオントロジー (1)」というチップも表示され、この回答が参照したページの一覧を確認できます。
ページの構成がそのまま回答の構成になる
回答の見出し構成が「計算式」「ビジネス利用」「利用上の注意」と、こちらがページ本文に書いたセクション構成をほぼそのまま踏襲しています。ページは人間向けのドキュメントであると同時に、Genieの回答テンプレートとしても機能する。ページを書く際は「Genieにこう答えてほしい」という構成で書くのが良さそうです。
注意書きも引用される
「EOGMの当月値は確定値？」と聞くと、「いいえ、当月分のEOGMは速報値です」と、仕込んでおいた利用上の注意を引用して即答しました。
さらに「確定値は経理部門の締め処理後に反映されます」という、ページには書いていない補足を推論で足しています。定義部分はページを優先し、周辺は推論で補完する、という挙動です。
同義語の解釈は字義通りとは限らない
同義語経由のヒットも確認するため、「実効粗利って何？」と聞いてみました。結果は興味深いものでした。
同義語経由でページには到達したのですが、Genieは「実効粗利はEOGMの同義語 (別名) です」と説明した上で、計算式を独自に分解して再構成しました。
実効粗利 = 売上高 − 変動費 − 稼働調整額
EOGM = 実効粗利 ÷ 売上高
人間側は「実効粗利」を比率 (EOGM) の同義語として登録したのに、Genieは言葉の座りから「実効粗利 = 金額 (分子)」と解釈し直したわけです。今回は合理的な解釈ですが、同義語に登録した語をGenieが厳密な同義語として扱うとは限らないことが分かります。曖昧さのある略称は、同義語への登録だけで済ませず、ページ本文で明示的に定義した方が安全です。
利用上の注意点
検証を通じて把握しておくべきと感じた点をまとめます。
- 機密情報をページに書かない。ドキュメントに明記されている通り、ページデータは顧客管理キー (CMK) による暗号化をサポートせず、グローバルに複製される可能性のあるプレーンテキストとして保存されます。PII、規制対象データなどはページ名、説明、同義語、本文のいずれにも含めないでください
- タグポリシーのアカウント上限。ドメインの実体はタグポリシーなので、新規作成時に上限エラーになることがあります。既存タグの流用で回避できます
- ドラフトページはページ所有者にしか見えない。公開されたページはすべてのGenie One会話で使えますが、ドラフトは所有者との会話でのみ利用可能です。「他の人のGenieに反映されない」となったら公開状態を確認してください
まとめ
Unity Catalogセマンティクスのページを試して分かったことをまとめます。
- ページは「用語のガバナンス付き定義」で、Genieオントロジーの人間がモデル化したレイヤーを形成する
- ドメインの実体はタグポリシー。新規作成はアカウントのタグポリシー上限に引っかかることがあり、既存タグの流用で回避できる
-
テーブルを「ドメインに追加」すると、カタログエクスプローラーのタグ欄にドメイン名のガバナンスタグが現れる。アセットのドメイン所属はどこまでも普通のタグ付けで、
system.information_schema.table_tagsからSQLで一覧取得できる - ページ登録前は独自用語に回答不能だったGenie Oneが、登録後は定義・計算式・注意書きまで文単位の引用付きで即答するようになる
- ページ本文のセクション構成が、そのままGenieの回答の構成になる。「Genieにこう答えてほしい」形で書くのが良い
- 関連アセットなし (テーブル紐付けなし) でも、定義の引用は機能する
- 同義語をGenieが厳密な同義語として扱うとは限らない。曖昧な略称はページ本文で明示的に定義する
一番の収穫は、ページの書き方がそのままGenieの回答品質に直結する、という体感でした。従来のGenieスペースごとのインストラクションはスペースに閉じていましたが、ページは全社共通のガバナンス対象として一元管理され、しかも引用として回答に現れるため「なぜGenieがそう答えたか」を誰でも確認できます。Genieが用語を誤解したらページを書く、というループを回す運用が、これからのGenie活用の定石になっていきそうです。
参考リンク
- ページ | Databricks on AWS
- Unity Catalog のセマンティクス
- ドメイン
- Genie One のチャット (Genieオントロジー)
- Databricksのプレビューを管理する