日本語
サイトをチェック

SEO AI 活用：結果を確認できる3つの方法と、避けたい1つ（検証しました）

SEOgrinder 編集部 · 公開日 · 更新日 · 読了時間 約17分

結論： SEO AI 活用でいちばん安全なのは、結果を自分で確認できる仕事を AI に任せることです。それに当てはまる方法が3つあります。コーディングエージェントが、SEOgrinder のレポートの指摘を1件直す。AI がタイトルとメタディスクリプションの案を出し、人が文字数と事実を確認する。AI が JSON-LD を書き、Google のリッチリザルト テストで検証する。避けたいのは、ユーザーへの価値を加えないまま大量のページを生成することで、Google のスパムポリシーはこれを scaled content abuse と呼んでいます。

テスト状況（2026年11月5日）： 下で説明しているテストは実施済みで、合格しました。測定値は公開しないため、この記事は、それ以上の結果を述べていません。

AI のコンテンツは Google のルールに反する？

それだけで反することはありません。Google は、AI コンテンツについての FAQ でこの疑問に答えています。“Appropriate use of AI or automation is not against our guidelines.”（AI や自動化を適切に使うことは、ガイドラインに反しません）。同じ回答に、限界も書かれています。検索順位を操作することを主な目的としてコンテンツを生成するために AI を使ってはならず、それは Google のスパムに関するポリシーに違反するからです。有用なコンテンツのページも、AI による生成を含む自動化について、同じことを述べています。検索順位を操作することを主な目的にコンテンツを作ることは、“a violation of our spam policies”（スパムポリシーへの違反）です。

つまり Google が線を引いているのは、ツールではなく目的です。Google の生成 AI コンテンツについてのガイダンスは、推奨する使い方を1つ挙げています。“Generative AI can be particularly useful when researching a topic, and to add structure to original content.”（生成 AI は、トピックの調査や、オリジナルのコンテンツに構成を加えるのに、とくに役立ちます）。同じページは、あなたに果たすべきことも求めています。“It is critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing.”（公開前に、AI が生成したすべてのコンテンツの正確さと信頼性を、手作業でファクトチェックし、レビューすることが重要です）。このページによれば、確認の対象は、title 要素、メタディスクリプション要素、構造化データ、画像の alt テキストといったメタデータにも及びます。検索結果に表示されることがあるからです。以下の方法2と方法3は、まさにこの1文を軸に組み立てています。

SEO AI 活用の全体像：3つの方法と1つの警告

3つの方法は、どれも同じパターンに従っています。下書きは AI が行い、結果が正しいかどうかは、AI の外にあるものが決めます。新しいスキャン、文字数とページの内容との照合、あるいは Google 自身の検証ツールです。

やり方AI がすること正しいかを決めるもの
方法1コーディングエージェントが、指摘を1件直すためにコードを変更する変更が公開されたあとの、新しい SEOgrinder のスキャン
方法2タイトルとメタディスクリプションの案を出す人：文字数の確認と、すべての記述をページと照合すること
方法3ページの JSON-LD を書くGoogle のリッチリザルト テスト、そして目に見えるページとの照合
避けたいこと大量のページを生成する何もない。そこが問題（下を参照）

方法1：コーディングエージェントに指摘を1件直させる

SEO のレポートには、canonical タグがない、タイトルがない、といった機械的な指摘が含まれます。正解は1つで、ページを取得すれば確認できます。だから、Claude Code、Cursor、GitHub Copilot のようなコーディングエージェントに向いた仕事です。安全のためのルールを含めた全手順は、AIコーディングエージェントで SEO を直す記事にあります。ここでは短くまとめます。

公開しているページのアドレスを SEOgrinder に入力します。無料で、アカウントは不要です。レポートの「AI に渡す」を押すと、ブリーフィングが開きます。これは Markdown の作業指示書で、すべてのタスクに、確認できる「完了条件」が付いています。1つのタスクだけを渡すには、そのタスクのカードにある同じボタンを押します。ブリーフィングをエージェントに渡し、タスクを1つだけ行って止まるよう伝えます。差分を読み、変更を公開してから、「再チェック」を押します。SEOgrinder はレポートを最長24時間保持し、このボタンは新しい実行を強制します（1時間に数回まで使えます）。

新しいレポートから指摘が消えていれば、この方法は効きました。まだ残っているなら、エージェント自身の要約が伝えていたのは、変更するつもりだった内容であって、公開されている内容ではありません。SEOgrinder が読むのは公開されているページだけなので、自分のノートパソコンにしかない変更は、見えません。

ここで1つ、限界を書いておきます。直った指摘は、技術的なエラーを1つ取り除くだけです。SEOgrinder は技術面の土台のほとんどを調べますが、すべてではありません。順位が良くなることを約束するものではなく、SEOgrinder は順位も、AI アシスタントがサイトを挙げるかどうかも測りません。

方法2：AI にタイトルと説明文の案を出させ、人が確認する

下書きは、AI が時間を節約してくれる場面です。モデルは数秒で、タイトルを3案、説明文を3案出してくれます。リスクは、あなたのページに書かれていない記述が入ることです。数字、約束、機能などです。タイトルと説明文は検索結果に表示されることがあるので、上で見た Google のファクトチェックの規則が、そのまま当てはまります。

確認を簡単に保つための手順は、次のとおりです。

  • AI に元の文章を渡す。 ページの本文を貼り付け、キーワードを伝え、本文にないことは書かないよう禁止します。たとえば、次のようなプロンプトです。
この後に続くページ本文について、タイトルを3案、メタディスクリプションを3案、書いてください。
本文に出てくる事実だけを使い、数字、価格、受賞歴、約束を付け加えないでください。
主要なキーワードを各タイトルの先頭近くに置き、読者が何を得られるかを書いてください。
  • 文字数は自分で数える。 モデルが言う長さを信じないでください。ターミナルで printf '%s' "SEO AI 活用：3つの方法と Google が警告する1つの使い方" | wc -m を実行すると、35 と出力されます。
  • すべての記述をページと照合する。 案の中の主張がページになければ、削除するか、先にページに書き加えます。
  • 1案を選ぶか、手直しする。 訪問者が読むつもりで読んでください。

ここで関わる制限には、2種類あります。タイトルの 30〜60文字 と、説明文の 110〜160文字 という範囲は、私たち自身のブログのチェックが求める値です（日本語と韓国語の記事では、下限がタイトル15文字、説明文60文字になります）。Google が求める条件ではありません。Google のページは、決まった上限を挙げていません。title 要素の長さに上限はなく、メタディスクリプションの長さにも上限はありません。どちらの場合も、Google 検索では結果が「必要に応じて、通常はデバイスの幅に収まるように」切り詰められます（“as needed, typically to fit the device width”）。私たちの読み方では、短いほうが切られにくいので、この範囲を目安にしています。

表現については、Google の有用なコンテンツのページが、どんな案にも当てられる2つの問いを挙げています。メインの見出しやページタイトルは、コンテンツの説明的で役立つ要約になっているか。誇張や衝撃を狙う表現を避けているか。また Google は、ページ内のテキストよりもメタディスクリプションのほうがページを正確に説明している場合には、それをスニペットに表示することがあるとも述べています。そこにある誤った主張は、検索した人に届くことがあります。

方法3：AI に JSON-LD を書かせ、検証ツールで確かめる

構造化データは、文書化されたルールを持つコードです。だから AI にも、機械によるチェックにも向いた仕事です。Google は、サイトの構成が許すなら JSON-LD を推奨しています。パンくずリストについては、Google のドキュメントが、少なくとも2つの ListItem を持つ BreadcrumbList を定義するよう述べています。必須のプロパティは、リストの itemListElement と、各項目の name および position です。item のアドレスは、最後の項目を除くすべてのパンくずで必須です。ほかのタイプにも固有の必須プロパティがあるので、案を信じる前に、自分のタイプのページを Google のドキュメントで開いてください。ブログページの BreadcrumbList は、example.com をサイトとして、次のようになります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "ブログ", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "SEO AI 活用" }
  ]
}
</script>

このコードをリッチリザルト テストに貼り付けます。ページのアドレス用のタブと、コード用のタブがあります。Google は、その目的を、ページに含まれる構造化データからどのリッチリザルトが生成されうるかを示すものと説明しています。

「合格」が何を意味するかは、正確に捉えてください。Google の構造化データのガイドラインには、“Google does not guarantee that your structured data will show up in search results”（構造化データが検索結果に表示されることを、Google は保証しません）とあり、これは、リッチリザルト テストでマークアップが正しいと出た場合にも当てはまります。合格だけでは足りません。Google のパンくずリストのページには、“You must follow these guidelines to be eligible to appear with breadcrumbs in Google Search”（Google 検索でパンくずリストとともに表示される対象になるには、これらのガイドラインに従う必要があります）とあり、ページは Google から到達できる状態で、robots.txt、noindex タグ、ログインでブロックされていてはなりません。合格したからといって、リッチリザルトが生まれるわけではありません。たとえばパンくずリストは、ドキュメントでは、デスクトップで利用できる機能とされています。

このテストが確認するのは構造です。内容が正しいかどうかは教えてくれませんし、モデルは、もっともらしく見えるプロパティを付け足すことがあります。同じガイドラインは、ページの読者に見えないコンテンツをマークアップしないよう述べています。そこで、マークアップをページと照合してください。中に書かれたすべての名前、日付、アドレスが、ページに載っている必要があります。公開したあと、SEOgrinder は、構造化データのないページ、読み取れない JSON-LD ブロック、Google が必須とする項目が欠けたエントリを報告します。すべてのページにマークアップが必要なわけではありません。レポートには、ページに合うリッチリザルトのタイプがない場合は、構造化データがなくても問題ないと書かれています。

避けたい使い方：価値のないページの大量生成

Google のスパムポリシーは、これを1文で定義しています。“Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users.”（Scaled content abuse とは、ユーザーの役に立つことではなく、検索順位の操作を主な目的として、多数のページが生成されることです）。ポリシーにある例の1つは、“Using generative AI tools or other similar tools to generate many pages without adding value for users”（生成 AI ツールやそれに似たツールを使って、ユーザーへの付加価値のないまま、多数のページを生成する）です。ポリシーは、これが「作り方を問わず」不正にあたる（“no matter how it's created”）と付け加えています。同じ一覧には、フィード、検索結果、そのほかのコンテンツをかき集めて多数のページを作ること、異なるページのコンテンツをつなぎ合わせること、読者にはほとんど意味が通らないが検索キーワードは含んでいる多数のページを作ることも挙がっています。

結果は、はっきりと書かれています。ポリシーに違反したサイトは「検索結果での順位が下がる、またはまったく表示されなくなることがある」（“may rank lower in results or not appear in results at all”）とされ、Google は違反を、自動化されたシステムと、必要に応じた人による審査で検出します。それが手動による対策につながることもあります。自分のサイトにそうしたコンテンツがある場合の、ポリシーの指示は短いものです。“exclude it from Search”（検索から除外する）。

これは、私たちがテストしない唯一のやり方です。何が起きるかを見るために、価値のないページを公開することはしません。この警告は、Google の文章だけに基づいています。

AI はどこまで使うと多すぎる？

Google は数字を示していません。この記事のために読んだ4つの Google の文書（ポリシー、生成 AI コンテンツについてのガイダンス、有用なコンテンツのページ、FAQ の投稿）には、パーセンテージも、多すぎるとみなされる AI が書いたテキストの割合も書かれていません。「AI は X パーセントまでなら安全」という形の規則は、Google から出たものではありません。

Google が数字の代わりに示しているのは、問いです。有用なコンテンツのページは、とりわけ次のように尋ねています。“Are you using extensive automation to produce content on many topics?”（多くのトピックのコンテンツを作るために、大規模な自動化を使っていますか？）と、“Are you producing lots of content on many different topics in hopes that some of it might perform well in search results?”（検索結果で成果が出るものもあるだろうと期待して、多くのさまざまなトピックについて、大量のコンテンツを作っていますか？）。これらは自分自身に向ける問いであって、規則ではありません。Google は、ページの「なぜ」を、おそらくもっとも重要な問いだとしています。コンテンツは、主に人の役に立つために作られるべきだ、ということです。

同じページは、検索品質評価者（search quality rater）が労力を見ていること、そして生成 AI で大量のテキストを作ることは、“without manual oversight or curation represents little to no effort”（人による監督や選別なしでは、ほとんど、あるいはまったく労力を表していない）と述べています。Google は、AI コンテンツについてのガイダンスの中で、評価者の評価はランキングに直接影響しないとも付け加えています。以下は私たちの見方で、Google の発言ではありません。どのページについても、ほかのページを要約するだけでは得られないもの、たとえば自分で行った測定やスクリーンショットが入っているか、そして人が事実を確認したかを問うてください。そうだと答えられないなら、AI がどれだけ関わったかにかかわらず、問題はそのページにあります。

