リアルタイムデータ基盤が「金食い虫」になってしまう原因のほとんどは、実のところ技術選定のミスではなく要件定義のミスです。ビジネス側が本当に欲しかったのは「数分以内のニアリアルタイム」あるいは「1時間ごとの更新」だったにもかかわらず、技術的に面白いという理由でKafkaやFlinkを導入し、結果としてダッシュボードは1日1回しか更新されないのにストリーミング基盤の運用コストだけが膨らみ続ける。Anti-patternシリーズとしてあえて率直に申し上げますが、この構図は責任者個人の判断ミスではなく、要件の曖昧さと技術選定プロセスの不在が生む「構造的な罠」です。本稿ではその構造を言語化し、レイテンシ要件から逆算する設計手法までを一気通貫で解説します。
「リアルタイム」要件の9割は本当はリアルタイムではない
「リアルタイムで見たい」という要望ほど、データ基盤の現場を消耗させる言葉はありません。なぜなら「リアルタイム」という単語は、発話者ごとに想定しているレイテンシが異なるからです。経営層にとっての「リアルタイム」は「月次レポートより早ければ良い」程度を意味することが多く、マーケティング担当者の「リアルタイム」は「翌朝会議までに昨日の数字が見られる」だったりします。一方、エンジニアはこの言葉を聞いた瞬間にミリ秒単位のイベントストリーミングを想像し、KafkaとFlinkのアーキテクチャ図を描き始めます。このギャップこそが、不要なストリーミング基盤を量産する出発点になっています。
要件を具体化すると、業務で本当に求められているレイテンシは「数分以内」「1時間以内」「翌朝まで」のいずれかに収束するケースがほとんどです。ミリ秒単位のストリーミングが本当に必要なのは、後述する不正検知や動的プライシングなど、ごく限られた領域に限ります。まずはレイテンシを数値で定義し、そのうえで適切なアーキテクチャを選ぶというシンプルな手順を、技術選定の前段に置くだけで、金食い虫の大半は未然に防げます。
| 要件レベル | レイテンシ | 適切なアーキテクチャ | ユースケース例 | コスト目安（相対比） |
|---|---|---|---|---|
| 真のリアルタイム | ミリ秒〜数秒 | ストリーミング(Kafka + Flink等) | 不正検知、動的プライシング、IoT異常検知 | 10〜20 |
| ニアリアルタイム | 数秒〜数分 | マイクロバッチ(Spark Structured Streaming等) | 運用モニタリング、在庫更新 | 3〜5 |
| 分〜時間バッチ | 5分〜1時間 | 定時バッチ(Airflow + dbt等) | 業務ダッシュボード、KPIモニタリング | 1.5〜2 |
| 日次バッチ | 翌日 | 日次バッチ | 月次レポート、経営指標集計 | 1 |
この表の右端、コスト目安の数字こそが本稿の主張の核です。日次バッチを「1」とすると、ストリーミングは10〜20倍のコスト構造になります。そしてそのコストの大半は、後述するとおりインフラの常時稼働と運用工数から生まれます。
リアルタイム基盤が金食い虫になる3つのメカニズム
では、なぜリアルタイム基盤は桁違いにコストがかかるのでしょうか。「Kafkaのライセンス料が高いから」「クラウドの従量課金が重いから」といった表層的な理由で語られがちですが、本当の原因は3つのメカニズムに分解できます。順に見ていきます。
インフラコストの常時稼働問題
バッチ処理は原則として必要なときだけ起動します。深夜2時に1時間だけ動かせば終わるなら、それ以外の23時間はコンピュートリソースを落とせます。クラウド環境であればオートスケールや一時クラスタで、さらに安く運用できます。一方でストリーミング基盤は24時間365日稼働が前提です。Kafkaブローカー、Zookeeper、Flinkクラスタ、スキーマレジストリ、モニタリング用のPrometheus――こうしたコンポーネントすべてが常時起動している状態を、定常コストとして支払い続けることになります。単純なインフラ費比較だけでも3〜10倍のレンジに入ることは珍しくありません。
運用の複雑性とエンジニアリングコスト
より深刻なのは人件費です。ストリーミング基盤のデバッグとモニタリングは、バッチとは段違いに難しいのが現実です。データの順序保証、重複排除、exactly-once処理の担保、バックプレッシャー対応、イベント時刻とシステム時刻の扱い分け、チェックポイント管理など、バッチでは考えなくて済む論点が常時付いて回ります。障害が起きたときの復旧も、どの時刻から再処理すべきかをイベント単位で判断する必要があり、ジョブ単位で再実行すれば済むバッチとは世界が違います。こうした専門スキルを持つエンジニアの採用市場は狭く、採用できても年収水準はバッチエンジニアより大幅に高くなる傾向があります。
「リアルタイムなのに使われない」問題
そして最後にして最大の問題が、せっかくリアルタイムで更新しているのに、その先の消費者側が対応していないパターンです。BIダッシュボードは1時間おきにキャッシュを更新する設定のまま、業務アプリは画面更新に手動リロードが必要で、Slack通知も1日1回のサマリーだけ――こうした状況で、データだけがミリ秒単位で流れていても、ビジネス価値は1ミリも生まれません。生まれるのは「リアルタイム処理の請求書」だけです。消費者側の対応コストを含めて見積もらずにリアルタイム化だけ先行すると、この状態に必ず陥ります。
【バッチ処理とリアルタイム処理のコスト構造】
バッチ処理のコスト発生パターン
00:00 ------------ 02:00 ------------ 24:00
[稼働2h] [停止22h]
インフラ費: 稼働時間のみ課金
運用工数: 日次チェックで済む
障害対応: 翌日のリラン対応で多くが解決
リアルタイム処理のコスト発生パターン
00:00 ======================== 24:00
[常時稼働24h/365日]
インフラ費: 常時稼働分を全額負担
運用工数: 24/7監視体制が必須
障害対応: 秒単位の復旧判断が必要
コスト構成比（日次バッチを1とした相対値）
日次バッチ | インフラ1.0 / 運用1.0 / 合計 1.0
時間バッチ | インフラ1.2 / 運用1.5 / 合計 1.7
マイクロバッチ | インフラ2.5 / 運用3.0 / 合計 4.0
ストリーミング | インフラ5.0 / 運用8.0 / 合計12.0
※ 数値は国内中堅EC企業の実プロジェクト平均値を基にした概算本当にリアルタイムが必要なユースケース
ここまで読むと「リアルタイム基盤は全部悪者なのか」と思われるかもしれませんが、そうではありません。リアルタイム処理が本当に価値を生むユースケースは確かに存在します。共通しているのは「数秒の遅延がビジネス上の損失に直結する」という条件です。たとえば金融取引における不正検知では、カード決済のトランザクションが完了する前に異常を判定する必要があります。製造業のIoT異常検知では、設備の振動データに異常が出てから数秒以内に停止しなければ、設備破損や事故につながります。ECの動的プライシングや、航空券の残席連動プライシングも、競合の価格変化に対して数秒〜数十秒で追随する必要があります。
裏を返せば、これら以外のほとんどのダッシュボードやレポーティングは、バッチで十分なのです。ここで「リアルタイムが必要か否か」を判別するためのシンプルな基準を表にまとめておきます。
| 判断軸 | リアルタイムが必要 | バッチで十分 |
|---|---|---|
| 遅延が直接金額損失を生むか | Yes(秒単位で損失) | No（翌日でも問題ない） |
| 意思決定の主体 | 自動化された判定エンジン | 人間（会議・朝会） |
| 消費者側の更新頻度 | アプリが常時購読 | ダッシュボードを手動開閉 |
| 代表ユースケース | 不正検知、異常検知、動的プライシング | KPIレビュー、月次レポート、在庫確認 |
| 許容レイテンシ | 数秒以内 | 数分〜翌日 |
解決策――「レイテンシ要件駆動」のアーキテクチャ設計
構造的問題の処方箋は、技術選定の順序を逆転させることです。「Kafkaを使いたい」「モダンデータスタックで統一したい」といった技術主導の意思決定を一度脇に置き、まずビジネスのレイテンシ要件から設計を逆算します。以下の3ステップを順番に踏むだけで、ストリーミング基盤の過剰投資は大幅に減ります。
Step 1 — ユースケース別のレイテンシ要件を棚卸しする
最初にやるべきは、データ基盤で提供している（あるいは提供予定の）ユースケースを一覧化し、それぞれに「何秒以内にデータが必要か」を数値で記入することです。ここで大事なのは、業務担当者本人に聞くのではなく、業務プロセス自体を観察して決めることです。「早ければ早いほどいい」と答えられても、実際には翌朝の定例会で見るだけならレイテンシ要件は24時間で十分です。棚卸しができると、ストリーミングが必須なユースケースは全体の5〜10%に収まることがほとんどです。
Step 2 — Lambda/Kappaアーキテクチャの使い分け
次に、バッチとストリーミングの組み合わせ方を決めます。Lambdaアーキテクチャは「バッチレイヤ」と「スピードレイヤ」を並行運用する方式で、歴史的に広く使われてきました。これに対してKappaアーキテクチャは「ストリーミングで統一し、再処理もストリームでやる」思想です。どちらが優れているかは議論が尽きませんが、現実的には「バッチ中心＋一部ユースケースのみストリーミング」のLambda寄り構成のほうが運用負荷が低く、コストも抑えやすいケースが多いというのが筆者の見解です。Kappaは一見シンプルに見えますが、全社のデータ処理を1つのストリーミング基盤に寄せるため、障害時の影響範囲が極端に広がるリスクを抱えます。
Step 3 — 段階的にリアルタイム化する
最後に、段階的移行の原則です。初期構築ではすべてバッチで組み、本当にリアルタイムが必要だと証明されたユースケースだけをストリーミング化していきます。この順序を守ると、ストリーミング基盤は「絶対に必要だから導入した」ものになり、コスト正当化の議論が自然に通ります。逆に「最初からリアルタイム基盤を前提に設計し、あとからバッチで代替できるか検討する」という順序は、ほぼ確実に金食い虫を生みます。構築済みのKafkaをわざわざ撤去する判断は、組織心理として極めて取りづらいためです。
【レイテンシ要件駆動のアーキテクチャ選定フロー】
Q1. このユースケースの遅延は金額損失を生むか？
├── Yes → Q2. 許容レイテンシは何秒か？
│ ├── 1秒未満 → ストリーミング(Kafka + Flink)
│ ├── 1秒〜1分 → マイクロバッチ(Structured Streaming)
│ └── 1分以上 → 定時バッチで十分
└── No → Q3. 意思決定は人間か機械か？
├── 機械（自動判定） → Q2へ戻って判定
└── 人間（会議・朝会）→ 定時バッチまたは日次バッチ
└── レイテンシ要件の再確認へ
※ 判定結果は必ず数値（秒）で記録し、要件書にエビデンスを残すコスト比較シミュレーション
ここで、仮想的なシナリオで実際のコスト差を可視化してみます。国内中堅EC企業が「商品レコメンドのためのデータ基盤」を構築するケースを想定し、同じユースケースを3パターンのアーキテクチャで実装した場合の年間コストを比較します。商品閲覧イベントは日次1,000万件、レコメンド更新の要件は「ユーザー行動から商品候補が変わるまで」のレイテンシで定義します。
| 実装パターン | レイテンシ | インフラ費（年） | エンジニアリング工数（初期） | 運用工数（年） | 合計年間コスト | ビジネス価値差分 |
|---|---|---|---|---|---|---|
| 日次バッチ | 翌日 | 約200万円 | 2人月 | 1人月 | 約500万円 | 基準(±0) |
| ニアリアルタイム(15分) | 15分 | 約600万円 | 4人月 | 3人月 | 約1,400万円 | ＋5〜10% |
| リアルタイム(数秒) | 数秒 | 約2,500万円 | 10人月 | 12人月 | 約6,000万円 | ＋7〜12% |
ビジネス価値の差分は、レコメンド精度向上による売上増分の推定値です。ニアリアルタイム化で得られる売上増分と、リアルタイム化で得られる売上増分はそれほど大きく変わりません。一方でコストは4倍以上に跳ね上がります。この数字を見ると、中堅EC企業にとって経済合理的なのは日次バッチかニアリアルタイムであり、リアルタイム化は投資回収が成立しないことがわかります。繰り返しますが、これは技術の優劣の話ではなく、ビジネス要件と実装コストのマッチングの話です。
まとめ――リアルタイムは「手段」であって「目的」ではない
本稿の核心を最後に整理します。
- 「リアルタイム」という言葉は人によって意味が違うため、必ず秒単位で定義する
- ストリーミング基盤はインフラも運用も桁違いにコストがかかる構造であり、バッチの10倍以上を覚悟する必要がある
- 本当にリアルタイムが必要なのは「数秒の遅延が金額損失に直結する」ユースケースに限定される
- 設計はレイテンシ要件駆動で行い、バッチで組んでから段階的にリアルタイム化するのが鉄則
- 構築済みのストリーミング基盤を撤去するのは心理的に極めて難しいため、最初の判断が最重要
リアルタイム基盤の要否判断は、技術選定というより経営判断に近い領域です。DE-STKでは、レイテンシ要件棚卸しから段階的移行ロードマップの策定まで、実プロジェクトのDDとデータ基盤構築の経験をもとに伴走支援を行っています。「Kafkaは入れたが本当に必要だったのか確信がない」という段階でも、現状診断から着手可能ですのでお気軽にご相談ください。
よくある質問
リアルタイムデータ基盤はどのような場合に必要ですか?
「数秒の遅延がビジネス上の損失に直結する」ユースケースに限定されます。具体的には不正検知、IoT異常検知、動的プライシング、リアルタイムパーソナライゼーションなどが代表例です。一方で経営ダッシュボードや業務レポートは、日次〜時間バッチで十分なケースが大半です。判断に迷うときは「意思決定の主体が人間か自動エンジンか」を問うと分岐しやすくなります。
リアルタイムデータ基盤のコストはバッチ処理と比べてどのくらい高いですか?
インフラコストだけでも3〜10倍、エンジニアリング工数と運用工数を含めると5〜20倍になるケースがあります。ストリーミング基盤は24時間365日稼働が前提であり、バッチのように必要な時だけ起動するコスト最適化ができません。さらに障害対応と監視にかかる人件費を加味すると、合計コストは日次バッチの10倍を超えることも珍しくありません。
バッチ処理からリアルタイム処理への移行はどう進めればよいですか?
まず全ユースケースのレイテンシ要件を棚卸しし、本当にリアルタイムが必要なものを特定します。そのうえで該当ユースケースのみストリーミング化し、それ以外はバッチのまま維持するハイブリッドアプローチが推奨です。Lambdaアーキテクチャを前提に、バッチ中心の構成からスタートし、ビジネス価値が立証されたユースケースだけを段階的にストリーミング化するのが失敗しにくい順序です。