その著者情報、AIには読めていない｜E-E-A-Tのエンティティ実装

結論：著者名を「載せる」だけでは、AIには誰の記事か分からない

先に結論です。著者情報がAI検索で機能する条件は、「表示されていること」ではなく「人物としてエンティティ解決できること」です。具体的には次の3点が揃っているかどうかで決まります。

1. 著者ページ（プロフィールページ）が独立したURLとして存在し、経歴・実績・所属が本文テキストで書かれている
2. 記事側の著者表記と著者ページが、リンクと構造化データ（Person）で機械的に結ばれている
3. sameAsで外部プロフィール（X、LinkedIn、登壇記録、著書ページなど）と紐づき、「同姓同名の別人」と区別できる

逆に言うと、記事末尾に「監修：山田太郎（中小企業診断士）」と書いてあるだけの状態は、人間の読者には伝わっても、AIから見れば照合できる裏付けのない文字列です。本記事では、著者ページ・プロフィール・sameAs・監修者表記を、AIが人物エンティティとして解決できる形に実装する手順を、チェックリストと失敗例つきで解説します。

なお、本記事は人物（著者・監修者）エンティティに限定した実装ガイドです。構造化データ全般の考え方はAI検索時代の構造化データ、会社・ブランドという法人エンティティの整備はWikipedia/Wikidataとブランドエンティティで扱っています。対象が「人」か「法人」かで実装が変わるため、本記事は人に絞ります。

定義：AI検索向けの著者情報設計とは

AI検索向けの著者情報設計とは、記事の著者・監修者を「名前の文字列」ではなく「一意に特定できる人物エンティティ」としてAIや検索エンジンに伝えるための実装のこと。著者ページの整備、記事からのリンク、Person型の構造化データ、sameAsによる外部プロフィールとの紐づけの4要素で構成される。目的は、コンテンツの信頼性評価の枠組みであるE-E-A-T（経験・専門性・権威性・信頼性）の根拠を、機械が照合可能な形で提示することにある。

この定義だけ切り出されても意味が通るように書いています。以降は「なぜ必要か」「何をどう実装するか」の順で進めます。

なぜ今、著者情報がAI検索の論点になるのか

確認できている事実

まず、公式情報で確認できる範囲を整理します。

• E-E-A-Tは、Googleの検索品質評価ガイドラインでコンテンツ品質を評価する枠組みとして定義されている。Experience（経験）・Expertise（専門性）・Authoritativeness（権威性）・Trust（信頼性）の4要素で、「誰がこのコンテンツを作ったのか」が評価の重要な観点とされています。
• Googleは記事の構造化データで、著者をauthor.nameとauthor.urlで示すことを推奨している。名前には肩書きや敬称を混ぜず、author.urlで「著者を一意に特定できるページ」（プロフィールページ等）へリンクするのが公式のベストプラクティスです。複数著者は配列で個別に記述します。
• Googleはプロフィールページ用の構造化データ（ProfilePage）を用意しており、mainEntityにPersonを置き、sameAsで外部プロフィールを示す形を案内している。著者ページ・自己紹介ページがこのマークアップの適用対象として挙げられています。
• 一方でGoogleは、AI Overview / AIモードに表示されるための「AI専用の追加要件や特別な最適化は不要」と明言しています。インデックス登録・スニペット表示可能であることなど、通常の検索の技術要件がそのまま前提です。

ここから先は仮説として扱うべき部分

「著者情報を整備すればAIに引用されやすくなる」という因果関係は、公式に保証されたものではありません。私たちが仮説として置いているのは次の構図です。

AI検索（AI Overview、ChatGPT、Perplexity、Geminiなど）は、回答を組み立てる際に「この情報源は信頼できるか」を何らかの形で判断します。その判断材料として、著者が誰で、どんな裏付けがあるかを機械的に照合できるサイトと、照合できないサイトがあれば、照合できるサイトの方が「信頼性の説明がつく情報源」として扱われやすい、という仮説です。少なくともGoogleの公式ドキュメントが著者ページへのリンクとProfilePageマークアップを推奨している以上、この整備は「AI専用の裏技」ではなく、検索エンジンへの標準的な情報提供をきちんとやることに含まれます。だからこそ費用対効果の高い基礎工事として位置づけられます。

「実装すれば必ず引用される」とは言えません。言えないからこそ、本記事では実装した状態・していない状態の差分をAIが照合できるかという観点でチェックリスト化します。

AIは人物をどう「解決」するのか：名寄せの視点

エンティティ解決（entity resolution）とは、平たく言えば名寄せです。「山田太郎」という文字列が、あなたのサイトの監修者の山田太郎なのか、同姓同名の別業界の山田太郎なのかを、機械が判別する処理を指します。

