ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説

ストリーム処理は、発生し続けるデータを到着のたびに受け取り、ためこまずに処理し続けるデータ処理方式です。ECの行動ログ、IoTセンサーの計測値、決済トランザクションのように「終わりのないデータ」を秒以下〜数秒の遅延で分析・変換する場面で使われてきました。本記事では、バッチ処理・リアルタイム処理との違いという基礎から、イベント時間とウォーターマーク、ウィンドウ、ステート管理、exactly-onceといった処理モデルの内部、Apache KafkaやFlinkなど基盤技術とアーキテクチャの型までを実装者の視点で整理します。そのうえで、ストリーム処理の採用が見合う要件と、バッチ処理で十分な場面の線引きを言い切ります。

まとめ：ストリーム処理の要点とバッチ処理との使い分け判断の軸

先に結論を置きます。ストリーム処理とは、データを一定量ためてから一括で処理するバッチ処理と対をなす方式で、データが届いた瞬間に1件ずつ（または小さな塊ごとに）処理を進める点が特徴です。得られるのは「データ発生から結果反映までの遅延を秒以下〜数秒に縮められる」という性質であり、不正検知・在庫連動・障害検知のように、結果が数分遅れると価値が落ちる業務で効きます。

実装面の本質は、単に「速く処理する」ことではありません。終わりのないデータを正しく扱うために、イベント時間と処理時間の区別、遅れて届くデータを締め切るウォーターマーク、集計範囲を区切るウィンドウ、途中結果を保持するステート管理、障害時にも結果を重複・欠落させない処理保証という一連の処理モデルが要ります。この部分がバッチ処理には無い設計負担で、Apache Kafka（4.x系）やApache Flink（2.x系）といった基盤は、まさにここを肩代わりする道具です。

使い分けの軸は明確です。日次・月次の集計やレポートのように「結果が翌朝あれば足りる」業務はバッチ処理で組むほうが安く、運用も単純に済みます。逆に、遅延そのものが損失に直結する業務だけをストリーム化するのが定石です。全部をストリームにする必要はありません。この線引きと基盤選定の考え方を、以下で順に掘り下げます。

ストリーム処理の定義とバッチ処理・リアルタイム処理との違いの整理

まず用語の土台をそろえます。ストリーム処理・バッチ処理・リアルタイム処理は混同されがちですが、区別の軸は「データをためるか、流れたまま処理するか」と「遅延の要件」の2つです。

発生し続けるデータを到着のたびに処理するストリーム処理の基本動作

ストリーム処理の対象は、始まりと終わりが定義できない無限のデータ列（データストリーム）です。Webサーバーのアクセスログ、アプリのクリックイベント、センサーの計測値、データベースの変更履歴（CDC）などが典型で、これらは1日に数百万〜数十億件の粒度で流れ続けます。処理系はこの流れを購読し、イベントが到着するたびにフィルタ・変換・集計・結合を実行して、結果を下流のデータベースや通知系へ送り出します。データの置き場としては、Apache Kafkaのような分散ログにいったんイベントを追記し、そこから処理エンジンが読み出す構成が事実上の標準です。ポイントは「データ全体がそろう瞬間が永遠に来ない」前提で計算を設計することにあります。

バッチ処理との違いを遅延・スループット・障害復旧の3観点で比較

バッチ処理は、一定期間ためたデータを夜間などにまとめて処理する方式です。両者の違いは次のように整理できます。

復旧の項が実務では効いてきます。バッチは失敗したら再実行すれば同じ結果になりますが、ストリームは走り続けているため「どこまで処理したか」を記録し、途中から正しく再開する仕組みを最初から組み込まなければなりません。この差が、後述するステート管理と処理保証の設計につながります。

リアルタイム処理・マイクロバッチとの関係と用語の実務的な切り分け

リアルタイム処理は「発生から結果までの遅延が要件を満たす処理」を指す要件側の言葉で、ストリーム処理はそれを実現する実装方式の1つという関係にあります。ミリ秒単位の応答を保証する組み込み系のハードリアルタイムとは別物なので、データ基盤の文脈では「低遅延処理」程度の意味で読むのが実態に合います。もう1つ紛らわしいのがマイクロバッチです。これは数百ミリ秒〜数秒間隔の小さなバッチを連続実行して擬似的にストリームを実現する方式で、Apache SparkのStructured Streamingが代表例に挙げられます。1件ずつ処理する純粋なストリーム（Flinkなど）に比べ遅延は伸びますが、バッチ資産を流用しやすい利点があり、秒単位の遅延で足りるなら実用上の差は小さくなります。

ストリーム処理を支える処理モデルとステート管理・処理保証の仕組み

