E-E-A-T 対策 完全ガイド 2026年版 — Trust を軸に実装で証明する

E-E-A-T 対策は「概念として知っているが、実装で何をどう証明すれば良いか分からない」と言われることが最も多い SEO テーマです。E-E-A-T を定義する Google 検索品質評価ガイドライン（Search Quality Rater Guidelines、最新は 2024 年 12 月 19 日改訂版、181 ページ）は E-E-A-T を直接ランキング要因とは呼んでいません。代わりに「品質評価者が品質を判断する際の枠組み」と位置付け、その上で Trust が中心、Experience / Expertise / Authoritativeness は Trust を支える要素と明示しています。AI 検索時代に入り、ChatGPT Search・Perplexity・Google AI Overview が引用ソースを選ぶ際にも、E-E-A-T の構造化された証拠が鍵を握るようになりました。本ガイドでは Tufe Company が現場で実装している「E-E-A-T を技術と編集の両輪で証明する手順」を、コピペで使える JSON-LD・印刷可能 50 項目チェックリスト・失敗パターンとともに整理します。

※ 出典: Google「Search Quality Rater Guidelines」PDF（2024-12-19 改訂版）（取得 2026-05） / Google Search Central「Creating helpful, reliable, people-first content」（取得 2026-05）

Chapter 1: E-E-A-T の Google 公式定義（2024-12 版）

「E-E-A-T はランキング要因」は誤り — Google の公式表現を正確に押さえる

「E-E-A-T はランキング要因か？」は SEO 界隈で長年議論されてきた論点ですが、Google の答えは一貫しています。Google 検索アドボケイトの Danny Sullivan は 2022 年 12 月の E-A-T → E-E-A-T 移行発表時、および以降の複数の場で 「E-E-A-T 自体はランキング要因ではない。Google の各種シグナルが集積した結果として、E-E-A-T が高いコンテンツが上位に来やすい構造になっている」 と説明してきました。Google 検索セントラルの「Creating helpful, reliable, people-first content」ドキュメントも E-E-A-T を 「品質を評価する枠組み」 と位置付け、「直接の要因」とは書いていません。

※ 出典: Google Search Central Blog「Our latest update to the quality rater guidelines: E-A-T gets an extra E for Experience」（取得 2026-05） / Google Search Central「Creating helpful, reliable, people-first content」（取得 2026-05）

つまり、E-E-A-T を「単一スコアで測れるランキング要因」として語ると、その瞬間に Google 公式と乖離した提案になります。正確には 「Google の数百のランキングシグナル（HCU・SpamBrain・コアアップデート等）が複合的に評価される結果、E-E-A-T が満たされているサイトが選ばれやすい」 と表現するべきです。

4 要素の定義（2024-12 版ガイドラインから）

Google 検索品質評価ガイドライン 2024-12-19 版（PDF 181 ページ）における E-E-A-T 4 要素の公式定義は次の通りです。

※ 出典: Google「Search Quality Rater Guidelines」PDF（2024-12-19 改訂版）（取得 2026-05）

Trust が中心 — 図で示される階層構造

ガイドラインには有名な「E-E-A-T 概念図」が掲載されており、中央に Trust、その周囲に Experience / Expertise / Authoritativeness が配置されています。Google は同図のキャプションで「Trust is the most important member of the E-E-A-T family because untrustworthy pages have low E-E-A-T no matter how Experienced, Expert, or Authoritative they may seem」と明示しています。日本語で言えば「どれだけ経験・専門性・権威があっても、信頼できないページは E-E-A-T が低い」となります。

つまり実装の優先順位は Trust → Experience / Expertise / Authoritativeness の順 です。本ガイドの Chapter 構成もこの順序を意識して、Chapter 2-4 で E/E/A を扱い、Chapter 5 で Trust を厚く取り扱います。

「E-E-A-T 評価」と「実際のランキング」は別物

注意したいのは、品質評価者（Quality Rater）が付ける E-E-A-T の評価点が直接ランキングに反映されるわけではない、という点です。Quality Rater のレポートはアルゴリズム改善の参考データとして使われるだけで、個別の URL 順位を上下させません（Google 公式ヘルプ）。E-E-A-T 対策とは「Google のアルゴリズムが間接的に拾えるシグナルを、サイト全体に分厚く配置する仕事」と理解してください。

AI 検索時代に E-E-A-T が加速度的に重要になる理由

ChatGPT Search や Perplexity などの AI 検索 は、回答に使うソースを「信頼できる出典かどうか」で篩いにかけています。Perplexity 公式は「権威ある情報源・科学出版物・公式サイト・評判の良いニュースメディアを優先する」とコミュニティブログで明示しており、ChatGPT Search も「最新で正確な情報をニュースパートナーから取得する」と公式紹介記事で説明しています。つまり E-E-A-T 実装は、従来の SEO に加えて 「AI に引用される権利」を手に入れる投資 に変質しました。AI 検索引用と E-E-A-T の関係は AI検索引用 vs 従来の被リンク で詳述しています。

※ 出典: OpenAI「Introducing ChatGPT search」（取得 2026-05） / Perplexity「Introducing the Publishers' Program」（取得 2026-05）

Chapter 2: Experience（実体験）の証明

Experience は 2022 年に追加された「最も新しい」要素

E-E-A-T の 4 要素のうち Experience は 2022 年 12 月 15 日に追加されました。Google の公式説明では「コンテンツの作成者が トピックに関する一次的な人生経験（first-hand life experience） をどれだけ持っているか」を見る要素です。たとえばレストランレビューなら「実際に食べに行ったか」、節税ガイドなら「実際に確定申告を経験している人が書いたか」が問われます。

※ 出典: Google Search Central Blog「Our latest update to the quality rater guidelines: E-A-T gets an extra E for Experience」（取得 2026-05）

