Kafka資格の難易度比較：CCDAK/CCAAKの学習時間と難しさ

本稿では、Kafka開発者向けのCCDAKと、管理者向け（本稿では便宜上CCAAKと表記、Confluentの認定ページでは名称が更新される場合あり）の難易度・学習時間を比較します。公式ドキュメントと安定した概念に基づき、受験準備を最短距離に寄せることを狙います。

結論から言えば、アプリ開発経験があるならCCDAKの方が取り付きやすく、運用設計・障害対応の土台があればCCAAKの方が習得は速い傾向です。未経験からの受験は、CCDAKで60〜90時間、CCAAKで80〜120時間を見込むと無理がありません（実務の有無で前後します）。

CCDAK/CCAAKの全体像と前提

CCDAKは、プロデューサ／コンシューマ、パーティションとオフセット、デリバリセマンティクス（at-least-once/at-most-once/exactly-once）、スキーマ管理、Kafka StreamsやKafka Connectの基本的な使い所と設計判断を問います。コードや設定の正誤だけでなく、運用に耐えるアプリ設計が重視されます。

CCAAK（管理者試験に相当）は、ブローカー/クラスター設計、レプリケーション、リーダー選出、セキュリティ（SASL/SSL、ACL）、スロットリングやクォータ、監視/メトリクス、パーティション再割当、ローリングアップグレード、障害時の復旧方針など、現場運用の意思決定を中心に問います。

注意点として、認定名称・配点は改定されることがあります。最新の出題範囲とポリシーはConfluentの認定ページとApache Kafka公式ドキュメントで必ず確認してください。

• 共通基盤：トピック/パーティション/レプリカ、ISR、レコード順序性、ブローカー設定の主要キー
• 開発者寄り（CCDAK）：クライアント設定、シリアライゼーション、EOS/トランザクション、Streams/Connectの設計判断
• 管理者寄り（CCAAK）：容量計画、信頼性パラメータ（replication.factor、min.insync.replicas、acks）、セキュリティ、運用オペ

難易度と学習時間の比較（実務スキル別）

同じKafkaでも、求められる思考回路が異なるため、難易度の感じ方はバックグラウンドで大きく変わります。以下は受験者の典型プロファイル別に、学習時間と難しさの肌感を整理したものです（学習時間は目安、ハンズオンを含む）。

「開発経験豊富・運用未経験」ならCCDAK先行、「SRE/運用豊富・アプリ未経験」ならCCAAK先行が一般的に効率的です。両方を同時に進める場合も、最初の2週間は片方に寄せて基礎を固めるのが無難です。

• 未経験からの短期集中は、模擬問題の反復だけでは定着しにくい。必ず小規模クラスター（ローカルやコンテナ）で挙動を確認する。
• 学習は「概念→設定→メトリクス→失敗パターン→設計判断」の順で回すと、試験/実務の双方で効く。

出題ドメインと問われ方（安定トピックに絞る）

安定して問われるコアは、Kafkaの耐障害化モデルとクライアント挙動です。バージョン影響が大きい細部（細かなデフォルト値など）に依存せず、原理原則に立ち返ると得点が安定します。

ドメインごとに、試験での“ひっかけ”を想定して読むと効果的です。

• トピック設計：パーティション数とキーの分布、順序性とのトレードオフ、再パーティション時の影響
• レプリケーション：ISR、リーダー選出、unclean.leader.electionの是非
• デリバリ保証：acks、idempotence、transactions、min.insync.replicasの相互作用
• シリアライゼーションとSchema：互換性モード（後方/前方/双方向）と進化戦略
• Kafka Streams：状態管理、再処理、タイムセマンティクス（event-time/processing-time）の違い
• Kafka Connect：ソース/シンクのエラーハンドリング、再試行、Exactly-onceが成立する/しない境界

学習ロードマップ（3〜6週間プランと実践順序）

短期で効かせるには、観察できる現象から概念を腹落ちさせる順序が有効です。以下のロードマップは、CCDAK/CCAAKどちらにも通用する“共通の芯”を先に固め、その後に試験固有領域へ寄せる構成です。

週あたり10〜15時間捻出できるなら3週間でCCDAK合格圏、6週間でCCAAK合格圏に届く計画が現実的です（未経験は+2週間見積もり）。

• Day 1〜3：ローカル/コンテナでシングル→3ブローカーへ拡張。プロデュース/コンシュームを体験。
• Day 4〜7：acks/min.insync.replicas/replication.factorを動かして可用性と損失の関係を観察。
• Week 2：Schema互換性、Streamsの再処理、Connectのリトライ/デッドレタ設計。
• Week 3：セキュリティ（SASL/SSL/ACL）と監視。障害シナリオの手順化。
• Week 4〜6（CCAAK寄せ）：再割当、ローリング更新、容量計画の定量化とSLO設計。

学習フェーズと試験対応マップ

Phase 0   Phase 1            Phase 2                    Phase 3                    Phase 4
Bootstrap -> Core broker -----> Reliability knobs -------> Dev/Streams/Connect ------> Security/Monitoring
              (topics, ISR)      (acks, minISR, RF)         (CCDAK寄り)                (CCAAK寄り)
                 |--------------------- 共通知識（両試験の得点土台） ----------------------|

実務タスクへの対応づけと落とし穴（頻出）

試験は“設定の丸暗記”ではなく“因果の説明”を要求します。以下は、誤答が生まれやすい代表パターンです。各項目はハンズオンで実際に確認しておくと定着が早いです。

特に、可用性とデータ損失のトレードオフに関わるパラメータ（acks、min.insync.replicas、replication.factor）は、単独ではなく組み合わせと障害シナリオで評価する癖をつけると良いです。

• acks=allでもmin.insync.replicasが1なら、リーダー単独でACKしてしまい障害時に損失が起こり得る。
• unclean.leader.election.enable=trueは可用性を上げるが一貫性を犠牲にしやすい。試験では“最後の手段”として扱われる。
• パーティション増加は順序性を壊し得る。キー設計と同時に議論する。
• StreamsのEOSは“プロデューサ設定だけ”では完結しない。トランザクション境界と状態管理が伴って初めて効果が出る。

よく出る運用コマンド例（安全策の基本）

# min.insync.replicas をトピック単位で設定（RF=3のとき一般に2を推奨）
$ kafka-configs.sh --alter --topic orders --add-config min.insync.replicas=2 --bootstrap-server localhost:9092

# パーティション再割当（計画ファイルを指定、ローリングに注意）
$ kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file plan.json --execute

試験テクニックと当日の注意

シナリオ問題では、与件の“制約条件”を先にマークします。可用性優先か一貫性優先か、RPO/RTOの許容値、運用体制（24/7か）などで正解が変わります。

数問は“絶対に違う選択肢”を先に除外できます。特に、unclean leader electionの無批判な有効化、acks=1の乱用、RFの無計画な削減などは誤答の典型です。

• 時間配分：わからない問題はマーキングして後回し。因果チェーンを紙に1行で書くと選択肢が絞れる。
• 用語の読み替え："at least once"＝重複はあり得る、"exactly once"＝重複/欠落なし（前提条件に注意）。
• 最後の見直し：パラメータの組み合わせ（acks/minISR/RF）に内在する前提（ISRが十分か、フェイル時の経路）は矛盾していないかを確認。

問題で確認

よくある質問