はじめに
こんにちは。DMM のデータサイエンスグループで検索レコメンドの PdM を務めている西潟一生です。
私たちの組織では，情報検索，推薦システム，自然言語処理，機械学習といった技術を駆使し，DMM の多角的な事業の売上に貢献するプロダクト開発を行っています。個人的なロールとしては，技術選定から事業価値の最大化，組織全体のディレクションまで，技術とビジネスの両面から最適解を模索する立場にあります。
今回，ラスベガスで開催された Google Cloud Next 2026 に参加してきました。本記事では，検索・レコメンドプロダクトに携わる視点から，特に注目したアップデートと今後の展望について共有します。
全体の所感
今回のカンファレンスを通じて最も強く感じたのは，AI エージェントによる開発効率の民主化でしょうか。
これまで，大規模なシステムを構築するには，膨大なエンジニアリソースと専門知識が不可欠でした。ここが大きな企業の優位性であると常々感じていましたが，今回発表された Workspace Intelligence や，会場の至る所で見かけた Gemini Enterprise Agent Platform を中心とする実用例を見て，小規模なチームやスタートアップであっても，初動からビッグテックと同等の開発効率と高度なナレッジ活用を手にできる時代が到来したと感じます。
カンファレンスそのものとしては，25年と同様の規模感だったかなと思いましたが，相変わらずの人の量と熱気でした。今年はなんとランチにスープが提供され，北米のライトなランチに華を添える食べ物が出現したことは素直に感動でした。
検索レコメンドにおける「Agentic」な進化と課題
今回のカンファレンスに限った話ではないですが，検索・レコメンド領域においても "Agentic" な処理の加速が顕著です。
検索・レコメンド系のセッションを見ると，従来，泥臭く行ってきた「辞書整備」「正規化」「クエリ理解」「ベクトル検索のチューニング」といった工程が，LLM によって吸収されつつあると感じました。
特にデータ（BigQuery）があり，どのようなクエリであってもそれなりの結果を返してくれるベクトル検索エンジンがクイックに立ち上げられるマネージドサービスにおいては，一番リードタイムがかかり，且つ難易度が高いタスクを LLM にこなしてもらうことは必然の流れでしょう。
吊るしのベクトル検索の網の粗さを LLM がカバーするアーキテクチャは理にかなっているとも思えますが，実務者の視点で見れば，大規模データに対して LLM がミリ秒単位でこれらの処理を捌き切るには，まだ技術的な壁があるとも感じています。現時点では，AI に丸投げするのではなく，依然として「愚直にクエリやベクトルと向き合い，チューニングを行う」というエンジニアリングこそが，大規模サービスの品質を担保する鍵であることは変わらないと感じました。
Vector Search 2.0 の DMM における立ち位置
2025年末ごろに Public Preview として登場した Vector Search 2.0 からもその傾向が見て取れます。 Vector Search 2.0 は 2026年3月5日に主要機能が GA となり，従来の ANN 中心のサービスから，より汎用的な検索・RAG 向けのデータストアへと進化しています。2.0 では Auto-embeddings により，指定したスキーマに基づいてベクトルフィールドを自動生成・管理できるようになり，開発者が埋め込み生成・保存・検索基盤の実装詳細から一定程度解放される方向に進んでいます。
セッションの中で Vector Search 2.0 が直接取り上げられることはなく（そういうセッションもあったのかもしれませんが，少なくとも私は出会いませんでした），このプロダクトが隠蔽できるほど各社サービスそのものに注力している証左だと思っています。
ちなみに，従来の Vector Search は，主に dense vector や sparse embedding を用いた近傍検索・ハイブリッド検索の色が強く，Elasticsearch のような全文検索エンジンとは役割が異なっていました。2.0 からは全文検索が可能となり，これと Dense Vector とのハイブリッド検索が可能になっています。これによって，Elasticsearch の大きな優位性は，個人的にはファセットや QAC，全文検索におけるチューニング周りだけになってきた印象があります。
このあたりも Elasticsearch との思想や歴史の違いを感じるところで，そもそも高度に意味を捉えられるエンジンであれば，ファセットのような絞り込みや，検索をアシストするような QAC の重要性は限定的であり，AI エージェントや RAG が必要なコンテキスト取得に寄せる方が投資対効果が高いという思想が見えてきます。
では，我々が Elasticsearch から Vector Search 2.0 に乗り換えるかというと，その可能性は常にゼロではないが，特定ドメインに対するチューニングが必要というラストワンマイルの壁が突破されない限りは Vector Search 2.0 はあくまで「PoC 用」という位置づけが妥当であると考えています。少なくとも現在の DMM の UI/UX を踏襲する必要性があるうちは，ファセットが高速に捌けないという1つの理由だけでも乗り換えることはないだろうと考えています。Vector Search 2.0 は「AI アプリケーションのための検索・RAG 基盤」としては非常に強力になった一方，EC やコンテンツ検索の UI/UX を細かく作り込む検索エンジンとしては，Elasticsearch とはまだ得意領域が異なると感じました。
ただし，中長期的には Google Cloud が巨大な検索データストアになるだろうこと，Embedding モデルが今以上に精度向上し，LLM が今以上に高速になって，マネージドな金銭的コストが下がればその限りではないだろうという予感もしています。
その点では，我々はますますどのようなサービスを作るべきかという，プロダクトではなく，ユーザーと向き合う時間が大切になると感じました。
Knowledge Catalog
Keynote で発表された Knowledge Catalog（前身の Dataplex Universal Catalog からの進化）は AI 時代に合わせて更にブラッシュアップしたものだろうと認識しています。
これまでの Dataplex は，メタデータ管理，リネージ，データ品質，プロファイリングなどを担うガバナンス基盤でした。ただし，その文脈付けや業務的な意味づけは，人間による定義や運用に依存する部分が大きかったと理解しています。
Knowledge Catalog 利用のメリットは，Gemini が自動でデータの意味を推論し，構造化する点にあります。
例えば，BigQuery に title と price というカラムを持つテーブルがあったとします。
Knowledge Catalog と連携すると，Gemini が「title は商品名であり，price は販売価格である」といった意味を推論し，データセットやカラムの説明，関係性，例示クエリなどのコンテキストとして活用できるようになる，といった具合です。また，BQ に投入されたデータやスキーマ，利用履歴から，データセットやカラム説明，テーブル間の関係，例示クエリのようなメタデータを自動生成できる点も重要です。
ただし，これによって検索レコメンド用のメタデータ生成パイプラインが直ちに不要になるわけではありません。商品・作品・ユーザー行動に対するドメイン固有の特徴量生成や正規化は引き続き必要であり，Knowledge Catalog はそれらを置き換えるというより，社内データの意味・所在・品質を AI エージェントや人間が理解しやすくする基盤と捉えるのがよさそうです。
一方で，メタデータ自動生成装置として Knowledge Catalog を見た時には，既にその仕組みがある我々にとっては，直近あまり必要のないプロダクトではありますが，ポイントは Knowledge Catalog が Google Cloud 利用者全体で統合的に扱えるようになっていることなので，パイプラインの結果が我々しかアクセスできないような場所に置かれていたり，逆に他の部署が我々の預かり知らぬところでデータを持っているような時に，効果が最大化するだろうと思っています。
我々のような様々な事業が相互的にシナジーを生むような事業においては，まさに Knowledge Catalog のようなプロダクトがデータのコンテクストを補完して，効果を最大化させるだろうと考えられますし，検索レコメンドに限って述べても，DMM 全体のデータをより広く扱え，1つ1つのデータの意味・品質・関係性が継続的に整理され，AI エージェントや人間が信頼できるコンテキストとして参照できる状態は，精度にも大きく貢献できるポテンシャルがあると感じています。
今後の展望：データのエンリッチメント化
本カンファレンスで提示された "Agentic Data Cloud" という構想は，データ基盤そのものが検索・レコメンドのエンジンへと融合していく世界観を示していると感じています。
我々は改めて以下の方向で邁進していくことで間違いなさそうだという感覚を得ています。
- セマンティックレイヤーの充実: Knowledge Catalog を活用し，社内の多様なデータを「検索レコメンドが即座に，正確に扱える」状態にエンリッチメント化。
- 「説明可能な推薦」の高度化: データが網羅的に観察可能になることで，「なぜこのコンテンツを推薦したのか」の根拠をよりリッチに示すことの加速。
- データホルダーとしてのアドバンテージ: AI が進化するほど，自社で持つ「固有のデータ」の価値が高まる。このデータを速く，深く AI に学習・グラウンディングさせることの加速。
まとめ
本カンファレンスでは，AI によって「持たざる者」が「持てる者」に追いつく手段を提供した一方で，大規模サービスにおいては依然として「データの量と質」と「専門的なチューニング」が勝負を決めることを再認識させてくれました。
1サービスが立ち上がる速度が異常なほどまで高まった影響で，今後のカンファレンスは個別機能の GA/Preview といったステータス変更よりも，どのようなサービスが立ち上がったのか，サービスがどのように進化したのかといったところにますますフォーカスし，機能そのものも隠蔽，抽象化されていくだろうと感じました。
DMM の検索・レコメンドも，最先端の恩恵を賢く享受しつつ，地に足の着いたエンジニアリングを追求していきます。
余談
ラスベガスでは，2026年4月現在，Amazon 傘下の Zoox の無人タクシーがトライアル中で，無料で乗れます。乗り降りできる場所はかなり限られていますが，既存車両をベースとした Waymo や Tesla の車両とは違って，無人タクシー専用の形をしているので，乗り降りがしやすく，見た目も可愛く親しみやすいことから，短距離の移動ならばこちらの方が良いかもと思いましたし，大変便利でした。
日本在住の方が現地で Zoox のアプリをダウンロードするには少しコツがいるのですが，一度アプリが使えれば後は簡単です。
実際，道をよく間違え，何度も遠回りすることもあったところから，正直なところ運転に関しては Waymo や Tesla ほどの完成度はないように思えましたが，危なっかしさは全くなく，Zoox の中で寝たり，スマホを触り続けたりするくらい，安心感がありました。日本の過疎地で，すれ違いができないほどの細い路地ほど Zoox の小さくて小回りが効く車体が有効だと感じました。
DMM のデータサイエンスグループでは，事業貢献するための検索レコメンドの KPI 設計や事業戦略の Meetup を不定期開催しています。是非ご参加ください。
2026年5月25日（月）開催予定
Strategic Search & Recommendation Meetup #4
Discussion