REVIEW TRUST / METHODOLOGY
食べログ・Googleマップ・Hot Pepper・SNS — 飲食店の評価情報は複数の媒体に分散しており、各媒体には金銭授受や無償提供を背景にした口コミ（いわゆる「桜」）が混じっている、というのが業界の率直な現実です。
NAGOYA BITES の「口コミ信頼度」は、「この店の Google の★と件数は、そのまま信じてよいか」という 1 つの問いに答える指標です。各媒体の口コミ本文は取得せず（運営側の利用規約と表現の自由を尊重するため）、公式 API で取れる事実だけを使い、観測できた検証項目だけで機械的に採点します。店の良し悪しを評価するものではありません。
このページでは、その仕組みのすべて — 検証項目、計算式、段階の定義、何をやらないと決めたか、誤判定が起きたときの異議申立て手順 — を第三者が検証できる形で開示します。1 分で読める要約は 口コミ信頼度の読み方 にあります。
一般的な「サクラチェッカー」型のサービスは、各レビューや店舗ごとに 「サクラ確率 87%」 のような数値を出します。 NAGOYA BITES では、機械統計の発想を借りつつも、同じ数値を「サクラ確率」とは呼びません。代わりに「口コミ信頼度」— その店の★と件数をどれだけ信じてよいか — という読者向けの名前を採用し、段階の語も店への評価ではなく読者への助言（「そのまま参考にできます」「他の情報と合わせて判断を」）として書いています。
理由は 3 つあります。
「サクラ確率」を採用しない 3 つの理由
口コミ信頼度が答えるのは 「この店の Google の★と件数は、そのまま信じてよいか」 の 1 つだけです。 店の良し悪し・料理の評価・当サイトの推薦度ではありません。段階は次の 5 つ（SS〜D）＋判定材料不足で、語はすべて読者への助言として書いています。
2026-08-20 の実測分布（5,030 店）: SS 4% ／ A 12% ／ B 36% ／ C 22% ／ D 19% ／ — 9%。D の大半は「件数が 30 件未満」または「★4.6 以上なのに 50 件未満」で、助言「件数が少ないため★は参考程度に」が事実として正しい帯です。SS は観測できた検証項目すべてで満点という明確な基準を持つ最上位帯です。
採点器は次の 8 軸を計算します。このうち口コミの信用度に関わる 7 項目（S1・S2・S4・S7a・S7b・S7c・S8）だけが口コミ信頼度に入り、サイト側のデータ整備状況を表す S3・S5・S6 は「掲載データの充実度」として別枠で見せます（信頼度には含めません）。
8 軸の単純和（0〜100）は内部合成点 crossCheckScore として特集の掲載店選定などに使いますが、公開面の数字ではありません。
| ID | シグナル名 | 取得元 | 満点 | 口コミ信頼度 | 判定の趣旨 |
|---|---|---|---|---|---|
| S1 | Google★ vs 件数比率 | Google Places API（rating × user_ratings_total） | 15 | 入れる（★と件数が取れた店で観測） | ★4.6 以上なのに件数が 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（手動）+ 無料RSS自動検出（Google News/note/はてな）の mediaFeatures | 10 | 入れる（掲載が 1 件以上見つかった店で観測） | 第三者媒体への掲載が複数あるほど独立検証が効いていると加点（1媒体5点・2媒体以上8点・4媒体以上10点）。掲載情報が見つからない場合は3点（中立）— プレス実績の有無は無料RSS発見の性質上ほとんどの正当な小規模店で該当するため、0点（減点）にはしない。 |
| 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/c を個別に観測判定） | (a) 口コミの増え方 ／ (b) 直近の評価は全体と一致するか ／ (c) 直近の評価のばらつき。オープン直後の急増→失速、直近だけ高い／低い、といった時系列の偏りを検知。 |
| S8 | 評価分布の自然性 | Google Places API reviews（最新 5 件） | 15 | 入れる（最新 5 件が取れた店で観測） | ★5 と ★1 が混在し中間が薄い、両極に割れた分布は不自然な分布として低点。最新 5 件からの近似判定。 |
S7 は週次で Google Places API から取得した結果を data/places_history.json に蓄積し、スナップショット間の差分から算出します。最大 12 回分のリングバッファで履歴を保持し、次の 3 サブシグナルを合算します。
S7 サブシグナル（max 20）
user_ratings_total の増加ペースを分析。初回だけ急増、直近は伸びが止まるような急増→失速パターンを検知 → 1 点まで減点。変動係数 ≤ 0.5 で安定なら 8 点。2026-08 時点の実測: 履歴の蓄積が想定どおり進んでいなかったため、S7 は稼働開始から数ヶ月経っても中立スコア寄りのままでした。 原因は取得スクリプト側の仕様（取得済み店舗を毎回スキップする設計）にあり、2026-08-14 に修正しています。 修正後は既存店舗も優先度付き・予算制御つきで週次に再取得する運用に切り替えました（2026-08-15、蓄積サイクル短縮のため月次から変更）。 履歴が 3 回分蓄積されるまでは、引き続き「履歴が無いだけで店舗を不利に扱わない」公平性のための中立スコアを返し、口コミ信頼度の分母には入れません（観測外）。
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 検知）口コミ信頼度（0〜100）＝ 観測できた検証項目の得点 ÷ その満点 × 100
data/trust_display_policy.json が唯一の情報源で、判定器 scripts/lib/trust_display.js だけが解釈します。
採点器と判定器はソースコードベースで完全に公開されています。8 軸の採点は scripts/lib/cross_check.js 内の
computeCrossCheckScore() 関数、段階への変換は scripts/lib/trust_display.js の evaluate() で、リポジトリは公開リポジトリ
wakuwaku-labs/nagoya-bites
から第三者が再現可能です。
各軸は段階関数で 0〜満点の範囲にマップされます。8 軸の単純和（0〜100）は内部合成点 crossCheckScore で、特集の掲載店を月次で選び直す際のバランス型スコアの一要素や、編集部の優先度付けに使います。公開面（店舗カード・詳細・店舗ページ・構造化データ）に出すのは口コミ信頼度の方です。
軸のデータが取得できない場合、内部合成点では「不利な情報がない」と解釈し中立寄りで評価し（件数情報が取得できないだけで店舗を不利に扱うのは公平でないため）、口コミ信頼度ではその項目を観測外として分母から外します。
段階の定義は 02 のとおりです。サイト上では同じ語彙を 4 層で繰り返します。
どこに何が出るか
段階の低い店にも、段階と助言語をそのまま表示します（非表示にはしません）。2026-05-20 までは 50 点未満を非表示、その後は「参考値」と表示していましたが、2026-08-20 からは段階 D「他の情報と合わせて判断を」・「—」「判定材料が足りません」と、読者が★をどう読むべきかの助言として出しています。店を非難する語は段階にも内訳にも使いません。
この仕組みで意図的にやらないと決めたこと
scripts/audit_trust_wording.js）で毎日検査する。機械統計には必ず誤判定が含まれます。NAGOYA BITES では誤判定をすみやかに発見・修正するため、次のセーフガードを用意しています。
スコアに違和感があった場合の窓口
data/cross_check_flags.json の内部フラグを目視確認し、誤検知が疑われる店は editor_picks.json の手動補正で対応します。
また、スコア算出ロジックは scoreVersion でバージョン管理されており、重大な変更を加える際は agent-backlog.md に変更履歴を記録します。
アルゴリズム変更によって特定店舗のスコアが急変するリスクを最小化するためです。
NAGOYA BITES は飲食業界の中で働いてきた人間が運営している媒体です。 広告と口コミの境界が曖昧になってきた業界の現状に対して、業界側がやらなければいけない仕事として、この仕組みを設計しました。
重要なのは、機械が個別の口コミの真贋を判定できるとは思っていないということです。 我々ができるのは、複数の根拠が同じ方向を指している「整合性」を測ることだけです。 最終的に「この店に行くかどうか」を決めるのは読者の皆さんであり、口コミ信頼度は判断材料の 1 つにすぎません。
だからこそ、この仕組みのすべてをこのページで公開しています。 機械の判断を信じてもらうのではなく、仕組みを公開することで第三者が検証できる状態を維持することが、信頼の作り方だと考えています。