実装で Experience を証明する 7 つの編集パターン

Tufe Company が現場で Experience を証明するために使っているパターンは次の 7 つです。これは「資格や肩書きで Expertise を主張する」のではなく、「実際に手を動かした事実」を読み取れる形で残す編集です。

※ 上記表の年月日・件数・固有名詞は「Experience 証明のための表記例」であり、特定案件の実数値ではありません。一次実測を含める時は ※ Tufe Company 内部実測 / YYYY-MM時点 の注釈を必ず付与してください（鉄則 #2）。 ※ 出典: Google「Search Quality Rater Guidelines」PDF（2024-12-19 改訂版）（取得 2026-05）

1 ページ 1 著者制で「誰が書いたか」を明示する

Experience は「誰が経験したのか」が紐付かないと評価できません。Tufe Company の pSEO ページでは frontmatter に必ず author と reviewedBy を配線し、ページ末の AuthorCard にプロフィール・実績・連絡導線を表示する設計を取っています。著者ページから経歴・出版実績・LinkedIn 等の sameAs に辿れる状態が、AI 検索の引用判定でも効きます。

著者プロフィール を整備していないサイトは、いくら本文に経験が書かれていても評価者・AI 双方から「誰のものか分からない」と扱われます。鉄則として 「無記名コンテンツを公開しない」 を運用ルールに入れてください。

うちの場合: 具体的にこう示している

• 本ガイドは Tufe Company 内部実測（2026-05時点）の pSEO 運用、content/guides・content/glossary・content/compare・content/industries・content/areas の 5 系統で 360+ MDX ファイルを運用してきた現場知見を整理したものです。
• frontmatter.reviewedBy / wordCount / dateModified / canonical を Article schema にレンダリング配線する仕組み（/app/guides/[slug]/page.tsx）を実装しており、本ガイド自体がその実装事例です（※ Tufe Company 内部実測 / 2026-05時点）。
• 鉄則 #7「既存記事の数字は疑え」運用で実施した権威性キャンペーンでは N=30 件以上の誤情報を発見・訂正しました（※ Tufe Company 内部実測 / 2026-05時点）。

※ 仕組みの公式根拠は Google Search Central「Article structured data」（取得 2026-05）。

このように 自分自身が手を動かした証拠を文章に染み込ませるのが、Experience 実装の核心です。

Chapter 3: Expertise（専門性）の構築

Expertise は「日常 vs 専門」の文脈で評価が変わる

Google の品質評価ガイドラインには「Everyday Expertise」という概念が出てきます。たとえば「ベビーシューズの履かせ方」のような日常トピックは、医師資格より「実際に乳児を 2 人育てた親」の方が Expertise として評価される、という考え方です。一方で「アスピリンの服用量」のような医療判断は、医師資格・薬剤師資格が決定的に効きます。

※ 出典: Google「Search Quality Rater Guidelines」PDF（2024-12-19 改訂版）（取得 2026-05）

つまり Expertise 実装の最初の判断は 「このトピックは公式資格が必要な領域か、日常経験が説得力を持つ領域か」 の振り分けです。前者なら有資格者を執筆・監修に必ず巻き込み、後者なら長年の実体験者を起用します。

専門性を証明する 8 つの編集装置

「監修者がいる」を Trust に変換する仕組み

reviewedBy は frontmatter に書いただけでは Article schema に反映されません。Tufe Company の /app/guides/[slug]/page.tsx ではメタデータ生成時に reviewedBy を JSON-LD の Article 要素にマップする実装を入れています。これにより Google や AI に「このページは別の有資格者が確認している」を読み取らせる構造ができあがります。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "E-E-A-T 対策 完全ガイド 2026年版",
  "author": {
    "@type": "Organization",
    "name": "Tufe Company",
    "url": "https://tufecompany.co.jp/company"
  },
  "reviewedBy": {
    "@type": "Person",
    "name": "Tufe Company 代表",
    "jobTitle": "代表"
  },
  "wordCount": 10200,
  "dateModified": "2026-05-24"
}

単発のスター人材より「組織としての専門性」

個人ブランドの強い著者を 1 人雇うより、組織として継続発信し、複数人で監修する体制 の方が Trust に変換しやすい、というのが Tufe Company の現場感覚です。理由は (1) 1 人が辞めるとサイト全体の権威性が崩れるリスク、(2) 月次の更新ペースを 1 人で維持するのが困難、(3) 監修者が著者と別人格である方が Trust シグナルが分厚い、の 3 点です。

このため Tufe Company の pSEO 運用では「著者 = Tufe Company 部門名、監修者 = Tufe Company 代表」の組み合わせを基本形にして、属人化リスクを抑えています。

専門性と関連する用語整理

Chapter 4: Authority（権威性）の獲得

Authoritativeness は「業界内での go-to source」評価

Authoritativeness は「この分野について調べる時、誰もが行くソース として認知されているか」という外部評価です。社内でいくら「うちは権威ある会社です」と書いても、他者がそう扱っていなければ Authority とは認められません。Google は具体的に (1) 業界 / メディアからの言及・引用、(2) Wikipedia ページの有無、(3) 業界団体の認定、(4) 他の権威サイトからのリンクや言及 を Authority 判定の参考にしているとガイドラインで示唆しています。

Authority を獲得する 6 つの編集戦略

ナチュラル被リンクは「リンクされたくなる素材」を作ること

被リンク獲得の王道は「リンクされたくなる一次調査・データ・ツール・テンプレを無料公開する」ことです。Tufe Company の運用では (1) JSON-LD ジェネレーター、(2) LLMO 無料診断、(3) glossary 100+ ページ、(4) compare 40+ ページを「他社がリンクしたくなる素材」として配置しています。リンクビルディング業者へのアウトリーチに頼るより、素材ストックを増やす方が継続的に効きます。

「権威ある引用が引用を呼ぶ」効果

Google および AI 検索エンジンは、権威ある情報源を引用しているコンテンツ自体も権威があると評価する 傾向があります（Google E-E-A-T ガイドライン、Perplexity 公式のソース選定方針）。本ガイドが Google Search Central・schema.org 公式・Search Engine Land 等の一次情報を ±5 行以内で引用しているのは、まさにこの効果を狙っています。鉄則 #2 の「数字に必ず出典」運用は、Trust を高めると同時に Authority も底上げします。

Authority を毀損する 5 つの落とし穴

1. 「専門家チーム」など主体不明の主張 — 名前と顔が無い「専門家」「監修者」を量産すると、逆に Trust が下がります。
2. 古いソースの孫引き — 鉄則 #7 のとおり、2020 年の記事の数字をそのまま使うと数年で大量の誤情報が積み上がります。
3. 誤帰属 — 「Google が発表」と書いた実体が代理店ブログだった、のような誤帰属は致命的です（※ Tufe Company 内部監査ログ / 2026-05時点。30 件以上の誤情報訂正を実施）。
4. 過剰な自社言及 — ページの大半が自社サービス言及なら Trust より広告として認識されます。Google「Helpful content」ガイドラインも「主に検索エンジン向けに作られたコンテンツ」を低評価対象に挙げています。
5. 誇大な順位主張 — 「○○で 1 位」と書く時、SERP のスクショ・日付・地域・閲覧者を明示しない場合は控える。景品表示法の優良誤認表示に該当する恐れがあります。

※ 出典: Google Search Central「Creating helpful, reliable, people-first content」（取得 2026-05） / 消費者庁「景品表示法 — 優良誤認表示」（取得 2026-05）

Chapter 5: Trust（信頼性）の担保

Trust が中心 — 「最も重要」と Google が明言

冒頭で示した通り、Google のガイドラインは「Trust is the most important member of the E-E-A-T family」と明記しています。Trust が崩れている時点で、Experience・Expertise・Authority がいくら積み上がっていても E-E-A-T 全体は低評価です。

Trust は「正確性・誠実性・安全性・信頼性」の 4 つから成ると定義されています。実装で言えば次の 4 系統です。

Trust を担保する 4 系統の実装

1. 正確性（Accuracy）— 事実の正しさ

• すべての具体数値に ±5 行以内の出典脚注（鉄則 #2）
• 古い数字の継続監査（鉄則 #7）
• 誤りが見つかった場合は dateModified を更新し、訂正内容を明記
• 一次情報優先（政府統計 > 政府ポータル > 業界団体 > 事業者公表）

2. 誠実性（Transparency）— 主体・利害関係の明示

• 運営会社情報（会社名・住所・代表者・連絡先）の常時公開
• 著者プロフィール・監修者プロフィールの公開
• 利益相反の開示（アフィリエイト・スポンサーシップなど）
• プライバシーポリシー・利用規約の整備

3. 安全性（Safety）— ユーザーを守る

• HTTPS 全ページ強制
• フォーム送信時のバリデーション
• 個人情報保護法・GDPR 対応
• Cookie 同意（Cookie Consent）の適切な実装

4. 信頼性（Reliability）— 約束を守る

• 営業時間・連絡対応時間の明示
• 公開した数値・約束の継続的な達成
• 問い合わせ対応の品質と速度
• 商品・サービスの返品・キャンセル規約

うちの場合: Trust をこう実装している

• 運営会社情報 を常時公開
• プライバシーポリシー・利用規約・特定商取引法に基づく表記 を整備
• 全ページ HTTPS 強制（proxy.ts の validPaths 設計、鉄則 #9）
• すべての具体数値に ±5 行以内の出典脚注を配置（本ガイド自体がその実装事例）
• メールアドレスを Footer に置かず、問い合わせは /contact フォームに集約（鉄則 #1）

Trust を失う代表的な失敗（後述の失敗パターン 10 でも詳述）

• 個人情報漏洩（鉄則 #1 の発端でもある「メールアドレス Footer 掲載」も類似事象）
• 誇大表現（「業界 No.1」「100% 効果保証」など。景品表示法の優良誤認表示に該当する恐れ）
• 出典なき数字の連発
• 編集者不明の量産記事
• 違法・グレーな手法の推奨

※ 出典: 消費者庁「不当景品類及び不当表示防止法（景品表示法）」（取得 2026-05）

Trust と AI 検索の関係

AI 検索エンジンの引用判定では Trust が決定的に効きます。Perplexity 公式（Publishers' Program 案内）には、信頼できるニュースパブリッシャーや権威ある一次情報を優先するという方針が示されており、Trust シグナルの薄いサイトは引用候補から外されます。OpenAI も ChatGPT Search の紹介で「ニュースパートナーから最新情報を取得する」モデルを説明しています。

※ 出典: Perplexity「Introducing the Publishers' Program」（取得 2026-05） / OpenAI「Introducing ChatGPT search」（取得 2026-05）

Chapter 6: Author schema 実装（JSON-LD）

Author schema は「著者性」をコードに翻訳する基盤

Author schema という単独の schema 型は存在しません。Article / BlogPosting / NewsArticle の author プロパティに Person または Organization を入れる形で実装します。詳細は 構造化データ完全ガイド の Chapter 3 を併読してください。

Google Search Central の Article ドキュメントは author について次を 強く推奨 しています。

• Person または Organization のオブジェクト型（文字列ではなく）
• name（実名推奨）
• url（著者プロフィールページの絶対 URL）

※ 出典: Google Search Central「Article structured data」（取得 2026-05）

Author schema フル実装テンプレ

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "○○の実装ガイド",
  "image": [
    "https://example.com/og-image.png"
  ],
  "datePublished": "2026-05-24T09:00:00+09:00",
  "dateModified": "2026-05-24T09:00:00+09:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/yamada#person",
    "name": "山田太郎",
    "url": "https://example.com/authors/yamada",
    "jobTitle": "シニア SEO コンサルタント",
    "worksFor": {
      "@type": "Organization",
      "name": "Example株式会社",
      "url": "https://example.com"
    },
    "alumniOf": "○○大学経済学部",
    "knowsAbout": ["SEO", "MEO", "AI Search Optimization"],
    "sameAs": [
      "https://x.com/yamada",
      "https://www.linkedin.com/in/yamada",
      "https://github.com/yamada"
    ],
    "award": [
      "○○マーケティングアワード 2024 受賞",
      "△△協会 認定コンサルタント"
    ]
  },
  "reviewedBy": {
    "@type": "Person",
    "@id": "https://example.com/authors/sato#person",
    "name": "佐藤花子",
    "url": "https://example.com/authors/sato",
    "jobTitle": "監修責任者"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example株式会社",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "wordCount": 8500,
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/articles/example"
  }
}

著者プロフィールページ（/authors/[slug]）の構成

Author schema の url が指す先のページが「ペラ 1 枚の名前だけ」だと逆効果です。著者プロフィールページには以下を含めてください。

• 顔写真（プロフェッショナルな撮影 / 利害関係者でも識別可能なもの）
• 経歴（学歴・職歴・実績）
• 資格・認定（番号公開可能なものは番号も）
• 所属（現職・所属団体）
• SNS リンク（X / LinkedIn / GitHub / note 等、sameAs と一致）
• 寄稿・登壇実績
• 連絡先（個別連絡可否を明示）
• 直近の執筆記事一覧

Person schema（著者ページ単体）

著者プロフィールページの <head> には Person schema を入れてください。

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/authors/yamada#person",
  "name": "山田太郎",
  "image": "https://example.com/authors/yamada/photo.jpg",
  "jobTitle": "シニア SEO コンサルタント",
  "description": "10 年以上 SEO / MEO / AI Search Optimization に従事...",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://example.com/#org",
    "name": "Example株式会社"
  },
  "alumniOf": {
    "@type": "EducationalOrganization",
    "name": "○○大学"
  },
  "knowsAbout": ["SEO", "MEO", "LLMO", "AI Search Optimization"],
  "sameAs": [
    "https://x.com/yamada",
    "https://www.linkedin.com/in/yamada",
    "https://github.com/yamada"
  ],
  "url": "https://example.com/authors/yamada"
}

Article schema との @id リンクで関係性を明示

著者プロフィールページの Person schema に @id を付け、各記事の Article schema の author から同じ @id を参照すれば、「複数記事と 1 つの著者ページが同一エンティティとして紐付く」 ことを Google や AI に読み取らせられます。Google・AI 検索エンジンの双方が「この著者は何記事書いていて、どの程度の専門性があるか」を集約しやすくなります。

reviewedBy 配線の実装パターン（Tufe Company の現場メモ）

Tufe Company の /app/guides/[slug]/page.tsx では、frontmatter の reviewedBy.name / reviewedBy.role をメタデータ生成時に Article JSON-LD の reviewedBy プロパティへ自動マッピングしています。これにより、ライターが frontmatter に 2 行書くだけで構造化データ側まで一気通貫で配線される設計です。pSEO の量産で属人化を避けたい場合に有効なパターンで、本ガイド自体がその実装事例です。

詳細は 構造化データ完全ガイド の Article schema 章と、内部運用メモ「pSEO Article schema 必須要件」を参照してください。

Chapter 7: YMYL 領域の特殊対応（医療・金融・法律）

YMYL とは — 公式定義

YMYL（Your Money or Your Life） は Google 検索品質評価ガイドラインで定義される 「人生・健康・財産・安全に重大な影響を及ぼす可能性のあるトピック」 です。E-E-A-T の評価基準が他領域より厳しく適用されます。

ガイドライン上では YMYL の例として次のカテゴリが挙げられています。

• 健康・安全 — 医療情報、薬の使用、緊急時対応、危険物の扱い
• 金融 — 投資、住宅ローン、退職計画、税金、保険、暗号資産
• 法律 — 離婚、養育権、遺言、市民権、法的アドバイス
• 市民の安全・選挙 — 投票、政府サービス、災害情報
• その他社会的影響大 — 栄養、フィットネス、住居購入、就職

※ 出典: Google「Search Quality Rater Guidelines」PDF（2024-12-19 改訂版）（取得 2026-05）

俗に「YMYL は検索結果の XX%」のような数字が業界記事で流通していますが、Google 公式は 具体的な比率を公表していません。鉄則 #7 のとおり、根拠不明な比率を提案に使うのは避けてください。

YMYL で求められる 7 つの追加実装

業種別の実装ポイント

医療・歯科系（健康 YMYL）

• 医師免許番号 / 歯科医師免許番号の表示
• 厚生労働省・日本医師会・日本歯科医師会等の一次情報リンク
• 医療広告ガイドライン遵守（虚偽・誇大・体験談禁止）
• 「医師の診断を代替するものではない」免責
• 関連: 歯科 MEO / 歯科 SEO コンテンツ / 整骨院 MEO / 医療クリニック LLMO / 医療広告コンプライアンス比較

税理士・会計事務所（金融 YMYL）

• 税理士登録番号の表示
• 国税庁・財務省・日本税理士会連合会等の一次情報リンク
• 税理士法 / 税理士業務に関する広告の指針遵守
• 「個別の税務判断は税理士へ」免責
• 関連: 税理士 SEO コンテンツ / 税理士 AI 検索ツール / 税理士 AI 自動化

