コンテキストとは「情報量」ではない──エンタープライズでの大規模エージェント展開「第一の柱」とは?
IBM×Confluentによる“Streamhouse”は新たな主流アーキテクチャとなるか
【データ】“State”と“Change”をAIにリアルタイムで給餌せよ
登壇したのは、2026年3月にIBMへ統合されたConfluentのゼネラルマネージャーであるショーン・クローズ(Shaun Clowes)氏だ。同氏は、自動化が可能な業務領域がLLMの進化により急速に拡大することで、企業のクロックスピード(処理速度)に変化が起こりつつあると指摘した。人間がプロセスを実行する場合は、組織レベルのスピードも人間の理解力・行動力の範疇に収まるが、エージェントは理解も行動もマシンスピードである。
ただし、AIエージェントは自分が理解できる情報にしかアクセスできない。つまり、理解も行動も、アクセスできるコンテキストの質と適時性の範疇にとどまるのがエージェントの特性である。古く、断片化され、不完全なコンテキストを頼りにするエージェントは、マシンスピードで間違いを繰り返し、人間の手戻り作業を増やし、組織の足を引っ張る存在になる。
もちろん、すべてのデータがリアルタイムで必要というわけではない。しかし、「人間のキャパシティによって制限されていたスピードの壁が破壊されたとき、アーキテクチャ自体が制約になる」とクローズ氏。エージェントが大規模かつ安全に素早く行動できるかどうかは、アーキテクチャがAIに対し「正確・最新・信頼できる」ビジネスコンテキストをいかに迅速に“給餌”できるかにかかっていると述べた。
コンテキストの質を左右するのは、情報量ではない。特定のタスクを完了するという目的に対し、必要な情報がそろっていれば十分だ。そのカギを握るのは、「State(状態:今、何が事実なのか)」と「Change(変化:今、何が起こっているのか)」である。
エンタープライズにおけるコンテキストは、多種多様なシステムに分散している。従来は、各プロジェクトごとに個別のコネクタ、パイプライン、データのコピーを繰り返し構築することが一般的だったが、エージェント時代にこのやり方では、複雑・鈍足・高コストの3点セットで確実に破綻する。
とはいえ、システムやデータを無理に一箇所に集約する必要はない。IBMがConfluentの力をもって提案している「Streamhouse(ストリームハウス)」という新しいアーキテクチャが解決策となる。2026年9月に、複数のデータストリーミング企業とともに共同で定義・発表したものだ。データを集約することなく、ソース(発生源)に近い場所で再利用可能なコンテキストを作成・統制し、それをエージェントやアプリケーション、アナリティクスツールなど、すべてのワークロードへリアルタイム配信する構造となっている。これなら、StateとChangeは常に最新を保てる。
フィールドCTOのキユ・ガブリエル(Kiyu Gabriel)氏は、架空のユースケースを披露した。ある大手ホテルチェーンが運営するサービス上で、顧客の滞在体験をサポートするAIコンシェルジュが稼働していたとする。顧客のフライトに遅延が発生した場合、チェックインや観光ツアー、施設予約などの手配を自動で調整してくれるというものだ。
このシステムを設計する場合、従来なら基本的には2つのアプローチが考えられた。
- データフェデレーション(API連携):各システムにリクエスト・レスポンスで問い合わせる手法だが、エージェントがChangeの有無を確認するために頻繁に問い合わせの通信を行うため、システムリソースの大部分が無意味なステータス確認に浪費される
- データコンソリデーション(Lakehouseへの集約):Kafka経由で集約し、バッチ処理でデータを精製するが、長い遅延が発生する。たとえば、エージェントがホテルを予約した直後にツアー手配を行おうとしても、ホテル予約のデータにアクセスできるまでのタイムラグが大きく、エージェントは次のアクションであるツアー手配がなかなかできない。その間に誤作動を起こしてしまう可能性もある
Streamhouseは、上記2つの間に位置する「第三の優れた選択肢」だとガブリエル氏。ブロンズ(生データ)、シルバー(クレンジング済データ)、ゴールド(活用可能なデータ)と段階的にデータを整えて蓄積するメダリオンアーキテクチャではなく、リアルタイムのイベントストリーム上にゴールド層のビューを構築し、ステートフル(Stateful)なストリーム処理とガバナンスを実現する。従来、そのようなストリーム処理コードの記述・運用は困難であったが、IBMのAIアシスタント「IBM Bob」やConfluentの進化したインターフェースにより、直感的な構築・運用が可能となった。

なお、IBMはStreamhouseについて、上記2つに「とって代わるもの」だとは考えておらず、あくまでもエージェント時代における組織のニーズや要件に対して提供できる選択肢の一つだとしている。日本から現地に参加した日本アイ・ビー・エムのフィールドCTO 野村幸平氏は、「ベンダーロックインを誘発したり、他社の市場へ競合しにいくのではなく、顧客にあらゆる選択肢を用意するのがIBMの一貫した姿勢であり、大切にしている思想だ」と、基調講演後の囲み取材で語った。
とはいえ、Streamhouseのニーズ自体は、AIエージェントのさらなる浸透とともに確実に高まっていくだろう。特に、リアルタイムの情報に基づいた上で精密な動作を要求されるフィジカルAIなどが大規模にエンタープライズで展開される時代が到来でもしたら、厳格な産業ではきっと主流アーキテクチャになるのではないだろうか。
Streamhouseのポイントは、データの「行き先」ではなく「発生源」から考えることにある。IBM ZやKafka、Oracle、PostgreSQL、SAPなどといった既存のデータソースにあるChangeデータをキャプチャし、コンテキストを一度精製・統制して再利用するという工程だ。自社のデータアーキテクチャを以下3つの観点で見直してほしい、とクローズ氏は呼びかけた。
- エージェントが行動するために必要なStateデータはどこにあり、何が必要か?
- コネクタやパイプライン、コピーを増やさずにStateとChangeの両方を可視化できているか?
- エージェントの行動結果が即座にState/Changeの状態変化として反映され、次の意思決定に活用されているか?
この記事は参考になりましたか?
- DB Press連載記事一覧
-
- コンテキストとは「情報量」ではない──エンタープライズでの大規模エージェント展開「第一の柱...
- データ分析優等生企業キーエンスが重視する「データの科学」/“任せられるAI”を作るデータガ...
- HPC界レジェンド「AIインフラで真っ先に限界を迎えるのは“メタデータ処理”」NetApp...
- この記事の著者
-
名須川 楓太(編集部)(ナスカワ フウタ)
サイバーセキュリティとAI(人工知能)の分野を中心に、ソフトウェア/ハードウェアを問わず国内外の最新技術やルールメイキング動向を取材。そのほか、DX推進、IRなどのコーポレート領域でも情報を発信。※取材のご案内等は個人のメールアドレスか、EnterpriseZine編集部の問い合わせ窓口にお願いいた...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア

