AI記事にE-E-A-Tを足す方法｜評価されない原因は経験

AIで記事を書いているのに検索で評価されない。この相談を受けるとき、原因としてまず疑われるのは「AIで書いたこと」そのものです。ところがGoogleは2023年2月の公式ブログで、"Appropriate use of AI or automation is not against our guidelines."（AIや自動化の適切な使用は、当社のガイドライン違反ではありません）と明言しています。評価されない理由を「AIを使ったから」に置くかぎり、直すべき場所にたどり着けません。

結論を先に書きます。AIで書いたこと自体は問題になりません。足りないのはE-E-A-Tのうち Experience（経験）と Trust（信頼性）です。Google 検索セントラルはE-E-A-Tの4要素について「中でも、信頼性は最も重要なものです。その他の項目も信頼性の一因となるものですが、必ずしもすべてにおいて優れている必要はありません。」と位置づけています。そして検索品質評価ガイドラインは Experience を「そのトピックについて、コンテンツ作成者が必要な一次的経験または実体験を持っているか」として測ります。AIは公開された情報を要約できますが、自社が実際に踏んだ経験と、自社が責任を取るという事実は、人が渡さないかぎりどこからも湧いてきません。

先に誤解も解いておきます。E-E-A-T はランキング要因そのものではありません。Google は「E-E-A-T そのものは特定のランキング要素ではないが、良いE-E-A-Tを備えたコンテンツを見つけられる複数の要素の組み合わせを使うことは有用である」と書いています。つまり「E-E-A-Tを上げれば順位が上がる」という因果の線はなく、順位に効くのはその評価軸が見ようとしている中身そのものです。この記事では、その中身をAI記事にどう実装するかだけを扱います。

E-E-A-Tの4要素 × AIが自力で埋められるか × 人が渡すもの

いちばん最初に見てほしいのがこの表です。AI記事の運用でつまずく箇所は、ほぼ「AIが自力で埋められない欄を、誰も埋めないまま公開している」ことに集約されます。

右端の列が空のまま公開された記事は、読めば正しいのに、どこにも「この会社が書いた理由」が残りません。これは量産の規模とは無関係に起きます。規模まで加わったときに何が起きるかはAI記事の量産がペナルティにつながる条件に分けて書きました。

公式が実際に言っていること

ここは推測を混ぜると全部が崩れる部分なので、Googleの文言だけを並べます。

AI生成そのものは違反ではない。違反になるのは目的

Googleは「制作方法を問わず高品質なコンテンツを評価する」という立場を示しており、AIの使用自体を禁じていません。禁じられているのは目的のほうです。検索セントラルは「検索ランキングを操作することを目的にAI生成などの自動化を使用してコンテンツを作成している場合、その行為はGoogleのスパムに関するポリシーに違反していると見なされます」と書いています。

この線引きは、読み手にとっての有用性がどちらを向いているかで決まります。ツールが人かAIかは問われていません。だから「AIで書いている」ことを隠す必要もありません。むしろ後述の「どのように」の設問は、自動化やAIの使用を開示しているかを問うています。

4要素の中で最も重要なのは Trust

E-E-A-Tは4つ並んでいるので均等に見えますが、公式の位置づけは均等ではありません。検索セントラルは「中でも、信頼性は最も重要なものです。その他の項目も信頼性の一因となるものですが、必ずしもすべてにおいて優れている必要はありません。」としています。

実務的な意味は大きいです。権威性が足りない中小企業でも、信頼性なら今日から積めるからです。運営者が誰かを明示する、出典を置く、更新日を正直に出す、間違いを直した記録を残す。どれも予算ではなく運用の問題です。逆に、信頼性を欠いたまま専門性の濃い文章を増やしても、土台のない階を積むことになります。

「誰が・どのように・なぜ」に答えられるか

検索セントラルはコンテンツの自己点検として、Who（誰が）・How（どのように）・Why（なぜ）の3つを挙げています。公式の設問はおおよそ次の形です。

• 誰が——コンテンツを書いたのが誰か、訪問者にとって自明か。バイラインはあるか。著者の経歴や背景にたどり着けるか。
• どのように——どう作られたかを説明しているか。自動化やAIを使っているなら、それを開示しているか。なぜその方法を選んだかを説明できるか。
• なぜ——そのコンテンツを作る本来の理由は何か。公式は「主として人々の役に立つコンテンツを作成すること」であるべきだとしています。

AI記事が評価されないとき、この3問に声に出して答えてみると、だいたい「誰が」と「なぜ」で止まります。「社名は入っているが執筆者が誰か分からない」「このテーマを自社が書く理由が本文のどこにも無い」。この2つが埋まっていない記事は、人が書いてもAIが書いても同じように薄く見えます。

補足：E-E-A-Tは「スコア」ではない

E-E-A-Tは検索品質評価者がページ品質を測るための概念で、評価者の付けた点がそのままページの順位になるわけではありません。Google自身が「E-E-A-Tそのものは特定のランキング要素ではない」と明記しています。だから「E-E-A-T対策」という名前の施策リストを順番に消しても順位は動きません。動くのは、評価軸が見ようとしている実体（経験・専門性・参照され方・信頼）を本当に足したときです。

Experience を足す具体的な手

ここから先はMihataの実測です。私たちは自社サイトのコラムを800本以上、AIを使って毎日運用しています。生成・公開・内部リンク・改稿までを自動で回し、その結果を自分たちで毎朝見ています。その中でいちばんはっきりした結論が、AIが一番書けないのはExperienceであるということでした。

外部の情報を要約するだけだと、どの記事も同じ構成に収束します。見出しの並びまで似てきます。理由は単純で、材料が同じだからです。差がつくのは材料が自社にしかないときだけでした。

自分が踏んだ失敗を、再現できる形で1つ書く

効果がはっきり出たのは、記事ごとに自分が踏んだ失敗を1つ、再現できる形で書くやり方です。抽象的な教訓ではなく、何が起きて、何を見て、何が原因で、どう直したかを順に書きます。

このサイトで実際に起きたことを例にします。2026年9月末から10月初めにかけて、記事の公開処理が8日間にわたって失敗し続けました。やっかいだったのは、CMSが毎回「成功」を返していたことです。APIのレスポンスは正常、ページを開けばHTTP 200。表向きは何の問題もありません。その裏で本番のページは古い版のまま凍結していました。原因はコードのバグではなく、ビルド環境のディスクを使い切っていたことでした。全ページに同じ大きなデータを埋め込む実装になっていたため、ページ数ぶん膨らんで容量上限に当たり、ビルドが途中で落ちていたのです。

この話には、どのAIにも書けない情報が3つ入っています。「CMSの成功レスポンスは公開の証明にならない」「ページが200を返すことも証明にならない」「だから検証はサイトマップの最終更新日と既存ページのタイトルで行う」。実体験としてこれを踏んだ人間だけが、次に同じ罠を踏む人へ渡せる形で書けます。公式ドキュメントのどこにも書かれていません。

失敗を書くのは怖い、という反応はもっともです。ただ実際に読まれるのは、うまくいった話よりも「同じところで詰まった人の記録」でした。インデックスされない・順位が落ちたといった症状別の詰まりは、AI記事がインデックスされないときの切り分けとAI記事の順位が落ちたときに見る順番にそれぞれ分けてあります。

数値と出典をペアにして本文に埋める

もう一つ効いたのが、公式ヘルプを引いて、数値と条件を本文にそのまま埋めることです。「容量制限に注意が必要です」ではなく「上限は何GBで、超えると何が起きるか」まで書く。そのうえで、その数値の出どころを同じ場所にリンクで置きます。

