G-gen の奥田です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 CDP だけで顧客理解は不十分？Google Cloud と生活者データで実現する「Why 分析」最前線 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 データはあるのに顧客が見えない データの量ではなく種類が足りない 再発する 5 つの症状 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 勘と経験がもつ 3 つの限界 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは ID 突合ではなく確率的な意味マッチング 処理の 4 ステップ 既存テーブルを変更せずに列が増える Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH 発見 2: Gemini による出力品質の独立検査 発見 3: 承認済みルーティンによる双方の資産保護 Why 分析の先にあるもの AI の均質化とブランドらしさ 業種を越えた共通フレームワークへ 関連記事 セッションの概要 当セッションでは、株式会社博報堂による発表が行われました。CDP（Customer Data Platform、顧客データを個人単位で統合管理する基盤）だけでは捉えられない「顧客が行動した理由（Why）」を、生活者データと BigQuery の機能を組み合わせて補完する手法が紹介されました。 セッションは以下の 5 章で構成されていました。 データはあるのに顧客が見えない Why を補ってきた「勘と経験」の正体 生活者データという「Why の辞書」と Why 分析の方法 Google Cloud だから実現できた 3 つの発見 Why 分析の先にあるもの 当記事では BigQuery の基礎的な説明は割愛します。BigQuery そのものについては、以下の記事を参照してください。 blog.g-gen.co.jp データはあるのに顧客が見えない データの量ではなく種類が足りない セッション前半では、多くの企業が直面する課題として「データ量は十分にあるが、データの種類が足りていない」という点が提示されました。 CDP に記録されるのは、会員属性、購買履歴、行動ログ、解約記録といった「What（結果）」のデータです。一方、価値観、生活文脈、意思決定の傾向、不安や願望といった「Why（原因）」は、CDP のどこにも記録されません。登壇者はこれを氷山にたとえ、水面上に見えるのが What、水面下に隠れているのが Why であると説明しました。 たとえば「妥協して選んだ」という本音は、購買履歴という結果データからは読み取れません。同じ商品を買った顧客でも、買った理由は三者三様です。 再発する 5 つの症状 この構造的な欠落が原因となり、データを精緻化しても再発する症状として、以下の 5 つが挙げられました。 セグメントの画一化 メッセージの一律化 LTV（Life Time Value、顧客生涯価値）向上の頭打ち 静かな離反の見落とし 新規獲得の非効率 登壇者は、CDP や CRM（Customer Relationship Management、顧客関係管理システム）の整備自体は不可欠な土台であり、ID 統合、行動ログの蓄積、施策の自動化という期待された役割は果たしていると強調しました。問題は、CDP だけではカバーできない領域（なぜ買ったのか、なぜ離れたのか、なぜ選んだのか）が存在することです。 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 これまで Why の欠落を埋めてきたのは、マーケターの「勘と経験」でした。セッションでは、その正体は「5W1H を同時に読む力」であると定義されました。 ベテランマーケターは、Who（どんな生活状況か）、When（いま何が起きそうか）、Where（どこで接点を持つか）、Why（なぜその選択か）、How（どう情報収集し選ぶか）を、過去事例の蓄積による暗黙のパターンマッチで同時に推論しています。たとえば「40 代男性が SUV を購入した」という購買データから、「家族の安全を重視する層である」と言い当てる、といった推論です。 勘と経験がもつ 3 つの限界 一方で、この勘と経験には 3 つの構造的な限界があると指摘されました。 スケールしない: 顧客一人ひとりに勘と経験を働かせるのは物理的に不可能 引き継げない: ベテランの退職は「顧客理解資産」の消失を意味する 共有できない: 「なんとなく刺さる」という判断では合意形成が属人的になる 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは この課題に対する解決策として、博報堂が保有する生活者データを「Why の辞書」として使用し、マーケターの脳内プロセスを機械化する手法が紹介されました。材料となるのは、圧倒的な量の Why の語彙と、生活者インサイト（購買行動の背後にある価値観や動機）を推論する技術の 2 つです。 博報堂独自の観点として、価値観、動機、幸福感といった軸（たとえば購入時の価値観として、価格、幸せ、機能性など）が生活者データの中で 5W1H により体系化されています。 ID 突合ではなく確率的な意味マッチング 特徴的なのは、顧客データと生活者データを ID 突合（異なるデータベース間で共通の ID をキーにレコードを結合すること）ではなく「確率的な意味マッチング」で接続する点です。これにより以下の 3 点が実現されます。 個人を特定しない 既存の CDP をそのまま使用できる Cookie 規制（サードパーティ Cookie によるトラッキングの制限）の影響を受けにくい 処理の 4 ステップ 処理は以下の 4 ステップで構成されます。 翻訳: 企業ごとに異なる顧客 CDP の項目を、生活者データの共通言語にマッピングする 数値化: 顧客データと生活者データを「意味の座標」上に配置し、意味の近さを距離として比較できるようにする 検索: 生活者データの中から、意味的に最も近い人を選ぶ 特徴付与: 生活者データに近い特徴を顧客データにも付与する 既存テーブルを変更せずに列が増える この手法の利点は、既存の顧客テーブルを変更する必要がないことです。顧客 ID、属性、購買金額といった従来の列はそのままに、以下のような生活者インサイトの列が追加されます。 価値観（なぜ買うのか。指名買い、コスパ重視など） 意思決定傾向（どう選ぶのか。SNS 影響、即決型など） ライフスタイル（どう生きるのか。都市型ライフ、子育て重視など） 既存の顧客データ基盤が、そのまま顧客理解基盤へ進化するという表現が用いられました。 Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 博報堂独自の生活者データを AI 時代に使用するには 3 つの条件が必要であり、Google Cloud はそのすべてを満たすと説明されました。 意味の近さを計算できる BigQuery が標準機能としてベクトル検索（テキストなどを数値ベクトルに変換し、意味の近さで検索する仕組み）を備えています。 マーケターが直接触れる SQL やダッシュボードで完結し、ノーコードまたはローコードで操作できるため、マーケター自身が仮説をすぐ検証できます。 データを動かさない 顧客データは企業環境から一切出さず、顧客環境内で処理が完結します。 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH セッション後半では、実運用から得られた発見として次の3点が紹介されました。1 つ目は、マーケターの直感を SQL で再現できたことです。「この人は、こんな価値観の人と似ているな」というベテランマーケターの頭の中の処理は、これまで言語化も再現もできない暗黙知でした。この処理を、BigQuery の標準機能である VECTOR_SEARCH 関数への変換（SQL Translation）によって再現しています。 これにより「意味の近さ」が可視化され、感覚でしかなかった判断を数字として表現できるようになりました。 参考 : ベクトル検索の概要 発見 2: Gemini による出力品質の独立検査 2 つ目は、出力品質を Gemini で独立検査する仕組みです。付与されたインサイトが施策の判断材料になる以上、品質に責任を持つ必要があります。人間による品質検査には量的な限界があるため、Gemini による5観点の独立評価を、品質保証レイヤーとして組み込んでいます。これは LLM ジャッジ（Large Language Model による評価）と呼ばれる、大規模言語モデルに出力の良し悪しを判定させる手法です。5 観点は以下のとおりです。 一貫性: 矛盾するタグがないか 妥当性: その人らしいか 網羅性: 必要な観点があるか 不足検出: タグの抜けはないか 実用性: マーケティング施策に使えるか 発見 3: 承認済みルーティンによる双方の資産保護 3 つ目は、データを守りながらロジックも守る仕組みです。顧客データは企業環境から一切出さない一方で、博報堂の推論ロジックも公開しません。この双方の資産保護を、BigQuery の承認済みルーティン（Authorized Routine）で実現しています。承認済みルーティンは、呼び出し元に定義内容を開示せず、実行権限のみを付与できる機能です。 参考 : 承認済みルーティン Why 分析の先にあるもの AI の均質化とブランドらしさ 最終章では、AI エージェントが購買の意思決定を担う時代の展望が語られました。購買が AI エージェント経由になるほど、効率最適化により「どのブランドも同じ答え」に収束するリスク（AI の均質化）があります。 エージェントが最適解を出す時代では、生活者の「なぜ（Why）」への深い理解こそがブランドらしさの源泉であり、ブランドに求められるのは最適化ではなく「選ばれる理由」を持ち続けることである、と締めくくられました。 業種を越えた共通フレームワークへ また、この設計様式は博報堂だけの話ではない、という点も強調されました。ID 突合に依存しないポストクッキー時代（サードパーティ Cookie が使えなくなる時代）のマーケティング手法として、また「データを動かさず、処理を動かす」という厳格なデータガバナンス下で AI 利用を進めるための共通フレームワークとして、規制業界を含むデータを持つすべての企業に波及していくという展望が示されました。対象業種の例として、小売、金融、通信、旅行、メディアが挙げられました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

