SAKURA-FREE / TRUST METHODOLOGY
食べログ・Googleマップ・Hot Pepper・SNS — 飲食店の評価情報は複数の媒体に分散しており、各媒体には金銭授受や無償提供を背景にした口コミ（いわゆる「桜」）が混じっている、というのが業界の率直な現実です。
NAGOYA BITES では、各媒体の口コミ本文を取得することはせず（運営側の利用規約と表現の自由を尊重するため）、取得可能な公式 API と既に編集部が確認しているデータだけを使い、複数シグナルでの整合度を機械的に算出する仕組みを導入しました。
このページでは、その仕組みのすべて — シグナル定義、計算式、何をやらないと決めたか、誤判定が起きたときの異議申立て手順 — を第三者が検証できる形で開示します。
01 — Why We Don't Call It "Sakura Score"
一般的な「サクラチェッカー」型のサービスは、各レビューや店舗ごとに 「サクラ確率 87%」 のような数値を出します。 NAGOYA BITES では、機械統計の発想を借りつつも、同じ数値を「サクラ確率」とは呼びません。代わりに「クロスチェック整合度」と中立的な名前を採用しています。
理由は 3 つあります。
「サクラ確率」を採用しない 3 つの理由
02 — 8 Signals: 8 つのシグナル（scoreVersion 2.0）
整合度は次の 8 シグナルの合計（0〜100 点）で表現します。各シグナルは独立に評価され、合計値が高いほど「複数の根拠が同じ方向を指している」状態を意味します。 S7・S8 は「点数の変動・時系列パターン（★5/★1 の異常多発、オープン時の急増失速、化粧剥がれ）」を真のサクラ判定要素として組み込んだ新規シグナルです。
| ID | シグナル名 | 取得元 | 満点 | 判定の趣旨 |
|---|---|---|---|---|
| S1 | Google★ vs 件数比率 | Google Places API（rating × user_ratings_total） | 15 | ★ が極端に高いのに件数が少ない（<50 件）はガチャレビュー疑い。件数 100+ で ★4.0+ は強い整合シグナル。 |
| S2 | レビュー件数絶対値 | Google Places API（user_ratings_total） | 10 | 30 件未満はサンプル不足、200+ は豊富なサンプル。 |
| S3 | データ充実度 | LOCAL_STORES のフィールド埋まり率 | 15 | タグ ≥3 個・Instagram URL・食べログ URL・おすすめポイント・写真 URL の 5 要素 × 3 点。データキーパーの拡充状態を客観的に測る。 |
| S4 | 他媒体掲載クロスチェック | editor_picks.json の mediaFeatures | 10 | 第三者媒体への掲載が複数あるほど独立検証が効いていると評価。 |
| S5 | 営業実態継続 | Hot Pepper API 取得継続 + Places business_status | 5 | Hot Pepper 取得継続＝営業実態あり。CLOSED_PERMANENTLY は除外。 |
| S6 | Instagram 実在シグナル | instagram_resolved.json + Instagram投稿URL | 10 | 公式 IG アカウント解決済み（+7）+ 最新投稿 URL あり（+3）。実在性 + 集客活動の客観シグナル。 |
| S7 | レビュー時系列健全性 | places_history.json（月次差分）+ 最新 5 件レビュー | 20 | (a) 投稿ペース安定性 ／ (b) 最新★ vs 全体★ の乖離 ／ (c) 最新★の標準偏差。オープン時の急増→失速、サクラ継続投入、化粧剥がれパターンを検知。 |
| S8 | 評価分布の自然性 | Google Places API reviews（最新 5 件） | 15 | ★5 と ★1 が混在し中間が薄い U 字型分布は評価操作の典型パターン。最新 5 件からの近似判定で減点。 |
02-A — S7 の詳細: 時系列シグナル
S7 は毎月 1 回 Google Places API から取得した結果を data/places_history.json に蓄積し、月次差分から算出します。最大 12 ヶ月分のリングバッファで履歴を保持し、次の 3 サブシグナルを合算します。
S7 サブシグナル（max 20）
user_ratings_total 増加ペースを分析。初月だけ +20 件、直近 +2 件以下のような急増→失速パターンを検知 → 1 点まで減点。変動係数 ≤ 0.5 で安定なら 8 点。S7 は稼働開始から 2〜3 ヶ月後に本格機能します。初月は月次差分が取れないため、中立スコア（10/20）を返します。これは「履歴が無いだけで店舗を不利に扱わない」公平性のための設計です。
02-B — S8 の詳細: U 字型分布の近似判定
Google Places API は★1〜5 の完全な件数分布を返しません。そのため、最新 5 件のレビュー（取得可能な最大件数）から U 字型分布を近似判定します。
S8 判定ロジック（max 15）
data/cross_check_flags.json に分離保存しています。
これらは Inspector の月次レビュー素材として使われるだけで、サイト上には表示しません — 機械判定で個別店を「サクラ疑い」と名指しすることのリスクが大きすぎるためです。
gachaReviewSuspicion: ★≥4.6 かつ件数 <50 = ガチャレビュー疑いmediaDiscrepancy: 食べログ URL あり かつ Google★ ≤3.2 = 媒体間評価乖離openingBurstPattern: 投稿急増 → 失速パターン（S7-a 検知）uShapedDistribution: ★5/★1 偏在で中間が薄い（S8 検知）03 — Scoring Formula
整合度の算出式は、ソースコードベースで完全に公開されています。実装は build.js 内の
computeCrossCheckScore() 関数で、リポジトリは公開リポジトリ
wakuwaku-labs/nagoya-bites
から第三者が再現可能です。
各シグナルは段階関数で 0〜満点の範囲にマップされ、最後に単純和を取ります（重み付け平均ではなく、合計）。 シグナルが取得できない場合は「不利な情報がない」と解釈し中立寄りで評価します — 件数情報が取得できないだけで店舗を不利に扱うのは公平でないためです。
04 — Tier Definition: 表示の段階
算出された整合度（0〜100）は、サイト上では次の 4 段階で表現されます。
50 未満の店にはバッジを表示しません。これは「検証が浅い」「シグナルがまだ揃っていない」だけのケースが多く、機械判定でネガティブな表示を出すことで誠実な店を誤って傷つけるリスクを避けるためです。
05 — What We Don't Do（戦わない領域）
この仕組みで意図的にやらないと決めたこと
06 — Dispute & Correction（異議申立てと修正）
機械統計には必ず誤判定が含まれます。NAGOYA BITES では誤判定をすみやかに発見・修正するため、次のセーフガードを用意しています。
スコアに違和感があった場合の窓口
data/cross_check_flags.json の内部フラグを目視確認し、誤検知が疑われる店は editor_picks.json の手動補正で対応します。
また、スコア算出ロジックは scoreVersion でバージョン管理されており、重大な変更を加える際は agent-backlog.md に変更履歴を記録します。
アルゴリズム変更によって特定店舗のスコアが急変するリスクを最小化するためです。
07 — 設計の根本にある立場
NAGOYA BITES は飲食業界の中で働いてきた人間が運営している媒体です。 広告と口コミの境界が曖昧になってきた業界の現状に対して、業界側がやらなければいけない仕事として、この仕組みを設計しました。
重要なのは、機械が個別の口コミの真贋を判定できるとは思っていないということです。 我々ができるのは、複数の根拠が同じ方向を指している「整合性」を測ることだけです。 最終的に「この店に行くかどうか」を決めるのは読者の皆さんであり、整合度は判断材料の 1 つにすぎません。
だからこそ、この仕組みのすべてをこのページで公開しています。 機械の判断を信じてもらうのではなく、仕組みを公開することで第三者が検証できる状態を維持することが、信頼の作り方だと考えています。