Microsoft Purview CSVインポートでHas_Table/Has_Fileが作れない原因とrelatedObjectsでの紐付け方法

Microsoft Purview の「Business Asset」をCSVで一括インポート（import）すると、description や steward / expert などは更新できるのに、[Relationships]Has_Table / [Relationships]Has_File にGUIDを入れても関係が作られない――この“あるある”の原因と、運用で詰まらないための現実的な解決策（relatedObjects／Lineage／API）をまとめます。

現象：CSV importは成功するのに、Has_Table / Has_File だけ空のまま

Purview の Business Asset をエクスポート→CSV編集→インポートで運用していると、次のような挙動に遭遇しがちです。

description、owner、steward、expert などの基本プロパティは更新できる
ところが、CSVの列に [Relationships]Has_Table / [Relationships]Has_File があり、そこへGUIDを ; 区切りで入れても、インポート後に画面を見ると関係が空のまま
インポート処理自体は「成功」に見える（エラーが出ない）ため、原因が追いづらい

結論から言うと、ここで「CSVの書き方が少し違うのでは？」と粘るほど時間が溶けます。Purview側の仕様・意味づけ・機能制約が絡むため、狙いに合った別ルートへ切り替えるのが最短です。

結論：Business AssetのCSVインポートで Has_Table / Has_File を作るのは制限が強く、期待通り動かないことが多い

Microsoft Q&A でも同様の相談があり、Business Asset のCSVインポートでは Has_Table / Has_File のような複雑なRelationshipの作成・更新は制限が強く、うまく動かない（空のままになる）という説明がされています。特に、Business Asset（またはBusiness Glossary側）から外向きに Has_Table/Has_File を張る用途は「テンプレートとして列があっても、実際は反映されない」ケースが起きやすいです。

また、Business AssetをCSVで扱う機能自体は「エクスポートしてスプレッドシートで編集し、インポートで一括反映できる」ことがメリットとして紹介されていますが、ここで得意なのは主に属性（プロパティ）編集です。Relationshipは別の表現に寄せたほうが安定します。

まず押さえる：Has_Table / Has_File は「ビジネスアセットの紐付け」用というより“コンテナ関係”の文脈が強い

Purview のデータカタログ（Data Map）は Apache Atlas の型システムをベースにしており、エンティティ（資産）同士の関係は「Relationship」として定義されます。

この前提に立つと、Has_Table / Has_File はしばしば次のような“技術アセットの階層”を表す意図で使われます。

関係名	典型的な意味（よくある発信側 → 受信側）	Business Assetから使うと起きがちな問題
Has_Table	データベース／スキーマ → テーブル（「このコンテナがテーブルを持つ」）	Business Assetは“コンテナ”ではないため、意味づけが噛み合わず、インポート時に無視されやすい
Has_File	フォルダ／ストレージ階層 → ファイル（「この場所がファイルを持つ」）	Business Assetがファイルを“所有する”という表現に無理があり、UIやテンプレートに列があっても更新されないケースがある

つまり、やりたいことが「Business Asset（例：データプロダクト、KPI、業務概念）と、テーブル／ファイル等の技術アセットを結びつけたい」なら、Has_Table / Has_File を“所有関係”のように使うのは遠回りになりがちです。Microsoft Q&A の回答でも、Has_Table / Has_File のセマンティクスがBusiness Asset用途と合わない点が指摘され、別の方法（relatedObjects等）が推奨されています。

なぜGUIDを正しく入れても反映されないのか

「GUID形式も合っているはず」「; 区切りも正しい」「それでも空」になる主な理由は、だいたい次のどれかです。

CSVインポートがRelationship更新を“公式に”サポートしていない／反映範囲が限定的

Business AssetのCSVインポートは、説明文や担当者（owner/steward/expert）のような属性の一括編集が中心で、Has_Table / Has_File のようなRelationshipは非対応または実質的に反映されないケースが多い、という整理がされています。

Has_Table / Has_File が“読み取り専用に近い”扱いになっている

Relationshipの中には、スキャン・系統（lineage）・内部処理で自動生成される前提のものがあり、CSVで「手で押し込む」更新が通らないことがあります。結果として、インポート成功に見えてもRelationshipだけ黙って無視される、という挙動になります。

GUIDが存在しない／権限が足りない／空白混入など“ありがちな落とし穴”がエラーにならない

仮にRelationship更新が可能だったとしても、参照先GUIDがカタログに存在しない、別環境のGUIDを貼っている、余計なスペースが混ざっている、といったケースはエラーにならず無視されやすいとされています。