G-gen の今村です。当記事は、Google Cloud Next Tokyo 26 の2日目に行われた Google セッション「 Gemini Enterprise Agent Platform 入門！進化した次世代エージェント構築基盤の全貌 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Gemini Enterprise Agent Platform とは サービス提供の背景 機能の全体像 Build（構築） 概要 Model Garden Agent Studio Agent Development Kit その他の開発ツール Scale（スケーリング） 概要 Agent Runtime Agent Sandbox Session と Memory Bank Govern（管理） 概要 Agent Registry Agent Gateway Agent Identity Governance Policies Optimize（最適化） 概要 OpenTelemetry Agent Observability Traces と Tool Usage Evaluation（評価） 概要 評価アプローチ オフライン評価とオンラインモニタリング まとめ 関連記事 セッションの概要 当セッションでは、Google Cloud における次世代の AI エージェント構築基盤である Gemini Enterprise Agent Platform の全体像や各機能レイヤー、および主要な機能群についての発表と解説が行われました。 当セッションは、Google Cloud の AI 技術統括本部 アプライド AI エンジニアである牧氏によって行われました。 Gemini Enterprise Agent Platform とは サービス提供の背景 企業で AI エージェントを構築し使用する際、開発者と使用部門の間で溝が生じるケースがあります。例えば「特定部門のために開発されたエージェントが使われない」「想定した業務用途に合致しない」といった課題です。 AI エージェント導入のハードル Gemini Enterprise Agent Platform は、このような課題を解消する目的で提供されました。開発者と使用者の双方にとっての使いやすさを追求し、エンタープライズ要件に応えるエージェントプラットフォームとして設計されています。 参考 : Agent Platform の概要 Gemini Enterprise Agent Platform の立ち位置 Gemini Enterprise Agent Platform の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 機能の全体像 Gemini Enterprise Agent Platform は、あらゆるシナリオに対応可能なオープンで包括的な基盤として位置づけられています。 機能は大きく分けて4つのレイヤーで構成されています。 Build （構築） Scale （スケーリング） Govern （管理） Optimize （最適化） また、これら4つのレイヤーによるライフサイクル運用に加え、デプロイ前後におけるエージェントの品質や応答精度を担保するための Evaluation （評価）アプローチを組み合わせて使用します。 参考 : Agent Platform の概要 - Gemini Enterprise Agent Platform のコンポーネント 4つのレイヤー Build（構築） 概要 Build（構築）レイヤーは、AI エージェントの迅速な開発と検証を支える仕組みです。多様な技術スタックや開発手法に対応できるよう、オープンソースのフレームワーク、最先端のモデル、およびローコードからハイコードまでの開発環境を選択できます。開発者のスキルセットやプロジェクトの要件に応じた柔軟な開発を可能にします。 参考 : Agent Platform の概要 - 構築 Gemini Enterprise Agent Platform を使用する理由 Model Garden Model Garden を通じて、Google の最新 Gemini モデルをはじめ、サードパーティ製のモデルやオープンモデルなどを柔軟に選択して使用できます。 参考 : Model Garden の概要 Model Garden Agent Studio Agent Studio は、コンソール画面（GUI）から直感的にエージェントを作成する機能です。 Python などのプログラミング知識がない場合でも、自然言語でディスクリプションやインストラクション（動作指示）を記述するだけでエージェントを構築できます。Google 検索ツールとの連携や、作成したエージェントのテストからデプロイまでを同一画面内で完結できます。 参考 : Agent Studio の概要 AI エージェント開発の選択肢 Agent Development Kit Agent Development Kit （以下、ADK）は、さまざまなプログラミング言語に対応したオープンソースのフレームワークです。 学習コストを抑えつつ、Google Cloud 上でオープン性を重視したエージェント開発が可能です。 参考 : Agent Development Kit Agent Development Kit その他の開発ツール コードファーストでの開発や自動化を支援するため、以下のツールが用意されています。 Agents CLI コマンドラインからエージェントのライフサイクル管理や Skills の実行を行うツールです。 参考 : Agent Platform で ADK と Agents CLI を使用してエージェントを構築する Agents CLI Antigravity エージェントと会話しながらコーディングを進められる開発・自動化プラットフォームです。 参考 : Google Antigravity Antigravity Managed Agents API セキュアなサンドボックス環境からエージェントを直接呼び出すための API です。 参考 : Agent Platform の Managed Agents API の概要 Managed Agents CLI Scale（スケーリング） 概要 Scale（スケーリング）レイヤーは、ローカル環境で作成されたエージェントを全社規模の運用へ適応させるための基盤です。サーバーレスなデプロイ環境やセキュアなサンドボックスにより、トラフィック負荷に耐えうるインフラの自動スケーリングを実現します。また、高度なコンテキスト（会話履歴や記憶）管理機能を備えています。 参考 : Agent Platform の概要 - スケーリング Scale の概要 Agent Runtime Agent Runtime は、エージェントのインスタンスをサーバーレス環境にデプロイし、自動スケーリングや運用管理を担う機能です。ノーコードで作成されたエージェントと、コードベースの複雑なエージェントまで幅広く対応します。呼び出しプロセスやパラメータを一元的に可視化・追跡できるため、組織内で把握されない「野良エージェント」の乱立リスクを抑えられます。 参考 : エージェント ランタイム Agent Runtime の概要 Agent Runtime の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Sandbox Agent Sandbox を使用することで、セキュアでカスタマイズ可能な実行環境を用意できます。GUI ベースの自動化ワークフローなどを安全に検証・実行できます。 参考 : サンドボックスの概要 Agent Sandbox の概要 Session と Memory Bank 業務でエージェントを使用する場合、1回の応答で処理が完了することは少なく、会話のコンテキスト保持が重要となります。 Session （セッション）と Memory bank （メモリーバンク）機能により、短期記憶と長期記憶を、それぞれフルマネージドなデータストアに保存できます。ユーザーごとの参照データや属性情報を考慮した、柔軟な応答を実現します。 参考 : Agent Platform セッションの概要 参考 : Agent Platform メモリバンク Session と Memory Bank Govern（管理） 概要 Govern（管理）レイヤーは、エンタープライズに要求されるセキュリティ、コンプライアンス、ID 管理を一括制御する層です。管理用レジストリやセキュリティポリシーを適用し、情報漏洩や不正アクセスのリスクを極小化しながら、組織全体での安全なエージェント使用を統制します。 参考 : Agent Platform の概要 - 管理 ガバナンスを遵守するための全体アーキテクチャ Agent Registry Agent Registry は、デプロイ前のコアエージェントや Model Context Protocol（以下、MCP）サーバーを一元管理する機能です。サードパーティ製コンポーネントの登録にも対応しており、不正なエージェントやコストが高騰している設定を一覧画面から早期に識別できます。 参考 : Agent Registry Agent Registry の概要 Agent Registry の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Gateway Agent Gateway は、外部システムや社内サービスからのトラフィックを集約・管理するエンドポイントです。トラフィックの入り口を統一することで、リソース制御や認証管理を効率化できます。 参考 : Agent Gateway の概要 Agent Gateway の概要 Agent Gateway の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、エージェントに対してセキュアで一意な識別子（ID）を付与・管理する機能です。部署をまたいだデータ参照を行う際も、定義されたアクセス制御に基づいて情報資産を守ります。 参考 : エージェント ID の概要 Agent Identity の概要 Agent Identity の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Governance Policies Governance Policies は、Google Cloud の Identity and Access Management（以下、IAM）の権限体系と連携して動作する制御機能です。Agent Runtime 等にホストされたエージェントへのアクセス権限は、Agent Gateway を通じて、Governance Policies により制御されます。 参考 : ポリシーの概要 Governance Policies の概要 Google Cloud の IAM については、以下の記事を参照してください。 blog.g-gen.co.jp 本セッションのデモでは、住宅ローン審査のアシスタントエージェントが例として挙げられました。個人情報を含むメールを外部送信しようとした際、権限不足により不許可となる挙動が確認できました。環境内では Model Armor 等のセキュリティ機能と組み合わせ、システム的に個人情報をブロックする設計が施されています。 参考 : Model Armor の概要 Governance Policies の使用例 Model Armor の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Optimize（最適化） 概要 Optimize（最適化）レイヤーは、本番環境で稼働する AI エージェントの運用コスト、パフォーマンス、および応答の正確性を計測・制御するための層です。トレースやログ分析を通じて、不要なモデル呼び出しによるコストの抑制や、レイテンシ障害の迅速な検知・解析が可能です。 参考 : Agent Platform の概要 - 最適化 OpenTelemetry オープンな標準規格である OpenTelemetry に準拠しており、世界基準に則ったテレメトリーデータ収集を実装できます。 参考 : OpenTelemetry とは OpenTelemetry の概要 Agent Observability Agent Observability は、Cloud Logging や Cloud Storage へ各種運用データを保存し、モニタリングを行う機能です。短文要約のような簡易タスクに対して、オーバースペックな高コストモデルが呼び出されていないかなどを可視化・管理します。 参考 : オブザーバビリティの概要 参考 : Cloud Logging の概要 参考 : Cloud Storage のプロダクト概要 Agent Observability の概要 Cloud Logging の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Cloud Storage の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Traces と Tool Usage Traces 機能により、処理のボトルネックやアクセススパイクを分析できます。併せて、呼び出されたツールやモデルを Tool Usage 画面で確認し、想定外の動作が発生していないかを検証可能です。 参考 : エージェントのトレースを表示する Traces の概要 Traces の Tool Usage 機能 Evaluation（評価） 概要 Evaluation は、エージェントが出力する回答の正確性や定義した業務フローの遵守状況を、客観的・定量的に分析するための仕組みです。テスト段階の事前評価と運用中のリアルタイム監視を組み合わせることで、ハルシネーション（誤回答）や品質の低下を未然に防ぎます。 参考 : エージェントの評価 エージェントの成功指標を計測 評価アプローチ エージェントの出力品質を定量化するため、主に以下の3つのアプローチを組み合わせて検証を行います。 ルールベース評価 あらかじめ定義した制約ルール（必須キーワードや指定の出力フォーマットなど）に適合しているかを自動判定します。 LLM-as-Judge 評価 評価用として調整された大規模言語モデル（LLM）を判定者として用い、回答文の定性的な妥当性や文脈の論理性を自動スコアリングします。 適応型（Adaptive Rubrics）評価 評価基準（ルーブリック）を段階的に配置し、特定の処理ステップごとに期待されたビジネスロジックに従っているかを動的に評価します。 評価アプローチ 適応型ルーブリック オフライン評価とオンラインモニタリング 評価の実行環境として、デプロイ前後に最適化された以下の機能が備わっています。 GenAI Evaluation Service（オフライン評価） デプロイ前のテストフェーズにおいて、準備したデータセットと定義したルーブリックを基に一括で評価処理を実行します。 Offline 評価 GenAI Evaluation Service の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Evaluation / Online Monitors（オンライン評価） 稼働中の対話データを継続的にモニタリングする機能です。エージェントがツールを呼び出した順番などの実行軌跡（Traces）をトラッキングし、運用中の応答精度や制御状態をリアルタイムで追跡します。 Online Monitors 参考 : Gen AI Evaluation Service の概要 参考 : エージェントの評価 まとめ Gemini Enterprise Agent Platform の概要をはじめ、AI エージェントの開発・運用に不可欠な「Build（構築）」「Scale（スケーリング）」「Govern（管理）」「Optimize（最適化）」の各機能群の要点を解説して、本セッションは締めくくられました。 まとめ なお、今回のセッション内容には Gemini Enterprise（Gemini Enterprise app）の解説は含まれていません。Gemini Enterprise の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 関連記事 blog.g-gen.co.jp 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

日本におけるAIの利用実態 Google Cloud導入企業のAI活用率は75% 最初に、日本企業におけるAI活用の現在地が具体的な数字とともに紹介されました。Google Cloudを導入している企業では、AIの活用率がすでに約75％に到達。さらに先行企業では、生成AIが単なる検証テーマではなく、実際の業務を支える仕組みとして本番運用へ移り始めています。