はじめに AWS Summit Japan 2026（6/25-26 @幕張メッセ）にご来場いただいた皆様、ありがとうございました。本ブログでは、建設・不動産業向けインダストリーブース（A057）の不動産パートの展示内容をご報告します。 不動産ブースのテーマ： 「不動産業の未来を、生成 AI で切り拓く ─ データと対話が変える、新しい不動産体験」 また、ブースの事前紹介は こちらの開催予告ブログ で公開しています。 不動産×AI ─ AI 時代のデータ戦略をどう描くか 不動産業界では、人口減少・空き家問題・人手不足といった構造的な課題が山積しています。これらに立ち向かうために、データと AI を組み合わせた業務変革が求められています。しかし、どれだけ優れた AI が登場しても、活用できるデータが整っていなければ課題解決は始まりません。今回のブースでは、不動産業の数ある業務の中でも 開発・流通・管理 という3つのフェーズに着目し、さらにそれらを横断する 意思決定・可視化 の視点を加えた4つの切り口で、業務課題を解決するためのデータと AI の活用方法をご紹介しました。 開発：オープンデータ× 自社データ活用。大量のデータを AI で解析し、エリア分析・将来予測 流通：自社の物件・顧客データを AI に提供。AI が自社システムにアクセスし、顧客体験をセルフサービス化 管理：設備データ・修繕履歴・IoT センサーを深く・継続的に蓄積。3D モデルや AI で解析・予測 可視化：データを横断的に可視化。Amazon Quick の生成 AI によるダッシュボード自動生成で、経営判断を加速 今、不動産業に求められるのは、ユースケースを正しく理解し、必要なデータを集め、求められる切り口で AI に活用させること。これが 2026 年における「AI 時代のデータ戦略」です。 ここからは、ブースで展示した各ソリューションをご紹介します。 展示① 都市・エリア分析 × AI エージェント「AI Urban Digital Twin」 概要 不動産業における 開発 フェーズにおいて「どこに」「何を」建てるかの意思決定を AI で支援するソリューションです。人口統計・地価・交通量・POI などの公開データと自社データを統合し、AI が都市特性を多角的に分析します。 本ソリューションには2つの側面があります。ひとつは、大量のオープンデータを事前に整形・統合し、3D 地図上にヒートマップや境界ポリゴンとして描画する可視化機能。もうひとつは、MCP（Model Context Protocol）で AI エージェントが不動産情報ライブラリ API や分析データベースにリアルタイムにアクセスし、「この地域の将来人口は？」などの自然言語クエリに即座に回答する対話型分析機能です。この2つを組み合わせることで、エリア分析を高速に実行し、不動産開発・用地選定の判断を加速します。 デモの見どころ エリアの開発ポテンシャル分析：生成AIが人口増加率・地価変動率・災害リスク・周辺施設の充実度など多角的な指標をもとにエリアをスコアリングし、地図上にエリアの状況を描画 開発企画の提案：エリア特性（人口分布・用途地域等）に基づき、住宅・オフィス・商業施設それぞれにおいて、周辺施設の状況などを踏まえた開発企画を AI が提案 将来予測の可視化：5年後・10年後・20年後の地価変動・人口予測をヒートマップで表示 データ取得・変換フロー 今回は、国土交通省が提供する「不動産情報ライブラリ」の情報を元に都市を分析するデモを作成しています。 不動産情報ライブラリは REST API として公開されており、以下の2種類の形式でデータを取得しています。 JSON API：市区町村・都道府県単位で取得。不動産取引価格（四半期別）など ベクトルタイル API（GeoJSON）：将来推計人口、用途地域、災害リスク、施設POI など 不動産情報ライブラリ API から取得したデータは、 AWS Lambda を利用して変換し、 Amazon S3 に CSV として蓄積します。この際、データは都市コードごとに分類され、さらにデータ種別（将来推計人口・用途地域・地価・災害リスク等）ごとのディレクトリに整理して格納されます。2次処理では Amazon S3 上の全データを読み込み、空間統合・スコアリングを行った結果を Amazon DynamoDB のテーブルへ書き込みます。処理の中では、取得した各種ポリゴンデータを約250m四方の正方形グリッド（メッシュ）に変換・割り当てし、メッシュ単位でデータを統合しています。それぞれのテーブルには以下のようなデータが格納されます。 AreaData：同一用途地域ごとにグルーピングしたエリア単位の分析結果 PredictionData：エリアごとの5年刻みの将来予測データ BoundaryData：地図描画に使用するエリアの境界ポリゴン ZoningData：用途地域データや建ぺい率・容積率の区域データ PropertyData：自社物件データ（所在地・緯度経度・物件属性） なぜ、2段階の処理でデータを取得しているかというと、データ量の問題があります。1都市あたり約 200 MB、1,000ファイル以上にも渡る取得結果をそのまま描画するのはパフォーマンスの懸念がありました。そこで、 Amazon DynamoDB にデータを整形して投入することで、地図描画時のパフォーマンスを確保しています。また、 Amazon S3 に生データを残すことで、処理ロジックを改良した際にいつでも再処理が可能な設計としています。 フロントアプリケーションの構成とデータの活用 Amazon DynamoDB に格納されたデータは、API を経由してフロントエンドに提供されます。各 Lambda 関数がそれぞれの Amazon DynamoDB テーブルにアクセスし、用途に応じた形でデータを返却します。また、MCP Chat Lambda は Amazon Bedrock と連携して自然言語での対話型分析を、Geodata Lambda は Amazon Location Service と連携して地図描画を実現しています。 フロントアプリケーションでは以下の機能が提供されます。 AI 都市診断機能 各テーブルから取得したエリア分析結果を地図上に可視化し、ユーザーにデータ参照体験を提供します。さらに Amazon Bedrock がデータを解釈し、人口動態・地価・災害リスク・周辺施設などを総合した都市分析レポートを生成します。 開発企画生成機能 用途地域・施設充実度・人口構成などのデータを元に、生成 AI が当該エリアに適した開発企画（住宅/商業/オフィス等）を提案し、顧客に新たなインサイトを提供します。 未来の可視化機能 将来予測データを元に、都市の5年後・10年後・20年後の人口・地価の変化をヒートマップで表示します。時間軸を切り替えることで、エリアの将来性を直感的に把握できます。 自社物件マッピング機能 自社保有物件を地図上にプロットし、エリア分析結果と重ねて表示します。これにより「自社物件がどのようなエリア特性の中に位置しているか」を一目で把握できます。さらに、エリアのスコアや将来予測と自社物件を掛け合わせ、生成 AI が「このエリアの物件は将来的に価値が上がるか」「周辺施設の充実度に対して賃料設定は適切か」といった分析を提供します。開発判断やポートフォリオ見直しの材料として活用できます。 その他にも、用途地域ポリゴンを地図上に重ねて表示する機能や、洪水浸水想定区域・液状化リスク・土砂災害警戒区域といった防災情報の可視化機能も備えており、開発候補地のリスク評価を地図上で直感的に確認できます。 AI チャット機能 大規模なバッチ処理によって大量のデータ処理と可視化を実現している一方で、不動産情報ライブラリ API を MCP（Model Context Protocol）サーバーとして構成し、生成 AI を利用した対話型分析機能も提供しています。こちらはバッチ処理済みのデータに加え、国交省 API からリアルタイムに最新情報を取得して回答できるため、「直近の取引事例は？」「このエリアの最新の地価公示は？」といった鮮度の高い問いかけにも対応します。バッチによる俯瞰的な可視化と、MCP によるリアルタイムな対話分析の両輪で、ユーザーの意思決定を支援します。 このように、大量のデータを高速に参照して地図上に描画する用途と、チャットのようにリアルタイムで短い問いに即座に応答する用途では、求められるデータパイプラインが異なります。前者にはバッチ処理による事前整形と Amazon DynamoDB への投入が、後者には MCP を通じた API のリアルタイム呼び出しが適しています。ユースケースに応じてパイプラインを分けることが、データと AI を組み合わせたソリューション設計において重要なポイントです。 展示② 不動産流通支援 AI エージェント「AI コンシェルジュ」 概要 不動産業における顧客接点は Web・電話・メッセージアプリと多岐にわたりますが、どのチャネルでも一貫した体験を提供できている企業はまだ少ないのではないでしょうか。その背景には、物件データベースや予約管理システムなど自社の業務システムが個別に存在し、チャネルが分断している現状があります。本展示では、生成 AI エージェントが自社の物件データベースや予約管理システムに直接接続し、電話でもチャットでも、物件提案から内覧予約までをシームレスに完結させるオムニチャネル体験をお見せしました。AI が自社システムのデータにリアルタイムにアクセスすることで、顧客はどのチャネルからでもセルフサービスで物件探しから予約まで完了できます。 デモでは、チャットで「目黒駅の 2LDK を探している」と伝えると、AI が条件を整理して物件を提案し、内覧日時をその場で確定する、という一連の流れをお見せしました。 デモの見どころ 電話とチャットのオムニチャネルな体験：同じ AI エージェントがチャットでも電話でも対応。チャネルを問わず一貫した顧客体験を提供 生成AIが既存システムと連携：顧客の発話内容に応じて、AI が自社システムの API（物件検索・予約管理等）を自律的に呼び出しデータを取得・入力 顧客体験がセルフサービスで完結：物件提案から内覧予約の確定まで、人間の介在なしに AI が一連の業務を完結。24時間対応 アーキテクチャの特徴 Amazon Connect Customer AI Agents は、 Amazon Connect Customer 上で動作する AI エージェント機能です。音声やチャットチャネルを通じて顧客と直接会話し、質問への回答だけでなく予約の作成・変更・キャンセルといったアクションまで自律的に実行できます。解決が難しい場合はシームレスに人間のオペレーターにエスカレーションします。この仕組みの軸は、自社システムの API をツールとして AI エージェントに読み込ませることにあります。プロンプトで定義されたルールに基づき、AI エージェントが顧客の希望に合わせて能動的にツールを起動し、自社の物件データベースから条件に合う物件を検索したり、予約管理システムに内覧予約を書き込む操作を自律的に実行します。人間が介在せずとも、データの参照と入力の両方を AI が行える点がポイントです。 この仕組みはチャットだけでなく電話でも同様に機能します。 Amazon Connect Customer がオムニチャネルの入口となるため、顧客がどのチャネルから問い合わせても同じ AI エージェントが同じツールを使って対応します。 本展示で扱う物件データ（PropertyData）は、展示①のエリア分析で使用しているものと同じデータです。展示①では「エリア × 自社物件」の俯瞰的な分析視点で活用しているのに対し、展示②では同じデータを顧客向けのセルフサービス体験として提供しています。 展示③ 施設管理 × AI × デジタルツイン 概要 展示①と同じ地図ベースのソリューションですが、扱うデータが異なります。展示①がオープンデータと自社物件データで「都市」を分析するのに対し、本展示では施設のセンサーから取得する稼働データや修繕履歴データを用いて「管理されている施設の状態」を可視化・分析します。 不動産管理のフェーズでは、開発・流通とは異なる課題があります。管理施設が数十〜数千棟に散在する中で「どの施設が最もリスクが高いか」を一元的に把握する手段がなく、台帳はExcelや紙・個別システムに分散しているため横比較ができません。修繕優先度の判断は熟練者の勘に依存し、退職とともに知見が消失します。さらに、設備状態の確認には毎回現地巡回が必要であり、劣化に気づかないまま放置された結果、発見時には既に状態が深刻化し、大規模修繕による膨大なメンテナンスコストが発生するリスクがあります。 デモの見どころ 地図上の施設状態マッピング：施設のセンサー稼働データ・修繕履歴を元に劣化ランクを算出し、地図上に色分けで表示。コンディションベースでメンテナンスの意思決定が可能に 生成 AI アシスタント：取得したデータが生成 AI に連携され、施設に関する質問への回答や劣化予測・修繕優先度の提案を自然言語で取得可能（例：「築40年以上でFCIがD以上の施設は？」） デジタルツイン（3D可視化）：これらの情報を建物の3Dモデル上にマッピングし、デジタルツインとして管理可能。現地に行かずに設備状態を空間的に把握 アーキテクチャの特徴 統合施設管理AIダッシュボードは、施設・設備の維持管理を支援するAIエージェント機能です。ダッシュボード上のチャットUIを通じて担当者と対話し、施設の劣化状況や修繕優先度に関する質問への回答だけでなく、修繕依頼の起票といったアクションまで実行できます。修繕依頼の作成にあたっては、プロンプトで定義されたルールに従って担当者に確認を求めたうえで書き込みを行います。 この仕組みの軸は、自社システムのAPIをツールとしてAIエージェント（Strands Agents SDK + Amazon Bedrock AgentCore ）に読み込ませることにあります。プロンプトで定義されたルールに基づき、AIエージェントが担当者の要望に合わせて能動的にツールを起動します。 Amazon DynamoDB の施設・設備・修繕データから条件に合う施設を検索し、 Amazon Neptune Analytics の知識グラフに対してopenCypherクエリを発行して施設間の関係性（同型設備の故障リスク伝播、業者依存度、類似施設のクラスタリング）を分析し、確認を経たうえで修繕依頼を書き込む操作までを実行します。人間が最終判断を担いつつ、データの参照と入力の両方をAIが行える点がポイントです。 Amazon Bedrock の基盤モデルは、テキストの対話だけでなく画像の解析にも活用されています。点検時にアップロードされた写真をマルチモーダル基盤モデルが解析し、ひび割れ・錆・水損・劣化といった問題点の検出、重要度評価、推奨対応、概算費用の目安を構造化データとして返します。対話エージェントによるデータの参照・入力と、画像解析による点検の効率化が、いずれも同一のAI基盤の上で提供されています。 本ソリューションで扱う施設データは、単一のデータ基盤（ Amazon DynamoDB ）を複数の視点で共有しています。ダッシュボードでは「地図 × 3Dデジタルツイン（ AWS IoT TwinMaker ） × KPI」という俯瞰的な管理視点でデータを活用するのに対し、AIエージェントでは同じデータを担当者向けの対話型セルフサービス体験として提供します。さらに、 Amazon DynamoDB Streams 経由で知識グラフ（ Amazon Neptune Analytics ）へ自動同期されるため、参照系（可視化）と実行系（修繕依頼の起票）のどちらの操作を行っても、俯瞰と対話の両方の視点で常に最新かつ一貫した情報にアクセスできる点が本アーキテクチャの特徴です。 展示④ Amazon Quick ─ データの見せ方を変え、新たなインサイトを得る ここまでの展示で使用したデータを Amazon Quick で可視化すると、地図や AI チャットとはまた異なる切り口が見えてきます。 Amazon Quick には自然言語からダッシュボードを生成する機能があります。例えば、展示①で取得したエリア情報に関しても、地価や取引状況に着目したダッシュボードとして生成し直すと、経営管理ダッシュボードとして生まれ変わります。 このように、不動産に関するデータは見せ方・使い方・その粒度によって、様々なインサイトを我々にもたらしてくれます。同じデータでも、地図上のヒートマップとして見れば開発判断に、ダッシュボードとして見れば経営判断に活用できる。データと AI の組み合わせ方次第で、不動産業の意思決定は大きく変わります。 まとめ 今回のブースでは、不動産ビジネスの 開発・流通・管理、そして 可視化 という4つの視点を通じて、「AI 時代のデータ戦略」をお伝えしました。 開発 ── 国交省のオープンデータと自社データを広く掛け合わせ、メッシュ単位で AI が俯瞰的に解析する 流通 ── 自社システムのデータに AI がリアルタイムにアクセスし、顧客と直接対話して業務を完結する 管理 ── 設備・修繕履歴という深いデータを長期的に蓄積し、AI が予兆を読み 3D で可視化する 可視化 ── すべてのデータを Amazon Quick に統合し、生成 AI でダッシュボードを自動生成。経営判断を加速する 生成 AI の時代、まず取り組むべきは派手な AI 機能の開発ではなく、自社のデータを整え、つなぎ、AI に渡せる状態にすること。その第一歩を一緒に踏み出しませんか。 ブースにお越しいただいた皆様、ありがとうございました。展示内容についてのご質問や、自社での活用についてのご相談がございましたら、お気軽に担当のソリューションアーキテクトまでお問い合わせください。 本ブログは、ソリューションアーキテクトの奈良、Fikko が執筆しました。 関連リンク ・ 【開催予告】AWS Summit Japan 2026 建設・不動産向けブース展示

