【Google Cloud Next 2026】McLaren Racing Intelligenceハンズオン
- 4月24日
- 読了時間: 7分
更新日:4月26日
著者:駒場 成美(金融NEXT企画部)
Google Cloud Next 2026 の会期中に開催されたハンズオン「McLaren Racing Intelligence — Build AI Agents for F1 Analytics」に参加しました。基調講演で発表された Gemini Enterprise Agent Platformを、F1 を題材に 実機・実コード・実データ に触れながら体感できる構成で、"PoCの段階は脱した" というメッセージを開発者目線で追体験する内容でした。

会場の様子(執筆者撮影)
ワークショップ概要
テーマ: F1 レースのルールブック QA と、順位予測を題材に、エージェント構築の3階層を順に体験
階層 | ツール | 想定ユーザー |
Tier 1 プリビルド | Gemini Enterprise のみ | 業務部員・エンドユーザー |
Tier 2 ローコード/ノーコード | Gemini Enterprise の Agent Designer | DX推進・業務企画 |
Tier 3 フルコード | Agent Development Kit (ADK) | AIエンジニア・テックリード |
基調講演で Sundar Pichai 氏が強調した「数千のエージェントをどう管理するか?」という問いに対して、同じ基盤・同じ UX で自在に縦断できる という答えを、実際に手を動かして確認できる構成でした。
題材と扱うデータ

