Geminiに相談しながらプロンプトを作ったのでこちらに。
スライド生成できたら都度アップデートします。
# Role & Context
あなたは世界トップレベルのデータアーキテクト兼教育者です。
Flink SQL開発チームのマネージャーである私の思考パートナーとして、社会人3年目程度の新規プロジェクト参画者に向けた「Flink SQL / Confluent / Splunk O11y」の教育資料（全60スライド）を作成してください。
# Technology Stack
- Confluent (Apache Kafka / Apache Flink)
- Flink SQL (Tumbling/Sliding Window, State, JOIN)
- OpenTelemetry (OTel): Context propagation using Kafka Headers
- Splunk Observability Cloud (APM, Service Map, Infrastructure Monitoring, Log Observer)
# Core Concepts to Preserve (The "Yasuda Approach")
1. トリアージ基盤: Confluentを単なる運び屋ではなく、データの重要度や行き先を瞬時に判断する司令塔として定義。
2. 付箋（Header）の比喩: OTelのTrace IDをKafkaヘッダーに貼る「付箋」に例え、Flinkが加工中もその付箋を貼り直してトレーサビリティを維持する仕組みを解説。
3. トピック階層: In-topic（生データ）、中間topic（下ごしらえ済み）、Out-topic（完成品）の3層構造。
4. 設計のコツ: リソース最適化のための「ジョブ集約」と、障害影響を抑えるための「ジョブ分離」のトレードオフ判断。
# Detailed Curriculum (Roadmap)
この6部構成（各10スライド）に沿って作成を進めます。
第1部：データストリーミングと可観測性の世界 〜現代の「動脈」と「診断装置」〜
1. ガイダンス：本コースの目的とゴール
2. なぜ今「リアルタイム」なのか？（バッチの限界）
3. 3大要素の全体図：Confluent(Kafka)・Flink・Splunk O11y
4. メッセージングモデルの基礎：Pub/Subとデータ流路
5. データの「鮮度」と「価値」：なぜ遅延が問題なのか
6. 障害対応のパラダイムシフト：監視（Monitoring）から可観測性（o11y）へ
7. Splunk O11yの概要：インフラ、APM、ログを1つに繋ぐ力
8. ユースケース：不正検知における「検知」と「分析」のスピード感
9. 開発環境のデモ：ConfluentとSplunkのダッシュボードを眺める
10. 第1部のまとめ：信頼されるリアルタイム基盤の全体像
第2部：KafkaとOpenTelemetry 〜「付箋」が繋ぐトレースの旅路〜
1. Kafka物理構造：トピック・パーティション・レプリカ
2. メッセージの中身：Key, Value, Headerの三層構造
3. OTelの基礎：TraceIDとSpanContextの概念
4. Headerによるバトンパス：Kafkaを経由したトレース情報の伝播
5. スキーマ管理：Schema Registryによるデータの一貫性確保
6. プロデューサー設計：Splunk APMで送信側のレイテンシを見る
7. コンシューマー設計：コンシューマーグループとリバランスの挙動
8. Kafkaメトリクスの重要性：メッセージの滞留（Lag）をどう検知するか
9. データの保存と圧縮：Compactトピックの使い道
10. 第2部のまとめ：OTel付箋を落とさないKafka設計
第3部：Flink SQL 基礎 〜動くデータに対するSQLと時間の管理〜
1. Flink SQL 構文基礎：標準SQLとの違い
2. ストリーム処理の「時間」：Event Time vs Processing Time
3. ウォーターマーク：遅れて届くデータへの「待機」設定
4. ウィンドウ関数①：Tumbling（固定）とSliding（重なり）
5. ウィンドウ関数②：SessionとCumulative（累積）
6. 状態管理（State）：Flinkが「過去」を覚えている仕組み
7. 結合（JOIN）：Stream-Stream JOIN の難しさと対策
8. Lookup JOIN：外部DB参照とキャッシュ戦略
9. Flinkのパフォーマンス監視：Splunk O11yで見るジョブの健康状態
10. 第3部のまとめ：正しい結果を、正しい時間内に出すクエリ
第4部：トリアージ基盤の実践設計 〜効率的なパイプライン構築〜
1. トリアージの極意：仕分け（Route）と加工（Transform）
2. パイプライン構成：In / Intermediate / Out トピックの役割
3. データのクレンジング：汚い生データを「資産」に変える工程
4. 複数出力（Multi-sink）設計：1つのデータを複数の用途へ
5. Splunk Service Mapへの反映：トピック間の繋がりを可視化する
6. 中間トピックの戦略的活用：再利用性とデバッグ効率の向上
7. 冪等性の設計：障害復旧時に「二重計算」を防ぐ方法
8. スキーマ進化：ビジネスの変化に合わせてデータを育てる
9. 実践演習：Syslogトリアージ・パイプラインの構成図作成
10. 第4部のまとめ：迷子を出さないトリアージの地図設計
第5部：Splunk O11y による徹底解剖 〜犯人探しのプロフェッショナル〜
1. Splunk APM入門：分散トレースでFlinkジョブの中を覗く
2. Infrastructure Monitoring：CPU/メモリとFlinkリソースの関係
3. Log Observer：ログから「なぜ」を瞬時に特定する
4. Service Mapの読み方：ボトルネックになっているコンポーネントの特定
5. バックプレッシャーの検知：データが詰まった時のSplunkでの見え方
6. カスタムタグの活用：ビジネス指標（注文ID、ユーザーランク）での分析
7. Detector（アラート）設計：静的なしきい値と動的な異常検知
8. ダッシュボードの構築：マネージャーが見るべき指標、現場が見るべき指標
9. トラブルシューティング演習：Splunkを使ってバグを特定する
10. 第5部のまとめ：可視化されないデータは「存在しない」と同じ
第6部：運用・コスト・チーム開発 〜プロとしての持続可能な開発〜
1. リソースサイジング：CFU（Compute Unit）の最適な見積もり
2. ジョブ集約の損得勘定：コスト削減 vs 障害リスク
3. ステートフルデプロイ：データを失わずにジョブを更新する手順
4. CI/CDパイプライン：SQLのテスト自動化とSplunkでのリリース監視
5. セキュリティ：認証・認可と個人情報（PII）のマスク処理
6. 運用自動化：オートスケーリングとリカバリ戦略
7. コスト最適化：不要なトレース・ログ・トピックを削る技術
8. チーム開発のルール：命名規則、ドキュメント、Git管理
9. トラブル事例集：過去の大きな失敗から学ぶ
10. 全編の総括：ビジネスを支えるリアルタイムエンジニアへの道
# Output Requirements
- 各パートごとに10枚ずつのスライドを作成する。
- スライドは、モダンでプロフェッショナルな「HTML/CSSベース」のビジュアル資料（1280x720）として出力すること。
- 日本語で作成し、新規参画者がワクワクするような「具体的な比喩」を多用すること。
- 1つずつパートを作成し、都度私の確認を受けること。
- すべてのスライドの下部にトークスクリプトをつけること
Important: Output Format & Exporting Rules
- ユーザーが容易にエクスポート（ダウンロード）して利用できるように、以下の出力形式を厳守してください。
- ファイル生成: HTML/CSSコードは、指定のコードブロックタグ（Titleとfilepathを含むもの）で開始すること。
- 自己完結型: 全てのCSSとJavaScriptを1つのHTMLファイルに含めること。
- ビジュアル: 1280x720のサイズを前提としたモダンなデザインにすること。日本語で具体的な比喩を多用すること。
- 逐次作成: 1部（10枚）ずつ作成し、ユーザーの確認を受けてから次に進むこと。
まずは、「第1部」のスライド10枚を、上記の構成項目1〜10を網羅して作成してください。