Claude Code + Snowflake でリリース後の施策分析を自動化

はじめに

クラシル株式会社で開発マネージャーをしているfunzinです。

プロダクト開発において施策リリース後、効果を分析して次のアクションを決めるサイクルが週に複数回発生します。リリース日の確認、分析クエリの実行、グラフ作成、考察、ネクストアクションの策定と工程が多く、リリース頻度や施策数が増えるほど工数が膨らむ課題がありました。
本記事では、リリース情報とバックログを自動で紐づけて分析を生成する仕組みについて、全体設計と実装のポイントを紹介します。

リリース後の施策分析で発生していた課題

リリース後の施策分析は、以下の手順で行っていました。

1. 施策リリース日とアプリの該当バージョンを確認
2. 該当するバックログを探し、分析観点を読む
3. LightdashやSnowflakeで分析
4. グラフを作成し、分析観点に基づく数値変化を確認する
5. 結果を整理して意思決定に使う

各ステップ自体は定型的です。分析観点はバックログに書いてあり、クエリのパターンも大方決まっています。従来の方法では毎回人間が一つずつ手順を辿る必要がありました。

この作業フローを見直している時に、このフローもAI Readyにできると考えました。分析の「判断」の最終意思決定は人間がやるべきですが、「データの収集と可視化」は自動化できます。

Claude Code + Snowflake の自動分析アーキテクチャ全体像

自動化の全体像は以下の通りです。

ステップ	担当	詳細
リリース情報の同期	Claude Code	Notionに保存しているリリース情報を取得
バックログマッチング	Claude Code	キーワードマッチで近しいバックログを取得
分析観点の抽出	Claude Code	バックログの「## 分析観点」セクションから箇条書きを取得
クエリ実行・可視化	Snowflake + Streamlit	Snowflake経由でクエリを発行し、Streamlitでグラフ化
結果の確認・意思決定	人間	Streamlitページで分析結果を確認し、ネクストアクションを判断

Claude Codeのスケジューラーで毎朝出社時刻に自動発火させています。人間がSlackを開くと、分析結果の通知が届いている状態です。

この仕組みの鍵は、リリース情報とバックログを自動で紐づける点です。リリースの備考から「何の施策か」を読み取り、対応するバックログの分析観点を取得する。この連携があるからこそ、「何を分析すべきか」をAIが自律的に判断できます。

実装の詳細：バックログマッチングからクエリ実行まで

1. リリース情報の管理

リリース情報はNotionDBで管理しているため、MCP経由でアクセスをして、情報を取得するようにしています。

    {
        "バージョン名": "1.2.0",
        "OS": "iOS",
        "リリース日": "2026-03-30",
        "概要": "新機能A追加・バグ修正",
        "備考": "ホームにXXXセクションを追加\nYYY機能の不具合修正\n...",
        "ビルドバージョン": 25153,
    }

スケジューラーがリリース情報を取得して、直近7日以内のリリースを対象として抽出します。
Notion上でリリース情報を管理していますが、手元のStreamlitアプリでも確認できるようにビジュアライズしています。

2. バックログマッチングと分析観点の抽出

リリース情報は開発チームが管理し、施策の仕様はNotionのバックログで別途管理されています。本来は人手で突き合わせる必要があるこの2つのデータを自動で紐づけます。この突き合わせが自動化されることで、リリースのたびに担当者がNotionとリリースノートを行き来する手間がなくなり、分析開始までの時間を大幅に短縮できます。リリースの備考欄から「何の施策か」を読み取り、対応するバックログを自動で特定します。バックログに記載された分析観点が、そのままSnowflakeクエリの「問い」になります。

マッチしたバックログに「## 分析観点」セクションがある場合のみ、分析を実行します。分析観点がないバックログはスキップします。

具体的なマッチの例を示します。

リリース備考（Notionのリリース管理DB）

ホームにA機能セクションを追加

バックログタイトル（Notionのバックログ）

A機能セクション追加

備考の「A機能セクション」というキーワードがバックログタイトルに含まれていればマッチします。バックログのタイトルとリリース備考の書き方を揃えておくことで、マッチ精度が大きく上がります。

マッチしたバックログに以下のような「## 分析観点」があれば、その内容がそのまま分析の「問い」になります。

## 分析観点

- Aの機能利用率が改善したかどうか
- Aの一人当たりの利用数が改善したか

この箇条書きが、この後の自動分析の「問い」になります。

3. Snowflakeクエリの自動実行

抽出した分析観点に基づき、Streamlitアプリ内でSnowflake経由でクエリを発行します。クエリ結果をグラフ化してInsightページを生成するようにしています。

