【Google検索セントラル解説】生成AIコンテンツの利用ガイダンス｜2026年10月更新で公開前の人による事実確認を明記

2026年10月8日

中野輝規

生成AIで記事の下書きを作る会社は、小さな会社でも増えました。気になるのは「Googleは、AIで作った記事をどう扱うのか」です。

Googleはこの問いに、検索セントラルの1ページで答えています。

この記事は、そのページ「生成AIによるコンテンツの利用に関するガイダンス」を英語版の原文から読み、要点を整理します。

2026年10月1日に英語版だけが更新され、日本語版にはまだ反映されていない文があります。その差も具体的に示します。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。記事づくりにAIを使う会社として、Googleが公開前の確認をどこまで求めているのかを、原文で確かめておく必要がありました。

結論：3行で言うと

Googleが問題にしているのは、AIを使うこと自体より、読者への価値を足さないまま大量のページを作ることです。これは「大量生成コンテンツの不正使用」というスパムポリシーに当たる可能性があります
2026年10月1日の更新で、生成AIの出力は不正確になりうるので、公開前に人の手ですべて事実確認することが欠かせない、と明記されました。確認の対象は本文に加え、タイトル・メタディスクリプション・構造化データ・画像の代替テキストまで含みます
自動で作ったコンテンツには、どう作ったかを読者に伝える工夫を検討するよう勧めています。通販でMerchant Centerを使う場合は、AI画像のメタデータとAI生成の商品データの区別が必須です

このページの基本情報

項目	内容
原題（英語）	Google Search’s guidance on using generative AI content on your website
日本語版の題名	ウェブサイトで生成 AI によるコンテンツを使用するための Google 検索のガイダンス
英語版の最終更新日	2026年10月1日
日本語版の最終更新日	2025年12月31日
検索セントラルの中の位置	「SEOの基礎」の中の「生成AIの基礎」。左側の目次での名前は「生成AIの利用に関するガイダンス」
直近の主な更新	2026年10月1日、変更履歴に「生成AIコンテンツの利用に関するガイダンスを更新」。ページ自体の初出は2025年5月21日

原文はこちらで読めます。英語版／日本語版。

Googleがこのページで言っていること

導入：AIは役に立つが、価値を足さない大量生成は違反になりうる

Googleはまず、生成AIはテーマを調べるときや、オリジナルのコンテンツに構成を与えるときに特に役立つ、と述べています。

そのうえで、生成AIなどの道具で、利用者への価値を足さずに多くのページを作ると、大量生成コンテンツの不正使用というスパムポリシーに違反する可能性がある、と書いています。

リンク先のスパムポリシーも開いて確かめました。そこでは、作り方を問わず、順位を操作する目的で独自性の乏しいページを大量に作る行為を対象にしています。

例として、価値を足さないAIでの大量生成のほか、他サイトの内容を言い換えや翻訳で加工して並べる行為なども挙がっています。

次に、検索品質評価者ガイドライン（Googleが外部の評価者に渡している評価の手引き）を参考にできる、と案内しています。参照先は次の2つの節です。

節	中身（2025年9月11日付の版を開いて確かめた範囲）
4.6.5 大量生成コンテンツの不正使用	独自性や付加価値の無いコンテンツを大量に作ったサイトは、作り方にかかわらず最低の評価にする、という基準です
4.6.6 手間・独自性・付加価値がほぼ無い主要コンテンツ	ページの中身のほぼすべてが、コピー・言い換え・自動生成などで手間も独自性も乏しい場合に最低の評価とする基準です。同時に、生成AIを使ったこと自体は手間や品質を決めない、とも書かれています

ただしGoogleは、このガイドラインは上位表示の手引きではないこと、評価者の評価は順位に直接影響しないことも、同じ段落で明記しています。

節1：正確さ・品質・関連性を最優先する

とくに自動で生成するときは、正確さ・品質・関連性を優先するように、というのがこの節の主題です。

2026年10月1日の更新で、ここに理由と求める行動が書き足されました。

生成モデルは事実を取り出しているわけではなく、学習したデータをもとに、次に来そうな語の並びを予測しています。

そのため出力には不正確な内容（ハルシネーション）が混じることがある、という説明です。

そして、次の1文が続きます。

“It is critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing.”
（和訳：公開する前に、AIが生成したすべてのコンテンツについて、正確さと信頼性を人の手で事実確認し、見直すことが欠かせません。）