私たちのテスト：2026年11月5日にやったこと

見出しには「検証しました」とあります。この節は、その検証を説明しています。測定値は公開しません。

開示： SEOgrinder は私たちのツールで、私たちが開発しています。

テストは2026年11月5日に、1回あたり約10分の実施を3回、私たち自身のウェブサイトで、テストを行う担当者が行いました。

  1. 方法1、未対応の指摘があるページ。 そのページを SEOgrinder でスキャンし、未対応の指摘を書き留める。「AI に渡す」でコーディングエージェントに渡し、差分を読み、変更を公開して、「再チェック」を押す。
  2. 方法2、このブログの新しい記事。 記事の本文から、AI にタイトルとメタディスクリプションの案を出させる。文字数を数え、すべての記述を記事と照合して、1案を選ぶ。
  3. 方法3、ブログの1ページ。 そのページの JSON-LD を AI に書かせ、そのコードを Google のリッチリザルト テストに貼り付ける。

記録するのは、日付と時刻、使ったツールのバージョン、実施1の前後の SEOgrinder のレポート、変更を含むコミット、実施2の各案の文字数、実施3のリッチリザルト テストのスクリーンショットです。

結果：3回の実施は合格しました。測定値は公開しません。4つ目のやり方、つまり価値のない大量のページを公開することは、テストに含めません。

よくある間違い

  • AI の下書きを読まずに公開する。 Google はこの確認を「重要」（“critical”）と呼んでおり、対象はタイトル、説明文、構造化データ、alt テキストに及びます。
  • モデルが言う文字数を信じる。 自分で数えてください。
  • ページにないことをマークアップする。 Google のガイドラインは、構造化データが、読者に見えるコンテンツを記述するものでなければならないと述べています。
  • 「合格」を「リッチリザルトが保証される」と読む。 構造化データが表示されることは保証しないと、Google ははっきり述べています。
  • エージェントにレポート全体を一度に渡す。 差分が大きいと、どの変更がどの問題を起こしたのかが分からなくなります。指摘を1つずつ進めるほうが時間はかかりますが、はるかに安全です。
  • 試し読みなしで、方法を何百ページにも適用する。 まず1ページで試し、結果を読んでから、広げてください。
  • パーセンテージを、Google が出したもののように引用する。 私たちが読んだ文書には、書かれていません。

よくある質問

Google は、AI が書いたコンテンツにペナルティを与えますか？

Google は、AI の適切な利用はガイドラインに反しないと述べています。スパムポリシーは、検索順位を操作することを主な目的として作られたコンテンツを対象にしており、違反したサイトは順位が下がるか、まったく表示されなくなることがあります。決め手になるのは、ツールではなく、目的とユーザーへの価値です。

AI のコンテンツには、表示が必要ですか？

Google は、これを推奨として述べています。ガイダンスは、コンテンツがどのように作られたかについての情報を、読者にとって意味のある形で加えることを検討するよう述べており（“consider adding information on how your content was created in a way that makes sense for your audience”）、FAQ は、そうした開示を「当然期待される場合」に加えるよう述べています（“when it would be reasonably expected”）。

記事の著者として AI を挙げてもよいですか？

Google の FAQ によれば、AI を著者として記載することは、コンテンツの作成に AI が関わっていることを読者に分かりやすく伝える方法として、「おそらく最善ではありません」（“is probably not the best way”）。

これらの方法で、順位は上がりますか？

誰にも約束できません。方法1は技術的なエラーを取り除き、方法2はページが検索結果にどう表示されるかを変え、方法3はリッチリザルトが依存するマークアップを検証します。順位を保証するものは、3つのどれにもありません。

次の一歩

SEOgrinder で自分のサイトの無料スキャンを実行し、一覧の最初のタスクを選んで、その指摘1件で方法1を試してください。渡し、差分を読み、公開し、「再チェック」を押します。エージェントと作業する際の安全ルールを先に読みたい場合は、AIコーディングエージェントで SEO を直す記事を読んでください。

あわせて読みたい

ブログのほかの記事