Real-Time Context Engineのご紹介: AI 向けリアルタイム処理データによって簡素化されるコンテキストエンジニアリング

Real-Time Context Engineがアーリーアクセス（EA）版として利用可能になったことをお知らせいたします。これは、Apache Kafka®とApache Flink®の力を利用してリアルタイムデータを本番環境のAIシステムに直接取り込むという私たちのビジョンであるConfluent Intelligenceの重要な要素です。

Kafka と Flink は既に AI 向けストリーミングパイプラインの基盤として機能し、イベントを収集、リアルタイムで処理、クリーンでエンリッチされたストリームに変換しています。しかし、同じデータを AI システムが使用できる形式で提供するとなると、また別の課題が生じます。データチームは依然として、ストリームと AI アプリ間で不一致なデータモデルのマッピングや、異なるソース間でのデータガバナンスやアクセスの適用、スキーマや上流システムの変更のたびにパイプラインの再構築することに何時間も費やしています。欠けているのは、データの一貫性、セキュリティ、そしてリアルタイムにクエリを実行できるようにするサービスレイヤーです。

Real-Time Context Engine は、ストリーミングデータの提供レイヤーを単一のマネージドサービスに統合することで、ラストワンマイルの問題を解決します。 エンリッチされたエンタープライズデータセットを高速なインメモリキャッシュに継続的にマテリアライズし、Model Context Protocol（MCP）を介して AI システムに提供されます。これらはすべてConfluent Cloud内のフルマネージドサービスです。Kafka や Flink の複雑さは、開発者には意識させません。開発者は必要なデータを要求するだけで、すぐにライブで提供され、本番環境の AI をすぐに活用できます。

現在のAI向けエンタープライズデータ提供のアプローチが不十分である理由

基本的なタスクを高速化するために、ChatGPTやClaudeに生データを接続しようとした経験は数多くあるでしょう。しかし、本番環境で人間とのインタラクションを許容できるレベルで行い、適応性と信頼性を備えたインテリジェントシステムを構築するのは容易ではありません。実際の機能を自動化する信頼性の高い本番環境に向けたAIシステムには、ビジネスに関する豊富なコンテキストデータが必要です。例えば、注文処理を自動化するエージェントには、製品、出荷、在庫に関する常に最新の情報が必要です。つまり、複数のソースから継続的に結合・強化されたデータが必要です。

業務システムや分析システムからそのコンテキストを構築しようとする際、いくつかのよく知られた手法がありますが、結局それらは不十分であることが判明しています。

アプローチ1：すべてのソースシステムを直接公開し、すべてを「MCP化」する

MCPなどの新しいAIプロトコルにより、AIシステムをライブデータに簡単に接続できます。これらのプロトコルは、エージェントが自然言語を使って情報を要求したり、アクションを実行したりできるエンドポイントを公開します。多くの場合、チームはここから着手し、MCPを介してソースシステムに直接接続し、モデルを指示して、リアルタイムに応答を確認します。

デモの結果は好印象に見えますが、本番環境での使用には適していません。それには、以下のようないくつかの理由があります。

• 生データ、使えないデータ: ソースシステムから得られる生データは、それを作成したアプリと密接に結びついています。アプリの内部構造を知らなければ、人間やAIでは解読できない難解なコードやIDが散りばめられています。生データは、活用できるようになる前に、意味のあるコンテキストへと変換・拡充する必要があります。

• カスタムセキュリティやアクセス制御: ライブクエリを可能にするために、チームは API またはデータベース全体を公開するか、各エンドポイントの周囲に複雑なアクセス制御とフィルターを構築することになります。

• 運用負荷: AIクエリが通常のワークロードに加えて積み重なり、同じ本番システムが繰り返しアクセスされる状況になり、本来AI向けに設計されていないデータベースやAPIに過負荷がかかります。さらに、ITチームはデータフローを維持するために、多数のMCPサーバー群を維持管理しなければなりません。

• トークンのコスト: モデルに送信される冗長フィールドやフィルター処理されていないフィールドごとにトークンの使用量が増加し、各クエリのコストが高くなり、応答が遅くなります。

このアプローチがなぜスケールしないのかは明らかです。結局、セキュリティに欠け、運用負荷の高い方法で数十ものソースシステムにクエリを実行し、エンリッチされるまで使用できない生データを取得するためだけに、システムに過負荷をかけることになります。

