著者情報 Person Schema でAI引用率を上げる実装ガイド【2026年版】

著者情報 Person Schema でAI引用率を上げる実装ガイド

この記事の結論: Person SchemaにsameAs・knowsAbout・ProfilePageを組み合わせることで、ChatGPT・Perplexity・Google AI Overviewが「信頼できる著者による情報」と判定し、AI引用率が改善します。構造化データ単体ではなく「著者エンティティの一貫性」が核心です。

最終更新日: 2026-06-07

はじめに

「Person Schemaを実装するとAI引用率は上がるのか？」という問いに、2026年現在の実務では条件付きで「Yes」と答えられます。

2026年5月にAhrefsが公開した大規模調査では「スキーマを追加しただけでは明確なAI引用増は確認できなかった」と報告されました。しかし同調査が示したのは「スキーマ単体では弱い」ということであり、著者エンティティの信頼性を構造化データで可視化するアプローチの否定ではありません。

Person Schemaが効く条件は明確です。著者名が実在する人物として複数の外部プラットフォームに存在し、その一貫性をsameAsプロパティで結びつけ、ProfilePageで独立した著者ページを持つ——この3点が揃ったとき、AI検索エンジンは「この記事は信頼できる専門家が書いたもの」と判定しやすくなります。

本記事ではE-E-A-Tの観点からPerson Schemaの実装手順を解説し、AI引用率に直結するプロパティの優先順位と、よくある実装ミスを整理します。

→ 構造化データ全般の基礎はAI検索最適化の完全ガイドで解説しています。

---

Person Schemaとは何か、なぜAI引用率に関係するのか

Schema.orgが定義するPersonタイプは、個人の属性（名前・肩書・所属・専門分野・外部プロフィール）を機械可読形式で記述するための語彙です。記事ページのArticleスキーマ内にネストするauthorプロパティとして使う形が最も一般的ですが、著者ページそのものに独立したJSON-LDとして配置することも推奨されています。

AI検索エンジンがページを引用する際、重要な判断基準のひとつが「誰が書いたか」です。ChatGPTやPerplexity、Google AI Overviewは、回答を組み立てるとき出所の信頼性を評価します。そのとき構造化データは「事実確認の最短パス」として機能します。

JSON-LD形式は、2026年現在もGoogleが最推奨する実装形式であり、HTMLと分離して記述できるため保守性も高くなっています。

---

実装の前提：著者ページ（ProfilePage）を用意する

Person Schemaの効果を最大化する前提条件として、著者ページの設置があります。Googleは2023年にProfilePageスキーマを公式サポートし、著者プロフィールページへの構造化データ実装をドキュメント化しました。

著者ページに最低限必要な要素は次のとおりです。

• 名前（公式に使っている表記で統一）
• 顔写真（本人と識別できる解像度）
• 略歴（専門性の根拠となる職歴・資格・受賞歴）
• 専門分野の明示（「SEO/LLMO/コンテンツ戦略を専門とする」等）
• 外部プロフィールへのリンク（LinkedIn・X・GitHub等）

著者ページが存在しない状態でPerson Schemaだけを記事に書いても、AI検索エンジンが「この人物のプロフィールページはどこか」と辿る先がなく、エンティティの確立が不完全になります。

ProfilePage JSON-LDの基本形

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "dateCreated": "2024-01-15",
  "dateModified": "2026-06-07",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/authors/tanaka-taro",
    "name": "田中太郎",
    "jobTitle": "シニアSEOコンサルタント",
    "description": "SEO/LLMO戦略を専門とするコンテンツストラテジスト。10年以上のSEO実務経験を持つ。",
    "url": "https://example.com/authors/tanaka-taro",
    "image": {
      "@type": "ImageObject",
      "url": "https://example.com/authors/tanaka-taro.jpg",
      "width": 400,
      "height": 400
    },
    "sameAs": [
      "https://www.linkedin.com/in/tanaka-taro",
      "https://twitter.com/tanaka_seo",
      "https://github.com/tanaka-taro"
    ],
    "knowsAbout": ["SEO", "LLMO", "構造化データ", "コンテンツマーケティング"],
    "worksFor": {
      "@type": "Organization",
      "name": "Example Corp",
      "url": "https://example.com"
    }
  }
}

