本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第6弾として、ストリーミング処理について解説する記事です。
「リアルタイム」要件を問い直すと9割は「5分遅延バッチで十分」に落ち着きます。本記事ではストリーミング基盤の選定（Kafka／Kinesis／Pub/Sub／Flink）・Exactly-Once・ウィンドウ処理を解説し、本当にリアルタイムが必要かをまず疑うという実務の鉄則を示します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- 「本当にリアルタイムが必要か」をまず疑う（9割は日次 / マイクロバッチで足りる）
- 必要ならマネージド（Kinesis / Pub/Sub）を最優先する
- スキーマを明示する（Protobuf / Avro+Schema Registry、JSONフリーダム禁止）
- 消費者側を冪等に設計する（Exactly-Onceは盾、冪等は矛）
この記事を読む前に
本記事はデータベース周りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「データベースの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもストリーミング処理とは何か
ストリーミング処理とは、ざっくり言えば「データが発生した瞬間にリアルタイムで処理し続ける仕組み」です。
回転寿司のレーンを想像してください。バッチ処理は「注文を溜めて、まとめてキッチンに出す」方式。ストリーミング処理は「注文が入った瞬間にレーンに流し、客の前を通過する」方式です。不正検知・株価更新・IoTセンサーなど「数秒の遅れが許されない」場面で使われますが、バッチの10倍の運用コストがかかるため、本当に必要な時だけ選ぶのが鉄則です。
なぜストリーミング処理が必要なのか
不正検知・在庫連動・広告入札・IoT制御のように、イベント発生から判断まで秒以下が業務価値に直結する場面があります。また24時間365日稼働のグローバル業務では夜間バッチの時間が取れず、マイクロサービス構成ではイベントで繋ぐストリーミング基盤がサービス間通信の中枢神経として機能します。
| バッチ処理 | ストリーミング処理 | |
|---|---|---|
| 処理単位 | まとまったデータ | 1イベント〜少数 |
| 遅延 | 数時間〜日単位 | ミリ秒〜秒単位 |
| 実装・運用 | 比較的簡単・安い | 難しい・重い・高い |
| 代表技術 | Spark・dbt | Kafka・Flink |
ただし多くの業務要件はバッチで十分で、「リアルタイムっぽく見える」程度なら15分マイクロバッチで代用できることも多いです。
主要な構成要素
ストリーミング基盤は「イベントを運ぶ層」（メッセージキュー）と「イベントを処理する層」（処理エンジン）に分かれ、別々に選定します。
メッセージキュー ― まずはマネージド
Apache Kafkaはストリーミング基盤の事実上の標準で、毎秒数百万イベントを捌ける性能とエコシステムを持ちますが、代償として運用負荷が極めて重い。KRaft管理・パーティション設計・コンシューマーグループの調整など、専属の運用チームがいないと本格利用は困難です。少人数チームは、運用をクラウド側が担うマネージドキュー──AWSならKinesis、GCPならPub/Sub、AzureならEvent Hubs（またはConfluent Cloud）──を最優先します。「まずはマネージド、スループット上限で困ったらKafkaへ」が現代の定石です。
処理エンジン ― 規模に応じてSQLから
Apache Flinkはステートフルなストリーム処理の本命で、複雑な集計・結合をミリ秒レイテンシで実行しExactly-Once保証も堅牢ですが、運用難度はKafka以上です。「Kafka+SQLで済む規模」ならksqlDB（KafkaをSQLで扱える）が学習コスト桁違いに低く最短ルートで、複雑化したらFlinkへ移行します。GCPならPub/Sub+Dataflow、AWSならKinesis+Lambdaの組み合わせがマネージドで手軽です。
Exactly-Onceとウィンドウ処理 ― ストリーミング特有の難しさ
ストリーミングで最も厄介なのが「メッセージを1回だけ処理する保証」（Exactly-Once）です。ネットワーク障害・再起動で重複処理や欠損が簡単に起き、決済・在庫反映では重複が致命的です。KafkaやFlinkはExactly-Onceをサポートしますが、エンドツーエンドの保証には消費者側の冪等設計（同じ入力で同じ結果）が必須です。Exactly-Onceは盾、冪等は矛、両方揃って初めて安全です。
もう一つの設計論点がウィンドウ処理です。「直近5分の売上」のような時間区切りの集計は、終わりの無いストリームでは「どこで区切るか」（Tumbling / Sliding / Session）の設計が必要で、さらにイベント時刻（発生時刻）と処理時刻（到着時刻）の区別、遅れて来たイベントの扱いも決めなければなりません。
どう選べばいいのか ― 鮮度要件を数値で分解する
「リアルタイム」と言われたら、まず数値で分解するのが実務です。
※ 2026年4月時点の業界相場値です。
| 鮮度要件 | 採用技術 | 必要SRE人員 |
|---|---|---|
| 日次〜数時間遅れOK | バッチ（dbt） | 0人（兼任） |
| 5〜15分遅れOK | マイクロバッチ（15分dbt） | 0人 |
| 1分〜数秒遅れ | 軽量ストリーミング（Pub/Sub+Lambda） | 1人 |
| 100ms以下必須 | 本格ストリーミング（Kafka+Flink） | 2〜3人専属 |
100ms以下が本当に必要な業務は、決済・不正検知・広告入札・IoT制御・取引所など限定的です。そして「本格ストリーミング採用の実質下限は専属SRE 2人以上」これ未満で採用すると、24/7の障害対応・ウィンドウ設計・Exactly-Onceの運用で現場が溶けます。業務要件の9割は日次バッチかマイクロバッチで足りる、というのが経験則です。
3つのシナリオで考える
個人開発・スタートアップの場合
この規模では、ストリーミングは持たないのが正解だと思います。日次バッチ（dbt）か、必要になったとしても15分サイクルのマイクロバッチで十分ですし、それなら専任SREが0人のままでも回せてしまいます。「リアルタイムっぽい体験」が欲しいだけであれば、ポーリング間隔の短縮で大半は実現できてしまうのです。
中小SaaSの場合
1分〜数秒遅れの要件が本当に出てきたら、Pub/SubやKinesisにLambdaを組み合わせた軽量ストリーミングから始めるのが良いでしょう。マネージドに寄せておけばSRE 1人で維持できますので、この段階でKafkaの自前運用に踏み込む必要はありません。
大企業の場合
決済・不正検知・広告入札のような100ms以下が必須の業務になって、初めてKafkaとFlinkによる本格ストリーミングが正当化されます。とは言っても、専属SRE 2〜3人と24/7体制、Exactly-Once設計が前提装備となりますので、これを用意できないのであれば要件の方を見直すべきだと私は考えています。
AI判断軸 ― マネージド+スキーマ駆動がAIに優しい
マネージドストリーミングはAIの学習データが豊富
KinesisやPub/Subは公式ドキュメントとサンプルが充実しているため、AIが設定コード（Terraform）やProducer / Consumerコードを正確に生成できます。自社運用のKafkaクラスタはプロジェクト固有の設定が多く、AIの汎用知識だけでは正確に扱えないケースがあります。
スキーマ駆動のイベント設計がAI生成精度を上げる
Avro / ProtobufでイベントスキーマをSchema Registryに登録していれば、AIは「このイベントのどのフィールドが使えるか」を正確に把握してConsumerコードを生成できます。スキーマなしの自由なJSONでは、イベント構造をAIに毎回教える必要があり、消費者が壊れ続ける原因にもなります。
やってはいけないこと
データ欠損・二重処理・サービス全停止に直結する典型を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 「顧客がリアルタイム欲しい」で即ストリーミング採用 | 実際は30分遅れでOKなことが多い → 要件を数値でヒアリングする |
| 冪等性なしのAt-Least-Once運用 | 二重決済・二重在庫減算が起きる → 消費者側を冪等に設計する |
| Kafkaを専属SREなしで自社運用 | パーティション設計・障害対応で現場が溶ける → マネージドにする |
| スキーマ定義なし（JSONフリーダム）でKafka運用 | 消費者が壊れ続ける → Protobuf / Avro+Schema Registryを必須にする |
| DLQ（Dead Letter Queue）なしで運用 | 処理失敗メッセージが永遠にリトライして詰まる → DLQを最初から用意する |
| イベント時刻と処理時刻を区別しない | 遅延到着イベントで集計が狂う → ウィンドウ設計を厳密にする |
2020年11月のAWS Kinesis大規模障害（us-east-1で長時間停止し、CloudWatch・Cognito等が連鎖的に影響）は、ストリーミング基盤に依存した瞬間、その障害が全業務を止めることを示した教訓です。リアルタイム基盤は便利な道具であると同時に、新しい単一障害点になり得ます。
筆者メモ ― 「リアルタイムが欲しい」の本当の意味
ある案件では、顧客から「リアルタイムダッシュボードが欲しい」と言われてKafka+Flinkの構成を3ヶ月かけて組んだものの、後でヒアリングし直すと実際の業務要件は「30分以内の遅れなら問題ない」だった、という話がよく聞かれます。cronの15分スケジュールで十分だった案件で、その後1年は深夜の障害対応に追われた、というオチまでがセットで語られる典型事例です。
顧客から「リアルタイムで数字を見たい」と言われた時に、最初に「数秒遅れなら困りますか？5分ならどうですか？」と問い直す──このクセが過剰投資を防ぎます。5分遅れと100ms遅れでは世界が違います。マイクロバッチで済むなら、それが一番安全で安いのが実務の結論です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 本当にリアルタイムが必要か（要件の数値分解）
- メッセージキュー（Kafka / Kinesis / Pub/Sub）
- 処理エンジン（Flink / ksqlDB / 不要）
- 保証レベル（At-Least-Once / Exactly-Once）と冪等設計
- スキーマ管理（Avro・Protobuf+Schema Registry）
- 監視・アラート（コンシューマーラグの常時監視）
この記事に関連する記事
まとめ
本記事はストリーミング処理について、基盤の選定・Exactly-Onceとウィンドウ処理・鮮度要件×運用コストの段階表まで含めて解説しました。如何だったでしょうか。
本当にリアルタイムが必要か問い、マネージドを最優先し、スキーマを明示し、消費者側を冪等に設計する。これが2026年のストリーミング処理の現実解です。
次回はデータガバナンス（マスタ管理・カタログ・規制対応）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Apache Kafka も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（50/95）