この確認は、検索結果に表示されうる次のメタデータにも及ぶ、と書かれています。

タイトル要素（ページの題名）
メタディスクリプション（ページの説明文）
構造化データ（ページの内容を、機械が読める形で書き添えたデータ）
画像の代替テキスト（画像の内容を言葉で書いたもの）

構造化データについては、一般的なガイドラインと機能ごとの個別ポリシーに従い、マークアップを検証して、検索の機能に表示される条件を満たすように、と付け加えています。

節2：読者に背景を伝える

コンテンツをどう作ったかを伝えると、読者が内容を受け取る手がかりになる、というのがこの節の趣旨です。自動で生成している場合は、自動化をどう使ったかの説明や、画像のメタデータの追加を、読者にとって自然な形で検討するよう勧めています。

通販サイト向けには、Merchant CenterにAI生成コンテンツのポリシーがある、と案内しています。要点は次の2つです。

AIで生成した画像には、IPTC（報道写真などのメタデータ規格を定める団体）のDigitalSourceTypeという項目で、TrainedAlgorithmicMedia（生成AIで作った、という意味の値）を入れる必要があります
AIで生成した商品のタイトルや説明は、通常の項目と分けて指定し、AI生成だと示す（ラベルを付ける）必要があります

リンク先のポリシーも開いて確かめました。商品のタイトルと説明は、AI生成用の専用の属性に入れる形でした。

生成ツールが画像に埋め込んだメタデータを消さないように、という注意もありました。

最後に、2023年2月のブログ記事のよくある質問を挙げています。

英語版と日本語版の違い

英語版は2026年10月1日、日本語版は2025年12月31日が最終更新です。2026年10月3日に両方を取得して比べると、次の差がありました。

箇所	英語版（2026年10月1日）	日本語版（2025年12月31日）
節1の冒頭	生成モデルは事実を取り出さず、次の語の並びを予測する。そのため不正確な出力（ハルシネーション）がありうる、という説明がある	この説明が無い
節1の冒頭	公開前に、すべてのAI生成コンテンツを人の手で事実確認・見直しすることが欠かせない、と明記	この1文が無い
メタデータの扱い	上の「見直し」がメタデータにも及ぶ、という書き方	正確さ等を優先する対象にメタデータも含む、という書き方
導入の1文目	オリジナルのコンテンツに「構成（structure）」を与えるときに役立つ	「オリジナルコンテンツに構造化データを追加したり」する際に便利

4行目は更新とは関係のない、訳の差です。英語版の”structure”は、文章の組み立てを整える意味だと私は読みました。

日本語版だけを読むと、構造化データという特定の技術の話に見えてしまいます。英語版を正として読むのがよいと考えます。

更新の経緯

Googleの変更履歴によると、このページは2025年5月21日に、AI機能に関するページと一緒に新しく公開されました。

2026年10月1日の項目では、変更の内容を「評価者ガイドラインの情報で更新した」、理由を「開発者向けイベントで使っている発表資料と内容を揃えるため」と説明しています。

インターネットアーカイブ経由で保存した2025年12月10日版の英語版と、現在の英語版を1文ずつ比べました。評価者ガイドラインの4.6.5と4.6.6への言及は、12月10日版と日本語版にすでにありました。

比較で増えていた本文は、ハルシネーションの説明と、公開前の人による確認を求める文でした。2026年6月21日と9月27日の保存版も、本文は12月10日版と同じでした。

10月2日の保存版で、現在の内容に変わっています。

あわせて、メタデータの文も書き換えられていました。以前は「正確さなどを優先する対象にメタデータも含む」という書き方でしたが、今は「この見直しがメタデータにも及ぶ」という書き方です。

このページから、言えること・言えないこと

言えること	言えないこと（よくある誤解）
AIを使うこと自体は、ガイドライン違反として扱われていない。参照先のブログのよくある質問も、適切な使い方は違反に当たらないと答えている	「AIで書けば順位が上がる」。同じよくある質問は、AIを使っても特別に有利にはならないと答えている
価値を足さずに大量のページを作ると、スパムポリシー違反になりうる	「月に何本までなら安全」。このページにもスパムポリシーにも、本数の線は書かれていない
公開前に、人がすべてを事実確認・見直しすることを「欠かせない」と書いている	「人が確認すれば必ず評価される」。確認は正確さを守るための前提として書かれている
評価者ガイドラインの4.6.5と4.6.6を、考え方の参考として挙げている	「評価者の点数がそのまま順位になる」。評価は順位に直接影響しないと明記されている
Merchant Centerでは、AI画像のIPTCメタデータとAI生成の商品データの区別が必須	「すべてのサイトの画像にメタデータが義務」。検索のページでは、画像メタデータの追加は「検討」を勧める書き方

