この記事の要点
- Feature Storeは、AIの判断材料を置く棚のような役割です。
- 新しい出来事がすぐ棚に並ぶほど、AIの判断は現実に近づきます。
- 価格や利用開始日は、公式ブログでは明示されていません。
AIの厨房に新しい材料を置く
Databricksは2026年8月17日、Feature Store（AIに渡す特徴量を管理する場所）のサブ秒更新について公式ブログで説明しました。AIに渡す材料を、作り置きから出来たてへ近づける話です。
特徴量（AI判断に使う信号）は、料理でいえば食材です。古い食材だけで作れば、料理の味は今の注文に合いません。
今回の数字はKafkaからオンラインFeature Storeまで200ms p99です。p99（遅い上位1%を含めた目安）でこの速さなら、AIはかなり新しい材料を見られます。
レジ前の数秒が勝負になる
公式ブログが出す例は、不正検知です。利用者が購入を押した時、AIはその取引を通すか判断します。
ここで、過去30日間の平均だけを見ると平常時は分かります。ただし、直近10分間に急な取引が積み上がったかは別です。
不正の兆しは、最後の数秒に出ることがあります。直近の信号を拾えるAIほど、現場の判断に近づきます。
冷蔵庫ではなく流れる棚になる
従来のバッチ処理（まとめて処理する方式）は、冷蔵庫にまとめて補充する感覚です。決まった時間に補充されるので、棚は安定します。
一方で、いま入った注文への反応は遅れます。Databricksは、既存のFeature Store基盤では秒やミリ秒まで下げるのが難しいと説明しています。
Databricks Feature Storeは、同じ特徴量定義をオフラインとオンラインの両方で使う形です。作り方を二重に持たないので、現場側のつなぎ込みも軽くなります。
3種類の時間の見方
時間の見方にも違いがあります。Databricksは、時間窓を3つに分けています。
・Tumbling windowは、決まった箱ごとに集計します。
・Sliding windowは、重なる箱で少し細かく見ます。
・Rolling windowは、今から見た直近を常に見ます。
不正検知や現在の興味を読むなら、Rolling window（直近時間を動かしながら見る集計）が合います。箱が閉じるのを待たず、出来事ごとに値が変わるからです。
これは、レストランで注文票を後でまとめて読むか、入った瞬間に厨房へ渡すかの違いです。AIの判断も、受け取る順番と速さで変わります。
裏側では何が動くのか
Spark Real-Time Mode（行ごとに処理を進める実行方式）は、届いた行を待たせずに処理します。Databricksは、従来のマイクロバッチ方式より低い遅延を狙う中核として説明しています。
Lakebase（DatabricksのサーバーレスPostgres基盤）は、オンライン側の値を持ちます。小さな更新が大量に来る場面で、書き込みの負担を抑える設計です。
Model Serving（AIモデルを呼び出す仕組み）は、AIが答えを出す時に最新の特徴量を取り出します。特徴量の依存関係はMLflow（機械学習の実験・モデル管理）で記録されます。
使える条件の見え方
| 項目 | 公式発表で読めること |
|---|---|
| 発表日 | 2026年8月17日のDatabricks公式ブログ |
| 性能 | 200ms p99のend-to-end latency |
| 用途例 | 不正検知、パーソナライズ |
| 価格 | 発表に書かれていない |
| 一般提供開始日 | 発表に書かれていない |
Databricksの開発者向けページでは、企業データ上で低遅延アプリやエージェントを作る統合環境も説明されています。Agent Bricksは、Claude、GPT、Gemini、DeepSeek、Llamaなどに触れています。
つまり、Databricksはモデル単体の話だけをしていません。企業データ、アプリ、エージェント、特徴量の更新を同じ場所に寄せる方向です。
AIの価値は、質問への答えだけで決まりません。直前の出来事を見て、迷う時間を短くできる時、仕事の中に溶け込みます。