ストリーミング処理 ― 本当に必要かをまず疑う ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第6弾として、ストリーミング処理について解説する記事です。

「リアルタイム」要件を問い直すと9割は「5分遅延バッチで十分」に落ち着きます。本記事ではストリーミング基盤の選定（Kafka／Kinesis／Pub/Sub／Flink／ksqlDB）・Exactly-Once・ウィンドウ処理・判断基準を解説し、本当にリアルタイムが必要かをまず疑うという実務の鉄則を示します。

このカテゴリの他の記事

概要 ― AI時代の前提となるデータ整備 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-overview/

データストア選定 ― RDB中心+用途特化の使い分け ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-datastore/

データモデリング ― AIにも人間にも読めるスキーマ ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-modeling/

データ基盤 ― DWH・データレイク・レイクハウスの選び方 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-platform/

ETL・ELT ― Fivetran+dbt+DWHが現代の定石 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-etl/

データガバナンス ― AIへの辞書として整える基盤 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-data-governance/

ストリーミング処理が扱うもの

中核にはメッセージキュー（Kafka・Kinesis・Pub/Sub）があり、イベントを永続的なログとして保持しつつ、複数の消費者に同時配信します。データは止まらず流れ続けるのが特徴で、バッチとは世界観が根本的に違います。

ストリーミングは本当に必要な時だけ選ぶ。バッチの10倍の運用コストがかかります。

なぜ必要か

① 秒単位の遅延が業務価値に直結する

不正検知・在庫連動・価格連動・IoT制御──これらは「数分後」では遅すぎます。イベント発生から判断まで秒以下にする必要があります。

② バッチウィンドウが消滅しつつある

24時間365日稼働のグローバル業務では、「夜間バッチ」の時間が取れません。常時流れ続けるデータをそのまま処理する必要が出てきます。

③ マイクロサービス間の疎結合連携

マイクロサービス構成では、サービス間をイベントで繋ぐのが主流です。ストリーミング基盤がサービス間通信の中枢神経として機能します。

バッチとストリーミングの違い

	バッチ処理	ストリーミング処理
処理単位	まとまったデータ	1イベント〜少数
遅延	数時間〜日単位	ミリ秒〜秒単位
実装	比較的簡単	難しい・運用重い
コスト	安い	高い
リトライ	やり直し容易	設計が難しい
代表技術	Spark・dbt	Kafka・Flink

多くの業務要件はバッチで十分で、ストリーミングが真に必要な場面は限定的です。「リアルタイムっぽく見える」程度なら、15分マイクロバッチで代用できることも多いです。

主要な構成要素

ストリーミング基盤は「イベントを運ぶ層」と「イベントを処理する層」に分かれます。前者がメッセージキュー（Kafka等）、後者がストリーム処理エンジン（Flink等）で、役割が異なるため別々に選定します。

flowchart LR
    PROD[Producer<br/>業務システム/IoT]
    MQ["メッセージキュー<br/>(運ぶ層)<br/>Kafka/Kinesis/Pub-Sub"]
    PROC["処理エンジン<br/>(集計・変換・結合)<br/>Flink/ksqlDB"]
    SINK1[(DWH/<br/>BigQuery)]
    SINK2[(検索<br/>Elasticsearch)]
    SINK3[Realtime<br/>ダッシュボード]
    PROD -->|Event| MQ
    MQ --> PROC
    PROC --> SINK1
    PROC --> SINK2
    PROC --> SINK3
    MQ -. 直接Sink .-> SINK1
    classDef prod fill:#fef3c7,stroke:#d97706;
    classDef mq fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
    classDef proc fill:#fae8ff,stroke:#a21caf;
    classDef sink fill:#dcfce7,stroke:#16a34a;
    class PROD prod;
    class MQ mq;
    class PROC proc;
    class SINK1,SINK2,SINK3 sink;

層	役割	代表例
メッセージキュー	イベントの永続化と配信	Kafka・Kinesis・Pub/Sub
ストリーム処理エンジン	集計・変換・結合	Flink・ksqlDB・Spark Streaming
スキーマ管理	メッセージの型定義	Schema Registry・Protobuf

Apache Kafka（メッセージキューの業界標準）