数値と出典をペアにすると、記事の質は目に見えて変わりました。読者が自分の環境で検算できるようになるからです。逆に数値だけを置いて出典を付けないと、正しくても確かめられない情報になり、Trustの側で損をします。ここは機械的にチェックできるので、公開前の工程に入れてしまうのが早いです。

自社の画面・自社の日付を入れる

公式サイトのスクリーンショットではなく、自分の環境で撮った画面を入れます。管理画面でも、エラーログでも、測定結果でもかまいません。撮った日付を添えると、読者はその情報がいつの話かを判断できます。素材が1枚も無いと記事は一般論に寄りますが、画面が1枚入るだけで「この人は実際に触っている」という前提で読まれます。

「ファクトチェックを通した」だけでは経験にならない

見落としやすいのがここです。ファクトチェックは必要ですが、通しただけでは経験になりません。出てくるのは「正しいが誰でも書ける文章」です。事実の裏取りは誤りを消す工程であって、自社しか持っていない材料を足す工程ではありません。

この2つは別の作業なので、工程も分けて持つほうが運用が安定します。裏取りの手順そのものはAI記事のファクトチェックの工程に書いたので、本記事は「経験をどう足すか」に絞っています。

Trust を足す具体的な手

Trustは4要素のうち最も重要とされていながら、やることは地味です。順に挙げます。

• 運営者情報と連絡先——会社名・所在地・問い合わせ手段が、記事から1〜2クリックで辿れる状態にする。
• 執筆者名と背景——誰が書いたかを記事内に出す。肩書きだけでなく、そのテーマに関わってきた経歴にリンクを張る。「誰が」の設問に直接答える部分です。
• 更新日を正直に出す——公開日と更新日を分けて出し、中身を直していないのに日付だけ新しくしない。構造化データでは dateModified をISO 8601で、タイムゾーン情報を付けて渡すのが推奨です。著者も author で Person または Organization として名前とURLを渡せます。
• 出典を本文の中に置く——記事末にまとめるだけでなく、主張のすぐ隣に一次ソースのリンクを置く。二次情報のまとめ記事ではなく、公式・公的機関の原典を当てる。
• 訂正の出し方を決めておく——間違いが見つかったとき、黙って書き換えるのではなく「どこをいつ直したか」を残す。訂正の記録は、Trustを削るどころか最も効率よく積む材料になりました。

この5つはいずれも1記事ごとの作業ではなく、サイト全体の運用の形です。だから最初に一度決めてしまえば、以降は記事を増やすほど効いてきます。

私たちMihataは、こうした記事運用そのものをお手伝いするサービスも行っております。記事の途中で恐縮ですが、よろしければ合わせてご覧いただけたら嬉しいです。「AIが自動で書くので楽になります」という売り方はしていません。経験と数字はお客様から預かって人が埋める前提の運用で、AIに任せているのは下調べと構成、公開や内部リンクといった機械の工程です。

発注側が渡すチェックリスト

記事制作を外注する場合でも、生成ツールを社内で回す場合でも、発注側が渡さないかぎり永久に埋まらないものがあります。先の表の右端の列を、実際に渡せる単位まで割ったのが次のリストです。キックオフで一度に集めるのが最も早く、ここが空のままだと、何本作っても同じ構成の記事が並びます。

1. 自社の数字——導入件数、対応時間、価格の内訳、歩留まり、処理件数など。出せる範囲でよいので、丸めた数字ではなく実測値を渡す。
2. 失敗の記録——過去にクレームになった案件、やり直した工程、見積りを外した理由。原因と直し方まで含めて1件ずつ。
3. 判断基準——どういう条件なら受けて、どこからは断るか。見積りが上がる条件、他社に任せる条件。現場の人が頭の中だけで持っていることが多い部分です。
4. 自社で撮った写真・画面——現場、設備、管理画面、作業中の様子。フリー素材で置き換えられない1枚を渡す。
5. 執筆者・監修者の実名と経歴——誰の名前で出すかを決める。資格・許認可・在籍年数まで含めて、裏の取れる情報だけを渡す。
6. 業界固有の例外——一般論どおりにならないケース、地域差、法令・規格で決まっている条件。AIは一般論に寄るので、ここを渡さないと必ず平均的な記事になります。
7. 引いてよい一次ソースの指定——自社が根拠に使っている公式ドキュメント、業界団体の資料、公的統計。これがあると数値と出典のペアを機械的に作れます。
8. 訂正の連絡経路——公開後に間違いが見つかったとき、誰に言えば何日で直るかを決めておく。

