AI記事はSEOで評価されるのか｜Googleの公式見解と、実際に落ちる記事の共通点

1. 本数は増えたのに、検索から人が来ない

生成AIを導入して、記事の本数は増えました。半年で30本、40本と積み上がっている。それなのに、こうなっていないでしょうか。

• 記事数は3倍になったのに、検索経由のセッションがほとんど変わらない
• 公開直後にわずかに表示されて、そのまま伸びずに沈む
• インデックスはされているが、平均掲載順位が20位より下から動かない
• 上位に入っている記事は、AI導入前に人が時間をかけて書いた数本だけ
• 社内から「AIで書いたからGoogleに評価されないのでは」という声が出ている
• 効果が説明できないので、来期の予算が付くか怪しくなっている

いちばん困るのは、原因が分からないまま本数だけ増え続けることです。投下している工数は確実に増えているのに、成果の説明ができない。

まず結論から言うと、AIで書いたこと自体が理由で順位が下がることはない、というのがGoogleの公式な立場です。落ちる記事には別の共通点があります。順に見ていきます。

2. Googleは何と言っているか

推測を挟まずに、公式に示されている内容だけを整理します。

見解1：制作方法ではなく、品質で評価する

Google検索セントラルの公式ブログは2023年2月に「AI生成コンテンツに関するGoogle検索のガイダンス」を公開しています。ここで示されているのは、コンテンツがどのように作られたかではなく、有用で信頼できるものかどうかで評価するという方針です。AIの使用そのものを禁止する記述はありません。

見解2：順位操作を主目的とした大量生成はスパムポリシー違反

同じガイダンスで、検索ランキングの操作を主目的とした自動生成はスパムポリシーに違反すると明示されています。さらに2024年3月、Googleはスパムポリシーを更新し、大量に生成されたコンテンツの不正使用を独立した項目として整理しました。

ここで重要なのは、対象が生成手段を問わないとされている点です。自動生成か人力かではなく、検索順位を得るためだけに大量のページを作る行為そのものが対象になります。裏を返せば、読者のために作られていれば、AIを使っていること自体は問題になりません。

見解3：評価の軸はE-E-A-T

検索品質評価ガイドラインで示されているE-E-A-Tは、経験、専門性、権威性、信頼性の4つです。2022年12月に経験（Experience）が追加されました。これは検索アルゴリズムに直接組み込まれた数値ではなく、品質評価者が評価するための概念ですが、Googleが何を良いコンテンツと考えているかの指標として公開されています。

AIで書いた記事が構造的に弱いのは、このうち経験です。実際にやってみた人でなければ書けない記述は、モデルの内部からは出てきません。

見解4：有用性の評価はコアに統合された

2024年3月のコアアップデートで、それまで独立して動いていたヘルプフルコンテンツシステムはコアランキングシステムに統合されました。有用性の評価が特別なフィルタではなく、通常の評価に組み込まれたということです。

ここから導ける結論

AIで書いたから落ちるのではありません。読者のために作られていない記事が落ちるだけです。

そしてAIを使うと、読者のために作られていない記事が、以前より速く大量に作れてしまう。問題はここにあります。

E-E-A-Tの各要素をどう記事に落とすかについては、E-E-A-TとGoogleの評価基準に整理されています。

---

3. 実際に落ちる記事の共通点10と、直し方

ここからが本題です。順位が付かない記事には、はっきりした共通点があります。それぞれに、検出のしかたと直し方を付けます。

共通点1：一次情報がひとつも入っていない

症状。 記事のどこにも、自社でなければ出せない数値、事例、現場の言葉がありません。すべて公開情報の組み替えで書けてしまう内容です。

検出。 記事から、他社が同じことを書けない箇所を抜き出してみてください。3つ挙がらなければ該当します。

直し方。 一次情報の入手先は、たいてい社内にあります。営業が受けている質問、サポートへの問い合わせ、導入企業の運用実態、自社で試して失敗した記録。これらは公開されていないので、そのまま独自性になります。

以下の記事について、独自性を診断してください。

【記事】（貼る）

1. 本文の記述を「公開情報から誰でも書ける」「自社でなければ書けない」に分類してください
2. 「自社でなければ書けない」に分類された記述を列挙してください
3. 記事全体に占める割合を出してください
4. 独自性を上げるために、どんな情報をどこから足せばよいか提案してください
   （情報源は「社内の誰／どの資料」のレベルまで具体的に）