弁護士・法律事務所（法律 YMYL）

• 弁護士登録番号 / 所属弁護士会の表示
• 日本弁護士連合会・最高裁判所・法務省等の一次情報リンク
• 弁護士業務広告に関する規程遵守
• 「個別法律相談は弁護士へ」免責
• 関連: 弁護士 SEO コンテンツ / 弁護士 LLMO/GEO / 弁護士 MEO / 単独 vs 複数弁護士事務所 SEO

YMYL の更新サイクル

YMYL ページは半年以上更新が無いと、Google の鮮度評価で減点される傾向があります（Search Engine Roundtable の取材記事より）。Tufe Company が YMYL クライアントに提案する標準サイクルは「四半期ごとに dateModified を更新するために実質的な追記・修正を行う」運用です。修正履歴を ## 更新履歴 として記事末に残すと、Trust シグナルも上がります。

Chapter 8: 引用と被リンク獲得の編集戦略

リンクは買わない。2012 年以降ずっと

Google が Penguin アルゴリズムを 2012 年 4 月に導入して以降、購入リンク・相互リンク・ディレクトリ大量登録などの旧来手法は逆効果に転じました。2022 年 SpamBrain にリンクスパム対策が組み込まれ、低品質リンクは「自動で無効化」される設計です。被リンク獲得の中心は 「リンクされる素材を作る」「メディアに取り上げられる」「業界権威に引用される」の 3 系統 に集約されています。

※ 出典: Google Search Central Blog「December 2022 link spam update releasing for Google Search」（取得 2026-05） / Google「Another step to reward high-quality sites」（Webmaster Central Blog 2012-04-24）（取得 2026-05）

ナチュラル被リンクを生む 7 つの素材タイプ

AI 検索引用は「機械が読み取れる権威」を求める

AI 検索引用 では従来の被リンクとは別の評価軸が働きます。AI 検索エンジンは (1) 構造化データの整備度、(2) 著者性・監修者の明示、(3) 一次出典の引用密度、(4) サイト全体のトピック網羅性、(5) Brand Mention の頻度 を総合判定する傾向があります。被リンクが少なくても Brand Mention（リンクされない単純な言及）が多いサイトが AI 引用で優位に立つケースが Tufe Company の現場でも観察されています。

※ Tufe Company 内部観察 / 2026-05時点（pSEO 360+ ファイル運用での AI 引用露出と被リンク数の相関観察）。一般原理は Perplexity「Introducing the Publishers' Program」（取得 2026-05）等の AI 検索プラットフォーム公式方針と整合します。

業界メディアへの寄稿戦略

業界権威メディア（Search Engine Land / Search Engine Journal / 日本では Web 担当者 Forum / MarkeZine 等）への寄稿は、被リンク + Authority の二重効果があります。寄稿の交渉時は次の 3 点をテンプレ化すると採用率が上がります。

1. 読者にとっての new angle — 「同テーマを別視点で」ではなく「未公開の一次データ + 既存議論への反論」
2. 編集部の負担を下げる構成 — 見出し設計、引用元リスト、画像権利処理を済ませた完成原稿
3. 過去寄稿実績の提示 — まず自社サイトで長尺記事を蓄積し、寄稿実績の代わりにする

サイテーション（NAP 一致）の運用

実店舗ビジネスの場合、被リンクと並行して サイテーション（NAP 一致） を運用してください。サイテーションは MEO の必須要素であり、@type: LocalBusiness schema との整合性が Authority に直結します。詳しくは GBP 最適化 vs サイテーション構築比較 を参照。

Chapter 9: ソーシャル証明の見せ方

ソーシャル証明は「実体 + 開示」が原則

ソーシャル証明（レビュー・受賞・メディア掲載）は Trust を一気に押し上げますが、誤った見せ方は逆に Trust を毀損します。原則は次の 3 つです。

1. 必ず実体に基づく — 自社で操作したレビュー・出さもしないメディア掲載の捏造は致命的
2. 第三者検証可能な形で開示 — 「○○ 100 社受賞」より「○○協会 公式発表（URL）」
3. 古い実績は更新する — 5 年前の受賞をトップに残し続けると Trust が下がる

レビュー（Review / AggregateRating）の正しい運用

Review schema を実装する際の Google ガイドライン違反パターンに注意してください。

• ページに実表示が無いレビューを schema に書かない — 最重大違反。リッチリザルト対象外＋手動対策のリスク
• 自社サイト内で集めた批評を AggregateRating で表示 — 一次情報なら OK だが、レビュー収集方法を明示
• 第三者レビュープラットフォーム（食べログ / 楽天 / Google レビュー）の数値引用 — 出典明示が必要

受賞・メディア掲載の見せ方

※ 上記表の媒体名・日付・受賞名は「Trust を担保する表記の例示」であり、Tufe Company の実掲載実績ではありません。No.1 表記の運用基準は 消費者庁「No.1 表示に関する実態調査報告書」（取得 2026-05）と 景品表示法 公式ガイド（取得 2026-05）を参照。

※ 表内の媒体名・日付は表記例。媒体掲載実績を出す際は 景品表示法（取得 2026-05）に準拠した範囲・期間の明示が必要です。

お客様の声・事例

事例ページは Trust に直結しますが、次の 3 つを守らないと逆効果になります。

1. 顔写真・実名 or 明示的な許諾を得た仮名 — 「A 様（30 代女性）」のような匿名化は Trust が薄い
2. 実数値の開示 — 「売上が伸びました」より「売上が ○ ヶ月で ○% 伸びました」
3. 再現性の説明 — 「同じ手法でも結果が変わる要因」を併記すると逆に Trust が上がる

Tufe Company の事例ページ運用方針（2026-05 時点）