会場の様子(執筆者撮影)
扱うデータは大きく2種類。
構造化データ: 1966年〜現在までの F1 レース結果(ドライバー、チーム、サーキット、スタート位置、結果など)
非構造化データ: FIA(国際自動車連盟)が発行する F1 公式ルールブック(2025年版/2026年版、各数百ページ)
目的は「次戦でマクラーレンのドライバーが表彰台に上がれる確率を予測するエージェント」の構築。数百ページの規程 PDF を参照しつつ、過去数十年の構造化データから学習・推論する構成です。
ワークショップの流れ
Tier 1 — Gemini Enterprise で データをそのままの形で扱う
Cloud Shell で API 有効化・BigQuery データセット作成・リポジトリ clone までを数コマンドで済ませた後、FIA 規程 PDF を Gemini Enterprise の データストアコネクタ に接続。接続すると Gemini Enterprise が自動的に PDF をチャンク分割し、各チャンクを 3,072次元ベクトル に埋め込んでベクターストアへ格納します。数百ページ × 2本で、インデックス完了まで 約30分〜1時間ほどだそうです(ハンズオンでは完了済みのものを使用)。
「Closed Parc 条件とは何か?」という質問を2パターンで試すと、Web Grounding(Google Search)のONとOFFで結果が対照的でした。
Google Search ON → Wikipedia、FI Insights など 非公式情報 を引用
Google Search OFF → FIA 2026 Sporting Regulations の Section B Article 5 を正しく引用
コーポレートデータを参照してほしいクエリで Google Search が有効になっていると、Web 情報と社内文書が混ざったハルシネーションに近い回答が返ってくる、という点を、実感をもって知ることができました。
続けて「2025 と 2026 のパワーユニット規定の違いを教えて」と尋ねると、数百ページ × 2本 の PDF を横断的に読み込み、差分を構造化して返してくれました。基調講演で語られた "データサイロを超える統合コンテキストエンジン" の最小構成を実感できます。
Tier 2 — Agent Designer(ローコード/ノーコード)
Gemini Enterprise の Configuration → Feature Management で Agent Designer を有効化したうえで、「Formula 1 のレギュレーションに特化した専門家エージェント」とプロンプトを入力するだけで、数秒で以下が自動生成されました。
名前: Formula 1 Regulations Expert
description(説明文)
system instructions(Markdown 形式)
使用モデル・接続済みデータストア
Flowビュー(DAG:Directed Acyclic Graph)で処理が可視化され、サブエージェントの追加もドラッグ&ドロップで行えます。基調講演で紹介されたAgent Studioを実際に操作しました。
講師が特に強調していたのは、descriptionは人間向けの説明文ではなく、エージェント間のルーティングに使われる情報であるという点です。マルチエージェント協調(A2Aプロトコル)では、親エージェントが子エージェントのdescriptionを参照し、「このタスクはどのエージェントに委ねるべきか」を判断します。基調講演で紹介されたAgent RegistryやAgent Identity(各エージェント固有の暗号ID)は、このdescriptionベースのオーケストレーションを、組織横断で統制・監査するための基盤として位置づけられている点が印象的でした。
Instructionsについては、「新入社員に業務を指示するように具体的に書く」という指示と、Google Docsで作成した内容を「Copy as markdown」で貼り付けるという実務的なノウハウが紹介されており、現場での活用イメージが湧きやすい内容でした。
Tier 3 — ADK でフルコード実装
Cloud Shell Editor を開き、Python で本格実装。ADK では次の3要素だけを定義すれば動きます。
Model — 思考する頭脳(今回は Gemini 3 Flash preview)
Instructions — 振る舞いの指示(prompts.py に切り出し)
Tools — 外部世界との接点(関数、Built-in Toolset、MCP ツールなど)
今回組み込んだツールは以下。
BigQuery Toolset(ADK 組み込み、データセット一覧・スキーマ取得・任意 SQL 実行を1行で付与)
カスタム関数 get_podium_predictions(season)(関数の docstring を読んでエージェントが呼び出しタイミングを判断する 設計)
可視化サブエージェント(受け取ったデータで Python コードを書いて matplotlib 実行。ツールとして注入)
予測モデルは CREATE MODEL ... OPTIONS(model_type='LOGISTIC_REG', ...) の Google SQL 1本で、BigQuery 上にそのまま構築(BQML)。学習は〜2023年、ホールドアウトに 2024/2025 を使用。特徴量はスタート位置、直近レースでのドライバー勢い、チーム競争力、サーキット適性など。
adk web でローカル Streamlit UI を立ち上げてテストしたクエリは以下。
質問 | 裏側の挙動 |
"What is McLaren's podium rate at Monaco across all time?" | エージェントが 自ら SQL を書いて BigQuery を叩き、結果を要約 |
"What was Oscar's predicted podium probability for the 2024 Monaco Grand Prix? Did the model get it right?" | カスタム関数 get_podium_predictions(2024) を自動選択 → BQML 推論 → 実結果と照合(予測 50.02%、実際ポディウム獲得) |
"Show me a chart of McLaren's championship points progression through the 2024 season" | 可視化サブエージェントが Python コードを生成 → matplotlib で折れ線グラフ |
最後に Vertex AI Agent Engineへデプロイし、サービスアカウントに BigQuery 権限を付与。デプロイ済みエージェントを Gemini Enterprise 側で "組織のエージェント" として登録すると、エンドユーザー画面には Google 提供/組織の ADK/Agent Designer 製 の3カテゴリが同じ UI に並びます。基調講演の Agent Marketplace 構想の入口がここに接続していました。
まとめ — ハンズオン所感と金融業界への示唆
基調講演で繰り返された「PoCの段階は脱した」「作るから運用・管理へ」というメッセージが、実機・実コード・実データでそのまま体験できる濃密な3時間でした。特に強く印象に残ったのは次の3点です。
非エンジニア → ローコード → フルコードの順で、同じ基盤上にエージェントを積み上げられる(Tier 間の移行コストが低く、PoC を本番に昇格させるパスが明快)
BigQuery・BQML・Agent Engine が有機的に結合 し、データ分析・予測モデル・エージェントが同じアーキテクチャ上で完結
Instructions は従業員マニュアル、description はルーティング情報 という比喩が、エージェント設計・ガバナンスを語る共通言語になりつつある
金融業界への示唆としては、以下が挙げられます。
取引・顧客データ(構造化)と、大量の規程・約款・社内ポリシー(非構造化)を横断するユースケース — 与信、コンプライアンス、AML、不正検知など — に本構成はそのまま転用可能
既存 Vertex AI 資産(Agent Engine、Model Garden、BQML)はそのまま使え、上位に Agent Studio / Agent Registry / Agent Identity・Agent Gateway が重なる構造なので、金融機関が求めるゼロトラスト・監査要件に自然に整合する
「管理職に SQL 研修」ではなく「SQL を書くエージェントを与える」時代へ。ただし SELECT 限定・DML 禁止 のガードレールは必須で、Agent Gateway のポリシー一元管理がその受け皿になる
Google Search グラウンディングは便利だが監査不能。規制対応領域ではデフォルト OFF が現実解
また、ハンズオンの結果を日本語でも出力してみましたが、英語での結果と遜色なく、日本でも実務レベルで活用できるポテンシャルを感じました。
一方で、"ファイルをアップロードするだけで誰でもエージェントが完成する" というレベルにはまだ届いていない、というのが今回のハンズオンを通じた私自身の正直な実感です。Agent Designer の自動生成は確かに強力ですが、本番運用レベルの精度を担保するには SQL・Python・クラウド権限設計などの技術的素養が一定必要で、現時点では「技術に抵抗のない方であれば短時間で構築できる」基盤と位置づけるのが実態に近いと考えています。
Gemini Enterprise には30日間の無料トライアルがあり、ADK のサンプルも Cloud Shell 上でそのまま動作させることができます。お手元の社内データと接続することも可能ですので、まずは題材を絞った小さな PoC から、エンジニアリングチームと一緒に試していくアプローチが現実的です。本基盤の有効性を見極めるには、机上の議論よりも実機で数時間手を動かす経験に勝るものはありません。当社としても、お客様のユースケースに即した検証・実装をご支援できればと考えております!



