evidence-based-reviews

エビデンスに基づくレビュー

根拠と一致した主張を盛り込んだ製品レビューや購入ガイドを作成します。この手法は、根拠を明示したうえで証拠を統合するものです。そして、すべてを支えるルールがひとつあります。実際には経験していないハンズオンの時間を、決してあったかのように主張しないことです。

ほとんどのレビューサイトは、このルールをひそかに破っています。仕様書をつなぎ合わせて作ったコンテンツの上に「テストしました」と書かれていて、読者にはそれが見抜かれています。正直な代替案は、弱いどころか、より強力です。多数の所有者の体験、検証済みの仕様、複数の専門家情報源を照合して統合すれば、実証可能な独自分析になります。その方法を開示することで、捏造したテストが損なう信頼を築けます。

---

使用する場面

• ハンズオンで製品を試す機会が一部しかない、またはまったくない状況で、製品レビューや購入ガイドを執筆するとき
• 新しいレビューサイトやアフィリエイトサイトのレビュー方法を整備するとき
• 既存のレビューコンテンツに、根拠の開示を追加するとき
• 根拠では裏付けられない主張がレビューコンテンツに含まれていないか監査するとき
• 個々の記事にReviewまたはProductのスキーマを適用することが誠実かどうかを判断するとき
• レビューコンテンツを、GoogleのレビューシステムやFTCの開示要件に沿わせるとき

使用しない場面

• 一般的なコンテンツの執筆や編集（content-and-copyを使用してください。このスキルはレビューコンテンツの根拠と主張の部分を特に扱います）
• ブランドの語り口を定義するとき（brand-voiceを使用してください）
• レビューページ自体を検索向けに最適化するとき（seo-onpageを使用してください）
• 個別の記事向けの編集ブリーフを作成するとき（content-brief-authoringを使用してください）
• 初めて読む人に手順や概念を教えるチュートリアルや解説記事などの、説明を目的としたハウツーコンテンツ。この種の教育コンテンツは、執筆、構成、検索向けの工夫によって成り立ちます。根拠に関する規律は主張を制約する要素として並行して機能するため、このスキルは複数ある入力のひとつであり、唯一の選択肢ではありません。

計測機器や手順を用いた本格的なハンズオンテストを大規模に実施している場合も、このスキルが適用されます。ティアは変わりません。方法論の説明でティア4を明記し、テスト手順を開示する根拠として示します。

---

必要な入力

• 製品カテゴリーと予定している記事（レビュー、購入ガイド、またはその両方）
• 根拠となる情報源へのアクセス：メーカーのページ、販売店のレビューコーパス、フォーラムや所有者コミュニティ、専門メディア
• ブランドの開示文言（ある場合。このスキルでは、ない場合に使えるテンプレートを提供します）
• 実際に存在するハンズオン経験の正直な一覧（該当する場合）

---

フレームワーク：ひとつのルールと4つのエビデンスティア

基本ルール：実際には経験していないハンズオンの時間を、決してあったかのように主張しないこと。この手法に含まれるほかの要素はすべて、嘘に頼らなくても十分に強いコンテンツを作るためのものです。

ティア1：メーカーの仕様を検証する

仕様は、内容が古くなっていることもある集約サイトの転載ではなく、メーカー自身のページを参照して記載します。検証作業こそが重要です。メーカーの最新掲載情報と仕様を照合し、日付を記録し、情報源間に食い違いがあれば、どれかを黙って選ぶのではなく明示します。この方法で作成した仕様表は事実に基づく情報層です。別のレビューサイトからコピーした仕様表は、うわさの情報層です。

これで十分な場面：事実に基づく比較、適合性や互換性に関する回答、価格帯ごとの分類。これだけで製品の品質を評価することは、決してできません。

ティア2：多数の所有者の体験を統合する

販売店のレビューコーパス、フォーラムのスレッド、保証請求や返品の傾向を、複数の情報源にわたって確認し、誠実に要約します。誠実な統合には、次の要素が含まれます。

