こんにちは、Data & Analysis部で機械学習エンジニアをしている由川です。 キャディでは、2026年8月3日〜8月6日に出島メッセ長崎で開催された MIRU 2026 （第29回 画像の認識・理解シンポジウム)にてゴールドスポンサーとして協賛し、ポスター発表も行いました。 本記事では、出展内容と気になった論文発表のレポートをします。 MIRUとは 企業ブース ポスター発表 気になった発表 Cello: 視覚接地した文書特化型視覚言語基盤モデルの構築 局所的な幾何特徴の多様性に着目した数式生成点群データセットの構築および事前学習効果の検証 出力分布に基づくMLLM推論：Visual Question AnsweringのためのMLLMにおける視覚情報と内部知識の統合改善 まとめ MIRUとは 画像の認識・理解シンポジウム（MIRU）とは、画像の認識と理解技術に関する国内最大規模の会議で、参加者数は1500名ほど、発表件数は932件でした。 参加した中での個人的な感想ではありますが、発表内容には以下のトレンドがあるなと感じました。 既存のVLM / MLLMを活用して、特定ドメイン（医療、自動運転など）の精度改善を行う研究 3D再構築や人物姿勢推定など3Dに焦点を当てた研究があり、その中でも3DデータとしてGaussian Splattingを利用した研究が多い ベンチマークの構築、学習に有効な2D or 3Dデータセットの自動生成などデータセット構築系の研究 MIRUの会場 企業ブース TechBlog 実データx経営直下のスピードで価値を生む製造業AI研究開発 - リサーチエンジニア募集 にある通り、キャディではリサーチ組織の立ち上げを行っています。この組織を中心に取り組んでいるテーマに対して以下のようなことをご紹介しました。 機械学習技術を適用するにあたっての製造業ドメインの課題 製造業では2D、3D、構造化データ、文書というマルチモーダルなデータを関連付けて処理する必要がある 図面とCADデータの認識が求められるが、現在の汎用VLM / MLLMでは空間や幾何を認識するタスクが難しい 研究で利用されるようなオープンデータとの現場で利用されるデータにはギャップがある 課題解決のために製造業向けの基盤モデルを開発 基盤モデルを下流タスクに活用 タスク例：設計資産全体を横断して検索するための2D図面や3DCADモデルなどの埋め込み空間の統合や、3D CAD データ内の加工に必要な特徴の認識など また「製造業AIデータプラットフォームCADDi」のデモを通して実際に製造業の現場でどのように利用しているか示すことで、現状できていること、今後取り組んでいきたいことをより実感を持っていただくことができました。 ブースに立ち寄ってくださった皆様、ありがとうございました！ 企業ブースの様子 ポスター発表 キャディとしては初めて、学会でのポスター発表を行いました。 内容はTech Blog 製造業特化LLMを開発するための評価ベンチマーク や 製造業ドメインにおける VLMの現在地 （SSII 2026、画像センシングシンポジウム）にてご紹介した製造業向けのVLM評価ベンチマークManuDraw-Benchについてのもので、以下の成果を発表しました。 製造業に関する試験問題を解かせたところ、モデルによっては90%を超える正解率を出し、試験の合格ラインを超える しかし、製造業において重要な以下タスクは低スコア 空間認識タスク：2D図面から3D CADへの形状復元（製品設計のために図面から立体の形状を想起する工程を再現） 視覚認識タスク：図面内の記号検出（製造方法や原価を見積もるために、図面から特徴的な記号を見つける工程を再現） 以上より、製造業に関する意味的な内容は理解できている。しかし、空間認識タスクや視覚認識タスクの性能は低いので、製造業領域においてVLMはまだ実運用に至らない。 発表は多くの方が立ち寄ってくださり、評価データの集め方、評価方法を中心に様々な議論ができました。 また、このベンチマークは公開されているのか、公開する予定はあるのか？という旨のご質問を数多くいただきました。 現状の公開は難しいですが、業界全体で製造業ドメインにおいてVLMやMLLMを適用できるようにするにはどうすればよいのか模索できるようにするために、対応していきたいと思っています。 今回のポスター発表を通して非常に関心を持っていただけたことを実感しました。改めてお話いただいた皆様ありがとうございました！ ポスター発表の様子 気になった発表 会期中で聴講したり、論文を読んだりしたセッションの中で面白い、参考になったものをピックアップして紹介します。 Cello: 視覚接地した文書特化型視覚言語基盤モデルの構築 内田奏, 竹長慎太朗, Mengsay Loem, 山内敏嗣, 石井良（Sansan株式会社） この研究では、文書画像からの情報抽出において抽出したテキストがどこにあるのかの判断根拠の提示やOCRと連携して細字を認識することを目的として、テキストと位置情報（Bounding Box）を同時に出力する文書特化型VLM「Cello」を提案しています。 Celloでは名刺・請求書・契約書の文書画像と対応するテキストを事前学習したモデルに対して、テキストと対応するBounding Boxを表す座標を追加で事前学習しています。 Bounding Boxを表す座標は（<x_0>、<y_0>）のような特殊トークンで表現し、このトークンにTransformer系で用いられる位置埋め込み手法を適用し学習時の初期埋め込みをする、といった工夫を行うことでテキストの位置関係を効率的に学習しています。 レシート画像を使った公開データセットから情報抽出を行うタスクで実験したところ、既存手法と比べて特に位置検出精度が改善したことが示されました。また、Celloで検出したBounding Boxをもとにテキスト領域を抽出しOCRエンジンで読み取りを行うと、課題としていた細字の認識も改善することも示しています。 ポスター発表では、VLMは記号検出（=Bounding Boxを出力するタスク）が苦手だという旨を紹介しましたが、上記のような学習を行うと検出精度が改善しそうだなと思い、参考になりました。 局所的な幾何特徴の多様性に着目した数式生成点群データセットの構築および事前学習効果の検証 金子知紘, 大塚大地, 山田亮佑, 鳥見晃平, 柳凜太郎, 片岡裕雄（産業技術総合研究所）, 中村明生（東京電機大学） この研究では、3D点群モデルの事前学習に有効な幾何的要素を明らかにするため、数式ドリブン教師あり学習に基づき多様な局所幾何特徴を再現するデータセットSinusoidal Surface Point Cloud（SSPC）を提案しています。 また、3Dデータの複雑さを定量化するため、全体の複雑さを表す法線多様性と、局所的な形状（凹凸やエッジなど）の複雑さを表す曲率多様性という2つの指標を定義しています。これらの指標に基づいて、SSPCは、既存のデータセットと比べて大域的にも局所的にも多様な形状を表現できることを示しています。 SSPCにより生成された点群データを事前学習した上で、下流タスク（3Dセマンティックセグメンテーション）用にファインチューニングして評価したところ、下流タスクの学習データがわずか1%しかない厳しい状況でも、従来のデータセットで事前学習したモデルより高い精度を出せることを実証しています。 キャディでも3Dデータを用いた検証を進めていますが、データ不足に悩みやすく学習効果の高いデータセットを作るのも難しいため、このような数式に基づくデータ生成のアプローチは参考になりました。 出力分布に基づくMLLM推論：Visual Question AnsweringのためのMLLMにおける視覚情報と内部知識の統合改善 佐藤雅也, 前田圭介, 藤後廉, 小川貴弘, 長谷山美紀（北海道大学） この研究では、MLLMが入力画像に対するドメイン知識を必要とするKnowledge-Based Visual Question Answering（以降、KB-VQA。例：ゴルフをしている人の画像 + このスポーツの発祥国はどこですか？という質問に対して回答するタスク）に対しては十分な性能に達していないという問題が起こる一因を確認したうえで、解決策を提案しているものです。 著者らはKB-VQAにおいて、「テキスト先行決め打ち」という現象が起こることを発見しました。これは、視覚情報が寄与する前の層においてテキストトークンの出力確率が高くなった結果、モデルが視覚情報と自身の内部知識を統合する前に、テキスト情報から回答するというものです。 テキスト先行決め打ちが起こることがKB-VQAで性能が低くなる要因の一つだと仮定し、回答に対する画像トークンの層別寄与度を定量化する指標 layer sensitivity を提案しました。そのうえで、推論時にlayer sensitivityに基づいて視覚情報が最も使われる層を特定し、この層の前にトークンの出力確率が上がっていればその確率を下げるようなノイズを加えて行うことでテキスト先行決め打ちを抑制できる（≒KB-VQAでの正解率が既存手法と比べて改善する）ことを確認しました。 他のモデルやデータセットでも検証することでテキスト先行決め打ちと提案手法の一般性を確認するのが課題だと言及されていましたが、Tech Blog 製造業×AIの最前線：キャディが挑む研究課題と、CV・AIの「いま」が交わる場所 で言及したVLMの言語偏重の要因の一つにあるかもしれない + 解消につながるかもしれない研究だと思い、興味深かったです。 まとめ 本記事では、キャディの研究開発の現状や気になった論文をいくつかご紹介しました。 会期中を通して以下を実感できたので、非常に有意義な時間でした。 画像認識分野のトレンドと、トレンドに対する我々の現在地を知ることができたこと 多くの方と意見交換でき、我々の取り組みに興味と期待を抱いていただけたこと 最後に、キャディのリサーチ組織では2D/3D領域に関するResearch Engineerを募集しています。 そもそも何に取り組んでいる会社なのか、研究開発を通して何を実現したいのかなども含めて、ご興味があればぜひお気軽にご連絡ください。 speakerdeck.com open.talentio.com