ストリーム処理の設計が難しいのは、終わりのないデータで「正しい集計」を定義し直す必要があるからです。ここでは実装時に必ず向き合う4つの概念を、Flink系エンジンの用語に沿って押さえます。

イベント時間と処理時間の区別とウォーターマークでの遅延データの扱い

時刻には2種類あります。イベント時間はデータが実際に発生した時刻（ログのタイムスタンプ）、処理時間はそのデータが処理系に届いて計算される時刻です。ネットワーク遅延やモバイル端末のオフライン期間があるため、イベントは発生順に届きません。たとえば10:00:59に発生したイベントが10:01:05に届くことは日常的に起きます。「10:00〜10:01の集計」を正しく出すには、イベント時間で集計しつつ、どこまで遅れを待つかを決める必要があり、その締め切りを流すのがウォーターマークです。「イベント時間10:01より前のデータはもう来ないとみなす」という印をストリームに流し、これが届いた時点でウィンドウを確定させます。待ち時間を長くすれば正確さが上がり、短くすれば遅延が縮む——このトレードオフを業務要件で決めるのが、ストリーム設計の最初の分岐点になります。

タンブリング・スライディング・セッションのウィンドウ3方式の使い分け

無限のデータをそのまま集計はできないため、時間や条件で区切った範囲（ウィンドウ）ごとに計算します。代表的な区切り方は次のとおりです。

• タンブリングウィンドウ：固定長で重複なく区切る（例：1分ごとの売上集計）。集計の重複が無く、ダッシュボードの定点観測に向く
• スライディングウィンドウ：固定長の窓を一定間隔でずらす（例：直近5分の異常値を1分ごとに評価）。しきい値監視や不正検知に向く
• セッションウィンドウ：イベントの間隔が空いたら区切る（例：ユーザーの一連の操作を無操作30分で1セッション化）。行動分析に向く

どれを選ぶかは分析要件そのものです。実装上は、スライディングは窓が重なるぶん計算量とステートが増える点、セッションは長さが可変なためウォーターマーク設計と組み合わせて確定タイミングを詰める点に注意が要ります。

ステート管理とチェックポイントによる障害復旧と再処理の仕組み

ウィンドウ集計や「同一ユーザーの直前イベントとの比較」のような計算は、途中結果（ステート）を持ち続ける必要があります。ステートはメモリや組み込みKVストア（FlinkならRocksDB）に置かれ、数百GB規模まで膨らむこともあり、その保全が可用性を左右する急所です。Flink系エンジンは、稼働中のステート全体を定期的に外部ストレージへ書き出すチェックポイント（分散スナップショット）を取り、障害時は直近のスナップショットと入力ログの読み出し位置（Kafkaのオフセット）を復元して再開します。入力側に「同じデータを再読み出しできるログ」があることが前提になるため、KafkaやKinesisのような再生可能なメッセージ基盤とセットで使う構成が標準になっています。

at-least-onceとexactly-onceの処理保証3水準と選択基準

障害復旧時にデータがどう扱われるかで、処理保証は3水準に分かれます。at-most-once（欠落しうるが重複しない）、at-least-once（欠落しないが重複しうる）、exactly-once（欠落も重複もしない）です。exactly-onceは「1回だけ実行される」魔法ではなく、チェックポイントと出力側のトランザクション（二相コミット）を組み合わせ、結果が1回だけ反映されたように見せる仕組みで、Kafkaもトランザクションと冪等プロデューサで同等の保証を提供します。選択基準は出力先の性質で決まります。金額集計や課金のように重複が事故になる処理はexactly-once、通知やログ転送のように受け手側で重複排除できる処理はat-least-onceで十分です。保証を1段上げるごとに遅延とスループットを支払うため、全経路をexactly-onceにするのは過剰になりがちです。

ストリーム処理基盤を構成する主要技術と代表的なアーキテクチャの型

処理モデルを自前で実装するのは現実的でないため、実務ではメッセージ基盤と処理エンジンを組み合わせます。役割分担と構成の型を押さえると、技術選定の見通しが立ちます。

Kafka・Flink・Sparkの役割分担と2026年時点の現行版

ストリーム基盤は「イベントを受けて保持する層」と「計算する層」の2層で考えます。前者の代表がApache Kafkaで、イベントを分散ログとして追記・保持し、複数の処理系へ再生可能な形で配ります。現行は4.x系で、4.0からZooKeeperを廃止しKRaftへ一本化、2026年6月時点では4.3系が最新です。タスク分配に使うキュー型ブローカーとの使い分けはRabbitMQとKafkaの違いの比較解説で整理しています。後者の代表がApache Flinkで、イベント時間・ウォーターマーク・ステート・exactly-onceを一級の機能として備えた処理エンジンです。2.x系が現行で、2026年6月に2.3.0が公開されています。SparkのStructured Streamingはマイクロバッチ方式で、既存のSparkバッチ資産と分析チームのスキルを流用したい場合の選択肢になります。

