サブタイトル：
イベントは事実で、コンテキストは意味
Kafkaはイベントを運び、Flinkは意味を作る
はじめに
たとえば、ある社員が短時間に大量のデータをダウンロードし、その直後にUSBへコピーしたとします。
LOGIN
DOWNLOAD
USB接続
という個々のイベントは、それぞれ「起きた事実」です。
しかし、これらを組み合わせることで、
「通常とは異なる行動が、今起きている」
という状況を捉えることができます。
この記事では、ConfluentとApache Flinkを使って、個々のイベントから「今起きていること＝コンテキスト」をどのように生成するのかを整理し、デモを作成しました。
本記事では、「コンテキスト」を 「今、何が起きているのかを理解するための情報」 として扱います。
本文
私はデータ利用者がデータ活用を進める上でのデータ基盤（データセマンティックレイヤー、論理層）の構成に関わってきました。そこではデータそのものに加え、「そのデータが何を意味するのか」を考えてきました。
そして今このタイミングで、ConfluentやApache Flinkで「今、何が起きているのか」を扱っていく中でリアルタイムなデータの意味付けが必要になってきていることを感じます。
このデモを作ろうとした経緯
先日、Confluentで実現する「需要シグナル」× SoR の イベント駆動型 AI システム という内容でQiitaで投稿させていただきました。
ここでは、
・確定在庫（SoR）
・身の回りに起きている「シグナル」のような情報、需要シグナル（Data in Motion）
を分離し、Confluent + Flink + AI Agentでリアルタイム活用するデモを作成しました。
この中で「DBでも業務のイベントデータを保存できるのでは？」という疑問を整理してみました。
今回は「イベントログ」で考えてみようと思います。
イベントログも前回の記事で扱った需要シグナルと同じく、Data in Motionとして扱うことができます。
例えばセキュリティ業務で重要なのは「何が起きたか」だけではありません。
「今、何が起きているのか」を把握し判断につなげること です。
イベントはひとつひとつの事実です。
人が判断するのは事実そのものだけでなく、「その事実が持つ意味」です。
「コンテキスト」 とは、「今、何が起きているのかを理解するための情報」だと考えます。
ただ、これも前回と同様に「DBでも業務のイベントデータを保存できるのでは？」という疑問が出てくるかもしれません。
ではなぜ、今Confluentでリアルタイムデータを扱い、さらにコンテキスト（文脈）を作ろうとしているか？ 次の観点で整理すると解像度が高まると考えました。
前回の記事の SoR と 需要シグナル という観点と、State と Context という単語を使って整理してみましょう。

SoR(DB) ：今どうなっているか、現在の状態 ＝ State
Event(Kafka)：今、何が起きているのかという単独の事実
Confluent(Kafka + Flink)：今、何が起きているのかを理解するための情報 ＝ Context
では、実際にシナリオを参考にしてユースケースを確認してみます。
今回はAIエージェントからの利用イメージまでは言及しておりませんが、StateとContextの違いをBIダッシュボードでリアルタイムに変化する状態を把握いただけると思います。
次のシナリオをご覧いただき、AIエージェントでの利用も想像してみていただければ、様々なアイデアが生まれるかもしれません。
デモ・シナリオ
製造業界での開発部門向け 内部不正・インサイダー脅威検知デモ
※本デモで使用しているデータ・社員ID・数値はすべて説明用の架空データです。
このデモが表現していること — Confluent + Flink の本質的な価値
単にセキュリティアラートの仕組みではありません。
個々のログイベントから「意味」を生成するリアルタイムデータのエンリッチメントです。
生ログ（login / file / USB / HR）
↓ Phase1: Flink CEP — イベントの連鎖を検知（何が起きたか）
↓ Phase2: Flink ML異常検知 — その人にとって異常か（いつもと違うか）
↓ Phase3: UBAストリーミングスコアリング — 業務コンテキスト評価（リスク評価）
↓
業務判断：security.alerts（意思決定に使える形へ変換済み）
*CEP：複合イベント処理 / Complex Event Processing）
*ML：（機械学習）
*UBA ストリーミングスコアリング：User Behavior Analytics
この構造はセキュリティに特化したお話ではないとお考えください。
前回のQiita デモ・シナリオにも応用できます。
例えば、以下のように照らし合わせていただくと、ご想像いただけると思います。
今回のQiita デモ・シナリオ：LOGIN → DOWNLOAD → USB
前回のQiita デモ・シナリオ：商品閲覧 → カート → 見積依頼
システム・アーキテクチャ図 （比較）
デモの流れ
Step 1 — Flink CEP（複合イベント処理 / Complex Event Processing）
ポイント：
複数システムをまたぐイベントの 順序・時間窓・組み合わせ を SQL 1本で記述できます。
「状態の検索」ではなく「イベントの流れを捉える」ことに着目します。
単体ログからFlink CEPで「Login → Download → USB の 15分以内の連鎖」を自動検知します。
Step 2 — Flink AI/ML（振る舞い異常検知 / ML_DETECT_ANOMALIES）
ポイント：
ルールではなく Confluent が提供する組み込み ML 関数 が過去パターンを学習し、 リアルタイムで統計的異常を判定する。
feature_name = ML_DETECT_ANOMALIES:file_count として出力。
EMP-007 の平均 2件/日 vs 当日 47件 という乖離を ML が自動判定し is_anomaly=true を返す。
Step 3 — UBA ストリーミングスコアリング（User Behavior Analytics）
Kafka Topic を集計し、ルールベースでスコア付けを行っています。
BIダッシュボードのデータ変化イメージ
これまでのKafka TopicからFlinkでコンテキスト化したデータを、後続の仕組みで活用できる状態になりました。
今回はBIダッシュボードで表現してみました。
伝えたいこと、まとめ
State は「今どうなっているか」
Context は「今、何が起きているのかを理解するための情報」
SoR(DB) ：今どうなっているか、現在の状態 ＝ State
Confluent + Flink：今、何が起きているのかを理解するための情報 ＝ Context
私はこれまで、BIやデータ基盤の世界で「データから意味を作ること」に取り組んできました。
ConfluentやApache Flinkに触れる中で感じるのは、その意味生成がリアルタイムの世界へ拡張されているということです。
重要なのはイベントそのものだけではありません。イベントから継続的に生成されるコンテキスト です。
AI Agentが活用するのも、リアルタイムデータそのものだけではなく、その瞬間から生成されたコンテキスト なのかもしれません。そこから私たちの身近な業務の変化へつながっていくヒントを感じます。
記事：Harukichi