本記事は 2026 年 8 月 18 日 に公開された「 Fresher insights, faster decisions: talabat’s near-real-time analytics across AWS and Google Cloud 」を翻訳したものです。 talabat は、中東・北アフリカ (MENA) 地域をリードする日常生活アプリです。レストランや小売店の幅広い選択肢から、食品、食料品、その他の日用品を手軽に注文でき、パーソナライズされた体験を提供しています。2004 年にクウェートで創業した talabat は、アラブ首長国連邦、オマーン、カタール、バーレーン、ヨルダン、イラク、エジプトに事業を拡大し、2025 年 12 月時点で月間アクティブユーザー 700 万人以上にサービスを提供しています。本社はアラブ首長国連邦のドバイにあり、2024 年 12 月にはドバイ金融市場 (DFM) で新規株式公開 (IPO) を完了しました。Delivery Hero SE の子会社として、グローバルな知見を活かしてサービス向上と事業拡大に取り組んでいます。パートナーとライダーのネットワークを通じて、顧客が必要なものを必要なときに届ける、地域全体の日常の利便性を支えています。 本記事では、talabat がハイブリッドなマルチクラウドレイクハウスを構築し、ストリーミングデータの Apache Iceberg コピーを AWS 上に一元的に保持しながら、 Google Cloud Platform (GCP) からガバナンスの効いたニアリアルタイム分析を実現した方法を紹介します。 talabat におけるデータ データは talabat のビジネスの中枢です。顧客が「注文」ボタンを押した瞬間からドアベルが鳴るまで、システムは瞬時にデータドリブンな意思決定を行い、価格設定、配車、ルーティング、注文の不正検知をリアルタイムで最適化しています。長年にわたり、talabat のアプリケーションは 2 つのパブリッククラウドにまたがる環境へと成長しました。トランザクションおよびオペレーション基盤は AWS 上で成熟し、エンジニアリングチームがサービスを構築・運用しています。一方、多数のアナリスト、データサイエンティスト、分析エンジニアリングパイプラインは Google Cloud Platform のウェアハウスである Google BigQuery を標準としています。 どちらへの投資も深く、どちらも価値を生み出しています。戦略的な問いは「どちらのクラウドに統合するか」ではなく「両者の境界をまたいでデータをどうスムーズに流すか」でした。この前提がアーキテクチャ全体を形作っています。課題はクラウド間だけでなくリージョン間にも及びます。AWS サービスは EU リージョンでホストされ、GCP のデータは US リージョンにあります。 次の図は、AWS 上のオペレーションプレーンと GCP 上の分析プレーンの間における talabat のデータフローを示しています。 図 1: AWS 上のオペレーションプレーンと Google Cloud 上の分析プレーン間のデータフロー これまでデータエンジニアリングチームは、2 つのクラウド間のデータ移動をオーケストレーションしており、AWS から GCP へ、EU から US への物理的なデータ移動が必須でした。従来の ETL (抽出、変換、ロード) ツールやフレームワークでの移動は、複数のホップを経てデータの遅延と重複を引き起こしていました。具体的には、 Amazon Relational Database Service (Amazon RDS) から Amazon Simple Storage Service (Amazon S3) EU AWS リージョンへ、Amazon S3 EU から Amazon S3 US リージョンへ、そして最終的に Amazon S3 US から BigQuery US への移動です。 各ホップはコピーであり、コピーのたびにリスクが積み重なりました。障害点の増加、レイテンシーの累積、冗長なコンピューティングとストレージ、型の忠実性、そして最も重要なのはクロスリージョンおよびクロスクラウドのデータ転送料（エグレスコスト）です。 要するに、従来の設計は自ら作り出した問題、すなわち BigQuery がデータを読めるようにデータを移動するという問題の解決に、コスト、レイテンシー、信頼性の代償を払っていました。典型的なデータウェアハウスのボトルネックです。代わりにオープンデータレイクを使えないか？使えます。しかし分析の利用は BigQuery に集中しており、オープンソースのデータレイク層を通じたアクセスが制限されています。そこで再設計は逆の前提から始めました。AWS にコピーを 1 つ保持し、BigQuery にそのままの場所で読み取らせる。本記事の残りで説明するのは、この talabat のレイクハウスです。 課題 オペレーションシステムは、注文ライフサイクルの変更、ベンダー、メニュー、ロジスティクスやライダーのシグナル、決済情報といったビジネスイベントを継続的にストリームとして発行し、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 上の Apache Kafka にパブリッシュしています。これらのイベントは Protocol Buffers でエンコードされ、 Confluent Schema Registry に登録された後方互換スキーマで管理されているため、プロデューサーとコンシューマーが安全に進化できます。 分析側の要件は、簡単に述べられるものの実現は困難です。イベントを正しい型で、生成から数分以内にクエリ可能にし、各チームが既に使っているツールからクエリできるようにすることです。 2 つのクラウドを持つことを技術的負債と見なしがちですが、talabat のようなリアルタイムビジネスにとっては単に地形であり、それぞれの側に本来の強みがあります。 イベント基盤は AWS 上にある。トランザクションおよびストリーミングシステムが Amazon MSK にパブリッシュしている。これらのイベントを最も低レイテンシーかつ低リスクに参照・処理できるのは、同じ AWS リージョン内、イベント基盤のすぐ隣です。 分析基盤は Google Cloud 上にある。何千もの下流のモデルやダッシュボード、そしてそれらを構築する人々が、BigQuery をクエリサーフェスとして前提としています。 どちらか一方に統合するには数年規模のマイグレーションが必要であり、片方のユーザーグループにとっては大幅な機能後退を意味します。単にインジェストと分析の間の継ぎ目を取り除くためだけに。データエンジニアは、その継ぎ目を排除するのではなく設計することに決めました。設計目標は一文にまとまります。データの物理コピーを AWS に 1 つ保持し、両方のクラウドからネイティブに読み取れるようにする。ハイブリッドデータレイクハウスにより、「どちらのクラウドか」という問いはアーキテクチャ上の分岐ではなくアクセスパスの選択肢になります。 最初に試したこと: ホットパス上のクロスクラウド書き込み 最初の試みでは、最終的に採用したフローとは逆のアプローチを取りました。Raw (Bronze とも呼ばれる) レイヤーのデータを AWS から直接 Google Cloud Storage 上の BigQuery マネージド Iceberg テーブルに書き込みました。理論上、最大の参照者基盤に最も近い場所にデータが配置されます。しかし実際には、常時稼働のストリーミングパスでクラウドをまたいで書き込むことで、長期的に許容できない問題が生じました。 インジェストパスにおけるクロスクラウド依存。マイクロバッチのたびに、リモートクラウドの書き込み API の可用性とレイテンシーに結合していました。 ストリーミング書き込み API の障害がインジェスト障害として顕在化。リモート書き込みが脆弱なリンクとなり、読み取り側の問題が書き込み側の障害に転化しました。障害を吸収する場所としては最悪です。 プレビュー段階の機能が物理レイアウトを制約。特定のパーティショニング動作や機能が一般提供されておらず、コストとパフォーマンスのためのデータ編成が制限されていました。 教訓は明確でした。書き込みパスはシフトレフトすべきです。書き込みパスは短く、ローカルで、シンプルであるべきです。クロスクラウドの課題は読み取りパスに属し、読み取り専用、キャッシュ可能、リトライ可能であり、インジェストに影響しません。この再構成が、現在稼働しているアーキテクチャに直結しました。 BigQuery が AWS 上のデータを読み取る方法の選択 フローを反転させ (Raw データは AWS 上、読み取りは Google Cloud から)、BigQuery が物理的に AWS 上にあるテーブルを読み取る 3 つの方法を評価しました。4 つの基準に照らして評価しました。 データ移動なし。 オープンテーブルフォーマット。 ガバナンス可能な信頼モデル。 最小限の運用面。 アプローチ 評価 Google Cloud Storage へのクロスクラウド書き込み Bronze を Google Cloud Storage 上の BigQuery マネージド Iceberg に書き込み続ける方法。前述の理由で却下しました。インジェストのホットパスにクロスクラウド依存とクロスリージョンレイテンシーが生じるためです。 BigQuery Omni BigQuery Omni のマネージドなクロスクラウドコンピュートを通じて AWS 上のデータをクエリする方法。読み取り専用の Bronze レイヤーに対して必要以上のマネージド面と制約が生じ、カタログと信頼モデルを直接制御したかったため不採用としました。 Lakehouse フェデレーテッド Apache Iceberg REST カタログ (IAM 認証) BigQuery が Amazon S3 Tables (マネージド Apache Iceberg テーブルを提供する Amazon S3 の機能) 内のデータを、AWS Glue Data Catalog のメタデータを同期するフェデレーテッドカタログを通じて読み取る方法。アクセスはクロスクラウド IAM 信頼で認証されます。4 つの基準をすべて満たしたため、この方法を選択しました。 決め手となったのは、Raw データが AWS から出ないこと、フォーマットがオープンな Apache Iceberg であること ( Amazon Athena 、Spark、Iceberg 互換エンジンが同じテーブルを読める)、そしてクロスクラウドの関係が定期的なコピージョブではなくアイデンティティと信頼として表現されることです。 Amazon S3 Tables を選んだ理由 AWS 上に単一の Iceberg コピーを保持するアーキテクチャが決まった後、スケーラブルな Iceberg に特化したストレージレイヤーが必要でした。Amazon S3 Tables は運用面を追加せずに要件を満たしました。テーブルメンテナンス (コンパクション、スナップショット期限切れ、未参照ファイル削除) はサービスマネージドポリシーとして自動実行され、テーブル数に比例して増える外部オーケストレーションジョブが不要です。同様に重要な点として、各テーブルが Amazon Resource Name (ARN) でアドレス指定可能なリソースです。IAM ポリシーで個別テーブルへのアクセスを許可・拒否でき、他の AWS リソースに適用するのと同じ最小権限モデルが使えます。また、 AWS CloudTrail がすべてのアクセス判定を記録します。信頼境界が IAM のみで表現されるクロスクラウド設計では、テーブルがファーストクラスの IAM リソースであることは利便性ではなく前提条件です。S3 Tables により、マネージド Iceberg ハウスキーピングときめ細かく監査可能なアクセス制御が単一の構成で実現し、エンジニアリングチームはストレージ層の実装ではなくストリーミングロジックに集中できました。 ソリューション概要 システムは、オープンテーブルフォーマットで接続される 2 つの部分で構成されています。 AWS 上の短くローカルな書き込みパス。 BigQuery がデータを参照できるようにする読み取り専用のクロスクラウドハンドシェイク。 唯一の信頼できるソース (Single Source of Truth) は、Amazon S3 Tables 内の Apache Iceberg データです。すべてのコンシューマーがこの 1 つの物理コピーを読み取ります。 次の図は、イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャを示しています。 図 2: イベントインジェストからストレージ、参照経路までのエンドツーエンドアーキテクチャ 書き込みパス: 短く、ローカルで、信頼性が高い Kafka トピックごとに 1 つの Amazon EMR Serverless Spark Structured Streaming ジョブ (プリベイクされた Docker イメージ、ARM64/Graviton 上の emr-7.13.0 ) を、Amazon MSK と同じ AWS リージョン (eu-west-2) で実行しています。コンピュートをイベント基盤と同じ場所に配置することで、マイクロバッチあたりのデータ転送量を最小化し、コストとレイテンシーを削減しています。各ジョブは Spark の foreachBatch オペレーションをトリガー間隔約 1〜5 分、at-least-once デリバリーで実行します。各マイクロバッチは 5 つのステップを実行します。 Kafka から コンシューム する。 登録済みスキーマを使用して Protocol Buffers を デコード する。 ターゲットの Iceberg スキーマに 変換 する。 Amazon S3 Tables 内の Iceberg テーブルに 追記 する。 オフセットを コミット する。 このサイクルが中断なく繰り返されます。 このパスは AWS のみで完結します。クロスクラウド依存はなく、意図的なクロスリージョンホップが 1 つだけあります。コンピュートは欧州 (ロンドン) リージョン (eu-west-2)、ストレージは米国東部 (バージニア北部) リージョン (us-east-1) です。標準の AWS リージョン間データ転送コストが発生しますが、これは BigQuery からのクロスクラウド読み取りが同一リージョン内に収まるようにするための意図的な選択です。 不正レコードはストリームをブロックしません。専用のデッドレターキュー (DLQ) テーブル ( <table>_dlq ) が別の S3 Tables バケットに配置され、生のペイロード ( raw_value_b64 ) と skip_reason が保存されます。暗黙のドロップは発生しません。DLQ テーブルは Lakehouse を通じて AWS Glue Data Catalog に登録されているため、エンジニアは Amazon Athena または BigQuery から障害を検査できます。 この時点から、Amazon S3 Tables が信頼できるソースとなります。 核心: クロスクラウドハンドシェイク ここが設計の中核です。BigQuery は Lakehouse フェデレーテッド Apache Iceberg REST カタログ を通じて S3 Tables の Iceberg データを読み取ります。Google Cloud 側の読み取り専用カタログが AWS 上のテーブルを参照する仕組みです。3 つのメカニズムで実現しています。 オープンなカタログ契約 (Iceberg REST) 。 Amazon S3 Tables は Apache Iceberg REST カタログ インターフェースを公開し、 Google Lakehouse も同じ標準を使用します。双方が Iceberg のオンディスクフォーマットと REST カタログプロトコルに合意しているため、変換レイヤーもデータコピーも不要です。BigQuery は Athena や Spark が読み取るのと同一の Iceberg データファイルを読み取ります。 Google Cloud 側では単一の Lakehouse フェデレーテッドカタログ です。アナリストにはテーブルが talabat-data.s3tables-glue.catalog.orders として表示されます。 クロスクラウドのアイデンティティと信頼 (IAM と OIDC) 。 Lakehouse カタログは、Google マネージドのサービス ID (Lakehouse REST カタログサービスアカウント) として AWS に認証します。 AWS Identity and Access Management (IAM) ロールが accounts.google.com との OpenID Connect (OIDC) フェデレーションを通じてこのサービス ID を信頼し、 sts:AssumeRoleWithWebIdentity でサービスアカウントの数値 ID をロールの信頼ポリシーにピン留めしています。S3 Tables Iceberg エンドポイントへのリクエストは SigV4 署名されます。他の AWS SDK が使用するのと同じ AWS リクエスト署名スキームで、S3 Tables サービスにスコープされています。つまり、ハンドシェイクはプロプライエタリなコネクターではなく、信頼された外部 ID が実行する標準の AWS リクエスト署名です。 信頼は AWS 側で Infrastructure as Code (IaC) としてコード化されており、最小権限が付与され、いつでも取り消し可能です。次の図は認証シーケンスを示しています。 図 3: Lakehouse カタログと AWS IAM 間のクロスクラウド認証シーケンス この信頼関係のステップバイステップのウォークスルー (IAM ロールの作成、トークンのオーディエンスとサブジェクトの検証、信頼ポリシーへの Lakehouse サービスアカウント ID のピン留め) については、 Create and manage AWS Glue federated datasets および Set up cross-cloud Lakehouse for AWS Glue を参照してください。 メタデータ同期 (約 5 分間隔のリフレッシュ) 。 フェデレーテッドカタログは、S3 Tables のフロントとなる AWS Glue Data Catalog からテーブルメタデータを定期的に同期します。新しく作成されたテーブルや新データは、短いリフレッシュサイクル (約 300 秒) で BigQuery から参照可能になります。読み取りはライブの Iceberg データに対して行われ、同期されるのはカタログポインターのみです。 結果として、AWS 上で一度書き込まれたテーブルは BigQuery で通常のカタログオブジェクトとして表示され、標準 SQL でクエリできます。一方で、バイトは AWS から出ず、フォーマットはオープンなままです。 Infrastructure as Code: クロスクラウド信頼面 以下のセクションでは、アーキテクチャ図に示した認証ハンドシェイクを説明します。Lakehouse カタログサービスアカウントが Google OIDC JSON Web Token (JWT) を提示し、AWS が IAM OIDC プロバイダーを通じて検証し、読み取り専用の S3 Tables アクセスにスコープされた短期間の認証情報を返します。 Google を信頼された ID プロバイダーとして登録する。Lakehouse カタログのサービスアカウントにスコープされます。 resource "aws_iam_openid_connect_provider" "google" { url = "https://accounts.google.com" client_id_list = [var.lakehouse_sa_audience] #Lakehouse REST-catalog serviceaccount } 信頼を特定の ID に限定する。ここがセキュリティの核心です。ロールは、サブジェクトがサービスアカウントに一致する Google 署名トークンを通じてのみ引き受け可能です。sub クレームの条件が他のすべてのプリンシパルを排除します。 data "aws_iam_policy_document" "trust" { statement { actions = ["sts:AssumeRoleWithWebIdentity"] principals { type = "Federated" identifiers = [aws_iam_openid_connect_provider.google.arn] } condition { test = "StringEquals" variable = "accounts.google.com:sub" values = [var.lakehouse_sa_subject_id] # nobody else can assume the role } } } resource "aws_iam_role" "lakehouse_read" { name = "bq-lakehouse-read" assume_role_policy = data.aws_iam_policy_document.trust.json max_session_duration = 43200 # 12-hour sessions, then re-issued } 読み取り専用の最小権限を付与する。引き受けたロールには、AWS Glue を通じたカタログメタデータの読み取りと S3 Tables を通じた Iceberg データへのアクセスに必要な権限のみが含まれ、IAM ポリシーで保護され、書き込み可能なものはありません。 statement { actions = [ "glue:Get*", "s3tables:GetTable", "s3tables:GetTableData", "s3tables:ListTables", "s3tables:ListTableBuckets", "s3tables:GetTableMetadataLocation", "s3tables:ListNamespaces", "s3tables:GetNamespace","s3tables:GetTableBucket" ] resources = [var.s3tables_bucket_arn, "${var.s3tables_bucket_arn}/*"] } Google 側のカタログをこのロールに紐付ける。Lakehouse フェデレーテッドカタログ自体はパイプラインとは別に事前作成 (一回限りの gcloud コマンド) され、前述のロールに紐づけられるため、すべての読み取りが信頼された ID を提示します。AWS キーが Google Cloud に存在することはありません。 gcloud iceberg catalogs create s3tables-glue \ --federated-catalog-type=GLUE --glue-aws-region=us-east-1 \ --glue-aws-role-arn=arn:aws:iam::<account>:role/bq-lakehouse-read これら 4 つのステップがハンドシェイクの全体像です。信頼された発行者、サービスアカウントのみが引き受けられるロール、最小権限の読み取り許可、そしてそのロールにバインドされたカタログです。 運用上の教訓: メタデータをファーストクラスの関心事として扱う オープンなフェデレーテッドカタログをクラウド間で運用する中で、テーブルメタデータをファーストクラスの運用上の関心事として扱うことの重要性を学びました。具体的には以下を意味します。 スナップショット保持 : Iceberg のスナップショット保持期間を短く設定し、テーブルごとのメタデータをコンパクトに保ち、確実に同期できるようにする。 コンパクション : S3 Tables 組み込みのメンテナンス設定を通じて、テーブルメンテナンス (コンパクションとスナップショット期限切れ) を統一的なサービスマネージドポリシーとして標準化する。 スキーマ進化 : Protobuf スキーマが進化 (後方互換の追加) すると、Spark ジョブが S3 Tables 内の Iceberg スキーマにカラムを追加・削除する。フェデレーテッドカタログは次の同期サイクルで変更を検出し、BigQuery は手動介入なしに変更を反映する。 設定方法さえ分かってしまえば小さく明確な設定項目にすぎませんが、カタログが正常に動作するか、時間とともにずれていくかの分かれ目です。 データ参照はエンジンの選択であり、コピーの選択ではない ソースがライブになった後、同一の Iceberg テーブルに 1 つの物理データセットから 3 つの方法でアクセスできます。 BigQuery ユーザー は標準 SQL でクエリし、Google Cloud ウェアハウスの他のデータと結合できる。 インフラエンジニア はアドホック確認や継続的インテグレーション (CI) バリデーションのために Amazon Athena で同じクエリを実行できる。 データサイエンティスト は BigQuery や Athena を経由せず、Spark で直接テーブルを読み取れる。 夜間エクスポートを待つ必要はなく、3 つの異なるコピーを照合する必要もありません。コピーは 1 つだけです。 パフォーマンスとコストへの影響 定性的なメリットは既に明らかです。 ニアリアルタイム分析のための数分レベルの鮮度を持つ Raw データ。従来アーキテクチャのレイテンシーはデータ量の問題ではなく設計上の制約でした。インジェスト自体は 5 分間隔で実行されていましたが、下流の 1 時間バッチジョブがエンドツーエンドの鮮度を 60〜90 分に制限していました。カタログフェデレーションにより、同じデータが生成から数分以内にクエリ可能になります。イベントの 95% が 5 分以内、レイテンシーに敏感なミッションクリティカルなワークロードでは 100% をカバーするようにパイプラインを調整する選択肢もあります。 S3 Tables に 1 つのストレージコピー、3 つのコンピュートエンジン。BigQuery、Athena、Spark またはその他の Iceberg 互換エンジンが Amazon S3 Tables 内の単一の物理 Iceberg データセットを読み取り、ストレージの重複とコピー同期に伴う照合コストを回避します。 ホットパスでのクロスクラウドエグレスなし。インジェストは AWS 内で完結します。唯一のクロスクラウドトラフィックは読み取り時のメタデータ同期とクエリ読み取りであり、継続的な書き込みストリームではありません。月次の AWS および Google Cloud データ転送料金、オーケストレーションオーバーヘッド、多層 ETL ワークフローコスト、ストレージバックアップ料金の内部比較に基づき、talabat は同等のデータボリュームでデータ移動コストを約 40% 削減しました。比較は継続的レプリケーションパイプラインの削除前後の 2 か月間にわたり、月間数百テラバイトの反復的なクロスリージョンおよびクロスクラウドデータ転送を排除しました。 オープンテーブルフォーマット、ロックインなし。Raw の Bronze データレイヤーが Amazon S3 Tables 内の Apache Iceberg であるため、データは特定のクエリエンジンやクラウドに囲い込まれません。新しいコンシューマーはエクスポートを要求する代わりに、Iceberg 対応のインターフェースで接続するだけです。 ガバナンス可能なクロスクラウドアクセス。クロスクラウドの境界は、常時稼働のデータパイプラインではなく、IAM 信頼関係 (最小権限、監査可能、取り消し可能) で保護されています。BigQuery 内のエンドユーザーアクセス制御は、GCP のネイティブなロールベースアクセス制御 (RBAC) とフェデレーテッドカタログのきめ細かなアクセス制御で別途管理されます。 今後の拡張 今後は、残りの高価値イベントストリームとバッチストアをハイブリッドな単一設定パターンに取り込み、ソースカバレッジを拡大する予定です。エンドツーエンドの鮮度目標とその周辺のオブザーバビリティ (バッチレベルのメトリクス、デッドレター監視、カタログ同期の正常性) を形式化しています。テーブル数が増加してもクロスクラウドカタログが高速かつ信頼性の高い状態を維持できるよう、スナップショット保持とコンパクションの調整を続けます。より広い観点では、Bronze レイヤーを超えた新しいデータセットについても「一度書き込み、任意のエンジンで読み取り」をデフォルトにし、クラウド間の接続基盤としてオープンテーブルフォーマットをさらに活用していく方針です。 まとめ 2 つのクラウドを使うことは、マイグレーションすべき問題として捉えられがちですが、talabat にとっては単に地形です。イベント基盤は AWS が中心であり、分析コミュニティは BigQuery で活動しています。Apache Iceberg を搭載した Amazon S3 Tables を AWS 上の唯一の信頼できるソースとし、クロスクラウド IAM 信頼で保護された Lakehouse フェデレーテッド Iceberg REST カタログを通じて BigQuery に読み取り専用で参照させることで、2 つのクラウドという制約を数分以内にエンジンが読み取れる単一のガバナンスされたデータセットに変えました。書き込みパスは短く、ローカルで、信頼性が高いままです。クロスクラウドの課題は、あるべき場所、すなわち読み取りパスに存在し、データ移動ではなくオープン標準とアイデンティティで表現されています。 これがハンドシェイクです。AWS 上にデータのコピーを 1 つ、オープンなカタログ契約、そしてクラウドの境界を越えてデータを読み取るための署名された、信頼された、取り消し可能なアイデンティティです。 本記事では BigQuery から AWS 上のデータを読み取ることに焦点を当てました。他のシステムから AWS Glue Data Catalog へのカタログフェデレーションを含む、より広範なマルチクラウド Lakehouse パターンについては、 Multi-cloud Lakehouse architecture on AWS for agentic AI を参照してください。 著者について Harish Ramesh Harish は、talabat の Staff Data Engineer です。小売、ヘルスケア、メディア、物流、ホスピタリティ、FMCG など幅広い業種で大規模データプロダクトを構築してきた経験を持ち、talabat でデータプラットフォームの構築と管理に注力しています。 Raghunandana Krishna Murthy Sanur Raghu は、talabat における Data Engineering and Machine Learning Platform の Senior Manager です。データおよび機械学習プラットフォームのアプリケーションとインフラストラクチャを開発するチームのリードを専門としています。 Lakshmi Nair Lakshmi は、AWS の Principal Analytics Specialist Solutions Architect です。業界横断で高度な分析システムの設計を専門とし、クラウドベースのデータプラットフォームの構築、リアルタイムストリーミング、ビッグデータ処理、データガバナンスの確立に注力しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本ブログは ハイテクインター株式会社 様と 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 のスマートシティソリューション をご覧ください。 ソリューションアーキテクト 伊勢田氷琴