@idでURIを指定することがエンティティ同一性の確立に不可欠です。記事ページのArticleスキーマで同じ@idを参照することで、Googleのナレッジグラフが「著者ページの人物」と「記事の著者」を同一エンティティとして認識します。

---

Article内のauthorプロパティ：ネスト形式の正しい書き方

記事ページのArticleスキーマ内にPersonをネストする書き方は広く使われていますが、最低限のプロパティしか書かれていないケースが多いです。Googleが2022年に公開したベストプラクティスでは、以下の対応が求められています。

Googleが推奨するauthorのベストプラクティス

記事ページJSON-LDの実装例（@graphパターン）

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/articles/seo-guide/#article",
      "headline": "SEO完全ガイド2026年版",
      "datePublished": "2026-06-07",
      "dateModified": "2026-06-07",
      "author": {
        "@id": "https://example.com/authors/tanaka-taro"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "image": {
        "@type": "ImageObject",
        "url": "https://example.com/articles/seo-guide/og.jpg"
      }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/authors/tanaka-taro",
      "name": "田中太郎",
      "jobTitle": "シニアSEOコンサルタント",
      "url": "https://example.com/authors/tanaka-taro",
      "sameAs": [
        "https://www.linkedin.com/in/tanaka-taro",
        "https://twitter.com/tanaka_seo"
      ],
      "knowsAbout": ["SEO", "LLMO", "構造化データ"]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Corp",
      "url": "https://example.com",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      }
    }
  ]
}

@graph構文でArticle・Person・Organizationを1つのJSON-LDブロックにまとめ、@idで相互参照するのが2026年の推奨パターンです。Yoast SEOやRank Mathも内部的にこの形式で出力しています。

---

AI引用率に最も効く4つのプロパティ

Person Schemaには50以上のプロパティが定義されていますが、AI引用率の観点で優先度が高いのは次の4つです。

1. sameAs（エンティティ同一性の証明）

sameAsは、Schema.orgで最もAI引用率に影響するプロパティとして実務で報告されています。外部の権威あるプラットフォームへのリンクを並べることで「この人物は実在し、複数の場で同じアイデンティティを公開している」ことの証明になります。

推奨する登録先の優先順位：

2. knowsAbout（専門分野の明示）

knowsAboutは「著者がどの分野の専門家か」をAIに伝えるプロパティです。記事のトピックとknowsAboutが一致しているとき、AIは「この著者はこの分野について語る資格がある」と判定しやすくなります。

文字列でもURLでも指定できます。より精度の高い指定にはSchema.orgの概念URLを使います。

"knowsAbout": [
  "SEO",
  "https://en.wikipedia.org/wiki/Search_engine_optimization",
  "LLMO",
  "コンテンツマーケティング"
]

3. alumniOf・hasCredential（学歴・資格）

教育背景や資格はE-E-A-Tの「専門性（Expertise）」を裏付ける重要な要素です。YMYL（健康・金融・法律）領域では特に重要度が高くなります。

"alumniOf": {
  "@type": "EducationalOrganization",
  "name": "東京大学"
},
"hasCredential": {
  "@type": "EducationalOccupationalCredential",
  "name": "Google公認アナリスト資格"
}

4. url（著者ページとの紐づけ）

urlプロパティで著者ページのURLを明示することで、AI検索エンジンが「もっと詳しい著者情報を取得できる」と認識します。著者ページにProfilePageスキーマを実装していれば、エンティティの完全なプロフィールを構築できます。

---

複数著者・組織著者の扱い方

複数著者の場合

Googleのベストプラクティスでは、共著記事はすべての著者を配列で記述することが推奨されています。

"author": [
  {
    "@type": "Person",
    "@id": "https://example.com/authors/tanaka-taro",
    "name": "田中太郎"
  },
  {
    "@type": "Person",
    "@id": "https://example.com/authors/yamada-hanako",
    "name": "山田花子"
  }
]

組織名義の記事

