2026 年 8 月 4 日、「製薬企業向け Claude Code on AWS ワークショップ 〜創薬研究を加速する AI コーディングエージェントの活用〜」を開催しました。10 社以上の製薬企業から創薬研究者と研究 IT のご担当者にお集まりいただき、ハンズオンを中心に、実際に Claude Code on AWS の導入を進める第一三共株式会社とＪＣＲファーマ株式会社、および Anthropic Japan 合同会社による登壇セッションも実施しました。 参加者は、AI コーディングエージェントを初めて使う方から、既に研究業務で Claude Code を活用している方まで様々でしたが、アンケート（回答 47 件）の総合満足度は 4.70 / 5.00 であり、「ワークショップに参加して世界が変わった」「わずか半日で欲しい研究アプリが作れたことに感動した」「自社で利用していく際のイメージが掴めた」といった声をいただくなど高い評価をいただくことができました。 本記事では、イベントの背景や当日の様子をお届けいたします。 目次 ワークショップのゴール 開催の背景：AI for Science の現在地と実践 ハンズオンの内容: 創薬研究の仕事はどう変わるか ハンズオン実行環境：Claude Code を組織で安全に活用するには お客様登壇: 先行する創薬研究現場での実践 第一三共株式会社 ＪＣＲファーマ株式会社 Anthropic Japan 合同会社様登壇: 研究者自身が AI エージェントを使う意義 体験を組織の実践へ まとめ ワークショップのゴール 本ワークショップが目指したのは、Claude Code の細かな機能やプロンプト技法の習得ではありません。参加者自身の研究テーマや興味のある題材を用いて、AI とともに創薬研究の様々な業務に取り組み、研究の進め方や研究者の役割がどう変わるかを体感していただくことです。何を AI に任せられ、何を人間が行うべきかは、実際の業務に近い領域で使い込んでこそ初めて見えてきます。そのため、いち早く実践を始め、 AI が創薬研究にもたらす可能性と人が担うべき役割を見極め、今後の研究の進め方を考える契機にしていただくべく、本ワークショップを企画しました。 開催の背景：AI for Science の現在地と実践 ライフサイエンス業界を取り巻く現状として、AI が具体的な創薬成果につながり始める一方、組織展開には大きな隔たりがあります。  Deloitte 社の調査 によると、ヘルスケア・ライフサイエンス企業を対象とした調査で、AI をうまくスケールできたとの回答は 22%、AI への取り組みで大きなビジネス成果を得たとの回答はわずか 9% にとどまりました。その一方で、例えば Insilico Medicine は AI で創出した特発性肺線維症の治療薬候補について  Phase III 臨床試験を開始したと発表 しているなど、AI 活用を実際の創薬成果に繋げる企業と展開に苦戦する企業との差が開きつつあります。 一度の回答から情報収集、計画、作業、検証という一連の仕事へと広げる AI エージェントは、仮説を立て解析や実験を行う創薬研究とも重なり、研究者は問いと判断に集中するという新しい役割分担を可能にします。ただ多くの企業が同じフロンティアモデルを利用できるいま、差を生むのはモデル性能やツール導入ではありません。自社の知見や業務の型を AI エージェントに正確に与え、AI エージェントに何を任せどこで人が介入するかを設計して初めて、研究現場で大きな成果を生む形になります。こうした設計の力は、実際に近い業務で試行錯誤しなければ体得できず、その第一歩になればと今回のイベントの企画に繋がりました。 今回題材としたのは、Anthropic が開発する代表的な AI コーディングエージェントである Claude Code です。コード生成に限らず、調査や分析、成果物の作成など研究の様々な業務で活用できます。AWS と Anthropic は戦略的協業を結んでおり、AWS は Anthropic のプライマリクラウドプロバイダーとして、お客様が Claude をセキュアかつ大規模に活用できる環境を提供しています。 ハンズオンの内容: 創薬研究の仕事はどう変わるか ハンズオンは二部構成でした。前半では研究上の判断を支える調査とレポート作成を行い、後半ではその判断プロセスないし関心のある研究業務を Web アプリケーションとして AWS 上に構築しました。用意されたプロンプトを順番に貼り付けるのではなく、参加者自身が目的と基準を言葉にし、Claude Code に作業を任せ、結果を確かめながら方向を調整しました。詳しいシナリオや当日の操作手順に興味のある方は、 こちらの URL をご覧ください。 前半の題材は、薬の作用先となる複数の分子候補の中から研究で優先するものを選定する「Target Prioritization ( 標的の優先順位付け) 」です。例えば 「原発性高コレステロール血症」という疾患では、 HMGCR、NPC1L1、PCSK9 などが標的候補となりますが、対象患者、既存治療との違い、安全性など、重視する基準を複数定めることによってアプローチするべき候補の優先順位が変わります。 今回、創薬研究者の方々には、関心のある疾患や実際の研究テーマを自ら選んでいただき、選定基準と 2〜5 件の標的候補を Claude Code と対話しながら決めていただきました。創薬研究に馴染みのない方には、AWS 側で事前にシナリオを用意しました。 テーマと基準が固まると、Claude Code が Open Targets、Europe PMC、ClinicalTrials.gov などの公開 API や、AWS が幅広いオープンデータの公開と利用を支援する Registry of Open Data on AWS に掲載されたデータセットも参照しながら根拠を集め、候補比較のレポートを作成します。参加者は出典や反証を確認し、条件を変えた際の順位を検証しながら、判断の理由と不確実性を判断メモにまとめていきました。 実際のハンズオン操作画面。研究アシスタントとして動く Claude Code（右側）と対話しながら、Target Prioritization の分析レポート（左側）を作成していきます。 後半では、前半の判断プロセスや参加者が関心を持つ研究業務を題材に、AI エージェントが動くアプリケーションを AWS 上に構築しました。Claude Code の質問に答えながら要件を固め、設計書を確認して GO を出すと、コード作成、テスト、インフラ構築、デプロイまでが進みます。参加者はコードを書かず、作るものを人と AI で合意してから実装へ進むプロセスを体験しました。 ハンズオン実行環境：Claude Code を組織で安全に活用するには 当日は、Claude の呼び出しに Amazon Bedrock を利用しました。Amazon Bedrock では、入力と出力はモデル提供者に共有されず、基盤モデルの学習にも使用されません。 AWS IAM による権限管理、 AWS CloudTrail による操作記録、 AWS PrivateLink によるプライベート接続など、既存の AWS のセキュリティ統制の中で Claude Code を利用できます。さらに、データレジデンシー要件がある場合は、対応モデルで 日本国内クロスリージョン推論 (Japan Cross Region Inference) を利用することで、推論処理を国内リージョンに限定しデータを日本国内に留めることもできます。 一方、組織への展開には、モデル利用のガバナンスや、会社支給 PC への導入、研究データの扱い、認証・権限、利用者ごとの環境差といった課題があります。研究部門の方々と普段お話しするなかでも、こうした点が個人の試行から組織利用へ進む際の壁として挙がります。 それを解決する選択肢の一つが、今回利用した RADS ( Remote AWS Development Station ) です。 RADS は、 Amazon EC2 ベースのクラウドワークステーションを Web ポータルから構築・管理することができる AWS 公式サンプル実装であり、 GitHub で公開 されています。Web ポータルから Claude Code などがインストールされた AI コーディング環境を作成・起動・停止し、Amazon DCV によるリモートデスクトップ、ブラウザの Code Editor、SSH 等で接続して使うことができます。以下のような特徴があります。 AI 環境がプリセット済み：Claude Code などを Amazon Bedrock 向け設定込みで導入済み API キー配布や初期設定が不要：ワークステーション (EC2) の IAM ロール経由で自社アカウント内の Bedrock を呼び出す PC を閉じても稼働継続：長時間タスクをエージェントに任せられ、マシン性能も変更可能 ローカルに影響しないサンドボックス: 各環境が独立した EC2 インスタンスのため手元の PC に影響が及ばない お客様登壇: 先行する創薬研究現場での実践 当日は、ハンズオンでの体験を実際の業務へつなげる材料として、Claude Code on AWS の研究現場への導入・展開を進める 2 社に、研究部門と IT 部門それぞれの視点からご登壇いただきました。 第一三共株式会社 第一三共株式会社の田村様からは、「Coding Agent で変わる創薬 DRY 解析」と題してご発表いただきました。田村様が所属されている研究部門にて取られた DRY 研究員への社内アンケートでは、92% が「Coding Agent がなくなると業務に影響する」、85% が「時間やスキルが理由で以前はできなかった業務を遂行できた」と回答したとのことです。具体例として、十分な作業時間を確保できず、4 か月間着手できずにいた大量の化合物データの SAR 解析を Claude Code との対話で約 1 時間で完了した事例や、100 件以上の非構造情報を含む文献や特許からデータを抽出した事例、 AWS Parallel Computing Service (AWS PCS) と連携した解析の取組みなどを紹介いただきました。また、定型業務は Agent Skills や プライベート Plugins として GitHub 上のプライベートレポジトリで共有し、個人の成功パターンをチームで再利用できる仕組みも整備されています。ハルシネーションを 100% 防ぐことは原理上できなくても、後段の解析や実験で結果を検証できるため、創薬研究は AI エージェントを活用しやすい領域ではないかとの見解も示されました。 ＪＣＲファーマ株式会社 ＪＣＲファーマ株式会社の東本様からは、「Claude Code on AWS で創薬研究・業務を加速する」と題してご発表いただきました。チャット型 AI では、提示された手順やコードの実行、エラー対応を利用する人間側が担わねばなりません。AI エージェントは、作成・テスト・修正までを自ら進めます。その様子を AWS から提供したワークショップで実際に体感されたことで、自律実行への懸念から、従来の手間を解決できるという見方へ変わったといいます。 導入には、自社の AWS 環境から Amazon Bedrock 経由で Claude を利用する構成を選択しました。国内でのデータ保管、既存のセキュリティ運用の踏襲、従量課金で小さく始められることが決め手となり、AWS のイベントで体験してから約 10 日でリリースに至りました。研究者が環境構築やエラー対応から離れ、解析そのものに集中できる環境を整えられたとのことでした。実際に触れることが、構成の判断と迅速な導入につながった事例です。 詳しくはご寄稿いただいた こちらの記事 もご参照ください。 Anthropic Japan 合同会社様登壇: 研究者自身が AI エージェントを使う意義 2 社の実践に続き、Anthropic Japan 合同会社の渡部様には「信頼できるフロンティア AI」と題してご登壇いただきました。Constitutional AI を含むモデル設計、能力の向上に応じて安全対策を強化する責任あるスケーリング、顧客データを学習に使用しない方針など、規制産業で活用するための信頼性への取り組みと、Anthropic が一般提供する中で最も高性能なモデルである Claude Fable 5 の最新動向が紹介されました。 Claude Code のハッカソン「Built with Opus」では、入賞した上位 5 組のうち 4 組が職業エンジニアではない非技術者だったといいます。実装の障壁が下がる現在、課題を深く理解している人の知見が成果を左右することを示す 1 つの事例と言えるでしょう。創薬研究でも、ドメインエキスパートである研究者自身がエージェントを使い、課題設定と評価を担うことが成果を生み出す鍵になります。 体験を組織の実践へ クロージングでは、このハンズオンの中で、何故短い指示からエージェントが一連の作業を進められたのか、その背景をご紹介しました。今回のハンズオンでは、対象とする業務の前提や判断基準をコンテキスト（ CLAUDE.md など）として与え、定型作業を Agent Skills として登録し、MCP で研究データベースや文献検索のツールにつなぎ、計画・実行・検証までのループを回す仕組みをあらかじめ設計し、参加者がハンズオンで利用する操作環境のなかに組み込んでいました。参加者には、その土台の上で Claude Code を使い一連の操作を進めていただきました。こうしたモデル周辺の仕組みは一般に「ハーネス」と呼ばれます。 同じモデルを利用できても、社内の知見、業務手順、システムとの接続は企業ごとに異なります。今回の環境のように、自社の知見や業務の型をハーネスに組み込み、実際に使いながら継続的に更新することで、モデルの進化を研究現場の成果へ素早く反映できます。その準備には、今から使い、学び、改善を重ねる時間が必要です。 エージェントが一連の作業を担うと、人はループの中ですべての工程を実行する立場から、ループの上で目的と進め方を設計し、結果を監督する立場へ移ります。任せる範囲を決め、結果に責任を持つのは引き続き人です。目指すのは、一工程ずつ数十 % の効率化を積み上げるだけでなく、仕事の形そのものを組み替えて数十倍の成果を生み出すことです。 では、こうした変化に向けて何から始めるべきでしょうか？ 今回の参加者には、体験を各社へ持ち帰り、参加できなかった方も含めて、自社の研究テーマで AI に何を任せ、人がどこで判断するかを話し合う機会を作っていただきたいとお願いしました。対象者・人数・題材などを要望に合わせて、AWS とともに個社向けワークショップを企画・実施することも、その議論を具体化する選択肢になります。 また、今の人間中心の業務のやり方を変えていくことも重要です。業務プロセスを AI エージェント前提に組み替える  AI-BPR (AI-driven Business Process Re-Engineering)  や、開発サイクル全体を AI 主導で進める  AI-DLC(AI-driven Development Life Cycle; AI 駆動開発ライフサイクル)  の実践が選択肢の一つです。さらに、今回利用した RADS などを活用して、 Claude Code on AWS を組織的に利用・展開できる環境を早期に整えることで、個人の体験を組織の変革へつなげられます。 AWS は、お客様とともに課題と目指す姿を整理し、進め方の検討から実践、展開まで支援していきます。 まとめ Claude Code のような AI コーディングエージェントが変革するのは、解析コードの書き方ではなく、創薬研究の進め方そのものです。AI が調査や実装を担い、研究者が問いと判断に集中する働き方は、すでに現実になりつつあります。 その変化を先取りするには、いち早く自らの研究テーマで触り、AI への任せ方と人の判断を組織で学ぶことが欠かせません。AI コーディングエージェントが自社の創薬研究をどう変え得るのか、まずは実際の題材で確かめてみてください。 AWS は、こうしたワークショップを起点に、AI エージェントへの理解と活用を組織に広げ、プロセスの変革と創薬加速につなげる取り組みを今後も支援していきます。ワークショップの実施やその先の組織展開などにご関心をお持ちの方は、担当の AWS アカウントチームまでご相談ください。 執筆者 森下 裕介 (Yusuke Morishita) ライフサイエンス領域や医療機器領域のお客様を担当するソリューションアーキテクトです。医用画像の機械学習研究を経て、現在は生成 AI や AI エージェント領域を得意分野として活動しています。趣味は旅行と映画鑑賞。 原田 裕平 (Yuhei Harada) 製薬・ライフサイエンス領域のお客様を担当し、AI エージェントを活用した研究開発の高度化や、近年は Physical AI 分野での活動も精力的に行っています。 石尾 千晶 (Chiaki Ishio) 製薬・医薬品卸領域のお客様を担当し、クラウドや生成 AI の活用の技術支援を行っています。 川合 広喜 (Hiroki Kawai) 主に製薬業界のお客様を中心に営業支援を行っております。クラウド移行から生成 AI の活用まで、お客様の課題に応じたご支援を心掛けています。 亀田 俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略 (DTx 含む) を得意としています。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

こんにちは、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 がレビューしました。