Current 2024 Keynote Day 1 - Data Streaming in the Age of AIを翻訳する
AI時代におけるデータストリーミングの未来：レポート
このブログでは、Confluentの共同創設者兼CEOであるJay Kreps氏が2024年9月のCurrentイベントで行った基調講演の内容を紹介します。Mercedes-Benz、Accenture、Viacom 18のリーダーたちも参加し、データストリーミングがどのようにして業界を変革し、AIを活用したリアルタイムのアプリケーションを実現しているかについて語られました。本記事では、重要なハイライトや技術のトレンド、データストリーミングの未来について掘り下げていきます。
1. AI時代におけるデータストリーミングの役割
1.1 ソフトウェア化するビジネス
企業は単にソフトウェアを使うだけでなく、ソフトウェア自体が企業の主要な基盤となりつつあります。
Jay Krepsは「企業がソフトウェア化している」という仮説に戻り、ビジネスがいかにエンドツーエンドでソフトウェアによって運営されるようになっているかを語りました。ソフトウェアをより多く使用するということではなく、企業の大部分がソフトウェアシステムで実装されるようになっている、という意味です。つまり、少しのアプリが存在しているわけではなく、企業の多くの部分がソフトウェアでエンド・ツー・エンドに実装されているのです。例えば、KafkaやKubernetes、オブザーバビリティの分野で起きていることなど、この10年で生まれた多くのインフラストラクチャーレイヤーに反映されています。企業の全体像をどう捉え、どうやって全てのパーツを繋ぎ合わせるか、という問いがますます重要になっているのです。ソフトウェアの普及は急速に進みましたが、その結果として、かなりの混乱が生じました。もし、ホワイトボードに戻って、企業のソフトウェアの基盤を設計し直すことができるとしたら、現在の状況は選ばなかったでしょう。現在の企業内のソフトウェアは、断片的で、異なるアプリケーション同士が繋がり合っただけのものです。このような状態に至ったのは、一度に少しずつ進めてきたからです。つまり、少しずつカエルを茹でるような形で、結果として遅く、エラーが発生しやすいシステムが出来上がってしまったのです。この問題を解決しようと生まれたのが、データストリーミングです。それは、データを単に保存するのではなく、企業内の全ての部門でリアルタイムに流れ、連携することを目的としています。この技術は非常に成功しました。今日ここに集まっている多くの方にとって、これは既に大規模に展開され、企業の重要な部分を支えている技術です。
1.2 AIが加速するソフトウェア化のトレンド
AIの時代に突入するにあたって、ソフトウェア化の傾向はさらに加速していくと考えています。なぜそうなるのか？それは、経済学の基本原則に戻ると、価値のあるものが安価になると、その需要が高まるからです。企業をソフトウェアでモデリングすることは、実際に非常にコストがかかります。クラウドによって、ソフトウェアシステムの運用が非常に容易になりましたが、ソフトウェアを開発するプロセス自体が容易になったわけではありません。しかし、AIはこのプロセスを大きく変える可能性があります。AIは単に大量のコードを生成するだけでなく、ビジネスをソフトウェアでモデリングする作業そのものを簡単にするのです。これまでは、ハードコードされたルールに落とし込むことが非常に困難だった問題が数多く存在しました。たとえば、新しいインターンに『こうやってやってみて』と教えるのは簡単ですが、コンピュータにそれを指示するのは難しいことが多かったのです。しかし今や、Pythonに「頭を使って考える」という関数が存在するようなものです。これはもちろん比喩的な表現ですが、現実的に、AIによってそのような問題に取り組むことが可能になってきています。
2. AIとデータ：主要な障壁を克服する
2.1 従来のAIトレーニングモデルの課題
私たちのデータストリーミング基盤は、AIアプリケーションを構築するための最適な基盤なのでしょうか？今、すぐに利用できる状態でしょうか？一言で言えば、答えは「いいえ」です。
現状は、データの「大混乱」がまだ続いています。AIを成功させるために何が必要なのでしょうか？最も重要なのは、ChatGPTやClaudeのようなシステムがインターネット上の静的なデータをトレーニングしているという事実です。これらのシステムは、たくさんのWikipediaを読む博識な友人のようなもので、非常に有用ではありますが、会社の重要な業務に直ちに投入して実行させることはできません。なぜなら、それらのシステムはビジネスに関するデータやプロセスを何も知らないからです。
2.2 エンタープライズにおけるAIの課題
エンタープライズの用途においては、会社に関するデータ、顧客、売上、業務手順に関するデータをそのまま活用できることが必要です。しかも、そのデータは正確で、今現在のデータでなければなりません。つまり、私たちがAIに求めているのは、「正しいデータ」を「正しいタイミングで」アプリケーションに届けることです。
例えば、消費者向けの銀行チャットボットを設計するとしましょう。顧客は、自分の支出パターン、手数料、利子、取引履歴などに関する質問をします。この場合、知的なモデルをデータの大混乱とどう結びつけるかが課題になります。顧客が尋ねる質問の中には、よくある質問（FAQ）のように、毎回ほぼ同じ答えになるものもあります。例えば、銀行の営業時間などです。しかし、多くの質問は顧客固有のものであり、その取引や直近のアクティビティに関するものです。これらに正確な回答を提供するためには、リアルタイムでデータにアクセスできる仕組みが必要です。多くの人は、このようなシステムを構築する際に、企業の全てのデータをトレーニングしてモデルに組み込むべきだと考えます。しかし、実際にはこれは正しくありません。その理由は三つあります。まず第一に、インターネット上の膨大なデータと企業の比較的小規模なデータを同じモデルで処理すると、結果が不正確になりやすいです。次に、トレーニングプロセスはバッチ処理であり、数週間や数ヶ月かかることが一般的です。しかし、私たちが必要としているのはリアルタイムのデータです。例えば、口座残高を確認するときに、1ヶ月前の情報ではなく、今現在の正確なデータが必要です。そして三つ目の問題は、これらのAIモデルにはアクセスコントロールがないことです。つまり、あなたのデータと私のデータを区別する仕組みがないのです。全てが一つの巨大なデータセットの中に含まれ、誰が何を閲覧できるのかが管理されていません。もしも私が自分の口座の取引を尋ねたときに、あなたの取引が表示されてしまったら、それは非常に大きな問題になります。これが大問題である理由は明白で、責任者が議会に呼び出され、何が起こったのか説明する羽目になるでしょう。つまり、これらの理由から、企業のデータをすべてAIモデルにトレーニングさせることは、解決策にはならないのです。もちろん、トレーニングは重要ですが、それが主な課題ではありません。課題は、保存されたデータとAIモデルをランタイムでどう組み合わせて活用するかにあります。
3. AIアーキテクチャの進化とリアルタイム処理
3.1 RAG（Retrieval-Augmented Generation）アーキテクチャの導入
銀行の窓口係が全ての取引を記憶することはないように、AIにも全てを覚えさせる必要はありません。人間の窓口係は、基本的な手順を学び、顧客に関する情報を適宜調べて対応します。それと同じように、AIもリアルタイムのデータにアクセスし、その場で必要な情報を取得して処理することが求められます。
このようなアーキテクチャには名前があります。これを『RAG（Retrieval-Augmented Generation）』と呼びます。アイデアとしては、必要なデータを各システムから集め、それを適切な形式で表現し、例えばデータベースやベクターデータベースなどに保存するというものです。これにより、必要なときにすぐに情報を参照できるようにします。
3.2 リアルタイムAIアプリケーション構築のためのデータストリーミングの重要性
では、どうやってこのようなシステムを構築するのでしょうか？AIシステムをデモから本格的な生産レベルに引き上げ、信頼性の高い実用的なシステムにするためには、データストリーミングが非常に重要です。さまざまなシステムからリアルタイムでデータを取得し、それを正確な形でベクターデータベースに保存するプロセスが必要です。
3.3 Flinkによるストリーミングデータの処理
これは、Apache Flinkのようなツールを使用する理想的なケースです。私たちは、データストリーム内でこれらのモデルを直接適用できるように、FlinkをConfluentプラットフォームに統合してきました。
3.4 AIがデータストリーミングに必要なもの
先ほどはチャットボットの簡単な例を示しましたが、ここで私たちがAIに必要なものについての答えを考えてみます。必要なのはデータです。正確には、AIには『正しいデータ』が『リアルタイム』で『今』必要なのです。そして、私たちが思うに、AIに必要なのはデータストリーミングプラットフォームです。これは、リアルタイムのデータをスケールに応じて取り扱い、すべての部門が最新のデータにアクセスできるようにするための基盤です。
3.5 エージェントの登場
先ほどのRAGの例はシンプルなチャットボットでしたが、私たちは今、エージェントと呼ばれるものに移行しています。エージェントとは、何かバックグラウンドで作業を自動的に行うソフトウェアシステムです。エージェントを使うことで、チャットボットのように質問に答えるだけでなく、特定のタスクを実行させることが可能になります。たとえば、私には2人の10代の娘がいるので、エージェントに『娘たちの口座を監視し、親として注意すべき支出があれば知らせてください』と頼むことができます。これが、エージェントのようにバックグラウンドで継続的に動作し、注意すべき状況をチェックして通知してくれるシステムです。では、このようなエージェントを動作させるために何が必要でしょうか。まず、モデルの精度が向上する必要があります。ある程度の信頼性がなければ、自動的にタスクを実行させるのは難しいでしょう。モデルの精度は徐々に向上しており、今後さらに進化していくことが予想されます。そしてもう一つ重要なのは、信頼できるデータです。どれだけ優れた判断力を持ったAIでも、間違ったデータを与えれば間違った結論に至ります。ですから、データの信頼性を確保することが非常に重要です。
3.6 エージェントのアーキテクチャ
エージェントのアーキテクチャは、先ほど説明したチャットボットの例とあまり変わりません。依然として、必要な入力データを集めてコンテキストを維持し、トリガーとしてのデータストリームを処理します。ただし、エージェントは、通知や取引処理の一時停止といったアクションを実行する点で異なります。これにより、AIが単なるチャットボットから、自動化されたエージェントとしての役割を果たすことができます。Apache Flinkはこのような非同期エージェントの構築に最適なプラットフォームです。Flinkの埋め込み計算機能は、エージェントのリアルタイム処理に直接活用できます。
3.7 ストレージからストリーム処理へ
これまではデータストレージが中心でしたが、これからはデータストリーミングとストリーム処理が中心になっていくと考えています。これにより、企業全体でのソフトウェアの利用範囲が拡大し、データストリーミングが企業内で重要な役割を果たすようになるでしょう。
3.8 現状のAIアプリケーションアーキテクチャの課題
現在、多くの企業がAIアプリケーションの構築においてデータレイクやデータウェアハウスを利用しています。
レイクハウスに関連するセットアップを考えると、それがAIアプリケーションにとって最適とは限りません。理由の一つは、レイクハウスのパラダイムが主にバッチ処理を中心にしていることです。データが異なる部分から抽出され、後でクリーンアップされ、分析用に利用されるといったプロセスです。
これがAIアプリケーションで問題になる理由の一つは、上流で何かが変更されたときに、ダウンストリームのプロセスがそれを知らない可能性があることです。そのため、壊れたデータや誤った結果が生じる可能性があります。これは非常に大きな問題です。
次にバッチ処理の速度の問題です。AIアプリケーションがビジネスと同期する必要がある場合、バッチ処理の遅延は致命的です。数時間や数日の遅延では、ビジネスのリアルタイムな進行に対応できません。したがって、ビジネスと同期するためにはリアルタイム処理が必要です。
さらに、データの流れが一方向ではなく、複数のシステム間でのデータの交換が頻繁に行われているという現実もあります。エージェントを用いると、アクションがフィードバックとして戻されるため、運用システムと分析システムの間に大きなループが生じます。この複雑さを解消するためには、全てのシステムにデータを提供できることが重要です。
3.9 データプロダクトへの移行
現状の課題を解決するためには、データのガバナンスとクリーンアッププロセスをデータを生成するチームに移管し、リアルタイムのデータストリームとして提供する必要があります。これはデータプロダクトの概念で、各チームが自分たちのデータをリアルタイムで公開し、それを他のチームが利用できるようにするというものです。これにより、全社的にデータを活用でき、さまざまなアプリケーションに対応できるようになります。
データストリーミングの未来は非常に明るいと考えています。AIの台頭により、データストリーミングの採用が加速しています。そして、この変化は企業がソフトウェアとAIを統合し、すべてのビジネスプロセスをリアルタイムに実行できるようにすることを推進しています。
4. 顧客事例
4.1 メルセデス・ベンツ：個別化されたドライビング体験のユースケース
私たちのような高級ブランドでは、顧客は非常に個別化された体験を求めます。たとえば、暑い日に車に乗り込むと、車が自動的にあなたの好みの温度に設定され、照明や音楽もあなたの好みに合わせて調整されるといった体験です。また、渋滞や道路封鎖に応じて、車が最適なルートを提案することもできます。
このような個別化された体験を実現するために、私たちはバックエンドで非常に多くの作業を行っています。車は、さまざまなECU（電子制御ユニット）やデータチャネルを持つ複雑なIoTデバイスと考えることができます。
そのため、データ管理は非常に複雑です。私たちは多くのデータソースからデータを収集し、クリーンアップし、データプロダクトを作成します。これにより、私たちのAIとMLチームがリアルタイムに推論を行い、顧客に対して個別化された推奨を提供できるようにしています。
以前の私たちのアーキテクチャは、複数のデータプラットフォームを使っていました。車両のECUやフリートからデータを取得し、オープンソースのKafkaやKinesis、Event Hubsに送信していました。しかし、これは非常に複雑で、各チームがデータエンジニアを持つ余裕がなく、再利用性も低かったのです。
現在、私たちはデータストリーミングプラットフォームを構築し、Confluent Cloudを活用しています。特にFlinkを使用してストリーム処理を行っています。これにより、データの管理とガバナンスを早期に行うことができ、最小限のアクセス権でデータを安全に保つことができます。
私たちは現在、非常に整理されたデータプロダクトを作成しており、それを使用してリアルタイムで推論を行い、天気データなどの外部データと統合することで、非常に個別化された顧客体験を提供しています。また、データの可視化と監視ツールを活用して、フリートの状態や顧客の好みについてリアルタイムのインサイトを得ることができます。
開発者にとっての最大のメリットは、再利用性です。このデータプラットフォームは月に800テラバイトのデータを処理し、1日あたり1800億のイベントを処理しています。再利用可能なパイプラインのおかげで、開発者の時間の80%が節約され、複雑なエコシステムを管理する必要がなくなりました。
ビジネスにとっても大きなメリットがあります。フリートや顧客の状況をリアルタイムで把握できるため、意思決定のスピードが劇的に向上しました。また、個別のチームがパイプラインをゼロから構築する必要がなくなったため、市場投入までの時間も4〜6週間に短縮されました。
4.2 アクセンチュア:グローバルIT部門での活用
Cloud移行の過程で、多くのバッチジョブがあり、それらが互いに密接に結びついていることがわかりました。それは非常に複雑で時間がかかりました。そこで、私たちはデータの流れをシンプルにするために、クラウドのパワーとスケール、Kafkaのオープンプラットフォームを活用しました。
データをリアルタイムで利用できるようになり、新しい機会が開かれました。それにより、プロジェクトのスタートがより迅速になり、以前なら数週間から数ヶ月かかったデータ統合が大幅に短縮されました。
開発者にとっても非常に大きなメリットがあります。データ統合が非常に簡単になり、標準化された方法でデータを消費できるようになりました。私たちは、データの供給チェーンをシフトレフトすることで、データをより迅速に利用できるようにしました。
私たちの次のステップは、すべてのバッチジョブを完全に排除することです。また、AIの進化とともに、データ製品がさらに発展し、新技術を試す能力がより高まり、ビジネスの日常業務に影響を与えることなく、実験が可能になります。
4.3 Viacom 18とIPL：スケールに対応したリアルタイムストリーミング
IPL(インドのプロクリケットリーグ)中、Viacom 18は何億もの視聴者をリアルタイムで処理する必要があり、データストリーミングが大きな役割を果たしました。視聴者数の急増にも耐えるスケーラブルなインフラが構築されました。
最初、Kafkaを使ってアナリティクスとインサイトのシステムを構築しましたが、その後、イベント駆動型のアプリケーションやマイクロサービスアーキテクチャを構築するためにKafkaを拡張しました。私たちのデータストリーミングプラットフォームは、これを可能にする鍵となっています。
Confluent Cloudを使用することで、Kafkaの管理やスケーリングにかかる時間とコストを大幅に削減できました。これにより、私たちの開発者はインフラ管理に煩わされることなく、新しい機能や顧客向けのプロダクトに集中できるようになりました。
開発者がインフラ管理ではなく、新しい顧客向けの機能を構築する時間を持てることが、私たちにとって大きな成功です。これが、Geo Cinemaの成長を支えるデータストリーミングプラットフォームの力です。
5. Warpstream
BYOC（Bring Your Own Cloud）の基本的なアイデアはシンプルです。通常、インフラストラクチャはベンダーのクラウドアカウントで管理されますが、BYOCでは、インフラストラクチャを顧客のアカウントにデプロイし、ベンダーがリモートで管理します。これにより、データ主権を確保し、すべてのデータが顧客の環境内に留まるという利点があります。
従来のBYOCモデルでは、複雑な技術の管理が伴い、セキュリティにリスクが生じます。ベンダーが顧客のクラウドアカウントにアクセスするため、多くの権限を与えなければならず、ベンダーがサポートスタッフを介して、最悪の場合にはSSHでシステムに直接アクセスすることが必要になることもあります。これにより、セキュリティと責任の面でリスクが高まります。
Warpstreamを構築したとき、これらのセキュリティ問題を解決する方法を見つけるために、システムのアーキテクチャを再設計しました。重要なのは、ベンダーが顧客の環境にアクセスすることなく、データ主権を維持することでした。そこで、私たちはシンプルでステートレスなソリューションを作り上げました。
Warpstreamのアーキテクチャには、2つの主要なコンポーネントがあります。1つは顧客のクラウドアカウント内で実行されるステートレスなエージェント、もう1つは私たちのクラウドアカウント内で実行されるコントロールプレーンです。エージェントは、オブジェクトストレージの前に配置され、データ処理を行います。
このアプローチにより、ベンダーが顧客の環境にアクセスする必要がなくなり、システムのセキュリティが大幅に向上します。さらに、Warpstreamは、オートスケーリング機能により、必要なリソースに応じて簡単にスケールアップおよびスケールダウンできます。
6. クロージングコメント
私たちはお客様のさまざまなユースケースに対応できる、フルスペクトラムのオファリングを提供できるようになりました。データストリーミングをより簡単で強力にするという私たちの目標を実現するために、これからもこのプラットフォームを発展させていきます。
データストリーミングが企業の中枢神経系となり、リアルタイムでデータを活用できる未来を想像してください。私たちは、データストリーミングをあらゆる企業にとってデフォルトの選択肢にするために、努力を続けていきます。
Discussion