Person構造化データ

TL;DR — Person schemaは、ページが誰についてのものかを検索エンジンへ伝える小さなコードです。多くは記事著者に使い、schema.orgのPersonタイプで氏名、略歴URL、役職、外部プロフィールを記述します。同姓同名の人物を区別することが主な役割で、順位を上げたり「専門性ポイント」を与えたりするものではありません。

Person schemaとは

署名に人物名があれば、人は文脈から誰かを理解できますが、検索エンジンには文字列にしか見えません。Person schemaは氏名を人物としてラベル付けし、略歴URL、役職、勤務先、ソーシャルプロフィールなどの機械可読な情報を追加します。

商品価格、レビュー星、パンくずにも使われる共通のschema.org語彙のうち、個人を表すタイプがPersonです。記事のauthorとして使うことが多く、紹介・略歴ページ全体がその人物についてのものだと示す用途にも使えます。

存在理由：同姓同名の人物を区別する

追加する本当の理由は曖昧性の解消です。sameAsにLinkedIn、個人サイト、Xなど本人の外部プロフィールを列挙すると、この著者とウェブ上の各プロフィールが同一人物であると結び付けやすくなります。検索エンジンやAIシステムは、この一貫した本人識別を構築しようとしています。

最も多い誤解

Person schemaで順位は上がらず、E-E-A-Tも作れません。 jobTitleや多数のsameAsを追加すればGoogleから信頼されるという説明は誤りです。Google担当者も、E-E-A-Tは直接のランキング要因ではなく、マークアップで専門家を自己申告してもそれ自体には意味がないと説明しています。

Googleが重視するのは、読者がページ上で確認できる見える著者情報です。schemaは署名を機械可読に写すものであり、署名の代替でも、信頼を生む魔法のスイッチでもありません。

初心者向けの規則は2つです。

• nameフィールドには氏名だけを入れる。 「Jane Smith, Senior Editor」と書かず、役職は別のjobTitleへ入れます。
• 表示内容とマークアップを一致させる。 ページ上にない役職や勤務先をコードだけで主張するのは利点ではなく問題です。

プロパティ別の説明、ArticleとProfilePageの違い、担当者の引用はAdvancedタブで確認してください。

TL;DR — Person schema（schema.org/Person）は、主に記事のauthor、場合によってはProfilePageのmainEntityとして個人をマークアップします。役割はsameAsを中心に署名、略歴、プロフィールを照合するエンティティの曖昧性解消です。ランキング要因でもE-E-A-T付与手段でもありません。記事著者とProfilePageでは推奨プロパティが異なり、マークアップは見える署名を反映する必要があります。

Person schemaを使う場所

一般的な配置先は3つで、相互に置き換えられるものではありません。

1. 記事著者。 Article/BlogPostingのauthorをPersonとして設定します。Googleの例にはname、jobTitle、urlがあります。
2. ProfilePageのmainEntity。 Personを主対象とする専用の略歴・紹介ページです。Googleは、“where creators (either people or organizations) share first-hand perspectives.” (翻訳) 「人物または組織のクリエイターが一次的な視点を共有する」サイト向けと説明しています。
3. Organizationマークアップ内。 企業ページで紹介する創業者や従業員です。

これは企業自体を表すOrganization schemaや、実店舗事業を表すLocalBusiness schemaと並ぶテーマです。Personは同じエンティティグラフのうち、個人単位を担当します。

順位ではなく、本人識別の曖昧性を解消する

Person schemaの本来の機能は、サイト内外のコンテンツを結び、人物を一貫して識別できるようにすることです。中心となるsameAsで同一人物を表す外部URLを示し、「これらはすべて私です」と宣言します。

Googleの著者URL文書も同じ考え方です。推奨のauthor.urlは、“that uniquely identifies the author” (翻訳) 「著者を一意に識別する」紹介・略歴・ソーシャルページへのリンクです。記事ごとに異なるURLを設定せず、1つの正規プロフィールページへ統一して照合します。Mueller氏も著者識別をこの種の照合プロセスとして説明していますが、正確な言い回しは二次報道の要約として扱います。

