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