Kafkaの設計思想と選定理由はApache Kafkaが選ばれる理由と特徴の解説で、Flinkの実行モデルとユースケースはApache Flinkとはの解説記事で個別に掘り下げています。本記事では2層の組み合わせ方に絞ります。

LambdaアーキテクチャとKappaアーキテクチャの構成差と選択

基盤全体の型としては2つが知られています。Lambdaアーキテクチャは、正確な集計を担うバッチ層と速報値を担うスピード層を並走させ、参照時に統合する二系統構成です。正確さと低遅延を両取りできる一方、同じロジックを2系統で実装・保守する負担が残ります。これに対しKappaアーキテクチャは、Jay Krepsが2014年に提唱した「ストリーム一本化」の型で、過去分の再計算もKafkaのログ再生で賄い、コードを1系統に保つ構成です。処理エンジンの成熟でexactly-onceが実用になった現在は、新規構築ならKappaを既定とし、規制対応などで確定バッチが別途要る場合だけ二系統を検討する順序が実態に合います。二系統構成の詳細はLambdaアーキテクチャとはの解説で整理しています。

イベント駆動アーキテクチャとの関係とメッセージング基盤の位置づけ

ストリーム処理とよく併記されるイベント駆動アーキテクチャ（EDA）は、システム間をイベントの発行・購読で疎結合につなぐ設計様式であり、レイヤーが異なります。EDAが「サービス同士の会話の仕方」を決めるのに対し、ストリーム処理は「流れるイベントから分析結果や派生データを計算する方法」を決めます。両者はKafkaのようなメッセージ基盤を共有することが多く、EDAで流れ始めたイベントをそのままストリーム処理で集計する、という積み重ねが自然な発展形です。マイクロサービス間の連携パターンや採用判断はイベント駆動アーキテクチャとはの実装者向け解説で扱っており、本記事とは「様式」と「計算」で役割を分けています。

Kinesis・Dataflow等マネージドサービスで始める構成の選択肢

KafkaやFlinkのクラスタ自前運用は、ブローカー増設・ステート肥大・バージョン追随の手間が継続的にかかります。小さく始めるならマネージドサービスが現実的です。AWSではKinesis Data Streams（メッセージ基盤）とAmazon Managed Service for Apache Flink（旧Kinesis Data Analytics）、Kafka互換が要るならAmazon MSKという組み合わせになります。Google CloudはDataflowがApache Beamモデルでストリームとバッチを同一コードで実行でき、AzureはEvent Hubs＋Stream Analyticsが同じ役割を担います。判断基準は移植性です。KafkaプロトコルやFlink・Beamのような標準実装に乗っておけばクラウド間の載せ替え余地が残り、独自APIのサービスに深く依存するほど移行コストが積み上がります。

ストリーム処理の採用判断とバッチ処理で済ませるべき場面の見極め

最後に、どの業務をストリーム化すべきかを条件で言い切ります。技術的に可能かではなく、遅延の短縮が金額や損失回避に換算できるかで判断します。

ストリーム処理の採用が見合う要件と業務での具体的なユースケース

採用が見合うのは「結果が数分遅れると損失が確定する」業務です。具体的には、決済の不正検知（承認前の数百ミリ秒〜数秒で判定）、ECの在庫・価格連動（売り越し防止）、インフラやIoT機器の異常検知（障害の波及前に遮断）、広告入札やレコメンドの直近行動反映などが該当します。共通するのは、遅延短縮の価値が「チャージバック額」「機会損失」「復旧時間」といった数字で説明できることです。逆にこの説明ができない段階での導入は、後述の過剰投資になりがちです。ストリーム処理基盤はイベント設計・ステート設計・監視まで含めた基盤構築の色が濃いため、要件の整理から設計・構築までを外部の専門チームと進める選択肢もあります。当社のデータ分析基盤構築・MLOps構築支援では、こうしたリアルタイムデータ基盤の設計・構築を含むデータ基盤の立ち上げを支援しています。

バッチ処理で十分な条件とストリーム化が過剰投資になる場面の線引き

言い切ります。日次レポート、月次決算、機械学習モデルの定期再学習、BIダッシュボードの朝次更新のように「結果の鮮度要件が時間単位より粗い」業務は、バッチ処理で組むべきです。ストリーム化しても得られるのは誰も見ていない時間帯の鮮度だけで、対価としてウォーターマーク設計・ステート運用・24時間稼働の監視体制という固定費を払い続けることになります。中間の要件、たとえば「15分おきに更新されれば足りる」ケースも、まずはマイクロバッチや高頻度バッチで実現できないかを先に検討するのが定石です。ストリーム処理を選ぶのは、秒単位の遅延要件が業務側の数字で正当化できたときだけ——この順序を守るだけで、基盤の複雑さは一段下がります。