人間は文脈で判別できますが、機械は照合できる手がかりが必要です。手がかりになるのは次のような情報です。

• 一意のURL：この人物について書かれた正規のページ（著者ページ）が1つ存在するか
• 一貫した表記：サイト内・外部で氏名表記が揺れていないか（漢字/ローマ字、旧姓、ペンネーム）
• 相互参照：著者ページと外部プロフィール（X、LinkedIn、出版社の著者ページ、登壇イベントページ）が互いにリンクしているか
• 所属の裏付け：会社サイトのメンバー紹介にその人物が載っているか、会社エンティティと接続されているか

社名の表記ゆれで別会社と誤認されるリスクは社名の表記ゆれとAI検索で詳しく扱いましたが、人物でも構図は同じです。むしろ人物は同姓同名が多いぶん、照合材料がないと「誰でもない人」として扱われるリスクが高いと考えるべきです。

実装1：著者ページ（プロフィールページ）を作る

すべての起点は、著者1人につき1つの独立した著者ページです。記事末尾の3行プロフィールではなく、URLを持つページとして作ります。

著者ページに書くべき内容

E-E-A-Tの4要素に対応させると、書くべきことが明確になります。

ポイントは、AIが引用しても意味が通る「完結した文」で書くことです。「経験豊富なコンサルタント」という形容ではなく、「〇〇業界で△△件の□□を担当した」という検証可能性のある記述にします。ここで件数や実績を盛るのは逆効果です。外部から裏が取れない誇張は、照合された瞬間に信頼性を毀損します。

ProfilePage / Personの構造化データ

Googleはプロフィールページ向けにProfilePageマークアップを用意しており、mainEntityにPersonを置く形が公式に案内されています。実装で押さえる点は次の通りです（JSON-LDの具体コードは実装環境ごとに異なるため、ここでは設計指針として示します）。

• nameは実名。ハンドルネームで活動している場合はalternateNameに分ける
• jobTitleに肩書きを入れる。nameに「代表取締役 山田太郎」と混ぜない（Googleの記事構造化データのガイドラインでも、nameには名前のみを入れ、肩書きは別プロパティに分けることが明示されています）
• sameAsに外部プロフィールURLを列挙する（次章）
• imageにプロフィール写真を指定する
• worksFor / affiliationで所属組織（Organization）と接続する

構造化データの検証は、実装後にリッチリザルトテストとSchema Markup Validatorの両方で行ってください。構造化データ全体の優先順位づけはAI検索時代の構造化データを参照してください。

実装2：sameAsで「同一人物である」ことを示す

sameAsは、schema.orgで「このエンティティと同一の対象を指すURL」を示すプロパティです。人物エンティティの名寄せにおいて、最も直接的な照合材料になります。

sameAsに入れるURLの優先順位

なんでも並べればよいわけではありません。「その人物であることが第三者的に確認できるURL」を優先します。

重要なのは、リンク先の側にも同一人物であると分かる情報を置くことです。Xのプロフィール欄に所属サイトのURLを書く、出版社の著者ページから見て氏名・所属表記が一致している、という「双方向の一致」があって初めて名寄せ材料として機能します。片方向のsameAsは主張であって、証明ではありません。

実装3：記事側の著者・監修者表記

著者ページができたら、個々の記事側を接続します。

• 記事の著者表記から著者ページへ必ずリンクする。Googleの記事構造化データではauthor.urlで著者を特定できるページを指すことが推奨されています。表示上の著者名も同じページへリンクさせ、構造化データと表示テキストを一致させます。
• 「執筆」と「監修」を区別して表記する。監修者を置く場合、「監修：氏名（著者ページへリンク）」を独立した要素として置き、構造化データ上も執筆者と混同しない形にします。監修と書きながら実態はチェックしていない「名義貸し監修」は、後述の通り最悪の失敗パターンです。
• 氏名表記をサイト全体で統一する。記事Aでは「山田太郎」、記事Bでは「Taro Yamada」、会社概要では「山田 太郎（スペース入り）」のような揺れは、それぞれ別文字列として扱われる余地を残します。正規表記を1つ決め、別表記は著者ページのalternateName側に寄せます。
• 組織名義の記事は無理に人物化しない。編集部名義で出す記事はOrganizationをauthorにするのが正しい実装です。実在しない人物名（ペルソナライター）を作って人物らしく見せるのは、照合すると裏付けが何もない状態を自ら作ることになります。

判断表：どこまでやるべきか

全記事・全著者にフル実装が必要なわけではありません。判断の目安を示します。

実装チェックリスト

