AIが生成する回答では、「何が書かれているか」だけでなく、「誰が述べているか」も併せて評価されます。しかし、台湾のB2Bサイトの多くは、著者欄を単なるテキストの氏名として扱っています。これではAIエンジンが読み取れるのは数文字の名前だけで、そのコンテンツを実在する検証可能な専門家へ結び付けられません。Person Schemaの役割は、創業者やコンテンツ著者を文字列のままにせず、ナレッジグラフ上で身元、専門性、裏付けを備えたエンティティとして認識できる状態にすることです。
AIエンジンが著者情報を必要とする理由
GoogleのE-E-A-Tでは、「経験」と「専門性」がコンテンツ品質を評価する中核要素に位置付けられています。しかし、記事の背後に誰がいるのかを機械が自動的に把握できるわけではありません。ChatGPT、Perplexity、Google AI Overviewsが引用するコンテンツを選ぶ際は、出典が明確で、著者を識別でき、外部の権威ある情報とも整合しているページが有利です。ここで必要になるのが、同姓同名を見分けるエンティティの曖昧性解消です。たとえば「陳志明」という名前の人物が数百人いる場合、記事に登場する陳志明が、特定の企業に所属し、SaaS分野で30本の記事を執筆してきたコンサルタントだと判断するには、十分な識別シグナルが必要です。Person Schemaは、まさにそのための情報を提供します。
Person Schemaの最小構成
最初からすべての項目を埋める必要はありません。AIや検索エンジンが正しく解釈できる著者エンティティには、通常、次のプロパティを含めます。JSON-LD形式で、著者の個人ページと記事ページに実装します。
- name：著者の氏名です。サイト全体と外部プラットフォームで表記を完全に統一し、スペースの有無や英字表記まで一致させます。
- @id：https://yoursite.com/author/name#person のような、URLベースの固定識別子です。他のスキーマから同じエンティティを参照できるようにします。
- jobTitleとworksFor：役職と所属組織を示します。worksForは、企業のOrganizationエンティティを参照します。
- sameAs：本人確認の裏付けとなる外部プロフィールのURLを配列で指定します。特に重要なプロパティです。
- knowsAbout：著者が専門とするトピックの一覧です。実際に公開してきたコンテンツの領域と対応させます。
- alumniOf、description、image：学歴、プロフィール、顔写真を補足し、著者の経歴と信頼性を明確にします。
これらの情報がなければ、記事内に「author」というつながりがあっても、実態は名前へのリンクが1本あるだけです。プロフィールが充実していても、エンティティとして結び付ける仕組みがなければ、その価値を十分に伝えられません。
sameAsで外部ナレッジグラフにつなぐ
一連の構造化データの中でも、sameAsは特に効果の大きいプロパティです。同一人物について、外部の権威あるプラットフォームに掲載されたプロフィールURLを列挙します。AIや検索エンジンはそれらを照合し、自社サイトの著者を、既存のナレッジベースにあるエンティティノードへ対応付けられるようになります。実務では、次の情報源から優先して設定します。
- LinkedInプロフィール。B2Bでは最も重要で、AIや検索エンジンからも信頼性を判断されやすい情報源です。
- X/Twitter、Threadsなどのソーシャルアカウント。
- WikidataまたはWikipediaの項目。存在する場合は、強いシグナルになります。
- Crunchbase、AngelListの創業者ページ。
- 研究者や学術分野の著者であれば、ORCIDとGoogle Scholar。
- 企業公式サイトのチーム紹介、登壇イベントのページ、メディアによるインタビューや掲載記事。
注意したいのは、sameAsでは双方向の整合性が重要だという点です。スキーマ上で著者のLinkedInとして特定のURLを示すなら、そのLinkedInプロフィールからも自社サイトや所属企業を確認できる状態が望まれます。一方的に関連を宣言しても、リンク先で本人や所属との関係を確認できなければ、シグナルの信頼性は弱まります。
著者の「実体ページ」を用意する
重要な著者ごとに、固定URLと安定した内容を持つ専用の個人ページを設けましょう。このページが、自社ドメイン内における著者エンティティの公式ノード、つまりエンティティホームになります。完全なPerson Schemaに加え、実際のプロフィール、代表記事、外部プロフィールへのリンクを掲載します。各記事ページのauthorは、@idを使ってこのページを参照させ、著者情報の信頼できる唯一の情報源にします。実体ページがなければ、著者情報は各記事の署名欄に分散し、AIや検索エンジンがそれらを一つの安定したエンティティとして集約しにくくなります。
@idで著者・記事・組織を一つの関係図にする
構造化データの強みは、ノード同士のつながりにあります。記事ではArticleスキーマのauthorから著者の@idを参照し、著者のworksForから企業のOrganization @idを参照します。さらに、企業のOrganizationからemployeeまたはfounderで著者を参照します。こうすることで、AIや検索エンジンが読むのは孤立した3つの情報ではなく、互いを裏付ける小さなナレッジグラフになります。「この企業のコンテンツに誰が責任を持ち、その人物が本当にこのテーマを理解しているのか」を判断する材料が、関係図として明確になります。
B2B顧客の構造化データを棚卸しすると、最も多い問題はコンテンツ不足ではなく、各記事の著者が「見つからない」ことです。AIや検索エンジンは名前を読み取れても、検証可能な情報源へ結び付けられません。Person SchemaとsameAsの整備は、通常、成果につながりやすい最初の改善策です。— Tenten GEO implementation experience
実装チェックリスト
- Google リッチリザルト テストとSchema.org Validatorを使い、Personマークアップが正しいことを確認する。
- 著者名、役職名、企業名について、中国語・英語の表記やスペースも含め、サイト全体で完全に統一する。
- sameAsに指定したすべてのリンクが開けることを確認し、リンク先のプロフィールからも自社サイトまたは所属企業を確認できるようにする。
- knowsAboutに記載するトピックは、著者が実際に発信してきたコンテンツ領域と一致させ、過剰に広げない。
- 各記事のauthorに氏名の文字列を繰り返し記載するのではなく、@idで同一の著者エンティティを参照する。
- 著者のエンティティホームをインデックス可能にし、noindexを設定せず、ログイン画面の内側にも置かない。
まずは1人の著者から始めましょう。社内を代表する創業者またはコンサルタントを選び、その人物の実体ページを用意して、Person SchemaとsameAsを設定します。次に、関連するすべての記事のauthorから、その@idを参照させます。完成形を1つつくれば、ほかの著者にも展開できます。自社コンテンツがAIエンジンから「著者不明」と見なされていないか、また、どの実体シグナルが不足しているかを確認したい場合は、30分のGEO診断（/contact）をご予約ください。優先して修正すべきポイントを具体的にお伝えします。
