Microsoft Purviewのカスタム/組み込みエンティティでRelatedタブに表示されない問題の原因と対処法【UI仕様とワークアラウンド】

Microsoft Purview で「カスタム → 組み込み」エンティティ間の関係を作ると、Related タブに片側しか表示されない――この挙動に戸惑う方は少なくありません。本記事では、Subscription → Kusto_Custom_Entity → azure_data_explorer_cluster の二段関係を題材に、なぜ「組み込み」側で逆方向が見えないのか、どう確認し、どう運用で補うかを、UI 仕様・API・設計パターン・ワークアラウンドの観点から深掘りします。

カスタムエンティティと組み込みエンティティの Related タブ表示問題の全貌

現象の要約

次の二段階リレーションシップを作成した前提を共有します。

カスタムエンティティ Subscription → カスタムエンティティ Kusto_Custom_Entity
カスタムエンティティ Kusto_Custom_Entity → 組み込みエンティティ azure_data_explorer_cluster

結果として、Kusto_Custom_Entity の Related タブには azure_data_explorer_cluster が表示される一方、azure_data_explorer_cluster の Related タブには Kusto_Custom_Entity が表示されません。

結論：UI 仕様による片方向可視化（設定漏れではない）

現状の Microsoft Purview UI は「カスタム → 組み込み」のユーザー定義リンクを、カスタム側からのみ可視化します。 組み込みエンティティの Related タブは、ユーザー定義で追加した逆方向リンクを UI 上に掲出しません。したがって、ポリシーや権限、タイプ定義の設定漏れが原因ではありません。

重要なのは、メタデータ層では関係が保存されているという点です。つまり、UI で片側が見えないだけで、Atlas/Purview のメタモデル上は関係エッジが存在し、API で取得できます。この「UI の可視化仕様」と「メタデータ上の実体」を分けて理解すると、運用判断が速くなります。

表示可否の早見表

発信エンティティ	受信エンティティ	リレーション定義	発信側 Related タブ	受信側 Related タブ
カスタム（例：Kusto_Custom_Entity）	組み込み（例：azure_data_explorer_cluster）	ユーザー定義（タイプ定義/属性）	表示される	表示されない
カスタム	カスタム	ユーザー定義	表示される	表示される（設定次第）
組み込み	組み込み	既定（製品組み込み）	表示される	表示される

本記事のテーマは 1 行目に該当します。

なぜこうなるのか：Purview/Atlas の可視化レイヤーの考え方

Purview は内部で Apache Atlas のメタモデル（タイプ定義、エンティティ、リレーションシップ）に準拠した表現を採用しています。
UI の Related タブは、「どの関係を、どのナビゲーション方向で、どの種類のエンティティに対して露出するか」を製品側で制御しています。組み込みタイプ（例：azure_data_explorer_cluster）は、豊富な内蔵関係を持ちますが、ユーザーが追加する任意の逆方向リンクまで一律に露出する設計にはなっていません。このため、カスタム → 組み込みで作った関係は、「カスタムからの参照」としてのみ UI に現れます。

誤解しがちなのは、「Related に見えない＝リンクが存在しない」ではないことです。関係の実体は Atlas のリレーションシップとして保存されており、API では両端を追跡できます。

裏付け：API で両端のリンクを確認する

確認手順（概要）

対象の Kusto_Custom_Entity と azure_data_explorer_cluster の GUID を把握します。
Atlas/Purview REST API を使って、エンティティ詳細（relationshipAttributes/relationships）を取得します。
関係の片側（カスタム）から相手（組み込み）へのリンクがあること、あるいは関係リソース（relationshipGuid）で両端が接続されていることを確認します。

サンプル：エンティティ取得

# アクセストークン取得は環境に合わせて実施（省略）
# Kusto_Custom_Entity の GUID を仮に {GUID_CUSTOM} とする
curl -s -H "Authorization: Bearer &lt;TOKEN&gt;" \
  -H "Content-Type: application/json" \
  "https://&lt;your-purview-account&gt;.purview.azure.com/api/atlas/v2/entity/guid/{GUID_CUSTOM}?minExtInfo=true&amp;ignoreRelationships=false"

応答 JSON（要旨）では、relationshipAttributes または relationships に、azure_data_explorer_cluster を指す関係が格納されます。

{
  "entity": {
    "typeName": "Kusto_Custom_Entity",
    "attributes": { "...": "..." },
    "relationshipAttributes": {
      "adxCluster": [
        {
          "guid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
          "typeName": "azure_data_explorer_cluster",
          "displayText": "adx-prod-cluster"
        }
      ]
    }
  }
}

サンプル：組み込み側から逆引き

組み込み側の Related には出なくても、API で逆方向をたどれます。エンティティ GUID を {GUID_BUILTIN} とし、関連リレーションを列挙します。