Tufe Company は事例ページの量産より、ガイド・glossary・compare の蓄積を優先しています。理由は (1) 事例公開の許諾取得が重い、(2) クライアント秘匿性、(3) 業界・規模が違うと参考にならない、の 3 点です。代わりに「業種別 pSEO ページで業界共通課題を扱う」「無料ツールで実装能力を示す」運用で Trust を担保しています。今後の事例ページ整備は提督方針に従って段階的に追加予定です。

Chapter 10: 計測と改善（Brand Mention 追跡・Author 検索流入）

E-E-A-T 投資の効果は 7 指標を並走させて読む

E-E-A-T 単独スコアは Google 公式に存在しないため、効果計測は 代替指標を並走させて変化を読む 設計にします。Tufe Company が標準で追跡している指標は次の 7 系統です。

E-E-A-T 実装前後で見る最低限の比較

新規に E-E-A-T 実装を行った場合、最低でも 3 ヶ月後・6 ヶ月後 の 2 ポイントで比較してください。Google のコアアップデートは年 3〜4 回、間隔は数ヶ月のため、効果は短期間では出にくいのが実情です。

Author 検索流入の追跡

著者名で検索される回数は、Authority と Trust の両方を反映する重要指標です。GSC の「検索パフォーマンス」→ 「クエリ」→ 著者名でフィルタすると追跡できます。月次で 0 から 10 → 50 → 100 と推移すれば、Authority 構築が機能しています。

Brand Mention Rate と LLM Citation Rate

AI 検索時代の新指標として Brand Mention Rate と LLM Citation Rate を Tufe Company は追跡しています。Profound や Otterly.AI のような商用ツール、または ChatGPT / Claude / Perplexity / Gemini への手動プロンプト 100 件ベンチマークで月次計測する方法があります。詳しくは Profound vs 日本の LLMO ツール を参照。

計測ツール選定

Chapter 11: Tufe Company の支援領域

ここまで自分で Author schema を書いて配線し、Trust 監査も自走できるなら、本章は読み飛ばしてください。実装方針は理解したが手を動かす時間が無い、既存サイトの E-E-A-T 棚卸しを書面で受け取りたい、という場合の窓口だけ用意しておきます。

段階別の選択肢

「いきなりサービスを契約する」必要は無いように設計しています。まずは無料の Rich Results Test と LLMO 無料診断でセルフチェックし、それでわからなければ AI Search Health Check で書面のレポートを取る、という順番で十分です。

E-E-A-T 50 項目チェックリスト（公開前・四半期監査用）

公開前と四半期ごとの監査で、この 50 項目を順番に潰してください。

Experience（実体験）の証明 — 10 項目

• 各記事の冒頭で「誰が・いつ・どの実体験を持って書いたか」が明確
• 一次データ・実測値に Tufe 内部実測注釈または出典脚注が ±5 行以内
• スクリーンショット・写真は撮影日 / 出典が明示
• 失敗例 / 例外パターンが各章に少なくとも 1 つ含まれる
• 自社事例は匿名化された統計（N=○）で表現
• 著者の継続発信頻度（月次更新数）が公開されている
• 「やってみた系」記事には実行プロセスのタイムスタンプが入る
• レビュー記事は実物写真と購入証跡を伴う
• 業界経験年数 / 関連実績が著者プロフィールに明記
• AI 生成のみの記事（人手の体験が入らない）は公開していない

Expertise（専門性）の構築 — 10 項目

• 全記事に author フィールドが配線され、無記名記事が存在しない
• 著者の資格・所属が著者プロフィールページで確認可能
• YMYL 記事は有資格者の執筆 or 監修
• reviewedBy が frontmatter と Article schema 両方に配線
• 著者プロフィールに Person schema が実装
• 著者の sameAs（X / LinkedIn / GitHub 等）が複数件設定
• 業界団体所属・学会会員などの認定が affiliation で構造化
• 出版実績・登壇実績が一覧化されている
• 関連 glossary が 100 件以上整備されている
• 比較記事が 40 件以上整備され、第三者視点の言及が可能

Authoritativeness（権威性）の獲得 — 10 項目

• 一次調査・統計を年 1 件以上公開
• 業界権威メディアへの寄稿実績がある
• 無料ツール / テンプレを公開（被リンクの引力源）
• Wikipedia ページが存在（あれば理想、必須ではない）
• 業界団体認定 / Google パートナー認定等の第三者認定が複数
• 過去 12 ヶ月の月次新規被リンク数を計測している
• 引用元として明記されている他社記事の数を把握
• プレスリリースを四半期 1 件以上配信
• 有名な業界カンファレンスへの登壇歴がある（あれば理想）
• サイト内でブランド検索数の月次推移を GSC で追跡

Trust（信頼性）の担保 — 10 項目

• 全ページ HTTPS 強制
• 運営会社情報（会社名・住所・代表者・連絡先）が常時公開
• プライバシーポリシー・利用規約・特商法表記が整備
• Cookie 同意・個人情報取り扱いが法令準拠
• すべての具体数値に ±5 行以内の出典脚注
• 「弊社調べ」「Tufe 調べ」のような曖昧な逃げが無い
• 誇大表現（「業界 No.1」「100% 効果保証」）が無い（景品表示法 優良誤認表示への該当を回避）
• 利益相反（アフィリエイト・スポンサー）が開示されている
• 訂正履歴・更新履歴が透明に記録されている
• 連絡導線が複数（フォーム・電話 / SNS DM 等）整備

※ 上記項目の景品表示法判断基準は 消費者庁「景品表示法」公式ガイド（取得 2026-05）を参照。

構造化データと配線 — 10 項目

