Claude Codeで分析基盤を構築。ユーザー行動を可視化した瞬間、自分のプロダクトがゴミに見えた。

※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記です。

ユーザーの動きが手にとるようにわかる

ユーザーが何をしているか、全部見えるようにした。ページを開いた瞬間から、どのボタンを押し、どこで離脱したか。そういうログを全部残す仕組みを作った。なんでこれ最初から作らなかったんだろ。見えた瞬間に、僕の仮説は音を立てて崩れ去った。

見えていなかった80%の真実

今週はユーザーの行動追跡と分析ダッシュボードの構築に全振りした。自分が作ってきた機能が、本当に使われているのかを知りたかった。

• 総コミット: 34件
• 新機能: 3件
• バグ修正: 1件

結果として、自分のプロダクトに対する思い込みが完全に否定された。データが突きつける残酷な現実に直面し、開発の方向性を根本から見直した。

全能感とデータ汚染

ユーザーの行動をログに残せば、プロダクトの改善ポイントが明確になる。KPIは確実に右肩上がりになると信じていた。「feat: ユーザー操作アクティビティログ追加」で、あらゆる操作のトラッキングを開始した。

漫画生成のダイアログ開閉から、画像生成のクレジット不足表示まで。投稿候補の承認や却下、さらには非同期ジョブの開始と完了まで記録した。「feat: トラッキング対象ページを大幅拡充」で、収益化ガイドや設定ページも網羅した。

Claude Codeと一緒に、設計から実装まで一気に組み上げた。ユーザーの動きが手に取るようにわかる全能感があった。しかし、いざ可視化してみると、僕の自信作は誰にも使われていなかった。

逆におまけで作った機能に、ユーザーが群がっていた。さらに悪いことに、集計データそのものが汚染されていた。「fix: イベントアクティビティ統計でNULL値もカウントされるバグを修正」

開封日やクリック日がNULLのレコードも、全件カウントされていた。開封803件、クリック803件と、全件数がそのまま表示されていた。データ解析ツール導入時の初期設定ミスは致命傷だ。

しんたろー:
バグないですって顔して動いてたけど、普通にバグだらけだった。100%の開封率なんてあるわけないのに、一瞬喜んでしまった自分が恥ずかしい。

罠はこれだけではなかった。ファネル分析の数字も、根本から狂っていた。「fix: ユーザーファネルの1000件制限バグを修正」

Supabaseの仕様で、取得件数が1000件で止まっていた。デフォルトの制限はパフォーマンス保護のためのものだ。この上限値を疑わなかったせいで、全体の数字が大きく歪んでいた。

ページネーション関数を追加して、制限を回避した。数万件のデータも安全に取得できる仕組みに変えた。バグを直した瞬間、全く違う数字が画面に現れた。

候補生成ユーザー数が8人だと思っていたら、実は44人だった。見えていなかった80%のユーザーの動きが、そこにあった。さらに、内部利用者のデータも混ざっていた。

「fix: 内部利用者を有料プラン統計から除外」

テスト用のメールアドレスが、KPIを不当に押し上げていた。テストデータの混入はデータドリブン開発の最大の罠だ。

開発者自身の行動が混ざると、成長率が過大評価される。撤退すべきタイミングを見失う原因になる。実課金ユーザーのみでMRRを計算するように修正した。

内部ユーザーを除外した結果、さらにリアルな数字が突きつけられた。仮説で動いていた期間が長すぎた。ユーザー行動の可視化は、初期装備にするべきだった。3時間かけて実装した結果、僕のメンタルはボロボロだ。

サーバーが悲鳴を上げた日

管理画面のユーザー一覧を出すだけなら、単純なクエリで十分だと思っていた。しかし、ユーザー数が増えるにつれて、サーバーが悲鳴を上げ始めた。管理画面を開くたびに、画面がフリーズする事態になった。

「feat: admin/users APIのパフォーマンス改善」

ユーザーIDを取得して、そこからループでカウント処理を回していた。いわゆるN+1問題の亜種だ。

PostgREST環境において、クライアントサイドでのループ処理はアンチパターンだ。企業の大規模システムなら、一瞬でデータベースのコネクションが枯渇する。僕はその禁忌を平気で犯していた。

