Lambda Architecture vs Kappa Architecture――どちらを選ぶべきか徹底解説

Lambda ArchitectureとKappa Architectureはストリーム+バッチ統合の代表的アーキテクチャです。本記事では両者の構成・特徴・選定基準に加え、現代のレイクハウスによる「両方の課題解決」についても解説します。結論を先に述べると、2026年時点で純粋なLambdaやKappaを選ぶ機会は減り、Delta Lake / IcebergベースのレイクハウスがLambdaの課題を解決しつつ、要件次第でKappa的な構成も実現する形が主流です。

Lambda Architectureとは

Lambda Architectureは、2011年にNathan Marz氏が提唱したビッグデータ処理アーキテクチャです。バッチ層（Batch Layer）、スピード層（Speed Layer）、サービング層（Serving Layer）の3層で構成され、バッチでの正確性とストリームでのリアルタイム性を両立させる狙いがあります。

全体構成を図解します。

【Lambda Architecture構成図】

  [Source Events]
         |
  +------+------+
  v             v
[Batch Layer]  [Speed Layer]
  HDFS/S3       Kafka + Storm/Flink
  Spark / MR    逐次処理で最新を反映
  正確な結果
  を計算
  |             |
  v             v
  +------+------+
         |
         v
  [Serving Layer]
  HBase / Cassandra / DWH
  両方の結果をマージしてクエリ応答

※ バッチとスピードで同じロジックを二重実装するのが最大の課題

Kappa Architectureとは

Kappa ArchitectureはLambdaの課題（ロジック二重実装）を解消するべく、2014年にLinkedInのJay Kreps氏が提唱しました。バッチ層を廃止し、ストリーム処理のみですべてを賄う設計思想です。データの再処理は「ストリームを再生する」ことで実現します。

【Kappa Architecture構成図】

  [Source Events]
         |
         v
  [Immutable Log]
  Kafka / Kinesis
  すべてのイベントを保持
         |
         v
  [Stream Processor]
  Flink / Spark Streaming
  逐次処理
         |
         v
  [Serving Store]
  DWH / Cassandra / Elasticsearch

※ 再処理が必要な場合はKafkaのログをリプレイする
※ バッチ層を持たないため二重実装問題が解消される

徹底比較

両者の特徴を並べた比較表です。複雑さとコストの両方でKappaのほうが単純に見えますが、実際には状態管理や再処理の難度が上がります。

観点	Lambda Architecture	Kappa Architecture
構成	バッチ + スピード + サービング	ストリームのみ + サービング
複雑さ	高い（2系統を管理）	中（1系統だが状態管理が複雑）
整合性	バッチで保証	ストリーム処理の精度に依存
レイテンシ	バッチは遅い / ストリームは速い	全体的に低レイテンシ
コスト	中〜高（2系統分）	中〜高（24/365稼働）
運用負荷	高い	中〜高
ロジック重複	あり（課題）	なし
再処理	バッチで簡単	ストリームを再生
向くユースケース	過去にHadoop資産あり	Kafka中心でストリームが主

現代における選択肢

2026年の実務で、純粋なLambdaやKappaを選ぶ機会は減っています。その代わりに、Delta LakeやApache Icebergといったオープンテーブルフォーマットを用いたレイクハウスが、両方の課題を解決する選択肢として主流になっています。これらのフォーマットはACIDトランザクションとスキーマ進化を備え、同じテーブルに対してバッチとストリームの両方から読み書きできるため、事実上「統合アーキテクチャ」として機能します。

観点	伝統的Lambda	レイクハウス統合型
バッチ・ストリーム統合	2系統で二重実装	同じテーブルに両方から書き込み可
整合性	マージ処理で担保	ACIDトランザクションで担保
ツール	Hadoop + Storm + HBase	Delta Lake / Iceberg + Spark / Flink
運用負荷	高い	中
再処理	バッチを再実行	Time Travelで過去時点を参照
ロジック共有	難しい	dbt / Spark SQLで共通化可能

選定フローチャート

現代の選定フローをシンプルなツリーで示します。多くのケースでレイクハウスが第一候補となることが分かるはずです。

【選定フローチャート】

Q1. リアルタイム性が本当に必要か？
├── No  → バッチのみ（Airflow + dbt）で十分
└── Yes → Q2. バッチの再処理要件はあるか？
             ├── Yes → レイクハウス（Delta Lake / Iceberg）推奨
             │         └ バッチ・ストリーム統合が可能
             └── No  → Q3. ソースは完全にイベント駆動か？
                          ├── Yes → Kappa Architecture（Kafka + Flink）
                          └── No  → レイクハウスに戻る

実装例

Spark Structured Streamingを使ったバッチ＋ストリーム統合の簡易例です。Delta Lake上で同一テーブルをストリームから書き込みつつ、バッチからも集計クエリで読み出せます。

from pyspark.sql.functions import current_timestamp

stream = (spark.readStream.format("kafka")
    .option("kafka.bootstrap.servers", "kafka:9092")
    .option("subscribe", "events").load())

query = (stream.selectExpr("CAST(value AS STRING) AS json", "timestamp")
    .withColumn("ingested_at", current_timestamp())
    .writeStream.format("delta")
    .option("checkpointLocation", "/chk/events")
    .outputMode("append")
    .start("/delta/events"))

まとめ

Lambda / Kappaは歴史的には重要ですが、2026年の実務ではレイクハウスによる統合アプローチが圧倒的に現実的です。「ストリーム+バッチを統合したい」と感じたら、まずDelta LakeやIcebergを検討するのが正攻法となっています。アーキテクチャ名に拘るより、課題を解決する手段を選ぶ柔軟性が大切です。

よくある質問

Lambda Architectureの問題点は何ですか？

バッチ層とスピード層で同じロジックを二重実装する必要があり、開発・運用コストが増大します。レイクハウスの登場でこの課題は緩和されています。現代的には純粋なLambdaをあえて採用する合理性は薄れつつあります。

Kappa Architectureは実用的ですか？

ストリーム処理基盤（Kafka + Flink等）が成熟した現在では実用的です。ただし全データをストリームで処理するコストと複雑さは考慮が必要です。過去の大規模な再集計をストリームで回すのは負荷が高くなりがちです。

2026年時点でどちらを選ぶべきですか？

多くの場合、Delta Lake / Icebergを使ったレイクハウスが両方のアーキテクチャの課題を解決します。純粋なLambda / Kappaよりも統合アプローチが推奨されます。要件のリアルタイム度と再処理要件から逆算して構成を決めてください。