記録上、ランキング要因でもE-E-A-Tでもない

多くの競合ガイドが誤る核心です。Googleには別々の2つの見解があります。

構造化データは順位を押し上げません。 John Mueller氏は、構造化データは文書化された検索機能向けであり、サイト順位を上げるものではないと説明しています。したがってPersonブロックはランキングレバーではありません。

E-E-A-Tは直接のランキング要因ではなく、専門性の自己申告には意味がありません。 Google検索連絡担当のDanny Sullivan氏は次のように述べています。

「having an expert write things doesn’t magically make you rank better, because 1) anyone could self declare someone to be an expert, and that means nothing and 2) we don’t somehow try to check and say ‘Yes, that’s an expert.’」 (翻訳) 「専門家に書いてもらえば順位が自動的に上がるわけではありません。誰でも専門家だと自己申告でき、それ自体には意味がなく、Googleが専門家だと確認・認定する仕組みもありません。」

Person schemaはまさに自己申告です。jobTitle: "Senior SEO Expert"や多数のsameAsを書いても、Googleが「E-E-A-Tポイント」を与えることはありません。E-E-A-Tは品質評価者向けの枠組みであり、マークアップのチェックリストではありません。

Googleが推奨するのは見える著者情報です。読者が期待する場所に正確な署名などを追加し、コンテンツの制作方法を理解できるようにします。資格情報は人が見えるページへ掲載し、schemaはそれを反映してください。schemaで置き換えてはいけません。

主要プロパティ

Googleの記事構造化データガイドには必須プロパティ表はなく、コンテンツに適用できる項目を追加するよう説明しています。authorの推奨プロパティ表にあるのは2つです。

• name — 氏名だけを入れます。Googleの原文は “In the author.name property, only specify the name of the author. Don’t add any other piece of information.” (翻訳) 「author.nameには著者名だけを指定し、その他の情報は追加しないでください」です。「Jane Smith, Editor」は不可です。
• url — 著者を一意に識別する正規の略歴・紹介ページです。Googleは同じ曖昧性解消用途で**sameAs**をurlの代替として認めています。

この2つ以外では、Googleの記事著者例にjobTitleがありますが、推奨表の独立した項目ではなく例の内容です。以下は、正確でページ上に表示されている場合に追加できるschema.orgプロパティであり、Google必須のチェックリストではありません。

• jobTitle — nameから分離した役職。Googleの例にだけ登場します。
• worksFor — 勤務先のOrganization。Googleの記事文書には推奨表にも例にもなく、職業上の文脈に使えるschema.org語彙です。
• image — 顔写真。worksForと同様、記事の推奨表にはありません。
• sameAs — Google文書がurlの代替として挙げる曖昧性解消手段。LinkedIn、個人サイト、Wikipedia/Wikidata、X、GitHub、ORCIDなど本人のURLだけを使います。誤ったリンクは本人識別を悪化させます。
• 任意項目: description、alumniOf、knowsAbout。

記事著者のPersonとProfilePageのPerson

多くのガイドが両者を混同し、過不足のあるマークアップを生みます。Googleはページタイプごとに異なる要件を文書化しています。

すべてのPersonプロパティを両方に使える、または例に登場すればGoogle推奨だと考えるのが誤りです。ProfilePageで必須・推奨されるのはmainEntity、name、alternateName、sameAs、description、image、日付項目です。jobTitle/worksForはProfilePageにも記事著者の正式な推奨表にもありません。

最小構成の記事著者例

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How search engines crawl the web",
  "author": {
    "@type": "Person",
    "name": "Willow Lane",
    "jobTitle": "Journalist",
    "url": "https://www.example.com/staff/willow-lane"
  }
}

nameには氏名だけを、jobTitleには役職を入れます。Google文書が求める区別です。

所属とsameAsを含む詳細例