Apache Kafka は LinkedIn 発の OSS で、ストリーミング基盤の事実上の標準です。毎秒数百万イベントを捌ける高スループット、イベントを「ログとして永続化」する設計、複数消費者が独立して読める仕組みが特徴で、Netflix・Uber・LINE など世界のメガ企業が採用しています。Confluent Platform（商用版）や Confluent Cloud（マネージド）という選択肢もあります。

強みは「性能と拡張性の高さ」ですが、代償として運用負荷が極めて重いのが難点です。Zookeeper（現代はKRaft）の管理、ブローカーのパーティション設計、コンシューマーグループの調整など、専属の運用チームがいないと本格利用は困難です。

メリット	デメリット
圧倒的な性能・実績	運用負荷が重い
OSS・ベンダーロックイン薄い	学習コストが高い
エコシステム（Connect・Streams等）が豊富	小規模には過剰
低レイテンシ（ミリ秒単位）	クラスタ設計の難度が高い

Kafkaは自社で運用できるなら最強、できないならマネージド（Kinesis・Pub/Sub・Confluent Cloud）を検討します。

マネージドキュー（Kinesis / Pub/Sub / Event Hubs）

クラウドベンダーが提供するKafka代替サービスです。運用をクラウド側が担うため、スケーリング・可用性・バックアップの心配が不要で、少人数チームでもストリーミング基盤を持てるのが最大の魅力です。AWSなら Kinesis、GCPなら Pub/Sub、Azureなら Event Hubs が標準選択です。

メリット	デメリット
運用ゼロに近い	クラウドロックイン
小規模から始めやすい	大規模だと割高になる場合あり
他マネージドサービスと統合容易	細かいチューニングは難しい
障害対応がクラウド側	Kafka固有機能は使えない

代表例：Amazon Kinesis Data Streams・Google Pub/Sub・Azure Event Hubs・Confluent Cloud

まずはマネージド、スループット上限で困ったらKafkaへ移行が現代の定石です。

Apache Flink（処理エンジンの本命）

Apache Flink は、ステートフルなストリーム処理に特化した OSS で、複雑な集計・結合・イベント時刻処理をミリ秒レイテンシで実行できます。Uber・Alibaba・Stripe など、数百億イベント/日の規模でも使われる本格派で、Exactly-Once保証を最も信頼性高く実装できます。

一方で運用難度はKafka以上で、チェックポイント設計・ステートバックエンド選定・ジョブ再起動の管理など、学習コストが非常に高いです。AWS Kinesis Data Analytics・Aliyun Realtime Computeのようなマネージド版もあり、運用負荷を下げて導入するのが現実的です。

メリット	デメリット
低レイテンシ・高スループット	学習コストが高い
複雑な処理を柔軟に書ける	運用難度が高い
Exactly-Onceが堅牢	小規模には過剰
イベント時刻処理が強力	Java/Scalaが主（Pythonもあり）

ksqlDB・Kafka Streams（SQL と Javaライブラリ）

Kafka専用の軽量処理エンジンです。ksqlDB はKafkaをSQLで扱える製品で、Flinkのような本格的処理を書かずに、集計やフィルタリングをSQLで表現できます。Kafka Streams はライブラリで、アプリケーションに組み込んでストリーム処理を書ける手軽さが売りです。

どちらもKafkaを前提とした選択肢で、Kafka以外のキュー（Kinesis等）では使えません。SQLで済むユースケース、あるいは既存Javaアプリに処理を組み込みたいケースで有効です。Flinkほどの複雑な処理はできませんが、「学習コストが桁違いに低い」のが魅力です。

「Kafka + SQLで済む規模」ならksqlDBが最短ルート。複雑化したらFlinkへ移行します。

典型的な構成例

ストリーミング基盤の典型構成は以下のようになります。イベントの発生源からBI・DBまで、リアルタイムで流れ続けるのがバッチとの決定的な違いです。

flowchart TB
    SRC([Web / モバイル / IoT / 業務システム])
    BUS["Kafka / Kinesis / Pub/Sub"]
    RT["リアルタイム処理<br/>Flink・ksqlDB"]
    DWH["DWH取込<br/>Fivetran / Snowpipe"]
    ACT["即時アクション<br/>通知・ブロック"]
    BI["分析・BI"]
    SRC -->|イベント発行| BUS
    BUS --> RT --> ACT
    BUS --> DWH --> BI
    classDef src fill:#fef3c7,stroke:#d97706;
    classDef bus fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
    classDef rt fill:#fae8ff,stroke:#a21caf;
    classDef bi fill:#dcfce7,stroke:#16a34a;
    class SRC src;
    class BUS bus;
    class RT,ACT rt;
    class DWH,BI bi;

