分散データ エステートでは、コンテキストのない未加工のデータだけでは、ビジネス上の問題を解決することはほとんどありません。構造化データベース、非構造化ログ、分析指標にビジネス上の意味がない場合、ユーザーと自律システムはコンテキストの限界に直面します。人間のアナリストは、データソースを検証するために手動で検証を行う必要がありますが、AI エージェントは不正確な回答(ハルシネーション)を生成したり、アクションを実行できなかったりすることがよくあります。
Knowledge Catalog は、メタデータ管理を受動的なカタログからアクティブなコンテキストの動的コントロール プレーンに移行することで、この問題を解決します。Knowledge Catalog は、技術構造、ビジネスルール、実際の使用パターンを集約することで、統一されたコンテキスト レイヤを提供します。これにより、ユーザーと AI アプリケーションの両方が、データ資産を正確かつ安全に検出、評価、解釈できます。
コンテキストとは
コンテキストは、データアセットを記述する構造、運用、セマンティクスの詳細なファブリックです。コンテキストは、テーブルを名前とデータ型のスタンドアロン スキーマとして表すのではなく、データの全体像を提供します。
Knowledge Catalog は、コンテキストを次のレイヤに整理します。
技術メタデータ。データベース スキーマ、フィールド タイプ、パーティショニング キー、セキュリティ タグ(Identity and Access Management(IAM)ポリシーなど)など、ソースシステムから直接取り込まれた構造の詳細。
セマンティック メタデータ。データのビジネス上の意味。これには、ビジネス用語集、指標の関係、分類、ドメイン用語、ゴールデン クエリ(正しい SQL コード ステートメントにマッピングされた検証済みの自然言語の質問)が含まれます。
オペレーショナル メタデータ。列レベルのデータリネージ、実行プロファイル、プロファイリング統計情報、データ品質スコアなど、時間の経過に伴うデータの動作と健全性。
関係。物理ストレージ テーブルと概念的なビジネス指標間の推論または定義されたリンク。
トラスト シグナル。アセットが信頼できる情報源であるかどうかを確認する、所有権のスタンプや認証などの確認インジケーター。
エージェント向けガイダンス。リソースのクエリ方法とタイミングについて自律型ツールをガイドする非構造化された説明(README ファイル、使用上の注意、実行ログなど)。
これらのレイヤを統合することで、Knowledge Catalog はデータを完全に理解できるようにし、サイロ化されたドキュメント化されていないデータに関連する運用上のボトルネックと不確実性を回避します。
データ コンテキストとメタデータの違い
メタデータは基本的な構成要素を提供しますが、メタデータとコンテキストは相互に置き換えられません。
- メタデータ。分離されたデータアセットの物理構造、ロケーション、技術的なプロパティを定義する説明属性(列名、データ型、パーティション キー、テーブル サイズなど)。
- コンテキスト。技術スキーマ、ビジネス セマンティクス、データ関係、運用動作、信頼シグナルを組み合わせて、データの意味を付与し、推論を導く、合成された多次元ナレッジグラフ。
次の表に、パッシブ メタデータとアクティブ データ コンテキストの主な違いを示します。
| ディメンション | テクニカル メタデータ | アクティブなデータ コンテキスト |
|---|---|---|
| 主な焦点 | 物理的な仕様とストレージ形式。 | ビジネス上の意味、運用上の動作、関係。 |
| State | パッシブ: エンジニアが手動で検索できるように、カタログ レジストリに保存されます。 | アクティブ: AI によって継続的に拡充され、クエリ履歴からマイニングされ、LLM プロンプト用に動的に組み立てられます。 |
| 主な消費者 | データベース エンジン、データ エンジニア、コンプライアンス監査担当者。 | AI エージェント、大規模言語モデル(LLM)、ビジネス アナリスト、会話型インターフェース。 |
| 主な目的 | ストレージ管理、インデックス登録、コンプライアンス検証。 | エージェントの推論のグラウンディング、結合の解決、ハルシネーションの防止。 |
例: メタデータとコンテキストの比較
コンテキストがテクニカル メタデータをどのように拡張するかを理解するには、Knowledge Catalog がトランザクション列をどのように表すかを考えてみましょう。
1. テクニカル メタデータのみ
テクニカル メタデータは構造情報を提供しますが、ビジネス ロジックと運用ガイドラインがありません。
- テーブル:
fact_orders - 列:
disc_val - データ型:
NUMERIC - ストレージのプロパティ:
order_dateでパーティショニング
この技術メタデータのみを使用する AI エージェントは、disc_val が顧客割引の合計を表していると推測する可能性がありますが、その値に税金、メーカーの割引、プロモーション クーポンが含まれているかどうかを判断することはできません。
2. 拡充されたデータ コンテキスト
Knowledge Catalog は、セマンティック レイヤ、リレーショナル レイヤ、オペレーション レイヤを使用して技術メタデータを拡充し、統合されたコンテキスト ペイロードにします。
- 技術スキーマ:
fact_orders.disc_val(NUMERIC)。 - セマンティック定義: ビジネス用語集の用語「プロモーション割引」にマッピングされます。これは、メーカーの割引や送料を除き、購入手続き時に適用される顧客割引として定義されます。
- 検出された関係:
fact_orders.customer_idをdim_customers.idに、fact_orders.promo_idをdim_promotions.idに自動的にリンクします。 - 運用上の使用状況: クエリ履歴から、ビジネス クエリの 90% が
status = 'COMPLETED'でこのテーブルをフィルタし、dim_promotionsと結合していることがわかります。 - 信頼性と品質: 自動データ品質スキャンで 99.8% の有効性スコアを獲得し、過去 2 時間以内にデータの更新速度が確認済み。
- ゴールデン クエリ:
disc_valを使用して認識された純収益を計算する方法を示す検証済みの SQL テンプレートが含まれています。
この完全なコンテキストにより、AI エージェントやデータ アナリストは、手動による人間の検証やハルシネーションなしで、クエリを正確に生成し、データを解釈できます。
コンテキストなしでデータを使用する際の課題
ほとんどのエンタープライズ データには必要なメタデータが不足しているため、AI での検出、信頼、運用が困難になっています。構造化されたコンテキストがない場合、組織は次のような運用上のボトルネックに直面します。
コラボレーションのトイル。明確なビジネス定義がないため、分析チームと AI チームは、テーブルの基本的な理解を構築するために、対象分野の専門家(SME)との継続的な手動調整サイクルを余儀なくされます。
コンテキストのずれ。標準のドキュメントは静的であり、時間の経過とともに劣化します。継続的なモニタリングがないと、古いメタデータが誤った前提につながり、AI エージェントのワークフローが破綻します。
推論の失敗。AI エージェントと大規模言語モデルは、構文的に正しい SQL クエリを生成する可能性がありますが、基盤となるエンタープライズ ロジックを尊重できず、ビジネスの観点から正しくない計算が行われる可能性があります。
情報のサイロ化。データセットを正しくフィルタリングまたは結合する方法に関する内部知識は、一元化されたインベントリに登録されるのではなく、ドキュメント化されていないスクリプトやダッシュボードの設定に閉じ込められたままになります。
こうした運用上のボトルネックを解消し、データを実用的なものにするには、データ資産全体で信頼性の高いコンテキスト エンジンが必要です。
コンテキスト管理の主な柱
データ資産全体でこの信頼性の高いコンテキスト エンジンを維持するために、Knowledge Catalog は次の 3 つの柱で構成されています。
集計
Knowledge Catalog は、組み込みデータベース、Iceberg REST カタログ、サードパーティ プラットフォーム全体からメタデータを自動的に収集します。これらの断片的な入力を単一の統合されたガバナンス ゾーンに統合し、セキュリティ ポリシーと分類定義が一貫して継承されるようにします。
拡充
Knowledge Catalog は、AI 駆動型の取り込みを使用してコンテキスト グラフを継続的に更新し、キュレートします。Knowledge Catalog は、トランザクション ログ、データベース スキーマ、ビジネス インテリジェンス モデルをマイニングすることで、列の説明とテーブルの関係を自動的に検出します。この継続的な学習により、データオーナーの組織内の知識が取得され、アセットに動的に適用されます。
検索と取得
Knowledge Catalog は、自然言語でデータ エステートをクエリできる高精度のセマンティック検索を提供します。Knowledge Catalog は権限グループ(ACL)とビジネス用語を理解しているため、ユーザーと自律型エージェントの両方が低レイテンシで関連するデータ コンテキストを見つけることができます。
メタデータとコンテキストが Knowledge Catalog にどのように取り込まれるか
信頼性の高いコンテキスト エンジンを構築するために、Knowledge Catalog は、自動化されたプラットフォーム コネクタ、継続的な AI 拡充、拡張可能なカスタム インターフェースを通じて情報を取り込み、キュレートします。
ファーストパーティ データソースと自動収集
Knowledge Catalog は、手動構成を必要とせずに、コア Google Cloud サービスから構造メタデータと運用メタデータを自動的に収集します。
- データベースと分析用ウェアハウス。BigQuery、Spanner、Cloud SQL、AlloyDB for PostgreSQL などのサービスは、テーブル スキーマ、フィールド データ型、パーティショニング キー、クラスタリング仕様、データセット境界などの技術メタデータを継続的に同期します。
- 非構造化データの分析情報。Cloud Storage に保存されている非構造化ファイル(PDF ドキュメントやポリシー マニュアルなど)の場合、Knowledge Catalog は検出スキャンとプロファイリング スキャンを実行して、キーコンセプトとエンティティ関係を抽出し、グラフ プロファイルを生成して、BigQuery に構造化オブジェクト テーブルを登録します。詳細については、非構造化データ分析についてをご覧ください。
- すぐに使える BI セマンティクスとリネージの同期。Looker(Google Cloud コア)の場合、Knowledge Catalog はビジネス インテリジェンス アセットを自動的に同期します。
- LookML セマンティック定義。モデル、Explore、ビュー、ディメンション、メジャー。
- BI ダッシュボード アセット。ダッシュボード、ダッシュボード要素、Look。
- エンドツーエンドのデータリネージ。基盤となる BigQuery テーブルからダウンストリームの Looker ダッシュボードまでの関係のデータフローをトレースします。詳細については、Knowledge Catalog を使用して Looker(Google Cloud コア)リソースを管理するをご覧ください。
- データ統合と変換。Datastream などのサービスは、変更データ キャプチャ(CDC)ストリームのメタデータとリネージをキャプチャし、Dataform はテーブル定義と SQL 変換をプッシュし、Cortex Framework は登録されたデータ プロダクトを公開します。
AI による継続的なコンテキスト キュレーション
Knowledge Catalog は、静的な技術スキーマだけでなく、組み込みのインテリジェンス エンジンを使用してコンテキスト グラフを動的に更新します。
- データの分析情報: Gemini in BigQuery を搭載したデータ分析情報は、過去のクエリログ、ユーザー トランザクション、スキーマ パターンをマイニングして、自然言語の列の説明を生成し、テーブルの関係(結合キーなど)を検出し、エンタープライズ ロジックをキャプチャする検証済みのクエリの例(「ゴールデン クエリ」)を提案します。詳細については、構造化データのデータ分析についてをご覧ください。
- 自動データ プロファイリングとデータ品質。スキャンでは、統計分布(重複しない数、null 比率、サンプル値など)を計算し、ルールベースのデータ品質チェックに照らしてデータを評価して、カタログ エントリにライブの健全性スコアを付加します。詳細については、自動データ品質についてをご覧ください。
- 自動データリネージ。データ パイプライン全体で列レベルの変換フローとジョブ実行履歴を集計します。詳細については、データリネージについてをご覧ください。
カスタム メタデータの取り込みとサードパーティ システム
カスタム ナレッジベース、サードパーティのガバナンス ツール、オンプレミス システムを使用している組織の場合、Knowledge Catalog には柔軟な取り込みメカニズムが用意されています。
- Knowledge Catalog API(CRUD オペレーション)。
CreateEntry、UpdateEntry、CreateAspectType、SetAspectの API メソッドを使用して、外部アセットをプログラムで登録し、カスタム メタデータ アスペクト(コンプライアンス評価やシステム ドキュメントなど)を関連付けます。 - カスタム エンリッチメント エージェント。Agent Development Kit(ADK)や LangChain などのエージェント フレームワークを使用して、カスタムの拡充エージェントを構築します。たとえば、ADK エージェントは、内部 Wiki や Git リポジトリから技術ドキュメントを取り込み、LLM を使用して標準化されたビジネス用語集の用語に解析し、カタログ エントリに添付できます。詳細については、メタデータを拡充する AI エージェントを構築するをご覧ください。
- エクスポートとインポートのオペレーション。ファイルベース(JSON または CSV)の一括エクスポートとインポートのワークフローを使用して、AI によって生成されたビジネス定義を確認し、データ スチュワードと共同作業を行い、メタデータを一括更新します。詳細については、メタデータをエクスポートするをご覧ください。
ファーストパーティ サービスとサードパーティ サービスでコンテキストがどのように使用されるか
サービスとアプリケーションは、次の 2 つの異なるロールで Knowledge Catalog とやり取りします。
- メタデータ プロバイダ。技術的メタデータ、スキーマ、LookML 定義、リネージを Knowledge Catalog に送信するサービス(Looker、Cloud SQL、Spanner など)。メタデータ プロバイダはメタデータをカタログにプッシュしますが、必ずしもビジネス用語集の定義を独自のユーザー インターフェースに取り込むわけではありません。
- コンテキスト コンシューマー。Knowledge Catalog からビジネス定義、運用プロファイル、ガバナンス ルールを取得して、推論と実行の根拠とするサービス、デベロッパー ツール、AI エージェント。
アプリケーションとエージェントがコンテキストを使用する前に、基本的なビジネス用語と品質ルールを確立する必要があります。詳細については、基本的なデータ コンテキストを確立するとポリシー コードとしてのデータ品質ワークフローを構築するをご覧ください。
AI アプリケーションとサービスは、次のメカニズムを介して Knowledge Catalog からコンテキストを消費します。
組み込みのファーストパーティ(1P)統合
次の Google Cloud サービスは、Knowledge Catalog をネイティブにクエリして、コンテキスト認識 AI エクスペリエンスを提供します。
- Gemini in BigQuery(会話型エージェント)。BigQuery Studio で自然言語プロンプトを入力すると、Gemini はバックグラウンドで Knowledge Catalog のビジネス用語集の定義、列の説明、過去のクエリの関係を自動的にクエリします。これにより、Gemini はエンタープライズ ビジネス用語を理解し、生成された SQL クエリで正しいテーブル結合と指標定義が使用されるようになります。
- BigQuery のデータ エンジニアリング エージェント。Apache Iceberg テーブルと BigQuery テーブルを検出してクエリし、セマンティック カタログ検索を自動的に呼び出してアセットの依存関係を解決し、パイプラインの実行中にカタログ メタデータを生成します。
- Vertex AI と Agent Builder。Vertex AI で構築されたカスタム生成 AI エージェントと検索アプリケーションは、カタログ メタデータとビジネスルールを使用して、検証済みの企業事実に基づいてモデルの推論を行います。
- Google Cloud コンソールとビジネス UI。エンドユーザーとデータ スチュワードは、自然言語のセマンティック検索を使用してアセットを探索し、インタラクティブなデータ関係グラフを表示して、ビジネス用語集を管理します。
サードパーティ アプリケーションと AI エージェント エコシステム
組み込みの統合がないサービスと自律システムは、オープン プロトコルと専用の取得 API を介してコンテキストを使用します。
Model Context Protocol(MCP)
Model Context Protocol(MCP)は、AI エージェント、デベロッパー ツール、IDE を Knowledge Catalog ツールに直接接続できるオープン スタンダードです。MCP は、テーブル スキーマの検査、用語集の定義の検索、データ品質スコアの検証、データリネージのトレースを行うための標準化されたインターフェースを提供します。
Knowledge Catalog は、次の 2 つの MCP デプロイ オプションをサポートしています。
- リモート MCP サーバー。クラウドネイティブ エージェント、サーバーレス ワークフロー、マルチエージェント プラットフォーム用に Google Cloud でホストされる(または Cloud Run にデプロイされる)マネージド エンドポイント。詳細については、Knowledge Catalog リモート MCP サーバーを使用するをご覧ください。
- ローカル MCP ツールボックス。デベロッパー IDE(VS Code や Cursor など)とローカル開発ワークフローを統合するローカル CLI プロキシ。詳細については、ローカル MCP ツールボックス サーバーで Knowledge Catalog を使用するとローカル MCP ツールボックス サーバーでデータ リネージを使用するをご覧ください。
LookupContext API を使用して事前フォーマットされたコンテキストを取得する
カスタム AI パイプラインと LLM アプリケーションの場合、Knowledge Catalog は LookupContext API メソッド(projects/<var>PROJECT_ID</var>/locations/<var>LOCATION</var>:lookupContext)を提供します。
LookupContext メソッドは、エージェントがスキーマの検査、用語集の用語の検索、データ品質スコアの取得、クエリログの検査を行うために複数の連続した呼び出しを行う必要がないように、1 回のリクエストでリッチ メタデータの統合された事前フォーマット済みのバンドルを取得します。
LookupContext メソッドの主な機能は次のとおりです。
- LLM 対応の形式。
yaml(デフォルト)、json、xmlとしてフォーマットされたコンテキストを返します。これは、LLM システム プロンプトに直接挿入するように設計されています。 - トークン予算(
context_budget)。目標文字予算を指定できます。API は、モデルのコンテキスト ウィンドウに収まるように、メタデータをインテリジェントに切り捨てて優先順位を付けます。 - 構成可能なコンテキスト ビュー。
- BASIC。基本的なエントリのメタデータ、スキーマ、列の説明、概要テキスト、エージェントのガイドラインを返します。
- 標準。基本的なメタデータに加えて、コンテキスト グラフをトラバースして、複数テーブルの結合関係、関連付けられたビジネス用語集の用語と同義語、ランタイムの使用パターン、検証済みのサンプルクエリを含めます。
- 運用と使用状況に関する豊富なシグナル。クエリ履歴から抽出された詳細な使用状況の統計情報(
partitionBy、clusterBy、topReadFields、topFilterFields、topGroupByFields、topSortFields、topAggregationsなど)を返します。 - 検出された結合とゴールデン クエリ。推測されたテーブル結合条件(
orders.customer_id = customers.idなど)と検証済みの SQL クエリの例が含まれます。
詳細については、データアセットのコンテキストを取得すると lookupContext REST リファレンスをご覧ください。
コンテキストがエンドユーザーと AI エージェントにどのように役立つか
Knowledge Catalog は、技術スキーマ、ビジネス セマンティクス、データリネージ、品質指標をアクティブなコンテキスト レイヤに統合することで、エージェント データクラウド内で普遍的なコンテキストを提供します。このメタデータを Model Context Protocol(MCP)、コンテキスト取得 API、セマンティック検索などのオープン インターフェースを介して公開することで、Knowledge Catalog はユーザーと自律型システムの両方を支援します。
ユーザーの手動による信頼作業をなくす
一元化されたセマンティック レイヤがない場合、基本的なビジネス上の質問に答えるには、データベースの系統とクエリ履歴を調査する必要があります。標準カタログはスキーマのパッシブ インベントリとして機能するため、指標の定義を手動で検索したり、テーブルのクリーンさを確認したりする必要があります。
Knowledge Catalog は、この受動的なガバナンスをアクティブなインテリジェンスに変換します。Knowledge Catalog では、データアセットとともに品質スコア、セマンティック記述、使用上の警告が直接表示されるため、エンジニアリング レビューを待つことなく、データを信頼して使用できます。
自律エージェントをグラウンディングし、動的ガバナンスを有効にする
AI エージェントと大規模言語モデル(LLM)は、データベースとやり取りするための厳格な決定論的ルールを必要とします。明示的なセマンティック コンテキストがないと、エージェントは列名について誤った想定をしたり、誤った SQL クエリを生成したりします。
また、アクティブ コンテキストにより、メタデータ管理がパッシブ レジストリからアクティブ ガバナンス レイヤに移行します。検証済みのビジネスルール、指標、エージェントの手順を Knowledge Catalog 内で直接定義することで、組織はエージェントが企業データを取得、評価、処理する方法を管理できます。
Knowledge Catalog は、このギャップを解消します。統合されたアクティブ コンテキスト プロファイルを、Model Context Protocol(MCP)や LookupContext API などの標準インターフェースを介して AI アプリケーションにエクスポートします。このメタデータに基づいてモデルをグラウンディングすると、ハルシネーションが最小限に抑えられ、ガバナンス ルールが適用され、自律的なアクションが検証済みの組織の真実に基づいて実行されるようになります。
共有コンテキストを使用してマルチエージェント ワークフローを調整する
マルチエージェント フレームワーク(またはスウォーム)では、個別の専門エージェントが連携して複雑なワークフローを実行します。これらのエージェントが共有コンテキスト プレーンのないサイロ化された環境で動作する場合、コンテキストの限界に直面します。競合するビジネスルールを使用したり、関連する依存関係を見つけられなかったり、取得作業が重複したりする可能性があります。
Knowledge Catalog を一元化されたコンテキスト レジストリとして使用すると、マルチエージェント スウォームを調整してスケーリングできます。Knowledge Catalog でスワームをグラウンディングすると、次のメリットがあります。
共有ビジネス セマンティクス。すべてのエージェントが同じビジネスの意味と定義を参照します。たとえば、データ分析エージェントとレポート エージェントの両方が売上高を含むテーブルを取得する場合、
Gross Merchandise Value (GMV)などの指標の同じ用語集定義を使用して、一貫性を確保します。動的依存関係の解決。エージェントは、データ リネージを使用して、アップストリーム リソースとダウンストリーム リソースをプログラムで検出できます。これにより、パイプラインのトラブルシューティング エージェントは、データ障害をソーステーブルまでトレースし、依存関係ルールをハードコードすることなく、修復エージェントにタスクを引き渡すことができます。
統合接続インターフェース。Model Context Protocol(MCP)を使用すると、単一のセマンティック エンドポイントがスウォーム全体に公開されます。これにより、個々のエージェントごとにカスタム API 統合を構成する必要がなくなります。
境界レベルのセキュリティ ガバナンス。Knowledge Catalog は、事前構成された IAM ロールに対してエージェント クエリをチェックします。これにより、エージェントが明示的にアクセスを許可されたリソース コンテキストのみを取得し、スワーム全体でデータ漏洩を防止できます。
データ コンテキストの使用例
データ コンテキストが複雑な問い合わせを解決する仕組みを理解するために、Knowledge Catalog が技術レイヤ、セマンティック レイヤ、運用レイヤを実際に適用する方法について考えてみましょう。
e コマース: 検索候補をパーソナライズする
季節のマーケティング キャンペーンを商品在庫と一致させるには、検索エージェントが、非構造化のプロモーション メールと構造化された商品カタログやユーザー トランザクション テーブルとの関係を理解する必要があります。Knowledge Catalog はこれらのエンティティをマッピングし、レコメンデーション モデルが関連商品をリアルタイムで提案できるようにします。
製造業: 機械のメンテナンスを最適化する
予測メンテナンス モデルでは、構造化された部品ログと構造化されていない技術者の修理ガイド、ライブセンサー フィードを統合する必要があります。部品番号とマニュアルの章の間の関係をマッピングすることで、Knowledge Catalog を使用して分析システムで機器の疲労を予測し、故障が発生する前に修理をスケジュールできます。
医療: 臨床試験データを検証する
臨床研究センターは、患者の統計情報が厳格な研究ルールに準拠していること、患者の同意記録が試験結果のデータセットに直接マッピングされていることを確認する必要があります。Knowledge Catalog は、列レベルのデータ リネージを追跡して同意パイプラインを監査し、データ プロファイル異常を研究者に警告することで、試験の完全性を維持します。
金融サービス: 信用リスクを評価する
ローン引受審査モデルでは、顧客のクレジット スコア、取引履歴、個別のソースシステムにわたるアクティブな債務残高が使用されます。Knowledge Catalog は、ローン指標の統合グラフを提供し、データリネージをマッピングします。これにより、引受審査ツールは、リスク評価で認定された準拠アセットが使用されていることを確認できます。
通信: ネットワーク運用を診断する
自律型ネットワーク管理システムとエージェントは、リアルタイムのシグナル動作を分析し、パフォーマンスの低下を検出し、自己修復の是正措置を適用します。これらのエージェントを Knowledge Catalog のコンテキストにグラウンディングすることで、システムはリネージ グラフを通じてネットワーク コンポーネントを安全にトレースし、技術ログとビジネス サービス領域間の関係をマッピングできます。
次のステップ
MCP を使用してエージェントをグラウンディングする
Model Context Protocol がエージェントを Knowledge Catalog のツールとリソースに接続する方法について説明します。
LookupContext でコンテキストを取得する
LLM プロンプト インジェクションを直接挿入するために、事前フォーマットされたトークン予算の YAML または JSON コンテキストを抽出します。