{
  "@type": "Person",
  "name": "Willow Lane",
  "jobTitle": "Senior Journalist",
  "url": "https://www.example.com/staff/willow-lane",
  "image": "https://www.example.com/img/willow-lane.jpg",
  "worksFor": {
    "@type": "Organization",
    "name": "Example Media",
    "url": "https://www.example.com/"
  },
  "sameAs": [
    "https://www.linkedin.com/in/willowlane",
    "https://x.com/willowlane",
    "https://www.wikidata.org/wiki/Q00000000"
  ]
}

各sameAsは実際に本人のプロフィールへ到達する必要があります。リンク切れや別人へのリンクは、何もない場合より悪化させます。

Person schemaとナレッジパネル

sameAsは曖昧性解消の手掛かりであり、パネル生成器ではありません。ナレッジパネルや本人確認を保証せず、Googleが作成・更新するには独立した信頼できる情報源による裏付けが必要です。一貫したPerson/Organizationマークアップは認識を助けますが、強制はできません。

AI検索についての期待値

Person schemaはLLMやAI検索の人物説明を変える手段として語られがちですが、慎重に考えるべきです。現在のAIクローラーが回答で構造化データを直接利用するとは確認されていません。Person schemaは、時間をかけてナレッジグラフの本人認識を助ける、一貫した機械可読のエンティティ基盤です。現在のAI出力を即座に変えるスイッチではありません。私自身のLinkedIn投稿の要約であり、逐語引用ではありません。

結論

Person schemaは、検索エンジンが人物を一貫して識別し、ウェブ上のコンテンツを照合できるように使います。見える署名・略歴と一致させ、順位上昇やE-E-A-Tを期待しないでください。具体的な失敗例はAnti-Patternsタブで確認できます。

AIまとめ

高度な解説の要点をまとめると、次のとおりです。

• 概要: schema.org/Personは個人を表します。多くは記事のauthor、場合によってはProfilePageのmainEntity、またはOrganizationマークアップ内の創業者に使います。OrganizationやLocalBusinessと並ぶ、個人単位のエンティティマークアップです。
• 本来の役割は曖昧性の解消: 署名、略歴、外部プロフィールにまたがる同一人物を結び付けます。中心となるのはsameAs（LinkedIn、個人サイト、Wikidata、X、GitHub、ORCID）です。author.urlは1つの正規プロフィールページへ向けます。
• ランキング要因でもE-E-A-T付与手段でもない: Mueller氏は構造化データで順位は上がらないと説明し、Sullivan氏はE-E-A-Tが直接のランキング要因ではなく、専門家を自己申告しても意味はないと説明しています。Person schemaも自己申告なので、専門性を授与できません。発言は信頼できる二次報道経由であり、原文は一次投稿で確認が必要です。
• Googleが推奨するのは見える著者情報: 読者が確認できる正確な署名や経歴を掲載し、マークアップだけに資格情報を隠さないでください。
• 記事著者とProfilePageは別契約: 記事著者ではGoogleが正式に推奨するのはnameとurl（sameAsはurlの代替）です。jobTitleは例にのみ登場し、worksForとimageは記事文書にありません。ProfilePageではmainEntityとnameが必須、alternateName、sameAs、description、imageが推奨です。jobTitleとworksForはProfilePageでも推奨項目に含まれません。
• nameの規則: nameには氏名だけを入れ、役職はjobTitleへ分けます。「Jane Smith, Editor」は誤りです。
• ナレッジパネル: sameAsは多数ある手掛かりの1つであり、パネル生成器ではありません。独立した裏付けが必要です。
• AI検索: 長期的なエンティティ基盤であり、現在のAI出力を即座に変えるスイッチではありません。
• 表示内容とマークアップを一致させる: 誤ったsameAsは曖昧性を解消するどころか悪化させます。

公式ドキュメント

検索エンジンが公開している一次資料です。

Google