左側がリアルタイム処理、右側が分析向け取込という二系統に分かれるのが一般的です。

Exactly-Onceの難しさ

ストリーミングで最も厄介なのが「メッセージを1回だけ処理する保証」（Exactly-Once）の実現です。ネットワーク障害・再起動・タイムアウトが発生すると、重複処理や欠損が簡単に起きます。銀行送金・決済・在庫反映のような業務では、重複は致命的です。

Kafka・FlinkはExactly-Onceをサポートしますが、「エンドツーエンドの保証は設計が必要」で、消費者側の処理も冪等（同じ入力で同じ結果）に設計しなければ意味がありません。

保証レベル	意味	難易度
At-Most-Once	失敗時は諦める（欠損あり）	簡単
At-Least-Once	重複ありで確実に配信	中
Exactly-Once	厳密に1回	難しい

重複処理を避けたければ、消費者側を冪等に設計するのが王道。Exactly-Onceは盾、冪等は矛です。

ウィンドウ処理

ストリーミング処理では「直近5分の売上」「1時間あたりのエラー数」といった時間で区切った集計（ウィンドウ処理）が頻出します。バッチなら簡単な集計も、終わりの無いストリームでは「どこで区切るか」が設計論点になります。

ウィンドウ種別	内容	例
Tumbling	固定長で重複なし	0-5分・5-10分
Sliding	固定長でずらしながら	直近5分（1分ずつ更新）
Session	活動が途切れるまで	1ユーザーの訪問セッション
Global	全期間	累計カウント

加えてイベント時刻（発生時刻）と処理時刻（到着時刻）の区別も重要で、ネットワーク遅延で順序が乱れるため、「遅れて来たイベントをどう扱うか」が設計ポイントになります。

判断基準

① 本当にリアルタイムが必要か

ストリーミングを検討する際、まず問うべきは本当にリアルタイムが必要かです。要件をヒアリングすると「数分遅れでOK」だったことが多く、バッチで安く安定運用できます。

要求	推奨
数日遅れOK	日次バッチ
数時間遅れOK	時次バッチ
5〜15分遅れOK	マイクロバッチ
数秒〜1分遅れOK	軽量ストリーミング
100ms以下必須	本格ストリーミング

100ms以下が本当に必要な業務は、「決済・不正検知・広告入札・IoT制御・取引所」など限定的です。

② 運用体制

ストリーミングは「24/7で稼働し続ける」ため、バッチよりも監視・障害対応の負荷が桁違いに重くなります。運用チームがいないと、障害時に数時間データが欠損することもあります。

運用体制	推奨
専属SRE（Site Reliability Engineering）/データエンジニアなし	ストリーミング選ばない
マネージドサービス使える	Kinesis・Pub/Sub
Kafkaを自社運用できる	Kafka + Flink
24/7運用チームあり	本格ストリーミング基盤

③ データ量と予算

ストリーミング基盤はデータ量に応じて料金が上がります。Kafkaのブローカー・Kinesisのシャード・Pub/Subのメッセージ数──いずれも放っておくと月額が数百万になります。

データ量	構成イメージ	月額目安
〜100万イベント/日	Pub/Sub + Cloud Functions	〜数万円
〜1億イベント/日	Kinesis + Lambda	数十万円
数十億〜/日	Kafka + Flink自社運用	数百万円〜

ケース別の選び方

小規模・AWS・SaaSスタートアップ

Kinesis Data Streams + Lambda。マネージドで運用ゼロに近い。月数万円から回せる。

中規模・GCP・データ分析重視

Pub/Sub + Dataflow。Beamベースで学習コスト低め。BigQueryとの統合が秀逸。

大規模・社内運用可能

Kafka + Flink。最強の組み合わせだが、運用チーム必須。専属SRE 2-3人は欲しい。

SQLで済ませたい

ksqlDB + Kafka or Materialize。SQL書けるアナリストが運用できる。

そこまで即時性要らない

マイクロバッチ（dbt + 15分スケジュール）。ストリーミング運用を避けつつリアルタイムぽく見せる。

筆者メモ — 「リアルタイムが欲しい」の本当の意味

