リクルートのデータ推進室長 野村が自ら聞き手となり、現場の最前線で試行錯誤を続けるスペシャリストたちの「手の内」を紐解く連

AIエージェント開発でLLM as a Judgeを機能させるには、評価AIを用意するだけでは不十分です。人間の暗黙知を評価基準へ落とし込み、実行ログをテストケースとして蓄積し、評価器であるLLM自体のズレも継続的に点検する運用設計が必要です。 こちらの記事 では、AIがAIを評価する仕組みである「LLM as a Judge」の基本的な考え方を紹介しました。しかし、実際にLLM as a Judgeを導入するのはそう簡単ではありません。 本記事では、dotDataで開発した「UseCase Advisor（UCA）」を例に、LLM as a Judge導入を成功させ、効率よく運用するための知見を紹介します。特に、次の3点に焦点を当てます。 評価基準を作る: 人間の暗黙知やフィードバックを、評価可能な観点へ分解する ログをテストケース化する: 実運用で得た対話ログを、将来の品質保証に使える評価資産へ変える Judge Driftをメタ評価で検知する: 評価AIの判定が人間の判断からずれていないかを点検する 1. AIエージェント開発に立ちはだかる「80点の壁」 LLM（大規模言語モデル）の登場により、AIエージェントの開発は驚くほど容易になりました。優れたAPIやフレームワークを組み合わせれば、数日、場合によっては数時間でプロトタイプを作ることも珍しくありません。 しかし、プロトタイプが動くことと、商用サービスとして安心して提供できることは別の話です。実際には、多くの開発プロジェクトで最後の20点を詰める作業に最も時間がかかります。 dotDataが開発しているAIエージェント「UseCase Advisor（UCA）」でも同じでした。 UseCase Advisorは、dotDataのデータ分析プラットフォーム「 dotData Insight 」に搭載されたAIエージェントです。dotData Insightは、分析に詳しくないビジネスユーザーでも高度な分析が可能な分析プラットフォームで、独自のAIが業務データから重要なパターンを自動探索し、ビジネスKPIに関連するインサイトを発見します。 UseCase Advisor（以下、UCA）は、その中でも「データを活用したいが、どんなテーマで何を分析すべきか分からない」というビジネスユーザーの悩みに向き合う壁打ちツールです。分析に着手する前に、ユーザーの業務課題を対話形式で深掘りし、分析ユースケースを整理。具体的な分析テーマの提案からKPI・評価指標の設定まで、データ分析の企画書としてとりまとめます。 このようなAIエージェントでは、一度のプロンプトで回答が完結するわけではありません。ユーザーへの問診、追加質問、回答内容を踏まえた企画書の修正など、複数回の対話を経て最終的な成果物を生成します。そのため、ユーザーの入力や対話の流れによって生成結果が大きく変わります。 従来のソフトウェアのように、「この入力なら、この出力が正しい」というテストケースだけで品質を保証することはできません。 その結果、開発現場では次のような課題が生じます。 テストケースを十分に用意できない 出力品質を人手で確認する負荷が大きい 「なんとなく良い」「少し違う」といった判断が属人的になる 改善によって本当に品質が向上したか客観的に判断しにくい UCA開発でも当初は、開発者が数件の対話を確認して品質を判断する、いわゆる「バイブスチェック」に頼らざるを得ませんでした。しかし、この方法では品質改善を継続的に進めることはできません。 そこで導入したのが、LLMにより評価を自動化する仕組みである LLM as a Judge です。 2. AIエージェント開発でLLM as a Judgeを導入する際に直面した課題 しかし、LLM as a Judgeの導入には、大きく2つの課題がありました。1つは評価基準をどう具体化するか、もう1つは評価データをどう育てるかです。 課題①：評価基準の具体化 ─ 人間の暗黙知をどう評価基準へ落とし込むか LLM as a Judgeで評価用のAI（評価AI）に人間の評価を代替させるには、「何を良い出力と判定するか」を定義した評価基準（ルーブリック）の定義が不可欠です。評価基準が曖昧なままでは、LLMによる自動評価も一貫した結果を返せません。 一方で、実際のAI開発では、必要となる評価基準をあらかじめすべて定義しておくことは現実的ではありません。UCAの開発では特に、「適切な問診」「質の高い企画書」といった判断基準の多くが分析コンサルタントが持つような暗黙知であり、開発初期の段階では何を評価項目として定義すべきか自体が明確ではありませんでした。 そのため重要なのは、最初から完璧な評価基準を作ることではなく、ユーザーフィードバックや改善要望をもとに、人間の暗黙知を少しずつ評価基準へ落とし込み、継続的に評価基準を強化していくことです。 課題②：評価データの具体化 ─ 現実的なテストケースをどう育てるか AIとユーザーの対話が複雑になると、テストケースは無限の組合せを持ちます。分析企画書の作成では、ユーザーへの問診、回答内容に応じた追加質問、フィードバックを踏まえた企画書の修正など、複数の対話プロセスを経て最終的なアウトプットを生成します。そのため、エージェントへの入力パターンは非常に多岐にわたります。ユーザーの業種や課題だけでなく、回答の粒度や曖昧さ、途中で寄せられるフィードバックによっても、エージェントがたどる経路や生成結果は大きく変化します。 こうした無数の入力パターンを、あらかじめテストケースとして網羅することはできません。実運用で得られるログを効率よく継続的に評価データとして蓄積し強化するプロセスが必要です。 3. LLM as a Judgeを機能させる改善サイクル そこで、AI機能の開発では、最初から高品質なシステムを作り込むのではなく、検査不足でも利用可能な状態を作った後早くリリースし、社内の関係者やテストユーザーから実際のフィードバックを収集することが重要です。これにより、「どのような出力が望ましいのか」「どのようなケースで失敗しやすいのか」といった、品質そのものを定義するための情報を蓄積し、評価基準・テストケース、AIエージェントの三つを改善する3つのサイクルを回します。 ① 評価基準の強化：暗黙知を評価基準へ反映 ユーザーから寄せられる「分かりにくい」「期待と違う」といったフィードバックは、そのままではLLM as a Judgeの評価基準として利用できません。重要なのは、その背景にある原因を分析し、評価可能な観点へ分解することです。 例えば、ユーザーテストで「UCAの問診が難しくて、どう答えていいか分からない」というフィードバックが寄せられたケースを考えます。このフィードバックだけでは、評価基準としては曖昧です。 そこで「何が難しさを生んでいるのか」を分析し、原因を評価可能な観点へ分解する必要があります。この例の場合、 専門用語の壁 ：分析用語（目的変数など）が説明なく使われていないか 意図・ガイドの不足 ：質問の目的や回答例が十分に示されているか 認知負荷の高さ ：一度に多くの情報を求め、回答しづらくなっていないか このようにフィードバックを具体的な観点へ分解することで、「用語の平易性」「意図とガイドの提示」「認知負荷の軽減」といった評価基準を追加できます。このように、実際のフィードバックや改善事例を通じて評価観点を継続的に追加・見直し、人間の暗黙知を少しずつ評価基準として資産化していくことが重要です。 LLM as a Judgeの価値は、単にスコアの割り当てを自動化することではなく、このような改善サイクルを通じて評価基準そのものを継続的に管理できる点にあります。こうして言語化された評価基準をLLM as a Judgeの評価プロンプトに組み込むことで、新しい基準が反映されます。人間が毎回目視で判断していたプロセスを、AIが一貫した基準で担えるようになります。 ② ログの資産化：生データを「テストケース」へ 実運用で得られた実行ログを継続的に収集し、失敗したケースや判断に迷ったケース、特徴的な対話をテストケースとして保存・管理することが重要です。こうして蓄積されたテストケースは、一度限りのログではなく、将来の品質保証に活用できる評価資産になります。AIエージェントを改善した後も同じケースを繰り返し評価することで、品質向上の確認だけでなく、劣化の検知にも利用できます。 ③ AIエージェントの改善：継続的なアップデートと品質維持 評価基準とテストケースが整備されると、AIエージェントを改善するたびに、その効果を継続的かつ効率的に評価できるようになります。AIエージェントを改善した際には、過去に保存した同じテストケースに対して再度評価を実施することで、改善したかった項目が実際に向上しているかを確認できます。 一方で、ある機能を改善した影響で、これまで問題なく動作していた別のケースの品質が低下してしまうこともあります。例えば、回答を簡潔にする改善によって必要な説明まで削られてしまったり、専門用語を分かりやすく説明する改善によって別のケースでは冗長な回答になったりすることがあります。このような意図しない品質劣化（デグレード）を早期に検知し、修正できることも、テストケースを蓄積する大きな価値です。 さらに近年では、LLM as a Judgeによる評価結果を利用して、プロンプトやエージェント全体を自動的に改善する技術も登場しています。例えば、 DSPy では、あらかじめ定義した評価指標（Metric）を目的関数として、プロンプトやFew-shot例を自動探索・最適化するMIPROv2や、実行ログや自然言語フィードバックを利用して改善を繰り返す GEPA などの最適化手法が提供されています。これらは、「評価」と「改善」を自動的に結び付けるアプローチとして注目されています。 このように、評価基準・テストケース・AIエージェントの改善を一つのサイクルとして継続的に回すことが、AIエージェントの品質を効率よく向上させるポイントです。 4. LLM as a Judgeを継続的に機能させるポイント 評価器であるLLM（評価AI）も、長期運用の中で判定基準が徐々に変化する可能性があります。LLM as a Judgeを継続的に機能させるには、 適切にAIと人間の役割分担すること と、 評価器自体の品質を監視すること が重要です。 AIと人間の役割分担 AIと人間の役割を以下のように分けたHuman-in-the-loop（人間が評価ループに介在する設計）の運用を推奨します。 AIの役割：大量データの一次評価 評価AIは、実行ログを継続的に評価し、問題がありそうなケースを抽出します。LLMは確率的に動作するため、同じ入力でも評価結果がわずかに変動します。そのため、1回の評価結果だけで判断するのではなく、複数回評価の平均と分散を確認することが重要です。分散が大きい（＝判定がぶれている）ケースを「迷い」として数値化し、確信度が低いものは人間へ引き継ぎます。 人間の役割：判断と評価基準の更新 人間は、AIが判断に迷ったケースを重点的に確認します。また、新機能の追加やユーザー要求の変化に応じて、「何を良い出力とするか」という評価基準自体を継続的に見直します。 Judge Driftの検知：評価AIの品質を保つ 長期運用では、評価AI自体の品質が徐々にずれるJudge Drift（評価指標の乖離）が発生します。 Judge Driftは、たとえば次のような要因で発生します。 基盤モデルのアップデートにより、同じ評価プロンプトでも判定傾向が変わる アプリケーションの機能追加により、以前の評価基準では品質を捉えきれなくなる ユーザーの要求水準が上がり、良い出力の定義が変化する 人間側の評価観点が更新されたのに、評価プロンプトへ反映されていない メタ評価：AIの評価結果を人間が検品する このズレを検知するために、dotDataはメタ評価（Meta-Evaluation）の仕組みを取り入れています。メタ評価とは、評価AIの判定が人間の感覚とずれていないかを評価する、二重のフィードバックループです。 運用では、評価AIの評価結果に対して、定期的に人間がサンプリング検品を行います。AIが過大評価したケース、過小評価したケース、人間の評価と割れたケースを分析し、評価プロンプトやテストケースへ反映します。 この改善ループでは、次のような更新を行います。 評価プロンプト内の判定基準をより厳密にする 人間が修正した正解例を新しいベンチマークとしてテストケースへ追加する 評価軸の粒度を見直し、曖昧な評価項目を分解する 確信度が低いケースを重点的にレビューする LLM as a Judgeを長期運用するには、評価AIもまた評価対象として扱う必要があります。評価AIの品質保証まで含めて設計することで、自動評価システムへの信頼性を保ちやすくなります。 5. LLM as a Judge運用に向けた提言まとめ UCAの開発を通じて見えてきたのは、LLM as a Judgeの成否は、評価モデルの性能だけで決まらないということです。むしろ、評価対象、評価基準、人間の判断、改善プロセスをどうつなぐかが重要です。 実務上のポイントは、次の3つです。 まずリリースし、ログを集める : 開発者が想像したテストケースだけでは、実際のユーザー入力を十分に再現できません。ユーザーが入力した生のログこそが、AIエージェントが進化すべき方向を示す重要な材料になります。 評価観点を資産化し続ける : カジュアルに集まったフィードバックや失敗ログを、テストケースと評価基準へ還元します。複数回試行による確信度の算出やメタ評価を通じて、評価の品質そのものも改善し続けます。 評価器自身の品質も継続的に改善する : LLM as a Judgeは一度設計すれば維持できるものではありません。基盤モデルのアップデートや要件の変化により、評価基準は徐々にずれていきます。評価AIのスコアと人間の判断を定期的に照合し、評価プロンプト自体を見直す仕組みを持つことが、長期運用での信頼性を支えます。 複雑化するAIエージェント開発では、データとフィードバックに基づく継続的な改善プロセスが、品質向上の土台になります。 6. dotDataが提供するビジネスユーザーに寄り添った分析AI dotDataは、創設以来一貫して「高度なデータサイエンスを、誰もがビジネスの現場で使える形にする」という考え方を掲げています。UCAも、その考え方を生成AIの技術で具体化する取り組みの一つです。 AIが生成したアウトプットだからといって、品質の曖昧さを受け入れる必要はありません。専門家が持つ暗黙知を評価基準やテストケースへ変換していくことが、ビジネス現場で実用に耐えるAIをつくるうえで重要です。 感覚（バイブス）に頼る開発の壁を感じている方は、ぜひdotDataとともに、データとシステムに基づいた確かなLLMアプリケーション開発への一歩を踏み出してみませんか。ぜひお気軽に お問い合わせ ください。 The post LLM as a Judgeの運用知見：AIエージェント開発で『暗黙知 → 評価指標 → 自動評価』をどう繋いだか appeared first on dotData .

