AI 検索が 「誰の情報を引用するか」 を決めるとき、最も重視するのは 「著者の信頼性 ()」。本記事では Person スキーマの完全実装と、E-E-A-T を満たす著者ページの作り方を扱います。
1. E-E-A-T の 4 軸
| 軸 | 意味 | 示し方 |
|---|---|---|
| Experience (実体験) | 実際にやった経験がある | 「3 年運用」「100 件試した」等の数字 |
| Expertise (専門性) | 専門知識がある | 資格・学位・職歴・著書 |
| Authoritativeness (権威性) | 業界で認知されている | メディア掲載・登壇・寄稿 |
| Trust (信頼性) | 嘘をつかない | 誤りの訂正・出典明記・誇張なし |
2. Person スキーマの完全例
充実した Person 実装
HTML
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "Person", "name": "松尾 亮", "url": "https://hukuhuku.co.jp/about", "image": "https://hukuhuku.co.jp/profile.jpg", "jobTitle": "代表", "worksFor": { "@type": "Organization", "name": "合同会社ふくふく", "url": "https://hukuhuku.co.jp" }, "description": "28 年のソフトウェア開発経験。データ基盤と AI 受託開発を専門。", "knowsAbout": [ "Data Engineering", "BigQuery", "dbt", "Claude Code", "Generative AI" ], "alumniOf": "(該当する場合の出身大学)", "sameAs": [ "https://x.com/example", "https://github.com/example", "https://linkedin.com/in/example" ]}</script>3. 著者ページに書くべき要素
- 自己紹介 (1-2 段落、専門領域と経験年数)
- 経歴 (時系列・会社・役割)
- 実績 (具体的な数字付き、誇張なし)
- 専門分野 (技術スタック・知見領域)
- 外部リンク (SNS / GitHub / 著書 / 登壇)
- 連絡先 (メール / フォーム)
- 最終更新日 (古い情報は AI から信頼度が下がる)
4. 「実体験」を示す書き方
| 弱い | 強い |
|---|---|
| 「データ基盤に詳しい」 | 「BigQuery を 5 年運用、月 10TB クエリ規模を扱う」 |
| 「AI に詳しい」 | 「Claude Code で受託開発を 8 案件」 |
| 「セキュリティが得意」 | 「ISMS 認証取得支援を 3 社」 |
| 「分析できます」 | 「Tableau ダッシュボード 50 本以上構築」 |
5. 個人 + 組織のバランス
1 人会社・スタートアップこそ Person を強く
「組織が小さくても、個人として顔が見える」 は強いシグナル。逆に大企業は組織名で信頼を確保しやすい。1 人会社 / 個人事業主は、Person を厚く、Organization は会社情報程度でも OK。
6. 著者シグナルの落とし穴
- ❌ AI 生成の「専門家っぽい」プロフィール (実体がないとすぐバレる)
- ❌ 複数記事で著者名がブレる (松尾亮 vs 松尾 亮 vs Ryo Matsuo - 統一する)
- ❌ 更新されないプロフィール (5 年前の経歴のまま)
- ❌ 匿名 + 法人名のみ (Person を省略すると E-E-A-T が立ちにくい)
- ❌ 誇張・捏造 (信頼を一発で失う、E-E-A-T の Trust 失格)
7. 次の話
EP.05 では 業界別 LLMO 対策 に進みます。B2B SaaS / EC / メディア / コーポレートの 4 業態それぞれの最適戦略を整理します。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。