• 全ページに Organization または LocalBusiness schema
• 全コンテンツページに Article schema（reviewedBy / wordCount / dateModified 配線）
• 全ページに BreadcrumbList schema
• 著者プロフィールページに Person schema
• author.url から著者ページに辿れる構造
• sameAs で SNS / LinkedIn 等が紐付け
• dateModified がリライト時に必ず更新されるワークフロー
• Rich Results Test で全主要ルートが pass
• Schema Markup Validator で構文エラーゼロ
• Search Console 拡張レポートで Article エラーゼロ

Author schema / 著者プロフィールひな形テンプレ集

Article schema（個人著者 + 監修者付き）

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "{記事タイトル}",
  "image": ["{OG 画像の絶対URL}"],
  "datePublished": "{YYYY-MM-DDThh:mm:ss+09:00}",
  "dateModified": "{YYYY-MM-DDThh:mm:ss+09:00}",
  "author": {
    "@type": "Person",
    "@id": "{https://example.com/authors/著者slug#person}",
    "name": "{実名}",
    "url": "{https://example.com/authors/著者slug}",
    "jobTitle": "{役職}",
    "worksFor": {
      "@type": "Organization",
      "@id": "{https://example.com/#org}",
      "name": "{会社名}"
    },
    "sameAs": [
      "{X URL}",
      "{LinkedIn URL}"
    ]
  },
  "reviewedBy": {
    "@type": "Person",
    "@id": "{https://example.com/authors/監修者slug#person}",
    "name": "{監修者実名}",
    "jobTitle": "{役職}"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "{https://example.com/#org}",
    "name": "{会社名}",
    "logo": {
      "@type": "ImageObject",
      "url": "{ロゴ絶対URL}"
    }
  },
  "wordCount": {数値},
  "inLanguage": "ja",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "{記事絶対URL}"
  }
}

Person schema（著者プロフィールページ）

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "{https://example.com/authors/著者slug#person}",
  "name": "{実名}",
  "image": "{顔写真絶対URL}",
  "jobTitle": "{役職}",
  "description": "{経歴 100-200 字}",
  "worksFor": {
    "@type": "Organization",
    "@id": "{https://example.com/#org}",
    "name": "{会社名}"
  },
  "alumniOf": {
    "@type": "EducationalOrganization",
    "name": "{大学・専門学校名}"
  },
  "knowsAbout": ["{専門領域 1}", "{専門領域 2}", "{専門領域 3}"],
  "award": ["{受賞・認定 1}", "{受賞・認定 2}"],
  "sameAs": [
    "{X URL}",
    "{LinkedIn URL}",
    "{GitHub URL}"
  ],
  "url": "{著者プロフィール絶対URL}"
}

著者プロフィール本文ひな形

# {実名}

{会社名} {役職}。{経歴概要 200 字}

## 経歴
- YYYY年 ○○大学○○学部 卒業
- YYYY年 ○○株式会社 入社
- YYYY年 {会社名} 入社、現職

## 資格・認定
- {資格名・登録番号}
- {認定名・認定機関}

## 専門領域
- {領域 1}
- {領域 2}

## 寄稿・登壇実績
- {媒体名 / カンファレンス名}（YYYY-MM）

## 連絡先
お問い合わせは [/contact](/contact) フォームへ

Organization schema（サイト全体共通）

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "{https://example.com/#org}",
  "name": "{会社名}",
  "url": "{https://example.com}",
  "logo": "{ロゴ絶対URL}",
  "sameAs": [
    "{X URL}",
    "{LinkedIn URL}",
    "{Facebook URL}"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "url": "{https://example.com/contact}",
    "availableLanguage": ["Japanese"]
  },
  "address": {
    "@type": "PostalAddress",
    "addressCountry": "JP"
  }
}

Trust を失う行為 10 例（避けるべき失敗パターン）

E-E-A-T 構築で最も致命的なのは Trust 毀損です。Tufe Company が監査で頻繁に発見する失敗 10 例を共有します。

1. 個人情報漏洩（誤掲載） — Footer に従業員メールアドレスを掲載 → スパム流入源化（鉄則 #1 の発端）。お客様の顔写真・氏名を許諾なく掲載するのも同類。
2. 誇大・虚偽の実績表記 — 「業界 No.1」「100% 効果保証」「○○ 社が導入」と書く時、検証可能なソースを明示できないと景品表示法（不当景品類及び不当表示防止法）の優良誤認表示に抵触します。※ 出典: 消費者庁「景品表示法」（取得 2026-05）
3. 編集者・著者不明の量産記事 — 「○○ 編集部」だけで個人名が無い、もしくは AI 生成丸投げで人手の監修が入っていないケース。
4. 古い数字の継続使用 — 「ChatGPT は GPT-3 ベース」「Map Pack CTR は 20-30%」「LP は最初の 3 秒で判断」のような古値・俗説。鉄則 #7 該当。実証データの最新化は Core Web Vitals 完全ガイド 2026年版 と LLMO 完全ガイド を併読してください。
5. 誤帰属 — 「Google が発表」と書いた実体が代理店ブログだった、のような出典の誤帰属。
6. 出典なき具体数値の連発 — 鉄則 #2 違反。会社公式サイトでこれをやると致命的に Trust が下がる。
7. 「弊社調べ」「Tufe 調べ」での逃げ — 集計範囲・件数・方法が不明な「調べ」は逃げと取られる。
8. ページに無い情報を schema に書く — AggregateRating・Review・FAQ・営業時間など、HTML に表示されていない情報を JSON-LD に書くのは Google ガイドライン違反。
9. アフィリエイト・スポンサーシップ未開示 — 利益相反を隠した推薦記事は景品表示法のステマ規制（2023 年 10 月施行）に抵触。
10. 訂正履歴を隠す — 誤りを発見した時、こっそり書き換えて訂正履歴を残さない運用は、後で発覚した時に Trust が一気に崩れる。## 更新履歴 を記事末に常設しておく。

