※本記事は、世界最大のデータ・AIカンファレンスである「Data + AI Summit」のDay 1基調講演の内容を基に作成されています。本基調講演では、Databricksの共同創業者やプロダクトリーダー、AIの開発者、そして世界各地のビジネスリーダーたちが、画期的な新製品の発表や、AIで実現可能なことを塗り替えている組織のストーリーを披露しています。登壇者には、Databricks共同創業者兼CEOのAli Ghodsi氏をはじめ、共同創業者のReynold Xin氏、Patrick Wendell氏、Apache Icebergの創始者でありTabular共同創業者兼CEOのRyan Blue氏、Neon創業者でありOLTP領域を率いるNikita Shamgunov氏、プロダクトマネジメントを担うKen Wong氏、Bilal Aslam氏、Elise Joris氏らDatabricksのメンバーに加え、OpenAI社長兼共同創業者のGreg Brockman氏、PepsiCoグローバル最高データ・AI責任者のMagesh Bagavathi氏、MasterCardのFederica Cohen氏といったゲストが含まれます。本記事では、基調講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. オープニングとイベント概要
1.1 テーマ映像とイベント規模
キーノートは、一本のテーマ映像から始まりました。世界が「人工の脳（artificial brain）」を作り出したものの、それを一室に閉じ込めてしまった、という語りです。その脳はほとんどどんな問いにも答えられるけれども、現実から、つまり皆さんの業務やビジネスの世界からは切り離され、孤立しています。考え方は知っているが、現実が何であるかをまだ見ていない、というのです。映像はこう続けます。「現実」とは、あらゆる意思決定であり、あらゆる取引であり、あらゆるシグナルであり、あらゆる発見であり、あらゆる約束であり、変えられたあらゆる人生のことだ、と。私たちが力を合わせてその脳に皆さんのすべてのデータという文脈（コンテキスト）を与えるが、主導権は皆さんが握っている。何を知らせ、何にアクセスさせ、誰がアクセスでき、何をさせるのかを決めるのは皆さん自身であり、それをどんな基盤の上で、どんなやり方でも動かせる――そうした主張です。究極の脳はあくまで出発点に過ぎず、本当のブレイクスルーは皆さんがそれを使って何を作るかにある、というメッセージで映像は締めくくられました。
そしてDatabricksの共同創業者兼CEOであるAli Ghodsiが登壇しました。
Ali： あの映像、本当に素晴らしかったですね。会場の多くの方は気づかなかったかもしれませんが、流れていたクリップの多くは、実は私たちの顧客と、その実際のユースケースなんです。これは本当にわくわくするイベントで、これまで私たちが開催してきた中で最大のData + AI Summitになりました。ほんの数日前に確認したときは登録者がまだ9万7,000人でしたが、いまや10万人を超えました。そして私のいちばんのお気に入りは、174カ国が参加しているという、とんでもない数字です。本当に国際的でグローバルなイベントで、世界中からこのために飛行機で来てくださった方々がいます。現地参加者は正確に31,309人で、これによって世界最大のデータ・AIカンファレンスになりました。
1.2 オープンソースの歴史と登壇者・パートナー紹介
Ali： このカンファレンスは、ご存じのとおり本質的にコミュニティのイベントであり、そのルーツはオープンソースにあります。私たちがData + AI Summitを始めたのは2013年で、当時はSpark Summitという名前でした。オープンソースプロジェクトのSparkから出発したわけですが、そのSparkはいまや年間30億ダウンロードを超えています。そして長年にわたって、私たちはオープンソースプロジェクトを増やしてきました。Delta Lake、Iceberg、MLflow、そして私たちがオープンソース化したUnity Catalog。さらに最近では、Postgresを本気で取り込んでいます。このカンファレンスでもPostgresについてはもっと多くをご覧いただけますが、私たちは本当にこのプロジェクトに入れ込んでいて、プロジェクトのガバナーの7分の1が当社の社員で、コミッターの6%以上を占めています。Postgresこそがデータベースの未来だと考えています。そしてこの週末、私の共同創業者であるMateiが、Omnigentというプロジェクトをオープンソース化しました。これはメタハーネスで、ぜひチェックしてみてください。後ほど私からも触れますし、彼自身からも話があります。
Ali： コミュニティの話に戻ると、このカンファレンスではコミュニティから多くの方が講演します。OpenAIの共同創業者兼CTOであるGreg Brockman、Satya Nadella、その他にも数多くのリーダーやCEO、そしてAnthropic、Cognition、Glean、Decagon、Agno、Llama Index、Crew AIといったAI企業の共同創業者たちが登壇します。彼らはみな、今週ここに集まった、より大きなエコシステムの一部です。そのエコシステムには、システムインテグレーターや、Databricksの上に何かを構築した方々、データ共有やAIのパートナーが含まれています。このイベントを可能にしてくれたすべてのパートナーに、特別な感謝を伝えたいと思います。彼らも、先ほどスライドでお見せした企業も、エキスポホールに出展していて、興味深いイノベーションを数多く展示していますので、ぜひ足を運んでみてください。
Ali： そして、このカンファレンスはすべての顧客なしには成り立ちません。プラットフォームの上で本当に驚くべきことを成し遂げているのは皆さんであり、私たちが語るあらゆるユースケースが実際に生まれているのもそこです。世界で起きているデータとAIの変化を実際に推し進めているのは、すべて皆さん自身なのです。
2. 顧客事例とAGIをめぐる問題提起
2.1 3つの顧客事例（Insulet・Tonal・Merck）
Ali： プラットフォーム上で本当に素晴らしいことを実現している顧客の中から、とりわけ感銘を受けた3社を取り上げたいと思います。まず1社目はInsuletです。彼らにはOmnipodという製品があります。これは糖尿病を抱える方々を助ける製品で、グルコースモニターを搭載していて、血液中のグルコース値を測定します。そして、もちろん大量のデータとAIを活用することで、いま自分のグルコース値に何が起きているのかを正確にパーソナライズし、インスリンを放出して糖尿病を管理できるようにします。世界中で糖尿病を抱えるすべての方にとって、これは状況を一変させるものです。私たちがここで語ってきた2万件にも及ぶインパクトのうちの、ひとつの代表例です。
Ali： 私のお気に入りのもうひとつの例は、当社の初期社員の多くも持っているTonalというデバイスです。これは本当にクールなデバイスで、それほど大きくはなく、壁に取り付けるのですが、そこであらゆるワークアウトができます。デバイスがすさまじい負荷を生み出してくれるので、その上でトレーニングができるのです。何が本当にクールかというと、彼らは年間1,000億秒ものワークアウトデータを集めていて、それを皆さん一人ひとりにパーソナライズしている点です。まるで自分専属のパーソナルトレーナーのように、食事のアドバイスまで含めてパーソナライズされたワークアウトが得られます。もちろんこれも、プラットフォーム上でデータとAIを活用しているからこそ可能になっています。
Ali： そして最後の例、これは私が特に興奮しているものですが、Merckです。Merckはトランスフォーマーベースの言語モデルを学習させました。Teddyという名前で、これはtransformer-enabled drug discovery（トランスフォーマーによる創薬）の略です。LLMのような、いわゆる次トークン予測器のひとつなのですが、Databricksのリサーチチームと共に、Databricks上で学習させました。ただし、これは言語モデルではありません。次の単語を予測するのではなく、遺伝子制御ネットワークを予測するのです。つまり、体内のどの遺伝子が実際に病気の原因（causal）となっているかを予測できます。この細胞を変えれば次の細胞にこういうことが起きる、この細胞は原因となる細胞だ、この細胞は単に反応するだけの細胞だ、といったことを予測できるわけです。これによって創薬の開発が大幅に加速します。1億個を超える細胞で学習しているので、本当にすごいことです。まさに人を奮い立たせるAIのユースケースだと思います。
2.2 AGI到来の問いかけと数学問題
Ali： さて、AIは私たち全員にとって最大の関心事です。せっかくData + AI Summitに来ているので、少し会場の皆さんに参加していただきたいと思います。問いはこうです。AGIは今日すでにここに来ているのか。すでにAGIを手にしていると思う方は手を挙げてください。統計的に推定してみますと、この辺りで少なくとも5%くらいの方がAGIは来ていると手を挙げているようですね。逆に言えば、90%から95%の方はAGIはまだ来ていないと言っているわけです。
Ali： では、皆さんに問題を出します。どなたかこれを解ける方はいますか。問いはこうです。「リー群G2の分類空間の、簡約された12次元スピン・ボルディズムを計算せよ」。答えがわかる方は声に出してくださっても、ここに上がってきて共有してくださっても構いません。手を挙げてみてください。おや、一人だけいますね。ステージに上げるべきかもしれません。
Ali： 実は、今日のフロンティアのエージェントやAIはすべて、これを解けます。これは難しい問題ではないんです。私たちにとっては難しいけれど、フロンティアのエージェントにとっては自明な問題です。これは「Humanity's Last Exam」というベンチマークの一部で、彼らが本当に注力しているものです。このベンチマークには2,500問あり、画像認識などさまざまなカテゴリにわたって、こうした問題が並んでいます。そして今日、彼らはほぼ全員、そのうちの半分を解くことができます。ですから私は、AGIはすでに来ていると考えています。汎用人工知能はすでに到来したのです。
Ali： 実のところ、私が研究のために渡米してUC BerkeleyのAMP Labという研究室にいたのは2009年で、AはアルゴリズムとAIのAでした。当時最大のAIラボのひとつで、このカンファレンスも、そのラボで私たちが作ったソフトウェアから生まれました。そして当時私たちが持っていたAGIの定義は、もうとっくの昔に、それも大幅に満たしてしまっています。実際、当時ラボにいた多くの人に「2009年に私たちが定義した意味で、AGIを超えたと思うか」と聞いてみたのですが、誰もが「もちろん、当時の定義でならとっくに達成している」と答えました。もちろんゴールポストは動いているので、議論は尽きませんが、いずれにせよAGIはもう来ているのです。
2.3 コンテキスト欠如という本質的課題
Ali： AGIは十分に賢い。私たちは、AIがこれ以上賢くなる必要があるとは思っていません。AIに知能の問題はないのです。私たちが組織の中で抱えている問題は、そういう種類のものではありません。本当の問題は、AGIが組織の中に完全には浸透していないことです。皆さんの会社の中で、何百ものエージェントが自律的に働き、互いに協働し、提案を出し、交渉し、私たちはただエージェントを管理するだけ――そんな状態にはなっていないでしょう。私たちのほとんどは、いまだチャットボットを使って質問しているだけ、あるいはコーディングツールを使ってコードを書かせているだけです。エージェント的に使ってはいても、皆が語っているあのビジョンを完全に実現できてはいません。だからこそ、先ほど「AGIは来ているか」と聞いたとき、多くの方が手を挙げなかったのだと思います。
Ali： つまり問いは、これを職場でどう実現するか、ということです。それがこの数日間のテーマです。要するに、これだけのAIがすでにある。多くのベンダーがリリースし、オープンソースもあれば、フロンティアモデルもある。では、組織内のすべてのデータ、すべてのプロセス、そして皆さんの頭の中にあるすべてを、どうやってコンテキストとしてAIに与えるか。それさえできれば、AIは私たちにやってほしいタスクの多くを、すでに解けると私たちは考えています。これらの非常に賢いモデルにコンテキストを与えさえすれば、企業の中で驚くべきことができるはずです。私たちが日々やっているタスクの大半は、12次元スピン・ボルディズムを解くことではありません。Salesforceから情報を取り出し、要約し、別の場所に置き、目を通し、準備する――そういった類いのタスクです。ですから、必要なのはそのコンテキストをすべて手に入れることなのです。
Ali： それだけのことなのですが、このコンテキストをAIに与えるのは、想像以上にずっと難しい。本当に、本当に困難なんです。そして完璧なエンタープライズのコンテキストを得ることは、つかみどころがありません。これこそが、私たちDatabricksがずっと取り組んできた問題です。
3. 解決すべき4つの課題
3.1 コンテキストとコントロール
Ali： コンテキストと一言で言っても、それは単に「どうやってAIに届けるか」という話だけではありません。コンテキストとは、まず、組織が持つすべてのデータをどうやってAIに接続するか、ということです。データには、たとえば組織内のあらゆる会議の議事録があります。本来、組織で起きるすべての会議は記録され、その文字起こしを手に入れられるべきです。そのためには、私たちは自分たちのプロセス自体を組み替える必要があります。実際にDatabricksには、そうした組み替えを手伝うフォワードデプロイドエンジニアがいます。しかしコンテキストとは、それだけでなく、皆さんが抱えているデータサイロや、どこかにしまい込まれていてアクセスできていないデータ――たとえばセキュリティの承認が下りていないために手が届かないデータ――に接続することも意味します。これがステップ1です。どうやって皆さんのデータをAIで使える状態（AI ready）にし、エージェントに渡せるようにするか。
Ali： しかし、仮にこれを解決し、すべてのデータにアクセスする方法がわかったとしても、まだ終わりではありません。コンテキストの問題は解けていないのです。なぜなら、私たちはここで、たとえばopen clawのようなものを、皆さんのすべてのデータに対して野放しに解き放つこともできてしまうからです。open clawがリリースされたとき、その中のスキルの10%以上が、実は悪意のあるものでした。ですからステップ2は、これをどうやって安全に、コントロールしながら行うか、ということになります。まずコンテキスト、そして次にコントロールです。エージェントがあちこち動き回っていろいろなことをするのであれば、それが私たちのセキュリティポリシーを満たしていること、監査できること、そして私たちが望まないことをしないことを、確実にしなければなりません。
3.2 コストとロックインの回避
Ali： これも解決できたとしましょう。それでもまだ本当に難しい問題が残ります。エージェントが走り回り、すべてのデータをライブでループしながらチェックし続けたら、これは極端にコストがかかるようになります。ですからコストの問題も解かなければなりません。これはいま、私たちのほとんどの顧客で急上昇している問題です。コストが完全に暴走しているのを目の当たりにしています。Uberのある幹部は、ある四半期でその1四半期のうちに1年分のAI予算を使い切ってしまったと言っていました。これが続けば、ほとんどの組織にとって完全に持続不可能です。コストが収益を完全に追い越してしまえば、会社は倒産します。皆さんの会社はそんなことを許さないでしょうから、ただ止めるか、シャットダウンされるだけです。つまり実現不可能なのです。ですからコストの問題も解かなければなりません。
Ali： しかし、これらすべてを、コストも含めて解決できたとしても、私の考えでは最も重要なことにたどり着きます。それは、どうやってロックインなしにそれを実現するか、ということです。どうすれば皆さんに選択肢（choice）がある形でこれを行えるか。これは超重要です。そして、これが最も難しい。会場には設立10年未満の組織を代表している方もいるので、その方々には当てはまらないかもしれませんが、ここにいる組織の大半――90%以上の方々は、長い歴史を持つ会社を代表しています。20年、30年、50年、中には数百年続いている会社もあるでしょう。
Ali： 私がこの13年間見てきて感じるのは、皆さんの会社にあるスタックは、ただただ複雑だということです。長年にわたって新しいソフトウェアを買い続け、スタックにどんどん積み増していき、そのすべてのベンダーにロックインされてしまう。ベンダーは現れては消えていきますが、ソフトウェアは残り続けます。そしてスタックの中のその一片を欲しがる誰かが必ずいるので、それを引っこ抜くのは難しいのです。では、どうすればデータやコンテキストに、そして何より今ではAIにロックインされることなく、これを実現できるか。私たちは特定のひとつのAIだけにロックインされたくはありません。AIに関して選択肢が欲しいのです。
Ali： それが、私たちが今日取り組んでいることです。私のキーノートは、この4つを解くことだけに焦点を当てています。今日それをすべて完全に解いたと言うつもりはありません。「コンテキストは解決済みだ」とは言いません。けれども、この4つを解くことに向けて大きな飛躍を遂げていることは、納得していただけると思います。私たちが注力している4つとは、まず、ロックインされず選択肢を持てること。次に、セキュリティとコントロール、そしてコストのコントロールを得られること。さらに、コンテキストを手に入れてそれをAIに届けること。それによって、私たちは共により大きなインパクトを生み出せるのです。
4. 選択肢（Choice）— データレイヤーの構築
4.1 Lakeflowとデータ取り込みの革新
Ali： では、どうやって実現するかという話をしましょう。まずは選択肢からです。先ほど申し上げたように、すべてはデータから始まります。私たちはすべてのデータを持っていて、それをAIで使える形（AI ready）にしたい。ステップ1は、この1年だけでも大きく前進したのですが、そのデータをオープンなレイクハウスに移すことです。どのクラウドの上にも構築できるオープンなインフラの上で、データを使える状態に整える。それを担うのがLakeflowです。Lakeflowはこの1年でたくさんのコネクターを開発してきました。2年前にここで話したときはコネクターはほとんどありませんでしたが、いまや100を超えるコネクターを持っています。Salesforce、Workday、NetSuiteだけでなく、MetaやGoogle Analytics、あるいは皆さんのドキュメントやあらゆるコーパスからデータを引き出せます。もし手元にないデータソースがあれば、ぜひ教えてください。オープンなレイクに取り込めるよう手伝います。
Ali： そして、ただデータを取り込むだけではありません。いろいろなモダリティで取り込めます。特に3つ取り上げたいと思います。ひとつ目は、昨年リリースしたZero Busで、これが現在GA（一般提供）になり、しかも多くの機能を追加しました。Zero Busが何をするかというと、名前のとおり、データインフラのためのバス（メッセージバス）がもう要らなくなるのです。Apache Kafkaのようなものを使う代わりに、このZero BusのAPIを叩くだけで、入ってくるデータをそのまま渡せます。バースト的でも、小さな行でも構いません。何百万ものファイルやバッファリングを気にする必要もありません。Zero Busは、非常に高いレートで叩き込まれたエントリをすべて受け取り、後で参照できる形でオープンなレイクに確実に現れるようにしてくれます。スケーラブルで、管理しやすいものです。
Ali： ふたつ目は、昨年発表したSpark Real-Time Mode、私たちがRTMと呼んでいるものです。これはオープンソースのフレームワークで、レイテンシを数十ミリ秒まで下げられます。これは本当に驚くべきことです。歴史的に、Sparkは何にでも優れていましたが、10ミリ秒まで下げることはできませんでした。リアルタイムのストリーミングでも、1秒程度のマイクロバッチを取るのが常でした。けれどもReal-Time Modeを使えば、それを本当に超高速にできます。多くの方はストリーミングのインフラとしてApache Flinkを使っていて、それが唯一の選択肢だったかもしれません。しかし今では、そうしたワークロードの多くを、オープンソースであるApache Spark上のReal-Time Modeで直接実行できます。
Ali： 最後の3つ目はLakeFlow Designerです。私自身、データエンジニアリングやデータ移動を、このLakeFlow Designerでやるのが本当に好きです。LakeFlow DesignerはAlteryxのような見た目で、ビジュアルなので、コードを一切見る必要がありません。代わりにAI、つまりGenieに話しかけて、「こういう変換をしたい」「この2つのテーブルを結合したい」と伝えると、それがどうなるかを視覚的に見せてくれて、皆さんが承認する。けれども裏側はすべてオープンソースのSparkで、実際にコードを検査でき、バージョン管理もでき、本番運用にも耐えられます。これら3つはすべてGAです。
4.2 IcebergとDeltaの統合（Ryan Blue登壇）
Ali： さて、これだけのデータを、これらのモダリティやコネクターを使って、さまざまなシステムから取り込めるようになりました。では、どのフォーマットを選ぶべきでしょうか。Delta Lakeを選ぶべきか、Apache Icebergを選ぶべきか。これは大きな問いです。そこで、ステージにApache Icebergの本来の生みの親であり、私たちが昨年買収したTabularのCEO兼共同創業者であるRyan Blueをお迎えしたいと思います。Ryan、調子はどうですか。実は、数年前のあなたの動画でちょっと恥をかかせたいんです。この動画には「なぜApache Icebergを気にすべきでないのか」という、なかなか興味深いタイトルがついていました。少し聞いてみましょう。
Ryan： （動画より）私は本気でそう思っています。皆さんはApache Icebergを気にすべきではありません。
Ali： Apache Icebergを気にすべきでない、と。実は私も賛成です。Delta Lakeのことも気にすべきでないと思っています。けれども、なぜそう言ったのですか。
Ryan： 誰もフォーマットなど気にせずに済むべきだからです。すべてのデータに対して、好きなツールを使えるべきなのです。仕事に合った正しいツールを使う――だからこそ私たちは最初から両方のフォーマットを作りました。
Ali： そうですね。実はこれはとても可笑しな話で、数年前は顧客との打ち合わせに行くと、IcebergがDeltaと比べてどう実装されているかの細部に入り込んで、「削除ベクター（deletion vectors）はこういうやり方でできるのか、ああいうやり方でできるのか」と聞かれたものでした。私は、業界がそんな方向に進むべきではないと思っていました。それで、今はどうなっているのですか。バージョンなどの状況を教えてください。
Ryan： ちょうどIceberg V3サポートのGAリリースを終えたところで、DBRでのマネージドIcebergテーブルが、とてもうまくいっています。それに続いて今年後半には、Delta 5とIceberg V4に組み込まれる統一メタデータ層をリリースする予定です。ですから、完全な統一というビジョンにかなり近づいています。
Ali： V3の何が特別なのですか。
Ryan： V3は統一データ層です。DeltaテーブルとIcebergテーブルの間でデータを共有するために、データファイルを書き換える必要がもうなくなります。
Ali： それは素晴らしい。つまり、ディスク上に配置されたデータは、IcebergであれDeltaであれ、ビッグデータとしては今や同一に見えるということですね。
Ryan： そのとおりです。
Ali： 素晴らしい。そしてV4では、残るのはほんの少しのメタデータだけになる。それはいつ手に入りますか。
Ryan： 今年後半を目指しています。あまり約束を増やしたくはありませんが、仕様自体はおそらくQ4のどこかで完成させられると思います。
Ali： 素晴らしい。これは本当に楽しみです。Ryanとコミュニティ全体、Icebergコミュニティ、Deltaコミュニティ、見事な仕事です。皆さんはこんなことを気にせずに済むべきなのです。もうこの話はやめにできますか。
Ryan： ええ。もし終わりなら、私には片付けるべき仕事がありますので。
Ali： というわけで、フォーマットは本当にどうでもいいのです。Databricksを使っているなら、DeltaかIcebergかは問題になりません。V3のおかげで、ディスク上にあるデータフォーマットは今や同じものになりました。データをこのオープンなフォーマットに取り込む方法については、これでお話しできました。やり方はひとつ、シームレスで、裏側はすべてSparkベースです。
5. レイクハウスとLake Base
5.1 レイクハウスの進化
Ali： では次に、取り込んだデータの上で実際にどう分析を行うかを見ていきましょう。約4〜5年前に発表したデータウェアハウス、私たちがレイクハウスと呼んでいるものです。当時のキャッチフレーズは「最良のデータウェアハウスはレイクハウスである」でした。なぜなら、オープンなのでデータを皆さん自身がコントロールでき、しかも機械学習のワークロードでも動くからです。前回のData + AI Summit以降のこの1年で、レイクハウスは大きく前進しました。レガシーなデータウェアハウスが持っている機能を110以上追加し、それらをより簡単に移行できるようにしました。
Ali： また、多くのAI関数もリリースしました。これこそ皆さんがレイクハウスに求めている主要なものです。データがテーブルにあるとして――これはデータウェアハウスで皆さんが扱うものですが――今ではSQLクエリの中からSQLのAI関数を呼び出せます。たとえば「これらのセルそれぞれについて、人々がどう感じているかセンチメント分析をしてくれ」と言ったり、「これらのセルそれぞれから、見つけた会社名を抽出してくれ」と言ったり、「この数値がどうなるか予測してくれ」と言ったりできます。それを非常に高いスケールでこなせるのです。実際これは、皆さんがデータウェアハウスで行う最も人気のある使い方になっています。さらに、既存のデータウェアハウスからの移行を支援するLake Bridgeという自動コンバーターも用意しました。オンプレミスや別のクラウドにあるデータウェアハウスからの移行を、今では本当にうまくこなせます。実際、皆さんが使ってくださっているおかげで、この1年だけでデータウェアハウスの消費量は倍以上になりました。
Ali： しかし私が本当にわくわくしているのは、共同創業者のReynoldがステージに上がって、新しいエンジンについて話すことです。Raidenという名前のエンジンで、何がすごいかというと、私たちがこれまで見てきた中で世界最速のエンジンなのです。他のあらゆるものとベンチマークを取ってきました。レイテンシをわずか数十ミリ秒まで下げています。これまでに私たちがやってきたどんなものよりもはるかに高速です。これについては今日のキーノートの後ほどのトークで彼が話します。
5.2 Lake Base（Postgres）
Ali： では、トランザクション処理についてはどうでしょうか。冒頭で申し上げたように、私たちはPostgresを本当に気に入っていて、本気で取り込んでいます。今日のAIはPostgresを本当に好みます。今日のどのAIに「どんなデータベースを選ぶべきか」と聞いても、オープンソースのPostgresと答えるでしょう。そして私たちがわくわくしているのが、Lake Baseと呼ぶものです。これはPostgresを取り出して分離し、そのストレージのすべてを安価なレイクの上に置けるようにする仕組みです。これはOLTP、つまりMySQLやOracleのようなトランザクション処理にあたります。データがレイクの上に置かれると、その上で素晴らしいことができるようになります。
Ali： たとえばサーバーレスのオートスケーリングです。Postgresをスケールアップ・ダウンでき、しかも非常に高速で、1秒未満で行えます。ゼロまでスケールダウンすることさえできます。これは本当に素晴らしくて、真夜中に誰も使っていなければ料金を払う必要がなく、レイクに置かれた安価なストレージの分だけ払えばいいのです。これは以前は不可能でした。他社は専用のストレージを持っていましたが、これはオープンソースのフォーマットで皆さんのレイクの上にただ置かれているのです。なぜこれを気にすべきかというと、データベースを動かすコストを大幅に削減できるからです。こうしたオートスケーリングによって、TCO（総所有コスト）が大きく下がります。
Ali： しかし、Lake Base Postgresの最もクールな機能はそれですらありません。最良の機能は、エージェントが本当に大好きな、ブランチング（branching）という機能です。これは、ペタバイト級の巨大なデータベースに対して「これのクローンを作ってくれ」と言うと、1秒未満で「完了」と返ってくるというものです。何をしているかというと、実際にデータベース全体をコピーしているわけではありません。どのみちデータはレイクの上にあるので、ただ追跡しているだけです。「2つのコピーがある」と言いますが、実際には1つのコピーで、片方に変更を加えると「この変更はこのコピーにある、もう片方のコピーにはこの変更は存在しない」と追跡するだけです。いわゆるcopy-on-write（書き込み時コピー）です。
Ali： なぜこれが重要かというと、企業内でデータベースを構成するやり方そのものを完全に変えるからです。ほとんどの企業は、何千、何万ものデータベースインスタンスを動かしていて、DBAがそれらすべてを管理しようと駆け回っています。なぜこれほど多くを抱え、サイロ化されたデータの何千ものコピー代を払っているのかといえば、ユーザー受け入れテスト用のデータベース、本番データベース1号、本番データベース2号、ステージング用、R&D用――といったコピーがすべて必要だからです。しかしブランチングが可能にするのは、たったひとつのインスタンスを持ち、その異なるブランチを持つだけ、という状態です。これでTCOは下がり、管理は容易になり、しかもエージェントがこれを大好きなのです。エージェントはただブランチを切ってデータで実験し、何かを試したい、それを素早くやりたいと考えるので、あの1秒未満のレイテンシは彼らにとって非常に重要です。データベースが立ち上がるのを10分も待ちたくはありません。そして、もし何かがうまくいかなければ――データが破損したり、エージェントが誤って何かをしてしまったりしたら――以前のスナップショットに戻れるべきです。
Ali： ですから、今後何か開発をするなら、ぜひLakeBase Postgresを使ってみてください。今後12カ月で、人類の歴史上かつてないほど多くのソフトウェアが書かれることになります。そのソフトウェアはすべてLLMやコーディングツールを使って書かれ、それらは裏側にデータベースを必要とします。それを、低コストでオープンソースのLakeBase Postgresにしようではありませんか。これこそエージェントが愛するものです。そして今日は、これに関してもうひとつ私がとてもわくわくしているトークがあります。ここでは詳しく話しませんが、Reynoldが戻ってきて、私たちがLCapと呼ぶもの――LakeBaseとLakeHouseの統合について話します。これは業界が40年にわたって取り組んできたブレイクスルーで、私たちはついにそれを成し遂げたと考えています。彼がそれについても話してくれます。
6. コントロール — Unity CatalogとUnity AI Gateway
6.1 Unity CatalogとOpen Sharing
Ali： これでデータを取り込むLakeFlow、分析を行うデータウェアハウスとしてのLakeHouse、そしてトランザクション処理を行うLakeBaseについてお話ししました。つまり、選択肢を持ったデータレイヤーが、エージェントが高速かつシームレスに消費でき、データで実験できる形で、AIのために底辺に整ったわけです。けれども、先ほど申し上げたように、私たちはコントロールも解決しなければなりません。エージェントをすべてのデータに対して野放しに解き放つわけにはいかないからです。彼らが何をしているかをコントロールする必要がある。だからこそ、私たちは数年前にUnity Catalogプロジェクトを始めました。
Ali： このプロジェクトを始めたとき、業界がやっていたのは構造化テーブルのためのカタログでした。データウェアハウスは行と列の構造化テーブルを見て、「この列は誰かの給与情報だから隠せるか」といったことをやっていた。そういう構造化データへのアクセス制御です。しかし私たちがUnity（統一）と名付けたのは、制御は構造化データだけに対して行うべきではなく、組織が持つすべてのデータ・AIアセットに対して行うべきだと考えたからです。非構造化ファイルやPDF、AIモデル、そして長年にわたって追加してきた50を超えるアセットタイプ、そのすべてに対して制御できるようにしたい。これがUnity Catalogのアイデアその1です。アイデアその2は、アクセス制御をするだけではない、という点です。すべてをロックダウンして終わり、ではなく、組織内のデータを発見し、民主化できるようにもしたい。異なるデータセットのリネージ（来歴）を追跡し、このデータがどこから来たのかをグラフとして可視化できるようにしたい。すべてのものに対してコスト管理を行えるようにしたい――そうしなければコストは尽きてしまいますから。そして組織が持つすべてのもののデータ品質も見られるようにしたい。これらすべてがUnity Catalogの一部であり、極めて重要です。
Ali： だからこそ、私たちはUnity Catalogに一度も課金していません。Unity Catalogは無料で、しかも数年前にオープンソース化し、さらにオープンソース化を加速させています。この1カ月でも、その一部をオープンソース化する人員を増やしました。非常に速く進んでいます。そして、データを共有できるようにすることも発表しました。これは私たちにとって本当に重要でした。業界の他社は、いわばロックインされた共有をやっていました。「私のソフトウェアを買え、そして他の誰かと共有したければ、その相手も私のソフトウェアを買え、そうすればその間でデータセットを共有できる」と。だからこそ私たちは数年前、Delta Lakeプロジェクトの一部としてDelta Sharingをオープンソース化しました。これで、あらゆるデータアセットを、エコシステムの誰とでも共有できるようになりました。
Ali： そして今年とりわけわくわくしているのは、Delta Sharingのスーパーセットとなる新しいプロジェクトをオープンソース化することです。Open Sharingと呼んでいます。これによって、Deltaだけでなく――今や同じフォーマットなので――Icebergとも共有でき、さらにデータアセットだけでなくAIアセットも共有できます。つまり、自分のエージェントやスキル、モデルを共有でき、しかもそれをオンプレミスでも行えるのです。
6.2 Unity AI Gateway
Ali： これだけのことがUnity Catalogでできて、Open Sharingもある。しかしこの1年で起きたのは、AIガバナンス――これは常にUnity Catalogの一部でしたが――それが多くの組織で非常に複雑になってきたということです。今、組織には大量のエージェントがあります。皆さんはLlama IndexやLangChainを使ってエージェントを作っているかもしれません。SaaSプロバイダーは今や各社それぞれ「うちのエージェントを使ってくれ」と提供してきます。彼らは使ってほしいエージェントビルダーを持ち、独自のMCPサーバーを持ち、「うちのMCPサーバーを、こういうスキルと一緒に使ってくれ」と言ってきます。皆さんの組織の開発者たち自身もMCPサーバーやスキルファイルを開発しています。各社のモデルにもさまざまなバージョンがあり、それぞれ能力が違い、存在したりしなかったりする。コーディングツールやバイブコーディングのものもあれば、組織内ではコワーク型のエージェントもますます増えてきている。これはもう泥沼で、完全な混乱状態です。
Ali： では、この何が問題か。問題その1は、コストが暴走していることです。これが今いちばんの問題だと思います。誰に話を聞いても本当に心配しています。コストはただ急上昇していて、しかも誰も可視性を持っていません。それは誰のエージェントなのか、どのモデルなのか、何をしていたのか。トークンの使い過ぎが起きているのに、全体を横断して上限を設けたり、レート制限したりする手段がない。問題その2は、エージェントが何をしているかを制御する手段がないことです。エージェントが適切なデータにアクセスしていることをどう保証するか、監査できるか、入出力にガードレールを設けられるか、そしてアイデンティティをどう管理するか。彼らは誰の代わりに行動しているのか、それをどう追跡するか。そして最後、これが先ほど言ったとおり最も重要ですが、どうやって選択肢を持ち、ロックインなしにこれを行うか、です。なぜなら、最先端モデルの寿命は今や1カ月だからです。昨年11月にはGoogleからGeminiが出て「これが史上最高のモデルだ」と皆で乗り換え、1月から2月頃には明らかにOpusが史上最高となり、その後OpenAIがGPT-5.5を出して史上最高となり、先週にはMythosやFableが出て皆で乗り換えようとしたら、それがキャンセルされ、また戻ってきて……という具合に行ったり来たりしているのです。どうすれば柔軟性を確保し、どれでも選べて、選択肢を持てるようにできるか。これらが本当に重要な3つの問題です。
Ali： だからこそ、私たちはUnity Catalogの一部として、皆さんのすべてのエージェント、すべてのAI支出を一カ所で管理・制御できる場所を切り出すことを発表できて、とてもわくわくしています。Unity AI Gatewayと呼んでいます。これは単一のガラス窓（single pane of glass）で、すべてのエージェント、すべてのAI、起こるすべてのことに対するひとつの入口になります。皆さんが使っているどんなハーネスも、ここを通せます。これもUnity Catalogの一部なのでオープンソース化されていて、課金もしません。さらにAI GatewayはMLflowの一部でもあるので、こちらもオープンソースです。
Ali： しかし、おそらく会場の全員がご存じではない最も重要なことのひとつは、私たちがフロンティアモデルのためのキャパシティを提供する、という点です。たとえば、皆さんがDatabricksに10万ドルを支払うとコミットしたとします。その分をLakeFlowに使ったり、Lakehouseに使ったりもできますが、その10万ドルをそのまま、OpenAIのモデルやAnthropicのモデル、あるいはGeminiのトークンとして、私たちから直接使うこともできるのです。しかもこれを、Azure、GCP、AWSのどのクラウド上でも行えます。次に、組織内のすべての支出について完璧なオブザーバビリティを得られます。支出がどう発生しているかを可視化するダッシュボードがあり、上限を設定でき、予算を設定できます。グループやサブグループ、さらには個人レベルまで予算を設定でき、誰かが予算を使い切ると、皆さんにアラートが届く。あるいは、ただ止めてレート制限することもできるので、誰も使い過ぎないようにしたり、毎日どれだけ使ったかをメールで知らせたりできます。そして最後に、すべてのAIについて、安全性、コンプライアンス、監査、アイデンティティ管理を強制できます。これはハーネス、モデル、エージェントを含みます。
Ali： ひとつ強調しておきたいのは、これはDatabricksの中にあるMCPやツールだけの話ではない、ということです。組織内にあるどんなベンダーのMCPでも、Unity AI Gatewayに登録すれば、すべての利用状況を追跡でき、状況を見られます。さらに素晴らしい機能として、MCPに対して一度認証すれば、そのすべてに対して認証が効くので、何度も何度も認証し直す必要がありません。
7. コンテキストレイヤーとGenie Ontology
7.1 既存エージェントの限界
Ali： さて、これでコントロールとコスト――どうやって皆さんのデータを準備するか、エージェントにとって高速なオープンフォーマットでデータを整えるか、Unity AI Gatewayでガバナンスとコスト管理をどう行うか――が片付きました。そこで、いよいよコンテキストレイヤーに話が移ります。先ほど言ったとおり、AIは十分に賢い。AIに知能の問題はなく、コンテキストの問題があるのです。では、そのコンテキストを実際にどうやってAIに入れるか。これが最も重要なことです。
Ali： 今日それがどう機能しているか、例を挙げましょう。皆さんは今、こうしたエージェントを使っています。コーディングエージェントを使っているかもしれません。世に出ている最良のエージェントを見ると、だいたいこんなふうに動きます。組織内で皆がやっていることすべてのドキュメントからなる巨大なグラフがあって、皆さんが質問をすると――この赤い点がそうですが――エージェントはそこへ向かいます。たとえば「ヨーロッパでの直近2週間の製品売上はどうなっているか」と聞くと、エージェントはまずひとつのドキュメントを見に行きます。そのドキュメントを読んで「何か面白いことはあるか」と考え、「お、リンクがある」と気づいて、MCPサーバーを開いて別のドキュメントに飛び、それを読む。こうやって皆さんのコーパスをライブでループしながらデータを取りに行くわけです。
Ali： しかし、今日のエージェントが――フロンティアのものも含めて全部が――使っているこのアプローチには大きな問題があります。問題その1は、非常に時間がかかることです。ライブでデータを探し回るこのループは、ただただ長い時間がかかります。皆さんも見ているとおり、単純な質問でも、答えが返ってくるまでに10分、15分かかったりします。MCPサーバーをライブで巡っていて、どこを探せばいいかわからず、コンテキストを持たないままライブで試行しているからです。問題その2は、コストが非常に高いことです。冗談で言われるのは、「このファイルの名前を変えてくれ」と頼むと、10分かけて5ドル請求される、というものです。検索をしながら大量のトークンを消費して、すべてを組み立てるからこうなるのです。
Ali： けれども、この2つすら最大の問題ではありません。これらはユーザー体験を悪くし、コストを高くします。最大の問題は、品質が損なわれることです。なぜなら、組織内のすべてのドキュメントとデータアセットは巨大だからです。エージェントはその一部のごく小さなサブセットを、いわばランダムウォークでたどっているにすぎません。それでも返ってくる答えは目を見張るもので、私たちは皆わくわくして使っていて、コストは上がり続けた。けれども実際に精度を見てみると、これがかなり問題なのです。では、どう解決するか。私が今日発表する中でも最も重要なもののひとつ、Genie Ontologyです。
7.2 Genie OntologyとOntoRank
Ali： Genie Ontologyが何をするかというと、組織が持つすべてのデータと接続し、バックグラウンドで――つまり皆さんが質問をしているときではなく、その裏で――組織が持つ最も重要な知識のグラフを構築し、そのコンテキストをどのエージェントにも渡せるよう準備しておくのです。ここで本当に重要なのは、それがレイクハウスやDatabricksの中にあるものだけではない、という点です。Google DriveやSharePoint、メール、Google Calendarなど、皆さんが設定したあらゆるものに接続し、そこにあるすべてに枝分かれしてアクセスできます。
Ali： そしてリサーチチームが、OntoRankというアルゴリズムを開発しました。名前が良くないのは承知していますが、リサーチチームが考えたものなので。OntoRankとは何か。これは、覚えている方もいるでしょうがPageRankのようなものです。PageRankは、25年か30年前にGoogleがウェブ全体を取り込み、最も重要なサイトのインデックスを作る方法でした。Google以前のAltaVistaやYahooは、ある単語がそのサイトに何回出てくるかを見ていただけで、それがSEO――検索エンジン最適化――につながり、人々は順位を上げるために同じ単語をウェブページに千回も書き込んだりしました。しかしPageRankは、グラフそのものから何が重要かを割り出せました。OntoRankは、組織が持つすべてのアセットに対して同じようなことをします。ただし、これはPageRankそのものではありません。この問題のほうが難しいのです。なぜなら、リンクのあるウェブページだけではなく、皆さんが持つあらゆるアセットを対象とし、しかもそれらは異なるアセットタイプだからです。ソースコードはGoogleドキュメントとは違う、と識別する必要があります。さらにここにはユーザーも登場します。組織内のユーザーは組織図の一部であり、彼らがどれくらいの頻度で何にアクセスするかも実際に重要です。こうしたあらゆるアセットタイプと組織内のすべての人物を取り込んで、このオントロジーのグラフを構築し、それがフロンティアのエージェントとともに素晴らしいことを可能にしてくれるのです。これが、私たちが与えるコンテキストです。
Ali： ここで「いや、私はもうコンテキストをまとめてある。自社でセマンティックレイヤーを作ったし、長年かけて作ったビジネス用語集（business glossary）もある」と言う方もいるでしょう。Genieはそれをどのソースからでも取り込めます。つまり、自前のセマンティクスを持ち込めるのです。Unity Catalogの一部にUnity Catalog Semanticsというものがあり、AtlanやAtScaleといったパートナーから、あるいはセマンティクスを持つ既存のBIツールから、あるいは皆さんがすでに持っているビジネス用語集から持ち込めて、人間がそれをキュレーションすることもできます。喜んでそれを受け取り、Genieをより賢くするのに役立てます。ですから、どちらの陣営に属していても――完全に自動的に行われるべきだと考えるなら、Genie Ontologyがそれをやりますし、手作業でのキュレーションをたくさんやりたいなら、モデル化されたセマンティクスでそれができます――両方ともうまく連携して機能します。これらがエージェントに供給されるわけです。
Ali： 製品の中ではこんなふうに見えます。グラフをクリックして、探索できます。ここで探索しているこのグラフは、私たち自身のための、Databricks社員のためのDatabricksの一インスタンスにすぎません。これは450万を超えるオントロジーのデータスニペットを収集・構築しています。450万ものスニペットを、エージェントがライブで一つひとつ見て回るのは明らかに不可能です。けれども、これはすでにそれをやり遂げ、このグラフを構築しているので、皆さんはそれを手にできるのです。
8. Genieエージェント群とKen Wongによる紹介・比較実験
8.1 4種のエージェントの概要
Ali： このオントロジーが、いよいよ私たちのエージェントに供給されます。エージェントには3つのカテゴリーがあり、それぞれが速さ、コスト効率、そして品質を高めるこのコンテキストを与えられます。Genie 1、Genie Agents、Genie Codeです。まずGenie 1。これは、組織内のすべてのデータアセットにアクセスする一カ所です。Databricksでこの3年ほどGenieを使ってきた方もいるでしょうが、それとは別物です。従来のGenieは特定のドメインに閉じていて、たとえばマーケティングの人がマーケティングの質問だけをGenieのスペースで聞く、というものでした。Genie 1は、組織内のどんなビジネスユーザーもログインできる一カ所です。10万人の社員がいれば、自動的なアイデンティティ管理を有効にして全員にGenie 1を渡せます。彼らはデータウェアハウスやその他のDatabricksインフラを手にするわけではなく、データウェアハウスを立ち上げて大金を使うこともできません。ただ、こうしたシンプルなインターフェースを得て、そこで質問するだけです。他のエージェントと同じように見えますが、違いがあります。画面下部のあらゆるソース――Google DriveやSharePointなど――からデータを取得でき、スキルを持てて、タスクをスケジュールしてコワーク的な作業をさせられます。そして何より、Genie Ontologyにアクセスできる。これがすべてを変えます。私自身のお気に入りの使い方はスマホ、iPhoneやAndroidで使うことで、ビジュアルでグラフが見られ、ダッシュボードと統合されています。
Ali： 次にGenie Agentsです。Genie 1で交わした会話を「これをエージェントにしてくれ」と言うと、それをエージェント化して全社に提供できます。たとえば「これは私のすべてのHRドキュメントだ」とエージェントを作って会話し、HRに関する質問に答えられることを確認したら、それを組織全体に提供できる。誰でもそのエージェントにHRの質問ができるようになり、SlackやTeamsなど好きなモダリティに置けます。さらに自律的な作業もできます。毎日Salesforceから情報を取得し、準備し、Workdayに入れ、レポートを送り、他のエージェントと協働する、といったことです。そしてGenie Codeです。これは他のコーディングエージェントと似ていますが、2つのことに非常に長けています。ひとつはデータエンジニアリングで、プラットフォーム上での13年のデータエンジニアリングの蓄積により、パイプラインやコードを書くのが本当に得意です。もうひとつは機械学習とデータサイエンスで、機械学習モデルを構築してGPUで訓練し、その精度が本当に高いことをテストでき、組織内で機械学習へのアクセスを民主化できます。
Ali： さらに、私が特にわくわくしているものを発表します。多くの組織にとって最も変革的なエージェントになると思うもので、Genie Zero Opsと呼んでいます。名前のとおり、これはバックグラウンドで動き、皆さんのすべてのデータパイプライン、あるいはデータサイエンスの機械学習モデルを見て、たとえば「このパイプラインが午前2時に落ちている」と気づきます。すると調査に向かい、「なぜ落ちているのか。エラーがある、このデータに見慣れない新しい列があるようだ」と突き止め、その列の名前を確認し、追加できるかを見る。本番パイプラインに影響を与えない別の環境で、実際にコードを書いて実験するのです。準備ができると、皆さんのスマホに通知を送り、皆さんはそれを見てレビューし、良ければ「承認」をクリックするだけでパイプラインが直る。人間がループに残っています。もちろん「自動でやれ」と設定もできますが、私はおすすめしません。誰も午前2時に起きたくはありませんよね。オンコールの人がいて「パイプラインが壊れた、なぜだ、調べろ」と、明け方に2時間費やし、皆が怒鳴り合う――これがデータエンジニアリングの世界です。Zero Opsでこれをずっとシンプルにできることに、本当にわくわくしています。
Ali： そして最後にアプリです。組織内でデータとAIへのアクセスを民主化する自前のアプリを、今では本当に簡単にバイブコーディングできます。lovableやreplit、Vercelといった私たちのパートナーを使うこともできますが、私たちもGenie App Builderを提供します。ここで鍵となるのは、私たちが自動的に構築するGenie Ontologyです。それこそが本当の秘伝のソースで、コワークやレイクハウスの外にあるデータへのアクセスも非常に重要なのです。
8.2 5エージェント比較実験とベンチマーク
このオントロジーを基盤に、Genie 1で何ができるかを示すため、Databricksのプロダクトマネジメント担当シニアディレクターであるKen Wongが登壇しました。
Ken： おはようございます。今日はGenie 1を紹介します。Genie 1は、皆さんのすべてのデータとアプリに接続できるAIの同僚で、組織内の誰もがインサイトを得て、アクションを自動化さえできます。Genieに話しかけるだけで自律エージェントを作ることもできます。けれど、皆さんはこう思っているでしょう。2026年に、なぜまた別のAIエージェントが必要なのか、と。答えは単純です。今あるものはエンタープライズデータをうまく扱えないからです。データに接続して推論することがそもそもできないか、できても、実際の意思決定を任せて信頼できるほどの精度がない、ましてや業務を自動化させられるほどではないのです。
Ken： 何を言っているか、お見せします。昨日Databricksで製品諮問委員会（PAB）のミーティングがありまして、Genie 1に手伝ってもらって、私たちの全顧客の包括的なプロファイル――各アカウントで何が起きているか――を作ろうとしました。これにはGenie 1が、私の個人のメールやSlack、カレンダーを含むすべてのシステムに接続し、PABに誰がいて何を話してきたかを把握する必要がありました。さらにSalesforceに接続してユースケース情報を引き出し、加えてDatabricksに接続して、彼らが持つすべての消費データを引き出す必要がありました。彼らがGenieを何に使っているかについて、込み入った質問をたくさん盛り込みたかったからです。そしてGenie 1が出してきたのがこれです。一部はぼかしていますが、Databricksやこれらのシステムに問い合わせたうえで、全顧客の包括的でビジュアルなプロファイルを返してくれました。
Ken： そこで私は、まったく同じプロンプトを、世に出ている5つの主要なAIエージェントで試してみました。私たちが持つソフトウェアに同梱されていたAIアシスタントを2つ、そして主要なコーディング・コワークエージェントを3つです。すると、こうなりました。1つ目のAIアシスタントは、実は私がよく使っているもので、ドキュメントを書いたりするのに使っているものです。プロンプトへの応答はとても速く返ってきました――少し速すぎるくらいで、何かおかしかった。最初に気づいたのは、「PABには24社の顧客がいる」と書いてあったことです。これが事実でないと私は知っていました。そこで「この24という数字はどこから来たのか」と聞いたら、何と答えたと思いますか。完全にでっち上げた、と白状したのです。私は仕事だけでなく個人でも課金して使っているものだったので、唖然としました。でも、これはエンタープライズのグラウンディング（事実への接地）がいかに重要かを物語っています。
Ken： もう1つのAIアシスタントは、もっとうまくやりました。既存のドキュメントを検索してアカウント概要を引っ張り出してきたのですが、それらはすべて古く、四半期前のもので、私がしたかった会話にはもう関係のない情報でした。だから結果は完全に使い物にならない。良いニュースは、とても速かったことくらいです。次に、コーディングエージェントとコワークエージェントは、本気で挑んでくれて、ライブデータを引き出すためにすべてのシステムや構造化ソースに接続しました。けれど、この手のものを使ったことがある方ならおそらく経験があるとおり、必死に情報を引き出そうとして時間制限に達し、「続けるには許可がいる、どれだけのトークンを燃やすかわからないが」と聞いてくる。続行を許可すると、また何度も何度も繰り返す。そしてクールなアスキーアートを返してきたかと思えば、「実はまだ全然終わっていない、ほんの一部しか進んでいない」とまた白状する。30分かけて部分的なレポートしかない。Genie 1ができたこととは、まさに天と地ほどの差です。
Ken： 「いや、それは一回限りのテストで、都合のいい例を選んだだけだろう」と言われるかもしれません。けれども、これはDatabricks Researchがコーディングエージェントの新規質問への対応力について行ってきた調査と、極めて一貫しています。私たちは、社員がGenieに実際に投げている質問からベンチマークを作り、同じ問題をコーディングエージェントに解かせました。これは、セマンティックレイヤーで簡単に解けるような月並みな単純質問ではなく、たとえば「Genieを使う全顧客のうち、サードパーティのエージェントも使っているのは何パーセントか」といった、これまで誰も聞いたことのない込み入った質問です。そして見えてきたのは、コーディングエージェントは最良のものでも約半分の確率でしか解けず、しかも数分かかる、ということでした。このチャートは覚えておいてください、後で戻ってきます。実データに関する質問で正答率50%というのは、基本的に使い物になりません。文字どおりコインを投げているのと同じです。これらのエージェントの仕組みを知っていれば驚くべきことではありません。彼らはエージェント的ループを通る過程で、正しい答えにたどり着くには、質問に答えるのに必要な正しいコンテキストに、偶然たどり着くような正しい推論ステップの並びに、たまたま行き当たる必要があるからです。だから、いわばその辺を歩き回って最善を尽くすしかなく、得られる精度と、コストや実行時間との間には、非常に現実的なトレードオフがあるのです。
8.3 セマンティックレイヤーの限界とOntologyの成果
Ken： この問題を解くための、私たちの現状での最善のアプローチは、コンテキストを注入すること、つまり正しいことへのヒントを与える情報を渡すことです。AIの世界から来た方ならこれを「スキル」と呼ぶでしょうし、BIの世界から来た方なら「セマンティックレイヤー」と呼ぶでしょうが、実は同じ考え方です。「やるべきことを教えてやれば、もっとうまくやれる」というわけです。問題は、最も安定したビジネス概念についてこれをやるのは完全に理にかなっていて、実際ベストプラクティスでもあるのですが、組織内でやっていることの広がり全体に対してこれをやるのは現実的でない、という点です。考えてみてください。マーケティングのキャンペーンの一つひとつが「リード」を少しずつ違う定義で扱っていたり、スクラムチームの一つひとつがJiraのフィールドを少しずつ違うふうに使っていたりする。そのすべてを書き下すことなど、現実的にできません。
Ken： 「では、AIを使ってこれらのモデルを生成させて解決すればいいじゃないか」と言われそうですが、それはうまくいかないのです。実はAnthropicがこの限界について素晴らしいブログを公開していて、これをやると結局、AIをひとつの特定のユースケースにエンコード、いわばアンカリング（固定）してしまい、かえって全体の結果に悪影響を及ぼす、と論じています。では、私たちの解決策は何か。Aliに少し先を越されてしまいましたが、Genie Ontologyです。Genie Ontologyは、Unityにあろうと既存のセマンティックモデルやモデリングツールにあろうと、皆さんが持つあらゆるモデル化済みのコンテキストの上に、学習された層を加える自動コンテキストレイヤーです。これによって、Genieやオントロジーに接続されたあらゆるエージェントが、データを使って質問にはるかに正確に答えられるようになります。
Ken： 仕組みを説明します。まずGenie Ontologyは、知識を含む皆さんのシステムに接続します。たとえばDatabricksのシステムを使っていれば、パイプライン、クエリ、ダッシュボードなどに、エージェントがデータについてどう推論できるかを示す膨大な情報があります。私たちはそれらを――式や関係性だけでなく、「この人は特定のトピックについて本当に詳しい」といった専門性までも――抽出し、内部のナレッジストアに格納します。そしてその知識を、私たちがOnto Rankと呼ぶアルゴリズムで処理します。これがPageRankのようなアルゴリズムで、どのスニペットが実際に権威あるものかを判定するのを助けます。質問がGenieに来ると、この情報を引き、権限を適用し――基盤ソースのアクセス権限も抽出してあるので、権限の漏えいを心配する必要がありません――そのコンテキストをエージェントのループに注入することで、Genieははるかに正確に質問に答えられるのです。たとえば「登録者は何人か」と聞けば、一切モデル化していなくても、私たちの内部システムで登録をどう捕捉しているかの機微をGenieが知っています。それがどこから来たのか知りたければ、検査して、基盤のダッシュボードからこの計算をどう学習したのかを確認できます。
Ken： さて、先ほどのチャートに戻りましょう。マーケティングチームには少し怒られています。この動画を2週間前に撮ったので、数字は今ではもっと高いのですが。汎用のコーディングエージェントで何が起きたかは見たとおりです。ではオントロジーを備えたGenieはどうか。社内テストで見えてきたのは、主要なエージェントに対して、精度で一貫して30パーセントポイント以上の改善があり、実行時間はおよそ半分だ、ということです。そして、Onto Rankアルゴリズムのチューニングを続け、オントロジーの広がりを拡大していけば、この精度をさらにずっと高く押し上げられると確信しています。この、Genie Ontologyによって可能になった精度のレベルがあって初めて、本当のデータの同僚を作れます。すべての社員に渡して、実際にデータで意思決定をさせ、意思決定の自動化さえできる――それが基盤なのです。
9. Elise JorisによるGenie 1詳細デモ
9.1 ドキュメント生成とオントロジー検証
この基盤の上でGenie 1が実際に何をできるかを示すため、Elise Jorisがステージに招かれました。
Elise： 皆さん、こんにちは。Eliseです。DatabricksでGenieのプロダクトマネージャーをしていて、日々の業務でGenieをたくさん使っています。ちょうどこれからGenieのOKRについてのエグゼクティブレビューがあるので、その準備をGenieで進めてみます。ここがGenie 1で、ご覧のとおりかなりシンプルなインターフェースです。真ん中に私のチャットがあり、ドキュメントを下書きしたりスキルを作ったりするボタンがいくつかあります。左側には過去のチャットと、私が使えるすべてのエージェントやアセットが並んでいますが、それは後ほど。まずはGenieに、レビュー用のドキュメントを作ってもらうところから始めます。Databricksのどのチームも同じテンプレートを使っていて、指標、ハイライト、ローライトといった項目があります。そこへのリンクをGenieに渡しました。あわせて、未対応のJiraチケットを持っている人たちをつついて（poke）、案件が前に進むようにしてほしいとも頼みました。
Elise： Genieが動いている間、何を考えているかをクリックして見ることができます。ご覧のとおり、Unity Catalogの用語集（Glossary）の中で何か興味深いものを見つけたようです。関連しそうなオントロジーのスニペットを見つけたみたいですね。これはすべて、私がもともとアクセス権を持っているデータからのものです。Genieは別の権限システムを作ることを強いてはいません。Unity Catalogを通じて皆さんがすでに持っている権限を、そのまま強制しているのです。さらにGoogleのファイルをいくつか取得し、Jiraチケットも見つけたようです。私が頼んだとおり、MCPを使ってそれらのチケットにコメントしました。そして今、DatabricksとBigQueryの両方をまたいでSQLを実行し、最新の真実（ground truth）を取りに行っています。これは本当に重要なことです。多くの汎用エージェントは、ドキュメントにすでに書かれていることを引き写すだけですが、今週の指標についてのドキュメントなど存在しません。だからこそ私はこれをやっているわけです。Genieは数字を理解していて、私たちのライブの運用データに基づいて結果を実際に計算できます。
Elise： そうこうするうちに、もうレビュー用のドキュメントができたようです。Genieが指標を引き、地域別に分解してくれました。きれいな可視化をいくつもつけて、ハイライト、ローライト、異常値も拾ってくれています。しかも、それをかなり速くやってのけた点に注目してください。試行錯誤のエージェント的ループをひたすら回して大量のトークンを食いつぶすのではなく、Genieはまっすぐ真実へ向かいました。これこそGenie Ontologyの働きです。では、これを信頼していいとどうやってわかるのか。そのために、ここの引用（citations）を開いてみます。これは、Genieが私の質問に答えるのに実際に使ったすべてです。テーブル、外部カタログ、チケット、ドキュメントがあります。用語集の定義も実際に使ったようで、ここに「検証済み（verified）」と出ています。でも、オントロジーそのものを見て、Genieがすべてを正しく推論したか確かめたいと思います。
Elise： ここに見えているのがオントロジーのスニペットです。これらは、Genieが自動的に学習・評価した、私たちのビジネスについての事実です。「エンゲージメント」をどう定義するかのスニペットや、Jiraで何が「ブロッカー」とみなされるかのスニペット、地域別エンゲージメントを引くのに使えるSQLのスニペットがあるようです。最初のスニペットをクリックしてみると、ここに完全な定義が見えます。私たちは30秒より長く続いたセッションを見ているのですね。これをGenieは、同僚のChungが作成したモバイルKPIダッシュボードから引いてきたようです。しかも高いオーソリティスコア（authority score）がついています。これは、そのスニペットがどれくらい頻繁に使われているか、どのアセットから引かれたかといった要素から決まるもので、Kenが話していたOnto Rankアルゴリズムにさかのぼります。Chungのプロフィールをクリックすると、彼が私たちのチームが大事にしているドメインの多くに関わっているのが見えますし、実際、Genieが彼の作成したアセットから多くのスニペットを引いていることもわかります。
9.2 エージェント作成と各種展開
Elise： さて、ここにいるついでに、これを毎週実行するようスケジュールしておきましょう。そうすればJiraを自分で管理せずに済みます。よし、できました。もう一歩進めてみます。Genieに、ドキュメントへ予測（forecast）を追加してもらいます。チームメイトのひとりがすでに予測用のスキルを持っているので、それを使います。特別なことは何もしておらず、組み込みのforecast関数を使い、私たちが予測をどうレビューするのが好きかの指示をいくつか加えただけです。これも、Genieがライブの運用データに基づいて結果を計算できるからこそ可能なことです。予測が追加され、きれいな可視化もつきました。では、これを送り出します。メールとSlackで共有します。
Elise： このOKRレビューは一度きりのものではありません。モバイルアプリの最新状況について、しょっちゅう更新を求められます。そこで、この会話のコンテキストを使って質問に答えられるエージェントを作ります。名前をつけて……できました。これはエキスパートの同僚で、Genieモバイルアプリに関する質問に答え、アクションも取れます。すぐに陳腐化してしまうOKRドキュメントと違って、このエージェントは常に最新の状態を保ち、しかも結果をその場で計算できます。せっかくなので、これを他のPMたちと共有しておきます。エージェントをクリックすると、私はいま自分のエージェントと直接チャットしています。何の製品の話かを指定する必要はありません。すでにエージェントに組み込まれていて、モバイルアプリにカスタマイズされているからです。Genieが自動生成したエージェントの詳細にもそれが表れています。もっと広く考えれば、こうしたものを使いそうなあらゆるチームが想像できます。たくさんの質問に答えなければならない部門――HR、IT、財務など――を考えてみてください。今や組織内の誰もが、こうしたエキスパートの同僚を一カ所で作り、協働できるのです。ここからエージェントを管理して、スコープを絞ったり、指示を研ぎ澄ましたり、コンテキストを加えたり、あるいは認証（certify）したりできます。認証すると、組織のエージェント一覧ページに認証済みエージェントとして現れ、Genie Ontologyもそれを優先するようになります。
Elise： 私はデスクトップだけで仕事をしているわけではなく、移動中にもたくさん作業します。だからGenieのモバイルアプリを使っています。スマホでアプリを開くと、ちょうど通知が来たようです。アプリのエンゲージメントが急上昇しています。Genieを使ってGenieの仕事をするのは、なんともメタな感じですね。アプリをクリックして詳しく知ることも、追加の質問をすることもできます。はっきりさせておきたいのは、このインサイトを私が設定したわけではない、という点です。Genieは私の活動から、私がアプリのエンゲージメントを気にかけていると知っていて、何か興味深いことが起きたときに、こちらが聞くまでもなくプロアクティブに知らせてくれるのです。これは本当に強力です。Genieはもはや受け身のQ&Aツールではなく、私が問いを立てることすら知らないうちに、大事なことを持ってきてくれるプロアクティブなAIの同僚になりました。こうして、ほんの数分のうちに、プロジェクトを前に進め、エグゼクティブレビューの準備をし、同僚たちの質問に答え、聞くことすら思いつかなかったことまで学べたのです。これが本当に質の高いAIの同僚で、Genieがオントロジーを通じて私たちのビジネスを理解しているからこそ可能になっています。ドキュメントを引き写すのではなく結果を計算でき、その過程で組織のガバナンスも強制できる。ぜひ皆さんも自分のデータで試して、フィードバックをお寄せください。
このデモを受けて、Ken Wongが再び話を引き取りました。
Ken： どうでしたか。Genie 1はデータに明るいAIの同僚です。完全なコアの能力を持っていて、ドキュメントを作り、それも既存のものを要約・引用するだけでなく、まったく新しい分析をその場で計算します。私たちが持つコネクターのおかげで、皆さんのすべてのシステムに接続でき、皆さんが席を外している間に動くようスケジュールでき、しかもノートPCを開いたままにしておく必要もありません。カスタムのものも含めてあらゆるシステムに統合できます。すべてUnity AI Gatewayを通じて管理されるカスタムMCPツールがあるからです。同僚と共有・作成できるカスタムスキルを開発でき、Genieに話しかけるだけで特定ドメインに特化した専用エージェントを作り、その性能を時間をかけて高めていくこともできます。
Ken： たとえばWarner Music GroupはGenieをDatabricksのデータにも、Databricks以外のデータにも使えていますし、General Motorsは何百ものGenieエージェントを本番に投入して、あらゆるチームの性能を高めています。Foot Lockerのような顧客は、すべての従業員がデータで意思決定できる世界へと、自社のビジネスをどう変革するかを考えられるようになっています。私たちは本当に、一人ひとりのユーザーがデータを活用して仕事をできるようにしたい。だからこそGenieをあらゆる場所で使えるようにしようと努めています。今日からGenieがTeamsとSlackに統合されたことを発表でき、うれしく思います。さらに今日から、AndroidとiOSの両方の主要プラットフォームのモバイル端末でも使えるようになります。Aliが触れたとおり、これはすでにDatabricks社員がGenieを体験する最も人気のある方法になっていて、皆さんの従業員にとってもそうなると確信しています。
Ken： 既存のAIエージェントを使っていたり、自前で開発したものがあったりして、Genieの優れた精度とデータへの明るさの恩恵を受けたい方のために、Genie MCPアプリの提供も発表できてうれしく思います。これは、皆さんの既存のエージェントやツールに、Genieの正確に結果を計算する能力を取り込む力を与えるもので、これも今日から使えます。私たちは、Genie 1がオントロジーを備えた唯一無二のAIエージェントであり、組織の全員が既存ドキュメントの情報を要約するだけでなく、一貫して結果を出せるようにする唯一のものだと、本当に信じています。そして、それを文字どおり全員が使えるようにしたい。そこで、それを後押しするために、組織内の一人ひとりのユーザーに、毎月10ドル分のトークンを提供します。Genie 1を始めない理由はもうありません。Genie 1は今日、一般提供（GA）になります。ぜひGenie 1を組織内のあらゆるものに接続し、全員に渡してください。
10. PepsiCo事例
10.1 データ基盤の変革
続いて、PepsiCoのグローバル最高データ・AI責任者であるMagesh Bagavathiと、DatabricksのArsalanがステージに招かれました。
Arsalan： Magesh、外ではGenieについてのなかなかクールなデモを見ましたが、ここではPepsiが取り組んできた素晴らしいことについて話しましょう。皆さんもご存じのとおり、PepsiCoは非常に巨大で複雑なビジネスですが、AI変革においては最高峰の存在です。少しそのあたりを聞かせてください。
Magesh： ありがとうございます、Arsalan。ここに来られて素晴らしいです。とても才能あふれる聴衆ですね。私はチームPepsiCoを代表してここにいます。私たちの旅は6年ほど前、本格的なエンドツーエンドのデジタル変革とプロセス変革を始めたときに始まりました。焦点は常に、顧客と消費者にとってより速く（faster）、社員・製品・事業にとってより強く（stronger）、そして地球にとってより良く（better）あること。これがPepsiCoの中核的なミッションです。PepsiCoの規模とスケールは、自分自身でも驚かされることがあります。私たちは世界中で32万人の従業員を抱え、約200カ国で事業を展開していて、これは止まることのない継続的なオペレーションです。北米最大級の車両群（フリート）も持っています。これほどの複雑さがあると、何より重要なのは消費者にきちんとサービスを提供できることです。私たちはそれを「オケージョン（occasions）」という指標で測っていて、1日あたり約14億オケージョンに及びます。オケージョンとは、皆さんが私たちの素晴らしい製品を毎日どう消費するか、ということです。これを600万の小売店、そしてeB2BやD2Cのチャネルを通じて提供するのは、かなり複雑な取り組みです。だからこそ私たちは、AI変革とはデータ変革である、と心から信じていて、それに取り組んできました。
Magesh： チームがこの6年でやってきたのは、根本的に、60を超えるデータレイクを持っていたレガシーなアーキテクチャから、Databricks上で動くひとつのレイクハウスへと移行したことです。そしてモノリシックなアーキテクチャから、本当にプラガブルなLegoベースのアーキテクチャへと移行しました。この変革こそ、私たちがプラットフォームにあるデータの価値を解き放ち始める鍵です。なぜなら今、PepsiCoのデータの宇宙の90%がこのプラットフォーム上にあるからです。これを私たちはエンタープライズ・データ・ファウンデーションと呼んでいます。私たちにとってこれは、生きて呼吸するプラットフォームで、さらに注力を強めているものです。
10.2 Genie導入の成果と展望
Arsalan： 素晴らしい。そして、あなたは早い段階で私たちにGenieについて話しに来てくれた一人でしたね。社内でも取り組みがあって、Aliと私のところに来て「こういうものを作らなければならない」と言ってくれた。なぜGenieはこれほどゲームチェンジャーだったのですか。
Magesh： ええ、数年前にあなた方のところに来ました。それは、このプラットフォームにすべてのデータをオンボーディングし始めたときで、このプラットフォームがコア機能の面で私たちに途方もない豊かさを提供してくれると気づいた頃です。私たちはこれを「AI for BI」、そして「データと対話する能力」と呼んでいます。倉庫のオペレーターであれ、現場の従業員であれ、ナレッジワーカーであれ、Kenが見せてくれたように、まさにデータと対話できるようにしたいのです。私たちがこのAI for BIのコンソールに取り組んでいた頃は、ひとつ作るのに3カ月から6カ月かかっていました。ベクトル化したり、RAGのパターンを使ったり、データをオンボードして実行し始めたりすると、その過程で精度が私たちの望むレベルに達していないことが見えてきて、本番化に3カ月から6カ月もかかっていたのです。そこであなた方に声をかけました。今この時点では、エンタープライズ・データ・ファウンデーションに95%近く正確でカタログ化されたデータがあり、私たちにとってGenieはDatabricks環境から価値を解き放つことそのものです。
Arsalan： 素晴らしいストーリーですね。では、それを具体的なところに落とし込んでください。実際のユースケースをお持ちですよね。まだ始めたばかりとはいえ、どんな価値があって、どう使ってきたのか聞かせてください。
Magesh： ええ、本番化して初めて本物になりますからね。PepsiCoの野心は、「PepsiCoを特定する（identify）」ことです。その文脈で、私たちはサプライチェーンのAIブレインといった概念を考えています。そのひとつの構成要素が調達ブレイン（procurement brain）です。最高調達責任者からの非常に強力なスポンサーシップのもと、直接・間接の支出すべてについて、調達に関するあらゆるインサイトを見始めています。私たちは年商950億ドルの会社なので、直接・間接の支出はかなりの額に上ります。Spend Wiseと呼ぶプラットフォームの中で、調達リーダーや主要なシニアリーダーが間接支出の全体像を把握するために、これまでもダッシュボードや機能、レポートを持っていました。しかし、そこにGenieを解き放つと、本当に大きなゲームチェンジャーになりました。ローンチからわずか数週間で、ほぼ3万件のクエリ、行き来のやり取りがありました。そして突然、ユーザー層がレポートやダッシュボードから、Genie型のエンゲージメントへとシフトしていくのが見えてきたのです。Genieについて私が気に入っていることのひとつは、Kenが少し見せたような、エージェントモードに入って深い調査（deep research）を始められる能力です。プラットフォームの中に途方もない柔軟性があり、それこそ私と多くのPepsiCoのリーダーが本当に気に入っている点です。今私たちが目指しているのは、このユースケースをPepsiCoのあらゆる部門へ――ヨーロッパの商業レポーティングやラテンアメリカも含めて――拡大することです。
Arsalan： なるほど。遅れていると怒られそうですが、聞かずにはいられません。次は何ですか。
Magesh： 私たちにとっては、どうやってエージェンティックなPepsiCoにたどり着くか、です。大きな野心を持っています。インサイトからアクションへ、そしてエンドユーザーと私たちの人々にとっての成果（outcomes）へと進むことが本質です。私たちのゴールは今、この3万件超のレポートを、50を超えるAI for BI、つまりGenieのコンソールへと集約することです。それが私たちにとって大きな成果になります。それが、これからのビジネスを推し進めるやり方です。これが本当にPepsiCoをエージェント化し、32万人の従業員をエージェント化する助けになります。
Arsalan： 素晴らしい。本当に見事な旅でしたし、次に何が来るのか楽しみです。ありがとうございました。
Magesh： パートナーシップに感謝します。
11. Bilal AslamによるLakehouseとデータエンジニアリングの簡素化
11.1 データエンジニアリングの課題
続いて、DatabricksのプロダクトマネジメントシニアディレクターであるBilal Aslamが登壇しました。
Bilal： おはようございます。Lakehouseについてお話しします。その前に、ちょっとした一言を。この紫のジャケットは、2年前にLakehouseの話をしたときに着ていたものです。去年は着なかったのですが、いちばん多かったフィードバックが「あれを戻してくれ」でした。というわけで、戻ってきました。さて、Magesh、Arsalan、Ali、Ken、そしてAIとエージェントについて話してくれた皆さんに感謝します。本当にわくわくする未来ですが、もし皆さんが私のようなデータエンジニアなら、こう思っているでしょう。「素晴らしい、けれどこれ全部にはデータが要る。アプリも、エージェントも、AIも、何もかもデータを必要とする。自分の仕事は少し大変になったぞ」と。
Bilal： というのも、データエンジニアリングでは、目的地はシンプルだからです。目的地は右側、つまり私たちが望むビジネス成果――エージェント、アプリケーション、リアルタイムのオペレーション――にたどり着くことです。でも私たちは実際には左側から始めます。生のデータソースからです。データはKafka、Salesforce、NetSuiteにあり、OracleやSQL Serverといったオンプレミスのデータベースにもある。そしてその「メッシーな中間（messy middle）」、それがデータエンジニアリングであり、生データを取り込んでインサイトに変えるのが私たちの仕事です。長年にわたって、私たちはこういうアーキテクチャを築いてきました。これを掲げたのは、それが典型例だからです。一つひとつの箱を見る必要はありません。ロゴだらけ、箱だらけ、箱と箱をつなぐ線だらけです。しかもこれは、データをある場所から別の場所へ動かすだけのものです。私たちは複雑さと折り合いをつけてきました。「ツールはたくさんあるけれど、少なくとも動いてはいる」と。
Bilal： けれども、この複雑で統一されていないアーキテクチャには、いくつもの重要なものが欠けていると、皆さんも本能的にわかっているはずです。データエンジニアとして、私たちはすべてをバージョン管理したい。でもこのスタックでは、一部はバージョン管理できても、他はできません。Sparkのコードはバージョン管理できても、Kafkaのインフラはできない。あらゆる場所でガバナンスを効かせたいのに、あまりに多くの場所に読み書きしているため、ほぼ不可能です。そして後で見るように、スタックには丸ごとロックされてしまっている部分もあります。最後に、すべてをスケールさせ、コストを節約して、ビジネスのためにもっと多くのアプリと成果を築きたい。でもスタックのすべての部分が等しくうまくスケールするわけではありません。私は今日、データエンジニアである私の仕事も、皆さんの仕事も、これからかなり大変になる、とお伝えするためにここにいます。
Bilal： ここに映っているのはGenie Codeです。データサイエンス、機械学習、データエンジニアリングのために専用に作られたコーディングエージェントです。使っているなら素晴らしいことで、というのも、なんとLakeFlowのパイプラインの60%が、リリースからわずか3カ月で、すでにGenie Codeによって書かれているからです。とんでもない統計です。リリースしたばかりなのに、本当にすごい。一方で、この統計はデータエンジニアとして少し私を怖がらせます。私はエージェントに首ったけなのですが、すべてのエージェントは新しいデータ、新しいパイプラインを意味し、あの脆いインフラの上で、構築するもの、管理するものが増えることを意味します。私たちは押し流されてしまいます。ではどうするか。動く部品を取り除くことから始めます。ここが超重要なのですが、私たちは複雑さを、さらなる複雑さで取り除きたいわけではありません。オープンなフォーマット、オープンなフレームワーク、オープンなツールで置き換えたいのです。最終的にデータスタックを簡素化する必要があります。そして大胆な主張をします。LakeFlowこそが、その統一されたスタックである、と。AIとエージェントのためのオープンな基盤を与え、皆さんの会社にふさわしい未来を築けるようにするものです。私たちは何百ものパートナー、たくさんのツールと協働していて、それらはすべてLakeFlowとLakehouseと相互運用可能です。
11.2 LakeFlowによる簡素化
Bilal： では始めましょう。少し駆け足でいきます。まず、データ変換、つまりETLをどう簡素化するか。ここに皆さんは最も多くの時間とお金を費やしています。Sparkがあり、たくさんのレガシーなSparkジョブがあり、EMRや他のベンダー上のSparkディストリビューションがあるかもしれません。それを、Apache Sparkの宣言的パイプライン（declarative pipelines）に置き換えます。まだ使っていなければ、ぜひLakeFlow上で試してください。これらはオープンで、ノートPCを含めどこででも動かせて、宣言的なので、やるべき作業そのものに集中できます。そしてオープンだからこそ、エージェントがこれらのパイプラインを書くのが本当に得意です。バッチとストリーミングを統合します。かつてSQLでのETLといえばDBT一択でしたが、Sparkの宣言的パイプラインはそれも統一していて、SQLとPythonの両方があり、選ぶ必要がありません。さらに、リアルタイムストリーミングにFlinkを使っているなら、それはおそらく低レイテンシのストリーミングがDatabricksやSparkでは本当に難しかったからでしょう。でも昨年オープンソース化したReal-Time Mode――低レイテンシストリーミングのための新しいエンジン――が、いまSparkの宣言的パイプラインの中で使えるようになりました。どこでも動くオープンなフレームワークで、ミリ秒のストリーミングが得られます。
Bilal： さて、起きているシャドーITはどうでしょう。データエンジニアが20人いても、ドラッグ&ドロップのツールでパイプラインを作っているアナリストが何百人もいるかもしれません。これらはノートPC上で、プロプライエタリなフォーマットとツールで作られていて、誰かがチームを去れば、もうお手上げです。Genieを搭載したノーコードのデータ準備ツール、LakeFlow Designerが一般提供（GA）になったことを、ぜひお伝えしたいです。今すぐ試せます。そして超クールなことに、LakeFlow Designerはプロプライエタリなパイプラインを一切作りません。裏側でSparkの宣言的パイプラインを作るだけなので、やはりどこでも動かせます。パターンが見えてきましたね。
Bilal： もう少し速くいきます。次はデータ取り込みの簡素化です。何百ものコネクターを持つSaaSを使っているなら結構ですが、それはおそらくプロプライエタリなフォーマットにデータを落としています。エージェントはそのSaaSの扱い方を知らず、自動化もできず、監視もガバナンスもほとんどできません。Aliが触れたとおり、LakeFlow Connectが100を超えるコネクターを持つようになったことをお伝えできてうれしいです。思いつくコネクターがあれば、もう作ったか、作っているか、これから作ります。そしてオープンソースのコネクターを作る新しいコミュニティもあり、自分で作ることもできます。お察しのとおり、これも特別な種類のパイプラインやETLではなく、裏側はSparkの宣言的パイプラインです。
Bilal： Kafkaの話をしましょう。データエンジニアとして、私たちは大量のテレメトリのためにKafkaを日々使っています。Kafkaはバッファですが、管理が本当に大変だということも知っています。Zero Bus Ingestが、Kafkaと100%ワイヤー互換のフルマネージドサービスになったことをお伝えできて、とてもうれしいです。Kafkaにデータを送るコードをそのままZero Bus Ingestに向ければ、AIに使える状態のオープンフォーマットで、毎秒12GBのスピードで、何百万もの小さなファイルを作ることなく、Lakehouseにデータを落とせます。スタックからKafkaを取り除けるのです。
Bilal： さて、ほぼ到達しました。まだすべてをオープンで宣言的なETLフレームワークの上に築いています。でも、そこにAirflowのアイコンがぶら下がっているのが見えますね。皆さんのオーケストレーターです。物事をトリガーしたりスケジュールしたりするのにそれを使わなければなりません。これも簡素化しましょう。Airflowを使っているのは、おそらくPythonでワークフローを書くのが好きだからでしょう。LakeFlow Jobsは今やPythonでのワークフロー記述に対応していて、純粋なPythonです。ポイント&クリックのDAGも作れます。完全にサーバーレスなので、インフラを一切管理する必要がありません。そして顧客調査で興味深い事実がわかりました。顧客の80%が古いAirflowのディストリビューションを使っているのです。つまり、それを管理・維持し、セキュリティ脆弱性を抱え、新機能も得られていない。最後に、私が本当にわくわくしていることを。長らくJobsはDatabricksのオーケストレーションは得意でも、他のシステムのオーケストレーションはあまり得意ではありませんでした。そこで、50を超える統合をリリースして、Snowflakeを含むすべてをオーケストレーションできるようにします。Airflowのオペレーターのようなものと考えてください。オープンソースで、すべてをオーケストレーションできます。
Bilal： これがどこに私たちを連れて行くかというと、オープンなスタックです。ほぼすべてがオープンソースの宣言的パイプラインを築いています。これは真新しい製品ではなく、私たちはしばらく前からこれに取り組んでいて、世界で最も過酷なデータワークロードに対応できる状態にあります。いくつか統計を共有させてください。Sparkの宣言的パイプラインは今や毎日200兆行のデータを処理しています。LakeFlow Jobsは世界最大級のデータワークロードを動かしていて、月あたり約17億回のジョブ実行です。そしてサーバーレスコンピュートが本当に人気です。クラスタを管理したくないし、VPCをセットアップしたくない。今や顧客の50%がサーバーレスコンピュートの利用をオプトインしています。素晴らしいことです。
12. データオペレーションとGenie Zero Ops
12.1 運用の難しさと核心的気づき
Bilal： さて、私は皆さんに、構築が以前より簡単になったと、ある程度は納得していただけたと思います。すると皆さんはこう考えるでしょう。「よし、オープンなスタックができた。構築を始められる。コードも書けるし、Genieを試せば何かを作ってくれるかもしれない。でもオペレーションはどうなんだ。それはまだ解決してくれていないじゃないか」と。実のところ、私はむしろ問題を悪化させてしまったとも言えます。「素晴らしい、これでもっと多くの人がもっと多くのパイプラインを作れる、つまりもっと多くの障害、もっと多くの問題が起きる」というわけです。現実はこうです。パイプラインの作成を簡素化するのは、実は簡単な部類なのです――それでもかなり大変でしたが。本当に、本当に難しいのはデータオペレーションです。あるパートナーが行った調査によると、データエンジニアリングのチームは時間の50%以上をメンテナンスに費やしています。皆さんの時間はそこに消えているのです。これは悪化する一方で、これだけメンテナンスに時間を費やしても、なお月あたり最大60時間のダウンタイムが発生しています。これは最悪です。
Bilal： ここで皆さんはこう思うでしょう。「でもBilal、さっき統一されたスタックだと言ったじゃないか。APIもエンドポイントもテーブルもあるんだろう。コーディングエージェントが直してくれるんじゃないか」と。残念ながら、そう簡単ではありません。なぜか、手短に説明します。大きな考え方はこうです。データエンジニアリングはソフトウェアエンジニアリングではない、もう少し別のものなのです。ソフトウェアエンジニアリングでは、コードは自己記述的で、文字どおりそれ自身を説明します。データエンジニアリングでは、データとコードの両方があります。ソフトウェアエンジニアリングでは、テストは通るか通らないかで、完全に決定論的です。データエンジニアリングでは、コードとデータがあり、データを単純にテストすることはできません。統計的なものだからです。そして最後に、これが大きいのですが、ソフトウェアエンジニアリングでは失敗が許されます。何かがおかしくなれば、トレースが見え、例外が見え、デプロイをロールバックできます。データエンジニアリングでは、失敗はサイレントで、しかも永続的です。おそらく1週間後に、CEOやステークホルダーから「なぜこのデータはおかしいんだ」という怒りの電話がかかってくるのです。
Bilal： では、なぜコーディングエージェントはここでつまずくのか。検知（detection）の段階では、データが、テレメトリが欠けているからです。たとえばSparkのログを渡すこともできますが、これは数メガバイトにもなるトレースで、コンテキストウィンドウの管理に細心の注意が要ります。同じように、根本原因の評価（assess）の段階では、リネージが欠けています。リネージをシステムの外にエクスポートしなければならず、ある程度はできますし、コーディングエージェントもコンテキストウィンドウも良くなってきています。次に、修復（remediate）――コードの修正を書かなければなりません。でも、本当の難所は最後のステップで、少し細かいことを言いますが、これを検証（verify）と呼びます。データでは、ユニットテストをただ走らせるわけにはいきません。コードの修正を取って、それを本番データの上で実際に走らせなければならないのです。これでゾクッとしたなら、それが正しい反応です。
Bilal： つまり、皆さんのオペレーションのエージェントには何が必要か。コードとデータを組み合わせること、それがツールとスキルです。ある程度はできます。根本原因を突き止めるには、本番データへの読み取りアクセスが要ります。これに抵抗のない方は――自分が書いたわけでも信頼してもいないエージェントに――いますか。一人も手が挙がりませんね。しかも、皆さんのコーディングエージェントには本番データへの書き込みアクセスも要ります。それが修正を検証できる唯一の方法だからです。どこかのよくわからないエージェントに本番データへの書き込みアクセスを与えたい人は、いますか。一人くらいいてもいいのに、誰もいませんね。混乱を引き起こし、すべてを消し去ってしまいかねないからです。これが大きな気づきでした。私たちはこの問題をずっと見てきて、たどり着いた大きな実感は、皆さんのオペレーションのエージェントは、データプレーン（data plane）の中に住む必要がある、ということです。データプレーンの外には住めない。考えてみれば当然で、データプレーンこそがデータを持ち、リネージを持ち、しかも正しいガバナンスの境界でもあるからです。
12.2 Genie Zero Opsの仕組みとデモ
Bilal： そこで、Genie Zero Opsを発表できることに、本当に、本当にわくわくしています。皆さんのデータとAIのオペレーションを自動操縦（autopilot）にする、新しいバックグラウンドのGenieです。デモをお見せしますが、まず仕組みを手短に。検知については、Genie Zero Opsはテーブルごとに機械学習モデルを自律的に構築し、継続的に微調整します。メトリクス、イベント、ログにネイティブにアクセスできるので、この配管を自分で作る必要がありません。すでにGenie Zero Opsで何万ものこうした機械学習モデルが本番で動いています。評価については、Unity Catalog内のデータリネージに対してグラフランキングを行います。根本原因の特定――皆さんが多くの時間を費やすところですが――については、スーパーバイザーエージェントと、リサーチを行うサブエージェントの一群がいて、最も可能性の高い原因について合意（コンセンサス）に達します。修復については、Genie Zero OpsはGenie Codeと協働します。Genie Codeが皆さんのコード、チケットシステム、バージョン管理にアクセスできれば、それらをすべて使い、ライフサイクルの過程でチケットを更新することもできます。そして検証――最も難しいステップ――については、これは10年かけてオープンなレイクハウスを築いてきた成果ですが、皆さんの本番データの浅いクローン（shallow clones）を作ります。Lake Baseでやっているのと同じような、超安価で超高速なブランチです。そしてDatabricksのネイティブなネットワークとコードの分離を活用します。
Bilal： では、Genie Zero Opsが実際に何をするか、手短なデモをお見せします。いくつか気づくことがあるでしょう。まず、これはダッシュボードには全然見えません。メトリクスやイベント、アラート、赤いランプであふれさせたりはしません。皆さんが目にするのは、メールの受信箱（inbox）のように見えて、そう感じられるものです。実際、優先順位づけされたメール受信箱を手本にしています。たとえば、ここで重大度（severity）が見えるのがクールな点で、すべてのインシデントが重大度でランクづけされているので、本当に重要なものだけに集中できます。また、これは単なるジョブやパイプライン、障害の羅列でもありません。ここにアラートがあって、Genie Zero Opsは「16のジョブが失敗しているが、これらは実は同じインシデントだ」と突き止めています。この自然なグルーピングが時間を節約してくれます。
Bilal： では、実際のインシデントを見てみましょう。ここで起きているのは、top fan votersという上流のテーブルに何か問題が起きている、ということです。10分ほど前に、行数がかなり落ち込みました。Genie Zero Opsがやってくれるのは、皆さんがログインする頃には、バックグラウンドのエージェントがすでにすべての思考を、すべての調査を済ませてくれている、ということです。データエンジニアとして、私はまず影響(impact)のようなものを見られます。すべてのテーブルやパイプラインが重要なわけではないので、リネージを前方にたどります。この場合、top fan votersはかなり重要なテーブルだと判明します。下流のテーブルがそれに依存し、このファンエンゲージメントのダッシュボードも依存しているので、クリティカルとマークされます。次に、根本原因のエージェントを展開して何が起きているかを突き止めます。これらのエージェントは、このテーブルから出発し、リネージを使って後ろへ扇状に広がり、上流の潜在的な原因を調査していきます。これは比較的単純なDAGで、どのテーブルでもありえたのですが、最終的にこのfan interactionsという一枚のテーブルが問題だと突き止めます。
Bilal： そして、自律的に修正を書いてくれました。ただし、この修正は本番にはデプロイされていません。主導権は皆さんにあります。Genieが何をしたかというと――これが超クールなのですが――浅いクローンを作りました。本番データの、Lake Baseのブランチのようなものです。ちなみに、これには許可を与える必要があります。自動では行いません。「このパイプラインでやっていい」と伝える必要があるのです。これはテラバイト級のデータかもしれませんが、浅いクローンです。そこに修正をデプロイし、正しい行数が返ってくることを実際に検証しました。これは何時間、いや何日分もの作業です。この時点で、私はプルリクエストを作り、自分のソフトウェア開発ライフサイクルに従って進められます。
Bilal： Genie Zero Opsができるもうひとつの超クールなことをお見せします。許可を与えれば、PIIのようなものがないか、テーブルを自律的にスキャンします。このケースでは、私たちのアプリケーションが、知らぬ間に約1,000人のユーザーのPIIを露出させてしまっています。かなりまずいですね。Genie Zero Opsは私のためにレポートを作り、そのPII――個人を特定できる情報――が何かを突き止め、テーブルごとの内訳を示し、リネージを見てこれが重要だと判断します。そしてこの場合、提案してくる修正はコードの修正ではなく、Unity Catalogのポリシーの修正で、私はそれをデプロイできます。これがGenie Zero Opsです。本当にわくわくしています。私のようなデータエンジニアにとって、そして願わくは皆さんにとっても、構築にかける時間がはるかに減り、メンテナンスにかける時間がはるかに減り、統一されてシンプルなデータスタックの上で構築する時間がずっと増える、ということを意味します。ありがとうございました。
13. 「Known Data Realm」とRaidenエンジン
13.1 データ世界の地図
Bilalのデモを受けて、Ali Ghodsiが再び登壇しました。
Ali： 本当にクールでした。Zero Opsには大いにわくわくしています。私たちの暮らしをずっと楽にしてくれるでしょう。さて、今日触れた数々の発表を実際に語っていく、ショーの本当にエキサイティングな部分に入っていきます。Reynoldが、この1年で私たちがイノベーションを起こしたものの多くを紹介してくれます。けれどもその前に、全体像の中に位置づけておきたいと思います。データの世界はとにかく混乱しがちで、技術がたくさんあり、動く部品がたくさんあるからです。
Ali： これを私たちは「known data realm（既知のデータの世界）」と呼んでいます。データインフラのゲーム・オブ・スローンズのようなものです。荒れた海です。説明しましょう。この惑星の西側には、OLTPデータベースの世界があります。このOLTPデータベースの領域は1980年代に発明されました。あらゆるソフトウェアの背後にデータベースが必要とされたのです。たとえばATMがあって、お金を引き出そうとすると、それはデータベースを叩く必要がある。しかも非常に速く、レイテンシはミリ秒であってほしい。決して止まってほしくないし、超信頼性が高くあってほしい。トランザクションを取り違えるようなことは絶対にあってはなりません。時とともに、key-valueストアや、いまではAIによるベクトル検索といった、ニッチなデータベースも現れました。これがOLTPの島です。
Ali： この地図の右側にあるのが、データウェアハウジングの世界です。これは1980年代の少し後に現れました。人々が「このATMをどれだけのデータ量が通ったのか」「すべてのATMで実際にいくら取引されたのか」と問いたくなったからです。そうした問いを左側のOLTPの面で尋ねるのは複雑すぎますし、それらのデータベースを落としてしまい、ATMに影響を与えかねません。それは絶対に避けたい。だからこそ、それを稼働させ続け、隔離しておきたい。そこで右側でデータウェアハウジングを始め、こうした分析的な問いを尋ねられるようになったわけです。
Ali： ところがすぐに、ここ15年で、人々はもっと高度な問いを尋ねたくなりました。ATMの総取引量はいくらか、というだけでなく、「Aliは今日いくら引き出すか」――未来を予測できるか、と。そこで私たちはデータサイエンスや、ますます高度な統計分析を始めました。そしてここ数年で、リアルタイム分析が現れました。エージェントやアプリケーション、ダッシュボードが、本当に低いレイテンシを求めるものです。これらは複雑な問いに答えたり、データの大きな結合をしたりはできませんが、いくつかの分析的なクエリを返すダッシュボードを与えてくれます。これらのそれぞれに異なるものが必要で、左側のOLTPデータベースから右側までデータを動かす必要がありました。そこで登場したのがデータエンジニアリングで、OLTPデータベースから右側のOLAPエンジンまで、データを動かしシャッフルするすべての複雑さがそこにありました。先ほどBilalが話していたのが、まさにこのデータエンジニアリングの世界です。彼はこの面を片付け、道路を敷いてくれました。
Ali： けれども今、私たちが目にしているのは、エージェントの猛襲です。これらの異なる島の間で、はるかに多くのデータを運ぶことを要求するエージェントが現れている。そして私たちは、襲ってくる嵐に押しつぶされ、船を失おうとしています。私たちのインフラは超脆弱です。この1年でも、私たちが依存している重要なインフラのサイトが、いくつも落ちるのを見てきました。これはあらゆる組織に起きることです。まるで全員が従業員の数を倍にしたようなものです。エージェントがクエリを投げ、もっとデータを欲しがり、もっと多くのデータ移動が起きているからです。だから、これを簡素化する必要があります。
Ali： どう簡素化するか。私たちはDatabricksを始めたときに、ある程度これをやりました。データサイエンスとデータエンジニアリングを融合させたのです。Sparkはすでに大きなデータ移動ができて、Spark MLのようなもので機械学習ができました。そして5年前、私たちはLakehouseを発表し、ひとつのエンジンでデータウェアハウジング、データエンジニアリング、データサイエンスを行えるようにしました。これはすでにある程度成し遂げています。けれども、まだリアルタイム分析の島が分離して残っていて、本当に低いレイテンシが欲しければ、データの別コピーを作る必要があります。今日のすべてのデータウェアハウスのような分析スタックは、1秒の何分の一かまで下げることはできません。何をしようと、ハードなトレードオフがあるのです。複雑なクエリと、リアルタイム分析が持つ何分の一秒のクエリの両方を、こなすことはできない。だからそのすべてに別々のエンジンが必要になります。これに対して、私たちの最新のイノベーションを発表できることにわくわくしています。それを共同創業者のReynold Xinに紹介してもらいましょう。
13.2 Raidenエンジン（Reynold Xin登壇）
Reynold： ありがとう、Ali。今日この新しい取り組みについて話せることに、とてもわくわくしています。正直なところ、これはおそらくLakehouseを導入して以来、私たちが行ってきた中で単独で最大のイノベーションです。Aliが言ったとおり、Lakehouseで私たちはデータサイエンス、データエンジニアリング、そしてデータウェアハウジングを統一できました。データウェアハウジングの事業は導入から5年で指数関数的に伸び、GartnerとForresterの両方からデータウェアハウジングのリーダーと認められました。Fortune 500の60%以上がLakehouseをウェアハウジングに使っていると思います。冗談で言うのですが、皆さんがいるタイムゾーン次第では、朝食を取る前に、私たちはエクサバイト規模のワークロードをスキャンしています。
Reynold： この数年、私たちは性能の改善にかなり力を入れてきました。Data and AI Summitのたびに、私か、Shawnか、誰かがステージに上がって、私たちが行った大規模な性能改善を紹介してきました。けれども現実には、ウェアハウス、つまりLakehouseは、約1秒のところで壁にぶつかっています。「壁にぶつかる」とはどういう意味か。Lakehouseやウェアハウスからクエリの応答を1秒未満で決して得られない、という意味ではありません。ただ、ミリ秒や数百ミリ秒の範囲で非常に厳格なSLAを求める、とりわけ厳しいワークロードがある場合、それを達成するのは非常に難しい、という意味です。レイテンシのスパイクが起きかねないからです。その結果、非常に厳格なSLAを要するワークロードを持つ多くの組織は、別のサービング用スタックを立てています。データウェアハウスやLakehouseの代わりにデータをコピーし、サービングに必要なその一部分を、別のスタックにコピーするわけです。
Reynold： これが多くの問題を引き起こしました。データセットごとに維持すべきデータパイプラインができてしまうのです。こうしたサービングスタックは非常に単純なクエリでは抜群の性能を出しますが、より一般的なワークロードではうまく機能しません。そしてガバナンスの悪夢でもあります。「この特定のプラットフォームでデータセットを保護し忘れていないか、基盤のウェアハウスではやったのに」と心配しなければならない。テーマが統一なのであれば、もしデータを一度も動かさなくてよかったら、コピーしなくてよかったら、どうでしょう。2年前、私たちは自分たちにその問いを投げかけました。
Reynold： それは実際、かなり根本的な問題だと判明しました。非常に解くのが難しいのです。Turing賞受賞者で、Postgresの本来の生みの親としてご存じの方もいるMichael Stonebrakerが、これについて「One Size Fits All（一つのサイズですべてに合う）、その時代は来て、そして去った」という学術論文を丸ごと書いています。その論文でStonebrakerは、幅広いワークロードを動かせる単一のデータベースエンジンを設計するのは非常に難しい、と論じました。複雑さが増すと、システムを設計するのが非常に難しくなるからです。その根本的な理由は、過去40年、いや50年のデータベース工学のやり方にあります。Databricksも含め、どのチームもおおむねこう進めてきました。「ここに研究したいかもしれない新しいワークロードがある」と狙いを定め、その特定の種類のワークロードについて最新でクールな学術論文をすべて研究する。論文の中には40年、50年前のものもあれば、ここ数年のものもある。それらを研究して理解し、「これは現実に適用できるか」と考え、実装に多くの時間を費やし、ある時点で実世界のワークロードでどれだけうまくいくかをテストしようとする。そして必ずこうなります。新しく実装した技術――新しいアルゴリズムやデータ構造――が、一部のクエリでは驚くほどうまく機能し、別の一部のクエリではひどい結果になる。データベースは「ここでは良くなったが、実はあそこでは退行した」となるのです。ミリ秒の応答時間を保証するような非常に低いレイテンシで本当にうまく機能するアルゴリズムやデータ構造の多くは、より大きなデータセットでは裏目に出る傾向があり、その逆もまた然りです。
Reynold： これが最大の問題のひとつでした。そこで2年前、私たちは決めました。「現状を打ち破れないか。それに挑み、できる限りのことをやろう」と。私たちは白紙に戻りました。素晴らしいエンジニアリングチームとともに、データベース工学のやり方そのものを反転させたのです。アイデアや技術から始めるのではなく、ワークロードから始めました。幸い、Databricksにはスキャンしてきたゼタバイト級のデータ、そのトレースが、クアドリリオン規模の自然なトレースとして集まっています――この単語の発音は覚えなければなりませんが。これらは何兆ものクエリが実行されたことから来ています。このトレースに基づいて、特定の新しい技術が与えられたときに実際に何が起きるかを、非常に高い忠実度で推定する機械学習モデルを構築できました。このモデルに基づいて2つのことができます。ひとつは、実行時に正しいアルゴリズムを素早く選んでディスパッチすること。LLMではありません、LLMはレイテンシが高すぎますから。実行時に正しいアルゴリズムを選べます。そしてさらに重要なのは、本番に至る前に、そもそもどのアルゴリズムを実装すべきかを判断・予測できることです。世の中には何百万ものアルゴリズムとデータ構造があり、全部を見つけるのは大変です。何を実装すべきかを知ることこそ、得られる最大の優位性のひとつなのです。
Reynold： その結果生まれたエンジンがRaidenで、ご存じのとおりMortal Kombat（モータルコンバット）への言及です。出来上がったエンジンは実に見事です。世に出ている他のサービングスタックを使ったことがあれば、私たちが話してきた多くの問題にぶつかったはずです。たとえば、5秒より長いクエリを実行できないものもあります。ほぼすべてが、データをエンジン固有の非常に特定のフォーマットにコピーする必要があり、複雑な結合を実行できません。けれどもRaidenはそのすべてをこなせます。Raidenは新しいSQLウェアハウスという形で現れます。少し抽象的なので、Raidenが実際に何をするか理解していただくために、手短なデモをお見せしましょう。ここに非常にシンプルなセットアップがあります。正直、ただのシンプルなクエリで、ニューヨークのタクシーのデータセットへのクエリです。何をするか理解する必要はありません。データセットを知っている方のために言えば、かなり小さいものです。まずこのクエリを今日のLakehouseで走らせました。約1秒で終わりました。悪くはありません。そして右側に、Raidenのセットアップ、私たちがLakehouse RTと呼ぶものがあります。これを走らせてみましょう。この数字、見えますか。もう一度走らせてみましょう。0.007秒です。ハードコードしたんじゃないかって。いえ、していません。
Reynold： でも、それはたった1クエリです。1クエリだけ走らせて何が面白いのか。実際にシステムを叩きまくったとき、現実に何が起きるかをお見せしたいと思います。私たちは実際のダッシュボードアプリケーションのワークロードを模したシミュレーターを作り、Raidenエンジンに当てています。まず1つのアクティブセッションから始めます。実際のダッシュボードが動いていると想像してください。このダッシュボードをロードします。かなり速くロードされますね、期待どおりです。では、10、100、いや、1,000までスケールアップしたらどうでしょう。1,000のアクティブなエージェントが同じエンジンに同時に当たるのをシミュレートします。ちなみに各エージェントは複数のクエリを生成していて、ダッシュボードはロードするのに約8つのクエリを要します。それらが全部、まったく同じ瞬間に当たります。何が起きるか見てみましょう。完了です。8,000のクエリを、毎秒6,000クエリで、テールレイテンシ37ミリ秒で実行しました。これは信じがたいことです。既存のシステムでこれができるものはありません。
Reynold： とても単純なデモでしたが、「既存のシステムにはこれができない」と言ったのを、既存システムとの対比で位置づけましょう。レイテンシ対スループット――スループットはここでは毎秒のクエリ数（queries per second）です――を測るベンチマークをお見せします。Y軸がP90、つまり90パーセンタイルのレイテンシ、X軸が実行中のクエリ数です。TPC-H Q6という、少量のデータをスキャンして集約を行う、データウェアハウジングの定番のクエリを走らせます。世の中の異なるシステムをテストするとどうなるか。ある競合ベンダーについては、彼らの最新のウェアハウスを使っています。押し上げていけますが、毎秒160クエリあたりまで来るとレイテンシが上昇し始め、壁にぶつかります。同じベンダーが昨年、Interactive Warehouseというかなり革新的な製品を発表しました。あまりに「インタラクティブ」なので、一般のウェアハウスと同じデータを読むことすらできず、機能させる唯一の方法はデータを別のウェアハウスにコピーすることです。このInteractive Warehouseは最新世代の一般ウェアハウスよりはるかに良くて、レイテンシがスパイクし始めるまで毎秒300クエリほど押し上げられます。
Reynold： さらに、非常に単純なクエリを非常に高速に実行できることで知られるオープンソースのクエリエンジンも黄色でテストしました。この特定のワークロードでは、Gen2やInteractive Warehouseよりずっと良く動き、毎秒約15,000クエリ近くまで押し上げられます。かなり良いですよね。でも、その直後にクラッシュし始めます。タイムアウトするのではなく、ただクラッシュするのです。ではRaidenはどうか。同じワークロードで、Raidenはテールレイテンシを1秒未満に保ちながら、毎秒12,000クエリまで走り切ります。もうひとつ見せたいベンチマークがあります。標準的なデータウェアハウジングのベンチマークであるTPC-Hを全部走らせたらどうなるか。画面のとおり、データセットが小さいときは、実はすべてのシステムがそれなりにうまく動きます。22のクエリを数秒で走らせる程度です。けれどもスケールアップして、たとえば100GBになると、黄色のシステムは実行時間がスパイクし始めます。これは私が先ほど話した、専用のサービングエンジンは、完全なTPC-Hのクエリに現れるような、より複雑な結合ではうまく機能しない、という点をまさに示しています。そしてもっと大きなデータ量にスケールアップすると、両方のシステムがクラッシュし始めました。Interactive Warehouseは5秒より長いクエリを実行できないので終えられず、黄色のシステムはメモリ不足で完了できませんでした。Raidenは、すべてのスケールファクターで、すべてのクエリを完了できました。
Reynold： ベンチマーク疲れしているかもしれませんね、合成ベンチマークなど誰が気にするんだ、と。Raidenを開発する過程で本当にわくわくしたのは、一緒に取り組んできた設計パートナーたちです。彼らのうち何社かのロゴを画面に出しています。設計パートナーから得られた2つの結果を共有させてください。1社目はAmverceです。エネルギーセクター向けの、世界をリードするデータ・AIプラットフォームで、彼らは最も代表的な11の本番クエリでRaidenをテストしました。既存のサービングスタックと比べてわかったのは、Raidenでは、もともと極端に低レイテンシのクエリは100ミリ秒未満のままで、一方で長く走るクエリは実行時間を劇的に縮められた、ということです。全体平均で16倍の高速化を得ています。AmverceのPaulは、数十ミリ秒でクエリを実行できるようになっただけでなく、最も長く走るクエリの実行時間を100倍近く縮められたことに、とても興奮していました。Metaも同様にRaidenをテストし、とてもよく似た結果を見出しました。典型的なクエリが数十ミリ秒で返ってくるようになり、何より重要なのは、サービングのためだけに脇に別のシステムを置く必要がない、ということです。
Reynold： Raidenが何をするかというと、極端に高い同時実行性のもとで可能な限り最良の低レイテンシを与え、実世界のワークロードを本当にうまく動かし、複雑なCDLやEDWのワークロードも見事にこなせます。そして今日、Raidenエンジンを搭載した最初の製品を発表できることに、とてもわくわくしています。Lakehouse RTと呼びます。Lakehouse RTは、読み取り専用のワークロードから始まる新しいウェアハウスで、ミリ秒の性能と大規模な同時実行性をサポートしますが、最も重要なのは、それがレイクの上で直接、Unity Catalogによってガバナンスされ、同じDeltaやIcebergのデータに対して行われる、という点です。RTはreal time（リアルタイム）の略です。Lakehouse RTで何が違ってくるか。これまでの常識に挑んでください。別のサービングスタックを持っているなら、これを試して、2つのプラットフォームをひとつに畳めるかもしれません。そうすれば、ミリ秒の性能、大規模な同時実行性が、皆さんのデータレイクの上で、オープンフォーマットに対して直接得られます。ベータが今日から始まります。早期アクセスを得るには、担当のアカウントチームに相談してください。
ここでNikitaが割って入り、Raidenの名前の由来を明かしました。
Nikita： いや、まだですよ。Reynoldは頑なにRaidenが何の略か言わないので、私が上がってきて、彼を少し恥ずかしがらせてあげましょう。Reynoldはデータプラットフォーム関連のすべてを率いています。皆さんが目にするこのイノベーションは、すべて彼のチームのものです。彼のチームはこのエンジンをRaidenと呼びました。なぜなら、Reynold's dream engine(レイノルドの夢のエンジン)の略だからです。本当ですよ。実話です。ひとつには彼を恥ずかしがらせたかったのでしょうが、もうひとつ、チームのメンバーの一人と話していたら、こう言うんです。「Databricksにはあまりに多くのプロジェクトがあって、皆さんはいつも、人を薄く広げたくないからとプロジェクトを潰してしまう。だから、共同創業者にちなんで名付けたらどうかと考えたんだ」と。それがRaidenエンジンです。
Ali： これが、私たちが持っていたデータ世界の地図で、リアルタイム分析が別の島にあるのを見ましたね。今、私たちはこの地殻プレートを動かして、それを融合できます。裏側のデータは同じフォーマットで、同じUnity Catalogのガバナンスを得られ、低レイテンシの処理も、ビッグデータの処理も、すべてこのひとつの島で、裏側は同じ技術スタックで行えます。それがLakehouse RTという形で出てきます。しかも、超競争力のある価格をつけていて、本質的に同じ価格です。とてもわくわくしています。
14. Nikita ShamgunovによるLake Base（OLTP）とMasterCard事例
14.1 Lake Baseのアーキテクチャと性能
Ali： さて、今度は左に目を向けて、このOLTPの島を見ていきます。ステージにNikita Shamgunovをお迎えできることに、とてもわくわくしています。彼はMemSQL、のちのSingleStore、そしてDatabricksが買収したNeonのCEOで、今はこれらすべてを率いています。本当に長い間OLTPをやってきた人物です。Postgresについて話してもらいましょう。
Nikita： AIのおかげで、私たちは今やソフトウェアを生成しています。手で書いてはいません。26年の最初の6カ月のトレンドを見ていますが、今や自信を持って言えます。来年1年で、人類の歴史全体よりも多くのソフトウェアが生成されるだろう、と。そしてすべてのアプリケーションは、いまだにデータベースを必要とします。では、次世代のアプリケーションとエージェントは、データベースに何を求めるのか。
Nikita： まず、馴染み深い（familiar）ものである必要があります。その理由は、エージェントがシステムについて多くを知っているほど――そしてエージェントはインターネットやStack Overflow、Redditのフォーラムをスキャンして知るわけですが――それを動かし運用するのが上手になるからです。だからオープンソースで、人気があり、拡張可能（extensible）である必要があります。そうすれば、主要なワークロードも、ニッチなワークロードも、単一のデータベースプラットフォームに集約できます。次に、俊敏（nimble）である必要があります。押し寄せてくるアプリケーションと、さまざまな開発・テスト・ステージングの環境を考えると、システムはサーバーレスで、ブランチ可能（branchable）である必要があります。そうすれば、エージェントが安全に動ける環境を簡単に作れます。そして、これらを規模と量で動かすにつれて、コスト効率が良い必要があります。最後に、基幹（mission critical）である必要があります。運用データベースは皆さんのビジネスを動かすので、無限にスケールでき、速く、極めて信頼性が高くなければなりません。つまり、馴染み深く、俊敏で、基幹である、ということです。
Nikita： そこで私たちは、世界で最も先進的なオープンソースデータベースであるPostgresから始めることにしました。世界最大のエコシステムと、たくさんの拡張機能を持っています。追加のワークロードを、主要な運用データベースシステムへ、プラットフォームへと集約できます。オープンソースで、地球上のすべてのエージェントに理解されています。けれどもPostgresはモノリス（一枚岩）で、その中でコンピュートとストレージが密に結合しています。俊敏にするには、何かをしなければならない。システムを再設計する必要があります。私たちが持っていた中心的なアイデアは、ストレージとコンピュートを分離し、ストレージをレイクに移すことです。けれども、これは思うよりずっと難しい。そのために、ストレージを一から再設計する必要がありました。レイクのストレージには非常に良い性質がたくさんあります。安価で、スケールがとても簡単です。けれども遅く、トランザクション的に一貫していません。Postgresをレイク上で動かすためにストレージを作り直すにあたって、読み取り用と書き込み用に、2つの追加サービスを導入する必要がありました。
Nikita： 書き込みとトランザクションの一貫性のために、私たちはsafe keepersを作りました。これらはPaxosと呼ばれる合意プロトコルを実装していて、低レイテンシの書き込みを提供します。そしてpage serversというもうひとつのサービスを導入し、Postgresのコンピュートにページを提供します。これらが低レイテンシの読み取りを担います。それらすべてをまとめてレイクと統合すると、Lake Baseが得られます。レイクの上で動く、フルマネージドのサーバーレスPostgresです。Lake Baseは何を与えてくれるか。まず、俊敏です。Postgresを500ミリ秒未満でプロビジョニングできます。GitHubにマージしたいPRごとに開発・ステージング環境がたくさん要るような状況で、ゼロまでスケールできます。たくさんの環境があり、それらがサーバーレスなので、TCOを実現する必要があり、使われていない環境を自動的にシャットダウンします。
Nikita： さらに、この新しいエージェント時代に非常に有用な2つのパターンを導入しました。ひとつ目はブランチングです。すべてのPostgresデータベースを簡単にブランチでき、これも約500ミリ秒でブランチできます。開発・テスト・ステージング用の追加環境を作れます。エージェント的な開発で現れたもうひとつのパターンが、スナップショット・リストアです。マウスを一回クリックするか、API呼び出しひとつで、データベースをスナップショットし、そのうえでエージェントを解き放って、ソフトウェアを作らせたり、スキーマを変えさせたり、データを変えさせたりできます。作業が気に入れば、そのまま進めればいいし、気に入らなければ、即座に以前のスナップショットにロールバックできます。
Nikita： さて、エージェント向けに作られているのはわかったが、基幹（mission critical）たりうるのか、皆さんのビジネスを支えられるのか、という話です。スケーラビリティから始めましょう。Lake Baseで設定する必要があるのは、コンピュートのエラーバー(誤差範囲)だけです。「コンピュートをこの最小値より下にも、その最大値より上にもスケールするな」と言える。これはコスト管理のためでもあります。けれどもその2つのエラーバーの内側では、ワークロードの変化に応じて自動的にスケールアップ・ダウンできます。ピーク時にはシステムをスケールアップし、週末や夜にはスケールダウンします。ストレージはもちろんレイクの上にあり、無限のスケーラビリティを与えてくれます。ストレージが枯渇することは決してなく、ディスクサイズに近づいたときのような管理オペレーションも一切要りません。
Nikita： 「Postgresのアーキテクチャをストレージレベルで変えたのなら、それは速いのか。Postgres as a serviceの業界の実装と比べてどうなのか」と思うでしょう。これはReynoldがRaidenで見せたのとよく似たグラフで、スループットをスケールさせながらレイテンシを測っています。もちろんこちらは運用システムなので、分析システムよりもずっと小さなクエリを、非常に高い同時実行性で走らせます。比較対象は、まず非常に人気のある1つ目のクラウドベンダーで、これは毎分約13万オペレーション(ママ)あたりで頭打ちになります。ちなみに私たちはTPROCという、かなり標準的な業界ベンチマークを走らせています。少し異なるアーキテクチャを持つもう1つのクラウドベンダーは、スループットを毎秒約35万オペレーションまで押し上げられましたが、その後はもちろんレイテンシもスパイクし始めました。そして、ぜひお見せしたい素晴らしい性能の成果ですが、Lake Baseは各トランザクション、各オペレーションについて10ミリ秒未満を保ちながら、毎秒60万オペレーションをはるかに超えるところまでスケールできます。Lake Baseはほぼあらゆるワークロードに対応できる状態です。
Nikita： 基幹であるということは、たくさんの機能も意味します。セキュリティ、コンプライアンス、暗号化、何でも、私たちは備えています。けれども、私たちが非常にユニークな立場で提供できるものをお見せしたい。クラウドの障害は毎日起きるわけではありませんが、起きると、皆さんのビジネスに壊滅的です。今や皆さんのビジネスの多くがますます自動化され、エージェント自身によって動かされているので、クラウドの障害はオペレーションに本当に大きな混乱をもたらしかねません。そこで、業界初のフルマネージドのクロスクラウド・ディザスタリカバリを導入できることに、ものすごくわくわくしています。これこそ、私たちが真に基幹と呼ぶものです。フルマネージドのクロスクラウド・ディザスタリカバリでは、システムをクラウドをまたいで動かすよう設定できます。たとえばLake Baseを、AWSのUS Westにプロビジョニングし、レプリカをAzureのUS Eastに置く。そしてAWSの障害が起きた場合、即座に一方のクラウドから別のクラウドへフェイルオーバーし、中断のないビジネスオペレーションを続けられます。これがLake Baseです。レイクの上で動くフルマネージドのサーバーレスPostgresで、基幹に耐えるものです。市場に出てまだ1年ですが、すでに3,500を超えるエンタープライズの顧客が、基幹のワークロードを私たちに託してくれています。そのうちの1社を、ここにお招きしたいと思います。
14.2 MasterCard事例
MasterCardのFederica Cohenがステージに招かれました。
Nikita： お元気ですか。お招きありがとうございます。MasterCardは、データとサービスで収益の半分以上を占めることを目指していますね。そこにたどり着くために、80もの異なるサービスをひとつのエージェンティックなプラットフォームに集約された。過去に何がうまくいかず、今は何がうまくいっているのですか。
Federica： いい質問ですね。まず私たちが事業を展開している規模感をお伝えすると、200を超える国々で事業を行い、数十億のカードホルダーを抱え、年間1,500億を超える取引を処理しています。これだけの規模で運用しなければならないので、サービスをひとつにまとめることは非常に重要でした。Lakehouseは、差別化されたインサイト、ガバナンス、そして必要なときの分離をもたらせる共有基盤を作ることで、それを加速してくれました。リアルタイムで推論でき、さらに重要なことに、その共有されたコンテキストとアーキテクチャのもとで協働できるエージェントを、ひとつにまとめられるのです。
Nikita： Unity CatalogとLake Baseを使って、再利用可能なアーキテクチャを築き、バーチャルC-suiteの創出を助けていますね。Lake Baseへの標準化はどう役立っていますか。
Federica： Lake Baseへの標準化はかなり重要でした。たとえば3月に、virtual C-suiteという新しいソリューションを発表しました。これは中小企業が経営層レベルの意思決定で運営できるよう設計されたものです。平均的な中小企業のオーナーを考えてみてください。非常に多忙で、キャッシュフローや予測について意思決定するのは難しい。そこで私たちは、それぞれがデジタルなエグゼクティブとして、さまざまなデジタル業務を助ける一連のエージェントを作りました。最初に着手したのがvirtual CFOで、キャッシュフローや支払い、運転資本の作り方といった、成否を分ける意思決定を助けます。私たちはLake Baseを使って、彼らのデータやパフォーマンスからインサイトを取り込み、すべてをまとめる基盤を作りました。Lake Baseを使っているからこそ、その共有された理解を持てる、という利点があります。一方のエージェントがアクションを取ったりインサイトを生成したりすると、それが次のエージェントに即座に利用可能になるのです。
Nikita： マルチテナンシーの話をしましょう。何千もの発行銀行が単一のプラットフォーム上にいるとき、マルチテナントの分離は非常に高いリスクを伴う課題です。銀行レベルの安全なデータ分離を実現しつつ、継続的に学習・改善できるAI駆動のインサイトを可能にするために、Lake Baseをどう使いましたか。
Federica： いい質問です。Performance Poolsという、近く登場するもうひとつのソリューションに取り組んでいます。こうしたソリューションのいくつかでは、何千もの発行銀行を、共有されたプラットフォーム上で支える必要があります。私たちにとってデータの分離は任意ではなく、クライアントが私たちに寄せる信頼にとって基礎的なもので、データレジデンシーなどの要件を管理する助けにもなります。常時オンのインサイトをアクションへ、そして測定へとつなぐ継続的なループをもたらすこの能力は、各クライアントを守るために発行データを分離・分離(ママ)し続けることを要求しますが、同時に、安全で透明性があり匿名化された形でインサイトを集約できる必要があります。Lake Baseは、何千もの発行体に一度に適用できる単一の基盤を確立することで、このソリューションを作れるようにしてくれました。私たちにとっては、一つのクライアントのために作ったものを、信頼と組み込まれた基盤を保ったまま、すべてのクライアントへ水平にスケールできるようにしてくれたのです。
Nikita： あなたのチームは、コンセプトからスケール対応のMVPデモまで7週間で到達しました。正直、度肝を抜かれました。こんなものは見たことがありません。MasterCardの規制水準を持つ会社では、なおさらです。エージェントメモリ、モデルサービング、ガバナンスを単一のプラットフォームの中に保つことが、信頼を犠牲にせず速く動くことをどう可能にしたのですか。
Federica： 達成できたスピードを非常に誇りに思っていますが、鍵となる部分は、AIとデータをどう管理しガバナンスするかについて、私たちが一切妥協しないことです。Lake Baseでできたのは、すべての基盤を最初から築くことでした。新しいMVPの開発を始めるとき、必要なガバナンスやガードレール、その他の分離や基盤を、最初から組み込めるのです。これをLake Baseのアーキテクチャに組み込むことで、いつもより格段に速く動けました。それらの信頼の構成要素が、交渉の余地のないものになるからです。つまり、コーナーを削って加速したのではなく、最初から基盤を築くことで加速したのです。しかも、それは今や、追加のエージェントを作るたびに再利用できるものになっています。
Nikita： 先を見据えて、エージェントがより自律的になるにつれて何が可能になり、Databricksのプラットフォーム上で何を築くのを楽しみにしていますか。
Federica： 冒頭であなたが言ったことに戻ります。私たちは、自分たちのサービスがMasterCardのますます多くを動かすことを目指しています。エージェンティックな世界でそれが意味するのは、時とともに、エコシステムのクライアントが使うエージェントの集合が増えていく、ということです。けれどもそれは、それらが信頼され、内に共有された基盤を持たなければならない、ということでもあります。インサイトや情報を提供するだけのエージェントから、アクションを取り、エコシステムを動かすのを助けるエージェントへと移っていくにつれて、その共有された基盤こそが、エージェントが互いから学び、その力をさらに高める助けになります。先ほど触れたvirtual C-suiteやperformance pulse、エージェンティックコマースで進めている能力を考えると、私たちにとってそのレベルの信頼をもたらすことは、イノベーションの通貨そのものです。それが、築き込める共有された構成要素のおかげで、私たちをずっと先までスケールさせてくれると信じています。
Nikita： 素晴らしい顧客でいてくれてありがとう、Federica。
Federica： お招きありがとうございました。皆さん、ありがとうございました。
15. Greg Brockman（OpenAI）とPatrick Wendellの対談
15.1 モデル開発とAGI観
DatabricksのエンジニアリングVP兼共同創業者であるPatrick Wendellが、OpenAIの社長兼共同創業者であるGreg Brockmanをステージに迎えました。
Patrick： 私のゲストに紹介は不要ですが、それでも紹介させてください。Greg BrockmanはOpenAIの共同創業者で、お迎えできて光栄です。Greg、まずあなたのOpenAIでの、ますます広がっている役割について話したいと思います。あなたはモデル生産プロセスの「ゴッドファーザー」として知られていて、そのコアエンジンを動かすのに必要なインフラ、人材、すべてを担ってきましたが、最近はもっと広い役割を、創業者として担い始めたと聞いています。その動機と、最近どこに焦点を当てているのかを聞かせてください。
Greg： まず、お招きありがとうございます。これほど多くの人が、Databricksに、そしてテクノロジーの向かう先に情熱を注いでいるのを一カ所で見られるのは素晴らしいことです。OpenAIでは、ごく初期から、自分が手伝えるあらゆる技術的側面に関わってきました。私のやり方は、その日その日で最も重要で差し迫った問題が何であれ、そこへ行って違いを生もうとする、というものです。GPT-4の頃には、毎晩午前2時まで起きてモデルを立ち上げ直し、どのノードが問題を起こしているのか、ノードを深く二分探索して突き止めようとしたりしていました。訓練のフレームワークも作りました。そして最近では、最も重要な問題のひとつが、私たちが非常に優れたモデル生産プロセスを持つようになったことです。この数年、あらゆる層でイノベーションできるよう多くの時間を費やしてきて、今やそれらのモデルを世界につなぐことこそが、最も重要で決定的な課題になっています。だから私は、この素晴らしい研究をすべて実りあるものにするために何をすべきか、チームが焦点を絞るのを手伝うことに多くの時間を使っています。プロダクトを作り、この会場の皆さんに価値を加えられるエージェントを作る、ひとつのやり方を持つことに、本当に集中した取り組みをしています。
Patrick： モデル自体についても手短に話したいです。この6カ月、いや本当にこの3カ月、あなた方はものすごい勢いです。私の理解が正しければ、5.3が2月、5.4が3月、5.5が4月に出ました。ほぼ月に1回です。私はそれらのモデルを主にCodexで使っていますが、どのモデルも前のものから巨大な飛躍でした。この急速なモデル品質の進化は何によるもので、今後どう動いていくと見ていますか。
Greg： これは「アヒルの比喩」そのものです。表面はとても滑らかでシームレスに見えて、6週間のサイクルでこうしてモデルが出てくる、という具合ですが、水面下では膨大な作業があります。多くのチームが協調しています。技術者として私が興味深いと思うのは、OpenAIの前にStripeで働いていたので、テクノロジー企業を築くのがどういうものか見てきたわけですが、これらのモデルを作るのはまったく別物だと思うかもしれません。けれども実際には、まったく同じなのです。ただ、非常に異なる領域で、この複雑な空間を多くの層に切り分けることを要求される、というだけです。事前学習(pre-training)があり、事後学習(post-training)があり、競合状態(レースコンディション)を見つけ出すような作業があり、推論を良い形にする方法を考え、安全性を考え、リリースの仕方、価格設定、パッケージング、その全体を考える。たくさんの技術的問題が積み重なっているのです。そして私たちは社内に、どんどん速く回っていくフライホイールを持っていて、すべてのチームが各リリースにどう貢献するか、という点で、技術レベルで大きく前進してきました。2年前は、大きなモデルを訓練することすら大変な苦痛でしたが、インフラ、研究、あらゆる層のチームが力を合わせて、そのプロセスをより滑らかに、より良くし、ひとつになってモデルを世に出せるようにしてきました。これは筋肉を鍛えるような、繰り返しのプロセスなのです。
Patrick： 私たちDatabricksも、開発プロセスで5.5を展開したとき、巨大な成果を目にしました。エンジニアたちも、こうしたワークロードに関しては絶対的にフロンティアにあると感じていました。
Greg： ええ。そして指数関数は続きます。この分野のすごいところは、モデルが出るたびに、試して「うわ、前はできなかったこの問題が、今は簡単だ」となることです。それをそのまま前へ投影すると、ソフトウェアエンジニアリングだけでなく、今や幅広い知識労働でも、コンピュータで行うあらゆる作業が、これらのモデルが加速できるものになり始めています。あらゆることで前へ進ませてくれるロケットのようなもので、その指数関数は止まりません。AI戦略を考えるとき、これを織り込んでおく価値があると思います。
Patrick： ということは、次のモデルについて、時期や能力について何か教えてもらえると聞いていいんでしょうか。ここだけの話で。
Greg： もちろん。私たちは次のレベルの能力を届けるために、超必死に取り組み続けています。今のこの瞬間をどう捉えるか、ですが、GPT-4のようなもの、と思っています。あれはチャットに優れたモデルでした。初めてこのインタラクティブ性が得られ、自分のために練り込まれた出力を読む価値があったからです。一方で今の瞬間は、本当に有用な仕事ができるモデルを手にしています。実際に物事を成し遂げ、ツールを使える。だからそれらをワークフローに取り込みたくなる。ソフトウェアエンジニアリングがそれを最初に感じた場所だと思います。これらのモデルを本当に活用すれば、いわゆる「雑務」の20%がモデルにこなされる状態から、80%へと変わる。すると突然、使うツールが変わります。今、あらゆる場所の働き手にとって、その瞬間が訪れているのだと思います。スライドやプレゼン、PowerPointのようなもの、あるいは異なるシステムの間でデータをつなぐようなこと、そのすべてがどんどん良くなっていきます。私たちは、皆さんがビジネスでやる必要のあるあらゆることで、より有用な、ステップ関数的に良くなるモデルを出し続けます。そして、これらのモデルを安全な形で広く世界にもたらすことが、私たちの使命の一部だと考えています。
Patrick： このカンファレンスはData + AIのカンファレンスで、データの実務家もいれば、AIに焦点を当てる人もいて、その両者の相乗効果や組み合わせを考えています。OpenAIの仕事であまり評価されていないことのひとつは、モデルやプロダクトの品質改善に情報を与えるために、あなた方がデータをどれだけ使っているか、という点だと思います。OpenAIの製品やモデルの開発において、データ自体がどんな役割を果たしているのか、そしてDatabricksや他のインフラがそこでどう重要なのかを聞かせてください。
15.2 データの役割とパートナーシップ
Greg： 根本的に、データは、私たちのモデルを――ケーキか何かにたとえるなら――その上に成り立つほとんど中核の材料、いわば小麦粉のようなものだと思います。たぶん一番下にあるものですね。これは、モデルをどう生産するかという点でも真実ですし、データをきれいにすること自体のリターンは、過小評価できないほど大きい。けれどももっと広く、人々が私たちの製品をどう使っているかを理解する、という点でも真実です。ChatGPTは最も広く展開されているAIチャットボットで、人々がそれでやることには途方もない多様性があります。私が本当に気にかけているのは、ユースケースが何かを考えることです。掘り下げていくと、人々が私たちのモデルを、予期もしなかった驚くべき素晴らしい使い方をしている例がたくさんあります。たとえばヘルスケアのような応用で、医療レポートをアップロードして、他の方法では得られなかったインサイトを得る。医者にかかれない人もいます。人々がこれらのモデルからどう価値を得ているか、その異なるやり方を見つけて理解することに、私たちは多くの時間を費やしています。
Greg： エージェント的な側面では、AIが実際にどう問題を解いているかを理解しようとするだけでも、トレースをただ読むのははるかに難しくなります。これらを分析的に見る、もっと良い方法が必要です。けれども今の私たちのすごいところは、人間だけでは到底及ばない規模と速度で情報を取り込める技術を持っている、ということです。だから時には、自分たち自身のモデルを使って、モデルがどう動き、振る舞っているかを理解できます。これはインサイトの側でも真実ですが、安全性の側でも真実です。たとえば、Codexを使ううえで常に最も苦痛な部分のひとつが承認(approvals)でしたが、今やその承認を代わりに行ってくれるAIの層があるのです。
Patrick： Databricksへの機能要望はありますか。実現できるよう、私が掛け合ってみますよ。
Greg： 私たちにとっては常にスケーラビリティです。もっと速く、もっと良いレイテンシが欲しい。一般論として、私たちが最も欲しい大きなものは、インフラの信頼性の基本です。私たちはこれほど大きなワークロードを抱えていて、すべてがスケールし、しょっちゅう倒れているので。
Patrick： より良く、より速く、より強く、ですね。さて、昨年DatabricksとOpenAIはパートナーシップを発表しました。当初は1億ドルのパートナーシップで、私たちの顧客がGPTファミリーのモデルにアクセスし、自社のエンタープライズデータと組み合わせられるようにすることに焦点を当てていました。そしてこの6カ月、あなた方がCodexの周りで革新を続ける中で、私たちはAIゲートウェイでそのサポートを加え、Genie――私たちのAI――をCodexの内側からネイティブに使えるようにも一緒に取り組みました。OpenAIはパートナーシップを一般的にどう考えているのか、聞かせてください。
Greg： まず第一に、私たちがやっていることは、私たち皆が共に築いているこのAI革命という経済の、エンジン全体の中の火花のようなものだと捉えています。パートナーは決定的に重要な要素です。社内でできることもあって、そこは注力を強めますが、そこに至る唯一の方法は、皆がやっていることのレバレッジを効かせ、Databricksのような企業と協働することだと思います。私たちのモデルを動力源とするGenieのようなシステムが、これほど多様な文脈で使われているのを見るのは本当に素晴らしいことです。さて、この会場で何人がCodexを試したことがありますか。この会場の全員が絶対に試すべきだと思います。私たちはCodexのあり方を非常に大きく進化させてきました。まずCodexのアプリは非常に差別化されていて、試す価値があります。今、あれに匹敵するものはありません。コンピュータのまったく新しい使い方のように感じられます。Patrick、あなた自身のCodexの使い方を話してもらえますか。
Patrick： ええ、私たちは展開しました。Databricksでは早期採用者だと思います。開発者の生産性に巨大な向上が見られるだけでなく、改善のペースが目を見張るほどです。新しいモデルのリリースか、デスクトップソフトのアップデートがあるたびに戻ってくると、すべてが非常に、非常に速く良くなっています。私たちは自分の顧客にもいつも勧めているように、複数のAIソリューション、AIベンダーを見て、エンジニアに見つけられる最高のモデルとツールを与えるよう促しています。Codexは私たちの開発スタックの非常に重要な一部になっています。
Greg： 競争のダイナミクスを見るのは興味深いですね。Codexのようなフォームファクターを作るうえで、私たちはある意味で出遅れた部分もありましたが、極めて懸命に注力してきて、改善の速度は非常に高い。あまり評価されていませんが、Codex自体はオープンソースなのです。それは私たちのDNAそのもので、人々が手を加え、望むあらゆる文脈で使えるものにする、ということです。
Patrick： つまりあなたのメッセージは「Codexを試せ」で、私のメッセージは「Databricksでそれができる」ですね。すでにOpenAIとDatabricksを一緒に使っているなら、超簡単です。最後の質問にします。今朝Aliが、AGIはすでにここにある、私たちのパートナーや顧客が気にかけるようなタスクは、すでにほぼ完璧にAIに実行されている、という意味でAGIは来ていると話していました。AGIは人によって違う意味を持ちますが、あなたの考えはどうですか。
Greg： AGIがこれほど個人的なものだというのは、ちょっとすごいことだと思います。AGIはほとんど、定義されたものというより「感覚（a feeling）」なのです。
Patrick： 「ずっと一緒にいた友だち」というやつですね。
Greg： まさに。でも、考える価値のある重要なことがあると思います。私が考えるカテゴリーエラーのひとつは、AGIはほとんど「瞬間」ではなく「スペクトラム」だ、という点です。AI の進歩には終着点があるわけではなく、続いていく。もし「AGIの瞬間」があるとすれば、私たちはまだそこに達していません。私の考え方では、それは、本当にどんなタスクでも自律的に取り組んでくれて、トップレベルの人間と同じ水準で皆さんを加速してくれるアシスタントを手にしたとき、です。私たちが手にしているのは「ギザギザの知性（jagged intelligence）」で、ある面では人を本当に加速させますが、別の面ではとても限定的で未発達です。これは大きな機会だと思います。OpenAIで私たちが本当に大切にしていることのひとつは、人間を中心に置き続けること(keeping humans at the center)だからです。人間が目標を設定し、コントロールを握り、これらのシステムが人類の利益になるようにしたい。だから、本当に望む場面でこれらのシステムを活用しつつ、人間がどこで根本的にとどまり、これから起きるすべての物事の駆動者であり続けるべきかを考える時間も、たっぷりある。私たちはこの指数関数の終わりには近くない。続いていきます。この会場の誰もが、その変化に貢献できる何かを持っていると思います。
Patrick： ある意味で、AGIかそうでないか、という枠組み自体が、今の時点ではあまり役に立たない、と言っていいですか。
Greg： 正しい枠組みではないと思います。正しい枠組みは、能力は何か、これらのAIに何をしてほしいのか、どう恩恵を受けられるか、どう助けてもらえるか、です。それを中心に置き、私たちが共に何を築いているかを考える――それが私にとって何より大事なことです。
Patrick： 素晴らしい。私たちの締めくくりの推奨は「Codexを試せ」です。Databricksの顧客なら、AIコーディングゲートウェイで極めて簡単に使えます。セットアップは1分ほどです。Greg、来てくれて本当にありがとう。皆さん、Gregに盛大な拍手を。
Greg： お招きありがとうございました。
Ali： 素晴らしい。OpenAIとのパートナーシップは大好きです。彼らは最高です。ぜひCodexをチェックしてください。彼らもDatabricksを使っていて、ほぼ10億人のユーザーがいて、そのデータをすべてDatabricksに入れて分析し、誰もジェイルブレイクしていないか、おかしなことが起きていないかを確かめています。
16. ELTaP / AltabとHollyによる統合デモ、クロージング
16.1 CDC・HTAPの課題とAltab
Ali： さあ、データの領域に話を戻しましょう。最もエキサイティングな発表がまだ残っています。見逃したくないはずです。データの領域はどう見えるか。右側についてはすでに話しました。皆さんが分析的な問いを尋ねる場所――データウェアハウジング、データサイエンス――で、Reynoldが、Raidenとそれを搭載したLakehouse RTで超低レイテンシ、世界最速のエンジンが得られることを見せてくれました。そして私たちはOLTPの側に渡り、OLTPデータベースの本当の専門家であるNikitaが、Postgresのすべてをレイクの上で、超高速・超低コストで、クラウドをまたぐディザスタリカバリ付きで動かせるよう、どう融合させるかに焦点を当ててくれました。では、AIと、押し寄せてくるこの猛攻と嵐に、私たちはどう立ち向かうのか。OLTPとOLAPの間でいまだに物事をシャトルさせる、この水域が残っています。RaidenでおなじみのReynoldに、もう一度ステージに戻ってもらいましょう。
Reynold： ありがとう。Bilalからデータエンジニアリングの簡素化を、私から分析の統一を、そしてNikitaからOLTPの近代化について聞いていただきました。けれども正直なところ、まだひとつ大きなものが残っています。OLTPデータベースという巨大な大陸があって、アプリケーションはまずそこにデータを入れます。そしてアプリケーションが十分に成功すると、そのデータについて推論し、分析したくなる。そこで私たちは結局、OLTPデータベースから分析の大陸へとデータを運ぶCDCパイプラインを作ることになります。CDCパイプラインを愛している方はどれくらいいますか、手を挙げてください。おや、何人かいますね。どうやって維持しているのか、ぜひ教えてほしいくらいです。CDCパイプライン、つまりchange data capture(変更データキャプチャ)パイプラインは、OLTPデータベースのbinログを読み、小さな差分（デルタ）の変更をすべて取得し、それを分析システムに送って、OLTPデータベースの状態をそこに再構築します。超脆弱で、維持するのが本当に煩わしい。多くのデータエンジニアが、データ破損を引き起こしたせいで午前3時に起こされてきました。実際、Databricksの一部の人間は、CDCはchange data captureではなくContinuous Data Corruption(継続的なデータ破損)の略だ、と冗談を言っています。
Reynold： この問題を解くために、業界はzero CDC、zero ETL、ミラーリングといったものを導入し始めました。けれどもこれらはすべて、パイプラインを隠して自動的に起きるようにする「マネージドCDC」の洒落た言い方にすぎません。実際には裏側にパイプラインがあって、CDCとまったく同じ問題に苦しみます。HTAP――hybrid transactional analytical processing(ハイブリッドなトランザクション・分析処理)――という言葉を聞いたことがある方もいるでしょう。HTAPはデータベース工学の聖杯のようなもので、OLTPのワークロードと分析のワークロードの両方を、ひとつのシステムで扱える単一のデータベースシステムを作る、という考えです。けれども、実際にHTAPシステムを使ったことのある方はおそらくほとんどいないでしょう。理由は、HTAPはほぼ失敗したカテゴリーだからです。採用はごくわずかで、世に出ているHTAPシステムはどれも非常にプロプライエタリで、大きなエコシステムを持たず、単一のシステムを作ろうとすることで、OLTPの性能でも分析の性能でも妥協し始めてしまったのです。
Reynold： では、どうすれば本当に2つを統一できるのか。HTAPがうまくいかず、CDCが非常に煩わしく、しょっちゅう破損を引き起こすなら、どうやるのか。この解決策は、実は行指向ストレージと列指向ストレージという、ごく根本的な問題、二分法にさかのぼります。AliもNikitaも先ほど触れたように、OLTPシステムは、干し草の山から針を探すようなルックアップが必要なので、行指向ストレージを必要とします。行に対する更新を非常に速く行う必要があるからです。一方で分析システムは、大量のデータのスキャンをたくさん行うので、列指向ストレージから本当に恩恵を受けます。Nikitaがすでに見せてくれたアーキテクチャ図――safe keeperとpage serverが実際の行指向フォーマットでデータをデータレイクに書き込む――を見ると、解決策はまさにそこにあるのです。safe keeperとpage serverのシステムを観察してプロファイルしてみると、これらはストレージサービスなので、CPUの観点では非常に低稼働で、しかし非常にIOバウンドだとわかりました。やっているのはローカルディスクの読み書きと、ネットワークの読み書きだけだからです。
Reynold： これは、それらのストレージサービス上の遊んでいるCPUを活用して、まさにその瞬間に、データを行指向フォーマットから列指向フォーマットへトランスコーディング(変換)する機会を与えてくれます。そしてデータを行指向から列指向に変換しても、CPU使用率はそれほど増えないどころか、実際にはデータ量を劇的に縮める、ということがわかりました。列指向フォーマットのほうが圧縮率が良いからで、しばしば10対1から100対1のどこかになります。すべてのサービスがIOバウンドなので、圧縮率が良くなることで、このトランスコーディングは性能を損なうどころか、むしろ恩恵をもたらせます。こうして、OLTPのデータを列指向フォーマットでデータレイクに書き込めます。列指向のDeltaやIcebergになれば、そのデータに対して直接、あらゆる分析コンピュートを当てられます。実際にどう機能するか。Lake Baseに新しい行を挿入すると想像してください。Lake Baseのコンピュートが、最終的にその行を下層のストレージシステムに送ります。ストレージシステムはそこでトランスコーディングを行い、その行をDeltaやIcebergの列フォーマットに直接書き込みます。そして、Lakehouseに対してクエリを起動すると、LakehouseはそのDeltaやIcebergのフォーマットを直接読み、最も新鮮なコピーのデータでクエリを返します。
Reynold： これは革命的だと思います。少なくとも、先ほど話したRaidenと同じくらい大きい。そしてLakehouseとLake Baseを合わせたこのコンセプト全体で、両方のための統一されたストレージを実際に持てます。私たちはこのストレージ技術にAltabという名前を与えました。Altabはlake transactional analytical processing(レイク・トランザクション・分析処理)の略です。Altabは「HTAPを正しく実現したもの」だと考えています。単一のクエリエンジンを持つことなく、HTAPの目標を達成しています。けれどもストレージは統一できていて――これがはるかに最も重要な部分です――今や、OLTPデータベースのためのデータの一コピーと、ガバナンスすべき一コピーを持てます。Altabは皆さんのデータインフラを真に統一できます。アプリケーションのためにOLTPデータベースから始めますが、データをコピーする必要はなく、維持すべきパイプラインもなく、何より、OLTPシステムにとっても分析システムにとっても、性能の妥協が一切ありません。そしてこれらすべてが、Postgres、Delta Lake、Icebergというオープンで相互運用可能なフォーマットの上に築かれています。Altabによって、OLTPと分析という別々の大陸を、ついにひとつの巨大な大陸に結合できます。
Reynold： けれども、私たちはこれを単独でやるわけではありません。Postgresのデータを直接parquetの列フォーマットに変換する、非常に基礎的なライブラリをオープンソース化します。ロゴはなかなかかわいくて、parquetの象が描かれていて、何をするものかを表しています。これは近く登場します。同じ問いですが、Altabを活用したいなら何を違うことをすればいいのか。実は何もありません。ただLakehouseを使い始めてください。Altabの機能を今後数週間で展開していきます。展開されれば、皆さんのLakehouseのすべてのテーブルが自動的にLakehouseに現れます。皆さんが何かする必要はありません。裏側に維持すべきパイプラインがないからこそ、そうできるのです。すべてのテーブルで利用可能になります。
16.2 統合デモとクロージング
最後のデモのため、Hollyがステージに招かれました。
Holly： LakehouseとAltabの両方を案内し、なぜ分析データと運用データを組み合わせる必要があるのかをお見せします。私はアメリカ大陸全域に銀行を持っていて、1日に数十億の取引を生み出しています。そして、VIPになりうる顧客を見つけ出し、その資格と地域の規制に基づいてアドバイザーにマッチングし、お客様がドアを出る前に窓口係がその情報を伝えられるよう間に合わせる、そんなエージェントが欲しい。以前なら、これは不可能だったでしょう。遅延が大きすぎて、介入が遅れすぎてしまう。でも、もうそうではありません。
Holly： Lake Baseから始めましょう。Lake BaseはオープンソースのPostgresで、Databricksによってフルマネージドされ、ストレージとコンピュートが分離されていて、始めるのがとても簡単です。新しいプロジェクトを作り、名前をつけ、デフォルトのままにすると、もうできました。コンピュートのサイズは固定ではないので、UI内でスケールアップ・ダウンでき、最小・最大サイズを設定できます。左側にはブランチがあり、新しいブランチを作れます。名前をつけ、自動削除させたり、本番からブランチを切ったり、過去のある時点からブランチを切ったり、さらにブランチからブランチを切ったりできます。データをコピーする必要がないので、ほぼ即座に作られます。過去の話で言えば、バックアップとリストアもあります。デフォルトで7日間の履歴を保持するよう設定されていますが、好みで増減でき、任意の時間枠にリストアできます。あるいは、定期的にスケジュールされるスナップショットからリストアすることもできます。
Holly： さて、私が事前にセットアップしておいた、すべてのデータを処理しているものがあります。テーブルに入ると、すべての取引データが見えます。誰が外れ値で、VIPになりうるかを計算するには、これらすべての過去の残高を横断してスキャンするクエリが必要です。そうしたクエリでは、いくつかの指標を気にします。ひとつ目はTPSで、右側の緑の折れ線です。この数字が下がればビジネスに影響し、止まれば支店のスタッフは障害に見舞われます。ふたつ目は分析クエリにかかる時間で、左上の青い数字です。最後に、データがどれだけ新鮮か、あるいは古いか――これは秒で測られ、右上の紫の数字です。リアルタイムでクエリするなら、リアルタイムの答えが返ってくるべきです。
Holly： 先ほどReynoldが、こうしたクエリを走らせるには3つの方法があると言いました。ひとつ目は、エージェントがデフォルトでやろうとするかもしれない方法で、複雑な分析クエリを既存のLake Baseのコンピュートに投げることです。DatabricksのSQLエディタから走らせていますが、なかなか返ってきません。一回限りの分析クエリとしてもよくないし、はるかに速い答えが要るエージェントにとっては最悪です。TPSにも影響し始めていて、緑の線が下がっていくのが見えます。これは心配なトレンドです。現実には一回の落ち込みではなく、何千回も起きるからです。こんなふうではVIPをリアルタイムで見つけ出すどころか、まともに分析すらできません。……まだ走っていますね。皆が自己紹介して回る時間がありそうです。あ、終わりました。やっと。青い数字を見ると、1分以上かかりました。鮮度もかなり悪く、本番を落としかねないリスクもありました。これは明らかにうまくいきませんでした。
Holly： では代わりに、CDCを使ってこのデータのコピーを取ったらどうでしょう。Lake Baseのchange data feed機能を使っていますが、これは本来、最新の分析ではなく監査ワークロード向けのものです。これだと、少なくとも15〜30秒の鮮度の遅れが出るとわかっています。でもこれはDatabricksのエコシステム内です。もし別のPostgresの提供や別のCDFを使っていたら、これは数分にもなりかねず、追加の請求や維持する追加のチームは言うまでもありません。走り終えると、TPSは平らなままで、実行に13秒かかりましたが、25秒分古くなっていました。
Holly： では最後に、ELTaPのやり方です。ELTaPでは、これらのテーブルがUnity Catalogで利用可能になっています。マネージドテーブルのように見えますが、アイコンから、これがLake Baseのテーブルでありながら、DeltaとIcebergの両方のリーダーからも利用可能だとわかります。これを実現するのに、追加のパイプラインを一切セットアップする必要はありませんでした。ただカタログを指定したら、現れたのです。UIに少し違いがあって、S3のパスがあります。そこへ行けばすべてのテーブルが見え、開放性の点でも素晴らしく、望めばオープンソースのSparkでクエリすることもできます。ELTaPに戻りましょう。同じクエリを、新しいタイプのウェアハウス、real-time warehouse(リアルタイムウェアハウス)でクエリします。実行をクリックすると……できました。ミリ秒で走りました。鮮度の遅れも一切なく、非常にリアルタイムなデータで、TPSへの影響もありませんでした。
Holly： ですから、エージェントを好きなだけ投げかけられます。そしてほぼ瞬時に走ったので、コンピュートのコストの面でも大幅に安く、中間のツールを管理する必要がなかったので維持コストも安い。私たち全員にとって、これは巨大なことです。運用システムと分析システムの両方に、性能を妥協することなく使える、単一の記録システム（system of record）を持てるのです。これらすべてが自動的に起きました。私はバックグラウンドで何のステップもセットアップしていません。そして、ついに私たちは、運用と分析という分断された世界の見方を持たずに済みます。もう選ばなくていいのです。
Ali： というわけです。私たちはこれらの異なる島をすべて統一し、すべてのデータ移動を取り除いて、このひとつの大きなパンゲアにしました。ELTaP、つまりlake tapで、レイクのデータを取り出せます。下層のデータはただIcebergに、オープンソースのIcebergやDeltaに保存されているだけです。そこでトランザクション処理ができ、分析ができ、リアルタイムができ、データサイエンスができる。これはゲームチェンジャーです。振り返ると、私たちはまずSparkでデータエンジニアリングとデータサイエンスを統一し、次にLakehouseでデータウェアハウジングを統一し、そしてRaidenエンジン、つまりLakehouse RTでそれらをひとつに統一し、さらにOLTPデータベースを取り込んでELTaPに至りました。
Ali： 今日を手短に振り返り、ズームアウトしましょう。私たちにはエージェントがいますが、コンテキストが欠けています。プラットフォームの上で、そのコンテキストをすべて与えたい。だから今日、たくさんの発表をしました。エージェンティックなデータの基盤を導入し、超高速なLakehouse RTがあり、クラウドをまたぐディザスタリカバリを備えたLake BaseとELTaP、そしてすべてのコネクターを持つLakeFlowがありました。次にコンテキストの層へ進み、極めて重要なGenie Ontology――皆さんのコンテキストグラフ――があり、すべてのモデルとエージェントのコントロールとコストガバナンスのためのUnity AI Gateway、Open Sharing、そして明日もっと詳しく聞けるOmnigentがありました。そして最後にエージェンティックなデベロッパーの仕事として、Genieのエージェント群――Genie 1、Genie Code、Genie Agentsという3つの主要なもの――があり、私たちが本当にわくわくしているアプリ、SIEMのためのLake Watchと、CDPのためのCustomer Lakeについても話しました。
Ali： これで今日のキーノートセッションは締めくくりです。11時30分にセッションがあります。そして明日の朝は、MateiによるOmnigentのキーノートをお見逃しなく。素晴らしいショーになります。来てくださってありがとうございました。