Data Catalog／付随情報 Catalog × AI

Data CatalogをAI/Agentのcontext sourceにする場合、検索結果をそのまま正本データや実行権限として扱いません。 Catalogから取得したcontextには、可能な範囲でentity identity、source locator、metadata revision/freshness、owner、glossary/term、lineage、quality、authorization境界を残します。

Catalogはschemaだけでなく、description、owner、domain、tag/classification、glossary、lineage、quality metadata等をAIへ供給できます。 ただしcatalog metadataはsource systemのcopy/derived metadataです。ingestion、sync、index、manual curationの遅延や欠落を持ち得るため、catalog hitをsource recordの最新性・完全性・利用可能性の証明にしません。

AIへ渡すcontext itemには、可能なら次を保持します。 - catalog entity ID / FQN - source system / source locator - metadata type - catalog/product version - ingestion/sync run ID - observed/synced timestamp - metadata revision/version freshnessが不明またはSLO超過なら、その状態をcontextから消しません。

search resultはdiscovery resultです。検索成功だけから、全対象取得、source現存、metadata最新、source data可読、ranking上位が正解、を断定しません。pagination、index lag、duplicate identity、filter/ACLを検証対象にします。

Glossary/term/tagはbusiness semanticsをAIへ渡す重要な入力です。一方、term存在だけで組織合意や正確性を保証しません。可能ならowner/reviewer、approval/status、version、definition、related assetsを保持し、draft/unreviewed/conflicting termをauthoritative factへ自動昇格させません。

Catalog lineageは有用ですが、完全なruntime provenanceと同一視しません。lineageはconnector coverage、query parsing、manual edge、sync timing、catalog/client versionに依存します。missing edgeはNO_DEPENDENCYではなく、coverageを確認できない場合はUNKNOWNとして扱います。AI回答から重要なlineage claimを出す場合、対象entity、edge source、observed revision/freshnessへ逆参照できる状態を維持します。

catalog read権限とunderlying warehouse/object/APIの実行権限を分離します。Catalogにassetが見えることをsource access許可として扱いません。Agentが実データへアクセスする場合はsource側IAM/authorizationを別途評価します。

CatalogのAI/MCP surfaceではreadとwriteを分離します。read-onlyはsearch/entity details/lineage retrieval。write-capableはglossary/term creation、lineage creation/deletion、entity patch、quality-test creation等。write toolは明示approval、least privilege、audit log、mutation後readbackを要求します。toolが公開されていることを実行許可と解釈しません。

Catalog上のquality resultは重要なcontextですが、AI回答品質保証ではありません。quality constraintの対象、run、timestamp、resultへ参照可能にし、DATA_QUALITY_PASSとAI_ANSWER_PASSを別stateとして扱います。

Catalogの挙動はserver、client/SDK、connector、index、lineage parser等のversionに依存します。OpenMetadata/DataHub双方で2026年にもMCP、search、indexing、lineage、runtime互換性に関する修正・更新が継続しています。導入時は製品名だけでなくversionとconnector/runtimeを固定します。

stale ingestion、connector omission、lineage parse loss、manual false edge、entity rename/FQN drift、duplicate entity、search pagination defect、index lag、glossary conflict、unreviewed term、stale owner、tag propagation error、source deletion後のcatalog残存、catalog-visible/source-denied、ACL drift、MCP overbroad scope、write tool accidental mutation、metadata内prompt injection、sensitive metadata leakage、stale quality badge、client/server mismatch、async ingestion failure、AIによるfreshness/provenance無視を想定します。

本項は2026-10-06時点のOpenMetadata current documentation/2.0.3 release line、DataHub current documentation/Cloud 2.1.7 release line、およびmaintainer issue/release evidenceとbounded local fixtureに基づきます。live catalog、connector、MCP、warehouse/object IAMへのmutationは未実施です。

Data CatalogをAI/Agentのcontext sourceにする場合、検索結果をそのまま正本データや実行権限として扱わず、entity identity、source locator、metadata revision/freshness、owner、glossary、lineage、quality、authorization境界を保持してください。Catalog lineageやsearchはconnector・index・version・manual metadataに依存するため、欠落を「依存なし」、hitを「最新かつ完全」と断定しません。read-only context toolとmetadata write toolを分離し、writeは別approvalとreadbackを要求します。

organization catalog、chosen product/version、connectors、ingestion cadence、source IAM、entity identity policy、glossary approval、lineage coverage target、quality integration、MCP scopes、prompt-injection filtering、metadata retention、tenant/network boundaryは未確認です。