導入時につまずきやすい設計・運用の失敗パターンと体制面の回避策

実装段階の典型的な失敗は3つに集約されます。第一に、イベント時間を使わず処理時間で集計してしまい、遅延データの混入で日次の数字がバッチ集計と合わなくなるパターン。突合不能は基盤への信頼を直撃します。第二に、ステートの無限成長です。セッションやキー単位のステートにTTL（保持期限）を設けず、数か月後にチェックポイントが肥大して復旧時間が伸びる事例は頻出します。第三に、exactly-onceを全経路に適用して遅延とスループットが要件を割るケースで、保証水準は出力先ごとに使い分けるのが正解です。体制面では、ストリーム基盤は「作って終わり」でなく、遅延・ラグ・ステートサイズを常時監視する運用が本体です。バッチ運用と同じ感覚で引き継ぐと障害対応が回らないため、設計段階から監視項目とオンコールの持ち方を決めておく必要があります。

ストリーム処理の仕組み・使い分け・導入判断についてよくある質問

検討段階でよく挙がる質問をまとめます。用語の混同と選定の迷いに絞って答えます。

ストリーム処理とバッチ処理はどちらを選ぶべきですか？

遅延要件を金額に換算して決めます。不正検知や在庫連動のように、結果が数分遅れると損失が確定する業務はストリーム処理の出番です。日次・月次の集計やレポートのように翌朝あれば足りる業務はバッチ処理のほうが構築も運用も安く済みます。両者は排他ではなく、同じ基盤で「速報はストリーム、確定値はバッチ」と併用する構成も一般的です。まず全業務の遅延要件を棚卸しし、秒単位が正当化できるものだけをストリーム化する順序が安全です。

ストリーム処理とリアルタイム処理は同じ意味ですか？

厳密には異なります。リアルタイム処理は「遅延が要件内に収まる」という要件側の言葉で、ストリーム処理はデータを流れたまま処理するという実装方式の言葉です。ストリーム処理はリアルタイム処理を実現する代表的な手段ですが、ミリ秒応答を保証する制御系のハードリアルタイムとは別物です。データ基盤の文脈では、ストリーム処理＝秒以下〜数秒の低遅延処理と読み替えてほぼ差し支えありません。

ストリーム処理にはどんなツールが使われますか？

メッセージ基盤と処理エンジンの2層で構成します。基盤側はApache Kafka（4.x系）やAmazon Kinesis Data Streamsがイベントを再生可能なログとして保持し、エンジン側はApache Flink（2.x系）やSpark Structured Streaming、Kafka Streamsが集計・変換を担います。マネージドではAmazon Managed Service for Apache Flink、Google Cloud Dataflow、Azure Stream Analyticsが同じ役割の受け皿です。KafkaプロトコルやBeamのような標準に乗ると、後からの載せ替え余地を残せます。

exactly-onceとは何ですか？なぜ難しいのですか？

障害や再実行があっても、結果が欠落も重複もせず1回だけ反映されたように見える処理保証です。難しいのは、入力の再読み出し・処理途中のステート・出力先への書き込みという3か所の整合を取る必要があるためで、チェックポイント（分散スナップショット）と出力側のトランザクションを組み合わせて実現します。そのぶん遅延とスループットを支払うため、課金や金額集計など重複が事故になる経路に限定し、通知やログ転送はat-least-onceで済ませる使い分けが実務的です。

小規模なシステムでもストリーム処理は必要ですか？

多くの場合は不要です。データ量が小さく、集計結果の利用が日次・週次なら、cronやワークフローエンジンによるバッチ処理で足ります。小規模でもストリームが要るのは、通知の即時性や不正検知のように「遅延そのものが要件」のときだけです。その場合もKafkaクラスタの自前運用から入らず、Kinesis Data StreamsとマネージドFlinkのような従量課金のマネージド構成で小さく始めると、運用負担を抑えたまま要件を満たせます。

関連記事

• イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説：サービス間をイベントで疎結合につなぐ設計様式。本記事の「計算」に対する「様式」側の解説
• Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説：ストリーム基盤のメッセージ層を担うKafkaの設計思想と選定理由
• Apache Flinkとは何か？リアルタイム処理エンジンの特徴・利点とユースケースの概要を詳しく解説：本記事で扱った処理モデルを実装する代表的エンジンの個別解説
• Lambdaアーキテクチャとは何か？バッチ処理とリアルタイム処理を組み合わせたデータ処理基盤の概要を解説：バッチ層とスピード層の二系統構成。Kappaとの比較の前提知識