curl -s -H "Authorization: Bearer &lt;TOKEN&gt;" \
  "https://&lt;your-purview-account&gt;.purview.azure.com/api/atlas/v2/entity/guid/{GUID_BUILTIN}/relationships"

レスポンスに、end1/end2 のいずれかが Kusto_Custom_Entity を指すリレーションが含まれます。これで「メタデータ上は両端リンクが保存されている」ことを機械的に検証できます。

Power BI などで可視化する

API で取得した JSON を Data Lake/Blob に蓄え、Power BI で読み込むと、組み込み側からも関係をナビゲートするダッシュボードを作れます。実装上の要点は次のとおりです。

抽出：REST 呼び出し（認証は Azure AD）。エンティティ一覧 → エンティティ詳細 → リレーションの 2 段抽出。
整形：entity.guid をノードキーに、relationship.guid をエッジキーにするグラフ化。
可視化：クラスタ（組み込み）を中心に、接続しているカスタムを外周に描くネットワーク図やサンバースト図が有効。

タイプ定義（TypeDef）の設計ポイント

カスタムエンティティから組み込みエンティティへリンクする場合、relationshipAttributeDefs で参照先タイプを指します。以下はイメージ（簡略化）です。

{
  "entityDefs": [
    {
      "name": "Kusto_Custom_Entity",
      "superTypes": ["DataSet"],
      "attributeDefs": [
        { "name": "kustoDatabase", "typeName": "string" }
      ],
      "relationshipAttributeDefs": [
        {
          "name": "adxCluster",
          "typeName": "azure_data_explorer_cluster",
          "cardinality": "SINGLE",
          "isLegacyAttribute": false,
          "isOptional": true
        }
      ]
    }
  ]
}

この定義で作った関係は、Kusto_Custom_Entity 側の Related には現れますが、azure_data_explorer_cluster 側には出ません。したがって、UI から双方向を期待する要件であれば、次節の設計パターンや運用ワークアラウンドを検討します。

誤設定ではないことを確かめるチェックリスト

観点	確認ポイント	合格基準
権限	Purview Studio に当該資産の閲覧権限がある	ポリシー違反や権限不足のエラーが出ない
タイプ定義	relationshipAttributeDefs に組み込みタイプを正しく参照	タイプの公開後、エンティティ作成が成功している
エンティティ	カスタム側の属性に GUID/参照が入っている	API で relationshipAttributes に値が出る
リレーション	relationships API で両端の GUID が接続されている	エッジ件数が 1 以上返る
UI 仕様	組み込み側 Related にユーザー定義逆リンクは出ない	UI の想定通り（＝非表示）であれば正常

要件に応じた 4 つの設計/運用パターン

パターン A：UI 片方向で十分（最小構成）

要件：カスタム → 組み込みの参照が片側で見えれば良い。
対応：現状のまま。API 監査だけ用意。
利点：実装・運用コスト最小。

パターン B：ビジネスユーザーにも逆方向を示したい（ワークアラウンド）

要件：組み込み側の資産ページからも関連カスタムに辿りたい。
対応：
- 説明欄にカスタム資産へのハイパーリンクを追記（資産 URL を貼付）。
- 資産名の命名規約に相互参照情報（ID/略称）を含める。
利点：即効性。非エンジニアにも分かりやすい。
注意：手作業のため品質管理が必要。

パターン C：ダッシュボードで双方向を可視化（推奨）

要件：網羅的に関係を探索したい／棚卸や影響分析で使いたい。
対応：REST 抽出 → ストレージ → Power BI でネットワーク図・テーブル化。
利点：資産種別を横断したグラフ視点、差分監査も容易。

パターン D：ビジネスグロッサリ連携

要件：用語（グロッサリ）側から、関連資産を一覧したい。
対応：グロッサリエンティティにカスタム/組み込み資産を紐づけ、用語ページをハブにする。
利点：教育・検索起点として強い。ユーザー導線が単純化。

運用で効くワークアラウンド（実例付き）

資産説明欄への逆リンク埋め込み（テンプレート）

【関係するカスタム資産】
・Kusto_Custom_Entity: <カスタログ内 URL または資産名/ID>
・Subscription: <資産名/ID>

【メモ】
・本クラスタは上記カスタム資産から参照されています。
・検索キーワード: <事業領域> / <データドメイン> / <責任者>

Power BI での関係グラフ化（変換レシピ）

抽出：entity/search で対象タイプの GUID を収集 → entity/guid/{id}?ignoreRelationships=false で詳細取得。
整形：entities テーブル（GUID, typeName, name）と edges テーブル（relGuid, end1Guid, end2Guid, relTypeName）。
可視化：force-directed グラフで azure_data_explorer_cluster を中央固定、Kusto_Custom_Entity と Subscription を周囲に配置。

