著者の構造化データの書き方｜AIに権威を伝える手順

「良い記事を書いているのに、AI検索に引用されない」。その原因のひとつが、記事を書いたのが誰なのかをAIが判断できていないことです。

この記事では、著者構造化データ（著者の情報を機械が読める形で記述するコード）の具体的な書き方を、コピペで使えるJSON-LDと検証のやり方まで含めて解説します。専門知識がなくても、順番どおりに進めれば実装できる形でお伝えします。

Contents / 目次

1. 結論。著者構造化データは「誰が書いたか」をAIに伝える土台になる
2. 著者構造化データの書き方。5ステップで実装する
3. 実装するとどう変わるか。期待できる効果と成功企業の共通点
4. よくある失敗と回避法。現場でつまずくポイント
5. 現場の本音。ここは割り切りが必要という話
6. よくある質問

結論。著者構造化データは「誰が書いたか」をAIに伝える土台になる

先に結論をお伝えします。著者構造化データとは、記事を書いた人の名前・肩書き・専門分野・外部プロフィールへのリンクを、AIや検索エンジンが読み取れる形式（JSON-LD）で記述したものです。これを整えると、AIが「この情報は、その分野に詳しい特定の人物が書いた」と認識しやすくなります。

Googleは、コンテンツ品質を評価する考え方としてE-E-A-T（経験・専門性・権威性・信頼性の4つの頭文字）を示しています。この4要素のひとつが、経験（Experience）を持つ実在の人物が書いているかという点です。

ここで大事なのは、優先順位です。著者構造化データは「土台」ですが、コードだけ入れても効果は限定的です。やるべきことは大きく3つあります。

• 著者の実体をつくる：専用の著者ページに、経歴・専門分野・顔写真・外部プロフィールへのリンクを用意する
• 機械可読にする：Person schemaを書き、記事のArticle schemaのauthorと紐づける
• Web全体で一致させる：著者名・肩書き・専門分野を、自社サイト内でも外部サービスでも同じ表記に揃える

この3つはセットです。コードが正しくても著者ページが空なら、AIは裏付けを取れません。逆にプロフィールが充実していても、機械可読な形になっていなければ、AIは関係性を読み解きづらくなります。GEO全体の進め方はGEO対策のやり方を7手順で解説した記事でも整理しているので、あわせて読むと位置づけが分かりやすくなります。

まず、著者構造化データが「何をする道具か」を表で整理しておきましょう。

項目	やること	AIに伝わること
Person schema	著者の名前・肩書き・専門分野を記述	「誰が」書いたか
author プロパティ	Article schema内で著者を指定	記事と著者の結びつき
sameAs	LinkedInなど外部プロフィールへのリンク	実在する同一人物だという裏付け
著者ページ	経歴・実績・執筆記事一覧を掲載	専門性と経験の中身
knowsAbout	詳しい分野を明示	どのテーマの専門家か

押さえどころ。構造化データは「AIに読ませるための翻訳」です。ページに書いていないことを構造化データに書くのはルール違反（表示内容との不一致）なので、まず人間が読む著者ページを整え、その内容をコードに写す順番で進めます。

著者構造化データの書き方。5ステップで実装する

ここからが記事の主役です。実際に手を動かせるよう、準備からコード実装、検証までを5つのステップに分けて解説します。JSON-LD（構造化データを書くための推奨フォーマット）はHTMLと分けて書けるので、非エンジニアの方でも扱いやすい形式です。

ステップ1。著者ページ（著者アーカイブ）を用意する

最初にやるのは、コードではなく著者ページの整備です。構造化データのリンク先になる「実体」を先に作ります。WordPressなら投稿者アーカイブページがこれにあたります。

著者ページに載せる情報は次のとおりです。ここが薄いと、後のコードがいくら正しくても信頼の裏付けになりません。

• 氏名：本名またはサイト全体で統一した表記
• 顔写真：本人と分かる、加工しすぎていない写真
• 現在の肩書きと所属：「株式会社◯◯ 代表取締役」など
• 専門分野と経験年数：「◯◯領域で約20年」のように具体的に
• 実績：登壇・寄稿・取材実績、保有資格
• 外部プロフィールへのリンク：LinkedIn、X、個人サイトなど
• 執筆記事の一覧：そのテーマで書き続けている証拠

ステップ2。Person schemaを書く

