※本記事は、AWSのプリンシパル・テクニカル・アカウント・マネージャーであるSidhanth Muralidhar氏と、FanDuelのデータエンジニアリング・ディレクターであるOana Sentanai氏による講演「DataOps for AI-Ready Platforms」の内容を基に作成されています。本講演は、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録されたものです。本セッションでは、組織がAIへの取り組みを加速させるなかで、信頼性が高くAIに対応したプラットフォームを支える堅牢なデータ基盤を構築・拡張するうえでDataOpsが果たす極めて重要な役割を探り、次世代データプラットフォームを形づくる新たなトレンドや、今日から準備を始める方法を論じています。また、Amazon BedrockとSageMaker Unified Studioを用いたライブデモを通じて、Customer 360やAIOpsといった実際のシナリオを実演しています。本記事では、講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. セッション概要と現場で見えている課題
1.1 セッションのアジェンダ・登壇者紹介と4つの構成
Sid： 本日のこのセッションでは、私と、FanDuelでエンジニアリングディレクターを務めるAnnaから、データオプスがどのようにしてAIに対応したデータプラットフォームを支えるのかについてお話しします。私はSadhana Murderと申しまして、AWSでプリンシパル・テクニカル・アカウント・マネージャーを務めております。本日はお越しいただき、ありがとうございます。アジェンダとしては4つの観点でこのセッションを進めていきます。まず私が現場で見てきたことをお話しします。私は多くのリーダー、アーキテクト、エンジニア、そしてデータプラットフォームの利用者であるアナリストの方々と仕事をしてきましたので、彼らから聞こえてくる声と、なぜこれからお見せするアーキテクチャについて議論するのかをお伝えします。
Sid： 続いて、次世代のエージェンティックデータプラットフォームがどのようなものかをご紹介します。これはとてもエキサイティングな内容で、本来はライブデモを予定していたのですが、途中で止まってしまうことがないように、あらかじめ録画したものをご用意しました。再生しながら、その都度何が起きているのかを解説していきます。その後はマイクをAnnaに渡し、データオプスとは何か、そしてなぜプロダクションレベルのデータプラットフォームを運用するうえでそれが極めて重要なのかを深掘りしてもらいます。
1.2 リーダーから寄せられる問いとアナリティクスの進化
Sid： まずは現場で何が起きているのかを理解していきましょう。私がリーダーの方々と打ち合わせをすると、よく次のような質問を受けます。「プラットフォームの生産性をどう高めればよいのか」「プラットフォームを使うユーザーの生産性をどう向上させればよいのか」「パフォーマンスの観点でプラットフォームをどう最適化すればよいのか」「どうすれば運用上の卓越性を実現できるのか」、そして同時に「次世代のデータプラットフォームとはどのようなものか、そのロードマップはどうあるべきか」といったものです。こうした会話をリーダーと重ねながら、ロードマップを設定し、その達成を支援していくわけです。
Sid： もう一つ私が強く感じているのは、大規模なデータシステムに対して分析を行ううえでの分析手法の移り変わりです。以前はヒストリカル分析、つまり過去のデータを振り返る分析を行っていました。そこから顧客が行う分析はリアクティブなアナリティクス、さらにアクショナブルなアナリティクスへと移ってきました。しかし最近のリーダーがデータプラットフォームに求めているのは予測的なアナリティクスです。そして彼らは、解決しようとしているユースケースが何であれ、その分析結果に基づいてほぼ即座にアクションを取れるようにしたいと考えています。もしまだ自分たちのユースケースでこれを実践できていないのであれば、これから考え始めなければならないことかもしれません。
Sid： このセッションでは、ゲーミングプラットフォームを例に取って進めていきます。これからお見せする録画デモも含めて、すべてゲーミング業界を題材にしたものになります。ですので、プレイヤー分析の話が多く登場しますし、データレイク上のIcebergをどのようにクエリするのかといった話も出てきます。ここで一つ伺いたいのですが、データレイクが何かをご理解されている方はどれくらいいらっしゃいますか。素晴らしい、よかったです。それでは、こうした前提を踏まえたうえで、具体的なデータセットとユースケースに入っていきましょう。
2. ゲーミング業界のデータセットとユースケースの実演
2.1 Athenaコンソールによるデモ（プレイヤーデータ・S3 Tables・Iceberg・139百万行）と利益率分析
Sid： それでは実際の画面をご覧いただきます。これはAthenaのコンソールです。ここでお見せしたいのは、今回扱うデータセットがどのようなものかという点です。ご覧のとおり、このプレイヤーデータにはユーザーID、ゲーム名、レーティング、セッションの詳細、賭けて獲得した金額、失った金額、さらにはクレジットカードの情報や住所まで含まれています。これらはすべてIceberg形式のS3 Tablesに格納されています。では、このテーブルがどれくらいの規模なのかを見てみましょう。今回扱っているテーブルはおよそ1億3,900万行あります。決して小さなテーブルではありません。これよりも大きなテーブルを扱った経験もありますが、何が起きているのかをお見せするには十分な規模です。
Sid： いま実行しているこのクエリは、このゲーミングデータセットの利益率がどうなっているのかを、ロケーション別に把握しようとするものです。結果を見ると、ある地域では利益率が76%といった形で出力されています。SQLを書いて、その出力が返ってきたわけです。これは今日、誰もが行っていることで、何ら特別なことではありません。ただ、このデータセットがどのように使われているのかを次に見ていきましょう。このデータセットは複数のユースケースにまたがって活用されています。
2.2 活用領域と従来のSQL作成の課題
Sid： このデータセットは、チャーン予測やLTV、すなわち顧客生涯価値の算出に使われています。さらに多くのお客様は、ゲームのパフォーマンス分析や行動分析にもこのデータを利用しています。そしてこのベッティング業界において最も重要なユースケースの一つが、責任あるギャンブリング、いわゆるレスポンシブル・ギャンブリングです。このデータセットを使ってこうした分析を行う場合、クエリがどれほど複雑になりうるかは想像に難くありません。WHERE句が大量に並び、多くのJOINが発生し、さまざまな条件が一つのSQLクエリの中に組み込まれていくことになります。
Sid： こうした前提と、このデータセットでできることを踏まえたうえで、一つのユースケースを考えてみましょう。たとえば誰かがやってきて、こう尋ねたとします。「カリフォルニアに住む高価値プレイヤーのうち、主にカジノゲームをプレイし、過去30日間で5,000ドル以上を入金していて、なおかつエンゲージメントの低下、つまり90日間の平均よりもセッション数が少なくなる兆候を見せている人を見つけ出し、チャーンリスクの高い順にランク付けしてほしい。リテンションのオファーでその人たちにアプローチできるようにするためだ」というものです。これは一つの問いです。では今日、これに対して何が起きるでしょうか。アナリストやエンジニアがそこに行き、そのSQLを書きます。そして誰かがそのSQLを書き上げ、プロダクションに投入するまでには、控えめに見積もっても少なくとも1時間から2時間はかかります。
Sid： しかもこれは、自分がどのカラムを扱っているのかを理解し、どのデータセットをクエリしているのかを理解し、さらにそれをクエリするためにどの技術を使っているのかを理解している、という前提の上での話です。ここで私が「技術」と言っているのが何を意味するかというと、プロダクション環境のデータプラットフォームの中には、データシステムが一つしか存在しないわけではない、ということです。データをクエリするのにAthenaを使うこともあれば、Redshiftを使うこともありますし、EMR、RDS、Auroraなど、いくつものシステムがありえます。なぜなら、データという技術は、複数の異なるエンジンを通じてデータベースをクエリすることを可能にするからです。ですので、クエリを書く際には「そのプラットフォームに対してどうすれば効率的なクエリを書けるのか」も併せて考えなければなりません。まさにここで、次世代のエージェンティックAIを活用したデータプラットフォームが登場するのです。
3. 次世代エージェンティックデータプラットフォーム
3.1 オープンデータアーキテクチャ・データ基盤の卓越性・信頼性と全体アーキテクチャ
Sid： このスライドは、本日の冒頭、オープニングセッションでもご覧になったかもしれません。データの上にエージェンティックなプラットフォームを構築する際には、まずオープンデータアーキテクチャを備えている必要があります。そして、データ基盤の卓越性、つまりデータファンデーションのエクセレンスが最上位に位置づけられるべきです。最後にもう一つ重要なのは、エージェントがあなたのデータと対話するようになったとき、それは信頼に足るものでなければならない、という点です。データが極めて正確であるからこそ、人々はこうしたエージェントを使うことに自信を持てるのです。エージェントを通じて提供されるデータが正しいと分かっているからこそ、安心して使えるのです。
Sid： それでは、アーキテクチャがどのようなものかを見ていきましょう。先ほどAthenaのデモをお見せしたとき、あの11行のSQLコードで特定のデータセットの利益率を出力しましたよね。これがもしエージェントを使った場合には、そのエージェントに対して「このユースケースの利益率を出してくれないか」と尋ねるだけでよくなります。エージェントは「もちろんです、それをSQLに変換してデータベースをクエリします、答えはこちらです」と応えてくれるわけです。それはそれで結構なのですが、今日のエージェンティックデータプラットフォームを構築するということは、それ以上の意味を持ちます。
Sid： このアーキテクチャを右から左へと説明していきましょう。右側にはS3 Tablesがあります。S3 Tablesには、今日の例で言えば1億3,900万行のデータセットが、すべてIceberg形式で格納されています。左に進むと、RedshiftとAthenaがあり、これらは主にそのIcebergテーブルをクエリするために使われます。さらにLambdaがあり、これがエージェントからのリクエストを受け取ってクライアントのような形に変換し、RedshiftやAthenaがIcebergをクエリできるようにしています。上部を見ると、生データがParquet形式でS3にプッシュされているのが分かります。そしてGlueがそのParquet形式をS3 Tablesに対応したIceberg形式に変換し、取り込みを始めます。レイヤーの下部にはPlatform Analyticsと呼ばれるものがあり、これがDynamoDBをクエリします。これについては後ほど触れます。そして一番下にはAIOpsエージェントと呼ばれるものがあります。
3.2 単なる行出力ではなくインサイトとアクションを返すという発想
Sid： この図には今、あまりにも多くのものが描かれていますので、これから3、4分は、ビジネスリーダーとアナリストをユースケースとして焦点を当てていきましょう。先ほどお話ししたように、こうしたエージェントを構築してデータシステムをクエリするようになると、利用者はもはやあの11行の出力や100行の出力だけを求めているわけではない、というのが業界の向かっている方向です。今はまだあまり語られていないことですが、彼らはその11行や100行の出力を欲しがると同時に、アクションアイテムとしてのインサイトも求めているのです。
Sid： つまり、データの利用者は単にデータプラットフォームを効率的にクエリするだけでなく、その出力が実際に何を意味するのかを即座に理解したいと考えています。「このデータで自分は何をすべきなのか」「ビジネスにもっと大きな価値を示すにはどうすればよいのか」と自問するわけです。まさにこれを実現するのが、次世代のデータプラットフォームです。エージェントが、あなたが与えた文脈に基づいて、結果が何を意味するのか、そのユースケースとビジネスが何であるのかを理解し、次に何をすべきかについてのインサイトを提供してくれる。この発想を実際のデモでどのように体現しているのか、次のセクションでご覧いただきましょう。
4. アナリスト向けデモ：エージェントによるクエリ自動化とインサイト提供
4.1 ペルソナに応じたエンジン自動選択と文脈に基づくインサイト提供
Sid： それでは実際のデモを見ていきましょう。このアーキテクチャでまず焦点を当てたいのはアナリストです。先ほどのような複雑なユースケースを思いつくアナリストたちは、もうSQLを書く必要がありません。彼らはエージェントに話しかけるだけです。エージェントは、アナリストが尋ねた質問を見て、それを分析し、出力を返してくれます。実際の動きをデモで見てみましょう。ログインはCognitoを通じて行われます。分析画面に進むと、これはエージェンティックなアーキテクチャの裏側で何が起きているのかをアニメーションで表現したものになっています。
Sid： たとえば私がリスクチームの人間だとして、「ロンドンと東京における、ロケーション別の平均損失額を見せてほしい」と尋ねたとします。ここで何が起きているかというと、ユーザーのクエリがBedrockに送られています。そこにいるエージェントが、このクエリが実際に何を意味するのかを分析しているのです。エージェントは「このクエリに応えるべきペルソナはリスクチームの人間だ」と理解し、このリクエストに応えるのに最適なサービスは何かを判断しようとします。Redshiftなのか、それともAthenaなのか。これはまさに一部のリーダーが私たちに求めていることでもあります。彼らは「自分のアナリストたちには、裏側でどのエンジンが動いているのかを知ってほしくない。ただプラットフォームを提供したいだけだ」と言うのです。この特定のエージェントは、ご覧のとおりS3 TablesをクエリするエンジンとしてAthenaを選択しました。
Sid： しかし覚えておいてください、私たちが提供すべきなのは単なる1行の答えではない、とお話ししましたよね。重要なのはここからです。これが次世代のデータプラットフォームであり、エージェントは結果が何であるかを理解し、与えられた文脈に基づいてユースケースとビジネスが何であるかを理解したうえで、次に何をすべきかについてのインサイトを提供します。まさにそれが実現されています。先ほどのリクエストとエージェントが提示した内容に基づいて、システムをもう一度クエリし、「2つの都市の平均を出すのであれば、それらの都市におけるゲーム数という観点でのトランザクション量はどうなっているのか」を調べていきます。理にかなっていますよね。これが機能するのは、エージェントにゲーミング業界の文脈を与えているからです。エージェントはリクエストを受け取り、SQLを生成し、出力が何であるかの要約を書き、さらにアナリストとして次に何をすべきかについての追加のインサイトまで提供してくれます。こうして、単にSQLを書いて11行や100行の出力を得て、その出力が何を意味するのかを理解しようとする作業から解放され、文字どおり何時間、場合によっては何日もの作業を節約できるのです。これこそ、一部のリーダーがアナリストの生産性を高めるために、データプラットフォームの上にエージェントを構築したいと望んでいる理由です。
Sid： では、これを他のサービスでも使いたい場合はどうなるでしょうか。これはAthenaの上でしか動かないのでしょうか。答えはノーです。もう一度デモに戻って再生してみましょう。今度はプロダクトチームの立場を選んで、「プラットフォーム上で多額の金額を勝ち取ったトッププレイヤー5人は誰か」を調べてみます。ここで起きていることは本質的に先ほどと同じです。ただ考えてみてください。もしこのユーザーが自分でプラットフォームを使わなければならないとしたら、Redshiftがどう動くのかを知らなければならず、Redshiftのドキュメントを読み込んで、サービス固有の観点からRedshift上でパフォーマンスの出るSQLをどう書くのかを理解しなければなりません。ですが、これはどんなプラットフォームでも動きます。Auroraでも、Athenaでも、その他のあらゆる技術でも構いません。ここではご覧のとおり、エージェントが「このクエリはRedshiftで実行するのが最適だ」と判断し、トッププレイヤー5人の詳細を表示するとともに、重要なインサイトも提供してくれます。「これは単なる結果ではなく、これらがインサイトです。これらのプレイヤーに何が起きているのか、もっと詳しく調べてみてください」と語りかけてくるわけです。ここで起きているテーマがお分かりいただけるでしょうか。データの消費者あるいは利用者として、私たちはデータプラットフォームを効率的にクエリしているだけでなく、その出力が実際に何を意味するのかを即座に理解しているのです。
4.2 Customer 360とフォローアップ質問への動的対応
Sid： プレイヤーの金額についてはRedshiftで処理されました。ここは少し飛ばして、次のデモであるCustomer 360に進みましょう。これもRedshiftをクエリするという点ではほぼ同じことをしているのですが、今回はあらかじめユースケースをセットアップしてあります。不正検知、アクティビティの低下、成長機会などのユースケースが用意されている状態です。ここでアナリストがやってきて、「ギャンブリングの問題の兆候を見せているプレイヤーを特定してほしい」と尋ねます。
Sid： このクエリを考えてみてください。もしこれを自分で書いてRedshiftをクエリしなければならないとしたら、まず自分のデータセットを理解するのに丸一日を費やし、カラムが何であるかを理解し、カタログが何であるかを理解し、そのうえでSQLをリード開発者に検証してもらい、それからプロダクションに投入することになります。ここで起きているのは、まさに先ほど見たことと同じです。クエリがメインエージェントに送られ、メインエージェントがそれを受け取ります。エージェントは「これは責任あるギャンブリングに関するものだ」と認識し、私たちが解決しようとしている文脈を理解したうえで、「これだけのセッションを確認したところ、この人物にはこれだけの損失がある」といった詳細な分析を提供してくれます。
Sid： さて、次に私はもっと尋ねたいことが出てきます。インサイトを提供してくれたのは素晴らしいのですが、私自身の質問もあるわけです。それをどうやればよいのか。そこで私は「Mumbaiに住むプレイヤーについて同じ分析をやってくれないか」と尋ねます。するとエージェントは「先ほど行った分析は何だったか。それをRedshift上でそのままクエリに反映できるか」と考え、まさにそれを実行します。これがRedshiftのコンソールです。クエリが実行されている間に、SQLがどのようになっているかを確認したかったので、クエリ実行のタブに移動し、そのユースケースを実行したクエリを検索します。正しいクエリを見ているかを確認するためにクエリテキストを見て、それを選択します。少し待ってみましょう。ご覧のとおり、この一連の処理が数秒もかからずに書き上げられています。
Sid： ただし、これは最初の質問に対するものでした。覚えておいてください、私たちはそこに「Mumbaiに住むプレイヤーについてもっと分析してほしい」という別の条件を追加しました。ですので、そのSQLクエリがどうなっているかも確認してみましょう。このクエリのページに戻り、そのクエリテキストを検索します。最も直近にシステムが実行したクエリなので最初のものを選ぶと、ご覧のとおり「location Mumbai」というWHERE句が追加され、同じデータを分析したうえで、ここで何が起きているのか、追加のインサイトは何かを導き出しています。これがCustomer 360です。
5. SageMaker Unified Studioによる完全制御とガバナンス
5.1 データセット検索・列マッピング・リネージの自動提示とエンジン非切替選択
Sid： さて、これまでは生産性を高めたいユーザーを見てきましたが、一方で「私はプラットフォームを完全にコントロールしたい、それを今すぐどうやればよいのか」と考えるユーザーもいます。それを実現するのがSageMaker Unified Studioです。ご覧のとおり、Unified StudioはS3 Tablesを直接クエリします。Unified Studioにアクセスすると、これがホームページです。そこから自分のデータセットを検索します。このデータセットはあらかじめ組み込まれているもので、おそらくデータ管理者によってセットアップされたものです。「1308テーブルのプレイヤーデータを出してくれないか」と言って検索すると、ご覧のとおりすべてが用意されています。
Sid： Unified Studioはそのテーブルが何であるかを特定し、そのテーブルとデータセットで何が起きているのかについての要約を書き、さらに何のユースケースなのかも記述しています。そしてここでは、一つひとつのカラムについて、それが何に使われているのかと、その説明をマッピングしています。ですので、誰かがこのデータセットを使おうとするとき、カラムが何であるか、そしてこのデータセットが生データからプロダクションへとどのように変換されてきたのかを、明確に理解できるのです。リネージもそこに表示されていましたよね。これを理解したうえで、アナリストはクエリエディタに戻ってきます。そのときには「このデータセットにはこれらのカラムがある、カタログも分かっている、それが何を意味するのかも分かっている、これが扱うべき正しいデータセットだ」と分かっている状態です。そこでそのデータセットを選び、テーブルをプレビューします。ご覧のとおりAthenaを使ってクエリしていますが、このアナリストやエンジニアは、ここで自分の書きたいSQLを完全に自由に書く権限を持っています。良い点は、説明をすべて読み、スキーマを十分に理解しているので、正しいデータセットを使っているということです。
Sid： ここで考えてみてください。あるユースケースはAthena向け、あるユースケースはRedshift向けだとお話ししました。ところがコンソールを移動することも、何かを変更することもなく、ユーザーはただそこでRedshiftを選び、その特定のテーブルのためにセットしたカタログを選ぶだけで、同じデータセットをクエリできるのです。
5.2 コンピュート／ストレージの分離・クエリの手動再編集・SageMaker Catalogによるガバナンス
Sid： つまりここにはコンピュートの分離があり、ストレージの分離があります。しかしUnified Studioを使うことで、データオプスにおいて極めて重要となるガバナンスが得られます。データに対して何が起きているのかを完全にコントロールでき、必要であればクエリを再調整することもできます。ですので、常にエージェントのクエリに頼らなければならないわけではありません。もし何かが間違っていると思えば、先ほどお見せしたクエリエディタのタブに戻り、そのクエリを取得してここに貼り付け、再編集することができます。まさにそれがここで起きていることです。これは、1億3,900万行という同じデータを、RedshiftとAthenaの両方で扱っていることを示すデモでもあります。
Sid： コンソール上で見たものをもとに自分のクエリを調整できるとお話ししましたが、それがまさにここで起きています。Redshiftクラスタを選び、クエリデータベースに戻り、編集あるいは再テストしたいクエリを選びます。これは「異常なベッティングパターン」のユースケースで、SQLクエリがどれほど長いかお分かりいただけるでしょう。これを調整したければUnified Studioで調整できます。それをコピーしてこちらに貼り付け、実行する内容を再確認したうえでExecuteを押します。これは先ほどエージェントが返してくれたのと同じ答えです。
Sid： このスライドからの重要な学びは、こうした複雑なデータプラットフォームを持つときには、そのデータセットが正確に何であるかを理解する必要がある、ということです。ですのでガバナンスが極めて重要になります。SageMaker Catalogがまさにそれを助けてくれますし、同じことはRedshiftだけでなくAthenaでも機能します。ここでは同じ作業として、クエリをここからコピーし、Unified Studioを使って実行しています。少し時間がかかりますが、ご覧のとおり動作します。ここでエージェントが登場することによる違いがお分かりいただけたと思います。Unified Studioだけを使う場合に得られるのは静的な出力であり、それは常に同じで、インサイトはありません。しかし上にエージェントを載せ、業界の十分な文脈とともに結果をエージェントに渡すと、はるかに多くの詳細を提供してくれるのです。
6. プラットフォームガバナンスとデータオプスの実演
6.1 DynamoDBへの全インタラクション保存とエージェントによる利用状況分析
Sid： プラットフォームのガバナンスも非常に重要になってきます。データリーダーの方々からはよくこう尋ねられます。「私たちのプラットフォーム上ではこれだけ多くの技術が動いているが、それをどう活用できているのか。個々の技術のことはいったん忘れて、そもそも自分たちのプラットフォーム自体をどう使えているのか」と。まさにここで、このユースケースが役立ちます。私たちが何をしたかというと、データプラットフォームとのあらゆるクエリ、あらゆるインタラクションをすべてDynamoDBに保存しているのです。そしてエージェントをDynamoDBに向けて、プラットフォーム全体の監査証跡をすべて見たうえで「私たちは実際どうやれているのか、データプラットフォームを実際どう使えているのか」を教えてくれるよう依頼します。
Sid： ここで動画を一度止めます。ご覧のとおり、「あなたはプラットフォームをこのように使っています」と表示されています。メトリクスを見ると、クエリの総数は28件です。クエリの種類の内訳では、57%が一般的なクエリで、これはユーザー全員が使っているものです。29%が財務分析、11%が顧客分析、そして3%がインフラ運用、いわゆるInfraOpsです。InfraOpsについては後ほど触れます。さらにリスクと緩和戦略についても教えてくれます。「単一のユーザーがいます」と指摘していますが、これは私です、私がプラットフォームをあれこれ試していたからです。「ほかの全員にも使ってもらう必要があります、一人のユーザーだけが常に使っている状態ではいけません」と言っているわけです。これがデータプラットフォームの上にエージェントを構築し、自分のデータプラットフォームで何が起きているのかを理解するというガバナンスの側面です。
6.2 Glue・Redshiftのサービス別運用分析とエージェント成功への影響
Sid： これを理解したうえで、いよいよデータオプスの側面に踏み込んでいけます。データオプスにおいて私が理解したいのは、「いま動かしているサービスから、どうすれば最大限のものを引き出せるのか」ということです。先ほどのアーキテクチャでは複数のサービスを動かしていますよね。ここで私はGlueを選びました。これが何をしているかというと、「どのGlueジョブを分析してほしいか選んでください」と尋ねてきます。私は「すべて分析してくれ」と答えます。すると、これはMCPサーバーを取り込み、私のGlueジョブにアクセスし、一つひとつのGlueジョブをすべて確認したうえで、Glueを最善の形で使えているかどうかを分析します。サービスを最善の形で使うこと、それこそがエージェントが最大限の力を発揮できる条件なのです。
Sid： これが何を意味するかというと、もしあなたのGlue、Redshift、Athena、あるいはデータプラットフォームそのものがパフォーマンスを出せていなければ、エージェントが応答を返すまでに当然時間がかかってしまう、ということです。複数の方が以前から語っているデータ基盤が極めて重要であるのはもちろんですが、それに加えて、各サービスのデータオプスを完璧に整えておくことも非常に重要になります。今このコンソールに戻ってくると、184個のジョブを分析しています。ご覧のとおり数秒で「あなたのジョブの構成は、あまりうまくできていないと思います。これが私の提供できる最善のパフォーマンス最適化です」と返してきました。監視とエラーハンドリングについても「このようにやるべきです」と示し、「Glueジョブで使っているDPUが多すぎます、このように最適化すべきです」といった具合に、私のGlue環境を丸ごと分析してくれました。同じことはRedshiftでもできます。Redshiftに絞り込み、どのテーブルを分析したいかを選んで、それらに対して運用分析を実行できるのです。
Sid： これまでお見せしたすべてからの重要な学びは、データシステムをクエリする大規模なエージェンティックプラットフォームは構築でき、しかも実際に機能する、ということです。ただし、エージェントが機能するためには、データシステムそのものからパフォーマンスが出ていなければなりません。ですのでパフォーマンスは極めて重要です。そしてデータ品質はさらに重要になります。エージェントにハルシネーションを起こしてほしくないので、チェックを設けておく必要があるのです。私たちが正しいことをやれていると分かる一つの理由は、Unified Studioを使ってデータセットの説明やガバナンスなどを得ているからです。そして最後に、運用上の卓越性です。もしこれらのサービスのいずれかが十分なパフォーマンスを出せていなければ、エージェントが提供するユーザー体験が損なわれかねません。まさにそこでデータオプスが登場します。データオプスとは何かを高いレベルでお伝えすると、データプラットフォーム上の運用を管理するために、すでに整えている一連のプラクティスだと考えてください。それでは、データオプスについてさらに詳しくお話しするために、Annaをお招きしたいと思います。
7. データオプスの定義とAnna（FanDuel）による導入
7.1 Annaの経歴とFlutter／Betfair／Paddy Power／Sky Betting／FanDuelでの経験・2015年のクラウド移行と早期採用者としての学び
Anna： こんにちは、聞こえていますでしょうか。素晴らしい。私の名前はAnna Sentaniと申します。FanDuelでデータエンジニアリングのディレクターを務めています。FanDuelをご存じの方もいらっしゃるかもしれませんが、もう少し詳しくお話しします。私はAWSと一緒に仕事をして約11年になります。その道のりを通じて、データオプスは常に、データの卓越性に関わるあらゆることの中心的な要素であり続けてきました。
Anna： FanDuelをご存じない方もいらっしゃるかもしれません。これは私たちの米国事業です。ですが、Paddy PowerやBetfair、あるいはSky Betting and Gamingならご存じかもしれません。私はそのすべてで働いてきました。11年前、私はFlutterでキャリアを始めました。当時はBetfairでした。そして2016年にPaddy Powerとの合併を経て、私たちはPaddy Power Betfairとなりました。その時点で私は、オンプレミスのOracle、オンプレミスのSQLからAWSクラウドへの大規模な移行を率いる役割を任されました。私たちはAWSの技術、そしてデータ技術の早期採用者だったのです。その後、Sky Betting and Gamingが加わり、8か月前に私は米国事業へと移りました。
Anna： これが私たちのブランドファミリーです。私たちは現在、世界最大のオンラインゲーミング企業であり、先ほどお話ししたように長年にわたって世界中に拠点を構えています。この会社はまさに巨大な存在へと成長しました。ですので、オンラインゲーミング企業である私たちにとって、データオプスは中核事業にとって極めて重要なのです。
7.2 「エージェントの時代の進歩は実験ではなく実装で生まれる」という気づきとデータ基盤の重要性
Anna： 今日Sidが、エージェントを備えた次世代データプラットフォームについて多くを語ってくれました。私は今朝のキーノートである言葉を聞いて、それがとても心に残りました。「エージェントの時代において、進歩は実験を通じて成し遂げられるのではなく、現実世界での実装を通じて成し遂げられる」という言葉です。これはまさに私がここでお伝えしようとしている点そのものでした。エンタープライズレベルでAIを適切に実装するためには、その水面下に何があるのかを必ず把握していなければなりません。それこそが適切なデータオプスなのです。なぜなら、あなたのAIの成功は、実装するモデルや、エージェンティックAIをどう実装するかだけによって決まるのではなく、データオプスの成熟度によって絶対的に左右されるからです。
Anna： つまり、あなたのAIはデータと同じ程度にしか良くなりえないのです。私がこの場でこれをお話ししたい理由は、市場にギャップがあると考えているからです。私たちは、業界全体としてAIについて多くを語ります。それはもっともなことで、AIには大きな力があります。しかし私たちは、その水面下に何があるのかについて十分に語っていません。約1年前、私はデータオプスについて同じような講演を行いました。そしてその講演の後、会話を重ねるなかで気づいたのは、こうしたデータオプスの問題を解決するために経営層の耳を傾けてもらえずにいる人がとても多い、ということでした。これは今、業界において極めて必要なことだと私は考えています。ゲーミング業界に限った話ではなく、データ領域全体にとってそうなのです。
8. データオプスが解決する問いと基盤の重要性
8.1 自問すべき質問群とイベント時のスケーリング対応
Anna： ここで皆さんに伺いたいのですが、これまでにこうした問いを自問したり、向き合ったりしたことはあるでしょうか。「自分のデータは一貫しているか。パフォーマンスは出ているか。インシデントが多発していないか。常に壊れていないか」。「自分のデータは適切に分類されているか。PIIデータがどこにあるか把握しているか。それはどう統制されているか。非PIIデータがどこにあり、どう使われているか分かっているか」。「自分のプラットフォームとエコシステムにどれだけのコストがかかっているか可視化できているか。それを管理する手段を持っているか、それともベンダーの言いなりに請求書を支払うしかないのか、あるいは最適化する手段を持っているか」。「ダッシュボード、MLモデル、AIモデル、AIエージェントに供給されているデータが、完全で、正確で、適時であるかを把握しているか」。「必要なときに自分のプラットフォームをスケールできるか」。こうした問いです。
Anna： たとえば来週はCheltenhamがあります。これは英国事業にとって大きなスポーツイベントで、ご存じの方もいらっしゃるでしょう。英国のブランドは、サーバーレスではない部分のプラットフォームをスケールできるよう、先回りして準備を進めています。皆さんのビジネスにも同じようなイベントがきっとあるはずです。私も今では米国に身を置いているのでSuper Bowlに親近感がありますし、あるいはBlack Friday、その他あらゆる種類のイベントが考えられます。ですので、システムをどうスケールさせるか、そして繰り返し発生する運用システムについてどう備えるかを、常に考えておかなければなりません。
8.2 早期採用で直面した課題と学習ループ・各要素が相互排他的でないという指摘
Anna： 私たちは早期採用者として、2015年にクラウドへ移行していました。ですので、AWS上でちょうど10年を迎えたばかりのこれらの技術のいくつかに、非常に早い段階から取り組んでいたのです。私たちは、これを大規模に実装した最初の大口顧客の一つでした。当時はあらゆる種類の問題に直面しました。しかし、絶え間ない学習のループ、根本原因を評価する明確なプラクティス、そして失敗のパターンを見極めてそれに正面から取り組む姿勢を持っていたおかげで、抱えていた問題を乗り越えることができたのです。
Anna： ここで挙手で伺いますが、これまでにこの問いを自問したことがある、あるいは日々自問しているという方はどれくらいいらっしゃいますか。何名かいらっしゃいますね。もしこうしたことを考えてこられたのであれば、それは皆さんがデータの信頼性について考えてきた、ということです。データのガバナンスとコンプライアンスについて考えてきた、ということです。「これは財務的に持続可能か。データが増え続けるなかで、自分のビジネスはそれに耐えられるのか」と考えてきたわけです。今日この後にも触れられますが、エージェントの利用はデータ量を10倍、いや1,000倍に増やすとも言われています。ですので、「いま自分が運用しているデータプラットフォームのやり方は、財務的に持続可能なのか」「自分はデータを信頼できるか。それはスケーラブルか。自分のプラットフォームはスケーラブルか。そして、プラットフォームを絶えず改善できる継続的な改善プロセスやフィードバックループを持っているか」を考えてきたことになります。
Anna： もしこうしたことを自問したことがあるのなら、それは皆さんがデータオプスを構成する特定のトピックに指を触れてきた、ということです。そして、まさにこれこそデータオプスが提供してくれるものなのです。データオプスはその根底において「物事を正しく行うための規律」であり、こうしたあらゆる恩恵をもたらしてくれます。ここでもう一点強調したいのは、これらは互いに排他的なものではない、ということです。一つをやって他をやらなければ、依然としてデータオプスにおいて卓越しているとは言えません。データが信頼できても分類されていなければ、それは問題です。データを信頼できても、それが絶えず壊れていてシステムからデータを取り出せないのであれば、それもまた良くありません。ですので、真に必要なデータ基盤を持つためには、これらの領域それぞれに少しずつ投資をしていく必要があるのです。
9. データオプスの5つの柱
9.1 アーキテクチャとインシデント管理・オブザーバビリティ
Anna： データオプス、つまりデータの運用について考えるとき、皆さんが意識すべき柱は本当に5つあります。それぞれを取り上げていきますが、時間の都合もあり、一つひとつについて何時間でも語れてしまうので、ごく簡単に触れていきます。AIの成功に真に必要なデータ基盤を手に入れたいのであれば、投資すべき縦軸はこの5つです。
Anna： まず一つ目はアーキテクチャです。ここには多くの要素が含まれており、私は来週、そのうちの一つだけについてのプレゼンテーションを行う予定です。その中の二つ目に挙げているのが技術評価です。というのも、業界では適切なデータシステムの技術評価が真に行われていないことに気づいたからです。多くは勘や、営業トーク的なものに頼っているのです。ですので、ハッピーパスのデモを超えた、適切なデータ技術評価をどう行うかについての深掘りの内容も別に用意しています。アーキテクチャの領域はこれが極めて重要で、これは単なるデータアーキテクチャ部門の仕事であってはなりません。これは絶対に、データエンジニアリング機能とデータオプス機能の仕事であるべきです。なぜなら、夜中にオンコールで起こされるのは彼らだからです。ですので、彼らはデータエコシステムのアーキテクチャに非常に深く関与している必要があります。
Anna： 先ほどSidが行ったデモを思い出していただくと、あのアーキテクチャの中でうまくいっていることがいくつもあります。まず一つ目はアーキテクチャのモジュール性です。二つ目はプラットフォーム上でのスケーリング、つまり拡張の可用性です。あのアーキテクチャをよく見ると、ほとんどのサービスがサーバーレスであることに気づくはずです。ですので、通常のアーキテクチャや他の種類のアーキテクチャでは悩まされるキャパシティやスケーリングの問題を心配する必要がありません。さらにこのアーキテクチャに関わるもう一つの要素が進化です。2015年には、データの世界には約200の技術がありました。2025年には2,000から2万5,500の間にまで増えています。つまり、ものすごい飛躍があったのです。私たちの技術スタックは変化しており、異なるニーズに対応する多くのプラットフォームが存在するため、特定の技術にロックインされずに柔軟であり続けられることが必要なのです。Sidが構築しデモしたあのアーキテクチャには、進化をより容易にする一つのユニークな特徴があります。それがIcebergというオープンデータフォーマットで、これによって他のデータベース技術を差し替えたり追加したりできるのです。もう一つは、エージェントの数です。あそこには6つあったと思いますが、もし1,000個のエージェントを追加したらどうでしょう。まったく異なることをするエージェント、あるいは同じことをするエージェントを。そのスケールはどれほどでしょうか。この種のアーキテクチャは非常に柔軟で、私たちがデータ運用のベストプラクティスに期待するものに非常に合致しているのです。
Anna： 二つ目はインシデント管理とオブザーバビリティです。これは良いプラクティスです。ここにあるすべては、データであろうとなかろうと、あらゆる種類の運用やプラットフォームにとっての良いプラクティスです。インシデントにどう対応するか、どう復旧するか、根本原因分析をどう行うか、インシデント後のレビューや問題管理をどう行うか、真の根本原因をどう修正するか、そしてユーザーの体験はどうか、それをどう監視しているか。これらはどんなデジタルビジネスでも当然やるべきことです。しかしデータに関しては、これはさらに重要になります。そしてAIの実装について考えるなら、これは極めて重要になります。AIにまつわる規制の多くは、責任あるAIをめぐって生まれてきました。たとえば、不満を訴えてきた顧客に対してエージェントが提供した回答を理解するためには、監査証跡が必要になるはずです。これは極めて重要です。こうしたプラクティスを日々のデータ運用に組み込んでおけば、皆さんのAI実装は最初の段階から格段に成熟したものになると断言できます。
9.2 クエリ性能・セキュリティとガバナンス・自動化とテスト・コスト最適化
Anna： ここで一つ重要な点に触れていなかったので戻りますが、それがクエリ性能です。2015年、私たちは最初の合併とクラウドへの移行を行っていました。Oracleデータベース、SQLデータベースからAWSのさまざまなプラットフォームへと移っていったのです。その数年後には、BigQueryからAWSへという別のAI統合も行いました。流れがお分かりいただけると思います。成長を続ける企業では、データ統合のプロジェクトが数多く生まれ、私はそれを率いる機会に恵まれてきました。その中では、ユーザーに移行してもらうよう動機づけることに苦労します。移行や技術変革のプロジェクトを経験されたことがある方なら、アナリストに、いや誰であれ、変化を促すことがどれほど難しいかお分かりでしょう。ですので、クエリ性能、リソース監視、運用ヘルスは極めて重要です。先ほどSidが見せてくれたように、基盤となるパフォーマンスのクエリや、その下にある最適化のソリューションにたどり着くのは驚くほど速いものでした。私たちの場合、誇張ではなく、Redshiftのログの粒度と設定を理解するのに、S3のログの設定と粒度を理解するのに、そしてAuroraなどでも同様に、何か月もかかったのです。こうしたエージェンティックなAIOps監視のおかげで、今ではそれが極めて容易になっています。10年前にこれがあればよかったのに、と思います。そうすればログ構造とそこから最善を引き出す方法を理解するのに何か月も費やさずに済んだでしょう。
Anna： 次に簡単に触れますが、セキュリティとガバナンスです。AIエージェントにはこれが必要です。先ほどキーノートでもセクション全体がセキュリティに割かれていました。これは皆さんのデータのセキュリティとガバナンス、そして水面下に何があるのかに関わるものです。Icebergの例えを思い出していただくと、AIエージェントがあなたのデータにアクセスすることを考えてみてください。彼らはどのようなデータにアクセスできるのか。PIIのどの階層にアクセスできるのか。PIIにも異なる階層があるからです。どの階層のPIIに、どの時点でアクセスを許されるのか。そしてリネージも極めて重要です。その答えがどこから来ているのか、システム間でどう整合しているのかを理解できているべきだからです。
Anna： 次に、自動化とテストもデータ運用の卓越性の一つのセクションです。ここにも重要なことが数多くありますが、データ品質テストはおそらく最も重要なものの一つです。特に、データエコシステムの下に多数のエージェントと多数のプラットフォームを抱えている場合、自分が持っている答えを検証することは極めて重要です。エージェントが実際の答えを提供していることを確認したいからです。インシデント管理について考えると、以前はデータにおける重大なインシデントといえば「データが最新でない」といったものでした。ところがエージェントの時代における新たなインシデントは、「エージェントが間違った答えを返す」というものです。これは非常にまずいことです。エージェントを通じてデータをクエリしていて、それが正確でないという状況にあるなら、それは以前よりもさらに深刻な問題と言えるでしょう。
Anna： そして最後に、コスト最適化とリソース最適化です。ここでは特にDR、つまり災害復旧だけを取り上げます。AIの時代において災害復旧はさらに重要になると考えるからです。データレプリケーションやそれを活用することも含めてです。今日の世界では、私たちは非常に変動の激しい世界に生きており、DRや災害復旧に関してはより慎重に、より規律をもって臨む必要があります。もちろん、その内部にはコスト最適化やリソース最適化を含め、本当に重要なことが他にも数多くあります。
10. データオプス成熟度・AI導入戦略と結論
10.1 AI導入ジャーニーにおける成熟度の自己評価・導入アプローチとAWS Data Ops Assessment
Anna： ここまで多くのトピックをお話ししてきましたが、それぞれについて深掘りすれば何時間でも語れてしまいます。セッションの後にお話しすることもできますので、ぜひそうしましょう。ですがその前に、数秒だけ考えてみてください。皆さんの現在のギャップは何でしょうか。夜眠れなくなるほど気になっていることは何でしょうか。それこそが、皆さんがデータ運用において取り組むべきことなのです。なぜなら、皆さんのAIの成功は、書き上げるモデルによって決まるのではなく、その水面下にあるすべてによって決まるからです。そしてそれこそが、この取り組みの大きな部分を占めているのです。
Anna： 一つお伝えしておきたいのは、私たちFlutterでは、データ運用の成熟度、データオプスの成熟度を非常に真剣に捉えている、ということです。私は幸運にも最も成熟した部門を率いる立場にありましたが、長年のうちに、私たちの会社の中にはあらゆる度合いのデータ成熟度が存在してきました。これは、皆さんがAI導入のジャーニーにおいてどこに位置しているのかを、非常に分かりやすく視覚化したものです。もし数秒前に「自分はデータオプスの成熟度が高い」と思ったのであれば、皆さんはエンタープライズ規模での実装にまさに準備ができています。しかし、もし自分のデータ運用に大きなギャップがあると思うのであれば、成熟度が高い場合ほど積極的にではなく、少し慎重に始めるべきです。そして、AIの導入と、データ運用の修正の両方の取り組みを並行して進めるべきです。
Anna： これまで多くのブランドをお見せしてきました。昨年、AWSがデータ運用とその重要性をAIの文脈においてより真剣に考え始めたとき、ユニークな機会が訪れました。インパクトを生み出し、AWSのデータオプスアセスメントのための顧客諮問委員会に参加するというユニークな機会です。今ではAWSからデータオプスアセスメントが提供されています。私たちはすでにそれを始めており、14あるブランドのうち9ブランドがこのアセスメントをすでに実施しました。このアセスメントは、データオプスアセスメントに基づいてギャップが何であるかを教えてくれるだけでなく、見つかったギャップに対して皆さんのAI実装がどのように振る舞うことになるのかまで教えてくれるドキュメントを提供してくれます。ですので、これを受け取って、皆さんが前進していくためのロードマップに落とし込むうえで、極めて有用なドキュメントなのです。
10.2 結論：「AIはデータオプスの良し悪しに尽きる」というメッセージ
Anna： 最後に、結論を導くとすれば、AIに胸を躍らせてください。AIは間違いなくゲームチェンジャーです。しかし、その水面下にあるものを忘れないでください。皆さんのAIは、データオプスと同じ程度にしか良くなりえないからです。どうか、これを持ち帰って振り返っていただき、AIのジャーニーで成功するために行動を起こしていただければと思います。ありがとうございました。