症状	原因の例	対処
インポートは成功扱いだが関係だけ空	そもそもRelationshipがCSV更新対象外／セマンティクス不一致	Has_* を捨て、relatedObjects/Lineage/APIへ切替
一部だけ入る／環境によって挙動が違う	テンプレート差分、ポータル体験（classic/新UI）の差、更新可能フィールド差	エクスポートしたCSVを“正”としてフォーマットを踏襲
GUIDを貼ったのに反映ゼロ	GUID誤り、余計な空白、別環境GUID、参照先が未スキャンで未存在	APIでGUIDの実在確認、スペース除去、まず対象アセットをスキャンで作る

実務的な解決策：Business Asset ↔ 技術アセットは relatedObjects で紐付ける

「このBusiness Assetが参照するテーブル」「このデータプロダクトに含まれるファイル」など、“関連付け”として辿れるリンクを作りたい場合は、Has_Table/Has_File ではなく relatedObjects を使うのが現実的です。Microsoft Q&A の回答でも、Business Assetから技術アセットへ結びつける用途では relatedObjects が推奨ルートとして示されています。

relatedObjectsでできること（Has_* を無理に使わないメリット）

Business Asset側の画面で「関連オブジェクト（Related objects）」として辿れる
“所有”や“階層”ではなく、業務上の紐付け（参照・対象・関連）として意味が通る
スキャンで自動生成される技術階層（コンテナ→中身）と衝突しにくい
CSV運用でも比較的再現性が高い（ただしエスケープが肝）

relatedObjectsのCSV記述パターン

relatedObjects は、GUID参照を配列として持たせる形になります。ポイントは「CSVの1セルの中に配列（文字列）を入れる」ことです。

まず最優先でおすすめなのは、Purview側からエクスポートしたCSVをテンプレートとして使い、relatedObjects列の表記を踏襲することです。Business Assetのエクスポート→編集→インポートの導線は公式ブログでも紹介されています。

ここでは“崩れにくい”形として、ダブルクォートをCSVルールどおりに二重化した例を示します（Excel編集でも破綻しにくいです）。

name,typeName,qualifiedName,description,relatedObjects
"顧客売上KPI","BusinessAsset","kpi_customer_revenue@contoso","月次の顧客売上を示すKPI","[{""entity"":{""guid"":""7eb58f8a-1234-5678-abcd-111111111111""}}]"

複数のテーブル／ファイルへ紐付けたい場合は、配列要素を増やします。

"顧客売上KPI","BusinessAsset","kpi_customer_revenue@contoso","月次の顧客売上を示すKPI","[{""entity"":{""guid"":""7eb58f8a-1234-5678-abcd-111111111111""}},{""entity"":{""guid"":""2aa58f8a-1234-5678-abcd-222222222222""}}]"

上記は汎用例です。実際のキーやオブジェクト形は、環境・テンプレート・エクスポート形式で微妙に違う可能性があります。だからこそ、エクスポートしたCSVの relatedObjects 列を正とするのが安全です。

Excelで崩さないためのコツ（relatedObjectsが反映されない最大原因）

relatedObjects が反映されないとき、原因はPurviewではなく「CSVの中身が見た目どおりになっていない」ことが非常に多いです。次の手順だと事故が減ります。

Purviewで1件だけ手作業で関連付けできるなら先に作る（可能な範囲で）
そのアセットタイプをエクスポートし、relatedObjects列の“正解フォーマット”を確認する
Excelで編集する場合は、relatedObjects列を文字列（テキスト）扱いにしてから貼り付ける
保存後、メモ帳系エディタで開き、ダブルクォートが増殖していないか、改行が混入していないか確認する

落とし穴	起きること	回避策
セル内に改行が入る	見た目は1セルでもCSV上は複数行になり、インポートで無視されやすい	セル内改行禁止、貼り付け前に整形
ダブルクォートのエスケープ崩れ	JSONっぽく見えてもCSVとして解釈がズレる	`""` で二重化、またはエクスポート形式を踏襲
区切り文字の混乱（地域設定）	カンマ区切り前提のはずが別区切りで保存される	CSVの区切りを固定、可能ならテキストエディタで編集

インポート後の確認ポイント

Business Asset詳細画面で Related objects が表示されるか（表示名が出ない場合でもリンクがあるか）
紐付けた先のテーブル／ファイル側の画面から、逆方向の関連が辿れるか（UI差はあります）
反映が怪しいときは、まず「1件・1GUID」で成功する形を作ってからスケールさせる

Lineageで表現すべきケース：参照ではなく“流れ・由来”を残したい

「このBusiness Assetはこのテーブルから作られる」「このファイルを加工してこの成果物になる」など、データの由来・変換の流れを示したいなら、静的な関連付けよりも Lineage（系統） が適切です。