次に、著者本人の情報をPerson schemaで記述します。これは著者ページの内容を、AIが読める形に翻訳する作業です。以下はそのままたたき台に使える例です。［ ］の部分を自社の値に置き換えてください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/author/deguchi/#person",
  "name": "出口 宣佳",
  "jobTitle": "代表取締役",
  "worksFor": {
    "@type": "Organization",
    "name": "株式会社コレットラボ",
    "url": "https://colet-lab.jp/"
  },
  "url": "https://example.com/author/deguchi/",
  "image": "https://example.com/img/deguchi.jpg",
  "description": "プロモーション・マーケティングの現場で約20年。中小企業のAI導入を伴走支援。",
  "knowsAbout": ["AI導入支援", "GEO", "業務システム化"],
  "sameAs": [
    "https://www.linkedin.com/in/［アカウント名を入力］",
    "https://x.com/［アカウント名を入力］"
  ]
}
</script>

ポイントは3つあります。

• @idは他のコードから著者を参照するための識別子です。
• knowsAboutには得意分野を入れ、記事の内容と揃えます。
• sameAsには、本人が管理していると確認できる外部プロフィールだけを並べます。

ステップ3。記事のArticle schemaと著者を紐づける

Person schemaを書いただけでは、「この人が、この記事を書いた」という関係がまだつながっていません。記事側のArticle schemaで、authorプロパティを使って結びつけます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "［記事タイトルを入力］",
  "datePublished": "2026-07-14",
  "dateModified": "2026-07-14",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/author/deguchi/#person"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社コレットラボ",
    "url": "https://colet-lab.jp/"
  }
}
</script>

ここでauthorの中を@idだけにしているのは、ステップ2で書いたPerson schemaを参照させるためです。こうすると情報が一箇所にまとまり、名前や肩書きを更新するときに書き換える場所が減ります。dateModifiedは記事を更新したら必ず直します。実際の更新内容と日付が食い違わないようにするためで、日付だけ新しくしても順位が上がるわけではありません。

ステップ4。プラグインを使う場合の進め方

WordPressを使っているなら、コードを手書きせずプラグインで著者スキーマを生成する方法もあります。構造化データに対応したSEOプラグインの中には、著者情報を生成できるものもあります。ただし対応状況やプロパティの範囲、設定方法はプラグインやバージョンによって異なるため、導入前に使うプラグインの公式ドキュメントで確認してください。

プラグインを使う場合でも、やることの本質は同じです。プロフィール欄に経歴・SNSリンク・専門分野を入力し、その情報をプラグインがschemaに変換します。つまり入力する中身が薄ければ、出力される構造化データも薄いという点は変わりません。具体的な設定画面の名称やメニュー位置は更新で変わることがあるため、正確な手順は各プラグインの公式ドキュメントで確認してください。

ステップ5。検証ツールでエラーを確認する

最後に、書いたコードが正しく認識されるかを検証します。構造化データは、括弧ひとつ抜けるだけで全体が無効になるため、この確認は必須です。

検証は次の順番で進めます。

1. Schema.orgのPerson仕様で、使うプロパティの名称や書き方が正しいかを確認する
2. 公開後は、Google Search Consoleで構造化データのエラーや警告がサイト全体で出ていないかを定期的に確認する

Googleの構造化データの考え方はGoogle検索セントラルの構造化データ入門でも解説されています。

検証をとばして公開すると、JSONの構文エラーで著者情報がまるごと無視されることがあります。目視では気づきにくいので、必ずツールに通してから公開してください。

実装するとどう変わるか。期待できる効果と成功企業の共通点

成果を出している企業には共通点があります。単発でコードを入れて終わりにせず、著者・組織・記事の3つの情報を一貫してつなぎ続けている点です。具体的には次のような取り組みです。

• テーマを絞る：あれこれ手を広げず、決まった専門領域で書き続けている
• 著者を固定する：記事ごとに書き手を変えず、同じ著者に実績を積み上げている
• 表記を揃える：著者名や肩書きを、サイト内でも外部サービスでも統一している
• 更新を続ける：古くなった情報を直し、dateModifiedを最新に保っている

注意したいのは、効果の出方です。構造化データは検索順位を即座に押し上げる魔法ではありません。E-E-A-Tの評価は、複数の記事や外部の言及が積み重なって初めて安定します。数週間で結果を求めるより、半年から1年かけて「この会社（この著者）は、この分野の発信元だ」という認識を育てる取り組みだと考えるのが現実的です。

関連して、AI検索で見られる会社概要ページの整え方はAI検索に強い会社概要ページの作り方チェックリストにまとめています。著者ページと会社概要は、どちらも「実体を伝える」役割で連動するので、セットで整えると効果が高まります。