G-gen のバロキです。当記事では、Anthropic の Claude Code と Google Cloud の データサイエンスエージェント という 2 つの AI ツールに、同一のデータセットと指示を与えて比較しました。自動生成されるデータ分析ノートブックに、どのような違いが生まれるかを検証しました。 概要 はじめに データサイエンスエージェントとは Claude Code とは 検証の前提条件 使用したデータセット 投入したプロンプト 評価の観点 生成されたノートブックの全体像 データサイエンスエージェントの特徴 Claude Code の特徴 観点別の比較 コードの量と構造 可視化のスタイル 説明可能性 データクレンジングへの姿勢 コードの再利用性 設計思想の対比 ユースケース別の使い分け データサイエンスエージェントが向いているケース Claude Code が向いているケース 概要 はじめに 「データを渡すと、AI が分析ノートブックを生成してくれる」という体験が、一般的になりつつあります。Google Cloud のデータサイエンスエージェントや、Claude Code をはじめとする大規模言語モデル（Large Language Model、以下、LLM）ベースのエージェントツールは、いずれもデータ分析の自動化を可能にします。 しかし実際に検証してみると、同じデータセットと同じ指示を与えても、ツールによって出力されるノートブックに違いがあるケースがあります。当記事では、両者の成果物を並べて比較し、その差がどこから生まれるのかを読み解きます。 結論を先に述べると、2 つのツールに優劣はなく、想定されている用途やユーザー層が異なります。なお、当記事の内容は、検証を行った2026年5月現在の仕様に基づいています。 データサイエンスエージェントとは データサイエンスエージェント は、Google Cloud の Colab Enterprise に組み込まれた、 Gemini をベースとするデータ分析エージェントです。タスクをサブタスクに分解し、ステップごとに思考プロセスを示しながら処理を進める点が特徴です。BigQuery テーブルや CSV ファイルを入力に、自然言語の指示から動作する Colab ノートブックを生成します。 参考 : データ サイエンス エージェントを使用する - Colab Enterprise 以下の記事も参照してください。 blog.g-gen.co.jp Claude Code とは Claude Code は、Anthropic が提供する、ターミナル上で動作するエージェント型のコーディングツールです。プロンプトを受け取ると、ノートブック全体の構成をあらかじめ設計し、一括で書き下ろすスタイルが特徴です。 参考 : Claude Code overview 検証の前提条件 使用したデータセット 検証には、Kaggle で公開されている「Japanese Universities」データセットを使用しました。1872 年以降の日本の大学情報を網羅したオープンデータです。 参考 : Japanese Universities - Kaggle データセットの主な仕様は以下のとおりです。 項目 仕様 公開者 webdevbadger 内容 1872 年以降の日本の大学情報（所在地、創立年、評判、難易度など） ライセンス Open Data Commons Public Domain Dedication and License（ODC-PDDL） 行数 / 列数 813 校 / 22 列 対象範囲 47 都道府県すべてを網羅 創立年範囲 1872 年 11 月（明治期）〜 2022 年 4 月（近年） 設置主体内訳 Private 626 校 / Public 101 校 / National 86 校 主なカラム code 、 name 、 name_jp 、 type （National / Public / Private）、 address 、 state_jp 、 latitude 、 longitude 、 found （YYYY-MM）、 faculty_count 、 department_count 、 review_rating 、 review_count 、 difficulty_SD 、 difficulty_rank （A〜F） 当データセットは、設置主体や地域の分布に明確な構造を持ち、創立年の時間軸も広いため、探索的データ分析（exploratory data analysis、以下 EDA）の検証素材として適しています。EDA とは、本格的なモデリングに入る前に、データの分布や欠損、変数間の関係を可視化しながら把握する作業です。AI に EDA を依頼し、その出力の質を比較する用途にも向いています。 投入したプロンプト 両者には、以下の 4 つの観点を網羅する EDA を依頼する同一の本文を、いずれも日本語のプロンプトで与えました。 データ品質 : 欠損、重複、異常値、基本特性、数値変数間の関係 地理的分析 : 大学の空間分布と都道府県・地域別の設置主体構成 機関特性 : National / Public / Private を規模と評判の両面から比較 時系列分析 : 創立の経年トレンドと設立時期別の設置主体構成 加えて、最終成果物に「分析から得られた重要な気づきを 5 つ」を含めること、および日本語テキストが正しく表示されることを条件としました。 なお、公平性のため分析を依頼する本文は両者で同一にしていますが、成果物の保存先の指示だけは実行環境に合わせて変えています。Claude Code はローカルのターミナルで動作するため、「成果物を output/ フォルダに保存する」よう明示的に指示しました。一方、データサイエンスエージェントは Colab Enterprise 上でノートブック自体が保存されるため、この指示は与えていません。 データサイエンスエージェントに入力したプロンプト（分析本文は Claude Code と同一） Claude Code のターミナルに入力したプロンプト 評価の観点 生成されたノートブックの品質を、以下の軸で観察しました。 実行性（エラーなく走るか） カバレッジ（プロンプトの要求項目を満たしているか） コード品質（慣用的か、再利用可能か） 可視化の量と質 説明可能性（各ステップの意図が読み取れるか） 構造の見通しの良さ 生成されたノートブックの全体像 データサイエンスエージェントの特徴 データサイエンスエージェントは、タスクをサブタスクに分解し、各ステップの目的を明示してから実行します。出力されたノートブックでは、各コードセルの直前に「 Reasoning : ...」という Markdown セルが配置され、これから何を行うか、なぜその処理が必要なのかが自然言語で解説されます。 主な特徴は以下のとおりです。 各セルが自己完結する（必要なインポートをセル内で都度実行する） 「データの読み込み → 欠損値の確認 → 補完処理 → 可視化」のように段階を明示する 各ステップに Reasoning ブロックを付与する エラーや警告が発生した場合、それを検知して次のセルでリカバリするプロセスが記録される ステップごとの透明性の確保が、データサイエンスエージェントの設計思想の中核と言えます。 データサイエンスエージェントのコードセル上部に表示される Reasoning マークダウン Claude Code の特徴 Claude Code は、ノートブック全体を 1 つの完成品として設計してから書き下ろします。プロンプトを受けると、内部で全体構造をプランニングし、必要なライブラリ、再利用するカラーパレットや定数、セクション構成を最初に決定したうえで、一括でノートブックを出力します。 主な特徴は以下のとおりです。 インポート文とグローバル定数（ TYPE_ORDER 、 TYPE_PALETTE など）を冒頭に集約する 同じ可視化スタイルを全セクションで一貫させる セルあたりのコード密度が高く、1 つのセルで複数のグラフを配置する 各セクションの最後に「ポイント」として短い解釈を記述する 観点別の比較 コードの量と構造 出力されたノートブックの構成を数値で示します。 項目 Claude Code データサイエンスエージェント 総セル数 55 41 コードセル 30 16 Markdown セル 25 25 総コード行数 約 353 行 約 286 行 インポートの位置 冒頭に集約 各セルで都度実行 セル数やコード行数の違いは、それぞれの設計思想を反映しています。Claude Code は完成されたレポートとしての密度を重視し、データサイエンスエージェントはステップごとの実行ログとしての読みやすさを重視していると言えます。 可視化のスタイル Claude Code はライブラリ選択の幅が広く、 folium による地図プロット、 seaborn の violinplot 、 pairplot 、 heatmap などを柔軟に使い分けます。1 つの観点に対して多角的にアプローチする構成です。 データサイエンスエージェントは、 plotly express による地図プロットや、 matplotlib と seaborn を組み合わせたシンプルな boxplot 、積み上げ棒グラフが中心です。種類を絞ることで、初学者でもプロセスを追いやすい一貫性を持たせています。 Claude Code が生成した Folium 地図と violinplot/heatmap データサイエンスエージェントが生成した Plotly Express 地図と box plot 説明可能性 ここが 2 つのアプローチで最も大きく分かれるポイントです。 Claude Code が生成するノートブックは、コードは洗練されているものの、「なぜその可視化手法を選んだのか」といった意図はコードから読み解く必要があります。一定以上のデータ分析リテラシーを前提としたレポート構成です。 一方、データサイエンスエージェントでは、各セルの直前に処理の意図が明記されます。例えば欠損値処理のフェーズでは、以下のような Reasoning が出力されます。 Reasoning: Based on the analysis of missing values, I will impute phone with 'Unknown' as it is a categorical identifier. For numerical columns review_rating, review_count, and difficulty_SD, I will use median imputation as it is more robust to outliers. For the categorical column difficulty_rank, I will use mode imputation. データサイエンスエージェントの Reasoning 付き欠損値補完セル Claude Code の可視化中心の欠損値処理セル 「何を、どう処理して、なぜそうするのか」が逐一言語化されるため、データ分析を学習中のメンバーにとって、ノートブック自体が良質なチュートリアル教材となります。 データクレンジングへの姿勢 データクレンジングに対する姿勢も対照的です。 Claude Code は欠損値を可視化して報告するに留め、欠損のまま分析を進めます。EDA としては伝統的な進め方で、欠損のパターン自体に情報があるため、むしろ望ましいという見方もあります。 データサイエンスエージェントは、欠損値を統計的に補完（インピュテーション）します。インピュテーションとは、欠損したセルを平均値や中央値などで埋める処理のことです。 phone は 'Unknown' 、数値カラムは中央値、カテゴリカラムは最頻値で埋める、という戦略を文章で宣言してから実行します。下流のモデリングに繋ぐパイプラインを想定すると、この明示性は実務で有用です。 どちらが正解ということはなく、Claude Code は分析者の判断を読者に委ね、データサイエンスエージェントは判断を逐一表に出す、という思想の違いです。 コードの再利用性 Claude Code はグローバル定数（ TYPE_ORDER 、 TYPE_PALETTE ）と再利用可能なヘルパー関数（ iqr_outliers ）を冒頭で定義し、以降のセルがそれを参照する構造になっています。コードベースとして手入れし続ける用途に適しています。 データサイエンスエージェントはセルごとに自己完結しているため、一部のセルだけを別のノートブックにコピーして流用するのが容易です。「特定の処理だけ使い回したい」というユースケースには、データサイエンスエージェントのスタイルが向きます。 設計思想の対比 これまでの検証を踏まえ、両者の設計思想の違いを一覧にまとめます。 観点 Claude Code データサイエンスエージェント 出力の性格 完成形のレポート 実行ログ・チュートリアル プランニング 上位から一括生成 ステップ単位で漸進的に実行 説明可能性 サマリでの論評 各セルに Reasoning を配置 カバレッジ 網羅的かつ深層的 コアとなる観点に集中 エラーハンドリング エラーを起こさない前提のコード エラー時は次セルでリカバリを実行 コードの密度 高い 低い（可読性重視） 再利用性 グローバル定義による一元管理 セルごとの自己完結型 介入の容易さ 低い 高い 想定ユーザー 経験豊富なアナリスト 学習者・ビジネス層・探索的分析 ユースケース別の使い分け データサイエンスエージェントが向いているケース データ分析の学習フェーズ Reasoning が併記されるため、分析者の思考プロセスを追体験する教材として使用できます。 対話的な探索フェーズ 「ここまでの結果を踏まえ、次は別の切り口で検証したい」といった、人間が途中で介入しながら進める探索に適しています。 ビジネス層によるデータ探索 非開発者が自然言語でデータを問い合わせる際、処理がブラックボックス化せず、結果の根拠をステップごとに確認できます。 Colab 環境での完結 Colab 起動を前提とした環境設定コードも含まれるため、ブラウザのみで即座に分析を開始したい場合に最適です。 パイプラインの部分流用 セル自己完結型のため、データクレンジングのセルだけを別ノートブックにコピーするといった部分流用がしやすくなります。 Claude Code が向いているケース 迅速なレポート作成 分析結果を素早くレポートとして共有したいケースで、一括生成が強みを発揮します。可視化のバリエーションが豊富で、レポートとしての完成度が高い特徴があります。 経験豊富なアナリストの叩き台 コードが慣用的で密度が高いため、これをベースに独自のカスタマイズや手動の書き換えを素早く行う用途に適しています。 要求項目の網羅（カバレッジ重視） プロンプトに指定したチェックリスト的な要求に対して、抜け漏れなく一括で対応させたい場合に有利です。 カスタムビジュアライゼーションの使用 folium のクラスタリング地図、scatter matrix、violin plot など、データ分析で慣習的に使われる可視化を幅広く使いたい場合に引き出しが多くなります。 ハサナル・バロキ (記事一覧) クラウドソリューション部 クラウドサポート課。インドネシア北スマトラ州ビンジャイ市出身。 YKK株式会社での金型設計を経て IT 業界へ転身。AI／システムエンジニアとしての経験を積み、現在は G-gen にてクラウドサポートに従事。 趣味は水泳と RAG チャットボット開発（OpenAI・Gemini・Vector Search 等）。好きな食べ物はラーメンと寿司。

