各統計をどう構築しているか

表示するすべては監査可能に保つ3つのソースから来ています: Supercell公開API（developer.brawlstars.com）、Brawlify CDN（cdn.brawlify.com）、そしてプレイヤーごとの直近25試合を超えて公式APIが公開しないバトルや集計を永続化する弊社のSupabaseデータベース。

Supercell APIは構造データ（ブロウラー、ガジェット、スターパワー、ハイパーチャージ、ギア、イベントローテーション）の正典源ですが、ブロウラー画像、レアリティ、長文説明などの重要なフィールドは含まれていません。これらのフィールドは独立して運営され、時にSupercellより1〜3日遅れるBrawlify CDNとクロスチェックします。公式APIに新ブロウラーが現れBrawlifyにまだ存在しない場合、ローンチ日にもブロウラーページが正しくレンダリングされるよう、ローカルレアリティマップ（BRAWLER_RARITY_MAP）を保持します。

データベースはmeta_stats内に2クラスの行を保存します: source=user（同期を有効にしたプレミアムユーザーの実バトル）とsource=global（上位PROランキングからの自動サンプリング）。サイトの公開統計はすべてsource=globalでフィルターして計算され、個別ユーザーの個人データが公開ページに漏れることはありません。

BrawlVisionの「PRO」層は、世界トップ選手の最新バトルに対して計算された集計です。6時間ごとにcronジョブ（meta-poll）が、競技活動が集中する11カ国のSupercell公式ランキングをクエリし、各トップ200から約2,100人のユニークプレイヤーで構成される重複排除済みプールを構築します。

このプールに確率的サンプラーを適用し、人気のある（マップ、モード）の組み合わせがデータセットを支配して稀なものをマスクするのを防ぎます。個々のバトルを受け入れる確率はp = min(1, (minLive + 1) / (current + 1))で、minLiveは最も代表されない組み合わせのカウント、currentは候補バトルの組み合わせのカウントです。サンプル不足の組み合わせはより多くの重みを受け取り、飽和したものは成長を止めます。

cronはサーバーレス関数の300秒maxDurationに収まるよう270秒のソフト予算で実行ごとにMETA_POLL_MAX_DEPTH = 1,000人まで反復します。各応答にはイテレーションカウント、サンプル対象プレイヤー、モード別カウントを含む「adaptive」診断ブロックがあり、サンプラーの異常動作が本番で観察可能です。

ナイーブな勝率（勝利/試合）は小サンプルでは誤解を招きます: 新マップで3-0のブロウラーは「100%勝率」と表示されますが何の意味もありません。BrawlVisionはこれを補正するためベイジアン平滑化を使用し、サンプルサイズが大きく異なるブロウラー間でも比較可能な数値を返します。

式はWR_bayesian = (wins + α) / (battles + α + β)で、αとβは50%勝率を中心とする事前信念をエンコードするハイパーパラメータです。実用上α = β = 25、つまり「実データを見る前に50/50の50バトルを仮定する」に相当します。3勝0敗のブロウラーはナイーブな100%から(3 + 25) / (3 + 50) = 52.8%に移行し、サンプリングの実態をはるかによく表します。

サンプルが大きくなるにつれ事前分布の重みは減少します: 1,000バトル530勝でベイジアン勝率は(530 + 25) / (1,000 + 50) = 52.9%、ナイーブな53.0%とほぼ同じです。平滑化はサンプルが本当に小さい時にのみ「痛み」ます。これがまさに望ましい性質です: ノイズを罰し、シグナルを罰しない。

Comfort ScoreはBrawlVision独自のメトリクスで「平均より実際にどのブロウラーで上手いか」に答えます。生の勝率ではありません: 個人パフォーマンスの異なる側面をカバーするため、60/30/10の重みで3コンポーネントを組み合わせます。

主要コンポーネント（60%）はそのブロウラーでのプレイヤー勝率で、グローバルメタと同じくベイジアン平滑化が適用され、ほぼ使われないブロウラーがランキングを歪めないようにします。中間コンポーネント（30%）はこの個人勝率とブロウラー全体のメタ勝率との差です: グローバルメタが48%の時にSHELLYで55%のプレイヤーは、メタが53%のブロウラーで55%のプレイヤーより多くのcomfortを得ます。相対的な伸びが大きいからです。

最終コンポーネント（10%）は正規化された使用頻度です: 他が同じ条件なら、ブロウラーを100回プレイすることは10回プレイすることよりも価値があります。一貫性が報われるからです。正確な式と重みはsrc/lib/analytics/compute.tsにあり、各エンドポイント呼び出しで同一に適用され、ランキングは再現可能です。

すべての公開ブロウラーには「+X.Y%」または「−X.Y%」のトレンドインジケータがあり、メタ勝率が直近7日と前7日（合計14日ウィンドウ）でどう変化したかを示します。計算はsource=globalで、ウィンドウの各半分に最低MIN_BATTLES_PER_TREND_WINDOW = 3バトルで実行されます — 半分の一方でも閾値に達しなければnullを返し、UIは弱い信号の数を捏造する代わりに矢印を隠します。

トレンドはpg_cronジョブにより6時間ごとに小テーブル（public.brawler_trends、ブロウラーごとに1行）で事前計算されます。エンドポイント応答ではなくDBで行うことで、ISRリフレッシュごとに14日スライスの数万行をスキャンすることを避けます。事前計算テーブルが12時間以上古いか空の場合、エンドポイントはmeta_statsへのページネーションされたインラインルートにフォールバックし、より高いコストで同じ応答を返します。PostgRESTがページネーションされていないクエリを1,000行に静かに切り詰めるため、ページネーションが必要で、これにより一度多くのブロウラーが偽のアンダーサンプリングでnullを返したことがあります。

ロジックは設計上重複して存在します: src/lib/brawler-detail/trend.tsのTypeScriptバージョン（詳細ルート）とsupabase/migrations/022_*.sqlのSQLバージョン（バルクルート）。両者は同じ閾値、同じウィンドウ、同じsource=globalフィルタを使用します。乖離するとブロウラー個別ページと集計ページが同じブロウラーに対して異なる数を表示するため、変更は両方に適用されます。

データがどれくらいの頻度で更新されるかは解釈に影響するため、明示的に文書化します。静的ページ（このページを含む）は24時間再検証のISR（Incremental Static Regeneration）を使用します。動的データを持つページは、関連ジョブが無効化するまでAPI応答をキャッシュします。

ブロウラー、ガジェット、スターパワーは24時間サーバーキャッシュでSupercell APIから同期します。meta-poll（PROデータ）は6時間ごとに実行され新しいmeta_stats行を生成します。7日トレンドの事前計算はmeta-pollとの衝突を避けるためpg_cronで「17 */6 * * *」（6時間ごとの17分）に実行されます。ゲーム内イベントローテーションは30分ごとに更新されます。

同期を有効にしたプレミアムユーザーの個別バトルは、sync cron経由でスライディングウィンドウで各試合直後にダウンロードされます。データベースに入るとsource=userでmeta_statsに供給され、プロフィールセクションのプライベート分析の基礎となります; 公開集計には決して現れず、source=globalと混ざることもありません。