本当に必要なのものは、生データへのアクセスの増加ではなく、実際のビジネス上の意味を持つ、整理されたクリーンな派生データセットです。

アプローチ2: Lakeでバッチ処理し、オペレーショナルデータベースを通じて提供する

バッチシステムは、こうしたクリーンで派生的なデータセットを構築するのに最も適しているように思えます。結局のところ、私たちのデータのほとんどはデータレイクハウスまたはデータウェアハウスに保存されています。開発においては、これが真価を発揮します。モデルが実際のエンタープライズデータで機能することをテスト、反復、そして実証できるからです。

その後、セマンティック検索用のベクターデータベースやルックアップ用のオペレーショナルデータベースなどのサービスレイヤーに、処理済みの大量のデータをロードできます。しかし、本番環境では問題が発生します。データはロードされた時点で既に古くなっており、すべての更新は次にスケジュールされたバッチジョブに依存することになります。

航空会社の運航を例に考えてみましょう。フライトスケジュールとゲート割り当てを管理するAIアシスタントは、予約と乗務員のデータを1時間ごと、あるいは毎晩更新する必要があるかもしれません。しかし、そのバッチジョブが実行される頃には、数十便のフライトのステータスが変更され、乗務員の交代やゲートの変更が行われています。その結果、現実世界がリアルタイムで動いているにもかかわらず、モデルは過去の状況について推論することになるのです。

こういったアプローチでは、各システムはリアルタイムアクセスまたはコンテキストの豊かさという単一の側面に最適化されており、両方を同時に最適化しているわけではないのです。ストリーミングは根本的に異なる基盤を提供します。

AIの基盤としてのストリーミング

Apache Kafka によるストリーミングは、基本的にコミットログを基盤としています。コミットログは、あらゆるイベントを継続的に記録するものであり、これにより発生時にデータを処理できるだけでなく、過去のデータを発生時のまま再生することも可能です。理論上は、1 つのシステムで履歴を評価し、現在を処理し、結果をリアルタイムで提供できることになります。しかし、実際には実現が困難だったため、ほとんどの人はストリーミングをこの方法で利用しようとは考えていません。多くの Kafka デプロイメントでは数日分のデータしか保持されておらず、ストリーム上で過去のイベントを再処理したりクエリを実行したりするには、時間と手間がかかっていました。

ストリーミングを実際に使えるようにするには、バッチ処理の一般化が必要です。つまり、開発段階ではすべての履歴を迅速に処理できるスケールアップ機能を備えつつ、本番環境では新しいデータが到着するたびに同じコードを継続的に実行できるような仕組みです。ConfluentでTableflowやFlinkなどで行っていることは、このアイデアの拡張と言えます。

Tableflowは、KafkaのコミットログをApache Iceberg™やDelta Lakeなどのオープンテーブル形式の耐久性の高い構造化ストレージに拡張します。これらのオープンテーブルはオブジェクトストレージに保存されるためコスト削減が可能で、あらゆるデータレイクハウスや分析エンジンにリアルタイムデータを供給できます。データを必要な期間、コスト効率よく保存し、テーブルのようにクエリを実行し、リアルタイムストリームと分析システム間のギャップを埋めることができます。

Flink は、ストリームとバッチのセマンティクスを 1 つのフレームワークに統合します。

スナップショットクエリでは、同じSQL、Java、またはPythonを使用して、Tableflowに保存された過去データを、ストリームを再処理するよりも最大で50～100倍高速に処理できます。また、Kafkaストリームとして到着する新しいイベントに対応し、プログラムを切り替えることなくロジックを継続的に改良することも可能です。このストリームとバッチの二重性により、大規模なデータ処理や再処理をリアルタイムで実行できます。

これらのイノベーションを組み合わせることで、ストリーミングは、コンテキストをリアルタイムで継続的に評価、処理、提供できる世界の基盤となります。最終ステップは、そのコンテキストをAIシステムに提供することですが、これには依然として複雑な作業が伴います。多くの場合、チームはストリームをベクターデータベースにマテリアライズしたり、それぞれにカスタマイズされたセキュリティ、ガバナンス、モニタリングレイヤーを備えたカスタムMCPサーバーを接続したりする必要があります。それが本日から皆様にご提供する、私たちが特に楽しみにしている部分です。

Real-Time Context Engine のご紹介