• 目立つ単独の逸話ではなく、繰り返し見られる苦情や称賛を取り上げる
• サンプル数を率直に示す：「約1,400件の所有者レビュー全体を見ると」という表現と「所有者の声によると」という表現では、読者の受け取り方が異なります。読者には件数を知る権利があります
• 都合のよい情報だけを選ばない：所有者の意見が分かれているなら、その相違こそが調査結果です
• 情報源を明記する：どのレビューコーパス、どのコミュニティを、どの期間に調べたのか

これで十分な場面：耐久性や信頼性の評価、仕様書だけでは分からない実環境での癖、用途ごとの満足度の傾向。このティアは、ハンズオンなしで誠実なレビューを作るための主力であり、大規模に実施すれば正真正銘の独自分析になります。

ティア 3：専門家ソースの突き合わせ

専門家として名前を挙げられる情報源を互いに比較します。突き合わせとは、判断をひとまとめに平均化するのではなく、一致点と相違点を明らかにすることです。信頼できるテスターが正反対の結論に至った場合は、その事実を率直に伝え、どのような条件がその違いを説明し得るかを述べます。匿名の「専門家も同意」はティアではなく、飾りにすぎません。

適用する場面：サイトにない計測機器が必要な性能に関する主張、技術に左右される評価、カテゴリの文脈。

ティア 4：実地検証（実際に行った場合のみ）

実際に行った場合に限って明記し、その旨を示したうえで、実施内容、規模、条件を定量的に記載します。ティア 1〜3で公開した記事に、後から実地検証の経験が加わった場合は、何が変わったかを記した更新情報を添えて記事をアップグレードします。最初から実地検証を行っていたかのように後付けしてはいけません。アップグレードの履歴自体が信頼の証です。

---

方法論ブロック

すべてのレビューと購入ガイドには、根拠の種類を明記した短い開示ブロックを、評価基準と一緒に掲載します。法律家ではなく読者に向けて書きます。記入式テンプレートと記入例は、references/methodology-block-template.mdにあります。

このブロックには、重み付けした順の評価基準、実際に使用したティア（具体的な情報源も含む）、実地検証で行ったこと、または「主張なし」という文言、そして更新情報を記載します。記事で使用していないティアを主張するブロックは、アンカールールが禁じる虚偽と同じものを、より小さな文字で書いているにすぎません。

---

この方法論が求める構成上の規律

• おすすめを選ぶ前に、評価基準を明示して順序を付けます。 読者が明示された基準にたどって検証できない結論は、方法論を装った意見です。
• おすすめする各製品について、欠点を1つ挙げます。 すべての製品には欠点があります。欠点が見つからないレビューは、十分に調べていません。欠点の掲載位置を統一することで、率直さが伝わります。
• 更新内容を透明にします。 変更内容を日付付きで記載します。古くなったベスト製品記事が気づかれないまま劣化することは、このカテゴリで最もよくある問題の1つです。変更内容を記した日付付きの行があれば、他の記事より優れたものになります。

---

Google のレビューシステムとの整合性

このガイダンスでは、実証された実体験、または実証可能な独自の調査と分析が求められます。後者はこのスキルの対象であり、「独自の分析」とは具体的な成果物を指します。

• 統合そのもの：単一の情報源には含まれない、所有者の使用経験の傾向
• 検証済みデータを使い、明示された評価基準に沿って構成した比較表
• 意思決定の枠組み：各おすすめがどのような人に適しているか、また適していないか
• 言い換えただけの仕様書は該当しません：メーカーの箇条書きを並べ替えても、経験にも分析にもならず、評価もそれに応じたものになります

ガイダンスが定めるティア 2 および 3 の作業を誠実に行うサイトは、その定義に照らして独自の分析を行っています。その成果を示すのが方法論ブロックです。

---

FTC との整合性

アフィリエイト関係は平易な言葉で開示し、おすすめの掲載箇所に記載します。フッターには置きません。開示は収益化されたコンテンツと一緒に掲載します。おすすめの近く、本文と同程度の文字サイズで、読者が利用できる最初のアフィリエイトリンクの前か横に置きます。「平易な言葉」とは、アフィリエイトという言葉を初めて聞く読者でも、サイトが報酬を得ることと、読者が支払う価格は変わらないことを理解できる表現を意味します。「パートナーリンク」や「サイトを応援」といった婉曲表現は、平易な言葉という基準を満たしません。

