🦔

分析パイプライン構築（3）　〜メトリクス設計とモニタリングの現実

に公開
AWS
データ分析
Glue
モニタリング
実務
tech

分析パイプライン構築（3） 〜メトリクス設計とモニタリングの現実

この連載では、実務でデータ分析基盤を立ち上げる中で、
「どのようにして分析パイプラインを構築してきたか」を、
実際の試行錯誤を交えて書いています。

筆者は、プロダクトのログを扱いながら、
分析・データ基盤の整備を行っている実務担当者です。

前回は、日々更新されるデータを対象に、
運用コストと品質のバランスを取りながら分析パイプラインを構築しました。

今回はその続きとして、
メトリクスの設計とモニタリングについて書きます。

パイプラインは作って終わりではありません。
回り続けていること、
そしてビジネスに価値を出していることを確認する必要があります。

1. まず整理すること

メトリクス設計で最初に考えたのは次の4点です。

  • 誰が見るのか
  • 何のために見るのか
  • どの頻度で見るのか
  • どうやって確認するのか

いきなり指標を並べるのではなく、
ヒヤリングから始めました。

2. ヒヤリング結果

営業・ビジネス側

  • DAUなどを週1回の定例で報告したい（ダッシュボード）
  • インシデントに直結する情報は毎日確認したい（アラート）
  • 施策の反応を翌日から追いたい（ダッシュボード）

エンジニア側

  • FW更新後に問題がないか確認したい（ダッシュボード）
  • パイプラインが正常に動いているか知りたい（アラート）

要求は多様ですが、整理できます。

3. 要求の分類

軸は2つです。

頻度

  • 日次
  • 週次
  • 月次

種別

  • ビジネス（Growth / Engagement）
  • 品質（Quality）
  • パフォーマンス（Performance）

ここで重要なのは、

一般的に良い指標ではなく、
今回のビジネスに意味がある指標か？

という視点です。

4. 日次モニタリング

このIoTプロダクトはスタンドアローンで動作するため、
ビジネス指標の日次モニタリングは優先度が高くありません。

利用データはリアルタイムにクラウドへ送られるわけではなく、
スマホ接続時にまとめてアップロードされます。

そのため、

  • 昨日のDAUが減った
  • 今日の利用時間が少ない

といった変動は、必ずしも実利用の変化を意味しません。

ビジネス側は週次で確認する運用とすることで合意しました。

一方で、エラー系の監視は日次で実施します。

理由は明確です。

  • 問題が起きたユーザーはスマホ接続を試みる可能性が高い
  • 異常ログは早期に検知するほど影響を小さくできる
  • パイプライン障害は即時対応が必要

ビジネスの変動は多少遅れても致命的ではありません。

しかし、
品質問題やシステムエラーは即座に検知すべき対象です。

日次モニタリングの主目的は、
成長確認ではなく品質保証です。

日次で見るもの

Data Quality

  • Log Volume（前週同曜日比）
  • Outlier Ratio（前日比）
  • アノマリーカウント
  • 異常ファイルの種別と数
  • 異常レコードの種別と数
  • 遅延到達レコード数

Performance

  • Glue実行時間

※日次は「ユーザーの動向を見る場」ではなく、
異常を監視するための場にしました。

5. 週次モニタリング

一方、週次のモニタリングはビジネス側の意向を反映させています。
こちらでユーザーの動向を確認します。

目的

  • 曜日ノイズを均した傾向把握
  • 定着度確認

比較

  • 前週比（WoW）

Growth

  • WAU

    • 週間ユニーク利用者数

  • Retention Rate

    • 初回利用週を基準に残存率を見る

  • Usage Frequency

    • Light user / Medium user / Heavy user 構成比

※アクティブ定義：「主要機能を5分以上使用」

Engagement

  • Avg Duration / User
    • 前週比のみ

6. 月次モニタリング

目的

  • 長期成長管理
  • マクロトレンド把握

比較

  • 前月比（MoM）

Growth

  • MAU

    • 機種別・FW別に確認

  • Churn Rate

    • 月単位で評価

  • Device Breakdown

    • 機種構成比の変化

7. 実装方針

メトリクスは、データセットに対してその都度クエリを実行して取得することもできます。

しかし今回は、日々実行されるパイプラインの中で同時に集計し、保存する方式を採用しました。

理由はシンプルです。

1. コスト効率

毎回Athenaで過去データを含めてクエリを実行すると、

  • スキャンデータ量が増える
  • 実行時間が伸びる
  • コストが増加する

日次・週次・月次のトレンドを見る場合、
都度フルスキャンする設計は不利です。

パイプライン実行時に集計して保存しておけば、
参照時のクエリは軽量になります。

2. パイプライン内部でしか取得できない情報がある

例えば、

  • 不正ファイル数
  • 破損レコード数
  • 除外理由別カウント

これらは正規化後のデータセットには存在しません。

元データをクエリすれば取得できますが、
時系列トレンドを追う場合は過去分も毎回スキャンする必要があります。

これは実行時間・コストの両面で効率的ではありません。

結論

時系列で変化点を見たい情報は、
処理の途中で取得し、そのまま保持する。

メトリクスは「後から計算するもの」ではなく、
パイプラインの副産物として生成するものと考えています。

実装方針まとめ

  • パイプライン内でメトリクスを集計
  • S3へParquet形式で保存
  • 日付パーティションを付与
  • 必要最小限の基本指標から開始

営業側には、

必要になれば追加できます

と伝えています。

最初から完璧を目指さず、
拡張可能な設計を優先します。

8. 可視化方法

エンジニア向け

  • QuickSightでダッシュボード作成
  • アラートは様子を見て判断

ビジネス側向け

  • シンプルなWebアプリを開発
  • PC・スマホ対応
  • PowerPoint貼り付け可能

Webアプリなどに関しては、また別の回で書きたいと思います。

9. まだ始まったばかり

現在はデータ取得を開始した段階です。

運用が始まれば、

  • 指標の追加
  • 定義変更
  • ダッシュボード改善

は必ず発生します。

メトリクス設計は、一度決めて終わりではありません。

次回

ここまでで、分析パイプラインの骨格が揃いました。

では、このパイプラインは
どのように設計し、組み上げていったのか。

次回は、GoogleのAIエージェント開発プラットフォームである、
Antigravity をどのように活用したかを書きます。

単なるコード生成の話ではありません。

  • どのように問いを立てたか
  • どこまでAIに任せたか
  • どこを人間が判断したか
  • データ分析の視点で何を明示したか
  • 色々なトラブルと解決策

設計プロセスそのものを整理します。

AIを使えば楽になるのか。
それとも、より思考が求められるのか。

実際の試行錯誤を交えて書きます。

Discussion