Real-Time Context Engine は、本日からアーリーアクセス版として提供され、ストリーミングデータの提供レイヤーが単一のマネージドサービスに統合されます。継続的に更新され、リアルタイムで処理される統合ストリーミングデータを、あらゆるAIアプリやエージェントが即座に利用できる構造化された信頼性の高いコンテキストに変換します。

処理済み・ガバナンスが確保されたストリームをオブジェクトストレージ内のクエリしやすいオープンテーブルに拡張したのと同様に、エンリッチされたストリーミングデータをインメモリの低レイテンシキャッシュにマテリアライズし、本番環境のアプリからの高速アクセスができるようになります。これはフルマネージドのMCPを通じて提供され、KafkaとFlinkの複雑さを開発者から取り除きます。開発者は、本番環境のAIに必要なデータをセキュアにリクエストできるようになります

Confluentのデータストリーミングプラットフォーム（DSP）上に直接構築されているため、Real-Time Context Engineは過去のリプレイ、継続処理、リアルタイムサービングを一元管理します。認証、ロールベースアクセス制御（RBAC）、監査ログ機能を備えたセキュアなクラウドネイティブサービスの背後で、KafkaとFlinkの複雑さをデータコンシューマから取り除きます。これにより、開発者はインフラ運用ではなく、インテリジェントシステムの構築に集中できます。上流の定義が変更されると、データストリーミングプラットフォームは影響を受けるデータを自動的に再処理し、下流のAIシステムでの一貫性を、手動での再構築やドリフトなしに維持します。

その結果、履歴に基づいて継続的に検証、エンリッチされ、ライブで提供される、常時接続のコンテキストソースが実現します。これは、AIシステムの実験と本番環境間のミッシングリンクなのです。

Confluent Intelligenceのビジョン

Real-Time Context Engine は、Confluent Intelligence におけるより広範なビジョンの一部です。Kafka と Flink の力を活用して、リアルタイムデータを本番環境の AI に直接提供することを目標としています。Real-Time Context Engine は、これまで議論してきたのと同じ原則、つまりエンタープライズデータをストリームとして取り込み、継続的にエンリッチメントを行い、ライブで提供するという原則を基本としていますが、外部の AI アプリやエージェントだけでなく、Kafka と Flink 上に直接構築されたインテリジェントシステムにも拡張されています。Streaming Agentを使用して、Flink 上でリアルタイムデータを扱う AI/ML パイプラインやアプリケーションを直接構築し、MCP などのオープンインターフェースを通じてあらゆる AI アプリやエージェントにリアルタイムコンテキストを提供できます。

このソリューションの強みは、すべてがConfluentのDSP上で実行されることです。業務システム、分析、データフローを支える基盤が、AIにも活用されています。再生可能なデータで過去を評価し、Flinkの統合ストリームおよびバッチエンジンで継続的に処理し、Real-Time Context Engineでリアルタイムのコンテキストを提供できます。つまり、構築するあらゆるインテリジェントシステムに、同じリアルタイムでコンテキスト化された信頼性の高いデータが活用されるということです。すべてがフルマネージドで、緊密に統合され、同じストリーミングバックボーンで動かされます。さらに、ロールベースのアクセス制御、暗号化、ガバナンスがあらかじめ組み込まれているため、あらゆるインタラクションはセキュアで、監査可能であり、設計段階からコンプライアンスに準拠しています。

始めましょう

Real-Time Context Engineは現在、アーリーアクセス版としてご利用いただけます。アーリーアクセスプログラムへの参加にご興味のある方は、こちらからご登録ください。

Streaming Agentはオープンプレビュー版としてもご利用いただけます。詳細はこちらをご覧いただき、クイックスタートガイドをご覧の上、実際にお試しください。

Confluent Cloud に今すぐご登録いただき、リアルタイムデータを本番環境の AI システムに取り込む方法をご検討ください。まだ Confluent Cloud の無料トライアルにご登録いただいていない方は、ぜひ新しい機能をお試しください。新規ご登録で、最初の 30 日間 Confluent Cloud でご利用可能な 400 ドル相当のクーポンを進呈します。コード CCBLOG60 を利用すれば、さらに 60 ドル分の無料利用枠をご利用いただけます。*

Apache®、Apache Kafka®、Kafka®、Apache Flink®、Flink®、Apache Iceberg™️、Iceberg™️、および Kafka と Flink のロゴは、Apache Software Foundation の登録商標または商標です。