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

表示するすべては監査可能に保つ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 =（勝利数 + α·μ）/（試合数 + α）です。パラメータαは架空の試合をどれだけ加えるかの重みで、μはその試合に割り当てる結果です。α = 30を使っており、実際のデータを見る前に30試合を先に足すことにあたります。

2026年9月まで、この架空の試合の値は50%でしたが、それは誤った値でした。私たちのテーブルは1試合につき1行、調査対象プレイヤーの行だけを保存します。この層は自国の上位200位に入り、自分の試合の71.4%を勝ちます（14日間のウィンドウで85,970試合中61,400勝、2026年9月7日測定）。71.4%を中心とするデータを50%へ縮めると、試合数の少ないセルはすべて下に引っ張られ、サンプルが小さいほど強く引っ張られていました。現在のμは0.714で、これは実測した基準値です。

事前分布の重みはサンプルが増えるにつれて小さくなります。1,000試合で530勝なら結果は（530 + 21.42）/ 1,030 = 53.5%となり、生の53.0%にごく近い値です。3試合3勝なら、ナイーブな100%ではなく74.0%になります。平滑化が効くのはサンプルが本当に小さいときだけです。

公開している勝率は2つのものを混ぜています。1つはブロウラーの性能、もう1つはどの相手と当たったかです。有利な対戦に多く現れるブロウラーは上位に出てきますが、それは性能について多くを語りません。補正後の強さはこの2つを分け、そのブロウラーが中位レベルの相手にどれくらいの頻度で勝つかを推定します。

計算は、直近14日間の対戦表に対してMMで当てはめたBradley-Terryモデルです。当てはめに入れる前に各ブロウラーのペアを対称化します。行は常に調査対象プレイヤー側から記録されており、その側が有利だからです。各方向に30回以上の対戦があるペアで測ると、AのBに対する勝率とBのAに対する勝率の合計は中央値で138%になり、対称なデータなら100%になります。各対戦を両側から1回ずつ数えると、この有利さは両方に働いて打ち消し合います。結果は当てはめの中央値のブロウラーに対する期待勝率として公開しているので、この尺度では50%が引き分けにあたります。

この数値は相手の構成とサンプリングの平均的な有利さを差し引いています。ブロウラーを操作する人の腕前は差し引いていません。meta_statsにもmeta_matchupsにもプレイヤーの識別子は保存されておらず、手持ちのデータで操作者のレベルを引くことはできません。それには取り込み時に調査対象プレイヤーのランキングを記録する必要があります。そのためサイトのリストは今も観測勝率で並べ、強さはその横に置いています。観測勝率が50%ではなく72%前後になるのも同じ理由です。サンプルは11か国の上位200位のプレイヤーの試合で、この層は自分の試合の72%近くを勝つため、この尺度では72%が平均的なブロウラーを表します。強さを公開するのは、20体の異なる相手に対する400回以上の対戦記録があるブロウラーだけです。それを下回る場合は、根拠の乏しい数値を見せる代わりに表示を省きます。

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と混ざることもありません。