• 記事の構造化データ — author（Person/Organization）、author.nameには氏名だけを入れる規則、推奨されるauthor.url。
• プロフィールページ（ProfilePage）の構造化データ — mainEntity、name/alternateName、sameAs、description。
• 有用で信頼性の高い、人を第一に考えたコンテンツの作成 — 読者が期待する場所に正確な署名などの著者情報を追加するためのGoogleガイダンス。
• リッチリザルトテスト — Article/ProfilePageマークアップを検証します。
• Schema Markup Validator — リッチリザルトがないPersonを含む、あらゆるschema.orgタイプを検証します。
• schema.org — Person — Personの全プロパティを確認できる語彙リファレンス。

Bing / Microsoft

• Bing Webmaster Guidelines — schema.org構造化データとJSON-LDへのBingの対応。
• Bing Webmaster Tools — Bingがマークアップをどう読み取るか確認します。

出典からの引用

Google担当者の公開発言です。以下で原文を確認できた引用は1件だけです。その他は二次報道を通じて確認した見解なので、一次投稿に結び付けられない文言へ引用符は付けず、要約として扱います。

Google検索連絡担当 Danny Sullivan氏 — 専門性の自己申告について

「having an expert write things doesn’t magically make you rank better, because 1) anyone could self declare someone to be an expert, and that means nothing and 2) we don’t somehow try to check and say ‘Yes, that’s an expert.’」 (翻訳) 「専門家に書いてもらえば順位が自動的に上がるわけではありません。第一に、誰でも誰かを専門家だと自己申告でき、それ自体には意味がありません。第二に、Googleが確認して『はい、この人は専門家です』と認定する仕組みもありません。」

Danny Sullivan氏 — E-E-A-Tは直接のランキング要因ではない（要約）

• Sullivan氏は、E-E-A-Tは速度のようにGoogleが直接測定する単一の技術的ランキング要因ではなく、人がE-E-A-Tを評価する方法にコンテンツが合うかを推定するため、さまざまなシグナルを代理指標として使うと説明しています。 二次報道に基づく要約です。一次情報を取得するまでは逐語引用として扱いません。

GoogleのJohn Mueller氏 — 構造化データとランキング（要約）

• Mueller氏は、構造化データでサイトの順位が上がるわけではなく、文書化された検索機能の対象にするために使われると説明しています。他のschema.org用途に使うこと自体は問題ありませんが、Google検索で目に見える変化が生じる可能性は低いとも述べています。また、著者識別を照合のプロセスと説明し、著者URLを1つの集約プロフィールページへ向けることを推奨しています。 Mueller氏のBluesky/X投稿を扱ったSearch Engine Journal / Search Engine Roundtableの記事に基づく要約です。正確な引用にする前に元投稿で確認してください。

Googleドキュメント — author.nameの制限（Googleの現行文書より）

• “In the author.name property, only specify the name of the author. Don’t add any other piece of information.” (翻訳) 「author.nameプロパティには著者名だけを指定し、その他の情報は追加しないでください。」 記事の構造化データ

Person schemaで避けるべきこと

繰り返し見られる失敗と、それぞれが機能しない理由です。

Person schemaでE-E-A-Tや順位が上がると期待する。 これが最大の誤りです。Person schemaは自己申告であり、Sullivan氏が述べたように、専門家だと自己申告してもランキングには「意味がなく」、Googleが専門家を確認・認定するわけでもありません。Mueller氏も、構造化データでページ順位は上がらないと説明しています。Personマークアップは本人識別と検索機能の適格性のために追加し、順位上昇や「E-E-A-Tポイント」を期待して追加しないでください。

著者マークアップとsameAsのプロフィール連携を混同する。 authorは記事を人物へ帰属させ、sameAsは外部プロフィールが同一人物であることを宣言します。役割は異なります。sameAsは曖昧性解消の手段、authorオブジェクトは帰属の手段です。両方を適切に使う必要があり、別人のプロフィールへ向けた誤ったsameAsは識別を積極的に壊します。

