AI 検索が普及した今、記事が読まれる前に、その情報源を信頼してよいかを機械が判断します。Google の検索品質評価で語られてきた E-E-A-T（経験・専門性・権威性・信頼性）は、AI Overviews や各種 AI 検索が「どの情報を引用するか」を選ぶ局面で、改めて重みを増しています。
ところがこの判断材料の多くは、本文を最後まで読まないと分からない形で散らばっています。誰が書いたのか、その人は何の専門家なのか、運営しているのはどんな組織なのか。人間なら著者プロフィールや会社概要をたどって確かめますが、機械にとってはテキストの中に埋もれた情報にすぎません。
そこで効くのが構造化データです。著者を Person、運営者を Organization として明示し、sameAs で外部のプロフィールに連結しておくと、「誰が・どんな専門性で・どの組織から発信したか」が機械可読になります。この記事では、その設計と実装を、当サイト自身の JSON-LD 実装を一次情報として具体的に解説します。
結論：AI 時代の E-E-A-T は「誰が書いたか」を構造化する
先に結論を述べます。AI 検索時代の E-E-A-T 対策の中核は、コンテンツの中身を磨くことに加えて、その発信者を機械可読なエンティティとして定義し、外部の信頼できるプロフィールに結びつけることです。
具体的には次の三点に集約されます。
著者を Person スキーマで表現し、jobTitle（肩書き）と knowsAbout（専門領域）でその人が何の専門家かを宣言する。運営者を Organization スキーマで表現し、所在地・法人名・専門領域を示す。そして両者に sameAs を付け、X・GitHub・登記情報などの外部プロフィールに連結して、エンティティの実在性と同一性を裏付ける。
注意したいのは、構造化データそのものが E-E-A-T のスコアを直接上げるわけではない、という点です。E-E-A-T はあくまで評価の枠組みであり、Person を入れたから加点される、という単純なものではありません。構造化データの役割は、評価される材料を機械が誤読しない形で差し出すことにあります。中身が薄ければ意味がなく、逆に中身が良くても発信者が曖昧なら正当に評価されません。両輪です。
この考え方は、AI 検索全体への最適化の一部でもあります。引用される記事構造をより広く整理したAI モード時代の SEO とはも合わせて読むと、E-E-A-T 補強がどこに位置づくか掴みやすくなります。
E-E-A-T と AI 検索の引用判断の関係
E-E-A-T は Experience（経験）、Expertise（専門性）、Authoritativeness（権威性）、Trustworthiness（信頼性）の頭文字です。もともとは Google の検索品質評価ガイドラインの語彙で、評価者が「このページは信頼に足るか」を見極めるための観点として使われてきました。
AI 検索の登場で、この観点は別の意味で重要になりました。AI は無数のページから回答を組み立てるとき、すべてを等しく信頼するわけにはいきません。誤った情報を引用すれば回答そのものの品質が落ちるため、引用元の信頼性を何らかの形で見積もる必要があります。このとき手がかりになるのが、発信者が誰か、その分野に詳しいか、実在する組織か、外部からも参照されているか、といったエンティティレベルの情報です。
人間の読者は、記事末尾の著者プロフィールやフッターの会社情報を見て直感的に信頼度を測ります。しかし機械は、本文中に「筆者は 10 年フロントエンドをやっています」と書いてあっても、それが検証可能な事実なのか、ただの文字列なのかを区別しづらい。だからこそ、信頼の根拠を構造化データという形式で、明示的かつ機械可読に提示しておく価値があります。
ここで鍵になるのが「エンティティ」という発想です。著者「Tsumiki」や運営「FIXIT」を、単なる名前の文字列ではなく、一意の識別子（@id）を持つ実体として扱う。同じ識別子が複数の記事・複数のページから参照されることで、機械の側に「この発信者は継続して存在し、これらのテーマで発信している」という像が形作られていきます。これが Knowledge Graph 的な理解の出発点になります。
著者ページに Person スキーマと knowsAbout を持たせる
最初の一手は、著者ごとに専用ページを設け、そこに Person スキーマを置くことです。著者情報が記事のフッターにテキストで散らばっているだけの状態から、一意の URL を持つ著者エンティティへと格上げします。
当サイトの著者ページでは、次のような Person の JSON-LD を出力しています。実際の生成ロジックを抜粋します。
export const buildPersonSchema = (
input: PersonSchemaInput,
): WithContext<Person> => ({
"@context": "https://schema.org",
"@id": `${siteConfig.url}/authors/${input.slug}/#person`,
"@type": "Person",
name: input.name,
url: `${siteConfig.url}/authors/${input.slug}/`,
...(input.role ? { jobTitle: input.role } : {}),
...(input.bio ? { description: input.bio } : {}),
...(input.knowsAbout && input.knowsAbout.length > 0
? { knowsAbout: input.knowsAbout }
: {}),
// 著者の外部プロフィール (X / GitHub 等) を sameAs で連結し、
// 「誰が書いたか」を AI 検索・Knowledge Graph に伝える E-E-A-T シグナル。
...(input.socials && input.socials.length > 0
? { sameAs: input.socials.map((social) => social.url) }
: {}),
worksFor: { "@id": ORG_ID },
});ポイントは 3 つあります。
まず @id に著者ページの URL とフラグメント（#person）を組み合わせた一意の識別子を与えています。これにより、記事側からこの著者を参照するときも、同じ @id を指し示すだけで「同一人物」だと機械に伝わります。名前の文字列照合に頼らず、識別子で同一性を担保するのが要点です。
次に jobTitle と knowsAbout で専門性を表現しています。jobTitle は「フロントエンドエンジニア」のような肩書き、knowsAbout は「Next.js」「React」「TypeScript」「AI 駆動開発」といった具体的なテーマの配列です。AI 検索がこの著者の記事をフロントエンドの文脈で引用すべきか判断するとき、knowsAbout は直接的な根拠になります。
そして worksFor で運営組織への参照を持たせています。著者単体ではなく、所属組織と結びつけることで、個人と組織の権威性が相互に補強し合う関係になります。
実装の負担を抑えるため、これらの値はソースのべた書きではなく、著者定義ファイルから供給しています。たとえばある著者の定義はこのようになっています。
slug: tsumiki
name: Tsumiki
role: フロントエンドエンジニア
bio: |
Next.js・React・TypeScript を中心に、モダンなフロントエンド基盤と
ツールチェーン整備を担当。新しいツールをいち早く試し、AI 駆動開発の
現場に取り込むのが得意です。
knowsAbout:
- Next.js
- React
- TypeScript
- フロントエンド
- AI 駆動開発role が jobTitle に、bio が description に、knowsAbout がそのまま配列にマッピングされます。著者を一人追加するときは YAML を一枚足すだけで、Person スキーマも著者ページも自動で揃う構造です。後述しますが、この「データを一箇所に置いて、各種スキーマへ展開する」設計が、E-E-A-T を破綻なく運用し続けるうえで効いてきます。
運営者を Organization + sameAs で外部プロフィールに連結する
著者という個人だけでは、信頼性の土台としては足りません。その人がどんな組織に属し、その組織が実在するのかという裏付けが、サイト全体の信頼性を支えます。ここで Organization スキーマの出番です。
当サイトでは、サイト全体で共有する単一の Organization エンティティを定義し、すべての記事・著者がこれを参照します。実装は次の通りです。
export const organizationSchema: WithContext<Organization> = {
"@context": "https://schema.org",
"@id": ORG_ID,
"@type": "Organization",
address: {
"@type": "PostalAddress",
addressCountry: "JP",
addressLocality: "中央区",
addressRegion: "東京都",
postalCode: "104-0061",
streetAddress: "銀座1丁目12番4号 N&E BLD.6F",
},
description:
"Claude Code、Cursor、AI エージェントを実プロジェクトに組み込み、開発速度と品質の両立を実現する、AI 駆動開発のクリエイティブスタジオ。",
knowsAbout: [
"AI駆動開発",
"AIエージェント開発",
"Claude Code",
"Cursor",
"生成AI",
],
legalName: "株式会社フィット",
name: siteConfig.name,
// 検証済みの公式 SNS プロフィール。Organization エンティティを外部の
// 信頼できるプロフィールに連結し、E-E-A-T と Knowledge Graph を補強する。
sameAs: ["https://x.com/fixit_inc", "https://github.com/fixit-inc"],
url: siteConfig.url,
};Organization で重視しているのは、実在性を裏付ける情報を揃えることです。legalName（登記上の法人名）、address（所在地）を明示することで、「ペーパーカンパニーではなく、住所も法人名も特定できる実在の組織だ」という事実を機械に伝えます。description と knowsAbout は組織としての専門領域を示し、どの分野の発信者として信頼されるべきかを補強します。
そして要となるのが sameAs です。ここには組織が運営していると検証できる外部プロフィール、当サイトの場合は公式 X と GitHub の URL を入れています。sameAs は schema.org において「このエンティティと同一のものを指す別の URL」を宣言するプロパティで、Organization を外部の足跡に結びつける役割を担います。
sameAs を効かせるコツは、数を増やすことではなく、検証済みであることと相互参照が成立していることです。リンク先のプロフィール側にも、こちらの公式サイトへのリンクが張られている、という双方向の関係があると、機械は「確かに同一主体だ」と判断しやすくなります。本人・自社と無関係なページや、放置されたアカウントを並べても信頼の足しにはなりません。
なお、運営組織は @id（ORG_ID）という一意の識別子で定義しており、著者の worksFor、記事の publisher、サービスの provider など、サイト中のさまざまなスキーマがこの一点を参照します。組織エンティティを一箇所に集約し、全体から参照する設計が、矛盾のない一貫した信頼グラフを作るうえで重要です。
記事と著者・運営をどう JSON-LD でつなぐか（author / publisher）
著者の Person、運営の Organization が用意できたら、個別の記事からこれらを正しく参照して、三者を 1 つの信頼グラフとして結びます。ここで役割を取り違えやすいのが author と publisher の使い分けです。
author は記事を実際に書いた人物、publisher は記事を発行する組織を指します。著者は個別記事の専門性を担い、発行元はサイト全体の信頼性を担う、という分担です。当サイトの記事スキーマ生成ロジックは次のようになっています。
export const buildArticleSchema = (
input: ArticleSchemaInput,
): WithContext<Article> => ({
"@context": "https://schema.org",
"@type": articleType(input.section),
author: buildAuthorSchema(input.author),
datePublished: input.datePublished,
dateModified: input.dateModified ?? input.datePublished,
headline: input.title,
description: input.description,
inLanguage: "ja-JP",
isPartOf: { "@id": SITE_ID },
mainEntityOfPage: { "@type": "WebPage", "@id": input.url },
publisher: { "@id": ORG_ID },
url: input.url,
});publisher は { "@id": ORG_ID } という参照だけを持たせています。Organization の本体は別途出力済みなので、ここでは識別子で指し示すだけで十分です。同じ @id を共有することで、サイト内のすべての記事が「同一の発行元から出ている」と機械に伝わります。
author 側は、誰が書いたかによって Person か Organization かを切り替えています。実際の分岐を見てみます。
const buildAuthorSchema = (
author: ArticleAuthorInput,
): Person | Organization => {
const isPerson = !!author.slug && author.slug !== "fixit-editorial";
if (!isPerson) {
return { "@type": "Organization", "@id": ORG_ID, name: author.name };
}
return {
"@type": "Person",
"@id": `${siteConfig.url}/authors/${author.slug}/#person`,
name: author.name,
url: `${siteConfig.url}/authors/${author.slug}/`,
...(author.role ? { jobTitle: author.role } : {}),
...(author.knowsAbout && author.knowsAbout.length > 0
? { knowsAbout: author.knowsAbout }
: {}),
worksFor: { "@id": ORG_ID },
};
};個人著者の記事では、著者ページの Person と同じ @id（/authors/{slug}/#person）を指す Person を author に据えます。著者ページ側にフルプロフィールの Person、記事側に同一 @id の Person 参照があることで、機械はこれらを同じ人物として束ね、その著者が手がけた記事群を辿れるようになります。編集部名義など個人著者を立てない記事では、author を Organization（発行元と同じ @id）にしています。
整理すると、記事は author で著者 Person を、publisher で運営 Organization を、それぞれ @id で参照する。著者 Person は worksFor で運営 Organization を参照する。こうして記事・著者・運営が一意の識別子で相互に結ばれ、1 つの信頼グラフが完成します。この構造が崩れていると、AI 検索は「どの組織が出した、誰の記事か」を確信を持って辿れません。
なお記事スキーマには、後述の FAQ を FAQPage として併記すると、回答抜粋の引用に直結します。FAQ の構造化についてはFAQPage 構造化データで AI 検索に答えを届けるで詳しく扱っています。
MDX の authors 定義から著者情報を構造化する設計
ここまでの実装で見落とせないのが、データソースの一元化です。著者情報を記事ごとに手書きしていたら、表記ゆれや記載漏れがすぐに発生し、信頼グラフはあっという間に綻びます。E-E-A-T の構造化は、一度作って終わりではなく、記事を書き続けるあいだ整合性を保ち続けることが本質的に難しいのです。
当サイトでは、著者情報を content/authors/{slug}.yml という単一の定義ファイルに集約しています。先に挙げた YAML がそれです。コンテンツビルド時にこの定義をスキーマで検証し、不正な値が混じったままビルドが通らないようにしています。著者定義のバリデーションは概ね次の形です。
const authors = defineCollection({
name: "Author",
pattern: "authors/*.yml",
schema: s.object({
slug: s.slug("authors"),
name: s.string().max(40),
role: s.string().max(60).optional(),
bio: s.string().max(400).optional(),
knowsAbout: s.array(s.string()).default([]),
socials: s
.array(
s.object({
type: s.enum(["x", "github", "linkedin", "note", "zenn"]),
url: s.string().url(),
}),
)
.default([]),
}),
});socials の type を列挙型に絞り、url を URL 形式で検証しているのがポイントです。sameAs に入る外部プロフィールは E-E-A-T の根幹なので、形式不正な URL や想定外の種別が紛れ込まないよう、入口で弾く設計にしています。著者ページの Person も、各記事の author も、この同じ定義ファイルから値を引きます。
この設計には次の利点があります。
- 表記ゆれが起きません。著者名や専門領域が一箇所で管理されるため、記事 A と記事 B で同じ著者の
knowsAboutが食い違う、といった事故が構造的に起きません。 - 著者の追加・更新が YAML 一枚で完結します。新しい著者が加わってもスキーマ実装に手を入れる必要がなく、運用の継続性が保たれます。
- ビルド時検証によって、構造化データが壊れた状態で本番に出ることを防げます。
このように、設計でデータを一元化し、検証で品質を担保する発想は、AI 駆動開発でドキュメントやデータを整備する考え方とも通じます。背景はAI 駆動開発とは何かで触れています。
一次情報・実績で E-E-A-T を裏付ける（作話を避ける運用）
最後に、技術実装より重要かもしれない論点に触れます。構造化データはあくまで器であり、中身が伴わなければ意味がない、ということです。
knowsAbout に「AI 駆動開発」と書いても、その分野の実務に裏打ちされた一次情報を発信していなければ、専門性の主張は空回りします。AI 検索も読者も、最終的には中身を見ます。むしろ、専門性を構造化データで強く主張しているのに本文が一般論の寄せ集めだと、主張と実態の乖離としてマイナスに働きかねません。その一次情報を結論先出しや質問形式の見出しで引用されやすい形に整える書き方は、AI Overviews に引用されるための記事構造で解説しています。
ここで効いてくるのが、自分たちが実際にやっていることを一次情報として書く姿勢です。この記事自体が 1 つの例で、E-E-A-T の構造化を語るにあたり、当サイトが実際に運用している JSON-LD 生成ロジックや著者定義ファイルを引用しました。これは検証可能な一次情報であり、「やったことを書いている」という事実そのものが Experience と Expertise の裏付けになります。
逆に避けるべきは作話です。E-E-A-T を盛ろうとして、ありもしない実績や根拠のない数値を書いてしまうと、信頼性は土台から崩れます。クライアント事例を書くなら業種と規模の匿名表記に留め、効果は「数倍」程度の穏当な表現にする。経験していないことを経験したかのように書かない。地味ですが、検証可能な範囲で正直に書き続けることが、長期的には最も強い E-E-A-T になります。
運用面では、次のサイクルを回すことをおすすめします。著者の専門領域に沿ったテーマで、実務に基づく一次情報を書く。その著者を Person で構造化し、外部プロフィールと sameAs で連結する。記事は author・publisher で著者と運営に結びつける。そして著者情報は単一のデータソースで一元管理し、ビルド時に検証する。器（構造化データ）と中身（一次情報）の両方を、運用で破綻なく保ち続ける。これが AI 検索時代の E-E-A-T 対策の実像です。
まとめ
AI 検索時代の E-E-A-T は、コンテンツの質を磨くことに加えて、「誰が・どんな専門性で・どの組織から発信したか」を機械可読にすることで補強できます。著者を Person、運営を Organization として一意の @id で定義し、jobTitle・knowsAbout で専門性を、sameAs で外部プロフィールへの連結を示す。記事は author と publisher で両者を参照し、1 つの信頼グラフを形作る。そして著者情報は単一データソースで一元管理し、ビルド時に検証して整合性を保つ。
構造化データはスコアを直接上げる魔法ではありませんが、正当に評価されるための材料を機械へ過不足なく差し出す土台です。そのうえに、検証可能な一次情報という中身を積み上げていくことが、引用されやすい権威性につながります。
当サイトの著者一覧では、各執筆者の専門領域と外部プロフィールを構造化して公開しています。E-E-A-T 対策や構造化データの設計を含め、AI 検索に強いサイト構築・コンテンツ運用を検討している方は、お問い合わせからお気軽にご相談ください。あわせてAI モード時代の SEO とはも、全体像の把握に役立ちます。