【条件】記述を創作して補わないでください。診断だけ行ってください。

共通点2：上位記事の平均を再構成しただけ

症状。 見出し構成が、検索上位の数本とほぼ同じです。書いてある内容も同じ。

検出。 自記事と上位5記事の見出しを並べてみてください。7割が重なっていたら該当します。

直し方。 網羅をやめて、差分を作ります。上位が全部書いている論点のうち読者がすでに知っているものは削り、誰も書いていないが実務でぶつかる論点を厚くします。削る勇気がないと差分は生まれません。

共通点3：検索意図とページの型が合っていない

症状。 比較したくて検索した読者に、定義の解説が返っている。手順を知りたい読者に、概念の説明が返っている。

検出。 対象キーワードで実際に検索して、上位10件のページの型を数えてください。解説記事、比較記事、事例、ツール、公式ドキュメント。上位を占める型と自記事の型が違えば該当します。

直し方。 型を合わせます。合わせたくない場合は、キーワードのほうを変えます。意図に合わない記事は、どれだけ丁寧に書いても順位が付きません。

共通点4：網羅しすぎて焦点がない

症状。 1本で7つも8つも問いに答えていて、結果としてどの問いにも浅くしか答えていません。

検出。 記事の主張を1文で書けるか試してください。書けなければ該当します。

直し方。 答える問いを3つに絞り、残りは別記事にします。分けたほうが、結果的に両方とも順位が付きやすくなります。

共通点5：経験の記述がない

症状。 「〜が重要です」「〜が求められます」で構成されていて、実際にやった痕跡がありません。

検出。 本文から、やってみた人でなければ書けない記述を探してください。失敗した話、想定と違った点、手間がかかった箇所。これらが皆無なら該当します。

直し方。 実際の運用で分かったことを書き足します。うまくいった話より、つまずいた話のほうが読者には価値があり、同時に経験の証拠にもなります。

以下の記事に、経験に基づく記述が含まれているか診断してください。

【記事】（貼る）

次の観点で該当箇所を抜き出してください。
1. 実際に試した結果として書かれている記述
2. 想定と実際が違った点についての記述
3. 手間や制約についての具体的な記述
4. 判断に迷った点と、どう決めたかの記述

該当がゼロの観点については、どんな情報を足せば埋まるかを提案してください。
提案する際、記事に書かれていない体験を創作しないでください。

共通点6：著者・出典・更新日がない

症状。 誰が書いたか分からず、出典もなく、いつの情報か分かりません。

検出。 記事ページを開いて、著者名、所属、公開日、更新日、参照元が確認できるかを見てください。

直し方。 著者情報を実名または担当部署名で入れ、プロフィールページにリンクします。統計や制度に触れている箇所には出典を明記します。更新日は自動で入る設定にします。ここは記事の中身と違って、1度整えれば全記事に効きます。

共通点7：内部リンクがなく孤立している

症状。 記事から他の記事へのリンクがなく、他の記事からも張られていません。

検出。 サイトの記事一覧に対して、リンクが1本も張られていない記事を数えてください。量産したメディアでは、この数がかなり多くなります。

直し方。 関連するテーマ同士を、本文の文脈の中でつなぎます。記事末尾に関連記事を機械的に並べるより、本文中で「この点についてはこちらで整理しています」とつなぐほうが効きます。1記事あたり2〜4本が目安です。

共通点8：タイトルと中身が一致していない

症状。 タイトルで約束したことに本文が答えていません。「10選」なのに実質3つしか説明がない、といった状態です。

検出。 タイトルに含まれる語が、本文でどう扱われているかを確認します。

直し方。 本文で実際に答えている内容だけをタイトルにします。逆でも構いません。タイトルに合わせて本文を足します。

共通点9：自社記事どうしが共食いしている

症状。 似たテーマの記事が複数あり、同じクエリで両方が中途半端な順位に留まっています。

検出。 Search Consoleで主要クエリを1つ選び、そのクエリで表示されているページを確認してください。複数のURLが出ていたら該当します。

直し方。 統合するか、明確に役割を分けます。統合する場合は、残す1本に内容を寄せ、もう一方から内部リンクを張ります。役割を分ける場合は、対象読者か検索意図のどちらかを変えます。量産したメディアで最も見落とされやすい問題です。