---

スキーマの判断

マークアップは主張です。構造化データにも、文章と同じ誠実さを適用します。

• Review および Product のマークアップは、記事の主張がマークアップの内容を裏付ける場合に限って使用します。Review マークアップは、レビュー担当者が評価した項目についての評価レビューを主張するものです。ティア 1〜3 の購入ガイドに、実地検証を行ったかのようなレビュー用マークアップを付けるのは、禁止された主張を機械可読な形式で表明することになります。
• 実地検証を行っていない購入ガイドには、ガイドに適したマークアップを使用します。おすすめには ItemList、記事には Article を使用します。
• ティア 4 の実地検証を実際に行い、その旨を明記している場合は、Review マークアップを誠実に使用できます。その場合はテンプレートの既定値としてではなく、記事ごとに追加します。

---

ワークフロー

1. 根拠を正直に棚卸しします。 このカテゴリーで実際に利用できるティアは何ですか。実機での検証はありますか。ある場合はどのようなものですか。
2. まず評価基準を設定します。 製品を検討する前に順序も含めて決め、特定の候補に合わせて基準がひそかに変わることがないようにします。
3. ティアごとに情報を集めます。 仕様を一次情報で確認します。所有者のコーパスを大規模に収集し、サンプル数を記録します。意見の相違も含め、専門家の情報源を明示して集めます。
4. 統合します。 基準ごとの調査結果、各候補の欠点、意見の相違を提示します。
5. 実際に行ったことに基づいて方法論のブロックを作成します。よく見える内容ではなく、実施した内容を記載します。
6. 主張に合わせてマークアップを選びます。 通常は ItemList と Article を使い、ティア 4 を満たす場合にのみ Review を使います。
7. 継続して更新します。 更新日を記録し、変更点を明記します。実機での検証ができるようになったら該当箇所をアップグレードし、その旨を示します。

---

よくある失敗パターン

• 「テストしました」の誇張。 基本ルールへの違反です。それに、実際の作業を読者が比較すれば、偽のテストより正直な統合のほうが優れているため、そもそも必要ありません。
• アグリゲーターの仕様。 他のレビューからコピーした仕様表には、古い情報も混在しています。メーカーのページで確認するか、数値を公開しないでください。
• 統合を装った逸話。 フォーラム投稿が 3 件あっても、大規模な所有者の使用経験とはいえません。サンプル数を明記するか、主張の確度を下げてください。
• 専門家の意見の平均化。 相反する専門家の判定の中間を取ると、最も有益な情報、つまり信頼できるテスター間に意見の相違があり、その理由は何か、が失われます。
• 欠点のない候補。 明示された欠点のない推奨は、広告と同じ構成になっているため、広告のように読めます。
• 後付けの実機検証。 古い統合記事を、最初からテスト済みだったかのようにひそかに書き換えることです。アップグレードして明記するパターンがあるため、そのようなことをする必要はありません。
• フッターでの開示。 読者が探し回らなければ見つからないアフィリエイト開示は、FTC の掲載位置に関する期待にも、開示が担う信頼の目的にも反します。
• スキーマの過剰適用。 統合コンテンツに Review マークアップを使うことです。記事の本文は正直なのに、マークアップが嘘をついています。

---

出力形式

方法論の設定の場合：サイトが採用する簡潔な方法論基準（ティア、サイトの情報源を記入したブロックテンプレート、スキーマの方針）を、ドキュメントや編集ガイドに適した形式で作成します。

記事単位の依頼の場合：その記事の方法論ブロック、評価基準の一覧、エビデンスファイル（ティアごとに収集した情報源とサンプル数）、およびこの記事がこのスキルの作成前から存在していた場合は主張の監査を作成します。

---

必要なデータを入手できない場合

このスキルの出力は、このスキルだけでは生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合、認められる出力は、その不足を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響があるかを示してください。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足を明記すれば、それで完全な回答です。

---

参考ファイル

• references/evidence-tiers.md - 4 つのティアの詳細：検証手順、統合の誠実さ、三角測量の実践、アップグレードして明記するパターン。
• references/methodology-block-template.md - 記事ごとに記入できる開示ブロック、記入例、掲載ルール。