本記事は 2026 年 6 月 29 日 に公開された「 Scale analytics with Amazon Redshift multi-warehouse enhancements 」を翻訳したものです。 Amazon Redshift のリモートテーブル DDL の改善、マテリアライズドビューの機能強化、ゼロ ETL および 自動コピー向けの同時実行スケーリング拡張により、大規模なアナリティクスワークロードを効率的にオンボードできるようになりました。 組織がアナリティクス機能を拡張する際には、本番環境の運用を中断せず、単一のデータウェアハウスのリソースに制約されずにワークロードを追加できる柔軟性が求められます。本記事では、 Amazon Redshift のマルチウェアハウスおよびスケーリング機能を強化する新機能として、リモートマテリアライズドビュー (MV) 操作、リモートテーブル DDL サポート、ゼロ ETL および S3 イベント統合向け同時実行スケーリングの拡張を紹介します。各機能を組み合わせることで、Amazon Redshift 上でスケーラブルかつ高パフォーマンスな分散型アナリティクスアーキテクチャを構築できます。 マルチウェアハウスの新機能で大規模アナリティクスをどのように実現できるか確認していきましょう。 リモートマテリアライズドビュー操作の新機能 Amazon Redshift では CREATE MATERIALIZED VIEW がユーザーワークロードとして分類される ようになりました。リソース競合時に同時実行スケーリングが追加のウェアハウスで MV ロジックを実行できるため、高負荷時でもクエリが MV のパフォーマンスメリットを安定して享受できます。 Amazon Redshift で リモートデータ共有上での MV 作成 がサポートされるようになりました。Redshift ウェアハウス間でデータを共有しているお客様が、ローカルデータと共有データの両方で MV のパフォーマンスメリットを活用できます。 コンシューマーウェアハウスで、 プロデューサーで作成された MV のリフレッシュや、データ共有された MV の上に MV を作成 できるようになりました。データ共有アーキテクチャのプロデューサーとコンシューマーのウェアハウス間で MV の機能が完全に同等になりました。 リモートテーブル DDL 操作の新機能 ALTER TABLE ALTER DISTSTYLE 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスで動作するようになりました。分散環境全体でデータ分散を動的に最適化し、データ移行なしでクエリパフォーマンスとリソース使用率を改善できます。複数のウェアハウスにまたがるパフォーマンスチューニングを行うデータエンジニアや、変化するクエリパターンに対応する管理者にとって特に有用です。 ALTER TABLE APPEND 操作が、同時実行スケーリングとデータ共有を通じてリモートウェアハウスに拡張されました。分散環境間でデータを統合でき、複雑なデータ移動や ETL プロセスなしで効率的にテーブルを結合できます。複数環境にまたがる動的テーブル操作を管理する組織が、運用負荷を軽減しながらデータの一貫性を維持できます。 同時実行スケーリングの改善 Amazon Redshift の拡張された ゼロ ETL 機能が同時実行スケーリングをサポート し、アプリケーションやオペレーショナルソースからの自動データ取り込みに対応しました。 Amazon Redshift の拡張された 自動コピー機能が同時実行スケーリングをサポート し、S3 からの自動データ取り込みに対応しました。 Amazon Redshift の同時実行スケーリングが Amazon S3 からの COPY クエリをサポートするようになりました。バッチワークロード向けに 同時実行スケーリングでデータ取り込みを自動的にスケール できます。 同時実行スケーリングの拡張により、既存のウェアハウスパフォーマンスを損なわずに一貫したデータ鮮度を維持できます。アナリティクスとデータロードのトレードオフが解消されます。同時実行スケーリングを有効にする以外に、追加の変更は不要です。 お客様のユースケース ここでは、金融サービスとゲーム業界の 2 つのユースケースを紹介します。 金融サービスのユースケース 以下は、グローバル展開する大手金融サービスのお客様のサンプルアーキテクチャです。同社は Amazon Redshift 上にマルチウェアハウスアーキテクチャを構築しています。 ステージング (STG) ウェアハウスは、メダリオンアーキテクチャのブロンズレイヤーのように、さまざまなソースからのデータの 生データゾーンです。STG ウェアハウスは 生データのクレンジングと標準化も行い、シルバーレイヤーとして後続処理に利用可能にします。また、MV を使用して数百万件のネストされた JSON メッセージを処理し、属性をスカラーのカラム型 Amazon Redshift テーブルに抽出します。 CREATE MATERIALIZED VIEW rawdb.fsi.customer_orders_raw distkey(c_custkey) sortkey(c_custkey) AS ( SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx FROM customer_orders_lineitem c, c.c_orders o AT o_idx ); REFRESH MATERIALIZED VIEW rawdb.fsi.customer_orders_raw; DWH ウェアハウスはプライマリ Amazon Redshift インスタンスおよびゴールドレイヤーとして、Business Objects や Tableau などのコンシューマーアプリケーションにデータを提供します。ゼロ ETL 同時実行スケーリングの改善により、ゼロ ETL の取り込みスパイクと DWH の高負荷ワークロードが同時に発生しても、一貫したデータ鮮度を維持できます。DWH の MV は、Tableau エクストラクトや Business Objects のライブレポート向けに集約データへの高速アクセスを提供します。DWH ウェアハウスは、DWH インスタンス上で複数の MV をリフレッシュする必要がある場合に同時実行スケーリングを活用します。 CREATE MATERIALIZED VIEW bodb.final.customer_churn_tbl AS ( SELECT state, account_length, area_code, total_charge/account_length AS average_daily_spend, cust_serv_calls/account_length AS average_daily_cases, churn FROM custdb.final.customer_activity_all ); REFRESH MATERIALIZED VIEW bodb.final.customer_churn_tbl; ETL01/02 ウェアハウスはプロジェクト固有の ETL ジョブを実行する専用コンピュート環境として、USR01/02 ウェアハウスは dbt からのアドホック分析やモデル構築などのユーザーワークロードを処理します。ユーザーワークロードに新しいオブジェクトが必要な場合、リモートのプロデューサーウェアハウス (DWH) 上で作成・管理されます。 ALTER TABLE salesdb.final.sales_report_all ALTER DISTKEY sales_id; ALTER TABLE APPEND salesdb.final.sales_report_all FROM stagingdb.sales.sales_2026_02; ゲーム業界のユースケース 大手ゲーム会社は、アナリティクスインフラ全体を AWS 上に構築しており、アナリティクスチームがゲームからのデータストリーミング、データウェアハウジング、BI ツールを管理しています。同社は Amazon EC2 上で稼働していた Vertica から移行し、Amazon Redshift を組織全体で標準化しました。クラスターリサイズ操作に関する初期の課題を克服した後、チームは Amazon Redshift の強力な推進者となり、現在は 32 ノードの ra3.16xlarge でプライマリ本番クラスターを運用しています。 データ取り込みパイプラインの成長に伴い、クエリワークロードがデータ取り込みプロセスと競合し、パフォーマンスのボトルネックが発生しました。プライマリクラスターをスケールアップするのではなく、Amazon Redshift データ共有を使用したワークロード分離戦略を実装しました。プライマリクラスターをプロデューサーとして、16 ノードの ra3.4xlarge クラスターをデータ共有コンシューマーとして起動しました。データ共有アーキテクチャにより、コンシューマークラスターにコンシューマーワークロードを移行し、プロデューサーはデータ取り込みに集中することで、プライマリクラスターのサイズを増やすことなく成長に対応できました。 分散アーキテクチャの利点を認識した同社は、ワークロードを Amazon Redshift Serverless に移行してアプローチを拡大し、ワークロード分離のためにデータ共有モデルをさらに活用しました。Amazon Redshift のリモートマテリアライズドビュー機能により、プロデューサークラスターが共有するデータ上に直接マテリアライズドビューを作成できるようになりました。各コンシューマークラスターが、固有のワークロードパターンに最適化されたマテリアライズドビューを構築できます。事前集約データセット、カスタム結合戦略、ワークロード固有のデータ分散を、プロデューサークラスターのパフォーマンスに影響を与えずデータの重複も不要で実現できました。プロデューサーウェアハウスは汎用的なエンタープライズニーズ向けに設計されたデータ分散とソート戦略を維持し、すべてのコンシューマーに対して一貫したデータ品質を提供します。一方、コンシューマーウェアハウスはリモートマテリアライズドビューを使用して、リアルタイムのプレイヤーアナリティクス、BI ダッシュボード、アドホックなデータサイエンスワークロードなど、固有の分析要件に合わせてクエリパフォーマンスを最適化しました。データ消費を最適化する分散アプローチは同社にとって不可欠でした。プロデューサークラスターを信頼できる唯一の情報源 (Single Source of Truth) として維持し、冗長なデータコピーの管理負荷を回避しながら、多様な分析ワークロード全体で高速なクエリパフォーマンスを実現しました。 ベストプラクティス 新機能を最大限に活用するために、以下のベストプラクティスを検討してください。 Amazon Redshift クラスターおよび Serverless ワークグループで同時実行スケーリングを有効にし、ETL やユーザークエリの実行をさらに高速化して、レポートやダッシュボードのパフォーマンスを安定させましょう。 Amazon Redshift プロビジョンドクラスターおよび Serverless ワークグループの両方で、適切な MaxRPU 設定により同時実行スケーリングの使用制限を設定しましょう。予期しない追加コストの発生を防げます。詳細については、Amazon Redshift の使用制限に関するドキュメントを参照してください。 リモート MV を使用して、リソース集約型の MV 作成やリフレッシュ操作をプライマリウェアハウスからリモートデータ共有クラスターにオフロードしましょう。 まとめ 本記事では、MV リフレッシュの新機能、リモートテーブル DDL 機能、ゼロ ETL および S3 自動コピー向けの同時実行スケーリングサポートの拡張について紹介しました。各機能により、単一ウェアハウスの制約を超えることができます。複数環境にまたがる動的テーブル管理を必要とし、データの一貫性を維持しながら変化するワークロードに迅速に適応する分散データアーキテクチャを管理する組織にとって特に価値があります。利用を開始するには、最新の Amazon Redshift バージョン を実行していることを確認してください。続いて Amazon Redshift のドキュメントで 同時実行スケーリング 、 データ共有 、 マテリアライズドビュー の詳細をご覧ください。 著者について Raza Hafeez Raza は、Amazon Redshift のシニアテクニカルプロダクトマネージャー。エンタープライズデータウェアハウスの構築と最適化に 15 年以上の経験があり、あらゆる規模のお客様にとってクラウドアナリティクスを利用しやすく費用対効果の高いものにすることに注力しています。 Ravi Animi Amazon Redshift チームのシニアプロダクトリーダー。空間アナリティクス、ストリーミングアナリティクス、クエリパフォーマンス、Spark インテグレーション、アナリティクスビジネス戦略など、Amazon Redshift クラウドデータウェアハウスサービスの複数の機能領域を管理しています。リレーショナルデータベース、多次元データベース、IoT 技術、ストレージおよびコンピュートインフラサービスの経験があり、最近では人工知能 (AI) とディープラーニング、コンピュータビジョン、ロボティクスの分野でスタートアップの創業者としての経験もあります。 Satesh Sonti Satesh は、アトランタ拠点のプリンシパルアナリティクススペシャリストソリューションアーキテクト。エンタープライズデータプラットフォーム、データウェアハウジング、アナリティクスソリューションの構築を専門としています。20 年以上にわたり、世界中の銀行・保険のお客様向けにデータ資産の構築と複雑なデータプラットフォームプログラムのリードに携わっています。 Milind Oke Amazon Web Services で 3 年間勤務するシニア Redshift スペシャリストソリューションアーキテクト。AWS 認定ソリューションアーキテクト – アソシエイト、セキュリティ – 専門知識、アナリティクス – 専門知識を保有。ニューヨーク州クイーンズ在住。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。