著者が個人ではなく組織の場合はOrganizationタイプを使います。「編集部」や「〇〇社マーケティングチーム」は、Personではなく個人名付きPersonにした方がAI引用率の観点では有利です。組織名義の記事が多いサイトでも、少なくとも「担当編集者」レベルで個人を明示することをお勧めします。

---

WordPressでの実装：プラグイン別対応状況

Yoast SEO（推奨）

Yoast SEOは著者プロフィールページに自動でProfilePage・Person JSON-LDを出力します。「ユーザー設定」から各著者のソーシャルリンクを入力すると、自動的にsameAsに反映されます。ただしknowsAboutは手動でのカスタマイズが必要なため、wp_headフックでカスタムJSON-LDを追加する方法が一般的です。

Rank Math

Rank Mathはスキーマモジュールで著者情報のカスタムフィールドを設定できます。sameAs・knowsAboutを含むPerson Schemaを記事単位で調整できるため、個人ブログや著者が複数のメディアサイトに向いています。

テーマ・カスタム実装

プラグインに頼らずfunctions.phpでJSON-LDを出力する場合、is_author()やis_single()で出力条件を制御し、著者データをWP_Userオブジェクトから取得する実装が標準パターンです。

---

実装後の検証：3つのツールで確認する

Person Schemaを実装したら必ず3段階で検証します。

Step 1：リッチリザルトテスト（Googleが認識するか確認）

Google公式のリッチリザルトテストでPageのURLを入力し、Person・ProfilePageが「検出されたアイテム」に表示されるかを確認します。エラーが出た場合はプロパティの型違い（stringとURLの混在等）が原因のことが多いです。

Step 2：Schema Markup Validator（構文の正確性を確認）

Schema Markup ValidatorでJSON-LDの構文チェックを行います。sameAsのURLが正しい形式か、knowsAboutの型が適切かを検証します。

Step 3：Search Console（本番での認識確認）

公開後1〜2週間経過したら、Search ConsoleのURL検査ツールで「ページが実際にどのような構造化データを返しているか」を確認します。クローラーが取得したHTMLに目的のJSON-LDが含まれているかを「取得済みのページ」ビューで確認できます。

---

「構造化データだけでは引用率は上がらない」という誤解の解消

2026年5月のAhrefs調査を受けて「Person Schemaは意味がない」という解釈が広まりましたが、調査の正確な結論は異なります。

同調査が示したのは「スキーマを追加するだけでは不十分」であり「エンティティの信頼性・コンテンツ品質・一次情報の密度が組み合わさって初めて引用率が上がる」ということです。

Person Schemaが効く条件を整理すると次のようになります。

構造化データは「コンテンツの権威性を機械に伝える翻訳ツール」であり、権威性そのものを生み出すものではありません。著者情報の実態が伴っていれば、Person Schemaはその実態をAIに正確に届ける手段として機能します。

→ AI検索での引用獲得の全体戦略はAI検索最適化の完全ガイドで解説しています。

---

著者エンティティ設計の3パターン

サイトの著者体制によって最適な実装パターンが異なります。

パターンA：個人ブロガー・専門家サイト

単一著者が全記事を執筆するケースです。著者ページは1つで十分ですが、WikidataやLinkedInへのsameAs登録が最優先の施策になります。全記事から同じ著者の@idを参照し、エンティティを集中的に強化します。

パターンB：複数著者メディア

編集部員ごとに著者ページを作成し、それぞれにProfilePage+Personスキーマを実装します。著者別の専門分野をknowsAboutで分けることで「このメディアにはSEO専門家とマーケティング専門家がいる」という多様な権威性を構造化できます。

パターンC：組織名義で運営するコーポレートブログ

「編集部」名義が多い場合でも、執筆担当者の名前を最低限記載し、Personスキーマを付与することをお勧めします。組織スキーマのみでは「どの専門家が書いたか」の情報がなく、AI引用率の観点で不利になります。

---

よくある質問

Q1. Person SchemaはArticle内にネストするだけでいいですか？

記事ページのArticle内にネストするのは最低限の実装です。AI引用率を本格的に上げるには、著者ページにProfilePage+Personスキーマを独立して配置し、記事ページから@idで参照する形が推奨されます。エンティティとして「著者ページが存在する実在の人物」をAIに示せるかどうかが分かれ目です。