ある案件では、顧客から「リアルタイムダッシュボードが欲しい」と言われて「Kafka + Flinkの構成を3ヶ月かけて組んだ」ものの、後でヒアリングし直すと実際の業務要件は「30分以内の遅れなら問題ない」だった、という話がよく聞かれます。cronの15分スケジュールで十分だった案件で、その後1年は深夜の障害対応に追われた、というオチまでがセットで語られる典型事例です。

もう一つ有名なのが、2020年11月のAWS Kinesis大規模障害です。米国東部リージョンで Kinesis Data Streams が長時間停止し、AWS 自体の管理コンソールや CloudWatch まで巻き込まれた出来事で、ストリーミング基盤に依存した瞬間、その障害が全業務を止めるという怖さを広く周知した事件として語り草になっています。リアルタイム基盤は「便利な道具ではなく、新しい単一障害点」になり得る、という教訓です。

筆者自身、顧客から「リアルタイムで数字を見たい」と依頼された時に、最初に「数秒遅れなら困りますか？」「5分ならどうですか？」と問い直すクセが付いたのは、過去にこの種の案件で痛い目を見たからです。どちらも「ストリーミングは本当に必要な時だけ」という基本を踏み外すと、運用負荷と可用性リスクが同時に跳ね返ってくることを示しています。マイクロバッチで済むなら、それが一番安全で安い、というのが実務の結論です。

「リアルタイム」と言われたらまず数値で分解。5分遅れと100ms遅れでは世界が違います。

鮮度要件×ストリーミング採用の判断段階

「リアルタイム」と言われたら、まず数値で分解するのが実務。鮮度要件ごとに最適な解が違います。

鮮度要件	採用技術	月額運用コスト	必要SRE人員
日次（朝に前日分）	日次バッチ（dbt）	数千円〜	0人（兼任）
数時間遅れOK	時次バッチ	数万円	0人（兼任）
5〜15分遅れOK	マイクロバッチ（15分 dbt）	数万円	0人
1分〜数秒遅れ	軽量ストリーミング（Pub/Sub + Lambda）	数十万円	1人
100ms以下必須	本格ストリーミング（Kafka + Flink）	数百万円〜	2〜3人専属

「ストリーミング採用の実質下限は専属SRE 2人以上」これ未満で採用すると、24/7 の障害対応・ウィンドウ設計・Exactly-Once の運用で現場が溶けます。業務要件の9割は日次バッチかマイクロバッチで足りる、というのが経験則。「リアルタイムっぽく見せる」ならマイクロバッチで十分です。

リアルタイムはバッチの10倍の運用コスト。本当に必要な場面に限定します。

ストリーミング運用の鬼門・禁じ手

ストリーミング領域で事故る典型を整理します。どれもデータ欠損・二重処理・サービス全停止に直結します。

禁じ手	なぜダメか
「顧客がリアルタイム欲しい」で即ストリーミング採用	実際は30分遅れでOKだったケースが多数。要件ヒアリングを先に
冪等性なしのAt-Least-Once運用	ネットワーク障害で二重決済・二重在庫減算
Kafkaを専属SREなしで自社運用	Zookeeper / KRaft管理、パーティション設計で現場が溶ける
イベント時刻と処理時刻を区別しない	遅延到着イベントで集計が狂う。ウィンドウ設計を厳密に
JSONフリーダム（スキーマ定義なし）でKafka運用	消費者が壊れ続ける。Protobuf / Avro + Schema Registry必須
ストリーミング基盤に依存した瞬間に全業務が依存	2020年11月のAWS Kinesis障害のようなSPOFに
Exactly-Onceで安心しきる	消費者側の冪等性が伴わないと無意味。盾と矛の両方が必要
DLQ（Dead Letter Queue）なしで運用	処理失敗したメッセージが永遠にリトライ、詰まる
監視をバッチと同じ粒度で設定	ストリーミングは秒単位の監視が必要。メッセージ遅延・コンシューマーラグを常時監視
メッセージ量急増への備えなし	Kafkaのパーティション不足で処理遅延が雪だるま式に
スキーマ変更を前方互換なしで実施	旧バージョンの消費者が全滅。Avro / Protobufの互換性ルールを守る