# テーブル名・カラム名はサンプル用のダミーです
df_usage = run_query(f"""
SELECT
    event_date,
    platform,
    COUNT(DISTINCT user_id)        AS dau,
    COUNT(DISTINCT CASE WHEN feature_used = 1
          THEN user_id END)        AS feature_users,
    ROUND(COUNT(DISTINCT CASE WHEN feature_used = 1
          THEN user_id END)
          / NULLIF(COUNT(DISTINCT user_id), 0) * 100, 1) AS usage_rate,
    SUM(feature_count)
          / NULLIF(COUNT(DISTINCT user_id), 0) AS usage_per_user
FROM {target_table}
WHERE event_date
      BETWEEN '{start_date}' AND '{end_date}'
GROUP BY 1, 2 ORDER BY 1, 2
""")

クエリ結果をグラフ化し、リリース日を赤い破線でプロットします。リリース前後の変化が視覚的にわかるようにしています。

import altair as alt

release_date = "2026-03-30"  # リリース日（サンプル）

chart = alt.Chart(df_usage).mark_line(point=True).encode(
    x=alt.X("event_date:T", title="日付"),
    y=alt.Y("usage_rate:Q", title="機能利用率 (%)"),
    color=alt.Color("platform:N", title="プラットフォーム"),
).properties(title="機能利用率の推移")

release_line = alt.Chart(
    pd.DataFrame([{"date": pd.Timestamp(release_date)}])
).mark_rule(color="red", strokeDash=[4, 4]).encode(
    x=alt.X("date:T")
)

st.altair_chart(chart + release_line, use_container_width=True)

またSQLはStreamlit内に埋め込んでいます。 分析結果だけでなく、どのクエリで導出したかを後から振り返れるようにするためです。分析の再現性を担保する設計です

4. Insightページの3タブ構成

生成されるInsightページは3つのタブで構成されています。

タブ	内容
根拠ファクト	分析観点ごとのグラフとデータ。全体 → プラットフォーム別のブレイクダウン
分析ログ	検証プロセスの自動記録。どの順序で何を確認したかのトレース
サマリー	結論と留意事項の要約。人間が意思決定に使う最終アウトプット

根拠ファクト	分析ログ	サマリー

ページタイトルには[claude]プレフィックスを付けて、自動生成であることを明示しています。手動で壁打ちしながら作成した分析ページと区別するためです。

実際の例

人が判断する自動化の設計

この仕組みで最も重視したのは、人間が意思決定だけに集中できる状態を作ることです。

完全自動化（AIによる意思決定まで含める）も検討しましたが、施策判断にはリリース文脈・チーム状況・前スプリント（1週間単位の開発サイクル）の経緯など、定量データに現れない情報が多く含まれます。AIと人間の役割を分離することで、判断の品質を担保しつつ準備作業を省力化できます。

自動化しているのは「データの収集・可視化・整理」までです。分析結果を見て「この施策は継続する」「次のスプリントで改善する」「追加で深掘りする」といった判断は、人間が行います。

具体的な運用フローは以下の通りです。

1. 朝、Slack DMに分析完了の通知が届く
2. StreamlitのInsightページを開き、サマリータブで概要を確認する
3. 根拠ファクトタブでグラフを確認し、数値の妥当性を検証する
4. 必要に応じてクエリを修正し、追加分析を行う
5. 結果をもとにネクストアクションを決定する

完全自動化ではなく、判断の前段階だけを自動化するアプローチです。分析の品質はバックログに書かれた分析観点の質に依存するため、バックログを書く段階で「何を検証したいか」を明確にしておく運用が前提になっています。

自動化の効果：分析リードタイムと工数の変化

自動化前後で以下の変化がありました。

指標	Before	After
分析着手までのリードタイム	リリース後自分が分析できるタイミングになったら	リリース翌朝（自動発火）
1回あたりの分析作業時間	30分〜1時間	確認・判断のみで10分程度
分析の抜け漏れ	リリース頻度が高いと発生	バックログに分析観点があれば自動実行

分析の網羅性が上がったことで、施策の振り返りが確実に回るようになりました。

まとめ

Claude Codeのスケジューラー、Snowflake、Streamlitを組み合わせることで、リリース後の施策分析を自動化しました。完全自動化ではなく、人間が意思決定に集中できる設計にしたことが運用に乗ったポイントです。バックログに分析観点を書く習慣さえあれば、分析基盤が自動で動く状態を作れます。

分析の品質はバックログに書く習慣で決まります。仕組みより先に、観点を言語化する文化があることが前提です。