jobTitle/worksForを任意の補足ではなくGoogleの必須項目として扱う。 jobTitleはGoogleの記事例に登場しますが、worksForは記事文書に登場しません。どちらも推奨プロパティ表にはなく、記事著者についてGoogleが正式に推奨するのはnameとurl（またはsameAs）だけです。同姓同名の著者がいるサイトでは正確な所属情報が役立つことはありますが、Googleが要求・評価する項目として説明してはいけません。

見える署名ではなく、資格情報をマークアップだけに隠す。 Googleは、読者が実際に確認できる署名や経歴などの見える著者情報を推奨しています。ページ上は氏名だけなのに、JSON-LDへ役職、勤務先、資格を詰め込むのは順序が逆です。表示内容にない主張を含むマークアップは、構造化データが見える内容を反映すべきというGoogleのガイドラインにも反します。まずページへ表示し、その後schemaへ反映してください。

nameフィールドへ役職を詰め込む。 Googleは明確に、author.nameには氏名だけを入れるよう求めています。「Jane Smith, Senior Editor」は誤りです。役職には別のjobTitleプロパティを使います。

PersonとProfilePageを同じチェックリストで扱う。 両者の文書上の要件は異なります。記事著者のPersonでは、Googleはnameとurl（sameAsは代替）を推奨し、jobTitleは推奨ではなく例の内容です。ProfilePageのmainEntityであるPersonでは、mainEntityとnameが必須、alternateName、sameAs、description、imageが推奨で、jobTitle/worksForは明記されていません。一方のチェックリストを他方へ適用すると、過不足のあるマークアップになります。

sameAsだけでナレッジパネルが作られると考える。 sameAsは多数ある手掛かりの1つであり、パネル生成器でも本人確認の「証明」でもありません。Googleがパネルを作成・更新するには独立した裏付けが必要です。

Person schemaで現在のAI/LLMの回答が変わると期待する。 現在のAIクローラーが回答生成で構造化データを直接利用するとは確認されていません。Person schemaは長期的なエンティティ基盤として扱い、今週のAI出力を書き換えるスイッチとは考えないでください。

どのPersonマークアップが必要ですか？

記事著者とProfilePageでは必要なプロパティが異なります。この決定ツリーで、JSON-LDを書く前に適用すべき経路を確認できます。

Person schema実装チェックリスト

記事の署名またはProfilePageへPersonマークアップを公開する前に、順番に確認してください。

• nameフィールドには氏名だけを入れる。 「Jane Smith, Senior Editor」は不可です。Googleはauthor.nameに氏名以外を含めないよう明記しています。
• jobTitleは別プロパティにする。 その役職がページ上に実際に表示されている場合だけ追加します。
• author.urlは1つの正規プロフィールページへ向ける。 同じ著者の記事では常に同じURLを使い、投稿ごとに別URLへ向けません。
• 勤務先が署名に関連し、表示されている場合はworksFor（Organization）を設定する。
• imageはページに表示される顔写真と一致させる。
• sameAsには本人所有を確認できるプロフィールだけを列挙する。 LinkedIn、個人サイト、Wikidata、X、GitHub、ORCIDなどを必要に応じて使い、誤ったリンクで曖昧性を悪化させないでください。
• マークアップした情報はすべてページ上に表示する。 役職、勤務先、略歴は読者が確認できる内容を反映し、JSON-LDだけに資格情報を追加しません。
• ProfilePageには記事著者用ではなくProfilePage用のプロパティを使う。 name、alternateName、sameAs、descriptionを使い、jobTitle/worksForはここでは省きます。
• リッチリザルトテストまたはSchema Markup Validatorで検証する。
• 期待値を正しく設定する。 これは本人識別と適格性の改善であり、ランキングやE-E-A-Tを上げる手段ではありません。順位変動で効果を測らないでください。

Person schema quick reference

Personマークアップは人物の曖昧性を解消します。専門性、ランキング、ナレッジパネルを作り出すものではありません。

テスト yourself: Person Schema

Person schemaでできること、できないことを確認する5問です。各設問の答えを選んで確認してください。

変更履歴