命名規約による発見性向上

例）adx:{環境}-{領域}:{クラスタ名}、cust:kusto:{領域}:{論理名}
資産名に共通トークン（例：dom:marketing）を含め、Purview Studio の検索でヒットしやすくする。

再現実験：5 分でできる検証レシピ

Kusto_Custom_Entity タイプを登録（relationshipAttributeDefs に azure_data_explorer_cluster を参照）。
ダミーの Kusto_Custom_Entity エンティティを作成し、既存の ADX クラスタ（組み込み）へリンク。
Purview Studio で Kusto_Custom_Entity を開き、Related に ADX クラスタが表示されることを確認。
ADX クラスタ資産を開き、Related に Kusto_Custom_Entity が表示されないことを確認。
API で ADX クラスタの relationships を取得し、関係エッジがあることを確認。

この手順で UI とメタデータの乖離（＝UI 片方向表示）を誰でも再現できます。

影響範囲とビジネスインパクト

探索性：組み込み資産から起点に探索するユーザーは、UI 上の Related だけではカスタム資産を見つけにくい。
棚卸/監査：影響分析や棚卸は UI では不十分。API/ダッシュボードを併用すると抜け漏れが減る。
教育/オンボーディング：グロッサリや命名規約、説明欄テンプレートを整えると学習曲線を緩和できる。

実装時の落とし穴と回避策

落とし穴	症状	回避策
Related と Lineage の混同	血統図（Lineage）に出ないので関係が消えたと誤認	Lineage はデータフロー中心。構造的関係は Related/API で確認
タイプ定義の破壊的変更	属性名変更で既存エンティティの参照が切れる	属性の追加で対応し、移行フェーズを設ける
手作業リンクの品質ばらつき	説明欄リンクの貼り漏れ・表記ゆれ	テンプレート化＋定期的な品質チェック（API 監査）

監査・品質管理の実装ヒント

API を使えば、UI に非表示の逆方向も含め、関係の完全性を自動点検できます。

SELECT
  cluster.guid   AS builtin_guid,
  custom.guid    AS custom_guid,
  COUNT(rel.guid) AS rel_count
FROM
  relationships rel
JOIN entities cluster ON rel.end1 = cluster.guid OR rel.end2 = cluster.guid
JOIN entities custom  ON rel.end1 = custom.guid  OR rel.end2 = custom.guid
WHERE
  cluster.typeName = 'azure_data_explorer_cluster'
  AND custom.typeName = 'Kusto_Custom_Entity'
GROUP BY 1,2;

この集計で rel_count=0 のペアが見つかれば、想定リンクの欠落を検知できます。スケジュール実行して通知するだけでも運用の安心感が高まります。

よくある質問（FAQ）

Q. 組み込み側 Related に表示させる設定項目はありますか？
A. ありません。現行 UI の仕様です。

Q. 権限不足が原因の可能性は？
A. 組み込み側 Related に「そもそも列挙しない」ため、権限付与でも表示は変わりません。関係があるかは API で確認してください。

Q. Lineage に出すことはできますか？
A. Lineage はデータフロー（プロセス/入出力）表現です。カスタム → 組み込みの静的関連を Lineage に出すことは前提ではありません。

Q. 将来、双方向表示に変わる可能性は？
A. UI 改修・ロードマップ次第で変わる可能性はあります。運用では API 可視化と説明欄リンクを併用し、変化に備えてください。

設計判断のフローチャート（文章版）

「UI で片方向で十分か？」→ はい → 現状維持（API 監査のみ）。
「ビジネスユーザーが組み込み起点で探索するか？」→ はい → 説明欄リンク + 命名規約。
「棚卸/影響分析が重要か？」→ はい → API 抽出 + ダッシュボード化。
「用語起点でのナビゲーションが多いか？」→ はい → グロッサリをハブ化。

実務で役立つテンプレート集

説明欄テンプレート（組み込み側）

【関連カスタム】
・Kusto_Custom_Entity: <資産名/ID>
・Subscription: <資産名/ID>

【責任情報】
・プロダクトオーナー: <氏名/連絡先>
・技術責任: <氏名/連絡先>

【更新履歴】
・YYYY-MM-DD: 逆リンク追記、品質チェック済み

レビュー観点チェックリスト

カスタム → 組み込みのリンクが全て成立しているか（API）
説明欄の逆リンクが最新か（命名規約順守）
グロッサリの用語から対象資産に辿れるか（ユーザー受入）

セキュリティとガバナンスの補足

認可：API 利用は最小権限のサービスプリンシパルで。読み取り専用ロールを原則化。
変更管理：タイプ定義の変更はデータ契約の一部としてレビュー／承認を必須に。
監査証跡：抽出スクリプトは Git 管理、出力はバージョン付与。差分で逸脱検知。