G-gen の佐々木です。当記事では、Google Cloud Next '26 で発表された BigQuery に関する新機能について、公式の投稿記事「 What’s new in BigQuery: Powering the Agentic Era 」の内容をもとに紹介します。 はじめに Open, cross-cloud lakehouse Managed Iceberg Tables（GA） Iceberg REST Catalog の読み書き相互運用性（Preview） Cross-Cloud Lakehouse（Preview） Catalog Federation（Preview） リアルタイムデータレプリケーション（GA / Preview） Graph-based reasoning for enterprise agents BigQuery Graph（Preview） BigQuery Graph におけるメジャーのネイティブサポート（Preview） BigQuery Conversational Analytics におけるグラフサポート（Preview） BigQuery Graph と Looker の統合（Preview） BigQuery Studio での視覚的なモデリング機能（Preview） Native AI processing to unlock structured and unstructured data AI.PARSE_DOCUMENT（Preview） TabularFM（Preview） ObjectRef（GA） AI 連携関数の最適化モード（Preview） BigQuery ネイティブの Gemma エンベディング（Preview） 自律型エンベディング生成（GA） BigQuery Hybrid Search（Preview） Python UDF（GA / Preview） コネクテッドシートにおける TimesFM モデルの利用（GA / Preview） Geospatial Analytics Datasets（Preview） Agentic experiences BigQuery における Conversational Analytics（GA / Preview） Proactive Agentic Workflows（Preview） BigQuery Agent Analytics（GA / Preview） BigQuery Studio の新機能群（GA / Preview） データサイエンスエージェント（GA） Colab Data Apps（Preview） BigQuery Remote MCP Server（GA） BigQuery ADK Toolset（GA） Google Cloud Data Agent Kit（Preview） Unparalleled performance and scale Fluid Scaling（GA） 高度なランタイム、小規模クエリ、履歴ベースの最適化（GA） 新しいワークロード管理機能（GA / Preview） 可観測性の向上（GA / Preview） はじめに 以下の Google 公式投稿を参考に、Google Cloud Next '26 で発表された BigQuery の新機能を紹介します。なお、当記事で紹介する機能の提供ステータス（GA / Preview / Coming Soon）は 2026年4月23日現在の情報です。 参考 : What’s new in BigQuery: Powering the Agentic Era 他の Google Cloud Next '26 の関連記事は、Google Cloud Next '26 カテゴリの記事一覧から参照してください。 blog.g-gen.co.jp Open, cross-cloud lakehouse Managed Iceberg Tables（GA） Google Cloud Lakehouse （旧称 : BigLake ）は、 Apache Iceberg などのオープンテーブル形式と Google Cloud のマネージドストレージを組み合わせた、オープンデータレイクハウス向けのストレージエンジンです。 Google Cloud Lakehouse における Managed Iceberg Tables は、OSS である Apache Iceberg のマルチエンジン互換性と BigQuery の高度な機能を組み合わせたマネージドな Iceberg テーブルで、自動テーブル管理、Iceberg パーティショニング、マルチテーブルトランザクション、変更データキャプチャ（CDC）、強化されたベクトル化（Enhanced Vectorization）、履歴ベースの最適化（History-based Optimizations）を提供します。 参考 : Google Cloud Lakehouse とは 参考 : Apache Iceberg テーブル Iceberg REST Catalog の読み書き相互運用性（Preview） Iceberg REST Catalog は、BigQuery、Spark、その他 OSS / サードパーティエンジンの間で Iceberg テーブルを共有するためのカタログです。 カタログ上での Iceberg テーブルに対する 読み書きの相互運用性 （Read/Write Interoperability）により、複数の Iceberg 互換エンジン（Apache Spark、Trino など）から Iceberg テーブルを作成 / 更新 / クエリできるようになります。 参考 : Openness without compromises for your Apache Iceberg lakehouse Cross-Cloud Lakehouse（Preview） Cross-Cloud Lakehouse は、AWS や Azure など Google Cloud 以外のクラウド上のデータに対して、データ移行や ETL を行うことなく BigQuery の分析機能や AI 機能をそのまま適用できる機能です。たとえば、Amazon S3 Iceberg 上のデータに対して Gemini Enterprise のエージェントや BigQuery の AI 関数などを実行できます。 Iceberg REST Catalog によるオープンスタンダードなテーブル共有と、 Cross-Cloud Interconnect によるクラウド間の高帯域幅ネットワークを組み合わせることで実現されています。 参考 : クロスクラウド レイクハウスについて 参考 : The future of data lakehouse: Open and interoperable for the agentic era 基盤技術である Cross-Cloud Interconnect については以下の記事をご一読ください。 blog.g-gen.co.jp Catalog Federation（Preview） Catalog Federation は、外部のメタデータカタログを BigQuery 側でフェデレーションする機能です。 AWS Glue、Databricks、SAP、Salesforce、Snowflake のカタログに対応しており、Confluent Tableflow についても2026年後半に提供予定です。データの発見、分析、ゼロコピー共有を、複数のカタログをまたいで実現できます。 リアルタイムデータレプリケーション（GA / Preview） Spanner 、 AlloyDB 、 Cloud SQL から BigQuery へのリアルタイムレプリケーション（GA）と、Iceberg テーブルへのレプリケーション（Preview）が提供されます。これにより、データベースの変更をリアルタイムに分析基盤側へ反映でき、レプリケーションパイプラインを別途整備する必要がなくなります。 Graph-based reasoning for enterprise agents BigQuery Graph（Preview） BigQuery Graph は、BigQuery 上でデータをグラフとしてモデル化 / 分析 / 可視化できるグラフ分析機能です。SQL の CREATE PROPERTY GRAPH 文で既存の BigQuery テーブルに対してエンティティ（ノード）と関係性（エッジ）を直接定義でき、データの移動や重複を伴わずにグラフ分析を行えます。 従来の SQL では「友達の友達の友達」のような多段階の関係性分析に複数の JOIN を入れ子にする必要があり、SQL の記述・読解が難しいうえ、データ規模が大きくなるとパフォーマンスが急激に低下する点が課題でした。グラフ分析では、データをノードとエッジの集合としてモデル化することで、こうした多段階の関係性を直感的に記述でき、深い探索もスケーラブルに実行できます。 BigQuery Graph はこうしたグラフ分析を BigQuery 上でネイティブに実行できる基盤として、不正検知、Customer 360、サプライチェーン分析、ソーシャルネットワーク分析などのユースケースに対応します。 参考 : BigQuery Graph の概要 参考 : BigQuery Graph のご紹介 : データに潜む関係性を明らかに BigQuery Graph におけるメジャーのネイティブサポート（Preview） メジャー （売上や解約率といった集計値を再利用可能な形で定義したもの）が BigQuery Graph 上でネイティブサポートされるようになりました。 これにより、メジャーとエンティティ間のリレーションシップを1つのガバナンスされた定義に統合でき、AI エージェントは単なる検索や集計に留まらず、あるビジネスイベントが他の指標にもたらす影響をマルチホップで辿るような構造的推論を行えるようになります。 参考 : メジャーを使用する BigQuery Conversational Analytics におけるグラフサポート（Preview） 自然言語データ分析の Conversational Analytics が BigQuery Graph と連携できるようになりました。会話分析エージェントが生テーブルではなくグラフ上のエンティティと関係を辿って推論するため、回答の精度が向上します。メジャーを用いて正確な KPI を計算すると同時に、関係性を辿ることで「なぜその数字になっているか」を発見できます。 BigQuery における Conversational Analytics の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp BigQuery Graph と Looker の統合（Preview） BigQuery Graph と Looker の統合により、BigQuery Graph をそのまま Looker のビューとして公開でき、定義した指標をデータスタック全体で再利用できます。 逆方向のユースケースとして、Looker 側で BigQuery Graph を定義することもできます。これにより、Looker が標準で備えるバージョン管理（Git 連携）や検証機能を、グラフ定義の変更管理にそのまま適用できます。 BigQuery Studio での視覚的なモデリング機能（Preview） BigQuery Studio 上で、BigQuery Graph のエンティティ、リレーションシップ、ビジネスロジックを視覚的に構築 / 管理できる新しいインターフェースが追加されました。グラフスキーマの設計を SQL の CREATE PROPERTY GRAPH 文だけでなく UI 上からも進めることができます。 Native AI processing to unlock structured and unstructured data AI.PARSE_DOCUMENT（Preview） マネージド AI 関数の1つである AI.PARSE_DOCUMENT は、OCR（光学文字認識）、レイアウト解析、チャンク分割を自動化する SQL 関数です。複雑なドキュメント処理ワークフローを別途のパイプラインを構築せずに簡素化でき、非構造化ドキュメントの取り込みを SQL で完結できます。 TabularFM（Preview） TabularFM は、表形式データに対する高品質な回帰・分類機能を提供する基盤モデルです。事前学習済みのモデルとして提供されるため、特徴量選択、チューニング、モデルトレーニング、デプロイ後のモデル管理といった工程を経ずに、SQL から直接呼び出して予測結果を得られます。 従来の BigQuery ML では、表形式データに対する分類・回帰モデルをユースケースごとに用意する必要があり、本格的に運用するまでに一定のセットアップコストがかかっていました。TabularFM はこれを共通の基盤モデルに置き換え、典型的な分類・回帰タスクをモデル開発の工程を踏まずに試せるようにします。 ObjectRef（GA） ObjectRef 値 は、SQL や Python から非構造化データと構造化データを並行して扱うための値です。以下のフィールドを持つ STRUCT として表現されます。 フィールド 型 モード 説明 uri STRING REQUIRED Cloud Storage オブジェクトの URI version STRING NULLABLE オブジェクトのバージョン authorizer STRING NULLABLE 委任アクセス用の BigQuery 接続 ID。直接アクセスの場合は NULL details JSON NULLABLE オブジェクトのメタデータや処理時のエラー情報などが入る ObjectRef 値を操作するための SQL 関数として、以下の4種類がサポートされています。 関数 用途 OBJ.FETCH_METADATA URI のみが埋まった ObjectRef 値に Cloud Storage 上のメタデータを取り込み、完全な ObjectRef 値を返す OBJ.GET_ACCESS_URL ObjectRef が指す Cloud Storage オブジェクトへのアクセス URL（読み取り / 読み書き）を JSON 値で返す（委任アクセスが必要） OBJ.GET_READ_URL ObjectRef が指す Cloud Storage オブジェクトの読み取り用 URL を STRUCT（ url 、 status ）で返す（URL は45分で失効、委任アクセスが必要） OBJ.MAKE_REF Cloud Storage URI などから ObjectRef 値を生成する 参考 : ObjectRef functions 参考 : ObjectRef 値を操作する AI 連携関数の最適化モード（Preview） Optimized Mode により、 AI.CLASSIFY や AI.IF などの SQL から呼び出せる AI 関数で、タスク固有のモデルをクエリ実行時に動的にトレーニングして利用できます。これにより、従来の行単位でモデルを呼び出す場合と比較して、トークン消費量を230分の1に削減できます。 BigQuery ネイティブの Gemma エンベディング（Preview） Gemma ベースの組み込みテキストエンベディングモデル embeddinggemma-300m が、 AI.EMBED 関数および AI.SIMILARITY 関数で利用できるようになりました。エンベディング生成には BigQuery のスロットがそのまま使われるため、GPU 環境を別途用意することなく、検索や RAG 向けのエンベディングパイプラインを構築できます。 参考 : The AI.EMBED function 参考 : The AI.SIMILARITY function 自律型エンベディング生成（GA） Autonomous Embedding Generation （自律型エンベディング生成）は、テーブルのテキスト列（STRING 列）から生成するベクトルエンベディングをフルマネージドで維持する機能です。エンベディングモデルが生成したベクトルを自動メンテナンスし、ソース列のデータが追加・更新されるたびに自動で再生成されます。これにより、煩雑になりがちなエンベディング作成・更新ジョブの運用を簡素化できます。 参考 : 自律型エンベディング生成 BigQuery Hybrid Search（Preview） BigQuery Hybrid Search はセマンティック検索と全文検索を単一の関数に統合する検索機能で、RAG や複雑な探索系ユースケースにおいて、単独の検索よりも高い精度を実現します。 Python UDF（GA / Preview） Python UDF は、Python で独自実装したスカラー関数を BigQuery で利用する機能です。データの拡張・変換・クリーニングなどが行え、コンテナを用いたサーバーレス実行環境により数百万行規模まで自動スケールします。 以下の機能が新たに Preview 提供となり、Python UDF は今後数週間にわたって段階的に GA となる見込みです。 Apache Arrow の RecordBatch インターフェースを使ったベクトル化 Python UDF を作成でき、行単位の呼び出しと比べてパフォーマンスを改善できる CPU 使用率、メモリ使用率、インスタンスごとの最大同時リクエスト数などのメトリクスを Cloud Monitoring にエクスポートできる CREATE FUNCTION 文に追加された container_request_concurrency オプションで、Python UDF のコンテナインスタンスごとの最大同時リクエスト数を制御できる イメージストレージのバイト数（プロジェクト・リージョンごとに 10 GiB）とミューテーションレート（プロジェクト・リージョンごとに1分あたり30回）の新しいクォータが適用される INFORMATION_SCHEMA.JOBS ビューの external_service_costs 列、および Job API の ExternalServiceCosts フィールドから Python UDF のコストを確認できる 参考 : Python のユーザー定義関数 コネクテッドシートにおける TimesFM モデルの利用（GA / Preview） コネクテッドシート は、BigQuery のスケールを Google スプレッドシート上で利用できる機能です。アップデートにより、組み込みの時系列予測モデル TimesFM を使った予測（GA）と異常検知（Preview）に対応し、業務担当者がスプレッドシートから大規模データに対する予測や異常検知を行えるようになります。 参考 : コネクテッド シートの使用 参考 : TimesFM モデル コネクテッドシートの利用方法については、以下の記事をご一読ください。 blog.g-gen.co.jp Geospatial Analytics Datasets（Preview） Geospatial Analytics Datasets は、 Google Maps Platform 由来のデータセットと Earth Engine のラスターデータおよび解析機能を BigQuery 上で直接扱えるようにする機能です。地理空間データの取得・前処理を自前で組まなくても、BigQuery の他のデータセットと同じ感覚で参照できます。 提供されるデータセットは以下の4種類です。 データセット 内容 Imagery Insights ストリートビューの画像 Places Insights Google マップ上のビジネス / スポットの集約データ Roads Management Insights 道路ネットワークの交通流・混雑状況 Earth Engine in BigQuery Earth Engine の衛星画像・ラスターデータと解析機能 参考 : Power up your BigQuery analysis with Google's new geospatial datasets Agentic experiences BigQuery における Conversational Analytics（GA / Preview） BigQuery の Conversational Analytics （対話型分析）は、自然言語を用いて BigQuery 上のデータに対する質問を生成 AI に投げかけ、分析を行うことができる機能です。予測分析や、構造化・非構造化データを横断した推論もサポートします。 BigQuery Studio および API 経由での利用は GA、データポータル（英名 : Data Studio、旧称 : Looker Studio）および Gemini Enterprise からの利用は Preview 提供となっています。 参考 : BigQuery の会話型分析 BigQuery の対話型分析機能の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Proactive Agentic Workflows（Preview） Proactive Agentic Workflows は、エージェントが単なる対話型の質問応答を超えてプロアクティブに動作する機能です。指標の変化を検知して根本原因分析を行い、定期的な調査レポートをメールで直接配信するといったユースケースに対応します。 BigQuery Agent Analytics（GA / Preview） BigQuery Agent Analytics は、AI エージェントのアクティビティ（イベント）を BigQuery に記録し、分析できるようにする機能です。エージェントのトラブルシューティング、最適化、定量評価に活用できます。 エージェント向けのプラグインとして、 Agent Development Kit （ADK）向けのプラグインは GA、 LangGraph 向けのプラグインは Preview として提供されています。 BigQuery に記録されるイベントの種類は、以下のようなものがあります。 イベントの種類 内容 LLM interactions LLM へのプロンプト、モデル出力、エラーに関するイベント トークン使用量、生成にかかった時間なども記録される Tool usage ツール呼び出しの開始、完了、エラーに関するイベント ツールの呼び出し元（ tool_origin ）も記録される State Management エージェントの内部状態の変更に関するイベント Agent lifecycle & Generic Events エージェントの起動、実行完了、ユーザー入力の受信などのイベント Human-in-the-Loop (HITL) Events ユーザー認証情報の要求、ユーザーへの確認要求、ユーザーからの入力要求などの割り込みイベント 参考 : Use BigQuery agent analytics 以下の記事では、BigQuery Agent Analytics の ADK 向けプラグインの使い方を紹介しています。 blog.g-gen.co.jp BigQuery Studio の新機能群（GA / Preview） BigQuery Studio は BigQuery の各種機能を Google Cloud コンソールに統合した BigQuery 向けのワークスペースです。今回のアップデートで複数の機能が追加されました。 機能 ステータス 内容 コンテキスト認識型アシスタント Preview リソース探索やトラブルシューティングを支援 SQL Cells GA SQL と DataFrames を統合 Visualization Cells GA ノートブック内で直接ビジュアルを作成 Files Explorer GA フォルダ形式でコード資産を整理・共有・管理 Git Integration and Workflows Preview GitHub、GitLab、Bitbucket、Azure DevOps に対応した Git 連携 参考 : BigQuery 分析の概要 - BigQuery Studio データサイエンスエージェント（GA） データサイエンスエージェント （Data Science Agent）は、Colab Enterprise ノートブック上で動作する AI エージェントです。自然言語で目標を述べるだけで実行計画を自動生成し、データのロード、クリーニング、ビジュアライゼーションを自動で進めます。内部的には BigQuery ML、DataFrames、Spark を組み合わせて利用しています。 Colab Enterprise のほか、BigQuery Studio 上で Colab Enterprise ノートブックを開くことでも、データサイエンスエージェントを利用することができます。 参考 : BigQuery で Colab Enterprise データ サイエンス エージェントを使用する データサイエンスエージェントの詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Colab Data Apps（Preview） Colab Data Apps は、BigQuery Studio のノートブックで作成したデータ分析を、Python 製のインタラクティブアプリに変換できる機能です。アプリは BigQuery のスロットを使用してフルマネージドな環境で実行されます。 アプリの公開・共有はデータポータル側で行い、エンドユーザーはコードを編集することなく、UI 上で日付範囲やフィルタなどのパラメータを変更してデータを操作できます。 参考 : BigQuery とデータポータルで Colab Data Apps を使用する BigQuery Remote MCP Server（GA） BigQuery Remote MCP Server は、 Model Context Protocol （MCP）対応のリモートサーバーをマネージドで提供するものであり、AI エージェントが MCP を介して BigQuery を操作できるようになります。 参考 : Use the BigQuery MCP server Google Cloud が提供している MCP サーバーについては、以下の記事をご一読ください。 blog.g-gen.co.jp BigQuery ADK Toolset（GA） BigQuery ADK Toolset は、Agent Development Kit（ADK）を用いて構築したエージェントが BigQuery 上のデータを閲覧・操作するためのツールセットです。 参考 : BigQuery tool for ADK Google Cloud Data Agent Kit（Preview） Google Cloud Data Agent Kit は、IDE、ノートブック、ターミナルといった開発環境を問わずに利用可能な、エージェントによるデータ活用を支援する一連の機能を提供するスイートです。VS Code 拡張機能、MCP サーバー、Gemini CLI / Codex / Claude Code 向けのスターターパックといった複数の形態で提供されます。 エージェントは BigQuery、AlloyDB、Cloud SQL（MySQL / PostgreSQL）、Spanner、Cloud Storage などの Google Cloud 上のデータソースに接続し、以下のような作業を支援します。 Python や SQL でのクエリ実行、および自然言語による問い合わせを介したデータの検出・探索 Managed Service for Apache Spark や BigQuery でのデータエンジニアリングパイプラインの構築・テスト・デプロイ データの探索・クリーンアップから ML モデルの学習・デプロイまでを行う AI / ML 開発 組み込みの AI スキルやツールを使った反復的なタスクの自動化 参考 : VS Code 用 Data Agent Kit 拡張機能の概要 参考 : Data Agent Kit Starter Pack（GitHub） Unparalleled performance and scale Fluid Scaling（GA） Fluid Scaling は、変動の大きいワークロードに対して、コストとパフォーマンスのトレードオフを必要としない BigQuery 向けのオートスケーリング機能です。秒単位課金により細かい粒度でスケールでき、最大34%のコスト削減が可能です。 高度なランタイム、小規模クエリ、履歴ベースの最適化（GA） BigQuery のクエリエンジンに、 高度なランタイム 、 小規模クエリの最適化 、 履歴ベースの最適化 が適用されました。これらは BigQuery ネイティブテーブルと Iceberg テーブルの双方のワークロードに対して、コードやスキーマの変更なしに自動で適用されます。これにより、前年比でクエリ速度を35%向上させつつ、クエリ処理コストを40%削減しています。 新しいワークロード管理機能（GA / Preview） reservation groups （GA）、 flexible dynamic assignments （Preview）、 プロジェクトレベルのスロット / 同時実行制御 （Preview）といった新しいワークロード管理機能が追加され、きめ細かなコスト配分と価格性能比の制御ができるようになりました。さらに、 宣言型・ルールベースのワークロード管理 （Preview）により、これらの管理を簡素化できます。 可観測性の向上（GA / Preview） ミッションクリティカルなワークロード向けに、 Enhanced Observability （GA）、 Intersection Routing （Preview）、 Agent-Ready Security Center （Preview）といった可観測性・ディザスタリカバリ・セキュリティ関連の機能が追加・強化されました。さらに、 Agent-Powered Observability （Preview）により、AI エージェントによるターンキーなトラブルシューティングで運用を簡素化できます。 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805