共通点10：公開後に一度も見直していない

症状。 公開して終わりになっており、順位が付かない理由を確認していません。

直し方。 Search Consoleの表示回数と平均掲載順位で、打ち手を機械的に分けます。

公開後の見直しをどう回すかは、記事リライトの進め方に手順が整理されています。

公開前チェックをプロンプト1本にまとめる

上の10項目を、公開前に通すチェックとして使えます。

以下の記事を、検索評価の観点で診断してください。書き直しはしないでください。

【記事】（貼る）
【狙うキーワード】（貼る）
【想定読者】（貼る）

次の10項目を、それぞれ「問題なし／要改善／重大」の3段階で判定し、
判定の根拠として本文の該当箇所を引用してください。

1. 自社でなければ書けない記述が3つ以上あるか
2. 見出し構成が一般的な解説記事の型をなぞっていないか
3. 狙うキーワードの検索意図と、記事の型が合っているか
4. 記事の主張が1文で言えるか
5. 実際にやった人でなければ書けない記述があるか
6. 出典が必要な記述に出典があるか
7. 本文中に関連記事への文脈リンクが2本以上あるか
8. タイトルの約束に本文が答えているか
9. 同じ意図の既存記事と役割が重なっていないか（判断材料を示す）
10. 読み終えた読者が次に取れる行動が書かれているか

最後に、公開前に必ず直すべき箇所を3つだけ、行を特定して挙げてください。

---

4. それでも残る限界

ここまでの10項目を潰せば、順位が付かない主な理由は取り除けます。ただ、運用に載せると別の問題が出てきます。

一次情報の調達は自動化できません。 共通点1と5は、記事制作の外側の作業です。営業やサポートから材料を集め、導入企業に話を聞き、社内の記録を掘る。ここが詰まると、他の8項目をどれだけ整えても順位は頭打ちになります。

判断が公開後にしか分かりません。 検索意図に合っているかは、実際に表示されるまで確証が得られません。1本あたり2〜3か月の観測期間が要ります。その間も記事は作り続けることになり、同じ間違いを含んだ記事が積み上がります。

本数を増やすと品質が落ちます。 10項目のチェックは1本あたり30分から1時間かかります。月10本なら回りますが、月30本になると形骸化します。そして形骸化したチェックを通った記事が、共通点9の共食いを生みます。

基準が人によって違います。 「自社でなければ書けない記述」がどのくらい具体的なら合格か。この線引きは担当者ごとに違い、結果として記事ごとに水準が変わります。チェックリストを配っても、この差は埋まりません。

担当者が変わると水準が落ちます。 材料の集め方も、チェックの厳しさも、その人の経験に紐づいています。異動があると、メディア全体の質が一段下がる。積み上げた評価が、そこから緩やかに落ちていきます。

限界の正体は、AIの能力ではありません。一次情報を材料にする工程と、品質を判定する工程が、どちらも人の手作業で残っていることです。

---

5. 一次情報を起点にする工程を仕組みにする

検索で評価される記事に共通しているのは、公開情報の組み替えではなく、その組織にしかない材料から書かれていることです。だとすれば、一次情報を集める工程こそ、仕組みに載せる価値があります。

sonataは、取材や社内ヒアリングの音声を起点に記事を作るサービスです。音声をアップロードすると、事前のWeb調査、企画、文字起こし、構成、記事生成までが一連の流れとしてつながっていて、工程間の受け渡しを人がやらなくて済みます。この音声から記事化までの一連のワークフローについて特許を出願しています。

素材が話し言葉なので、この記事で挙げた共通点1と5、つまり一次情報と経験の記述が、生成の前段階から入っています。あとから独自性を足す作業ではなく、最初から独自の材料で書き始める形になります。

同じ工程を全員が通るので、担当者が変わっても記事の水準が個人の慣れに左右されにくくなります。

無料で試せます。社内の商談録音やヒアリング音源を1本入れて、いま公開している記事と読み比べてみてください。

• sonataを無料で試す

まずは直近に公開した記事を、§3の公開前チェックプロンプトにかけてみるのが早いと思います。10項目のうちどこが「重大」になるかで、いま補うべき工程が見えてきます。