ケーススタディ：Subscription → Kusto_Custom_Entity → ADX クラスタ

本ケースにおける「見える/見えない」の期待値を再度整理します。

画面	表示されるべきもの	補足
Kusto_Custom_Entity の Related	azure_data_explorer_cluster	UI で可視。クリックで組み込み資産へ遷移可能。
azure_data_explorer_cluster の Related	（表示されない）Kusto_Custom_Entity	UI 仕様。見せたい場合は説明欄リンクやダッシュボードを活用。
REST API（relationships）	Kusto_Custom_Entity ↔ azure_data_explorer_cluster の関係	両端が保持されていることをレスポンスで確認可能。

まとめ

仕様理解：Purview の Related タブは、カスタム → 組み込みのユーザー定義リンクをカスタム側だけに可視化する。
設定不要：ポリシー/設定変更では解決不可。現行 UI の想定動作。
裏付け：REST/Atlas API で両端リンクが保存されていることを確認できる。
運用解：説明欄逆リンク・グロッサリ連携・Power BI 可視化で、逆方向の発見性を確保。
将来性：UI 改修の可能性はあるため、ダッシュボードと命名規約で当面をカバーしつつ変化に耐える設計を。

本記事の指針に沿って、仕様に抗わず、見せたい人に見せたい関係を運用で提供してください。メタデータは正しく保存されています。後は、どう魅せるかのデザインです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Purviewのカスタム/組み込みエンティティでRelatedタブに表示されない問題の原因と対処法【UI仕様とワークアラウンド】

カスタムエンティティと組み込みエンティティの Related タブ表示問題の全貌

現象の要約

結論：UI 仕様による片方向可視化（設定漏れではない）

表示可否の早見表

なぜこうなるのか：Purview/Atlas の可視化レイヤーの考え方

裏付け：API で両端のリンクを確認する

確認手順（概要）

サンプル：エンティティ取得

サンプル：組み込み側から逆引き

Power BI などで可視化する

タイプ定義（TypeDef）の設計ポイント

誤設定ではないことを確かめるチェックリスト

要件に応じた 4 つの設計/運用パターン

パターン A：UI 片方向で十分（最小構成）

パターン B：ビジネスユーザーにも逆方向を示したい（ワークアラウンド）

パターン C：ダッシュボードで双方向を可視化（推奨）

パターン D：ビジネスグロッサリ連携

運用で効くワークアラウンド（実例付き）

資産説明欄への逆リンク埋め込み（テンプレート）

Power BI での関係グラフ化（変換レシピ）

命名規約による発見性向上

再現実験：5 分でできる検証レシピ

影響範囲とビジネスインパクト

実装時の落とし穴と回避策

監査・品質管理の実装ヒント

よくある質問（FAQ）

設計判断のフローチャート（文章版）

実務で役立つテンプレート集

説明欄テンプレート（組み込み側）

レビュー観点チェックリスト

セキュリティとガバナンスの補足

ケーススタディ：Subscription → Kusto_Custom_Entity → ADX クラスタ

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Purviewのカスタム/組み込みエンティティでRelatedタブに表示されない問題の原因と対処法【UI仕様とワークアラウンド】

カスタムエンティティと組み込みエンティティの Related タブ表示問題の全貌

現象の要約

結論：UI 仕様による片方向可視化（設定漏れではない）

表示可否の早見表

なぜこうなるのか：Purview/Atlas の可視化レイヤーの考え方

裏付け：API で両端のリンクを確認する

確認手順（概要）

サンプル：エンティティ取得

サンプル：組み込み側から逆引き

Power BI などで可視化する

タイプ定義（TypeDef）の設計ポイント

誤設定ではないことを確かめるチェックリスト

要件に応じた 4 つの設計/運用パターン

パターン A：UI 片方向で十分（最小構成）

パターン B：ビジネスユーザーにも逆方向を示したい（ワークアラウンド）

パターン C：ダッシュボードで双方向を可視化（推奨）

パターン D：ビジネスグロッサリ連携

運用で効くワークアラウンド（実例付き）

資産説明欄への逆リンク埋め込み（テンプレート）

Power BI での関係グラフ化（変換レシピ）

命名規約による発見性向上

再現実験：5 分でできる検証レシピ

影響範囲とビジネスインパクト

実装時の落とし穴と回避策

監査・品質管理の実装ヒント

よくある質問（FAQ）

設計判断のフローチャート（文章版）

実務で役立つテンプレート集

説明欄テンプレート（組み込み側）

レビュー観点チェックリスト

セキュリティとガバナンスの補足

ケーススタディ：Subscription → Kusto_Custom_Entity → ADX クラスタ

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル