本ブログは ハイテクインター株式会社 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。 地方都市の中心市街地活性化は、多くの自治体が直面する共通の課題です。従来、通行者数の調査は単発的に実施されることが多く、年間を通じた傾向把握や詳細な属性分析が困難でした。このブログでは、ハイテクインター様が開発した VIX（Video Information eXchange）クラウドと AI カメラを活用し、富山市が北陸地区で初めて常設 AI カメラによる通年人流計測を実現した事例をご紹介します。AWS のサービスを活用することで、コスト削減と性能向上を両立し、さらにオープンデータとして一般公開することで地域経済の発展に貢献しています。 地方都市が直面する中心市街地活性化の課題と背景 富山市では、富山市スマートシティ推進ビジョンに基づき富山市中心市街地活性化基本計画を策定し、中心市街地の活性化に取り組んでいます。しかし、新規出店等のマーケティングに活用できる詳細なデータが不足していました。従来の調査方法では、単発的な実施に留まり、年間を通じた平日休日別や時間帯別の通行者データ、さらには性別・年齢といった属性情報を継続的に取得することが困難でした。 この課題を解決するため、富山市は地元企業の株式会社 CHRONOX（以下クロノクス）に委託し、スマートシティの情報基盤となる都市 OS 上に AI カメラを活用した人流観測プラットフォームを構築、2023 年 4 月 1 日より運用を開始しました。クロノクスは富山駅周辺および総曲輪地区に 52 台の AI カメラを設置し、ハイテクインターの VIX クラウドと常設 AI カメラによる人流計測を北陸地区で初めて実現しています。 図1: 富山市に設置された AI カメラの様子 AWS サービスの採用理由：コスト削減と性能向上の両立 ハイテクインター様は、情報通信・映像機器の企画・開発から輸入・販売・サポート、さらにはシステムの構築・設置設定・保守管理まで一貫して手がける企業です。同社が開発した VIX クラウド（Video Information eXchange Cloud）は、クラウド上でカメラから取得した映像を AI 解析し、目的に合った情報に変換する情報交換プラットフォームです。 AWS サービスの採用にあたり、ハイテクインター様は以下の点を重視しました。 まず、コスト効率の高い処理基盤の構築です。映像ストリーム処理と AI 推論を別々のインスタンスで行っていた従来構成では、台数分のコストと運用負荷が課題でした。 Graviton プロセッサ 搭載の Amazon EC2 インスタンスであれば、Arm ネイティブの処理性能を活かして両方の処理を 1 台に集約でき、約 4 割のコスト削減が見込める点が採用の決め手となりました。 次に、顔属性認識の精度とコストです。人流データに性別・年齢などの属性を付加するにあたり、 Amazon Rekognition を採用しました。他社製品比で約 2 割のコスト優位があることに加え、表情の認識粒度が細かく、データの付加価値を高められる点を評価しています。 図2: VIX クラウドの概念図 ソリューションの概要：VIX クラウドによる人流データの可視化 VIX クラウドは、マルチベンダーカメラからの映像取得、各種 AI エンジンの搭載、静止画および動画配信機能を備えた統合プラットフォームです。主な機能として、以下を提供しています。 人流・交通流計測 AI 機能 では、カメラから送られてきた画像から車両識別（大型・小型・二輪車）、人流および人属性（年齢・性別）を計測し、グラフ化します。車種別認識率は昼夜問わず 97% 以上を実現しており、時間ごと、曜日ごとの集計が可能です。 危険地域侵入検知機能 では、工事現場などでの危険地域立ち入りを検知し、LINE への発報やパトランプとの連携が可能です。スマートフォンで危険領域を設定できる利便性も備えています。 その他、水位異常解析など、多様な用途に対応できる拡張性を持っています。 ソリューションの構成：AWS サービスを活用した効率的なアーキテクチャ 富山市の人流観測プラットフォームは、以下の AWS サービスを中心に構成されています。 IP カメラからの映像ストリームは、Amazon EC2 上で稼働する VIX クラウドに連携されます。ストリーム映像からのエリア検知には Amazon EC2 の Graviton プロセッサを活用し、性能向上とコスト削減を同時に達成しました。従来は i3 インスタンスで変換処理を行い g4dn インスタンスで AI 処理を実行していましたが、G5g インスタンス 1 台でストリーム処理と AI 処理の両方を処理できるように最適化した結果、約 4 割のコスト削減を実現しています。 顔属性認識には Amazon Rekognition を利用しています。他社製品と比較して約 2 割のコスト削減を達成しただけでなく、より豊かな表情認識が可能になりました。 図3: 富山市人流観測プラットフォームの AWS アーキテクチャ AI カメラは「人間」「車両」「顔」の検出が可能で、52 台のカメラが富山駅周辺および総曲輪地区に設置されています。 通年データ取得から始まる都市計画の最適化 富山市中心市街地活性化に向けて、年間を通じた平日休日別や時間帯別の通行者の人数・滞留時間・属性（性別・年齢）をデータ化することに成功しました。従来単発的に実施されていた調査データを通年で取得することにより、これまで以上に最適化された都市計画の立案に寄与しています。 特筆すべきは、このデータをオープンデータとして一般に公開している点です。 富山市の人流データダッシュボード では、誰でも人流データにアクセスできます。これにより、新規出店を検討する事業者がマーケティングに活用したり、研究機関がデータ分析に利用したりと、地域経済の発展を多角的に支援しています。 AWS のサービスを活用することで、約 4 割のインフラコスト削減と約 2 割の顔属性認識コスト削減を実現し、持続可能な運用基盤を構築できました。 今後の展開：スマートシティの更なる進化 ハイテクインター様と富山市は、今回構築した人流観測プラットフォームを基盤として、さらなるスマートシティの実現を目指しています。通年で蓄積されたデータを活用した詳細な分析や、他の都市 OS 機能との連携により、より高度な都市計画の立案が期待されています。 また、VIX クラウドの持つ拡張性を活かし、水位異常解析など、防災や環境保全の分野への応用も検討されています。オープンデータとして公開されている人流データは、民間企業や研究機関による新たなサービス開発や学術研究にも活用され、地域経済のエコシステム形成に貢献していくことが期待されます。 お客様の声 本プロジェクトにおける VIX クラウドの開発と AWS 基盤の設計を主導したハイテクインター株式会社 映像開発部 AI クラウド開発 Gr. 課長 高橋 亨氏は、今回の取り組みを振り返り次のようにコメントしています。 「富山市人流計測システムの開発においては、AWS を基盤とするクラウドネイティブなアーキテクチャを採用し、スケーラビリティとリアルタイム性を両立できる実行基盤を構築しました。特に、映像入力から推論、属性抽出、集計、可視化までを疎結合に設計することで、処理負荷の変動に対しても柔軟に追従できる構成とした点が、本システムの技術的な特徴です。AI 処理については、最新の Graviton プロセッサのインスタンスを活用することで、映像データに対する推論処理の高速化を図り、現場で求められるリアルタイム応答性を実現しました。また、Amazon Rekognition による顔属性取得機能を組み合わせることで、単純な通行人数の把握にとどまらず、属性情報を含めた多面的な人流分析を可能にしています。これにより、都市空間における人の流れを定量的かつ即時的に把握できるシステムとして、運用面・分析面の双方で高い有効性を持つ構成に仕上げることができました。開発側の観点では、本取り組みは、マネージドサービスと高性能な推論基盤を適切に組み合わせることで、開発効率と運用性を確保しながら、実用レベルの精度と応答性能を実現できた点に大きな意義がありました。加えて、機能拡張や処理対象の追加にも対応しやすい構成として設計しているため、今後の横展開や類似ユースケースへの適用可能性も高いと考えています。」 また、富山市 活力都市創造部 まちづくり推進課 管理振興係 副主幹・係長 五十嵐祐子氏は、AI カメラを活用した人流データの計測の導入効果について次のように述べています。 「富山市では、中心市街地のにぎわい創出に向けた取り組みを進める中で、これまで単発の調査では把握しきれなかった人流の実態を、継続的にデータとして把握する必要があると考えていました。本システムの導入により、年間を通じて通行者数や滞留状況、時間帯・曜日ごとの変化に加え、年代や性別といった属性情報も継続的に取得できるようになり、中心市街地の活性化施策や都市計画の検討に活用できる基盤が整いました。また、本データはオープンデータとして公開しており、市民や事業者、研究機関など多様な主体が自由に利用できる環境を整えています。実際に大学による人流分析の研究にも活用されるなど、データの新たな活用が広がり始めています。今後は、これまでに蓄積してきた人流データをさらに活用し、AI などの技術による高度な分析も取り入れながら、データに基づいたまちづくりを推進していきたいと考えています。」 まとめ ハイテクインター様が開発した VIX クラウドと AI カメラを活用し、富山市は北陸地区で初めて常設 AI カメラによる通年人流計測を実現しました。Amazon EC2 の Graviton プロセッサと Amazon Rekognition を活用することで、約 4 割のインフラコスト削減と約 2 割の顔属性認識コスト削減を達成し、持続可能な運用基盤を構築しています。 通年で取得された詳細な人流データは、都市計画の最適化に貢献するだけでなく、オープンデータとして一般公開されることで、地域経済の発展を多角的に支援しています。この取り組みは、地方都市におけるスマートシティ実現のモデルケースとして、今後の展開が期待されます。 AWS の生成 AI サービスや IoT サービスについて詳しく知りたい方は、 AWS のスマートシティソリューション をご覧ください。 ソリューションアーキテクト 伊勢田氷琴

はじめに 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 等）。好きな食べ物はラーメンと寿司。