中小企業の視点で、どう受け取るか

ここからはGoogleの説明とは別の、私の読み取りです。従業員が数人から数十人の会社で、WordPressのサイトを運用している場合を想定しています。

1. 公開前の確認を「本文」から「検索結果に出る部分」まで広げる

今回の更新でいちばん実務に効くのは、確認の範囲がメタデータまで明記された点だと読みました。本文は丁寧に読んでも、タイトルや説明文はAIの案をそのまま通しがちです。

WordPressなら、確認する場所は次の3つです。

投稿の編集画面のタイトル欄。本文の結論と食い違っていないかを読みます
お使いのSEO用プラグインやテーマにある、メタディスクリプションの入力欄。空欄だと、本文の冒頭が機械的に切り取られて使われる設定のものもあります
メディアライブラリで画像を開いたときの「代替テキスト」欄。画像の内容を一言で表しているかを見ます

公開後は、ブラウザでページのソースを表示して description を検索すると、実際の説明文を確かめられます。

2. 事実確認の対象を、数字・固有名詞・日付・URLに絞って決めておく

Googleは「すべてを人の手で」と書いています。小さな会社では、確認の順番を先に決めておくと続けやすくなります。

私は、間違えると信頼を損なう箇所から確かめるのが現実的だと考えます。数字、人名や制度名などの固有名詞、日付、リンク先のURLです。

外注先から納品された原稿を受け取る場合の手順は、外注記事の生成AI利用と検収の手順をまとめた記事に書いています。

3. 構造化データは、テストツールで実物を確かめる

構造化データは、テーマやプラグインが自動で出していることが多い部分です。Googleはマークアップの検証を求めているので、Googleの「リッチリザルトテスト」に記事のURLを入れ、エラーや意図しない内容が出ていないかを見ておくと安心です。

Search Consoleを使っている場合は、左のメニューの「拡張」にある各レポートで、サイト全体の構造化データの状態も確かめられます。

4. 「どう作ったか」は、読者が気にしそうなときに書き添える

このページは、作り方の説明を「検討」するよう勧めています。参照先のよくある質問も、読者が「これはどう作られたのか」と思いそうなときに開示を考える、という書き方でした。

同じよくある質問は、AIを著者として表示するのは最善ではないだろう、とも答えています。また、Googleの有用なコンテンツの作成に関するページは、AIで作った顔写真や架空の経歴で書き手を装うことを、欺く行為として挙げています。

著者は実在の人の名前で書き、必要に応じてAIの使い方を一言添える形が、無理のない線だと私は考えます。

AIを使った記事づくりの手順全体は、生成AIの記事作成でGoogleペナルティを避ける完全ガイドで扱っています。この記事は公式ページの解説、あちらは社内での進め方、という役割分担です。

弊社のサイトで確かめたこと

このページの主題に沿って、弊社サイトの公開記事3本のHTMLを、2026年10月3日に次のコマンドで取得して読みました。対象は、上でリンクした2本と、論文解説の記事1本です。

curl -sL （記事のURL）

取得したHTMLから、該当する部分を抜き出した結果です。

確認した項目	結果
タイトル	3本とも、記事の見出しと同じ内容の題名が入っていた
メタディスクリプション	1本は記事の要点を書いた説明文だった。残りの2本は本文の冒頭が途中で切れた形で、1本は「お聞きす」、もう1本は英語の語句の途中で終わっていた
アイキャッチ画像の代替テキスト	2本は画像の内容を表す日本語だった。1本は英単語1語（歯車を意味する語）で、記事の内容を表していなかった。構造化データの画像の説明にも同じ語が入っていた
構造化データ	3本とも、記事を表すデータが2つの別々のまとまりで出力されていた。著者の指し方がまとまりごとに違っていた
アイキャッチ画像のメタデータ	3本の画像ファイルを取得し、ファイル内の区画を一覧にした。画像本体の区画だけで、テキストやメタデータの区画は入っていなかった