Q2. sameAsにはどのURLを登録すべきですか？

優先度の高い順にWikidata、LinkedIn、X（旧Twitter）、GitHubです。Wikidataへの登録は少し手間がかかりますが、AI検索のナレッジグラフが直接参照するため投資対効果が最も高いです。WikipediaページがあればそのURLも必ず追加してください。

Q3. knowsAboutは何件くらい書くべきですか？

3〜7件が実務上の推奨範囲です。多すぎると「すべての分野の専門家」という矛盾が生じ、エンティティの焦点が拡散します。記事コンテンツのトピックと一致する専門分野を絞って記述してください。

Q4. 著者ページがないサイトでも効果はありますか？

著者ページなしでも記事レベルのauthor Personスキーマには一定の効果があります。ただしProfilePageとの組み合わせに比べると効果は限定的です。新規で実装するなら著者ページの作成とセットで進めることをお勧めします。

Q5. ペンネームや編集部名義でもPerson Schemaは有効ですか？

ペンネームは実在する著者が使う場合は有効です。ただしsameAsで登録した外部プロフィールもペンネームで統一する必要があります。一方、架空の「山田一郎（編集部）」のような実在しない人物にPersonスキーマを付与しても、外部照合が成立しないため効果は見込めません。

Q6. WordPressプラグインのYoast SEOだけで十分ですか？

Yoast SEOは著者ページのProfilePage・Person JSONを自動出力し、ソーシャルリンクをsameAsに反映する機能があります。基本実装としては十分ですが、knowsAboutや学歴・資格などの詳細プロパティは手動でのカスタム追加が必要です。

Q7. 記事更新のたびにdateModifiedを変えると著者情報に影響しますか？

dateModifiedは記事スキーマのプロパティのため、著者のPersonスキーマには直接影響しません。ただしdateModifiedを実質的な更新なしに頻繁に書き換えると鮮度偽装とみなされるリスクがあります。著者プロフィールの更新（転職・資格取得等）はProfilePageのdateModifiedに反映させてください。

Q8. 日本語の著者名と英語表記を両方入れるには？

nameプロパティには公式に使っている表記を入れ、alternateNameで別表記を追加します。日本語名と英語名が混在する場合はalternateNameに英語表記を記述するのが一般的です。

Q9. AI引用率をどうやって測定すればいいですか？

ChatGPT・Perplexity・Google AI Overviewで著者名+専門分野キーワードを定期的に検索し、引用されているかを確認する方法が基本です。専用の引用追跡ツール（BrandWatchやMentionなど）を使うとより体系的に管理できます。

Q10. Organization SchemaとPerson Schemaはどちらを先に実装すべきですか？

サイトの目的によります。コーポレートサイトやメディアではOrganization Schemaを先に実装し、全体の「どの組織が運営しているか」を確立してからPersonを追加する順序が効率的です。個人ブログや専門家サイトはPerson Schemaを最優先にしてください。

---

関連用語

• E-E-A-T — 経験・専門性・権威性・信頼性。著者情報はE-E-A-Tの中核をなす
• Schema.org — Person・Organization・ProfilePageなど800以上のタイプを定義する語彙集
• 構造化データ — 機械可読な形式でページの内容を記述する仕組み
• JSON-LD — GoogleとAIクローラーが最も推奨する構造化データの記述形式
• ブランドメンション — AI検索でのエンティティ認識に貢献する著者名の外部言及
• LLMO — LLM（大規模言語モデル）への最適化戦略。著者エンティティ設計はLLMO施策の柱

---

関連記事

• SEO完全ガイド【2026年版】 — 構造化データを含むSEO全体像
• AI検索最適化の完全ガイド — AI検索で選ばれるための総合戦略
• 著者エンティティの実装方法 — 著者エンティティ設計の詳細手順
• WordPressで著者ボックスをE-E-A-T対応にする方法 — WordPress実装の実践ガイド
• 著者ページのSEO設計2026 — 著者ページのSEO・LLMO最適化
• 著者情報の有無でAI引用率はどれだけ変わるか — 著者情報の有無による引用率差の実証研究