ループ処理を全廃止した。代わりにRPC関数を使用した効率的なクエリに変更した。データベース側で集計を完結させるのが、スケーラビリティ確保の鉄則だ。

しんたろー:
ページを開くのに5秒かかっていた。RPCに変えたら50ミリ秒になった。100倍の速度差。今までサーバーにどれだけ無駄な負荷をかけていたのか。

さらに、APIの並列化も進めた。「fix: admin/users最適化 - 非同期ローディングとAPI高速化」

ユーザー一覧と統計データを分離し、一覧を先に表示するようにした。

2つの非同期処理を1つに統合して、並列実行した。フィルター処理も半減させた。結果として、管理画面のレスポンスは劇的に向上した。

しかし、別の問題が発生した。代理閲覧機能が、一部のページで機能していなかった。「fix: 代理閲覧機能の全体的な修正」

管理者が特定のユーザーとしてログインした状態をシミュレートする機能だ。これが分析ページや設定ページでうまく動いていなかった。「fix: 分析ページと設定ページに代理閲覧機能を完全対応」

全てのコンポーネントにユーザーIDを渡すように修正した。サーバーアクション経由でアカウント情報を取得するように変更した。これでようやく、見たくない現実を見るためのダッシュボードが完成した。

「feat: 管理画面にトレンド分析・日次スナップショット機能を追加」

毎日23時55分に、ユーザー活動統計をスナップショット保存する。トレンド分析チャートと、業界ベンチマークの表示も追加した。

LINEからの登録率30〜50%、無料から有料への転換率2〜5%。このベンチマークと自分の数字を並べるのは、精神的な拷問に近い。それでも、事実から目を背けるわけにはいかなかった。完璧なダッシュボードが完成した代償として、僕は現実という名の鈍器で殴られ続けている。

落とし穴

ユーザーの離脱を正確に測ろうとした。どこでページを閉じたのか、詳細なログが欲しかった。ブラウザのイベント発火仕様を完全に甘く見ていた。

「fix: ページ離脱イベントの重複を修正 & 管理者メニュー整理」

ページを離れる際の発火イベントが重複していた。ログの数が実際のアクセス数の2倍に膨れ上がっていた。

ユーザーが離脱したんじゃなかった。僕のログが離脱してただけだった。

今日の数字

| 項目 | 今回のデータ | 比較対象 |

|------|------------|----------|

| 分析基盤の構築 | 2週間 | 企業なら3〜6ヶ月 |

| ファネル離脱率 | 30-50% | 業界標準と同等 |

| API応答速度 | 50ミリ秒 | 修正前は5秒 |

| 自作ログ基盤コスト | 月額無料 | 外部SaaSなら月額数万円〜 |

しんたろー:
外部の分析ツールに月額数万円払うくらいなら、自分で作った方が早い。Supabaseの無料枠に収まる限り、コストはゼロだ。

ファネル分析の離脱率が、業界標準の30〜50%に収まっていることがわかった。数字だけ見れば悪くない。しかし、その数字を出すまでに流した冷や汗の量は計り知れない。

よくある質問（FAQ）

なぜ外部の分析SaaSを使わなかったのか？

外部SaaSを導入すれば月額数万円の固定費がかかる。自作のログ基盤ならSupabaseの無料枠に完全に収まる。コストゼロで同等のトラッキング機能が手に入るからだ。

ログ基盤の実装はどのような手順で進めたのか？

まずクライアント側でページビューとスクロールを追跡するプロバイダーを作った。次にそれを受け取るAPIエンドポイントを構築し、データベースに保存した。最後に管理者用のダッシュボードを組み上げて、データを可視化した。

ログ導入前後でKPIの計測値はどう変わったか？

導入前はファネルの離脱率が全く見えていなかった。導入後はLINE登録からの遷移率が30%〜50%という業界標準の数字として正確に可視化された。バグ修正で候補生成ユーザーの計測値も8人から44人へと適正化された。

現実を見る覚悟

見たくない数字を見ることでしか、プロダクトは前に進まない。

👉 ThreadPostでSNS運用を自動化する