こんにちは。SCSK山口です。
近年、生成AIやAIエージェントの業務適用が急速に進む中、多くの企業が最初につまずくのが「データ基盤のAI Ready化（AIが理解・活用できる状態への整備）」です。
そこで役立つのが、先日のGoogle Cloud Next ’26でも発表された「Knowledge Catalog」です。
本記事では、Dataplex、DataCatalogから進化を遂げ、AI時代のコンテキストエンジンとしてリブランドされた「Knowledge Catalog」の概要、利点、推測される現場の疑問について解説します。
Knowledge Catalog（ナレッジカタログ）とは？
Knowledge Catalogは、Google Cloudのデータガバナンスプラットフォームです。従来の「Data Catalog」および「Dataplex」が、生成AI時代のコンテキストエンジンとして進化・統合されました。
下記の3つの基本的な柱で構成されています。（※ 2026 年 4 月 23 日時点）
集約
Knowledge Catalogは、散在するデータアセット全体のコンテキストを統合・集約する基盤です。
-
幅広いメタデータの集約 (GA): Google Cloud基盤システムやサードパーティ・パートナーカタログから、技術的・レガシーなメタデータを自動収集します。
-
エンタープライズ接続 (プレビュー): SAPやSalesforceなどの主要な業務システムと相互接続し、セマンティックコンテキストを迅速に可視化します。
-
LookML エージェント: 戦略ドキュメントを自律的に読み取ってセマンティクスを自動生成し、企業全体で共通のビジネスロジックを連携させます。
-
BigQuery measures (プレビュー版): SQLエンジンにビジネスロジックを直接組み込んで再利用を可能にし、LookMLと共にセマンティック基盤へ一元化します。
-
データ プロダクト (GA): インテントやSLA、ガバナンス制約を組み込んだアセットをパッケージ化し、複雑なAIユースケースのスケールを支えます。
拡充
Knowledge Catalogは、継続的な能動的分析と学習を通じて、データの意味や関係性を自動で拡充・生成する基盤です。
-
スマート ストレージおよびオブジェクト コンテキスト API (プレビュー版): GCSに保存されたファイルを自動でタグ付け・メタデータ拡充し、エージェントによる非構造化データの即時発見を可能にします。
-
高度なマルチモーダル メタデータ抽出 (プレビュー): Geminiとのネイティブ統合により、複雑な非構造化データからビジネス情報を特定し、エンティティ抽出や関係性マッピングのパイプラインを自動構築します。
-
コンテキストの自動キュレーション (プレビュー): データセットや検証済みSQLパターンに対し、ビジネス用語集を含む自然言語の説明を自動生成し、データとビジネスの関連性を示す動的マップを構築します。
-
検証済みのクエリとセマンティック ガードレール (プレビュー): ハルシネーションによる誤ったロジックや推測に基づくSQL結合を防ぐため、検証済みのSQLパターンと事前生成された自然言語の質問を提供します。
検索
Knowledge Catalogは、エージェントが迅速かつ安全にデータを探索・取得できるよう、高精度でセキュリティに対応した検索基盤を提供します。
-
高精度セマンティック検索 (GA): Google検索と同等のML技術やクエリ書き換え技術を活用し、エージェントが必要とする1秒未満の低レイテンシと的確な関連性でコンテキストを即座にランク付けして返します。
-
アクセス制御対応の検索: ソースシステムで定義されたアクセス権限を尊重したグローバル検索を行い、エージェントが閲覧を許可されたアセットのみを取得・操作させることでハルシネーションを防ぎます。
-
測定可能なコンテキスト評価: 堅牢な評価フレームワークにより、チームが多様なコンテキスト構築戦略を定量的に検証・改善できるようにし、提供するコンテキストの関連性と質を継続的に最適化します。
-
Gemini Enterprise の Deep Research エージェント (プレビュー版): カタログにネイティブ対応した本エージェントは、ビジネスデータや社内ドキュメント、Web調査を統合し、詳細な引用を伴う高精度な回答を数分で実行します。
要約すると、
なぜ今必要か？既存顧客のギャップを埋める2つの利点
ここからは、私が感じたKnowledge Catalogの必要性・利点について書きます。
利点①：AI Readyな基盤設計がない既存環境の「救世主」に
データウェアハウス（DWH）やデータレイクを構築した当時、数年後に「生成AIにデータを読み込ませる」ことまで想定してスキーマやカラム名、ドキュメントを設計できていた企業はごく僅かかと思います。
それどどころか、同じコンテキストを持つ別名のスキーマ・カラム名が付与されているケースも少なくなく、これによってそのままAIにプロンプトを投げても、的外れな回答（ハルシネーション）の連発や、結合（JOIN）エラーを起こす事態が発生します。
Knowledge Catalogは、こういったデータ間の「ギャップを埋める架け橋」になります。Geminiがクエリログや既存スキーマからコンテキストやビジネスインテント（意図）を推測し、自然言語のビジネス用語集や、AIの手本となる「ゴールデンクエリ（お手本）」を自動生成してくれます。既存の基盤を大規模改修せずとも、AI Readyな環境の整備が可能です。
さらに、上記のような作業を手動ではなく、自動的に学習・生成し、カタログを「自動拡充」してくれます。
利点②：顧客接点の高度化（データのセマンティック理解をAIに任せる）
エンドユーザーや社内オペレーター向けのAIエージェント（接点高度化）を開発する際、開発者が「このデータとこのデータはこういうビジネスロジックで繋がっている」と、IF-THENルールを大量にコードへ組み込む必要はありません。
Knowledge Catalogによって構築されたセマンティックレイヤ（意味の階層）をAIエージェントに参照させることで、「データの文脈理解そのものをAIに委ねる」ことが可能になります。これにより、顧客からの複雑な自然言語の問い合わせ（例：「先月一番リピート率が高かった商品の在庫は？」）に対して、AI自身が「リピート率の定義」と「在庫テーブル」を正しく紐付け、正確な回答を出力できるようになります。
Knowledge Catalogに関する「3つの疑問」とアンサー
実際の提案や設計の現場で想定される（私が実際に感じた）疑問について解説します。
まだ公式のドキュメントがない部分が多々あるので、一部Geminiの手を借りて、現段階の私なりのアンサーを作ってみました。
Q1. 最初からAI Readyに設計されたBigQueryと比べて、処理コストや速度に違いはある？
アンサー：クエリ実行時の「速度」はほぼ変わりません。「AIの思考コスト（リトライ減少によるコスト最適化）」において、Knowledge Catalogを挟む明確なメリットがあります。
- 処理速度（パフォーマンス）: Knowledge Catalogはメタデータとセマンティックの管理レイヤです。AI（Gemini in BigQueryなど）が実際にSQLを発行してBigQueryを叩く際のスキャン速度自体は、テーブル設計（パーティショニングやクラスタリング）に依存します。そのため、生データの物理配置が最適化されている「最初からAI Readyな環境」の方が純粋なクエリ速度は有利です。
- 処理コストと「AIの打率」: テーブル設計が不十分な環境でAIに直接クエリを組み立てさせると、AIがスキーマを誤認して「巨大なテーブルをフルスキャンする無駄なクエリ」を投げたり、エラーになってリトライ（再考）を繰り返したりして、LLMのトークンコストやBigQueryのコンピュートコストが跳ね上がります。Knowledge Catalogが「検証済みのSQLパターン（ゴールデンクエリ）」をインプットとしてAIに提供することで、AIが一発で最適化されたクエリを書けるようになり、結果的にトータルの処理コストを低く抑えることができます。
Q2. 「スモールスタート」が推奨される？
アンサー：大いに推奨されます。むしろ、スモールスタートで始めなければ破綻します。
全社のデータを一気にカタログ化しようとすると、メタデータスキャンやデータプロファイリングの初期コストが膨らむだけでなく、ビジネス用語の整合性を取るフェーズでプロジェクトがスタックします。
まずは「特定のユースケース（例：カスタマーサクセス部門のFAQ対応AI、特定のマーケティングマート）」にスコープを絞り、対象のBigQueryデータセットやCloud StorageのバケットだけをKnowledge Catalogに接続して効果を検証するアプローチがベストプラティスになりそうです。
Q3. 業務・業界のセマンティックを理解するために必要なデータ量は？精度を上げる基盤設計のコツは？
アンサー：必要なのは「データの量（Volume）」よりも「メタデータの質とログ（Context）」です。基盤設計段階では「クエリログの残存」と「Looker/LookMLの活用」が鍵になります。
- データ量と精度の関係: Knowledge Catalogがセマンティック（意味論）を理解する際、テーブルのレコード数（100万行あるか、1億行あるか）はあまり重要ではありません。重視されるのは「スキーマの構造」「データプロファイリング（どのような値が入っているかの傾向）」、そして何より「過去に人間が流したクエリログ（どのテーブルとどのテーブルがどう結合されているか）」です。ログのバリエーションや期間が多いほど、Geminiは「この企業における『売上』の定義はどのカラムを指すのか」を高い精度で推測できるようになります。
- 精度を上げるために基盤設計段階から意識すべきこと:
- クエリログを蓄積・維持する: BigQueryの
INFORMATION_SCHEMA.JOBS_BY_*などのクエリ履歴を適切に保持し、Knowledge Catalogがスキャンできるように権限を設計しておくこと。 - Looker（LookML）との統合: Knowledge CatalogはLookerのセマンティックモデル（LookML）と深く統合されています。すでにLookerでビジネスロジック（指標の定義など）を定義している場合は、それをカタログにインポートすることで、AIエージェントへの意味付けの精度向上が期待できます。
- クエリログを蓄積・維持する: BigQueryの
まとめ
既存のデータ基盤がAI Readyでない状態だからといって、AI活用を諦める必要はありません。Knowledge Catalogを導入することで、既存資産を活かしたまま、AIエージェントが自律的に社内データを探索・活用できる「AI Ready」な環境へと進化させることが可能になります。
まずは、社内で最もデータ活用が進んでいるクローズドな環境から、ナレッジカタログのコンテキストグラフ構築を試してみてはいかがでしょうか。