逆に、発注側が渡さなくていいものもはっきりしています。構成案、見出しの並べ方、文章のトーン、公開作業、内部リンクの貼り直し。これらは機械の側で回せます。人の時間は上の8項目に使ったほうが、同じ予算で結果が変わります。

やってはいけない見せかけ

E-E-A-Tを「足すべきもの」と理解すると、次に出てくるのが「それらしく見せる」近道です。ここだけは明確に避けてください。見せかけは、Trustという最も重要な軸を自分から削る行為になります。

• 架空の監修者名・存在しない肩書き——「誰が」の設問に対して虚偽で答えることになります。実在しない人物の署名は、裏が取れた瞬間にサイト全体の信頼を落とします。監修者がいないなら、いないまま執筆者名で出すほうが健全です。
• 根拠のない「導入実績◯◯社」「満足度◯◯%」——検証できない数字は、あっても信頼の材料になりません。出典や算出条件を添えられない数値は書かないほうが得です。
• 他人の体験の言い換え——他社の事例記事を読んで、自社が体験したかのように書き直す。Googleのスパムに関するポリシーは「スケーリングされたコンテンツの不正使用（Scaled content abuse）」の例として、他のソースのコンテンツを十分な付加価値なくわずかに変えて使うことを挙げています。公式の定義は「検索ランキングの操作を主な目的とし、ユーザーの役に立たない多数のページが生成されること」です。経験の偽装は、まさにこの「付加価値のない変形」に当たります。
• テンプレートを量産して数で押す——同じ型に単語だけ差し替えたページを並べるのも、同じスケーリングされたコンテンツの不正使用の対象です。生成AIを使ってユーザーへの価値を足さずにページを増やす行為が、公式に例示されています。
• 評価の高い他社メディアに自社記事を置いて順位を借りる——第三者のコンテンツを、ホストサイトの既存の評価を主な理由として掲載する行為は「サイトの評判の不正使用（Site reputation abuse）」に該当します。編集上の責任を持たない寄稿の大量掲載はここに入ります。
• 期限切れドメインを買って中身を入れ替える——「期限切れドメインの不正使用」として明記されています。過去の評価を流用する発想そのものが対象です。

どれも共通しているのは、読者に対する約束を実体なしに先取りしていることです。経験が足りないなら、足りないまま「調べて整理した記事」として誠実に出す。そのうえで一次情報を1つずつ足していく。遠回りに見えますが、積み上がるのはこちらだけでした。

まとめ：今日やる順番

最後に、手を動かす順番だけ整理します。

1. 既存記事の「誰が・どのように・なぜ」に答えてみる。止まった場所が最初の修正点です。多くの場合は執筆者名と、自社が書く理由の2つ。
2. Trustの5項目を運用の形で決める（運営者情報・執筆者名・更新日・出典・訂正）。記事単位ではなくサイト単位で一度決めます。
3. いちばん伸ばしたい記事に、自社の失敗を1件だけ入れる。再現できる形で、原因と直し方まで。
4. 数値と出典をペアにする工程を公開前に挟む。機械的に点検できるので、担当が変わっても落ちません。
5. 発注側チェックリストの8項目を集める。外注でもツール運用でも、ここが揃うと記事の性格が変わります。

AIで記事を作ること自体は、公式に禁じられていません。評価されないのは、AIに渡す材料が足りていないからです。足りない材料は、ほとんどの場合、自社の中にすでにあります。