よくある失敗と回避法。現場でつまずくポイント

著者構造化データは、正しく書けば効きますが、間違えると逆効果になったり、まったく認識されなかったりします。現場でよく見かける失敗を、起きる状況・結果・防ぎ方のセットで紹介します。

失敗1。ページに書いていないことを構造化データに書く

これはもっとも危険な失敗です。実績を盛りたくて、著者ページには載せていない資格や肩書きを構造化データにだけ書いてしまうケースがあります。

構造化データの情報は、ユーザーに表示されるページの内容と一致している必要があるとGoogle検索セントラルが示しています。不一致は、手動対策（ペナルティ）につながる可能性があります。防ぎ方はシンプルです。まず著者ページに事実を書き、それをそのままコードに写す。この順番を絶対に崩さないことです。

失敗2。著者名の表記がバラバラになっている

「出口宣佳」「出口 宣佳」「Deguchi」のように、記事や外部サービスごとに表記が揺れている状態です。人間には同じ人だと分かっても、AIは別人の可能性を疑います。

結果として、せっかく積み上げた実績が一人の著者にまとまらず、権威が分散します。防ぐには、著者名のフォーマットをひとつに決め、全記事・全プロフィールで統一します。SNSや外部の寄稿先も、可能な範囲で同じ表記に揃えましょう。

失敗3。sameAsに外部プロフィールを一切つながない

Person schemaは書いたのに、sameAsを空のままにしている、あるいはプロパティ自体を省いているケースです。この状態だと、AIは「本当に実在する人物か」を外部から確認する手がかりを持てません。

LinkedInやX、業界団体のプロフィールなど、本人が管理していると確認できるページをsameAsに並べると、実在性の裏付けになります。Wikipediaページがなくても代替手段はあるので、その考え方はWikipediaがなくてもAIに権威を伝える代替策で詳しく解説しています。

失敗4。関係のないschemaを詰め込む

効果を狙って、記事に関係のないschemaを大量に足してしまう失敗です。サービス業なのに製品用のschemaを入れる、といったミスマッチも含まれます。

関連性のないschemaを足しても、著者を伝える効果は増えません。かえってページの内容と構造化データがちぐはぐになる原因になります。使うのは、そのページの内容に合ったschemaだけにしましょう。著者を伝えたいならPersonとArticleのauthor、それで十分です。

現場の本音。ここは割り切りが必要という話

ここまで手順を書いてきましたが、実際に運用してみると「教科書どおりにいかない」場面が出てきます。相談を受ける中でよく感じる、率直な妥協点をお伝えします。

まず、構造化データは「入れれば順位が上がる」ものではありません。構造化データの役割は「見た目を派手にする」ことから「AIに内容を正しく理解させる」ことへ移ってきています。

だから、リッチな表示を期待して入れると肩透かしを食らいます。目的は表示ではなく、AIの理解を助けることだと割り切るのが正解です。

次に、内製と外注の線引きです。JSON-LDを書くこと自体は、テンプレートがあれば非エンジニアでも十分こなせます。難しいのはコードではなく、その手前にある「著者の実績づくり」と「Web全体での一貫性の維持」です。ここは地道で終わりがなく、片手間だと続きません。

コストの見落としもよくあります。構造化データの実装は一度きりですが、著者ページの更新、外部プロフィールの整合、記事の追加は運用として続きます。「入れて終わり」の予算感で始めると、半年後に更新が止まって形骸化します。最初から運用込みで考えておくことをおすすめします。

向き不向きもあります。会社名だけで発信していて、特定の書き手を前面に出す文化がない企業だと、著者構造化データの効果は出にくくなります。その場合は、まず匿名運用を実名化すべきかという判断から入ることになります。この点は匿名の社員ブログを実名化すべきかを判断する記事で掘り下げています。無理に実名を出すより、組織としての権威を先に固める道もあります。

ちなみに、こうしたコードの生成や検証には、Claude（Anthropic）のようなAIを使うと作業が速くなります。ただし、AIが出したJSON-LDは実在しないプロパティを混ぜることがあるため、必ず検証ツールに通してから使ってください。生成は任せても、最終確認は人がやる。ここは崩さないほうが安全です。

よくある質問

ここまで読んで、著者構造化データの整備を自社だけでやり切るのは大変そうだと感じた方もいるかもしれません。AIに「おすすめ」として紹介される記事づくりの詳細はこちらから、いまの状況を整理するだけのご相談も歓迎です。まずはお話を聞かせてください。