実装後の確認に使ってください。すべて「はい」にできれば、人物エンティティとしての照合材料は一通り揃っています。

No.12は実装の「答え合わせ」です。誤った説明が返ってくる場合の是正手順は、AIが自社情報を間違えるときの直し方の考え方が人物にもそのまま使えます。

よくある失敗例

実際のサイト診断で頻出するパターンを挙げます。

失敗1：肩書きだけの監修者表記

「監修：〇〇大学医学部卒 △△クリニック院長」とだけ書かれ、著者ページもリンクもない状態です。人間には権威的に見えますが、機械的にはどこにも照合できない文字列です。さらに、その院長がクリニック公式サイトに載っていない・氏名表記が違うとなると、裏付けの欠如がかえって目立ちます。監修者を置くなら、監修者こそ著者ページとsameAsをフル実装するのが正解です。

失敗2：nameに肩書き・社名を詰め込む

構造化データのauthor.nameに「株式会社〇〇 代表取締役 山田太郎」と入れるパターンです。Googleのガイドラインは名前のみを入れ、肩書き等は別プロパティに分けるよう明示しています。詰め込んだ文字列は「山田太郎」という人物名と一致しなくなり、名寄せを自分で壊すことになります。

失敗3：sameAsの水増し

数を増やそうと、更新停止ブログや専門と無関係な趣味アカウントまでsameAsに列挙するパターンです。照合材料は量より質です。氏名・所属・専門領域が一致して確認できるURLが2〜3件ある方が、雑多な10件より機能します。

失敗4：架空著者・ペルソナライター

「専門家っぽい著者がいた方がよい」という発想で、実在しない人物のプロフィールを作るパターンです。外部にいっさい痕跡のない人物は、照合すれば裏付けゼロであることがそのまま露呈します。E-E-A-Tの根拠を示すための実装で、信頼性を自ら損なう最悪の選択です。組織名義に切り替えるべきです。

失敗5：著者ページを作って放置

作った時点の情報のまま数年放置され、退職済みの所属や終了したサービスが載っているパターンです。著者ページは会社概要と同じく「正しさを維持すべきページ」です。実績・所属が変わったら更新する運用をセットで決めてください。

FAQ：著者情報とAI検索

著者情報を整備すれば、AI検索での引用は増えますか

増えると保証はできません。Googleは、AI Overview / AIモードへの表示に特別な最適化は不要で、通常の検索のベストプラクティスが前提だと公式に述べています。著者情報の整備は「引用を増やす裏技」ではなく、信頼性の根拠を機械が照合できる状態にしておく基礎整備です。引用元としての適格性を説明できる状態を作る、という位置づけで取り組んでください。引用のされ方そのものの設計はAI検索の引用を獲得する考え方で扱っています。

匿名やペンネームで運営しているサイトはどうすればよいですか

実名を出せない場合、無理に人物エンティティを立てる必要はありません。組織（Organization）としての信頼性整備に寄せるのが現実的です。ペンネームで長期の発信実績・著書がある場合は、そのペンネーム自体が照合可能なエンティティになり得るため、ペンネームで一貫させて外部実績と紐づけます。中途半端に実名と使い分けるのが最も照合しにくい状態です。

監修者は外部の専門家に依頼すべきですか

「表記のためだけの監修」なら依頼しない方がよいです。監修の実態（どの範囲を確認したか）を説明できることが前提です。実態のある監修を依頼するなら、その専門家の著者ページを自社サイト内に作らせてもらい、本人の外部プロフィールとsameAsで結ぶところまで含めて設計してください。

効果はどうやって測ればよいですか

直接の測定は難しいのが実情です。実務では、チェックリストNo.12のように主要なAIに著者名・自社名を定期的に質問し、返答の正確さを記録する定点観測が現実的です。AI経由の流入計測はGA4でのAI検索トラフィック計測を参照してください。

まとめ：人物エンティティは「作る」より「照合可能にする」

著者情報のAI検索対応は、立派な経歴を書き並べることではなく、書いてあることが外部と突き合わせて確認できる状態を作ることです。著者ページを1つ立て、記事と構造化データで結び、sameAsで外部の実在証拠と双方向に接続する。この地味な配線作業が、E-E-A-TをAIに対して「主張」から「照合可能な事実」に変えます。

自社サイトの著者・監修者情報が現状どこまで照合可能な状態になっているか、構造化データやエンティティ整備を含めて客観的に把握したい場合は、UravationのLLMO診断（AI検索対応診断）で現状の棚卸しから始められます。まずは本記事のチェックリストでセルフチェックし、判断に迷う箇所が出てきた段階でご相談ください。