2020年11月25日のAWS Kinesis大規模障害は、us-east-1でKinesis Data Streamsが長時間停止し、CloudWatch / Cognito / SQSなど多数のAWSサービスが連鎖的に影響を受けた事件です。ストリーミング基盤に依存した瞬間、その障害が全業務を止めることを示した教訓です。

本格ストリーミングは専属SRE 2〜3人とSchema Registryが最低条件です。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、ストリーミングはAIエージェントの判断を即座に反映する経路として重要性が増します。不正検知・異常検知・動的推薦などは、AIがリアルタイムに判断する基盤が前提です。

AI時代に有利	AI時代に不利
マネージド（Kinesis・Pub/Sub）	自前Kafka（運用がAIに学習されにくい）
スキーマ駆動（Avro・Protobuf）	JSONフリーダム
イベント駆動（ドキュメント化済）	暗黙のタイミング依存
SQL中心（ksqlDB・Flink SQL）	独自DSL（Domain-Specific Language）

AIが処理を書く時代には、スキーマと契約が明示されたストリームが有利です。Protobuf + Schema Registry で型を管理し、AIが安全に処理を生成できる状態を整えるのが新しい基準です。

リアルタイム基盤はスキーマを明示する。AI時代のストリーミングは「型」が命です。

よくある勘違い

リアルタイムの方がカッコいいから採用 → 運用コストは桁違い。業務要件の9割はバッチで十分。技術選定は必要性で決める
Kafkaを入れれば問題解決 → Kafkaは「土台」に過ぎません。処理エンジン（Flink等）・スキーマ管理・監視・運用体制も必要で、総合的に重い
Exactly-Onceがあれば安心 → 保証は万能ではありません。消費者側の冪等性がないとエンドツーエンドでは守られません
ストリーミングだから速い → 設計次第ではバッチより遅いこともあります。ウィンドウ・状態管理・リトライを誤ると性能が出ません

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

本当にリアルタイムが必要か（要件の再確認）
メッセージキュー（Kafka / Kinesis / Pub/Sub）
処理エンジン（Flink / ksqlDB / Spark Streaming / 不要）
保証レベル（At-Least-Once / Exactly-Once）
スキーマ管理（Avro・Protobuf + Schema Registry）
ウィンドウ設計（時刻の種類・遅延許容）
監視・アラート（SLO（Service Level Objective）・メトリクス・障害通知）

最終的な判断の仕方

ストリーミング処理の核心はバッチの10倍の運用コストがかかるという認識から始まることです。リアルタイムはカッコいいから選ぶものではなく、業務要件の9割はバッチかマイクロバッチで足ります。100ms以下の遅延が本当に価値を生むのは決済・不正検知・広告入札・IoT制御など限定的で、それ以外でストリーミングを選ぶと、24/7運用・Exactly-Once設計・ウィンドウ管理の難度で現場が疲弊します。「まず本当に必要か」を問い、次に「運用体制はあるか」を問うのが正しい判断順序です。

決定的な軸はスキーマと型が明示されているかです。AIエージェントがリアルタイム判断を行う経路としてストリーミングの重要性は増しますが、JSONフリーダムな設計ではAIが処理を生成できません。Protobuf / Avro + Schema Registryで型を明示し、SQL中心（ksqlDB / Flink SQL）で書くのが、AI時代に陳腐化しないストリーミング基盤の形です。

選定の優先順位

本当にリアルタイムが必要か問う — 数分遅れOKならマイクロバッチで代用
マネージドを最優先 — Kinesis / Pub/Subで運用負荷を下げる、Kafka自社運用はSRE専属が必要
スキーマを明示 — Protobuf / Avro + Schema Registry、JSONフリーダム禁止
消費者側を冪等に設計 — Exactly-Onceは盾、冪等は矛。両方揃って初めて安全

「ストリーミングは本当に必要な時だけ」運用体制とスキーマ設計を先に固めてから選びます。

まとめ

本記事はストリーミング処理について、Kafka・Kinesis・Pub/Sub・Flink・ksqlDBの選定・Exactly-Onceとウィンドウ処理・鮮度要件×運用コストの段階表・リアルタイムの過剰投資を避ける判断軸まで含めて解説しました。如何だったでしょうか。

本当にリアルタイムが必要か問い、マネージドを最優先し、スキーマを明示し、消費者側を冪等に設計する。これが2026年のストリーミング処理の現実解です。

次回はデータガバナンス（マスタ管理・カタログ・規制対応）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。