PurviewのLineageは、データセット（ノード）とプロセス（エッジ）で表現され、Data FactoryやPower BIなどが実行時に系統情報をプッシュする仕組みや、Atlas hooks／REST API でのカスタム系統もサポートされます。

relatedObjects と Lineage の使い分け

やりたいこと	おすすめ	理由
このKPIに関連するテーブル一覧を見せたい	relatedObjects	静的リンクとしてシンプルに辿れる
原データ→加工→集計→レポートの流れを残したい	Lineage	プロセスと入出力の関係として表せる
“関連”も“流れ”も必要	relatedObjects＋Lineage併用	Business側の文脈はrelatedObjects、技術側の変換はLineageが得意

Azure Data Factoryの実行系統を使う（自動化の王道）

Azure Data Factory と Purview を接続すると、サポートされるアクティビティ実行時にソース／出力などのメタデータが Data Map に取り込まれ、Lineageとして可視化できます。運用で「継続的に正しい系統を残す」なら、まずここを押さえるのが効果的です。

大量・継続更新なら CSVよりAPI/スキャン/Atlas hooks が安定

CSVは“人がメンテできる範囲”に強い一方、次の条件が揃うと破綻しやすくなります。

対象が数千〜数万で、毎週・毎月更新が発生する
関連先GUIDの検索・検証が手作業では回らない
Lineageや複雑な関係を正確に維持したい

このフェーズでは、Purview（Atlas）REST API を使った一括更新が現実的です。たとえばエンティティの一括作成・更新APIは、guidまたはqualifiedNameで既存エンティティを突合できることが明記されています。

API運用に寄せるメリットは次のとおりです。

GUIDの実在確認、更新対象の差分抽出、失敗時のリトライなどを“仕組み化”できる
更新結果（レスポンス）をログとして残し、監査・検証がしやすい
Lineageやカスタム関係（hooks含む）に拡張しやすい

なお、API側でも「配列やマップなどコレクション型は扱いに制限がある」旨が書かれているため、Relationshipや配列属性を一気に更新する設計は、テンプレート作りと小さな検証を挟むのが安全です。

最低限のトラブルシュート：詰まったらここだけ見る

「relatedObjectsに切り替えたのに反映されない」「APIで更新したのに見えない」など、次のチェックで原因の切り分けが早くなります。

チェック	見るポイント	具体例
GUIDは本当に存在するか	存在しないGUIDは無視されやすい	`GET https://<account>.catalog.purview.azure.com/api/atlas/v2/entity/guid/{guid}` で確認
CSVが壊れていないか	クォート、改行、区切り文字	relatedObjects列だけテキストエディタで最終確認
権限が足りるか	更新できるロール・コレクション	対象コレクションで更新権限を確認
UIの見え方の差	classic/新UIで表示位置が違う	Related objects、Lineageタブの両方で確認

運用で失敗しない設計のコツ：Business Assetを“説明書”、技術アセットを“実体”として結ぶ

Has_Table/Has_File を無理やり作ろうとして詰まる背景には、「Business Assetで技術資産の構造を管理したい」という発想が混ざっていることが多いです。ここを分離すると、Purview運用が安定します。

技術アセットの階層（コンテナ→中身）：スキャンで自動生成される関係に任せる（Has_Table/Has_File を手で作らない）
Business Asset（KPI/データプロダクト/業務概念）：意味・定義・責任者・利用条件など“説明書”を充実させる
両者の接続：relatedObjects で「この説明書が指す実体」を紐付ける
変換・派生の流れ：Lineage（自動またはAPI/hook）で残す

この役割分担にすると、「CSVでできること」と「CSVで無理にやるべきでないこと」が自然に分かれ、結果的にメンテ工数が下がります。

まとめ：Has_Table/Has_Fileにこだわらず、Purviewの想定ルートで“確実に”紐付ける

Business AssetのCSVインポートで [Relationships]Has_Table/[Relationships]Has_File を更新しようとして空のままになる場合、CSVの書き方以前に機能制約と意味づけの不一致が原因であることが多いです。

Business Assetとテーブル／ファイルを「関連付け」として辿りたい → relatedObjects を使う
データの流れ・派生を示したい → Lineage（ADF連携やAPI/hook）を使う
大量・継続更新が前提 → CSVではなく REST API を軸に自動化する

最短で安定させるなら、まずは「エクスポートしたCSVをテンプレートとして踏襲し、relatedObjectsで1件成功させる」→「複数GUIDに拡張」→「必要ならAPI化」の順が、現場で失敗しにくい進め方です。

この記事を書いた人

佐藤健司

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