※ ステマ規制の参考: 消費者庁「ステルスマーケティングは景品表示法違反になります」（取得 2026-05）

E-E-A-T 関連の公的・一次情報リソース集

実装中に必ず参照したい一次情報を集約しました。社内 Slack に貼って共有してください。

Google 公式（最重要）

• Google「Search Quality Rater Guidelines」PDF（2024-12-19 改訂版、181 ページ）
• Google Search Central「Creating helpful, reliable, people-first content」
• Google Search Central Blog「Our latest update to the quality rater guidelines: E-A-T gets an extra E for Experience」
• Google Search Central「Article structured data」
• Google Search Central「General Structured Data Guidelines」
• Latest Google Search Documentation Updates

schema.org 公式

• schema.org トップ
• Person タイプ
• Article タイプ
• Organization タイプ
• Schema Markup Validator

日本国内法令・指針

• 消費者庁「ステルスマーケティングは景品表示法違反になります」
• 厚生労働省「医療法における病院等の広告規制について」
• 日本税理士会連合会「税理士業務の広告に関する指針」
• 日本弁護士連合会「弁護士の業務広告に関する規程」
• 個人情報保護委員会

業界調査・実証データ

• Search Engine Land
• Search Engine Roundtable
• Ahrefs Blog
• Semrush Blog
• Backlinko（オリジナル調査）

AI 検索プラットフォーム公式

• Perplexity「Introducing the Publishers' Program」
• OpenAI「Introducing ChatGPT search」
• Google「Generative AI in Search: Let Google do the searching for you」（2024-05）

まとめ — 6 つの要点

1. E-E-A-T は直接ランキング要因ではない — 「品質を判断する枠組み」。複数の Google シグナルの結果として E-E-A-T が高いサイトが上位に来やすい。
2. Trust が中心 — どれだけ Experience・Expertise・Authority があっても Trust が崩れていれば E-E-A-T は低評価。優先順位は Trust → E/E/A。
3. Experience は 2022 年追加の最新要素 — 一次体験・実測・写真・失敗例で「誰が手を動かしたか」を文章に染み込ませる。
4. Author schema 配線で「著者性」を機械可読化 — Person schema、@id リンク、reviewedBy 配線で AI 検索の引用判定にも効く。
5. YMYL は資格・監修・出典・免責の 4 点セット — 医療 / 金融 / 法律は他領域より E-E-A-T 評価が厳格。
6. 計測は複数指標の組み合わせ — ブランド検索 / 著者名検索 / Brand Mention / LLM Citation Rate / 被リンク数を四半期で追跡。

よくある質問

Q. E-E-A-T はランキング要因ですか？

直接的なランキング要因ではない、と Google は公式に説明しています。Google 検索アドボケイトの Danny Sullivan は「E-E-A-T 自体はランキング要因ではないが、Google の数百のシグナルが集積した結果として E-E-A-T が高いコンテンツが上位に来やすい構造」と説明してきました。E-E-A-T は「品質を判断する枠組み」として理解し、Google の各種シグナル（HCU / SpamBrain / コアアップデート等）を間接的に改善する取り組みとして実装するのが正確です。詳しくは Chapter 1（E-E-A-T の Google 公式定義）を参照してください。

※ 出典: Google Search Central Blog（2022 年 12 月）（取得 2026-05）

Q. Author schema を実装すれば検索順位は上がりますか？

Author schema 単独で順位を直接押し上げる効果は Google から明示されていません。期待できるのは (1) Google が著者エンティティを正しく識別することによる Authority シグナルの間接強化、(2) AI 検索エンジンの引用判定で著者性が評価されることによる引用機会の拡大、の 2 点です。Article schema の author / reviewedBy / wordCount / dateModified を一式配線するのが現実解です。詳しくは Chapter 6（Author schema 実装）を参照してください。

Q. YMYL に該当するページの判断方法は？

「人生・健康・財産・安全に重大な影響を及ぼす可能性のあるトピック」が YMYL です。医療・金融・法律・選挙・災害情報・栄養・住居購入・就職などが代表例。判断に迷う場合は「この記事の内容を信じて読者が行動した時、健康 / お金 / 法的地位に被害が出る可能性があるか」で判定してください。該当する場合は有資格者の執筆・監修、一次情報リンク、免責事項を必ず実装します。詳しくは Chapter 7（YMYL 領域の特殊対応）を参照してください。

Q. 個人ブログでも E-E-A-T 対策は意味がありますか？

意味があります。むしろ「組織として権威」を主張しにくい個人ブログこそ、Experience（実体験）と Trust（誠実な開示）で勝負できます。実体験の写真・実測・失敗ログ、運営者情報の明示、SNS との sameAs 紐付け、訂正履歴の透明化、を徹底することで、企業サイトに引けを取らない Trust を構築できます。資格不要な日常トピックは特に Everyday Expertise として評価されやすい領域です。

Q. AI 引用率を上げるために最も効く E-E-A-T 実装は？

優先順位は (1) Article schema の author / reviewedBy / dateModified / wordCount 配線、(2) 出典脚注の ±5 行以内配置（一次情報を引用している密度）、(3) Person schema の sameAs で SNS 紐付け、(4) Organization schema の sameAs でブランド identity 整備、(5) FAQ schema で Q&A 構造化、の順です。AI 検索エンジンは構造化データ・著者性・一次出典引用の 3 点を引用判定に強く使う傾向があります（Perplexity 公式の説明より）。詳しくは Chapter 6（Author schema 実装）と Chapter 10（計測と改善）を参照してください。

※ 出典: Perplexity「Introducing the Publishers' Program」（取得 2026-05）